私が Google Cloud の ID と環境設計を熱愛する 9 つの理由

※この投稿は米国時間 2021 年 10 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

私は Google Cloud に来てまだ数週間ですが、その前は長年 AWS Hero で別のクラウドの構築に携わっていました。なので、先週の Google Cloud Next は初体験で、ちょっとしたカルチャー ショックでした。私がそのとき目の当たりにしたのは、Google Cloud がどのように構築されているかについて惜しみなく情報を提供する、その考え抜かれた包括的なアプローチです。GCP ポッドキャストでは、それを「intentionality（意図的に行われていること）」という言葉で言い表しました。しかも、Google Distributed Cloud のような大々的な新発表のときだけではなく、普段からこのアプローチであるということも驚きでした。

IAM やプロジェクト設定においてもそうです。クラウド プロジェクトの最初のステップといえば、環境アクセスのプロビジョニングですが、Google Cloud に来る前は、このステップはイライラのしどおしでした。面倒なこと、古臭いものとお付き合いしなければならなかったからです。たとえば、

• 自作の中途半端な SSO ツールと構成ファイル

• 一元化された ID がなかったので、クラウド アカウントごとに別人扱いされる

• コンソールで、謎のログアウト、リダイレクトが発生したり、プロジェクト コンテキストが消失したりする

• 後から付け足されたアカウントの管理機能（最初から正しい方法で設計されていなかった）

つい最近 Twitter のスレッドで、Google Cloud の ID と環境がどれだけきっちりしているかについて投稿しました。これは、前の職場での経験とは対照的です。Google Cloud で今一番お気に入りのこの点について、この投稿で理由を詳しくお話ししたいと思います。クラウドへのアクセスや管理の改善策を模索していて、このブログにたどり着いた方は、今日はラッキーデーです。このウェブコミックのとおり、毎日 10,000 人限定の初耳学の受講者になれたのですから！

私が Google Cloud の ID と環境設計を愛する 9 つの理由

1. あなたは、あなたです

すべてのユーザーは、プロジェクトをまたいで通用する 1 つの Google アカウント（個人用、または法人用アカウント）で表されます。クラウドにまだ馴染みのない方は、これだけでも理解のハードルが下がって、知っていることの延長のように感じられるのではないでしょうか。エキスパートの方にとっては、関連性のないたくさんの ID を使い分けする負担が減らせることを意味します。どんな Google アカウントでも（組織外の協力者も！）、共同編集者としてクラウド プロジェクトに入れることができるのは、とてもいいと思います。

2. 非 IAM root アカウントは立ち入り禁止

Google Cloud はゼロから設計されています。これは、ID 管理インフラストラクチャのどこにも属さない、手動構成のスーパーユーザーがなければクラウドを構築できないといった矛盾を避けるためです。Google の世界では、人間は Google アカウントを使用し、サービスは IAM ベースのサービス アカウントを使用します。とてもシンプルですね（Google 以外のサービスも IAM を使用できます。そう、Workload Identity 連携です！）。  

3. 人を意識したプロジェクト検出

コンソールに組み込まれているプロジェクト、フォルダ、組織の検出を実行する際には、ファイル システムを閲覧するときと同じようにアクセスレベルに合わせてスコープが適用されます。これは機能と呼べないくらいさりげないものですが、実は非常に重要なのです。一度経験したら、それぞれの環境が互いの関係を知らずに存在する、あの世界にはもう戻れません。

また、階層組織モデルからは、環境ごと、アプリケーションごとにプロジェクトを 1 つというベスト プラクティスが最も楽な道であることがわかります。私は、論理グループを分けすぎていたようです。プロジェクトとフォルダと遊んでいると時間を忘れます。

4. あなたを守る請求書

