0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

新人プログラマ応援 - みんなで新人を育てよう！
@0h-n0

AWS FIS・Gremlinで始めるカオスエンジニアリング組織導入とGameDay運営ガイド

0
Last updated at Posted at 2026-04-04

AWS FIS・Gremlinで始めるカオスエンジニアリング組織導入とGameDay運営ガイド

カオスエンジニアリングは「本番環境に意図的な障害を注入し、システムの弱点を発見する」エンジニアリング手法です。カオスエンジニアリングツール市場は2024年に60.5億ドル規模に達し、2033年には404.5億ドルまで成長すると予測されています（CAGR 23.5%、SkyQuest調査）。しかし、ツールを導入しただけでは効果は出ません。組織としてカオス実験を継続運用し、GameDayを文化として定着させる仕組みが不可欠です。

本記事では、AWS FIS・Gremlin・Steadybitの3つのプラットフォームを比較しながら、組織へのカオスエンジニアリング導入戦略と月次GameDay運営の実践パターンを解説します。Kubernetes上のLitmusChaos・Chaos Meshについては既存記事をご参照ください。

この記事でわかること

  • カオスエンジニアリングの成熟度モデル（Shadows→Investment→Adoption）に基づく段階的導入戦略
  • AWS FIS・Gremlin・Steadybitの機能比較と組織規模別の選定指針
  • 定常状態仮説（Steady-State Hypothesis）の設計方法とSLO連携パターン
  • GameDayの企画・運営・振り返りフローとKPIベース評価
  • CI/CDパイプラインへのカオス実験統合と自動化パターン

対象読者

  • 想定読者: マイクロサービスを運用するMLEやSRE、DevOpsエンジニア
  • 必要な前提知識:
    • AWSの基本サービス（EC2、ECS、Lambda）の運用経験
    • SLI/SLOの概念理解
    • CI/CDパイプラインの基礎知識
    • Prometheus/Grafana等のモニタリング基礎（OpenTelemetry実践ガイドも参考）

結論・成果

カオスエンジニアリングを組織的に導入した場合、以下の改善が報告されています。

  • MTTR（平均復旧時間）: 31.5%改善（50組織24ヶ月追跡、R Systems調査）
  • 本番インシデント: 42.8%削減（同調査）
  • 障害検知時間（MTTD）: 平均41.6%短縮（導入初年度、50マイクロサービス以上の環境で顕著）
  • インシデント解決速度: カオス実験を実施するチームは従来手法の2.1倍速く解決

ZOZOの事例では、AWS FISを活用した月1回のGameDay運営により、障害検知3分以内・MTTR 10分以内を目標とするKPIベース評価を確立しています（ZOZO Tech Blog）。

カオスエンジニアリングの基礎概念を理解する

カオスエンジニアリングは2011年にNetflixが開発したChaos Monkeyに端を発します。Netflixは2008年のデータベース障害で3日間サービスが停止した経験から、AWSへの移行と並行してカオスエンジニアリングを正式導入しました（Wikipedia - Chaos engineering）。現在ではprinciplesofchaos.orgで5つの原則が定義されています。

5つの原則とML類推

カオスエンジニアリングの原則は、MLエンジニアにとってモデル評価プロセスと構造が似ています。

原則 説明 MLでの類推
定常状態の仮説を立てる 正常な状態をSLI/SLOで定量定義 ベースラインモデルの精度定義
現実世界のイベントを反映する 実際に起こりうる障害をシミュレート 本番データ分布でのモデル評価
本番環境で実験する ステージングだけでなく本番でも検証 A/Bテストを本番トラフィックで実行
自動化して継続実行する CI/CDに組み込み継続的に回す モデル再学習パイプラインの自動化
ブラストレディウスを最小化する 影響範囲を段階的に拡大 カナリアデプロイでリスク限定

MLパイプラインに例えると、「定常状態仮説＝ベースラインメトリクス」「障害注入＝ノイズ・摂動テスト」「観測＝モデルモニタリング」に対応します。

定常状態仮説（Steady-State Hypothesis）を設計する

カオス実験の核心は定常状態仮説です。SLI（Service Level Indicators）とSLO（Service Level Objectives）をベースに、システムが「正常」であることを定量的に表現します。

仮説のテンプレートは以下の形式です。

「[障害]が発生した場合、[システム]は[期待動作]を維持し、[定常状態メトリクス]が[SLO範囲内]に留まる」

具体例を見てみましょう。

