✔️ 適用対象: Microsoft.Storage リソース プロバイダーで作成された従来の SMB ファイル共有と NFS ファイル共有
✔️ 適用対象: Microsoft.FileShares リソース プロバイダーで作成されたファイル共有
Azure Files は、ほとんどのアプリケーションとユース ケースのパフォーマンス要件を満たすことができます。 この記事では、ファイル共有のパフォーマンスに影響を与えるさまざまな要因と、ワークロードのAzure Filesのパフォーマンスを最適化する方法について説明します。
ストレージ パフォーマンス用語集
ストレージのパフォーマンスに関連する以下の重要な用語を押さえておくと、この記事を理解するのに役立ちます。
1 秒あたりの IO 操作回数 (IOPS)
IOPS (1 秒あたりの入出力操作) は、1 秒あたりのファイル システム操作の数を測定したものです。 Azure Filesドキュメントでは、"IO" という用語は "operation" と "transaction" という用語と交換可能です。
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/秒です。
待機時間
待機時間は遅延のシノニムであり、ミリ秒単位で測定されます。 待機時間には、エンドツーエンドの待機時間とサービス待機時間の 2 種類があります。 詳しくは、「待機時間」をご覧ください。
キューの深さ
キューの深さは、ストレージ リソースが一度に処理できる保留中の I/O 要求の数です。 詳細については、「キューの深さ」を参照してください。
使用パターンに基づくメディア層の選択
Azure Filesには、パフォーマンスと価格のバランスを取るために使用できる 2 つのストレージ メディア層 (SSD と HDD) が用意されています。 ストレージ アカウント レベルでファイル共有のメディア層を選択します。 特定のメディア層でストレージ アカウントを作成した後は、 新しいファイル共有に手動で移行しないと、他のメディア層に移動することはできません。
SSD ファイル共有と HDD ファイル共有のいずれかを選択する場合は、Azure Filesで実行する予定の使用パターンの要件を考慮してください。 大量の IOPS、高速なデータ転送速度、または低待機時間が必要な場合は、SSD ファイル共有を選択します。
次の表は、SSD と HDD ファイル共有の間で予想されるパフォーマンス目標をまとめたものです。 詳細については、「Azure Files のスケーラビリティおよびパフォーマンスのターゲット」を参照してください。
| 使用パターンの要件 | SSD | HDD |
|---|---|---|
| 書き込み待機時間 (1 桁のミリ秒) | はい | はい |
| 読み取り待機時間 (1 桁のミリ秒) | はい | いいえ |
SSD ファイル共有では、共有サイズに基づいて次のパフォーマンス プロファイルを保証するプロビジョニング モデルが使用されます。 詳細については、「プロビジョニングされた v1 モデル」に関する記事をご覧ください。
パフォーマンスのベスト プラクティス
新規または既存のワークロードのパフォーマンス要件を評価する場合でも、使用パターンを理解することで、予測可能なパフォーマンスを実現できます。
待機時間の秘密度: 読み取り待機時間に敏感で、エンド ユーザーの可視性が高いワークロードは、SSD ファイル共有に適しており、読み取り操作と書き込み操作の両方に 1 ミリ秒の待機時間を提供できます (小さな I/O サイズでは 2 ミリ秒未満)。
IOPS とスループットの要件: SSD ファイル共有では、HDD ファイル共有よりも大きな IOPS とスループットの制限がサポートされます。 詳細については、「 ファイル共有のスケール ターゲット」を参照してください。
ワークロードの期間と頻度: 実行時間が長く、頻繁に発生するワークロードと比較して、短い (分) および頻度の低い (時間単位) ワークロードが HDD ファイル共有のパフォーマンス上限に達する可能性は低くなります。 SSD ファイル共有では、ワークロードの期間は、プロビジョニングされたストレージ、IOPS、スループットに基づいて、使用する適切なパフォーマンス プロファイルを決定するのに役立ちます。 一般的な間違いは、数分間だけパフォーマンス テストを実行することであり、誤解を招くことがよくあります。 パフォーマンスを現実的に把握するためには、十分な頻度と持続時間でテストを行うことが重要です。 プロビジョニング済みファイル共有では、ショートテストでプロビジョニングされたIOPSの代わりにクレジットベースのバーストIOPSを測定できます。 詳細は 「Bursting」をご覧ください。
ワークロードの並列化: 同じクライアント上の複数のスレッド、プロセス、またはアプリケーション インスタンスなど、並列で操作を実行するワークロードの場合、SSD ファイル共有は、HDD ファイル共有 (SMB マルチチャネル) よりも明確な利点を提供します。 詳細については、「SMB Azure ファイル共有のパフォーマンスの向上」を参照してください。
API 操作の分散: メタデータの負荷の高いワークロード (多数のファイルに対して読み取り操作を実行するワークロードなど) は、SSD ファイル共有に適しています。 詳細については、「 メタデータまたは名前空間の負荷の高いワークロード」を参照してください。
ゾーン配置: ゾーン配置 を使用して、ストレージ アカウントが存在する特定の可用性ゾーンを選択します。 この機能を使用すると、VM をストレージと同じ可用性ゾーンに配置できるため、待機時間を最大 30% 短縮できます。 現在、この機能は、 サポートされているリージョンでローカル冗長ストレージ (LRS) を使用している SSD ストレージ アカウントでのみ使用できます。
バースト
プロビジョニング済みv2またはプロビジョニングv1の請求モデルを使用するファイル共有は、クレジットベースのIOPSバースティングをサポートします。 クレジットベースのバースティングは、ファイル共有が一定期間、ファイル共有に対してプロビジョニングされているIOPSよりも多くのIOPSを使用できるようにします。 クレジットベースのバースティングはファイル共有の特徴です。 バースティトラフィックとは、IOPSやスループットが短時間で急上昇するワークロードパターンのことです。 クレジットベースのバースティングは、バーストトラフィックによる短いIOPSのスパイクを吸収できます。
クレジットベースのバースティングは、プロビジョニングされたファイルシェアのコストに含まれており、請求書に料金が加算されることはありません。 クレジットベースのバースティングはIOPSにのみ適用されます。 プロビジョニングされたスループットを上回るスループットは増やしません。
従量課金のファイル共有にはバースティングは適用されません。 バースト可能なクラシック ファイル共有は、引き続きストレージ アカウントの IOPS 制限の対象となります。 詳細については、 クラシックファイル共有データプレーン制限を参照してください。 バースティングがコストに与える影響については、「Azure Files請求の理解」をご覧ください。
プロビジョニング済み v2 のバースト
クレジットベースの IOPS バーストを利用すると、IOPS の使用に関する柔軟性が向上します。 予期しない IO スパイクに対するバッファーとして、この柔軟性を使用します。 確立された IO パターンの場合は、IO ピークをプロビジョニングします。
バースト IOPS クレジットは、ファイル共有のトラフィックがプロビジョニング (ベースライン) IOPS より小さいたびに蓄積されます。 ファイル共有に使用される IOPS がプロビジョニング済み IOPS を超えているときに、バースト IOPS クレジットがある場合は、そのファイル共有は許容されるバースト IOPS の上限までバーストできます。 クレジットが残っている限り、発生したバースト クレジットの数に基づいて、ファイル共有は引き続きバーストを行うことができます。 プロビジョニング済み IOPS を超える IO が発生するたびに、1 クレジットが消費されます。 すべてのクレジットが消費されると、シェアはプロビジョニング済みのIOPSに戻ります。 バーストを使用するために、ファイル共有に対する IOPS について特別な操作を行う必要はありません。 バーストはベスト エフォート ベースで動作します。
共有のクレジットには次の 3 つの状態があります。
- 発生：ファイル共有がプロビジョニングされた IOPS を満たしていない場合に発生します。
- ファイル共有がプロビジョニングされたIOPSを超え、バーストモードで使用されている場合は、利用速度が低下します。
- ファイル共有がプロビジョニングされた IOPS を正確に使用していて、クレジットが発生しないか、使用されていない場合は定数。
新しいファイル共有は、そのバースト バケットにすべてのクレジットが含まれる状態で開始されます。 共有の IOPS がプロビジョニング済み制限を下回る理由がサーバーによるスロットリングの場合は、バースト クレジットは蓄積しません。 バースト IOPS の上限と、1 つのファイル共有が持てるクレジットの数の特定には、次の数式が使用されます。
| Item | SSD の式 | HDD の式 |
|---|---|---|
| バースト IOPS 上限 | MIN(MAX(3 * ProvisionedIOPS, 10000), 102400) |
MIN(MAX(3 * ProvisionedIOPS, 5000), 50000) |
| バースト IOPS クレジット | (BurstLimit - ProvisionedIOPS) * 3600 |
(BurstLimit - ProvisionedIOPS) * 3600 |
次の表は、さまざまなプロビジョニング済み IOPS の量に対するこれらの数式の例をまとめたものです。
| プロビジョニングされた IOPS | SSD のバースト IOPS 上限 | SSD のバースト クレジット | HDD のバースト IOPS 上限 | HDD のバースト クレジット |
|---|---|---|---|---|
| 500 | -- | -- | 最大 5,000 | 16,200,000 |
| 1,000 | -- | -- | 最大 5,000 | 14,400,000 |
| 3,000 | 10,000まで | 25,200,000 | 最大 9,000 | 21,600,000 |
| 5,000 | 最大 15,000 | 36,000,000 | 最大 15,000 | 36,000,000 |
| 10,000 | 最大 30,000 | 72,000,000 | 最大 30,000 | 72,000,000 |
| 25,000 | 最大 75,000 | 180,000,000 | 最大 50,000 | 90,000,000 |
| 50,000 | 最大 102,400 | 188,640,000 | 最大 50,000 | 0 |
| 75,000 | 最大 102,400 | 98,640,000 | -- | -- |
| 102,400 | 最大 102,400 | 0 | -- | -- |
プロビジョニング済み v1 のバースト
プロビジョニングされたv1モデルは、追加費用なしで含まれるクレジットベースのバースティングと、使用量に基づく料金に対してプロビジョニング量を超えるIOPSやスループットを許可できる有料バースティングの2種類のバースティングをサポートしています。
プロビジョニング済み v1 のクレジット ベースのバースト
クレジットベースの IOPS バーストを利用すると、IOPS の使用に関する柔軟性が向上します。 予期しない IO スパイクに対するバッファーとして、この柔軟性を使用します。 確立された IO パターンの場合は、IO ピークをプロビジョニングします。
クラシック ファイル共有のトラフィックがプロビジョニング (ベースライン) IOPS より小さい場合は常にバースト IOPS クレジットが蓄積されます。 クラシック ファイル共有の IOPS 使用率がプロビジョニングされた IOPS を超え、バースト IOPS クレジットが使用可能な場合、クラシック ファイル共有は、許可されるバースト IOPS の上限までバーストできます。 クラシック ファイル共有は、クレジットが残っている限り、発生したバースト クレジットの数に基づいてバーストを続けることができます。 プロビジョニング済み IOPS を超える IO が発生するたびに、1 クレジットが消費されます。 すべてのクレジットが消費されると、クラシックファイルシェアはプロビジョニング済みのIOPSに戻ります。 クラシック ファイル共有に対する IOPS は、バーストを使用するために特別な操作を行う必要はありません。 バーストはベスト エフォート ベースで動作します。
共有のクレジットには次の 3 つの状態があります。
- クラシック ファイル共有がプロビジョニングされた IOPS 未満を使用している場合に発生します。
- クラシック ファイル共有がプロビジョニングされた IOPS を超え、バーストモードで使用されている場合の性能低下。
- クラシック ファイル共有がプロビジョニングされた IOPS を正確に使用していて、クレジットが発生しておらず、使用されてもいない場合は定数。
新しいクラシック ファイル共有は、バースト バケット内のクレジットの完全な数から始まります。 共有の IOPS がプロビジョニング済み制限を下回る理由がサーバーによるスロットリングの場合は、バースト クレジットは蓄積しません。 次の数式を使用して、バースト IOPS の制限と、クラシック ファイル共有で可能なクレジットの数を決定します。
| Item | 計算式 |
|---|---|
| バースト限度 | MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400) |
| バースト クレジット | (BurstLimit - BaselineIOPS) * 3600 |
次の表は、プロビジョニングされたサイズに対するこれらの数式の例をいくつか示しています。
| 容量 (GiB) | ベースライン IOPS | バースト IOPS | バースト クレジット | スループット (MiB/秒) |
|---|---|---|---|---|
| 100 | 3,100 | 10,000まで | 24,840,000 | 110 |
| 500 | 3,500 | 10,000まで | 23,400,000 | 150 |
| 1,024 | 4,024 | 10,000まで | 21,513,600 | 203 |
| 5,120 | 8,120 | 最大 15,360 | 26,064,000 | 613 |
| 10,240 | 13,240 | 最大 30,720 | 62,928,000 | 1,125 |
| 33,792 | 36,792 | 最大 102,400 | 227,548,800 | 3,480 |
| 5万1,200 | 54,200 | 最大 102,400 | 164,880,000 | 5,220 |
| 102,400 | 102,400 | 最大 102,400 | 0 | 10,340 |
プロビジョニング済み v1 の有料バースト
有料バーストは、調整されたくないお客様をサポートするように設計された、プロビジョニング済み v1 モデルの高度な機能です。 有料バーストでは、プロビジョニングされたストレージを超える任意の量の IOPS またはスループットに対して、使用量ベースの課金が追加されます。 この機能は、プロビジョンドストレージの一部として無料で提供されるクレジットベースのバースト機能とは明確に区別されます。 有料バーストを使用すると、従来のファイル共有をプロビジョニングする方法に強力な柔軟性が追加されますが、誤って使用した場合に予期しない課金が発生する可能性もあります。
クレジット ベースのバーストと同様に、有料バーストは、適切な量の IOPS とスループットをプロビジョニングするための代替ではありません。 むしろ、予期せぬ需要が発生した場合にスロットリングに対する保護を強化するものです。 一貫したレベルの IOPS またはスループットの使用量がある場合は、有料バーストに依存するのではなく、(ストレージ プロビジョニングを通じて) 需要をカバーするのに十分な IOPS とスループットをプロビジョニングする方が安価です。
有料バーストは既定では無効になっていますが、 プロビジョニングされた v1 クラシック ファイル共有のコストとパフォーマンスの特性を変更 する手順に従って有効にすることができます (PowerShell と CLI のみ)。 有料バーストを有効にする場合は、Azure Monitorで使用可能な次のメトリックを使用して、IOPS とスループットの使用状況を監視します。
- ファイル共有のプロビジョニングされた IOPS
- ファイル共有のプロビジョニング済み帯域幅 MiB/秒 (スループット)
- Max IOPS によるトランザクション
- MiB/秒（スループット）での最大帯域幅
- IOPS のバースト クレジット (クレジットベースのバースト)
- 有料バースト IOS (IO)
- 有料バースト帯域幅
Latency
レイテンシについて考えるときは、まず Azure Files がレイテンシをどのように決定するかを理解してください。 最も一般的な測定値は、エンドツーエンドの待機時間とサービス待機時間のメトリックに関連する待機時間です。 これらの トランザクション メトリック を使用すると、アプリケーション トラフィックがクライアントとの間で送信中に費やした時間を示すことで、クライアント側の待機時間とネットワークの問題を特定するのに役立ちます。
エンドツーエンドの待機時間 (SuccessE2ELatency) は、トランザクションがクライアントからネットワークを経由して Azure Files サービスに到達し、クライアントに戻る完全なラウンド トリップを実行するのにかかる合計時間です。
サービス待機時間 (SuccessServerLatency) は、トランザクションがAzure Files内でのみラウンドトリップするまでにかかる時間です。 この測定値には、クライアントまたはネットワークの待機時間は含まれません。
SuccessE2ELatency 値と SuccessServerLatency 値の差は、ネットワークやクライアントによって発生する可能性のある待機時間を示します。
クライアント待機時間とサービス待機時間 (この場合は Azure Files のパフォーマンス) を混同してしまうことがよくあります。 たとえば、サービス待機時間で待機時間が短いと報告され、エンドツーエンド待機時間では要求に対する待機時間が非常に長い場合、時間はすべてクライアントとの間の転送に費やされており、Azure Files サービス内ではありません。
さらに、図が示すように、サービスから離れるほど待機時間のエクスペリエンスが遅くなり、クラウド サービスでパフォーマンス スケールの制限を達成するのが難しくなります。 この条件は、オンプレミスからAzure Filesにアクセスする場合に特に当てはまります。 Azure ExpressRouteなどのオプションはオンプレミスに最適ですが、同じAzure リージョンでのみ実行されているアプリケーション (コンピューティング + ストレージ) のパフォーマンスとはまだ一致しません。
ヒント
Azure の VM を使用してオンプレミスと Azure の間のパフォーマンスをテストすることは、Azure への接続のネットワーク機能をベースライン化するための効果的で実用的な方法です。 ExpressRoute 回線または VPN ゲートウェイの使用率が低い、または誤ってルーティングされると、Azure Files で実行されているワークロードが大幅に遅くなる可能性があります。
キューの深さ
キューの深さは、ストレージ リソースがサービスを提供できる未処理の 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 | 32 |
ヒント
パフォーマンスの上限を達成するには、ワークロードまたはベンチマーク テストが複数のファイルでマルチスレッドされていることを確認します。
シングルスレッドアプリケーションとマルチスレッドアプリケーション
Azure Filesは、マルチスレッド アプリケーションに最適です。 マルチスレッドがワークロードに与えるパフォーマンスへの影響を理解する最も簡単な方法は、シナリオを I/O で確認することです。 次の例では、10,000 個の小さなファイルを、Azureファイル共有との間でできるだけ早くコピーする必要があるワークロードがあります。
この表では、4 KiB ブロック サイズで書き込まれるシングルスレッドのアプリケーションに基づいて、Azure ファイル共有に 1 つの 16 KiB ファイルを作成するためにかかる時間 (ミリ秒) を細かく分けて示しています。
| I/O 操作 | 作成 | 4 KiB 書き込み | 4 KiB 書き込み | 4 KiB 書き込み | 4 KiB 書き込み | [閉じる] | 合計 |
|---|---|---|---|---|---|---|---|
| スレッド 1 | 3 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 2 ミリ秒 | 3 ミリ秒 | 14 ミリ秒 |
この例では、6 つの操作から 1 つの 16 KiB ファイルを作成するのに約 14 ミリ秒かかります。 シングル スレッド アプリケーションが 10,000 個のファイルを Azure ファイル共有に移動する場合、各ファイルは一度に 1 つずつ移動されるため、その操作は 140,000 ミリ秒 (14 ミリ秒× 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 ミリ秒 |