こんにちは！FIXER R&D Division担当、フェローの千賀です。
今日は、先日8月23日に発生したAWSでの大規模障害を受けて、クラウドを使ってシステムやサービスを構築、提供する際の考え方や留意事項等をお伝えし、止まらないサービスを作るにはどうしたらいいかをアーキテクチャの観点から解説したいと思います。

AWSでの障害の内容と原因

まず簡単に、AWSで2019年8月23日に発生した障害の原因や内容を簡単に解説します。既に当ブログでも取り上げ、報道などもされておりますのでご存知の方も多いかもしれませんが、同日正午過ぎごろから22時過ぎまでの間、AWS東京リージョンにて、EC2やRDSへの接続障害など発生しました。原因は冷房をコントロールする制御システムを中心とする多重障害であり、サーバの温度が上がりすぎたことによる過熱である、と報告されています。

これにより約10時間に渡って、AWS上に構築されたサービスが利用できないなどの影響がありました。その中には決済サービスやSNS、ECサイトなどが含まれており、大きな影響がありました。

クラウドの特徴を押さえる

クラウドはオンプレ環境と性質が様々に異なります。だからこそ、クラウドの特性、Pros/Consを知り、適切に利用することが求められます。私たちFIXERのような会社は、そのためのサービス提供がお仕事の中心です。（ちょっと自慢ですが、当社はMicrosoft社よりMSP - Managed Service Provider - としての認定を正式に受けており、これは、日本国内の審査で合格した初めての事例です?）

例えば、オンプレ環境でデータセンターが丸ごと運用不能となることは耳にしませんが、クラウドではリージョン丸ごとの障害が、AWS・Azure・GCPといったベンダーを問わず、過去に発生しています。クラウドの運用が全地球規模で大規模に自動化されており、1つの障害が影響を与える範囲が大きくなりがちであることに起因します。

しかし、複数のリージョンが同時に停止したり、あるサービスがリージョンを跨って複数のリージョンで障害停止となることはまずありません。物理的にサーバー群が独立して運用されているためです。東京で何か失敗をやらかしたとしても、大阪やシンガポールのデータセンターでシステムが止まる事態ができる限り発生しないような分離がなされています。
今回のAWSの障害でも、影響は単一のアベイラビリティーゾーンに留まっており、マルチAZ構成ではほぼ影響がありませんでした。（設計上の不備があるシステムで、一部影響があったようです。本稿では、その対策も含めて解説します。）

サービス停止を防ぐ3つのポイント

クラウドで大規模障害と聞くと、危ない、使えないと一般の方は思ってしまうことがありますが、実際はそうではありません。クラウドは適切に使う限り、SLAの下で安定してサービスを停止せずに継続することができるものです。

停止しないサービスを構築する上でのポイントは3つあります。
・マルチリージョン、マルチAZ構成とすること
・1つのリージョンに固定化されるような設計を避けること
・「リージョンなし」のサービスに対策すること

これらのポイントをそれぞれ解説します。

マルチリージョン、マルチAZ構成を採る

まず最初に、シングルリージョンではなく、マルチリージョンあるいはマルチAZをベースにシステムを設計します。そうしておくことで、どこか単一にリージョンで障害が発生したとしても、他のリージョンでサービスを継続することができます。

マルチAZとマルチリージョンでは、マルチリージョンの方がより分離レベルが高いため、ミッションクリティカルなシステムではマルチリージョンを選択します。但し、データのコネクティビティという点ではレイテンシや接続しやすさ、通信コストといった点などでマルチAZに軍配が上がります。また、設計の難易度や考慮すべき点も異なります。

FIXERではデータセンターやリージョンといった一部の障害でサービスが停止するのは「クラウド的でない」「クラウドの特徴を活かしきれていない」と考えているため、また、ミッションクリティカルなサービスを提供されるEnterpriseのお客様が多いため、基本的にはマルチリージョンでのサービス設計をご提案し、費用や納期等からそこまで必要でないと判断された場合には、マルチAZやシングルリージョンといった設計をご提案します。

その上で、ユーザーやクライアントからのリクエストを各リージョンに適切に振り分けます。Traffic ManagerやFront Doorなど、そのために必要な機能もクラウドには用意されています。

1つのリージョンに固定化される設計を避ける

ところが、マルチリージョンを選択した場合に、システム自体は複数リージョンに配置しているのに、処理系を片方に寄せてしまうといった設計上の失敗がよくあります。アクティブ-スタンバイのような構成です。オンプレ環境での設計経験が長いと、こういった失敗をよくしてしまいます。せっかく複数のリージョンにシステムを構築しますので、きちんと両現用、アクティブ-アクティブとなるように設計しましょう。そうでないと、1つの系に障害が起こった場合にサービス全体が停止してしまいます。

※以前はマルチマスターやミラーリングが難しく、共有ストレージが必須でSPoFになりがちだったRDBも、現在では SQL Server Always On や Oracle Data Guard といった高可用性機能も充実しており、Azure SQL Database では Premium 可用性モデル や ゾーン冗長データベース 機能により、リージョンを跨いでデータを保護することができるようになっています。

