Azure エンタープライズ スキャフォールディング:サブスクリプションの規範的なガバナンス

  • [アーティクル]

Note

Azure エンタープライズ スキャフォールディングは、Microsoft Cloud Adoption Framework に統合されています。 この記事の内容は、現在ではフレームワークの「準備手法」に移されています。 この記事は、2020 年前半に非推奨になる予定です。 新しいプロセスを使い始めるには、準備手法の概要、Azure ランディング ゾーン、ランディング ゾーンに関する考慮事項に関するページを参照してください。

俊敏性と柔軟性を求めてパブリック クラウドを採用する企業がますます増えています。 これらの企業は、収益を生み出したり、ビジネスのリソース使用状況を最適化したりするために、クラウドの強みに依存しています。 Microsoft Azure は、企業がさまざまなワークロードやアプリケーションに対応するためにブロックのように組み立てることができる多数のサービスと機能を提供しています。

Microsoft Azure の使用を決定することは、クラウドのメリットを実現する最初のステップに過ぎません。 次のステップは、企業が効果的に Azure を利用するための方法を理解して、次の質問に対応できるように設定する必要があるベースライン機能を特定することです。

  • "データの主権に懸念があります。自分のデータとシステムが規制要件を満たすことをどのように保証できるか"
  • "各リソースがサポートしているものを把握し、その明細を明らかにして正確に課金できるようにするにはどうすればよいか"
  • "パブリック クラウドでのデプロイや処理はすべて、セキュリティを最重要として開始されることを確認する必要があります。そのためには何をすべきか"

ガードレールのない空のサブスクリプションでは見通しが立ちません。 この空のスペースは、Azure への移行の妨げとなる可能性があります。

この記事は、技術者がガバナンスのニーズに対処し、俊敏性のニーズとのバランスを取る際の出発点となります。 この記事では、組織が安全な方法で Azure 環境を実装および管理する際の指針となるエンタープライズ スキャフォールディングの概念について説明します。 こうして提供されるフレームワークが、効果的かつ効率的な管理につながります。

ガバナンスのニーズ

Azure に移行する場合、企業内でクラウドを有効に活用するために、早期にガバナンスに対処する必要があります。 しかし、包括的なガバナンス システムの構築には時間がかかり、煩雑さを伴うため、IT 部門を関与させずに直接プロバイダーに依頼するビジネス グループもあります。 このアプローチでは、リソースが適切に管理されていない場合に、企業がセキュリティ侵害にさらされるおそれがあります。 パブリック クラウドの俊敏性、柔軟性、従量課金という特性は、(社内と外部の両方の) 顧客のニーズに速やかに対応する必要があるビジネス グループにとって重要です。 ただし、IT 部門はデータとシステムを効果的に保護できるようにする必要があります。

ビルを建てるとき、スキャフォールディング (足場) は構造の基礎を作るために使用されます。 スキャフォールディングは概要を示し、より永続的なシステムを実装するためのアンカー ポイントを提供します。 エンタープライズ スキャフォールディングも同様であり、環境を構造化する一連の柔軟な制御と Azure の機能、およびパブリック クラウド上に構築されるサービスのアンカーを提供します。 エンタープライズ スキャフォールディングは、迅速に提供することに配慮した、ビルダー (IT 部門とビジネス グループ) が新しいサービスを作成して配置するための基盤となります。

スキャフォールディングは、さまざまな規模のクライアントとの多数の取り組みの中で収集された実践に基づいています。 これらのクライアントは、小規模の組織から、クラウドでソリューションの移行と開発を行っている大規模な多国籍企業や独立系ソフトウェア ベンダーまでさまざまです。ワークロードを移行したり、クラウド用ソリューションを開発したりしています。 エンタープライズ スキャフォールディングは、従来型 IT ワークロードとアジャイル ワークロード (Azure プラットフォームの機能に基づくサービスとしてのソフトウェア (SaaS) アプリケーションの開発など) の両方を柔軟にサポートできるように設計されています。

エンタープライズ スキャフォールディングは、Azure 内の新しい各サブスクリプションの基盤として使用できます。 エンタープライズ スキャフォールディングにより、管理者は、ビジネス グループや開発者が各自の目標を速やかに達成するのを妨げることなく、組織のガバナンスの最小要件を満たすワークロードを実現できます。 私たちの経験から、これがパブリック クラウドの成長を妨げるものではなく、大いに加速させることは明らかです。

Note

Azure Blueprints と呼ばれる新機能がプレビューとしてリリースされました。これは、サブスクリプションや管理グループにまたがって、共通のイメージ、テンプレート、ポリシー、スクリプトの、パッケージ化、管理、およびデプロイを行えるようにするものです。 この機能は、参照モデルとしてのスキャフォールディングの目的と、企業へのモデルのデプロイの橋渡しをします。

次の図は、スキャフォールディングのコンポーネントを示しています。 基礎は、管理階層とサブスクリプションの確かな計画に依存しています。 柱は、Resource Manager ポリシーと厳密な命名規則で構成されます。 スキャフォールディングの残りの部分は、安全で管理しやすい環境を実現して結び付ける Azure のコア機能です。

Enterprise scaffold

階層の定義

スキャフォールディングの基盤は、サブスクリプションとリソース グループにおける Enterprise Agreement (EA) 加入契約の階層とリレーションシップです。 加入契約は、契約の観点から、企業内での Azure サービスの構造と使用法を定めています。 エンタープライズ契約の範囲内で、各企業の構造に合わせて、環境を部門、アカウント、サブスクリプション、リソース グループにさらに分割できます。

Hierarchy

