tcpdump で追う Datastream 障害調査と Transit Gateway × VPN のリアーキテクチャ設計

Transcript

1. 徳富 博（プラットフォームエンジニアリングチーム） tcpdump で追う Datastream 障害調査と Transit Gateway × VPN のリアーキテクチャ設 計 @yannKazu1 The SRE Backlog: 蔵出し事例共有会
2. 自己紹介
3. 自己紹介 徳富 博 - 所属: タイミー プラットフォームエンジニアリング チーム - 好きな技術: Go, Ruby, TypeScript, AWS, GCP… - 野菜を育ててます
4. 今日お話しすること 1 Datastream の障害をテーマに、tcpdumpを使った調査方法から再発防止のためのリアーキテクチャ設計、さらにはリ アーキテクチャに伴い新たに追加した AWS アカウントの Organizations OU 設計まで。現場のトラブル対応からクラウ ド設計へ、レイヤーを上げながら実際に悩んだこと・学んだことをお話しします。 Part 1 障害調査編 Datastream のレプリケーション停止。 Datastream 側のエラーは接続エラー だけ。SG もルートテーブルもシロ。 tcpdump でパ ケットを見に行って、ようやく原因に辿り着いた話。 Part 2 リアーキテクチャ編 踏み台 EC2 を廃止したい。VPN + Writer 直指定、CDC 専用レプリカ + GTID、NLB + Lambda の 3 案を検討。Aurora 固有 の制約にぶつかりながら設計を詰めた過程。 Part 3 Org 設計編 Transit Gateway を置くアカウントをどうするか。 AWS Whitepaper の推奨と、stg/prod のネットワーク経路分離の不安。 hub = 経路管理 / network = ポリシー管理という整理に至った経緯。
5. PART 1 障害調査編 tcpdump で SSH トンネル断を追った話
6. ある朝、データ基盤連携が止まっていた 2 3月16日の朝、Aurora MySQL → BigQuery へのレプリケーション（GCP Datastream）が停止していた。 さらに遡ると、障害の発生は 3/14（土）。3/14 は休日だった。 3/14（土） 障害発生。休日のため対応者が不在 3/16 朝 アラートで発覚 調査開始 Datastream のレプリケーション停止を確認、調査に着手 データが送られてこない場合のアラート自体は設定されていたが、 休日だったこともあり、営業日の確認まで検知が遅れた。
7. 障害時の構成： Datastream 3 当時の構成はこうだった。 Aurora はプライベート IP しか持たないので、パブリック IP 付きの踏み台 EC2 を経由して GCP と通信する構成。Datastream は SSH tunnelで Bastion を通り、Aurora に接続していた。 Aurora MySQL Private IP → EC2 Bastion SSH tunnel port xxxx → GCP Datastream CDC → BigQuery 分析基盤 この SSH tunnel が、静かに停止していた。
8. Datastream の仕組み：バックフィルと CDC 3-1 この構成で Datastream がどうやってデータを同期しているかを先に整理しておく。 大きく2つのフェーズがあり、binlog が鍵になる。 1 初回：バックフィル テーブルの全データを SELECT して BigQuery にコピーする。 初回接続時や、ストリーム再構築時に 実行される。データ量が多いと 時間がかかる 2 継続：CDC（binlog） バックフィル完了後は MySQL の binlog（変更ログ）を読み取って 差分だけを BigQuery に反映する。 binlog が失われると CDC が中断し、 再度バックフィルが必要になる。 つまり SSH トンネルが切れると接続が断絶し、 再接続を試みても SSH が使えなければエラーになる。 — これにより連携(CDC)が停止していた。 ref: cloud.google.com/datastream/docs/ssh-tunnel
9. 最初に疑ったもの、全部シロだった 4 Datastream 側のエラーログには「接続エラー」が出ていた。 まずはネットワーク周りを順番に確認していった。でも、全部シロだった。 GCPとAWS ネットワーク周りの確認 インバウンドルールは許可済み。 GCP の IP レンジも正しく設定されていた。 ルートテーブルも問題なし。 awsのネットワーク 周りは完全にシロだった。 問題なし EC2 インスタンス自体 起動中。CPU / Memory の異常なし。ネットワークインターフェースも正常。 reachability check も OK。 インスタンスの状態だけ見れば何も異常がない。 問題なし 「ネットワーク設定的には通っているはずなのに、なぜ 接続エラーなのか…」 ここで発想を切り替えた。通信経路ではなく、パケットを見よう。
10. 「推測するな、観測せよ」 — tcpdump の出番 5 SG もルートテーブルも正しいなら、次にやるべきことは実際のパケットを見ること。 設定レイヤーの確認では「問題ない」としか言えない。実際にパケットが EC2 まで届いているのか、 届いた後にどう処理されているのかを tcpdump で直接観測した。 $ tcpdump -i eth0 port 22 IP gcp-proxy.xxxxx > bastion.22: Flags [S], seq ... IP bastion.22 > gcp-proxy.xxxxx: Flags [R.], seq ... SYN パケットは EC2 まで到達 ネットワーク経路は生きている RST（リセット）が返されている EC2 側で接続を拒否している
11. 補足：tcpdump の読み方 5-1 tcpdump はネットワークインターフェースを流れるパケットをリアルタイムにキャプチャするツール。 設定ファイルの確認では見えない「実際に何が起きているか」をパケットレベルで観測できる。 IP 送信元.ポート > 宛先.ポート: Flags [フラグ], seq 番号, ... TCP フラグの意味 — これが読めれば「何が起きているか」がわかる： [S] SYN 接続要求。「つなぎたい」という最初のパケット。これが届いていればネットワーク経路は生きている。 [S.] SYN-ACK 接続要求の承認。「OK、つないでいいよ」という応答。正常な接続確立の 2 番目のパケット。 [R.] RST 接続拒否。「つなげません」という拒否。対象ポートを listen しているプロセスがいないとき OS が返す。 [F.] FIN 接続終了。「通信を終わります」という正常な切断。 今回は SYN が届いたのに RST が返っている → 経路は OK だが、接続拒否が行われている
12. sshd が IPv4 を listen していない 6 パケットは届いている。でも RST が返る。つまり EC2 上で port 22を listen しているプロセスがいない可能性が高そ う。 そこで sshd の状態を確認した。 $ ss -tlnp | grep 22 LISTEN 0 128 [::]:22 [::]:* ← IPv6 のみ！ IPv6（[::]:22）だけが listen されていて、IPv4 の listen がない。 Datastream は IPv4 経由で SSH tunnel を張っているので、接続先プロセスがいない状態。 だからパケットは届くが RST で弾かれていた。 なぜ突然 IPv4 の listen が消えたのか？ → 次のスライドで深掘り
13. 原因：Ubuntu 24.04 の ssh.socket 変更 7 この Bastion は Ubuntu 24.04 で動いていた。調べていくと、 unattended-upgrades が openssh-server を自動更新 していたことがわかった。そして Ubuntu 24.04 では、sshd の起動方式が根本的に変わっている。 Ubuntu 22.04 まで sshd.service がデーモンを直接起動する方式。 /etc/ssh/sshd_config の ListenAddress に従って IPv4 / IPv6 両方を listen する。 設定ファイルがそのまま反映される、素直な挙動。 Ubuntu 24.04 から ssh.socket（systemd socket activation）がデフォルト。 sshd_config の ListenAddress ではなく、 ssh.socket の ListenStream 設定を使う。 つまり sshd_config をではなくssh.socket のListenStream 設定が反映されてしまい IPv6 のみをlisten するようになっ てしまった openssh-server パッケージが自動更新 → ssh.socket が再起動 → ListenStream に IPv4 が含まれていない → IPv6 only でバインド → Datastream（IPv4）の接続が RST される 修正: /etc/systemd/system/ssh.socket.d/override.conf → ListenStream=0.0.0.0:2200
14. 図解：なぜ IPv4 の listen が消えたか 8 1 unattended-upgrades が openssh-server を 自動更新 → 2 パッケージ更新に伴い ssh.socket が restart される → 3 ssh.socket の ListenStream に IPv4 が未設定 → 4 IPv6 only で listen Datastream(IPv4) は RST される 22.04 → 24.04 で sshd の起動方式が変わったことを知らなければ、この問題には気づけない。 OS のメジャーバージョンアップは「パッケージの更新」ではなく「アーキテクチャの変更」を伴うことがある。 tcpdump → ss → systemd と、下のレイヤーから順に追ったことで原因に辿り着けた。
15. 補足：unattended-upgrades とは 8-1 Ubuntu に標準搭載されている自動セキュリティアップデートの仕組み。 サーバー管理者が手動でパッチを当てなくても、セキュリティ修正が自動適用される。 便利な反面、今回のように意図しないパッケージ更新が行われるリスクがある。 定期実行 systemd timer が 毎日自動で起動 （デフォルト有効） → パッケージ確認 セキュリティ アップデートがある パッケージを検出 → 自動更新 対象パッケージを ダウンロード & インストール → サービス再起動 更新されたサービスを 自動で再起動 （ssh.socket 等） 今回は openssh-server がセキュリティアップデートの対象になり、自動更新 → ssh.socket 再起動 → IPv4 の listen が消える、という流れで障害が発生した。 対策: /etc/apt/apt.conf.d/50unattended-upgrades の Blacklist に openssh-server を追加
16. SSHは復旧したが .....
17. 障害時の binlog 状況 8-4 SSH の設定を修正して Datastream の接続経路は復旧できた。しかし、ストリームは再開できなかった。 なぜ復旧に 11 日もかかったのか？ 障害時の Aurora binlog 保持期間 CALL mysql.rds_set_configuration('binlog retention hours', 24); — つまり 1日（24時間） 何が起きたか 3/14 障害発生。Datastream の CDC が binlog を読めなくなる 〜3/16 binlog 保持期間（24時間）が経過。Aurora MySQL の binlog ファイルが自動削除される SSH を修正し Datastream の「連携再開」を試みるが、 binlog ポジションが既に存在しないため失敗 結果：ストリームの再構築 + full backfill が必要に → 復旧まで数日必要になる binlog 保持期間が1日だったため、発見時にはファイルが消えていた …というのが状況的な推測。 正確にはストリーム再開失敗の真因は不明（ Datastream 内部のエラー）だが、 binlog 喪失が原因と考えている。
18. 検知遅延の分析 — 休日 × binlog 保持期間 10 sshd の IPv4 listen を復旧すること自体はすぐ終わった。問題はそこではなかった。 休日だったこともあり検知が遅れた結果、 Aurora の binlog ポジションが失われていた。 binlog 保持期間内に気づけていたら 差分再開で数分〜数十分で復旧できた。full backfill は不要だった。 binlog 保持期間を超えてしまった現実 binlog ポジション喪失 → Datastream の「連携再開」が内部エラーで失敗 → full backfill が必要 → Aurora Writer への負荷を考慮してスループット制限 → 復旧まで11日 → 障害を受けてbinlog保持期間の延長を行ってます。
19. ここまでが「何が起きていたか」 ここからは検知・特定・対処を分解して振り返る
20. 障害対応の振り返りでは MTTR だけでなく、検知・特定・対処開始まで分解して分析することが重要。どのフェーズにボト ルネックがあったかで、改善策がまったく変わるからだ 。 MTTD Mean Time To Detect 障害発生から検知までの時 間 MTTI Mean Time To Identify 検知から原因特定までの時 間 MTTA Mean Time To Act 原因特定から対処開始まで の時間 MTTR Mean Time To Recover 対処開始から復旧完了まで の時間 障害発生 復旧完了 MTTR（復旧時間）= MTTD + MTTI + MTTA + 復旧作業 MTTR が長い原因は「復旧が遅い」とは限らない。検知が遅いのか、特定に時間がかかったのかを分解して初めて正しい改善策が見える。 次のスライドでは、今回のインシデントを各フェーズに分解して振り返る。 MTTD / MTTI / MTTA / MTTR とは
21. MTTD / MTTI / MTTA / MTTR で振り返る 9 MTTD（検知） 約32時間 休日（土曜）に発生したため、翌営業日の朝まで検知が遅れた。データ欠損アラートはあったが休日体制で対応が遅延。 MTTI（特定） 比較的短い tcpdump → ss → systemd と順に追い、socket activation の問題を特定。低レイヤーの切り分けが効いた。 MTTA（対処開始） MTTD に律速 原因特定後の対処着手は早かった。ボトルネックは検知フェーズ。 MTTR（復旧） 11日 検知遅延の間に binlog ポジションが喪失。full backfill が必要となり、Writer 負荷を考慮してスループット制限。 MTTR だけ見ると「11日もかかった」だが、分解すると MTTD がボトルネックだったことがわかる。 改善策は「復旧を速くする」ではなく「検知を速くする」に集中すべき構造だった。
22. ここまでの対応（暫定） ✓ binlog 保持期間の延長 検知が遅れても binlog が消えないよう猶予を確保 ✓ 休日アラート体制の見直し MTTD 短縮のため検知フローを改善 しかしこれらは「次に同じことが起きたとき被害を小さくする」対策にすぎない。 踏み台 EC2 を経由する構成自体、そして Aurora 固有の制約への対処など、根本的な設計を見直す必要がある。 ▼ PART 2 リアーキテクチャ編 踏み台 EC2 を廃止する設計判断と Aurora 固有の制約
23. PART 2 リアーキテクチャ編 踏み台 EC2 を廃止する設計判断と Aurora 固有の制約
24. 踏み台 EC2、2回目はない 11 実は 2024年8月にも Bastion 起因の類似障害が発生していた。今回で 2回目。 パッチ（unattended-upgrades 除外、ssh.socket 明示設定）で一時対応はしたが、 パッチを当て続ける運用には限界がある。構造的な問題に向き合う必要があった。 SPOF 全てのレプリケーション通信が特定の EC2 1台に依存。この EC2 が死ぬとデータ連携が全停止する。 OS レイヤーの運用負荷 普段マネージドサービスを扱うチームにとって、 sshd や systemd のトラブルシューティングは難易度が高い。属人化しやすい。 セキュリティリスク EC2 にパブリック IP を付与し、OS パッチの管理が必要。 GCP マネージド IP の許可リスト登録で、他社 GCP 環境からのリス クもゼロではない。 「踏み台を廃止して、マネージドサービスで接続する構成にしたい」 → AWS-GCP 間を HA VPN（IPsec）で直接つなぐ方向で検討を開始した。
25. HA VPN とは 11-1 踏み台 EC2 を廃止する代替手段として、 GCP と AWS の間に VPN トンネルを張る。 IPsec で暗号化されたトンネルを通じて、 GCP から AWS のプライベート IP に直接アクセスできるようになる。 IPsec（Internet Protocol Security）とは インターネット上に暗号化されたトンネルを構築するプロトコル。通信内容は暗号化され、 パブリック IP を持つ踏み台を経由せずに、プライベートネットワーク同士を安全に接続できる。 GCP と AWS で VPN を構成するコンポーネント： GCP 側 HA VPN Gateway → Cloud Router (BGP) 外部 IP を 2つ持ち、各 IP から AWS 側に IPsec トンネルを張る。 Cloud Router が BGP でルートを交換。 AWS 側 Customer Gateway → VPN Connection GCP の外部 IP を Customer Gateway に登録。 VPN Connection が IPsec トンネルを確立。 各 Connection は Tunnel 1/2 の 2本を持つ。 ── IPsec ──
26. VPN で何が変わるか — Private IP 直接接続 11-2 Before：踏み台 EC2 経由 Datastream → Bastion EC2 (Public IP) → Aurora (Private IP) インターネット経由。 Bastion の SSH tunnel を通って Aurora に接続。Bastion が SPOF。 Bastion に障害が起きると通信が完全停止する。 After：HA VPN 経由 Datastream → HA VPN (IPsec) → Aurora (Private IP) プライベート通信のみ。 VPN で暗号化されたトンネル。 Bastion 不要。マネージドサービスで完結。 Datastream から Aurora の Private IP に直接接続できる。 VPN を使えば Datastream から Aurora の Private IP に直接接続できる — Bastion は不要になる ただし、新たな問題が発生する Datastreamの仕様でprivate connectionを利用する場合 は接続先を IP アドレスで直接指定する必要がある（ DNS 不可）。 Aurora Writer の IP はフェイルオーバーで変わる。 → フェイルオーバー時にどうするか？ (今まではWriter の IPをDNSで指定してい た)
27. 設計方針：最もシンプルな構成から潰す 12 リアーキテクチャの設計では「最もシンプルな構成から始めて、制約を 1つずつ潰していく」方針を取った。 最初から複雑な構成を選ぶのではなく、シンプルな案がなぜダメなのかを明確にしてから次の案に進む。 このプロセスで Aurora 固有の制約を発見し、最終的な設計判断に至った。 A HA VPN + Writer IP 直指定 最もシンプル。だがフェイルオーバーで IP が変わる → 不採用 不採用 B HA VPN + CDC 専用レプリカ + GTID IP 不変 + GTID で連続性確保。完璧に見えたが Aurora の制約で不可 実現不可 C HA VPN + NLB + Lambda NLB の固定 IP + Lambda による自動ターゲット切替。唯一の現実解 採用
28. 選択肢 A：HA VPN + Writer IP 直指定 13 まず最もシンプルな構成を検討した。 VPN でプライベートネットワークを繋ぎ、 Datastream から Aurora Writer のプライ ベート IP を直接指定する。NLB も Lambda も不要で、管理コンポーネントが最小になる。 しかし2つの問題があった 問題① Datastream の Private Connectivity では DNS 解決ができない GCP 公式ドキュメントに明記されている。 Aurora Writer エンドポイント（DNS名）は使えず、IP アドレスの直指定が必須。 問題② Aurora Writer の IP はフェイルオーバーで変わる Writer の IP はフェイルオーバー時に変わるため、 IP 直指定ではフェイルオーバーのたびに手動での IP更新が必要になる。 選択肢 A の課題まとめ この構成では、Aurora Writer の IP がフェイルオーバーのたびに変わってしまい、その都度 Datastream 側の接続先 IP を手動で更新 しなければならない。これは運用上現実的ではない。 そこで、「Datastream から見た接続先 IP を固定できれば、この問題は解消できるのでは？」 という発想をもとに、次の選択肢を検討 していく。 ref: cloud.google.com/datastream/docs/create-a-private-connectivity-configuration
29. B案に行く前に binlogレプリケーションの 2方式を整 理しておく 14-1 そもそも binlog を使ったレプリケーションには 2つの方式がある。 方式① ポジションベース binlog ファイル名 + 位置（offset）で 「どこまで読んだか」を管理する。 ファイルが消えると位置がわからなくなり レプリケーションが中断する。 ライターインスタンスしかターゲットに指定できない mysql-bin.000042: pos 12345 方式② GTID ベース Global Transaction ID で 「どのトランザクションまで適用したか」を管理。 ファイル位置に依存しないので 任意のリーダーインスタンスをターゲットに指定できる GTID: 3E11FA47:1-42 （TX 42 まで完了） ※ MySQL 8.4 では GTID が必須に ただし、どちらの方式でも CDC ソースには binlog 自体が必要。 GTID は「位置の指し方」を変えるだけ。
30. 選択肢 B：HA VPN + CDC 専用レプリカ + GTID 14 Aurora のリードレプリカはフェイルオーバーが起きても自身の IP は変わらない。tier 15(tireは昇格優先順位) に設定 すれば昇格リスクも排除できる。 GTID ベース CDC なら、レプリカ経由でもトランザクションの連続性を追跡可能。 GCP 公式もリードレプリカ経由を推奨している。「完璧に見えた」。 ✓ リードレプリカの IP はフェイルオーバーで変わらない ✓ tier 15 で昇格リスクを排除 ✓ GTID でトランザクション連続性を追跡可能 ✓ GCP 公式もリードレプリカ経由の CDC を推奨 しかし、 Auroraのレプリカには binlogがないことが判明し、実現不可だった → 次のスライドへ ref: cloud.google.com/datastream/docs/sources-mysql#mysqlbestpractices
31. Aurora のレプリカには binlog がない 15 一般的な MySQL とは根本的にアーキテクチャが異なる。ここが落とし穴だった。 一般的な MySQL Writer binlog 書込 binlog → → Replica binlog有 Local Storage Local Storage ✓ Replica にも binlog あり → CDC ソースにできる Aurora MySQL Writer binlog 有 Replica binlog 無 共有クラスターボリューム（redo log） ↓書込 ↑読取 ✕ Replica に binlog なし → CDC ソースにできない Aurora は Volume 共有のアーキテクチャ。レプリカは redo log を直接読むため binlog を経由しない。 GTID ベースでも Datastream のソースにできない。選択肢 B は実現不可能だった。 ref: docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html
32. 選択肢 C：HA VPN + NLB + Lambda（採用） 16 Writer の IP は変わる。レプリカは CDC ソースにできない。 ならば「固定 IP を持つ中間コンポーネントを手前に置く」のが唯一の現実解。 NLB（Network Load Balancer）に固定プライベート IP を割り当て、Datastream の接続先にする。 フェイルオーバー時は Lambda が NLB のターゲットを新 Writer に自動切替する。 Datastream → HA VPN → NLB (固定 IP) → Aurora Writer フェイルオーバー自動切替：EventBridge(RDS-EVENT-0073) → Lambda → NLB ターゲット切替 全体で約60秒で自動復旧。Datastream は同じ固定 IP に繋ぎ続ける。 注意点：NLB TCP idle timeout NLB の TCP idle timeout はデフォルト 350秒（2024年9月より 60〜6000秒に変更可能）。 Datastream keepalive < NLB timeout < Aurora wait_timeout となるようチューニングが必要。 ref: aws.amazon.com/about-aws/whats-new/2024/09/aws-network-load-balancer-tcp-idle-timeout/
33. 選択肢の振り返り 17 選択肢 接続先 FO 耐性 複雑性 判定 A Writer IP ❌ 手動対応 低 不採用 B レプリカ + GTID —（実現不可） 低 Aurora 制約 C（採用） NLB 固定 IP ✅ 自動切替 中 ✅ 採用 「シンプルな構成から順に検討し、各案がなぜダメなのかを明確にした上で、 最終的に NLB + Lambda という構成を選択した。 運用複雑性は増すが、Aurora の制約を回避できる唯一の現実解だった。」
34. 全体構成図（完成形） 23 GCP Datastream プロキシ 10.3.0.0/29 HA VPN Gateway interface 0 / 1 Cloud Router ASN: 65001/65002 advertise: 10.3.0.0/29 Datastream v3 → BigQuery IPsec / BGP 計 4 トンネル ←→ 　　新設アカウント AWS: network-hub-stg/prod VPN Connection 0 Tunnel 1 / Tunnel 2 VPN Connection 1 Tunnel 1 / Tunnel 2 Transit Gateway ASN: 64512 ↓ RAM 共有 → AWS: service stg/prod TGW VPC Attachment NLB 固定プライベート IP (TCP:3306) Aurora Writer Lambda + EventBridge (FO 時 NLB ターゲット自動切替 ) ↓ ↓ 通常時 ターゲット IP 切替 ↑ Private Connection (VPN 経由) 接続先: NLB 固定 IP
35. PART 3 Org 設計とネットワーク分離編 Transit Gateway をどこに置くか — アカウント設計の検討過程
36. Transit Gateway をどこに置くか 18 今回の構成は3種類のアカウントに跨がる。 TGW をサービスアカウントに置くと責務が混ざるため、 ネットワークの「ハブ」としての専用アカウントを新規に作成した。 RAM（Resource Access Manager）で TGW をサービスアカウントに共有し、 Attachment するだけで利用できるように する。 GCP Datastream HA VPN Gateway Cloud Router AWS hub アカウント Transit Gateway VPN Connection （新規作成） AWS service アカウント Aurora + NLB Lambda + EventBridge (timee-jp-prod/stg) ← HA VPN (IPsec/BGP) → ← RAM 共有 / TGW Attach → 将来、別のアカウント（IdP 等）を追加する場合も、hub 側で RAM 共有を追加するだけ。 GCP 側の HA VPN / Cloud Router は変更不要。
37. AWS Whitepaper を読み解く 19 弊社の AWS Organizations の OU 設計は Whitepaper に沿って構成されている。 TGW を置くアカウントの設計にあたり、改めて Whitepaper の Infrastructure OU セクションを確認した。 最初に読んだ記述（基本構成） 一般的に、インフラストラクチャ組織単位（ OU）内に、これらのアカウントの 本番用と非本番用のバリエーションを設けるのは合理的ではありません。 (翻訳) → 「分けなくていい」と読めて、 stg/prod 分離に迷った よく読むと拡張構成で分離が推奨されていた 本番環境のワークロードとリソースを、本番環境以外の環境から分離するために、 「Prod」および「Test」の子OUを使用することが推奨されます。 network-prod アカウントには、 安定した本番環境レベルのネットワーク機能が含まれています。 (翻訳) → Prod / Test の子 OU を作り network-prod / network-test を分けることも推奨されていた Whitepaper の拡張構成パターンに沿って、stg / prod でネットワークアカウントを分離する方針に決定。 次のスライドで具体的なアカウント命名と責務分担を説明する。 出典: docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/infrastructure-ou.html
38. 設計判断： hub という命名で責務を限定する 20 Whitepaper の拡張構成に沿って stg / prod 分離は決まった。 次に考えたのは「このアカウントに何を置くか」の責務設計。 Whitepaper の network-prod は広い責務を想定しているが、今回は TGW + VPN に限定したかった。 なぜ「network」ではなく「network-hub」にしたか Whitepaper の「network-prod」はネットワーク全般（ Firewall Manager, DNS Firewall 等）を含む広い責務。 今回必要なのは TGW + VPN Connection だけ。「hub」を名前に入れることで責務を明確に限定した。 将来 Firewall Manager 等の Org 全体に適用するネットワーク設定が必要になった場合は、 別途「network」アカウント（ポリシー管理）を作るという設計方針。 hub = 経路管理（ TGW / VPN / ルーティング） → env ごとに分離 network = ポリシー管理（ Firewall Manager 等）→ 将来必要になったら Org 全体で1つ 「Whitepaper の拡張構成パターンに沿いつつ、hub という命名で責務を限定する」 という判断に至った。推奨構成を理解した上で、自分たちの現在のスコープに合わせた設計。
39. 着地：アカウント構成 21 Whitepaper の拡張構成パターンに沿いつつ、 hub という命名で責務を TGW + VPN に限定した。 hub（経路管理） env ごとに分離（Whitepaper 拡張構成準拠） network-hub-prod network-hub-stg 責務：TGW / VPN Connection / ルーティング network（ポリシー管理） 将来必要になったら Org 全体で1つ作る network 責務：Firewall Manager / DNS Firewall 等 Org 全体にばら撒く設定を管理 Whitepaper の推奨構成を理解した上で、自分たちのスコープに合わせた命名と責務分担。 推奨に沿いつつ、将来の拡張にも対応できる設計にした。
40. まとめ 24 01 MTTD / MTTI / MTTA で障害を分解する MTTR だけ見ると「11日」だが、分解すると MTTD がボトルネック。休日で検知が遅れたことと binlog 喪失が連鎖した。 改善策は「復旧を速くする」ではなく「検知を速くする」に集中すべきだった。 02 tcpdump という基本 「ネットワークか、プロセスか」を切り分ける低レイヤーの技術は、クラウド時代でも強力な武器になる。 「推測するな、観測せよ」。 03 「シンプルな案から潰す」設計プロセス Aurora の binlog 不在は、実際に検討しないとわからなかった。一般的な MySQL の常識が通用しないケースがある。 最初から複雑な構成を選ぶのではなく、なぜダメかを明確にしてから次へ進む。 04 Whitepaper を読み解いて設計に活かす 基本構成の記述で迷ったが、拡張構成で分離パターンが推奨されていた。 推奨構成を理解した上で、 hub という命名で責務を限定する設計に落とし込んだ。
41. ありがとうございました ご質問・ご感想お待ちしています @yannKazu1