Google Cloud Associate Cloud Engineer試験で学んで驚いたこと

今年の12月から来年2月までCCNP、Google Cloud、AWS6個と資格試験更新祭りなので忙しくてアドベントカレンダーに参加できませんでした。
過去に書いた記事を元にQiitaさんからアドベントカレンダーのスポンサー企業さんの商品を使った記事を書いてくれませんか？みたいなお誘いのメールも来ていたので参加したかったのですが、CCNPの更新試験に一度落ちて完全に追い込まれてしまい、全然余裕がありませんでした。
CCPNは更新期限日に受験した2回目で合格できたので何とか失効せずに済みました。
その後Google Cloud Associate Cloud Engineer試験の更新試験を受けて合格し、少し自信を取り戻せたのでこんな時期になってしまいましたが記事を書きます。
Google Cloud Associate Cloud Engineerの更新試験の勉強で知って驚いたことを早速検証しつつ記事にします。

Google CloudのVPCって、リージョン跨ぎで構成できるって知ってました？

早速結論なんですが、Google CloudのVPC、Azureで言うところの仮想ネットワーク、AWSは同じくVPCと表現するGoogle Cloud上のプライベートアドレス設定ができるネットワークなんですが、なんとリージョン跨ぎで構成できます。
ビックリですよね？
AzureをベースにAWSの技術も習得した私には、AWSのVPCがAvailability Zoneごとにサブネットを構成しなくてはならないことも驚きでしたが、Google CloudのVPCは更にその驚きを超えてきました。

え？どういうこと？

いや、ホントにそうなんですよ。
Google Cloudガチ勢の皆様は周知の事実なんでしょうけど、Azure、AWS勢にしてみたら驚天動地ですよ。

とりあえず構成図にしてみた。

Azure、AWS、Google CloudとそれぞれでVPC、仮想ネットワークとリージョン、サブネットの関係性を構成図にしてみました。

まずはAzure

赤の点線がリージョンです。
リソースグループと仮想ネットワークは別リージョンでもOKなんですが、今回便宜上同じリージョンにしました。
リソースグループまで別リージョンで構成う描いてしまうとめっちゃわかりづらくなりますからね。

次にAWS

こちらもVPCがリージョンの中にすっぽりと収まる構成ですね。

そしてGoogle Cloud

無駄に文字の色にこだわってみました。

構成図も独特ですね。
黒板に色つきのチョークで手書きしたっぽい風合いです。
分かりやすいのか分かりくいのかわかりませんが、ちょっとオシャレっぽいんでしょうか？
これ、私が勝手にやってるんじゃなくて公式がこんな感じなんですよ。
https://cloud.google.com/blog/ja/products/application-development/13-popular-application-architectures-for-google-cloud

ね？

とまぁ描かれ方に関してはおいといて、構成図としては、VPCの中にリージョンがすっぽりと収まっている、AzureやAWSとは主従(というか包含関係という表現の方が適切？)が逆転しています。

ホンマにそんな構成できるん？

ですよね。
やってみましょう。

Google Cloudのアカウントを作成したら、次にプロジェクトを作成

はい。
Azureでいうとサブスクリプション、AWSでいうとAWSアカウントですね。
請求単位に関連付く枠組みをGoogle Cloudではプロジェクトと表現します。

ちなみに画像にある組織ってのがAWSでいうとAWS Organization、Azureだと管理グループですね。

プロジェクト作成したら作成したいリソースのAPIを有効化する

プロジェクトが作成されるとこんな感じです。

なんもわかんないですね。
今回はVPCなんですが、VPCを作成しようとするとGoogle Cloud Engine(GCE)のAPIを有効化しないといけません。
左上の三本線をクリックしてCompute Engineをクリックします。

Compute EngineのAPIを有効化する画面が出てくるので、有効にするをクリックします。

有効化にするをクリックすると、有効化にするのボタンと赤枠内の画面右上の鈴のボタンが同時にくるくる回り出します。

あれ？
UIが変わってる・・・
以前作ったときはこんなUIじゃなかった・・・はず・・・
まぁクラウドあるあるなんで捨ておきましょう。

VPCの作成

画面左上の三本線をクリックするとメニューが開くので、[VPCネットワーク]を選択してその中にある[VPCネットワーク]をクリックします。

画面の上の方にある[VPCネットワークを作成]をクリックします。

VPCの名前は適当に命名して、サブネット作成モードを[カスタム]にしました。
ちゃんと見てないですがたぶん[自動]を選んでしまうと暗黙的にデフォルトとか推奨とかの構成で作成されちゃうんでしょうね。
この[自動]がどんなサブネットを構成してくれるのか興味はありますが、時間がガンガン溶けていくのでいったん[カスタム]で作成しましょう。

サブネットの作成

ん？

な、なんやてー！？

はい。
毎度集中線が煩いので外しました。
赤枠の通りGoogle Cloudはサブネット単位でリージョン分けられます！

凄い！
Google Cloud！
始まってますね！

VPCにリージョンを内包してると何が凄いの？

はい。
そうですよね。
そういう疑問、わいちゃいますよね。
お客様のGoogle Cloud上で構築するシステムの性質次第ですが、複数リージョンに跨ったVPCが必要、でもDBや監査ログなんかはメインで利用しているリージョン、監査部がいるリージョンに集約したいよ、っていう要件が出てきた場合、AzureだとVnet Peering、AWSだとVPC Peeringが必要でしたが、Google Cloudだと不要です。
ネットワークアドレッシングの節約にもなりますし、なによりもネットワーク構成が単純になります。

そうなんや。じゃあVPCにリージョンを内包していることによるデメリットは無いの？

あります。
結局リージョン間通信は発生するので、ユーザーは気にしないところでリージョン間通信が発生してしまう、ということですね。
VPCや仮想ネットワークが違うとアドレッシングが違う、アドレッシングと拠点番号なんかが関連付いている場合、またアドレスとホスト名が関連付いているお客様だとリージョンをホスト名から意識しやすいんですが、この前提が崩れてしまいますね。
まぁホスト名の命名規則にIPアドレスを関連付けず、直接リージョン名の一部やリージョンに番号を振ってその番号を付与すれば済む話なんですけどね。
今オンプレミスにある規約をGoogle Cloud用に変更するのはちょっと面倒かな・・・という程度です。

今日はここまで。