Azure サブスクリプションは、すべてのリソースが含まれる基本単位です。 また、サブスクリプションによって Azure 内での制限 (コア数、仮想ネットワーク数、その他のリソース数など) が定められます。 リソース グループを使用すると、サブスクリプション モデルをさらに調整して、リソースを自然なグループに分けることができます。

企業はそれぞれ異なるので、上の図の階層はその企業での Azure の構造に非常に柔軟に対応します。 企業の課金、リソース管理、リソース アクセスのニーズを反映するように階層をモデル化することは、パブリック クラウドの運用を開始する際に最初に行う最も重要な決定事項です。

部門とアカウント

EA 加入契約には、次の 3 つの一般的なパターンがあります。

  • 機能パターン:

    Diagram of the functional pattern.

  • 部署パターン:

    Diagram of the business unit pattern.

  • 地域パターン:

    Diagram of the geographic pattern.

これらのパターンには役割がありますが、部署パターンが使用されることが増えています。企業のコスト モデルをモデル化する際や、統制範囲を反映する際に柔軟性が高いためです。 Microsoft のコア エンジニアリングと運用グループによって、連邦、州、および地方に関してモデル化された部署パターンの効果的なサブセットが作成されました。 詳細については、サブスクリプションとリソース グループの整理に関するページを参照してください。

Azure 管理グループ

Microsoft は階層をモデル化するための別の方法を提供しています。Azure 管理グループという新しい方法をリリースしました。 管理グループは、部門とアカウントよりも柔軟性が非常に高く、最大で 6 レベルまで入れ子にすることができます。 管理グループを使用すると、課金階層とは別に、リソースの効率的な管理のみを目的として階層を作成できます。 管理グループは課金階層を正確に反映するように作成できます。多くの企業ではそのように開始しています。 ただし、管理グループが力を発揮するのは、それらを使用して組織をモデル化し、関連するサブスクリプションをまとめて (請求階層内の場所に関係なく) グループ化し、共通のロール、ポリシー、およびイニシアティブを割り当てる場合です。 次に例をいくつか示します。

  • 運用と非運用。 一部の企業は、運用サブスクリプションと非運用サブスクリプションを識別するために管理グループを作成します。 このようなお客様は、管理グループによって、ロールとポリシーを簡単に管理できます。 たとえば、非運用サブスクリプションでは、開発者は、共同作成者としてアクセスできますが、運用環境では閲覧者としてのみアクセスできます。
  • 内部サービスと外部サービス。 企業では、多くの場合、内部サービスと顧客向けサービスで要件、ポリシー、ロールが異なります。

適切に設計された管理グループは、Azure Policy とポリシー イニシアティブとともに、効率的な Azure ガバナンスのバックボーンです。

サブスクリプション

部門とアカウント (または管理グループ) を決定する際には、主にご自分の組織に合わせて Azure 環境を調整する方法を検討します。 しかしながら、サブスクリプションは実際の処理が行われる場所であるため、ここでの決定はセキュリティ、スケーラビリティおよび課金に影響を与えます。 多くの組織では、次のパターンをガイドとして使用しています。

  • アプリケーション/サービス: サブスクリプションはアプリケーションまたはサービス (アプリケーションのポートフォリオ) を表します
  • ライフサイクル: サブスクリプションがサービスのライフサイクル (Production または Development など) を表します。
  • 部門: サブスクリプションは組織内の部門を表します。

最初の 2 つのパターンが最もよく使用されており、どちらも強くお薦めします。 ライフサイクルのアプローチはほとんどの組織に適しています。 この場合は、2 つの基本的なサブスクリプション (Production と Nonproduction) を使用してから、リソース グループを使用して環境をさらに分割することが、一般に推奨されます。

リソース グループ

Azure Resource Manager では、管理、課金、または自然なアフィニティのために、リソースを意味のあるグループに編成できます。 リソース グループは、共通のライフサイクルを持つリソースまたは All SQL servers や Application A などの属性を共有するリソースのコンテナーです。

リソース グループに別のリソース グループを入れ子にすることはできません。また、リソースは 1 つのリソース グループにのみ属することができます。 リソース グループのすべてのリソースに対して特定のアクションを適用できます。 たとえば、リソース グループを削除すると、そのリソース グループ内のすべてのリソースが削除されます。 サブスクリプションと同じく、リソース グループを作成するときには一般的なパターンがあり、これらは従来型 IT ワークロードからアジャイル IT ワークロードまでさまざまです。

  • 従来型 IT ワークロードは、一般的に、同じライフサイクル内の項目 (アプリケーションなど) でグループ化されます。 アプリケーションでグループ化すると、個々のアプリケーションの管理が可能になります。
  • アジャイル IT ワークロードは、外部顧客向けのクラウド アプリケーションに集中する傾向があります。 多くの場合、リソース グループは、デプロイメントのレイヤー (Web 層、アプリケーション層など) と管理のレイヤーを反映します。

Note

ワークロードを理解すると、リソース グループ戦略の開発に役立ちます。 これらのパターンをうまく組み合わせることができます。 たとえば、共有サービスのリソース グループは、アジャイル ワークロードのリソース グループと同じサブスクリプションに存在できます。

命名規則

スキャフォールディングの最初の柱は一貫性がある命名規則です。 適切に設計された命名規則を使用することで、ポータル、請求書、スクリプトでリソースを識別できるようになります。 おそらくオンプレミス インフラストラクチャのための命名規則は既に存在しています。 Azure を環境に追加するときは、それらの命名規則をAzure リソースにも適用する必要があります。

ヒント

命名規則のヒント

