Google Cloud 基礎コース

terraform実行に使うサービスアカウントのkeyを本業ではkeyファイル発行して踏み台サーバーに置いて実行する運用となっていました… これだとローカルで編集→PR作成→マージ後踏み台でpullして反映、というフローだったのですが結構大変でした… impersonate_service_accountを使うことでセキュアかつ運用コストも大幅に削減されるので、今非運用中でも使えるように整備しているところです！

どこがGoogle管理で何がユーザ管理のネットワークなのかなど曖昧だったのですが、DirectEgressやfirewallのチャプターでかなり解像度があがりました！

たとえばCloud RunはVPC外に存在し、Cloud SQLはGoogle管理のVPCに存在する。そのためCloud RunとCloud SQLは同じネットワーク空間にはいないこと。なのでユーザ管理VPCのサブネットを作って、Egressの仕組みでプライベートIPを送信元IPに割り当て、Google CloudのVPCに繋げるようにしないといけないこと。

firewallの暗黙のデフォルトルールや、サービスアカウントに対して適用できるところあたりも、これまでなんとなく理解していた部分が整理され、「なぜその設定が必要なのか」を説明できるレベルまで落とし込めたのは大きな収穫でした！

「slack_metrics DB に workspace のデータを投入して動作確認を行う」課題では、DNS がうまく解決できずかなり苦戦しました。しかし、原因を一つずつ切り分けていく過程で、ネットワークや DNS 周りの理解を深められた点は非常に良かったと感じています。
最終的な原因が Route53 のメール認証未実施による clientHold 状態という、Google Cloud とは直接関係ない部分だったのも含めて、実務に近いトラブルシューティングの経験になりました。

現在、簡易的なデータ分析環境について AWS から GCP への移管およびエンハンスを内製で進めており（部内で初の内製開発の取り組み）、その中で本コースで学んだ内容がそのまま活きています。先行リリースいただいたことで、実務に直結する知識をタイムリーに吸収できた点は非常にありがたかったです。

社内に Google Cloud の有識者がほとんどおらず、特に BigQuery の権限設計や DWH 設計、Vertex AI 周りについては手探りの状態ではありますが、本コースで学んだ Google Cloud の根本的な思想を軸に、外部のユースケースも参考にしながら形にしていきたいと考えています！

特にネットワーク周りはその最たるもので、
・Cloud Run がグローバルなネットワークに存在していること
・Cloud SQL は Google 管理の VPC にあること
・Cloud Run から Cloud SQL へは Direct VPC Egress を使って接続していること
このあたり、知識としては知っていたものの、なぜそうなっているのか／どういう構造なのか を自分の言葉で説明できない状態でした。

今回の基礎コースを通して、これらの構成や考え方をちゃんと言語化できるようになったのが一番大きな収穫です。ずっと頭の片隅にあったモヤモヤが、かなりスッキリしました。

また、個人的に少し苦手意識があったのがファイアウォールルール周りです。AWS のセキュリティグループとは考え方や設計の仕方が違うので、「なんとなく分かったつもり」で避けてきた部分でもありました。

ですが今回、どういう単位で・どういう意図で設計するものなのか が腹落ちして、「なるほど、そういう思想なのね」というところまで理解できた感覚があります。これはかなり大きいです。

Google Cloud 自体は、Google MAP API や AI Studio 以外のサービスは触ったことはなくて、ネットワーク設計が AWS と違うんだくらいの知識しかありませんでしたが、基本は AWS の時に学んだ各サービスの前提知識の応用でキャッチアップ自体はできるなという印象でした。

AWSとのネットワークの設計の思想の違いに関して、VPC がグローバルなリソースだったり、ロードバランサーがグローバルレベルでの負荷分散が可能だったりと、ネットワークの設計思想が AWS と大きく異なる印象でした。

ロードバランサーがグローバル負荷分散が可能というのを最初に課題で見た時に、コンプライアンス要件とかにありがちな「リソースは日本国内に全部配置してください」みたいな要件とか、どうすんだみたいなことを思ったりしましたが、リージョナルで選択肢がちゃんとあって、やっぱ考えられてるなーと思いました。

Cloud Run すごい。ECS で slack-metrics を動かすときに VPC を作って、セキュリティグループ作って、ECR に Dockerfile push して、ECS サービス作ってと色々やったのが、Cloud Run だと、圧倒的に楽に動かせたのは驚きでした。常時起動ゼロでも動く上に、Lambda よりも重い処理を動かせるのは非常に強力なアドバンテージになり得るので、インフラを Google Cloud に閉じた設計にしない場合でも、活躍する機会は多そうな印象でした。

リソースの操作権限やアクセス制御周りの仕組みに関して、Google アカウントでログインした状態で、権限委譲を行いサービスアカウントになりすましてリソース操作を行う仕組みや、Identity-Aware Proxy（IAP）によって、「Google アカウントにログインしている社員だけアクセス可能」といった制御をアプリケーションレイヤーの前段で実現できる仕組みは、Google が提供しているパブリッククラウドならではの強みだよなーと感じました。

実際に基礎コースを終えてみて、GCP と AWS の設計思想の違いは興味深いなぁ…と思ったし、要件や務める会社さん次第では GCP もしっかり使えるようになっておきたいというモチベーションがかなり高くなりました。

この週末の 3 日間で終えることができたが、短期間とは思えないくらい濃いインプットができたと感じており、脳疲労がすごい（今はリラックスしながら書いています）。

今回、GCLB やネットワークファイアウォールの概念の理解がかなり難しいところだったと思うけど、丁寧な解説と適切な粒度の課題によって、そこまで苦労することなくインプットすることができ、今まで以上にありがたいなと感じました。

Cloud SQL Studio、AWS にはない機能だし、個人的にはとてもありがたいなぁ、と思えた（TablePlus でアクセスできるとはいえ、ドキマギしたくなるので）。

AWS と違って、同じ Google アカウントで別タブで別プロジェクトを開いても元のプロジェクトには影響しないところは使いやすい反面、cp-main-stg で誤操作しそうになってしまったので、（あまりないと思うが）業務の時は気をつけたいと思った。

各チャプターの前半にある AWS との比較解説のおかげで、頭の中を整理しながら内容を理解できた点が特に印象的でした。

特にサービスアカウントの解説がわかりやすかったです。

また、自分が今どのリソースを扱っているのかを示す図解が分かりやすく、全体像を掴みやすかったです。