どうも、島寿司です。
はじめに
とにかく落ちないサービスを作りたい...せや！とりあえずマルチリージョンアーキテクチャーにすればええんや！
マルチリージョンアーキテクチャーは大変。コストも掛かる。
長男だからどんなコストも我慢できるとかそんな話ではない。
マルチリージョンアーキテクチャーについて知って、自分たちのサービスの要件と照らし合わせて最適なアーキテクチャを選べるようにしましょう。
このページではAWSを例にマルチリージョンアーキテクチャーを検討する際の考え方とマルチリージョンの構成パターンをご紹介します。
今回は業務継続やDR観点から解説します。
そもそもマルチリージョンアーキテクチャーとは
マルチリージョンアーキテクチャーとは、複数のリージョンにシステムを配置することで、高可用性を実現する構成のことを言います。
AWSは世界中にリージョンがあり、リージョンごとに複数のゾーンがあります。1ゾーンは1つ以上のデータセンターでできています。
複数のリージョン間でシステムの分散運用やバックアップサイトを用意しておくことで、災害対策（DR）として有効です。
他にも、グローバルで展開しているサービスで
- 高い応答性能を求められる場合
- データを顧客が住んでいる地域で取り扱わないといけない場合
などにも有効です。
マルチリージョンにする必要、本当にありますか？
マルチリージョンを検討する観点として、業務継続性、レイテンシ、情報保護などの観点があります。
今回は業務継続性（可用性、災害対策）の観点から考えてみます。
可用性
稼働率と停止時間に注目します。
AWSではシングルリージョンでMulti-AZであれば稼働率99.99%を実現できます。つまり月間停止時間4.38分停止、年間で 52.56 分停止することを許容できない場合はマルチリージョンを検討することになります。
２つのリージョンで同等のインフラを構築した場合、稼働率99.99%のシステムが並列で動くので
1-(1-0.9999)×(1-0.9999)=0.99999999
稼働率は99.999999%となり月間停止時間は0.026秒停止、年間で0.315秒停止することに相当します。
いくつかのAWSサービスを例に上げて計算してみます。
リージョン内でEC2、ELB、Aurora、CloudFrontを使った場合の稼働率を計算してみましょう。ここではSLAで定義されている稼働率を使用します。
- EC2（マルチAZ）、ELB、Aurora（マルチAZクラスター）:99.99%
- CloudFront：99.9%
シングルリージョンでは、
0.9999×0.9999×0.9999×0.999=0.99870033
稼働率は99.87%となり月間停止時間は56.94分停止、年間で11.388時間停止することに相当します。
2つのリージョンで同等のインフラを構築した場合、
1-(1-0.9987)×(1-0.9987)=0.99999831
稼働率は99.999831%となり月間停止時間は4.44秒停止、年間で53.296秒停止することに相当します。
自分たちが作るサービスはこれほどの稼働率が要求されるのか？どれくらいの停止時間が許容されるのか？という観点で検討してみると必要な構成が見えてきます。
稼働率の算出方法
コンポーネントA・B・Cに依存関係がある：稼働率=Aの稼働率×Bの稼働率×Cの稼働率
コンポーネントAが冗長化されている：1-(1-Aの稼働率)^並列数
災害対策（DR）
DRを考える指標として、RPO（目標復旧地点）とRTO（目標復旧時間）があります。
(画像は【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummitより引用)
マルチリージョンと聞くと、複数のリージョンですべてのサービスが稼働している（Active-Active）構成をイメージするかもしれませんが、必ずしもその必要があるとは限りません。
許容されるRPO、RTOによっていくつかのパターンが考えられます。
- Backup & Restore
- Pilot Light
- Warm Standby
- Active-Active
(画像はAWS IoTのDRを考えるより引用)
それぞれ見ていきましょう。
Backup & Restore
- 平常時はメインサイトでシステムを運用し、バックアップを取得
- RTOに応じて、バックアップデータを定期的または障害発生時にサブサイトへ転送
- 障害発生時にデータをサブサイトで復元
- 最もDRにおける運用コストを抑えられる
- RPO：数時間以内、RTO：24時間以内
(画像は【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummitより引用)
Pilot Light
- 平常時はコアサービスやダウンタイムを作りたくないシステムをサブサイトで運用
- 障害時にDNSルーティングを切り替え、必要に応じて止まっているサーバーを起動
- データベースはサブサイトでも常時運用しておくことで復旧にかかる時間を短縮できる
- RPO：数分以内 RTO：数時間以内
(画像は【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummitより引用)
Warm Standby
- 平常時からからメインサイト同等の機能をもち、規模を縮小したサブサイトを運用
- 障害時は自動フェールオーバーし、流量を絞って業務を継続
- サブサイトで復旧後にスケールが必要
- RPO：数秒以内、RTO：数分以内
(画像は【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummitより引用)
Active-Active
- 平常時からメインサイト同等構成のサブサイトを運⽤
- 障害時は⾃動フェールオーバー
- 最もコストが掛かる構成
- RPO：数秒以内orなし、RTO：数秒以内
(画像は【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummitより引用)
可用性を高めるとお金がかかる
可用性を高めるには、クラウド利用料が跳ね上がります。
Active-Avtiveの構成で、単一リージョン内の構成と同等のリソースを別リージョンにも構築する場合、その分のコストが倍になります。
また、AuroraやS3をリージョンまたぎでレプリケーションする場合、単一リージョンでの利用料以外にも別途レプリケーション費用がかかるのでデータ操作の頻度が多いサービスの場合は注意が必要です。
データ量やスループットの前提を置いて試算してみることをおすすめします。
サービスによって課金体系が異なるため、AWSの公式ドキュメントやシミュレーターを確認してみてください。
他にも、時間コストや人的コストへの投資も増加します。
ビジネスへの影響やリスクを考慮して可用性要件を定義することが重要です。
マルチリージョンがサポートされているか確認する
AWSでマルチリージョンアーキテクチャーを構築する場合、検討しているAWSサービスがマルチリージョンをサポートしているかが非常に重要です。
マルチリージョンがサポートされていれば、開発がグッと楽になります。
逆にサポートされていなければ自分で作り込むか、使うAWSサービスを変えることになるので余計に工数がかかります。
余談ですが、私が過去に聞いたプロジェクトでは、ある程度開発が進んだあとに稼働率99.999%が要求されていることが発覚し、使っているAWSサービスを見たところマルチリージョンがサポートされていなかったことがわかり、大変ざわざわしたそうです。。。
実現可能性を調査する際は、マルチリージョンがサポートされているも含めて調査してみてください。
マルチリージョンがサポートされているAWSサービス例
- Global Accelarator
- 2つのグローバルの静的なIPを使ってマルチリージョンでトラフィックを振り分けられる
- Route53だけで短い間隔でヘルスチェック&フェイルオーバーをしようとするとキャッシュが課題になるが、Global Accelaratorを挟めばRoute53のキャッシュを気にせずに高速フェイルオーバーが可能
- ALBに対してヘルスチェックをする場合、ALBの自身が行うヘルスチェックの結果を見ていないので、Route53のようにbodyの中身まで見れない
- DynamoDB Global Tables
- １秒以下で別リージョンにレプリケーション完了
- SLA99.999%が定義されている
- 各リージョンに書き込みトラフィックが流れるようにすると整合性の問題が出てくるため、パーティションの工夫が必要
- Aurora Global Database
- １秒未満で別リージョンにレプリケーション完了
- 整合性モードが選べる（セッションの整合性、グローバルな整合性、結果整合性）
- 書き込みインスタンスはプライマリーリージョンに１つしかない
- 他のリージョンへの書き込みトラフィックは書き込み転送機能を使えばプライマリーリージョンに書き込みトラフィックを転送できる
- セカンダリークラスターは制約が多いので注意（AutoScalingが使えなかったりする）
- S3
- クロスリージョンレプリケーションが使用可能
- 公式ドキュメント曰く「ほとんどのオブジェクトは 15 分以内にレプリケートされる」とのこと。性能要件も合わせて使い方の検討が必要
最後に
持って帰っていただきたいこと
- ビジネスニーズ応じて可用性、RPO、RTOを決めることが大事
- マルチリージョンにもいくつか種類があるため、可用性、RPO、RTOに応じたアーキテクチャを決定する
- すべては壊れるものとして考え、障害は起きるものとして管理・対策する
- マルチリージョンにするとクラウドコスト、時間コスト、人的コストがかかることを理解してどこまで許容できるかを検討する
以上、島寿司でした！