Microsoft Azureリソース・グループ：導入とベスト・プラクティス

Azureリソース・グループは、すべてのAzure仮想マシン（VM）のグループ化を必要とするMicrosoft Azureのサービスです。この記事では、このグループ構造が実際に何を意味するのか、また、それを使用してガバナンスを向上させ、インフラストラクチャーのリソースをより適切に管理する方法についてご紹介します。

まず、リソースの管理レイヤーであり、おそらく読者の方も慣れ親しんでいるAzure Resource Managerでリソース・グループの管理とプロビジョニングを行う方法について簡単に説明します。Azure Resource Managerを使用すると、スクリプトではなく宣言型テンプレート、タグ付け管理、デプロイメント・テンプレート、依存関係マッピング、簡素化されたロールベースのアクセス制御、明確なコスト管理を通じてインフラストラクチャーを管理できます。

リソース・グループを編成して、ワークフローとアプリケーションに関連するコストの保護、管理、追跡に役立てることができます。

Azureリソース・グループは、VM、アプリ、ストレージ、アプリ、データベース、およびデータベース・サーバーの論理的なコレクションです。これらを使用すると、アプリケーションに関連するリソースをグループ化し、本番環境、非本番環境、その他の必要な組織構造のグループに分割できます。

Azure リソース・グループの管理モデルは、リソースを整理するために4つのレベル、つまり管理の「スコープ」を提供します。

• 管理グループ：これらのグループは、複数のサブスクリプションのアクセス、ポリシー、およびコンプライアンスを管理するためのコンテナです。管理グループ内のすべてのサブスクリプションは、管理グループに適用される条件を自動的に継承します。これらはしばしば、社内の部署や地域ごとにサブスクリプションをグループ化するために使用されます。
• サブスクリプション： サブスクリプションでは、あるユーザー・アカウントとそのユーザー・アカウントが作成したリソースを関連付けます。各サブスクリプションには、作成して使用できるリソースの数に制限または割り当てがあります。組織はサブスクリプションを使用して、ユーザー、チーム、プロジェクトによって作成されるコストとリソースを管理できます。通常、サブスクリプションはアプリケーションと同等です。
• リソース・グループ： リソース・グループは、Webアプリ、データベース、ストレージ・アカウントなどのAzureリソースのデプロイおよび管理を行う論理コンテナです。
• リソース： リソースは、VM、ストレージ、SQL Databaseなど、作成するサービスのインスタンスです。

これらのスコープを管理する際に留意すべき重要な要素の1つは、Azureのサブスクリプションと管理グループの相違点です。管理グループにAzureのリソースを含めることはできません。追加できるのは他の管理グループやサブスクリプションのみとなります。Azureの管理グループは、Azureのサブスクリプションより上位での編成を行うためのものです。たとえば、サブスクリプションがアプリケーションである場合は、Azure管理グループにはその部門が管理するすべてのアプリケーションが含まれる場合があります。Azureのリソース・グループには「ネストされた」リソース構造はありません。パーミッションのためにグループを「ネスト」するには、先に挙げた異なるレベルのパーミッションを組み合わせて使う必要があります。また、Azureリソース・グループと “Azureアベイラビリティ・セット “の概念を区別することも忘れないように。Azureのアベイラビリティセットは、アプリケーションの可用性を保護するために、アプリケーションの構築方法をAzureに通知するためのVMの論理的なグループ化です。

Azureリソース・グループを作成するにはいくつかの方法があります。

• Azureポータル
• Azure PowerShellスクリプト
• Azure CLI
• ARMテンプレート

Azureリソース・グループを使用する際のベスト・プラクティスをいくつかご紹介します。

• グループ内のリソースは、同じライフサイクルを持つ必要があります。たとえば、アプリケーションがSQLデータベース、アプリ、モバイル・アプリケーションなど、一緒に更新する必要があるさまざまなリソースを必要とする場合、これらのリソースを同じリソース・グループにグループ化するのは理にかなっています。ただし、DevTest、ステージング、または本番環境の場合、これらのグループ内のリソースのライフサイクルは異なるため、別のリソースグループまたは新しいリソースグループを使用することが重要です。
• リソースは、Azureリソース・グループに追加したり削除することが可能です。ただし、各リソースは1つのAzureリソース・グループに属している必要があるため、リソースをあるリソース・グループから別のリソースグループに移動させる場合は、元のグループからリソースを削除した後で、新しいグループに追加する必要があります。
• すべてのリソースを別のリソース・グループに移動できるわけではありません。
• リソース・グループに含めるリソースは、複数の異なるAzureリージョンにあっても構いません。グループ自体とは異なるリージョンでも問題ありません。ただし、遅延やクロスリージョンによるデータ転送を短縮するために、場合によってはすべてのリソースを同じリージョンのリソース・グループに保持することがベスト・プラクティスとなります。いずれにせよ、グループにはメタデータを保管する場所を指定する場所が必要であり、これは一部のコンプライアンス・ポリシーでは必須です。
• リソース・グループにアクセス権を付与します。リソースグループを使ってリソースへのアクセスを制御する必要があります。
• リソース・グループが削除されると、そのグループ内のすべてのリソースが削除されます。
• いくつかの例外を除き、各リソース・グループには、1つのリソース・タイプのインスタンスを最大800個までデプロイできます。