# 定常状態仮説の定義例
steady_state_hypothesis:
  title: "APIゲートウェイのレイテンシSLOを維持"
  probes:
    - name: "p99レイテンシが500ms以下"
      type: probe
      provider:
        type: http
        url: "http://prometheus:9090/api/v1/query"
        arguments:
          query: 'histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))'
      tolerance:
        type: range
        range: [0, 0.5]  # 500ms以下
    - name: "エラー率が0.1%以下"
      type: probe
      provider:
        type: http
        url: "http://prometheus:9090/api/v1/query"
        arguments:
          query: 'rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])'
      tolerance:
        type: range
        range: [0, 0.001]  # 0.1%以下

注意点:

定常状態仮説は既存のSLOから導出するのが基本です。SLOが未定義のシステムにカオス実験を導入しようとすると、「何が正常かわからないのに異常を検知する」という矛盾に陥ります。先にSLI/SLOを整備してからカオスエンジニアリングに着手してください。

カオスエンジニアリングツールを選定する

3大クラウドのネイティブサービスと商用プラットフォームを比較し、組織規模に応じた選定指針を示します。

AWS FIS・Azure Chaos Studio・Google Cloud CEの比較

特性 AWS FIS Azure Chaos Studio Gremlin Steadybit
対応環境 AWSのみ Azureのみ マルチクラウド+オンプレ マルチクラウド+OSS拡張
障害タイプ AZ障害、CPU/メモリ圧迫、ネットワーク遅延、API障害 VM障害、DNS障害、NSG操作 200+障害タイプ 200+テンプレート
安全機構 Stop Conditions、Safety Levers RBAC、停止条件 ブラストレディウス制御、RBAC セーフティネット、自動ロールバック
CI/CD統合 EventBridge→Lambda Azure DevOps API/CLI API/CLI、GitHub Actions
可観測性連携 CloudWatch、X-Ray Azure Monitor Datadog、Prometheus、PagerDuty Prometheus、Grafana、Datadog
価格モデル アクション分数課金 アクション分数課金 サブスクリプション SaaS/オンプレ
適合組織 AWS中心の組織 Azure中心の組織 マルチクラウド大企業 OSS重視の中規模チーム

AWS FISの実践例: AZ障害をシミュレートする

AWS FISは、AWSサービスとの深い統合が特徴です。以下はAZ障害シミュレーション実験の例です。

{
  "description": "AZ-a障害時にサービスがAZ-cにフェイルオーバーすることを検証",
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:CriticalErrorRate"
    }
  ],
  "targets": {
    "ec2-instances-az-a": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {
        "Environment": "staging"
      },
      "filters": [
        {
          "path": "Placement.AvailabilityZone",
          "values": ["ap-northeast-1a"]
        }
      ],
      "selectionMode": "ALL"
    }
  },
  "actions": {
    "stop-instances-az-a": {
      "actionId": "aws:ec2:stop-instances",
      "parameters": {},
      "targets": {
        "Instances": "ec2-instances-az-a"
      },
      "startAfter": ["wait-before-fault"]
    },
    "wait-before-fault": {
      "actionId": "aws:fis:wait",
      "parameters": {
        "duration": "PT1M"
      }
    }
  },
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole"
}

なぜAZ障害から始めるか:

  • AZ障害はクラウド環境で最も頻度の高い大規模障害パターンの一つ
  • マルチAZ構成が正しく機能するかを検証できる
  • 影響範囲が明確で、Stop Conditionsによる自動停止が設定しやすい

注意点:

AWS FISの実験はAWSリソースに対してのみ有効です。オンプレミスやマルチクラウド環境を含むシステムでは、GremlinやSteadybitのようなマルチクラウド対応ツールを検討してください。また、初回実験はstaging環境で必ず実施し、Stop Conditionsが正しく機能することを確認してから本番に移行しましょう。

Gremlinの実践例: ネットワーク遅延を注入する

Gremlinはマルチクラウド対応の商用プラットフォームで、2026年1月にはDR Testing機能を発表しています（Gremlin公式）。以下はGremlin CLIでネットワーク遅延を注入する例です。

# Gremlin CLIでネットワーク遅延を注入
# 対象: payment-serviceタグが付いたホスト
# 影響: 300msの遅延を10分間注入
gremlin attack network latency \
  --length 600 \
  --delay 300 \
  --target-tags "service=payment-service" \
  --percent 50

# 実験結果の確認
gremlin attack status <attack-id>

Gremlin APIを使ったプログラマティックな実験定義も可能です。

