ある企業が、マイクロサービスアーキテクチャを採用して複数の API を Amazon API Gateway と AWS Lambda で運用している。各サービスは互いを直接同期的に呼び出すことがあり、依存先サービスの障害が連鎖してシステム全体がダウンするカスケード障害が発生した。カスケード障害を防ぎ、弾力性を向上させる設計を 2 つ選択してください。
- A. Lambda 関数のタイムアウト値を最大値（15 分）に設定して依存サービスの応答を長時間待機できるようにする。
- B. サービス間の同期呼び出しの代わりに Amazon SQS キューまたは Amazon SNS を経由した非同期メッセージングに切り替え、依存サービスの障害が呼び出し元に伝播しないようにする。
- C. 全サービスを単一の Lambda 関数に統合して依存関係をなくす。
- D. Amazon CloudWatch でサービスごとのエラー率を監視し、エラー率が高いサービスのLambda 関数のメモリを増やして処理能力を向上させる。
- E. API Gateway の統合タイムアウトとサーキットブレーカーパターンを実装する。依存サービスへの呼び出しが一定回数失敗した場合は即座にフォールバックレスポンスを返し、回路を「Open」状態にして一定時間後に再試行する。
解答と解説を見る
正解: B, E
カスケード障害を防ぐには、(1) 同期依存の排除と (2) サーキットブレーカーパターンが有効である。選択肢Bの非同期メッセージング（SQS/SNS）への切り替えにより、依存サービスが一時的に停止していてもメッセージをキューに蓄積し、サービス復旧後に処理できる。呼び出し元はキューへの送信成功で即座に応答を返せるため、依存先の障害が伝播しない。選択肢Eのサーキットブレーカーパターンは、連続した失敗を検知すると回路を「Open」にして依存サービスへの呼び出しを即座にフォールバックに切り替え、依存サービスの回復時間を確保しながら呼び出し元も正常に動作させる。選択肢Cはすべてを1関数に統合しており、スケーラビリティとデプロイの柔軟性を失うマイクロサービスの原則に反する。選択肢Aのタイムアウト延長は待ち時間を増やすだけでカスケード障害を悪化させる可能性がある。Lambda のコスト増にもなる。選択肢DのLambda メモリ増加は依存サービスの障害には効果がなく、カスケード障害の解決策にならない。
📚 関連サービスの解説: Amazon SQS ・ Amazon SNS