名前を後から変更するのは難しいことに注意してください。ここで数分間かけておけば後で面倒が起きません。

よく使用され検索対象にもなるリソースの命名規則は十分に考えてください。 たとえば、区別しやすいように、すべてのリソース グループが厳しい規則に従う必要があると定めます。

リソース タグ

リソース タグは命名規則と密接に関連しています。 リソースがサブスクリプションに追加されると、課金、管理、運用の目的から、論理的にリソースを分類することが非常に重要になります。 詳細については、タグを使用した Azure リソースの整理に関するページを参照してください。

重要

タグには個人情報が含まれる可能性があり、GDPR 規制の対象になる場合があります。 タグの管理は注意深く計画してください。 GDPR に関する全般情報については、Microsoft Service Trust Portal の GDPR に関するセクションを参照してください。

タグは課金や管理以外でも多くの方法で使用されます。 これらはオートメーションにおいてよく使用されます (後のセクションを参照してください)。 このため、事前に考慮しておかないと、競合が発生することがあります。 ベスト プラクティスは、エンタープライズ レベル (ApplicationOwner、CostCenter など) で一般的なすべてのタグを識別し、オートメーションを使用してリソースをデプロイするときにそれらを一貫して適用することです。

Azure のポリシーとイニシアティブ

スキャフォールディングの第 2 の柱は、Azure のポリシーとイニシアティブを使用して、サブスクリプションのリソースとサービスに対して (効果的に) 規則を適用して、リスクを管理することです。 Azure Policy のイニシアティブは、1 つの目標を達成するように設計されたポリシーのコレクションです。 その後、ポリシーとイニシアティブをリソース スコープに割り当てて、それらのポリシーの適用を開始します。

ポリシーとイニシアティブは、前述した管理グループと一緒に使用するとさらに効果的です。 管理グループを使用すると、イニシアティブまたはポリシーをサブスクリプションのセット全体に割り当てられるようになります。

Resource Manager ポリシーの一般的な使用法

ポリシーとイニシアティブは、強力な Azure ツールです。 ポリシーを使用すると、企業は基幹業務アプリケーションに安定性を提供する従来型 IT ワークロードを制御できるだけでなく、企業をさらなるリスクにさらすことなく顧客アプリケーションを開発するなど、よりアジャイルなワークロード開発も可能になります。 ポリシーの最も一般的なパターンは次のとおりです。

  • 地域コンプライアンスとデータの主権。 Azure が対応するリージョンは世界にまたがり、その数は増え続けています。 多くの場合、企業は、規制要件に対処するために、特定のスコープのリソースが 1 つの地理的リージョンに存在することを保証する必要があります。
  • サーバーの公開を回避します。 Azure のポリシーにより、特定のリソースの種類のデプロイを禁止できます。 一般的には、特定の範囲でパブリック IP の作成を拒否するポリシーを作成して、意図せずにサーバーをインターネットに公開することを避けます。
  • コスト管理とメタデータ。 多くの場合、リソース タグは、リソースとリソース グループに CostCenter や Owner などの重要な課金データを追加するために使用されます。 これらのタグは、リソースの正確な課金と管理のために重要です。 ポリシーによって、デプロイされたすべてのリソースに対してリソース タグの適用が実施され、管理が容易になります。

イニシアティブの一般的な使用方法

企業は、イニシアティブを利用して論理ポリシーをグループ化し、それらを 1 つのエンティティとして追跡することができます。 イニシアティブによって、企業はアジャイル ワークロードと従来のワークロード両方のニーズに対処できます。 次のようなイニシアティブの一般的な使用方法があります。

  • Microsoft Defender for Cloud でのファイルの整合性の監視を有効にします。 これは Azure Policy での既定のイニシアティブであり、イニシアティブとは何かがよくわかる例です。 これによって、ポリシーで、暗号化されていない SQL データベース、仮想マシン (VM) の脆弱性、一般的なセキュリティ関連ニーズを識別できるようになります。
  • 規制固有のイニシアティブ。 多くの場合、企業は規制要件 (HIPAA など) に共通するポリシーをグループ化して、コントロールやコントロールに対するコンプライアンスを効率的に追跡できるようにします。
  • リソースの種類と SKU。 デプロイできるリソースの種類と、デプロイできる SKU を制限するイニシアティブの作成は、コストを管理するために役立ちます。また、これによって、組織は、サポートするためのスキルセットと手順がチームにあるリソースのみを確実にデプロイできます。

ヒント

ポリシー定義の代わりにイニシアティブ定義を常に使用することをお勧めします。 イニシアティブをスコープ (サブスクリプションまたは管理グループ) に割り当てた後で、割り当てを変更する必要なく、イニシアティブに簡単にもう 1 つのポリシーを追加できます。 これにより、適用内容の理解とコンプライアンスの追跡がきわめて容易になります。

ポリシーとイニシアティブの割り当て

ポリシーを作成して、それを論理的なイニシアティブにグループ分けしたら、そのポリシーをスコープ (管理グループ、サブスクリプション、リソース グループなど) に割り当てる必要があります。 割り当てによって、ポリシーの割り当てからサブスコープを除外することもできます。 たとえば、あるサブスクリプション内のパブリック IP の作成を拒否する場合に、保護対象の DMZ に接続するリソース グループを除外する割り当てを作成できます。

Azure のリソースにポリシーとイニシアチブを適用する方法を示す例については、azure-policy GitHub リポジトリで入手できます。

ID およびアクセス管理