Azureリソース・グループの最適化を自動化する準備はできていますか？

Azureリソース・グループは、ロールベースのアクセス制御（RBAC）を運用するための手段のひとつです。通常はリソース・グループのレベルでユーザーにアクセス権を付与することが望ましいでしょう。グループを使用するとアクセス権の管理が簡単になり、可視性が向上します。

IBMがCIOに推奨している主なクラウドのベスト・プラクティスの一つは、組織に戦略をサポートする構造を与えることです。組織構造に従ってAzureリソースを編成することで、最小特権の原則に従い、管理グループやサブスクリプションのレベルではなく、リソース・グループのレベルで、必要最小限の権限にのみアクセス権を付与することが容易になります。たとえば、暗号化のキー管理に関するポリシーは管理グループレベルで適用できる一方、あらかじめ予定されているアカウント停止ポリシーは、リソースグループレベルで適用することになるでしょう。

タグ付けを効果的に使用すると、技術、オートメーション、料金請求、セキュリティーを目的としたリソースを特定できます。タグはリソースグループを超えて拡張できるため、タグを使用して同じプロジェクト、アプリケーション、サービスに属するグループとリソースを関連付けることができます。リソースの最適化を確実にするために、リソースのデプロイ前に標準的なタグセットの適用を要求するなど、タグ付けのベスト・プラクティスを必ず適用してください。

サブスクリプションとリソース・グループを編成する一般的な方法がいくつかあります。残念ながら一般的な最初のモデルは「カオス」です。もしこの言葉があなたの環境を表しているなら、諦めないでください。お客様の多くの組織がこうした成長の痛みを経験し、環境を整えて正常に機能させています。

次にアプリケーション単位での編成があります。例えば、給与管理や請求書管理のアプリケーションは、単一のAzureクラウド・サブスクリプションに関連付けられており、そのサブスクリプションの下に各環境のリソース・グループ（開発、テスト、ステージングなど）がロールアップされています。

環境別の編成構造もしばしば利用されます。この場合、本番環境全体、開発用、テスト用にそれぞれ1つのサブスクリプションがあり、その下に各アプリケーションに関連したリソース・グループがあります。最も成熟した方法は、事業単位またはサービスユニット別の編成で、企業機能にリソースの所有権を与えるモデルです。例えば、財務部門がサブスクリプションを所有し、マーケティング部門は別のサブスクリプションを所有します。それぞれのサブスクリプションの下には、各アプリケーションに対応するリソース・グループが存在します。

Azureリソース・グループと、その他クラウド・プロバイダーのネイティブな構造を使用すると、クラウド・リソースを効果的に整理および管理できます。基盤を作成し、Azureリソース・グループを使用して、必要なセグメンテーションを行い、事業部門とそこで実行するアプリケーションを関連付けたら、次のステップは、アプリケーションの需要にリソースを効果的に割り当てることです。これによりリソースのコストを最適化しつつ、アプリケーションのパフォーマンスを最大化することができます。

アプリケーションの性能を保証し、クラウドを最適化することは、人間のスケールを超えています。だからこそ、IBMでは、あらゆるクラウド上で、あらゆるスケールの、あらゆるアプリケーションの性能、コンプライアンス、およびコストを管理するという使命に力を注いでいます。

Turbonomicソフトウェアを使用すると、サブスクリプションとリソースの親子関係をより簡単に視覚化できます。この機能は、組織が実装したフレームワークを視覚的にマッピングするのに役立ち、すでに構築したアプリケーションのコンテキストでインフラストラクチャーを表示できるようにします。Turbonomicソフトウェアは、関連するすべてのAzureサブスクリプションとそのリソース・グループ、および各グループ内のリソース（Azure VM、Azure Managed Disks、SQL Server、共有リザーブド・インスタンスまたはスコープ対象の予約済みインスタンス）を自動的に検出します。Turbonomicソフトウェアは、各リソースの使用率を分析し、最適化アクションの生成を開始します。ここに記載されているビューには、単一のAzureサブスクリプションとその下にある複数のAzureリソース・グループの内訳、リソース・グループごとの保留中の最適化アクションと、そのアクションの実行で節減が見込まれる金額が表示されています。

さらに、Turbonomicソフトウェアには、顧客が安全なサンドボックス・モードでクラウド環境に対するさまざまなシナリオをモデル化できるように設計された強力な最適化モデリング・エンジンが含まれています。例えば、リソース・グループ内のワークロードを適正化した場合と、ワークロードを適正化しなかった場合の、Azure予約済みVMインスタンスのインベントリー使用率の影響をシミュレートすることができます。