「2つのアベイラビリティーゾーン(独立性の高いデータセンター群、AZ)にまたがった冗長構成では不十分だった。これからは3つのAZによる冗長構成に変える」(大手ユーザーの技術者)――。

 2019年8月23日に発生した米アマゾン ウェブ サービス(Amazon Web Services)のクラウドサービス「Amazon Web Services(AWS)」東京リージョンの大規模障害を受けて、ユーザーが続々と対策に動き始めている。冒頭の「3つのAZによる冗長構成」は中核となる対策の1つだ。

3つのAZによる冗長構成の例
仮想マシン2台構成の例を示したが、平常時からAZ-3にも仮想マシンを配置しても構わない
[画像のクリックで拡大表示]

 大規模障害への対策として何が必要なのか。AWSの活用経験が豊富なユーザーとITベンダーの技術者に聞いた。

 まずはAWS東京リージョンで起きた今回の障害についてまとめる。

ALBが内部エラーを返した

 AWS東京リージョンには4つのAZがある。その1つで空調設備が故障し、仮想マシンの「Amazon EC2」の一部が停止したり再起動できなくなったりしたのに加え、仮想マシンのディスクである「Amazon EBS」でも一部で性能が落ちたりアクセスできなくなったりした。EBSについては「データの復旧が難しくなったケースもある」(ITベンダーの技術者)という。

 アプリケーションロードバランサーの「ALB(Application Load Balancer)」も“予期せぬ影響”を受けた。具体的には、ALBに届いたリクエストの一定割合に対して内部エラーが返され続けたという。AWSは、Webアプリケーションファイアウオールの「AWS WAF」あるいはリクエストの振り分け先を固定化する技術「スティッキーセッション」とALBとを組み合わせたケースで不具合が発生したとしている。ただし「AWS WAFとスティッキーセッションのどちらも使っていないケースで内部エラーを返したケースがあった」(複数のITベンダー)との証言もある。

 EC2とEBSの障害によって、それらを基盤として動作しているプラットフォーム・アズ・ア・サービス(PaaS)にも接続しにくくなるなどの影響が出た。リレーショナルデータベースの「Amazon RDS」、インメモリーキャッシュの「Amazon ElastiCache」、データウエアハウスの「Amazon Redshift」、仮想デスクトップの「Amazon Workspaces」などだ。AWS利用者向けの管理画面である「AWSマネジメントコンソール」も「断続的にしか応答しなくなった」(ユーザーの技術者)という報告がある。

 これら影響があったサービスのうち最もインパクトが大きかったのはALBだ。ALBはAWS上に可用性の高いシステムを構築する上で要となるサービスだからである。

 AWSではAZ単位での障害は起こり得るものとされている。そのため高可用性が求められるシステムについては一般に、複数のAZによる冗長構成を取る。例えばAZ-1とAZ-2にそれぞれアプリケーションサーバーが動作する仮想マシン(EC2)を1台ずつ配置し、ALBによってリクエストを2つのAZの仮想マシンに振り分けるといった具合だ。

この先は日経 xTECH Active会員の登録が必要です

日経xTECH Activeは、IT/製造/建設各分野にかかわる企業向け製品・サービスについて、選択や導入を支援する情報サイトです。製品・サービス情報、導入事例などのコンテンツを多数掲載しています。初めてご覧になる際には、会員登録(無料)をお願いいたします。