Google Cloud プロフェッショナルのための Azure

  • [アーティクル]

この記事は、Google Cloud のエキスパートが Microsoft Azure のアカウント、プラットフォーム、およびサービスの基本を理解するために役立ちます。 Google Cloud と Azure プラットフォームの主要な類似点と相違点についても取り上げます。 (Google Cloud は以前は Google Cloud Platform (GCP) と呼ばれていたことに注意してください)。

学習内容:

  • アカウントとリソースが Azure でどのように構成されているか。
  • 利用可能なソリューションが Azure でどのように構造化されているか。
  • 主要な Azure サービスが Google Cloud サービスとどのように異なっているか。

Azure と Google Cloud のさまざまな機能は時間の経過と共に独立して構築されたため、各機能の実装と設計には重要な相違点があります。

Azure for Google Cloud の概要

Google Cloud と同じように、Microsoft Azure も、コンピューティング、ストレージ、データベース、およびネットワーク サービスを中心に構築されています。 多くの場合、両方のプラットフォームが提供する製品とサービスは、基本的には同等です。 Google Cloud と Azure の両方で、Windows または Linux ホストに基づく可用性が高いソリューションを構築できます。 したがって、Linux と OSS のテクノロジを使用する開発に慣れていれば、両方のプラットフォームでその仕事を行うことができます。

2 つのプラットフォームの機能は似ていますが、それらの機能を提供するリソースの構成は、しばしば異なっています。 ソリューションを構築するために必要なサービス間の一対一のリレーションシップは、常に明確であるとは限りません。 さらに、特定のサービスが片方のプラットフォームでのみ提供されている場合があります。

アカウントとサブスクリプションの管理

Azure には、リソースを効果的に管理するための管理グループとサブスクリプションおよびリソース グループの階層が用意されています。 これは、Google Cloud のリソースのフォルダーとプロジェクトの階層に似ています。

図は、ルートとして管理グループを持つツリー構造を示しており、次にサブスクリプション、リーフ ノードとしてのリソース グループと続きます。

管理範囲の Azure のレベル

  • 管理グループ: これらのグループは、複数のサブスクリプションのアクセス、ポリシー、コンプライアンスを管理するのに役立つコンテナーです。 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。
  • サブスクリプション: サブスクリプションでは、ユーザー アカウントと、それらのユーザー アカウントによって作成されたリソースが論理的に関連付けられます。 各サブスクリプションには、作成して使用できるリソース量に対する制限やクォータがあります。 組織では、ユーザー、チーム、またはプロジェクトによって作成されるリソースとコストを管理するためにサブスクリプションを使用できます。
  • リソース グループ: リソース グループとは、Web アプリ、データベース、ストレージ アカウントなどの Azure リソースのデプロイと管理に使用する論理コンテナーです。
  • リソース: リソースは、仮想マシン、ストレージ、SQL データベースなど、ユーザーが作成するサービスのインスタンスです。

Azure サービスは、組織の規模とニーズに応じて、さまざまな価格オプションで購入できます。 詳細については、価格の概要に関するページを参照してください。

Azure サブスクリプションは、リソースと割り当てられた所有者をグループ化したものです。所有者は課金とアクセス許可の管理を担当します。

Google Cloud プロジェクト は、課金、クォータ、制限に関して、概念的には Azure サブスクリプションに似ています。 ただし、機能面については、Google Cloud プロジェクトは Azure のリソース グループに似ています。 これは、クラウド リソースがデプロイされる論理ユニットです。

Google Cloud とは異なり、Azure サブスクリプションの最大数はないことに注意してください。 各 Azure サブスクリプションは、単一の Microsoft Entra テナント (Google Cloud 用語では "アカウント") にリンクされています。 Microsoft Entra テナントに含めることができるサブスクリプションの数に制限はありませんが、Google Cloud の既定では、アカウントあたり 30 プロジェクトの制限があります。

サブスクリプションには、3 種類の管理者アカウントが割り当てられます。

  • アカウント管理者。 サブスクリプションの所有者であり、このアカウントに対して、サブスクリプションで使用されたリソースの課金が行われます。 アカウント管理者は、サブスクリプションの所有権を譲渡することでのみ変更できます。
  • サービス管理者。 このアカウントには、サブスクリプション内にリソースを作成して管理する権限がありますが、課金の責任は負いません。 既定では、アカウント管理者とサービス管理者は同じアカウントに割り当てられます。 アカウント管理者は、サブスクリプションの技術面と運用面を管理するサービス管理者アカウントに別のユーザーを割り当てることができます。 サブスクリプションごとに割り当てられるサービス管理者は 1 人だけです。
  • 共同管理者。 1 つのサブスクリプションに複数の共同管理者アカウントを割り当てることができます。 共同管理者はサービス管理者を変更できませんが、それ以外は、サブスクリプションのリソースとユーザーを完全に制御できます。

