細かすぎて伝わらない:Azureユーザから見たAzureとGCPの違い
この記事は Google Cloud Platform Advent Calendar 2020 の 22 日目の記事です。
私は昨年まで3年以上、どっぷりと Azure の世界でアプリケーション開発を行っていましたが、転職に伴って主に GCP を使うようになりました。その中で、Azure と GCP では、同じパブリッククラウドなので似ているところもありつつ、最初使うときには少し戸惑うような細かな違いを感じることもありました。
違いと言っても、サービスとして大きく特徴があるところ(例:.NET Framework アプリをマネージドサービスで動かすなら Azure が強い、データ分析なら BigQuery を中心として GCP が強い、等)はすでに山のように情報が存在していてググればすぐ見つかると思うので、本記事では現場で実際に手を動かす人が気になる(かもしれない)めちゃくちゃ細かい部分 にフォーカスしてつらつらと書き残しておきます。
今 Azure をメインで使っていてこれから GCP も挑戦してみたい、という奇特な(?)方にとっては少しは参考になるかもしれません。
基本用語の対応
まず最初に前提知識として、Azure、GCP それぞれで利用する基本的な用語をまとめておきます。 細かい機能性などでもちろん違いはありますが、ざっくりとした概念としては、以下のような対応関係となっています。
概念 | Azure | GCP |
---|---|---|
Web の管理画面 | Azure Portal | Cloud Console |
リソースをまとめる単位 | リソースグループ | プロジェクト |
会社などのドメインに紐づく単位 | (Azure AD) テナント | 組織 |
ではさっそく1つ目に行きましょう。
1. サービスを利用するには API の有効化が必要
まず GCP を使い始めて最初に私が違和感を感じたのは、GCP では、新しくプロジェクトを作成したあとデフォルト状態では、すべてのサービス(の API)が利用不可(=無効)の状態になっている、という点です。デフォルトですべて無効になっているので、言い換えると、GCP では何かのサービスをはじめて使う際には CLI や Cloud Console の画面から、そのサービスの API を有効化する操作を行う必要があります。
ただし、有効化の作業といってもそんな大層な話ではなく、実作業としては CLI ならコマンドを一つ叩く、あるいは Cloud Console からなら「有効にする」というボタンをポチッと押すぐらいの話なので、一旦慣れれば特に違和感は感じなくなるとは思います。
人によっては少し面倒と思う気もしますが、このように明示的に Opt-in しないと利用できない仕様になっているのは、 不正利用や誤課金を避けるため
ということのようです。*1
2. リソース階層と課金管理の考え方の違い
どちらのクラウドでも、リソースを階層化して管理するための仕組みを持っています。
具体的には、Azure では、最上位に Azure AD テナント
があり、その下に 管理グループ(なくても良い)
-> サブスクリプション
-> リソースグループ
-> リソース(VM 等)
、という階層になっています。
一方 GCP では、最上位に 組織
があり、その下に フォルダ(なくても良い)
-> プロジェクト
-> リソース(VM 等)
という階層となっています。見比べていただくと、階層の構造自体はおおむね似たような形式で管理できることがわかると思います。
ただ一点異なっているのが、利用した費用の請求情報をどうやって紐づけるのか、という点です。 まず Azure では、サブスクリプションが請求先情報を含むような考え方になっています。サブスクリプションの作成時にクレジットカード等の支払い情報を指定し、それが密接不可分なものとして扱われるイメージです。*2
一方で GCP では、請求情報(請求先アカウント)は独立したエンティティとして扱われていて、それを適宜各プロジェクトに紐づけていく仕組みになっています。一度請求先アカウントに紐付けたプロジェクトも、紐付けを解除したり、別の請求先アカウントに変更したりすることが簡単に行えるようになっています。ただし、もちろん紐付けを解除して、請求情報が紐付かなくなってしまったプロジェクトでは、課金処理が行えないため、リソースの作成などは行うことができなくなります。
この違いも、一概にどちらの考え方が良いというものではなく、GCP のように請求情報を分離して管理できることにメリットを感じる人もいれば、一方で GCP ではプロジェクトに必ず請求先アカウントが紐付いていることが保証されないため、それが不便だと感じる人もいるかもしれないなという印象です。
3. Web 管理画面の違い
次に、Azure と GCP の Web 管理画面についてです。これも両者おおむね似てはいるんですが、細かい部分で操作感に違いがあるので、初めての人は戸惑うことがあると思います。
3.1 操作する (リソースグループ|プロジェクト) の指定方法
Web 管理画面から、何らかの操作や設定変更を行うことはよくあると思いますが、その際の操作範囲の指定方法が違います。 具体的には、GCP では、画面のヘッダにあるプルダウンっぽい項目で今何が選択されているか、が超重要になっています。
このプルダウンをクリックすると、前述した 組織 -> フォルダ -> プロジェクト
という階層構造の中から、それらのうちいずれか一つを選択する画面が開くのですが、GCP ではここで最初に操作範囲を指定した上で、何らかの操作や設定変更を行っていくことになります。
Azure では、変更を行う範囲は随時自分でメニューからたどっていくようなイメージなので、最初に必ず明示的に操作範囲を指定する、という GCP の考え方は個人的には結構違和感がありました。
少しわかりづらいので一例として、あるプロジェクト X
(Azure の場合リソースグループ X
)の権限を A さんに付与したい、というケースを想定してみます。
Azure では、Azure Portal の画面上でこれまでどのような作業を行っていたかはあまり意識することなく、左メニューなどからリソースグループ X
を探して開き、IAM のメニューから A さんを探して、ロールを指定して付与、という流れになります。
一方 GCP では、まず最初にヘッダにあるプルダウンから、プロジェクト X
を選択する必要があります。
プロジェクト X
を選択した上で、左メニューから IAM の画面を開くと、プロジェクト X
についての IAM 画面が開くことになります。あとは Azure と同じ流れで、「追加」画面から A さんと付与するロールを指定して、権限を付与、という流れになります。
というわけで、GCP の Cloud Console を使う際は、ヘッダのプルダウンをまずチェック、というのは覚えておくと良いと思います。
3.2 リソースの見え方
Azure の場合、各サービスで作成したインスタンスやサービス(App Service Plan, SQL Database...等)は基本的にすべて「リソース」として抽象化されているので、あるリソースグループに含まれるリソースも、Azure Portal 上で簡単に確認することができます。
一方 GCP の場合、各プロジェクト内にどのようなサービスのリソースが存在しているかを一覧化するような画面は現時点では提供されていません。Asset Inventory API という機能で、CLI から一覧化を行うことは可能 なので、必要な場合はそちらを利用することになりますが、この点に関して言えば、Azure の方がお手軽ではあります。
おわりに
以上、「実際使っている人なら当たり前にわかっているけど、意外と最初は戸惑うかもしれない」という観点で、Azure と GCP の細かい違いについて書いてみました。 今回はあまり時間がなくて思いつくままにいくつかだけ挙げてみましたが、実際に複数のクラウドを運用することになると、そういった細かい部分が意外とストレスになる気もするので、時間ができたらもう少しどこかに網羅的にまとめておきたいなと思います。