「アクセスが急増してバックエンドの処理が追いつかず、システム全体がダウンしてしまった⋯⋯」
「一部の機能がエラーになったせいで、注文処理全体が失敗してしまった⋯⋯」
そんな悪夢を終わらせるための設計思想、それが「疎結合」です。
私は模擬試験で「注文を受け付けるフロントエンドと、処理を行うバックエンドをどう繋ぐのがベストか？」と問われ、「直接APIで通信すればいいのでは？」と考えました。しかし、それだと一方が倒れた時にもう一方も巻き添えを食らいます。正解は、間に「伝言板（メッセージキュー）」であるAmazon SQSを挟むことでした。
Amazon SQSがもたらす「ゆとり」の設計
SQSは、メッセージ（データ）を一時的に預かってくれる、フルマネージドな「待ち行列（キュー）」サービスです。
- バッファ（緩衝材になる）
フロントエンドが秒間1000件の注文を受けても、バックエンドが秒間100件しか処理できなければ、SQSがその差分を預かってくれます。 - 非同期処理の実現
「注文を受け付けたら、あとはSQSに入れておしまい」とすることで、フロントエンドは即座にユーザーへレスポンスを返せます。 - 障害の隔離
バックエンドが一時的に静止しても、メッセージはSQSに残り続けるため、復旧後に処理を再開できます。データが消える心配はありません。
試験で必ず問われる「標準キュー」と「FIFOキュー」
SQSには2つのタイプがあります。この使い分けはSAA試験の超頻出項目です！
| 特徴 | 標準キュー（Standard） | FIFOキュー |
| スループット | ほぼ無制限 | 最大3,000件/秒（バッチ時） |
| 配信の順序 | ベストエフォート（入れ替わる可能性あり） | 送信順を厳格に守る |
| 配信の回数 | 少なくとも1回（重複の可能性あり） | 正確に1回だけ |
| 用途 | 順序を問わない大量のログ処理など | 銀行取引、在庫管理など順序が重要なもの |
「可視性タイムアウト」の罠に注意！
試験でよく出るテクニックが「可視性タイムアウト」の調整です。
メッセージを処理している最中に、他のワーカーが同じメッセージを拾わないようにする「ロック期間」のことです。処理に時間がかかる場合は、この値を適切に伸ばす必要があります。
試験で役立つ！キーワード判別法
システムの安定性や連携の問題で、以下の言葉があればAmazon SQSが正解です。
- 「疎結合（Decoupling）なアーキテクチャ」
- 「非同期処理（Asynchronous processing）」
- 「トラフィックの急増（バースト）を吸収したい」
- 「メッセージの順序を保証したい」→SQS FIFO
今回の学び：攻略の格言
「直接つながず、SQSを挟め！順序が命ならFIFOを選び、可視性タイムアウトで二重処理を防げ！」
あとがき：一歩ずつ合格へ
最後まで読んでいただき、ありがとうございました！
連載もついに20回。最初は「設定項目が多いな」と感じていたAWSも、こうして「なぜこのサービスを使うのか？」という背景がわかってくると、パズルを解くような楽しさに変わってきますね。
SQSを使いこなせるようになると、単なる「動くシステム」ではなく、「変化に強く、壊れにくいプロフェッショナルなシステム」が設計できるようになります。
それでは、次回の記事でお会いしましょう！