Azure リソースへのきめ細かなアクセス管理には、Azure ロールベースのアクセス制御 (Azure RBAC) を使用できます。これには、70 を超える組み込みのロールが含まれています。 独自のカスタム ロールを作成することもできます。

サブスクリプション レベルの下で、特定のリソースに対してユーザー ロールと個々のアクセス許可を割り当てることもできます。 Azure では、すべてのユーザー アカウントは、Microsoft アカウントまたは組織アカウント (Microsoft Entra ID を通して管理されるアカウント) に関連付けられます。

サブスクリプションには既定のサービスのクォータと制限があります。 これらの制限の完全な一覧については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。 これらの制限は、管理ポータルでのサポート リクエストの申し込みによって、最大値まで増やすことができまです。

関連項目

リソース管理

Azure における "リソース" という用語は、すべてのコンピューティング インスタンス、ストレージ オブジェクト、ネットワーク デバイス、プラットフォームで作成または構成できるその他のエンティティを意味します。

Azure リソースは、次の 2 つのモデルのいずれかを使用してデプロイ、管理されます。Azure Resource Manager または従来の Azure クラシック デプロイ モデル。 すべての新しいリソースは、Resource Manager モデルを使用して作成されます。

リソース グループ

Azure にはさらに、VM、ストレージ、仮想ネットワーク デバイスなどのリソースを整理する "リソース グループ" と呼ばれるエンティティがあります。 Azure リソースは、常に 1 つのリソース グループに関連付けられています。 あるリソース グループ内に作成されたリソースを別のグループに移動できますが、リソースは一度に 1 つのリソース グループ内にのみ存在できます。 詳細について、「リソース グループ、サブスクリプションまたはリージョン間で Azure リソースを移動する」をご覧ください。 リソース グループは、Azure Resource Manager によって使用される基本グループです。

リソースは、タグを使用して整理することもできます。 タグは、サブスクリプションのリソースを、リソース グループのメンバーシップに関係なくグループ化できるようにするキーと値のペアです。

管理インターフェイス

Azure では、さまざまな方法でリソースを管理できます。

  • Web インターフェイス。 Azure portal は、Azure リソース用の完全な Web ベースの管理インターフェイスを提供します。
  • REST API。 Azure Resource Manager REST API は、Azure ポータルで使用できる機能の大半に、プログラムによってアクセスできるようにします。
  • コマンド ライン。 Azure CLI は、Azure リソースを作成して管理できるコマンド ライン インターフェイスを提供します。 Azure CLI は Windows、Linux、および macOS で使用できます。
  • PowerShell。 PowerShell 用の Azure モジュールによって、スクリプトを使用した自動管理タスクを実行できます。 PowerShell は Windows、Linux、および macOS で使用できます。
  • テンプレート。 Azure Resource Manager テンプレートは、JSON テンプレート ベースのリソース管理機能を提供します。
  • SDK。 SDK は、ユーザーが Azure サービスをプログラムで管理および操作できるようにするライブラリのコレクションです。

どのインターフェイスでも、Azure でリソースの作成、デプロイ、または変更を行うための中心はリソース グループです。

さらに、多数のサード パーティ製の管理ツール (Hashicorp の Terraform や Netflix Spinnaker など) を Azure でも使用できます。

関連項目

リージョンと Availability Zones

障害が及ぼす影響の範囲はさまざまです。 たとえば、ディスク障害などの一部のハードウェア障害が、1 台のホスト コンピューターに影響を及ぼすことがあります。 障害が発生したネットワーク スイッチが、サーバー ラック全体に影響する場合もあります。 データセンターの停電など、データセンター全体を中断させる障害はまれです。 まれに、リージョン全体が使用できなくなる場合があります。

アプリケーションの回復性を実現するための 1 つの手段として、冗長性があります。 ただし、この冗長性は、アプリケーションの設計時に計画しなければなりません。 また、必要な冗長性のレベルは、ビジネス要件によって異なります。 リージョンの障害から保護するために、すべてのアプリケーションがリージョン間で冗長性を必要とするわけではありません。 一般的に、冗長性と信頼性を高めると、コストと複雑さが増すというトレードオフがあります。

