解消したはずが…技術と人間のエラーが交錯する恐怖体験

Transcript

1. 画像は Gemini 2.5 Flash で作成した サーバーのお化けです。
2. 自己紹介 赤池 悠 (あかいけ はるか) 　1998/07/29生まれ 所属：クラスメソッド株式会社 　　　クラウド事業本部コンサルティング部 ブログ：https://dev.classmethod.jp/author/akaike/ Twitter：@lamaglama39 最近怖かった出来事： 自宅のProxmoxクラスターが突然めっちゃ不安定になっ て、私の心も不安定になりました。 （再起動したら直りました）
3. これは前職で私が 
 実際に経験したお話しです…。
4. 私が担当していたシステム、および環境 • Direct Connectでの オンプレミス ↔ AWS 接続 • 複数システム共通VPC + AWSサービス別サブネット
5. その日私がやっていた作業 • 新規システム用のDirect Connect + AWSリソースの作成作業 • 人生初Direct Connectに胸を躍らせる
6. 起きた事件。
7. それは唐突に起きました。 私が作業を完了させてから約 1時間後に既存のDirectConnectが突如ダウンし、 オンプレから既存システムへの通信がすべてダウン …。
8. それは唐突に起きました。 • 障害状況 ◦ 既存DirectConnectのステータスがダウン ◦ オンプレから既存システムへの疎通NG • 騒然とする現場 ◦ 大量の障害検知に対応する運用部門 ◦ 各システムのアプリ担当者からの問い合わせ ◦ いつになく殺気立つPM (普段は仏) • 調査に駆り出される私 ◦ 直前でDirectConnectに関連する作業を実施していたため、逃れられない (別回線の作業だから俺は絶対関係ないだろ… と思いながら調査したのはここだけの秘密です。) ◦ AWSサポートにて電話しながらの調査実施
9. 第1の障害原因 
 AWS Direct Connect ロケーション 

10. 第1の障害原因はなんだったのか。 「AWS Direct Connect ロケーション側の問題」により障害が発生していた。
11. 無事解消するまでの話。 • AWSサポートとのやり取り ◦ 「AWS側での障害は確認していない」との回答 ◦ AWS上でそれらしい障害原因が見つからないため、 それ以上調査が進まない… • 回線事業者への問い合わせと連絡 ◦ マネージャー陣によって別途回線事業者へ問い合わせ ◦ AWS Direct Connect ロケーション側で問題が発生していたことが判明 ◦ しばらくした後、Direct Connectのステータスがアップし、 回線事業者からも復旧の連絡があった ◦ オンプレから各システムへの疎通もOK
12. すべて解消した！ 
 そう思われていたが…。 

13. 障害はまだまだ終わらない…。 なぜか特定のサブネット上のリソースだけ、疎通が通らない …。
14. 障害はまだまだ終わらない…。 • 障害状況 ◦ オンプレミスから特定のサブネットへの疎通だけ通らない ◦ それ以外のサブネットへは、正常に疎通できる • 疲弊し始める現場 ◦ ほっと一息ついた10分後には、おかわり障害対応 ◦ 困惑するPM • 引き続き調査に駆り出される私 ◦ これにより、ほぼまるまる1日の障害対応が確定 ◦ とりあえずネットワーク周りの設定から調査し始めた
15. 第2の障害原因 
 ヒューマンエラー 

16. 第1の障害の裏側で起きていたこと。 エンジニア〇〇さんが、 新規システム向けにサブネットなどのリソースを作成していた。 (マネジメントコンソールから手動作業)
17. 第1の障害の裏側で起きていたこと。 オンプレミス向けのRoute Tableは各サブネット共通で利用しており、 新規サブネットに関連づける際に、誤って既存のサブネットの関連付けを解除してしまった。
18. 無事解消するまでの話。 • 調査方法 ◦ 問題のサブネットにルートテーブルが関連づけられていないことを確認 ◦ CloudTrail + Configにて、 該当のサブネットとルートテーブルの設定履歴を確認 • 解消方法 ◦ サブネットにルートテーブルを関連付け ◦ 無事疎通が通るようになり、障害解消
19. 結論
 人間が一番の単一障害点 

20. どう対策するべきか。 • 作業プロセスの改善 ◦ 事前準備の強化 ▪ 作業前にシステム全体の依存関係を図式化し、影響範囲を明確化 ◦ 作業手順の標準化 ▪ チェックリスト形式の作業手順書を作成し、確認すべき項目を明文化 ▪ 重要な設定変更は、作業前後の状態を必ず記録
21. どう対策するべきか。 • 監視・検知体制の構築 ◦ 疎通確認の自動化 ▪ 各サブネットからオンプレミスへの疎通を定期的に自動チェック （スクリプト、Network Synthetic Monitorなど） • 作業体制の見直し ◦ 複数人での相互確認 ▪ 重要なインフラ作業は必ず複数人でレビュー ▪ 設定変更前後の状態を相互確認する体制を作る ◦ 段階的作業とロールバック準備 ▪ 作業を小さな単位に分割し、各段階で動作確認を実施 ▪ 即座に元の状態に戻せるよう、作業前の設定を必ず保存
22. どう対策するべきか。 • 技術的な対策 ◦ Infrastructure as Code（IaC）の活用 ▪ TerraformなどのIaCを使用して設定を管理し、 手動での設定ミスを防止 ▪ 変更履歴も自動的に管理 ◦ 作業時の権限の最小化 ▪ 作業に必要最小限の権限のみを付与 ▪ 重要な設定変更には承認フローを組み込む
23. ありがとうございました。 作業ミスに気をつけて、 用法用量を守って正しくAWSを利用しましょ う。