# gremlin_experiment.py
# Gremlin API を使った実験の自動実行例
import requests
import time
import os

GREMLIN_API_KEY = os.environ["GREMLIN_API_KEY"]
GREMLIN_TEAM_ID = os.environ["GREMLIN_TEAM_ID"]
BASE_URL = "https://api.gremlin.com/v1"

headers = {
    "Authorization": f"Key {GREMLIN_API_KEY}",
    "Content-Type": "application/json",
}


def run_latency_experiment(
    target_tags: dict[str, str],
    delay_ms: int = 300,
    duration_sec: int = 600,
    percent: int = 50,
) -> str:
    """ネットワーク遅延実験を実行し、attack IDを返す"""
    payload = {
        "command": {
            "type": "network",
            "commandType": "latency",
            "args": [
                "-l", str(duration_sec),
                "-d", str(delay_ms),
                "-p", str(percent),
            ],
        },
        "target": {
            "type": "Exact",
            "tags": target_tags,
        },
    }
    resp = requests.post(
        f"{BASE_URL}/attacks/new",
        json=payload,
        headers=headers,
        params={"teamId": GREMLIN_TEAM_ID},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.text.strip('"')


def check_steady_state(prometheus_url: str, query: str, threshold: float) -> bool:
    """Prometheusクエリで定常状態を検証"""
    resp = requests.get(
        f"{prometheus_url}/api/v1/query",
        params={"query": query},
        timeout=10,
    )
    result = resp.json()["data"]["result"]
    if not result:
        return False
    value = float(result[0]["value"][1])
    return value <= threshold


if __name__ == "__main__":
    prometheus = "http://prometheus:9090"
    latency_query = 'histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{service="payment"}[5m]))'

    # 1. 定常状態の確認（実験前）
    pre_check = check_steady_state(prometheus, latency_query, threshold=0.5)
    print(f"実験前の定常状態チェック: {'PASS' if pre_check else 'FAIL'}")

    if not pre_check:
        print("定常状態が満たされていません。実験を中止します。")
        raise SystemExit(1)

    # 2. 障害注入
    attack_id = run_latency_experiment(
        target_tags={"service": "payment-service"},
        delay_ms=300,
        duration_sec=600,
    )
    print(f"実験開始: attack_id={attack_id}")

    # 3. 実験中の観測（60秒間隔で定常状態を監視）
    for i in range(10):
        time.sleep(60)
        steady = check_steady_state(prometheus, latency_query, threshold=0.8)
        print(f"チェック {i+1}/10: {'PASS' if steady else 'FAIL - SLO違反検出'}")
        if not steady:
            print("SLO違反を検出。実験結果を記録して改善タスクを作成します。")
            break

    # 4. 定常状態の再確認（実験後）
    time.sleep(120)  # 回復待ち
    post_check = check_steady_state(prometheus, latency_query, threshold=0.5)
    print(f"実験後の定常状態チェック: {'PASS' if post_check else 'FAIL'}")

Steadybitの実践例: ノーコードで実験を定義する

Steadybitはオープンソース拡張フレームワークとノーコードエディタが特徴です。2025年6月にはカオスエンジニアリング初のMCPサーバーを発表し、LLMワークフローとの統合を実現しました（BusinessWire）。

# steadybit-experiment.yaml
# Steadybitの実験定義: Kubernetes Pod障害
name: "payment-service Pod障害復旧検証"
description: "payment-serviceのPodを1つ停止し、自動復旧とSLO維持を検証"
team: "platform-sre"
environment: "staging-east"

# 定常状態仮説
hypothesis:
  - name: "API成功率が99.9%以上"
    query:
      type: prometheus
      expression: 'sum(rate(http_requests_total{service="payment",code=~"2.."}[5m])) / sum(rate(http_requests_total{service="payment"}[5m]))'
    expected:
      type: ">="
      value: 0.999

# 障害注入アクション
actions:
  - type: "com.steadybit.extension_kubernetes.pod_delete"
    target:
      type: "com.steadybit.extension_kubernetes.kubernetes-pod"
      attributes:
        k8s.namespace: "production"
        k8s.deployment: "payment-service"
    parameters:
      gracePeriod: "0s"
      podCountMode: "fixed"
      podCount: 1
    duration: "30s"

# 安全機構
safeguards:
  - name: "エラー率上限"
    type: abort_on_metric_threshold
    query:
      type: prometheus
      expression: 'rate(http_requests_total{service="payment",code=~"5.."}[1m])'
    threshold: 0.05  # 5%超でアボート

ツール選定のよくある間違い:

最初はクラウドネイティブツール（AWS FIS等）だけで十分だと考えがちですが、実際にはマイクロサービス間の依存関係はクラウド境界を越えることが多いです。例えば、AWSのECSからオンプレのデータベースへの接続、あるいはサードパーティAPIへの依存などです。組織の成熟度が上がるにつれて、マルチクラウド対応ツールの必要性が高まります。

組織にカオスエンジニアリングを導入する

ツールの選定以上に重要なのは、組織としてカオス実験を継続運用できる仕組みを構築することです。O'Reilly『Chaos Engineering』で提唱された成熟度モデルに基づき、段階的な導入戦略を解説します（O'Reilly - Chaos Maturity Model）。

成熟度モデルの3段階

成熟度モデルは精巧度（Sophistication）と採用度（Adoption）の2軸で評価されます。

段階 精巧度 採用度 特徴 期間目安
Shadows Elementary 個人レベル 非公式な実験、ステージング環境のみ 1-3ヶ月
Investment Simple〜Advanced チームレベル 公式承認、月次GameDay、複数チーム参加 3-12ヶ月
Adoption Sophisticated 組織レベル 専任チーム、CI/CD統合、本番継続実験 12ヶ月以降

Shadows段階: 個人実験で成果を証明する

最初のステップは、1人のエンジニアがステージング環境で小規模な実験を行い、具体的な成果を示すことです。

# Chaos Toolkitを使った最小実験例
# Chaos ToolkitはPython製のOSSフレームワーク（Google Cloud公式推奨）
pip install chaostoolkit chaostoolkit-aws

# 実験定義（JSON形式）
cat > first-experiment.json << 'EXPERIMENT'
{
  "title": "ECSタスク1つ停止時にALBがトラフィックを再分配する",
  "description": "ECSタスクの自動復旧とALBヘルスチェックの動作を検証",
  "steady-state-hypothesis": {
    "title": "APIレスポンスが正常",
    "probes": [
      {
        "type": "probe",
        "name": "api-health-check",
        "tolerance": 200,
        "provider": {
          "type": "http",
          "url": "https://staging-api.example.com/health",
          "timeout": 5
        }
      }
    ]
  },
  "method": [
    {
      "type": "action",
      "name": "stop-one-ecs-task",
      "provider": {
        "type": "python",
        "module": "chaosaws.ecs.actions",
        "func": "stop_task",
        "arguments": {
          "cluster": "staging-cluster",
          "service": "api-service",
          "reason": "chaos-experiment-first-test"
        }
      },
      "pauses": {
        "after": 30
      }
    }
  ],
  "rollbacks": [
    {
      "type": "action",
      "name": "verify-task-recovery",
      "provider": {
        "type": "python",
        "module": "chaosaws.ecs.probes",
        "func": "are_all_desired_tasks_running",
        "arguments": {
          "cluster": "staging-cluster",
          "service": "api-service"
        }
      }
    }
  ]
}
EXPERIMENT

# 実験実行
chaos run first-experiment.json

この段階で重要なのは、実験結果を定量的にまとめて関係者に共有することです。「ECSタスク停止時にALBのフェイルオーバーに15秒かかっていたが、ヘルスチェック間隔を調整して5秒に短縮できた」のような具体的成果が、次の段階への承認獲得につながります。

Investment段階: チーム予算を確保しGameDayを開始する

成果が認められたら、チーム単位での正式な取り組みに格上げします。この段階で必要なのは以下の3つです。

  1. 専用環境の確保: カオス実験用のステージング環境、または本番のカナリア環境
  2. ツールへの投資: AWS FISの利用開始、またはGremlin/Steadybitのライセンス取得
  3. 定期的なGameDay: 月1回の定例イベントとして組織に組み込む

トレードオフ:

AWS FISは無料利用枠がなくアクション分数で課金されますが、AWS環境との統合が深いため設定コストが低いです。一方、Gremlinはサブスクリプション課金で初期費用は高いものの、マルチクラウド環境やオンプレミスも含めた統一的な管理が可能です。組織の環境構成に応じて選択してください。

GameDayを企画・運営する

GameDayはカオスエンジニアリングの組織定着において最も重要なイベントです。ZOZOの事例（ZOZO Tech Blog）を参考に、実践的な運営フローを解説します。

GameDay運営フロー

シナリオ設計の実践パターン

ZOZOの事例では、「リアルタイムシステム」と「バッチシステム」の2カテゴリに分けて合計9シナリオを実施しています（ZOZO CE合宿2025）。

以下に代表的な6つの障害シナリオテンプレートを示します。

カテゴリ シナリオ 検証ポイント 難易度
コンピュート ECSタスク/Pod停止 オートスケーリングの復旧速度 低
ネットワーク AZ間ネットワーク遅延 マルチAZフェイルオーバー 中
データストア DynamoDB/RDSネットワーク断 キャッシュフォールバック 中
キャッシュ ElastiCacheインスタンス障害 キャッシュミス時のDB負荷 中
リソース CPU/メモリ圧迫 リソースリミットの適切性 低
外部依存 サードパーティAPI遅延/タイムアウト サーキットブレーカー動作 高

KPIベース評価を設計する

GameDayの効果を定量的に測定するために、ZOZOの事例で採用されているKPIフレームワークを紹介します。

# gameday_kpi.py
# GameDayのKPI評価スクリプト
from dataclasses import dataclass
from datetime import datetime


@dataclass
class GameDayResult:
    """GameDay実験結果"""
    scenario_name: str
    participant: str
    detection_time_sec: int  # 障害検知までの時間（秒）
    recovery_time_sec: int   # 復旧までの時間（秒）
    root_cause_identified: bool  # 根本原因を特定できたか
    runbook_followed: bool   # ランブックに従えたか
    communication_score: int  # コミュニケーション評価（1-10）
    documentation_score: int  # ドキュメント記録評価（1-10）
    timestamp: datetime


def evaluate_gameday(results: list[GameDayResult]) -> dict:
    """GameDay全体のKPIを集計"""
    total = len(results)
    if total == 0:
        return {"error": "結果が0件です"}

    avg_detection = sum(r.detection_time_sec for r in results) / total
    avg_recovery = sum(r.recovery_time_sec for r in results) / total
    root_cause_rate = sum(1 for r in results if r.root_cause_identified) / total
    runbook_rate = sum(1 for r in results if r.runbook_followed) / total

    # 自己評価スコア（7項目合計 / 70点満点 → 百分率）
    avg_self_score = sum(
        r.communication_score + r.documentation_score for r in results
    ) / (total * 2) * 10  # 10点満点に正規化

    return {
        "参加者数": total,
        "平均障害検知時間（秒）": round(avg_detection, 1),
        "平均MTTR（秒）": round(avg_recovery, 1),
        "根本原因特定率": f"{root_cause_rate:.1%}",
        "ランブック遵守率": f"{runbook_rate:.1%}",
        "平均自己評価スコア": f"{avg_self_score:.1f}/10",
        "目標達成": {
            "検知3分以内": avg_detection <= 180,
            "MTTR10分以内": avg_recovery <= 600,
            "自己評価80点以上": avg_self_score >= 8.0,
        },
    }

よくある間違い:

GameDayを「テスト」として捉え、参加者の失敗を評価材料にしてしまうケースがあります。GameDayの目的はシステムとプロセスの弱点発見であり、個人の評価ではありません。心理的安全性を確保し、「障害を見つけたら勝ち」という文化を醸成することが継続運営の鍵です。

GameDay運営のハマりポイントと対策

ZOZOの実践から得られた3つの教訓を共有します。

ハマりポイント 原因 対策
GameDayがスキップされがち 丸1日確保が難しい 午前1-2時間（実験）+ 夕方1時間（振り返り）に分割
改善タスクが放置される バックログに入れても優先度が上がらない 振り返り時点で優先度をつけ、スプリントプランニングに組み込む
負荷テスト環境で障害検知と負荷不足の区別がつかない ステージング環境の負荷が不十分 全プロダクトに同時負荷をかけるルールを設定

カオス実験をCI/CDパイプラインに統合する

成熟度モデルのAdoption段階では、カオス実験をCI/CDパイプラインに組み込み、デプロイごとに自動実行します。Google Cloudの公式ガイダンスでも「CI/CDパイプラインへの統合による実験実行の自動化」が推奨されています（InfoQ - Google Cloud CE）。

GitHub Actionsでカオス実験を自動化する

以下はGitHub ActionsでAWS FIS実験をデプロイ後に自動実行する例です。

# .github/workflows/chaos-test.yaml
name: Post-Deploy Chaos Test

on:
  workflow_run:
    workflows: ["Deploy to Staging"]
    types: [completed]

permissions:
  id-token: write
  contents: read

jobs:
  chaos-experiment:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsFISRole
          aws-region: ap-northeast-1

      - name: Wait for deployment stabilization
        run: sleep 120

      - name: Run AWS FIS experiment
        id: fis
        run: |
          EXPERIMENT_ID=$(aws fis start-experiment \
            --experiment-template-id EXT_AZ_FAILURE_STAGING \
            --query 'experiment.id' \
            --output text)
          echo "experiment_id=$EXPERIMENT_ID" >> "$GITHUB_OUTPUT"
          echo "FIS実験開始: $EXPERIMENT_ID"

      - name: Wait for experiment completion
        run: |
          aws fis wait experiment-completed \
            --id ${{ steps.fis.outputs.experiment_id }} \
            || true

      - name: Check experiment result
        run: |
          STATUS=$(aws fis get-experiment \
            --id ${{ steps.fis.outputs.experiment_id }} \
            --query 'experiment.state.status' \
            --output text)
          echo "実験結果: $STATUS"
          if [ "$STATUS" = "failed" ]; then
            echo "::error::カオス実験に失敗しました。システムが定常状態を維持できませんでした。"
            exit 1
          fi

      - name: Verify steady state post-experiment
        run: |
          # Prometheusクエリで定常状態を確認
          LATENCY=$(curl -s "http://prometheus:9090/api/v1/query?query=histogram_quantile(0.99,rate(http_request_duration_seconds_bucket[5m]))" \
            | jq -r '.data.result[0].value[1]')
          echo "p99レイテンシ: ${LATENCY}s"
          if (( $(echo "$LATENCY > 0.5" | bc -l) )); then
            echo "::error::SLO違反: p99レイテンシが500msを超過しています"
            exit 1
          fi

段階的な統合戦略

CI/CDへの統合は一度にすべてを自動化するのではなく、段階的に進めます。

フェーズ 実行タイミング 対象環境 自動化レベル
Phase 1 手動トリガー ステージング 実験実行のみ自動
Phase 2 デプロイ後自動実行 ステージング 実験+定常状態チェック自動
Phase 3 デプロイ後自動実行 カナリア環境 実験+チェック+ロールバック自動
Phase 4 定期スケジュール 本番環境 完全自動（Stop Conditions必須）

制約条件:

CI/CDパイプラインでのカオス実験は、Phase 3以降で本番環境に影響を与える可能性があります。必ずStop Conditions（AWS FIS）やセーフガード（Steadybit）を設定し、SLO違反を検知したら即座に実験を中止するメカニズムを組み込んでください。また、デプロイ直後は一時的にメトリクスが不安定になるため、安定化待ち時間（2-5分）を設けることが重要です。

よくある問題と解決方法

問題 原因 解決方法
FIS実験が即座にfailedになる IAMロールの権限不足 FIS実行ロールにec2:StopInstances等の必要権限を付与
Stop Conditionsが機能しない CloudWatchアラームが正しく設定されていない アラーム状態をテスト送信で事前確認
ステージングで成功するが本番で異なる挙動 ステージングと本番のトラフィックパターンが異なる 負荷テストツール（k6等）でリアルなトラフィックを再現
GameDayの参加率が下がる 業務優先で後回しにされる 経営層のサポートを得て「月次定例」として確保
実験結果から改善アクションが生まれない 振り返りが形骸化 KPIベースの定量評価 + バックログ直接登録
Gremlin/Steadybitのコスト正当化が難しい ROIが見えにくい MTTR改善・インシデント削減の数値で投資対効果を算出

まとめと次のステップ

まとめ:

  • カオスエンジニアリングの導入は成熟度モデル（Shadows→Investment→Adoption）に沿って段階的に進める
  • ツール選定は組織のクラウド環境に依存する。AWS中心ならAWS FIS、マルチクラウドならGremlinまたはSteadybitが有力
  • 定常状態仮説をSLI/SLOベースで設計することが実験成功の前提条件
  • 月次GameDayをKPIベース評価で運営し、改善タスクをスプリントに組み込むことで継続性を担保する
  • CI/CDパイプラインへの統合は4フェーズで段階的に進める

次にやるべきこと:

  1. 自組織のSLI/SLOを整理し、最も重要なサービスの定常状態仮説を1つ定義する
  2. Chaos ToolkitまたはAWS FISでステージング環境に最小実験を1つ実行する
  3. 実験結果をチームに共有し、月次GameDayの開催承認を取得する

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?