プロジェクト コンテキストは、その中に含まれるリソースのコストを示す論理コンテナです。私が気に入っているのは、請求エンティティがプロジェクト自体とは別に管理されていることです。したがって、プロジェクトを削除すると、関連リソースもすべて消えて、料金も発生しないことを確信できます。また、将来本格的にリリースするかもしれないプロジェクトに備えて支払い能力を温存しておくことができます。

（ちなみに、無料枠では、基本的に「はい、どうぞ私に課金してください」と書かれた大きなボタンをクリックするまでは、料金が発生することはありません。クラウドを学び、探求するための安全な場所を探している初心者に私が Google Cloud をすすめる主な理由は、この安心感と Google アカウントのアクセスへのなじみの良さです）

5. 組織の構造 != 請求の構造

6. とにかく役に立つ SSO

CLI の使用をお望みですか？Google アカウントは、SSO がすぐに使えます。企業の組織図は要りません。構成ファイルやアクセスキーを手動で変更する必要もありません。さらに言えば、Cloud Shell を使ってブラウザ上で、そしてGoogle Cloud のドキュメント内でも（これは特に大事！）gcloud コマンドを実行できます。（豆知識: Cloud Shell は、AWS、Azure、Google Cloud で同じ名前を持つ唯一のネイティブ クラウド サービスだと思いますが、Google のバージョンが最も長く利用されており、私が知る限り、最も機能が充実しています。）

7. グループですべてを制御

ユーザー エンティティは、Google ではアカウントにすぎないと言ったことを覚えていますか？なんと、Google グループを使って、IAM ロールへのグループ アクセスを管理できるのです。そうです。ドキュメント、メール、クラウドにまたがる権限を持ったユーザーの集まりです。Google Workspace を Google Cloud の中心に据えるのが理にかなっている理由のひとつは、このようにグループを使用できることです。ID 管理の観点から見ると、1 つのクラウド サービスのように機能しているのです。

8. 居場所を確保しよう

他のクラウドでは、私が Timeout of Doom と呼んでいる問題が発生することがあります。コンソール セッションが期限切れになると見慣れたエラー画面が表示されるだけで、助けてくれません。だから、最初に使用したアカウントを思い出して、ゼロからコンテキストを作成し直す方法を考えなくてはいけません。Google Cloud Console へのアクセスが単一の URL をブックマークするのと同じくらい簡単であることに気付いたときの私の喜びを想像してみてください。 console.cloud.google.com は、あなたが誰であるかを覚えてくれています（少なくとも、あなたがどのような人であるかをサジェストしてくれます）。謎のログアウトやリダイレクトは発生しません。

9. 進化する複雑さ

私の経験では、クラウド プロバイダは、アカウント機能のほとんどをデベロッパーではなく企業向けに設計しているのが一般的です。もしあなたが独立系デベロッパーであれば、請求書におびえたり、便利な SSO 機能を利用できなかったりと、あなたの味方とは言えない世界でやっていかなければなりません。

Google Cloud は他企業と連携する道も見つけましたが、デベロッパーお気に入りのクラウドとしてのルーツは忘れていません。個人の Google アカウントでログインして作業を続け、準備ができたら組織にリンクすればよいのです。個人アカウントでも、通りに面した巨大なショップと同じように SSO や請求書への配慮もしてもらえます。

転職してからスムーズに仕事に入っていけました、と言うつもりはありません。たびたび（Google Workspace インテグレーションでプロジェクトを作成するたびに？）墓穴を掘っていますし、まだ学ぶことはたくさんあります。でも、それは Google Cloud で「意図的に行われていること」をまだ知らないからです。Google Cloud の ID と環境について言えば、統合されたというより、そのように設計されていたのではと感じます。クラウドはエレガントかつシンプルで、新たな興奮を覚えます。さあ、次はどんなワクワクに出会えるでしょう。

無料トライアルでご自身の目で確かめてみることをおすすめします。そして、あなたのお気に入りの Google Cloud の ID や環境の機能を、Twitter で教えてください。

- コンテンツ部門リーダー、Forrest Brazeal