Blog」に掲載された「クラウドアーキテクトによる『AzureやAWSに大規模障害が発生してもサービス停止しないクラウドの設計、使い方』」を再編集したものです。Division担当、フェローの千賀です。今日は、先日8月23日に発生したAWSでの大規模障害を受けて、クラウドを使ってシステムやサービスを構築、提供する際の考え方や留意事項等をお伝えし、止まらないサービスを作るにはどうしたらいいかをアーキテクチャの観点から解説したいと思います。AWSでの障害の内容と原因まず簡単に、AWSで2019年8月23日に発生した障害の原因や内容を簡単に解説します。当ブログでも取り上げ、報道などもされておりますのでご存知の方も多いかもしれませんが、同日正午過ぎごろから22時過ぎまでの間、AWS東京リージョンにて、EC2やRDSへの接続障害など発生しました。原因は冷房をコントロールする制御システムを中心とする多重障害であり、サーバの温度が上がりすぎたことによる過熱である、と報告されています。これにより約10時間に渡って、AWS上に構築されたサービスが利用できないなどの影響がありました。その中には決済サービスやSNS、ECサイトなどが含まれており、大きな影響がありました。クラウドの特徴を押さえるクラウドはオンプレ環境と性質が様々に異なります。クラウドの特性、Pros/Consを知り、適切に利用することが求められます。私たちFIXERのような会社は、そのためのサービス提供がお仕事の中心です。しての認定を正式に受けており、これは、日本国内の審査で合格した初めての事例です)例えば、オンプレ環境でデータセンターが丸ごと運用不能となることは耳にしませんが、クラウドではリージョン丸ごとの障害が、AWS・Azure・GCPといったベンダーを問わず、過去に発生しています。クラウドの運用が全地球規模で大規模に自動化されており、1つの障害が影響を与える範囲が大きくなりがちであることに起因します。複数のリージョンが同時に停止したり、あるサービスがリージョンを跨って複数のリージョンで障害停止となることはまずありません。物理的にサーバー群が独立して運用されているためです。東京で何か失敗をやらかしたとしても、大阪やシンガポールのデータセンターでシステムが止まる事態ができる限り発生しないような分離がなされています。今回のAWSの障害でも、影響は単一のアベイラビリティーゾーンに留まっており、マルチAZ構成ではほぼ影響がありませんでした。(設計上の不備があるシステムで、一部影響があったようです。本稿では、その対策も含めて解説します。)サービス停止を防ぐ3つのポイントクラウドで大規模障害と聞くと、危ない、使えないと一般の方は思ってしまうことがありますが、実際はそうではありません。クラウドは適切に使う限り、SLAの下で安定してサービスを停止せずに継続することができるものです。停止しないサービスを構築する上でのポイントは3つあります。・マルチリージョン、マルチAZ構成とすること・1つのリージョンに固定化されるような設計を避けること・「リージョンなし」のサービスに対策することこれらのポイントをそれぞれ解説します。マルチリージョン、マルチAZ構成を採るまず最初に、シングルリージョンではなく、マルチリージョンあるいはマルチAZをベースにシステムを設計します。しておくことで、どこか単一にリージョンで障害が発生したとしても、他のリージョンでサービスを継続することができます。マルチAZとマルチリージョンでは、マルチリージョンの方がより分離レベルが高いため、ミッションクリティカルなシステムではマルチリージョンを選択します。データのコネクティビティという点ではレイテンシや接続しやすさ、通信コストといった点などでマルチAZに軍配が上がります。設計の難易度や考慮すべき点も異なります。FIXERではデータセンターやリージョンといった一部の障害でサービスが停止するのは「クラウド的でない」「クラウドの特徴を活かしきれていない」と考えているため、また、ミッションクリティカルなサービスを提供されるEnterpriseのお客様が多いため、基本的にはマルチリージョンでのサービス設計をご提案し、費用や納期等からそこまで必要でないと判断された場合には、マルチAZやシングルリージョンといった設計をご提案します。その上で、ユーザーやクライアントからのリクエストを各リージョンに適切に振り分けます。Doorなど、そのために必要な機能もクラウドには用意されています。1つのリージョンに固定化される設計を避けるところが、マルチリージョンを選択した場合に、システム自体は複数リージョンに配置しているのに、処理系を片方に寄せてしまうといった設計上の失敗がよくあります。アクティブ-スタンバイのような構成です。オンプレ環境での設計経験が長いと、こういった失敗をよくしてしまいます。複数のリージョンにシステムを構築しますので、きちんと両現用、アクティブ-アクティブとなるように設計しましょう。ないと、1つの系に障害が起こった場合にサービス全体が停止してしまいます。機能により、リージョンを跨いでデータを保護することができるようになっています。アフィニティを導入してしまい(セッションをスティッキーにしてしまい)、特定のサーバーにアクセスすることを前提にしてしまうというものです。ログインやセッションの管理に慣れていないと、ラウンドロビンでロードバランスさせたときに前のリクエスト時のセッション情報が失われてしまうような仕組みにしてしまい、それを避けようと、同一のクライアントやセッションでは同一のサーバーにアクセスし続ける方式を採ることがあります。してしまうと、そのサーバーが属するリージョンがダウンした場合にセッション情報が失われ、少なくとも強制的にログアウトされたような振る舞いとなってしまいます。これはオンプレの時代であれば発生リスクが少なく問題ないものとされており、比較的多くのケースで採用された方法論でした。現在はクラウドの時代です。ログインやセッションの管理はフェデレーションIDというデザインパターンを用いることで、スティッキーである必要性を無くすことができます。「リージョンなし」のサービスに対策する最後に、比較的見落としがちなのが、マルチリージョンなクラウドサービスの利用です。多くのクラウドサービスはリージョンに紐づいており、利用開始する際にリージョンを選択します。VMやEC2を東日本/東京リージョンに立てるといった具合です。このVMは、西日本リージョンが全面ダウンしても東日本で動き続けます。サービスそのものがリージョンなし(マルチリージョン)であるものがあります。Managerといったようなものです。これらは特定のリージョンに依存しないため、どこかのリージョンで障害が発生しても影響を受けないことが前提です。リージョンなしサービスは、そのサービスが全世界的に障害となる可能性があるという、固有のリスクがあります。すると、そのサービスが利用できない状態になった場合の回避策を具備しておく必要があります。Managerであれば、DNSサーバー機能により振り分け先サービスをコントロールする機能を提供していますので、その上位DNSサーバーで切り替えができるようにすることで、全世界的に機能が停止してもサービスを継続することができます。これらの点に留意することで、大規模障害が発生した場合にもサービス継続性に影響を与えない、つまり、停止しないサービスを構築・提供することができます。クラウドの有用性、アドバンテージここまでで、オンプレとは異なるクラウドならではの留意事項について説明をしました。これらを取り入れるメリットや、その反面のコストはどう考えるべきでしょうか。マルチリージョン、マルチAZで構成した場合、シングルリージョン構成よりもコストが上がります。利用するサーバーの台数等が純粋に増えるためです。1リージョンを2リージョンにすると単純にコストが2倍になる、というわけではありません。サービスそのものに必要なコンピューティングリソース(CPUの計算能力の時間合計)やストレージ容量等は変化しないからです。月間1,000万MAUのサービスでサーバー群を500万MAUずつ対応するように2つに分けたとしても、処理に必要なコンピューティングリソースの合計は、理論的には増えません。東日本と西日本とで100の計算リソースを使っていたのであれば、東日本に50、西日本に50を準備し、オートスケールや手動スケーリングできるようにしておけば良いのです。することで、通常時のコストはさほど変わらず、片系に障害が発生した場合にはスケールアウト・アップによってもう一方で処理を代替でき、サービスが継続できます。実際には仮想ネットワークやその間の通信、余剰リソースの発生等により、コストは数十%程度上がるため、その点をどう捉えるべきかを考えます。これにも2つの考え方があります。1つは、リスクを受容し、コストを上げない選択をする。リージョンごと障害が発生するようなことは低頻度であり、その場合のビジネス影響も軽微であると考えて、リージョン障害によるサービス停止を許容するという考え方。Recovery、災害対策)等を含めて、全体のコスト低減効果で捉える考え方。マルチリージョンにしてサーバー等を東日本と西日本に配置した場合、例えば今週日曜深夜〜月曜朝のように史上最大の台風が東京の真ん中を通り、水害や火災、停電の継続等で(今回は発生しませんでしたが)東日本リージョンそのものが利用不可になったとしても、西日本ではサービスを継続することができます。DR対策が取られていることになります。同時多発テロという大変に痛ましい事件があり、旅客機に激突されて倒壊したWTCビルにはNASDAQ取引所がありました。ビル倒壊により、当然に市場での取引も全面的にできなくなりました。DR対策が取られていたことで、取引所は1週間で復旧し、取引が再開されたのです。取引所のシステムは高速性や精密性が極めて高いレベルで求められるため、1週間という短期間で復旧したことに、私も当時非常に驚きました。悲劇からの復旧――9.11ディザスタリカバリを振り返る(ITメディアエンタープライズ)https://www.itmedia.co.jp/enterprise/0311/07/epn13.htmlこの記事に書かれているように、通常はDRはとても大きな費用をかけて構築します。そのDR対策が、クラウドをうまく使うことにより、耐障害性と同時に若干のコスト追加で得られてしまう、ということです。まとめクラウドの特性を知り、適切に設計・構築することで、リージョン障害のような大規模障害が発生しても停止しないサービスを安価に構築することができます。いった点を考慮した効果的な設計を行うことで、DR発動のような災害時にも止まらないサービスを構築できるのがクラウドのメリットです。スマホお気に入り一覧マイページ。