Google Cloud では、リージョンに 2 つ以上の可用性ゾーンがあります。 可用性ゾーンは、地理的地域内に物理的に分離されたデータ センターに対応します。 Azure には、可用性セット、可用性ゾーン、ペアのリージョンなど、潜在的なあらゆる障害レベルでアプリケーションの冗長性を提供する多数の機能があります。

各オプションを以下の表に示します。

可用性セット 可用性ゾーン ペアのリージョン
障害の範囲 ラック データセンター リージョン
要求のルーティング Load Balancer クロスゾーン ロード バランサー Traffic Manager
ネットワーク待ち時間 非常に低い 低 中～高
仮想ネットワーク VNet VNet リージョン間 VNet ピアリング

可用性セット

ディスクやネットワーク スイッチの障害など、ローカライズされたハードウェアの障害から保護するには、可用性セットに 2 つ以上の VM をデプロイします。 可用性セットは、電源とネットワーク スイッチを共有する 2 つ以上の "障害ドメイン" で構成されます。 可用性セットの VM は複数の障害ドメインに分散されるため、ある障害ドメインがハードウェア障害の影響を受けた場合は、ネットワーク トラフィックを他の障害ドメインの VM にルーティングできます。 可用性セットの詳細については、「Azure での Windows 仮想マシンの可用性の管理」を参照してください。

VM インスタンスが可用性セットに追加されると、それらには更新ドメインも割り当てられます。 更新ドメインは、計画済みメンテナンス イベントが同時に設定される VM グループです。 複数の更新ドメインに VM を分散させることで、予定された更新と修正イベントが特定の時点でこれらの VM のサブセットのみに作用することが保証されます。

アプリケーション内のインスタンスのロール別に可用性セットを編成して、各ロールで 1 つのインスタンスが操作可能であることを保証する必要があります。 たとえば、3 層構造の Web アプリケーションでは、フロント エンド層、アプリケーション層、およびデータ層に個別の可用性セットを作成します。

Web インスタンスを持つ Web 層の可用性セット、アプリ インスタンスを持つアプリ層、およびデータベース インスタンスを持つデータ クラスターを含む図。

可用性セット

可用性ゾーン

Google Cloud と同様に、Azure リージョンは可用性ゾーンを持つことができます。 可用性ゾーンとは、Azure リージョン内の物理的に独立したゾーンのことです。 可用性ゾーンはそれぞれ異なる電源、ネットワーク、および冷却装置を持ちます。 可用性ゾーンに VM をデプロイすると、データセンター全体の障害からアプリケーションを保護するのに役立ちます。

3 つのゾーンすべてをまたぐサブネットを持つ 3 つのゾーンを含むリージョンを使用したゾーン冗長仮想マシンのデプロイを示す図。

Azure でのゾーン冗長 VM のデプロイ

詳細については、「可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。

ペアになっているリージョン

リージョンの障害からアプリケーションを保護するために、複数のリージョンにアプリケーションをデプロイし、Azure Traffic Manager を使用してインターネット トラフィックを異なるリージョンに分散できます。 各 Azure リージョンは別のリージョンとペアになります。 これがリージョン ペアになります。 ブラジル南部を除き、リージョン ペアは、税および法の執行を目的としたデータ常駐要件を満たすために同じ地理的場所に配置されます。

可用性ゾーン (物理的に独立しているが、比較的近接する地理的地域に配置されている場合があるデータセンター) とは異なり、ペアになっているリージョンは、通常は少なくとも 300 マイル離れています。 この設計により、大規模な災害が、ペアになっているリージョンのうちの 1 つにのみ影響することが保証されます。 近接するペアにデータベースとステージ サービスのデータを同期するように設定して、プラットフォームの更新プログラムが、ペアになっているリージョンの片方にのみ同時にロールアウトされるように構成できます。

Azure の geo 冗長ストレージは、適切なペアになっているリージョンに自動的にバックアップされます。 他のすべてのリソースでは、ペアになっているリージョンを使用した完全に冗長なソリューションの作成は、両方のリージョンにソリューションの完全なコピーを作成することを意味します。

図は Azure のリージョンのペアを示しています。ここで、地域にはリージョンのペアが含まれており、2 つのリージョンが含まれています。それぞれにデータセンターが含まれています。

Azure のリージョン ペア

関連項目

サービス

プラットフォーム間でのサービスの対応関係の一覧については、Google Cloud サービスと Azure サービスの比較を参照してください。

すべての Azure 製品とサービスがすべてのリージョンで使用できるわけではありません。 リージョン別の製品に関するページを参照してください。 Azure の各製品またはサービスのアップタイム保証とダウンタイム クレジット ポリシーについては、「サービス レベル アグリーメント」ページで確認できます。

次のステップ