JAWS-UG Kobe #11 / 2026.05.18 障害対応のRunbookは作った でも本当に動くの？ AWS FIS で EKS の AZ 障害を再現してみた Hiroki Takatsuka @tk3fftk / primeNumber Inc. 

Hiroki Takatsuka @tk3fftk primeNumber (2022 〜 ) • TROCCO / COMETA SRE, Engineering Manager • Security Team ⽴ち上げ 〜 兼務メンバー • Corporate SRE ⽴ち上げ 最近はFinOpsとかやっ てる ヤフー株式会社 (2016 〜 2022) • CI/CD プラットフォーム Screwdriver.cd の SRE, Engineering Manager 猫はアルくんです。かわいいですね。 2 今年の1⽉に⻄宮市に引っ越してきました🚅 神⼾には6年間住んでたことがあります🐗 関⻄SREコミュニティ⽴ち上げ企画中🚀 

© primeNumber Inc. 3 TROCCO/COMETAについて TROCCO:「データ統合」を軸にデータ基盤の構築や運用を支援 COMETA: AIを軸にデータの発見/理解/活用を促進するデータカタログ データをビジネスに活用するまでのステップ 

AGENDA 1. 背景 2. 検証設計 (何をどう試したか) 3. わかったこと‧ハマりどころ 4. まとめ 4 

AWS でのスタンダード == AZ 冗⻑化 ● AWS Well-Architected Framework において「複数 AZ にデプロイすること」が ベースラインとして推奨されている ○ 主要サービスは AZ 冗⻑配置が基本になるデザイン ( 「推奨」とか defaultになってる) ● 上位?のマルチリージョン構成はコスト‧運⽤負荷‧データ整合性とのトレードオフ ○ いわゆる、ビジネス要件次第 Reference: AWS Well-Architected Framework primeNumber Inc. 5 

AZ 障害 は リージョン障害 より頻度が⾼い (それはそう) 東京リージョン (ap-northeast-1) の主な障害履歴 発⽣⽇ 影響範囲 内容 2025-06-05 単⼀ AZ apne1-az1 パケットロス‧レイテンシ増加 2025-04-15 単⼀ AZ apne1-az4 電源遮断で⼀部 EC2 に接続障害 2024-10-03 リージョン ネットワークパーティション、EC2 / EBS の性能低下 2021-09-02 全 AZ 波及 Direct Connect コアの障害が東京全 AZ に波及 2021-02-20 単⼀ AZ apne1-az1 冷却系の電源喪失、温度上昇で EC2 障害 2019-08-23 単⼀ AZ apne1-az4 冷却制御システムのバグで EC2 / EBS / RDS 等に影響 Source: サーバーワークス — 過去の AWS 障害まとめ primeNumber Inc. 6 

AZ 障害耐性のある構成でも実際には何らかのデグレーションが発⽣する 設計上の冗⻑化 と 実障害下での挙動 は別物と考えたほうがよさそう💡 primeNumber Inc. ● EC2使ってないから⼤丈夫？ ○ EC2やネットワーク系の障害なら、他サービスの基盤なので間接的に影響する可能性ない？ ● LB挟んでるから⼤丈夫？ ○ ヘルスチェック落ちるまでのアクセスは⼤丈夫なんだっけ？ ○ Sticky SessionとかLBの設定で障害AZに固定されるとかはない？ ● ⾃動フェイルオーバー/オートヒーリングがあるから⼤丈夫？ ○ フェイルオーバーするまでの時間は？時間めっちゃかかったらどうする？ ○ キャッシュとかで古いほうにアクセスし続けちゃったりしない？ ○ EC2に障害があると「インスタンス落ちた」という判定そのものが「落ちる」ケースは？ 7 

障害対応のRunbook、 持っていますか？ Question (障害対応手順書や対応自動化の実装 ) 8 

障害対応のRunbook、 持っていますか？ 実際に試したことは？ Question (障害対応手順書や対応自動化の実装 ) 9 

