大阪リージョンへのDR初設計

Transcript

1. 大阪リージョンへのDR初設計 ※本資料の内容は、個人の見解であり、所属する企業とは一切関係がありません。
2. 普段はITアーキテクトとしてチームリード、設計、実装を行っております。 • 名前: 松本 祐樹 • ロール: ITアーキテクト(主にAWS) • AWS歴: 6年 • クラウド系認定資格:  AWS: 12認定(全冠)  Google Cloud: 11認定(全冠)  Azure: Solutions Architect Expert, Administrator Associate • IPA系:  DB, AP, FE • Japan AWS All Certifications Engineer • IPA 情報処理技術者試験委員  自己紹介
3. 大阪リージョンは、2021年3月に国内で2番の正式なリージョンとしてオープンしました。 オープンから約3年が経過し、国内でDRを検討することが増えてきています。  大阪リージョンの公開 AWS 大阪リージョン - 2021年3月 誕生! | AWS (アマゾン ウェブ サービス) (amazon.com)
4. 本LTでは、DRの初設計に挑んだ際に苦労した部分を話したいと思います。  Topics • 検討対象のAWSアーキテクチャ図 • DR戦略の概要 • DR設計に入る前に確認しておくこと  DR戦略の採用  ステークホルダーのDRのイメージ  外部システムのDR方針 • AWSリソース別DR設計 • API Gateway • Lambda • … 本日、お話しする範囲
5. 今回は、AWS上に構築された以下のシステムを大阪リージョンにDRできるように設計し てみましょう。どのようなDR設計になるでしょうか？  検討対象のAWSアーキテクチャ図 AWS Cloud 東京リージョン Amazon S3 Amazon DynamoDB AWS Lambda Amazon API Gateway User Internet Corporate data center Amazon SQS AWS Lambda Internet
6. AWSは4種類のDR戦略を定義しておりコストとRPO/RTOを最適化することができます。 「どれを採用すべきか」という問いへの解答をDR設計の前に用意しなければなりません。  DR戦略の概要 Disaster recovery options in the cloud - Disaster Recovery of Workloads on AWS: Recovery in the Cloud (amazon.com)
7. まず、システムで実現したいこと(=ビジネスの目的)を確認する必要があります。 RPO/RTOの数値だけでなく、DRを行いたい理由は必須で確認しましょう。  ビジネスの目的 • ビジネス上必ず必要な機能なら、追加で資金調達してでも作らなけ ればならない • 例) 法改正に対する対応 • わざわざ大阪リージョンにDRしたいのはなぜか？ => 原則は止められないから • ただ、止められないという理由だけでは、すべてのシステムに当ては まる一般論に終始してしまう
8. 「止められない」ということは明確なので、さらに踏み込んで目的を深堀していく必要が あります。つまり、ビジネスの目的を押さえた戦略を採用しましょう。  ビジネスの目的(例) • 全国の工場の操業を管理するシステムだから、30分止まっただけで も1億円の損失が出る。 => active/activeを採用し、コストをかけてでも停止時間を短くする • BCPが策定され、今後構築するシステムはBCPに準ずる必要がある から、大規模災害(首都圏直下型地震等)発生時に6時間以内に復 旧しなければならない。 => ウォームスタンバイで十分対応できる。ただし、東京リージョンが 長期間復旧しない可能性が高いので、DR発動後は大阪リージョンを メインにする
9. DRという単語はあいまいな単語で、ステークホルダーによってイメージしているDRの内容 が異なる。DR設計の前にDRに対するイメージを合わせる必要があります。  ステークホルダーのDRのイメージ • ステークホルダーとDRの発動条件や内容を共有できているか？  開発者 Aさん: 使用しているAWSサービスが1つでも落ちたらDR発動だと思っていた。  IT部門 Bさん: すべて自動で切り替えができると思っていた。  ビジネス部門 担当 Dさん: DRが発動すると、大阪リージョンで全機能がすぐに使えるようになると 思っていた。 • DRの発動条件はステークホルダーの合意を取っているか？  大規模災害時(≒適切な権限を持った人がDR発動を宣言する)？  外形監視失敗時？ • 本当にすべてを自動化する必要があるのか？  全部を自動化すると相当大変 + 誤発動を許容できるのか？  手作業を挟むと作業ミスのリスクがあるので、できる限りの自動化は必要です。 • 全機能でRTO/RPOを守り切らないといけないのか？  エンドユーザー影響がすぐに出ない機能(バッチなど)は、DR対応と切り離せないか？  全てのデータをリストアするとRTOが守れないかもしれない。 大阪リージョンにバックアップを取らないという選択肢を捨てない
10. 自システムがDRに対応できたとしても、依存関係がある外部システムがDRに対応して いるとは限らない。外部システムのDR方針を確認しておく必要があります。  外部システムのDR方針 • 外部システムのDR方針によって自システムのDR設計が大きく異なる。  外部システムがDRしないなら、自システムのどの機能が使えなくなるのか？ その機能だけをユーザーが実行しないようにできるのか？  外部システムがDRしたとしても、RTOが自システムと違う場合が多い。 RTOの差をどうやって埋めるのか？  RPOを決めていたとしても、自システムと外部システムで、データの整合性を完全 に合わせ切った状態で切り替えることは、かなり難しいです。 手動でデータの整合性を合わせる方法はどうするのか？ • サーキットブレイカーだけでは、うまくいかないケースもある Amazon API Gateway Amazon SQS with DLQ Amazon DynamoDB AWS Lambda with circuit breaker Corporate data center Internet User SQSの保持期間は最大14日であり、 外部システムの復旧にそれ以上かかると DLQのキューが失われる
11. DR設計を始める前に、ビジネスの目的の確認、ステークホルダーとのDRイメージ合わせ、 外部システムのDR方針確認といった、外堀を埋めておくことが大切です。  ステークホルダーのDRのイメージ • ビジネスの目的 なぜ、わざわざDRを行いたいのか？ RTO/RPO以外に実現しなければいけないことは何か？ • ステークホルダーとのDRイメージ合わせ DRの発動条件は？ 自動化する範囲は？ 全ての機能・データがDRに必要か？ • 外部システムのDR方針確認 外部システムはDRする？ 外部システムのRTO/RPOは？
12. 本日のLTでお話できなかったAWSリソース別DR設計が気になる方もいらっしゃると思い ます。  Topics • 検討対象のAWSアーキテクチャ図 • DR戦略の概要 • DR設計に入る前に確認しておくこと  ビジネスの目的  ステークホルダー間のDRの定義  外部システムのDR方針 • AWSリソース別DR設計 • API Gateway • Lambda • … 本日、お話できなかった範囲
13. JAWS DAYSのランチセッションに登壇します！ JAWS DAYSでお待ちしております！！  JAWS DAYS JAWS DAYS 2024 (jaws-ug.jp)
14. EOF