専門家に聞いた

クラウド導入「3つの失敗談」、IT管理者は悪夢を見た

クラウドには多くのメリットがある。だがクラウドが常にIT部門の助けになるとは限らない。導入に失敗すれば、セキュリティ侵害やPaaSの厄介な実装などが発生し、IT担当者を苦しめることになる。

公開 2016年11月21日 10時02分

著者

Kathleen Casey

[TechTarget]

印刷する

　TechTargetはこれまで、自身または他人が直面したクラウド関連の悪夢について専門家に話を聞いた。その恐怖体験をのぞいてみよう。

ビリー・ワイルダー氏

　DNSプロバイダーのDynは2016年、大規模なDDoS（分散型サービス拒否）攻撃に見舞われた。ハロウィーンより10日も早く訪れた悪夢だ。信頼できるDNSがなければ、インターネットは機能しない。そして、多くのクラウドアプリケーションやクラウドサービスがDynのような企業にDNSを外部委託している。Dynへの攻撃により、Twitter、Spotify、Netflixといった著名なコンシューマーサイトや、「Amazon Web Services」（AWS）、「Heroku」「GitHub」のような開発者向けクラウドサービスが影響を受けた。このニュースが報道されたのは、セキュリティ研究者兼ジャーナリストのブライアン・クレブス氏が、自身のWebサイトに史上最大規模のDDoS攻撃を受けた1カ月後だった。伝えられるところでは、同氏のWebサイトへの攻撃は、0.5Tbpsを超える驚くべきレベルに達したという（関連記事：“アンナ先輩”が公開したマルウェア「Mirai」に専門家が震え上がる訳）。

　攻撃は高い攻撃力を備えたボットの大群によって仕掛けられたようだ。このボットは、知らないうちにインターネットに接続されるIoTデバイスを利用する。ビデオカメラ、DVR、冷蔵庫のドアの鍵、バービー人形など、数十億ものIoTデバイスが既に出回っていることを考えると、これは本当に恐ろしいことだ。インターネットに接続されているIoTデバイスは特殊な検索エンジンを使えば簡単に見つけることができる。またIoTデバイスを侵害するコードは簡単にダウンロードできる。こうしたことから確信を持っていえることが1つある。この経験は新しい種類のDDoS攻撃の始まりにすぎない。

併せて読みたいお薦めの記事

クラウド失敗話

失敗事例集

ガウラブ“GP”パール氏

　クラウドコンピューティングでの最大の悪夢は、IaaS上にPaaSをカスタマイズして実装した体験だ。多くの大手企業は、高度な自動化、独立したクラウドプラットフォーム、コンテナなど、至高のクラウドを求めて革新の限界に挑んでいる。それ自体はすばらしい。だがIaaS、マネージドIaaS、PaaSの境界は曖昧で、至高のクラウドへの道のりは平たんではない。このプラットフォームの構築には予想よりもはるかに時間がかかり、セキュリティ監査に合格できず、運用の健全性を整えるのに困難を極めた。

　さらに、カスタムPaaSが登場して間もないこともあり、カスタムPaaSを扱った経験があり資格を持つ人材が不足していることが事態を悪化させた。加えてコンテナオーケストレーション面でのテクノロジー基盤が絶えず変化している。こうした要因全てが混在一体となって悪夢が生まれる。IaaS上のPaaSが成功するか失敗に終わるかは、時間が経てば分かるだろう。

アレックス・ウィザースプーン氏

　よく目にする傾向は、非クラウドアーキテクチャのアプリケーションをプライベートクラウドやパブリッククラウド環境で運用してしまうことと、間違ったコスト予測だ。こうしたアプリケーションにとってクラウドは理想的ではない。

　クラウド環境は、自動化と抽象化された物理リソースの利用が基本だ。またパブリッククラウドはその価値に課金する。加えてクラウドが存在する物理サーバへの課金もある。後者の課金は導入決定時にはあまり考えない費用だ。中にはパブリッククラウドの選択とそのコストモデルが適切に一致する企業もある。その場合は恐らく、ビジネスとのトレードオフをうまく表にすることができる。Dropbox社の「Dropbox」などに代表される多くのパブリッククラウドの場合、最初はコスト削減を見込めても、ある時点から急激に運用コストが増加の一途をたどることが分かっている。プライベートクラウドとは異なり、パブリッククラウドは運用費（OPEX）や資本支出（CAPEX）が安定しない。プライベートクラウドにCAPEXを行い、OPEXを柔軟に調整できるようにする現代の財務メカニズムを考えると、プライベートクラウドの財務モデルは経済的に採算が取れる場合が多い。ただしそれはプライベートクラウドで増加する複雑な管理という犠牲の上に成り立っている。とはいえ複雑さに対するトレードオフは、技術的、経済的なビジネスニーズに完璧に合致するプライベートクラウドアーキテクチャを形成して、利点をコントロールすることで正当化されることが多い。

　クラウドにおけるこのような最適化は非常に多岐にわたる可能性がある。その1つが、非クラウドアーキテクチャのアプリケーションのサポートだ。このサポートを考慮しておくことが重要なのは、全てのクラウドが同じように構築されているわけではないためだ。AWS、「Microsoft Azure」「Google Cloud Platform」のような多くのパブリッククラウドプロバイダーが提唱している実行可能な最小アーキテクチャは、幅広い分散アプリケーションだ。分散アプリケーションならば、どの単一ノードでランダムな障害が発生しても耐えることができるという。最新アプリケーションの多くは分散アプリケーションに対応している。だが結局のところ、現在運用されているソフトウェアの大半は、その実行基盤となるインフラを100％信頼できるものと想定している。そのため高可用性を設計目標としていないパブリッククラウドやプライベートクラウドでこのようなアプリケーションを運用するのは危険を伴う。

　サービスのライフサイクル全体のリスクと投資利益率（ROI）を検討することが常に重要である。あらゆる種類のクラウドが多様なROIを備えているので、そのようなクラウドサービスに対するビジネスニーズの戦略的装備を詳しく数値化できれば、ビジネスにおける技術的、経済的損失を回避できる。

印刷する