可用性とレジリエンス

可用性（Availability）とは、システムが期待される時間内に正常に動作し続ける能力を指す。SLA（Service Level Agreement）はサービス提供者と利用者の間の合意であり、SLO（Service Level Objective）はそのSLAを達成するための内部目標値、SLI（Service Level Indicator）はSLOの達成度を測定する実際の指標となる。たとえばSLIが「レスポンスタイム」であり、SLOが「95パーセンタイルで200ms以内」、SLAが「99.9%の稼働率保証」という関係になる。

レジリエンス（Resilience）は障害が起きたとしても全体が崩壊せずに復旧できる性質を指す。マイクロサービス環境では一つのサービスの障害が連鎖してシステム全体を巻き込む「カスケード障害」が発生しやすい。これを防ぐためにサーキットブレーカーパターン、バルクヘッドパターン、タイムアウト設計といったパターンを組み合わせることが重要である。

RPO（Recovery Point Objective）は「障害発生時にどの時点までのデータを失うことを許容するか」を示す目標値であり、RTO（Recovery Time Objective）は「障害発生からサービス復旧までの目標時間」を示す。これらはビジネス要件から逆算して設計に反映する必要がある。

コードレビューで着目するポイント

サーキットブレーカーが正しい状態遷移（Closed/Open/Half-Open）で実装されているか
リトライ処理に指数バックオフ（Exponential Backoff）とジッター（Jitter）が組み込まれているか
バルクヘッドパターンにより、一つの依存サービスの障害が他のスレッドプールを枯渇させない構造になっているか
タイムアウトが全ての外部呼び出しに設定されているか（デフォルトのタイムアウトなし設定は危険）
フォールバック戦略が実装されているか（キャッシュからの返却・デグレード応答など）
ヘルスチェックエンドポイントが依存サービスの状態も反映しているか
カオスエンジニアリングの実施計画（Chaos Monkey 等）があるか

典型的なアンチパターン

リトライストーム: 障害発生時に全クライアントが一斉にリトライすることで、回復しかけているサービスへの負荷が再び急増する現象。指数バックオフとジッターを組み合わせて、リトライのタイミングを分散させなければならない。

タイムアウト未設定: 外部 API 呼び出しやデータベースクエリにタイムアウトを設定しないと、一つの遅延がスレッドを長時間占有し続け、最終的にシステム全体がリソース枯渇で応答不能になる。

サーキットブレーカーなしの依存: 下流サービスが障害を起こしているのに上流が延々とリクエストを投げ続けると、障害が上流にも伝播する。サーキットブレーカーで「あきらめる」判断を自動化することでカスケード障害を防ぐ。

参考リソース

書籍: 「Release It!」（Michael T. Nygard） - 本番運用で起きる障害パターンとレジリエンス設計の実践書
ツール: Resilience4j - Java/Kotlin 向けサーキットブレーカーライブラリ
ツール: Polly - .NET 向けレジリエンスパターンライブラリ
ツール: Chaos Monkey - Netflix 発のカオスエンジニアリングツール
標準: Google SRE Book - SLA/SLO/SLI の設計に関するGoogleの実践知