システムの地理冗長を考える（2021/02 版）

Transcript

1. システムの地理冗長を考える （2021/02 版） JAWS-UG 浜松　AWS 勉強会 2021#2　2021/02/26 まつひさ（hmatsu47）

2. 自己紹介 松久裕保（@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

3. おことわり 内容は無保証です • 発表者個人の経験や考えをもとに構成しています • 一部 AWS Well-Architected フレームワークを参照していますが、必ずしも それに沿う内容ではありません

   AWS 以外の障害事例を含んでいます • オンプレや他クラウドの障害事例が混ざっています ◦ 何に備えて冗長化するのかをイメージするための例示です 地理冗長とは直接関係のない内容には（原則）触れません • アプリケーションのバグ・AWS ユーザ自身のオペレーションミスなど 3

4. その他 内部にデータベース等を持つ動的なサイトを前提とした話です • 静的サイトとして生成・運用できるのであれば、地理冗長も楽になります 4

5. 背景 東京リージョンの各 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

6. よくある誤解 6 AWS 障害でわが社のサービスが止まっただと？ けしからん！至急マルチクラウド化して止まらないサービス にしなさい！ AWS なら海外リージョンを使って冗長化すれば、日本で震災 が起きても止まらないシステムなんて簡単に作れるよね？ 知ってるよ。俺は詳しいんだ。

7. 地理冗長パターン選択・実装のポイント SLO・可用性目標を決める • 提供サービス別・機能別など（ビジネス価値をベースに） 発生しうる障害（リスク）を洗い出す • データセンター障害・マネージドサービス障害・広域停電・震災など RPO / RTO

   を定める • SLO・可用性目標と障害ケースに応じて（コストを考慮して）定める 地理冗長パターンを選ぶ（単一リージョン複数 AZ・マルチリージョン他） • 地理冗長で生じるリスク・デメリットも考慮する 選択した地理冗長パターン・RPO / RTO に合わせて実装する 7

8. 地理冗長と 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～109 8

9. 地理冗長と 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～109 9 P.63 推奨事項 「ワークロードの信頼性目標はほとんど、単一の AWS リージョン内でマルチ AZ 戦略を使用して満たすことが できます。マルチリージョンである必要があるワーク ロードの場合のみ、マルチリージョンアーキテクチャを ご検討ください。」

10. SLO（サービスレベル目標）・可用性目標 提供サービス（機能）の目的やビジネス価値に応じて決める • リアルタイム処理が不要な機能には、即時復旧は必要ない • ビジネス価値と不釣り合いに高いコストを掛けない RPO / RTO を決める（仮決め）

    • RPO（目標復旧時点） ◦ いつの状態に戻すか？ • RTO（目標復旧時間） ◦ 何分・何時間以内に復旧するか？ • 達成のためのコストがビジネス価値に見合うように、必要なら後で調整 10

11. リスク洗い出し : 障害事例を知る 物理障害（DC 障害など）については、オンプレ事例を参考に • クラウド利用ではイメージしづらい部分なので どの地理冗長パターンが有効な対策になり得るか • 例

    : DC 障害→単一リージョン複数 AZ パターンで回避・軽減可能 11

12. 障害事例 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.pdf 12

13. 障害事例 2 : DC 回線障害 とある会社が利用していた DC にて • 大手キャリア某社の下請け作業員が

    DC で回線敷設作業 • 作業員が誤って工具を床下に落下、床下の光ファイバーを切断 ◦ 作業員が事故を報告せずに退館したため、対処が遅れた ◦ 「とある会社」ではネットワーク障害が発生し、騒ぎに AWS の DC はもっと管理状態は良いはずだが、IDF・MDF・建物 への引き込み口周辺は回線が密集するので、事故があると全体へ の影響が大きい 13

14. 障害事例 3 : DC 火災 2013/02/25 台湾の DC で火災発生 •

    NTT コミュニケーションズ（が借りていた） DC • GMO クラウドなどもコロケーションで利用 • 地下の UPS 室で火災 参考リンク • https://tomocha.net/diary/?20130225 • http://twitpic.com/c6pf3f 14

15. 障害事例 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

16. 対策 : 複数 AZ 対応サービスの導入（例） インターネット接続の冗長化 • ELB（ALB・NLB） • API

    Gateway • Route 53（ヘルスチェック & DNS フェイルオーバー） データストア • DynamoDB • Aurora • S3 • DocumentDB 16

17. 17 例 : Aurora 複数 AZ 構成（データ読み取り） apne1-az1 Writer apne1-az2

    Reader apne1-az4 Reader ap-northeast-1 （東京） (注) 別 AZ の Reader を読みに行く 　　ケースもある（以降、同様）

