前回はオンプレミス環境出身のエンジニアから見たクラウド環境でのメリットについて取り上げました。今回はその反対であるデメリットについてお話ししたいと思います。クラウド特有のデメリットを知り、業者選定や運用を行うことによってこそ、前回お話ししたメリットを多分に享受することができると考えます。

クラウドの抱えるデメリットは4点あります。

1)パフォーマンスが揺らぐこと
2)ハードウェアやネットワークの把握が難しいこと
3)メンテナンス計画・成長計画が運用会社任せであること
4)データ管理の委託とサービス終了についての懸念があること
5)サービス特有の知識が潤沢に必要なこと

次にそれぞれの詳細について見て行きましょう。

1)パフォーマンスの揺らぎ

ハードウェアやネットワークを複数のユーザーで分け合うことによって安価なサービス提供を実現しているクラウドは、計算機資源やネットワーク資源を様々な技術で顧客が互いに影響しないように設計・運用されています。しかし実際問題としてこれらのパフォーマンスには一定以上の揺らぎが存在します。

計算機資源の揺らぎを仮想環境のユーザーレベルで感じたり計測したりすることは難しいのですが、ネットワーク伝送遅延時間の揺らぎについては明確に感じることができます。AWS(Amazon Web Services)の場合、任意のサーバ間で ping を打つだけでも、伝送遅延時間の揺らぎを大きく感じられることが多々あります。加えて EBS(Elastic Block Store)と呼ばれるネットワーク越しにマウントされるディスクがあるのですが、こちらにも伝送遅延時間の揺らぎが存在し、Read/Write テストをしてみるとその影響を実際に感じることができます。

こうした伝送遅延時間の揺らぎは、一般的な Web サービスを運用している限りは特段に目くじらを立てるような影響はありません。強いて言えばオンプレミス環境と同等の厳しい閾値(しきいち)でサービスの生存監視をしていると、いわゆる「ハズレ」のハードウェアやネットワーク環境上で起動しているインスタンスと呼ばれる仮想サーバから、時々ソケットタイムアウトや NTP(Network Time Protocol)の時刻同期ムラに関する警告がある程度です。しかし提供するサービスがリアルタイム性の高いオンラインゲームのようなものだと、サービス品質に影響することがあるため、無視しにくい問題となります。

AWS の場合は利用するインスタンスプランが上位であればあるほど、計算機資源やネットワーク資源が優先的に割り当てられるのでパフォーマンスの揺らぎについては優位となります。しかし各種パフォーマンスチューニングを行っても、真っ当なオンプレミスと同等の環境を作ろうとすると難しいと言わざるを得ません。監視にしろ、サービスにしろ、ある程度は揺らぎを考慮したシステム設計が必要です。

2)ハードウェアやネットワークの把握が難しいこと

ユーザーが状況を監視することができるのは、通常のパブリッククラウド環境であれば仮想環境より上位のレイヤになります。どんなに監視ツールを駆使しても仮想環境より下位レイヤのホスト環境の OS・ハードウェア、接続されたネットワークの状況を把握し、障害時に迅速な問題切り分けをすることには限界があります。

この仮想環境より下位レイヤの状況を知るためには、クラウド事業者に問い合わせ、回答を待たなければなりません。データセンター全域で起きているような大規模な障害であればむしろ即答も期待できますが、仮想環境が存在するハードウェアレベルになると、回答のための個別調査が発生するために時間が掛かる印象があります。AWS の場合、サポートプランにも松竹梅とあるので上位の場合はある程度の即答が期待できますが、それ以外のプランですと回答時間がある程度長くなることもあるため、緊急性の高い障害発生時はある程度諦めなければなりません。

こうしたリスクが存在することを前提に、複数の地点に分散してトポロジを組んだり、常時バックアップ技術と組み合わせて気軽に代替の環境をセットアップしたりできるような準備をしておくのが良いでしょう。

3)メンテナンス計画や成長計画が運用会社任せであること

前回述べたクラウドのメリットとして、設備の更新やサポートについて意識しなくて良いと挙げました。しかしその裏返しとしてメンテナンス計画や成長計画が運用会社任せであることがあります。

AWS の場合、ハードウェアやネットワークメンテナンスの告知は2週間から1か月ほど前にメールと Web 画面によって通知されます。先日の勉強会でヒアリングした上で再認識しましたが、AWS を利用していると必ず届くものではありません。まさしく自分たちがセットアップした仮想サーバがメンテナンス対象の範囲にあるかないかの運です。運が良ければ全く経験せずに済みますし、運が悪ければ運用している仮想サーバの6割が一ヶ月後に再起動すると宣言されたり、対象となる台数がたとえ少なかった場合であっても、マスター DB サーバや NFS(Network File System)サーバのようなクリティカルなサービスを行っているサーバに白羽の矢が立ったりするとサービスへの影響は大きなものになります。

