Azure ファイル共有のパフォーマンスを理解して最適化する

Azure Files は、ほとんどのアプリケーションとユース ケースのパフォーマンス要件を満たすことができます。 この記事では、ファイル共有のパフォーマンスに影響を与える可能性があるさまざまな要因と、ワークロードに合わせて Azure ファイル共有のパフォーマンスを最適化する方法について説明します。

適用対象

管理モデル	課金モデル	メディア階層	冗長性	中小企業	ネットワークファイルシステム（NFS）
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ローカル (LRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ゾーン (ZRS)
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ジオ （GRS）
Microsoft.Storage	プロビジョニング済み v2	HDD (標準)	ジオゾーン (GZRS)
Microsoft.Storage	プロビジョニング済み v1	SSD (プレミアム)	ローカル (LRS)
Microsoft.Storage	プロビジョニング済み v1	SSD (プレミアム)	ゾーン (ZRS)
Microsoft.Storage	従量課金制	HDD (標準)	ローカル (LRS)
Microsoft.Storage	従量課金制	HDD (標準)	ゾーン (ZRS)
Microsoft.Storage	従量課金制	HDD (標準)	ジオ （GRS）
Microsoft.Storage	従量課金制	HDD (標準)	ジオゾーン (GZRS)

用語集

ストレージのパフォーマンスに関連する以下の重要な用語を押さえておくと、この記事を理解するのに役立ちます。

• 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/秒と計算できます。

• 待機時間

  待機時間は遅延のシノニムであり、ミリ秒単位で測定されます。 待機時間には、エンドツーエンドの待機時間とサービス待機時間の 2 種類があります。 詳しくは、「待機時間」をご覧ください。

• キューの深さ

  キューの深さは、ストレージ リソースが一度に処理できる保留中の I/O 要求の数です。 詳細については、「キューの深さ」を参照してください。

使用パターンに基づくメディア層の選択

Azure Files には、SSD と HDD という 2 つのストレージ メディア層があり、パフォーマンスと価格のバランスを取ります。 ファイル共有のメディア層はストレージ アカウント レベルで選択します。特定のメディア層でストレージ アカウントを作成した後は、 新しいファイル共有に手動で移行しないと、他のメディア層に移動することはできません。

SSD と HDD のファイル共有を選択するときは、Azure Files で実行する予定の使用パターンの要件を理解することが重要です。 大量の IOPS、高速なデータ転送速度、または低待機時間が必要な場合は、SSD ファイル共有を選択する必要があります。

次の表は、SSD と HDD ファイル共有の間で予想されるパフォーマンス目標をまとめたものです。 詳細については、「Azure Files のスケーラビリティおよびパフォーマンスのターゲット」を参照してください。

SSD ファイル共有は、共有サイズに基づいて次のパフォーマンス プロファイルを保証するプロビジョニング モデルを提供します。 詳細については、「プロビジョニングされた v1 モデル」に関する記事をご覧ください。

パフォーマンス チェックリスト

新規または既存のワークロードのパフォーマンス要件を評価する場合でも、使用パターンを理解することで、予測可能なパフォーマンスを実現できます。

• 待機時間の秘密度: 読み取り待機時間に敏感で、エンド ユーザーの可視性が高いワークロードは、SSD ファイル共有に適しており、読み取り操作と書き込み操作の両方に 1 ミリ秒の待機時間を提供できます (小さな I/O サイズでは 2 ミリ秒< )。

• IOPS とスループットの要件: SSD ファイル共有では、HDD ファイル共有よりも大きな IOPS とスループットの制限がサポートされます。 詳細については、ファイル共有のスケール ターゲットに関するセクションを参照してください。

• ワークロードの期間と頻度: 実行時間の長い頻繁に発生するワークロードと比較して、短い (分) ワークロードと頻度の低い (時間単位) ワークロードでは、HDD ファイル共有のパフォーマンス上限を達成する可能性が低くなります。 SSD ファイル共有では、ワークロードの期間は、プロビジョニングされたストレージ、IOPS、スループットに基づいて、使用する適切なパフォーマンス プロファイルを決定するときに役立ちます。 よく見られる失敗は、数分間だけパフォーマンス テストを実行して満足することです。これによって、多くの場合、判断を誤ります。 パフォーマンスについて現実的な見方ができるようにするには、十分に高い頻度と長い期間でテストしてください。

• ワークロードの並列化: 同じクライアント上の複数のスレッド、プロセス、またはアプリケーション インスタンスなど、並列で操作を実行するワークロードの場合、SSD ファイル共有は、HDD ファイル共有 (SMB マルチチャネル) よりも明確な利点を提供します。 詳細については、「SMB Azure ファイル共有のパフォーマンスを向上させる」を参照してください。

• API 操作の分散: 多数のファイルに対して読み取り操作を実行しているワークロードなど、メタデータの負荷の高いワークロードは、SSD ファイル共有に適しています。 「メタデータまたは名前空間の過大なワークロード」をご覧ください。

待機時間

待機時間について考慮するときは、まず、Azure Files で待機時間がどのように決定されるかを理解することが重要です。 最も一般的な測定値は、エンドツーエンドの待機時間とサービス待機時間のメトリックに関連する待機時間です。 これらのトランザクション メトリックを使用すると、アプリケーション トラフィックがクライアントとの間で転送に費やす時間を特定することで、クライアント側の待機時間やネットワークの問題を識別できます。

• エンドツーエンドの待機時間 (SuccessE2ELatency) は、トランザクションがクライアントからネットワークを経由して Azure Files サービスに到達し、クライアントに戻る完全なラウンド トリップを実行するのにかかる合計時間です。

• サービス待機時間 (SuccessServerLatency) は、トランザクションが Azure Files 内でのみラウンドトリップするまでにかかる時間です。 これには、クライアントまたはネットワークの待機時間は含まれません。

  

SuccessE2ELatency 値と SuccessServerLatency 値の差は、ネットワークやクライアントによって発生する可能性のある待機時間を示します。

クライアント待機時間とサービス待機時間 (この場合は Azure Files のパフォーマンス) を混同してしまうことがよくあります。 たとえば、サービス待機時間が、短い待機時間を報告していて、エンド ツー エンドの待機時間が要求に対して非常に長い待機時間を報告している場合、すべての時間は Azure Files サービスではなく、クライアント間の転送に費やされていることを示しています。

さらに、図が示すように、サービスから離れるほど待機時間のエクスペリエンスが遅くなり、クラウド サービスでパフォーマンス スケールの制限を達成するのが難しくなります。 これは、オンプレミスから Azure Files にアクセスする場合に特に当てはまります。 ExpressRoute のようなオプションはオンプレミスに最適ですが、同じ Azure リージョンでのみ実行されているアプリケーション (コンピューティング + ストレージ) のパフォーマンスには適しません。

キューの深さ

キューの深さは、ストレージ リソースがサービスを提供できる未処理の I/O 要求の数です。 ストレージ システムで使用されるディスクが HDD スピンドル (IDE、SATA、SAS) からソリッド ステート デバイス (SSD、NVMe) に進化するにつれて、より深いキューの深さをサポートできるようになりました。 大規模なデータセット内の 1 つのファイルと順次対話する 1 つのクライアントで構成されるワークロードは、キューの深さが浅い例です。 これに対し、複数のスレッドと複数のファイルで並列処理をサポートするワークロードでは、より深いキューの深さを簡単に実現できます。 Azure Files は、数千の Azure クラスター ノードにまたがる分散ファイル サービスであり、大規模にワークロードを実行するように設計されているため、キューの深さが深いワークロードを構築して、テストすることをお勧めします。

キューの深さは、クライアント、ファイル、スレッドと組み合わせつつ、いくつかの異なる方法で実現できます。 ワークロードのキューの深さを判断するには、クライアントの数にファイルの数とスレッドの数を乗算します (クライアント * ファイル * スレッド = キューの深さ)。

次の表は、キューの深さを掘り下げるために使用できる、さまざまな組み合わせを示しています。 最適なキューの深さである 64 を超えることはできますが、推奨されません。 その深さを超えても、パフォーマンスの向上は見られず、かえって TCP の飽和状態により待機時間が長くなるリスクがあります。

シングルスレッドのアプリケーションとマルチスレッドのアプリケーション

Azure Files は、マルチスレッド アプリケーションに最適です。 マルチスレッドがワークロードに与えるパフォーマンスへの影響を理解する最も簡単な方法は、I/O ごとにシナリオを検証する方法です。 次の例には、Azure ファイル共有との間で、できるだけ早く 10,000 個の小さなファイルをコピーする必要のあるワークロードがあります。

この表では、4 KiB ブロック サイズで書き込まれるシングルスレッドのアプリケーションに基づいて、Azure ファイル共有に 1 つの 16 KiB ファイルを作成するためにかかる時間 (ミリ秒) を細かく分けて示しています。

この例では、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% 短い時間で移動できます。

関連項目

• Azure ファイル共有のパフォーマンスに関する問題のトラブルシューティング
• Azure Files の監視
• Azure Files のデプロイの計画
• Azure Files の課金の概要
• Azure Files の価格