Azure Files のパフォーマンスについて
Azure Files は、ほとんどのアプリケーションとユース ケースのパフォーマンス要件を満たすことができます。 この記事では、ファイル共有のパフォーマンスに影響を与える可能性があるさまざまな要因と、ワークロードに合わせて Azure ファイル共有のパフォーマンスを最適化する方法について説明します。
適用対象
| ファイル共有の種類 | SMB | NFS |
|---|---|---|
| Standard ファイル共有 (GPv2)、LRS/ZRS |  |
 |
| Standard ファイル共有 (GPv2)、GRS/GZRS | |
|
| Premium ファイル共有 (FileStorage)、LRS/ZRS | |
|
用語集
ストレージのパフォーマンスに関連する以下の重要な用語を押さえておくと、この記事を理解するのに役立ちます。
1 秒あたりの IO 操作回数 (IOPS)
IOPS (1 秒あたりの入出力操作) は、1 秒あたりのファイル システム操作の数を測定したものです。 "IO" という用語は、Azure Files ドキュメントの "操作" および "トランザクション" という用語と同等です。
I/O サイズ
I/O サイズ (ブロック サイズとも呼ばれます) は、アプリケーションがストレージに対して単一の入出力 (I/O) 操作を実行するために使用する要求のサイズです。 アプリケーションに応じて、I/O サイズは 4 KiB などの非常に小さいサイズから、非常に大きなサイズまでさまざまです。 I/O サイズは、達成可能なスループットにおいて大きな役割を果たします。
スループット
スループットは、1 秒あたりにストレージから読み取ったり書き込んだりするビット数を表し、1 秒あたりのメビバイト単位 (MiB/秒) で測定されます。 スループットを計算するには、IOPS に I/O サイズを乗算します。 たとえば、10,000 IOPS * 1 MiB I/O サイズ = 10 GiB/秒、10,000 IOPS * 4 KiB I/O サイズ = 38 MiB/秒と計算できます。
待機時間
待機時間は遅延のシノニムであり、通常はミリ秒単位 (ms) で測定されます。 待機時間には、エンドツーエンドの待機時間とサービス待機時間の 2 種類があります。 詳しくは、「待機時間」をご覧ください。
キューの深さ
キューの深さは、ストレージ リソースが一度に処理できる保留中の I/O 要求の数です。 詳細については、「キューの深さ」を参照してください。
使用パターンに基づいてパフォーマンス レベルを選択する
Azure Files には、適切なレベルのパフォーマンスと価格でデータを格納できるようにすることで、コストを削減するのに役立つさまざまなストレージ層が用意されています。 Azure Files には、Standard と Premium の 2 つのパフォーマンス レベルが用意されています。 Standard ファイル共有は、ハード ディスク ドライブ (HDD) によってサポートされるストレージ システムでホストされますが、Premium ファイル共有はソリッド ステート ドライブ (SSD) によってサポートされ、パフォーマンスが向上します。 Standard ファイル共有には、複数のストレージ層 (トランザクション最適化、ホット、クール) があり、それらの間をシームレスに移動して保存データのストレージとトランザクションの価格を最大化できます。 ただし、異なるストレージ アカウント間でデータを物理的に移行しないと、Standard レベルと Premium レベルの間を移動することはできません。
Standard ファイル共有と Premium ファイル共有のどちらかを選択する場合は、Azure Files で実行する予定の使用パターンの要件を理解しておくことが重要です。 大量の IOPS、非常に高速なデータ転送速度、または非常に短い待機時間が必要な場合は、Premium Azure ファイル共有を選択する必要があります。
次の表は、Standard と Premium の間で予想されるパフォーマンス目標をまとめたものです。 詳細については、「Azure Files のスケーラビリティおよびパフォーマンスのターゲット」を参照してください。
| 使用パターンの要件 | Standard | Premium |
|---|---|---|
| 書き込み待機時間 (1 桁のミリ秒) | はい | はい |
| 読み取り待機時間 (1 桁のミリ秒) | いいえ | はい |
Premium ファイル共有は、共有サイズに基づいて次のパフォーマンス プロファイルを保証するプロビジョニング モデルを提供します。 詳細については、「プロビジョニング モデル」に関する記事をご覧ください。 バースト クレジットは、ファイル共有のトラフィックがベースライン IOPS を下回るたびに、バースト バケットに蓄積されます。 獲得クレジットは、操作がベースライン IOPS を超えたときにバーストを有効にするために後で使用されます。
| 容量 (GiB) | ベースライン IOPS | バースト IOPS | バースト クレジット | スループット (イングレス + エグレス) |
|---|---|---|---|---|
| 100 | 3,100 | 最大 10,000 | 24,840,000 | 110 MiB/秒 |
| 500 | 3,500 | 最大 10,000 | 23,400,000 | 150 MiB/秒 |
| 1,024 | 4,024 | 最大 10,000 | 21,513,600 | 203 MiB/秒 |
| 5,120 | 8,120 | 最大 15,360 | 26,064,000 | 613 MiB/秒 |
| 10,240 | 13,240 | 最大 30,720 | 62,928,000 | 1,125 MiB/秒 |
| 33,792 | 36,792 | 最大 100,000 | 227,548,800 | 3,480 MiB/秒 |
| 51,200 | 54,200 | 最大 100,000 | 164,880,000 | 5,220 MiB/秒 |
| 102,400 | 100,000 | 最大 100,000 | 0 | 10,340 MiB/秒 |
パフォーマンス チェックリスト
新規または既存のワークロードのパフォーマンス要件を評価する場合でも、使用パターンを理解すると、予測可能なパフォーマンスを実現するのに役立ちます。 ストレージ管理者またはアプリケーション開発者と相談して、次の使用パターンを決定してください。
待機時間感度: ユーザーはファイルを開くか、Azure Files で実行される仮想デスクトップと対話していますか。 これらは、読み取り待機時間に敏感であり、エンド ユーザーの目にもつきやすいワークロードの例です。 これらの種類のワークロードは、Premium の Azure ファイル共有に適しており、読み取り操作と書き込み操作の両方に 1 ミリ秒の待機時間を提供できます (小さな I/O サイズの場合は < 2 ミリ秒)。
IOPS とスループットの要件: Premium ファイル共有では、標準のファイル共有よりも大きな IOPS とスループットの制限がサポートされます。 詳細については、ファイル共有のスケール ターゲットに関するセクションを参照してください。
ワークロードの期間と頻度: 短時間 (分) および頻度の低い (時間単位) ワークロードでは、実行時間が長く、頻繁に発生するワークロードと比較して、Standard ファイル共有のパフォーマンス上限に到達する可能性は低くなります。 Premium ファイル共有では、プロビジョニング サイズに基づいて使用する適切なパフォーマンス プロファイルを決定するときに、ワークロードの期間を参考にできます。 ワークロードがバーストする必要がある期間と、ベースライン IOPS を下回る期間に応じて、ピーク時にワークロードに対応できる十分なバースト クレジットを一貫して蓄積しているかどうかを判断できます。 適切なバランスを見出だすと、ファイル共有を過剰にプロビジョニングしてしまう場合と比べ、コストが削減されます。 よく見られる失敗は、数分間だけパフォーマンス テストを実行して満足することです。これによって、多くの場合、判断を誤ります。 パフォーマンスについて現実的な見方ができるようにするには、十分に高い頻度と長い期間でテストしてください。
ワークロードの並列化: 同じクライアント上の複数のスレッド、プロセス、またはアプリケーション インスタンスを使用して操作を並列で実行するワークロードの場合、Premium ファイル共有は、標準のファイル共有 (SMB マルチチャネル) よりも明確なメリットが得られます。 詳細については、「SMB Azure ファイル共有のパフォーマンスを向上させる」を参照してください。
API 操作の分散: ファイルのオープン/クローズ操作でワークロード メタデータが重く感じますか。 これは、大量のファイルに対して読み取り操作を実行しているワークロードでよく起こります。 「メタデータまたは名前空間の過大なワークロード」をご覧ください。
待機時間
待機時間について考慮するときは、まず、Azure Files で待機時間がどのように決定されるかを理解することが重要です。 最も一般的な測定値は、エンドツーエンドの待機時間とサービス待機時間のメトリックに関連する待機時間です。 これらのトランザクション メトリックを使用すると、アプリケーション トラフィックがクライアントとの間で転送に費やす時間を特定することで、クライアント側の待機時間やネットワークの問題を識別できます。
エンドツーエンドの待機時間 (SuccessE2ELatency) は、トランザクションがクライアントからネットワークを経由して Azure Files サービスに到達し、クライアントに戻る完全なラウンド トリップを実行するのにかかる合計時間です。
サービス待機時間 (SuccessServerLatency) は、トランザクションが Azure Files サービス内でのみラウンドトリップするのにかかる時間です。 これには、クライアントまたはネットワークの待機時間は含まれません。
SuccessE2ELatency 値と SuccessServerLatency 値の差は、ネットワークやクライアントによって発生する可能性のある待機時間を示します。
クライアント待機時間とサービス待機時間 (この場合は Azure Files のパフォーマンス) を混同してしまうことがよくあります。 たとえば、サービス待機時間が、短い待機時間を報告していて、エンド ツー エンドの待機時間が要求に対して非常に長い待機時間を報告している場合、すべての時間は Azure Files サービスではなく、クライアント間の転送に費やされていることを示しています。
さらに、図に示すように、サービスから離れるほど待機時間のエクスペリエンスが遅くなり、クラウド サービスでパフォーマンスのスケール上限に到達するのが難しくなります。 これは、オンプレミスから Azure Files にアクセスする場合に特に当てはまります。 ExpressRoute のようなオプションはオンプレミスに最適ですが、同じ Azure リージョンでのみ実行されているアプリケーション (コンピューティング + ストレージ) のパフォーマンスには適しません。
ヒント
Azure の VM を使用してオンプレミスと Azure の間のパフォーマンスをテストすることは、Azure への接続のネットワーク機能をベースライン化するための効果的で実用的な方法です。 多くの場合、ExpressRoute 回線または VPN ゲートウェイのサイズが不足しているか、正しくルーティングされていないと、ワークロードの速度が低下します。
キューの深さ
キューの深さは、ストレージ リソースがサービスを提供できる未処理の I/O 要求の数です。 ストレージ システムで使用されるディスクが HDD スピンドル (IDE、SATA、SAS) からソリッド ステート デバイス (SSD、NVMe) に進化するにつれて、より深いキューの深さをサポートできるようになりました。 大規模なデータセット内の 1 つのファイルと順次対話する 1 つのクライアントで構成されるワークロードは、キューの深さが浅い例です。 これに対し、複数のスレッドと複数のファイルで並列処理をサポートするワークロードでは、より深いキューの深さを簡単に実現できます。 Azure Files は、数千の Azure クラスター ノードにまたがる分散ファイル サービスであり、大規模にワークロードを実行するように設計されているため、キューの深さが深いワークロードを構築して、テストすることをお勧めします。
キューの深さは、クライアント、ファイル、スレッドと組み合わせつつ、いくつかの異なる方法で実現できます。 ワークロードのキューの深さを判断するには、クライアントの数にファイルの数とスレッドの数を乗算します (クライアント * ファイル * スレッド = キューの深さ)。
次の表は、キューの深さを掘り下げるために使用できる、さまざまな組み合わせを示しています。 最適なキューの深さである 64 を超えることはできますが、推奨されません。 その深さを超えても、パフォーマンスの向上は見られず、かえって TCP の飽和状態により待機時間が長くなるリスクがあります。
| クライアント | [ファイル] | スレッド | キューの深さ |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 1 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 64 |
ヒント
パフォーマンスの上限に到達させるには、ワークロードまたはベンチマーク テストを、必ず複数のファイルを含むマルチスレッドにしてください。
シングルスレッドのアプリケーションとマルチスレッドのアプリケーション
Azure Files は、マルチスレッド アプリケーションに最適です。 マルチスレッドがワークロードに与えるパフォーマンスへの影響を理解する最も簡単な方法は、I/O ごとにシナリオを検証する方法です。 次の例には、Azure ファイル共有との間で、できるだけ早く 10,000 個の小さなファイルをコピーする必要のあるワークロードがあります。
この表では、4 KiB ブロック サイズで書き込まれるシングルスレッドのアプリケーションに基づいて、Azure ファイル共有に 1 つの 16 KiB ファイルを作成するためにかかる時間 (ミリ秒) を細かく分けて示しています。
| I/O 操作 | 作成 | 4 KiB 書き込み | 4 KiB 書き込み | 4 KiB 書き込み | 4 KiB 書き込み | 閉じる | 合計 |
|---|---|---|---|---|---|---|---|
| スレッド 1 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
この例では、1 つの 16 KiB ファイルを作成するのに 6 つの操作で約 14 ミリ秒かかります。 シングルスレッドのアプリケーションで 10,000 個のファイルを Azure ファイル共有に移動する場合、各ファイルは一度に 1 つずつ移動されるため、140,000 ミリ秒 (14 ms * 10,000) または 140 秒かかります。 各要求を処理する時間は、前のセクションで説明したように、コンピューティングとストレージが互いにどの程度近い場所にあるかによって主に決まります。
1 つではなく 8 つのスレッドを使用することで、上記のワークロードを 140,000 ミリ秒 (140 秒) から 17,500 ミリ秒 (17.5 秒) に短縮することができます。 次の表に示すように、一度に 1 つのファイルではなく 8 つのファイルを並列に移動する場合、同じ量のデータを 87.5% 短い時間で移動できます。
| I/O 操作 | 作成 | 4 KiB 書き込み | 4 KiB 書き込み | 4 KiB 書き込み | 4 KiB 書き込み | 閉じる | 合計 |
|---|---|---|---|---|---|---|---|
| スレッド 1 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
| スレッド 2 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
| スレッド 3 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
| スレッド 4 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
| スレッド 5 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
| スレッド 6 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
| スレッド 7 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
| スレッド 8 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |