翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 非同期通信 逆に、非同期通信では、クライアントはサービスにリクエストを発行しますが、すぐには応答を受け取りません。この場合、クライアントは通常、リクエストが承諾されたという確認のみを受け取ります。 非同期通信の利点は次のとおりです。 + **イベント駆動型アーキテクチャのサポート** – イベントソーシングとコマンドクエリの責任分離 (CQRS) パターンに自然に適合します。 + **リソース管理の向上** – サービスではキャパシティに基づいてリクエストを処理できます。 + **障害分離の向上** – サービスのデカップリングにより、カスケード障害を防止します。 + **ピーク負荷処理** – メッセージキューイングによりトラフィックスパイクの処理を改善します。 欠点には複雑である点が含まれます。例えば、次のようになります。 + クライアントが非同期オペレーションの結果を必要とする場合、その結果を取得または受信するメカニズムを実装するには、より多くの労力が必要です。 + 非同期オペレーションのトラブルシューティングは、複数のシステムにわたるログを調べる必要があるため、より困難になる場合があります。 + テストには複数のシステムやサービス間の調整が必要なため、非同期オペレーションのテストはより難しい場合があります。 非同期通信へのアプローチには、ファイアアンドフォーゲット、クレームチェック、コールバック、双方向通信などがあります。 ## ファイアアンドフォーゲット ファイアアンドフォーゲットパターンでは、クライアントはサーバーにリクエストを発行し、サーバーがメッセージを受信して処理することを示す確認を同期的に受け取ります。ただし、実際の処理はまだ行われておらず、クライアントはいつどのように行われるかを把握できません。次の図は、このパターンを示したものです。 ![非同期通信におけるファイアアンドフォーゲットのパターン。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-integrating-microservices/images/fire-and-forget.png) この場合、オブジェクトが永続的に保持されるまで、サービスは確認を送信**しません**。この永続性は、データベース書き込みオペレーションとして実装することも、キューに項目を配置することで実装することもできます。 追加の考慮事項: + 重複したメッセージを処理するべき等性を実装します。つまり、各メッセージの処理は 1 回だけで済ませます。 + 処理に失敗した場合は[デッドレターキュー](https://aws.amazon.com/what-is/dead-letter-queue/)を検討してください。 + メッセージ処理の成功率をモニタリングします。 ## クレームチェック クライアントがサービス呼び出しの結果を必要とする場合は、リクエストを受信したときに*クレームチェック*を発行するようにサービスを構築できます。次の図は、このパターンを示したものです。クレームチェックは、サービスが確認で返す識別子として実装されます。クライアントは後でこの識別子を使用して、リクエストのステータスを確認し、リクエストの完了時に結果を取得できます。 ![非同期通信のクレームチェックパターン。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-integrating-microservices/images/claim-check.png) クライアントは、結果をポーリングするメカニズムを実装する必要があります。これは、自動化することも (例えば、*n* 分ごとにチェックを実行することもできます)、手動で実装することもできます。後者の場合、チェックは別のイベントやユーザーアクションに応答して実行されます。クレームチェックパターンを実装するサービスは、クレームチェックが有効である期間について明示的である必要があります。 ベストプラクティス + ポーリング用のエクスポネンシャルバックオフを実装します。 + クレームチェックに適切な有効期限 (TTL) を設定します。 + 進行状況を追跡するためのステータスエンドポイントを指定します。 ## コールバック コールバックパターンでは、クライアントはサービスにリクエストを発行し、処理が完了したときにサービスが連絡するロケーションを提供します。クライアントは結果が出るまで待機せず、処理が続行されます。サービスは、処理が完了したときにロケーションに連絡し、結果を提供する責任があります。応答の一般的なロケーションタイプは、REST API またはキューです。次の図は、コールバックパターンのワークフローを図解したものです。 ![非同期通信のコールバックパターン。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-integrating-microservices/images/callback.png) 実装 + 失敗したコールバックの再試行メカニズムを実装します。 + 他のサービスと同様に、コールバックのロケーションを保護します。 + コールバックタイムアウトを処理します。 ## 双方向通信 双方向通信を実装するには、クライアントとサービスの間にステートフル接続を作成する必要があります。これにより、クライアントとサービスの両方がメッセージを送信および処理できるようになります。これについては、以下の図で示されています。通信は非同期ですが、サービスはクライアントごとにオープン接続をサポートできる必要があります。 ![非同期通信の双方向通信パターン。](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/modernization-integrating-microservices/images/bidirectional.png) 実装の考慮事項 + メッセージの順序付け + シーケンス番号 + パーティション戦略 + メッセージの順序付け + 状態の管理 + イベントソーシングパターン + 状態調整 + 整合性モデル + エラー処理 + [デッドレターキュー](https://aws.amazon.com/what-is/dead-letter-queue/) + 再試行ポリシー + [回路ブレーカー](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html) + フォールバック戦略 + モニタリングとオブザーバビリティ + 相関 IDs + メッセージの追跡 + パフォーマンスメトリクス + システムヘルスインジケーター