MEGAZONEブログ
Hands-on with multi-Region architectures
マルチ・リージョン・アーキテクチャのハンズオン
Pulisher : Strategic Tech Center イ・ソンス
Description : マルチリージョンアーキテクチャ適用時に考慮すべき点とAWS Resilience Hubの紹介セッション
はじめに
事業継続性を高めるために、復旧時点や復旧時間の目標を達成するためのオプションや考慮すべき点について議論するセッションということで申し込みました。
セッションの概要紹介
RTO、RPOの定義といつマルチリジョンアーキテクチャを考えるべきか、マルチリジョンアーキテクチャを適用する際に考慮すべき点、最後にAWS Resilience Hubの紹介でまとめました。
このセッションのアジェンダは、マルチリージョンの定義やなぜ使うのかという説明と、その後にデモを見せ、質疑応答をする形式で行われました。
AWSは各地域ごとにリージョンというデータセンターのクラスターが存在し、そのリージョン内には可用領域で分離されており、可用領域ごとに物理的に互いに十分な距離を置いており、一つあるいは複数のデータセンターで管理されています。
リージョンの災害状況や高可用性のために「回復力」が必要な場合や、各リージョンの「規制の要求」やレイテンシーなどの利益を得ることができる「グローバルパフォーマンス」などのニーズがある場合は、マルチリージョンアーキテクチャを検討する必要があります。
マルチリージョン構成の場合、Active-Passive方式とActive-Active方式がありますが、Active-Active方式の場合、冗長なリソースとバックアップによりコストが高くなりますが、リージョン障害時の影響度が低く、Active-Passive方式の場合、運用に対するコストは低いですが、障害時にActiveからPassiveにサービスが移行するのに一定時間以上かかります。
では、いつActive-Activeアーキテクチャが必要なのでしょうか?
冗長費用をかけても99.99%以上のリージョン可用性が必要な場合と、リージョン内で生成されたデータを外部リージョンに持ち出すことができない場合、あるいはデータがバックアップされる場所がサービスされるリージョンから離れている場合など、アクセスしたユーザーとサービスエンドポイントが近く、レイテンシーなどに影響を受けやすい場合などです。
RTO(Recovery Time Objective)は目標復旧時間、RPO(Recovery Point Objective)は目標復旧時点ですが、バックアップと復旧戦略、コストなどを考慮してどの戦略を選択するかを決定することが重要です。規制、性能なども一緒に考慮すべき要素で、性能要件に合わせて常にマルチリージョンを考慮する必要はありません。 AWS Global Accelerator、Amazon CloudFrontなどを利用することもできますから。
また、AWS Resilience Hubを使用するメリットとして、復旧時間目標と復旧時点目標が達成されたかどうかを一元的に評価し、問題が発生する前に問題を特定するためのアラームを設定し、回復力を定義、検証、追跡することができます。
セッションを終えて
グローバルビジネスを展開するお客様でない場合、多くのお客様が単一リージョンサービスを利用しています。たまにDRを考慮してデータを他リジョンにバックアップする程度で使用していましたが、この機会にマルチリジョンアーキテクチャについてもう少し考えてみることができるセッションでした。