Upgrade to Pro — share decks privately, control downloads, hide ads and more …

障害対応のRunbookは作った、でも本当に動くの? AWS FIS で EKS の AZ 障...

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

障害対応のRunbookは作った、でも本当に動くの? AWS FIS で EKS の AZ 障害を再現してみた

【JAWS-UG 神戸 #11】LT 大会 - connpass
https://jawsug-kobe.connpass.com/event/391241/

Avatar for Hiroki Takatsuka

Hiroki Takatsuka

May 18, 2026

More Decks by Hiroki Takatsuka

Other Decks in Technology

Transcript

  1. JAWS-UG Kobe #11 / 2026.05.18 障害対応のRunbookは作った でも本当に動くの? AWS FIS で

    EKS の AZ 障害を再現してみた Hiroki Takatsuka @tk3fftk / primeNumber Inc.
  2. 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コミュニティ⽴ち上げ企画中🚀
  3. AWS でのスタンダード == AZ 冗⻑化 • AWS Well-Architected Framework において「複数

    AZ にデプロイすること」が ベースラインとして推奨されている ◦ 主要サービスは AZ 冗⻑配置が基本になるデザイン ( 「推奨」とか defaultになってる) • 上位?のマルチリージョン構成はコスト‧運⽤負荷‧データ整合性とのトレードオフ ◦ いわゆる、ビジネス要件次第 Reference: AWS Well-Architected Framework primeNumber Inc. 5
  4. 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
  5. AZ 障害耐性のある構成でも実際には何らかのデグレーションが発⽣する 設計上の冗⻑化 と 実障害下での挙動 は別物と考えたほうがよさそう💡 primeNumber Inc. • EC2使ってないから⼤丈夫?

    ◦ EC2やネットワーク系の障害なら、他サービスの基盤なので間接的に影響する可能性ない? • LB挟んでるから⼤丈夫? ◦ ヘルスチェック落ちるまでのアクセスは⼤丈夫なんだっけ? ◦ Sticky SessionとかLBの設定で障害AZに固定されるとかはない? • ⾃動フェイルオーバー/オートヒーリングがあるから⼤丈夫? ◦ フェイルオーバーするまでの時間は?時間めっちゃかかったらどうする? ◦ キャッシュとかで古いほうにアクセスし続けちゃったりしない? ◦ EC2に障害があると「インスタンス落ちた」という判定そのものが「落ちる」ケースは? 7
  6. TROCCOのデータ転送ジョブ基盤における課題 (2024年末ごろ) • TROCCO は EKS をデータ転送ジョブ基盤として利⽤している • AZ 障害に備えた

    Runbook (⼿順書) は作成していた (なおMR構成ではない) • 実際の障害発⽣時に、⼿順通り動くか、抜け漏れがないかは確認できていなかった ◦ EKSへの障害の注⼊… なんか⼤変そう。Chaos hogehogeみたいなやつ使わないとできない? ◦ 👉 AWS Fault Injection Serviceで試せそう💡 primeNumber Inc. 11
  7. AWS Fault Injection Service (FIS) とは • コントロールされたFault Injection(障害の注⼊)実験を実⾏できるマネージドサービス •

    影響範囲を絞り、障害シナリオを特定コンポーネントに対してのみ試せる ◦ 逆に範囲をマルチアカウントに広げて実施することも可能 • 各アクションの開始タイミング‧継続時間なども設定できる ◦ Stop Conditions で特定条件になった場合に停⽌する設定も可能 primeNumber Inc. reference: Fault Injection Service AWS とは - AWS フォールトインジェクションサービス 12
  8. 多くのシナリオライブラリ(テンプレのようなもの)が⽤意されている 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
  9. 今回ベースとしたシナリオ 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
  10. 最終的に実⾏したアクションは必要最低限の3つ 01 Stop-ASG-Instances AZ-a の ASG 管理インスタンスを停⽌ 02 Pause-ASG-Scaling ASG

    による EC2 API コールを失敗 03 Pause-network-connectivity Subnet の通信を 2 分間 停⽌ ※絞りたくて絞ったわけ訳ではなく残り3つは実⾏時エラー(後述)かつ必須でもない、という判断で除外 16
  11. 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
  12. ざっくり実施⼿順 primeNumber Inc. • 社内アナウンス (「OO時からstaging環境壊します!」的な) • 事前クラスタスケール (stagingなので数が少なく検証にならないため) •

    シナリオ作成 ◦ FISの実⾏に必要な実⾏ロールはAWSコンソールから案内通り作成 (⼀時的にしか使わないし… • 対象のリソースに⼀時的にタグを付与 ◦ aws-cli で EC2 / ASG / Subnet に AzImpairmentPower タグを付与 • 作成したシナリオをAWSコンソールから実⾏ • 障害の発⽣を確認後Runbook通りの対応を実施 • Runbook上うまく⾏かなかった部分を修正 18
  13. やってみてどうだったか? ネットワーク切断により、Redis への接続アラートがまず最初に⾶んだ 予測はしていなかったが、頻繁に接続しているため、依存側の影響が先に表⾯化した (とはいえ、Redisも落ちてる可能性あるので本質的にはRedis断も試すべきだったカモ) k8s の Node の NotReady

    への遷移は期待通り機能 対象 Node は 2 分以内に NotReady へ遷移し、k8sのサービスアウトの機構が期待通りに機能した ⼀⽅Podに関しては、k8s 上のステータスは Running のままだが実際には動いていない状態に (ネットワークが繋がらないためkubeletからのステータス更新ができなかったと思われる) 👉 AZ 障害時は対象 Node への明⽰的な drain 実⾏が必要な旨を Runbook に追記 Runbook の⼿順‧コマンドは概ねそのまま使えた ⼤きな抜け漏れは⾒つからず、⼿順書の有効性を検証できたこと primeNumber Inc. 19
  14. 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
  15. まとめ primeNumber Inc. • Runbookは「作る」に加えて 「試す」 のが⼤事 ◦ 試すこと⾃体が難しい場⾯が多いが、強⼒にサポートしてくれるツールが AWS

    FIS • いきなり本格的なカオスエンジニアリングはハードルが⾼すぎるので「部分的に壊して⼩ さく試せる」のはFISの強み ◦ より⾼度にやりたければだんだん影響範囲を広げていけばよい(ハズ) ◦ 天然のカオスエンジニアリングをまずは無くそうね 21