✔️ 適用対象: Microsoft.Storage リソース プロバイダーで作成されたクラシック SMB および NFS ファイル共有
✔️ 適用対象: Microsoft.FileShares リソース プロバイダーで作成されたファイル共有
ファイル共有のパフォーマンスを監視する方法を理解することは、アプリケーションができる限り効率的に実行されていることを確認するために重要です。 この記事では、可用性、待機時間、使用率などの Azure Files メトリックを、Azure Monitor を使用して分析する方法について説明します。
Azure Files に向けて収集できるデータの監視をその使用方法については、「Azure Files を監視する」を参照してください。
Azure Files でサポートされるメトリック
Azure Files のメトリックは、こちらの名前空間にあります。
- Microsoft.Storage/storageAccounts
- Microsoft.Storage/storageAccounts/fileServices
Azure Files で使用可能なメトリックの一覧については、「Azure Files 監視データのリファレンス」を参照してください。
(Azure Files を含む) すべての Azure Monitor がサポートするメトリックの一覧については、「Azure Monitor がサポートするメトリック」を参照してください。
Azure Files メトリック データを表示する
Azure portal、PowerShell、Azure CLI、または .NET を使用すると、Azure Files メトリックを表示できます。
Azure Monitor Metrics Explorer を使用して、他の Azure サービスのメトリックと共に Azure Storage のメトリックを分析できます。
[Azure Monitor] メニューの [メトリック] を選択し、Metrics Explorer を開きます。 このツールの使用法の詳細については、「Azure Monitor Metrics Explorer を使用してメトリックを分析する」を参照してください。
ディメンションをサポートするメトリックについては、目的のディメンション値でメトリックをフィルター処理できます。 Azure Storage でサポートされるディメンションの完全な一覧については、「メトリックのディメンション」をご覧ください。
メトリック定義の一覧表示
ストレージ アカウントまたは Azure Files サービスのメトリック定義を一覧表示できます。
Get-AzMetricDefinition コマンドレットを使用します。
この例では、<resource-ID> プレースホルダーをストレージ アカウント全体のリソース ID または Azure Files サービスのリソース ID に置き換えます。 これらのリソース ID は、Azure portal 上のストレージ アカウントの [プロパティ] ページで確認できます。
$resourceId = "<resource-ID>"
Get-AzMetricDefinition -ResourceId $resourceId
メトリック値を読み取る
ストレージ アカウントまたは Azure Files サービスのアカウント レベルのメトリック値を読み取ることができます。
Get-AzMetric コマンドレットを使用します。
$resourceId = "<resource-ID>"
Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00
ディメンションのあるメトリック値を読み取る
メトリックにディメンションが付いている場合、メトリック値を読み取り、ディメンション値をフィルターにしてメトリック値を絞り込むことができます。
Get-AzMetric コマンドレットを使用します。
$resourceId = "<resource-ID>"
Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00
$resourceId = "<resource-ID>"
$dimFilter = [String](New-AzMetricFilter -Dimension ApiName -Operator eq -Value "GetFile" 3> $null)
Get-AzMetric -ResourceId $resourceId -MetricName Transactions -TimeGrain 01:00:00 -MetricFilter $dimFilter -AggregationType "Total"
アカウント レベルのメトリック定義を一覧表示する
ストレージ アカウントまたは Azure Files サービスのメトリック定義を一覧表示できます。
az monitor metrics list-definitions コマンドを使用します。
この例では、<resource-ID> プレースホルダーをストレージ アカウント全体のリソース ID または Azure Files サービスのリソース ID に置き換えます。 これらのリソース ID は、Azure portal 上のストレージ アカウントの [プロパティ] ページで確認できます。
az monitor metrics list-definitions --resource <resource-ID>
アカウント レベルのメトリック値を読み取る
ストレージ アカウントまたは Azure Files サービスのメトリック値を読み取ることができます。
az monitor metrics list コマンドを使用します。
az monitor metrics list --resource <resource-ID> --metric "UsedCapacity" --interval PT1H
ディメンションのあるメトリック値を読み取る
メトリックにディメンションが付いている場合、メトリック値を読み取り、ディメンション値をフィルターにしてメトリック値を絞り込むことができます。
az monitor metrics list コマンドを使用します。
az monitor metrics list --resource <resource-ID> --metric "Transactions" --interval PT1H --filter "ApiName eq 'GetFile' " --aggregation "Total"
Azure Monitor には、メトリックの定義と値を読み取る Azure.Monitor.Query .NET SDK が用意されています。
でのパスワードレス認証には DefaultAzureCredential使用します。 詳細については、 Azure サービスのパスワードなしの接続に関するページを参照してください。
まず、必要な NuGet パッケージをインストールします。
dotnet add package Azure.Identity
dotnet add package Azure.Monitor.Query
これらの例では、 <resource-ID> プレースホルダーをストレージ アカウント全体のリソース ID または Azure Files サービスのリソース ID に置き換えます。 これらのリソース ID は、Azure portal 上のストレージ アカウントの [プロパティ] ページで確認できます。
アカウント レベルのメトリック定義を一覧表示する
次の例は、アカウント レベルでメトリック定義を一覧表示する方法を示しています。
using Azure;
using Azure.Identity;
using Azure.Monitor.Query;
using Azure.Monitor.Query.Models;
public static async Task ListStorageMetricDefinition()
{
var resourceId = "<resource-ID>";
var client = new MetricsQueryClient(new DefaultAzureCredential());
AsyncPageable<MetricDefinition> metricDefinitions = client.GetMetricDefinitionsAsync(resourceId, metricsNamespace);
await foreach (var metricDefinition in metricDefinitions)
{
Console.WriteLine(metricDefinition.Id);
Console.WriteLine(metricDefinition.ResourceId);
Console.WriteLine(metricDefinition.Name);
Console.WriteLine(metricDefinition.Unit);
}
}
アカウント レベルのメトリック値を読み取る
次の例は、アカウント レベルで UsedCapacity データを読み取る方法を示しています。
public static async Task ReadStorageMetricValue()
{
var resourceId = "<resource-ID>";
var client = new MetricsQueryClient(new DefaultAzureCredential());
Response<MetricsQueryResult> result = await client.QueryResourceAsync(
resourceId,
new[] { "UsedCapacity" },
new MetricsQueryOptions
{
Granularity = TimeSpan.FromHours(1),
Aggregations = { MetricAggregationType.Average },
TimeRange = new QueryTimeRange(TimeSpan.FromHours(3))
});
foreach (MetricResult metric in result.Value.Metrics)
{
Console.WriteLine(metric.Name);
Console.WriteLine(metric.Unit);
foreach(var item in metric.TimeSeries)
{
Console.WriteLine("Metadata:");
foreach(var metadata in item.Metadata)
{
Console.WriteLine($"{metadata.Key}: {metadata.Value}");
}
Console.WriteLine("Values:");
foreach(var value in item.Values)
{
Console.WriteLine($"TimeStamp: {value.TimeStamp}, Average: {value.Average}");
}
}
}
}
多次元メトリック値を読み取る
多次元メトリックの場合、特定のディメンション値に対するメトリック データを読み取る必要がある場合は、メタデータ フィルターを定義する必要があります。
次の例は、多次元値をサポートするメトリックのメトリック データを読み取る方法を示しています。
public static async Task ReadStorageMetricValueTest()
{
// Resource ID for Azure Files
var resourceId = "<resource-ID>";
var client = new MetricsQueryClient(new DefaultAzureCredential());
// Define a dimension filter to read metric data on specific dimension values
// More conditions can be added with the 'or' and 'and' operators, example: ApiName eq 'GetFile' or ApiName eq 'PutRange'
Response<MetricsQueryResult> result = await client.QueryResourceAsync(
resourceId,
new[] { "Transactions" },
new MetricsQueryOptions
{
Granularity = TimeSpan.FromHours(1),
Aggregations = { MetricAggregationType.Average },
TimeRange = new QueryTimeRange(TimeSpan.FromHours(3)),
Filter = "ApiName eq 'GetFile'"
});
foreach (MetricResult metric in result.Value.Metrics)
{
Console.WriteLine(metric.Name);
Console.WriteLine(metric.Unit);
foreach(var item in metric.TimeSeries)
{
Console.WriteLine("Metadata:");
foreach(var metadata in item.Metadata)
{
Console.WriteLine($"{metadata.Key}: {metadata.Value}");
}
Console.WriteLine("Values:");
foreach(var value in item.Values)
{
Console.WriteLine($"TimeStamp: {value.TimeStamp}, Average: {value.Average}");
}
}
}
Azure Monitorを使ってAzure Filesを使うワークロードを分析してください。 次の手順に従います。
-
Azure portal でストレージ アカウントに移動します。
- サービス メニューの [監視] で、[メトリック] を選択します。
-
[メトリック名前空間] で、[ファイル] を選択します。
監視対象に応じてメトリックを選択できるようになりました。
可用性を監視する
Azure Monitor では、Availability メトリックは、アプリケーションまたはユーザーの観点から明らかに問題がある場合や、アラートのトラブルシューティングを行うときに役立ちます。
Azure Files でこのメトリックを使用する場合は、常に集計を [最大] または [最小] ではなく [平均] として表示することが重要です。
[平均] を使用すると、エラーが発生している要求の割合と、それらが Azure Files の SLA 内にあるかどうかを示します。
待機時間を監視する
最も重要な 2 つの待機時間メトリックは、Success E2E Latency と Success Server Latency です。 これらは、パフォーマンス調査を開始するときに選択するのに理想的なメトリックです。
Average は、推奨される集計です。 可用性指標と同様に、最大および最小は遅延分析において誤解を招くことがあります。
次のグラフでは、青い線は合計待機時間 (Success E2E Latency) に費やされた時間を示し、ピンクの線は Azure Files サービスでのみ費やされた時間 (Success Server Latency) を示しています。
このグラフは、マウントされた Azure ファイル共有を持つオンプレミス クライアントを示しています。これは、たとえば、リモートの場所から接続する一般的なユーザーを表しています。 クライアントと Azure リージョン間の物理的な距離は、対応するクライアント側の待機時間と密接に関連付けられます。これは、E2E とサーバーの待機時間の違いを表します。
これに対し、次のグラフは、クライアントと Azure ファイル共有の両方が同じリージョン内にある状況を示しています。 クライアント側のレイテンシは最初のチャートの43.9msに対しわずか0.17msであり、クライアント側レイテンシを最小化することが最適なパフォーマンスを得るために不可欠であることを示しています。
問題を示唆する可能性のあるもう一つのレイテンシ指標は、 サクセスサーバーレイテンシの増加や異常なスパイクです。 これは一般的に、プロビジョニングされたファイル共有の目標制限 (または従量課金制ファイル共有の全体的なスケール制限) を超えた場合のリソース使用の制御(スロットリング)が原因です。
Azure Files の課金と、Azure Files のスケーラビリティとパフォーマンスのターゲットについて説明します。
詳細については、「待機時間が長い、スループットが低い、または IOPS が低い問題をトラブルシューティングする」を参照してください。
使用率を監視する
送信されるデータの量 (スループット) または処理される操作 (IOPS) を測定する Utilization メトリックは、一般的に、アプリケーションまたはワークロードによって実行されている作業量を判断するために使用されます。 Transaction メトリックにより、Azure Files サービスに対する操作または要求の数をさまざまな時間の粒度で確認できます。
Egress または Ingress メトリックを使用して受信データまたは送信データの量を調べる場合は、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。
ワークロードの平均スループットを判断するには、Ingress と Egress メトリックを合わせて (合計スループット) 送信されたデータの合計量を取得し、60 秒で除算します。 例: 1 分間の 1 GiB の合計スループット/60 秒 = 平均スループット 17 MiB。
最大 IOPS と帯域幅で使用率を監視する (プロビジョニングのみ)
平均IOPSやスループットはワークロードの活動の全体像を示しますが、バーストやピークを覆い隠すことがあります。 プロビジョニングされたファイル共有は、 最大IOPSごとのトランザクション 数や 最大MiB/s単位の帯域幅 の指標を提供し、ピーク負荷時にワークロードがどれだけ達成しているかを示し、実際のパフォーマンス要件をより正確に把握できます。 これらの指標を用いてワークロードを分析することで、スケールでの真の能力を理解し、スループットやIOPSの増加が与える影響を基準に設定し、Azureファイル共有を最適にプロビジョニングできます。
次のグラフは、1 時間に 263 万件のトランザクションを生成したワークロードを示しています。 263万件のトランザクションを3,600秒で割ると、平均IOPSは730 IOPSとなります。
平均IOPSと 最大IOPSによるトランザクション を比較すると、ピーク時のワークロードは1,840 IOPSに達しており、これはスケールでのワークロードの能力をよりよく表しています。
[メトリックを追加] を選択して、Ingress と Egress メトリック を 1 つのグラフに結合します。 これは、1 時間に 76.2 GiB (78,028 MiB) が転送されたことを表示しています。これにより、その同じ時間の平均スループットは 21.67 MiB になります。
最大MiB/sによる帯域幅と比較すると、ピーク時のワークロードは123 MiB/sに達しました。
Azure ファイル共有では、最大 12,000 のメタデータ IOPS にスケールアップします。 つまり、大量のオープン、クローズ、または削除操作でメタデータ負荷の高いワークロードを実行すると、メタデータ IOPS 調整の可能性が高くなります。 この制限は、ファイル共有のプロビジョニングされた全体的な IOPS とは無関係です。
メタデータが多い 2 つのワークロードが同じ使用パターンに従っていないので、お客様がワークロードを事前に監視し、正確なアラートを設定するのは困難な場合があります。
これに対応するため、Azure FilesはAzureファイル共有に対して2つのメタデータ固有の指標を提供しています。
メタデータ警告付きの成功: メタデータ IOPS が制限に近づいており、高いまま維持されたり増加し続けたりした場合、調整される可能性があることを示します。 これらの警告のボリュームまたは頻度が増加すると、メタデータ調整のリスクが高まってくることを示唆しています。
メタデータ調整の成功: メタデータ IOPS がファイル共有の容量を超えたため、スロットルが発生したことを示します。 IOPS 操作は失敗しませんが、最終的には再試行後に成功しますが、調整中に待機時間が影響を受けます。
Azure Monitor で表示するには、トランザクション メトリックを選択し、応答 の 種類に 分割を適用 します。 メタデータ応答の種類は、選択した期間内にアクティビティが発生した場合にのみドロップダウンに表示されます。
次のグラフは、メタデータ IOPS(トランザクション)が急増し、メタデータ警告付きの成功を引き起こしたワークロードを示しています。これは、メタデータがスロットリングされるリスクを示しています。 この例では、結果としてワークロードのトランザクションボリュームが減少し、メタデータのスロットリングを防ぐことができました。
ワークロードでメタデータ警告付き成功またはメタデータ調整付き成功の応答タイプに遭遇した場合は、次の推奨事項の 1 つ以上を実施することを検討してください。
- SSD SMB ファイル共有の場合は、 メタデータ キャッシュを有効にします。
- ワークロードを複数のファイル共有に分散 (シャード) します。
- メタデータ IOPS の量を減らします。
関連コンテンツ