のパフォーマンスのベストプラクティス AWS SDK for .NET

クライアントの作成方法、レスポンスの処理方法、アプリケーションの設定方法は、スループット、レイテンシー、メモリ使用量に大きな影響を与えます。このトピックでは、アプリケーションを効率的かつ確実に実行するのに役立つ使用パターンと設定パターンについて説明します。これらのパターンは、高負荷またはコンテナやサーバーレス関数などのリソースに制約のある環境で最も重要です。これらのプラクティスに従うことで、パフォーマンスが向上し、応答の遅延、ハング、メモリ使用量の増加などの一般的な問題を防ぐことができます。

最も影響の大きいプラクティスは次のとおりです。

開始する前に、環境をセットアップし、プロジェクトを設定したことを確認してください。

1 つの存続期間の長いサービスクライアントを再利用する

AmazonS3Client や AmazonDynamoDBClient などのサービスクライアントはスレッドセーフで、構築コストが比較的高く、存続時間が長くなります。クライアントを構築すると、リージョンとエンドポイントの情報が解決され、基盤となる HTTP インフラストラクチャが確立されます。サービスごとに 1 つのクライアントを作成し、アプリケーションの存続期間中再利用します。複数のリージョンを呼び出す場合は、リージョンごとに個別のクライアントを作成します。

依存関係インジェクションを使用するアプリケーションでは、クライアントをシングルトンとして登録します。AWSSDK.Extensions.NETCore.Setup NuGet パッケージのAddAWSService拡張メソッドは、デフォルトの有効期間が のクライアントを登録しますServiceLifetime.Singleton。クライアントは最初にリクエストされたときに作成され、同じインスタンスがプロセスの存続期間にわたって再利用されます。依存関係インジェクションでサービスを登録し、設定からオプションを読み取る方法の詳細については、 AWS 「」を参照してくださいAWSSDK.Extensions.NETCore.Setup および IConfiguration。

クライアントを手動でシングルトンとして登録することもできます。

builder.Services.AddSingleton<IAmazonS3>(_ => new AmazonS3Client());

クライアントを再利用しても、オペレーションごとのレスポンスの破棄を停止すべきではありません。アプリケーションの存続中はクライアントを再利用しますが、「」で説明されているように、個々のオペレーションが返すレスポンスとストリームは引き続き破棄しますレスポンスとストリームを破棄する。

レスポンスとストリームを破棄して接続を解放する

一部の SDK レスポンスオブジェクトには、ライブネットワークストリームがあります。最も一般的な例は GetObjectResponse です。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です。どちらか一方が基盤となるネットワークストリームを閉じ、プールへの接続を返します。

var metadata = await s3Client.GetObjectMetadataAsync(bucketName, key);
Console.WriteLine($"Size: {metadata.ContentLength} bytes");

async/await を正しく使用する

最新の .NET では、 のサービスオペレーション AWS SDK for .NET は非同期であり、 を返しますTask。.NET Framework では、同期メソッドも存在しますが、非同期呼び出しはより適切にスケールされるため、推奨されます。でオペレーションを消費しawait、コードのすべてのasyncレイヤーをエントリポイントまで伝達します。SDK を使用した非同期プログラミングの詳細については、「」を参照してください非同期プログラミング。

次のメソッドは、非同期呼び出しをブロックし、スレッドプールをデッドロックまたはスタベーションする可能性があります。

// Anti-pattern: do not do this.
public GetObjectResponse Get(GetObjectRequest request)
{
    return s3Client.GetObjectAsync(request).Result;
}

代わりに、 メソッドasyncと 呼び出しawaitを行います。

public async Task<GetObjectResponse> GetAsync(GetObjectRequest request)
{
    return await s3Client.GetObjectAsync(request);
}

非同期コードに関するその他の推奨事項:

AWS Lambda および Amazon ECS の .NET ガベージコレクションを設定する

コンテナに「メモリリーク」があるように見える場合、.NET ガベージコレクター (GC) は再利用のために再利用されたメモリを保持している可能性があります。その結果、マネージドヒープが増加していなくても、プロセスメモリは高く安定しているように見えます。さらに、GC はコンテナのメモリ制限 (cgroup 制限) を自動的に検出しません。制約のある環境では、ヒープはコンテナの制限ではなくホストのメモリに向かって大きくなる可能性があります。これにより、 OutOfMemoryExceptionまたはコンテナが終了する可能性があります。

制約のある環境で GC をうまく機能させるには:

これらの設定の詳細については、learn.microsoft.com のガベージコレクションのランタイム設定オプションを参照してください。 AWS コンピューティング固有のガイダンスについては、 AWS デベロッパーツールブログ記事「Amazon ECS および の .NET ガベージコレクションの設定 AWS Lambda」を参照してください。

HTTP 接続と接続制限の管理

高スループットでは、2 つの接続関連の問題が一般的です。1 つ目は、短時間接続を開く回数が多すぎることです。これにより、エフェメラルポートが枯渇し、ソケットが に残りTIME_WAIT、TCP および TLS ハンドシェイクのレイテンシーが追加されます。2 つ目は、利用可能な接続が少なすぎて、並列処理がボトルネックになることです。単一の存続期間の長いクライアント (「」を参照サービスクライアントを再利用する) を再利用することは、正常な接続プーリングの基盤です。プーリングは再利用されるクライアントに依存するためです。

エンドポイントあたりの同時接続数を調整するには、クライアント設定で 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」を参照してください。

最後に、独自の並列処理をバインドして、接続制限で許可されている以上の同時オペレーションを開始しないようにします。たとえば、接続制限に合わせてSemaphoreSlimサイズが のゲート呼び出しがあるとします。

var throttle = new SemaphoreSlim(50); // match MaxConnectionsPerServer
await throttle.WaitAsync(token);
try
{
    await s3Client.GetObjectAsync(request, token);
}
finally
{
    throttle.Release();
}

タイムアウトと再試行を設定する

タイムアウトと再試行は、認識されたパフォーマンスに直接影響します。Timeout 値が多すぎると、リクエストブロックが長時間停止されます。サービスがすでにスロットリングエラーを返している場合、積極的な再試行ポリシーはより多くのリクエストを追加し、スロットリングを悪化させる可能性があります。レイテンシーと障害に対するアプリケーションの許容度に合った再試行ポリシーを選択し、ハングを隠す方法で再試行するのではなく、真の例外が伝播されるようにします。

再試行モード、、MaxErrorRetryおよび Timeoutプロパティ (ReadWriteTimeout は .NET Framework にのみ適用されます) の詳細と設定方法の例については、「」を参照してください再試行とタイムアウト。

ストリーミングとラージオブジェクト転送の最適化 (Amazon S3)

大きなオブジェクト、または多数のオブジェクトをアップロードおよびダウンロードするには、Amazon.S3.Transfer名前空間で TransferUtility クラスを使用します。マルチパート転送を使用して並行してアップロードとダウンロードを行い、ストリーム、パート、接続を管理します。これは単一ストリーム転送よりも高速であり、大きなオブジェクトを移動するために推奨される方法です。

パフォーマンスの問題の診断

スローダウン、ハング、または明らかなリークを調査すると、次のシグナルが原因をすばやく見つけるのに役立ちます。