要点: 分散システムの信頼性は、安全な範囲で前提を意図的に壊して検証します。
この記事の用語: Contract Test：サービス間の約束を検証するテスト。Chaos Engineering：制御された障害で仮定を検証する手法。
現場の課題
テスト環境は本番と同じではありません。Mockはプロトコル差を隠し、E2E テストは遅く不安定です。再試行、ネットワーク遅延、複数バージョン共存時だけ起きる障害もあります。
単純な対策だけでは不十分な理由
テスト環境だけで本番を完全再現できません。低層の決定的テスト、サービス境界のContract Test、制御された障害注入、本番構成のCanaryを組み合わせます。
処理フロー
Contract Test
Compatibility→構成要素 テスト
Real 依存サービス→障害注入
Partial Fault→本番検証
Canary・SLO
Compatibility→構成要素 テスト
Real 依存サービス→障害注入
Partial Fault→本番検証
Canary・SLO
アーキテクチャ上の判断
ネットワーク下の不変条件 テスト
状態機械と冪等性をProperty テストします。
所有責任 Boundary Contract
エラー・Compatibilityも検証します。
Progressive 本番検証
Shadow、Canary、フラグ、SLO ゲートを使います。
さらに深く考える
テスト データもArchitecture
代表データを安全に用意します。
Game DayはPeopleもテスト
Role、運用手順書、Communicationを訓練します。
実装手順
- 状態遷移と不変条件を、結果が毎回同じになるテストで検証します。
- 提供側とコンシューマーのContractを、実際のシリアライズ済みデータで確認します。
- テスト環境とCanaryで障害を注入し、顧客体験を表すSLOで判断します。
コード例: Controlled Chaos 実験
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 actionsFault、Scope、中止をReviewed 自動化で再現可能にします。
想定しておく障害
- Mockが実提供側と違います。
- 再試行が不安定なを隠します。
- 別障害対応中にChaosします。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| 不安定な・再試行-to-pass | Suite信頼性です。 |
| Contract 失敗 | デプロイ前Driftを検出します。 |
| Canary SLO・ロールバック時間 | 本番検証効果です。 |
設計の検証方法
- 実スキーマでFixtureを検証します。
- Duplicate、Delay、Timeout等を注入します。
- Known-bad Canaryの一時停止・ロールバックを測ります。
本番導入の進め方
重要な業務フローとリスクをテスト層へ対応付け、不安定なテストを先に安定化します。読み取り専用の内部実験から始め、中止条件とSLOを持つ小さなCanaryへ広げます。
本番前チェックリスト
- Critical 依存サービスに失敗 テストがあります。
- ChaosにHypothesis、Scope、中止、担当者があります。
- Canaryと障害対応が同じメトリクスを使います。
まとめ
テスト環境は本番を証明できません。多層戦略によって、本番変更を小さく、観測可能で、戻しやすくします。