全4911文字
PR

クラウドサービスの活用では、従来型インフラとの違いに注意が必要である。「壊れないようにする」ではなく「壊れても直るようにしておく」という考え方だ。今回は、2019年に発生したAWSの障害をひも解き、クラウドならではの勘所を解説する。

 クラウドサービス上にシステムを移行する企業が日本でも増えてきました。しかし一方で、「クラウドサービスが障害の発生を前提としたインフラである」ことへの理解が進んでいないように感じます。そのため、オンプレミス(自社所有)環境にある従来の障害が発生しにくいインフラからの移行に当たり、適切な変更が行われず、問題を引き起こすケースがあります。

 実際、2019年8月にはアマゾンのクラウドサービス「AWS(Amazon Web Services)」の東京リージョンで障害が発生し、国内の多くのサービスに影響を与えました。

 本連載では、こうした障害を踏まえたうえで、クラウドサービスの仕組みを理解し、うまく活用するための考慮点を解説します。

冷却制御システムに異常が発生

 まずはAWSの東京リージョンで発生した障害について、何が起きたのかを確認しましょう。 

 2019年8月、AWSの東京リージョンを構成するあるデータセンター内で、バグを起因とした冷却制御システムの異常が発生。オーバーヒートによって仮想マシンサービス「Amazon EC2」や、マネージドのリレーショナルデータベースサービス「Amazon RDS(Relational Database Service)」など主要サービスが、6時間にわたって停止しました。

 その結果、AWSを利用していた様々なシステムが一時的な停止、あるいはAWSが復旧するまで停止する事態となりました。ただし、この障害の影響範囲は一部のシステムに限られます。

 AWSが公開した報告書「東京リージョン(AP-NORTHEAST-1)で発生したAmazon EC2とAmazon EBSの事象概要」を読むと、AWSの仕組みと、今回の障害の影響範囲が理解できます。

 本来、冷却制御システムに異常が発生し冷却装置の制御が効かなくなっても、冷却装置は自動で最大冷却モードになり、オーバーヒートは発生しません。しかし、あるデータセンターの、あるエリアの冷却装置が故障のため最大冷却モードにならず、冷却が行われなくなりました。このため、そのエリアに置かれたサーバー群がオーバーヒートし、関係するサービスだけが影響を受けたのです。

AWSは「マルチAZ」を推奨

 AWSではデータセンターレベルでの可用性を確保するために、冷却装置を含めた物理的なサーバー群の構成を複数持っています。この構成をアベイラリビリティーゾーン(AZ)と呼びます。東京リージョンは現在、4つのAZから構成されており、今回は単一AZ内の、ある冷却装置が設置されたエリアだけで障害が発生しました。

図 AWSを構成する設備の単位
図 AWSを構成する設備の単位
リージョン、AZ、データセンター
[画像のクリックで拡大表示]

 利用者がAWSでEC2インスタンスを起動する場合、必ずどこかのAZにアサインされます。その場所は利用者が選択するか、選択しないなら自動で決定されます。つまり、今回の影響範囲は該当のAZにアサインした(されてしまった)サーバーだけなのです。

 そのため前述の報告書でも「複数のアベイラビリティーゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした」としています。

 つまり、今回のような単一AZの障害によるシステム停止を回避したい場合、同一のアプリを複数のAZに分散して配置し、構成しておけばよいわけです。これは「複数アベイラビリティーゾーン(マルチAZ)」と呼ばれる手法です。報告書には「アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティーゾーンのアーキテクチャーに沿ってアプリケーションを稼働させることを引き続き推奨します」と記載されています。