翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 通信メカニズム
<a name="communication-mechanisms"></a>

 マイクロサービスパラダイムでは、アプリケーションのさまざまなコンポーネントがネットワーク経由で通信する必要があります。この一般的なアプローチには、REST ベース、GraphQL ベース、gRPC ベース、非同期メッセージングなどがあります。

## REST ベースの通信
<a name="rest-based-communication"></a>

 HTTP/S プロトコルは、マイクロサービス間の同期通信に広く使用され、RESTful APIs を介して動作することがよくあります。API Gateway は、トラフィック管理、認可、モニタリング、バージョン管理などのタスクを処理するバックエンドサービスへの一元化されたアクセスポイントとして機能する API を構築する効率的な方法を提供します。

## GraphQL ベースの通信
<a name="graphql-based-communication"></a>

 同様に、GraphQL は同期通信の広範な方法であり、REST と同じプロトコルを使用しますが、単一のエンドポイントへの露出を制限します。を使用すると AWS AppSync、 AWS サービスやデータストアと直接やり取りする GraphQL アプリケーションを作成および公開したり、ビジネスロジックに Lambda 関数を組み込むことができます。

## gRPC ベースの通信
<a name="grpc-based-communication"></a>

 gRPC は、同期、軽量、高性能、オープンソースの RPC 通信プロトコルです。gRPC は、HTTP/2 を使用し、圧縮やストリームの優先順位付けなどのより多くの機能を有効にすることで、基盤となるプロトコルを改善します。バイナリエンコードされた Protobuf Interface Definition Language (IDL) を使用するため、HTTP/2 バイナリフレーミングを利用します。

## 非同期メッセージングとイベントパス
<a name="asynchronous-messaging-and-event-passing"></a>

非同期メッセージングを使用すると、サービスはキューを介してメッセージを送受信することで通信できます。これにより、サービスは疎結合のままになり、サービス検出を促進できます。

メッセージングは、次の 3 つのタイプで定義できます。
+  **メッセージキュー:** メッセージキューは、メッセージの送信者 (プロデューサー) と受信者 (コンシューマー) を切り離すバッファとして機能します。プロデューサーはメッセージをキューにキューに入れ、コンシューマーはメッセージをキューから取り出して処理します。このパターンは、非同期通信、負荷の平準化、トラフィックのバーストの処理に役立ちます。
+  **Publish-Subscribe:** publish-subscribe パターンでは、メッセージがトピックに発行され、複数の関心のあるサブスクライバーがメッセージを受信します。このパターンにより、複数のコンシューマーにイベントまたはメッセージを非同期的にブロードキャストできます。
+  **イベント駆動型メッセージング:** イベント駆動型メッセージングでは、システムで発生するイベントをキャプチャして対応します。イベントはメッセージブローカーに発行され、関心のあるサービスは特定のイベントタイプにサブスクライブします。このパターンにより、疎結合が可能になり、サービスは直接的な依存関係なしにイベントに反応できます。

 これらの各メッセージタイプを実装するために、 は Amazon SQS、Amazon SNS、Amazon EventBridge、Amazon MQ、Amazon MSK などのさまざまなマネージドサービス AWS を提供します。これらのサービスには、特定のニーズに合わせてカスタマイズされた独自の機能があります。
+  **Amazon Simple Queue Service (Amazon SQS) と Amazon Simple Notification Service (Amazon SNS):** 図 8 に示すように、これらの 2 つのサービスは相互に補完し合い、Amazon SQS はメッセージを保存するためのスペースを提供し、Amazon SNS は複数のサブスクライバーへのメッセージの配信を可能にします。同じメッセージを複数の宛先に配信する必要がある場合に有効です。  
![でのメッセージバスパターンを示す図 AWS](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/microservices-on-aws/images/message-bus-pattern.png)
+  **Amazon EventBridge:** イベントを使用してアプリケーションコンポーネントを接続するサーバーレスサービス。スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。これを使用して、自社開発のアプリケーション、 AWS サービス、サードパーティー製ソフトウェアなどのソースから、組織全体のコンシューマーアプリケーションにイベントをルーティングします。EventBridge では、イベントの取り込み、フィルタリング、変換、配信をシンプルかつ一貫性のある方法で行うことができるため、新しいアプリケーションをすばやく構築できます。EventBridge イベントバスは、イベント駆動型サービス間のイベントの多対多のルーティングに適しています。
+  **Amazon MQ:** JMS、AMQP などの標準プロトコルを使用する既存のメッセージングシステムがある場合に適しています。このマネージドサービスは、オペレーションを中断することなく、システムの代わりとなります。
+  **Amazon MSK (Managed Kafka): **メッセージを保存および読み取るためのメッセージングシステム。メッセージを複数回処理する必要がある場合に役立ちます。また、リアルタイムのメッセージストリーミングもサポートしています。
+  **Amazon Kinesis:** ストリーミングデータのリアルタイム処理と分析。これにより、リアルタイムアプリケーションの開発が可能になり、 AWS エコシステムとのシームレスな統合が可能になります。

 最適なサービスは特定のニーズに依存するため、各サービスが提供する内容と要件との整合性を理解することが重要です。

## オーケストレーションと状態管理
<a name="orchestration-and-state-management"></a>

 マイクロサービスオーケストレーションとは、オーケストレーターと呼ばれる中央コンポーネントがマイクロサービス間のインタラクションを管理および調整する一元的なアプローチを指します。複数のマイクロサービス間でワークフローをオーケストレーションするのは難しい場合があります。オーケストレーションコードを サービスに直接埋め込むことはお勧めしません。これは、より緊密な結合を導入し、個々のサービスの置き換えを妨げるためです。

 Step Functions は、エラー処理やシリアル化などのサービスオーケストレーションの複雑さを管理するワークフローエンジンを提供します。これにより、調整コードを追加することなく、アプリケーションのスケーリングと変更をすばやく行うことができます。Step Functions は AWS サーバーレスプラットフォームの一部であり、Lambda 関数、Amazon EC2、Amazon EKS、Amazon ECS、SageMaker AI AWS Glueなどをサポートしています。

![によって呼び出されたマイクロサービスワークフローの図 AWS Step Functions](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/microservices-on-aws/images/microservices-workflow-with-steps.png)


[Amazon Managed Workflows for Apache Airflow](https://aws.amazon.com/managed-workflows-for-apache-airflow/) (Amazon MWAA) は Step Functions の代替手段です。オープンソースと移植性を優先する場合は、Amazon MWAA を使用する必要があります。Airflow には、新しい機能と統合を定期的に提供する大規模でアクティブなオープンソースコミュニティがあります。