👨🏾‍🌾 🗒️ 🐔 GRPC for ASP.NET CORE3.0での応答の圧縮 🍨 🐑 🀄️

記事の翻訳は、「C＃ASP.NETCoreDeveloper」コースの開始を見越して作成されました。

gRPCとASP.NETCoreに関する私のシリーズのこのエピソードでは、gRPCサービスの応答圧縮機能を接続する方法を見ていきます。

注：この記事では、呼び出しの設定とメソッドについて学習して学んだ圧縮の詳細の一部について説明します。同じ結果を達成するためのより正確でより効果的なアプローチがある可能性があります。

この記事は、gRPCとASP.NETCoreに関するシリーズの一部です。

GRPCで圧縮を有効にする必要があるのはいつですか？

簡単な答え：それはあなたのペイロードに依存します。

長い答え：

gRPCは、ネットワークを介して送信される要求メッセージと応答メッセージをシリアル化するためのツールとしてプロトコルバッファーを使用します。プロトコルバッファは、デフォルトで小さくて効率的なペイロード用に設計されたバイナリシリアル化形式を作成します。通常のJSONペイロードと比較して、protobufはより控えめなメッセージサイズを提供します。 JSONは非常に冗長で読みやすいです。その結果、ネットワークを介して送信されるデータにプロパティ名が含まれるため、転送する必要のあるバイト数が増加します。

プロトコルバッファは、ネットワークを介して送信されるデータの識別子として整数を使用します。これは、ベース128バリアントの概念を使用しており、0〜127の値を持つフィールドが転送に1バイトのみを必要とすることを可能にします。多くの場合、メッセージをこの範囲のフィールドに制限することができます。大きな整数には複数のバイトが必要です。

したがって、protobufペイロードは、ネットワークを介して送信されるバイトを可能な限り最小のサイズに削減することを目的としているため、すでに非常に小さいことを忘れないでください。ただし、GZipなどの形式を使用すると、さらに損失のない圧縮が行われる可能性があります。ペイロードに圧縮の恩恵を受けるのに十分な反復テキストデータがある場合にのみサイズの縮小が見られるため、この可能性をペイロードでテストする必要があります。おそらく小さな応答メッセージの場合、それらを圧縮しようとすると、圧縮されていないメッセージを使用するよりも多くのバイトが発生する可能性があります。これは明らかに良くありません。

また、プロセッサの圧縮オーバーヘッドも注目に値します。これは、サイズの縮小から得られる利益を上回る可能性があります。サービスの全体像を把握するには、圧縮レベルを変更した後、要求のCPUとメモリのオーバーヘッドを追跡する必要があります。

ASP.NET Core Server Integrationはデフォルトで圧縮を使用しませんが、サーバー全体または特定のサービスに対して圧縮を有効にすることができます。これは、さまざまなメソッドの応答を経時的に追跡し、それらを圧縮することの利点を評価できるため、妥当なデフォルトのように思われます。

GRPCで応答圧縮を有効にするにはどうすればよいですか？

これまでのところ、gRPC応答圧縮を接続するための2つの主要なアプローチを見つけました。これをサーバーレベルで構成して、すべてのgRPCサービスが応答に圧縮を適用するようにするか、個々のサービスレベルで構成することができます。

サーバーレベルの構成

services.AddGrpc(o =>
{
   o.ResponseCompressionLevel = CompressionLevel.Optimal;
   o.ResponseCompressionAlgorithm = "gzip";
});

Startup.cs GitHub

AddGrpc内部のメソッドを使用して依存関係インジェクションコンテナにgRPCサービスを登録する場合、でConfigureServices構成する機会がありますGrpcServiceOptions。このレベルでは、パラメーターはサーバーが実装するすべてのgRPCサービスに影響します。

