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