パブリック クラウドを導入する際に尋ねるべき重要な質問としては、「誰がリソースにアクセスできる必要がありますか」や「このアクセスはどのように制御しますか」などがあります。Azure portal とリソースへのアクセス制御は、クラウド内の資産の長期的な安全性にとって不可欠です。

リソースへのアクセスをセキュリティで保護するには、まず ID プロバイダーを構成してから、ロールとアクセス権を構成します。 オンプレミスの Active Directory に接続している Microsoft Entra ID は、Azure の ID の基盤です。 ただし、Microsoft Entra ID はオンプレミスの Active Directory と同じではありません。Microsoft Entra テナントとは何か、加入契約とどのように関連しているかを理解することが重要です。 Azure でのリソース アクセス管理の記事を参照して、Microsoft Entra ID とオンプレミスの Active Directory についてよく理解してください。 オンプレミスのディレクトリを Microsoft Entra ID に接続して同期するには、オンプレミスで Microsoft Entra Connect ツールをインストールして構成します。

Diagram of an architecture that includes both Microsoft Entra ID and an on-premises Active Directory instance.

Azure が最初にリリースされた時点では、サブスクリプションへのアクセス制御は基本的なもので、ユーザーには管理者または共同管理者のロールを割り当てることができました。 このクラシック モデルでのサブスクリプションへのアクセスは、ポータルでのすべてのリソースへのアクセスを意味していました。 きめ細かく制御することができなかったため、加入契約に妥当なレベルのアクセスの制御を提供するためにサブスクリプションが急増しました。 このようにサブスクリプションを急増させる必要はなくなりました。 Azure ロールベースのアクセス制御 (RBAC) を使用すると、所有者、共同作成者、閲覧者など一般的なアクセス権を提供する標準ロールをユーザーに割り当てることも、さらには独自のロールを作成することもできます。

Azure ロールベースのアクセス制御を実装する場合は、次の方法を強くお薦めします。

  • サブスクリプションの管理者および共同管理者ロールは広範な権限を持っているため、これらのロールを制御します。 サブスクリプションの所有者を共同管理者として追加する必要があるのは、その所有者が Azure クラシック デプロイを管理する必要がある場合だけです。
  • 管理グループを使用して、複数のサブスクリプションにロールを割り当て、サブスクリプション レベルでロールを管理する負荷を減らします。
  • Azure ユーザーを Active Directory のグループ (Application X Owners など) に追加します。 同期されたグループを使用して、アプリケーションが属するリソース グループを管理するための適切な権限をグループのメンバーに付与します。
  • 求められている作業を行うために必要な最小限の特権の付与の原則に従います。

重要

Microsoft Entra Privileged Identity Management、Azure 多要素認証、Microsoft Entra 条件付きアクセス機能の使用を検討してください。これらによって、セキュリティが強化され、Azure サブスクリプション全体の管理操作の可視性が向上します。 これらの機能は、有効な Microsoft Entra ID P1 または P2 ライセンス (機能によって異なります) によって提供され、ID のセキュリティと管理を強化できます。 Microsoft Entra PIM を使うと、承認ワークフローによる Just-In-Time の管理者アクセスと、管理者のアクティブ化とアクティビティの完全な監査が可能になります。 Azure 多要素認証はもう 1 つの重要な機能であり、Azure portal へのサインインの 2 段階認証を有効にします。 Microsoft Entra の条件付きアクセス制御と組み合わせると、セキュリティ侵害のリスクを効果的に管理できます。

ID およびアクセス制御について計画を立てて準備すること、および Azure の ID 管理のベスト プラクティスに従うことは、採用できる最適なリスク軽減戦略の 1 つであり、すべてのデプロイにおいて必須と考える必要があります。

セキュリティ

従来、クラウド導入の最大の障壁の 1 つは、セキュリティに対する懸念でした。 IT リスク マネージャーとセキュリティ部門は、Azure 内のリソースのセキュリティが既定で保護されており安全であることを保証する必要があります。 Azure には、リソースを保護しながら、リソースに対する脅威を検出して排除するために使用できる機能があります。

Microsoft Defender for Cloud

Microsoft Defender for Cloud は、環境全体のリソースのセキュリティ状態についての統一されたビューと、脅威に対する高度な保護を提供します。 Defender for Cloud はオープン プラットフォームです。Microsoft のパートナーは、プラグインして機能を強化するソフトウェアを作成できます。 Defender for Cloud の Free レベルのベースライン機能によって、セキュリティ態勢を強化する評価と推奨事項を提供します。 有料レベルでは、Just-In-Time 特権アクセスや適応型アプリケーション制御 (許可リスト) など、役に立つ追加機能が有効になります。

ヒント

Defender for Cloud は強力なツールであり、絶えず改善されており、脅威の検出や企業の保護に使用できる新しい機能を取り入れています。 常に Defender for Cloud を有効にすることを強くお勧めします。

Azure リソースのロック

組織がサブスクリプションにコア サービスを追加すると、ビジネスの中断を回避することがますます重要になります。 一般的な中断の 1 つは、Azure サブスクリプションで実行されているスクリプトまたはツールがリソースを誤って削除したときに発生します。 ロックによって、変更または削除したときに大きな影響を及ぼす価値の高いリソースに対する操作が制限されます。 ロックは、サブスクリプション、リソースグループ、または個々のリソースに適用できます。 仮想ネットワーク、ゲートウェイ、ネットワーク セキュリティ グループ、キー ストレージ アカウントなど、基盤となるリソースにロックを適用します。

Secure DevOps Kit for Azure

