✔️ 適用対象: 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、スループットに基づいて、使用する適切なパフォーマンス プロファイルを決定するのに役立ちます。 一般的な間違いは、数分間だけパフォーマンス テストを実行することであり、誤解を招くことがよくあります。 パフォーマンスを現実的に把握するためには、十分な頻度と持続時間でテストを行うことが重要です。
ワークロードの並列化: 同じクライアント上の複数のスレッド、プロセス、またはアプリケーション インスタンスなど、並列で操作を実行するワークロードの場合、SSD ファイル共有は、HDD ファイル共有 (SMB マルチチャネル) よりも明確な利点を提供します。 詳細については、「SMB Azure ファイル共有のパフォーマンスの向上」を参照してください。
API 操作の分散: メタデータの負荷の高いワークロード (多数のファイルに対して読み取り操作を実行するワークロードなど) は、SSD ファイル共有に適しています。 詳細については、「 メタデータまたは名前空間の負荷の高いワークロード」を参照してください。
ゾーン配置: ゾーン配置 を使用して、ストレージ アカウントが存在する特定の可用性ゾーンを選択します。 この機能を使用すると、VM をストレージと同じ可用性ゾーンに配置できるため、待機時間を最大 30% 短縮できます。 現在、この機能は、 サポートされているリージョンでローカル冗長ストレージ (LRS) を使用している SSD ストレージ アカウントでのみ使用できます。
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 ミリ秒 |