こうした運用会社都合のメンテナンスは基本的に自らが運営するサービスの都合とは関係なく起こる事象ですので、ある程度備えたサービス構成が必要になります。

4)データ管理の委託についての懸念

前々回に触れましたが、クラウド事業者も雨後の竹の子の如く多くのソリューションと共に登場しています。2000年頃、IT 革命黎明期にはこうしたクラウド事業者のような勢いで ISP が登場していました。しかし電話線によるダイアルアップ接続から ISDN を一瞬経験した後は、ADSL、CATV、光ファイバーと目まぐるしく時代は移り、その膨大な設備投資と価格競争を前に中小の ISP は淘汰されていきました。中には夜逃げした ISP というのも話題になりました。

それではクラウド事業者が当時の ISP のような流れを辿るとどうなるでしょうか。まだまだ現段階では希少な出来事ですが、弊社の別サービスでは以前、クラウド事業者のサービス終了を経験したことがあります。ある日メールが届いたかと思うと、本文には2週間で他社へ移って欲しいという内容が書かれていました。影響の少ないサービスではあったものの、他社サービスでの環境設定、データ移行、動作検証、負荷試験を突然言い渡されるというのは非常に厳しいものがありました。

インターネット接続のみを提供していた ISP とは違い、クラウドサービスが突如終了となるとその上で動いていたサービスや、蓄積された貴重なデータ資産をまるまる失ってしまうことになります。こうしたリスクも踏まえ、事業者選びをすることが重要です。

5) サービス特有の知識が潤沢に必要

クラウドを語る際に「プログラマブルな」などと形容されることが多々ありますが、実際にJAWS-ug(Japan AWS Users Group) などに参加すると、ユーザーとしてクラウド環境を用いている人は Web プログラマーやデザイナーの方が多い印象です。元々オンプレミス環境をばりばり担当していた人も居なくはないのですが、ある程度濃い人はユーザーから飛び出してアマゾンデータサービスの中の人になっているような印象があります。

このことは従来のオンプレミス環境の知識や運用経験が少なくても取り組めるインフラであることを意味します。しかしオンプレミス環境で必要な知識を埋め合わせる代償として、クラウドサービス固有の用語やハウツーを理解する必要があります。仮にオンプレミス環境に精通したインフラエンジニアを雇用したとしても、ドキュメント無しではインスタンスの開始すら難しいでしょう。また、AWS マスターが他社のクラウドサービスをすぐに使いこなせるかというと、そのサービスの名称や流儀に馴染むには時間が掛かると思われます。

私が AWS の全容が分かり始めた頃、アマゾンデータサービスの担当の方に冗談混じりで「これだけ専門性が高いと Microsoft Office みたいに検定が必要ですね」と話していたところ、数か月後には AWS 認定プログラムが登場しました。認定プログラムが登場するに十分な量の必要知識が詰まっているのがクラウド環境です。

このような状況ですので、もしこれからクラウド環境を専任の担当者を育成する以外の手段で利用を開始するのであれば、何社か市場にでているオペレーション代行業者に依頼してしまうのもビジネス上は妥当だと思います。もちろん、その代行業者が前述のようにサービス終了してしまう可能性はリスクとして想定するべきでしょう。


クラウド環境によるサービスはトラフィックが少なかったり、障害が起きないうちは安価かつスケーラブルに展開できたりするのですが、一旦躓くと様々な技術要素が絡まっているために原因の特定も解決も難しく、負の連鎖が横展開していく可能性があるという諸刃の剣です。うまくコントロールするにはクラウド固有の知識だけではなく、オンプレミスの知識が十二分に必要になってきます。しかしユーザーとしては途中からは運営会社管理下のブラックボックスであるため、ある程度は推測に頼らざるを得ないというのがクラウドをオペレーションする難しさです。

しかし「オンプレミス環境に戻りたいか?」と問われると私の答えは“No”です。そのくらいクラウドの恩恵は受けていると考えています。次はこうしたメリット・デメリットを踏まえた上で、クラウド環境を構築する際のポイントについてお話ししたいと思います。

執筆:株式会社ネットマーケティング 久松 剛
記事提供:株式会社ネットマーケティング