導入
既存システムのレビューでよく見つかる問題が、「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時にアクセス集中、など）にはスケジュールスケーリングを組み合わせることで、反応の遅れによる一時的な性能劣化を防ぎます。
具体例
ある決済サービスで「障害の連鎖」が起きました。外部の与信APIが一時的に重くなると、それを呼ぶ決済サービスの全スレッドが応答待ちで埋まり、決済サービスまで停止。さらにそれを呼ぶ注文サービスも詰まり、1箇所の遅延が全体に波及したのです。
レビューで、複数の信頼性テクニックを投入します。
- 指数バックオフ＋ジッター … 与信APIが失敗したとき、全クライアントが一斉に再試行すると二次的な過負荷になる。リトライ間隔を倍々に伸ばし、ランダムなばらつきを加えて再試行を分散（AWS SDKは標準実装）。
- サーキットブレーカー … 与信APIの失敗が続いたら、一定時間呼び出し自体を止めて即エラーを返す。下流の回復を妨げず、上流のスレッド枯渇も防ぐ。
- スロットリング … API Gatewayで秒間リクエスト数に上限を設け、過負荷時は一部を意図的に拒否して全体の可用性を守る。
- 疎結合化 … 同期呼び出しをSQSに置き換え、下流が遅くてもキューに溜まるだけにする。
SAPの思想は「何か1つを完璧に守る」のではなく「壊れる箇所を局所化し、全体を守る」。連鎖を断つこれらの手が繰り返し問われます。
読んでみよう
「特定サービスの遅延がシステム全体に波及するのを防ぎたい」は疎結合化とサーキットブレーカー、「アクセス集中時にリクエストが失敗しても全体は守りたい」はスロットリングが対応するキーワードです。SAPでは「何か1つを完璧に守る」より「壊れる箇所を局所化し、全体を守る」という設計思想が繰り返し問われます。