AWS障害に学ぶ、万一クラウド障害が起きても動き続けるシステムとは？（1/2 ページ）

ダウンタイムをどの程度許容できるかは企業によって異なり、アプリケーションによって異なる場合も多い。ダウンタイムの許容範囲を適切に予測し、不要で好ましくないダウンタイムを回避することが大切だ。

公開 2017年06月29日 05時02分

著者

Alan R. Earls

[TechTarget]

印刷する

　クラウドへの移行には各種のメリットがあるが、Amazon Web Services（Amazon）などのクラウド事業者はトラブルフリーの運用を保証してくれるわけではない。企業がいくら入念にクラウド移行を計画し、現実的な視点から機能とサービス条件を検討したとしても、エラーやダウンタイムが原因でクラウドに混乱が生じる可能性は残る。「Amazon Web Services」（AWS）のダウンタイムに備えている企業は、その影響を緩和できる。備えていない企業は、不都合な現実を突如突き付けられることになる。

　ソフトウェア会社Treasure Dataのマーケティング担当副社長を務める田村清人氏によれば、AWSのダウンタイムをどの程度許容できるかは企業によって異なり、ニーズとビジネスケースによっても異なる。ただしAWSのクラウドストレージ「Amazon Simple Storage Service」（Amazon S3）のような基幹サービスがダウンした場合は、誰もがその影響を受ける。「2017年2月末にAmazon S3に障害が発生したときは、文字通りインターネットの半分に影響が及んだ」と田村氏は語る。これは、Amazon S3が人気の証拠であると同時に、どれほど高い耐久性と可用性が想定されたシステムであれ、全てのデータを1カ所に集めることがいかに危険かを示す証拠でもある。

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

実際に起きたクラウド障害

クラウド障害への対策

　ダウンタイムの許容範囲は、そのインフラストラクチャがサポートするワークロードやビジネス機能によって異なる。オンライン販売や銀行業務、救急サービスのように100％の可用性を必要とするビジネス機能もあれば、人事（HR）や一部のビジネスインテリジェンスアプリケーションのように100％未満の可用性でも支障がないものもある。ワークロードの可用性要件を判断し、適切なアーキテクチャを導入するのは、各企業に個別的な課題だ。

　「可用性の高いインフラストラクチャを適切に構築するために、クラウドアーキテクトはAWS環境を深く理解する必要がある」とコンサルティング会社Stelligent Systemsの最高技術責任者（CTO）ポール・デュバル氏は語る。

　AWSの機能には、AWSの他の機能に依存しているものがある。2017年2月末のような残念な事態を回避するために、クラウドアーキテクトはこうしたAWS機能間の相互依存関係を理解しておく必要がある。実際2017年2月末には、Amazon S3で発生した障害のせいで、Amazon S3を利用するその他のAWS機能もダウンした。クラウド上のシステム構築を自動化する「CloudFormation」もその1つだ。

　「CloudFormationとAmazon S3の依存関係を理解していれば、クラウドアーキテクトは何らかの冗長性を持たせることができていただろう」とデュバル氏は語る。アプリケーションがどのプラットフォームで動作しているかは重要ではない。基幹業務に関わるアプリケーションとデータに関し、継続性とレジリエンス（回復力）を確保できるアーキテクチャを設計し構築することが、IT部門の責任だ。

ダウンタイムの許容範囲を予測する

　AWS顧客の大半は99.9～99.999％のアップタイムを期待している。年間に53分から8.76時間までのダウンタイムであれば許容できるということだ。ただしダウンタイムが年1回に集中するようでは、多くの顧客は不満を感じるだろう。実際、2017年2月末にS3に障害が発生した際も、ダウンタイムが長引き、AWS顧客は不満を募らせた。

　「現実には、AWS顧客の大半はある程度のダウンタイムを仕方がないものとして受け入れる」とネットワークトラフィックインテリジェンス企業Kentikの共同創業者でCEOのアビ・フリードマン氏は語る。ダウンタイムをゼロにするのは不可能ではない。だがそのためには、アーキテクチャへのそれ相応の投資と複数層あるいは複数ベンダーのソリューションが必要だ。