G-gen の杉村です。Google Cloud（旧称 GCP）の IAM には、 サービスエージェント という仕組みがあります。 概要 サービスエージェントとは サービスエージェントとサービスアカウントの違い Compute Engine 概要 永続ディスクの CMEK による暗号化・復号 VM の起動・停止スケジューリング Cloud Storage 概要 Pub/Sub 通知 CMEK による暗号化・復号 Cloud Logging 概要 サービスがバックエンドで利用 ログバケットの透過的な暗号化 (CMEK) ログシンクの書き込み ID Looker Studio 概要 データソースへの認証 概要 サービスエージェントとは サービスエージェント とは、Google Cloud サービスが内部的に用いる、特別なサービスアカウントです。プロダクトの API を有効化したときなどに自動的に作成されるため、ユーザーが意識することはあまりありませんが、初期設定時や仕組みの構築の際に、サービスエージェントに対して権限の付与が必要になることがあります。 サービスエージェントは、Google Cloud サービスが別のサービスを呼び出すときなどに使用されます。 サービスエージェントは通常、プロジェクトに所属しますが、組織レベルで作成されるサービスエージェントもあります。 なおサービスエージェントは別名として「Google マネージドサービスアカウント」または「Google が管理するサービス アカウント」とも呼ばれます。 参考 : Service agents サービスエージェントとサービスアカウントの違い サービスエージェントとサービスアカウントの違いは何でしょうか。 サービスエージェントは、サービスアカウントの 一種 です。サービスアカウントの方が広い概念です。 ユーザーが作成する通常のサービスアカウントは、Google Cloud コンソール画面の「IAM と管理 ＞ サービスアカウント」で一覧表示できます。 しかし、サービスエージェントは Google Cloud が管理する特殊なサービスアカウントのため、この一覧には表示されません。 また、プロジェクトの IAM ロール一覧画面（IAM と管理 ＞ IAM）でも、普段は非表示になっています。 Google 提供のロール付与を含める というチェックボックスをオンにすると、非表示だったサービスエージェントと IAM ロールの紐づき（バインディング）が表示されます。 Google 提供のロール付与を含める 当記事では、代表的な Google Cloud サービスで、サービスエージェントがどのように用いられているかを紹介します。 Compute Engine 概要 あるプロジェクトで Compute Engine API を有効化すると、プロジェクトに以下の名称のサービスアカウントが生成されます。これが、Compute Engine のサービスエージェントです。 service-(プロジェクト番号)@compute-system.iam.gserviceaccount.com なお Compute Engine の API を有効化すると (プロジェクト番号)-compute@developer.gserviceaccount.com という名称で、Compute Engine の デフォルトサービスアカウント が生成されますが、これとサービスエージェントは 別物 です。 デフォルトサービスアカウントは VM にアタッチするものですが、サービスエージェントは後述の用途のためにサービス側が使うものです。ユーザーが意識することはほとんどありません。 このサービスエージェントには最初から Compute Engine サービス エージェント というロールがプロジェクトレベルで付与されています。このロール紐づきを削除してしまうと、Compute Engine の正常な動作は保証されません。 参考 : Compute Engine サービス エージェント Compute Engine のサービスエージェントは、内部的に様々な用途に用いられていますが、普段はユーザーに意識されることはありません。 しかし、以下の用途の際にサービスエージェントを意識することがあります。 永続ディスクの CMEK による暗号化・復号 VM の起動・停止スケジューリング 永続ディスクの CMEK による暗号化・復号 以下のスクリーンショットは、永続ディスクの暗号化方式を CMEK での暗号化にするよう選択したときのメッセージです。 CMEK 暗号化にはサービスエージェントに鍵の利用権限が必要 Compute Engine サービスエージェントに、暗号鍵に対して Cloud KMS 暗号鍵の暗号化 / 復号（ cloudkms.cryptoKeyEncrypterDecrypter ）ロールが必要なことを示しています。ユーザーに代わってサービスエージェントがディスク I/O の都度、鍵を利用して透過的な暗号化・復号を行っているのです。 ここで権限を持たせる必要があるのは、VM にアタッチしたサービスアカウント ではなく、 サービスエージェント**である点に注意が必要です。 サービスエージェントが鍵に権限を持つ VM の起動・停止スケジューリング VM の自動起動・停止のスケジュールを設定する際にも、サービスエージェントが関係します。 参考 : VM インスタンスの起動と停止をスケジュールする Compute Engine ではコンソール等から、cron 形式で VM の自動停止・起動をスケジューリングできます。 このスケジューリング機能では、Google Cloud がユーザーに代わって VM を停止あるいは起動します。このときに、サービスエージェントの IAM 権限が使われます。 サービスエージェントにインスタンス停止・起動の IAM 権限が無い場合、以下のようなエラーメッセージが表示されます。 インスタンスのスケジュールで警告 Compute Engine System service account service-(PJ-NUMBER)@compute-system.iam.gserviceaccount.com needs to have [compute.instances.start,compute.instances.stop] permissions applied in order to perform this operation. このメッセージが出た場合、サービスエージェントに、プロジェクトレベルで Compute インスタンス管理者（v1） ( roles/compute.instanceAdmin.v1 ）などのロールを付与する必要があります。 Cloud Storage 概要 Cloud Storage にもサービスエージェントが存在します。名称は以下のとおりです。 service-(プロジェクト番号)@gs-project-accounts.iam.gserviceaccount.com サービスエージェントの名称はコンソールの「Cloud Storage ＞ 設定」画面から確認したり、gcloud コマンドラインで gcloud storage service-agent --project=${PROJECT_ID} を実行することでも確認できます。 参考 : Cloud Storage サービス エージェントの取得 参考 : サービス エージェント Cloud Storage のサービスエージェントは、以下のような用途で用いられます。 Pub/Sub 通知 CMEK による暗号化・復号 Pub/Sub 通知 Cloud Storage ではオブジェクトに変更（作成・削除等）があった際に、Pub/Sub に通知することができます。 参考 : Cloud Storage の Pub/Sub 通知 この機能は、オブジェクト変更をトリガにして Cloud Functions を起動し、後処理を実装する際などに用いられます。 Cloud Run functions を Cloud Storage トリガー関数という形で実装することがありますが、バックエンドではこの Pub/Sub 通知が用いられています。以下の記事も参照ください。 blog.g-gen.co.jp Cloud Storage サービスが Pub/Sub にメッセージをパブリッシュ（通知）する際には、サービスエージェントに権限が必要です。上記の記事の Cloud Storage サービスエージェントに権限付与 の項で示しているように、権限を付与する必要があります。 CMEK による暗号化・復号 Compute Engine と同じように、Cloud Storage でも、ストレージの透過的な暗号化に顧客管理の暗号鍵（CMEK）を指定できます。 その際にサービスエージェントがユーザーに代わって鍵を使い、データを暗号化・復号します。 サービスエージェントは、秘密鍵に対して Cloud KMS 暗号鍵の暗号化 / 復号（ cloudkms.cryptoKeyEncrypterDecrypter ）ロールを持つ必要があります。 プロジェクトレベルでサービスエージェントに上記ロールを付与するか、鍵に個別にロールを付与します。 Cloud Logging 概要 Cloud Logging のサービスエージェントは複数の種類があり、それぞれ用途が異なります。 No 名称 用途 1 service-(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com サービスがバックエンドで利用 2 cmek-p(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com ログバケットの透過的な暗号化 (CMEK) 3 p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com ログシンクの書き込み ID サービスがバックエンドで利用 service-(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com にはデフォルトで、プロジェクトレベルで Cloud Logging サービス エージェント ロールが付与されています。 この IAM ロールは、BigQuery データセットの作成とリンクの権限を持っていることから、 Log Analytics 機能で用いられていることが分かります。 参考 : Cloud Logging Service Agent 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - Log Analytics ログバケットの透過的な暗号化 (CMEK) cmek-p(プロジェクト番号)@gcp-sa-logging.iam.gserviceaccount.com は、CMEK 暗号化に用いられます。Compute Engine や Cloud Storage の項で前述した内容と、ほぼ同等です。 KMS の暗号鍵に対して、このサービスエージェントが Cloud KMS 暗号鍵の暗号化 / 復号（ cloudkms.cryptoKeyEncrypterDecrypter ）ロールを持つことで、透過的な暗号化が行われます。 参考 : Logging のストレージ データを保護する鍵を管理する なお p(プロジェクト番号) の部分は、組織レベルのログバケットであれば p(組織番号) になり、フォルダレベルであれば f(フォルダ番号) となります。 ログシンクの書き込み ID p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com は、 書き込み ID と呼ばれるサービスアカウント（サービスエージェント）です。 Cloud Logging では、 ログシンク （ログルーター）を作成することで、Cloud Logging に入ってきたログを様々な宛先に振り分けて保存することが可能です。 ログシンクが書き込み可能な宛先は「Cloud Logging ログバケット」「Cloud Storage バケット」「BigQuery データセット」「Pub/Sub」などですが、ログシンクを作成する際、宛先が「そのシンクが存在するプロジェクトの Cloud Logging ログバケット以外」だった場合、シンクは 書き込み ID （Writer Identity）と呼ばれる専用のサービスアカウントを使います。 書き込み ID の名称を確認するには、Google Cloud コンソールでログシンクを選択し「シンクの詳細を表示する」を押下したり、gcloud で gcloud logging sinks describe ${SINK_NAME} を実行します。 ログシンクの書き込み ID シンクはプロジェクトに作成したり、あるいはフォルダレベル / 組織レベルで作成することができます。プロジェクトレベルで作成したシンクの書き込み ID は p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com となり、フォルダレベルなら f(フォルダ番号)-(6桁数字)@〜 、組織レベルなら o(フォルダ番号)-(6桁数字)@〜 となります。 またシンクを作成するごとに書き込み ID が別個に生成され、一意の6桁の数字が払い出されてサービスアカウント名になります。 シンク（ログルーター）については以下の記事もご参照ください。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - ログルーティングとログの保存 Looker Studio 概要 Google Cloud の無償のダッシュボードツールである Looker Studioにも、サービスエージェントが存在します。サービスエージェントの名称は以下です。 service-org-(組織番号)@gcp-sa-datastudio.iam.gserviceaccount.com サービスエージェント名は、以下の URL にアクセスすることで確認可能です。 参考 : https://datastudio.google.com/serviceAgentHelp データソースへの認証 Looker Studio のサービスエージェントは、「データソースへの認証をサービスアカウントで行う」場合に用います。 Looker Studio には多様なコネクタが用意されており、BigQuery や Cloud SQL、Cloud Storage 上の CSV などにアクセスしてデータを可視化することができます。 参考 : Looker Studio | Connect to Data Google Cloud 上のリソースをデータソースとして扱う際には、認証が必要です。Looker Studio では、データソースへの認証方法として以下を選択できます。 ダッシュボードのオーナーの Google アカウント ダッシュボードの閲覧者の Google アカウント サービスアカウント データソースへの認証にサービスアカウントを使えば、利用者にはダッシュボードの閲覧権限だけを与えるだけでよくなります。Looker Studio レポートからデータソースへのアクセスには、サービスアカウントの認証情報が使われます。 この 3. の用途の際に、サービスエージェントが関係してきます。 認証情報として使うサービスアカウントは、Google Cloud プロジェクトに作成してデータソースへのアクセス権限（BigQuery 閲覧者等）を付与しておきます。 その後 Looker Studio がこのサービスアカウントの権限を借用できるように、作成したサービスアカウントに対して、Looker Studio サービスエージェントをサービス アカウント トークン作成者（ iam.serviceAccount.getAccessToken ）ロールとして紐づけます。 図示すると以下のようになります。 Looker Studio がサービスアカウントを使う仕組み つまり、データソースへのアクセス権限自体は、ユーザーが作成したサービスアカウントが持っていますが、そのサービスアカウント権限を借用するために、サービスエージェントが使われるのです。 参考 : Looker Studio 用に Google Cloud サービス アカウントを設定する 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen ビジネス推進部の菊池です。Google Workspace のツールのひとつである Google ドキュメントの意外と知らない機能をご紹介します。 Google Docs Google ドキュメントとは ファイルの共同編集 ファイルの変更内容を確認する ファイルの変更内容を提案する 音声で入力する メールの下書き ページ分けのありなし Google ドキュメントとは Google ドキュメント (英名 Google Docs) とは、オンラインで文書の作成・編集を行うことができるツールです。 Google の提供するコラボレーションツールスイートである Google Workspace のツールの一つとして提供されています。 作成されたドキュメントはクラウドに保存されますが、ダウンロードすることも可能です。作成されたドキュメントは Microsoft Word との互換性があるほか Word のファイルも読み込み・編集できるため「Word の Google 版」とも言えるツールです。 ファイルの共同編集 ファイルの変更内容を確認する ファイルに加えられた変更内容を確認できます。特別な設定は不要で自動的に編集履歴は保存されています。 使い方は [ファイル]>[変更履歴]>[変更履歴を表示] をクリックするだけなので非常に簡単です。 画面上の変更履歴で [すべての版] を選択すると、変更した履歴が表示されます。 間違えて更新してしまった場合は [この版を復元する]>[復元] をクリックするだけで復元されます。 他にも [コピーを作成] で以前の版をコピーしたり、 [この版に名前を付ける] で複数の版を統合されないようにできます。 ファイルの変更内容を提案する 複数人で共同編集をしていると誰が何を編集したのかわからなくなってしまう事を 提案モード で回避できます。 提案モードではドキュメントの内容を直接修正せず、修正内容の提案ができます。 画面右上の鉛筆マークをクリックし [提案] を選択すると提案モードに切り替わります。 削除すると打ち消し線で表示され、追加すると上下色付きで表示されます。変更箇所は右側にリスト表示され、コメント入力も可能です。 音声で入力する 会議の議事録作成やウェビナーを受講しながらのメモなど話を聞きながらドキュメントに文字を入力する作業はよくあるシーンです。タイピングが追いつかなかったり、メモを取ることに精一杯になってしまい、なかなか話が入ってこないと、本末転倒になってしまいます。 そんなときに Google ドキュメントの 音声入力機能 を活用することで、テキスト入力を簡易化し、手間を削減することが可能です。 www.youtube.com メールの下書き スマートチップ を挿入することで日付やファイル、カレンダー、メールの下書きや会議メモなどをドキュメント内に含めることができます。 使い方は至ってシンプルで「＠」と入力することでAIが候補を表示し、リンクを作成します。 一例として メールの下書き 機能を紹介します。 youtu.be このように簡単にメールの下書きを作成することができます。 Gmail の下書き機能では下書きした内容を他のユーザーと共有することができませんが、Google ドキュメントの下書き機能を使えば、他のユーザーと共有、編集が可能になり、様々なシーンで活用できます。 例えば よくあるメールのテンプレート化 メール送信前に他のユーザーに事前確認をしてもらう 複数名でメールの作成を行う など、いままでチャットツールなどを使って実施していたような内容を Google ドキュメント内で完結することができます。 また、下書きした文章はボタンひとつで Gmail に飛ばすことが可能ですので、コピー&ペーストの煩わしさもありません。 ページ分けのありなし [ファイル]>[ページ設定] を選択すると ページ分けのあり / なし が選択できます。 ページ分けをありにしていると余白が気になったり、画像を貼り付けた際に白紙部分が大きく余ってしまうことがあります。 使い分けの一例として PDF化や紙への印刷を前提とした文書の場合はページ分けあり 電子での保存を前提とした定例会議の議事録などをページ分けなし といった方法が考えられます。 デフォルトでどちらかを選択することができますので、よく使うほうに設定しておくと良いでしょう。 菊池 勇一 (記事一覧) ビジネス推進部 2022年5月にG-gen にジョイン。 勢いとスピード感を求めて大手製造業の販売会社からGoogle Cloudの営業にキャリアチェンジ！小さい脳みそをフル回転させながら日々勉強中。

G-gen の杉村です。これまで料金の掛かっていなかった「Cloud Logging ログバケットのログ保存料金」の課金が、2023年4月1日から開始されます。(当記事は2022年11月22日に執筆され、2023年2月27日に更新されました。) 概要と経緯 課金開始が2023年4月1日からに変更 何をすればいいのか 料金の確認 概要と経緯 Cloud Logging の ログバケット は Cloud Logging のログを保管するための独自ストレージです。 これまでログバケットの保存料金は、予告はされていたものの実際に料金は発生していませんでした。 Cloud Logging の課金体型には2つの軸があります。 一つ目は「 ログの取り込み料金 」で、Cloud Logging API にログが送信された GB 数に応じて発生します。単価は $0.50/GiB (2022年11月現在) です。これは2018年7月1日より実際に課金が発生しています。 二つ目は「 ログの保管料金 」で、ログが実際に保管されたストレージの使用料金として、ログの GB 数に応じて発生する料金です。 ログを Cloud Storage や BigQuery に送信していればそちらのストレージ料金が掛かります。しかし Cloud Logging の独自ストレージであるログバケットの保管料金は「30 日を超えて保持されたログに対して $0.01/GiB」とされていたものの、課金が実際に発生するのは「2023年1月16日から」とされており、これまで実際に料金は発生していませんでした。 参考 : Cloud Logging の料金概要 以前は2023年1月16日からの課金が予告されていた 課金開始日が2023年4月1日に訂正されている 課金開始が2023年4月1日からに変更 日本時間 2022年11月21日 に Google Cloud の特定のロールを持つ Google アカウントに対し、以下の要旨のメールが送信されました。 ログバケット保存料金の課金開始は 2023年3月1日 に変更 料金は $0.01/GiB (従来の予告通り) 課金対象はログバケットに30日を超えて保存されるログ (従来の予告通り) 課金開始の日程が変更になった さらに2023年2月24日には Google Cloud から追加の連絡が送信されました。課金開始が 2023年4月1日 からに延期になった旨を伝える連絡でした。 何をすればいいのか この通知により、従来の予告より3ヶ月ほど課金開始が延長されたことになります。 ただし、いずれにせよ間もなく課金が開始されることに変わりはありません。 これまで意識していなかった課金が 2023年4月 より開始されることになるので、Google Cloud 料金の 急激な増加に注意が必要 です。 また、以下のような対策が考えられます。 ログバケットの保管期間 (Custom Retention) の見直し (不要なログは30日で破棄されるように 設定 ) 予算アラート を設定 Google Cloud 利用者部門への注意喚起 支払い関係部署等、関係各所への事前通達 料金の確認 2023年4月の課金開始に備え、自分のプロジェクトの Cloud Logging にどのくらいの課金対象ログがあるのか確認したくなるはずです。 2023年1月より Cloud Monitoring で Billable Storage メトリクスが利用可能になっています。このメトリクスでは、30日を超えて保存されている課金対象のログのボリュームの概算が確認できます。 また、それ以外にも Google Cloud コンソールの「ロギング＞ログストレージ」画面にて、プロジェクトの全ログバケットのサイズ合計や、ログバケットごとの前月使用量、今月使用量、設定してある保持期限などが確認可能です。ただしこちらで確認できるのはログバケットに保存されている ログの全量 です。課金対象である「30日以上保管してあるログ」ではない点にご留意ください。 ログバケットのログサイズの確認 なお、デフォルトで存在する _Required と言うログバケットには課金が発生しません。同じくデフォルトで存在する _Default も、保持期間が 30 日以内になっている限りは、課金が発生しません。これら以外のログバケットで保持期限が 30 日以上になっているものについて、注意が必要です。 以下の記事も参考にしてください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の藤岡です。当記事では、 Google Cloud (旧称 GCP) の Cloud DNS の DNS ピアリングを使用して、異なるプロジェクトの Cloud DNS ゾーンの名前解決をする方法について紹介します。 Cloud DNS とは 一般公開 DNS ゾーンと限定公開 DNS ゾーン 名前解決の順序 DNS ピアリング 実施内容 構成 API の有効化 限定公開ゾーンの作成 レコードセットの追加 ピアリングゾーンの作成 名前解決の確認 Cloud DNS とは Cloud DNS は、 Google Cloud (旧称 GCP) のマネージドな DNS サービスです。 ここでは、今回の構成で出てくる用語について簡単に説明します。詳細については、公式ドキュメントをご参照ください。 一般公開 DNS ゾーンと限定公開 DNS ゾーン Cloud DNS では以下のゾーンのタイプが作成可能です。 一般公開ゾーン インターネットから名前解決が 可 限定公開ゾーン インターネットから名前解決が 不可 設定した 1 つ以上の VPC ネットワークからのみ名前解決が可能 名前解決の順序 Google Cloud が持つ Virtual Private Cloud（以下 VPC） は、Google Compute Engine 等のインスタンスに名前解決サービスを提供しています。 インスタンスが、デフォルトで設定されているメタデータサーバー（ 169.254.169.254 ）をネームサーバーとして使用する場合、規定された順序に従って名前解決が行われます。 参考 : 名前解決の順序 DNS ピアリング Cloud DNS の機能の中に DNS ピアリングがあります。名前の似ているサービスとして VPC ピアリングがありますが、別サービスです。 DNS ピアリングを使用することで、別の VPC に設定されているゾーンの名前解決が可能になります。 注意点として、 DNS ピアリングは 片方向の関係 です。そのため、当ブログの後半で紹介する構成において、仮に vpc-a で限定公開ゾーンを作成し、 vpc-b でそのゾーンの名前解決ができるようにするには、追加で DNS ピアリングを設定する必要があります。 その他の制約事項等については 公式ドキュメント をご参照ください。 実施内容 構成 今回の構成は以下の通りです。 構成図 構成図に DNS コンシューマネットワーク と DNS プロデューサーネットワーク という聞き慣れない用語がありますが、ここでは詳細な説明は割愛します。DNS コンシューマネットワークは、別 VPC で作成されているゾーンの名前解決を 参照する側 で、DNS プロデューサーネットワークは 参照される側 です。 API の有効化 project-a と project-b で Cloud DNS API の有効化をします。 Cloud DNS API の有効化（project-a / project-b） 限定公開ゾーンの作成 まず、 DNS プロデューサーネットワークである project-b の Cloud DNS で限定公開ゾーンを作成します。 ゾーンの作成には、 dns.managedZones.create の権限が必要です。その他詳細なロールと権限については 公式ドキュメント をご参照ください。 Cloud DNS の画面（project-b） 以下の項目を設定します。 項目 設定値 備考 ゾーンのタイプ 非公開 今回は限定公開ゾーンのため ゾーン名 g-gen-local-zone 任意の名前 DNS 名 g-gen.local 限定公開ゾーンの DNS 名 オプション デフォルト（限定公開） ネットワーク vpc-b ゾーンを使用する VPC DNS ゾーンの作成画面（project-b） ゾーンを作成すると、自動で SOA レコードと NS レコードが作成されます。DNS 名の最後のドット（.）は自動で追加されます。 DNS ゾーンの画面（project-b） レコードセットの追加 検証用にレコードを追加します。 レコードセットを追加（project-b） 今回は、 www.g-gen.local の A レコードを追加します。IP アドレスは 1.1.1.1 とします。 レコードセットの作成画面（project-b） レコードが追加されました。 DNS ゾーンの画面（project-b） 現段階では、 vpc-a と vpc-b は DNS ピアリングをしていないため vpc-a にあるインスタンス からは www.g-gen.local の名前解決はできません。 インスタンスの名前解決画面（project-a） ピアリングゾーンの作成 次に、 project-a でピアリングゾーンを作成します。 ピアリングゾーンの作成には、ピアリング先 VPC（DNS プロデューサーネットワーク）を含むプロジェクトで roles/dns.peer のあるアカウントで作成する必要があります。その他詳細なロールと権限については 公式ドキュメント をご参照ください。 Cloud DNS の画面（project-a） 以下の項目を設定します。 項目 設定値 備考 ゾーンのタイプ 非公開 今回は限定公開ゾーンのため ゾーン名 g-gen-local-peering-zone 任意の名前 DNS 名 g-gen.local 今回は project-b で設定した g-gen.local オプション DNS ピアリング ネットワーク vpc-a ゾーンを使用する VPC ピアリングプロジェクト project-b ピアリング先のプロジェクトを選択 ピアリングネットワーク vpc-b ピアリング先の VPC DNS ゾーンの作成画面（project-a） 以下のようにピアリングゾーンが作成されます。 DNS ゾーンの画面（project-a） 名前解決の確認 DNS ピアリングの設定が完了したので、インスタンスから先程は名前解決ができなかった www.g-gen.local の名前解決の確認をします。 インスタンスの名前解決画面（project-a） 無事、今回設定した A レコードの 1.1.1.1 が返ってくるようになりました。 藤岡 里美 (記事一覧) クラウドソリューション部 接客業からエンジニアへ。2022年9月 G-gen にジョイン。Google Cloud 認定資格は全冠。2023 夏アニメのオススメは、ダークギャザリング。箏を習っています :) Follow @fujioka57621469

G-gen の杉村です。Compute Engine で起動した Linux VM に SSH ログインするにはいくつかの方法があり、それぞれネットワーク的な考慮点が異なるため、整理しました。 Compute Engine VM への SSH 接続について コンソールの SSH ボタン 概要 インターフェイス 要件 ネットワーク 認証・認可 OS ログイン機能 gcloud コマンド 概要 インターフェイス 要件 ネットワーク 認証・認可 SSH ターミナルソフトウェア 概要 インターフェイス 要件 ネットワーク 認証・認可 Identity-Aware Proxy（IAP） 概要 インターフェイス 要件 ネットワーク 認証・認可 Compute Engine VM への SSH 接続について Compute Engine で Linux インスタンスを起動した際、SSH ログインするにはいくつかの方法があります。 No タイトル インターフェイス 1 コンソールの SSH ボタン Web ブラウザ 2 gcloud コマンド PC のターミナル 3 SSH ターミナルソフト SSH ターミナルソフト 4 Identity-Aware Proxy（IAP） 上記のいずれか それぞれの方法において、ログインのために必要な IAM や VPC ファイアウォールの設定が異なります。当記事では「ネットワーク」「認証・認可」の観点で整理しました。 コンソールの SSH ボタン 概要 Google Cloud コンソールの VM 一覧から SSH ボタンを押下してログインします。 最もシンプルで簡単に Linux VM へログインする方法です。 SSH ボタン 参考 : ブラウザからの SSH インターフェイス Web ブラウザの新規ウインドウが開き、SSH ターミナルとして利用できます。 ショートカットキーの利用やファイルのアップロードやダウンロード、フォントの変更なども利用でき、多くのケースで不便を感じません。 Web ブラウザの SSH インターフェイス なおこの方法でのログインを試みた際、Identity-Aware Proxy（IAP）を利用できる条件が満たされていると、自動的に IAP 経由でアクセスされます。 要件 ネットワーク この方式でログインする際、VM から見た接続元 IP アドレスは、Google のパブリック IP アドレスになります。そのため VPC ネットワークのファイアウォールにて、22/TCP を、以下のいずれかの接続元から許可する必要があります。 0.0.0.0/0（ログインしている Google アカウントが IAP 権限を持って いない 場合) 35.235.240.0/20（ログインしている Google アカウントが IAP 権限を持って いる 場合） 基本的には、 0.0.0.0/0 から該当インスタンスへの 22/TCP を VPC ファイアウォールルールで許可する必要があります。これは、VM への SSH トラフィックが、Google のパブリック IP アドレスから発信されるためです。 しかし、Google の接続元 IP アドレスは JSON フォーマットで公開されており、これを自動的・定期的に取得してファイアウォールに反映する仕組みを構築すれば、IP アドレスの追加や変動に対応することができます。 参考 : ブラウザでの SSH 参考 : Google の IP アドレスの範囲を取得する また 35.235.240.0/20 からの接続がファイアウォールで許可されており、かつログインしている Google アカウントが、IAP で保護された トンネル ユーザー（ roles/iap.tunnelResourceAccessor ）などの IAP 利用権限を持っている場合、自動的に IAP 経由での接続となります。その場合、VM から見た接続元 IP は 35.235.240.0/20 の IP アドレス範囲になります。 認証・認可 Google Cloud コンソールへのログインに利用している Google アカウントが、該当インスタンスに対して適切な IAM 権限を持っていれば、SSH 鍵を管理することなく、Google アカウントの認証でログイン可能です。 公開鍵・秘密鍵のキーペアが自動的に作成された後、公開鍵が VM に登録され、OS ユーザーも自動的に作成されます。作成されるユーザー名は Google アカウント名の@マークの前になります。（ただし、後述の OS ログイン 機能を使う場合は、ユーザー名が異なります）。 必要な IAM 権限は以下のとおりです。 compute.instances.use 権限等（Compute インスタンス管理者 (v1)（ roles/compute.instanceAdmin.v1 ）ロールの付与が推奨） VM にサービスアカウントがアタッチされている場合は、サービスアカウントまたはプロジェクトに対する iam.serviceAccounts.actAs 権限（サービス アカウント ユーザー（ roles/iam.serviceAccountUser ）ロール等が推奨) OS ログイン機能を利用する場合は、OS ログインに必要な IAM ロール（ roles/compute.osAdminLogin または roles/compute.osLogin ） このように、多少複雑です。プロジェクトのオーナー権限があれば問題なくログインできますが、例えば、Compute 管理者（ roles/compute.admin ）ロールのみを持っている人がこの方法でログインしようとした際、 予期しないエラーにより、VM インスタンスに接続できません。数分待ってからもう一度お試しください。 等のエラーメッセージが表示されることがあります。これは、IAM 権限が不足していることを示しており、サービス アカウント ユーザー（ roles/iam.serviceAccountUser ）ロール等を付与することで解決する場合があります。 エラー時に表示される「トラブルシューティング」ボタンを押下すると、不足している IAM 権限などが示されます。 接続できませんでした OS ログイン機能 OS ログイン （OS Login）機能とは、Compute Engine VM への SSH ログイン時の認証を、Google Cloud の IAM で管理するための仕組みです。 VM のゲスト OS 上にログインユーザーを作成しなくても、適切な IAM 権限を持っていれば、VM に SSH ログインできるようになります。 詳細は、以下の記事を参照してください。 blog.g-gen.co.jp gcloud コマンド 概要 PC 等で実行する gcloud コマンド（別名 Google Cloud CLI）を使って、Compute Engine VM にログインすることができます。 コマンドラインは gcloud compute ssh ${INSTANCE_NAME} --zone=${ZONE} です。 参考 : Linux VM への接続 インターフェイス gcloud コマンドがインストール済みであれば、Mac や Windows の通常のターミナルで操作できます。 使い慣れた自分の PC のターミナルから SSH 接続することができます。 参考 : gcloud CLI をインストールする 要件 ネットワーク VM から見た接続元 IP アドレスは、操作している PC 環境のパブリック IP アドレスとなります。そのため、VPC ファイアウォールで、PC が稼働している環境のパブリック IP アドレスからの 22/TCP を許可します。 認証・認可 公開鍵・秘密鍵を用意しなくても、Google アカウントによる IAM 認証で SSH ログインすることができます。 必要な IAM 権限は、前述の「コンソールの SSH ボタン」と同様です。 VM に作成されるユーザー名は、実行環境のローカルユーザー名となります。ただし、前述の OS ログイン機能を使う場合は異なり、 <アカウント名>_<ドメイン名> になります。 例 : tom@example.com → tom_example_com SSH ターミナルソフトウェア 概要 Tera Term や PuTTY といった、使い慣れた SSH ターミナルソフトウェアから、VM へログインすることができます。 インターフェイス Tera Term、PuTTY、Linux の SSH コマンド等です。 要件 ネットワーク VM から見た接続元は、操作している PC 環境のパブリック IP アドレスとなります。VPC ファイアウォールで、この接続元からの 22/TCP を許可する必要があります。 認証・認可 IAM ではなく、SSH キーペアによる公開鍵認証となります。 VM に公開鍵を追加する方法は、以下の公式ドキュメントを参照してください。以下の方法に沿って、インスタンスメタデータに SSH 公開鍵を追加することで、手元の秘密鍵でログインすることができます。 参考 : VM に SSH 認証鍵を追加する 一度ログインできるようになった後は、通常の Linux サーバーのように home ディレクトリの authorized_keys に公開鍵を直接追加することもできます。 Identity-Aware Proxy（IAP） 概要 Identity-Aware Proxy（IAP）は、Google Cloud が提供するフルマネージドのプロキシサービスであり、SSH ログイン時に使用できます。 VM へのログインにおいては、フルマネージドの踏み台サーバがポートフォワードをしてくれるイメージを持つとよいでしょう。 IAP による SSH ログインの詳細は、以下の記事でも解説しています。 blog.g-gen.co.jp インターフェイス 当記事で紹介した「コンソールの SSH ボタン」「gcloud コマンド」「SSH ターミナルソフトウェア」 のどれかと組み合わせて利用するため、いずれかのインターフェイスを選ぶことができます。 要件 ネットワーク VM から見た接続元 IP アドレスは、IAP のパブリック IP アドレス（ 35.235.240.0/20 ）になります。VPC のファイアウォールにて、 35.235.240.0/20 からの 22/TCP を許可します。 認証・認可 Google アカウントがプロジェクトレベルで、IAP で保護されたトンネル ユーザー（ roles/iap.tunnelResourceAccessor ）ロールを付与されている必要があります。 ただし、これはあくまで IAP を使ってトンネルを確率するための権限です。ログインに使う方法（「コンソールの SSH ボタン」「gcloud コマンド」「SSH ターミナルソフトウェア」）ごとの認証・認可の条件も、併せて満たす必要があります。 IAP による SSH ログインの詳細は、以下の記事でも解説しています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。 Cloud Functions で動作する Python プログラムから Google Calendar API を呼び出す方法をご紹介します。 検証内容 プログラムの内容 Google API への認証 検証の流れ Google Calendar API 有効化 サービスアカウント作成・設定 サービスアカウント作成 サービスアカウントへ IAM 権限付与 コマンドライン ソースコードの解説 ソースコード パッケージのインポート 認証情報取得 サービスオブジェクト作成 API 呼び出し BigQuery への書き込み Python 環境の準備 Cloud Functions のデプロイ 動作確認 ローカル環境でのテスト ローカル環境での Functions のテスト サービスアカウントのキーのダウンロード functions-framework インストール 仮想 Cloud Functions 実行 リクエスト 検証内容 プログラムの内容 Cloud Functions で動作する Python プログラムから Google Calendar API を呼び出す際の認証について検証しました。 今回は単純化のため、以下のようなプログラムとしています。 Google Calendar API をコールして日本の祝日一覧を取得 取得した祝日一覧を BigQuery テーブルに INSERT 実際のユースケースでは Google Calendar から従業員の予定を取得して BigQuery に投入し、分析するなどの用途が考えられます。 Google API への認証 今回検証したかった内容は Google Calendar を始めとする、 Google API への認証です。 Google Calendar や Gmail は Google Cloud 製品ではなく Google 製品です。そのため Cloud IAM を使った認証・認可がサポートされていません。 API キーによる認証、OAuth 2.0 による認証、サービスアカウントによる認証がサポートされています。 Cloud Functions など Google Cloud 上の実行環境で動作するプログラムではサービスアカウントを用いた認証が最もセキュア・低工数であると考えられるため、この方法を検証します。 検証の流れ 検証の全体の流れは以下のとおりです。 準備 Google Cloud プロジェクトにおいて Google Calendar API を有効化 サービスアカウントを作成 サービスアカウントに BigQuery データ編集者 ログ書き込み ロールを付与 (※) Python プログラムを Cloud Functions (2nd gen) にデプロイ (Functions にはサービスアカウントをアタッチ) (※) BigQuery データ編集者 は BigQuery テーブルへのデータ書き込みため、 ログ書き込み は Cloud Logging へのログ出力のため 処理の流れ google-auth ライブラリでサービスアカウントの認証情報を取得 google-api-python-client ライブラリでサービスインスタンス生成 Google Calendar API をコールして日本の祝日一覧を取得 google-cloud-bigquery ライブラリで祝日一覧を BigQuery テーブルに INSERT 注目すべきは、サービスアカウントを作成すれば、IAM 権限を付与しなくても同じプロジェクトで有効化された Google Calendar API にアクセスできるという点です。 ここからは、各手順を説明していきます。 Google Calendar API 有効化 まずはじめに Google Cloud コンソール > API とサービス > 有効な API とサービス の画面 ( リンク ) から Google Calendar API を有効化します。 同画面では多数の API のリストが表示されますが、テキストボックスでフィルタをかけることができます。 calendar と入力するとサジェストされるはずです。 もしくは以下のコマンドでも API を有効化できます。 gcloud services enable calendar-json.googleapis.com サービスアカウント作成・設定 サービスアカウント作成 Google Cloud コンソール > IAM と管理 > サービス アカウント の画面 ( リンク ) からサービスアカウントを作成します。自分のプロジェクトが正しく選択されていることを確認してください。 サービスアカウントはプロジェクトに所属するリソースです。 Google Calendar API を有効化したのと同じプロジェクトに、サービスアカウントを作成する必要があります。 今回は表示名を get-holidays として作成します。 サービスアカウント ID は get-holidays@${PROJECT}.iam.gserviceaccount.com となります (${PROJECT} はプロジェクト ID です) 。 サービスアカウントへ IAM 権限付与 次にこのサービスアカウントに IAM 権限を付与します。 Google Calendar API をコールするには IAM 権限は必要ありませんが、今回は BigQuery にデータを書き込んだり、Cloud Logging にログ出力するために IAM 権限が必要です。 今回はプロジェクトレベルでの権限付与とします。 Google Cloud コンソール > IAM と管理 > IAM の画面 ( リンク ) に遷移します。繰り返しになりますが自分のプロジェクトが正しく選択されていることを確認してください。 先程作成したサービスアカウントに BigQuery データ編集者 ログ書き込み の IAM ロールを付与します。 コマンドライン 前述の「サービスアカウント作成」と「IAM 権限付与」の作業は以下のコマンドでも実施できます。 PROJECT = " ＜プロジェクト ID に置き換えてください＞ " ACCOUNT_NAME = " get-holidays " gcloud iam service-accounts create ${ACCOUNT_NAME} --display-name= " ${ACCOUNT_NAME} " gcloud projects add-iam-policy-binding ${PROJECT} --member= " serviceAccount: ${ACCOUNT_NAME} @ ${PROJECT} .iam.gserviceaccount.com " --role= " roles/logging.logWriter " gcloud projects add-iam-policy-binding ${PROJECT} --member= " serviceAccount: ${ACCOUNT_NAME} @ ${PROJECT} .iam.gserviceaccount.com " --role= " roles/bigquery.dataEditor " ソースコードの解説 ソースコード 以下のソースコードを使います。 今回は Cloud Functions の HTTP 関数 を想定して用意しました。 #!/usr/bin/env python import datetime import logging from flask import abort import google.auth from googleapiclient.discovery import build import google.cloud.bigquery import google.cloud.logging # ロギング設定 logging.basicConfig( format = "[%(asctime)s][%(levelname)s] %(message)s" ) logger = logging.getLogger() # Cloud Logging への連携 logging_client = google.cloud.logging.Client() logging_client.setup_logging() logger.setLevel(logging.INFO) # BigQuery Data Transfer Service のクライアント生成 client = google.cloud.bigquery.Client() def get_holidays (dataset, table, year): """ 特定年の祝日一覧の取得とテーブルへの書き込み """ logger.info(f "Getting holidays for year: {year}" ) # 実行環境のデフォルトクレデンシャル = Cloud Functions にアタッチされているサービスアカウントを取得 credentials, project = google.auth.default() # サービスを生成 service = build( 'calendar' , 'v3' , credentials=credentials, cache_discovery= False ) # Google Calendar API 呼び出し result = service.events().list( calendarId= 'japanese__ja@holiday.calendar.google.com' , timeMin= str (year) + '-01-01T00:00:00.000000Z' , timeMax= str (year) + '-12-31T23:59:59.999999Z' , singleEvents= True , orderBy= 'startTime' ).execute() holiday_info = result.get( 'items' , []) # INSERT するリスト作成 holidays = [] for holiday in holiday_info: name = holiday[ 'summary' ] date = holiday[ 'start' ][ 'date' ] holidays.append([name, date]) # スキーマ定義 schema = [ google.cloud.bigquery.SchemaField( "name" , "STRING" , "REQUIRED" , "祝日の名称" ), google.cloud.bigquery.SchemaField( "date" , "DATE" , "REQUIRED" , "祝日の日付" ) ] # テーブルの定義 table_id = f "{project}.{dataset}.{table}" table = google.cloud.bigquery.Table(table_id, schema=schema) # テーブルにINSERT client.insert_rows(table=table, rows=holidays) return None def main (request): # リクエストからパラメータを取得 request_dict = request.get_json() logger.info(request_dict) # パラメータチェック if ( 'dataset' in request_dict): dataset = request_dict[ 'dataset' ] else : error_message = "Parameter dataset is missing." logger.error(error_message) return abort( 400 ) if ( 'table' in request_dict): table = request_dict[ 'table' ] else : error_message = "Parameter table is missing." logger.error(error_message) return abort( 400 ) # メイン処理 try : # 現在の西暦を取得 this_year = datetime.date.today().year # Google Calendar から祝日を取得して BigQuery に書き込み get_holidays(dataset, table, this_year) except Exception as e: logger.error(e) return abort( 500 ) return "OK" このソースコードの認証に関わる部分をご説明します。 パッケージのインポート #!/usr/bin/env python import datetime import logging from flask import abort import google.auth from googleapiclient.discovery import build import google.cloud.bigquery import google.cloud.logging 必要なパッケージのインポートを行います。 Cloud Functions では必要なパッケージを requirements.txt に記載してデプロイパッケージに含めることで自動的に環境がビルドされます。 requirements.txt の作成を含めた Python の環境構築手順は後述します。 import google.auth と from googleapiclient.discovery import build が認証に関わるライブラリです。 認証情報取得 get_holidays 関数で Google Calendar API を呼び出しています。 # 実行環境のデフォルトクレデンシャル = Cloud Functions にアタッチされているサービスアカウントを取得 credentials, project = google.auth.default() google-auth は Google API の認証のためのライブラリです。 default() 関数により実行環境のデフォルトクレデンシャル = 今回は Cloud Functions にアタッチされているサービスアカウントの認証情報を取得します。この書き方では credentials 変数にはライブラリ独自の Credentials 型で認証情報が代入され project 変数には str 型で実行環境のデフォルトプロジェクトのプロジェクト ID が代入されます ( 参考 )。 なおかつては oauth2client と言う名称のライブラリが存在しましたがこちらは deprecated (廃止予定・非推奨) となり現在は google-auth が推奨です。 サービスオブジェクト作成 Google API Python Client の build() によりサービスオブジェクトを生成します。Google の API を呼ぶためのインターフェイスを生成するイメージです。 # サービスを生成 service = build( 'calendar' , 'v3' , credentials=credentials, cache_discovery= False ) cache_discovery=False は oauth2client のバージョン 4 以前でサポートされていた機能を無効化するための記述です。これが無いと、以下のようなログメッセージが出力されます (実動作には影響ありません) 。 file_cache is only supported with oauth2client<4.0.0 API 呼び出し # Google Calendar API 呼び出し result = service.events().list( calendarId= 'japanese__ja@holiday.calendar.google.com' , timeMin= str (year) + '-01-01T00:00:00.000000Z' , timeMax= str (year) + '-12-31T23:59:59.999999Z' , singleEvents= True , orderBy= 'startTime' ).execute() execute() で実際に API を呼び出しています。 japanese__ja@holiday.calendar.google.com は日本の祝日を保持しているカレンダーリソースで、 Google Calendar がデフォルトで持っています。 BigQuery への書き込み BigQuery Python Client の insert_rows() でテーブルにデータを INSERT します。 # INSERT するリスト作成 holidays = [] for holiday in holiday_info: name = holiday[ 'summary' ] date = holiday[ 'start' ][ 'date' ] holidays.append([name, date]) 入力する値は [ ["カラムAの値1", "カラムBの値1"], ["カラムAの値2", "カラムBの値2"], ...] のように二次元配列で渡すため、このように整形しています。 以下で実際に API を実行し、テーブルにデータを挿入します。 client.insert_rows(table=table, rows=holidays) Python 環境の準備 ソースコードの解説はここまでです。 ここからは、ローカルで Python 環境を準備する方法を説明します。 必要に応じ以下のように venv 環境を作成し activate します。 python -m venv venv source venv/bin/activate 今回のプログラムで使うパッケージをインストールし requirements.txt を作成します。 pip install google-auth google-api-python-client google-cloud-logging google-cloud-bigquery pip freeze > requirements.txt なおソースコード中で flask のモジュールを import していますが Cloud Functions の python 実行環境には Flask パッケージが予め含まれているため、明示的に pip install したり requirements.txt に含める必要はありません。 Cloud Functions のデプロイ 以下のコマンドで Cloud Functions をデプロイします。 ソースコードと requirements.txt が存在するディレクトリでコマンド実行してください。またデプロイのパラメータは適宜設定ください。 PROJECT = " ＜プロジェクト ID に置き換え＞ " ACCOUNT_NAME = " get-holidays " FUNCTION = " get-holidays " gcloud functions deploy ${FUNCTION} \ --quiet --gen2 \ --project = ${PROJECT} \ --region = asia-northeast1 \ --runtime = python39 \ --service-account = ${ACCOUNT_NAME} @ ${PROJECT} .iam.gserviceaccount.com \ --entry-point main \ --trigger-http 動作確認 デプロイが成功すると、標準出力にエンドポイント URL が表示されます。Google Cloud コンソールの Cloud Functions 画面から確認することもできますし、以下のコマンドで取得することもできます。 FUNCTION = " get-holidays " URL = `gcloud functions describe ${FUNCTION} --region=asia-northeast1 --gen2 --format= " value(serviceConfig.uri) " ` echo ${URL} 以下の curl コマンドで function の動作確認をします。 INSERT 先のデータセットとテーブルは予め作成しておき、コマンド内の文字列を置き換えてください。 curl -X POST \ -H " Authorization: bearer $( gcloud auth print-identity-token ) " \ -H " Content-Type: application/json " \ -d ' {"dataset": "＜データセット名に置き換え＞", "table": "＜テーブル名に置き換え＞"} ' \ ${URL} なお当 function は呼び出し時に IAM 認証を必要とする設定になっていますので Authorization ヘッダを付与しています。 $(gcloud auth print-identity-token) によりローカル環境に設定されている Google アカウント権限でトークンを取得しています。 実行できたら、以下のように BigQuery テーブルにデータが INSERT されたことを確認します。 BigQuery テーブルにデータが挿入された ローカル環境でのテスト ローカル環境での Functions のテスト Cloud Functions のデプロイには 2 分程度の時間がかかります。コード修正後に動作確認したいとき、いちいちデプロイしていたのでは時間がかかりすぎてしまいます。 functions-framework というライブラリを使うことで、ローカル PC 環境で Cloud Functions を動作させ、テストすることができます。 ここからは、その手順をご紹介します。 サービスアカウントのキーのダウンロード まずローカルの仮想的な Functions から実際に Google Cloud API をコールする際の認証のため、サービスアカウントのキーをダウンロードします。 Google Cloud コンソール > IAM と管理 > サービス アカウント の画面 ( リンク ) から今回作成した get-holidays サービスアカウントを選択し、詳細画面へ遷移します。 キー というタブから「鍵を追加」を押下して「新しい鍵を作成」を選択します。 JSON 形式で鍵を「作成」し、ダウンロードします。 今回はローカルのソースコードと同じディレクトリに test-cred.json として保存します。 このファイルが漏洩すると、サービスアカウントが持つ権限で好きに Google Cloud 環境を操作できてしまうことになるので、十分お気をつけください。 functions-framework インストール functions-framework を使うことでローカル環境で HTTP 関数をテストすることができます。 pip でパッケージをインストールします。手順は以下を参考にしてください。 blog.g-gen.co.jp 仮想 Cloud Functions 実行 ソースコードと同じディレクトリで以下を実行してください。 GOOGLE_APPLICATION_CREDENTIALS = " ./test-cred.json " functions-framework --target main --debug これでダウンロードしたサービスアカウントキーを実行環境のデフォルト認証情報として設定したうえで仮想的な Cloud Functions を起動できます。仮想的な Functions は 8080/tcp ポートで待ち受けします。 なお本来、ローカルの仮想 function から Google Cloud API を呼ぶだけであれば Google アカウントの権限で一度 gcloud auth application-default login ( 参考 ) を実行すればキーのダウンロードや環境変数での指定は不要です。 しかし今回は Google Calendar API の呼び出しがあり、これが上記コマンドによる認証情報の設定 (Google アカウントによるアプリケーションデフォルトクレデンシャル設定) に対応していないため、本来はできれば避けるべきですがキーのダウンロード・指定を行いました。 リクエスト 以下の curl リクエストで実際に動作させることができます。データセット名とテーブル名は実際のものに置き換えてください。 curl localhost:8080 -X POST -H " Content-Type: application/json " -d ' {"dataset": "testdataset", "table": "holidays"} ' 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud の鍵管理サービスである Cloud KMS （Cloud Key Management Service）を徹底解説します。 Cloud KMS とは Cloud KMS の料金 デフォルト暗号化と CMEK デフォルトの暗号化 顧客管理の鍵（CMEK） 透過的な暗号化 Key と Key ring Key (キー、鍵) Key とは 鍵の目的 Key のバージョン 保護レベル (ストレージ) Key ring (キーリング) リソースの削除 鍵のローテーション・バージョン・状態 ローテーション バージョン バージョンの無効化と破棄 状態 Autokey Autokey とは 仕組み 有効化 Autokey の強制 鍵の権限管理 Key ring と Key の IAM ポリシー 誰が権限を必要とするか 職掌分散 (Separation of duties) 独自の鍵と外部の鍵 鍵のインポート 外部の鍵の利用 暗号化の手法と技術 エンベロープ暗号化 アルゴリズム Cloud KMS リソースの整合性 Cloud KMS とは Cloud KMS は Google Cloud（旧称 GCP）の鍵管理サービスです。正式名称は Cloud Key Management Service ですが、KMS と略されることがほとんどです。 Google Cloud で秘密鍵を作成・保管・管理でき、鍵は各種 Google Cloud サービスのストレージを暗号化すること等に用いることができます。例として Cloud Storage バケットや、Compute Engine の永続ディスク、BigQuery のデータセットなどが暗号化の対象です。 Google Cloud サービスに保存されるデータは デフォルトで暗号化されており 、このときは Google 側で自動的に鍵が管理・ローテーションされるため、ユーザー側で意識する必要はありません。これを「デフォルトの保存データの暗号化」といいます。 参考 : デフォルトの保存データの暗号化 しかし非常に強固なセキュリティが求められる場合や、情報セキュリティ監査上の理由等において、ユーザー側で独自に鍵を管理してこれを用いて暗号化したい場合があります。このときに、暗号鍵として Cloud KMS の鍵を利用することができます。 Cloud KMS には、ユーザー側で生成した鍵をアップロードして保管することもできますし、Cloud KMS で独自の鍵を生成させることもできます。さらに Cloud HSM と呼ばれるフルマネージドの HSM（Hardware Security Module）を用いて鍵の生成・ホスティングを行わせることもできます。 参考 : Cloud Key Management Service の概要 Cloud KMS の料金 Cloud KMS の料金は KMS が保持する鍵のバージョンの数と、鍵に対するオペレーションの回数で決まります。 例としてアクティブな対称鍵のバージョン 1 個につき、月額 $0.06 です（2024年9月現在。保護レベル SOFTWARE の場合）。料金は日割りされます。 オペレーションに対しては、暗号化/復号オペレーション 10,000 回につき $0.03 です。 最新の正確な料金や計算例は以下のドキュメントをご参照ください。 参考 : Cloud Key Management Service の料金 デフォルト暗号化と CMEK デフォルトの暗号化 Cloud KMS を利用する必要があるかどうかを検討するには「デフォルトの暗号化」と「CMEK（customer-managed encryption keys）」という言葉を理解する必要があります。 まず、Google Cloud サービスのストレージは全て、 デフォルトの暗号化 という機能で暗号化されています。Compute Engine のディスクや Cloud Storage のバケット、BigQuery のデータセットなどは、我々が何も指定しなくても AES-256 方式で暗号化されています。暗号化鍵は Google によって管理・監査・ローテーションされています。 これによりデータはハードウェアの物理的な盗難や Google の内部犯によるアクセスなどから保護されます。またこれらの管理方式は第三者機関による監査を受けています。 つまり、何もしなくても Google Cloud のストレージ上のデータは高度なセキュリティにより保護されていることになります。 より詳細な情報は以下の公式ホワイトペーパーをご参照ください。 参考 : デフォルトの保存データの暗号化 顧客管理の鍵（CMEK） 一方で Google Cloud サービスの中には、データをデフォルトの暗号化ではなく、 顧客管理の鍵 （CMEK = customer-managed encryption keys）で暗号化するよう選択できるものもあります。Compute Engine の永続ディスクや Cloud Storage のバケット、BigQuery のデータセットなどは、リソース作成時にデフォルト暗号化か CMEK 暗号化を選択できるようになっています。 CMEK による暗号化を選択すると、Cloud KMS でユーザー自身が管理する鍵でデータを暗号化することができます。 ただし CMEK を選択することが、必ずしもセキュリティを高めることを意味するわけではありません。デフォルトの暗号化は第三者機関による監査を受けており、十分に安全です。CMEK を選択する必要があるのは、以下のような特殊なセキュリティ要件が存在しているときのみです。 暗号化鍵の存在する国等のロケーションが管理できる必要がある 鍵のローテーションや無効化などの管理がユーザー側で行う必要がある 独自の鍵管理システムで生成・管理する暗号鍵を使う必要がある ほとんどのケースでは上記のような厳密な鍵管理は必要ありません。かなり高度なセキュリティが求めらていたり、第三者監査の要件として上記のような厳密な制御が求められる場合に、CMEK を利用します。 透過的な暗号化 デフォルトの暗号化も CMEK（customer-managed encryption keys）による暗号化も、いずれもストレージの 透過的な暗号化 です。 透過的な暗号化では、ユーザーは暗号化を意識することはありません。ユーザーの知らないところで「勝手に暗号化されている」のが透過的な暗号化です。 例えばユーザーが暗号化された Cloud Storage バケットにオブジェクトをアップロードすると、Cloud Storage のサービス側で自動的にデータが暗号化されて格納されます。データの読み取り時も同様に、ユーザーがデータにアクセスすると Cloud Storage のサービス側で自動的にデータが復号されユーザーに渡されます。 KMS の鍵は Google Cloud リソースであるため IAM 権限を適用可能ですが、透過的な暗号化においては、ユーザーは鍵へのアクセス権を必要としません。透過的なアクセスにおいて KMS 鍵へのアクセス権限が必要なのは、サービスエージェント（Google Cloud サービスがデフォルトで持つ特殊なサービスアカウント）です。 透過的な暗号化の仕組み (Cloud Storage) このように、透過的な暗号化はユーザーには全く意識されません（これが「透過的」という言葉の意味です）。ここから、データの透過的暗号化はアクセス制御観点でのセキュリティの向上には寄与しないことが分かります。データの透過的暗号化が対処できる脅威はあくまで「 物理ストレージ機器の盗難 」「 内部犯によるストレージ機器への物理的アクセス 」等です。 Key と Key ring Key (キー、鍵) Key とは Key (キー、鍵) はその名の通り、Cloud KMS で管理される鍵そのものです。 Key は必ず Key ring (キーリング) に所属しています。Key ring は特定のロケーション (リージョン) に所属するので、Key も必然的に特定のロケーションに存在するリソースです。 鍵は無効化したり、破棄したりすることができます。 鍵の目的 Key は作成時に 目的 (Purpose) を指定します。目的は以下の 4 つから選択します。目的は一度選択すると、変更できません。 対称暗号化 (Symmetric encryption) 非対称署名 (Asymmetric signing) 非対称暗号化 (Asymmetric encryption) MAC 署名 (MAC signing) 上記のうち 1. と 4. は 対称鍵 であり、2. と 3. は 非対称鍵 (秘密鍵と公開鍵のキーペア) です。 非対称鍵では、公開鍵のみをダウンロードすることができます。一方で対称鍵は 一切ダウンロードすることはできません 。KMS の鍵は、KMS 内部でのみ保持・管理・利用されます。 Compute Engine、Cloud Storage、BigQuery などのストレージの CMEK 暗号化に使うのは 1. 対称暗号化鍵です。 対称鍵は、いわゆる共通鍵暗号化に用いられる鍵で、生成される秘密鍵が暗号化と復号の両方に使われます。 非対称鍵は公開鍵・秘密鍵のペアで暗号化・復号を行う鍵です。 公開鍵暗号化 (非対称暗号化とも) と呼ばれる手法の暗号化や、署名に用いられます。 「共通鍵暗」「公開鍵暗号」「電子署名」といったワードは Google Cloud やクラウド特有のものではなく、IT 知識として一般的なものですので、各種 Web サイトをご参照ください。 MAC 署名の鍵は HMAC 署名を行うための鍵です。HMAC は Hash Based Message Authentication Code の略でメッセージ認証符号 (MAC) の一つです。システム間メッセージの改ざん検出やなりすまり防止のために使われます。KMS の MAC 署名目的の鍵を使った署名と検証は 対称鍵を用いて 行われます。 Key のバージョン Key には複数の バージョン を持たせることができます。またバージョンの一つを プライマリのバージョン (メインのバージョンとも呼称) として指定できます。 鍵の利用時に明示的に指定しない場合、プライマリのバージョンが用いられます。ただし非対称鍵にはプライマリバージョンが無く、常にバージョンを指定する必要があります。 また鍵のバージョンは「有効」「無効」「破棄の予定」「破棄」という状態を持っており、バージョンごとに無効化したり破棄したりすることができます。 保護レベル (ストレージ) 鍵は 保護レベル という属性を持ち、これにより鍵を保存するストレージが決まります。 SOFTWARE HSM EXTERNAL EXTERNAL_VPC 最も使われるケースが多いのが SOFTWARE で、Google Cloud の強固なセキュリティの元に管理されます。 HSM はその名の通りフルマネージドの HSM (Hardware Security Module) によって管理されます。料金は SOFTWARE よりも割高です。 EXTERNAL と EXTERNAL_VPC は、KMS ではない外部の鍵管理システムで管理されている鍵を KMS を経由して利用するための保護レベルです。ユーザーの独自の鍵管理システムに KMS 経由でアクセスし、Google Cloud サービスのストレージ暗号化等に用いることができます。この仕組みを利用するために External key manager (EKM) という仕組みを利用します。 Key ring (キーリング) Key ring (キーリング) はその名の通り、鍵をグルーピングするリソースです。Key ring は特定のロケーション (リージョン) に所属します。Key は作成すると存在した時間だけ料金が発生しますが Key ring には料金が発生しません。 なお「 ロケーション (リージョン) 」と表現していますが、ロケーションとリージョンは厳密には異なります。リージョンという言葉は asia-northeast1 (東京) や asia-northeast2 (大阪) など、特定のリージョンを指します。一方でロケーションという言葉は global や asia (アジア)、us (米国) といったマルチリージョン、また各リージョンの中にあるゾーンなども含めた、より広い概念です。 Key ring は作成するロケーションを指定できますが、asia-northeast1 (東京) など特定の単一リージョンを選ぶこともできますし、global や asia (アジア) などのマルチリージョンとして作成することもできます。 そして Cloud Storage バケットや Compute Engine 永続ディスクの暗号化に使える Key は、同じロケーションに存在する必要があります。asia-northeast1 (東京) のバケットであれば Key も asia-northeast1 (東京) に存在する必要がありますし、 asia マルチリージョンのバケットは asia マルチリージョンの Key でしか暗号化できません。このため、Key ring と Key を作成するロケーションは重要です。 リソースの削除 Key や Key のバージョン、また Key ring を一度作成すると 削除はできません 。 Key ring には費用が発生しないため、実質的な問題はありません。 また Key のバージョンは「破棄」することはできます。破棄したバージョンには料金が発生しません。Key のバージョンを全て削除すれば、Key に料金はかかりません。なお「無効」「破棄の予定」の状態のバージョンには料金が発生することにご注意ください。 これらのリソースは一度作成すると一意の ID が割当てられ、それが永続的に続くとお考えください。 鍵のローテーション・バージョン・状態 ローテーション Cloud KMS では対称鍵のみ、自動ローテーションを設定できます。また、API により手動ローテーションをオンデマンド実行することも可能です。 ローテーションされると、Key の新しいバージョンが生成され、バージョン番号が 1 増えます。 自動ローテーションの頻度は Key の作成時に指定できるほか、後から変更することも可能です。自動ローテーションの頻度は 1 日～36,500 日の間で指定することが可能で、デフォルトでは 90 日です。 非対称鍵の場合は、手動ローテーションで新しい秘密鍵を作る場合、公開鍵を配布しなおす必要があります。 バージョン Key には前述の通りバージョンが存在します。Key を新規作成するとバージョンは 1 から始まり、ローテーションするごとに数字が 1 つずつ増えます。 Key のバージョンには一意の ID が割り振られます。 バージョンの無効化と破棄 Key のバージョンは個別に無効化したり、破棄したりすることができます。 重要なポイントとして あるバージョンの Key で暗号化したデータを復号できるのは、そのバージョンだけである という点を理解してください。以下に例を示します。 ある Cloud Storage バケットが、ある Key で暗号化されているとします。あるときオブジェクト A がアップロードされました。このとき Key のプライマリバージョンは 1 だったとします。オブジェクト A はバージョン 1 の Key で暗号化されることになります。 その後のある日、キーがローテーションされ、プライマリバージョンは 2 になりました。この段階ではもちろん、ユーザーは引き続きバージョン 1 で暗号化されたオブジェクト A にアクセスできます。バージョン 1 の Key が有効状態だからです。 あるとき Key のバージョン 1 を何らかの理由で無効化したとします。このときユーザーがこのオブジェクト A にアクセスしようとすると Unable to decrypt with Cloud KMS のエラーが返ります。オブジェクト A を暗号化したバージョン 1 の Key が無効化されているため、Cloud Storage がオブジェクト A を復号できなくなったからです。 状態 Key のバージョンは「有効 ( ENABLED )」「無効 ( DISABLED )」「破棄の予定 ( DESTROY_SCHEDULED )」「破棄 ( DESTROYED )」の 4 つの状態のいずれかを持ちます。 有効 ( ENABLED ) はバージョンが使用可能な状態であることを示します。 無効 ( DISABLED ) はバージョンが明示的に無効化してあり、使用不可の状態です。再度、有効状態に戻すことが可能です。 破棄の予定 ( DESTROY_SCHEDULED ) はバージョンの破棄が指示されており、指定された日時で削除される予定であることを意味します。この状態のバージョンを利用することはできません。この状態のバージョンは「復元」することができます。 この「破棄の予定」という猶予期間はデフォルトでは 24 時間です。期間は Key の作成時にのみ設定でき、あとから変更することはできません。最小は 24 時間で、最大 120 日間です。 Autokey Autokey とは Autokey は、Cloud KMS 鍵の作成、割り当て、ローテーションを自動化する仕組みです。Autokey を有効化することで、Key ring や Key などが必要になった際に、これらが自動的に生成されるようになります。 Terraform との連携も考慮されており、鍵の管理工数を低減することができます。 参考 : Autokey の概要 仕組み Autokey は、 プロジェクト単位 、または フォルダ単位 で有効化します。 ある Google Cloud プロジェクトで Autokey を有効化すると、そのプロジェクト内のリソースのデータを、自動生成した暗号鍵で暗号化できるようになります。2026年2月現在、プロジェクト単位での Autokey 有効化は Preview 段階です。 あるフォルダで Autokey を有効化すると、そのフォルダ配下の Google Cloud プロジェクトで Autokey が使用可能になります。フォルダ単位での有効の場合、暗号鍵は 鍵プロジェクト （key project）と呼ばれる、Autokey の鍵を保存する専用のプロジェクトに集約されます。 Autokey が有効になっているプロジェクトで Cloud Storage バケット、Compute Engine の永続ディスク、BigQuery テーブル、Secret Manager のシークレット、Cloud SQL インスタンス、Spanner インスタンスなど、Autokey に対応しているリソースを作成する際に、Autokey 鍵の作成をリクエストできます。 リクエストが発生すると、Autokey は自動的に、Key ring、Key、サービスアカウント、サービスアカウントへの暗号化と復号の権限付与などが行われます。リソースを作成するユーザーが、これらの作業を手動で行う必要はありません。 有効化 プロジェクト単位で Autokey を有効化するには、 autokeyConfig という API オブジェクトを作成します。2026年2月現在、プロジェクト単位での Autokey 有効化は Preview 段階であり、Web API への直接リクエストしか、有効化の方法が用意されていません。 参考 : Enable Cloud KMS Autokey - Enable Autokey for delegated key management フォルダ単位で Autokey を有効化する際は、鍵を保管するための鍵プロジェクトを Autokey 専用に作成することが推奨されます。その後、対象のフォルダで Autokey を有効化します。このとき、鍵プロジェクトを指定します。フォルダでの有効化は、Google Cloud コンソールから行うことができます。 参考 : Enable Cloud KMS Autokey - Set up Autokey for centralized key management なお、Autokey の有効化は、Terraform で記述することも可能です。 参考 : Enable Cloud KMS Autokey - Enable Autokey using Terraform Autokey の強制 Autokey を有効化したうえで、CMEK の組織ポリシー（ constraints/gcp.restrictNonCmekServices ）や使用する鍵を制限する組織ポリシー（ constraints/gcp.restrictCmekCryptoKeyProjects ）を有効化することで、Autokey の使用を強制することも可能です。 詳細な手順は以下を参照してください。 参考 : Enable Cloud KMS Autokey 鍵の権限管理 Key ring と Key の IAM ポリシー KMS の Key ring と Key には IAM ポリシーを付与でき、鍵へのアクセスを制御することができます。 IAM ポリシーの意味については 当社記事 をご参照ください。これ以降の記述は IAM ポリシーや IAM ロールの意味を理解している前提で記載いたします。特に間違いが起きやすいポイントとして Google Cloud の「IAM ポリシー」「IAM ロール」は AWS の「IAM ポリシー」「IAM ロール」とは意味が異なる点にご留意ください。 Key ring に付与した IAM 権限は配下の Key にも継承されます。ただし Key の各バージョンに個別の IAM ポリシーはありません。つまり権限管理の最小単位は Key となります。 誰が権限を必要とするか 鍵へのアクセス権限は誰が必要とするかを考えます。大まかに以下の2通りです。 鍵の管理 (作成、破棄、ローテーション、無効化、有効化等） 鍵を使った暗号化・復号 前者の「管理」は、Google Cloud の管理者やセキュリティ担当者が権限を持つべきです。 クラウド KMS 管理者 (roles/cloudkms.admin) ロールなどをプロジェクト単位、もしくは Key ring / Key 単位で持つことができます。 後者の暗号化・復号権限については、特に CMEK によるストレージ暗号化で考える場面が出てきます。CMEK によるストレージ暗号化は透過的な暗号化であるため、鍵へのアクセス権限を必要とするのは Google Cloud サービス そのものです。正確に言うと Google Cloud サービスは サービス エージェント と呼ばれる特殊なサービスアカウントを持っています。 Comute Engine や Cloud Storage ではプロジェクトに一つ、サービスエージェントがデフォルトで用意されており、他の Google Cloud サービスの API 呼び出しはこのサービスエージェントによって行われています。このサービスエージェントが裏で KMS を使った暗号化・復号、Pub/Sub への通知などを行っているのです。 例として Cloud Storage のサービスエージェントは service-${プロジェクト番号}@gs-project-accounts.iam.gserviceaccount.com という名称で、最初から存在しており、コンソール画面や gcloud コマンドで確認することができます。 Cloud Storage のサービスエージェント 作成したばかりの鍵に権限変更も加えていない状態で Cloud Storage バケットの CMEK 暗号化を設定しようとすると、コンソール画面で以下のように促されます (以下は Cloud Storage バケットの作成画面です) 。 権限追加を促される 上記はプロジェクトの Cloud Storage サービスエージェントに該当の Key に対する cloudkms.cryptoKeyEncrypterDecrypter ロールを与えるように促すメッセージです。この権限を付与することで、Cloud Storage は Key にアクセスし、暗号化・復号を行うことができます。 なお上記ではサービスエージェントによる Key の利用の例を記載しましたが、それ以外にも KMS 鍵を署名作成などの目的で明示的に利用する場合には、利用するクライアント側で Cloud KMS 暗号鍵の署名者 (roles/cloudkms.signer) などの権限が必要です。 Cloud KMS 関連の定義済みロールについては、以下のドキュメントに網羅されています。 Cloud KMS のロール 職掌分散 (Separation of duties) IT 一般のセキュリティの考え方に 最小権限の原則 と呼ばれるものがあります。個人に業務上必要となる最小の権限だけを与えることを原則とすることでリスクを低減する考え方です。 Cloud KMS でも企業や組織において鍵へのアクセス権限や管理権限を分散し最小限にすることでリスクを下げることがベストプラクティスとされており、これは 職掌分散 (Separation of duties) と呼ばれています。 この考えに基づき、大規模利用においては Cloud KMS の鍵を独自の Google Cloud プロジェクトに集約させることが推奨されています。 KMS 専用プロジェクトにはオーナー (Owner) のロールを付与しない 代わりに組織レベルの組織の管理者 (roles/resourcemanager.organizationAdmin) が鍵の権限を管理する 組織の管理者は鍵自体への利用権限を持たないが鍵の IAM ポリシーを操作する権限を持つため「管理」と「利用」を分離できる 独自の鍵と外部の鍵 鍵のインポート KMS には既存の鍵をインポートすることができます。インポートした鍵は Cloud HSM Key もしくはソフトウェア Key としてインポートされます。 インポートできる鍵には鍵の種類・目的別に要件があるため ドキュメント をご参照ください。 鍵をインポートする前に Key ring と Key を作成しておきます。インポート後の鍵は、その Key の新しいバージョンとしてインポートされます。 外部の鍵の利用 Cloud External Key Manager (Cloud EKM、外部鍵マネージャー) を用いると Cloud KMS から Fortanix や Futurex といったサードパーティ製の鍵管理システムに接続し、外部鍵管理システムの鍵を KMS 鍵のように利用することができます。 外部鍵管理システムとの接続は「インターネット経由」「 VPC 経由 」を選択することができます。 EKM で取り込んだ外部鍵は Compute Engine や Cloud Storage、BigQuery で CMEK 暗号化に利用することができます。 Cloud EKM 経由で外部鍵管理システムの鍵を利用できる 暗号化の手法と技術 エンベロープ暗号化 エンベロープ暗号化 という技術があります。これは Cloud KMS による暗号化で使われている技術であり、AWS の KMS 等でも使われています。透過的暗号化においてはユーザーの意識しないところで行われているため、知らなくても業務に支障はありません。 エンベロープ暗号化ではデータを暗号化する鍵そのもの (Data Encryption Key = DEK) とその DEK を暗号化する別の鍵 (Key Encryption Key = KEK) の二段階を用います。 都度生成する DEK でデータを暗号化し、DEK 自体は KMS で生成・管理する KEK で暗号化したうえでデータと一緒に保管します。データを利用するときは KEK で DEK を復号し、復号された DEK でデータを復号します。KEK は KMS の外に出ることはなく、セキュアに管理されます。 文字での解説には限界があるため、図による解説があるドキュメントをいくつかご紹介します。 以下は Google Cloud の公式ドキュメントです。 エンベロープ暗号化 以下は AWS Encryption SDK の公式ドキュメントです。エンベロープ暗号化について図解しています。 AWS Encryption SDK の概念 - エンベロープ暗号化 アルゴリズム 選択できる鍵の暗号化アルゴリズムは、鍵の目的によって異なります。 目的が対称暗号化 / 復号 (Symmetric encrypt/decrypt) の対称鍵の場合、 GOOGLE_SYMMETRIC_ENCRYPTION アルゴリズムが利用され、 Galois Counter Mode (GCM) / AES-256 鍵となります。 目的が非対称署名 (Asymmetric signing) の非対称鍵の場合、楕円曲線署名 / RSA 署名アルゴリズムのうち複数の中から選択することができます。また非対称鍵の目的が非対称暗号化 / 復号 (Asymmetric encrypt/decrypt) の場合も、RSA アルゴリズムの中から選択できます。 詳細は以下のドキュメントをご参照ください。 鍵の目的とアルゴリズム Cloud KMS リソースの整合性 Cloud KMS リソース (Key や Key ring) は、作成・削除・無効化などのオペレーションに対して、リソースごとに 異なる整合性 を持っています。 KMS リソースに対するオペレーションには 強整合性 と 結果整合性 の 2 種類があります。強整合性オペレーションは実行後に直ちに適用されます。結果整合性のオペレーションは通常は 1 分以内に Google Cloud 内に伝播されますが、最大で 3 時間かかるとされています。 オペレーションごとの整合性は以下のとおりです。 オペレーション名 整合性 Key ring の作成 強整合性 Key の作成 強整合性 Key のバージョンの有効化 強整合性 Key のバージョンの無効化 結果整合性 Key のプライマリ (メイン) バージョンの変更 結果整合性 IAM 権限の変更 結果整合性 (通常は数秒) 注目すべき点は、鍵バージョンの無効化や IAM アクセスの変更が結果整合性である点です。鍵を使えなくするためにバージョンを無効化しても、最大で 3 時間、鍵が使える状態になってしまう可能性があります。また IAM 権限の削除も、通常は数秒で反映されますが、1 時間程度かかる場合もあります。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen 杉村です。Google Cloud の無償 BI ツール Looker Studio の有償版である Looker Studio Pro について解説します。 概要 Looker Studio Pro とは 機能 利用開始方法 サブスクリプション 利用開始手順 注意点とトラブルシューティング Gemini in Looker 生成 AI との連携 Conversational Analytics アセット ワークスペース ワークスペースとは 自分のスペース (My workspace) チームワークスペース (Team workspace) 権限管理 概要 Looker Studio の権限管理 チームワークスペース用のロール アセット用のロール IAM 権限管理 IAM 権限と Looker Studio 権限の使い分け 退職者対応 強化されたメール配信機能 概要 Looker Studio Pro とは Looker Studio Pro は Google Cloud の無償 BI ツール Looker Studio （旧称「データポータル」または「Data Studio」) の有償版です。 Looker Studio Pro では無償版と比較してエンタープライズ向け機能が強化されており、また Google Cloud のカスタマーケア（技術サポート）の対象となります。また SLA（99.9%の可用性）の対象となるなど、組織での大規模利用に適したものとなっています。 参考 : Looker Studio Pro について なお、よく似た名称の Looker は当記事でご紹介する Looker Studio（Pro）とは別の製品です。これらの違いについては、以下の当社記事をぜひご参照ください。 blog.g-gen.co.jp Looker と Looker Studio の違い 機能 Looker Studio Pro では、無償版の Looker Studio にはない、以下のような追加の機能が利用できます。 機能名 説明 Gemini in Looker 生成 AI モデル Gemini による多数の補助機能。 ・Conversational Analytics（AI との会話を通じた分析） ・Google スライドへのエクスポート ・計算フィールドの生成など チームワークスペース ・共同編集するための箱のこと ・ここにアセット (レポートとデータソースを指す) を入れることで、ワークスペースに対する権限を持つメンバー間で共同編集できるようになる ・チームワークスペースへの閲覧権限付与も可能 管理者権限 によるアセット管理 (IAM) ・Looker Studio Pro と紐づけた Google Cloud プロジェクトに IAM 権限を付与することで、管理者が全てのチームワークスペース内のアセットを見通すことができるようになる 強化された メール配信機能 無償版より強化されたレポート配信機能。 ・即時配信 ・Google チャットや Slack への配信 ・同一レポートへの複数スケジュール作成 ・受信者に応じたフィルタなど 退職者対応 ・Looker Studio Pro を有効化していると、アセットは組織によって管理されるようになり、作成者のアカウントが削除されてもアセットは削除されない ・一方の無償版 Looker Studio ではアセットのオーナーは個人アカウントのため、退職等でアカウントが削除される前にオーナーを移行する等の作業が必要 サポート ・公式サポート (Google Cloud カスタマーケア) のサポート対象 参考 : Looker Studio Pro コンテンツについて 参考 : Looker Studio Pro のスタートガイド 利用開始方法 サブスクリプション Looker Studio Pro の利用には、ライセンス (サブスクリプション) を追加で購入する必要があります。購入方法は二種類あります。 ユーザ単位の有効化 月間アクティブユーザー（MAU）サブスクリプション 前者の「ユーザ単位の有効化」は、Looker Studio のコンソール画面から実行できます。1ユーザあたり月額 $9 の料金が発生します（2025年12月現在）。 後者の「月間アクティブユーザー（MAU）サブスクリプション」は、Google Workspace（Cloud Identity）組織全体で有効化されます。MAU（Monthly Active User。月内で1度でも Looker Studio Pro を利用した人がカウントされる）あたりの月額費用がかかります。費用や有効化の方法は、Google Cloud や販売パートナーの営業担当者にお問い合わせください。 参考 : Looker Studio pricing 参考 : Looker Studio Pro サブスクリプションの概要 なお Looker を利用中の場合、Looker のユーザーライセンス1つごとに、Looker Studio Pro ライセンスが1つ、無料で付帯します。 参考 : 無料の Looker Studio Pro ライセンス特典に関する詳細 利用開始手順 Looker Studio のコンソール画面、または Google Cloud のコンソール画面から、Looker Studio Pro を有効化できます。有効化する際に、課金対象となる Google Cloud 請求先アカウントや、紐づけ先の Google Cloud プロジェクトを選択します。これにより Looker Studio は Looker Studio Pro にアップグレードされます。 詳細な手順は、以下をご参照ください。 参考 : Pro の新しいサブスクリプションを開始する 注意点とトラブルシューティング Looker Studio と紐付ける Google Cloud プロジェクトは、ライセンス（サブスクリプション）購入時に指定した組織配下に存在している必要があります。また同プロジェクトは、購入時に指定した請求先アカウントと紐付けられている必要があります。 設定する際、操作者は以下の IAM ロールを持っている必要があります。 紐付けるプロジェクトに対するオーナー（ roles/owner ）もしくは Looker Studio Pro マネージャー（ roles/lookerstudio.proManager ）ロール 権限が足りなかったり、プロジェクトに紐付けられている請求先アカウントが申請したものと異なったりすると、ひも付け時に「組織のプロジェクトを更新できませんでした。」といったエラーが出る場合があります。 Gemini in Looker 生成 AI との連携 Looker Studio Pro では、 Gemini in Looker 機能により、データ分析や可視化、レポーティングに生成 AI を利用することができます。 機能名称は Gemini in Looker ですが、ここでの Looker は Looker ブランド全体を指しており、Looker や Looker Studio Pro に、Google が開発した生成 AI ソリューションである Gemini を組み込んだ機能群をこのように呼称しています。 Gemini in Looker には、以下のような機能があります。 Conversational Analytics（AI との会話を通してデータソースを分析・可視化） Looker Studio のコンテンツを Google スライドにエクスポート 数式フィールド（calculated fields）を自然言語の指示により作成 Conversational Analytics Gemini in Looker の Conversational Analytics （会話型分析）機能を使うと、自然言語によりデータソースへ問い合わせることができます。 例えば「今月、売上が最も大きかったエリアのトップ10を教えて」のように、普段使うような言葉で Looker Studio に質問することで、BigQuery 等のデータソースから必要な情報を見つけ出し、テキストやグラフなどで可視化してくれます。 参考 : Gemini in Looker overview 参考 : Gemini in Looker の導入により AI を活用したインテリジェントな BI が誰でも利用可能に Looker Studio Pro の会話型分析 この機能により、BigQuery や Google スプレッドシート、CSV などのデータソースに対して、SQL の知識がなくても、自然言語でクエリを投入することができます。なお、BigQuery から自然言語でデータを抽出するその他の方法については、以下の記事も参照してください。 blog.g-gen.co.jp アセット Looker Studio における アセット とは レポート と データソース を指す概念です。 レポート とは、Looker Studio で実装されるダッシュボードです。 データソース とは、レポートから参照される BigQuery 等のデータベースやスプレッドシートなど、データ保有元との接続設定を指します。一度データソースを作ると、別のレポートでもそのデータソースを再利用できます。 参考 : アセット 参考 : レポート 参考 : データソース ワークスペース ワークスペースとは ワークスペース とは、アセットを共同編集するために入れておく「箱」のような概念です。 自分のワークスペース (My workspace) と チームワークスペース の2種類があります。 自分のスペース (My workspace) 前者の「 自分のワークスペース 」は自分専用の編集スペースであり、無償版の Looker Studio で「自分がオーナー (Owned by me)」として表示されるアセットと同様です。他人から閲覧したり編集したりするには、アセット一つ一つに「閲覧者」や「編集者」ロールを付与する必要があります。またここに入っているアセットは、作成者が「オーナー」となります。 チームワークスペース (Team workspace) 後者の「 チームワークスペース 」は共同編集用の編集スペースであり、これが Looker Studio Pro の最大の特徴です。ここに入れたアセットは、チームワークスペース自体に権限を持っている人 (アカウント) であれば、共同で編集することができます。 チームワークスペースに付与できるのはどのような権限なのかは、後述します。 参考 : チーム ワークスペースについて 権限管理 概要 Looker Studio Pro の権限管理には大きく分けて2つの軸があります。一つは Looker Studio の権限管理で、もう一つは IAM の権限管理です。 以下にそれぞれを説明し、最後にそれらの使い分けについて解説します。 Looker Studio の権限管理 チームワークスペース用のロール Looker Studio 上では、チームワークスペースやアセットにそれぞれ権限を付与できます。 各チームワークスペースに付与できるロールは、以下のとおりです。なおロールの日本語名は Web コンソール画面の表記を元にしており、ドキュメント上のものと異なる場合があります。 ロール名 説明 閲覧者 ワークスペース内のアセットを閲覧（フォルダ・ゴミ箱含む） 投稿者 ワークスペース内のアセットを閲覧・編集、アセットの新規作成、アセットにロール追加など コンテンツマネージャ 投稿者の権限に加え、ワークスペースに他の投稿者を追加・削除できる マネージャー コンテンツマネージャの権限に加え、他のコンテンツマネージャを追加したり、ロール変更、アセットを他のワークスペースに移動できる等 なお従来は、チームワークスペース紐づけ可能な「閲覧専用のロール」は存在しませんでしたが、2024年4月のアップデードで「閲覧者 (Viewer)」ロールが付与可能になりました。 参考 : ロールと権限 アセット用のロール 一方で各アセットに付与できるロールは以下のとおりです。 ロール名 説明 閲覧者 閲覧のみ (レポートやデータソースのスキーマ) 編集者 編集できる。またアセットの権限を変更できる オーナー 編集者の権限に加え、アセットを削除したり、他の誰かをオーナーにできる なお「自分のワークスペース」内のアセットは、作成者が最初のオーナーになる。チームワークスペースに所属しているアセットには「オーナー」が存在しない アセットには、閲覧者または編集者ロールを付与することができます。例えばあるレポートにおいて「〇〇部署の Google グループには閲覧者ロールを付与」「レポートを管理する XX 部署のグループには編集者ロールを付与」のように権限を分けられます。 オーナーだけは特殊なロールで、アセットがマイスペースにあるときに、作成者が自動的に「オーナー」になります。 参考 : ロールと権限 IAM 権限管理 IAM 権限管理は、どちらかというと Looker Studio Pro の利用者を横断で管理するような管理者向けの権限設定に用います。 利用開始時に Looker Studio と紐づけた Google Cloud プロジェクトに、プロジェクトレベルの IAM 権限を付与することで、権限を管理します。 例として、あるアカウントに対して、データポータル管理者（ roles/datastudio.admin ）ロールを Google Cloud プロジェクトレベルで付与すると、その人は Looker Studio 内の全てのワークスペースの編集・読取、および全てのアセットの編集・読取ができるようになります。 このように、付与する IAM ロールごとに付与される権限が異なります。以下に例を示します。なお表中のロールの日本語名は Web コンソール画面の表記を元にしており、ドキュメントの記載と異なる場合があります。 ロール名(英) ロール名(日) 説明 Data Studio Admin データポータル管理者 ワークスペース・レポートに対する全権限 Data Studio Workspace Content Manager データポータル ワークスペース コンテンツ マネージャー ワークスペースに対する閲覧・アセット作成等と、アセットに対する閲覧・更新等 Data Studio Asset Editor データポータル アセット編集者 アセットに対する閲覧・更新等。ただしワークスペースの閲覧・編集権限は無し Data Studio Asset Viewer データポータル アセット閲覧者 アセットに対する閲覧。ただしワークスペースの閲覧・編集権限は無し 参考 : Looker Studio roles and permissions 参考 : Looker Studio Pro の月間アクティブ ユーザーのサブスクリプションを Google Cloud プロジェクトにリンクする IAM 権限と Looker Studio 権限の使い分け 以上のことから、Looker Studio Pro 側の権限管理と IAM (Google Cloud) 側の権限管理は、以下のような使い分けが想定されます。 Looker Studio Pro 側の権限管理 : ワークスペース単位またはアセット単位で、 編集権限や閲覧権限を管理 する IAM 権限 (Google Cloud) : 組織全体でワークスペースを管理したり統制を効かせるための、 管理者特権を管理 する 退職者対応 レポート作成者の Google アカウントが削除された場合で、かつ削除時に「データのオーナー権限を移行しない」を選択した場合、アセットは以下のような挙動となります。 作成者の「自分のワークスペース」に入っていたアセット アセットのオーナーは「削除されたユーザー」となります。Google Cloud プロジェクトへの IAM 権限を持っている人には「共有アイテム」として見えます。編集権限があれば、チームワークスペースに移動することができます。 作成者の「チームワークスペース」に入っていたアセット アセット作成者の Google アカウントが削除されても、アセットは引き続きチームワークスペースに所属します。 強化されたメール配信機能 Looker Studio Pro では、無償版と比べてメール配信機能が強化されています。 Looker Studio では定期的にレポートの内容をメールで配信することができますが、Pro では無償版と比較して以下の違いがあります。 メールの即時配信（Send now オプション） Google チャットへの配信 Slack への配信 1つのレポートの複数のスケジュールを作成 メール受信者に応じてレポートをフィルタする レポートのプレビューをメールに埋め込み 以下の公式ドキュメントも参照してください。 参考 : Schedule automatic report delivery 参考 : Share and schedule reports with Slack 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

Google Cloud (旧称 GCP) の仮想サーバーサービスである Compute Engine では Windows Server を起動することができます。 Windows Server の VM で、ライセンス認証に関するエラーが出たときの対処方法をご紹介します。 事象 考えられる原因 対処方法 1. ルートを確認する 2. アクセス要件を解決する 3. ファイアウォールルールの追加 4. ライセンス認証の強制 参考ドキュメント 事象 Compute Engine で起動する Window Server の VM において、コンピュータのプロパティの画面等でライセンス認証が失敗している旨のメッセージが出力されることがあります。 「 Windows はライセンス認証されていません 」 「 組織のライセンス認証サーバーに接続できないため、このデバイスの Windows をライセンス認証できません。組織のネットワークに接続していることを確認して、もう一度やり直してください。ライセンス認証できない場合は、組織のサポート担当者にお問い合わせください。エラーコード: 0xC004F074 」 「 ライセンス認証に問題がある場合は、トラブルシューティングを選択して問題の解決を試みてください。 」 Windows はライセンス認証されていません 考えられる原因 該当の VM と Google Cloud の持つ Windows Key Management Service (KMS) サーバーの間の通信ができていない ことが原因と考えられます。 Google Cloud の KMS サーバーは kms.windows.googlecloud.com (35.190.247.13) に存在します。このサーバーと Windows Server VM が TCP 1688 番ポートにて通信できる必要があります。 この通信が失敗する原因として VPC ファイアウォールやルートの問題、または VM が外部 IP アドレスを持っていないなどの理由が挙げられます。 参考 : kms.windows.googlecloud.com へのアクセスを構成する 対処方法 1. ルートを確認する VPC のルート設定として、デフォルトゲートウェイ (0.0.0.0/0) が Default Internet Gateway へ向いているか、個別ルールで 35.190.247.13/32 のネクストホップが Default Internet Gateway へ向いている必要があります。 2. アクセス要件を解決する VM が kms.windows.googlecloud.com (35.190.247.13) へ到達するには、以下のいずれかの方法である必要があります。 外部 IP アドレスを持っている サブネットで 限定公開の Google アクセス が有効である 重要なことに、 KMS へは Cloud NAT 経由では到達できない 仕様となっています (Compute Engine インスタンスの IP アドレス以外からのリクエストは拒否されるためと 説明されています ) 。そのため VM に外部 IP アドレスを持たせるか、サブネットで「限定公開の Google アクセス」が有効である必要があるのです。 3. ファイアウォールルールの追加 VPC のファイアウォールルールでも 35.190.247.13/32 への 1688/tcp における 下り 通信が許可されている必要があります。 デフォルトでは「暗黙の下り許可」ルールが効いているため許可されていますが、厳密なファイアウォールルールを適用している場合は、この通信を明示的・優先的に許可するルールが必要です。 4. ライセンス認証の強制 上記まで実施すれば、 KMS への通信は確保されます。上記がクリアされているのに認証が行われない場合、 VM 上で以下の作業を実施することでライセンス認証を強制させます。 コマンドプロンプトを「管理者として実行」する 下記コマンドを実行して、KMS サーバーへの接続が完了しているかをテストする powershell.exe Test-NetConnection 35.190.247.13 -Port 1688 想定結果 TcpTestSucceeded : True 上記コマンドが成功した場合、以下の下記コマンドを実行する (ライセンスの現在の状態を確認 / KMS のサーバー IP アドレスを設定 / ライセンス認証を強制) cscript \windows\system32\slmgr.vbs /dlv cscript \windows\system32\slmgr.vbs /skms 35.190.247.13:1688 cscript \windows\system32\slmgr.vbs /ato 参考ドキュメント 参考 : Windows VM のトラブルシューティング 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen ビジネス推進部の菊池です。 当社の働き方を紹介することで、みなさんの業務効率・コミュニケーション円滑化の一助になれば幸いです。 当社は社員全員が勤務地に縛られることなく、フルリモートで勤務しています。 フルリモート勤務を可能としているのが、GoogleのコラボレーションツールであるGoogle Workspaceです。 Google Workspaceを活用することにより”協業型”の働き方を実践し、フルリモートの環境下においても常に繋がりを持ちながら業務を遂行しています。 当記事ではGoogle Meetをはじめ、Google Workspaceの各種ツールを用いて当社が実践しているWeb会議の準備や進め方から議事録の共有に至るまでをご紹介します。 Web会議の準備 Web会議の進め方 Web会議終了後 Web会議の準備 Googleカレンダーをクリックし、会議の予定を入力します。 タイトルに［社内］［社外］を入力するとスケジュールの判別がしやすくなります。 「会議メモを作成」をクリックすると会議内容を反映したメモが添付されます。 ・タイトル　ex.［社内］営業会議 ・日時 ・ゲストを追加 ・会議メモを作成 なお、社外とweb会議を行う際は、以下の手順で簡単に会議用URLの送付が出来ます。 ・「会議情報をコピー」をクリック ・メール本文にコピー＆ペーストでURLを記載する 会議の準備は以上で完了です。 Web会議の進め方 先程カレンダーに添付した「会議メモ」に会議の参加者全員でリアルタイムに書き込みます。Web会議中の発言者は議事録を書くことが難しいため、発言者以外のメンバーにて共同で議事録を編集します。 Web会議終了後 Web会議終了後は作成した議事録をお知らせしたいメンバーに共有します。 例えば欠席してしまったメンバーに共有することで簡単に情報共有が可能です。 議事録を開き、「共有」ボタンをクリックし、共有したいメンバーを追加します。 Googleドキュメントにはメンション機能があり、ドキュメント内で「@ + ユーザー名」で特定のユーザーへコメントすることができます。 メンション機能を利用することで、わざわざメールやチャットなどを使って連絡する必要がなく、業務効率化とコミュニケーション円滑化に繋がります。 菊池 勇一 (記事一覧) ビジネス推進部 2022年5月にG-gen にジョイン。 勢いとスピード感を求めて大手製造業の販売会社からGoogle Cloudの営業にキャリアチェンジ！小さい脳みそをフル回転させながら日々勉強中。

G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) のサーバーレスコンテナサービスである Cloud Run について、Cloud Run サービスからインターネット接続を行う際に Public IP アドレスを固定する方法を解説します。 使用するサービス・仕組み Cloud Run サーバーレス VPC アクセス 構成図 Cloud Run サービスのデプロイ アプリケーションを作成する main.py requirements.txt Dockerfile コンテナイメージを Artifact Registry に格納する リポジトリを作成する コンテナイメージをビルドしてリポジトリに格納する ビルドしたイメージを使用して Cloud Run サービスをデプロイする インターネット接続に動的 IP アドレスが使用されることを確認する 静的 IP アドレスを使用したインターネット接続 サーバーレス VPC アクセスコネクタを作成する Cloud NAT を設定するための Cloud Router を作成する 静的 IP アドレスを使用する Cloud NAT を設定する コネクタを使用するように Cloud Run サービスを設定する インターネット接続に静的 IP アドレスが使用されることを確認する 使用するサービス・仕組み Cloud Run Cloud Run はサーバーレスな環境でコンテナを実行できるサービスです。 サービスの全体像については以下の記事で解説していますので、ご一読ください。 blog.g-gen.co.jp サーバーレス VPC アクセス サーバーレス VPC アクセス は Cloud Run や Cloud Functions などのサーバーレス実行環境から VPC 内リソースにアクセスするための仕組みです。 サーバーレス VPC アクセスを設定すると、VPC 内に コネクタ が作成され、サーバーレス実行環境からの通信を VPC にルーティングすることができます。 構成図 Cloud Run サービスでは、 コンテナからインターネット通信を行う際、動的 IP アドレスプールを使用するのがデフォルトの動作 となっています。 したがって、接続先となる外部エンドポイントで IP アドレスベースのファイアウォールが設定されているなど、静的 IP アドレスが必要となるケースでは、デフォルトの設定では上手くいきません。 そこで、サーバーレス VPC アクセスを使用して Cloud Run サービスを VPC に接続し、静的 IP アドレスを使用する Cloud NAT を経由してインターネット通信を行うように設定します。 サーバレス VPC アクセスコネクタ と Cloud NAT を経由したインターネット接続 Cloud Run サービスのデプロイ アプリケーションを作成する Cloud Run ドキュメントの クイックスタート をベースとし、アプリケーションを実行するコンテナがインターネット接続に使用した IP アドレスを確認できるようにコードを書き換えます。 IP アドレスの確認には DynDNS を使用します。 http://checkip.dyndns.com/ に対して HTTP リクエストを送信することで、現在使用している IP アドレスの情報が返ってきます。 main.py DynDNS に HTTP リクエストを送信し、レスポンスをブラウザ上に表示するようにします。 import requests from flask import Flask app = Flask(__name__) # DynDNS の URL url = 'http://checkip.dyndns.com/' @ app.route ( '/' ) def ip_check (): # HTTP リクエストを送信 res = requests.get(url) # レスポンスをブラウザ上に表示 return res.text if __name__ == '__main__' : app.run(debug= True , host= '0.0.0.0' , port= 8080 ) requirements.txt クイックスタートの requirements.txt に requests パッケージを追記します。 Flask==2.1.0 gunicorn==20.1.0 requests==2.28.1 Dockerfile クイックスタートの Dockerfile をそのまま使用します。 FROM python:3.10-slim ENV PYTHONUNBUFFERED True ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ RUN pip install --no-cache-dir -r requirements.txt CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app コンテナイメージを Artifact Registry に格納する Cloud Run サービスに使用するコンテナイメージをビルドします。 当記事では Cloud Build を使用してイメージをビルドし、Artifact Registry に格納します。 リポジトリを作成する まず、 Artifact Registry のリポジトリを作成します。 $ gcloud artifacts repositories create {リポジトリ名} --repository-format=docker --location={ロケーション} # 実行例 $ gcloud artifacts repositories create myrepository --repository-format=docker --location=asia-northeast1 コンテナイメージをビルドしてリポジトリに格納する Cloud Build を使用してコンテナイメージをビルドし、先ほど作成したリポジトリに push します。 $ gcloud builds submit --tag {ロケーション}-docker.pkg.dev/{プロジェクトID}/{リポジトリ名}/{イメージ名} # 実行例 $ gcloud builds submit --tag asia-northeast1-docker.pkg.dev/myproject/myrepository/myimage ビルドしたイメージを使用して Cloud Run サービスをデプロイする まずはコンテナイメージをそのまま Cloud Run にデプロイしていきます。 Artifact Registry に格納したコンテナイメージから Cloud Run にデプロイする を選択します。 Artifact Registry から Cloud Run サービスをデプロイ 任意の サービス名 、 リージョン を設定します。 サービス名とリージョンを設定する 今回はサービスの呼び出し元は特に考慮しないので、 Ingress 項目の「すべてのトラフィックを許可する」、 認証 項目の「未認証の呼び出しを許可」にチェックを入れ、Cloud Run サービスを作成します。 Ingress と 認証の設定 インターネット接続に動的 IP アドレスが使用されることを確認する サービスのデプロイが完了したら、サービスの詳細画面にある Cloud Run サービスの URL をクリックします。 Cloud Run サービスの URL アプリケーションが実行され、実行基盤となったコンテナがインターネット通信に使用している IP アドレスがブラウザ上に表示されます。 コンテナがインターネット接続に使用している IP アドレスが表示される その後、起動したコンテナが削除されるまでしばらく待ちます。 コンテナ インスタンス数 のメトリクスで active と idle の値が 0 になってから、もう一度サービスの URL にアクセスします。 コンテナ インスタンス数の active と idle の値が 0 になるまで待つ 先ほどとは異なるコンテナ上でアプリケーションが実行され、ブラウザには別の IP アドレスが表示されます。 このように、デフォルトの設定では、コンテナは動的 IP アドレスプールを使用してインターネット通信を行います。 コンテナが新たに起動するため、別の IP アドレスが使用される 静的 IP アドレスを使用したインターネット接続 サーバーレス VPC アクセスコネクタを作成する VPC にサーバーレス VPC アクセスコネクタを作成していきます。 VPC ネットワーク のコンソールからコネクタの作成画面に進みます。 VPC ネットワークのコンソールからコネクタを作成する ネットワーク に使用する VPC を設定し、 サブネット で「カスタム IP 範囲」を選択します。 IP 範囲 に VPC で使用されていない /28 の IP 範囲を入力し、コネクタを作成します。 サーバーレス VPC アクセス コネクタの作成 「スケーリング設定を表示」を開くと、コネクタインスタンスの最小/最大数の設定や、インスタンスが使用するマシンタイプ（f1-micro/e2-micro/e2-standard-4）を設定することができます。 最小インスタンス数は 2~9、最大インスタンス数は 3~10 の値を設定することができますが、 コネクタインスタンスが一度スケールアウトするとスケールインすることができない 仕様のため、最大インスタンス数は慎重に設定しましょう。 サーバーレスVPCアクセスコネクタのスケーリング設定 Cloud NAT を設定するための Cloud Router を作成する Cloud NAT は VPC 、リージョン、そして Cloud Router に関連付けられるため、VPC に対して Cloud Router を作成します。 ハイブリッド接続 のコンソールから Cloud Router を作成していきます。 ハイブリッド接続のコンソールから Cloud Router を作成する 名前 、 ネットワーク 、 リージョン を設定し、それ以外の項目はデフォルトのまま作成します。 Cloud Router の作成 静的 IP アドレスを使用する Cloud NAT を設定する ネットワーク サービス のコンソールから Cloud NAT を作成していきます。 ネットワーク サービスのコンソールから Cloud NAT を作成する 先ほど作成した Cloud Router を設定し、 Cloud NAT IP アドレス 項目で「手動」を選択して、「IP アドレスを作成」をクリックします。 Cloud NAT の作成 予約する静的 IP アドレスの名前を入力し、「予約」をクリックします。 静的 IP アドレスの予約 予約した静的 IP アドレスが CLoud NAT に設定されるので、「作成」をクリックします。 予約した静的 IP アドレスが設定される コネクタを使用するように Cloud Run サービスを設定する Cloud Run サービスの詳細画面から 新しいリビジョンの編集とデプロイ を選択し、サーバーレス VPC アクセス コネクタを使用するようにサービスを設定します。 Cloud Run サービスを編集する 編集画面の 接続 タブにある VPC 項目で コネクタを作成した VPC を選択し、「すべてのトラフィックを VPC コネクタ経由でルーティングする」にチェックを入れます。 サーバーレス VPC アクセス コネクタの設定 「デプロイ」を選択し、Cloud Run サービスを更新します。 インターネット接続に静的 IP アドレスが使用されることを確認する Cloud Run サービスの URL をクリックし、アプリケーションを実行します。 ここまでの設定により、コンテナ は VPC にある Cloud NAT を経由してインターネットアクセスを行うため、ブラウザに表示される IP アドレスが Cloud NAT に設定した静的 IP アドレスになっています。 Cloud NAT の静的 IP アドレスが表示される Cloud NAT の静的 IP アドレス 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。 Google Cloud（旧称 GCP）の、 タグ （Tags）と ラベル （Labels）の違いについて解説します。 タグとラベル タグとラベルの概要 利用例 タグとラベルの違い 比較表 リソースとしての扱い IAM や組織ポリシーでの利用 IAM 組織ポリシー 課金管理 課金明細への反映 課金情報の BigQuery エクスポート タグの使い方 タグキー・バリューの作成 リソースへの紐づけ フォルダ・プロジェクト 個別リソース トラブルシュート ラベルの使い方 ラベルの付与 ラベルによるフィルタ タグとラベル タグとラベルの概要 Google Cloud（旧称 GCP）には、 タグ （Tags）と ラベル （Labels）という、よく似ているもののまったく異なる概念が存在します。 参考 : タグの概要 参考 : ラベルを使用してリソースにコンテキストを追加する - 概要 タグとラベルは、どちらもキー・バリューの文字列のペアであり、Google Cloud リソースに紐づけることができるという性質を持ちます。しかし、この2つは まったく別の機能 です。タグとラベルの違いは、端的に述べると以下のとおりです。 タグは 権限管理 のための機能 ラベルは リソース整理 や 課金の整理 のための機能 利用例 タグの利用例は、以下です。 本番環境フォルダには environment: prod タグを付与する 検証環境フォルダには environment: test タグを付与する IAM 許可ポリシーの条件（conditions）にタグを条件として追加して、環境を操作できるアカウントを制限する 一方で、ラベルの利用例は以下のようなものです。 gcloud コマンドで VM インスタンスを一覧表示（list）する際に、ラベルを指定してフィルタする。これにより、特定サブシステムの VM だけを抽出する タグとラベルの違い 比較表 タグトラベルの性質の違いを一覧にすると、以下のとおりです。 参考 : タグとラベル タグ ラベル リソース構造 キー、バリュー、バインディング（紐づけ）はそれ自体がリソース ラベル自体はリソースでなく、リソースのメタデータ 定義 組織またはプロジェクトでリソースとして作成 各リソースのメタデータとして定義 アクセス制御 タグ管理用の IAM 権限が存在 付与対象リソースごとの IAM 権限 事前定義 キーとバリューを事前定義する 事前定義なし 継承 Google Cloud 階層の子リソースに継承される 子リソースに継承されない 文字長 256文字以下 63文字以下 IAM ポリシー IAM ポリシーの条件 (Condition) として利用可能 IAM ポリシーから利用不可 組織ポリシー 組織ポリシーの条件付き制約として利用可能 組織ポリシーから利用不可 Billing 連携 ・BigQuery の Cloud Billing データとしてエクスポートされる ・BigQuery の Cloud Billing データとしてエクスポートされる ・Cloud Billing レポートのフィルタリングに使用可 リソースとしての扱い 大きな違いとして、 タグはそれ自体がリソースである 一方で、ラベルはリソースに付与する メタデータである という点です。 タグは組織レベル、またはプロジェクトレベルで、事前にキーとバリューのペアを定義します。定義されているキー、バリューを、リソースに紐づけることができます。また、紐づけ設定はバインディングというリソースとして実体があります。 ラベルは、リソースのメタデータとして付与するので、それ自体はリソースではありません。 また、タグには継承の概念があります。例えばフォルダにタグを紐づけると、配下のプロジェクトにも引き継がれます。 IAM や組織ポリシーでの利用 IAM タグは、主に権限管理のために用いられます。 IAM 許可ポリシーのロールバインディングには、条件（Condition）を記載することができ、例えば「◯時〜◯時の間だけ権限が有効」など条件をつけることができます。ロールバインディングの条件として「〇〇というタグがリソースに付与されていること」のように設定が可能です。 参考 : タグと条件付きアクセス 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog - IAM ポリシーの構造 例えば本番プロジェクトが格納されているフォルダに environment : prod タグを、開発用プロジェクトが入っているフォルダに environment : test タグを付与します。ロールバインディングの条件に「 environment : test タグ」を指定すれば「この Google グループは environment : test タグのついたプロジェクトにだけ権限が有効である」のように制限することが可能です。 組織ポリシー タグは、組織のポリシーの条件としても利用できます。 特定タグのついたプロジェクトにのみポリシーを適用する、といった条件付けが可能です。 参考 : 組織のポリシーを解説 - G-gen Tech Blog 参考 : 組織のポリシーをタグで制御してみた - G-gen Tech Blog 参考 : タグを使用した組織のポリシーの設定 課金管理 課金明細への反映 ラベルは、課金管理のために用いることができます。 請求先アカウントの課金レポート画面で、リソースに付与されたラベルによって「何にいくら利用料金がかかっているのか」を明細表示することができます。 請求先アカウントのレポート画面 例えば owner : xxx のようにオーナー部署のラベルを付与しておけば、利用料金を社内請求するときに利用できます。 なおラベル情報が課金に反映されるのは、 ラベルを付与した時より後の課金のみ です。ラベル付与前の課金情報にまで遡って反映されることはありませんので、ご注意ください。 参考 : Cloud Billing の概要 - ラベル 課金情報の BigQuery エクスポート 請求先アカウントの課金明細は BigQuery にエクスポートすることができます。エクスポート内容には、ラベル情報が含まれます。BigQuery を用いて SQL により詳細に課金情報の分析を行う際に、ラベルを活用できます。 参考 : Cloud Billing データのエクスポート クエリの例 - ラベルを使用したクエリの例 なお2022年10月のアップデートにより、タグの情報も BigQuery エクスポートに含まれるようになりました。ただし、リソースレベルで反映されるのは Compute Engine VM、AlloyDB クラスタ、Cloud Run サービスなど、サポートされているリソースの課金のみです。またタグを付与したり、削除したりしてから BigQuery エクスポートに反映されるまで、最大1時間程度かかります。 参考 : 標準データのエクスポートの構造 - タグについて タグの使い方 タグキー・バリューの作成 基本的なタグの使い方をご紹介します。 タグを使うにはまず、タグキーとタグバリューを、 組織 または プロジェクト で予め作成しておく必要があります。 タグを作成するには、組織またはプロジェクトレベルで、タグ管理者（ roles/resourcemanager.tagAdmin ）ロールが必要です。 コンソールの場合 まずは、Google Cloud コンソールの左上にあるプロジェクトセレクタで、タグを作成したい組織またはプロジェクトを選択してください。 その後、 Google Cloud コンソール ＞ IAM と管理 ＞ タグ から + 作成 を押下することで、キー・バリューを定義できます。定義すると、キーとバリューにはそれぞれ一意となる ID が払い出されます。 タグキー・バリュー作成画面 コマンドラインの場合 gcloud コマンドラインでは、 gcloud resource-manager tags keys create と gcloud resource-manager tags values create を用います。 キーを作成する際、 parent には、タグを作成する組織またはプロジェクトを指定します。組織の場合、 organizations/${組織 ID} のような形式にします。 gcloud resource-manager tags keys create test-tag-key \ --parent = organizations/ 1234567890 \ --description =" This is my description " バリューを作成する際、 parent には、 tagKes/ で始まる先ほど作成したキーの ID を指定します。 gcloud resource-manager tags values create test-value1 \ --parent = tagKeys/ 123456789012 \ --description =" This is for test. " 参考 : gcloud resource-manager tags keys create 参考 : gcloud resource-manager tags values create リソースへの紐づけ フォルダ・プロジェクト タグをフォルダやプロジェクトに紐づけるには、 Google Cloud コンソール ＞ Manage Resources（リソースの管理） でリソースツリーを表示させます。 コンソールの場合 Google Cloud コンソールの「リソースの管理」画面へ遷移します。対象のフォルダやプロジェクトを選択して画面上部に表示される「タグ」ボタンを押下します。付与するタグキー・バリューを追加して、保存します。 対象リソース選択 タグ付与画面 コマンドラインの場合 タグとリソースを紐づけるには、 gcloud resource-manager tags bindings create コマンドラインも使用できます。このコマンドラインを見ると、タグのバインディング（紐づけ）自体も Resource Manager API のリソースであるということが分かります。 紐づける対象リソースは parent に指定します。このとき、対象リソースは 完全なリソース名 で指定します。 gcloud resource-manager tags bindings create \ --tag-value = tagValues/ 123456789012 \ --parent = //cloudresourcemanager.googleapis.com/projects/my-project 参考 : gcloud resource-manager tags bindings create 参考 : 完全なリソース名 個別リソース また、プロジェクト配下の個別のリソースにも、対応しているサービスであればタグを付与できます。例として、Compute Engine VM は、コンソールでのタグ紐づけできるほか、コマンドラインでも可能です。 参考 : タグをサポートするサービス コンソールの場合 インスタンスへのタグ紐づけ画面 コマンドラインの場合 基本はプロジェクトのときと同様ですが、インスタンスはゾーン（ロケーション）の概念があるリソースのため、ロケーションを明示的に指定します。 gcloud resource-manager tags bindings create \ --tag-value = tagValues/ 123456789012 \ --parent = //compute.googleapis.com/projects/my-project/zones/asia-northeast1-c/instances/my-instance \ --location = asia-northeast1-c トラブルシュート タグの紐づけを行おうとした際に、以下のようなメッセージが出る場合があります。 ERROR: (gcloud.resource-manager.tags.bindings.create) PERMISSION_DENIED: The caller does not have permission このエラーメッセージは、IAM 権限が不足していることを意味します。タグ作成時に必要なタグ管理者（ roles/resourcemanager.tagAdmin ）ロールは、紐づけを行う権限を持っていません。紐づけを行う（バインディングを作成する）には、タグユーザー（ roles/resourcemanager.tagUser ）ロールが必要です。 タグ紐づけの作成には resourcemanager.tagValueBindings.create 権限が必要なほか、Compute Engine VM に対しては、 compute.instances.createTagBinding のように、各 API リソースごとにタグバインディングを作成するための権限が必要です。タグユーザー（ roles/resourcemanager.tagUser ）ロールには、多くのリソースに対する *.createTagBinding が含まれています。 参考 : IAM basic and predefined roles reference - Tag User (roles/resourcemanager.tagUser) ラベルの使い方 ラベルの付与 ラベルは、事前定義が必要ありません。 付与の方法はリソースごとに異なります。例として Compute Engine VM の場合、新規 VM 作成時に付与したり、VM の編集により付与できます。 コンソールの場合 ラベルの付与画面 コマンドラインの場合 VM へのラベル付与の場合は、 gcloud compute instances add-labels を使います。コマンドラインを見て分かるように、ラベルそれ自体はリソースではありません。ラベルは VM リソースに付与するメタデータですので、ラベルの付与は、リソースに対する編集操作になります。 gcloud compute instances add-labels my-instance \ --zone = asia-northeast1-c \ --labels = my-test-label = value-01 参考 : gcloud compute instances add-labels そのため、ラベルの付与に必要な IAM ロールは、Compute 管理者（ roles/compute.admin ）等、VM を編集できる IAM ロールです。 ラベルによるフィルタ Compute Engine を例に取ると、特定の値のラベルがついた VM のみをフィルタする、といった使い方ができます。 コンソール画面であれば、VM 一覧画面のテキストボックスに条件を指定できます。 コンソール画面でのフィルタ コマンドラインであれば、フィルタ条件を --filter オプションで指定します。 gcloud compute instances list --filter =" labels.my-test-label:value-01 " 参考 : gcloud topic filters 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの大津です。本記事では Google Cloud (旧称 GCP) における Cloud Interconnect の特徴やメリット、接続方法についてご紹介します。 Cloud Interconnect とは Cloud Interconnect を使うメリット 公共のインターネットを通過しない 接続帯域を柔軟に調整できる 下り（外向き）料金が割安 Dedicated Interconnect Dedicated Interconnect とは 4つの料金軸 Partner Interconnect Partner Interconnect とは ユースケース レイヤ２接続とレイヤ３接続 3つの料金軸 接続手順（Partner Interconnect） VLAN アタッチメントと Cloud Router の作成 サービスプロバイダからのリクエストを承諾 接続を有効にする BGP セッションの構成 Partner Interconnect の接続が確立する Cloud Interconnect のトラブルシューティング Cloud Interconnect とは Cloud Interconnect とは、自社の拠点やデータセンターなどのオンプレミスネットワークと、Google Cloud の Virtual Private Cloud（VPC）ネットワークを、 専用線もしくは閉域網で接続するサービス です。 参考 : Cloud Interconnect の概要 自社拠点等から Google Cloud 環境にプライベート IP アドレスで接続するには、IPsec プロトコルでの VPN を実現する Cloud VPN か、当記事で紹介する Cloud Interconnect のいずれかを選択することになります。Cloud Interconnect は、公衆インターネットを利用する Cloud VPN よりも、低レイテンシであったり、帯域が安定する可能性があります。 Cloud VPN については以下の記事をご参照ください。 blog.g-gen.co.jp Cloud Interconnect には、 Dedicated Interconnect と Partner Interconnect の2種類の接続方法があります。 参考 : 主な用語 - Cloud Interconnect の要素 Cloud Interconnect を使うメリット 公共のインターネットを通過しない Cloud Interconnect は公共のインターネットを経由せずに、オンプレミスネットワークと VPC ネットワークを接続できます。 Cloud Interconnect を用いると、トラフィックは専用線または閉域網ネットワークを持つネットワークサービスプロバイダを通過します。そのため、公共のインターネットの輻輳の影響を受けることなく、安定した通信を実現できます。 接続帯域を柔軟に調整できる Cloud Interconnect では、接続帯域を必要とするサービスの要件に応じて柔軟に選ぶことができます。 Dedicated Interconnect の場合、1回線あたり 10 Gbps または100 Gbps のイーサネット接続 Partner Interconnect の場合、VLANアタッチメントあたり 50 Mbps～50 Gbps の範囲で設定可能。ただしサービスプロバイダから提供されるサービスによっては使用できない帯域がある。 下り（外向き）料金が割安 Cloud Interconnect を介した VPC ネットワークからの下り（Google Cloudから見て外向き）トラフィック料金は、インターネットを経由した VPC ネットワーク下り料金と比べて、割安になっています。 Dedicated Interconnect の場合、アジア地域で $0.042/GB Partner Interconnect の場合、アジア地域で $0.042/GB 通常のVirtual Private Cloud（VPC）からの下り料金は、アジア地域で $0.12/GB Dedicated Interconnect Dedicated Interconnect とは Dedicated Interconnect は、オンプレミスネットワークと VPC ネットワーク間を、 専用線で直接接続 します。 Google が指定するコロケーション施設に設置するお客様ルータと、Google ピアリングエッジを 光ファイバーケーブルで接続する構成 です。 参考 : Dedicated Interconnect の概要 10 Gbps 以上の帯域が必要なデータ転送を利用するようなユースケースに適しており、公共のインターネット上でのデータ転送するよりもコスト効率面で優れています。 コロケーション施設には、以下の技術要件を満たしているルータを設置する必要があります。 10 Gbps 回線、シングルモード ファイバー、10GBASE-LR（1310 nm）、100 Gbps 回線、シングルモード ファイバー、100GBASE-LR4 IPv4 リンクのローカル アドレス指定 LACP（単一回線を使用している場合も必要） EBGP-4 マルチホップ 802.1Q VLAN 4つの料金軸 Dedicated Interconnect を利用する場合、以下の1～４の料金が必要となります。接続するロケーションや利用帯域などにより、料金は異なります。 Dedicated Interconnect の利用料 VLAN アタッチメントの料金 相互接続を介した VPC ネットワークからの下り（外向き）トラフィック 接続するデータセンターの構内配線の料金 1～3の料金について、各リソース（Interconnect 接続または VLAN アタッチメント）の時間単位の料金は、リソースを所有するプロジェクトに課金されます。4はユーザーが契約するコロケーション施設から請求されます。 参考 : Cloud Interconnect の料金 - Dedicated Interconnect Partner Interconnect Partner Interconnect とは Partner Interconnect は、 サービスプロバイダーのネットワークを利用 して、オンプレミスネットワークと Google Cloud の Virtual Private Cloud（VPC）を接続するサービスです。 参考 : Partner Interconnect の概要 日本では、アット東京、Equinix、インターネット イニシアティブ（IIJ）など、多くのネットワークプロバイダーが Partner Interconnect に対応しています。 参考 : サポートされているサービス プロバイダ ユースケース すでに利用中にサービス プロバイダーの追加契約で対応可能な場合 Google が指定するコロケーション施設にルータを用意できない 常時 10 Gbps の広帯域での直接接続する必要がない レイヤ２接続とレイヤ３接続 Partner Interconnect には、レイヤ2接続とレイヤ3接続が選択できます。ネットワークサービスプロバイダーによって、サポートしている接続方法が異なります。 2つの接続方法の違いは、Google Cloud の Cloud Router の対向ルーターとなる、BGP ピアの接続先です。 レイヤ2接続：お客様のオンプレミス拠点のルーター レイヤ3接続：ネットワークサービスプロバイダーのルーター 3つの料金軸 Partner Interconnect では、以下の1～3の料金が発生します。 VLAN アタッチメントの料金 相互接続を介した VPC ネットワークからの下り（外向き）トラフィック サービスプロバイダーの接続料金 1、2の料金について、各リソース（Interconnect 接続または VLAN アタッチメント）の時間単位の料金は、リソースを所有するプロジェクトに課金されます。3はユーザーが契約するサービスプロバイダーから請求されます。 この他に必要となる費用として、契約したサービスプロバイダーの閉域網サービスや、専用線サービス等の料金が必要となる場合があります。 参考 : Cloud Interconnect の料金 - Partner Interconnect 接続手順（Partner Interconnect） 利用頻度の高い Partner Interconnect を利用して、ユーザーのオンプレミスネットワークと、Google Cloud の VPC ネットワークを接続する手順を紹介します。 VLAN アタッチメントと Cloud Router の作成 Google Cloud メニューの「相互接続」＞「相互接続」から、 VLAN アタッチメントを作成します。 はじめに、「Dedicated Interconnect」か「Partner Interconnect 」の選択を行います。 VLAN アタッチメントの作成時に Cloud Router を作成することもできますし、作成済みの Cloud Router を利用することもできます。 正しく VLANアタッチメントと Cloud Router が作成されると、Google Cloud から ペアリングキー が生成されます。 ペアリングキーは、サービス プロバイダが Virtual Private Cloud（VPC）と関連する Cloud Router を識別して接続できるようにするための一意のキーです。 サービスプロバイダは、VLAN アタッチメントの構成を完了するために、このペアリングキーが必要になります。 サービスプロバイダからのリクエストを承諾 サービスプロバイダにペアリングキーの情報を送信し、サービスプロバイダが接続を構成するまで待機します。 この時、Google Cloud 上のステータスは「サービス プロバイダーを待機しています」と表示されています。 サービスプロバイダは、ペアリングキーからサービスプロバイダー側の VLAN アタッチメントを作成します。その後、サービスプロバイダは、Google Cloud へ接続のリクエストを行います。 Google Cloud の Web コンソールにて、サービスプロバイダのリクエストを承諾します。 接続を有効にする サービス プロバイダのリクエストを承諾した後は、VLAN アタッチメントを有効にする必要があります。 VLAN アタッチメントを有効にしてサービス プロバイダとの接続が確立されていることを確認します。この時、Google Cloud 上のステータスは「有効化する必要があります」と表示されています。 BGP セッションの構成 レイヤ2接続の場合、Cloud Router と拠点のルーターとの間で、BGP セッションを確立する必要があります。 Google Cloud コンソールの VLAN ID と BGP ピア IP アドレスを使用して、ルーターを構成します。 レイヤ3接続の場合、この構成は自動化されているので、Google Cloud のWeb コンソールから「BGP を構成する」をクリックします。 この時、Google Cloud 上のステータスは「BGP 構成が必要です」と表示されています。 Partner Interconnect の接続が確立する 以上の手順にて、オンプレミスネットワークと Google Cloud の VPC ネットワーク間が接続されました。 正しく構築が完了すると、Google Cloud 上のステータスは「稼働中」と表示されています。 Cloud Interconnect のトラブルシューティング Cloud Interconnect で発生する可能性がある一般的な問題については、以下の公式ドキュメントを参照してください。 参考 : トラブルシューティング 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) のサーバーレスコンテナサービスである Cloud Run から、マネージドなリレーショナルデータベースサービスの Cloud SQL に安全に接続する方法を紹介します。 使用するサービス Cloud Run Cloud SQL Cloud Run から Cloud SQL に接続する方法 サーバーレス VPC アクセスコネクタ の使用 Cloud SQL Auth Proxy の使用 Cloud SQL の作成と設定 Cloud SQL インスタンスを作成する データベースを作成する ユーザーを作成する Cloud SQL に接続する Cloud Run サービスを作成 Cloud Run サービスに紐付けるサービスアカウントを作成する サンプルアプリケーションを Cloud Run にデプロイする サンプルアプリケーションの Git リポジトリを使用する サンプルアプリのコンテナイメージをビルドする Cloud Run サービスをデプロイする 各種設定値を入力する Cloud SQL の接続情報を環境変数に設定する 接続する Cloud SQL インスタンスを設定する サービスアカウントを設定する サンプルアプリケーションの動作確認 使用するサービス Cloud Run Cloud Run はサーバーレスな環境でコンテナを実行できるサービスです。 詳細については以下の記事で解説していますので、ご一読ください。 blog.g-gen.co.jp Cloud SQL 今回は PostgreSQL データベース のマネージドサービスである Cloud SQL for PostgreSQL を使用します。 Cloud SQL の詳細については以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run から Cloud SQL に接続する方法 Cloud Run でリレーショナルデータベースを使用したい場合、最初に検討することになるのが Cloud SQL です。 Cloud SQL のインスタンスは Google Cloud のマネージド VPC ( サービスプロデューサーネットワーク ) に配置され、Cloud Run から接続する場合は、以下に示す 2 種類の方法のいずれかを使用します。 サーバーレス VPC アクセスコネクタ の使用 プライベート IP を使用して Cloud SQL に接続したい場合、 サーバーレス VPC アクセスコネクタ を使用します。 自身のプロジェクト内にある VPC と Cloud SQL インスタンスが存在するサービスプロデューサーネットワークを プライベートサービスアクセス を使用してピアリング接続し、VPC 内に作成したコネクタを使用して Cloud SQL に接続するように Cloud Run を構成します。 サーバーレス VPC アクセスコネクタを使用した接続 Cloud SQL Auth Proxy の使用 Cloud SQL Auth Proxy というプロキシソフトウェアを使用することで、Cloud SQL インスタンスのパブリック IP を使用しつつ、TLS 暗号化による安全な接続を実現できます。 また、Cloud SQL Auth Proxy を使用した場合、データベースの接続元を IAM で制御することができるため、 Cloud SQL Auth Proxy を使用し、かつ Cloud SQL インスタンスにアクセスする IAM 権限を持っているクライアントに接続元を制限することができます。 Cloud Run では、パブリック IP を使用する Cloud SQL インスタンスに接続する場合、あらかじめ Cloud Run 実行環境にある Cloud SQL Auth Proxy を使用するように構成することができ、UNIX ドメインソケットを使用して高速な通信を行うことができます。 なお、Cloud SQL にパブリック IP を使用したくない場合は、先述のサーバーレス VPC アクセスコネクタと Cloud SQL Auth Proxy を併用することで、プライベート IP を使用したプロキシ経由の接続も可能となっています。 当記事では、パブリック IP アドレスを使用する Cloud SQL に対して、Cloud SQL Auth Proxy 経由の接続を実際に試してみます。 Cloud SQL Auth Proxy を使用した接続 Cloud SQL の作成と設定 Cloud SQL インスタンスを作成する 当記事では PosgreSQL の Cloud SQL インスタンスを使用します。 任意の インスタンス ID 、パスワード、リージョン等を設定し、 パブリック IP を有効化 して作成します。 パブリック IP を有効にして Cloud SQL インスタンスを作成する デフォルトのマシンタイプは 4 vCPU 、メモリ 26 GB となっており、検証目的の場合は少々高めの課金がされてしまうため、必要に応じて調整すると良いでしょう。 データベースを作成する インスタンスが作成されたら、 データベース タブからデータベースを作成していきます。 ここで設定したデータベース名は、後ほど Cloud Run の環境変数に設定します。 データベースの作成① データベースの作成② ユーザーを作成する ユーザー タブからデータベースのユーザーアカウントを作成します。 ここで設定したユーザー名、パスワードも、後ほど Cloud Run の環境変数に設定します。 ユーザーアカウントを追加① ユーザーアカウントを追加② Cloud SQL に接続する Cloud Run サービスを作成 Cloud Run サービスに紐付けるサービスアカウントを作成する Cloud Run から Cloud SQL にアクセスできる権限を持ったサービスアカウントを作成します。 サービスアカウントには以下のロールを付与します。 Cloud SQL クライアント ( Cloud SQL Client ) Cloud Run 用サービスアカウントの作成 サンプルアプリケーションを Cloud Run にデプロイする サンプルアプリケーションの Git リポジトリを使用する Google Cloud によって、Cloud SQL Auth Proxy を使用するように構成された Cloud Run のサンプルアプリケーションが提供されています。 当記事では Python のサンプルアプリケーションを使用します（ GitHub リポジトリ ）。 $ git clone git@github.com:GoogleCloudPlatform/python-docs-samples.git サンプルアプリのコンテナイメージをビルドする python-docs-samples/cloud-sql/postgres/sqlalchemy/ に、Dockerfile を含む、サンプルアプリケーションの各種ファイルが配置されているので、当該ディレクトリに移動します。 $ cd python-docs-samples/cloud-sql/postgres/sqlalchemy/ Cloud Build を使用して、Dockerfile を元に Docker コンテナのイメージをビルドします。 $ gcloud builds submit --tag gcr.io/{コンテナイメージ作成先のプロジェクトID}/{任意の名前} ビルドしたコンテナイメージは、指定したプロジェクトの Container Registry に格納されます。 ビルドしたコンテナイメージ Cloud Run サービスをデプロイする 各種設定値を入力する ビルドしたコンテナイメージから Cloud Run サービスをデプロイしていきます。 コンテナイメージを Cloud Run にデプロイ ビルドしたコンテナイメージが入力されていることを確認し、任意のサービス名とリージョンを設定します。 Cloud Run サービスの作成① 今回は Cloud Run サービスに対するアクセス制御はしないので、 すべてのトラフィックを許可する と 未認証の呼び出しを許可 にチェックを入れます。 Cloud Run サービスの作成② Cloud SQL の接続情報を環境変数に設定する Cloud SQL に接続するための情報を Cloud Run の環境変数として設定します。 サンプルアプリケーションでは、UNIX ソケットを使用する場合、以下のモジュールを使用して接続が行われます。 connect_unix.py （以下抜粋） def connect_unix_socket () -> sqlalchemy.engine.base.Engine: # Note: Saving credentials in environment variables is convenient, but not # secure - consider a more secure solution such as # Cloud Secret Manager (https://cloud.google.com/secret-manager) to help # keep secrets safe. db_user = os.environ[ "DB_USER" ] # e.g. 'my-database-user' db_pass = os.environ[ "DB_PASS" ] # e.g. 'my-database-password' db_name = os.environ[ "DB_NAME" ] # e.g. 'my-database' unix_socket_path = os.environ[ "INSTANCE_UNIX_SOCKET" ] # e.g. '/cloudsql/project:region:instance' pool = sqlalchemy.create_engine( # Equivalent URL: # postgresql+pg8000://<db_user>:<db_pass>@/<db_name> # ?unix_sock=<INSTANCE_UNIX_SOCKET>/.s.PGSQL.5432 # Note: Some drivers require the `unix_sock` query parameter to use a different key. # For example, 'psycopg2' uses the path set to `host` in order to connect successfully. sqlalchemy.engine.url.URL.create( drivername= "postgresql+pg8000" , username=db_user, password=db_pass, database=db_name, query={ "unix_sock" : "{}/.s.PGSQL.5432" .format(unix_socket_path)}, ), # [START_EXCLUDE] # Pool size is the maximum number of permanent connections to keep. pool_size= 5 , # Temporarily exceeds the set pool_size if no connections are available. max_overflow= 2 , # The total number of concurrent connections for your application will be # a total of pool_size and max_overflow. # 'pool_timeout' is the maximum number of seconds to wait when retrieving a # new connection from the pool. After the specified amount of time, an # exception will be thrown. pool_timeout= 30 , # 30 seconds # 'pool_recycle' is the maximum number of seconds a connection can persist. # Connections that live longer than the specified amount of time will be # re-established pool_recycle= 1800 , # 30 minutes # [END_EXCLUDE] ) return pool コンテナ、接続、セキュリティ 項目の コンテナ タブから環境変数を設定することができるので、以下の環境変数に対応する値を Cloud Run サービスに設定していきます。 環境変数名 設定値 INSTANCE_UNIX_SOCKET 作成した Cloud SQL インスタンスの情報を元に、以下の値を設定 /cloudsql/{プロジェクト名}:{リージョン}:{インスタンスの名前} INSTANCE_CONNECTION_NAME Cloud SQL の インスタンス接続名 Google Cloud コンソールの Cloud SQL インスタンス一覧画面から確認可能 DB_NAME Cloud SQL インスタンスに作成したデータベースの名前 DB_USER 作成したデータベースユーザーの名前 DB_PASS 作成したデータベースユーザーのパスワード Cloud SQL のインスタンス接続名 Cloud Run サービスの環境変数を設定 コード内コメントに記載がある通り、データベースの接続情報をよりセキュアに Cloud Run に渡したい場合は、 Secret Manager を使用することもできます。 接続する Cloud SQL インスタンスを設定する コンテナ、接続、セキュリティ 項目の 接続 タブを開き、 Cloud SQL 接続 で環境変数に設定したものと同じ インスタンス接続名 を選択します。 これにより、Cloud Run サービスで Cloud SQL Auth Proxy が有効化され、プロキシを用いたデータベース接続が可能になります。 接続する Cloud SQL インスタンスを設定 サービスアカウントを設定する コンテナ、接続、セキュリティ 項目の セキュリティ タブで Cloud SQL インスタンスへの接続を許可したサービスアカウントを設定します。 サービスアカウントを設定 ここまで設定したら 作成 を押下して Cloud Run サービスを作成します。 サンプルアプリケーションの動作確認 ブラウザから Cloud Run サービスの URL にアクセスし、サンプルアプリケーションを動かしてみます。 ブラウザからサンプルアプリケーションにアクセス 当記事で使用するサンプルアプリケーションでは、 TAB と SPACE のどちらかに投票することで、投票結果がデータベースに記録されるようになっています。 サンプルアプリケーションの画面 投票ボタンを何度か押下します。 投票するたびに数字が加算される データベースに投票結果が保持されているか確認するため、Cloud Run サービスのコンテナがすべて破棄されるのを待ってから、もう一度 URL にアクセスします。 サービスの詳細 の 指標 タブから コンテナ インスタンス数 を確認できます。 active と idle の値が 0 になるまで少し待ちます。 コンテナ インスタンス数が 0 になったことを確認 2 つの値が 0 になったら、もう一度サービスの URL にアクセスします。 このとき、先程とは別のコンテナが起動されますが、投票結果はデータベース側で保持されているため、投票後と同じ投票数が画面に表示されます。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。Infrastructure as Code (IaC) を実現する Terraform を Google Cloud (旧称 GCP) で使ってみました。 Terraform とは 使ってみる Cloud Shell Terraform コマンドの確認 ファイル作成 エディタでの編集 Terraform 初期化 確認コマンド 適用 環境の削除 Cloud Storage に状態 (state) を保存する 前提知識 状態 (state) とは 状態 (state) の共有 バケットの作成 バックエンド構成の作成 再 init 応用 Terraform とは Terraform は Infrastructure as Code (IaC) を実現するオープンソース (Mozilla Public License v2.0) のツールです。 Google Cloud (旧称 GCP) のほか Amazon Web Services (AWS) や Microsoft Azure にも対応しており、 IaC ツールとして根強い人気を誇ります。 Terraform では独自フォーマットの設定ファイルでリソースを記述し、コマンドラインツールで操作します。また状態 (state) がファイルとして保存され、実環境と設定ファイルの差分が把握されます。 設定ファイルでクラウドインフラを管理できるため、 IT インフラのバージョン管理や CI/CD (継続的インテグレーション / 継続的デリバリ) を可能にします。 Google Cloud では公式の IaC ツールとして Cloud Deployment Manager が存在しているものの、事実上 Terraform が Google Cloud の IaC ツールとして定着しています。 使ってみる Cloud Shell Google Cloud の Web コンソールには Cloud Shell が備わっており、ローカル PC にツールをインストールしたり作業用の VM を起動しなくてもブラウザ上で Linux ベースの作業スペースを使うことができます。 Google Cloud コンソール にログインし、右上の四角いアイコンをクリックします (マウスオーバーすると Cloud Shell をアクティブにする と表示されます) 。 Cloud Shell を起動 始めて起動する場合は 1 分程度待つ必要があるかもしれませんが、2回目以降は数秒程度になります。しばらくすると黒いターミナル画面が出てきます。 以下スクリーンショットの赤枠部分をドラッグして上下に動かすと、ターミナル画面のサイズを変えることができます。 ターミナル画面 Terraform コマンドの確認 実は Cloud Shell にはデフォルトで Terraform がインストール済みです。 terraform --version と入力してエンターを押してみてください。 $ terraform --version Terraform v1. 2 . 8 on linux_amd64 Your version of Terraform is out of date! The latest version is 1 . 2 . 9 . You can update by downloading from https://www.terraform.io/downloads.html もしローカル PC に Terraform をインストールしたい場合、 公式サイト 等をご参照ください。 ファイル作成 フォルダを作ってその中に Terraform 設定ファイルを作成します。 ここでは Cloud Storage バケットを定義するための storage.tf というファイルを作成します。ファイル名は任意です。 mkdir terraform-demo cd terraform-demo touch storage.tf エディタでの編集 なんと Cloud Shell には ブラウザ上で動作するコードエディタまで付属しています。エディタを開くため、以下スクリーンショットの エディタを開く ボタンを押下します。 エディタを開く 左側のファイルエクスプローラから先程の storage.tf を選択し、編集します。 エディタ画面 以下の設定内容を貼り付けて、保存 ( File メニューから Save もしくは Ctrl + S 押下) します。 <任意のリソース名> は任意の名称に置き換えてください。これは Terraform 内でリソースを一意に特定するための識別子です。その左側にある "google_storage_bucket" はこのリソースの種類を表します。 また <バケット名> を世界で一意になるように置き換えてください。これが Cloud Storage バケット名となります。 resource "google_storage_bucket" "<任意のリソース名>" { name = "<バケット名>" location = "asia-northeast1" force_destroy = true uniform_bucket_level_access = true lifecycle_rule { condition { age = 5 } action { type = "Delete" } } } 上記は以下のような Cloud Storage バケットを定義する設定です。 設定名 値 バケット名 <バケット名> ロケーション asia-northeast1 (東京) force_destroy 有効 (バケット削除時にオブジェクトが残っていたら中身を全て削除してからバケット削除) 均一なアクセス制御 有効 ライフサイクル 5 日で削除 リソースタイプごとにパラメータの設定方法が定義されており Terraform の公式リファレンスから確認可能です。 参考 : google_storage_bucket Terraform 初期化 次に、コマンドを実行して Terraform の初期化を行います。エディタの編集部分下部に白いターミナルが表示されていますので、そこからコマンドを実行するか、エディタ上部の ターミナルを開く ボタンを押して先程の黒いターミナルに戻ることもできます。 terraform init コマンドを実行してください。 Terraform has been successfully initialized! と表示されたら成功です。 terraform init の実行 このコマンドを実行すると、カレントディレクトリの配下にある *.tf が自動的に読み込まれ、必要なファイルがセットアップされます。 今回はリソースタイプが google_storage_bucket のリソースが定義されているので、自動的に Google 用の プロバイダ がダウンロードされてセットアップされます。プロバイダとは Terraform 本体とは別個のバイナリであり AWS や Google Cloud など対応するプラットフォームごとに存在しています。 ls -la コマンドを実行すると、以下のように . から始まる隠しファイルが生成されていることが分かります。 $ ls -la total 20 drwxr-xr-x 3 sugimura sugimura 4096 Sep 19 02:04 . drwxr-xr-x 27 sugimura 1001 4096 Sep 19 01:19 .. -rw-r--r-- 1 sugimura sugimura 294 Sep 19 01:02 storage.tf drwxr-xr-x 3 sugimura sugimura 4096 Sep 19 02:04 .terraform -rw-r--r-- 1 sugimura sugimura 1155 Sep 19 02:04 .terraform.lock.hcl 確認コマンド 次は terraform plan コマンドを実行します。カレントディレクトリにある *.tf 設定ファイルが環境にどのような影響を及ぼすかを事前に確かめるためのコマンドです。 $ terraform plan Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # google_storage_bucket.ggen-test-storage will be created + resource " google_storage_bucket " " ggen-test-storage " { + force_destroy = true + id = ( known after apply ) + location = " ASIA-NORTHEAST1 " + name = " ggen-test-storage " + project = ( known after apply ) + self_link = ( known after apply ) + storage_class = " STANDARD " + uniform_bucket_level_access = true + url = ( known after apply ) + lifecycle_rule { + action { + type = " Delete " } + condition { + age = 5 + matches_prefix = [] + matches_storage_class = [] + matches_suffix = [] + with_state = ( known after apply ) } } } Plan: 1 to add, 0 to change, 0 to destroy. ────────────────────────────────────────────────────────────────────────────────────────── Note: You didn ' t use the -out option to save this plan, so Terraform can ' t guarantee to take exactly these actions if you run " terraform apply " now. Plan: 1 to add, 0 to change, 0 to destroy. は環境に新しいリソースが作成されることを意味しています。 実際にリソースを作成したり更新する前に毎回 terraform plan を実行することで、意図しない変更に事前に気がつくことができます。 適用 実際にリソースを作成するため terraform apply を実行します。 実行すると plan を実行したときと同じような環境差分の表示に加えて以下のプロンプトが表示されます。 Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes を入力して Enter を押下すると、実際に環境に適用されます。 Apply complete! Resources: 1 added, 0 changed, 0 destroyed. が表示されれば成功です。 Cloud Storage のコンソール画面で、バケットが作成されたことを確認してください。ライフサイクルポリシーも設定されているはずです。 環境の削除 環境を削除する場合は terraform destroy を実行します。 先程と同じようにプロンプトが表示されますので yes を入力して Enter を押下します。これで環境が削除されます。 Cloud Storage に状態 (state) を保存する 前提知識 状態 (state) とは Terraform の 状態 (state) とは Terraform が把握している実環境の現在の状態です。 Terraform は state をファイルとして保持します。 「状態をファイルとして保持せず、常に実環境を見てくれればいいのに。そうしないとファイルと実環境の差異が生まれてしまうのでは」と考える人もいるかもしれません。しかし「複数リソースの依存関係を保持する」「設定ファイルと実リソースのマッピングを保持する」「毎回実環境を精査すると多数の API コールが走りリソースが多い場合に処理が重すぎる」などの理由で Terraform は state をファイルとして保持しています ( 参考 ) 。 state は tfstate ファイル として保管され、先程の手順で実行するとファイルはローカル (Cloud Shell) に保存されます。もしローカル PC で Terraform を実行したら、ローカル PC に保管されます。 状態 (state) の共有 しかし、これでは複数人で Terraform 設定ファイルを管理する場合に問題が生じます。 誰かのローカルの tfstate ファイルが保存されていたのでは、この人が毎回 terraform plan terraform apply する必要が出てきます。これではチーム開発や CI/CD は実現できません。 これを解決するため tfstate ファイルをリモート管理することができます。 Google Cloud では Cloud Storage バケット に tfstate ファイルを保管し、これを共有することができます。 実際にやってみます。 バケットの作成 tfstate ファイルを保存するためのバケットを手動で作成しておきます。 このバケットを Terraform で作成しても構いません。しかし「 Terraform の管理に使われるファイルを保管するバケットが Terraform で管理されるべきではない」という考え方もできるため、今回は手動で作成することにします。 バックエンド構成の作成 以下のようなファイルを backend.tf として新規作成し、先程作成した storage.tf と同じディレクトリに配置します。 terraform { backend "gcs" { bucket = "ggen-terraform-demo" prefix = "terraform/state" } } 再 init terraform init を実行します。 Terraform has been successfully initialized! という表示が出たら成功です。 バケットの中身を見てみると terraform/state フォルダの中に tfstate ファイルが生成されているはずです。 バケット内の tfstate ファイル これ以降は terraform plan や terraform apply を実行するたびに最新の状態がバケットから取得され、 apply により環境が更新されるとバケット上の tfstate ファイルが更新されます。 これに加えて Terraform 設定ファイルを Git 等でバージョン管理することで、複数人による開発・管理が可能になります。 応用 以下は、Google Cloud が公式に掲載している、Terraform を使用するためのベストプラクティスに関するドキュメントです。 実環境で Terraform を運用していくにあたり、役に立つベストプラクティスが記載されています。 参考 : Terraform を使用するためのベスト プラクティス 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは、G-gen 又吉です。今回は、Security Command Center から検出される脅威を Slack に通知したり、特定の検出機能においては自動で修復する仕組みを実装してみたいと思います。 概要 Security Command Centerとは 作成するもの 作成の手順 Pub/Sub トピックを作成 サービスアカウントの作成 Cloud Functions の作成 main.py の内容 requirements.txt の内容 ポリシーの更新手順 ポリシーの更新手順 get_iam_policy set_iam_policy 動作確認 "@gmail.com" に単一のロールを紐づけた時 "@gmail.com" に複数のロールを紐づけた時 検出機能が「NON_ORG_IAM_MEMBER」以外の時 概要 Security Command Centerとは Security Command Center とは、Google Cloud 環境の構成ミス、脆弱性、脅威を特定して、セキュリティ強化・リスク軽減をするためのサービスです。 Security Command Center については、以下の記事で詳しく解説されているため事前にご覧いただけると幸いです。 blog.g-gen.co.jp また筆者の環境は、Security Command Center の スタンダード ティア が組織と組織配下のプロジェクトですべて有効化された状態ですので、まだ有効化されていない方は事前に以下を参考にSecurity Command Center を有効化していただけますと幸いです。 https://cloud.google.com/security-command-center/docs/set-up?hl=ja 作成するもの Security Command Center から検出機能の中で、重要度が「 重大 」または「 高 」のものを対象に Slack に推奨事項（改善策）とともに検出結果を通知します。 上記は、こちらのチュートリアルを参考にしました。 cloud.google.com また、検出機能の中でも 特定の検出機能 が検出された時、 自動で修復する仕組み も実装します。 今回ピックアップした検出機能は、「 NON_ORG_IAM_MEMBER 」です。こちらは、組織内で "@gmail.com" メールアドレスのアカウントに IAM 権限が紐づけられている場合に、リアルタイムに検出されます。 「NON_ORG_IAM_MEMBER」が検出された際は、対象の "@gmail.com" のユーザーに紐づけられたロールを自動で削除して、削除結果を Slack にて報告するスクリプトを記述し、Cloud Functions で実装していきたいと思います。 作成の手順 手順としては、大きく以下の3つとなります。 Pub/Sub トピックを作成 サービスアカウントの作成 Cloud Functions を構成 Pub/Sub トピックを作成 Cloud Shell を起動して、Cloud Pub/Sub トピックを設定していきます。 上記の赤枠をクリックすると Cloud Shell が起動しますので、Cloud Shell ターミナルから以下を実行します。 # 環境変数に Google Cloud プロジェクト を指定 export PROJECT_ID =PROJECT_ID # 環境変数に Google Cloud 組織を指定 export ORG_ID =ORG_ID # gcloud コマンドにプロジェクト ID を設定 gcloud config set project PROJECT_ID # 通知をパブリッシュする Pub/Sub トピックを作成 gcloud pubsub topics create scc-critical-and-high-severity-findings-topic # 環境変数にトピックを指定 export TOPIC =projects/ $PROJECT_ID /topics/scc-critical-and-high-severity-findings-topic # メッセージがトピックにパブリッシュされたときに、 Cloud Functions に通知するサブスクリプションを作成 gcloud pubsub subscriptions create scc-critical-and-high-severity-findings-sub --topic scc-critical-and-high-severity-findings-topic # トピックに通知をパブリッシュするように、Security Command Center を構成 (フィルタ機能を用いて、重要度が「重大」と「高」のアクティブな検出結果に関する通知をパブリッシュ) gcloud scc notifications create scc-critical-and-high-severity-findings-notify --pubsub-topic $TOPIC --organization $ORG_ID --filter " (severity= \" HIGH \" OR severity= \" CRITICAL \" ) AND state= \" ACTIVE \" " サービスアカウントの作成 Cloud Functions に紐づくサービスアカウントを作成していきます。 IAM と管理 ＞ サービスアカウント へ移動 サービスアカウントを作成 をクリック 「Cloud Functions 起動元」と「Pub/Sub サブスクライバー」、「Project IAM 管理者」のロールをアタッチ 完了 をクリック Cloud Functions の作成 Cloud Functions を作成していきます。 Cloud Functions へ移動 関数の作成 をクリック トリガー に「Cloud Pub/Sub」を、トピックに先程作成した「${TOPIC}」を選択 サービスアカウント に先程作成した「${サービスアカウント}」を入力 環境変数に Slack Webhook のURLを入力 Slack Webhook URL の発行手順は こちら を参考にしました。 次へ をクリック ランタイム に Python 3.9 を選択し、エントリポイントを「send_slack_chat_notification」と入力 main.py とrerequirements.txt のファイルをそれぞれ以下のコードに書き換え、[デプロイ]をクリック main.py の内容 import base64 import json import os import slackweb from google.cloud import resourcemanager_v3 from google.iam.v1 import iam_policy_pb2 # type: ignore # 環境変数から SLACK_WEB_HOOK_URL を取得 SLACK_WEB_HOOK_URL = os.environ.get( "SLACK_WEB_HOOK_URL" ) # slack クライアントの初期化 slack = slackweb.Slack(url=SLACK_WEB_HOOK_URL) # ProjectsClient クライアントの初期化 client = resourcemanager_v3.ProjectsClient() def send_slack_chat_notification (event, context): # SCC から受け取ったデータを json 形式で展開 pubsub_message = base64.b64decode(event[ 'data' ]).decode( 'utf-8' ) message_json = json.loads(pubsub_message) finding = message_json[ 'finding' ] # カテゴリー（検出機能）とレコメンド（改善策）を取得 category = finding[ 'category' ] recommendation = finding[ 'sourceProperties' ][ 'Recommendation' ] # 検出機能が「NON_ORG_IAM_MEMBER」の時、"@gmail.com" の対象ユーザーに紐づけられているロールを削除する if category == "NON_ORG_IAM_MEMBER" : # プロジェクトIDとメンバーのメールアドレス、紐づけられたロールの情報を取得 project_id = finding[ 'sourceProperties' ][ 'ResourcePath' ][ 0 ].split( '/' )[ 1 ] member = finding[ 'sourceProperties' ][ 'OffendingIamRolesList' ][ 0 ][ 'member' ] roles = [] for i in range ( len (finding[ 'sourceProperties' ][ 'OffendingIamRolesList' ][ 0 ][ 'roles' ])): roles.append(finding[ 'sourceProperties' ][ 'OffendingIamRolesList' ][ 0 ][ 'roles' ][i]) # 対象メンバー (@gmail.com) が紐付くロールから、対象メンバーを削除する関数を実行 modify_policy_remove_member(project_id, roles, member) # 削除結果を Slack で通知 slack.notify(text=f "【セキュリテクリスク検出】 \n {category} \n 【報告】 \n project_id:{project_id} に@gmailを含むユーザーが追加されたことを検知したため、対象ユーザに付与されたロールを自動的に削除しました \n 【対象ユーザ】 \n {member} \n 【削除したロール】 \n {roles} " ) return else : # 検出機能が「NON_ORG_IAM_MEMBER」以外の時、検出機能とレコメンド（改善策）の情報を Slack で通知 slack.notify(text=f "【セキュリテクリスク検出】 \n {category} \n 【推奨事項】 \n {recommendation}" ) return def modify_policy_remove_member (project_id, roles, member): # プロジェクト内の全てのアクティブなロールを取得 iam_policy = get_iam_policy(project_id) # roles リストにある role の数だけ処理を回す for i in range ( len (roles)): # iam_policy の中のロールと、引数で受け取ったロールが同じ場合、対象の bindings を取得 bindings = next (b for b in iam_policy.bindings if b.role == roles[i]) # bindings の中に、引数で受け取ったメンバー（"@gmail.com"）が含まれる場合、取り除く if bool (bindings.members) and member in bindings.members: bindings.members.remove(member) # 上記で修正したポリシーを、プロジェクトの新ポリシーとして上書きする set_iam_policy(project_id, iam_policy) return def get_iam_policy (project_id): # 対象プロジェクト内の IAM Policy の取得 request = iam_policy_pb2.GetIamPolicyRequest( resource=f "projects/{project_id}" ) iam_policy = client.get_iam_policy(request=request) return iam_policy def set_iam_policy (project_id, iam_policy): # 対象プロジェクト内の IAM Policy を上書き request = iam_policy_pb2.SetIamPolicyRequest( resource=f "projects/{project_id}" , policy=iam_policy, ) response = client.set_iam_policy(request=request) return requirements.txt の内容 slackweb==1.0.5 requests==2.28.1 google - cloud - resource - manager==1.6.1 grpc - google - iam - v1==0.12.4 ポリシーの更新手順 "@gmail.com" の対象ユーザーに紐づけられているロールを削除する仕組みは、以下の流れで行われています。 ポリシーの更新手順 既存のポリシーの取得 （ get_iam_policy ） ポリシーの変更 （ modify_policy_remove_member ） ポリシー全体の書き込み （ set_iam_policy ） 2 ポリシーの変更時に、"@gmail.com" の対象ユーザーに紐づけられているロールを削除しています。 get_iam_policy get_iam_policy で取得できるデータは以下のような形式です。 version: 1 bindings { role: " roles/bigquery.admin " members: " user:hogehoge@gmail.com " members: " user:matayuuu@g-gen.co.jp " } bindings { role: " roles/owner " members: " user:matayuuu@g-gen.co.jp " } ・ ・ ・ etag: " \007\005\351\264\211 C \021\344 " 対象のプロジェクト内でアクティブなロールに紐づくメンバーが bindings として取得できます。 また、 etag はポリシーが更新されるたびに変更されるため、 ポリシーの書き込み時の競合防止 に使われています（ 参考 ）。 set_iam_policy get_iam_policy で取得できるデータの一部を変更して、set_iam_policy でポリシーを更新できます。 仮に、 hogehoge@gmail.com のユーザーから "roles/bigquery.admin" のロールを削除したとすると、以下のようになります。 version: 1 bindings { role: " roles/bigquery.admin " members: " user:matayuuu@g-gen.co.jp " } bindings { role: " roles/owner " members: " user:matayuuu@g-gen.co.jp " } ・ ・ ・ etag: " \007\005\351\264\211 C \021\344 " 上記の状態で、set_iam_policy をすることで、 etag の中身が get_iam_policy で取得したときと同じ であれば新しいポリシーとして上書きが 成功 します。 逆に、etag の中身が get_iam_policy で取得したときと変わっていれば、自分が get_iam_policy した後に 他の誰かがポリシーを変更して上書きしている ため更新が 失敗 となります（競合の発生）。 その場合は、再度 get_iam_policy してから、その内容に変更を加えて set_iam_policy する流れになります。 動作確認 "@gmail.com" に単一のロールを紐づけた時 IAM と管理 ＞ IAM から、"@gmail.com" ユーザーに 任意のロールを紐づけし、自動で紐づけたロールが削除されるか確認します。 保存 をクリックしたタイミングで、Slack に以下の通知が届きました。 "@gmail.com" ユーザーのロールが上手く削除できた際、削除したことを報告する内容が Slack に届きます。 念の為、 IAM と管理 ＞ IAM でも ”@gmail.com" のユーザーにロールが紐付いていないか確認しましたが、問題なく削除されておりました。 "@gmail.com" に複数のロールを紐づけた時 次に、一人のユーザーに対し、一度に複数のロールを紐づけた際の挙動も確認していきたいと思います。 先程と同様、 "@gmail.com" ユーザーに任意のロールを複数紐づけます。 保存 をクリックしたタイミングで、Slack に以下の通知が届きました。 "＠gmail.com" ユーザーからロールが削除できています。 検出機能が「NON_ORG_IAM_MEMBER」以外の時 最後に、検出機能が「NON_ORG_IAM_MEMBER」以外の時の挙動も確認します。 こちらは、 SCC ＞ 検出 から適当な検出機能を選択し、 非アクティブ にした後、再度 有効 にすることで Slack へ通知されるか確認したいと思います。 「OPEN_FIREWALL」を、一度 非アクティブ にした後、再度 有効 にしたタイミングで、Slack に以下の通知が届きました。 「NON_ORG_IAM_MEMBER」以外の時は、セキュリティリスクを検出したことを報告し、推奨事項 (改善案) を通知する文が Slack に届きます。 今回作成した自動修復の仕組みは「 NON_ORG_IAM_MEMBER 」の検出機能のみでしたが、こちらを応用すると組織としてクリティカルな脅威に対して、自動修復する 是正的な統制 も実現できそうですね。 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Champion Innovator (AI/ML)。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリスト。好きな分野は生成 AI。 Follow @matayuuuu

