おばんです。Mr.oldtypeです。
今回は AWS Summit 2022 レポートということで、表題のセッションを視聴してきました。
非常に内容の濃いものでしたので、張り切ってレポートしていければと思います。

セッション概要

タイトル

マルチリージョンでディザスタリカバリ(DR) 戦略を検討するためのポイント(AWS-50)

スピーカー

AWS パートナーアライアンス統括本部 ストラテジック SI 技術部 シニアパートナーソリューションアーキテクト　大場 崇令氏

概要

AWS をご利用されている全てのお客様が直面する可能性のある最大の課題の 1 つに災害イベントがあります。ワークロードまたはシステムのビジネス目標の達成を妨げるイベントは、災害として分類されます。このセッションでは AWS Well-Architected フレームワークで説明されている信頼性の柱のベストプラクティスを基に、AWS における複数リージョンでのディザスタリカバリ (DR) 戦略の考え方とアプローチをご紹介します。

レポート

本セッションは、AWSにおけるDR（ディザスタリカバリ）戦略、とりわけマルチリージョンにフォーカスした戦略検討についての内容であった。
ワークロードの特性に応じたDR戦略を取ることが重要だが、特にAWS Well-Architected Framework（W-A）における『信頼性の柱』の観点で考えることが重要、である。（そもそもDR戦略を取ること自体が信頼性を向上させる一つの施策である）

災害イベントとは

昨今企業が求められる『強力なIT基盤』を確立するには様々なリスクが蔓延っている。
自然災害、ネットワーク損失などの技術的障害、ヒューマンエラー。これら ビジネス目標を妨げるもの全て を『災害イベント』と位置付けた。
その『災害イベント』に備えるべく、AWSでは26のリージョン、84のAZ（アベイラビリティゾーン）を提供しており、ユーザー自身でワークロードの特性に沿った対策が可能となっている。

重要な『RTO』と『RPO』

その対策を進めるために初めに考えるべきことが『RTO（目標復旧時間）』と『RPO（目標復旧地点）』だ。
これらが短ければ短いほど、ワークロードの復旧は早まり信頼性が向上するが、同時にコストもかかる。
大場氏曰く「まずはマルチAZ構成で可用性要件を満たせるか検討」するのが良いとし、具体的な可用性算出の式とともに、ワークロードに応じた停止許容時間の検討方法について解説を行った。

4つの戦略

ではRTO/RPO指標が定まったところで、具体的な戦略はどのようなものが取れるのか。
セッションでは以下4つの戦略を紹介した。

• バックアップと復元
• パイロットライト
• ウォームスタンバイ
• マルチサイト アクティブ/アクティブ

ひとつずつ見ていこう。

バックアップと復元

これはシンプルに、サブサイトへ常時バックアップを取得転送し、有事の際はそのバックアップから復旧するものである。
必要なランニングコストは基本的にストレージ使用料のみとなるため、非常にコストを抑えたDR対策が可能となる。
ストレージには Amazon S3 のような高い可用性（SLO 99.999999999%）を持ったストレージを選択するのが良いが、ここで大場氏が繰り返し重要だと話したのが「バックアップから復元する手順を記述」し、「定期的に練習を行う」ことだった。
せっかくバックアップを取っていても、いざという時初めて実施するとなると失敗するリスクが高まる。これではせっかく策定したRTOを実現できなくなる。
また復元の際も、なるべく人の手を介さず自動的に構築を行うため IaC（Infrastructure as Code）を用いてDRサイト実装を行うのが望ましいとした。

パイロットライト

次に「パイロットライト」。これはデータベースなどのコアデータセットのみをサブサイトで稼働させ、残りのコンポーネントは障害時のみ起動させるものだ。
「バックアップと復元」と比較してデータベースサービスが常時稼働するためコストは多少上がるが、重要なコアデータセットが常にサブサイトにあるため、特にRPOを短くし復旧させることが出来るのが特徴だ。
具体的には Amazon Aurora Global DatabaseやAmazon DynamoDB グローバルテーブルを利用することで、RPO 5秒・RTO 1分といった非常にシビアなシナリオにも対応できるとした。
また、ここでも上述の「バックアップから復元する手順を記述」し、「定期的に練習を行う」ことや、 IaC（Infrastructure as Code）を用いてDRサイト実装を行うことの重要性は変わらなかった。

ウォームスタンバイ

次に「ウォームスタンバイ」。これは「パイロットライト」にプラスして低キャパシティーな本番機能をサブサイトに持っておくものだ。
当然「パイロットライト」と比較してコストはかかるが、本番機能が稼働しているため重要なリクエストだけ即座にフェールオーバーし、残りはキャパシティーを拡張して対応することが出来る。
非常に短いRTO/RPOが求められるが、本番環境よりコストを抑えたいワークロードの場合選択肢に上がる戦略だ。

マルチサイト アクティブ/アクティブ

最後に「マルチサイト アクティブ/アクティブ」。これは文字通り本番環境と全く同じキャパシティーをもったサブサイトを常に稼働させておくものだ。
4つの戦略の中で一番コストがかかるが、DNSのフェールオーバー（エンドポイントの向き先を変える）だけで切替が可能なので、数秒～数分以内に復旧が可能となる。
セッションではこの戦略を手助けするAWSサービスとして、Amazon Route53 DNSフェールオーバーとAWS Global Acceleratorが紹介された。
各サービス特徴があるので、ユースケースに応じて検討してほしい。

DR戦略を考える上で一番大切なこと

セッションでは『災害イベント』とそれに対応するための『4つの戦略』について説明された。
もちろんこれらの導入に向けてさっそく会議をするのも良いが、一番重要なのが「ワークロードにおける可用性要件は何なのか」と「それをどのように実装し、運用していくか」が非常に重要だと感じた。
またセッション中で大場氏は「可用性要件だけでなく、ビジネスの継続性の観点も考慮して設計する」ことが重要だと話した。
それをサポートするものとして、AWS Well-Architected Toolがある。一度実施をしてみてほしい。

まとめ

マルチリージョンにフォーカスしたDR戦略を学ぶことが出来ました。
特に「最初はシンプルに、徐々にレベルアップを目指していけばよい」という言葉と、「DRは実装だけでなく復旧の練習が非常に大事だ」という言葉には感銘を受けました。
まだDRを検討したことがない皆さん、まずはサービスの可用性と持続性要件を関係者で協議してみてください。
そして要件が固まったら是非。低コストで始められる「バックアップと復元」戦略から検討してみてください。

以上レポートでした。