Azure Monitor でのコストの最適化
-
[アーティクル]
-
-
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法のことです。 さまざまな構成オプションと、収集するデータの量を減らす機会を理解することで、Azure Monitor のコストを大幅に削減できます。 この記事を使用する前に、「Azure Monitor のコストと使用量」を参照して、Azure Monitor が請求するさまざまな方法と、毎月の請求書を表示する方法を理解しておく必要があります。
この記事では、Azure Well-Architected Framework の一環としての Azure Monitor のコスト最適化について説明します。 Azure Well-Architected Framework は、ワークロードの品質向上に使用できる一連の基本原則です。 このフレームワークは、優れたアーキテクチャの 5 つの柱で構成されています。
- [信頼性]
- セキュリティ
- コストの最適化
- オペレーショナル エクセレンス
- パフォーマンス効率
Azure Monitor ログ
設計チェック リスト
- オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。
- 各 Log Analytics ワークスペースで通常収集されるデータ量の価格レベルを構成します。
- データ保持とアーカイブを構成します。
- デバッグ、トラブルシューティング、および監査に使用するテーブルを基本ログとして構成します。
- ワークスペースのデータ ソースからのデータ収集を制限します。
- 収集されたデータを定期的に分析して、傾向や異常を特定します。
- 収集したデータの量が多い場合のアラートを作成します。
- 特定の予算を超えないようにするための予防措置として、日次上限を検討します。
- Log Analytics ワークスペースの Azure Advisor のコストに関する推奨事項に対するアラートを設定します。
構成に関する推奨事項
| 推奨 |
特長 |
| オペレーショナル データとセキュリティ データを同じ Log Analytics ワークスペースに結合するかどうかを決定します。 |
Sentinel が有効になっている場合、Log Analytics ワークスペース内のすべてのデータは Microsoft Sentinel の価格の対象となるため、このデータを組み合わせるとコストがかかる可能性があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース戦略を設計する」を参照してください。 |
| 各 Log Analytics ワークスペースで通常収集されるデータ量の価格レベルを構成します。 |
既定では、Log Analytics ワークスペースには最低データ量なしの従量課金制の価格が使用されています。 十分なデータを収集する場合は、コミットメントレベルを使用してコストを大幅に削減できます。これにより、より低い料金と引き換えに収集された 1 日の最小データに専念できます。 1 つのリージョン内のワークスペース間で十分なデータを収集する場合は、専用クラスターにリンクし、クラスターの価格を使用して収集されたボリュームを組み合わせることができます。
コミットメント レベルの詳細と、お客様の使用レベルに最も適したものを決定するためのガイダンスについては、「Azure Monitor ログのコストの計算とオプション」を参照してください。 異なる価格レベルでの使用量に応じた推定コストを表示するには、「使用量と推定コスト」を参照してください。 |
| データ保持とアーカイブを構成します。 |
既定の 31 日 (ワークスペースで Sentinel が有効になっている場合は 90 日、Application Insights データの場合は 90 日) を超えて Log Analytics ワークスペースにデータを保持すると、料金がかかります。 ログ クエリでデータをすぐに使用できるようにするための特定の要件を検討してください。 アーカイブされたログを構成することで、最大 7 年間データを保持しながら、検索ジョブやデータセットのワークスペースへの復元を使用して時折アクセスすることができ、コストを大幅に削減することができます。 |
| デバッグ、トラブルシューティング、および監査に使用するテーブルを基本ログとして構成します。 |
基本ログ用に構成された Log Analytics ワークスペース内のテーブルは、制限された機能とログ クエリの料金と引き換えにインジェスト コストが低くなります。 これらのテーブルに対してクエリを実行する頻度が低い場合、このクエリ コストはインジェスト コストの削減によって相殺することができます。 |
| ワークスペースのデータ ソースからのデータ収集を制限します。 |
Azure Monitor のコストの主な要因は、Log Analytics ワークスペースで収集するデータ量であるため、サービスやアプリケーションの正常性とパフォーマンスを評価するために必要なデータ量を超過しないように収集する必要があります。 環境に合わせてこの決定を行い、他の柱の基準とバランスを取る方法の詳細については、「Log Analytics ワークスペース アーキテクチャを設計する」を参照してください。
トレードオフ: コストと監視の要件の間にトレードオフがある場合があります。 たとえば、高サンプル レートの方がパフォーマンスの問題を素早く検出できる可能性がありますが、コスト削減のために低サンプル レートが必要になる場合もあります。 ほとんどの環境では、収集の種類が異なる複数のデータ ソースがあるため、特定の要件とそれぞれのコスト目標のバランスを取る必要があります。 異なるデータ ソースの収集の構成に関する推奨事項については、「Azure Monitor でのコストの最適化」を参照してください。 |
| 収集されたデータを定期的に分析して、傾向や異常を特定します。 |
Log Analytics ワークスペースの分析情報を使用して、ワークスペースで収集されたデータの量を定期的に確認します。 さまざまなソースから収集されたデータの量を理解するのに役立つだけでなく、余分なコストにつながる可能性のあるデータ収集の異常や上昇傾向を特定します。 加えて、「Log Analytics ワークスペースでの使用量を分析する」の方法を使用してデータ収集を分析し、使用量をさらに減らすことができる追加の構成があるかどうかを判断します。 これは、一連の新しい仮想マシンや新しいサービスをオンボードするなど、新しく一連のデータ ソースを追加する場合に特に重要です。 |
| 収集したデータの量が多い場合のアラートを作成します。 |
予期しない請求を避けるため、過剰な使用量が発生した場合は、事前に通知される必要があります。 通知により、請求期間が終了する前に、潜在的な異変に対処できます。 |
| 特定の予算を超えないようにするための予防措置として、日次上限を検討します。 |
日次上限を使用すると、構成した上限に達すると、その日の残りの時間、Log Analytics ワークスペース内のデータ収集が無効になります。 これは、日次上限を使用するタイミングに関する記事で説明されているとおり、コストを削減する方法として使用しないでください。
1 日の上限を設定する場合は、上限到達時にアラートを作成するだけでなく、特定の割合 (たとえば 90%) に達したときに通知するアラート ルールも作成してください。 これにより、上限がデータ収集を停止する前に、増加したデータの原因を調査して対処する機会が得まれます。 |
| Log Analytics ワークスペースの Azure Advisor のコストに関する推奨事項に対するアラートを設定します。 |
Log Analytics ワークスペースに関する Azure Advisor の推奨事項では、コストを最適化する機会があるときにアラートで事前に通知されます。 これらのコストに関する推奨事項に対する Azure Advisor アラートを作成します。- 選択したテーブルに対してコスト効率の高い Basic ログ プランを構成することを検討してください - 低コストの Basic ログ データ プランの対象となるテーブルに対して、1 か月あたり 1 GB を超えるインジェストを識別しました。 Basic ログ プランを適用すると、デバッグとトラブルシューティングで使う検索機能を、低コストで利用できます。
- 価格レベルの変更を検討してください - 割引を受けてコストを削減するために、現在の使用量に基づいて価格 (コミットメント) レベルを変更することについてお調べください。
- 未使用の復元されたテーブルの削除を検討してください - 復元されたデータがあるアクティブなテーブルがワークスペースに 1 つ以上あります。 復元されたデータを使用しなくなった場合は、不要な料金が発生しないようにテーブルを削除します。
- データ インジェストの異常が検出されました - 過去 3 週間のインジェストに基づき、過去 1 週間のインジェスト率がきわめて高いことを識別しました。 この変更と予想されるコストの変化を書き留めておきます。
Log Analytics ワークスペースのリソース メニューから [概要]>[推奨事項] または [Advisor の推奨事項] を選択して、自動的に生成された推奨事項を表示することもできます。 |
管理
設計チェック リスト
- Azure リソースから重要なリソース ログ データのみを収集します。
構成に関する推奨事項
| 推奨 |
特長 |
| Azure リソースから重要なリソース ログ データのみを収集します。 |
Azure リソースのリソース ログを Log Analytics データベースに送信する診断設定を作成するときに、必要なカテゴリのみを指定します。 診断設定ではリソース ログの詳細なフィルター処理が許可されていないため、ワークスペース変換を使用して、サポートされているテーブルを使用するリソースの不要なデータをフィルター処理できます。 診断設定を構成し、変換を使用してデータをフィルター処理する方法の詳細については、「Azure Monitor の診断設定」を参照してください。 |
警告
設計チェック リスト
- アクティビティ ログ アラート、サービス正常性アラート、リソース正常性アラートは無料です。
- ログ検索アラートを使用する場合は、ログ検索アラートの頻度を最小限に抑えます。
- メトリック アラートを使用する場合は、監視するリソースの数を最小限に抑えます。
構成に関する推奨事項
| 推奨 |
特長 |
| アクティビティ ログ アラート、サービス正常性アラート、リソース正常性アラートは無料です。 |
Azure Monitor アクティビティ アラート、サービス正常性アラート、リソース正常性アラートは無料です。 監視対象をこれらのアラートの種類で実現できる場合は、それらを使用します。 |
| ログ検索アラートを使用する場合は、ログ検索アラートの頻度を最小限に抑えます。 |
ログ検索アラートを構成するときは、ルールの評価の頻度が高いほどコストが高くなることに注意してください。 それに応じてルールを構成します。 |
| メトリック アラートを使用する場合は、監視するリソースの数を最小限に抑えます。 |
一部のリソースの種類では、同じ種類の複数のリソースを監視できるメトリック アラート ルールがサポートされています。 これらのリソースの種類については、ルールによって多くのリソースが監視される場合、ルールのコストが高くなる場合があることに注意してください。 コストを削減するには、メトリック アラート ルールのスコープを減らすか、ログ検索アラート ルールを使用します。これは、多数のリソースを監視した場合にコストが低くなります。 |
仮想マシン
設計チェック リスト
- 詳細なデータ フィルター処理のため、Log Analytics エージェントから Azure Monitor エージェントに移行します。
- エージェントから不要なデータをフィルター処理します。
- VM の分析情報を使用するかどうか、および収集するデータを決定します。
- パフォーマンス カウンターのポーリング頻度を減らします。
- VM が重複するデータを送信していないことを確認します。
- Log Analytics ワークスペースの分析情報を使用して、請求対象のコストを分析し、コスト削減の機会を特定します。
- SCOM 環境を Azure Monitor SCOM マネージド インスタンス に移行します。
構成に関する推奨事項
| 推奨 |
Description |
| 詳細なデータ フィルター処理のため、Log Analytics エージェントから Azure Monitor エージェントに移行します。 |
Log Analytics エージェントを備えた VM がまだある場合は、それらを Azure Monitor エージェントに移行すると、より優れたデータ フィルタリングを活用し、さまざまな VM セットで独自の構成を使用できるようになります。 Log Analytics エージェントによるデータ収集の構成はワークスペースで行われるため、すべてのエージェントが同じ構成を受け取ります。 Azure Monitor エージェントで使用されるデータ収集ルールは、さまざまな VM セットの特定の監視要件に合わせて調整できます。 Azure Monitor エージェントでは、 変換 を使用して収集されるデータをフィルター処理することもできます。 |
| エージェントから不要なデータをフィルター処理します。 |
アラートや分析に使用しないデータをフィルター処理して、データ インジェスト コストを削減します。 さまざまな監視シナリオで収集するデータに関するガイダンスについては、「 Azure Monitor を使用した仮想マシンの監視: データの収集」および「コストを削減するためのデータのフィルター処理に関する具体的なガイダンスのコストの制御」を参照してください。 |
| VM の分析情報を使用して収集するデータを決定します。 |
VM 分析情報は、VM の監視をすばやく開始するための優れた機能であり、 マップやパフォーマンスの傾向ビューなどの強力な機能を提供します。 マップ機能またはマップ機能が収集するデータを使用しない場合は、データ インジェスト コストを節約するために、VM インサイト構成でプロセスと依存関係データの収集を無効にする必要があります。 |
| パフォーマンス カウンターのポーリング頻度を減らします。 |
データ収集ルールを使用してパフォーマンス データを Log Analytics ワークスペースに送信する場合、ポーリングの頻度を減らして収集されるデータの量を減らすことができます。 |
| VM が重複するデータを送信していないことを確認します。 |
マルチホーム エージェントの場合、または同様のデータ収集ルールを作成する場合には、各ワークスペースに一意のデータを送信していることを確認してください。 重複したデータを収集しないように収集したデータを分析する方法については、「Log Analytics ワークスペースでの使用量を分析する」を参照してください。 エージェント間で移行する場合、それぞれが固有のデータを収集していることを確認できない限り、両方を併用するのではなく、Azure Monitor エージェントに移行するまで、Log Analytics エージェントを引き続き使用します。 |
| Log Analytics ワークスペースの分析情報を使用して、請求対象のコストを分析し、コスト削減の機会を特定します。 |
Log Analytics ワークスペースの分析情報には、各テーブルと各 VM から収集された請求対象データが表示されます。 データをフィルター処理してコストを削減する最適な機会を表しているため、この情報を使用して、上位のマシンとテーブルを特定します。 Log Analytics ワークスペースでの使用状況の分析に関するページで、この分析情報とログ クエリを使用して、構成変更の影響をさらに分析します。 |
| SCOM 環境を Azure Monitor SCOM マネージド インスタンス に移行します。 |
既存の SCOM 環境を Azure Monitor SCOM マネージド インスタンス に移行して、Azure Monitor で置き換えることができない管理パックをサポートします。 SCOM マネージド インスタンスでは、ローカル管理サーバーとデータベース サーバーを維持する必要がなくなり、SCOM インフラストラクチャを維持するための全体的なコストが削減されます。 |
Containers
設計チェック リスト
- Prometheus メトリックの Container Insights コレクションを有効にしない。
- Container Insights でデータ収集を変更するようにエージェント収集を構成する。
- Container Insights によるメトリック データの収集の設定を変更する。
- Azure portal で Container Insights エクスペリエンスを使用しない場合は、メトリック データの Container Insights 収集を無効にする。
- コンテナー ログ テーブルに対して定期的にクエリを実行しない場合、またはアラートに使用しない場合は、基本ログとして構成する。
- 必要のないリソース ログの収集を制限する。
- AKS リソース ログにはリソース固有のログを使用し、テーブルを基本ログとして構成する。
- OpenCost を使用して、Kubernetes のコストに関する詳細を収集する。
構成に関する推奨事項
| 推奨 |
特長 |
| Prometheus でメトリックのスクレイピングを有効にしている場合は、Log Analytics ワークスペースで Prometheus メトリックの Container Insights 収集を有効にしない。 |
Prometheus 用 Azure Monitor マネージド サービスを使用してクラスターから Prometheus メトリックをスクレイピングするだけでなく、Log Analytics ワークスペースで Prometheus メトリックを収集するように Container Insights を構成できます。 これはマネージド Prometheus のデータと重複しており、追加コストが発生します。 |
| Container Insights でデータ収集を変更するようにエージェントを構成する。 |
「コスト削減のためにインジェスト制御をする」で説明されているように、コンテナーの分析情報によって収集されたデータを分析し、不要なデータの収集を停止するように構成を調整します。 |
| Container Insights によるメトリック データの収集の設定を変更する。 |
メトリック データが収集される頻度と Container Insights によって収集される名前空間の両方を変更する方法の詳細については、「コスト最適化設定を有効にする」を参照してください。 |
| Azure portal で Container Insights エクスペリエンスを使用しない場合は、メトリック データの Container Insights 収集を無効にする。 |
Container Insights では、マネージド Prometheus と同じメトリック値の多くが収集されます。 これらのメトリックの収集を無効にするには、「Container insights でコスト最適化設定を有効にする」の説明に従って、ログとイベントのみを収集するようにコンテナー分析情報を構成します。 この構成により、Azure portal でのコンテナー分析情報のエクスペリエンスは無効になりますが、Grafana を使用して Prometheus メトリックを視覚化し、Log Analytics を使用してコンテナー分析情報によって収集されたログ データを分析できます。 |
| コンテナー ログ テーブルに対して定期的にクエリを実行しない場合、またはアラートに使用しない場合は、基本ログとして構成する。 |
Container Insights スキーマを ContainerLogV2 に変換します。これは基本ログと互換性があり、「コスト削減のためにインジェスト制御をする」で説明されているように、大幅なコスト削減を実現できます。 |
| 必要のないリソース ログの収集を制限する。 |
AKS クラスターのコントロール プレーンのログは、Azure Monitor のリソース ログとして実装されています。 このデータを Log Analytics ワークスペースに送信するには、診断設定を作成します。 収集する必要があるカテゴリに関する推奨事項については、「AKS クラスターのコントロール プレーン ログを収集する」を参照してください。 |
| AKS リソース ログにはリソース固有のログを使用し、テーブルを基本ログとして構成する。 |
AKS では、リソース ログに対して Azure 診断モードまたはリソース固有モードがサポートされています。 リソース ログを指定し、基本ログのテーブルを構成するオプションを有効にします。これにより、場合によってはクエリを実行するだけでアラートに使用しないログのインジェスト料金が削減されます。 |
| OpenCost を使用して、Kubernetes のコストに関する詳細を収集する。 |
OpenCost は、Kubernetes のコストを理解し、AKS のコストを可視化する機能をサポートするための、ベンダーに依存しないオープンソースの CNCF サンドボックス プロジェクトです。 顧客固有の Azure 価格に加えて、詳細なコスト計算データを Azure Storage にエクスポートして、クラスター管理者がコストを分析および分類するのを支援します。 |
Application Insights
設計チェック リスト
- ワークスペースベースの Application Insights に変更します。
- サンプリングを使用して、収集されるデータの量を調整します。
- Ajax 呼び出しの数を制限します。
- 不要なモジュールを無効化します。
- TrackMetric への呼び出しのメトリックを事前に集計します。
- 可能であればカスタム メトリックの使用を制限します。
- 更新されたソフトウェア開発キット (SDK) を確実に使用します。
- ログ レベルを使用して、不要なホスト トレースと一般的なトレース ログを制限します。
構成に関する推奨事項
| 推奨 |
特長 |
| ワークスペースベースの Application Insights に変更します。 |
Application Insights リソースがワークスペース ベースであることを確認します。 ワークスペース ベースの Application Insights リソースでは、基本ログ、コミットメント レベル、データの種類別のリテンション期間とデータ アーカイブなどの新しいコスト削減ツールを適用できます。 |
| サンプリングを使用して、収集されるデータの量を調整します。 |
サンプリングは、Application Insights によって収集されるデータの量を調整するために使用できる主要なツールです。 サンプリングを使用すると、メトリックのひずみを最小限に抑えて、アプリケーションから送信されるテレメトリの量を減らすことができます。 |
| Ajax 呼び出しの数を制限します。 |
各ページ ビューに報告できる Ajax 呼び出しの数を制限したり、Ajax での報告を無効にしたりします。 Ajax 呼び出しを無効にすると、JavaScript の関連付けも無効になります。 |
| 不要なモジュールを無効化します。 |
ApplicationInsights.config を編集し、不要なコレクション モジュールを無効にします。 たとえば、パフォーマンス カウンターや依存関係のデータが必要ではないと判断した場合などに検討します。 |
| TrackMetric への呼び出しのメトリックを事前に集計します。 |
TrackMetric への呼び出しをアプリケーションに配置した場合、測定のバッチの平均と標準偏差の計算を受け取るオーバーロードを使用して、トラフィックを減らすことができます。 または、事前集計パッケージを使用することもできます。 |
| カスタム メトリックの使用を制限します。 |
Application Insights オプションの [カスタム メトリック ディメンションに関するアラートを有効にします] を使用すると、コストが増加する可能性があります。 このオプションを使用すると、作成される事前集計メトリックが増える可能性があります。 |
| 更新されたソフトウェア開発キット (SDK) を確実に使用します。 |
ASP.NET Core SDK と Worker Service SDK の以前のバージョンでは、多数のカウンターが既定で収集され、カスタム メトリックとして収集されます。 必要なカウンターのみを指定するために、新しいバージョンを使用します。 |
| 不要なトレース ログを制限します。 |
Application Insights には、考えられるログ ソースがいくつかあります。 ログ レベルを使用して、トレース ログ テレメトリを調整および削減できます。 ログ記録はホストにも適用できます。 たとえば、Azure Kubernetes Service (AKS) を使用しているお客様は、コントロール プレーン ログとデータ プレーン ログを調整する必要があります。 同様に、Azure Functions を使用しているお客様は、ログの量とコストを最適化するために、ログのレベルとスコープを調整する必要があります。 |
次のステップ