この記事は、Google Cloud の専門家がMicrosoft Azureアカウント、サービス、リソースの基本を理解するのに役立ちます。 Google Cloud と Azure プラットフォームの主要な類似点と相違点についても取り上げます。
注
Google Cloud は、以前は Google Cloud Platform (GCP) と呼ばれていました。
この記事では、次の内容について解説します:
- アカウントとリソースが Azure でどのように構成されているか。
- 利用可能なソリューションが Azure でどのように構造化されているか。
- 主要な Azure サービスが Google Cloud サービスとどのように異なっているか。
Azureと Google Cloud は、時間の経過と同時に独自に機能を構築しているため、実装と設計に大きな違いがあります。
Azureと Google Cloud の類似点
Google Cloud と同じように、Microsoft Azure も、コンピューティング、ストレージ、データベース、およびネットワーク サービスを中心に構築されています。 多くの場合、どちらのプラットフォームも同等の機能を提供し、Linux または Windows ホストで高可用性ソリューションをサポートします。 Linux とオープンソース ソフトウェアを使用した開発に慣れている場合は、両方のプラットフォームでジョブを実行できます。
プラットフォームは同様の機能を共有しますが、それらの機能を提供するリソースは、多くの場合、異なる方法で編成されます。 サービス間の直接マッピングは必ずしも明確ではなく、一部のサービスは 1 つのプラットフォームでのみ使用できます。
アカウントとサブスクリプションを管理する
Azureは、リソースを効果的に管理するのに役立つ管理グループ、サブスクリプション、およびリソース グループの階層を提供します。 この階層は、Google Cloud のリソースのフォルダーとプロジェクト構造に似ています。 次の図は、Azureの管理スコープの階層を示しています。
ツリー図は、4 レベルのAzure管理階層を示しています。 上部には、企業の IT というラベルが付いた 1 つの管理グループがあります。 企業 IT のすぐ下に、3 つの子管理グループが左から右に分岐します。運用、開発、QA です。 接続線は、企業の IT レベルで定義されたポリシーとアクセス制御が、3 つのすべてによって継承されることを示します。 運用管理グループの下には、ミッション クリティカル、保護されたデータ、その他の運用という 3 つのサブスクリプションが左から右に配置されます。 開発管理グループの下には、非運用環境というラベルが付いた 1 つのサブスクリプションがあります。 QA 管理グループの下には、ステージングというラベルが付いた 1 つのサブスクリプションがあります。 一番下のレベルでは、リソース グループにはアプリケーション リソースが含まれます。
管理グループ: これらのグループは、複数のサブスクリプションのアクセス、ポリシー、コンプライアンスを管理するのに役立つコンテナーです。 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。
サブスクリプション：サブスクリプションは、ユーザー アカウントと、それらのユーザー アカウントが作成するリソースを論理的に関連付けます。 各サブスクリプションには、作成して使用できるリソースの数に制限またはクォータがあります。 組織はサブスクリプションを使用して、コストと、ユーザー、チーム、またはプロジェクトが作成するリソースを管理できます。
Azure サブスクリプションの数に制限なく作成できます。 各サブスクリプションは、1 つのMicrosoft Entra テナント (Google Cloud 用語のアカウント) にリンクします。 テナントには無制限の数のサブスクリプションを含めることができますが、Google Cloud にはアカウントごとに異なる既定のソフト制限があり、要求を通じて増やすことができます。
Google Cloud プロジェクト は、課金、クォータ、制限に関して、概念的には Azure サブスクリプションに似ています。 ただし、機能上、Google Cloud プロジェクトは、クラウド リソースがデプロイされる論理コンテナーである Azure リソース グループによく似ています。
リソース グループ:リソース グループは、Web アプリ、データベース、ストレージ アカウントなどのAzureリソースをデプロイおよび管理する論理コンテナーです。
リソース： リソースは、仮想マシン (VM)、ストレージ、SQL データベースなど、作成するサービスのインスタンスです。
Azureには、さまざまなサイズとニーズの組織に合わせて、いくつかの購入オプションが用意されています。 詳細については、 価格の概要を参照してください。
Azure リソースへのアクセスは、100 を超える組み込みロールを含むロールベースのアクセス制御 (Azure RBAC) Azure使用して管理します。 独自のカスタム ロールを作成することもできます。
各サブスクリプションには、サブスクリプションの所有者と、サブスクリプションで使用されるリソースに対して課金されるアカウントを表すアカウント管理者もいます。 アカウント管理者は、サブスクリプションの所有権を譲渡することによってのみ変更できます。
サブスクリプション レベルの下で、特定のリソースにユーザー ロールと個々のアクセス許可を割り当てることができます。 Azure では、すべてのユーザー アカウントは、Microsoft アカウントまたは組織アカウント (Microsoft Entra ID を通して管理されるアカウント) に関連付けられます。
サブスクリプションには既定のサービスのクォータと制限があります。 これらの制限の完全な一覧については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。 管理ポータルでサポート 要求を提出することで、これらの制限の一部を増やすことができます。
アカウントとサブスクリプションの管理の詳細については、次のリソースを参照してください。
リソース管理
Azureでは、リソースは、プラットフォーム内で作成または構成できる任意のコンピューティング インスタンス、ストレージ オブジェクト、ネットワーク デバイス、またはその他のエンティティです。
Azure Resource Managerを使用して、Azure リソースをデプロイおよび管理できます。
リソース グループ
Azureには、VM、ストレージ、仮想ネットワーク デバイスなどのリソースを整理するリソース グループも用意されています。 常に、Azure リソースを 1 つのリソース グループに関連付けます。 あるリソース グループから別のリソース グループにリソースを移動できますが、一度に含めることができるリソース グループは 1 つだけです。 詳細については、「 Azure リソースを新しいリソース グループまたはサブスクリプションに移動する」を参照してください。 Azure Resource Managerでは、基本的なグループ化としてリソース グループが使用されます。
タグを使用してリソースを整理することもできます。 タグは、リソース グループ メンバーシップに関係なく、サブスクリプション全体でリソースをグループ化するために使用できるキーと値のペアです。
管理インターフェイス
Azure では、さまざまな方法でリソースを管理できます。
- Azure ポータル: Azure ポータルには、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 テンプレートは、テンプレートベースのリソース管理機能を提供します。 これらのテンプレートは、通常、Bicepまたは Terraform で記述されます。
- Azure SDK: SDK は、Azure サービスをプログラムで管理および操作するために使用できるライブラリのコレクションです。
これらすべてのインターフェイスで、リソース グループは、Azure リソースの作成、デプロイ、および管理の中心となります。
さらに、HashiCorp の Terraform や Spinnaker など、多くのMicrosoft以外の管理ツールがAzureで利用できます。
リージョンと可用性ゾーン
クラウド障害の範囲と重大度は大きく異なります。 ローカライズされたハードウェア障害または構成の問題は、ワークロード内の個々のリソースまたはリソース のグループに影響を与える可能性があります。 データセンターの停電など、データセンター全体を中断させる障害はまれです。 まれに、リージョン全体が使用できなくなる場合があります。
アプリケーションの回復性を実現するための 1 つの手段として、冗長性があります。 ただし、この冗長性は、アプリケーションの設計時に計画しなければなりません。 また、必要な冗長性のレベルは、ビジネス要件によって異なります。 リージョンの障害から保護するために、すべてのアプリケーションがリージョン間で冗長性を必要とするわけではありません。 一般的に、冗長性と信頼性を高めると、コストと複雑さが増すというトレードオフがあります。
Google Cloud では、リージョンに 2 つ以上の可用性ゾーンがあります。 可用性ゾーンは、地理的リージョン内の物理的に分離されたデータセンターに対応します。 Azureには、可用性ゾーン、、ペアリージョンなど、潜在的な障害のすべてのレベルでアプリケーションの冗長性を提供するための多数の機能があります。
各オプションを以下の表に示します。
| 可用性ゾーン | ペアのリージョン | |
|---|---|---|
| 障害の範囲 | データセンター | リージョン |
| 要求のルーティング | クロスゾーン Azure Load Balancer | Azure Traffic Manager |
| ネットワーク待ち時間 | 低 | 中～高 |
| 仮想ネットワーク | 仮想ネットワーク | リージョン間の仮想ネットワーク ピアリング |
可用性ゾーン
Google Cloud と同様に、Azure リージョンには可用性ゾーンを設定できます。可用性ゾーンは、Azure リージョン内で物理的に分離されています。 各可用性ゾーンには、個別の電源、ネットワーク、および冷却があります。 可用性ゾーン間に VM をデプロイすると、データセンター全体の障害からアプリケーションを保護するのに役立ちます。
単一のAzure リージョン内でのゾーン冗長仮想マシンのデプロイを示す図。 ラベル付けされた大きな外側の四角形の領域には、レイアウト全体が含まれています。 領域内では、3 つの水平四角形ゾーンが上から下に垂直に積み重ねられ、ゾーン 1、ゾーン 2、ゾーン 3 というラベルが付けられます。 各ゾーンには、1 つの仮想マシンが含まれています。 垂直の破線の四角形は、3 つのゾーンすべてに Virtual Machines をオーバーレイします。 この破線の四角形は、3 つの可用性ゾーンすべてに同時にまたがる 1 つのサブネットを表します。 ラベル サブネットは、破線の四角形の下端に表示されます。 レイアウトは、共有サブネットを介して接続された各ゾーンに仮想マシンをデプロイすると、1 つのゾーンで障害が発生した場合に冗長性が提供されることを示しています。
可用性ゾーンとリージョンの詳細については、「可用性ゾーン とリージョンの使用」を参照してください。
ペアになっているリージョン
リージョンの障害からアプリケーションを保護するには、複数のリージョンにアプリケーションをデプロイし、Azure Traffic Managerを使用してインターネット トラフィックを異なるリージョンに分散します。 各Azureリージョンは、別のリージョンとペアになっています。 これらの領域は、一緒に 領域ペアを形成します。 ブラジル南部を除き、地域ペアは、税および法執行機関の管轄区域の目的でデータ所在地の要件を満たすために、同じ地域内に配置されます。
物理的に独立したデータセンターであるが、比較的近くの地理的領域にある可能性がある可用性ゾーンとは異なり、ペアになっているリージョンは通常、少なくとも 300 マイル離れています。 この設計により、大規模な災害が、ペアになっているリージョンのうちの 1 つにのみ影響することが保証されます。 データベースとストレージ サービスのデータを同期するように、隣接するペアを設定できます。 これらは、プラットフォームの更新プログラムが一度にペアの 1 つのリージョンにのみロールアウトされるように構成されています。
Azure geo 冗長ストレージ は、対応するペア リージョンに自動的にバックアップされます。 他のすべてのリソースについて、完全な冗長性を実現するには、各リージョンにソリューションの完全なコピーをデプロイする必要があります。
Azure リージョン ペアの入れ子構造の包含階層を示す図。 最も外側の四角形は地理を表します。 地理の内側には、リージョン ペアが入れ子になっています。 リージョン ペアでは、2 つのリージョンが横に並んでいます。 各リージョン内にはデータセンターがあります。 図形の入れ子は、包含関係を示しています。データセンターはリージョン内に物理的に配置され、2 つのリージョンが一緒にリージョン ペアを形成し、1 つのリージョン ペアが 1 つの地理的な場所に属しています。
サービス別の信頼性ガイド
各Azure サービスの信頼性に関する推奨事項については、サービス別の信頼性ガイドを参照してください。
詳細については、次のリソースを参照してください。
サービス
Google Cloud サービスと同等のAzureに対応する方法については、Google Cloud と Azure サービスの比較を参照してください。
すべての Azure 製品とサービスがすべてのリージョンで使用できるわけではありません。 詳細については、「 リージョン別の製品」を参照してください。 各Azure製品またはサービスの稼働時間の保証とダウンタイムのクレジット ポリシーについては、オンライン サービスドキュメントのサービス レベル アグリーメントを参照してください。