世の中はクラウド化の流れが進み、AWS（Amazon Web Services）を利用して多くのシステムが提供されています。皆さんが運用しているシステムも、すでにAWSにマイグレーション（移行）されたり、これからマイグレーションが検討されたりしているのではないでしょうか。 AWSは全世界のクラウドマーケットの約1/3を占めて1位、2021年第1四半期で16兆円5千億円規模を誇っています（出典：Synergy Research Group）。いろいろなシステムやサービス、アプリなどで幅広く利用されていますが、障害が起きる可能性は常にあります。最近でも、AWSに障害が発生するたびに『あのサービスもAWSで動いていたのか！』と話題になることがありました。AWS利用者側として、事前にできる対策を講じていきましょう。

パブリッククラウドにも、たびたび障害は起きている！

ITシステムに詳しくない社会人や経営層だと、一般には『パブリッククラウドでは障害が起きない』と認識されている傾向があります。明確な根拠は無いはずですが、『クラウドにしておけば障害対策してもらえる』と考えている人も多いようです。これは大きな誤解で、パブリッククラウドを過信しすぎていると言わざるを得ません。 実際、パブリッククラウドの大手であるAWS・Azure・GCPのいずれかで、1年に1回は何かしらの障害が起きています。日本国内では影響が無いものもありますが、例えば以下の障害が起きています。

• データセンターの設備トラブルにより、クラウドサービスが停止
• クラウドサービスの人為的ミスにより、サービスの応答速度が低下
• クラウド上の認証基盤に不具合が起き、コンソールなどが操作不可

これらは一例ですが、つまり、『パブリッククラウドを利用すれば障害が起きない』というのは、勝手な淡い期待です。実際には、事前対策しなければ障害に巻き込まれることで、ビジネスにも影響が出てしまいます。

AWSの障害対策はマルチAZではなくマルチリージョンで

パブリッククラウドでも特に利用者が多いAWSは、「マルチAZ」と「マルチリージョン」での障害対策が求められます。

• マルチAZ：同じリージョン内で、AZ（アベイラビリティゾーン）と呼ばれる複数のデータセンター群にシステムを構築すること
• マルチリージョン：リージョンと呼ばれる、全世界で約25か所にあるAWSの施設がある地域（都市）を複数利用してシステムを構築すること

まず、マルチAZは同じリージョン内で異なるAZにシステムを構築する障害対策です。例えば、東京リージョンを利用しているならば、このリージョン内で複数のAZにシステム構築をします。それぞれのAZは物理的に独立しているので、離れた場所にシステム構築をすることで物理的な障害対策ができます。 一方、マルチリージョンは複数のリージョンにシステムを構築する障害対策です。例えば、東京リージョンに加えて、米国オハイオやオレゴンなど複数のリージョンにシステム構築をします。それぞれのリージョンはAZ以上に地理的な距離があるので、物理的な障害が発生してもお互いに影響する可能性を小さくできます。

マルチリージョンが求められるようになった理由とは？

従来は、AWSの障害対策といえばマルチAZを利用する方法が中心でした。それぞれのAZは地理的に離れているため、障害への影響が小さいと発表していたからです。しかし今は、マルチAZに加えてマルチリージョンが求められます。なぜなのでしょうか？ その理由のひとつに、2019年に東京リージョンで起こった障害があります。この障害では、サーバの負荷を分散するロードバランサにも障害が発生し、マルチAZでシステム構築をしていてもバランシングができなくなってしまったのです。結果、それぞれのAZではシステムが復旧しても、ロードバランサが復旧するのを待つしかありませんでした。 この障害による影響は大きく、ニュースになっただけでなく、AWSの障害対策の考え方にも影響を与えました。AWSのインフラは明確に公開されていないので、見えないインフラの都合を踏まえると、リージョンを超えた障害対策をしなければならないと考えられるようになったのです。

＜PR＞世界規模で使われるパブリッククラウドですら、障害とは無縁ではいられず、影響も広範囲になりがちです。 統合運用管理サービス「UOM」で日頃から自動化・効率化して、御社のビジネスを守るには？ 詳しくはこちらへ

マルチリージョンで障害対策する場合に、検討すべきこと

AWSをマルチリージョンにして障害対応するには、自社のシステムを対応させる必要があります。 例えば、大規模な開発ではなくともマルチリージョンに対応できるような修正は必要です。AWSの構成を考え直す必要があるかもしれません。場合によっては、システムを新規開発することも避けられません。このような修正や開発に対応したり許容できるかを、十分検討しなければなりません。 また、修正や開発の内容によっては、システム運用を変更しなければならない可能性があります。必然的に、手順書の編集や作成、担当者への教育など、付随する変更が求められます。これらにもコストが掛かるので、慎重な検討が必要です。

システム停止をどの程度許容できるか？の費用対効果

そもそも、自社のビジネスにとって、システム停止をどの程度許容できるかを考えましょう。つまり、『費用対効果を考えた際に、大きなコストを掛ける意味があるのかどうか？』を吟味します。場合によっては、マルチリージョンとは別の選択肢が適しているかもしれません。 例えば、マルチリージョンではなくコンテナ化やサーバレス化、AWS Step Functions（分散アプリケーションの調整）の利用などが選択肢に挙がります。これらは、マルチリージョンでの障害対策と比べると可用性が劣りますが、コストを抑えて実装できる可能性があります。システム停止をある程度許容できる場合は、有効なオプションです。

AWSに限らず、パブリッククラウドでも障害は起こります。システム運用担当者には、そのことを前提とした障害対策—AWSであれば、マルチリージョンでのシステム構築が求められます。ただ、マルチリージョンでの障害対策はコストが高くつくので、いろいろな条件を総合的に踏まえて、他の選択肢も考えるようにしましょう。

＜PR＞クラウドといっても、複数を組み合わせたマルチ、オンプレミスとのハイブリッドもあって複雑化するばかり… だから、属人化を省いた自動化による効率的な運用には、統合運用管理サービス「UOM」が有効です。 詳しくはこちらへ