Kubernetes環境におけるカオスエンジニアリング実装と回復弾力性検証

深夜2時、PagerDutyのアラートが鳴り響きます。原因はデータベースのCPUスパイクではなく、重要度の低いサードパーティAPIの応答遅延でした。たった200msのレイテンシ増加が、メインサービスのコネクションプールを枯渇させ、連鎖的な障害（Cascading Failure）を引き起こし、システム全体をダウンさせました。このシナリオは、単体テストや統合テストでは決して検出できません。分散システムの不確実性に対処するには、カオスエンジニアリングの原則と4段階実験プロセスに基づいた、プロアクティブな障害注入が必要です。

定常状態の定義と仮説の構築

カオスエンジニアリングは、単に本番環境でサーバーをランダムに再起動することではありません。科学的な実験プロセスです。まず、システムが正常に動作している状態、すなわち「定常状態（Steady State）」を定義する必要があります。これには、スループット、エラー率、レイテンシ（P95, P99）などのゴールデンシグナルを用います。

爆発半径（Blast Radius）の制御
実験は常に最小限の影響範囲から開始します。最初は単一のカナリアインスタンス、次に特定のAZ（アベイラビリティゾーン）、最終的にリージョン全体へと拡大します。Netflix Chaos Monkey導入事例が示すように、制御不能な実験は顧客体験を損なうリスクがあります。

Kubernetes環境でのChaos Mesh活用

コンテナオーケストレーション環境、特にKubernetesにおいては、Podのライフサイクルは揮発的です。ここでは、CNCFのサンドボックスプロジェクトであるChaos Meshを使用して、ネットワークレイヤーでの障害をシミュレーションします。

以下のマニフェストは、`payment-service`というラベルを持つPodに対して、100ミリ秒のネットワーク遅延を注入する実験定義です。これにより、依存サービスがタイムアウト設定を適切に処理できるか、リトライストーム（Retry Storm）が発生しないかを検証します。

# NetworkChaos定義: 決済サービスへのレイテンシ注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-latency-injection
  namespace: chaos-testing
spec:
  action: delay
  mode: one # 対象Podの選択モード（one, all, fixedなど）
  selector:
    namespaces:
      - default
    labelSelectors:
      "app": "payment-service"
  delay:
    latency: "100ms"
    correlation: "100" # 遅延の相関関係（100%のパケットに影響）
    jitter: "10ms"     # ネットワークの揺らぎを再現
  duration: "300s"     # 実験継続時間
  scheduler:
    cron: "@every 10m" # 定期実行スケジュール

マイクロサービス障害分離テストとGameDayの運営

実験を実施する日を「GameDay」と呼びます。GameDayの目的は、障害発生時のチームの対応能力を確認し、システムが想定通りにフォールバック（Fallback）するかを確認することです。

例えば、推奨エンジン（Recommendation Service）がダウンした場合、eコマースサイトのトップページは「500 Internal Server Error」を返すべきではありません。「人気の商品」リストが表示されないだけで、検索や購入機能は維持されるべきです。これをマイクロサービス障害分離（Fault Isolation）と呼びます。

実験シナリオ設計のチェックリスト

  • 仮説: 推奨エンジンが応答しない場合でも、トップページのロード時間は2秒以内である。
  • 注入: Chaos Meshを使用し、推奨サービスのPodを強制終了（PodKill）、またはパケットロス（PacketLoss）を発生させる。
  • 計測: Prometheusでフロントエンドのレイテンシとエラートレートを監視。
  • 判定: サーキットブレーカー（Circuit Breaker）が作動し、デフォルトのコンテンツが配信されたか？
比較項目 従来のテスト手法 カオスエンジニアリング
対象 既知の条件（Happy Path, Edge Cases） 未知の障害条件（Network Partition, Resource Exhaustion）
環境 ステージング、QA環境 本番環境（理想的）、またはそれに近い環境
目的 機能要件の確認 システム全体の回復力（Resilience）の証明
アプローチ バイナリ判定（Pass/Fail） システムの振る舞いの探求と学習

アプリケーション層での回復力実装

インフラレベルでの障害注入に対して、アプリケーションコードが防御的である必要があります。以下はGo言語を用いた、外部サービス呼び出しに対するサーキットブレーカーパターンの実装例です。単純なタイムアウト設定だけでは不十分であり、障害が検知された場合は即座に遮断してシステムリソースを保護する必要があります。

// GoでのHystrixライクなサーキットブレーカー実装パターン
// 外部依存サービスの障害時にFail-Fastを行う

import (
    "github.com/sony/gobreaker"
    "io/ioutil"
    "net/http"
    "time"
)

var cb *gobreaker.CircuitBreaker

func init() {
    var st gobreaker.Settings
    st.Name = "InventoryService"
    st.MaxRequests = 5                // 半開(Half-Open)状態で許可するリクエスト数
    st.Interval = 60 * time.Second    // エラーカウントをクリアする間隔
    st.Timeout = 30 * time.Second     // OpenからHalf-Openに遷移するまでの待機時間
    
    // トリップ条件: リクエスト数が一定以上かつエラー率が60%を超えた場合
    st.ReadyToTrip = func(counts gobreaker.Counts) bool {
        failureRatio := float64(counts.TotalFailures) / float64(counts.Requests)
        return counts.Requests >= 10 && failureRatio >= 0.6
    }

    cb = gobreaker.NewCircuitBreaker(st)
}

func GetInventory(itemID string) (string, error) {
    // Execute内で保護された呼び出しを行う
    body, err := cb.Execute(func() (interface{}, error) {
        resp, err := http.Get("http://inventory-service/items/" + itemID)
        if err != nil {
            return nil, err
        }
        defer resp.Body.Close()
        
        if resp.StatusCode >= 500 {
            return nil, fmt.Errorf("server error")
        }
        
        return ioutil.ReadAll(resp.Body)
    })

    if err != nil {
        // Fallbackロジック: キャッシュデータの返却やデフォルト値の設定
        return "Stock info unavailable", nil 
    }

    return string(body.([]byte)), nil
}

自動化の罠
カオス実験をCI/CDパイプラインに組み込むことは最終目標ですが、初期段階では手動実行（Manual Execution）を推奨します。可観測性（Observability）が不十分な状態で自動化すると、原因不明のビルド失敗やデプロイ遅延を引き起こし、開発チームの生産性を著しく低下させる可能性があります。

信頼性の高いシステムとは、障害が発生しないシステムではなく、障害が発生しても機能を維持し、自己修復できるシステムです。MTBF（平均故障間隔）の延長に固執するのではなく、カオスエンジニアリングを通じてMTTR（平均復旧時間）を短縮することに注力してください。本番環境は常に変化しており、今日の安定が明日の安全を保証するものではありません。

Related Posts

Loading…

Post a Comment