2021年9月2日、Amazon Web Services(AWS)の東京リージョンにおいて、専用ネットワーク接続サービスであるAWS Direct Connect(以下、Direct Connect)に大規模な障害が発生した。同障害では最大6時間12分にわたり、Direct Connectを通じたAWSリソースへの接続ができない、または不安定な状態となった。
責任共有モデルというパブリッククラウドの性質上、こうした障害の発生はどうしても避けることができない。ただ、クラウドベンダー起因の障害が発生したとき、利用者としてできることがないのかというと、決してそうではない。9月の障害だけをみても、AWS側の復旧を待たずしてAWSリソースへの接続を回復させた例があるからだ。
AWSパートナーネットワーク最上位の「AWSプレミアコンサルティングパートナー」に認定されているサーバーワークスが10月に開催したウェビナー「2021年9月2日に発生した AWS Direct Connect の障害を振り返る」では、同障害で何が起きていたのか、そこに対応する術はどのようなものなのかが語られた。同ウェビナーの模様をまとめたレポートから、一部を抜粋して紹介しよう。
ウェビナーレポート
AWS Direct Connect の障害の復旧対応から見える、障害に強いシステム構成の最適解
＞＞ 資料ダウンロードはこちら
Direct Connectの大規模障害では何が起きていたのか
今回の障害は2021年9月2日7時30分頃に発生し、同日13時42分頃までの6時間12分にわたって継続した。その原因は、Direct Connectのネットワークトラフィックを東京リージョン内のAvailability Zone(AZ)へと接続する際に使用される複数のコアネットワークデバイスに問題が発生したことだ。これによりパケットロスが頻発し、たとえ複数のDirect Connectを使って冗長化している環境でも、これを使用したAWSリソースへのアクセスが遮断される、または不安定になる事態が発生した。
 |
上の図は障害発生から復旧までのタイムラインだが、AWSから障害発生に関する通知がなされた後の9時から10時にかけて、サーバーワークスには「バッチが動かない」「通信ができない」といった顧客からの連絡が寄せられたという。
同社ではWeb会議などで顧客と情報を共有しながら、復旧対応を支援。そのなかで、IPsec VPNを利用した接続サービスのAWS Site-to-Site VPN(以下、Site-to-Site VPN)を併用している場合には、同サービスへのフェイルオーバーを行うことで接続が回復できることが確認できた。ただ、悩ましいことに、通常こういった事態が発生した場合に自動で切り替えを行う「自動フェイルオーバー」が、同障害に際しては機能しないケースが考えられた。パケットロスは頻発するものの、10回に1回は通る可能性があるなど主系のダウンが完全ではなかったためである。
 |
これを踏まえてサーバーワークスでは、手動フェイルオーバーによる対応フローをチャート化。右図(クリックで拡大)にある形で障害への対応判断を顧客へガイドし、復旧までの支援を行ったという。
大規模障害から学ぶ、信頼性に長けたシステム構成の在り方
今回の障害は、Site-to-Site VPNへの切り替えによって対応することができたが、当然ながらSite-to-Site VPNを導入していない企業はこの方法を利用することはできない。同様の事態が発生してもシステムを停止させないために、企業はシステムの構成をどう変えていくべきか。
以下のリンクからダウンロードできる資料では、9月に発生した障害についてより詳細に解説するほか、それを学びとした「在るべきシステム構成の姿」についても説明している。ビジネスにおけるITへの依存度が増すなか、システムの停止は何としてでも避けなければならない。より信頼性の高いシステムにするために、IT担当者の方はぜひ資料に目を通してほしい。
ダウンロード資料のご案内
ウェビナーレポート
AWS Direct Connect の障害の復旧対応から見える、障害に強いシステム構成の最適解
＞＞ 資料ダウンロードはこちら
[PR]提供：サーバーワークス