あなたのアプリにマルチリージョンは必要ないかもしれない
はじめに
アプリケーションを運用する上で、可用性は避けて通れない重要なテーマです。可用性を確保するためにインフラの単一障害点を可能な限りなくし、冗長化構成を組むことは今や常識となっています。
その中でも特に強力な障害対策として挙げられるのが「マルチリージョン構成」です。しかし、その実装と運用には相応のコストと複雑さが伴います。
この記事では、クラウドインフラにおける障害対策としてのマルチリージョン化が、本当にあなたのアプリケーションに必要なのかを、コストとリスクの観点から考察します。
あなたのアプリに「高い可用性」は必要か？
あらゆるサービスが高い可用性を目指すべきかというと、必ずしもそうではありません。まずは、どのようなサービスで高い可用性が求められるのかを整理してみましょう。
ビジネスの直接的損失につながるもの
- 機会損失につながるもの
- ECサイト、ネット証券など。サービスが停止している間の売上や取引の機会が失われるもの。特にセール時や限定商品の発売時などでは影響が甚大となります。
- 顧客の信頼を失うもの
- SNS、オンラインゲーム、ニュースサイトなど。ユーザーが「使いたいときに使えない」と感じると、サービスへの信頼がゆらぎ、利用を停止したり競合他社に流れる可能性があります。
- 業務生産性を著しく低下させるもの
- 社内の基幹システム、コミュニケーションツール、ファイル共有サービスなど。これらのサービスが停止すると、社員の業務が大幅に妨げられ、生産性が低下します。
社会インフラや人命に関わるもの
- 生命や安全の維持に関わるもの
- 医療機器の制御システム、緊急通報システム、交通管制システムなど。システムの不具合が直接的に人命に関わる可能性があります。
- 社会基盤の維持に関わるもの
- 電力供給システム、通信インフラ、金融システム、物流管理システムなど。これらのシステムが停止すると、広範囲にわたる社会的混乱や経済的損失を引き起こす可能性があります。
代替が効かない、または復旧コストが非常に高いもの
- 代替手段が存在しないもの
- 特定の行政手続きシステム、企業の特殊な生産ラインを制御するシステムなど。「そのシステムでしかできない」業務は、停止が許されません。
- 手動での復旧が困難なもの
- 大規模なデータ処理基盤や工場の自動化ラインなど。システム停止によって処理が中断されると、データの整合性を取ったり、生産ラインを正常な状態に戻したりするのに多大な時間とコストを要します。
契約や法的な制約があるもの
- SLA（サービス品質保証契約）で稼働率を定めているもの
- クラウドサービス（AWS, Azureなど）やデータセンターなど。顧客に対して「稼働率99.99%」のように契約で保証している場合、それを下回ると違約金の支払いなどが発生します。
- 法令や業界の規制で定められているもの
- 金融業界や通信業界など、公共性の高い一部の業界では、監督官庁への報告義務や、安定稼働に関する厳しい規制が設けられています。
もしあなたのサービスが上記のいずれにも当てはまらない場合、例えば社内利用で緊急性の低いツールや、リアルタイム性が不要なバッチ処理システム、個人の趣味で運営するWebサイトなどであれば、過剰な可用性を追求する必要はないかもしれません。
可用性の「質」を考える
可用性は「稼働率99.XX%」という一つの数字だけで語られがちですが、その数字だけでは実態を見誤る可能性があります。どのような「停止」が許容できないのか、具体的に考えることが重要です。
障害の影響範囲・深刻度
システムの障害は、全面停止だけではありません。一部機能の停止やパフォーマンスの低下など、その形態は様々です。「1時間サービスが完全に停止すること」と「1時間レスポンスが遅くなること」では、ユーザー体験やビジネスへの影響は大きく異なります。
障害の頻度
毎日数分停止するシステムと、年に一度だけ1時間停止するシステムでは、どちらが問題でしょうか。頻繁な障害はユーザーに大きなストレスを与え、サービスへの信頼を損ないます。
障害の継続時間
数分で復旧する障害であればユーザーは少し待ってくれるかもしれませんが、数時間にわたる停止は大きな問題に発展します。業務システムにおいても、短時間の停止であれば手動対応や後処理でカバーできるかもしれませんが、長時間になると業務そのものが成り立たなくなる可能性があります。
さて、あなたのサービスではどのような「質の障害」を最も避けたいですか？
可用性とコストのトレードオフ
「何があっても絶対に止めたくない」のであれば、利用可能なすべてのクラウドを契約し、すべてのリージョン・ゾーンで冗長化し、さらに自社のデータセンターも持つべきです。
しかし、現実にはそうしません。なぜなら、そこには莫大なコストがかかるからです。コストの内訳は大きく分けて3つあります。
- 費用コスト
- インフラの初期投資とランニングコスト
- 時間的コスト
- マルチクラウド・マルチリージョンを前提とした複雑なシステム設計・構築・運用の安定にかかる時間
- 運用コスト
- 複雑化したシステムの監視、障害対応、アップデートにかかる人的リソース。システムの複雑さは、時に機能開発の速度を犠牲にします
可用性戦略とは、どのリスクに、どれだけのコストを支払うかという経営判断そのものです。このバランスを見ずに「より安全だから」という理由でマルチリージョンを選択すると、コストと複雑性だけが増大し、見合った効果を得られない可能性があります。
そして、最も重要な問いがあります。
「クラウドインフラが原因の障害」と、「自分たちのアプリケーションが原因の障害（バグ、設定ミス、人的ミスなど）」、どちらの発生確率が高いでしょうか？
企業のリソースは有限です。インフラの過剰な冗長化にリソースを割いた結果、アプリケーションの品質担保や障害対応訓練が疎かになり、自分たちで障害を起こしてしまっては本末転倒です。
以降では、クラウドインフラが原因の障害リスクがどの程度なのかを評価する材料を提供します。
クラウド時代における可用性確保
ここでは話を分かりやすくするため、Google Cloudを例に説明します。
現代のクラウドサービスは、極めて高い可用性を前提に設計されています。例えばGoogle Cloudは、東京リージョン（asia-northeast1）と大阪リージョン（asia-northeast2）に、それぞれ3つの独立したゾーンを持っています。
地理的に離れた独立した地域（例: 東京）のことをリージョンと呼び、その中にある物理的に分離されたデータセンター群。それぞれが独立した電源、冷却、ネットワークを備えた単位をアベイラビリティゾーン（AZ）または単にゾーンと呼びます。
Google Cloudの多くのマネージドサービスは、デフォルトで複数のゾーンにまたがって冗長化されています（マルチゾーン、リージョナル構成）。つまり、1つのデータセンター（ゾーン）で障害が発生しても、サービスは継続するように設計されているのです。これは、自前でデータセンターを複数契約して冗長化するのに比べ、圧倒的に低コストで高い可用性を実現できる、クラウドの大きなメリットです。
Googleも、単一リージョン内での障害に耐えるアプリケーションの構築には、このマルチゾーン構成を推奨しています。そして、さらに上のレベルとして「リージョン全体が利用できなくなった場合に備える」ために、マルチリージョン化を選択肢として挙げています。
では、この「リージョン全体が利用できなくなる」事態は、どの程度の確率で起こりうるのでしょうか？
実際の障害データからリスクを評価する
クラウドインフラがどの程度安定しているかを知るには、公式のステータスダッシュボードを見るのが一番です。
過去の障害履歴を眺めると、ある傾向が見えてきます。
ゾーン単位の障害は比較的多い
ハードウェアの故障やメンテナンス作業など、単一ゾーンに影響する障害は定期的に発生しています。これこそが、マルチゾーン構成が重要である理由です。
リージョン単位の障害は非常に稀
単一リージョンのみに影響する大規模障害は、ゾーン障害に比べて圧倒的に少ないです。
広域障害はグローバルな問題が多い
リージョンレベルで影響が及ぶ障害は、特定のリージョンだけでなく、複数のリージョンやグローバルなネットワークコンポーネントに起因するケースが目立ちます。
重要なのは、これらの障害の多くが「パフォーマンスの低下」や「一部機能の利用不可」であり、既存のアプリケーションが完全に停止したり、データが破壊されたりするケースは極めて少ないということです。
大規模災害はリージョン障害を引き起こすか？
「日本は地震が多いから、東京リージョン全体がダウンするリスクに備えるべきだ」という意見もあります。過去の事例を見てみましょう。
私が調べた限り、過去に大規模な自然災害によって主要クラウドベンダーのリージョン全体が完全に停止した事例は見つかりませんでした。
以下にいくつかの代表的な事例を挙げます。
2016年 オーストラリア豪雨 (AWS ap-southeast-2 シドニーリージョン)
2016年6月5日に発生したこの障害は、シドニー地域を襲った大規模な暴風雨が原因でした。豪雨により地元の電力会社の変電所が停電し、その影響でAWSのデータセンターが電力を喪失しました。通常であれば、複数の電力系統と予備の発電機で電力を維持する設計になっていますが、この時は予備電源システムが設計通りに機能せず、特定の1つのアベイラビリティーゾーン（AZ）内の多数のインスタンスが影響を受けました。
この予備電源システムが正常に作動していれば、そもそもAZの停止は起こらなかった可能性があります。
2016年 ハリケーン・マシュー（Google Cloud us-east1 北米リージョン）
2016年10月に発生したハリケーン・マシューは、ノースカロライナ州だけで29人の死者が確認されるほどの大規模な自然災害でした。Google Cloudはハリケーンがデータセンターから200マイル以内に接近していると検知しながらも、特定のサービスの中断は予期していないと発表しました。
クラウドデータセンターは、自然災害に耐えうるよう堅牢に設計されています。もちろんリスクはゼロではありませんが、リージョン全体を機能不全に陥れるような災害は、国家レベルの非常事態と言えるでしょう。
まとめ
ここまでの考察を整理します。
マルチゾーン構成は非常に有効です。 ゾーン単位の障害は比較的よく起こるため、マルチゾーン構成でアプリケーションを設計することは、コストパフォーマンスに優れた可用性向上の基本戦略です。多くのクラウドサービスがこれを標準でサポートしています。
マルチリージョンで防げるリスクは限定的です。 マルチリージョン構成でなければ防げない「単一リージョン障害」の発生確率は非常に低いです。また、より発生確率の高い「グローバル障害」は、マルチリージョン構成でも防ぐことはできません。
本当にクリティカルならマルチクラウドを検討してください。 もし、Google Cloud全体のグローバル障害にも備える必要があるなら、検討すべきはマルチリージョンではなく、AWSやAzureなど他のクラウドを併用するマルチクラウド構成です。
多くのアプリケーションにとって、マルチリージョン構成は、発生確率の低いリスクに対して、非常に高いコスト（費用、技術、運用）を支払うことを意味します。
もしあなたがマルチクラウドの採用をコスト面から見送るのであれば、単一クラウド内でのマルチリージョン化によって得られる可用性の向上は、その複雑さやコストに見合わないかもしれません。
まずは堅牢なマルチゾーン構成を確立し、アプリケーション自体のバグを減らし、障害発生時の迅速な復旧訓練を行うこと。それが、多くのアプリケーションにとって最も現実的で効果的な可用性向上の第一歩となるはずです。
あなたのアプリケーションの価値と、許容できるリスク、そして支払えるコストを天秤にかけ、最適な可用性戦略を選択してください。
Discussion