次の方法で共有


Blob Storage 開発者向けのパフォーマンス チェックリスト

このチェックリストを使用して、待機時間を短縮し、スループットを向上させ、 Azure Storage のスケールとパフォーマンスのターゲットに合わせます。 Azure Storage では、要求に応じて一部の値を増やすことができるため、制限ではなくターゲットという用語が使用されます。 クライアントがこれらのターゲットに近づくか、またはこれらのターゲットを超えると、Azure Storage によって要求が調整され、待機時間が長くなる可能性があります。 この記事のチェックリストを使用して、パフォーマンスを犠牲にすることなくターゲットに合わせます。

この記事は、カスタム アプリケーションにのみ適用されます。 すべてのクライアントに適用される推奨事項については、 Blob Storage のパフォーマンス チェックリストを確認してください。

パフォーマンス チェックリスト

  • Azure Storage クライアント ライブラリを使用する: パフォーマンスを最大限に高めるには、Microsoft クライアント ライブラリを使用します。 これらのライブラリは、パフォーマンスのために最適化され、サービス バージョンで最新の状態に保たれ、実証済みのパフォーマンス プラクティスを内部的に処理します。

  • 並列ブロック転送の最適化: ブロック サイズを小さくして並列転送を増やしますが、高スループットのブロック BLOB をアクティブにするために、サイズは 4 MiB (Standard) または 256 KiB (Premium) を超えて維持します。 並列処理のバランスを取り、調整の原因となるデバイスの機能またはストレージ ターゲットを超えないようにします。 同時要求に適切な制限を設定します。 .NETJava、JavaScriptPythonGo のパフォーマンス ガイダンスを参照してください。

  • 指数バックオフ再試行ポリシーを使用する: 指数バックオフ ポリシーで一時的なエラーを処理します。 たとえば、2、4、10、30 秒後に再試行してから停止します。 このポリシーは、アプリケーションがパフォーマンスに近づいたり、パフォーマンスやスケールのターゲットを超えたりしたときに発生する一時的でないエラーに対する過剰な再試行を防ぎます。 クライアント ライブラリは、再試行するエラーと再試行しないエラーを認識します。 再試行ポリシーを適用するには、.NETJava、JavaScriptPythonGo の再試行ガイダンスを参照してください。

  • サーバー間 API を使用してコンテナーとアカウント間でコピーする: Put Block From URL を使用してアカウント間でデータをコピーし、アカウント内のデータをコピーします。 サーバー側の操作では、データをダウンロードしてアップロードする必要がないため、帯域幅が削減されます。 .NETJava、JavaScriptPythonGo のコピー ガイダンスを参照してください。

  • パフォーマンスを向上させるためにデータをキャッシュする: 構成データや参照データなど、頻繁にアクセスされるデータまたはほとんど変更されないデータをキャッシュします。 GET 操作で条件付きヘッダーを使用して、最後にキャッシュされてから変更された場合にのみ BLOB を取得します。 詳細については、BLOB サービス操作の条件ヘッダーを指定する方法に関するページを参照してください。

  • データをバッチでアップロードする: すぐにアップロードするのではなく、アップロードする前にデータを集計します。 たとえば、ログ エントリをローカルに保存し、各エントリを個別にアップロードするのではなく、1 つの BLOB として定期的にアップロードします。

次のステップ