第148回

Google Cloudコンソールの基本｜権限設計とコスト管理の勘所

Google Cloudの利用を検討し始めた企業が、最初に触れる画面がGoogle Cloudコンソールです。ブラウザだけでサーバーもデータベースも作れる手軽さは魅力ですが、その手軽さが、後の権限とコストの課題につながることもあります。

本記事では、コンソールでできることを一通り押さえたうえで、企業として最初に決めておくべきプロジェクトの構成、権限の与え方、そして請求の見える化までを整理します。個人の学習用途ではなく、組織で運用することを前提とした内容です。

Google Cloudコンソールとは

仮想マシンの作成、データベースの構築、ネットワークの設計、権限の付与、請求の確認まで、すべてがこの一画面から行えます。専用のソフトをインストールする必要はなく、対応ブラウザとGoogleアカウントさえあれば操作を始められます。

ここで、社内でよく起きる混同を先に解いておきます。Google Workspaceの管理コンソールとGoogle Cloudコンソールは、名前は似ていますが別の画面です。

両者は同じGoogleアカウントでログインできるため、混同したまま話が進むことがあります。社内で議論するときは、どちらの画面の話かを最初に確認してください。

Google Cloudコンソールへログインする際の前提

個人のGmailアカウントでも利用を開始できます。学習や検証にはそれで十分でしょう。ただし業務で使うのであれば、会社のドメインで管理されたアカウントが適しています。個人アカウントで作られた環境は、担当者の退職時に引き継ぎが難しくなります。

なお、無料試用の枠や無料枠が用意されているサービスもあります。検証を始めるハードルは低いのですが、無料枠を超えると課金が始まる点は押さえておきましょう。

Google Cloudでは「プロジェクト」が運用を左右する

階層は上から順に、組織、フォルダ、プロジェクト、そして個々のリソースという構造になっています。組織を頂点に据えることで、全社共通のポリシーを上位で定め、下位へ継承させられます。企業利用では、この階層を前提に設計するのが一般的です。

では、プロジェクトはどの単位で切るべきでしょうか。実務でよく採られるのは、システムごとに分け、さらに開発、検証、本番の環境ごとに分ける方法です。分けておけば、開発環境での操作ミスが本番へ波及しません。請求も環境ごとに把握できます。

逆に、ひとつのプロジェクトへ何もかも詰め込む構成は、初期は楽ですが、後からの見直しに手間がかかります。プロジェクトの分割は、後から直すより最初に決めておくほうが負担を抑えられます。

プロジェクトの命名規則を決める

プロジェクトには識別子が必要で、これは全世界で一意である必要があります。思いつきで付けると、数十個に増えた段階で一覧から目的のものを探しにくくなります。

実用的な構成は、会社を表す短い文字列、システム名、環境の区分をつなげる形です。並べ替えたときに同じシステムの環境が隣り合うため、視認性が上がります。識別子は後から変更できないため、最初のプロジェクトを作る前に規則を決めておきましょう。

加えて、ラベルという仕組みも活用できます。プロジェクトやリソースに対して、部門名や用途、費用の負担先といった情報を付与しておくと、請求のレポートでその単位ごとに費用を集計できます。後から付け直すこともできますが、数が増えてからでは手間がかかります。

組織ポリシーで枠を先に決める

階層の上位に組織を置く利点は、権限の継承だけではありません。組織ポリシーという仕組みを使えば、下位のプロジェクト全体に対して禁止事項を強制できます。

たとえば、リソースを作成できる地域を国内に限定する、外部への公開設定を禁止する、サービスアカウントの鍵ファイル作成を禁止する、といった制約です。個々の担当者の注意に頼らず、そもそもできない状態を作れます。

制約を厳しくしすぎると開発の妨げになるため、最初は影響の大きいものだけを設定するとよいでしょう。データの保存場所と、外部公開の可否。この二つを押さえておくことで、重大な事故の多くは防げます。

Google Cloudコンソールでできる主な操作

画面上部にはダッシュボードをカスタマイズする機能もあり、よく見る指標だけを並べておけます。日常的に確認する項目が定まってきたら、早めに整えておくと確認の手間が減ります。

IAMによる権限設計を最初に固める

IAMでは、利用者やサービスアカウントに対してロールを割り当てます。ロールには広い権限をまとめた基本ロール、用途ごとに絞られた事前定義ロール、そして自分で作るカスタムロールがあります。

検証段階では基本ロールのオーナーや編集者が手軽です。ただし本番環境で同じ与え方を続けると、必要のない削除権限まで全員が持つ状態になります。事前定義ロールから、その担当者の業務に必要なものだけを選ぶ運用へ切り替えておきたいところです。

• ・個人へ直接付与するのではなく、Googleグループへ付与してメンバーを入れ替える形にする
• ・アプリケーションが使うサービスアカウントには、必要最小限のロールだけを与える
• ・サービスアカウントの鍵ファイルは発行を避け、可能な限り鍵を持たない認証方式を選ぶ