拡張メソッドのオーバーロードを使用してAddGrpc、を提供できます Action<GrpcServiceOptions>。上記のコードスニペットでは、「gzip」圧縮アルゴリズムを選択しています。CompressionLevelデータ圧縮のために犠牲にする時間を操作して、サイズを小さくすることによって確立することもできます。パラメータが指定されていない場合、現在の実装ではデフォルトでCompressionLevel.Fastest。を使用します。前のスニペットでは、バイト数を可能な限り最小のサイズに減らすために、圧縮により多くの時間を許可しました。

サービスレベルの構成

services.AddGrpc()
   .AddServiceOptions<WeatherService>(o =>
       {
           o.ResponseCompressionLevel = CompressionLevel.Optimal;
           o.ResponseCompressionAlgorithm = "gzip";
       });

Startup.cs GitHub

呼び出しAddGrpcはを返しますIGrpcServerBuilder。ビルダーで呼び出される拡張メソッドを呼び出して、AddServiceOptions各サービスのパラメーターを個別に提供できます。このメソッドは汎用であり、パラメーターを適用する必要があるgRPCサービスのタイプを取ります。

前の例では、実装によって処理される呼び出しのパラメーターを提供することを選択しましたWeatherService。このレベルでは、サーバーレベルの構成で説明したのと同じオプションを使用できます。このシナリオでは、このサーバー上の他のgRPCサービスは、その特定のサービスに設定した圧縮オプションを受け取りません。

GRPCクライアントのリクエスト

応答の圧縮が有効になったので、クライアントが圧縮されたコンテンツを受け入れていることを要求が示していることを確認する必要があります。実際、これはGrpcChannel、作成されたメソッドForAddressで使用するとデフォルトで有効になっているため、クライアントコードで何もする必要はありません。

var channel = GrpcChannel.ForAddress("https://localhost:5005");

Program.cs GitHub

この方法で作成されたチャネルは、gzip圧縮タイプを含む「grpc-accept-encoding」ヘッダーをすでに送信しています。サーバーはこのヘッダーを読み取り、クライアントが圧縮された応答の返送を許可していると判断します。

圧縮効果を視覚化する1つの方法は、設計時にアプリケーションのロギングを有効にすることです。これはappsettings.Development.json、次のようにファイルを変更することで実行できます。

{
 "Logging": {
   "LogLevel": {
       "Default": "Debug",
       "System": "Information",
       "Grpc": "Trace",
       "Microsoft": "Trace"
   }
 }
}

appsettings.Development.json GitHub

サーバーを起動すると、より詳細なコンソールログが表示されます。

info: Microsoft.AspNetCore.Routing.EndpointMiddleware[0]
     Executing endpoint 'gRPC - /WeatherForecast.WeatherForecasts/GetWeather'
dbug: Grpc.AspNetCore.Server.ServerCallHandler[1]
     Reading message.
dbug: Microsoft.AspNetCore.Server.Kestrel[25]
     Connection id "0HLQB6EMBPUIA", Request id "0HLQB6EMBPUIA:00000001": started reading request body.
dbug: Microsoft.AspNetCore.Server.Kestrel[26]
     Connection id "0HLQB6EMBPUIA", Request id "0HLQB6EMBPUIA:00000001": done reading request body.
trce: Grpc.AspNetCore.Server.ServerCallHandler[3]
     Deserializing 0 byte message to 'Google.Protobuf.WellKnownTypes.Empty'.
trce: Grpc.AspNetCore.Server.ServerCallHandler[4]
     Received message.
dbug: Grpc.AspNetCore.Server.ServerCallHandler[6]
     Sending message.
trce: Grpc.AspNetCore.Server.ServerCallHandler[9]
     Serialized 'WeatherForecast.WeatherReply' to 2851 byte message.
trce: Microsoft.AspNetCore.Server.Kestrel[37]
     Connection id "0HLQB6EMBPUIA" sending HEADERS frame for stream ID 1 with length 104 and flags END_HEADERS
trce: Grpc.AspNetCore.Server.ServerCallHandler[10]
     Compressing message with 'gzip' encoding.