18. 18 例 : Aurora 複数 AZ 構成（データ書き込み） apne1-az1 Writer apne1-az2

    Reader apne1-az4 Reader ap-northeast-1 （東京） AZ またぎのアクセスになる ↓　　　　　　　↓ 2021/03/02 追記 : Aurora Multi-Master なら Writer を 複数持てるが、機能面・性能面（特に 更新性能）での制限がある

19. 注意点 EBS • 基盤障害・AZ（DC）障害があるとよく保存データが壊れる ◦ 永続的なデータストアとして使うなら複製・バックアップ必須 RDS Multi-AZ • 障害

    AZ の復旧後、データ再同期で性能低下の可能性がある EC2 などの Auto Scaling • オートスケールには時間が掛かる（サービスによって差がある） • AZ によっては起動できないインスタンスタイプがある ELB • 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも 19 https://minne.com /items/2715511 (ekot) より

20. 注意点 EBS • 基盤障害・AZ（DC）障害があるとよく保存データが壊れる ◦ 永続的なデータストアとして使うなら複製・バックアップ必須 RDS Multi-AZ • 障害

    AZ の復旧後、データ再同期で性能低下の可能性がある EC2 などの Auto Scaling • オートスケールには時間が掛かる（サービスによって差がある） • AZ によっては起動できないインスタンスタイプがある ELB • 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも 20 https://minne.com /items/2715511 (ekot) より 2AZ で冗長化していて片方 落ちたら、オートスケール でカバーできるのか？

21. 注意点 EBS • 基盤障害・AZ（DC）障害があるとよく保存データが壊れる ◦ 永続的なデータストアとして使うなら複製・バックアップ必須 RDS Multi-AZ • 障害

    AZ の復旧後、データ再同期で性能低下の可能性がある EC2 などの Auto Scaling • オートスケールには時間が掛かる（サービスによって差がある） • AZ によっては起動できないインスタンスタイプがある ELB • 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも 21 https://minne.com /items/2715511 (ekot) より スティッキーセッションを 使っていると障害 AZ 宛て に流し続けることも

22. 障害事例 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/07931343bcb703b101f8 22

23. 障害事例 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

24. 参考事例 : 地震による広域電源障害（ブラックアウト） 2018/09/06 北海道胆振東部地震による北海道電力の全域停電 • 苫東厚真火力発電所の発電機が相次いで停止 ◦ 連鎖的に他の発電所等も停止 当時の資料

    • https://www.occto.or.jp/iinkai/hokkaido_kensho/files/181219_hokkaido_saishu_gaiyou.pdf 自家発電装置の燃料確保問題が発生すると DC 運用継続に影響 • 東日本大震災でも発生 • 優先供給契約を結んでいても、被災地域が広範囲になったり供給経路が 絶たれたりすると確保できない可能性がある 24

25. 対策 : 複数リージョン対応サービスの導入（例） インターネット接続（エッジロケーション） • CloudFront • Global Accelerator ◦

    IP Anycast によって同一 IP アドレスを各リージョンに振り分け可能 ▪ グローバルに提供するサービスに有効 データストア • DynamoDB Global Tables • Aurora Global Database • S3（クロスリージョンレプリケーション） 25

26. 例 : Global Accelerator https://aws.amazon.com/jp/global-accelerator/ より 26

27. 27 例 : Aurora Global Database（データ読み取り） apne1-az1 Writer apne1-az2 Reader

    apne1-az4 Reader ap-northeast-1 （東京） apne2-az1 Reader apne2-az2 Reader apne2-az3 Reader ap-northeast-2 （ソウル）

28. 28 例 : Aurora Global Database（データ書き込み①） apne1-az1 Writer apne1-az2 Reader

    apne1-az4 Reader ap-northeast-1 （東京） AZ またぎのアクセスになる ↓　　　　　　　↓ apne2-az1 Reader apne2-az2 Reader apne2-az3 Reader ap-northeast-2 （ソウル） リージョンまたぎのアクセスになる　 ↓　　　　↓　　　　　　　↓

29. 29 例 : Aurora Global Database（データ書き込み②） apne1-az1 Writer apne1-az2 Reader

    apne1-az4 Reader ap-northeast-1 （東京） AZ またぎのアクセスになる ↓　　　　　　　↓ apne2-az1 Reader apne2-az2 Reader apne2-az3 Reader ap-northeast-2 （ソウル） 各 Reader で書き込み転送を使用　 ↓　　　　↓　　　　　　　↓

