Platformの可用性確保に向けてChaos engineering & GameDayやってみた

TIER IV MARCH TIER /IV 2022 2024 / 12 / 19 TITLE Platformの可用性確保に向けて Chaos engineering & GameDayやってみた

Who am I? ● ● 名前：重光 俊亮 職歴 ○ SIerで自動車関連のプロジェクトに携 わってきました ○ 2022/10〜 TIER IVにジョイン ● 最近の趣味 ○ 庭いじり ○ ポーカー始めてみました

Index Why Chaos Engineering? 1. Purposes in general 2. In TIER IV… Our approach 1. Process 2. Target environment 3. Tools 4. Targets Results & Impacts 1. Feedback 2. Lessons Learned

Why we did Chaos Engineering 01

Chaos Engineering? Principles of chaos engineering Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production. カオスエンジニアリングは、システムが本番環境における不安定 な状態に耐える能力へ自信を持つためにシステム上で実験を行う 訓練方法です。

• https://principlesofchaos.org

Why? Why do we need it now? TIER IVでは… - Web.Autoの利用が増えてきており、今まで以上に回 復性・信頼性を高めていくフェーズに入っている 従来のテストでの検出では限界があり、Chaos Engineeringで組織として・継続的に回復力を高めて いきたい マイクロサービスで構築された分散アーキテクチャ 1 様々なユースケースでの利用増加2 1. https://www.docswell.com/s/TIER_IV/K1J6W3-TIERIVMeetupWeb.Auto 2. https://tier4.jp/media/detail/?sys_id=2EhHTVUBKMswFNFBOJWYVn&category=BLOG

• https://www.docswell.com/s/TIER_IV/K1J6W3-TIERIVMeetupWeb.Auto
• https://tier4.jp/media/detail/?sys_id=2EhHTVUBKMswFNFBOJWYVn&category=BLOG

Our approach 02

Our approach - Process TIER IVでの進め方 設計の改善・定期的な訓練 定常状態の定義 仮説の設定 変数の注入 非同期な実験 Game Dayの開催 Web.Autoを構成する各サービスに 実験対象の事象が発生したときの ついて、アプリケーションチーム 挙動についての仮説を定義する の協力を得て、定常状態を整理し e.g., 特定のAZでのネットワーク障害が ていく 実際に現実世界で発生しうるイベ ントを起こして、挙動を確認する e.g., AWS FISを用いて、特定AZの通 発生しALB→ECS間の接続ができない場 信を遮断する e.g., 認証認可基盤において、トークンの 合、5分後にALBから問題のあるAZ内の Taskのヘルスチェックが失敗、ALBから 権限の検証が行えている (Token Serviceの5xxエラーが0.1％未満( 切り離される タイムスケール 1分間隔))

Our approach - Process TIER IVでの進め方 - Tips 設計の改善・定期的な訓練 定常状態の定義 仮説の設定 変数の注入 非同期な実験 インシデント対応訓練 現状のTIER IVでは、SREは各 アプリチームに所属しているわけ ではないため、ドメイン知識が要 求される部分はアプリチームの協 力が欠かせない →Chaos Engineering自体・進め 方の説明会を開催して、定常状態 （の一部）を定義してもらう Game Dayの開催 システム的な堅牢さを見るために非同期的なカオスの注入 + インシデント対応プロセス含めた組織としての回復力を見 るためのGame Day Game Dayに先立って、参加者がトラブルシューティング に注力できるよう、インシデント対応プロセスだけに絞っ た訓練を別で実施

Our approach - Game Day Game Dayの取り組み - Game Day開催にあたって、SREチーム+アプリチームから1⃣名で運営チームを結成 注入対象の障害の検討、事前の段取りを調整 アプリチームからの協力者は、当日はオブザーバーとして参加 当日は段取り説明→Game Day自体の実施→振返り、で2⃣時間枠で実施 SRE App 運営チーム App Game Day 参加チーム

Our approach - Target environment 実験対象の環境 Production environment/本番環境 本番環境で検証を実行する Staging environment/ ≠ いきなり本番環境で実施する ステージング環境 現状は本番環境での試験は未実施 本番環境と極力構成を合わせた 、検証用の環境。こちらをメイ ンの環境として実験を行う Development environment/開発環境 開発者が日々の開発・テストで利 用する環境。主にツール類の動作 Staging環境でそれなりに実験するためのTips ➔ 実験中のトラフィック生成 ➔ モニタリング用のDashboardをStaging環境にも準備しておく ➔ アラートをStaging環境からも発報する 確認で利用

Our approach - Tools 実験に利用したツール - - Chaosの注入にあたっては、基本的にAWS FISを利用 - Kubernetesを利用しているサービス 向けには、一部Litmusも導入 各環境のモニタリングはDatadog→Slack で開発者に通知されている Game Day開催のタイミングでは+αでstg 環境のOpsGenieの通知も開発者に通知す るよう変更

Our approach - Target hypothesis 実際に注入してみた障害（の一例） 各サービスでアーキテクチャ & 仮説が異なることから、Game Dayでは以下のような各種の障害を注入 - 車両とやり取りをするLambdaの関数群のうち一つに遅延を注入 - Lambda Layerを導入し、エントリーポイントを切替えることで実現 特定AZでDynamoDBとの通信を遮断 特定のECS Taskにネットワーク遅延を注入 (GameDayとは別で) 他にも試したもの: - 特定のSubnet (≠AZ)の通信を遮断。具体的にはALB → ECSの通信を特定のPublic Subnetだけ遮断 CPU使用率を高騰させる Kubernetes上のNodeやkubeletをkillしてしまう

Results & Impacts 03

Results & Impact フィードバック & そこからの改善 Availability - 単純なAZ障害であれば、基本的には数十秒〜数分で復旧することが確認できた リソース消費に応じたスケールアウトも想定通り - 一方、スケーリングのポリシーが誤っており、リソース消費が落ち着いた後にスケールインしない という問題を発見できた Observability - 特定のAZで発生した障害の場合、サービス横串のDashboardでは事象を調査しづらかった - → ECS Task単位のパネルをDatadog Dashboardに追加 アラートを受けて参照するPlaybookが陳腐化しており、新規メンバーの調査に支障が出る - → Playbookの棚卸し/最新化 特にLambda Layerを注入するような実験では、関数のデプロイの可観測性が現状不足している

Results & Impact フィードバック & そこからの改善 Incident Management - チームによっては人数が少なく、インシデント対応フローで定義した役割を回すのが困難 インシデント対応時の利用ツールが散逸しており、分かりづらい … - →利用ツール含めた、インシデント対応プロセスの見直し実施中 Culture - チームによっては自律的に(SREの関与無く)Chaos Engineeringを実施し始めている（すごい）

Lessons Learned これからの取り組み - Staging環境と本番環境は（当たり前だが）異なる - →Staging環境で本番相当の負荷をかけたとこ ろ、単一IPアドレスからの大量アクセスがあり 、チームがそちらに気を取られてしまう... etc - とはいえ、本番環境で実施できるだけの自信を つけるにはまだまだ取り組みが必要 - 継続可能な仕組みにしていくことが必須 - 現状はSRE、アプリチームともにそれなりに時 間を割いてGame Dayを実施している - まだまだ拡張していくべき領域がある - 例えばIoT部分のChaos Engineeringはこれから カオスエンジニアリングの原則

• https://principlesofchaos.org/ja/

CONTACT US https://tier4.jp/careers/ We are Hiring!

• https://tier4.jp/careers/

CONTACT US https://tier4.jp/ Thanks Again !

• https://tier4.jp/