本記事は GitHub Copilot を活用して作成しています。

Azure には管理グループ・サブスクリプション・リソース グループという既存の階層がありますが、現実のチームやワークロードはこの階層をまたいで存在することが多く、「複数サブスクリプションにまたがるリソースをまとめて見たい」という要求に応えにくい課題がありました。

Azure サービス グループ（Azure Service Groups）はその課題を解決する、現在パブリック プレビュー中の新機能です。本記事では、既存の管理境界との違いを整理しつつ、サービス グループ・正常性モデル（Health Models）・SLI（Service Level Indicators） の連携を解説します。

本記事の内容をまとめた Marp 形式のプレゼン資料はこちらです

既存の管理境界の限界

Azure の管理境界は RBAC・コスト管理・ガバナンス の観点で設計されています。

この構造は強力ですが、スコープをまたいだ柔軟なグループ化には対応していません。複数サブスクリプションにまたがる Web アプリを 1 つのビューで確認したい、本番・ステージング・開発のリソースをまとめて追跡したい、といったニーズに応えるのが サービス グループ です。

Azure サービス グループとは

サービス グループは、既存の管理階層を変更せずに、サブスクリプション・リソース グループ・リソースを横断して任意にグループ化できる テナント レベルの仮想フォルダー です。

• リソースは 複数 のサービス グループに同時に所属可能
• サービス グループへのアクセスはメンバー リソースへの権限を 付与しない（RBAC 継承なし）
• RBAC ロールは子サービス グループへのみ継承（メンバー リソースへは継承しない）
• 上限: テナントあたり最大 10,000 個、同一 Sub からのメンバーは 2,000 件

プレビュー中は 3 つの組み込みロール（サービス管理者/共同作成者/閲覧者）のみ対応。カスタム RBAC ロールは不可です。

graph TB
    MG["管理グループ\nポリシー・RBAC"]
    Sub1["サブスクリプション A"] --> RG1["RG-Network"] --> R1["VNet"]
    Sub1 --> RG2["RG-App-Prod"] --> R2["VM-Prod"]
    Sub2["サブスクリプション B"] --> RG3["RG-App-Dev"] --> R3["VM-Dev"]
    MG --> Sub1
    MG --> Sub2
    SG1["🗂 SG: Network Team"]
    SG2["🗂 SG: WebApp Project"]
    R1 -.->|member| SG1
    R2 -.->|member| SG2
    R3 -.->|member| SG2
    classDef sg fill:#ede7f6,stroke:#4527a0,color:#000
    class SG1,SG2 sg

管理境界の使い分けガイド

クロスシステム シナリオの例

「複数サブスクリプション＋複数チーム」での典型的な活用例です。

flowchart LR
    subgraph Sub_A["サブスクリプション A（インフラ）"]
        NET["VNet / Firewall"]
    end
    subgraph Sub_B["サブスクリプション B（Prod）"]
        APP_P["App Service / SQL（Prod）"]
    end
    subgraph Sub_C["サブスクリプション C（Dev）"]
        APP_D["App Service / SQL（Dev）"]
    end
    SG_NET["🗂 SG: Platform Network"]
    SG_WEB["🗂 SG: WebApp-All-Envs"]
    NET -.->|member| SG_NET
    APP_P -.->|member| SG_WEB
    APP_D -.->|member| SG_WEB
    SG_WEB --> SLI["📊 SLI（可用性・レイテンシ）"]
    classDef sg fill:#ede7f6,stroke:#4527a0,color:#000
    classDef sli fill:#e8f5e9,stroke:#2e7d32,color:#000
    class SG_NET,SG_WEB sg
    class SLI sli

既存の課金・ポリシー境界を崩さずに、チームの視点でリソースをまとめてビューを作れるのがサービス グループの特徴です。

正常性モデル（Health Models）

正常性モデルは、ワークロードを構成するコンポーネントの 依存関係 を定義し、各コンポーネントに正常性シグナル（SLI や Azure Monitor のメトリクス）を関連付ける仕組みです。

正常性の伝播（ロールアップ）: 子コンポーネントが異常になると、その状態が親コンポーネントやワークロード全体の正常性にロールアップされます。依存関係にある一部コンポーネントの障害が、ワークロード全体としてどのような影響を与えるかを可視化できます。

Microsoft Learn では、子エンティティの正常性状態が親エンティティへロールアップされる例が、次のように示されています。

例えば Event Hub の メトリックが悪化すると、ワークロード全体の正常性に伝達され、障害の影響範囲を即座に把握できます。

正常性モデルはサービスグループがなくても作成可能です。
しかし、サービスグループでワークロードを横断的にまとめておくことで、正常性モデルのエンティティとして一括管理ができます
あとからサービスグループに追加されたメンバーもエンティティとして追加されます

SLI （Service Level Indicators）

SLI（Service Level Indicator）は、サービスの信頼性やパフォーマンスを実測する指標です。

• 例：成功リクエスト率や一定時間内に応答したリクエスト率
  SLI は実測値、SLO はその目標値として定義されます。

従来メトリック監視との違い

混乱しやすいので整理します

従来のメトリックはいらないわけではないです。
SLI は従来メトリックを置き換えるものではなく、メトリックを材料としてユーザー視点の品質指標に集約するものです。

エラーバジェット

SLI の話をするとエラーバジェットなる概念に遭遇します。
エラーバジェットとは、SLO を守りながら許容できる失敗の余地、つまりチャレンジしていい余力のことです。

基本的には 「100％ − SLO」 で算出します

• SLOが99.9％ならエラーバジェットは0.1％
  エラーバジェットが十分に残っていれば、機能追加や変更などに一定のリスクを取れますが、エラーバジェットを使い果たすと、品質改善や障害対応に注力する必要があります。
• バーンレート: エラーバジェットを消費する速度
• 急激な消費は突発的な劣化、緩やかだが継続する消費は長期的な品質低下の兆候

Azure の SLI の現在の機能

SLI は、サービス グループを「ワークロードの境界」として、可用性（Availability） や レイテンシ（Latency） の信頼性指標を提供します。
Azure Monitor Workspace メトリックを正常性モデルのシグナルとして活用することで、システム全体が正しく動作しているかを一元判定できます。

イメージしやすいように簡単にスクショを貼っておきます

設定後は SLI の状態やエラーバジェットの消費状況を確認できます。

まとめ

サービス グループは既存の Azure 管理体系を壊さずに「ワークロードの横断的なビュー」を追加できる新たな選択肢です。
正常性モデルで依存関係を整理し、SLI で品質指標を定量化することで、ワークロード全体の信頼性をより明確に管理できます。

参考

• Azure サービス グループとは - Microsoft Learn
• Service level indicators in Azure Monitor - Microsoft Learn
• 管理グループとは - Microsoft Learn
• Microsoft Azure プレビューの補足利用規約