30. マルチクラウド化は必要？ エッジロケーションのサービス（CloudFront・Global Accelerator 他） • リージョンのサービスとは別の DC で運用 ◦ オペレーションミス等での全停止が（理論上は）あり得る

    その他グローバルサービス（Route 53(※)・IAM 他） (※) パブリックゾーンの情報はエッジロケーションに配置 • こちらも理論上は全リージョン停止があり得る ◦ とはいえ、障害時にアクセス先を別クラウドへ確実に切り替えるのは難しい 国外にデータを置けないなどの制約があれば、考慮が必要に • 大阪ローカルリージョンのフルリージョン化を待つ手も 2021/03/02 追記 : 本日より、大阪リージョンはフルリージョン化！ 30

31. 31 他クラウド 上のシステム AWS上の システム （稼働率 : 99.99%） 他クラウド 上のシステム

    （稼働率 : 99.99%） インターネット （ユーザ） データ 同期 稼働率 : 99.999999%?

32. 32 他クラウド 上のシステム AWS上の システム （稼働率 : 99.99%） 他クラウド 上のシステム

    （稼働率 : 99.99%） インターネット （ユーザ） データ 同期 稼働率 : 99.999999%? ここの可用性 も考慮する 必要あり （Route 53?） ここの可用性 を考慮する 必要あり

33. 33 他クラウド 上のシステム AWS上の システム （稼働率 : 99.99%） 他クラウド 上のシステム

    （稼働率 : 99.99%） インターネット （ユーザ） データ 同期 ここの信頼性 確保も難しい （通常はインター ネット経由になる）

34. 34 他クラウド 上のシステム AWS上の システム （稼働率 : 99.99%） 他クラウド 上のシステム

    （稼働率 : 99.99%） インターネット （ユーザ） データ 同期 AWS で複数リージョン化 する以上に難しい

35. 障害ケース 影響期間 発生頻度 単一リージョン 複数 AZ 複数リージョン DC 障害 その他局所的な災害

    数時間～数日間 ～ 1 年／回 回避・軽減可能 回避・軽減可能 マネージドサービス障 害 数時間 数年／回 ×利用サービスの数 一部 回避・軽減可能 ほぼ 回避・軽減可能 インターネットの ルーティング障害 数時間 数年／回 回避・軽減できない 可能性あり 回避・軽減可能 広域電源障害・震災 不定 （なし～数か月以上） 数十年／回 回避・軽減できない 可能性あり 回避・軽減可能 障害ケースと地理冗長パターン 35

36. 障害ケース 影響期間 発生頻度 単一リージョン 複数 AZ 複数リージョン DC 障害 その他局所的な災害

    数時間～数日間 ～ 1 年／回 回避・軽減可能 回避・軽減可能 マネージドサービス障 害 数時間 数年／回 ×利用サービスの数 一部 回避・軽減可能 ほぼ 回避・軽減可能 インターネットの ルーティング障害 数時間 数年／回 回避・軽減できない 可能性あり 回避・軽減可能 広域電源障害・震災 不定 （なし～数か月以上） 数十年／回 回避・軽減できない 可能性あり 回避・軽減可能 障害ケースと地理冗長パターン 36

37. 地理冗長で生じるリスクとデメリット ネットワークの遅延とシステムの複雑化 • 距離が延びる→ネットワーク遅延増大 ◦ EC2 RTT（32 ～ 64 bytes）：

    AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms • 経由する機器・設備や組み合わせるサービスが増える→複雑化 ◦ 想定外の動作が生じやすい（スプリット・ブレインなど） 切り戻し／復旧に関するリスク • 切り戻し／復旧時に性能低下・データ破損などのトラブルも コストの増加 37 複数 AZ 化で 10 倍、 複数リージョンで 100 ～ 1,000 倍以上 の遅延が生じる

38. 地理冗長で生じるリスクとデメリット ネットワークの遅延とシステムの複雑化 • 距離が延びる→ネットワーク遅延増大 ◦ EC2 RTT（32 ～ 64 bytes）：

    AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms • 経由する機器・設備や組み合わせるサービスが増える→複雑化 ◦ 想定外の動作が生じやすい（スプリット・ブレインなど） 切り戻し／復旧に関するリスク • 切り戻し／復旧時に性能低下・データ破損などのトラブルも コストの増加 38 アプリケーションの動作が 緩慢になるだけでなく、 最悪の場合システムが停止

