のバージョン 4 (V4) AWS SDK for .NET がリリースされました。 重要な変更とアプリケーションの移行については、[「移行トピック](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html)」を参照してください。 [![Orange button with text "Click here for details".](https://docs.aws.amazon.com/ja_jp/sdk-for-net/v4/developer-guide/images/BannerButton_less-round.png)](https://docs.aws.amazon.com/sdk-for-net/v4/developer-guide/net-dg-v4.html) 翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # のパフォーマンスのベストプラクティス AWS SDK for .NET クライアントの作成方法、レスポンスの処理方法、アプリケーションの設定方法は、スループット、レイテンシー、メモリ使用量に大きな影響を与えます。このトピックでは、アプリケーションを効率的かつ確実に実行するのに役立つ使用パターンと設定パターンについて説明します。これらのパターンは、高負荷またはコンテナやサーバーレス関数などのリソースに制約のある環境で最も重要です。これらのプラクティスに従うことで、パフォーマンスが向上し、応答の遅延、ハング、メモリ使用量の増加などの一般的な問題を防ぐことができます。 最も影響の大きいプラクティスは次のとおりです。 + リクエストごとに[作成せずに、1 つの存続期間の長いサービスクライアントを再利用](#net-dg-performance-reuse-clients)します。 + ネットワーク接続が接続プールに解放されるように、[レスポンスとストリームを破棄します](#net-dg-performance-dispose)。 + [`async`/`await` を正しく使用し](#net-dg-performance-async)、非同期 SDK 呼び出しをブロックしないでください。 + AWS Lambda や Amazon ECS などの制約のある環境に [.NET ガベージコレクションを設定します](#net-dg-performance-gc)。 + 高スループットで [HTTP 接続と接続制限を管理します](#net-dg-performance-connections)。 開始する前に、[環境をセットアップ](net-dg-config.md)し、[プロジェクトを設定した](configuring-the-sdk.md)ことを確認してください。 ## 1 つの存続期間の長いサービスクライアントを再利用する [AmazonS3Client](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/S3/TS3Client.html) や [AmazonDynamoDBClient](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/DynamoDBv2/TDynamoDBClient.html) などのサービスクライアントは*スレッドセーフ*で、構築コストが比較的*高く*、*存続時間が長くなります*。クライアントを構築すると、リージョンとエンドポイントの情報が解決され、基盤となる HTTP インフラストラクチャが確立されます。サービスごとに 1 つのクライアントを作成し、アプリケーションの存続期間中再利用します。複数のリージョンを呼び出す場合は、リージョンごとに個別のクライアントを作成します。 **警告** リクエストごと、またはループ内で新しいサービスクライアントを作成しないでください。クライアントを作成すると、基盤となる HTTP インフラストラクチャが繰り返し解約され、測定可能なレイテンシーが追加されます。また、ソケットやハンドルを使い果たし、ロード中にリクエストが失敗したりハングしたりする可能性があります。 依存関係インジェクションを使用するアプリケーションでは、クライアントをシングルトンとして登録します。`AWSSDK.Extensions.NETCore.Setup` NuGet パッケージの`AddAWSService`拡張メソッドは、デフォルトの有効期間が のクライアントを登録します`ServiceLifetime.Singleton`。クライアントは最初にリクエストされたときに作成され、同じインスタンスがプロセスの存続期間にわたって再利用されます。依存関係インジェクションでサービスを登録し、設定からオプションを読み取る方法の詳細については、 AWS 「」を参照してください[AWSSDK.Extensions.NETCore.Setup および IConfiguration](net-dg-config-netcore.md)。 クライアントを手動でシングルトンとして登録することもできます。 ``` builder.Services.AddSingleton(_ => new AmazonS3Client()); ``` **注記** はデフォルトでクライアントをシングルトンとして`AddAWSService`登録するため、 が提供するクライアントは破棄しないでください。デフォルト以外の有効期間が必要な場合は、 のオプション`lifetime`パラメータに別の`ServiceLifetime`値を渡します`AddAWSService`。 クライアントを再利用しても、オペレーションごとのレスポンスの破棄を停止すべき**ではありません**。アプリケーションの存続中はクライアントを再利用しますが、「」で説明されているように、個々のオペレーションが返すレスポンスとストリームは引き続き破棄します[レスポンスとストリームを破棄する](#net-dg-performance-dispose)。 ## レスポンスとストリームを破棄して接続を解放する 一部の SDK レスポンスオブジェクトには、ライブネットワークストリームがあります。最も一般的な例は [GetObjectResponse](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/S3/TGetObjectResponse.html) です。GetObjectResponse は、 `ResponseStream`プロパティを介してオブジェクトのコンテンツを実装`IDisposable`して公開します。レスポンスは、ストリームが完全に読み込まれるか、レスポンスが破棄されるまで、開いている HTTP 接続を保持します。これらのレスポンスをリークする場合 (各結果を破棄せずにループ`GetObject`で を呼び出すなど）、接続プールが使い果たされ、次の呼び出しがブロックされるまで、オープン接続が蓄積されます。これは、N 番目のオブジェクトで「ランダムにハングする」または停止するダウンロードの報告の背後にある原因です。 常にストリーミングレスポンスを`using`ステートメントにラップし、ストリームをすみやかに読み取りまたはコピーします。 ``` using Amazon.S3; using Amazon.S3.Model; // s3Client is a reused, long-lived client. var request = new GetObjectRequest { BucketName = bucketName, Key = key }; using var response = await s3Client.GetObjectAsync(request); await response.WriteResponseStreamToFileAsync(filePath, append: false, CancellationToken.None); ``` レスポンスを破棄して破棄することは同等`ResponseStream`です。どちらか一方が基盤となるネットワークストリームを閉じ、プールへの接続を返します。 **ヒント** サイズ、最終変更時間、コンテンツタイプ、ETag などのオブジェクトメタデータのみが必要な場合は、 `GetObjectMetadataAsync`の代わりに `GetObjectMetadata`または を呼び出します`GetObject`。メタデータオペレーションは HTTP `HEAD`リクエストを発行し、オブジェクト本文を転送しないため、管理するコンテンツストリームはありません。 ``` var metadata = await s3Client.GetObjectMetadataAsync(bucketName, key); Console.WriteLine($"Size: {metadata.ContentLength} bytes"); ``` **警告** などのレスポンスおよびストリームタイプはファイナライザーを実装`GetObjectResponse`していないため、ガベージコレクションを使用して接続を解放することはできません。レスポンスとストリームは、 `using`または明示的な`Dispose`呼び出しを使用して決定的に破棄する必要があります。 ## async/await を正しく使用する 最新の .NET では、 のサービスオペレーション AWS SDK for .NET は非同期であり、 を返します`Task`。.NET Framework では、同期メソッドも存在しますが、非同期呼び出しはより適切にスケールされるため、推奨されます。でオペレーションを消費し`await`、コードのすべての`async`レイヤーをエントリポイントまで伝達します。SDK を使用した非同期プログラミングの詳細については、「」を参照してください[非同期プログラミング](sdk-net-async-api.md)。 **警告** `.Result`、、`.Wait()`または で非同期 SDK 呼び出しをブロックしないでください`.GetAwaiter().GetResult()`。この*sync-over-async*パターンは、ハングするアプリケーションの一般的な原因です。 ロード中、ブロック呼び出しはスレッドプールが増大するよりも速くスレッドを消費するため、継続を実行できません。この*スレッドプールのスタベーション*は無期限のハングとして表示され、最新の .NET ( ASP.NET Coreにデフォルト がない場合`SynchronizationContext`) の主要な障害モードです。 一部のコンテキストは`SynchronizationContext`、従来の ASP.NET、、、Blazor WebAssembly、および .NET Framework Windows Forms WPFアプリケーションなどの をキャプチャします。これらのコンテキストでは、継続に同じスレッドが必要なときに呼び出し元のスレッドをブロックすると*デッドロック*が発生します。SDK のオペレーションは`ConfigureAwait(false)`内部的に を使用するため、その継続をキャプチャされたコンテキストに投稿しません。デッドロックは、それをキャプチャするコールチェーンの他の場所にある`async`コードから発生します。`await` 全体で で SDK 呼び出しを使用すると、問題を完全に回避できます。 次のメソッドは、非同期呼び出しをブロックし、スレッドプールをデッドロックまたはスタベーションする可能性があります。 ``` // Anti-pattern: do not do this. public GetObjectResponse Get(GetObjectRequest request) { return s3Client.GetObjectAsync(request).Result; } ``` 代わりに、 メソッド`async`と 呼び出し`await`を行います。 ``` public async Task GetAsync(GetObjectRequest request) { return await s3Client.GetObjectAsync(request); } ``` 非同期コードに関するその他の推奨事項: + すべてのオペレーション`CancellationToken`に を渡して、低速または停止した呼び出しをハングアップせずにキャンセルできるようにします。詳細については、「[タイムアウトに `CancellationToken` パラメータを使用する](retries-timeouts.md#timeouts-async)」を参照してください。 + 空の`catch`ブロックで例外を嚥下しないでください。これにより、実際の障害が非表示になり、ハングをエラーと区別できなくなります。特定の例外をキャッチしてログに記録します。 + キャッチされた例外を再スローする場合は、元のスタックトレースが保持`throw ex;`されるように、 `throw;`ではなく を使用します。 + 同期境界から を呼び出す必要がある場合は、それを最後の手段として扱い、ブロック呼び出しをデフォルトのパターンにするのではなく、キャプチャされたコンテキストから作業を分離します。 ## AWS Lambda および Amazon ECS の .NET ガベージコレクションを設定する コンテナに「メモリリーク」があるように見える場合、.NET ガベージコレクター (GC) は再利用のために再利用されたメモリを保持している可能性があります。その結果、マネージドヒープが増加していなくても、プロセスメモリは高く安定しているように見えます。さらに、GC はコンテナのメモリ制限 (cgroup 制限) を自動的に検出しません。制約のある環境では、ヒープはコンテナの制限ではなくホストのメモリに向かって大きくなる可能性があります。これにより、 `OutOfMemoryException`またはコンテナが終了する可能性があります。 制約のある環境で GC をうまく機能させるには: + GC が cgroup 制限に従うようにコンテナに明示的なメモリ制限を設定するか、 `DOTNET_GCHeapHardLimit` (絶対バイト値、16 進数) または`DOTNET_GCHeapHardLimitPercent`環境変数を設定してマネージドヒープを上限にします。報告されたいくつかの Amazon ECS out-of-memoryのケースでは、ハードメモリ制限を設定するとクラッシュが解決されました。 + 小規模ホスト AWS Lambda と Amazon ECS ホストでは、同時 (バックグラウンド) ガベージコレクションを無効にして、コレクターが追加のメモリを予約しないようにすることを検討してください。たとえば、`DOTNET_gcConcurrent`環境変数を に設定するか`0`、プロジェクトファイル`false`で を設定します。 + 同時実行数を制限します。大規模なコレクション`Task.WhenAll`を呼び出すなど、多数のオペレーションを一度に起動すると、プロセスメモリが拡張され、接続プールが枯渇する可能性があります。代わりに並列処理の度合いを設定します。たとえば、この無制限のパターンは避けてください。 ``` // Anti-pattern: starts one task per item with no limit. await Task.WhenAll(keys.Select(key => s3Client.GetObjectMetadataAsync(bucket, key))); ``` 代わりに、 との同時実行数の上限を設定します`Parallel.ForEachAsync`。 ``` var options = new ParallelOptions { MaxDegreeOfParallelism = 10 }; await Parallel.ForEachAsync(keys, options, async (key, token) => { await s3Client.GetObjectMetadataAsync(bucket, key, token); }); ``` これらの設定の詳細については、learn.microsoft.com [のガベージコレクションのランタイム設定オプション](https://learn.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector)を参照してください。 AWS コンピューティング固有のガイダンスについては、 AWS デベロッパーツールブログ記事[「Amazon ECS および の .NET ガベージコレクションの設定 AWS Lambda](https://aws.amazon.com/blogs/developer/configuring-net-garbage-collection-for-amazon-ecs-and-aws-lambda)」を参照してください。 ## HTTP 接続と接続制限の管理 高スループットでは、2 つの接続関連の問題が一般的です。1 つ目は、短時間接続を開く回数が多すぎることです。これにより、エフェメラルポートが枯渇し、ソケットが に残り`TIME_WAIT`、TCP および TLS ハンドシェイクのレイテンシーが追加されます。2 つ目は、利用可能な接続が少なすぎて、並列処理がボトルネックになることです。単一の存続期間の長いクライアント (「」を参照[サービスクライアントを再利用する](#net-dg-performance-reuse-clients)) を再利用することは、正常な接続プーリングの基盤です。プーリングは再利用されるクライアントに依存するためです。 エンドポイントあたりの同時接続数を調整するには、クライアント設定で `MaxConnectionsPerServer`プロパティを設定します。このプロパティが `null` (デフォルト) の場合、基盤となる`HttpClientHandler`デフォルトが適用され、最新の .NET では実質的に無制限です。同じエンドポイントへの多数の同時リクエストが接続でボトルネックになっている場合にのみ、それを増やします。適切な開始点は、エンドポイントごとに予想される同時リクエストのピーク数です。ワークロードよりもはるかに高く設定すると、スループットを向上させることなくソケットが無駄になります。 ``` using Amazon.S3; var config = new AmazonS3Config { MaxConnectionsPerServer = 50 }; var s3Client = new AmazonS3Client(config); ``` すでに依存関係インジェクションを使用している場合は、 を使用してクライアントを設定します`AWSSDK.Extensions.NETCore.Setup`。これは、DI を使用するか、複数のサービスクライアントを登録する場合に推奨されるアプローチです。設定が一元化され、クライアントの挿入とテストが容易になります。コードではなく、アプリケーションの設定から設定値を設定できます。詳細については、「[AWSSDK.Extensions.NETCore.Setup および IConfiguration](net-dg-config-netcore.md)」を参照してください。 最後に、独自の並列処理をバインドして、接続制限で許可されている以上の同時オペレーションを開始しないようにします。たとえば、接続制限に合わせて`SemaphoreSlim`サイズが のゲート呼び出しがあるとします。 ``` var throttle = new SemaphoreSlim(50); // match MaxConnectionsPerServer await throttle.WaitAsync(token); try { await s3Client.GetObjectAsync(request, token); } finally { throttle.Release(); } ``` ## タイムアウトと再試行を設定する タイムアウトと再試行は、認識されたパフォーマンスに直接影響します。`Timeout` 値が多すぎると、リクエストブロックが長時間停止されます。サービスがすでにスロットリングエラーを返している場合、積極的な再試行ポリシーはより多くのリクエストを追加し、スロットリングを悪化させる可能性があります。レイテンシーと障害に対するアプリケーションの許容度に合った再試行ポリシーを選択し、ハングを隠す方法で再試行するのではなく、真の例外が伝播されるようにします。 **注記** `Timeout` プロパティは非同期呼び出しには影響しません。非同期呼び出しを使用している場合は、[タイムアウトに `CancellationToken` パラメータを使用する](retries-timeouts.md#timeouts-async)代わりに「」を参照してください。 再試行モード、、`MaxErrorRetry`および `Timeout`プロパティ (`ReadWriteTimeout` は .NET Framework にのみ適用されます) の詳細と設定方法の例については、「」を参照してください[再試行とタイムアウト](retries-timeouts.md)。 ## ストリーミングとラージオブジェクト転送の最適化 (Amazon S3) 大きなオブジェクト、または多数のオブジェクトをアップロードおよびダウンロードするには、`Amazon.S3.Transfer`名前空間で [TransferUtility](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/S3/TTransferUtility.html) クラスを使用します。マルチパート転送を使用して並行してアップロードとダウンロードを行い、ストリーム、パート、接続を管理します。これは単一ストリーム転送よりも高速であり、大きなオブジェクトを移動するために推奨される方法です。 + **並列マルチパートダウンロード。**SDK の以前のバージョンでは、パートを並行してダウンロードするのではなく、オブジェクトを単一のストリームとしてダウンロードしました。`AWSSDK.S3` バージョン 4.0.17 以降、 `TransferUtility`は、`DownloadWithResponseAsync`、、`OpenStreamWithResponseAsync`および `DownloadDirectoryWithResponseAsync`メソッドを通じてマルチパート (並列) ダウンロードを提供します。を使用すると`OpenStreamWithResponseAsync`、返されたストリームを消費している間、オブジェクトの部分はメモリにバッファされます。[TransferUtilityOpenStreamRequest](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/S3/TTransferUtilityOpenStreamRequest.html) の `MaxInMemoryParts`プロパティでバッファされるパートの数を制御します。ほとんどの転送では、 を優先します`TransferUtility`。特定の範囲またはカスタム並列処理スキームが必要な場合にのみ、[GetObjectRequest](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/S3/TGetObjectRequest.html) の `ByteRange`プロパティを使用してバイト範囲を自分でダウンロードします。詳細については、 デベロッパーツールブログの[AWS 「 SDK for .NET Transfer Manager のマルチパートダウンロードサポートの紹介](https://aws.amazon.com/blogs/developer/introducing-multipart-download-support-for-aws-sdk-for-net-transfer-manager/)」を参照してください。 AWS + **アップロードのコンテンツの長さ。**Amazon S3 には既知のコンテンツの長さ`PUT`が必要であり、デフォルトでは SDK はリクエスト本文のチェックサムを計算します。長さがわかっていてストリームがシーク可能である場合、SDK はオブジェクト全体をメモリにバッファすることなくこれを行うことができます。は、必要に応じてバッファリングすることで、シーク不可のストリーム`TransferUtility`を処理します。代わりに、シーク不可のストリーム ( の raw リクエスト本文などASP.NET Core) で`PutObjectAsync`直接 を呼び出すと、リクエストが失敗する可能性があります。シーク可能なストリームを提供するか、コンテンツの長さを明示的に設定するか、SDK がチェックサムを計算する方法を設定します。詳細については、[「SDK およびツールリファレンスガイド」の「データ整合性保護](https://docs.aws.amazon.com/sdkref/latest/guide/feature-dataintegrity.html) AWS SDKs 」を参照してください。 + **パートのサイズ設定。**Amazon S3 では、マルチパートアップロードごとに最大 10,000 個のパートを使用できます。合計長がわかっている場合、SDK は、この制限内にとどまるパートサイズを自動的に計算します。主に、長さが事前にわからないストリームに`PartSize`自分で設定する必要があります。そうしないと、小さなデフォルトパートが非常に大きなアップロードの制限を超える可能性があります。パートサイズを大きくすると、パートごとのオーバーヘッドも削減され、パートあたりのメモリが増えます。 ## パフォーマンスの問題の診断 スローダウン、ハング、または明らかなリークを調査すると、次のシグナルが原因をすばやく見つけるのに役立ちます。 + `CLOSE_WAIT` または `TIME_WAIT`状態のソケット数の増加 ( で表示`netstat`) は、未処理のレスポンスまたはリクエストごとに作成および破棄されるクライアントのフィンガープリントです。「[レスポンスとストリームを破棄する](#net-dg-performance-dispose)」および「[サービスクライアントを再利用する](#net-dg-performance-reuse-clients)」を参照してください。 + リクエストメトリクスとレスポンスのログ記録を有効にして、リクエストが実際にディスパッチされていることを確認し、レイテンシーを測定します。サービスクライアントを作成する前に、[AWSConfigs](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/Amazon/TAWSConfigs.html) で [LoggingConfig](https://docs.aws.amazon.com/sdkfornet/v4/apidocs/items/Util/TLoggingConfig.html) オブジェクトのプロパティを設定します。クライアントは、構築`LogMetrics`時に などの設定をキャプチャします。 ``` using Amazon; AWSConfigs.LoggingConfig.LogMetrics = true; AWSConfigs.LoggingConfig.LogResponses = ResponseLoggingOption.OnError; ``` + メモリを調査するときは、全プロセスメモリをマネージドヒープと区別します。高いが安定したプロセスメモリは、多くの場合、リークではなく再利用されたメモリを保持する GC です。「[ガベージコレクションを設定する](#net-dg-performance-gc)」を参照してください。