G-gen の杉村です。Google Cloud（旧称 GCP）の Cloud Run functions（第2世代）を使い、Cloud Storage へファイルが配置されたことを起点に起動するプログラムを作ってみました。 前提知識 Cloud Storage と Cloud Run functions Cloud Storage トリガの Cloud Run functions とは 検証 やること ソースコード 実行結果 デプロイの手順 必要な API の有効化 Cloud Storage サービスエージェントに権限付与 トリガー用サービスアカウントの作成 ソースコードの配置 Cloud Run functions 関数のデプロイ 実行結果確認 トラブルシューティング Please verify that the bucket exists Build failed with status: FAILURE and message: An unexpected error occurred The request was not authenticated. ローカルでのテスト 前提知識 Cloud Storage と Cloud Run functions Cloud Storage と Cloud Run functions の基礎知識については以下の記事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp Cloud Storage トリガの Cloud Run functions とは Cloud Storage にオブジェクトがアップロードされたことをトリガーにして Cloud Run functions を起動させることができます。この呼び出し方を Cloud Storage トリガー と呼びます。 Cloud Storage トリガの関数 ユースケースとしては、例えば以下のようなものが挙げられます。 csv ファイルがアップロードされると中身を自動的に BigQuery のテーブルに投入する 画像ファイルがアップロードされるど自動的に切り抜き & 画像サイズを調整してサムネイルを作る Zip ファイルがアップロードされると自動的に展開して適切なパス (フォルダ) に振り分ける なお Cloud Run functions の第1世代と第2世代で少し実装方法が異なります。詳細は以下の公式ドキュメントをご確認ください。 参考 : Cloud Storage トリガー 参考 : イベント ドリブン関数を作成する 検証 やること Cloud Storage トリガの Cloud Run functions（第2世代）では、トリガの情報（Cloud Storage にアップロードされたオブジェクトのパスやファイル名、サイズ等）が CloudEvent形式 で渡されてきます。 参考 : CloudEvents 形式 - HTTP プロトコル バインディング 今回は、関数に渡されるイベントの内容を確かめる検証のため、特にファイルに対して処理をせず、イベントの中身をテキストとして Cloud Logging に出力するだけのプログラムを開発しました。 今回の検証 ソースコード import functions_framework @ functions_framework.cloud_event def main (cloud_event): # printing all the event data print (cloud_event) # Name of the bucket and the object bucket = cloud_event.data[ 'bucket' ] object = cloud_event.data[ 'name' ] size = cloud_event.data[ 'size' ] print (f "bucket : {bucket}" ) print (f "object : {object}" ) print (f "size : {size}" ) 冒頭の import functions_framework は CloudEvent 関数を使うときに必須のライブラリです。Cloud Run functions の実行環境にはデフォルトで含まれますのでライブラリをデプロイパッケージに含ませる必要はありません。まずはおまじないと思っても問題ありません。 main 関数の前の @functions_framework.cloud_event はデコレータです。デコレータとは、ある関数の実行前後に別の処理を加える際などに用いる Python の機能です。こちらもおまじないだと思っても構いません。 def main(cloud_event): 以降が本来の処理となります。 Cloud Storage にファイル（オブジェクト）がアップロードされると、そのファイルの情報が cloud_event として渡され、 main 関数が実行されます。この関数の処理は cloud_event の中身や cloud_event から取り出したバケット名、ファイル名、ファイルサイズを print する簡単なものです。 Cloud Run functions では標準出力が Cloud Logging に自動的に送信されるため、 print コマンドで簡易的にロギングしています。 実行結果 手順は後述しますが、上記のソースを Cloud Run functions（第2世代）にデプロイして、 gcs-function-test という Cloud Storage バケットと紐づけました。 このバケットに animal_panda.png という名称のファイルをアップロードすると関数が起動し、以下のような出力結果となりました。なお Cloud Run functions から print すると Cloud Logging 側では様々なメタ情報を付加しますが、以下に標準出力の中身だけを掲載します。 print(cloud_event) の結果 { 'attributes' : { 'specversion' : '1.0' , 'id' : '5635814697830791' , 'source' : ' //storage.googleapis.com/projects/_/buckets/gcs-function-test' , 'type' : 'google.cloud.storage.object.v1.finalized' , 'datacontenttype' : 'application/json' , 'subject' : 'objects/animal_panda.png' , 'time' : '2022-09-17T05:59:11.036457Z' , 'bucket' : 'gcs-function-test' }, 'data' : { 'kind' : 'storage#object' , 'id' : 'gcs-function-test/animal_panda.png/1663394351028903' , 'selfLink' : 'https://www.googleapis.com/storage/v1/b/gcs-function-test/o/animal_panda.png' , 'name' : 'animal_panda.png' , 'bucket' : 'gcs-function-test' , 'generation' : '1663394351028903' , 'metageneration' : '1' , 'contentType' : 'image/png' , 'timeCreated' : '2022-09-17T05:59:11.036Z' , 'updated' : '2022-09-17T05:59:11.036Z' , 'storageClass' : 'STANDARD' , 'timeStorageClassUpdated' : '2022-09-17T05:59:11.036Z' , 'size' : '214319' , 'md5Hash' : '8ui/28TJi+Qi/kJrJHWYuA==' , 'mediaLink' : 'https://storage.googleapis.com/download/storage/v1/b/gcs-function-test/o/animal_panda.png?generation=1663394351028903&alt=media' , 'crc32c' : 'cYHNvQ==' , 'etag' : 'CKe1qOuSm/oCEAE=' } } これが Cloud Storage トリガで得られる情報の全量となります。渡されるデータは StorageObjectData タイプであり、フォーマットは以下のように決まっています。 参考 : GitHub - proto/google/events/cloud/storage/v1/data.proto attributes にはイベントの性質が入っています。今回のイベントがオブジェクトの finalize (新規オブジェクト作成か既存オブジェクト上書きの完了) がきっかけであることや、イベントの時刻 (UTC) が入っています。 data にはオブジェクト名（ name ）、バケット名（ bucket ）、ストレージクラス（ storageClass ）、バイト数（ size ）などが含まれていることが分かります。 print(f"bucket : {bucket}") の結果 bucket : gcs-function-test print(f"object : {object}") の結果 object : animal_panda.png print(f"size : {size}") の結果 size : 214319 先程の cloud_event から情報を読み出して利用できることが分かります。 今回は行っていませんが、続くプログラム内で Cloud Storage API を呼び出してアップロードされたファイルに対して処理をすること等ができます。 なお cloud_event.data['name'] にはオブジェクト名が入りますが、フォルダの中に入っている場合は myfolder/myfile.txt のようにフルパスが入ります。 余談ですが、Cloud Storage にはフォルダという概念は実体としては存在しません。 参考 : Cloud Storage オブジェクトについて - オブジェクトの名前空間 Cloud Storage はあくまでキー・バリューストアであり、フラットな空間にオブジェクトが配置されます。 myfolder/myfile.txt の myfolder はフォルダという実体があるわけではなく、オブジェクト名の一部にすぎません。ただしコンソール画面や CLI ではフォルダ階層があるかのように表示にされ、オブジェクトを整理しやすくすることができます。 デプロイの手順 参考 : Cloud Storage から直接イベントを受信する（gcloud CLI） 必要な API の有効化 以下のコマンドで、必要な API を有効化します。 gcloud services enable \ artifactregistry.googleapis.com cloudfunctions.googleapis.com \ run.googleapis.com \ logging.googleapis.com \ cloudbuild.googleapis.com \ storage.googleapis.com \ pubsub.googleapis.com \ eventarc.googleapis.com \ このコマンドで有効化されるのは以下のサービスです。既に有効化されているものがあっても悪影響はありませんのでそのまま実行して構いません。 Artifact Registry Cloud Run functions Cloud Run Cloud Logging Cloud Build Cloud Storage Pub/Sub Eventarc Cloud Storage サービスエージェントに権限付与 以下のコマンドを実行して Cloud Storage のサービスエージェントに対し、 Pub/Sub へパブリッシュするための IAM 権限を付与します。 プロジェクト名に置き換えてください の部分は、ご自身のプロジェクト ID に置き換えてください。 PROJECT_ID = " プロジェクト ID に置き換えてください " SERVICE_AGENT = " $( gcloud storage service-agent --project = ${PROJECT_ID}) " gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_AGENT} " \ --role =' roles/pubsub.publisher ' gcloud storage service-agent --project=${PROJECT_ID} により Cloud Storage のサービスエージェント名を取得しています。サービスエージェントとは、Google Cloud サービスが他のサービスを呼び出すときに利用する特別なサービスアカウントです。Cloud Storage のサービスエージェントはプロジェクトに1つだけ存在します。 このサービスアカウントに Pub/Sub へパブリッシュ（メッセージを発行）する権限を与えているのです。Cloud Storage トリガの関数起動時には、内部的には Pub/Sub が利用されています（正確に言うと、裏で使われている Eventarc が Cloud Run functions や Cloud Run を呼び出す際に、Pub/Sub を使います）。 トリガー用サービスアカウントの作成 Eventarc が関数を起動するために使うサービスアカウントを作成します。サービスアカウントには、Eventarc イベント受信者（ roles/eventarc.eventReceiver ）ロールと、Cloud Run サービス起動元（ roles/run.servicesInvoker ）ロールをプロジェクトレベルで付与します。前者は Eventarc が Cloud Storage からのイベントを受信するために、後者は Eventarc が関数を起動するために必要です。 PROJECT_ID = " プロジェクト ID に置き換えてください " SA_NAME = " gce-trigger-test " gcloud iam service-accounts create ${SA_NAME} --project = ${PROJECT_ID} gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =' roles/eventarc.eventReceiver ' gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =' roles/run.servicesInvoker ' ソースコードの配置 新しいディレクトリを作成し、先程のサンプルコードを main.py という名称で配置します。 また、 requirements.txt という空のテキストファイルを同じディレクトリに配置してください。 requirements.txt は Python ライブラリの依存関係を記述するファイルであり、Cloud Run functions をデプロイすると、このファイルに基づいて実行環境が自動的に用意されます。今回のサンプルソースコードでは、何も記述しない状態で問題ありません。 Cloud Run functions 関数のデプロイ ソースコードと同じディレクトリに移動して、以下のコマンドを実行してください。 「 プロジェクト名に置き換えてください 」の部分は、ご自身のプロジェクト ID に置き換えてください。「 バケット名に置き換えてください 」の部分は、ご自身のバケット名に置き換えてください。 function= 以降は Cloud Run functions の関数名であり、任意の名称にしてください。 PROJECT_ID = " プロジェクト ID に置き換えてください " BUCKET = " バケット名に置き換えてください " SA_NAME = " gce-trigger-test " FUNCTION_NAME = " gcs-trigger-test " gcloud functions deploy ${FUNCTION_NAME} \ --gen2 \ --project = ${PROJECT_ID} \ --region = asia-northeast1 \ --runtime = python39 \ --memory = 128Mi \ --entry-point main \ --trigger-bucket = ${BUCKET} \ --trigger-service-account =" ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " 上記のコマンドではリージョン、ランタイム、メモリ数などを指定しています。このコマンドを実行すると、ビルドとデプロイにおよそ 2 分程度かかります。デプロイが完了すると関数が利用可能になり、バケットにファイルを配置したり上書きしたりすると関数が起動するようになります。 実行結果確認 指定した Cloud Storage バケットにファイルをアップロードしてみてください。 うまくいけば Cloud Logging のログエクスプローラで print した内容が確認できます。 Cloud Logging 画面 他のログが多くて確認しづらい場合、以下のクエリでフィルタすれば、 Cloud Run (Cloud Run functions 第2世代) のログだけに絞ることができます。 resource . type = " cloud_run_revision " トラブルシューティング Please verify that the bucket exists gcloud functions deploy コマンドを実行後、以下のようなエラーメッセージが出力されることがあります。 ERROR: (gcloud.functions.deploy) PERMISSION_DENIED: Cannot create trigger projects/my-project-id/locations/asia-northeast1/triggers/gcs-trigger-test-489977: Permission "storage.buckets.get" denied on "Bucket \"my-test-bucket\" could not be validated. Please verify that the bucket exists and that the Eventarc service account has permission." 素直に読むと「バケット名が正しいか」「Eventarc サービスアカウントが正しい権限を持っているか」などを確かめる必要があるように思えます。 しかしこれは、当記事の手順を始めて実施した直後に起こることがあり、時間をおいて再実行すると発生しなくなることがあります。 これは、 API の有効化や IAM 権限の付与が Google Cloud 内で伝搬するのに時間がかかる場合があるからです。数分〜十数分程度、間を開けて再実行してください。 Build failed with status: FAILURE and message: An unexpected error occurred 同じく gcloud functions deploy コマンドを実行後、以下のようなエラーメッセージが出力されることがあります。 ERROR: (gcloud.functions.deploy) OperationError: code=3, message=Build failed with status: FAILURE and message: An unexpected error occurred. Refer to build logs: https://console.cloud.google.com/cloud-build/builds;region=asia-northeast1/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx?project=0000000000000. For more details see the logs at https://console.cloud.google.com/cloud-build/builds;region=asia-northeast1/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx?project=0000000000000. ビルド失敗を意味するメッセージです。エラーメッセージ内に Cloud Logging へのリンクがあるのでそちらへ移動してさらにログを精査すると、以下のようなメッセージが見つかることがあります。 Artifact Registry API has not been used in project 0000000000000 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/artifactregistry.googleapis.com/overview?project=0000000000000 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry. メッセージ通り、 API の有効化が Google Cloud 内で伝搬するのに時間がかかっているために出るエラーです。数分〜十数分程度、間を開けて再実行してください。 この原因以外でも、ソースコードの誤り等でこのエラーが発生することもありえますので、ビルドのログを確認することが解決への近道です。 The request was not authenticated. ビルド・デプロイが成功し、ファイルをバケットにアップロードしても print 内容が Cloud Logging に現れず、以下のようなエラーが出ていることもあります。 The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header. Read more at https://cloud.google.com/run/docs/securing/authenticating Additional troubleshooting documentation can be found at: https://cloud.google.com/run/docs/troubleshooting#unauthorized-client The request was not authenticated. これは、認証がうまくいかず関数が実行されなかったことを意味しています。当記事に示したデプロイコマンドでデプロイした場合、指定したサービスアカウントの認証情報を使って関数が起動されます。その際に権限が足りず、エラーが起きていることが考えられます。 Cloud Storage トリガで Cloud Run functions 第2世代（実体は Cloud Run）を呼び出す際に、背後では Eventarc と Pub/Sub が動いています。このときサービスアカウントの認証情報を使って関数が呼び出されますが、サービスアカウントには Cloud Run サービス起動元（ roles/run.servicesInvoker ）ロールもしくは Cloud Run 起動元（ roles/run.invoker ）ロールが必要です。なお前者のロールのほうが権限が小さく、最小権限の原則に従っています。 権限不足は、以下のコマンドで対象のサービスアカウントに Cloud Run サービス起動元（ roles/run.servicesInvoker ）ロールを付与することで解決します。 PROJECT_ID = " プロジェクト ID に置き換えてください " SA_NAME = " サービスアカウント名に置き換えてください " gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SA_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =' roles/run.servicesInvoker ' なお、付与すべきロールは Cloud Functions 起動元（ roles/cloudfunctions.invoker ）ロール ではない ことに注意してください。このロールは、第1世代の古い Cloud Run functions 関数を起動するためのロールです。 もし関数のデプロイ時に --service-account オプションで関数自体にサービスアカウントをアタッチしており、かつ --trigger-service-account オプションを指定 しなかった 場合は、 --service-account オプションで指定したサービスアカウントが Eventarc に設定されます。またいずれのオプションも指定しなかった場合は、Eventarc と関数の両方に Comute Engine のデフォルトサービスアカウントが設定されます。Eventarc にどのサービスアカウントが設定されているかは、Google Cloud コンソールで Eventarc トリガーの一覧画面に遷移し、関数の名前を含むトリガーの設定を閲覧することで確認することができます。そのサービスアカウントに、Cloud Run サービス起動元（ roles/run.servicesInvoker ）ロールを付与してください。 ローカルでのテスト 以下の記事に functions-framework を使ってローカル環境で Cloud Run functions 関数の単体テストを行う方法が書いてあります。 blog.g-gen.co.jp functions-framework を使える環境が整ったら、以下のように仮想 function を起動します。 functions-framework --debug --target main 以下のような curl コマンドで CloudEvents を再現して単体テストを実行できます。 curl localhost:8080 \ -X POST \ -H " Content-Type: application/json " \ -H " ce-id: 123451234512345 " \ -H " ce-specversion: 1.0 " \ -H " ce-time: 2022-09-17T05:59:11.036Z " \ -H " ce-type: google.cloud.storage.object.v1.finalized " \ -H " ce-source: //storage.googleapis.com/projects/_/buckets/gcs-function-test " \ -H " ce-subject: objects/animal_panda.png " \ -d ' { "bucket": "gcs-function-test", "contentType": "image/png", "kind": "storage#object", "md5Hash": "...", "metageneration": "1", "name": "animal_panda.png", "size": "214319", "storageClass": "STANDARD", "timeCreated": "2022-09-17T05:59:11.036Z", "timeStorageClassUpdated": "2022-09-17T05:59:11.036Z", "updated": "2022-09-17T05:59:11.036Z" } ' この curl リクエストは gcs-function-test バケットに animal_panda.png というファイルが置かれたときのイベントを再現しています。 参考 : ローカル関数の呼び出し 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Cloud Run functions で Python プログラムを動作させる際に、ログをどのように扱い、出力させればよいかについてご紹介します。 Cloud Run functions のログ出力 標準出力と標準 logger Cloud Logging ライブラリ ライブラリのインストール サンプルコード 実行結果 Cloud Run functions のログ出力 標準出力と標準 logger Cloud Run functions や Cloud Run services 等で動作するプログラムが標準出力に文字列を出力すると、 自動的に Cloud Logging にログとして記録されます。つまり Python プログラムで print するだけで、テキストを Cloud Logging に送信できます。 参考 : 構造化ロギング - Google Cloud observability 参考 : Cloud Run でのログの記録と表示 - Cloud Run print 文により Cloud Logging に送出されたテキスト Cloud Logging ライブラリ 本番運用におけるトラブルシューティングなどをスムーズに行うためには、 Cloud Logging エントリに severity （重要度）を反映したり、 JSON 形式で追加の情報を持たせてそれをもとにフィルタしたりと、 Cloud Logging の強力なフィルタ機能と組み合わせて利用することが有用です。 Cloud Logging のログエクスプローラーに表示される severity severity の一覧 前述の print や logging で単純に文字列を出力しただけでは、Cloud Logging のログエントリに severity を反映することはできません。標準 logging ライブラリでログレベルを設定して出力したとしても、Cloud Logging 上では全て Default ログレベルとして表示されてしまいます。ログレベルを反映するには JSON 形式でログを構造化し、 severity というキーを含めることで反映させることができます。 print や標準 logger ではログレベルが全て Default になる しかし、Cloud Run functions で動作するプログラムで Cloud Logging の クライアントライブラリ を使用することで、簡単にログレベル（severity）を反映させたり、カスタム属性を追加することができます。 参考 : Python 用 Cloud Logging の設定 ライブラリのインストール pip コマンドで実行環境に google-cloud-logging をインストールします。 Cloud Run functions へデプロイした際に実行環境にライブラリが追加されるよう、 requirements.txt にも反映してください。 pip install google-cloud-logging サンプルコード 比較のため、 Cloud Logging ライブラリを用いる場合と用いない場合の2パターンの Cloud Run functions 関数を作成します。 1. Cloud Logging ライブラリ無し #!/usr/bin/env python import logging # 標準 Logger の設定 logging.basicConfig( format = "[%(asctime)s][%(levelname)s] %(message)s" , level = logging.DEBUG ) logger = logging.getLogger() def main (request): logger.critical( "This is a CRITICAL log entry." ) logger.error( "This is an ERROR log entry." ) logger.warning( "This is a WARNING log entry." ) logger.info( "This is an INFO log entry." ) logger.debug( "This is a DEBUG log entry." ) return "OK" 2. Cloud Logging ライブラリ使用 #!/usr/bin/env python import logging import google.cloud.logging # 標準 Logger の設定 logging.basicConfig( format = "[%(asctime)s][%(levelname)s] %(message)s" , level = logging.DEBUG ) logger = logging.getLogger() # Cloud Logging ハンドラを logger に接続 logging_client = google.cloud.logging.Client() logging_client.setup_logging() logger.setLevel(logging.DEBUG) def main (request): logger.critical( "This is a CRITICAL log entry." ) logger.error( "This is an ERROR log entry." ) logger.warning( "This is a WARNING log entry." ) logger.info( "This is an INFO log entry." ) logger.debug( "This is a DEBUG log entry." ) return "OK" 前者のコードと後者のコードの差は、4行目の import 文と、13〜16行目のみです。 13〜16行目では、Cloud Logging のクライアントを生成して標準 logger ライブラリと接続させています。これによりロガーに送出されたログは、全て Cloud Logging に送信されます。 参考 : Python 用 Cloud Logging の設定 参考 : Integration with Python logging module 実行結果 上記の Python プログラムを Cloud Run functions（第2世代）にデプロイし、実行しました。 1. Cloud Logging ライブラリ無し 標準 logger 標準 logger で指定したログレベルは、Cloud Logging ログエントリの severity として反映されていません。 2. Cloud Logging ライブラリ使用 Cloud Logging クライアントライブラリ Cloud Logging ライブラリを使用した場合、ログエントリの左端に色付きで severity が表示されているのが分かります。ソースコード内で指定したログレベルが、Cloud Logging ログエントリの severity として反映されています。 Cloud Logging クライアントライブラリと統合されていることにより、ログレベルのほか「実行ファイル名」「ログ送出元の関数名（main）」「ログが発生したプログラムの行数」などもログに含まれています。 様々な付加情報 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Google Cloud のサービスではなく、同じく Google によって提供されている Firebase について解説していきます。 Firebase とは Firebase と Google Cloud の共通点・相違点 共通点 プロダクト プロジェクト 料金の請求 アクセス制御 利用規約 ユーザーアカウント 相違点 Firebase プロダクトの概要 Build プロダクト Release & Monitor プロダクト Engage プロダクト 料金 権限管理 Built with Firebase Firebase とは Firebase は Firebase, Inc. が 2011 年に開発し、2014 年に Google が買収した モバイル・Web アプリケーション開発プラットフォームです。 2022 年 9 月 現在、Google Cloud のサービスには含まれていませんが、一部のプロダクトや請求が Google Cloud と統合されています。 Firebase は BaaS ( Backend as a Service ) もしくは MBaaS (Mobile Backend as a Service) と呼ばれるサービス形態となっており、アプリケーションが必要とするサーバ機能が一括して提供されます。 BaaS によりユーザーによる運用保守が不要なバックエンド環境が提供され、ユーザーはフロントエンドの開発に専念することができます。 Firebase では、Web ページのホスティング、アプリケーションの認証、NoSQL データベースなどの基本的な機能から、アプリのテストやリリース、モニタリングをサポートする機能、そして Google Analytics や Google Cloud サービス（Cloud Storage、Cloud Functionsなど）との連携が提供されます。 Firebase と Google Cloud の共通点・相違点 共通点 プロダクト Firebase と Google Cloud は、 Cloud Firestore 、 Cloud Functions 、 Cloud Storage の 3 つが共有されたプロダクトとして提供されています。 これらのプロダクトは、Firebase と Google Cloud のどちらのコンソールからでも管理することができ、サーバー SDK ( Google Cloud ) とクライアント SDK (Firebase) の両方からアクセスすることができます。 プロジェクト Firebase のプロダクトを利用するためには、作成するリソースの管理単位である Firebase プロジェクト を作成する必要があります。 ここで作成するプロジェクトは 内部的に Google Cloud のプロジェクトと同じもの となっており、既存の Google Cloud プロジェクトを Firebase プロジェクトとして利用することも、その逆も可能です。 料金の請求 料金はプロジェクト単位で請求されます。 Firebase でも Google Cloud 同様、請求先アカウントをプロジェクトに紐付けます。 請求先アカウントの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp アクセス制御 Google Cloud 同様、プロジェクトレベルのロールベースアクセス制御が可能です。 Firebase のコンソールからはプロジェクトの オーナー 、 編集者 、 閲覧者 の基本ロールと、 Firebase の事前定義ロール を設定できます。 利用規約 2022年 9 月現在、以下の Firebase プロダクトは、 Google Cloud の利用規約 のもとで提供されます。 Firebase Authentication Cloud Storage for Firebase Cloud Functions for Firebase Cloud Firestore Firebase Test Lab 今後、より多くの Firebase プロダクトが Google Cloud 利用規約に移行していくようです。 ユーザーアカウント Firebase と Google Cloud に対しては、Google アカウントを使用してアクセスすることが可能です。 相違点 Firebase は Google のモバイル開発プラットフォームであり、クライアントサイドのアプリケーションの開発者によって利用されることが想定されています。 Firebase では、新規アプリの構築と既存アプリへの機能追加、ユーザーの拡大に焦点が当てられます。 Google Cloud はクラウドコンピューティングサービスのスイートであり、バックエンド、サーバーサイドの開発者による利用が想定されています。 Google Cloud は、Google のインフラストラクチャ（コンピューティング、ストレージ、ネットワーキング、データ分析、機械学習）を活用した開発に利用されます。 Firebase プロダクトの概要 Firebase のプロダクトは、大きく 3 つのカテゴリに分けられます。 当記事では、各プロダクトを概要レベルで紹介していきます。 Build プロダクト Build プロダクト は、主にアプリに必要なマネージドな（ユーザーによる管理が不要な）インフラストラクチャを提供するプロダクトです。 プロダクト 説明 Cloud Firestore Firebase の最新のデータベースで、スケーラブルな NoSQL データベース です。 データはドキュメントとして保存され、柔軟な階層型データ構造をもつドキュメントを高機能なクエリで扱うことができます。 すべてのクライアントアプリ間の リアルタイムなデータ同期 が行われます。 デバイスがオフラインのときは、データキャッシュを用いた オフラインのデータ読み書き を実行できます。デバイスがオンラインに戻るとローカルの変更がすべて同期されます。 データはリージョン内（複数ゾーン）、もしくはマルチリージョンでレプリケーションされます。 Realtime Database Firebase に従来からあるデータベースで、Cloud Firestore と同じ NoSQL データベース です。 データは JSON 形式で保存され、Cloud Firestore と比較すると複雑な階層型データの取り扱いには向きません。 Cloud Firestore 同様、 リアルタイムなデータ同期 と オフラインの読み書き が提供されています。 Cloud Firestore と比較すると、 リアルタイム同期におけるレイテンシの低さ が特長となっています。より詳細な比較についてはこちらの ドキュメント もご一読ください。 Firebase Extensions 2022 年 9 月現在 ベータリリースのプロダクトです。 パッケージ化されている既存のソリューションを自分のアプリの拡張機能として使用することができます。 ソリューションには Google が提供する 公式 Firebase Extension と、パブリッシャーから提供される 早期アクセス パートナー拡張機能 があります。 拡張機能は Cloud Functions 関数として実装されており、Firebase 上のイベントや HTTPリクエスト 、Cloud Scheduler イベントなどのトリガーがあらかじめ定義されています。 App Check 承認されていないクライアントがバックエンドリソースにアクセスするのを防ぐことができます。 保護対象のバックエンドリソースとしては Cloud Firestore 、Realtime Database 、Cloud Functions 、Cloud Storage がサポートされています。 認証プロバイダとして Apple プラットフォームの DeviceCheck または App Attest 、Android の Play Integrity または SafetyNet 、Web アプリの reCAPTCHA v3 または reCAPTCHA Enterprise が使用できるほか、カスタムプロバイダとしてその他サードパーティや独自のプロバイダの利用も可能です。 Cloud Functions Firebase 上のアプリの動作拡張として、Cloud Functions 関数を Firebase アプリのサーバーサイドのロジックとして使用できます。 関数は JavaScript 、TypeScript で実装します。 呼び出し元がクライアントサイドの Firebase SDK になりますが、基本的には Google Cloud の Cloud Functions と同じ仕様となっています。 Authentication OAuth 2.0 や OpenID Connect などの業界標準に準拠したユーザー認証機能を Firebase アプリに実装することができます。 また、 Firebase Authentication with Identity Platform にアップグレードすることで、多要素認証やユーザーアクティビティのモニタリング、監査ロギング、その他様々な追加機能が利用できます。 Hosting 静的コンテンツと動的コンテンツの両方を Firebase のフルマネージド環境にホスティングできます。 Cloud Functions と組み合わせることで、Firebase 上でマイクロサービスを構築することができます。 SSD ストレージとグローバル CDN が基盤となっており、コンテンツを高速で配信することができるほか、組み込みの SSL が提供されます。 Cloud Storage Cloud Storage 用の Firebase SDK により、クライアントアプリケーションから Google Cloud Storage バケットに対して直接ファイルをアップロード、ダウンロードできます。 デバイスのネットワーク接続状況が悪いときでも、アップロードを中断、再開できます。 Firebase ML 2022 年 9 月現在 ベータリリースのプロダクトです。 パッケージ化された機械学習モデルをクラウド、もしくはクライアントアプリに実装することができます。 カスタムモデル API 、 AutoML Vision Edge はクライアントデバイス上で ML モデルによる推論を実行できます（ オンデバイスモデル ）。オンデバイスモデルではネットワーク接続が必要ないため、高速で推論を行うことができます。 テキスト認識、画像ラベリング、ランドマーク認識 API はクラウド上で ML モデルによる推論が実行されます。オンデバイスモデルと比較してクラウドの豊富な計算資源を利用できるため、精度の高い推論を行うことができます。 Firebase Local Emulator Suite 2022 年 9 月現在 ベータリリースのプロダクトです。 ローカルで Firebase アプリを開発するために、Firebase サービスの動作を正確に再現するためのツールセット（エミュレータ）が提供されます。 Release & Monitor プロダクト Release & Monitor プロダクト は、主にアプリのテストやリリース、リリース後の品質改善に役立つツールが提供されます。 プロダクト 説明 Firebase Crashlytics Apple 、Android 、Flutter 、Unity で動作するリアルタイムのクラッシュレポートツールを利用できます。 アプリのクラッシュに対して重要度付けをしてグループ化し、トラブルシューティングしやすくできるほか、重要度の大きいクラッシュをリアルタイムに通知できます。 また、Google Analytics と統合することで、特定のクラッシュデータを細かく分析したり、クラッシュ前のイベントを追跡したりできます。 Firebase Performance Monitoring Performance Monitoring SDK を使用してアプリからパフォーマンスデータを収集し、コンソール上で Firebase アプリのパフォーマンスの問題をリアルタイムに分析できます。 Firebase Test Lab Google のデータセンターでホストされている iOS 、Android デバイス上で、Firebase アプリをテストすることができます。 Firebase App Distribution 開発途中の Firebase アプリを効率的にテスターに配布することができるプラットフォームが提供されます。 テスターをグループで管理し、アプリの配布や通知を行うことができます。 Google Analytics や Firebase Crashlytics と併用することで、配布したアプリのログを収集、分析することも可能です。 Engage プロダクト Engage プロダクト は、主にユーザーエクスペリエンスの最適化に役立つツールが提供されます。 プロダクト 説明 Remote Config ユーザーがアプリをアップデートしなくても、サーバー側で変更したパラメータをすべてのユーザーのアプリに対してオーバーライドすることで、アプリの動作や外観を変更することができます。 パーセンテージロールアウト 機能を使用し、アプリのアップデートを一定の割合のユーザーに段階的に配信することができます。 Google Analytics Google Analytics の機能を Firebase に統合し、Firebase SDK で定義できる最大 500 種類のイベントに関してレポートを生成することができます。 デバイスデータ、カスタムイベント、ユーザープロパティなどの情報をもとにカスタムのユーザーリストを定義し、新機能や通知メッセージのターゲットとして Firebase の他の機能からリストを使用することができます。 Firebase A/B Testing 2022 年 9 月現在 ベータリリースのプロダクトです。 Google オプティマイズ の機能を利用することで、小規模な範囲のユーザーに A/B テストを実施してアプリの変更をテストしつつ、収益などの主要な指標への影響を確認することができます。 Cloud Massaging と連携して様々なマーケティングメッセージのテストをしたり、Remote Config と連携して様々なパラメータのアプリをテストすることで、アプリのどの動作や外観が最も高い効果を発揮できるのかを確認したりできます。 Cloud Messaging 特定の端末、端末のグループ、トピックのいずれかに対して、通知メッセージを無料で確実に送信することができます。 エンドユーザーのデバイスに通知を表示させる 通知メッセージ と、クライアントアプリが処理するためのメッセージを送信する データメッセージ の 2 種類のメッセージを送信することができます。 Firebase Dynamic Links 異なるプラットフォーム上で同じように動作する ディープリンク を実装することができます。 また Google Analytics による、リンクに関するイベントのトラッキングの情報を、 Firebase コンソール上で分析できます。 Firebase In-App Messaging 2022 年 9 月現在 ベータリリースのプロダクトです。 ターゲットのアプリ画面に対して、バナーやポップアップなどの形式でメッセージを表示することができます。 表示するメッセージは Firebase コンソール上（GUI で）カスタマイズすることができます。 料金 Firebase では 2 種類の料金プランが提供されています。 以前は Flame プランという定額制のプランもありましたが、現在は廃止されており、既存の Flame プランのプロジェクトはすべて Spark プランにダウングレードされています。 プラン 説明 Spark プラン 無料のプランで、月ごとのリソース使用量制限があります。 リソース使用量の制限を超過すると、アプリが利用不可になってしまいます。 検証環境向けのプラン。 Blaze プラン 従量課金制のプランで、プロジェクトに対して請求先アカウントの紐付けが必須となります。 プロダクトによっては無料枠あります。 Google Cloud のサービスを利用してアプリの機能を拡張することができます。 本番環境向けのプラン。 プロダクトごとの使用量制限や従量課金については ドキュメント をご一読ください。 Google Cloud 側でプロジェクトに対して請求先アカウントを紐付けた場合、Firebase のプランは自動的に Blaze プランにアップグレードされます。 逆に、Google Cloud 側でプロジェクトと請求先アカウントの紐付けを解除した場合、Firebase のプランが自動的に Spark プランにダウングレードされます。 プランをダウングレードした際、Blaze プランでのみアクセスできるプロダクトを使っていたり、Spark プランの無料利用制限を超えていた場合、再度 Blaze プランにアップグレードするまで Firebase にデプロイしたアプリが使用できなくなったり、有料のサービスが利用できなくなったりします。 権限管理 プロジェクト内の各 Firebase プロダクトに対するアクセス制御は、Google Cloud 同様に Google アカウント 、 Google グループ 、 サービスアカウント に対して ロール を割り当てることで行います。 ロールの種類 説明 基本ロール Google Cloud を含めたすべてのプロダクトに対するアクセス権を設定するロールです。 過剰な権限を与えてしまうことになるため、基本的には利用は推奨されていません。 以下の 3 種類の基本ロールがあります。 ・オーナー ・編集者 ・閲覧者 事前定義ロール 基本ロールよりも詳細にアクセス権を制御できるロールです。 Firebase における事前定義ロールは以下の ３ つに分類されます。 ・Firebase レベルのロール （ Firebase 全体に対するアクセス権を設定 ） ・プロダクトカテゴリのロール （特定カテゴリの複数の Firebase プロダクトに対するアクセス権を設定 ） ・プロダクトレベルのロール （ 特定の Firebase プロダクトに対するアクセス権を設定 ） カスタムロール ユーザーが構成した独自の権限セットを含む、カスタマイズされたロールです。 最小権限の原則 に従い、細かなアクセス制御を行うことが推奨されています。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。 Google Cloud (旧称 GCP) の強力なネットワークインフラサービスである External Application Load Balancer (外部アプリケーションロードバランサ) について解説します。 サービスの概要 Cloud Load Balancing とは ロードバランサーの種類 名称変更 External Application Load Balancer とは 3 種類の External Application Load Balancer ユースケース 料金 Cloud Load Balancing の料金体系 計算例 計算条件 計算式 ロードバランサーの選び方 9 種類からの選択 Global vs Regional Global vs Regional の留意点 新型 vs 従来型 External Application Load Balancer の機能 バックエンドへの負荷分散 ヘルスチェック トラフィック管理 SSL/TLS SSL/TLS の終端 (オフロード) Google マネージド証明書 バックエンドまでの暗号化 耐障害性 プロキシと HTTP ヘッダー ロギング モニタリング Cloud CDN と Cloud Armor プレミアムティアとスタンダードティア Google のネットワークティア ロードバランサーの利用するティア プレミアムティアの挙動 External Application Load Balancer の内部構成（アーキテクチャ） アーキテクチャの概要 転送ルール（Forwarding rule） ターゲットプロキシ（Target proxy） URL マップ（URL map） バックエンドサービス / バックエンドバケット Web コンソールの表記 高度なアーキテクチャ VPC・プロジェクトをまたぐ負荷分散 グローバルな可用性 サービスの概要 Cloud Load Balancing とは Cloud Load Balancing とは Google Cloud が提供する仮想的なロードバランサです。 クライアントからのリクエストを受け、背後にある複数の Compute Engine VM や Cloud Storage バケット等にトラフィックを負荷分散 (ロードバランス) します。 Cloud Load Balancing は仮想的・論理的な存在であり、 分散型アーキテクチャ です。また フルマネージドサービス でもあります。そのため、我々利用者はインフラを考慮・管理する必要がありません。 毎秒 100 万件以上のリクエストに対応でき、安定した高パフォーマンス・低レイテンシが提供されます。 またスケーリングも自動的に行われます。トラフィックがゼロの状態から例え急激なスパイクが発生しても対応できます。プレウォーミング (暖機運転) も必要ありません。 ロードバランサーの種類 Cloud Load Balancing には9種類の用途別のロードバランサーが用意されており、適切なものを選択して利用することになります。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer Regional internal Application Load Balancer Global external proxy Network Load Balancer Regional external proxy Network Load Balancer Regional internal proxy Network Load Balancer Regional external passthrough Network Load Balancer Regional internal passthrough Network Load Balancer 種類が多く難しいようですが「Global か Regional か」「External か Internal か」「Application か Network か (プロトコル)」「プロキシ型かパススルー型か」といった軸で別れています。 名称変更 Cloud Load Balancing は 2023/06/21 にリブランディングが行われ、旧名称から変更されました。 これまで10種類だったロードバランサは9種類に統合され HTTP(S) トラフィックを扱う Application Load Balancer とその他の TCP/UDP トラフィックを扱う Network Load Balancer に大別できるようになりました。 Cloud Load Balancing の名称変更 なお当記事で扱う External Application Load Balancer は、従来でいう External HTTP(S) Load Balancing に当たります。 External Application Load Balancer とは 9 種類のロードバランサーのうち、当記事では以下の 3 つを総称して External Application Load Balancer (外部アプリケーションロードバランサ) として解説します。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer External Application Load Balancer は「外部向け (External)」の「HTTP(S) プロトコル」用ロードバランサの総称です。パブリック IP アドレスを持っており インターネットからのリクエスト を受け付けます。これが「外部 (External)」の意味です。 また External Application Load Balancer は「プロキシ型」であり TCP コネクションをいったんロードバランサーで終端 します。 その後、再度バックエンドの VM 等に TCP コネクションを作成します。そのため、バックエンドから見ると 接続元 IP アドレスはロードバランサになります 。 また「レイヤ 7」ロードバランサーであり、対応しているプロトコルは HTTP / HTTPS です。使える TCP ポート番号は 80/8080 (HTTP) と 443 (HTTPS) のみであり、その他のプロトコルやポート番号を使いたい場合は別のロードバランサを選択します。 3 種類の External Application Load Balancer 当記事で取り上げる以下の 3 種類のロードバランサーの違いについて説明します。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer 1. Global external Application Load Balancer と 2. Global external Application Load Balancer (Classic) は新型・旧型の関係であり、細かい違いがあるものの基本的には同じ理解が適用できます。 1. Global external Application Load Balancer と 3. Regional external Application Load Balancer の違いは、Global か Regional かです。 Global は、複数のリージョン (世界中) にフロントエンドが分散しています。世界中のユーザーは、自動的に最も近いフロントエンドにルーティングされ、最適なネットワーク経路を辿ってバックエンドまで到達できます (プレミアムティアの場合。後述) 。 Regional は、特定のリージョンにのみフロントエンドを配置します。バックエンドが同一のリージョン内に存在するためスタンダードティアネットワークを使って料金を抑えたい (後述) 場合や、法令遵守のためにトラフィックを特定のリージョンに留めたい場合に用います。 ユースケース External Application Load Balancer が活躍する最も代表的なケースは以下のような、Web/AP サーバへのリクエストの振り分けです。 Web/AP サーバへのリクエスト振り分け ロードバランサの配下の Compute Engine VM は インスタンスグループ でまとめられており、オートスケーリングを設定することもできます。この場合、負荷状況に応じてインスタンスが増減し、自動的にロードバランサーがトラフィックを振り分けます。 その他にも複雑なユースケースが考えられます。以下の参考ドキュメントもご参照ください。 参考 : 外部アプリケーション ロードバランサのユースケース 料金 Cloud Load Balancing の料金体系 Cloud Load Balancing の料金 は「 内部 (Internal) の Application Load Balancer」と「それ以外」で料金体系が異なります。当記事でご紹介しているのは 3 つとも Application Load Balancer ですので、同じ料金の計算方法が適用できます。 Application Load Balancer の料金には以下の軸があります。 転送ルール数 × 利用時間 の従量課金 内向き (Inbound = Ingress) のデータ処理量 (GB) に応じた従量課金 外向き (Outbound = Egress) のデータ処理量 (GB) に応じた従量課金 1つ目の料金軸の 転送ルール (Forwarding rules) については後述しますが、簡単に言うとロードバランサーの「入り口」です。転送ルールの料金はロードバランサを構築後、存在し続けている限り発生すると考えればよいでしょう。 計算例 計算条件 大まかな料金のイメージを掴むために実際の例で計算してみます。 以下のような構成のロードバランサーの料金を試算してみます。 課金軸 数量 転送ルール HTTPS (443/tcp) / Premium tier 内向きトラフィック 1 KB のリクエストが 1000 万回 / 月 ≒ 10 GB 外向きトラフィック 0.1 MB のレスポンスが 1000 万回 / 月 ≒ 1,000 GB 計算式 記載の単価は2023年6月現在の Global external Application Load Balancer・東京リージョンのものです。最新の料金や詳細は必ず 公式の料金表 をご参照ください。 課金軸 計算式 計 転送ルール ( ※ ) $0.025 * 730h $18.25 /月 内向きトラフィック $0.012 * 10 GB $0.12 /月 外向きトラフィック $0.012 * 100 GB $1.2 /月 合計 $18.25 + $0.12 + $1.2 $19.57 / 月 ※ 最初の5ルールまでの範囲内とする なお、上記はロードバランサだけの料金であり、これに加えて Google Cloud のネットワーク外向き (Outbound = Egress) の 転送料金 が発生することに注意が必要です。上記の例では $0.14 * 100 GB で $14 となります。 ロードバランサーの選び方 9 種類からの選択 9 種類あるロードバランサーから適切な選択をするには、以下のドキュメントを参照します。 参考 : ロードバランサの選択 以下は同ドキュメントから引用したフローチャート図です。 このドキュメントと図に沿って適切なロードバランサーを選択するのが基本的な考え方になります。 公式ドキュメント から引用 当記事で取り上げる External Application Load Balancer は「バックエンドのサービスが提供するプロトコルが HTTP(S) である場合」に選択するロードバランサですので、最も利用機会が多いものとなります。 次に 3 つの External Application Load Balancer の中からどのように適切なロードバランサを選択するか、について解説します。 Global vs Regional 3種類ある External な Application Load Balancer は、以下のうち前者の2つが Global で、最後が Regional です。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer 以下の 全て に当てはまる場合は Regional が選択できます。 サービス利用者が特定の国や地域だけである バックエンド (VM 等) が単一リージョンだけであり利用者の地域と一致している バックエンドサービスは Compute Engine Cloud Run GKE など Regional に対応しているサービスである Cloud CDN は使わない (将来も利用予定がない) 一方で以下の いずれか に当てはまる場合は Global なロードバランサーが適切です。 サービスの利用者が複数の国や地域に跨っている バックエンド (VM 等) が複数リージョンに跨っている バックエンドとして Cloud Functions App Engine Cloud Storage を使いたい (Regional では対応していない) Cloud CDN を使う (または将来使う可能性がある) Global vs Regional の留意点 見落としがちなポイントとして、 Global と Regional では対応しているバックエンドのサービスが異なることに注意が必要です。 3. Regional external Application Load Balancer ではバックエンドに Cloud Storage バケットや Cloud Functions 関数を指定することができません。 対応しているバックエンドを始め、ロードバランサー種別ごとの機能の差異は以下のドキュメントで確認できます。 参考 : ロードバランサの機能比較 新型 vs 従来型 Global を使おうと考えたとき、 1. Global external Application Load Balancer と 2. (Classic) は「新旧」の差ですので、原則的には新型である 1. を選択するべきです。 公式ドキュメントの詳細な機能比較を見て、従来型 ( 2. ) でしか実現できない要件がある場合のみ、従来型を選びます。 参考 : 機能の違い また、新型 ( 1. ) のほうが従来型より高度な信頼性・スケーラビリティを実現できるよう、アーキテクチャが改善されています。Google としては、従来型から新型への移行を推奨しています。 参考 : Increasing Resiliency with Load Balancers 参考 : グローバル外部アプリケーション ロードバランサへの移行を計画する External Application Load Balancer の機能 バックエンドへの負荷分散 External Application Load Balancer の最も基本的な機能は、インターネットからのトラフィックをバックエンドに負荷分散することです。 バックエンドとして以下のような多様な選択肢があります。 Compute Engine Cloud Storage Cloud Run App Engine Cloud Functions Google Kubernetes Engine (GKE) オンプレ (ハイブリッド NEG) ただし前述の通り Global か Regional かによって 利用可能なバックエンド が異なりますので注意が必要です。 ヘルスチェック 配下のインスタンス等が障害を起こしてサービス停止状態になった場合、ロードバランサーはトラフィックを正常なインスタンスにのみ振り分けます。それには、ロードバランサーが配下のサービスが正常動作しているかを知る必要があります。 ロードバランサーからは定期的に ヘルスチェック が実行されます。例えば 1 分に一度、 HTTPS リクエストを各インスタンスに投げ、 200 OK を正常とみなすなどです。 ロードバランサーから配下のサービスへのヘルスチェックが通るようにするためには VPC ファイアウォール 等での許可設定が必要です。 External Application Load Balancer では以下の IP アドレスを接続元としたアクセスを許可する必要があります。 35.191.0.0/16 130.211.0.0/22 詳細な設定内容等は以下のドキュメントを参照してください。 参考 : ヘルスチェックの概要 トラフィック管理 外部ロードバランサには トラフィック管理機能 があり「トラフィックのミラーリング」「重み付けに基づくトラフィック分割」「リクエスト / レスポンス ベースのヘッダー変換」などを実現できます。大まかに分けると以下のようになります。 名称 概要 トラフィックステアリング HTTP(S) パラメータ (ホスト、パス、ヘッダー、その他のリクエスト パラメータ) に基づいたルーティング トラフィック アクション リクエストとレスポンスに基づいたリダイレクト、ヘッダー変換、URL 書き換えなどのアクション トラフィック ポリシー セッションアフィニティ、バランシングのアルゴリズムなどの指定 トラフィック管理は Cloud Load Balancing の最も強力な機能の一つです。 例えば「 通常のトラフィックは VM の Web サーバに振り分ける。 /image/* 以下の画像ファイルは Cloud Storage バケットに振り分ける 」のような振り分けも、簡単にできてしまいます。これによりストレージコストの削減とレスポンスの改善が実現されます。 ロードバランサにより実現可能な機能が細かく異なるため、詳細は以下をご参照ください。 参考 : グローバル外部アプリケーション ロードバランサのトラフィック管理の概要 参考 : 従来のアプリケーション ロードバランサにおけるトラフィック管理の概要 参考 : リージョン外部アプリケーション ロードバランサのトラフィック管理の概要 SSL/TLS SSL/TLS の終端 (オフロード) 今日の Web サービスでは HTTPS による通信の暗号化がほぼ必須と言えます。 Cloud Load Balancing では SSL/TLS の終端 (オフロード) が可能です。 自分で別途証明書を用意して セルフマネージド証明書 として Google Cloud にアップロードし、ロードバランサで利用することができます。 一方で Google Cloud から証明書を発行することもでき、これは Google マネージド証明書 と呼ばれます。 なお、ロードバランサ側で簡単に HTTP から HTTPS へのリダイレクトを設定 することができます。 Google マネージド証明書 Google Cloud 側で発行する SSL/TLS 証明書を Google マネージド証明書 と呼びます。 Google マネージド証明書は ドメイン検証（DV）証明書 です。また複数のドメイン名を登録することが可能ですが、ドメイン名にワイルドカードを使うことはできません (例 : *.example.com ) 。 ただし Google マネージド証明書は Regional のロードバランサでは使えないことに注意が必要です 。Google マネージド証明書が使えるのは、以下のロードバランサーのみです。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Global external proxy Network Load Balancer (with a target SSL proxy) また Google マネージド証明書はエクスポートしたりダウンロードしたりすることは できません 。Cloud Load Balancing でのみ使用できる証明書です。 発行するには証明書のドメインの DNS ゾーンに Google から払い出された CNAME レコードを登録する、もしくはロードバランサーの IP アドレスを A レコードとして登録する必要があります。詳細な手順は以下を参照してください。 参考 : Google マネージド SSL 証明書を使用する バックエンドまでの暗号化 ロードバランサーが SSL/TLS を終端した後、ロードバランサとバックエンドの通信は非暗号化の HTTP プロトコルで通信させることができます。 この場合でも Google Cloud の標準の仕組みにより 通信は全て透過的に暗号化され ます ( ネットワークレベルの自動暗号化 ) 。 耐障害性 Cloud Load Balancing は分散アーキテクチャの仮想的なロードバランサであり、高い可用性を持ちます。 Global なロードバランサはその名の通り全リージョンに分散されているのでゾーンレベルの可用性に加えあるリージョン全体が万一停止しても可用性を維持できます。 Region のロードバランサは、選択したリージョン内の複数ゾーンに分散されるので、ゾーン停止に対しての可用性は維持されますがリージョン全体が停止した場合には利用できなくなります。 なお Cloud Load Balancing では Compute Engine サービスの一部の扱いで Service Level Agreement (SLA) が定義されており、詳細は以下のドキュメントで確認可能です。 参考 : Compute Engine Service Level Agreement (SLA) プロキシと HTTP ヘッダー External Application Load Balancer はプロキシ型のロードバランサであるため、一度 TCP 接続を終端します。つまりバックエンドのサーバから見ると IP ヘッダの送信元 IP アドレスはロードバランサーのものとなります。 これでは本来の接続元であるクライアントの IP アドレスを特定することはできません。 これに対処するため (こういったプロキシ型のロードバランサでは一般的ですが) HTTP リクエストに X-Forwarded-For ヘッダがロードバランサによって 追記されます 。 また他にも、ロードバランサまでの接続プロトコル (http or https) を示す X-Forwarded-Proto や Google サービスを経由したことを示す Via : 1.1 google なども付与されます。 これらはデフォルトでロードバランサによって付与されるヘッダですが、任意の カスタムヘッダ を付与するように指定することも可能です。 ロギング Cloud Load Balancing ではアクセスログを有効化して Cloud Logging に出力することができます。 ロードバランサーのコンポーネントの一つである バックエンドサービス / バックエンドバケット (後述) でデフォルトで有効化されています (バックエンド バケット では無効化不可) 。 ログを表示するには Cloud Logging コンソールや gcloud コマンドを利用します。また ログルーティング を用いて、ログをシームレスに BigQuery に投入することも可能です。 Cloud Load Balancing のログには例として以下のような要素が含まれます ( 詳細 ) 。 Key 名 概要 一般的な情報 重大度 / プロジェクト ID / タイムスタンプ等 HttpRequest requestUrl, userAgent, remoteIp, serverIp など HTTP リクエストに関する情報 ( 詳細 ) statusDetails 正常/異常終了時メッセージ。値としてキャッシュヒット有無 (正常時) やエラーの原因 (異常時) が入る モニタリング Cloud Load Balancing は Cloud Monitoring によって自動的にモニタリングされます。 External Application Load Balancer では 1 分毎に指標 (メトリクス) が Cloud Monitoring に送出され、6週間保持されます。 Cloud Monitoring の アラート機能 を使えば、指標に閾値を設定してアラートメールを発報する等の仕組みが簡単に実装できます。 以下はモニタリングされる指標の例です。詳細は 公式ドキュメント を確認してください。 指標名 概要 https/request_count ロードバランサによって処理されたリクエスト数 https/request_bytes_count クライアントからロードバランサへのリクエストとして送信されたバイト数 https/response_bytes_count ロードバランサからクライアントへのレスポンスとして送信されたバイト数 https/backend_latencies GFE がバックエンドに最初のリクエスト バイトを送信してから、バックエンドから最後のレスポンス バイトを受信するまでのレイテンシの分布 Cloud CDN と Cloud Armor Global な External Application Load Balancer では コンテンツ・デリバリ・ネットワークである Cloud CDN やマネージドな WAF である Cloud Armor が利用可能です。 一方で Regional external Application Load Balancer ではこれらの機能は使えません。 ただし、Cloud Armor については Regional external Application Load Balancer での利用が2023年6月に Public Preview 公開され、将来的に一般公開になる見込みです。 参考 : 外部アプリケーション ロードバランサの概要 プレミアムティアとスタンダードティア Google のネットワークティア Google Cloud のネットワークには プレミアムティア と スタンダードティア があります。 プレミアムティアは Google の持つグローバルネットワークを使用するものです。低レイテンシで信頼性の高いことが特徴で、世界中に 100 以上の接続点 (PoP) を持っています。一方のスタンダードティアは、通常のインターネット経由でのトラフィック配信です。 Google Cloud のネットワークティアでは Google Cloud から 出ていくトラフィック量 (= ダウンロードされるデータサイズ) に対して料金が発生します。スタンダードティアのほうがプレミアムティアより安価な値段設定となっていますが、パフォーマンスは劣ります。 参考 : Network Service Tiers の概要 ロードバランサーの利用するティア ロードバランサーの種別によって利用されるティアが異なり、以下のようになっています。 ロードバランサー種別 プレミアムティア スタンダードティア Global external Application Load Balancer ◯ ✕ Global external Application Load Balancer (Classic) ◯ ◯ Regional external Application Load Balancer ✕ ◯ 2. Global external Application Load Balancer (Classic) でのみ、プレミアムとスタンダードから選択できるようになっています。スタンダードを選択した場合は、ロードバランサーのフロントエンドを配置するリージョンを選択することになり、実質的にリージョナルな挙動をしますし、バックエンドもフロントエンドと同じリージョンにある必要があります。 ※このときの Regional external Application Load Balancer との違いは、バックエンドの VPC ネットワークを選ばないという点です ( 参考 )。 プレミアムティアの挙動 プレミアムティアを用いたロードバランサでは エニーキャスト IP アドレス が用いられます。 Google の持つ世界中の PoP の中からクライアントに一番近い PoP が選択されトラフィックが Google のネットワークに入ることで、最適なネットワーク経路が選択されて高いパフォーマンスが発揮されます。その代わり、ダウンロード方向のトラフィックの課金が割高となります。 参考 : All networking pricing このプレミアムティアの利用により、世界中からのトラフィックの経路を最適化できるのが、 Cloud Load Balancing の最大の特徴でもあります。 External Application Load Balancer の内部構成（アーキテクチャ） アーキテクチャの概要 Cloud Load Balancing では、内部的に Google Front End（GFE）、Envoy、Maglev、Andromeda といったテクノロジーが使われています。その実体は Google Cloud の世界中のロケーション（データセンター）に分散配置されています。 参考 : Cloud Load Balancing の概要 External Application Load Balancer の内部構造は、論理的には 4つのコンポーネント で構成されています。ロードバランサを構築・運用していくにあたり、これらの構成に対するある程度の理解が必要です。 転送ルール（Forwarding rule） ターゲットプロキシ（Target proxy） URL マップ（URL map） バックエンドサービス / バックエンドバケット Web コンソールや gcloud コマンドラインでロードバランサを構築したり管理するときにも、上記の用語が登場します。 Google Cloud の Web コンソールからロードバランサを構築する場合、ウィザードに沿って順番にパラメータを指定していくと、これら4つのコンポーネントが自動的に出来上がることになります。 External Application Load Balancer の内部構造 転送ルール（Forwarding rule） 転送ルール は、外部 IP アドレスを持ち、特定のポート・プロトコルをリッスンする（待ち受ける）コンポーネントです。転送ルールは、受け取ったトラフィックをターゲットプロキシ（次項で説明）へルーティングします。 参考 : 転送ルールと IP アドレス 外部ロードバランサを構築すると1つのパブリック IP アドレスが割り当てられますが、これは転送ルールに割り当てられているものです。もしロードバランサに対して www.example.com のようなドメイン名を割り当てる場合、 DNS で CNAME レコードを作り、この IP アドレスに向けることになります。 転送ルールは、待ち受けるポート番号とプロトコルも設定値として持ちます。なお HTTP(S) ロードバランサでは、HTTP では 80/tcp もしくは 8080/tcp 、 HTTPS では 443/tcp しか待ち受けられない仕様です。 また転送ルールには、 Global と Regional の区別、また Premium tier と Standard tier の区別があります。 ターゲットプロキシ（Target proxy） ターゲットプロキシ は、クライアントからの HTTP(S) 接続を終端するコンポーネントです。 参考 : ターゲットプロキシ ターゲットプロキシは、参照する URL マップ（次項で説明）を設定値として持っており、URL マップの設定に基づいてバックエンドサービス / バックエンドバケットにトラフィックを転送します。 前述したとおり、 HTTP リクエストにデフォルト / カスタムの追加ヘッダを付与するのは、このコンポーネントです。 証明書を保持して SSL/TLS を終端するのもこのコンポーネントです。なお Global なロードバランサーの場合、プロキシとバックエンドは異なるリージョンに配置することもできますが、前述の通りロードバランサとバックエンドの間は非暗号化プロトコルでも「ネットワークレベルの自動暗号化」が行われ、透過的に暗号化されます。 参考 : ロードバランサからバックエンドへの暗号化 URL マップ（URL map） URL マップ は、トラフィックルーティングのルール一覧です。前項のターゲットプロキシは、URL マップに定義された URL パターンに基づいて、バックエンドサービス / バックエンドバケットにトラフィックをルーティングします。 参考 : URL マップ 例として、URL マップには以下のような設定を定義できます。 デフォルトのバックエンドサービスを Compute Engine の Web サーバとする /images/* というパスへのアクセスが来たら静的ファイルを保持する Cloud Storage のバックエンドバケットに振り分ける バックエンドサービス / バックエンドバケット バックエンド サービス と バックエンド バケット （Backend service / Backend bucket）は、バックエンドの VM インスタンスや Cloud Storage バケットをグルーピングする論理的なリソースです。 参考 : バックエンド サービスとバックエンド バケット バックエンドサービスの実体として、インスタンスグループ（Compute Engine VM のグループ）を指定したり、サーバーレス NEG（Cloud Run / Cloud Functions / App Engine 等のグループ）指定したりできます。 またバックエンドに通信する際のプロトコル（HTTP、HTTPS、HTTP/2）を指定可能です。 前述のヘルスチェック機能の設定値を保持するのも、バックエンドサービスです。 130.211.0.0/22 か 35.191.0.0/16 の範囲からバックエンドサービスに対してヘルスチェックが行われますが、このときのプロトコルやパスも指定可能です。 Web コンソールの表記 ここまで、External Application Load Balancer を構成する4つのコンポーネントを紹介しました。 しかし、Google Cloud の Web コンソールからロードバランサを構築したり、あるいは設定を表示したりすると、前述の名称とは表記が異なっていることに気が付きます。これが Google Cloud のロードバランサーの理解を難しくしている要因でもあります。 分かりやすく表示するために、Web コンソール画面では4つのコンポーネントをまとめて「ロードバランサ」という1つの論理コンポーネントとして表現しています。 Web コンソールでロードバランサを構築するときの表記と、実際に API リソースとして存在するリソース構成との対照表は、以下のとおりです。 Web 画面での表現 実際のリソース フロントエンド 転送ルール + ターゲットプロキシ ルーティングルール URL マップ バックエンドサービス / バケット バックエンドサービス / バケット 図示すると以下のとおりです。 Web コンソールでの表現と実際のリソース構成の対照 また Web コンソールで構築すると「ロードバランサ」「フロントエンド」などに名称を入力しますが、実際のリソース名称への反映は以下のとおりです。 Web 画面での表現 リソース 「ロードバランサ」の名称 URL マップの名称となる。またターゲットプロキシの名称は ${ロードバランサ名称}-target-proxy となる 「フロントエンド」の名称 転送ルールの名称となる 「バックエンドサービス / バケット」の名称 実際の「バックエンドサービス / バケット」のリソース名称は Web 画面と同じ なお、gcloud コマンドにより単独で URL マップを作成 ( gcloud compute url-maps create ) すると、その URL マップを何にも紐付けなくても、コンソール画面上には「ロードバランサ」として表示されます。 コンソールでは URL マップが「ロードバランサ」として扱われている 高度なアーキテクチャ VPC・プロジェクトをまたぐ負荷分散 External Application Load Balancer では共有 VPC (Shared VPC) を用いることで、VPC ネットワークやプロジェクトをまたいだ負荷分散を行うことができます。 ロードバランサ自体 (転送ルール / ターゲットプロキシ / URL マップ) はホストプロジェクト (共有 VPC の親プロジェクト) またはサービスプロジェクト (共有 VPC を利用する側のプロジェクト) のいずれにも作成できます。一方のバックエンド (負荷分散先の VM 等) は、これらロードバランサ本体コンポーネントと同じプロジェクトに作成することもできますし、他のプロジェクトに作成することもできます。 参考 : Shared VPC architecture グローバルな可用性 特に External Load Balancer で非常に高度な対障害性を得たい場合、以下のようなアーキテクチャも提唱されています。 メインのトラフィックは Global external Application Load Balancer で処理する Regional external Application Load Balancer を各リージョンに配置する 障害時は Global から Regional へ振り分け先をフェイルオーバする Global external Application Load Balancer と Regional external Application Load Balancer はそれぞれ独立した基盤のうえで稼働しているため、片方の大規模障害がもう片方に影響しないという利点があります。そのため、こういったアーキテクチャが可能となっています。 参考 : Increasing Resiliency with Load Balancers なお補足情報として、Google Cloud のフルマネージドサービスである Cloud DNS には ヘルスチェック機能 がありますが Internal passthrough Network Load Balancer と internal Application Load Balancer にしか対応していないため、上記のアーキテクチャで障害時に Global から Regional への自動フェイルオーバさせるためには、Cloud DNS 以外の仕組みでヘルスチェック・自動フェイルオーバを構築する必要があります。 参考 : Manage DNS routing policies and health checks 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it