39. 地理冗長で生じるリスクとデメリット ネットワークの遅延とシステムの複雑化 • 距離が延びる→ネットワーク遅延増大 ◦ EC2 RTT（32 ～ 64 bytes）：

    AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms • 経由する機器・設備や組み合わせるサービスが増える→複雑化 ◦ 想定外の動作が生じやすい（スプリット・ブレインなど） 切り戻し／復旧に関するリスク • 切り戻し／復旧時に性能低下・データ破損などのトラブルも コストの増加 39 リージョン A と B の夫々で システムがバラバラに動作 してしまう

40. 地理冗長で生じるリスクとデメリット ネットワークの遅延とシステムの複雑化 • 距離が延びる→ネットワーク遅延増大 ◦ EC2 RTT（32 ～ 64 bytes）：

    AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms • 経由する機器・設備や組み合わせるサービスが増える→複雑化 ◦ 想定外の動作が生じやすい（スプリット・ブレインなど） 切り戻し／復旧に関するリスク • 切り戻し／復旧時に性能低下・データ破損などのトラブルも コストの増加 40 データ再同期による I/O の 負荷発生 再同期の失敗　など

41. 地理冗長で生じるリスクとデメリット ネットワークの遅延とシステムの複雑化 • 距離が延びる→ネットワーク遅延増大 ◦ EC2 RTT（32 ～ 64 bytes）：

    AZ 内 100μs 台／AZ 間 1ms 前後／リージョン間数 ms ～数百 ms • 経由する機器・設備や組み合わせるサービスが増える→複雑化 ◦ 想定外の動作が生じやすい（スプリット・ブレインなど） 切り戻し／復旧に関するリスク • 切り戻し／復旧時に性能低下・データ破損などのトラブルも コストの増加 41 求められるスキルの高度化 などによる潜在的なコスト の増加も含む

42. 発生リスク・デメリット 単一リージョン複数 AZ 複数リージョン ネットワーク遅延・システム複雑化 低～中 （使うサービス・実装による） 中～高 （使うサービス・実装・リージョンによる） 切り戻し／クラスタ復旧リスク

    低～中 （使うサービス・実装による） 中～高 （使うサービス・実装による） コスト増加 低～中 （使うサービス・実装による） 高 リスク・デメリットと地理冗長パターン 42

43. RTO / RPO（見直し） 全ての障害ケースに対して同一の RTO を設定する必要はない • 障害ケースによっては RTO が長くなる対策を採用するケースも

    ◦ 影響期間・発生頻度・想定される損失・対策に必要なコスト等による • そのときユーザがどんな状況下にあるのか想像することも大事 ◦ ユーザ側が利用困難な状況で、システムの無停止継続は本当に必要か？ RPO についてはデータの種類や作業コストも考慮する • 変動が少ないデータや再投入が容易なデータは、あえてバックアップデータ からの復旧を選択する手も 43

44. まとめ 具体的な障害ケースをイメージして対策を考える • どの地理冗長パターンで対処できるか？ ◦ 過去の AWS 東京リージョン障害事例では、マルチクラウド化が必要なケースは （国外にデータを保管できないケースを除いて）なかった 対策によって生じるリスクやデメリットにも目を向ける

    • ネットワーク遅延とシステムの複雑性が上がると新たなリスクが生じる • 切り戻し／復旧のリスクにも気をつける ビジネス価値に見合った対策を行う • 障害ケースや提供サービス別の RTO / RPO を考える（コストを考慮して） 44

45. よくある誤解への回答 45 AWS 障害でわが社のサービスが止まっただと？ けしからん！至急マルチクラウド化して止まらないサービス にしなさい！ AWS なら海外リージョンを使って冗長化すれば、日本で震災 が起きても止まらないシステムなんて簡単に作れるよね？ 知ってるよ。俺は詳しいんだ。

    過去の AWS 東京リージョンの障害で、対策にマルチクラウド化が 必要なケースはほぼなかった。 AWS はリージョンの独立性が高いので、障害対策のためのマルチ クラウド化が必要なケースはかなり限定される。

46. よくある誤解への回答 46 AWS 障害でわが社のサービスが止まっただと？ けしからん！至急マルチクラウド化して止まらないサービス にしなさい！ AWS なら海外リージョンを使って冗長化すれば、日本で震災 が起きても止まらないシステムなんて簡単に作れるよね？ 知ってるよ。俺は詳しいんだ。

    AWS で複数リージョンにまたがるシステムを構築すること自体は さほど難しくはないが、安定性・信頼性を損なうことなく運用が 可能で、かつビジネス価値に見合うコストでシステムを構築する のは難しい。