Secure DevOps Kit for Azure (AzSK) は、スクリプト、ツール、拡張機能、オートメーション機能のコレクションです。元は Microsoft の IT チームによって作成され、GitHub でオープン ソースとしてリリースされています。 AzSK はオートメーションを広範に使用し、セキュリティをネイティブの DevOps ワークフローに円滑に統合して、チームのためにあらゆる Azure サブスクリプションとリソース セキュリティのニーズに対応します。次に示す 6 つの重点分野で、セキュアな DevOps を実現するために役立ちます。

  • サブスクリプションの保護
  • セキュアな開発の実現
  • セキュリティと CI/CD の統合
  • 継続的な保証
  • アラートと監視
  • クラウドのリスク ガバナンス

Overview diagram of the Secure DevOps Kit for Azure

AzSK は、Azure ガバナンス プラン全体の重要な部分を占めるツール、スクリプト、情報を豊富に含むセットです。これをスキャフォールディングに組み込むことは、組織のリスク管理目標を達成するために重要です。

Azure Update Management

環境の安全を保つためにできる重要なタスクの 1 つは、確実にサーバーに最新の更新プログラムが適用されるようにすることです。 これを実現するツールは多数ありますが、Azure が提供する Azure Update Management ソリューションは、重要な OS パッチを識別してロールアウトします。 これは、このガイドの後半の「自動化」セクションで説明している Azure Automation を利用しています。

監視とアラート

テレメトリの収集と分析は、Azure サブスクリプションで使用しているサービスの、アクティビティ、パフォーマンス メトリック、正常性と可用性に関する見通しを得ることができ、アプリケーションとインフラストラクチャを積極的に管理するために不可欠です。また、すべての Azure サブスクリプションの根本的なニーズです。 すべての Azure サービスは、テレメトリをアクティビティ ログ、メトリック、診断ログの形式で出力します。

  • アクティビティ ログには、サブスクリプションのリソースに対して実行されたすべての操作が示されています。
  • メトリックは、リソースから生成される数値情報であり、リソースのパフォーマンスと正常性を示します。
  • 診断ログは、Azure サービスから出力され、そのサービスの操作に関する豊富なデータを提供します。

これらの情報は複数のレベルで表示して対処することができ、常に改善されています。 Azure では、次の図に概説されているサービスを通じて、Azure リソースの共有、コア、詳細の監視機能を提供しています。

Diagram that depicts deep application monitoring, deep infrastructure monitoring, core monitoring, and shared capabilities.

共有機能

  • アラート: Azure リソースのすべてのログ、イベント、メトリックを収集できますが、重大な状態や動作を通知する機能はありません。このデータが役立つのは履歴管理の目的やフォレンジクスのためだけです。 Azure アラートは、すべてのアプリケーションとインフラストラクチャに対して定義した状態についてプロアクティブに通知します。 一連の受信者に通知するために、ログ、イベント、メトリックに対して、アクション グループを使用するアラート ルールを作成します。 アクション グループでは、外部アクションを使用して、修復のオートメーションを行う機能も提供されます。たとえば、Webhook を使用して、Azure Automation Runbook や Azure Functions を実行します。

  • ダッシュボード: ダッシュボードでは、監視ビューを集計して、リソースとサブスクリプションに対するデータを組み合わせることができ、Azure リソースのテレメトリについて企業全体のビューを提供します。 独自のビューを作成して構成し、他のユーザーと共有することができます。 たとえば、データベース管理者向けのさまざまなタイルを含むダッシュボードを作成して、Azure SQL Database、Azure Database for PostgreSQL、Azure Database for MySQL など、すべての Azure データベース サービスに関する情報を提供できます。

  • メトリックス エクスプローラー: メトリックは、リソースの操作やパフォーマンスの分析情報を提供する、Azure リソースによって生成される数値 (CPU の割合やディスク I/O メトリック) です。 メトリックス エクスプローラーを使用すると、興味があるメトリックを定義し、Log Analytics に送信して集計および分析できます。

コアな監視

  • Azure Monitor: Azure Monitor は、Azure リソースを 1 つのソースから監視できるコア プラットフォーム サービスです。 Azure Monitor の Azure portal インターフェイスは、Application Insights、Log Analytics、ネットワーク監視、管理ソリューション、サービス マップといった、詳細な監視機能を含め、Azure 全体のすべての監視機能が一元管理される出発点です。 Azure Monitor を使用すると、クラウド全体の Azure リソースのメトリックとログを視覚化、クエリ、ルーティング、アーカイブし、そのメトリックとログに対してアクションを実行できます。 ポータルに加え、Azure Monitor PowerShell コマンドレット、クロスプラットフォーム CLI、または Azure Monitor REST API でデータを取得できます。

  • Azure Advisor: Azure Advisor は、サブスクリプションと環境の全体にわたって継続的にテレメトリを監視します。 また、Azure リソースのコストを最適化し、アプリケーション リソースのパフォーマンス、セキュリティ、可用性を向上させるためのベスト プラクティスが推奨されます。

  • Azure Service Health: Azure Service Health では、アプリケーションに影響を及ぼす可能性がある Azure サービスの問題を特定します。これは、予定メンテナンス期間を計画する際に役立ちます。

  • アクティビティ ログ: アクティビティ ログには、サブスクリプションのリソースに対するすべての操作が示されています。 提供される監査証跡によって、リソースに対するすべての CRUD (作成、更新、削除) 操作について、"何を"、"だれが"、"いつ" を特定できます。 アクティビティ ログ イベントがプラットフォームに保存され、クエリで使用できる期間は 90 日です。 アクティビティ ログを Log Analytics に取り込むと、長期間保存することができ、複数のリソースに対して詳細なクエリと分析を行うことができます。

