JavaScript を使用したアップロードとダウンロードのパフォーマンス チューニング

アプリケーションで JavaScript 用 Azure Storage クライアント ライブラリを使ってデータが転送される場合、要求の速度、メモリ使用量、さらには成功または失敗に影響を与える可能性のあるいくつかの要因があります。 データ転送のパフォーマンスと信頼性を最大にするには、アプリが実行される環境に基づいて、クライアント ライブラリ転送オプションを事前に構成することが重要です。

この記事では、データ転送オプションのチューニングに関するいくつかの考慮事項について説明します。 クライアント ライブラリを適切にチューニングすると、複数の要求にデータを効率的に分散できるため、操作速度、メモリ使用量、ネットワークの安定性が向上する可能性があります。

アップロードのパフォーマンス チューニング

データ転送オプションを適切に調整することは、アップロードのパフォーマンスの信頼性の鍵となります。 ストレージ転送は、これらの引数の値に基づいて、複数のサブ転送に分割されます。 サポートされる最大転送サイズは、操作とサービスのバージョンによって異なるため、ドキュメントを調べて制限を確認してください。 Blob Storage での転送サイズの制限について詳しくは、「BLOB ストレージのスケール ターゲット」をご覧ください。

アップロードの転送オプションを設定する

BlockBlobParallelUploadOptions でプロパティを構成し、データ転送操作のパフォーマンスを向上させることができます。 次の表に、構成できるプロパティと説明を示します。

maxSingleShotSize

maxSingleShotSize 値は、1 回の要求のアップロードの最大 BLOB サイズ (バイト単位) です。

データ サイズが maxSingleShotSize 以下 の場合、BLOB は 1 つの Put Blob 要求でアップロードされます。 BLOB サイズが maxSingleShotSize より大きい場合、または BLOB サイズが不明な場合、BLOB は一連の Put Block 呼び出しの後に Put Block List を使用してチャンク単位でアップロードされます。

blockSize で指定する値により、 に対して定義する値は "制限されない" ことに注意してください。maxSingleShotSize maxSingleShotSize 引数では、操作全体をサブ転送なしで一度に実行するための、1 つの要求の個別のサイズ制限を定義します。 多くの場合、maxSingleShotSize は、 に対して定義した値より大きくはないにしても、"少なくとも" それと同じ大きさにする必要があります。blockSize データ転送のサイズによっては、このようにすると、転送が 1 つの要求で完了し、複数の要求のオーバーヘッドが回避されるため、パフォーマンスが向上する可能性があります。

状況に最適な値がわからない場合は、maxSingleShotSize に使われているのと同じ値に blockSize を設定するのが安全なオプションです。

blockSize

blockSize 値は、ブロック BLOB をチャンク単位でアップロードするときの転送の最大長 (バイト単位) です。

前に説明したように、この値によって が制限されることは "なく"、maxSingleShotSize より大きくできます。blockSize

データ移動の効率性を維持するため、クライアント ライブラリではすべての転送で blockSize 値に常に達するとは限りません。 転送サイズでサポートされる最大値は、操作によって異なる場合があります。 Blob Storage での転送サイズの制限について詳しくは、「BLOB ストレージのスケール ターゲット」の表をご覧ください。

コードの例

次のコード例は、BlockBlobParallelUploadOptions に値を設定し、そのオプションをアップロードメソッド呼び出しの一部として含める方法を示しています。 このサンプルで使用した値は、推奨を意図したものではありません。 これらの値を適切にチューニングするには、アプリの特定のニーズを考慮する必要があります。

// Specify data transfer options
const uploadOptions = {
  blockSize: 4 * 1024 * 1024, // 4 MiB max block size
  concurrency: 2, // maximum number of parallel transfer workers
  maxSingleShotSize: 8 * 1024 * 1024, // 8 MiB initial transfer size
} 

// Create blob client from container client
const blockBlobClient = containerClient.getBlockBlobClient(blobName);

// Upload blob with transfer options
await blockBlobClient.uploadFile(localFilePath, uploadOptions);

// Specify data transfer options
const uploadOptions: BlockBlobParallelUploadOptions = {
  blockSize: 4 * 1024 * 1024, // 4 MiB max block size
  concurrency: 2, // maximum number of parallel transfer workers
  maxSingleShotSize: 8 * 1024 * 1024, // 8 MiB initial transfer size
};

// Create blob client from container client
const blockBlobClient: BlockBlobClient = containerClient.getBlockBlobClient(blobName);

await blockBlobClient.uploadFile(localFilePath, uploadOptions);

この例では、concurrency プロパティを使って、並列転送ワーカーの最大数を 2 に設定しています。 また、maxSingleShotSize を 8 MiB に設定しています。 BLOB のサイズが 8 MiB 未満の場合、アップロード操作を完了するために必要な要求は 1 つだけです。 BLOB サイズが 8 MiB を超える場合、blockSize プロパティて定義された最大チャンク サイズ 4 MiB のチャンク単位で BLOB がアップロードされます。

アップロードのパフォーマンスに関する考慮事項

アップロード時に、Storage クライアント ライブラリは、BlockBlobParallelUploadOptions に定義された構成オプションに基づいて、特定のアップロード ストリームを複数のサブアップロードに分割します。 REST 操作は、サブアップロードごとに専用の呼び出しで行われます。 この例では、操作は Put Block です。 ストレージ クライアント ライブラリによって、これらの REST 操作が (転送オプションに応じて) 並列に管理されて、完全なアップロードが実行されます。