trce: Grpc.AspNetCore.Server.ServerCallHandler[7]
     Message sent.
info: Microsoft.AspNetCore.Routing.EndpointMiddleware[1]
     Executed endpoint 'gRPC - /WeatherForecast.WeatherForecasts/GetWeather'
trce: Microsoft.AspNetCore.Server.Kestrel[37]
     Connection id "0HLQB6EMBPUIA" sending DATA frame for stream ID 1 with length 978 and flags NONE
trce: Microsoft.AspNetCore.Server.Kestrel[37]
     Connection id "0HLQB6EMBPUIA" sending HEADERS frame for stream ID 1 with length 15 and flags END_STREAM, END_HEADERS
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
     Request finished in 2158.9035ms 200 application/grpc

Log.txt GitHub

このログの16行目に、WeatherReply（実際には、この例では100個のWeatherData要素の配列）がprotobufにシリアル化されており、サイズは2851バイトであることがわかります。

その後、20行目で、メッセージがgzipエンコーディングを使用して圧縮されていることがわかり、26行目で、この呼び出しのデータフレームサイズ（978バイト）がわかります。この場合、繰り返されるWeatherData要素にはテキストが含まれ、メッセージ内の値の多くが繰り返されるため、データは適切に（66％）圧縮されました。

この例では、gzip圧縮がデータサイズに良い影響を与えました。

サービスメソッドの実装で応答圧縮を無効にする

応答の圧縮は、各方法で制御できます。現在、私はそれをオフにする方法を見つけました。サービスまたはサーバーで圧縮が有効になっている場合、サービスメソッドの実装の一部として圧縮をオプトアウトできます。

サーバーからWeatherDataメッセージを送信するサービスメソッドを呼び出すときのサーバーログを見てみましょう。サーバーへのストリーミングについて詳しく知りたい場合は、前回の記事「gRPCと.NETCoreを使用したサーバーへのデータのストリーミング」を参照してください。

info: WeatherForecast.Grpc.Server.Services.WeatherService[0]
     Sending WeatherData response
dbug: Grpc.AspNetCore.Server.ServerCallHandler[6]
     Sending message.
trce: Grpc.AspNetCore.Server.ServerCallHandler[9]
     Serialized 'WeatherForecast.WeatherData' to 30 byte message.
trce: Grpc.AspNetCore.Server.ServerCallHandler[10]
     Compressing message with 'gzip' encoding.
trce: Microsoft.AspNetCore.Server.Kestrel[37]
     Connection id "0HLQBMRRH10JQ" sending DATA frame for stream ID 1 with length 50 and flags NONE
trce: Grpc.AspNetCore.Server.ServerCallHandler[7]
     Message sent.

Log.txt GitHub

6行目では、個々のWeatherDataメッセージのサイズが30バイトであることがわかります。8行目は圧縮されており、10行目は、データの長さが元のメッセージより50バイト長いことを示しています。この場合、gzip圧縮によるメリットはなく、ネットワーク経由で送信されるメッセージの合計サイズが増加します。サービスメソッドを呼び出すように

設定WriteOptionsすることで、特定のメッセージの圧縮をオフにできます。

public override async Task GetWeatherStream(Empty _, IServerStreamWriter<WeatherData> responseStream, ServerCallContext context)
{
   context.WriteOptions = new WriteOptions(WriteFlags.NoCompress);

   //  ,    
}

WeatherService.cs GitHub

私たちは、設定することができますWriteOptionsでServerCallContext私たちのサービスメソッドのトップ。私たちは、新しいインスタンスに渡しているWriteOptionsさWriteFlagsに設定しますNoCompress。これらのパラメータは、次のエントリに使用されます。

応答をストリーミングする場合、この値をに設定することもできますIServerStreamWriter。

public override async Task GetWeatherStream(Empty _, IServerStreamWriter<WeatherData> responseStream, ServerCallContext context)
{   
   responseStream.WriteOptions = new WriteOptions(WriteFlags.NoCompress);

   //     
}