詳細なアプリケーション監視

  • Application Insights: Application Insights では、アプリケーション固有のテレメトリを収集し、クラウドまたはオンプレミス内のアプリケーションのパフォーマンス、可用性、使用状況を監視できます。 .NET、JavaScript、Java、Node.js、Ruby、Python など、サポートされる複数の言語用の SDK を使用してアプリケーションをインストルメント化します。 Application Insights イベントが、インフラストラクチャとセキュリティ監視をサポートする同じ Log Analytics データ ストアに取り込まれると、高機能のクエリ言語を使用し、長期にわたってイベントを相互に関連付けて集計できます。

詳細なインフラストラクチャ監視

  • Log Analytics: Log Analytics は、Azure の監視において中心的役割を果たします。たとえば、さまざまなソースからテレメトリなどのデータを収集します。また、アプリケーションやリソースの運用を洞察するためのクエリ言語や分析エンジンを提供します。 Log Analytics のデータは、高速ログ検索やビューを通じて直接、対話操作することができるほか、Log Analytics にデータを格納する他の Azure サービス (Application Insights、Microsoft Defender for Cloud など) の分析ツールを使用することもできます。

  • ネットワーク監視: Azure のネットワーク監視サービスでは、ネットワーク トラフィック フロー、パフォーマンス、セキュリティ、接続性、ボトルネックについて洞察することができます。 よく計画されたネットワーク設計には、Network Watcher や ExpressRoute Monitor など、Azure ネットワーク監視サービスの構成を含める必要があります。

  • 管理ソリューション: 管理ソリューションは、アプリケーションまたはサービスのための、ロジック、分析情報、および事前定義済み Log Analytics クエリのセットがパッケージ化されたものです。 これらは Log Analytics を基盤として使用し、イベント データを格納および分析します。 サンプルの管理ソリューションには、コンテナー監視と Azure SQL Database 分析が含まれます。

  • Service Map: Service Map では、インフラストラクチャ コンポーネント、そのプロセス、および他のコンピューターや外部プロセスへの相互依存関係に関するグラフィカル ビューが提供されます。 これにより、Log Analytics 内のイベント、パフォーマンス データ、管理ソリューションが統合されます。

ヒント

個々のアラートを作成する前に、Azure アラート全体で使用できる共有アクション グループのセットを作成して管理します。 これによって、受信者リスト、通知配信方法 (電子メール、SMS 電話番号)、および外部アクションに対する Webhooks (Azure Automation Runbook、Azure Functions と Logic Apps、ITSM) のライフサイクルを一元的に管理できるようになります。

コスト管理

オンプレミス クラウドからパブリック クラウドに移るときに直面する大きな変化の 1 つは、設備投資 (ハードウェアの購入) から営業経費 (使用するサービスの支払) への切り替えです。 この切り替えには、より慎重なコスト管理も必要です。 クラウドのメリットは、不要になったときにシャットダウンするかサイズを変更するだけで、使用するサービスのコストに根本的かつ肯定的な影響を与えられることです。 意図的にクラウドにおいてコストを管理することは、ベスト プラクティスであり、熟練した顧客は日常的に行っています。

Microsoft では、コストの視覚化、追跡、および管理に役立ついくつかのツールを提供しています。 また、コスト管理を独自のツールとダッシュボードにカスタマイズして統合できるように API の完全なセットも提供されます。 これらのツールは Azure portal の機能と外部機能に大まかに分けることができます。

Azure portal の機能

これらは、コストに関する即時性のある情報と、アクションを実行する機能を提供するツールです。

  • サブスクリプション リソース コスト: ポータルにある、Azure Cost Management + Billing ビューでは、コストをひとめで確認でき、リソースまたはリソース グループごとの毎日の支出に関する情報を得ることができます。
  • Azure Cost Management + Billing: これにより、Azure の支出額および他のパブリック クラウド プロバイダーでの支出を管理および分析することができます。 Free レベルと有料レベルの両方があり、豊富な機能があります。
  • Azure Budgets とアクション グループ: 何にコストがかかるか、それについて何をすべきかを把握するのは、最近まではほぼ手動で行っていました。 Azure の予算とその API が導入されたことにより、コストがしきい値に達したときに実行されるアクションを作成できるようになりました。 たとえば、test リソース グループの消費量が予算の 100% に到達したら、そのグループをシャットダウンできます。
  • Azure Advisor: 何にコストがかかるかを把握しても、戦いは半分しか終わっていません。もう半分は、その情報に対してどうすべきかを把握することです。 Azure Advisor では、費用の節約、信頼性の向上、さらにはセキュリティの向上のための処置についてレコメンデーションが提供されます。

外部のコスト管理ツール

  • Power BI Azure Consumption Insights: 組織のために独自の視覚エフェクトを作成しますか。 その場合は、Power BI 用の Azure Consumption Insights コンテンツ パックをツールとして選択してください。 このコンテンツ パックと Power BI を使用すると、組織を表すためにカスタムの視覚エフェクトを作成し、コストについて詳しい分析を実行し、さらに充実させるために他のデータ ソースを追加することもできます。

  • Azure Consumption API:Consumption API を使用すると、予算、予約インスタンス、マーケットプレース請求料金に関する情報に加えて、コストと使用状況のデータにプログラムからアクセスできます。 これらの API にアクセスできるのは、EA 加入契約と一部の Web Direct サブスクリプションのみです。ただし、これらにより、コスト データを独自のツールとデータ ウェアハウスに統合することができるようになります。 また、Azure CLI を使用してこれらの API にアクセスすることもできます。