他にも、Webサービスの構成でよくしてしまう失敗が、セッション アフィニティを導入してしまい（セッションをスティッキーにしてしまい）、特定のサーバーにアクセスすることを前提にしてしまうというものです。ログインやセッションの管理に慣れていないと、ラウンドロビンでロードバランスさせたときに前のリクエスト時のセッション情報が失われてしまうような仕組みにしてしまい、それを避けようと、同一のクライアントやセッションでは同一のサーバーにアクセスし続ける方式を採ることがあります。

こうしてしまうと、そのサーバーが属するリージョンがダウンした場合にセッション情報が失われ、少なくとも強制的にログアウトされたような振る舞いとなってしまいます。

これはオンプレの時代であれば発生リスクが少なく問題ないものとされており、比較的多くのケースで採用された方法論でした。しかし、現在はクラウドの時代です。ログインやセッションの管理はフェデレーションIDというデザインパターンを用いることで、スティッキーである必要性を無くすことができます。

「リージョンなし」のサービスに対策する

最後に、比較的見落としがちなのが、マルチリージョンなクラウドサービスの利用です。多くのクラウドサービスはリージョンに紐づいており、利用開始する際にリージョンを選択します。例えばAzure VMやEC2を東日本/東京リージョンに立てるといった具合です。このVMは、西日本リージョンが全面ダウンしても東日本で動き続けます。

一方、サービスそのものがリージョンなし（マルチリージョン）であるものがあります。Azureで言えばCognitive Servicesの一部やTraffic Managerといったようなものです。これらは特定のリージョンに依存しないため、どこかのリージョンで障害が発生しても影響を受けないことが前提です。

しかし、リージョンなしサービスは、そのサービスが全世界的に障害となる可能性があるという、固有のリスクがあります。とすると、そのサービスが利用できない状態になった場合の回避策を具備しておく必要があります。例えばTraffic Managerであれば、DNSサーバー機能により振り分け先サービスをコントロールする機能を提供していますので、その上位DNSサーバーで切り替えができるようにすることで、全世界的に機能が停止してもサービスを継続することができます。

これらの点に留意することで、大規模障害が発生した場合にもサービス継続性に影響を与えない、つまり、停止しないサービスを構築・提供することができます。

クラウドの有用性、アドバンテージ

ここまでで、オンプレとは異なるクラウドならではの留意事項について説明をしました。では、これらを取り入れるメリットや、その反面のコストはどう考えるべきでしょうか。

マルチリージョン、マルチAZで構成した場合、シングルリージョン構成よりもコストが上がります。利用するサーバーの台数等が純粋に増えるためです。但し、1リージョンを2リージョンにすると単純にコストが2倍になる、というわけではありません。何故ならば、サービスそのものに必要なコンピューティングリソース（CPUの計算能力の時間合計）やストレージ容量等は変化しないからです。月間1,000万MAUのサービスでサーバー群を500万MAUずつ対応するように2つに分けたとしても、処理に必要なコンピューティングリソースの合計は、理論的には増えません。

つまり、例えば東日本と西日本とで100の計算リソースを使っていたのであれば、東日本に50、西日本に50を準備し、オートスケールや手動スケーリングできるようにしておけば良いのです。そうすることで、通常時のコストはさほど変わらず、片系に障害が発生した場合にはスケールアウト・アップによってもう一方で処理を代替でき、サービスが継続できます。
但し、実際には仮想ネットワークやその間の通信、余剰リソースの発生等により、コストは数十％程度上がるため、その点をどう捉えるべきかを考えます。

これにも2つの考え方があります。
1つは、リスクを受容し、コストを上げない選択をする。つまりリージョンごと障害が発生するようなことは低頻度であり、その場合のビジネス影響も軽微であると考えて、リージョン障害によるサービス停止を許容するという考え方。

もう1つは、DR（Disaster Recovery、災害対策）等を含めて、全体のコスト低減効果で捉える考え方。マルチリージョンにしてサーバー等を東日本と西日本に配置した場合、例えば今週日曜深夜〜月曜朝のように史上最大の台風が東京の真ん中を通り、水害や火災、停電の継続等で（今回は発生しませんでしたが）東日本リージョンそのものが利用不可になったとしても、西日本ではサービスを継続することができます。つまり、DR対策が取られていることになります。

ちょうど18年前の今日、米国の９.11 同時多発テロという大変に痛ましい事件があり、旅客機に激突されて倒壊したWTCビルにはNASDAQ取引所がありました。そしてビル倒壊により、当然に市場での取引も全面的にできなくなりました。しかし、DR対策が取られていたことで、取引所は1週間で復旧し、取引が再開されたのです。取引所のシステムは高速性や精密性が極めて高いレベルで求められるため、1週間という短期間で復旧したことに、私も当時非常に驚きました。

悲劇からの復旧――9.11ディザスタリカバリを振り返る（ITメディアエンタープライズ）
https://www.itmedia.co.jp/enterprise/0311/07/epn13.html

この記事に書かれているように、通常はDRはとても大きな費用をかけて構築します。そのDR対策が、クラウドをうまく使うことにより、耐障害性と同時に若干のコスト追加で得られてしまう、ということです。

まとめ

クラウドの特性を知り、適切に設計・構築することで、リージョン障害のような大規模障害が発生しても停止しないサービスを安価に構築することができます。予めそういった点を考慮した効果的な設計を行うことで、DR発動のような災害時にも止まらないサービスを構築できるのがクラウドのメリットです。ぜひ有効活用して高品質なサービスを提供していきましょう！