アップロードの間のバッファーリング

Storage REST レイヤーでは、中断したところから REST アップロード操作を再開することはサポートされていません。個々の転送は、完了するか失われるかのいずれかです。 ストリーム アップロードの回復性を確保するため、ストレージ クライアント ライブラリは、アップロードを始める前に、個々の REST 呼び出しごとにデータをバッファーに格納します。 ネットワーク速度の制限だけでなく、このバッファーリング動作も、順番にアップロードする場合であっても、blockSize の値を小さくすることを検討すべき理由です。 blockSize の値を小さくすると、各要求および失敗した要求の各再試行でバッファーに格納されるデータの最大量が減ります。 あるサイズのデータ転送中にタイムアウトが頻繁に発生する場合は、blockSize の値を小さくすると、バッファリング時間が短縮され、パフォーマンスが向上する可能性があります。

ダウンロードの最適化

ダウンロードのデータ転送オプションの調整は、downloadToBuffer メソッドを使う場合にのみ使用できます。 このメソッドでは、BlobDownloadToBufferOptions で定義されている値に基づいて、バッファーに並列で BLOB がダウンロードされます。 他のダウンロード メソッドでは、データ転送オプションの調整はサポートされていません。

ダウンロードの転送オプションを設定する

downloadToBuffer メソッドを使用する場合、ダウンロード用に次の値を調整できます。

• blockSize: 各要求で転送する最大ブロック サイズ。
• concurrency: 1 回の並列転送の一部として、任意の時点で発行される並列要求の最大数。

ダウンロードのパフォーマンスに関する考慮事項

downloadToBuffer を使用したダウンロード時に、Storage クライアント ライブラリでは、BlobDownloadToBufferOptions で定義された構成オプションに基づいて、特定のダウンロード要求が複数のサブダウンロードに分割されます。 REST 操作は、サブダウンロードごとに専用の呼び出しで行われます。 転送オプションに応じて、クライアント ライブラリにより、これらの REST 操作が並列に管理されて、完全なダウンロードが実行されます。

コードの例

次のコード例は、BlobDownloadToBufferOptions の値を設定し、downloadToBuffer メソッド呼び出しの一部としてオプションを含める方法を示しています。 このサンプルで使用した値は、推奨を意図したものではありません。 これらの値を適切にチューニングするには、アプリの特定のニーズを考慮する必要があります。

// Specify data transfer options
const downloadToBufferOptions = {
    blockSize: 4 * 1024 * 1024, // 4 MiB max block size
    concurrency: 2, // maximum number of parallel transfer workers
}

// Download data to buffer
const result = await client.downloadToBuffer(offset, count, downloadToBufferOptions);

// Specify data transfer options
const downloadToBufferOptions: BlobDownloadToBufferOptions = {
    blockSize: 4 * 1024 * 1024, // 4 MiB max block size
    concurrency: 2, // maximum number of parallel transfer workers
}

// Download data to buffer
const result = await client.downloadToBuffer(offset, count, downloadToBufferOptions);

CRC64-NVME を使用して検証を転送する

BlockBlobParallelUploadOptionsとBlobDownloadToBufferOptionsを使用したパフォーマンス チューニングに加えて、転送検証を構成して、アップロードとダウンロードのデータ整合性を確認できます。 CRC64-NVME は一般的にコンピューティングに対してパフォーマンスが高くなりますが、転送検証を有効にすると、他のチューニングの決定と共に考慮する必要があるパフォーマンスへの影響が生じる可能性があります。

CRC64-NVME を使用した転送検証では、Azure Blob Storageのクライアント レベルのデータ整合性が提供されるため、アプリケーションによって送信されるデータが、Azureに格納および読み取られるのと同じデータであることを確認できます。 有効にすると、Blob SDK はアップロードおよびダウンロード時に CRC64-NVME チェックサムを計算して検証し、サービスは受信するデータと返すデータについて CRC64-NVME チェックサムを独立して計算して検証します。 検証は各要求と完全なデータ ストリームで実行され、ブロック アップロードや範囲読み取りなどのパーティションでデータが転送された場合でも、BLOB 全体が検証されます。 詳細については、「 構造化ボディフォーマット 」を参照してください。

転送検証オプションは、BlobClientConfig を使用してクライアント レベルで定義できます。BlobClient インスタンスから呼び出されるすべてのメソッドに検証オプションを適用します。 または、 BlobUploadOptions や BlobDownloadOptions などのオプションを使用して、操作レベルで転送検証 オプションをオーバーライドすることもできます。

const blobServiceClient = new BlobServiceClient(
   `https://${account}.blob.core.windows.net`,
   new DefaultAzureCredential(),
   {
     uploadContentChecksumAlgorithm: "StorageCrc64",
     downloadContentChecksumAlgorithm: "StorageCrc64",
   }
);

 const blobServiceClient: BlobServiceClient = new BlobServiceClient(
   `https://${account}.blob.core.windows.net`,
   new DefaultAzureCredential(),
   {
     uploadContentChecksumAlgorithm: "StorageCrc64",
     downloadContentChecksumAlgorithm: "StorageCrc64",
   },
);

関連するコンテンツ

• Azure Storage の操作のパフォーマンスに影響を与える可能性のある要因について詳しくは、「Blob Storage での待ち時間」をご覧ください。
• Blob Storage を使用するアプリのパフォーマンスを最適にするための設計に関する考慮事項の一覧については、「BLOB ストレージのパフォーマンスとスケーラビリティのチェックリスト」をご覧ください。