ファイル共有のパフォーマンスを監視する方法を理解することは、アプリケーションができる限り効率的に実行されていることを確認するために重要です。 この記事では、可用性、待機時間、使用率などの Azure Files メトリックを、Azure Monitor を使用して分析する方法について説明します。
Azure Files 用に収集可能な監視データとその使用方法の詳細については、「Azure Files の監視」を参照してください。
適用対象
管理モデル | 課金モデル | メディア階層 | 冗長性 | 中小企業 | ネットワークファイルシステム(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) |
![]() |
![]() |
サポートされるメトリック
Azure Files のメトリックは、こちらの名前空間にあります。
- Microsoft.Storage/storageAccounts
- Microsoft.Storage/storageAccounts/fileServices
Azure Files で使用可能なメトリックの一覧については、「Azure Files 監視データのリファレンス」をご覧ください。
すべての Azure Monitor サポート メトリック (Azure Files を含む) の一覧については、「Azure Monitor のサポートされるメトリック」をご覧ください。
Azure Files のメトリック データを表示する
Azure Portal、PowerShell、Azure CLI、または .NET を使用して、Azure Files メトリックを表示できます。
Azure Monitor メトリックス エクスプローラーを使用して、他の Azure サービスのメトリックと共に Azure Storage のメトリックを分析できます。 メトリックス エクスプローラーを開くには、[Azure Monitor] メニューの [メトリック] を選択します。 このツールの使用方法の詳細については、「Azure Monitor メトリックス エクスプローラーでメトリックスを分析する」を参照してください。
ディメンションをサポートするメトリックについては、目的のディメンション値でメトリックをフィルター処理できます。 Azure Storage でサポートされるディメンションの完全な一覧については、「メトリックのディメンション」をご覧ください。
ワークロードのパフォーマンスを監視する
Azure Monitor を使用して、Azure Files を利用するワークロードを分析できます。 以下の手順に従ってください。
- Azure Portal のストレージ アカウントに移動します。
- サービス メニューの [監視] の下の [メトリック] を選択します。
- [メトリック名前空間] で [ファイル] を選択します。
監視対象に応じてメトリックを選択できるようになりました。
可用性を監視する
Azure Monitor では、可用性メトリックは、アプリケーションまたはユーザーの観点から明らかに問題がある場合や、アラートのトラブルシューティングを行うときに役立ちます。
Azure Files でこのメトリックを使用する場合は、常に集計を [最大] または [最小] ではなく [平均] として表示することが重要です。 [平均] を使用すると、エラーが発生している要求の割合と、それらが Azure Files の SLA 内にあるかどうかを示します。
待機時間を監視する
最も重要な 2 つの待機時間メトリックは、[成功した場合の E2E 待機時間] と [成功した場合のサーバー待機時間] です。 これらは、パフォーマンス調査を開始するときに選択するのに理想的なメトリックです。 Average が推奨される集計です。 前述のように、Max と Min は誤解を招く可能性があります。
次のグラフでは、青い線は合計待機時間 (成功した場合の E2E 待機時間) に費やされた時間を示し、ピンクの線は Azure Files サービスでのみ費やされた時間 (成功した場合のサーバー待機時間) を示しています。
このグラフは、マウントされた Azure ファイル共有を持つオンプレミス クライアントを示しています。これは、たとえば、リモートの場所から接続する一般的なユーザーを表しています。 クライアントと Azure リージョン間の物理的な距離は、対応するクライアント側の待機時間と密接に関連付けられます。これは、E2E とサーバーの待機時間の違いを表します。
これに対し、次のグラフは、クライアントと Azure ファイル共有の両方が同じリージョン内にある状況を示しています。 クライアント側の待機時間は、最初のグラフの 43.9 ミリ秒と比較してわずか 0.17 ミリ秒であることに注意してください。 これは、最適なパフォーマンスを実現するためには、クライアント側の待機時間を最小限に抑えることが不可欠である理由を表しています。
それを表すもう 1 つの待機時間インジケーターは、成功した場合のサーバー待機時間の頻度の増加または異常な急増が問題であることを示唆している可能性があります。 これは一般的に、プロビジョニングされたファイル共有の目標制限 (または従量課金制ファイル共有の全体的なスケール制限) を超えた場合のリソース使用の制御(スロットリング)が原因です。 Azure Files の課金と、Azure Files のスケーラビリティとパフォーマンスのターゲットについて説明します。
詳細については、「待機時間が長い、スループットが低い、または IOPS が低い」のトラブルシューティングのページを参照してください。
使用率を監視する
送信されるデータの量 (スループット) または処理される操作 (IOPS) を測定する使用率メトリックは、一般的に、アプリケーションまたはワークロードによって実行されている作業量を判断するために使用されます。 トランザクション メトリックにより、Azure Files サービスに対する操作または要求の数をさまざまな時間の粒度で確認できます。
エグレスまたはイングレス メトリックを使用して受信または送信データの量を調べる場合は、Sum 集計を使用して、ファイル共有との間で送受信されるデータの合計量を 1 分から 1 日の時間粒度で確認します。 Average、Max、Min などの他の集計では、個々の I/O サイズの値のみが表示されます。 このため、ほとんどのお客様は通常、 Max 集計を使用するときに 1 MiB が表示されます。 それは最大、最小、または平均の I/O サイズについてサイズを理解するには便利ですが、ワークロードの使用パターン別に生成された I/O サイズの分布を表示することはできません。
次のグラフに示すように、応答の種類 (成功、失敗、エラー) または API 操作 (読み取り、書き込み、作成、閉じる) に対して [分割を適用する] を選択して、追加の詳細を表示することもできます。
ワークロードの 1 秒あたりの平均 I/O (IOPS) を確認するには、最初に 1 分間のトランザクションの合計数を調べ、その数を 60 秒で割ります。 たとえば、1 分間に 120,000 トランザクション / 60 秒 = 平均 2,000 IOPS です。
ワークロードの平均スループットを判断するには、イングレスとエグレスのメトリックを合わせて (合計スループット) 送信されたデータの合計量を取得し、60 秒で割ります。 たとえば、1 分間で 1 GiB の合計スループット / 60 秒 = 平均スループット 17 MiB です。
最大 IOPS と帯域幅で使用率を監視する (プロビジョニングのみ)
プロビジョニングされたファイル共有では、 最大 IOPS 別のトランザクション と 最大 MiB/秒ごとの帯域幅 メトリックが提供され、ワークロードがピーク時に達成している内容が表示されます。 これらのメトリックを使用してワークロードを分析すると、大規模な真の機能を理解し、Azure ファイル共有を最適にプロビジョニングできるように、スループットと IOPS の影響を理解するためのベースラインを確立できます。
次のグラフは、1 時間にわたって 263 万件のトランザクションを生成したワークロードを示しています。 263 万件のトランザクションを 3,600 秒で割ると、平均 730 IOPS が得られます。
平均 IOPS と最大 IOPS でのトランザクションを比較すると、ピーク時の負荷で 1,840 IOPS を達成していたことがわかります。これは、ワークロードの能力をより適切に、十分に表しています。
[メトリックの追加] を選択して、イングレスとエグレスのメトリック を 1 つのグラフに結合します。 これは、1 時間に 76.2 GiB (78,028 MiB) が転送されたことを表示しています。これにより、その同じ時間の平均スループットは 21.67 MiB になります。
最大 MiB/秒での帯域幅と比較すると、ピーク時に 123 MiB/秒を達成していました。
メタデータ IOPS による使用率の監視
Azure ファイル共有では、最大 12,000 のメタデータ IOPS にスケールアップします。 つまり、大量のオープン、クローズ、または削除操作でメタデータ負荷の高いワークロードを実行すると、メタデータ IOPS 調整の可能性が高くなります。 この制限は、ファイル共有のプロビジョニングされた全体的な IOPS とは無関係です。
メタデータが多い 2 つのワークロードが同じ使用パターンに従っていないので、お客様がワークロードを事前に監視し、正確なアラートを設定するのは困難な場合があります。
これに対処するために、Azure ファイル共有に対して 2 つのメタデータ固有のメトリックを導入しました。
メタデータ警告付きの成功: メタデータ IOPS が制限に近づいており、高いまま維持されたり増加し続けたりした場合、調整される可能性があることを示します。 これらの警告のボリュームまたは頻度が増加すると、メタデータ調整のリスクが高まってくることを示唆しています。
メタデータ調整の成功: メタデータ IOPS がファイル共有の容量を超えたため、スロットルが発生したことを示します。 IOPS 操作は失敗しませんが、最終的には再試行後に成功しますが、調整中に待機時間が影響を受けます。
Azure Monitor で表示するには、トランザクション メトリックを選択し、応答 の 種類に 分割を適用 します。 メタデータ応答の種類は、選択した期間内にアクティビティが発生した場合にのみドロップダウンに表示されます。
次のグラフは、メタデータ IOPS(トランザクション)が急増し、メタデータ警告付きの成功を引き起こしたワークロードを示しています。これは、メタデータがスロットリングされるリスクを示しています。 この例では、結果としてワークロードのトランザクションボリュームが減少し、メタデータのスロットリングを防ぐことができました。
ワークロードでメタデータ警告付き成功またはメタデータ調整付き成功の応答タイプに遭遇した場合は、次の推奨事項の 1 つ以上を実施することを検討してください。
- SSD SMB ファイル共有の場合は、 メタデータ キャッシュを有効にします。
- ワークロードを複数のファイル共有に分散 (シャード) します。
- メタデータ IOPS の量を減らします。