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

# マイクロサービス通信でのチャットの管理
<a name="managing-chattiness-in-microservices-communication"></a>

** 喧嘩とは、マイクロサービス間の過剰な通信を指します。これにより、ネットワークレイテンシーの増加による非効率が生じる可能性があります。適切に機能するシステムでは、チャットを効果的に管理することが重要です。

 チャットを管理するための主要なツールには、REST APIs、HTTP APIs、gRPC APIs。REST APIs は、API キー、クライアントごとのスロットリング、リクエストの検証、 AWS WAF 統合、プライベート API エンドポイントなど、さまざまな高度な機能を提供します。HTTP APIsは最小限の機能で設計されているため、低価格で利用できます。このトピックと REST APIs および HTTP APIs[「REST APIs と HTTP APIs の選択](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html)」を参照してください。

 多くの場合、マイクロサービスは広く使用されているため、通信に HTTP 経由の REST を使用します。ただし、大量の状況では、REST のオーバーヘッドによってパフォーマンスの問題が発生する可能性があります。これは、通信が新しいリクエストごとに必要な TCP ハンドシェイクを使用するためです。このような場合、gRPC API の方が適しています。gRPC は 1 つの TCP 接続で複数のリクエストを許可するため、レイテンシーを短縮します。gRPC は双方向ストリーミングもサポートしているため、クライアントとサーバーは同時にメッセージを送受信できます。これにより、特に大規模またはリアルタイムのデータ転送の場合、より効率的な通信が可能になります。

 適切な API タイプを選択してもチャットが続く場合は、マイクロサービスアーキテクチャの再評価が必要になる場合があります。サービスを統合したり、ドメインモデルを改訂したりすると、喧嘩が軽減され、効率が向上します。

## プロトコルとキャッシュの使用
<a name="using-protocols-and-caching"></a>

 マイクロサービスは、多くの場合、通信に gRPC や REST などのプロトコルを使用します (「」の前のセクションを参照)[通信メカニズム](communication-mechanisms.md)。gRPC は転送に HTTP/2 を使用しますが、REST は通常 HTTP/1.1 を使用します。gRPC はシリアル化にプロトコルバッファを使用しますが、REST は通常 JSON または XML を使用します。レイテンシーと通信オーバーヘッドを減らすために、キャッシュを適用できます。Amazon ElastiCache や API Gateway のキャッシュレイヤーなどのサービスは、マイクロサービス間の呼び出し数を減らすのに役立ちます。