障害対応のRunbook、 持っていますか？ 実際に試したことは？ 実際の障害発⽣下 で試したことは？ Question (障害対応手順書や対応自動化の実装 ) 10 

TROCCOのデータ転送ジョブ基盤における課題 (2024年末ごろ) • TROCCO は EKS をデータ転送ジョブ基盤として利⽤している • AZ 障害に備えた Runbook (⼿順書) は作成していた (なおMR構成ではない) • 実際の障害発⽣時に、⼿順通り動くか、抜け漏れがないかは確認できていなかった ○ EKSへの障害の注⼊… なんか⼤変そう。Chaos hogehogeみたいなやつ使わないとできない？ ○ 👉 AWS Fault Injection Serviceで試せそう💡 primeNumber Inc. 11 

AWS Fault Injection Service (FIS) とは ● コントロールされたFault Injection(障害の注⼊)実験を実⾏できるマネージドサービス ● 影響範囲を絞り、障害シナリオを特定コンポーネントに対してのみ試せる ○ 逆に範囲をマルチアカウントに広げて実施することも可能 ● 各アクションの開始タイミング‧継続時間なども設定できる ○ Stop Conditions で特定条件になった場合に停⽌する設定も可能 primeNumber Inc. reference: Fault Injection Service AWS とは - AWS フォールトインジェクションサービス 12 

多くのシナリオライブラリ(テンプレのようなもの)が⽤意されている Reference: FIS シナリオライブラリの使⽤ / AZ Availability シナリオ EC2 instance failure CPU stress Memory stress Disk stress Network Latency EKS Pod Delete CPU stress Memory stress Disk stress Network Latency Multi-AZ / Region AZ Power Interruption AZ Application Slowdown Cross-AZ Traffic Slowdown Cross-Region Connectivity EBS Sustained Latency Increasing Latency Intermittent Latency Decreasing Latency primeNumber Inc. 13 

今回ベースとしたシナリオ AZ Availability: Power Interruption 特定 AZ の「電⼒断」を擬似再現する 複合シナリオ Stop-ASG-Instances ASG 管理インスタンスを停⽌ (aws:ec2:stop-instances) Stop-Instances 対象 AZ のインスタンスを停⽌(aws:ec2:stop-instances) Pause-Instance-Launches 新規起動を API で失敗(aws:ec2:api-insufficient-instance-capacity-error) Pause-ASG-Scaling ASG のスケール API を失敗 (aws:ec2:asg-insufficient-instance-capacity-error) Pause-Network-Connectivity Subnet 通信を遮断 (aws:network:disrupt-connectivity) Pause-EBS-IO EBS Volume の I/O を停⽌ (aws:ebs:pause-volume-io) 各アクションは 独⽴した継続時間 を設定可能 (ネットワーク以外はデフォルトだと 30 分) Failover-RDS RDSのfailoverを実施 (aws:rds:failover-db-cluster) Pause-ElastiCache ElastiCacheノードを停⽌ (aws:elasticache:replicationgroup-interrupt-az-power) reference: https://docs.aws.amazon.com/fis/latest/userguide/az-availability-scenario.html Start-ARC-Zonal-Autoshift ARCゾーンオートシフトを開始 (aws:arc:start-zonal-autoshift) 14 

実施の検討にあたってはスコープを絞った ゴールはEKS(ジョブ実⾏基盤)のRunbookが想定通り動くかの確認 「AZ障害が起きたときに実際にサービスで起こること」を知るのはまた別の機会に primeNumber Inc. ● AZ障害を模すため AZ-a のみを対象 ● EKS 関連リソースのみを対象 ○ RDS / ElastiCache などもサービスでは利⽤しているが除外した 15 