長期の熟練したクラウド ユーザーであるお客様は、特定のベスト プラクティスに従います。

  • コストを積極的に監視します。 熟達した Azure ユーザーである組織は、絶えずコストを監視して、必要に応じて対処しています。 組織によっては、分析を実行して使用方法の変更を提案するために専任の担当者を置くところもあります。このような担当者は、数か月間稼働しているのに未使用の HDInsight クラスターを見つけたときに初めて、採算以上の働きをしたことになります。
  • Azure Reserved VM Instances を使用します。 クラウドにおいてコストを管理するもう 1 つの重要な理念は、ジョブに対して正しいツールを使用することです。 年中無休で維持する必要がある IaaS VM がある場合は、予約インスタンスを使用すると大幅にコストを節約できます。 VM のシャットダウンのオートメーションと予約インスタンスの使用の間で適切なバランスを見つけるには、経験と分析が必要です。
  • オートメーションを効果的に使用します。 多くのワークロードは毎日実行する必要はありません。 毎日 4 時間ずつ VM をオフにすると、コストの 15% を節約できます。 オートメーションはすぐに効果が得られます。
  • わかりやすくするためにリソース タグを使用します。 このドキュメントの別の場所でも説明していますが、リソース タグを使用するとコストを詳しく分析できます。

コスト管理は、パブリック クラウドを効果的かつ効率的に実行するために重要な原則です。 成功を収める企業は、過剰に購入して需要が発生することを望むのではなく、コストを管理し、コストを実際の需要に合わせることができます。

自動化

クラウド プロバイダーを使用する組織の熟練度を区別する能力がいくつもありますが、その 1 つは、組み込んでいるオートメーションのレベルです。 オートメーションは決して終わらないプロセスです。 組織がクラウドに移行するとき、この部分にこそ、構築のためにリソースと時間を投資する必要があります。 リソースの一貫したロールアウト (スキャフォールディングのもう 1 つの主要概念であるテンプレートと DevOps に直接関連しています) から、問題の修復まで、オートメーションには多くの目的があります。 オートメーションは、Azure スキャフォールディングの各部分を結び付けます。

Azure Automation、Event Grid、Azure CLI といった Microsoft 製ツールから、Terraform、Jenkins、Chef、Puppet などの多数のサード パーティ製ツールまで、この機能を構築するときに役立つツールがいくつかあります。 コア オートメーション ツールには、Azure Automation、Event Grid、Azure Cloud Shell などがあります。

  • Azure Automation を使用すると、PowerShell または Python で Runbook を作成し、プロセスの自動化、リソースの構成、さらにはパッチの適用も実行できます。 Azure Automation には、デプロイに不可欠な広範なクロス プラットフォーム機能のセットが含まれますが、範囲が広すぎるためここで詳しく説明することはできません。
  • Event Grid は、Azure 環境内のイベントに対応することができるフル マネージドのイベント ルーティング システムです。 Azure Automation が成熟したクラウド編成の結合組織であるのと同様に、Event Grid は優れたオートメーションの結合組織です。 Event Grid を使用すると、新しいリソースが作成されるたびに管理者に電子メールを送信して、そのリソースをデータベースに記録する、単純なサーバーレス アクションを作成できます。 その同じ Event Grid が、リソースが削除されたときに通知し、アイテムをデータベースから削除することができます。
  • Azure Cloud Shell は、Azure でリソースを管理するための、ブラウザーベースのインタラクティブなシェルです。 これは、PowerShell または Bash に最適な環境を提供します。必要に応じて起動 (および管理) されるため、スクリプトを実行するために一貫性のある環境を得ることができます。 Azure Cloud Shell では、環境のオートメーションを行うために、既にインストールされている他の重要なツールにアクセスできます。Azure CLI や Terraform の他にも、コンテナー、データベース (sqlcmd) などを管理するためのツールがますます増加しています。

オートメーションはフルタイム ジョブであり、またたく間にクラウド チームにおける最も重要な運用タスクの 1 つになろうとしています。 "オートメーション ファースト" のアプローチを採用する組織は、 Azure を使用して大きな成功を収めます。

  • コストの管理: 積極的に機会を探し、リソースのサイズ変更、スケールアップ/スケールダウン、未使用リソースのオフを実行するオートメーションを作成します。
  • 運用の柔軟性: オートメーションを (テンプレートと DevOps と組み合わせて) 使用し、一定レベルの再現性を得ることで、可用性の向上やセキュリティの強化につながり、チームがビジネスの問題解決に集中できるようになります。

テンプレートと DevOps

以前に強調したように、組織の目標は、ソース管理されたテンプレートとスクリプトを介してリソースをプロビジョニングすること、さらに対話型での環境の構成を最小限にすることです。 継続的なデプロイのための制御された DevOps プロセスと "infrastructure as code" アプローチを組み合わせると、一貫性を保証することができ、環境内での誤差を減らすことができます。 ほぼすべての Azure リソースは、Azure Resource Manager JSON テンプレートを、PowerShell または Azure クロス プラットフォーム CLI や、HashiCorp の Terraform (最上のサポートと Azure Cloud Shell との統合が提供される) などのツールと組み合わせてデプロイできます。

Azure Resource Manager テンプレートを使用する場合のベスト プラクティスなどの記事では、Azure DevOps ツール チェーンを含む Azure Resource Manager テンプレートに DevOps アプローチを適用する場合について、ベスト プラクティスや実例から学んだ内容を説明しています。 特に運用環境と QA 環境に関しては、時間と労力を費やして、組織の要件に合うテンプレートのコア セットを開発し、DevOps ツール チェーン (Azure DevOps、Jenkins、Bamboo、TeamCity、Concourse など) を使用して継続的デリバリー パイプラインを開発してください。 Azure クイックスタート テンプレートの大規模なライブラリが GitHub 上にあり、テンプレートの作成を開始するときに役立ちます。また、Azure DevOps を使用するとクラウドベースの配信パイプラインを迅速に作成できます。

