週8ElastiCache / SQS / SNS
2026-09-22（火）ElastiCache, SQS, SNS
1. 【この範囲の全体像】
本範囲は、クラウドデザインにおいて最も重要な設計思想である 「 疎結合（デカップリング） 」 と 「 非同期処理 」 の基本概念を学ぶ、アプリケーションアーキテクチャの根幹エリアです [p.218, p.291]。
システムを構成するコンポーネント同士の直接的な依存関係を排除し、メッセージを仲介させることで、一部の障害が全体へ連鎖するのを防ぎます [p.218, p.291]。
試験では、個別のサービス機能（SQSやSNSなど）を学ぶ前段階として、「なぜ密結合を避け、疎結合アーキテクチャに設計すべきなのか」という設計原則の意図が厳格に問われます [p.218, p.291]。
2. 【重要キーワード・サービス一覧】
| キーワード | 説明 |
|---|---|
| 密結合（Tightly Coupled） [p.69, p.218] | システムコンポーネント同士が直接通信し、互いの稼働状態や処理速度に強く依存している状態。片方の遅延やシステムエラーが、呼び出し元のシステムに即座に波及（共倒れ）するため、耐障害性やスケーラビリティが著しく低下します [p.218]。 |
| 疎結合（Loosely Coupled / デカップリング） [p.218, p.291] | コンポーネント間にメッセージングサービス等を挟み、互いの仕様や動作状態を直接意識せずに通信できるようにした設計状態 [p.218, p.291]。一方のシステムがメンテナンスや被災で停止していても、もう一方は何の影響もなく独立して動き続けることができます [p.218]。 |
| 同期処理（Synchronous Processing） [p.218] | リクエストを送信したコンポーネントが、受信側からの「処理完了レスポンス（応答）」を完全に受け取るまで、次の処理に進まずにその場でスレッドを待機させる通信方式 [p.218]。 |
| 非同期処理（Asynchronous Processing） [p.218] | リクエストをキューなどの一時保管場所に送信した時点で送信側は処理を終了し、受信側の処理完了を待たずに次の動作へと即座に進む通信方式 [p.218]。突発的なスパイク負荷をバッファリングし、時間的に平滑化できます [p.218, p.220]。 |
| イベント駆動（Event-Driven） [p.78, p.146] | リソースの状態変化（例：S3へのファイル保存やDBのデータ更新）を「イベント（トリガー）」として検知し、それを契機として別のサーバーレス関数（Lambda等）が非同期に自律起動して処理を行うリアクティブな設計手法 [p.78, p.146]。 |
3. 【試験で問われる比較ポイント】
アプリケーション通信モデルの決定境界：同期通信 vs 非同期通信 [p.218]
「送信側が即時の戻り値を必要とするか」と「システムの可用性」を天秤にかけて選択します [p.218]。
| 比較項目 | 同期通信（密結合の典型） [p.218] | 非同期通信（疎結合の典型） [p.218, p.291] |
|---|---|---|
| 処理の連動性 | 送信側と受信側が同時に稼働している必要がある [p.218]。 | 送信側と受信側は完全に時間的・空間的に分離される [p.218, p.220]。 |
| 障害発生時の影響 | 受信側がダウンすると、送信側もAPIエラーを吐き、システム全体が即座に停止（共倒れ） する [p.218]。 | 受信側がダウンしていてもメッセージはバッファ（SQS等）に安全に保持され、復旧後に自動処理が再開される [p.218, p.220]。 |
| スケーラビリティ | 受信側の処理スループットがシステム全体のパフォーマンス限界となる。 | バッファを挟むことで、送信側と受信側が互いの処理速度に縛られず、それぞれ独立して自動スケーリングできる [p.218, p.220, p.291]。 |
| 決定的な選定シグナル | 🎯 「 ECサイトのクレジットカード決済成否判定のように、結果を即座にユーザー画面に同期的に返却する必要がある処理 」 | 🎯 「 注文の確定処理、重い動画のエンコード、メール一斉送信など、受付さえ終われば、裏で順次ゆっくり等速処理されればよいバッチ 」 [p.220]。 |
4. 【ひっかけ注意ポイント】
ひっかけ①：「ユーザーへの即時応答（リアルタイムレスポンス）」が必要な画面処理に、何でもかんでも「非同期キュー（SQS）」を提案する罠 [p.218, p.220]
- 罠: 「Webアプリにおいて、ユーザーが『残高照会ボタン』をクリックした際、Webサーバーの負荷を下げて疎結合にするため、リクエストを一度SQSキューに送信し、後段のワーカーが非同期で取得して画面に返す設計にした。」
- なぜ間違いか: ユーザーが画面の前で処理結果（戻り値）を待っているような即時応答が絶対条件のユースケースに非同期処理（SQS）を挟むと、ユーザー側は「いつデータが返ってくるか分からない（応答を受け取れない）」状態になり、Webシステムとして機能しません [p.218]。
- ベストプラクティス: 即時応答が求められる読み取り（参照）やリアルタイムAPIは 同期処理（およびElastiCache等のインメモリキャッシュによる超高速応答） で設計し [p.149, p.218]、動画変換やCSVレポート出力などの「即時の画面反映が不要で、バックエンドで順次実行されればよい重いバッチ処理」にのみ 非同期キュー（SQS） を指定して厳密に切り分けます [p.220]。
ひっかけ②：非同期に疎結合化（デカップリング）すれば、「単一処理にかかる時間（遅延）」が100%短縮・最小化されるという誤解 [p.218]
- 罠: 「社内システムにおける特定の大量トランザクション処理の『完了スピード自体』を極限までミリ秒単位に高速化（応答遅延を最小化）するため、システム間にSQSキューを配備してシステム全体を非同期化した。」
- なぜ間違いか: 疎結合（非同期キューイング）の主たる目的は「耐障害性の向上」と「負荷の平滑化（バッファリング）」です [p.218, p.291]。メッセージをキューに一度書き込み（送信）、それをワーカーがポーリングして読み出す（受信）という中継ステップが物理的に増えるため、単一のデータ処理が完了するまでの時間（レイテンシー）は、同期的にダイレクト処理するよりもむしろ増加（遅延） します。
- ベストプラクティス: 遅延自体の短縮（超高速化）が最優先要件である場合は、非同期キューではなく、インメモリキャッシュ（ElastiCache/DAX）の配置や、コンピューティングリソースの垂直拡張（スケールアップ）を指定します [p.58, p.147, p.149, p.291]。
5. 【一問一答セルフテスト】
選択肢を選ぶと、その場で正誤と解説が表示されます。