【動画レポ】JAWSDAYS 2024 B-4 国内東西リージョンでウォームスタンバイのDR設計をした話〜AWS User Group Japan JAWS-UGチャンネルから
今回は2024年3月2日（土）に池袋サンシャインで開催されたJAWSDAYS 2024のセッション動画が公開されていたのでその中からピックアップしたいと思います。
今回はDR設計がテーマのセッションです。
セッションスピーカー
松本 祐樹さん
佐々木慎也さん
デロイトトーマツコンサルティング合同会社
DB要件
・大規模な基幹システム
・首都直下型地震など大規模災害が発生しても業務を継続できる
・サービスレベルの障害ではDRを行わない
・東京リージョンから大阪リージョンにフェイルオーバー
・ＤＲ後大阪リーションをメインリージョンとする
・開発や運用保守を大阪リージョンで行う
・RTO/RPOは２時間だが過度にコストはかけたくない
・多数の外部システムからアクセスされる前提
・切り替え後に外部システムには再デプロイや設定変更を行わない
DR戦略の選択
・ＤＲ戦略としてウォームスタンバイを選択
バックアップ＆リストアやパイロットライトではRTOを満たせない
アーキテクチャ
・一般的なサーバレスアーキテクチャの構成
災害時
・Route53のエイリアスレコードを大阪リージョンのAPI Gatewayに切り替え
・外部システムごとにClientCredentionalGrantで認証
・CloudFormationのテンプレートをCodeCommitに保管、
CodeBuildとCodePipelineでデプロイ
DR設計時に検討したこと
APIクライアントの認証機能
実現したいこと
・外部システム向けにClient Credentional Grantによる認証
・AWS環境内に構築（外部iDaasは使用しない）
・ＤＲ発動後に外部システム側の設定変更を不要としたい
課題
・Amazon Cognitoを利用したいが大阪リージョンは未提供
・サードパーティ製品で構築を行う場合AmazonCognitoに比べ手間が増える
⇒絶妙のタイミングで大阪リージョンでCognitoが利用可能になった
Cognito利用となったがCognito間で同じ認証情報を利用できない
⇒認証情報の切り替えが必要 ：要件が満たせない
課題への対応
Amazon Cognitoの前段に処理を追加しリージョン間の認証情報の差異を吸収
・Cognitoの前段にAPI GatewayとLambdaを設置、認証情報を差し替え
・認証はCognitoにまかせてしまう
東西リージョンの構成管理
ウォームスタンバイ戦略では日頃から最新構成を維持する必要がある
⇒運用負荷を抑えつつ更新漏れをなくしたい
・東西リージョンの構成は８〜９割が同じ
・東西リージョンの更新をCI/CDパイプラインで更新したい
CloudFormationのテンプレートの構成
・同一リポジトリで階層化して管理（共通、東京専用、大阪専用）
・スタックに含める子テンプレートをリージョンごとのroot.yamlで選択
CI/CDパイプライン
・東西リーションをまたぐパイプラインを構築
・フォルダ単位に監視、変更が含まれていたらパイプラインを起動
〜コードコミットの遠隔地バックアップを取りつつ適用の手間を削減
課題
・大阪リージョンではAWS CodePipelineが提供されていない
認証アクションや複数実行時のステージ移行待機などが出来ない
⇒CodePipelineも大阪リージョンに利用可能になった
最終的に東西同じパイプラインで構成できた
まとめ
・大阪リージョンのサービスラインナップは日々充実してきている
・DR発動時には外部システムへの影響にも配慮する
・ウォームスタンバイ戦略では日頃から最新構成を維持しておく必要がある
この記事が気に入ったらサポートをしてみませんか？