最終的に実⾏したアクションは必要最低限の3つ 01 Stop-ASG-Instances AZ-a の ASG 管理インスタンスを停⽌ 02 Pause-ASG-Scaling ASG による EC2 API コールを失敗 03 Pause-network-connectivity Subnet の通信を 2 分間 停⽌ ※絞りたくて絞ったわけ訳ではなく残り3つは実⾏時エラー(後述)かつ必須でもない、という判断で除外 16 

EKS × AZ-a 障害注⼊ポイント FAILURE INJECTION POINTS 1 Stop-ASG-Instances Node が 2 分以内に NotReady 2 Pause ASG Scaling スケールアウト API を失敗 3 Pause Network Connectivity Subnet 通信を 2 分間ブ ロック primeNumber Inc. 17 

ざっくり実施⼿順 primeNumber Inc. ● 社内アナウンス (「OO時からstaging環境壊します！」的な) ● 事前クラスタスケール (stagingなので数が少なく検証にならないため) ● シナリオ作成 ○ FISの実⾏に必要な実⾏ロールはAWSコンソールから案内通り作成 (⼀時的にしか使わないし… ● 対象のリソースに⼀時的にタグを付与 ○ aws-cli で EC2 / ASG / Subnet に AzImpairmentPower タグを付与 ● 作成したシナリオをAWSコンソールから実⾏ ● 障害の発⽣を確認後Runbook通りの対応を実施 ● Runbook上うまく⾏かなかった部分を修正 18 

やってみてどうだったか？ ネットワーク切断により、Redis への接続アラートがまず最初に⾶んだ 予測はしていなかったが、頻繁に接続しているため、依存側の影響が先に表⾯化した (とはいえ、Redisも落ちてる可能性あるので本質的にはRedis断も試すべきだったカモ) k8s の Node の NotReady への遷移は期待通り機能 対象 Node は 2 分以内に NotReady へ遷移し、k8sのサービスアウトの機構が期待通りに機能した ⼀⽅Podに関しては、k8s 上のステータスは Running のままだが実際には動いていない状態に (ネットワークが繋がらないためkubeletからのステータス更新ができなかったと思われる) 👉 AZ 障害時は対象 Node への明⽰的な drain 実⾏が必要な旨を Runbook に追記 Runbook の⼿順‧コマンドは概ねそのまま使えた ⼤きな抜け漏れは⾒つからず、⼿順書の有効性を検証できたこと primeNumber Inc. 19 

FIS が意図通り動かなかったところ (今はいい感じに動くようになってるかも) Pause-Instance-Launches → Service Linked RoleだとIAM Role の編集ができなくてエラー 内部的にロールを更新して停⽌させる仕様なので指定できない模様 Pause-EBS-IO → “InvalidTarget for target EBS-Volumes.” となる Tag付与もDeleteOnTermination=true のフィルタも実施していた いくつか条件を試したが解消できなかったため、今回は除外した primeNumber Inc. Stop-Instances → Targetが0だとSkipではなくエラーとなる設定で実施していた Empty target resolution mode=Fail 設定ミス（タグ付け漏れなど）に実⾏前に気づける利点がある Stop-ASG-Instancesですべてカバーできていたため、除外した 20 

まとめ primeNumber Inc. ● Runbookは「作る」に加えて 「試す」 のが⼤事 ○ 試すこと⾃体が難しい場⾯が多いが、強⼒にサポートしてくれるツールが AWS FIS ● いきなり本格的なカオスエンジニアリングはハードルが⾼すぎるので「部分的に壊して⼩ さく試せる」のはFISの強み ○ より⾼度にやりたければだんだん影響範囲を広げていけばよい(ハズ) ○ 天然のカオスエンジニアリングをまずは無くそうね 21 

4 / 24 おまけ: Howに限らず「障害訓練やるべき」という話は クラウドネイティブ会議のこちらのセッションがとても良かったのでぜひ 〜備えあれば憂いなし〜 とりあえず障害訓練やろ？ デジタル/フィジカル横断プロダクトを 24365で維持するための戦略 22