連携・顧客対応・アプリ配信の違いと使い分け

名前ではなく、仕事を待たせるのか、複数先へ知らせるのか、出来事の内容で振り分けるのかを基準に比較します。顧客や従業員へ提供するサービスも、受取先と利用形態を具体化して選びます。

この単元で学ぶこと

連携の要件をキュー・通知・イベントへ対応付ける
顧客や機器へ提供する通信サービスを比較する
Web・デスクトップ・アプリ配信の要件を区別する

本文解説

1. 比較の最初は受け手画像作成を担う同種のワーカーへ仕事を分担するのと、在庫・配送という別業務の両方へ出来事を知らせるのでは構成が違います。前者はSQSキューを複数ワーカーで処理する例、後者はSNSから複数キューへファンアウトする例です。「非同期にする」という言葉だけでは必要なコピー数や完了条件までは決まりません。

2. 待機と振分け処理側が後から受信するために依頼をためる役割はSQS、イベントの内容をルールと照合して複数の処理先へつなぐ役割はEventBridgeで比較します。EventBridgeのターゲットとしてSQSを置けば、振分けと後段の待機を組み合わせられます。サービスを一つ選んだら他を使えないという関係ではありません。

3. SNSとEventBridgeの重なりどちらも複数の処理先へつなぐ設計に使えます。SNSはトピックと購読、EventBridgeはAWSや外部・独自イベントのバスとパターンを中心に考えます。SNSにもメッセージフィルターがあるため、絞り込みの有無だけを唯一の違いにしません。対応する発生元・宛先、イベント管理の機能、配信要件を調べます。

4. 順序と二重実行 SQS Standardの少なくとも1回配信とベストエフォートの順序、FIFOのグループ内順序を区別します。例えば同一口座の順序が重要なら、その単位を明示して比較します。ただし、キュー種類や通知サービスの選択だけで外部の課金処理を一度だけにするわけではありません。業務IDを使い、再送に対する処理を設計します。

5. 人へ知らせる目的システムの状態を購読者へ知らせるSNS通知、顧客へ自社ドメインのメールを送るSES、電話やチャットを担当者へつなぐConnect Customerを分けます。どれも人へ情報を届け得ますが、顧客対応の流れやメール送信管理は同じ機能ではありません。問い合わせへの応答を扱うのか、メール送信基盤を必要とするのかを先に書き出します。

6. 機器とWebアプリセンサーがMQTTで送信する接続にはIoT Core、Webやモバイルのアプリ開発にはAmplifyを比較します。IoT Coreで取り込んだ測定値を後段へ送り、Amplifyで公開するWeb画面から閲覧する組合せもあります。通信入口を作ることと、どの利用者にどの測定値を見せるかという認証・認可は別の設計です。

7. 仮想環境の三つの焦点利用者がデスクトップ全体で作業するならWorkSpacesを比較します。特定のデスクトップアプリをAWS上で実行して画面を届ける用途はWorkSpaces Applications、社内WebやSaaSへのブラウザーアクセスに絞る用途はSecure Browserです。AppStream 2.0という試験資料の旧名を見たらApplicationsの用途へ対応付けます。画面がブラウザーに表示されるかだけでは三者の役割は決まりません。

8. 組合せを評価する注文受付からSNSで業務ごとのキューへ送り、各ワーカーが処理し、SESで確認メールを送る例では、各段階の失敗と重複を考えます。Web画面の公開方式は別にAmplify等で検討できます。サービス名の数を減らすことだけを目標にせず、必要な待機、受取先の独立性、権限、運用、料金を比較します。

図解

連携と利用環境を別の軸で比較する — 役割を分けた後に組み合わせます。機能の一部が重なることとサービス全体が同一であることは別です。

重要ポイント

仕事分担と複数業務へのコピー配信を描き分ける。
機能の重なりを認め、必要な連携条件で選ぶ。
画面の表示方法だけでWeb開発と仮想環境配信を混同しない。

間違えやすい点

SNSには内容フィルターがないという誤った二分法を使う。
FIFOを選べば外部の二重課金も起きないと断定する。

用語解説

仕事分担: 複数の同種ワーカーが待機中の依頼を分けて処理する構成。
受取先の独立性: ある業務の速度や失敗と別業務の処理を分けられる性質。
イベント駆動: 出来事の発生をきっかけとして後続の処理を起動する方式。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。