<p><!--META { "title": "Azure Monitor コスト最適化戦略と実践", "primary_category": "Azure", "secondary_categories": ["Monitoring", "Cost Management"], "tags": ["Azure Monitor", "Cost Optimization", "Log Analytics", "KQL", "Azure CLI", "PowerShell", "Entra ID"], "summary": "Azure Monitorのコスト最適化はデータ収集の最適化、リテンションポリシー調整、適切なSKU選定が重要。", "mermaid": true } --> Azure Monitorのコスト最適化はデータ収集の最適化、リテンションポリシー調整、適切なSKU選定が重要である。</p> <h1 class="wp-block-heading">Azure Monitor コスト最適化戦略と実践</h1> <h2 class="wp-block-heading">アーキテクチャ</h2> <p>Azure Monitorのコスト最適化は、ログとメトリックの収集・保持戦略に依存する。主要コンポーネントはLog Analytics Workspace (LAW) であり、これがすべてのログデータの一元的な集約ポイントとなる。各Azureリソースから診断設定を通じてLAWにデータが送信され、Azure MonitorのMetrics、Logs、Alerts、Workbooksといった機能群がこれを活用する。</p> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD subgraph Azure Resources VM["Virtual Machine"] AppGW["Application Gateway"] DB["Azure SQL Database"] AKS["Azure Kubernetes Service"] end subgraph Azure Monitor Ecosystem LAW["Log Analytics Workspace"] Metrics["Metrics Explorer"] Logs["Logs (KQL)"] Alerts["Alerts & Action Groups"] Workbooks["Workbooks & Dashboards"] CostMgt["Azure Cost Management"] end VM -- Diagnostic Settings --> LAW AppGW -- Diagnostic Settings --> LAW DB -- Diagnostic Settings --> LAW AKS -- Diagnostic Settings --> LAW LAW -- Data Stream --> Metrics LAW -- Data Stream --> Logs Logs -- Query & Analyze --> Alerts Logs -- Visualization --> Workbooks Metrics -- Alerting Logic --> Alerts Alerts -- Notifications --> DevOps["DevOps Team"] Workbooks -- Reporting --> Management[Management] LAW -- Cost Analysis --> CostMgt </pre></div> <p>このアーキテクチャでは、データがLAWに集約される段階でのフィルタリングと、LAWでの保持期間管理がコストに直接影響する。Azure Cost Managementは、これらの利用状況を可視化し、最適化の機会を提供する。</p> <h2 class="wp-block-heading">設定手順</h2> <p>Azure Monitorのコスト最適化に向けたLog Analytics Workspaceと診断設定の構成は、Azure CLIまたはPowerShellを用いて実施できる。</p> <ol class="wp-block-list"> <li><p><strong>Log Analytics Workspace (LAW) の作成</strong> LAWのSKUはPerGB2018（従量課金）が初期選択肢となるが、データ量に応じてCommitment Tierを検討する。リテンション期間は初期段階で短く設定する。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># リソースグループの作成（もし存在しない場合） az group create --name "rg-monitor-prod" --location "centralus" # Log Analytics Workspaceの作成 # SKUはPerGB2018 (旧称 Per GB) を指定し、必要に応じてCommitment Tierへ変更を検討する。 # 初期リテンション期間を30日に設定。 az monitor log-analytics workspace create \ --resource-group "rg-monitor-prod" \ --workspace-name "law-prod-centralus-001" \ --location "centralus" \ --sku "PerGB2018" \ --retention-time 30 # 日数で指定 # 作成されたLAWのIDを取得 LAW_ID=$(az monitor log-analytics workspace show \ --resource-group "rg-monitor-prod" \ --workspace-name "law-prod-centralus-001" \ --query "id" -o tsv) echo "Log Analytics Workspace ID: $LAW_ID" </pre> </div></li> <li><p><strong>Azureリソースの診断設定の構成</strong> 不要なログカテゴリの送信を停止し、必要なデータのみをLAWへ転送することでコストを削減する。Azure Monitor Agent (AMA) を利用する場合は、データ収集ルール (DCR) でより詳細なフィルタリングが可能となる。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 仮想マシンのリソースIDを取得（例） # VM_ID="/subscriptions/{subscriptionId}/resourceGroups/{vmResourceGroup}/providers/Microsoft.Compute/virtualMachines/{vmName}" # 実際の環境に合わせて変更 VM_ID="/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-compute-prod/providers/Microsoft.Compute/virtualMachines/vm-prod-web-001" # 仮想マシンの診断設定を構成 # コスト最適化のため、必要なログカテゴリのみを選択。 # 例: Linux VMのSyslogとHeartbeatのみを収集。metricsは全てのメトリックを収集。 az monitor diagnostic-settings create \ --name "vm-diag-settings-cost-optimized" \ --resource "$VM_ID" \ --workspace "$LAW_ID" \ --logs "[{category: 'Syslog', enabled: true, retentionPolicy: {enabled: false, days: 0}}, {category: 'Heartbeat', enabled: true, retentionPolicy: {enabled: false, days: 0}}]" \ --metrics "[{category: 'AllMetrics', enabled: true, retentionPolicy: {enabled: false, days: 0}}]" </pre> </div></li> <li><p><strong>データ収集ルール (DCR) の適用（Azure Monitor Agent利用時）</strong> AMAを使用する場合、DCRにより、特定のパフォーマンスカウンターやイベントログIDのみを収集するなど、より粒度の高いフィルタリングと変換が可能になる。これにより、LAWへの取り込みデータ量を大幅に削減できる。DCRはJSONファイルで定義し、<code>az monitor data-collection rule create</code> コマンドで作成する。 例として、特定のWindowsイベントログのみを収集するDCRの概念を示す。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># DCR定義ファイル (dcr-windows-error.json) の内容例 # { # "properties": { # "dataSources": { # "windowsEventLogs": [ # { # "streams": ["Microsoft-InsightsMetrics", "Microsoft-WindowsEvent"], # "logName": "Application", # "eventLevels": ["Error", "Warning"], # "name": "app-error-warning-events" # }, # { # "streams": ["Microsoft-InsightsMetrics", "Microsoft-WindowsEvent"], # "logName": "System", # "eventLevels": ["Error"], # "name": "system-error-events" # } # ] # }, # "destinations": { # "logAnalytics": [ # { # "workspaceResourceId": "$LAW_ID", # "name": "mylaw" # } # ] # } # }, # "location": "centralus" # } # DCRの作成 (dcr-windows-error.json を別途用意) # az monitor data-collection rule create \ # --resource-group "rg-monitor-prod" \ # --name "dcr-windows-error-only" \ # --rule-file "dcr-windows-error.json" # DCRを仮想マシンに関連付け # az monitor data-collection rule association create \ # --resource "$VM_ID" \ # --rule-id "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-monitor-prod/providers/Microsoft.Insights/dataCollectionRules/dcr-windows-error-only" \ # --name "vm-dcr-association" </pre> </div></li> </ol> <h2 class="wp-block-heading">運用監視</h2> <p>運用監視においては、可観測性の維持とコスト最適化の両立が重要となる。 * <strong>可観測性</strong>: Azure Monitor Workbooks、Azure Dashboards、KQL (Kusto Query Language) クエリを駆使し、システムの健全性、パフォーマンス、セキュリティイベントを継続的に監視する。KQLは大量のログデータを効率的に分析するための基盤となる。 * <strong>ログ</strong>: Log Analytics Workspaceに集約されたログは、KQLクエリによりリアルタイムで分析可能である。データ保持期間は、コンプライアンス要件とコストのバランスを考慮し、定期的に見直す。 * <strong>SLA/バックアップ/DR</strong>: Azure Monitorサービス自体はMicrosoftによって高可用性で運用されている。Log Analytics Workspaceのデータはリージョン内で冗長化されるが、リージョン間のDRは提供されない。ミッションクリティカルなシステムの場合、複数のリージョンにLAWを展開し、監視対象のDRに追従する形で監視構成を切り替える運用を検討する。LAW内のデータバックアップ機能は提供されていないため、長期的な監査要件やフォレンジック分析のために必要なログは、アーカイブ機能やAzure Storageへのエクスポートを活用する。 * <strong>コスト最適化</strong>: * <strong>データ収集の最適化</strong>: 診断設定やDCRを用いて、本当に必要なログカテゴリやログイベントのみを収集する。例として、開発環境では詳細ログを収集し、本番環境ではエラーと警告ログに限定するなどのポリシーを適用する。 * <strong>リテンションポリシーの調整</strong>: Log Analytics Workspaceのデータ保持期間を、法規制や監査要件に基づき必要最小限に設定する。一般的に30〜90日とし、それ以上の期間が必要なデータは後述のアーカイブ機能を利用する。 * <strong>SKUの適切な選択</strong>: データ取り込み量に応じて、PerGB2018 SKUからCommitment Tier (例: 100 GB/日、200 GB/日) へ切り替える。Commitment Tierは月ごとの変更が可能であり、Azure Cost Managementで利用傾向を分析し、最適なTierを選択することでコストを最適化する。 * <strong>アーカイブ機能の活用</strong>: 長期保存が必要なログデータ（最大7年）は、Log Analyticsのアーカイブ機能を利用するか、ストレージアカウントへのエクスポートにより、より安価なストレージに保存する。これにより、LAWのインタラクティブなクエリ保持期間を短縮しつつ、データの保持要件を満たす。</p> <h2 class="wp-block-heading">セキュリティ</h2> <p>Azure Monitorにおけるセキュリティは、データの機密性、完全性、可用性を保護するために不可欠である。 * <strong>アイデンティティと権限境界</strong>: * <strong>Entra ID (Azure Active Directory)</strong>: 監視担当者や自動化アカウントに対して、Azure Entra ID上で認証・認可を行う。グループを作成し、一元的に管理することが推奨される。 * <strong>Azure ロールベースのアクセス制御 (RBAC)</strong>: Log Analytics Workspaceや監視リソースへのアクセスを最小権限の原則に基づいて制御する。 * <code>Log Analytics Contributor</code>: LAWの構成変更やデータ書き込み権限。 * <code>Log Analytics Reader</code>: LAW内のデータをクエリする権限。 * <code>Monitoring Contributor</code>: Azure Monitorのリソース（アラート、アクションルールなど）を作成・変更する権限。 * <code>Monitoring Reader</code>: 監視設定を閲覧する権限。 * 必要に応じて、カスタムロールを作成し、より厳密な権限セットを定義する。 * <strong>条件付きアクセス (Conditional Access)</strong>: Azure PortalやAzure Resource Manager APIへのアクセスに対し、多要素認証 (MFA) の強制、特定のデバイスからのアクセスのみ許可、場所によるアクセス制限などのポリシーを適用し、セキュリティを強化する。 * <strong>Azure Defender for Cloud</strong>: Azure Monitorと統合することで、セキュリティイベントの監視と脅威検出を強化する。Defender for CloudからのセキュリティアラートはLog Analytics Workspaceに転送され、KQLを用いて他の運用ログと組み合わせて分析することが可能である。LAWに保存されるデータは、既定でMicrosoft管理キーによる暗号化が実施されるが、コンプライアンス要件に応じてカスタマー管理キー (CMK) による暗号化も選択可能である。</p> <h2 class="wp-block-heading">コスト</h2> <p>Azure Monitorのコストは主にLog Analytics Workspaceのデータ取り込み量とデータ保持期間によって決定される。メトリックは基本的には無料だが、カスタムメトリックには費用が発生する場合がある。 * <strong>データ取り込み量の最適化</strong>: * <strong>診断設定の選択的適用</strong>: 各Azureリソースの診断設定で、不要なログカテゴリ（例: デバッグログ、冗長な監査ログ）を無効化する。 * <strong>データ収集ルール (DCR) の適用</strong>: Azure Monitor Agent (AMA) を使用する場合、DCRで特定のパフォーマンスカウンター、イベントログID、ファイルログパターンのみを収集するように設定し、不要なデータをフィルタリングする。これにより、取り込み量を大幅に削減できる。 * <strong>ログフィルタリング</strong>: KQL変換機能や取り込み時変換を利用して、ログデータがLAWに到着する前にフィルタリング・整形し、保存量を削減する。 * <strong>データ保持期間の最適化</strong>: * <strong>短期保持期間の設定</strong>: Log Analytics Workspaceのデフォルトのデータ保持期間を、法規制や運用上の要件を満たす最小日数（例: 30日、90日）に設定する。 * <strong>アーカイブ層の活用</strong>: 長期的なコンプライアンス要件やセキュリティ監査に備えるため、利用頻度の低いログはLog Analyticsのアーカイブ機能（最大7年）や、より安価なAzure Storageアカウント（Blob Storage）にエクスポートして保存する。 * <strong>Log Analytics Workspace SKUの適切な選択</strong>: * <strong>PerGB2018 (従量課金)</strong>: 取り込み量が少ない場合に適している。 * <strong>Commitment Tier</strong>: 取り込み量が一定量（例: 100 GB/日、200 GB/日）を超える場合、PerGB2018よりも単価が安くなるため、このTierへ移行することでコストメリットが得られる。Tierは月ごとに変更可能であるため、利用状況をモニタリングし、柔軟に調整する。 * <strong>Basic Logs</strong>: 特定のログタイプ（例: 頻繁にクエリされないが長期保存が必要な監査ログなど）に対して、取り込みコストは低いがクエリコストが高いBasic Logsの利用を検討する。これは、アクセスパターンによってコスト効率が変動するため、慎重な検討が必要。 * <strong>Dedicated Clusters</strong>: 大規模なデータ取り込みを扱う場合、Dedicated Clustersはクエリパフォーマンスを向上させるとともに、Commitment Tierと組み合わせて大規模な割引を適用できる可能性がある。</p> <h2 class="wp-block-heading">落とし穴</h2> <p>Azure Monitorのコスト最適化にはいくつかの注意点がある。 * <strong>過剰なログ収集</strong>: デフォルト設定や「すべてのログ」オプションを安易に選択すると、不要なデバッグログや冗長な情報ログが大量に取り込まれ、予測不能な高額なコストが発生する。 * <strong>不適切なリテンション期間</strong>: 監査やコンプライアンス要件がないにもかかわらず、長期間のデータ保持を設定すると、ストレージコストが不必要に増大する。 * <strong>SKUのミスマッチ</strong>: データ量がCommitment Tierの閾値を超えているのにPerGB2018 SKUを使用している、またはデータ量が少ないのにCommitment Tierを選択している場合、最適なコスト効率が得られない。定期的な見直しが不可欠である。 * <strong>エージェントの重複</strong>: 複数の監視エージェント（例: OMSエージェントとAzure Monitor Agent (AMA)）が同じデータを収集し、二重課金になるケースがある。AMAへの移行計画を推進し、重複を排除する。 * <strong>メトリックの誤解</strong>: メトリックはログと比較してコストが低いが、カスタムメトリックを過剰に作成するとコストが増加する可能性がある。 * <strong>クエリコストの見落とし</strong>: Basic Logs SKUを選択した場合、データ取り込みコストは低いものの、データクエリコストが高くなる。頻繁なクエリが必要なログには適さない。</p> <h2 class="wp-block-heading">まとめ</h2> <p>Azure Monitorのコスト最適化は、単なる費用の削減に留まらず、監視システム全体の効率と運用品質向上に直結する。ログ収集の粒度を厳密に制御し、データ保持期間をビジネス要件とコンプライアンスに適合させる。Log Analytics WorkspaceのSKUは、実際のデータ取り込み量に基づき、PerGB2018とCommitment Tier間で最適な選択を定期的に見直す。Azure Cost Managementを継続的に活用し、コスト傾向を分析し、最適化の機会を特定することが不可欠である。これらの戦略を実践することで、監視コストを最小限に抑えつつ、システムの安定稼働とセキュリティを確実に維持することが可能となる。</p>

graph TD
    subgraph Azure Resources
        VM["Virtual Machine"]
        AppGW["Application Gateway"]
        DB["Azure SQL Database"]
        AKS["Azure Kubernetes Service"]
    end

    subgraph Azure Monitor Ecosystem
        LAW["Log Analytics Workspace"]
        Metrics["Metrics Explorer"]
        Logs["Logs (KQL)"]
        Alerts["Alerts & Action Groups"]
        Workbooks["Workbooks & Dashboards"]
        CostMgt["Azure Cost Management"]
    end

    VM -- Diagnostic Settings --> LAW
    AppGW -- Diagnostic Settings --> LAW
    DB -- Diagnostic Settings --> LAW
    AKS -- Diagnostic Settings --> LAW

    LAW -- Data Stream --> Metrics
    LAW -- Data Stream --> Logs
    Logs -- Query & Analyze --> Alerts
    Logs -- Visualization --> Workbooks
    Metrics -- Alerting Logic --> Alerts

    Alerts -- Notifications --> DevOps["DevOps Team"]
    Workbooks -- Reporting --> Management[Management]
    LAW -- Cost Analysis --> CostMgt