WeatherService.cs GitHub

このパラメーターを使用すると、ログには、このサービスメソッドの呼び出しに圧縮が適用されていないことが示されます。

info: WeatherForecast.Grpc.Server.Services.WeatherService[0]
     Sending WeatherData response
dbug: Grpc.AspNetCore.Server.ServerCallHandler[6]
     Sending message.
trce: Grpc.AspNetCore.Server.ServerCallHandler[9]
     Serialized 'WeatherForecast.WeatherData' to 30 byte message.
trce: Microsoft.AspNetCore.Server.Kestrel[37]
     Connection id "0HLQBMTL1HLM8" sending DATA frame for stream ID 1 with length 35 and flags NONE
trce: Grpc.AspNetCore.Server.ServerCallHandler[7]
     Message sent.

Log.txt GitHub

これで、30バイトのメッセージはDATAフレームで35バイトの長さになります。ここで心配する必要のない余分な5バイトの小さなオーバーヘッドがあります。

GRPCクライアントからの応答圧縮を無効にする

デフォルトでは、gRPCチャネルには、受け入れるエンコーディングを決定するパラメータが含まれています。クライアントからの応答の圧縮を無効にする場合は、チャネルの作成時にこれらを構成できます。一般的に、圧縮できるものとできないものをよく知っているので、これを避けてサーバーに何をするかを決定させます。ただし、クライアントからこれを監視する必要がある場合があります。

これまでのAPI調査で私が見つけた唯一の方法は、インスタンスを渡してチャネルを設定することGrpcChannelOptionsです。このクラスのプロパティの1つはCompressionProviders-用IList<ICompressionProvider>です。デフォルトでは、この値がnullの場合、クライアント実装は自動的にGzip圧縮プロバイダーを追加します。これは、これまで見てきたように、サーバーがgzipを使用して応答メッセージを圧縮できることを意味します。

private static async Task Main()
{
   using var channel = GrpcChannel.ForAddress("https://localhost:5005", new GrpcChannelOptions { CompressionProviders = new List<ICompressionProvider>() });
   var client = new WeatherForecastsClient(channel);
   var reply = await client.GetWeatherAsync(new Empty());
   foreach (var forecast in reply.WeatherData)
  {
       Console.WriteLine($"{forecast.DateTimeStamp.ToDateTime():s} | {forecast.Summary} | {forecast.TemperatureC} C");
   }
   Console.WriteLine("Press a key to exit");
   Console.ReadKey();
}

Program.cs GitHub

このサンプルクライアントコードではGrpcChannel、新しいインスタンスを設定してプッシュしていますGrpcChannelOptions。プロパティにCompressionProviders空のリストを割り当てています。呼び出しが作成され、そのチャネルを介して送信されるときにチャネルでプロバイダーを指定しないため、grpc-accept-encodingヘッダーに圧縮エンコーディングは含まれません。サーバーはこれを認識し、応答をgzipしません。

概要

この投稿では、gRPCサーバーからの応答メッセージを圧縮する可能性について検討しました。一部の（すべてではない）ケースでは、これによりペイロードが小さくなる可能性があることがわかりました。デフォルトでは、クライアント呼び出しのヘッダーにgzip値「grpc-accept-encoding」が含まれていることがわかりました。サーバーが圧縮を適用するように構成されている場合、サポートされている圧縮タイプが要求ヘッダーと一致する場合にのみ適用されます。クライアントのチャネルを作成するときに、gzip圧縮を無効にする

ように構成できますGrpcChannelOptions。サーバーでは、サーバー全体を一度に構成することも、別のサービスを構成して応答を圧縮することもできます。各サービスメソッドのレベルでこれをオーバーライドおよび無効にすることもできます。

gRPCの詳細については、私の一部であるすべての記事を読むことができますgRPCおよびASP.NETコアシリーズ。

コースのすべて

GRPC for ASP.NET CORE3.0での応答の圧縮