BLOB ストレージのパフォーマンスとスケーラビリティのチェックリスト
Microsoft は、BLOB ストレージを使用して高パフォーマンス アプリケーションを開発するための多数の実証済みプラクティスを開発してきました。 このチェックリストでは、パフォーマンスを最適化するために開発者が従うことのできる主要なプラクティスを示します。 アプリケーションを設計している間、およびプロセス全体を通して、これらのプラクティスに留意してください。
Azure Storage には、容量、トランザクション レート、および帯域幅についてスケーラビリティとパフォーマンスのターゲットがあります。 Azure Storage のスケーラビリティ ターゲットの詳細については、「Standard Storage アカウントのスケーラビリティとパフォーマンスのターゲット」および「BLOB ストレージのスケーラビリティとパフォーマンスのターゲット」を参照してください。
チェック リスト
この記事では、パフォーマンスに関する実証済みプラクティスを、BLOB ストレージ アプリケーションの開発中に従うことのできるチェックリストにまとめています。
スケーラビリティ ターゲット
運用中のアプリケーションがいずれかのスケーラビリティ ターゲットに近づいたり超過したりすると、トランザクション待機時間や調整が増加することがあります。 Azure Storage によってアプリケーションが調整されると、サービスが 503 (サーバー ビジー) または 500 (操作タイムアウト) のエラー コードを返し始めます。 スケーラビリティ ターゲットの制限内にとどまることでこれらのエラーを回避することは、アプリケーションのパフォーマンスを強化するうえで重要な部分です。
Queue サービスのスケーラビリティ ターゲットの詳細については、Azure Storage のスケーラビリティおよびパフォーマンスのターゲットに関するページを参照してください。
ストレージ アカウントの最大数
特定のサブスクリプション/リージョンの組み合わせで許可されているストレージ アカウントの最大数に近づいている場合は、シナリオを評価して、次の条件のいずれかが当てはまるかどうかを確認します。
- ストレージ アカウントを使用して、アンマネージド ディスクを格納し、それらのディスクを仮想マシン (VM) に追加していますか? このシナリオでは、マネージド ディスクを使用することをお勧めします。 マネージド ディスクは自動的に拡張されます。個々のストレージ アカウントを作成して管理する必要はありません。 詳細については、「Azure マネージド ディスクの概要」を参照してください。
- データを分離するために、顧客ごとに 1 つのストレージ アカウントを使用していますか? このシナリオでは、ストレージ アカウント全体ではなく、お客様ごとに BLOB コンテナーを使用することをお勧めします。 Azure Storage では、Azure ロールをコンテナーごとに割り当てることができるようになりました。 詳細は、「BLOB データにアクセスするための Azure ロールを割り当てる」を参照してください。
- 複数のストレージ アカウントを使用したシャード化により、イングレス、エグレス、1 秒あたりの I/O 操作 (IOPS)、または容量を増やしていますか? このシナリオでは、ワークロードに必要なストレージ アカウントの数を減らすために、可能であればストレージ アカウントの制限を引き上げることをお勧めします。 Azure サポートに連絡して、ストレージ アカウントの制限の引き上げをご依頼ください。
容量とトランザクションのターゲット
アプリケーションが 1 つのストレージ アカウントに対するスケーラビリティ ターゲットに接近している場合は、次の方法のいずれかを検討し、適用します。
- アプリケーションがトランザクション ターゲットに達している場合は、高いトランザクション レートと一貫して短い待機時間に合わせて最適化されているブロック BLOB ストレージ アカウントを使用することを検討してください。 詳細については、「Azure ストレージ アカウントの概要」を参照してください。
- 対象のアプリケーションでスケーラビリティ ターゲットに対する接近や超過を引き起こしたワークロードを見直します。 設計を変更して、必要な帯域幅や処理能力を抑えたり、トランザクションを減らしたりすることができないでしょうか?
- アプリケーションがいずれかのスケーラビリティ ターゲットを超過することがほぼ確実な場合には、複数のストレージ アカウントを作成し、それらのアカウントにアプリケーション データを分けて配置します。 このパターンを使用する場合は、後で負荷分散用のストレージ アカウントを追加できるようにアプリケーションを設計してください。 ストレージ アカウント自体では、データ保存、トランザクション実行、データ転送以外の使用に料金が発生することはありません。
- アプリケーションが帯域幅ターゲットに近づいてきた場合は、クライアント側でデータを圧縮し、Azure Storage へのデータ送信に必要な帯域幅を削減する方法を検討します。 データを圧縮することにより帯域幅の節約とネットワーク パフォーマンスの改善が期待できますが、パフォーマンスにマイナスの影響が及ぶ可能性もあります。 クライアント側でデータの圧縮と展開の処理要件が増加することにより生じるパフォーマンスへの影響を評価してください。 圧縮データを格納すると、標準ツールではデータが見づらくなるため、トラブルシューティングが困難になる場合があることに留意してください。
- アプリケーションがスケーラビリティ ターゲットに近づいている場合は、再試行にエクスポネンシャル バックオフを使用していることを確認してください。 この記事に書かれている推奨事項を実践して、スケーラビリティ ターゲットへの到達を回避することを強くお勧めします。 ただし、再試行にエクスポネンシャル バックオフを使用するとアプリケーションの迅速な再試行が妨げられ、調整が悪化する可能性もあります。 詳細については、「タイムアウト エラーとサーバー ビジー エラー」セクションを参照してください。
1 つの BLOB に同時にアクセスする複数のクライアント
1 つの BLOB に多数のクライアントが同時にアクセスする場合は、BLOB ごとおよびストレージ アカウントごとにスケーラビリティ ターゲットを考慮する必要があります。 1 つの BLOB にアクセスできるクライアントの正確な数は、BLOB を同時に要求しているクライアントの数、BLOB のサイズ、ネットワークの状態などの要因によって異なります。
Web サイトから提供されるイメージやビデオなどのように CDN によって BLOB を配布できる場合は、CDN を使用できます。 詳しくは、「コンテンツ配信」セクションをご覧ください。
データが機密である科学シミュレーションなどの他のシナリオでは、2 つの選択肢があります。 1 つ目の方法は、同時にアクセスするのではなく、一定期間にわたって BLOB にアクセスするようにワークロードのアクセスを調整するというものです。 別の方法では、BLOB を複数のストレージ アカウントに一時的にコピーして、BLOB ごとおよびストレージ アカウント全体の合計 IOPS を高めることができます。 結果はアプリケーションの動作によって異なるので、設計時には必ずコンカレンシー パターンをテストするようにしてください。
BLOB ごとの帯域幅と操作
1 つの BLOB では 1 秒あたり最大 500 個の要求がサポートされます。 複数のクライアントが同じ BLOB を読み取る必要があり、この制限を超過する可能性がある場合は、ブロック BLOB ストレージ アカウントの使用を検討してください。 ブロック BLOB ストレージ アカウントは、より高い要求レート (1 秒あたりの I/O 操作 (IOPS)) を提供します。
また、Azure CDN などのコンテンツ配信ネットワーク (CDN) を使用して、BLOB での操作を分散することもできます。 Azure CDN の詳細については、Azure CDN の概要に関する記事を参照してください。
パーティション分割
Azure Storage が BLOB データをどのようにパーティション分割するかを理解すると、パフォーマンスの向上に役立ちます。 Azure Storage は、複数のパーティションにまたがるデータよりも、1 つのパーティション内のデータをより迅速に提供できます。 BLOB に適切な名前を付けることで、読み取り要求の効率を向上させることができます。
Blob ストレージでは、範囲ベースのパーティション構成を使用して、スケーリングと負荷分散を行います。 各 BLOB には、完全な BLOB 名 (アカウント + コンテナー + BLOB) で構成されるパーティション キーがあります。 パーティション キーは、BLOB データを複数の範囲にパーティション分割するために使用されます。 それらの範囲は、Blob ストレージ全体で負荷分散されます。
範囲ベースのパーティション分割は、辞書順 (mypayroll、myperformance、myemployees など) またはタイムスタンプ (log20160101、log20160102、log20160102 など) を使用する命名規則では、負荷が増加してより小さい範囲への分割が必要になるまでは、パーティションは同じパーティション サーバーに併置される可能性が高いことを意味します。 同じパーティション サーバーに BLOB を併置するとパフォーマンスが向上します。したがって、パフォーマンス向上の重要な部分として、BLOB を最も効果的に整理できる方法で BLOB に名前を付けることが必要になります。
たとえば、コンテナー内のすべての BLOB は、これらの BLOB の負荷がさらにパーティション範囲の再調整を必要とするまで、1 台のサーバーで提供されます。 同様に、名前が辞書順に配置された負荷の軽いアカウントのグループは、これらの 1 つまたはすべてのアカウントで負荷を複数のパーティション サーバーに分割することが必要になるまでは、1 台のサーバーで提供できます。
負荷分散の各操作は、操作中のストレージの呼び出しの待機時間に影響を与える可能性があります。 パーティションに対するトラフィックの急激な増加を処理するサービスの能力は、負荷分散操作が開始されて、パーティション キーの範囲が再調整されるまでは、1 台のパーティション サーバーのスケーラビリティによって制限されます。
このような操作の頻度を減らすために、ベスト プラクティスに従うことができます。
可能であれば、Standard および premium ストレージ アカウントの場合は、 256 KiB より大きい BLOB またはブロックのサイズを使用します。 BLOB またはブロックのサイズを大きくすると、スループットの高いブロック BLOB が自動的にアクティブ化されます。 高スループットのブロック BLOB は、パーティションの名前付けによる影響を受けない高パフォーマンスの取り込みを提供します。
アカウント、コンテナー、BLOB、テーブル、およびキューに対して使用する命名規則を確認します。 ニーズに最も適したハッシュ関数を使用して、アカウント、コンテナー、BLOB の名前に 3 桁のハッシュでプレフィックスを付けることを検討してください。
タイムスタンプまたは数値識別子を使用してデータを整理する場合は、追加専用 (または先頭への追加専用) のトラフィック パターンを使用しないようにしてください。 これらのパターンは、範囲ベースのパーティション分割システムには適していません。 これらのパターンを使用すると、すべてのトラフィックが 1 つのパーティションに送られて、システムの効率的な負荷分散が妨げられる可能性があります。
たとえば、yyyymmdd などのタイムスタンプを持つ BLOB を使用する毎日の操作がある場合、その毎日の操作のすべてのトラフィックが、1 つのパーティション サーバーによって処理される 1 つの BLOB に送信されます。 BLOB ごとの制限とパーティションごとの制限がニーズを満たすかどうかを確認し、必要に応じて、この操作を複数の BLOB に分割することを検討してください。 同様に、時系列データをテーブルに格納する場合は、すべてのトラフィックがキーの名前空間の最後の部分に送信される可能性があります。 数値 ID を使用している場合は、ID の前に 3 桁のハッシュを付けます。 タイムスタンプを使用している場合は、タイムスタンプの前に秒の値を付けます (たとえば、ssyyyymmdd)。 アプリケーションで一覧表示やクエリの操作が定期的に行われる場合は、クエリの数を制限するハッシュ関数を選択します。 場合によっては、ランダムなプレフィックスで十分な可能性があります。
Azure Storage で使用されるパーティション構成の詳細については、Azure Storage: 強力な一貫性を備えた高可用性クラウド ストレージ サービスを参照してください。
ネットワーク
アプリケーションの物理ネットワークの制約がパフォーマンスに大きな影響を及ぼすことがあります。 以降のセクションでは、ユーザーが遭遇する可能性のあるいくつかの制限について説明します。
クライアントのネットワーク機能
ネットワーク リンクの帯域幅と接続品質は、アプリケーションのパフォーマンスに重要な役割を果たします。以降のセクションでは、この点について説明しています。
スループット
帯域幅については、多くの場合にクライアントの処理能力が問題になります。 大きい Azure インスタンスは、処理能力の高い NIC を使用します。そのため、1 台のコンピューターのネットワーク制限を引き上げる必要がある場合は、大きなインスタンスを使用するか VM の数を増やすことを検討してください。 オンプレミスのアプリケーションから Azure Storage にアクセスする場合にも、同じ規則が当てはまります。クライアント デバイスのネットワーク性能と、Azure Storage の場所へのネットワーク接続を把握し、それらを必要に応じて増強するか、それぞれの性能の範囲内でアプリケーションが稼働するように設計してください。
接続品質
他のネットワーク運用と同様に、エラーやパケット損失が生じるネットワーク状態では、遅延が生じて有効なスループットが損なわれることに留意してください。 WireShark または NetMon は、この問題の診断に有用です。
場所
分散型環境では、サーバーの近くにクライアントを配置すると、パフォーマンスが最大になります。 最小限の遅延で Azure Storage にアクセスするには、同じ Azure リージョン内にクライアントを配置するのが最適です。 たとえば、Azure Storage を使用する Azure Web アプリを 1 つ保有している場合は、その両方を単一のリージョン内に配置します (たとえば、米国西部や東南アジア)。 リソースを併置することにより待ち時間が短縮され、コストが低下します。1 つのリージョン内での帯域幅使用は無料であるためです。
Azure 内にホストされていないクライアント アプリケーション (モバイル デバイス アプリやオンプレミスのエンタープライズ サービスなど) が Azure Storage にアクセスする場合、それらのクライアントに近いリージョンにストレージ アカウントを配置することで待機時間が短くなる可能性があります。 クライアントが広範囲に分散されている場合 (一部が北米に、一部がヨーロッパに存在する場合など) は、ストレージ アカウントをリージョンごとに 1 つ使用することを検討します。 アプリケーションが保存するデータが個々のユーザーに固有であり、ストレージ アカウント間でデータをレプリケートする必要がなければ、これは導入しやすい方法です。
BLOB コンテンツを広範囲に分散させるには、Azure CDN などのコンテンツ配信ネットワークを使用します。 Azure CDN の詳細については、「 Azure CDN」を参照してください。
SAS と CORS
ユーザーの Web ブラウザーや携帯電話アプリで実行されている JavaScript などのコードが Azure Storage 内のデータにアクセスするのを承認する必要があるとします。 1 つの方法として、プロキシとして動作するサービス アプリケーションを作成することが考えられます。 このサービスに対してユーザーのデバイスが認証を行うと、Azure Storage リソースへのアクセスがそのサービスによって承認されるというものです。 この方法では、安全でないデバイスにストレージ アカウント キーを知らせずに済みます。 しかし、この方法では、サービス アプリケーションに大きなオーバーヘッドが生じます。ユーザーのデバイスと Azure Storage との間で転送されるデータがすべてそのサービス アプリケーションを通過することになるためです。
Shared Access Signature (SAS) を使用すると、サービス アプリケーションを Azure Storage のプロキシとして用いることを回避できます。 SAS を使用すれば、ユーザーのデバイスから制限付きアクセス トークンを使って、Azure Storage に直接要求を実行できるようになります。 たとえば、ユーザーがアプリケーションに写真をアップロードしたい場合に、サービス アプリケーションで SAS を生成してユーザーのデバイスに送信することが考えられます。 Azure Storage リソースへの書き込みアクセス許可を SAS トークンで与えることが可能です。アクセス許可には期間が指定され、その期間を過ぎると SAS トークンの有効期限が切れます。 SAS の詳細については、「Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。
通常、あるドメイン上の Web サイトでホストされているページの JavaScript が、別のドメインに対して特定の操作 (書き込みなど) を実行することは、Web ブラウザーによって許可されません。 このポリシーは "同一オリジン ポリシー" と呼ばれ、ページ上の悪意のあるスクリプトが別の Web ページ上のデータにアクセスすることを阻止するものです。 ただし、クラウドのソリューションを構築するときには、同一オリジン ポリシーが制限になることがあります。 クロスオリジン リソース共有 (CORS) はブラウザーの機能です。ソース ドメインで生成された要求が信頼済みであることをターゲット ドメインがブラウザーに伝達できます。
たとえば、Azure で実行されている Web アプリケーションが Azure Storage アカウントにリソースを要求するとします。 Web アプリケーションがソース ドメインで、ストレージ アカウントがターゲット ドメインです。 任意の Azure Storage サービスに対して CORS を構成して、ソース ドメインからの要求が Azure Storage によって信頼されていることを Web ブラウザーに伝えることができます。 CORS の詳細については、「Azure Storage でのクロスオリジン リソース共有 (CORS) のサポート」を参照してください。
SAS と CORS はどちらも、Web アプリケーションに対する不要な負荷をなくす効果があります。
キャッシュ
キャッシュは、パフォーマンスにおいて重要な役割を果たします。 以降クションでは、キャッシュのベスト プラクティスについて説明します。
データの読み取り
一般に、データを 1 回読み取る方が、2 回読み取るよりも望ましいです。 Azure Storage から 50 MiB の BLOB を取得して、ユーザーにコンテンツとして提供する Web アプリケーションの例について考えてみましょう。 アプリケーションが BLOB をディスクにローカルにキャッシュし、キャッシュされたバージョンをその後のユーザー要求に対して取り出すのが理想的です。
キャッシュ後に BLOB が変更されていない場合に BLOB を取得しないようにする 1 つの方法は、変更時刻の条件ヘッダーを使用して、GET 操作を制限することです。 最終変更時刻が、BLOB がキャッシュされた時刻よりも後であれば、BLOB は取得されて、再度キャッシュされます。 それ以外の場合は、最適なパフォーマンスのために、キャッシュされた BLOB が取得されます。
また、BLOB 取得後の短期間は、BLOB が変更されていないままであると想定するようにアプリケーションを設計することもできます。 この場合、アプリケーションは、BLOB がその期間中に変更されたかどうかを確認する必要はありません。
アプリケーションで頻繁に使用される構成データ、参照データ、およびその他のデータは、キャッシュの対象として適しています。
条件ヘッダーの使用の詳細については、「Blob service 操作の条件ヘッダーの指定」を参照してください。
データの一括アップロード
一部のシナリオでは、データをローカルで集計し、各データをすぐにアップロードするのではなく、定期的に一括でアップロードできます。 たとえば、Web アプリケーションでアクティビティのログ ファイルを保持しているとします。 アプリケーションでは、アクティビティが発生するたびにすべてのアクティビティの詳細をテーブルにアップロードすることも (その場合、多くのストレージ操作が必要になります)、アクティビティの詳細をローカルのログ ファイルに保存して、すべてのアクティブの詳細を区切りファイルとして定期的に BLOB にアップロードすることもできます。 各ログ エントリのサイズが 1 KB の場合、1 回のトランザクションで何千個ものエントリをアップロードできます。 1 回のトランザクションでは、最大 64 MiB のサイズの BLOB のアップロードがサポートされます。 アプリケーション開発者は、クライアント デバイスまたはアップロードのエラーの可能性を考慮して設計する必要があります。 1 つのアクティビティではなく、ある時間間隔を対象としたアクティビティ データをダウンロードする必要がある場合は、テーブル ストレージよりも BLOB ストレージを使用することをお勧めします。
.NET 構成
このセクションでは、.NET Framework を使用するプロジェクトの場合に、パフォーマンスの大幅な向上を図るために利用できるいくつかの簡単な構成設定を示します。 .NET 以外の言語を使用している場合は、その言語に類似の概念がないか確認してください。
既定の接続数の上限を引き上げる
Note
接続プールは ServicePointManager クラスによって制御されるため、このセクションは .NET Framework を使用するプロジェクトに適用されます。 .NET Core では、接続プールの管理に関して大幅な変更が導入されました。接続プールは HttpClient レベルで行われ、既定ではプールのサイズが制限されません。 つまり、HTTP 接続はワークロードを満たすように自動的にスケーリングされます。 パフォーマンスの向上を活用するには、可能な場合は最新バージョンの .NET を使用することをお勧めします。
.NET Framework を使用するプロジェクトでは、次のコードを使用して、既定の接続数の上限 (通常、クライアント環境では 2、サーバー環境では 10) を 100 に引き上げることができます。 一般的に、この値はアプリケーションが使用するおおよそのスレッド数に設定します。 接続数の上限は、接続を開始する前に設定してください。
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
.NET Framework での接続プールの制限について詳しくは、「.NET Framework での接続プールの制限と .NET 用の新しい Azure SDK」をご覧ください。
他のプログラミング言語については、ドキュメントを参照して接続数の上限の設定方法を確認してください。
スレッドの最小数を増やす
同期呼び出しを非同期タスクと共に使用している場合、スレッド プールのスレッド数を増やしたい場合があります。
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
詳細については、ThreadPool.SetMinThreads メソッドを参照してください。
無制限の並列処理
並列処理はパフォーマンスの観点では非常に有用ですが、無制限の並列処理を使用すると、スレッド数や並列要求数に対して適用される制限がなくなることになるので、注意が必要です。 同じストレージ アカウント内の複数のパーティションにアクセスする状況や、同じパーティション内の複数の項目にアクセスする状況では、データをアップロードまたはダウンロードするための並列要求の数を制限するようにしてください。 並列処理が無制限の場合、アプリケーションはクライアント デバイスの処理能力やストレージ アカウントのスケーラビリティ ターゲットを超過することがあり、その結果、待ち時間や調整時間が長くなります。
クライアント ライブラリとツール
パフォーマンスを最大限に引き出すためには必ず、Microsoft から提供される最新のクライアント ライブラリとツールを使用してください。 Azure Storage のクライアント ライブラリは、さまざまな言語に対応しています。 また、Azure Storage は PowerShell と Azure CLI をサポートします。 Microsoft はパフォーマンスに留意してこれらのクライアント ライブラリとツールを積極的に開発し、最新のサービス バージョンに遅れることなく対応して、数多くのパフォーマンスの実証済みプラクティスを内部で確実に処理できるように取り組んでいます。
ヒント
ABFS ドライバーは、WASB の本質的な弱点を克服するために設計されました。 ABFS ドライバーはビッグ データ分析専用に最適化されているため、MICROSOFT では WASB ドライバーで ABFS ドライバーを使用することをお勧めします。
サービス エラーの処理
サービスが要求を処理できない場合、Azure Storage からエラーが返されます。 特定のシナリオで Azure Storage から返される可能性のあるエラーについての知識は、パフォーマンスを最適化するうえで役立ちます。 一般的なエラー コードの一覧については、「REST API の一般的なエラー コード」を参照してください。
タイムアウト エラーとサーバー ビジー エラー
アプリケーションがスケーラビリティの限界に近づくと、アプリケーションに対して Azure Storage による調整が発生することがあります。 場合によっては、なんらかの一時的な状態によって、Azure Storage が要求を処理できなくなることもあります。 どちらのケースでも、サービスからは 503 (サーバー ビジー) または 500 (タイムアウト) エラーが返されます。 スループットを高めるためにデータ パーティションがサービスによって再調整されている場合にも、これらのエラーが発生することがあります。 通常、クライアント アプリケーションは、そうしたエラーを引き起こしている操作を再試行する必要があります。 しかし、スケーラビリティ ターゲットを超過しているためにアプリケーションに Azure Storage による調整が発生している場合や、他のなんらかの理由でサービスが要求を処理できない場合、積極的に再試行を実行すると問題が悪化することがあります。 再試行ポリシーにはエクスポネンシャル バックオフを使用することをお勧めします。エクスポネンシャル バックオフは、クライアント ライブラリの既定の動作にもなっています。 この動作では、たとえば、アプリケーションが再試行する間隔を、2 秒後、4 秒後、10 秒後、30 秒後と延ばしていき、最終的に再試行を取りやめます。 そうすれば、調整が起こって動作が悪化することなく、サービスに対するアプリケーションの負荷を大幅に軽減できます。
接続エラーは、調整の結果ではなく、一時的な問題と予想されるので、直後に再試行を実行してかまいません。
再試行できないエラー
クライアント ライブラリは、再試行できるエラーと再試行できないエラーを認識して再試行を処理します。 ただし、Azure Storage REST API を直接呼び出している場合は、再試行すべきではないエラーも一部存在します。 たとえば、400 (正しくない要求) エラーは、クライアント アプリケーションから送信された要求が想定外の形式であったために処理できなかったことを示しています。 この要求を再送信しても、毎回同じ応答が返されることになるので、再試行は無意味です。 Azure Storage REST API を直接呼び出している場合は、どのようなエラーが生じる可能性があるか、また、それらを再試行すべきかどうかを意識するようにしてください。
Azure Storage のエラー コードの詳細については、「状態コードとエラー コード」を参照してください。
BLOB のコピーと移動
Azure Storage には、ストレージ アカウント内、ストレージ アカウント間、オンプレミス システムとクラウド間で BLOB をコピーおよび移動するためのさまざまなソリューションが用意されています。 このセクションでは、パフォーマンスへの影響の観点から、これらのオプションの一部について説明します。 Blob ストレージとの間で効率的にデータを転送する方法の詳細については、「データ転送用の Azure ソリューションを選択する」を参照してください。
BLOB のコピー API
ストレージ アカウント間で BLOB をコピーするには、Put Block From URL 操作を使用します。 この操作では、任意の URL ソースからブロック BLOB に同期的にデータをコピーします。 ストレージ アカウント間でデータを移行する場合、Put Block from URL 操作を使用すると、必要な帯域幅を大幅に削減できます。 コピー操作はサービス側で行われるため、データをダウンロードして再アップロードする必要はありません。
同じストレージ アカウント内でデータをコピーするには、Copy Blob 操作を使用します。 通常、同じストレージ アカウント内でのデータのコピーは迅速に完了します。
AzCopy を使用する
AzCopy コマンドライン ユーティリティは、ストレージ アカウントとの間で BLOB を一括転送するための簡単で効率的なオプションです。 AzCopy はこのシナリオに合わせて最適化されており、高い転送速度を実現できます。 AzCopy バージョン 10 は、Put Block From URL 操作を使用して、ストレージ アカウント間で BLOB データをコピーします。 詳細については、AzCopy v10 を使用した Azure Storage へのデータのコピーまたは移動に関する記事を参照してください。
Azure Data Box を使用する
大量のデータを Blob ストレージにインポートする場合は、オフライン転送に Azure Data Box ファミリを使用することを検討してください。 Microsoft が提供する Data Box デバイスは、時間、ネットワークの可用性、またはコストに制限がある場合に、大量のデータを Azure に移動するのに適した選択です。 詳細については、Azure DataBox のドキュメントをご覧ください。
コンテンツ配信
アプリケーションは、同一リージョンまたは複数のリージョンに存在する多数のユーザーに、同じコンテンツを提供する必要がある場合があります (たとえば、Web サイトのホームページで使用される製品のデモ ビデオ)。 このシナリオでは、Azure Front Door などのコンテンツ配信ネットワーク (CDN) を使用します。 Azure Front Door は、Microsoft の最新のクラウド CDN であり、世界中のユーザーとアプリケーションの静的および動的 Web コンテンツの間で、高速で信頼性が高く、セキュリティで保護されたアクセスを提供します。 Azure Front Door は、Microsoft のグローバル境界ネットワークを使用して Blob Storage コンテンツを配信します。このネットワークには、数百のグローバルおよびローカルのポイント オブ プレゼンス (PoP) があります。 CDN では通常、1 つのストレージ アカウントよりもはるかに高いエグレス制限をサポートできるため、他のリージョンへのコンテンツ配信の待機時間が短縮されます。
Azure Front Door の詳細については、「Azure Front Door」を参照してください。
メタデータの使用
Blob service は、BLOB のプロパティまたはメタデータを含むことができる HEAD 要求をサポートしています。 たとえば、アプリケーションに写真からの Exif (Exchangable Image Format) データが必要な場合は、写真を取得して抽出することができます。 帯域幅を節約してパフォーマンスを向上させるために、アプリケーションは写真をアップロードするときに、データを BLOB のメタデータに格納できます。 その後、HEAD 要求のみを使用して、メタデータ内の Exif データを取得できます。 BLOB の完全な内容ではなくメタデータのみを取得すると、帯域幅が大幅に節約され、Exif データを抽出するために必要な処理時間が短縮されます。 1 つの BLOB につき 8 KiB のメタデータを格納できることに留意してください。
アカウントとコンテナーのメタデータの更新
アカウントとコンテナーのメタデータは、アカウントが存在するリージョンのストレージ サービス全体に伝達されます。 このメタデータの完全な伝達には、操作に応じて最大 60 秒かかることがあります。 次に例を示します。
- 同じリージョンで同じアカウント名のアカウントを迅速に作成、削除、再作成する場合は、アカウントの状態が完全に伝達されるまで 60 秒待っているか必要があり、さもなければ要求が失敗する可能性があります。
- コンテナーに保存されているアクセス ポリシーを確立すると、ポリシーが有効になるまでに最大 30 秒かかる場合があります。
データ転送のパフォーマンス チューニング
アプリケーションで Azure Storage クライアント ライブラリを使ってデータを転送する場合、要求の速度、メモリ使用量、さらには成功または失敗に影響を与える可能性のあるいくつかの要因があります。 データ転送のパフォーマンスと信頼性を最大にするには、アプリが実行される環境に基づいて、クライアント ライブラリ転送オプションを事前に構成することが重要です。 詳細については、「アップロードとダウンロードのパフォーマンス チューニング」を参照してください。
BLOB をすばやくアップロードする
BLOB をすばやくアップロードするには、まず、1 つの BLOB をアップロードするのか、それとも多数をアップロードするのかを決定します。 以下のガイダンスを参考に、状況に応じて、適切な方法を見つけてください。 データ転送に Azure Storage クライアント ライブラリを使用している場合、詳細なガイダンスについては、「データ転送のパフォーマンス チューニング」を参照してください。
1 つの大きな BLOB をすばやくアップロードする
1 つの大きな BLOB をすばやくアップロードするために、クライアント アプリケーションでは、個々の BLOB とストレージ アカウント全体のスケーラビリティ ターゲットに注意して、そのブロックまたはページを並列でアップロードできます。 Azure Storage クライアント ライブラリでは、並列でのアップロードがサポートされています。 サポートされているその他の言語のクライアント ライブラリにおいて、同様のオプションが提供されています。
多数の BLOB をすばやくアップロードする
多数の BLOB をすばやくアップロードするには、複数の BLOB を並列アップロードします。 並列でアップロードすると、アップロードがストレージ サービスの複数のパーティションに分散されるため、並列ブロック アップロードで一度に 1 つずつ BLOB をアップロードするよりも高速になります。 AzCopy は、既定で並列アップロードを実行するため、このシナリオに対して推奨されます。 詳細については、「AzCopy を使ってみる」を参照してください。
正しい種類の BLOB を選択する
Azure Storage では、ブロック BLOB、追加 BLOB、およびページ BLOB がサポートされます。 特定の使用シナリオでは、BLOB の種類の選択がソリューションのパフォーマンスとスケーラビリティに影響を及ぼします。
ブロック BLOB は、大量のデータを効率的にアップロードしたい場合に適しています。 たとえば、写真やビデオを Blob ストレージにアップロードするクライアント アプリケーションは、ブロック BLOB をターゲットにします。
追加 BLOB は、ブロックで構成されているという点でブロック BLOB に似ています。 追加 BLOB を変更すると、BLOB の最後にだけブロックが追加されます。 追加 BLOB は、ログ記録など、アプリケーションが既存の BLOB にデータを追加する必要があるシナリオに役立ちます。
ページ BLOB は、アプリケーションがデータにランダムな書き込みを行う必要がある場合に適しています。 たとえば、Azure 仮想マシンのディスクは、ページ BLOB に格納されています。 詳細については、「ブロック BLOB、追加 BLOB、ページ BLOB について」を参照してください。