日経xTechでは障害により影響があったサービスの例が掲載されていました。
AWS大障害、ユニクロ・楽天・PayPayなど30社以上に影響
障害発生時、Twitterではゲーム系のサービスがダウンしているのは見かけていましたが、こちらの一覧を見るとゲームだけではなくECやネットサービス系の大手も影響があったようです。
AWSから障害に関する公式発表が出ています。
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
これによると
今回の事象はデータセンターで使用されるいくつかの冷却システムの制御と最適化に使用されるデータセンター制御システムの障害によって引き起こされました。制御システムは、高可用性を実現するために複数のホストで実行されます。
<中略>
サードパーティ製の制御システムにおけるロジックのバグにより、この情報交換が制御システムとデータセンターのデバイス間で過度に発生し、最終的には制御システムが応答しなくなりました。AWS のデータセンターは、データセンターの制御システムに障害が発生した場合、制御システムの機能が回復するまで冷却システムが最大冷却モードになるよう設計されています。これはデータセンターのほとんどで正常に機能していましたが、データセンターのごく一部で冷却システムがこの安全な冷却構成に正しく移行できず停止しました。
<中略>
運用チームは、影響のあるデータセンターのエリアで冷却システムを「パージ」モードにしようとしましたが、これも失敗しました。この時点で、データセンターの影響を受けるエリアの温度が上昇し始め、サーバーの温度が許容限度を超え、サーバーの電源が停止し始めました。
根本的には制御システムの不具合のようですが、サーバーが停止したのは温度上昇という物理的なものだったとはちょっと以外でした。
今回の障害は東京リージョンにある4つのAZのうちの1つで発生したという事ですが、 AWSの報告の最後にはこう記してあります。
この度の事象発生時、異なるアベイラビリティゾーンの EC2 インスタンスや EBS ボリュームへの影響はございませんでした。複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。アプリケーションで最大の可用性を必要とされるお客様には、この複数アベイラビリティゾーンのアーキテクチャに則ってアプリケーションを稼働させることを引き続き推奨しますもともとAWSは稼働率を上げるためにはAZを跨いだ冗長構成にする事を推奨していました。お手軽に使えるクラウドサービスですが、物理的にはデータセンターであることには変わりありません。障害は発生する前提でその対応策としてのシステム構成を設計する事がインテグレーターとしては求められます。
0 件のコメント:
コメントを投稿