分散システムをContract TestからCanaryまで検証する

要点: 分散システムの信頼性は、安全な範囲で前提を意図的に壊して検証します。

この記事の用語: Contract Test：サービス間の約束を検証するテスト。Chaos Engineering：制御された障害で仮定を検証する手法。

現場の課題

テスト環境は本番と同じではありません。Mockはプロトコル差を隠し、E2E テストは遅く不安定です。再試行、ネットワーク遅延、複数バージョン共存時だけ起きる障害もあります。

テスト環境だけで本番を完全再現できません。低層の決定的テスト、サービス境界のContract Test、制御された障害注入、本番構成のCanaryを組み合わせます。

設計と実装

1. 状態遷移と不変条件を、結果が毎回同じになるテストで検証します。
2. 提供側とコンシューマーのContractを、実際のシリアライズ済みデータで確認します。
3. テスト環境とCanaryで障害を注入し、顧客体験を表すSLOで判断します。

実装例

hypothesis: checkout SLO remains healthy when one payment replica fails
scope: 5% internal canary traffic
inject: terminate one replica for 10 minutes
abort: error budget burn > threshold or queue age > limit
observe: retries, bulkhead, p99, duplicate charges
record: result, gaps, owner actions

本番導入の進め方

重要な業務フローとリスクをテスト層へ対応付け、不安定なテストを先に安定化します。読み取り専用の内部実験から始め、中止条件とSLOを持つ小さなCanaryへ広げます。

まとめ

テスト環境は本番を証明できません。多層戦略によって、本番変更を小さく、観測可能で、戻しやすくします。