連携・顧客対応・アプリ配信のシナリオ判断

注文処理、機器の測定、顧客との連絡、従業員の作業環境という事例でサービスの役割を選びます。計算では到着・完了・コピー配信のどれを数えているかを明示し、再送を業務の二重実行にしない判断も練習します。

この単元で学ぶこと

数量と受取先を明示して連携構成を評価する
障害・再試行・時間起動の条件を判断する
顧客・機器・Web・仮想環境の用途をシナリオへ適用する

本文解説

1. 二つの業務へ同じ注文店舗が受けた注文を在庫引当てと配送準備の両方へ知らせるなら、二つの業務へ各通知が必要です。SNSから業務別SQSへ送る例では、在庫の一時停止中も配送側のキューは独立して処理できます。各業務の中でワーカーを増やすことと、二業務へコピーを送ることは、数える単位が違います。

2. 配信数と滞留を計算する 120件の注文を二つのキューへ一度ずつ配信する理想化した条件なら、総配信は240件です。一方、初期0件のキューに毎分60件が入り毎分45件を完了する8分間では、未完了は120件増えます。前者はコピー数、後者は到着から完了を引いた残りです。実環境は重複や失敗を別に含めて観測します。

3. 失敗が起きた場所 SNSへの発行成功、SQSへの到達、ワーカーの受信、外部業務の成功、SQSからの削除は異なる段階です。外部課金後にワーカーが停止して削除できなければ、再受信に備えて課金済みを判断します。DLQに依頼を隔離した場合も、形式を直しただけで再実行してよいか、既実行の効果を確認します。

4. 到着した出来事と予定注文取消しが発生したら後段へ送る処理はイベント内容によるルールで考えます。毎朝9時に集計を呼ぶ処理はScheduler等の予定です。朝の呼出しが遅れて再試行された場合も、同じ日付の集計を重複確定しない設計が必要です。呼出しが行われた時刻と、集計結果が利用可能になる時刻を分けます。

5. 顧客の連絡を分ける注文確認メールの送信基盤はSES、電話やチャットの問合せを担当者へつなぐ環境はConnect Customerという役割で比較します。システム状態を購読者へ知らせるSNSとも区別します。例えば注文メールを送った後で顧客が電話したなら、メール配信の仕組みだけでは担当者へのルーティング全体を提供したことになりません。

6. 測定値を閲覧させる工場のセンサーがIoT CoreへMQTTで値を送り、後段が保存・処理し、Webアプリが利用者に見せる構成を考えます。AmplifyはWeb・モバイルのアプリ開発や公開を支援する側です。機器が送信できることと、他工場の利用者にデータを見せてよいかは別なので、機器と人の権限を分けます。

7. 従業員の環境を選ぶ利用者専用のデスクトップを求めるならWorkSpaces Personal、既存デスクトップアプリをAWS上で実行して配信するならWorkSpaces Applicationsを比較します。Secure Browserは社内WebやSaaSへのブラウザーアクセスに絞った用途です。Personalの永続性をWorkSpacesの全方式へ一般化せず、Pools等の方式との違いも確認します。

8. 判断を一つの語に依存させない「非同期」「Serverless」「ブラウザーから使う」といった言葉は複数サービスに当てはまります。対象が依頼か出来事か、同じ通知を誰へ何個渡すか、保存・順序・再試行・認証はどうするかを書き出すと比較が具体的になります。サービスの採用後も、業務完了を観測する場所と費用に含める通信・実行・保存を確認します。

図解

注文一件を段階別に追う — 電話対応や従業員の作業環境は、注文メッセージの配信とは別の要件として比較します。

重要ポイント

コピー配信の総数と未完了の滞留数を区別する。
障害が起きた段階と既実行の効果を確認する。
用途・対象・必要な保証から選び、共通する形容だけに頼らない。

間違えやすい点

SNS発行成功をすべての業務の成功と考える。
DLQから再送すると既実行の効果が消えると考える。

用語解説

滞留: 受け付けたものの処理を完了していない依頼がたまった状態。
業務ID: 注文番号等、業務上同じ処理対象を識別する値。
配信と処理: 情報が宛先へ届くことと、宛先で業務効果を確定することの区別。

参考資料

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

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