一つ目の工夫は特に効果が大きく、人事異動のたびに権限を付け替える作業が不要になります。グループへの所属を変えるだけで、権限も自動的に追随するためです。

請求とコストをGoogle Cloudコンソールで見える化する

コンソールのお支払いの画面では、請求先アカウントごとの使用状況をレポートで確認できます。サービス別、プロジェクト別、期間別に分解できるため、どこで費用が増えたのかを追跡できます。

重要なのは予算とアラートの設定です。月あたりの予算額を定め、一定の割合に達した時点でメール通知を受け取る仕組みを作っておきます。設定自体は数分で終わります。これを行わないまま検証を進め、後から請求額に驚くという例も見られます。

より踏み込んだ分析を行うなら、請求データをBigQueryへ書き出す方法があります。サテライトオフィスでは、BigQueryとLooker Studioを組み合わせた分析ソリューションを提供しており、同社からGoogle Workspaceを購入している企業には無償で提供されます。詳しくはサテライトオフィスのBigQuery／Looker Studio分析ソリューションの詳細はこちらをご確認ください。

Google Cloudコンソールの操作を記録として残す

Google Cloudには監査ログの仕組みがあり、誰がいつどの操作を行ったかが記録されます。設定を変更した、リソースを削除した、権限を付与したといった操作が対象です。既定で記録されるものと、明示的に有効化が必要なものがあるため、必要な範囲を確認しておきましょう。

ログは残すだけでなく、確認する仕組みまで用意して初めて機能します。重要な操作については、通知を設定しておくとよいでしょう。本番環境のリソースが削除されたときに管理者へ通知が届く構成にしておけば、事故の発見が早くなります。

二つ目のデータアクセスに関する記録は、量が多くなりがちで保管費用も増えます。全プロジェクトで有効にするのではなく、機密性の高いデータを扱うプロジェクトに絞って設定するのが現実的です。

Google Cloudコンソール以外の操作手段と使い分け

Google Cloudコンソールには、行った操作に相当するコマンドやリクエストを表示する機能が備わっています。画面で設定を組み立て、生成されたコマンドを控えておけば、同じ構成を別の環境で再現する際の手戻りが減ります。学習の手段としても有効です。

ブラウザ上で動くターミナルであるCloud Shellを使えば、環境構築なしにコマンド操作を始められます。手元のパソコンに何もインストールせずに済むため、複数人が同じ条件で作業できる利点もあります。

最初からすべてをコード化する必要はありません。画面で作って動作を理解し、繰り返す作業からコマンドへ移していく順序が現実的でしょう。

Google Cloudコンソールの料金はどう決まるのか

つまり、画面を開いて眺めているだけなら費用は発生しません。仮想マシンを起動した時間、保存したデータの量、通信した量に応じて課金されます。多くのサービスには無料枠が設定されており、たとえばBigQueryでは毎月10GBのストレージと1TBのクエリ処理までが無料です。小規模な検証であれば費用がかからない場合もあります。

見落とされがちなのが、停止し忘れたリソースです。検証で作った仮想マシンを消し忘れる、使わなくなったデータを保管し続ける。こうした積み重ねが請求額に反映されます。プロジェクトを分けておけば、不要になった環境をまとめて削除できるという利点もここで効いてきます。

費用を抑えるために実務で効く工夫

従量課金の環境で費用を抑える方法は、値引き交渉ではなく使い方の設計にあります。効果の大きい順に挙げると、次のようになります。

• ・検証環境の仮想マシンを、業務時間外に自動で停止する仕組みを入れる
• ・保管しているデータのうち、参照頻度の低いものを低コストの保管区分へ移す
• ・分析用のデータは、読み取る範囲が絞られるよう分割して保存する
• ・長期的に稼働が確定しているリソースは、割引の適用される契約形態を検討する

一つ目は導入が簡単なわりに効果が大きく、夜間と休日に停止するだけで検証環境の費用は半分以下になることもあります。使っていない時間にも課金が続いている点は、請求書を見るまで気づきにくい部分です。

三つ目は分析基盤を運用する場合に効いてきます。日付などで分割して保存しておくと、集計時に読み取るデータ量が減り、そのまま費用の削減につながります。設計の段階で意識しておきたい点です。

コンソールの設計を固めてGoogle Cloudの運用を軌道に乗せましょう

この三つは、リソースが増えてから見直そうとすると、移行作業や業務の停止を伴います。最初のプロジェクトを作る前に方針を決めておくことで、後の運用負担を抑えられます。

サテライトオフィスは、Google Cloudの導入支援から伴走型の運用支援までを提供しています。コアエンジニアチームによる技術支援体制を持ち、日本円での請求書払いにも対応いたします。設計方針の相談から、既存環境の整理まで幅広くご相談いただけます。

Google Cloudの利用開始や、既存環境の見直しをご検討でしたら、サテライトオフィスにお気軽にご相談ください。自社の体制に合った進め方をご提案いたします。

サテライトオフィスのGoogle Cloud導入支援の詳細はこちら

※プライバシーポリシはこちら