Go を使用したアップロードとダウンロードのパフォーマンス チューニング
アプリケーションが Go 用 Azure Storage クライアント ライブラリを使ってデータを転送する場合、要求の速度、メモリ使用量、さらには成功または失敗に影響を与える可能性のあるいくつかの要因があります。 データ転送のパフォーマンスと信頼性を最大にするには、アプリが実行される環境に基づいて、クライアント ライブラリ転送オプションを事前に構成することが重要です。
この記事では、データ転送オプションのチューニングに関するいくつかの考慮事項について説明します。 クライアント ライブラリを適切にチューニングすると、複数の要求にデータを効率的に分散できるため、操作速度、メモリ使用量、ネットワークの安定性が向上する可能性があります。
アップロードのパフォーマンス チューニング
データ転送オプションを適切に調整することは、アップロードのパフォーマンスの信頼性の鍵となります。 ストレージ転送は、これらのプロパティの値に基づいて、複数のサブ転送に分割されます。 サポートされる最大転送サイズは、操作とサービスのバージョンによって異なるため、ドキュメントを調べて制限を確認してください。 Blob Storage での転送サイズの制限について詳しくは、「BLOB ストレージのスケール ターゲット」をご覧ください。
アップロードの転送オプションを設定する
BLOB の合計サイズが 256 MB 以下の場合、データは単一の Put Blob 要求でアップロードされます。 BLOB サイズが 256 MB より大きい、または BLOB サイズが不明な場合、BLOB は一連の Put Block 呼び出しの後に Put Block List を使用してチャンク単位でアップロードされます。
アプリのニーズに基づいて、次のプロパティを構成および調整できます:
BlockSize
: ブロック BLOB をチャンク単位でアップロードするときの転送の最大長 (バイト単位) です。 既定値は 4 MB です。Concurrency
: 並列で使用できるサブ転送の最大数。 既定値は 5 です。
これらの構成オプションは、次の方法を使用してアップロードするときに使用できます:
Upload メソッドは、これらのオプションをサポートせず、1 つの要求でデータをアップロードします。
Note
指定されていない場合、各データ転送オプションの既定値がクライアント ライブラリで使用されます。 通常、これらの既定値は、データ センター環境でのパフォーマンスは優れていますが、ホーム コンシューマー環境には適していない可能性があります。 データ転送オプションの調整が不十分な場合、処理時間が非常に長くなる可能性があり、要求がタイムアウトすることさえあります。 これらの値を事前にテストし、アプリケーションと環境のニーズに基づいて調整することをお勧めします。
BlockSize
BlockSize
引数は、ブロック BLOB をチャンク単位でアップロードするときの転送の最大長 (バイト単位) です。
データ移動の効率性を維持するため、クライアント ライブラリではすべての転送で BlockSize
値に常に達するとは限りません。 転送サイズでサポートされる最大値は、操作によって異なる場合があります。 Blob Storage での転送サイズの制限について詳しくは、「BLOB ストレージのスケール ターゲット」の表をご覧ください。
コードの例
次のコード例では、UploadFileOptions インスタンスの値を定義し、これらの構成オプションをパラメーターとして UploadFile に渡す方法を示します。
このサンプルで提供される値は、推奨を意図したものではありません。 これらの値を適切にチューニングするには、アプリの特定のニーズを考慮する必要があります。
func uploadBlobWithTransferOptions(client *azblob.Client, containerName string, blobName string) {
// Open the file for reading
file, err := os.OpenFile("path/to/sample/file", os.O_RDONLY, 0)
handleError(err)
defer file.Close()
// Upload the data to a block blob with transfer options
_, err = client.UploadFile(context.TODO(), containerName, blobName, file,
&azblob.UploadFileOptions{
BlockSize: int64(8 * 1024 * 1024), // 8 MiB
Concurrency: uint16(2),
})
handleError(err)
}
この例では、Concurrency
フィールドを使って、並列転送ワーカーの数を 2 に設定しています。 この構成では、最大 2 つの接続が同時に開かれ、アップロードを並列で実行できます。 BLOB サイズが 256 MB を超える場合、Block_Size
フィールドによって設定された最大チャンク サイズ 8 MiB のチャンク単位で BLOB がアップロードされます。
アップロードのパフォーマンスに関する考慮事項
アップロード時に、Storage クライアント ライブラリは、クライアントの構築時に定義された構成オプションに基づいて、特定のアップロード ストリームを複数のサブアップロードに分割します。 REST 操作は、サブアップロードごとに専用の呼び出しで行われます。 ストレージ クライアント ライブラリによって、これらの REST 操作が (転送オプションに応じて) 並列に管理されて、完全なアップロードが実行されます。
クライアント ライブラリがバッファリングをどのように処理するかについては、次のセクションで説明します。
Note
ブロック BLOB の最大ブロック数は 50,000 ブロックです。 したがって、ブロック BLOB の最大サイズは Block_Size
の 50,000 倍です。
アップロードの間のバッファーリング
Storage REST レイヤーでは、中断した REST アップロード操作の取得はサポートされていません。転送ごとに完了するか、失われます。 ストリーム アップロードの回復性を確保するため、ストレージ クライアント ライブラリは、アップロードを始める前に、個々の REST 呼び出しごとにデータをバッファーに格納します。 ネットワーク速度の制限だけでなく、このバッファーリング動作も、順番にアップロードする場合であっても、BlockSize
の値を小さくすることを検討すべき理由です。 BlockSize
の値を小さくすると、各要求および失敗した要求の各再試行でバッファーに格納されるデータの最大量が減ります。 あるサイズのデータ転送中にタイムアウトが頻繁に発生する場合は、BlockSize
の値を小さくすると、バッファリング時間が短縮され、パフォーマンスが向上する可能性があります。
ダウンロードのパフォーマンス チューニング
データ転送オプションを適切に調整することは、ダウンロードのパフォーマンスの信頼性の鍵となります。 ストレージ転送は、これらのプロパティの値に基づいて、複数のサブ転送に分割されます。
ダウンロードの転送オプションを設定する
次のプロパティは、アプリのニーズに基づいてチューニングできます:
BlockSize
: BLOB のダウンロードに使用される最大チャンク サイズ。 既定値は 4 MB です。Concurrency
: 並列で使用できるサブ転送の最大数。 既定値は 5 です。
これらのオプションは、次の方法を使用してダウンロードするときに使用できます:
DownloadStream メソッドは、これらのオプションをサポートせず、1 つの要求でデータをダウンロードします。
コードの例
次のコード例では、DownloadFileOptions インスタンスの値を定義し、これらの構成オプションをパラメーターとして DownloadFile に渡す方法を示します。
このサンプルで提供される値は、推奨を意図したものではありません。 これらの値を適切にチューニングするには、アプリの特定のニーズを考慮する必要があります。
func downloadBlobTransferOptions(client *azblob.Client, containerName string, blobName string) {
// Create or open a local file where we can download the blob
file, err := os.Create("path/to/sample/file")
handleError(err)
// Download the blob to the local file
_, err = client.DownloadFile(context.TODO(), containerName, blobName, file,
&azblob.DownloadFileOptions{
BlockSize: int64(4 * 1024 * 1024), // 4 MiB
Concurrency: uint16(2),
})
handleError(err)
}
ダウンロードのパフォーマンスに関する考慮事項
ダウンロード時に、Storage クライアント ライブラリは、クライアントの構築時に定義された構成オプションに基づいて、特定のダウンロード要求を複数のサブダウンロードに分割します。 REST 操作は、サブダウンロードごとに専用の呼び出しで行われます。 転送オプションに応じて、クライアント ライブラリにより、これらの REST 操作が並列に管理されて、完全なダウンロードが実行されます。
関連するコンテンツ
- この記事は、Go の Blob Storage 開発者ガイドの一部です。 開発者ガイドの記事の完全な一覧については、「アプリケーションをビルドする」を参照してください。
- Azure Storage の操作のパフォーマンスに影響を与える可能性のある要因について詳しくは、「Blob Storage での待ち時間」をご覧ください。
- Blob Storage を使用するアプリのパフォーマンスを最適にするための設計に関する考慮事項の一覧については、「BLOB ストレージのパフォーマンスとスケーラビリティのチェックリスト」をご覧ください。