JAWS-UG 浜松 AWS 勉強会 2021#2 2021/02/26
システムの地理冗長を考える（2021/02 版）JAWS-UG 浜松 AWS 勉強会 2021#2 2021/02/26まつひさ（hmatsu47）
View Slide
自己紹介松久裕保（@hmatsu47）https://qiita.com/hmatsu47名古屋で Web インフラのお守り係をしていますMySQL 8.0 の薄い本を作って配っています○ Qiita の記事：https://qiita.com/hmatsu47/items/ceb75caf46e3c761095d○ GitHub リポジトリの他、印刷版を勉強会などで無料配布していました○ 新型コロナウイルスの関係でオフライン勉強会ができなくなったので、現在は BOOTH でも配布しています（100円＋送料）8.0.23対応版配布中https://hmatsu47.booth.pm/2
おことわり内容は無保証です● 発表者個人の経験や考えをもとに構成しています● 一部 AWS Well-Architected フレームワークを参照していますが、必ずしもそれに沿う内容ではありませんAWS 以外の障害事例を含んでいます● オンプレや他クラウドの障害事例が混ざっています○ 何に備えて冗長化するのかをイメージするための例示です地理冗長とは直接関係のない内容には（原則）触れません● アプリケーションのバグ・AWS ユーザ自身のオペレーションミスなど3
その他内部にデータベース等を持つ動的なサイトを前提とした話です● 静的サイトとして生成・運用できるのであれば、地理冗長も楽になります4
背景東京リージョンの各 AZ で一通り大きな障害が発生● 2019/08/23 : apne1-az4（冷却システム障害→ EC2 基盤障害）● 2020/10/22 : apne1-az2 （ネットワーク接続性問題）● 2021/02/19-20 : apne1-az1（冷却システム障害→ EC2 基盤障害）※apne1-az3 は一部のユーザのみ利用可能な古い AZ なので除外マネージドサービス障害も発生（東京リージョン全体）● 2020/04/20 : SQS および SQS 利用サービス（Lambda など）この機会にシステムの地理冗長を見直しておきたい5
よくある誤解6AWS 障害でわが社のサービスが止まっただと？けしからん！至急マルチクラウド化して止まらないサービスにしなさい！AWS なら海外リージョンを使って冗長化すれば、日本で震災が起きても止まらないシステムなんて簡単に作れるよね？知ってるよ。俺は詳しいんだ。
地理冗長パターン選択・実装のポイントSLO・可用性目標を決める● 提供サービス別・機能別など（ビジネス価値をベースに）発生しうる障害（リスク）を洗い出す● データセンター障害・マネージドサービス障害・広域停電・震災などRPO / RTO を定める● SLO・可用性目標と障害ケースに応じて（コストを考慮して）定める地理冗長パターンを選ぶ（単一リージョン複数 AZ・マルチリージョン他）● 地理冗長で生じるリスク・デメリットも考慮する選択した地理冗長パターン・RPO / RTO に合わせて実装する7
地理冗長と AWS Well-Architected フレームワーク信頼性の柱についてのホワイトペーパー（2020/04 版・日本語）● https://d1.awsstatic.com/whitepapers/ja_JP/architecture/AWS-Reliability-Pillar.pdf● 可用性目標に合わせた実装例○ SLO に合わせたサービス実装・地理冗長パターンの選択の参考になる● 単一リージョンのシナリオ／複数 AZ○ 主に「99.9%(スリーナイン)シナリオ」以降○ P.89～97● 複数リージョンのシナリオ○ P.97～1098
地理冗長と AWS Well-Architected フレームワーク信頼性の柱についてのホワイトペーパー（2020/04 版・日本語）● https://d1.awsstatic.com/whitepapers/ja_JP/architecture/AWS-Reliability-Pillar.pdf● 可用性目標に合わせた実装例○ SLO に合わせたサービス実装・地理冗長パターンの選択の参考になる● 単一リージョンのシナリオ／複数 AZ○ 主に「99.9%(スリーナイン)シナリオ」以降○ P.89～97● 複数リージョンのシナリオ○ P.97～1099P.63 推奨事項「ワークロードの信頼性目標はほとんど、単一の AWSリージョン内でマルチ AZ 戦略を使用して満たすことができます。マルチリージョンである必要があるワークロードの場合のみ、マルチリージョンアーキテクチャをご検討ください。」
SLO（サービスレベル目標）・可用性目標提供サービス（機能）の目的やビジネス価値に応じて決める● リアルタイム処理が不要な機能には、即時復旧は必要ない● ビジネス価値と不釣り合いに高いコストを掛けないRPO / RTO を決める（仮決め）● RPO（目標復旧時点）○ いつの状態に戻すか？● RTO（目標復旧時間）○ 何分・何時間以内に復旧するか？● 達成のためのコストがビジネス価値に見合うように、必要なら後で調整10
リスク洗い出し : 障害事例を知る物理障害（DC 障害など）については、オンプレ事例を参考に● クラウド利用ではイメージしづらい部分なのでどの地理冗長パターンが有効な対策になり得るか● 例 : DC 障害→単一リージョン複数 AZ パターンで回避・軽減可能11
障害事例 1 : データセンター（DC）電源障害2006/08/14 首都圏の停電● クレーン船が送電線に接触→溶解→停電● 品川エリアにある某 DC にて、自家発電装置が起動しないまま UPS でカバーできる時間を越えてしまい、サーバ室への電源供給が停止※同様の事例は複数の DC で過去に何度か発生当時の資料● http://www2.iee.or.jp/ver2/honbu/16-committee/epress/data/12-jirei.pdf● http://ke.kabupro.jp/tsp/20060814/180e0270_20060814.pdf12
障害事例 2 : DC 回線障害とある会社が利用していた DC にて● 大手キャリア某社の下請け作業員が DC で回線敷設作業● 作業員が誤って工具を床下に落下、床下の光ファイバーを切断○ 作業員が事故を報告せずに退館したため、対処が遅れた○ 「とある会社」ではネットワーク障害が発生し、騒ぎにAWS の DC はもっと管理状態は良いはずだが、IDF・MDF・建物への引き込み口周辺は回線が密集するので、事故があると全体への影響が大きい13
障害事例 3 : DC 火災2013/02/25 台湾の DC で火災発生● NTT コミュニケーションズ（が借りていた） DC● GMO クラウドなどもコロケーションで利用● 地下の UPS 室で火災参考リンク● https://tomocha.net/diary/?20130225● http://twitpic.com/c6pf3f14
障害事例 4 : DC ファシリティ作業ミス・不具合2019/08/23 AWS 東京リージョン apne1-az4 冷却システム障害● 冷却システムのバグ● EC2 および EC2 基盤を使うサービスに障害発生※2021/02/19-20 apne1-az1 の障害も冷却システム障害（電力障害による）参考リンク● https://aws.amazon.com/jp/message/56489/● https://piyolog.hatenadiary.jp/entry/2019/08/23/174801障害事例 1 ～ 4 は DC に閉じた障害なので、単一リージョン複数AZ パターンで回避可能（障害事例 5 ～の対策には不十分）15
対策 : 複数 AZ 対応サービスの導入（例）インターネット接続の冗長化● ELB（ALB・NLB）● API Gateway● Route 53（ヘルスチェック & DNS フェイルオーバー）データストア● DynamoDB● Aurora● S3● DocumentDB16
17例 : Aurora 複数 AZ 構成（データ読み取り）apne1-az1Writerapne1-az2Readerapne1-az4Readerap-northeast-1（東京）(注) 別 AZ の Reader を読みに行く ケースもある（以降、同様）
18例 : Aurora 複数 AZ 構成（データ書き込み）apne1-az1Writerapne1-az2Readerapne1-az4Readerap-northeast-1（東京） AZ またぎのアクセスになる↓ ↓2021/03/02 追記 :Aurora Multi-Master なら Writer を複数持てるが、機能面・性能面（特に更新性能）での制限がある
注意点EBS● 基盤障害・AZ（DC）障害があるとよく保存データが壊れる○ 永続的なデータストアとして使うなら複製・バックアップ必須RDS Multi-AZ● 障害 AZ の復旧後、データ再同期で性能低下の可能性があるEC2 などの Auto Scaling● オートスケールには時間が掛かる（サービスによって差がある）● AZ によっては起動できないインスタンスタイプがあるELB● 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも19https://minne.com/items/2715511(ekot) より
注意点EBS● 基盤障害・AZ（DC）障害があるとよく保存データが壊れる○ 永続的なデータストアとして使うなら複製・バックアップ必須RDS Multi-AZ● 障害 AZ の復旧後、データ再同期で性能低下の可能性があるEC2 などの Auto Scaling● オートスケールには時間が掛かる（サービスによって差がある）● AZ によっては起動できないインスタンスタイプがあるELB● 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも20https://minne.com/items/2715511(ekot) より2AZ で冗長化していて片方落ちたら、オートスケールでカバーできるのか？
注意点EBS● 基盤障害・AZ（DC）障害があるとよく保存データが壊れる○ 永続的なデータストアとして使うなら複製・バックアップ必須RDS Multi-AZ● 障害 AZ の復旧後、データ再同期で性能低下の可能性があるEC2 などの Auto Scaling● オートスケールには時間が掛かる（サービスによって差がある）● AZ によっては起動できないインスタンスタイプがあるELB● 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも21https://minne.com/items/2715511(ekot) よりスティッキーセッションを使っていると障害 AZ 宛てに流し続けることも
障害事例 5 : マネージドサービス障害2020/04/20 AWS 東京リージョンの SQS 障害● Lambda・CloudWatch・CloudFormation（など？）にも影響● 東京リージョン単位（全 AZ）での障害に※マネージドサービスのオペレーションミスもリージョン障害になり得る参考リンク● https://classmethod.jp/news/200420-aws-incident/● https://uedy.work/?p=26（オミカレ : SQS・Lambda 等をシンガポールリージョンへ一時的に移行）● https://qiita.com/saitotak/items/07931343bcb703b101f822
障害事例 6 : インターネットのルーティング障害2017/08/25 Google の作業ミスによる通信障害● Google が誤った経路情報を配信● OCN（NTT コム）・KDDI などが影響を受け通信しづらい状況に● https://piyolog.hatenadiary.jp/entry/20170825/1503655538● https://internet.watch.impress.co.jp/docs/news/1077715.html※同様の事例は Google 以外にも過去に何度か発生AWS では 1 リージョンの複数 AZ で AS 番号を共用しているはず● このような事故が発生するとリージョン障害になり得る23
参考事例 : 地震による広域電源障害（ブラックアウト）2018/09/06 北海道胆振東部地震による北海道電力の全域停電● 苫東厚真火力発電所の発電機が相次いで停止○ 連鎖的に他の発電所等も停止当時の資料● https://www.occto.or.jp/iinkai/hokkaido_kensho/files/181219_hokkaido_saishu_gaiyou.pdf自家発電装置の燃料確保問題が発生すると DC 運用継続に影響● 東日本大震災でも発生● 優先供給契約を結んでいても、被災地域が広範囲になったり供給経路が絶たれたりすると確保できない可能性がある24
対策 : 複数リージョン対応サービスの導入（例）インターネット接続（エッジロケーション）● CloudFront● Global Accelerator○ IP Anycast によって同一 IP アドレスを各リージョンに振り分け可能■ グローバルに提供するサービスに有効データストア● DynamoDB Global Tables● Aurora Global Database● S3（クロスリージョンレプリケーション）25
例 : Global Acceleratorhttps://aws.amazon.com/jp/global-accelerator/ より26
27例 : Aurora Global Database（データ読み取り）apne1-az1Writerapne1-az2Readerapne1-az4Readerap-northeast-1（東京）apne2-az1Readerapne2-az2Readerapne2-az3Readerap-northeast-2（ソウル）
28例 : Aurora Global Database（データ書き込み①）apne1-az1Writerapne1-az2Readerapne1-az4Readerap-northeast-1（東京） AZ またぎのアクセスになる↓ ↓apne2-az1Readerapne2-az2Readerapne2-az3Readerap-northeast-2（ソウル） リージョンまたぎのアクセスになる ↓ ↓ ↓
29例 : Aurora Global Database（データ書き込み②）apne1-az1Writerapne1-az2Readerapne1-az4Readerap-northeast-1（東京） AZ またぎのアクセスになる↓ ↓apne2-az1Readerapne2-az2Readerapne2-az3Readerap-northeast-2（ソウル） 各 Reader で書き込み転送を使用 ↓ ↓ ↓
マルチクラウド化は必要？エッジロケーションのサービス（CloudFront・Global Accelerator 他）● リージョンのサービスとは別の DC で運用○ オペレーションミス等での全停止が（理論上は）あり得るその他グローバルサービス（Route 53(※)・IAM 他）(※) パブリックゾーンの情報はエッジロケーションに配置● こちらも理論上は全リージョン停止があり得る○ とはいえ、障害時にアクセス先を別クラウドへ確実に切り替えるのは難しい国外にデータを置けないなどの制約があれば、考慮が必要に● 大阪ローカルリージョンのフルリージョン化を待つ手も2021/03/02 追記 : 本日より、大阪リージョンはフルリージョン化！30
31他クラウド上のシステムAWS上のシステム（稼働率 : 99.99%）他クラウド上のシステム（稼働率 : 99.99%）インターネット（ユーザ）データ同期稼働率 : 99.999999%?
32他クラウド上のシステムAWS上のシステム（稼働率 : 99.99%）他クラウド上のシステム（稼働率 : 99.99%）インターネット（ユーザ）データ同期稼働率 : 99.999999%?ここの可用性も考慮する必要あり（Route 53?）ここの可用性を考慮する必要あり
33他クラウド上のシステムAWS上のシステム（稼働率 : 99.99%）他クラウド上のシステム（稼働率 : 99.99%）インターネット（ユーザ）データ同期ここの信頼性確保も難しい（通常はインターネット経由になる）
34他クラウド上のシステムAWS上のシステム（稼働率 : 99.99%）他クラウド上のシステム（稼働率 : 99.99%）インターネット（ユーザ）データ同期AWS で複数リージョン化する以上に難しい
障害ケース 影響期間 発生頻度 単一リージョン複数 AZ複数リージョンDC 障害その他局所的な災害数時間～数日間 ～ 1 年／回 回避・軽減可能 回避・軽減可能マネージドサービス障害数時間 数年／回×利用サービスの数一部回避・軽減可能ほぼ回避・軽減可能インターネットのルーティング障害数時間 数年／回 回避・軽減できない可能性あり回避・軽減可能広域電源障害・震災不定（なし～数か月以上）数十年／回 回避・軽減できない可能性あり回避・軽減可能障害ケースと地理冗長パターン35
障害ケース 影響期間 発生頻度 単一リージョン複数 AZ複数リージョンDC 障害その他局所的な災害数時間～数日間 ～ 1 年／回 回避・軽減可能 回避・軽減可能マネージドサービス障害数時間 数年／回×利用サービスの数一部回避・軽減可能ほぼ回避・軽減可能インターネットのルーティング障害数時間 数年／回 回避・軽減できない可能性あり回避・軽減可能広域電源障害・震災不定（なし～数か月以上）数十年／回 回避・軽減できない可能性あり回避・軽減可能障害ケースと地理冗長パターン36
地理冗長で生じるリスクとデメリットネットワークの遅延とシステムの複雑化● 距離が延びる→ネットワーク遅延増大○ EC2 RTT（32 ～ 64 bytes）：AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms● 経由する機器・設備や組み合わせるサービスが増える→複雑化○ 想定外の動作が生じやすい（スプリット・ブレインなど）切り戻し／復旧に関するリスク● 切り戻し／復旧時に性能低下・データ破損などのトラブルもコストの増加37複数 AZ 化で 10 倍、複数リージョンで 100 ～1,000 倍以上の遅延が生じる
地理冗長で生じるリスクとデメリットネットワークの遅延とシステムの複雑化● 距離が延びる→ネットワーク遅延増大○ EC2 RTT（32 ～ 64 bytes）：AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms● 経由する機器・設備や組み合わせるサービスが増える→複雑化○ 想定外の動作が生じやすい（スプリット・ブレインなど）切り戻し／復旧に関するリスク● 切り戻し／復旧時に性能低下・データ破損などのトラブルもコストの増加38アプリケーションの動作が緩慢になるだけでなく、最悪の場合システムが停止
地理冗長で生じるリスクとデメリットネットワークの遅延とシステムの複雑化● 距離が延びる→ネットワーク遅延増大○ EC2 RTT（32 ～ 64 bytes）：AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms● 経由する機器・設備や組み合わせるサービスが増える→複雑化○ 想定外の動作が生じやすい（スプリット・ブレインなど）切り戻し／復旧に関するリスク● 切り戻し／復旧時に性能低下・データ破損などのトラブルもコストの増加39リージョン A と B の夫々でシステムがバラバラに動作してしまう
地理冗長で生じるリスクとデメリットネットワークの遅延とシステムの複雑化● 距離が延びる→ネットワーク遅延増大○ EC2 RTT（32 ～ 64 bytes）：AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms● 経由する機器・設備や組み合わせるサービスが増える→複雑化○ 想定外の動作が生じやすい（スプリット・ブレインなど）切り戻し／復旧に関するリスク● 切り戻し／復旧時に性能低下・データ破損などのトラブルもコストの増加40データ再同期による I/O の負荷発生再同期の失敗 など
地理冗長で生じるリスクとデメリットネットワークの遅延とシステムの複雑化● 距離が延びる→ネットワーク遅延増大○ EC2 RTT（32 ～ 64 bytes）：AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms● 経由する機器・設備や組み合わせるサービスが増える→複雑化○ 想定外の動作が生じやすい（スプリット・ブレインなど）切り戻し／復旧に関するリスク● 切り戻し／復旧時に性能低下・データ破損などのトラブルもコストの増加41求められるスキルの高度化などによる潜在的なコストの増加も含む
発生リスク・デメリット 単一リージョン複数 AZ 複数リージョンネットワーク遅延・システム複雑化低～中（使うサービス・実装による）中～高（使うサービス・実装・リージョンによる）切り戻し／クラスタ復旧リスク低～中（使うサービス・実装による）中～高（使うサービス・実装による）コスト増加 低～中（使うサービス・実装による）高リスク・デメリットと地理冗長パターン42
RTO / RPO（見直し）全ての障害ケースに対して同一の RTO を設定する必要はない● 障害ケースによっては RTO が長くなる対策を採用するケースも○ 影響期間・発生頻度・想定される損失・対策に必要なコスト等による● そのときユーザがどんな状況下にあるのか想像することも大事○ ユーザ側が利用困難な状況で、システムの無停止継続は本当に必要か？RPO についてはデータの種類や作業コストも考慮する● 変動が少ないデータや再投入が容易なデータは、あえてバックアップデータからの復旧を選択する手も43
まとめ具体的な障害ケースをイメージして対策を考える● どの地理冗長パターンで対処できるか？○ 過去の AWS 東京リージョン障害事例では、マルチクラウド化が必要なケースは（国外にデータを保管できないケースを除いて）なかった対策によって生じるリスクやデメリットにも目を向ける● ネットワーク遅延とシステムの複雑性が上がると新たなリスクが生じる● 切り戻し／復旧のリスクにも気をつけるビジネス価値に見合った対策を行う● 障害ケースや提供サービス別の RTO / RPO を考える（コストを考慮して）44
よくある誤解への回答45AWS 障害でわが社のサービスが止まっただと？けしからん！至急マルチクラウド化して止まらないサービスにしなさい！AWS なら海外リージョンを使って冗長化すれば、日本で震災が起きても止まらないシステムなんて簡単に作れるよね？知ってるよ。俺は詳しいんだ。過去の AWS 東京リージョンの障害で、対策にマルチクラウド化が必要なケースはほぼなかった。AWS はリージョンの独立性が高いので、障害対策のためのマルチクラウド化が必要なケースはかなり限定される。
よくある誤解への回答46AWS 障害でわが社のサービスが止まっただと？けしからん！至急マルチクラウド化して止まらないサービスにしなさい！AWS なら海外リージョンを使って冗長化すれば、日本で震災が起きても止まらないシステムなんて簡単に作れるよね？知ってるよ。俺は詳しいんだ。AWS で複数リージョンにまたがるシステムを構築すること自体はさほど難しくはないが、安定性・信頼性を損なうことなく運用が可能で、かつビジネス価値に見合うコストでシステムを構築するのは難しい。
hmatsu47
kojira
microcms
forcia_dev_pr
moyheen
minorun365
mot_techtalk
shohei1029
trycycle
hazumirr
yu4u
inesmontani
junkifurukawa
sugarenia
jlugia
afnizarnur
62gerente
trallard
tanoku
lara
keathley
stephaniewalter
deanohume
morganepeng
yeseniaperezcruz