外部サービスの負荷増大時の影響を最小限にするための設計があるか？¶
Type: DeepDive
Category: パフォーマンス・スケーラビリティ
Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者
背景・概要¶
外部サービスに依存した機能は、相手側のパフォーマンス劣化や障害時の影響を最小限にする設計が求められる
フォールバック、リトライ制御、非同期化、サーキットブレーカーなどが代表的な対策
例¶
- 外部OCR(テキスト認識) APIに対し、3回までの指数的リトライを許容し、それ以上はローカルキューに退避(Google Pub/Sub、Amazon SQS、Azure Storage Queue、Redis、Cloud Tasks、RDBMSなどに蓄積)して再処理する
- SQS経由で非同期に送信し、送信結果は後続処理に影響しない設計に分離
- サーキットブレーカー（例：Hystrix）を導入し、外部障害が全体を巻き込まないように防衛する(外部APIを呼び出さず即座に失敗を返すなど)
よくある失敗例¶
- 外部サービスが遅延してレスポンス待ちのAPIが枯渇
- タイムアウトが無く永遠にリトライしてリソース枯渇
- 例外を握りつぶして意図しないサイレントフェイル
FAQ¶
Q. 障害を前提とした設計って何？
A. 外部サービスは必ずいつか落ちる。設計時点で「落ちたらどうする？」を先回りで想定することで、信頼性を高める
Q. 非同期処理すれば全部解決？
A. 非同期だけでは整合性やタイムリーなレスポンス保証はできない。業務要件によってはフォールバックや通知も必要