運用サブスクリプションまたはリソース グループのベスト プラクティスとしては、Azure RBAC セキュリティを使用して既定で対話型ユーザーを禁止することと、サービス プリンシパルに基づいて自動化された継続的デリバリー パイプラインを使用して、すべてのリソースをプロビジョニングし、すべてのアプリケーション コードを配信することが目標です。 管理者も開発者も Azure portal を使用してリソースを対話形式で構成する必要はありません。 このレベルの DevOps では協調が求められますが、Azure スキャフォールディングのすべての概念を使用して、組織の拡大縮小のニーズを満たす、一貫性を備えたセキュアな環境を提供します。

ヒント

複雑な Azure Resource Manager テンプレートを設計および開発するときは、リンクされたテンプレートを使用して、モノリシック JSON ファイルから複雑なリソースの関係を編成してリファクタリングします。 これにより、リソースを個別に管理できるようになり、テンプレートの内容がわかりやすくなり、テストや再利用を行いやすくなります。

Azure は、ハイパースケール クラウド プロバイダーです。 組織がオンプレミス サーバーからクラウドに移るときに、クラウド プロバイダーと SaaS アプリケーションが使用するのと同じ概念を利用することで、組織がビジネスのニーズに対応する効率の大幅な向上に役立ちます。

コア ネットワーク

Azure スキャフォールディング参照モデルの最後のコンポーネントは、組織がどうやって安全に Azure にアクセスするかという点で重要です。 リソースへのアクセスは内部 (企業のネットワーク内) の場合もあれば、外部 (インターネット経由) の場合もあります。 組織のユーザーは誤って不適切な場所にリソースを配置しがちであり、リソースが悪意のあるアクセスにさらされる可能性があります。 オンプレミスのデバイスと同様に、企業は Azure ユーザーが正しく判断できるように適切な制御を追加する必要があります。 Microsoft では、サブスクリプション ガバナンスのために、基本的なアクセス制御を提供するコア リソースを特定しました。 コア リソースは以下で構成されます。

  • 仮想ネットワークは、サブネットのコンテナー オブジェクトです。 必須ではありませんが、アプリケーションを内部の企業リソースに接続するときによく使用されます。
  • ユーザー定義ルートを使用すると、サブネット内のルート テーブルを操作して、ネットワーク仮想アプライアンス経由でのトラフィックの送信、またはピアリングした仮想ネットワーク上のリモート ゲートウェイへのトラフィックの送信を行うことができます。
  • 仮想ネットワーク ピアリングでは、Azure の 2 つ以上の仮想ネットワークをシームレスに接続し、より複雑なハブとスポークの設計または共有サービス ネットワークを作成できます。
  • サービス エンドポイント。 かつて、PaaS サービスはさまざまな方法に依存して、仮想ネットワークからそれらのリソースへのアクセスを保護していました。 サービス エンドポイントを使用すると、接続したエンドポイントのみからの有効な PaaS サービスに対するアクセスを保護することができ、全体のセキュリティが向上します。
  • セキュリティ グループは広範な規則のセットであり、これを使用すると、Azure リソースに対するインバウンドおよびアウトバウンド トラフィックを許可または拒否できるようになります。 セキュリティ グループは、サービス タグ (Azure Key Vault、Azure SQL Database など一般的な Azure サービスを定義) とアプリケーション セキュリティ グループ (Web やアプリケーション サーバーなどのアプリケーション構造を定義) を使用して拡張できるセキュリティ規則で構成されます。

ヒント

ネットワーク セキュリティ グループでサービス タグとアプリケーション セキュリティ グループを使用して、以下のことを行います。

  • ルールの読みやすさを向上させます。これは、影響を理解するうえで非常に重要です。
  • 大きなサブネット内で効果的なマイクロセグメント化を有効にすることで、不規則な拡大が減り、柔軟性が高まります。

Azure 仮想データセンター

Azure では、効果的なセキュリティ体制を提供する充実したパートナー ネットワークから、内部およびサード パーティ両方の機能が提供されます。 さらに重要なのは、Azure 仮想データセンター (VDC) という形で、ベスト プラクティスとガイダンスが提供されることです。 1 つのワークロードからハイブリッド機能を使用する複数のワークロードに移るとき、VDC ガイダンスから、Azure 内のワークロードが増大するにつれ拡張する柔軟性の高いネットワークを実現する "レシピ" が提供されます。

次のステップ

ガバナンスは Azure の成功に不可欠です。 この記事は、エンタープライズ スキャフォールディングの技術的な実装を対象としていますが、広範なプロセスとコンポーネント間の関係だけを取り上げています。 ポリシー ガバナンスのフローはトップダウンであり、その企業が目指していることによって決まります。 当然ながら、Azure のガバナンス モデルの作成には IT 部門の担当者が参加しますが、さらに重要なことは、ビジネス グループのリーダーの有力な代表者とセキュリティおよびリスク管理部門も参加することです。 要するに、エンタープライズ スキャフォールディングとは、ビジネス リスクを軽減して組織の任務や目的を推進することです。

サブスクリプション ガバナンスについて説明したので、「Azure 対応性のベスト プラクティス」を確認して、これらの推奨事項を実際に確認してください。