Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
システムの地理冗長を考える(2021/02 版)
Search
hmatsu47
PRO
February 26, 2021
Technology
6
1.9k
システムの地理冗長を考える(2021/02 版)
JAWS-UG 浜松 AWS 勉強会 2021#2 2021/02/26
hmatsu47
PRO
February 26, 2021
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
大吉祥寺.pm の LT で ChatGPT の力を借りて Next.js App Router ベースの投句箱を作って、 Lambda Web Adapter を使って公開した話
hmatsu47
PRO
0
2
ある日突然 DB の性能が 1/2(サイズのインスタンス相当)になった話
hmatsu47
PRO
0
24
pgvectorscale と pgai の話(ざっくり)
hmatsu47
PRO
0
28
pgvector 0.7.0 の新機能と、これから来る(かもしれない)pgvectorscale
hmatsu47
PRO
0
19
大人の社会科見学 ~ NTT 技術史料館に行ってみよう!
hmatsu47
PRO
0
380
pgvector 0.6.0 以降の進化についてざっくり取り上げてみる
hmatsu47
PRO
0
49
Cloudflare Workes からMySQL 系 DB への接続事情(2024/4 現在)
hmatsu47
PRO
0
99
BuriKaigi2024 にボランティアスタッフとして参加した話
hmatsu47
PRO
0
69
Aurora MySQL と Redshift の zero-ETL 統合のフィルター機能を試してみた
hmatsu47
PRO
0
130
Other Decks in Technology
See All in Technology
PREEMPT_RT over the years
ennael
PRO
0
330
【shownet.conf_】多様化するネットワーク環境を柔軟に統合するルーティングテクノロジー
shownet
PRO
0
330
「ばん・さく・つき・たー!」にならないためにSHIROBAKOから 学んだこと
ysknsid25
3
580
Hazard pointers with reference counter
ennael
PRO
0
120
[JAWS-UG GameTech] 第6回 各種事例紹介_18TRIPにおけるAWSサービスを活用した負荷テスト・障害テスト
naoto_yasuda
0
130
【shownet.conf_】ShowNet伝送改めShowNet APN 2024
shownet
PRO
0
380
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
2
200
【swonet.conf_】NOCメンバーが語るSTMの実態!! ~ShowNetから若者への贈り物~
shownet
PRO
0
270
Understanding and Optimising INP
akshayysharma
0
150
RAGの性能を評価しよう
kurahara
1
300
Low Latency Join Method for Distributed DBMS
yugabytejapan
0
120
【shownet.conf_】ローカル5Gを活用したウォーキングツアーの体感向上
shownet
PRO
0
290
Featured
See All Featured
Writing Fast Ruby
sferik
625
60k
Designing for humans not robots
tammielis
249
25k
Clear Off the Table
cherdarchuk
91
320k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Adopting Sorbet at Scale
ufuk
73
8.9k
Building Adaptive Systems
keathley
37
2.1k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Mobile First: as difficult as doing things right
swwweet
222
8.8k
Large-scale JavaScript Application Architecture
addyosmani
509
110k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
Building an army of robots
kneath
302
42k
Web Components: a chance to create the future
zenorocha
310
42k
Transcript
システムの地理冗長を考える (2021/02 版) JAWS-UG 浜松 AWS 勉強会 2021#2 2021/02/26 まつひさ(hmatsu47)
自己紹介 松久裕保(@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
よくある誤解 6 AWS 障害でわが社のサービスが止まっただと? けしからん!至急マルチクラウド化して止まらないサービス にしなさい! 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~109 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 9 P.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.pdf 12
障害事例 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/c6pf3f 14
障害事例 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 • DocumentDB 16
17 例 : Aurora 複数 AZ 構成(データ読み取り) apne1-az1 Writer apne1-az2
Reader apne1-az4 Reader ap-northeast-1 (東京) (注) 別 AZ の Reader を読みに行く ケースもある(以降、同様)
18 例 : Aurora 複数 AZ 構成(データ書き込み) apne1-az1 Writer apne1-az2
Reader apne1-az4 Reader ap-northeast-1 (東京) AZ またぎのアクセスになる ↓ ↓ 2021/03/02 追記 : Aurora Multi-Master なら Writer を 複数持てるが、機能面・性能面(特に 更新性能)での制限がある
注意点 EBS • 基盤障害・AZ(DC)障害があるとよく保存データが壊れる ◦ 永続的なデータストアとして使うなら複製・バックアップ必須 RDS Multi-AZ • 障害
AZ の復旧後、データ再同期で性能低下の可能性がある EC2 などの Auto Scaling • オートスケールには時間が掛かる(サービスによって差がある) • AZ によっては起動できないインスタンスタイプがある ELB • 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも 19 https://minne.com /items/2715511 (ekot) より
注意点 EBS • 基盤障害・AZ(DC)障害があるとよく保存データが壊れる ◦ 永続的なデータストアとして使うなら複製・バックアップ必須 RDS Multi-AZ • 障害
AZ の復旧後、データ再同期で性能低下の可能性がある EC2 などの Auto Scaling • オートスケールには時間が掛かる(サービスによって差がある) • AZ によっては起動できないインスタンスタイプがある ELB • 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも 20 https://minne.com /items/2715511 (ekot) より 2AZ で冗長化していて片方 落ちたら、オートスケール でカバーできるのか?
注意点 EBS • 基盤障害・AZ(DC)障害があるとよく保存データが壊れる ◦ 永続的なデータストアとして使うなら複製・バックアップ必須 RDS Multi-AZ • 障害
AZ の復旧後、データ再同期で性能低下の可能性がある EC2 などの Auto Scaling • オートスケールには時間が掛かる(サービスによって差がある) • AZ によっては起動できないインスタンスタイプがある ELB • 障害が発生した AZ のサブネットを手動で切り離す必要があるケースも 21 https://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/07931343bcb703b101f8 22
障害事例 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 Accelerator https://aws.amazon.com/jp/global-accelerator/ より 26
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 例 : 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 例 : 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 で書き込み転送を使用 ↓ ↓ ↓
マルチクラウド化は必要? エッジロケーションのサービス(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
よくある誤解への回答 45 AWS 障害でわが社のサービスが止まっただと? けしからん!至急マルチクラウド化して止まらないサービス にしなさい! AWS なら海外リージョンを使って冗長化すれば、日本で震災 が起きても止まらないシステムなんて簡単に作れるよね? 知ってるよ。俺は詳しいんだ。
過去の AWS 東京リージョンの障害で、対策にマルチクラウド化が 必要なケースはほぼなかった。 AWS はリージョンの独立性が高いので、障害対策のためのマルチ クラウド化が必要なケースはかなり限定される。
よくある誤解への回答 46 AWS 障害でわが社のサービスが止まっただと? けしからん!至急マルチクラウド化して止まらないサービス にしなさい! AWS なら海外リージョンを使って冗長化すれば、日本で震災 が起きても止まらないシステムなんて簡単に作れるよね? 知ってるよ。俺は詳しいんだ。
AWS で複数リージョンにまたがるシステムを構築すること自体は さほど難しくはないが、安定性・信頼性を損なうことなく運用が 可能で、かつビジネス価値に見合うコストでシステムを構築する のは難しい。