導入
既存システムのレビューでよく見つかる問題が、「1箇所が落ちるとシステム全体が落ちる」という単一障害点（SPOF）と、「負荷が集中すると連鎖的に全体が詰まる」という設計です。ここでは、信頼性を改善する具体的なテクニックを見ていきます。
説明
信頼性改善の代表的な観点を整理します。
| 観点 | 問題 | 改善策 |
|---|---|---|
| SPOF | 1インスタンス・1AZ・1リージョンに依存 | Multi-AZ、Auto Scaling、マルチリージョン化（第7章） |
| 密結合 | 呼び出し元が呼び出し先の遅延に引きずられる | SQS/SNS/EventBridgeによる非同期化 |
| 過負荷の連鎖 | 下流サービスの過負荷が上流に波及し全体停止（障害の連鎖） | スロットリング・リトライ・サーキットブレーカー |
| スケーリングの遅れ | 急激な負荷増にAuto Scalingの反応が追いつかない | スケーリングポリシーの見直し、事前スケジュールスケーリング |
flowchart LR
C["呼び出し元"] -->|"リトライ（指数バックオフ+ジッター）"| S["下流サービス"]
S -->|"過負荷時は429/エラーを返す"| TH["スロットリング"]
C -->|"連続失敗を検知したら遮断"| CB["サーキットブレーカー"]
- 指数バックオフ＋ジッター: リトライ間隔を毎回倍々に伸ばし（指数バックオフ）、さらにランダムなばらつき（ジッター）を加えることで、多数のクライアントが同時に再試行して二次的な過負荷を起こすのを防ぐ。AWS SDKは標準でこの方式を実装している。
- スロットリング: API Gatewayなどで「1秒あたりのリクエスト数」に上限を設け、過負荷時は一部リクエストを意図的に拒否してシステム全体の可用性を守る。
- サーキットブレーカー: 下流サービスの失敗が続いたら、一定時間呼び出し自体を止めて即座にエラーを返す。下流の回復を妨げず、上流のリソース枯渇も防ぐ。
Auto Scalingの見直しでは、ターゲット追跡スケーリング（CPU使用率等を一定に保つよう自動調整）に加え、予測可能なトラフィックの波（毎朝9時にアクセス集中、など）にはスケジュールスケーリングを組み合わせることで、反応の遅れによる一時的な性能劣化を防ぎます。
読んでみよう
「特定サービスの遅延がシステム全体に波及するのを防ぎたい」は疎結合化とサーキットブレーカー、「アクセス集中時にリクエストが失敗しても全体は守りたい」はスロットリングが対応するキーワードです。SAPでは「何か1つを完璧に守る」より「壊れる箇所を局所化し、全体を守る」という設計思想が繰り返し問われます。