AWS SAA（Solutions Architect – Associate）で頻出の
「マイクロサービス間の連携方式」
に関する定番問題です。
この問題は、
処理を確実に“次のマイクロサービスへ引き渡す”には、
どのAWSサービスを使うべきか
を正しく理解しているかが問われています。
早速、問題を見ていきましょう
【問題】
大手出版社ではAmazon ECSを活用してマイクロサービス型のアプリケーションを構築しています。 このアプリケーションのアーキテクチャでは、マイクロサービス１とマイクロサービス２に分割し、マイクロサービス１の処理後にマイクロサービス２に処理が引き渡されます。
この要件を満たすマイクロサービス間連携の仕組みを選択してください。
【選択肢】
- マイクロサービス１からAmazon SNSによるメッセージ通知によって、マイクロサービス２に連携する。
- マイクロサービス１からAWS Lambda関数によるイベント処理によって、マイクロサービス２に連携する。
- マイクロサービス１からAmazon SWFによって、マイクロサービス２に連携する。
- マイクロサービス１からAmazon SQSによるキューイング処理によって、マイクロサービス２に連携する。
これから先は正解と解説になりますので、まずは考えてみてください。
【正解】
マイクロサービス1から Amazon SQS によるキューイング処理を行い、
マイクロサービス2がそのキューをポーリングして処理を行う。
マイクロサービス1
│ メッセージ送信
▼
Amazon SQS
│ ポーリング
▼
マイクロサービス2なぜ Amazon SQS が正解なのか？
この問題の本質は 「疎結合な非同期連携」 です。
SQS が最適な理由
① 確実な処理引き渡し
- メッセージはキューに 安全に保存
- コンシューマ（サービス2）が落ちても消えない
- 少なくとも1回配信（At-least-once）
② マイクロサービスの疎結合
- サービス1と2は直接通信しない
- スケール・障害が相互に影響しない
③ ECSとの相性が非常に良い
- ECSタスクが 並列にポーリング可能
- 負荷増加時に自然にスケール
👉 マイクロサービス連携の王道パターン
❌ なぜ他の選択肢は不正解？
❌ Amazon SNS
- SNS は プッシュ型の通知
- 主用途は「イベント通知」
- 処理の確実な引き渡し・順序・再試行管理が弱い
👉
標準構成は
SNS → SQS → 処理
であり、SNS単体は不十分。
❌ AWS Lambda を中継に使う
- メッセージング専用サービスではない
- SQS がある以上、冗長で非効率
- 試験では選ばせない
❌ Amazon SWF
- ワークフロー管理サービス
- 状態管理・長時間ジョブ向け
- マイクロサービス間メッセージング用途ではない
👉 完全に用途違い
🎯 試験での見抜き方（超重要）
問題文に次の表現が出たら即反応してください。
| 問題文のキーワード | 選ぶサービス |
|---|---|
| マイクロサービス間連携 | SQS |
| 処理を引き渡す | キュー |
| 疎結合 / 非同期 | SQS |
| 確実に処理 | SQS |
| イベント通知 | SNS |
👉 ECS × マイクロサービス × 連携 = SQS
📌 SNS と SQS の役割整理（試験頻出）
| サービス | 役割 |
|---|---|
| SNS | 「起きたことを知らせる」 |
| SQS | 「やるべき処理を貯める」 |
👉 処理連携は SQS
📌 まとめ（試験用一文）
ECS 上のマイクロサービス間で処理を確実に引き渡すには、
Amazon SQS を用いたキューイングによる非同期連携が最適である。
この問題は、
「通知」と「処理キュー」を混同していないか
をチェックする典型問題です。
- SNS → 知らせる
- SQS → 処理させる
この切り分けができていれば、
AWS SAA のマイクロサービス問題は即答レベルになります。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
