G-gen の武井です。当記事では、Cloud Billing の機能の一つである FinOps ハブ を使い、Google Cloud のコストを最適化する方法を解説します。 FinOps ハブとは FinOps ハブのダッシュボード 表示方法 画面説明 Recommender による推奨事項 必要な権限 料金 実際に試してみた 推奨事項の確認 詳細の確認 リソースの削除 ダッシュボードへの反映 関連記事 FinOps ハブとは FinOps ハブ とは、Cloud Billing と Recommender（AI による推奨事項を管理する仕組み）によって収集された過去の使用状況に基づき、クラウド利用コストに関するダッシュボードを自動的に生成してくれるサービス（Cloud Billing の一機能）です。 後述する指標にもとづき、コスト最適化につながる推奨事項をダッシュボード上で表示してくれるため、それらをもとに費用の削減や改善のための具体的なアクションにつなげることができます。 FinOps ハブのダッシュボード 表示方法 Google Cloud コンソールから以下の方法でダッシュボードを表示できます。 検索バーに FinOps と入力し、 FinOps ハブ を選択 請求先アカウント を選択し、 FINOPS ハブに移動 をクリック FinOps ダッシュボードが表示 FinOps ハブを選択 請求先アカウント選択後、FinOpsハブに移動 FinOps ダッシュボードが表示 画面説明 ダッシュボードでは以下の情報が確認できます。（2024年10月時点） 項目 概要 Optimization summary（最適化サマリー） ・先月の削減額 ・現時点での推奨事項総数 ・トータルの削減見込み額 / 月 削減見込み / 月 ・すべての推奨事項一覧 ・各推奨事項の削減見込額 / 月 上位の推奨事項 ・すべての推奨事項のうち費用削減額の上位 10 件 FinOps score ・数値化された削減実績 ・スコア改善のヒント CUD optimization ・確約利用割引による前月の削減額 ・確約利用割引による最適化率 詳細については以下の公式ガイドをご確認ください。 参考： FinOps ハブのダッシュボード Recommender による推奨事項 Recommender によって、以下の指標にもとづく推奨事項が 収集・表示されます。（2024年10月時点） サービス 指標 概要 Cloud Run CPU 割り当て 常時割り当て CPU への切り替え Cloud SQL アイドル状態インスタンス 未使用インスタンスの削除 Cloud SQL オーバープロビジョニング インスタンス インスタンスサイズの適正化 Compute Engine 確約利用割引（CUD） コミットメントによるコスト削減 Compute Engine アイドル状態のカスタム イメージ 未使用イメージの削除 Compute Engine アイドル状態の IP アドレス 未使用アドレスの削除 Compute Engine アイドル状態の永続ディスク 未使用ディスクのバックアップ後削除 Compute Engine アイドル状態の VM 未使用 VM マシンの削除 Compute Engine アイドル状態の予約 未使用のゾーンリソース予約の削除 Compute Engine マネージド インスタンス グループ（MIG）のマシンタイプ MIG マシンタイプの適正化 Compute Engine VM マシンタイプ MIG マシンタイプの適正化 Resource Manager 放置されたプロジェクト 未使用プロジェクトの再利用または削除 参考： FinOps ハブの費用 Recommender 必要な権限 FinOps ハブを利用するプリンシパルが、請求先アカウントに対し、以下の公式ガイドに記載の権限を含む IAM ロールを持っている必要があります。 例として、 請求先アカウント閲覧者ロール（roles/billing.viewer） や 請求先アカウント管理者ロール（roles/billing.admin） が挙げられます。 参考： FinOps ハブにアクセスするために必要な権限 参考： IAM の Cloud Billing ロールの概要 なお、権限から事前定義ロール（IAM ロール）を逆引き検索する場合、以下に記載の方法が便利です。 参考： 最適な IAM ロールの選択（G-gen Tech Blog） 料金 FinOps ハブは無料でご利用いただけます。 実際に試してみた 推奨事項の確認 ダッシュボード上の 削減見込み/月 > View all recommendations から、推奨事項の一覧情報を確認します。 そのうち今回は、 アイドル状態のIPアドレス を削除します。 なお、フラグのついている推奨事項については、同じくダッシュボードにある 上位の推奨事項 からも確認可能です。 詳細の確認 削減見込み/月 列のリンクから各推奨事項の詳細に遷移できますが、権限がないと以下のようなエラーとなります。 前述の権限とは別に、 範囲 列に記載されたプロジェクト上の Google Cloud リソースに対し、少なくともそれらを閲覧できる権限が別途必要です。 今回の場合、対象のプロジェクトで 閲覧者ロール（roles/viewer） を付与すること閲覧できました。 請求先アカウントに紐づくプロジェクトが多い場合は、ご利用いただいている Google Cloud 環境の階層構造をご確認の上、上位のフォルダリソースや組織リソースに対して付与すると良いでしょう。 blog.g-gen.co.jp リソースの削除 前述の画面から直接リソースを削除することはできません。あくまで推奨事項の提示までが当サービスのスコープです。 当該プロジェクトにて直接削除するか、あるいはプロジェクト管理者に別途依頼する必要があります。（赤枠部分は公式ドキュメントへのリンク ） ダッシュボードへの反映 今回の検証では、削除したリソースに関する情報はリアルタイムで反映されませんでした。 一定期間後あらためてダッシュボードをご確認いただくと、FinOps スコアや削減見込額などへの反映が確認できます。 関連記事 blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部所属。G-gen唯一の山梨県在住エンジニア Google Cloud Partner Top Engineer 2024 に選出。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 趣味はロードバイク、ロードレースやサッカー観戦です。 Follow @ggenyutakei

G-gen の杉村です。複数の Google Cloud プロジェクトの Cloud SQL インスタンスの情報一覧を取得する bash スクリプトを紹介します。 はじめに 概要 前提条件 免責事項 ソースコード 出力例 実行方法 入力ファイルの準備 スクリプトの実行 応用 はじめに 概要 当記事で紹介するのは、複数の Google Cloud プロジェクトに存在する Cloud SQL インスタンスの一覧を CSV ファイルに出力するためのスクリプトです。 当スクリプトを使うことで、Google Cloud 組織配下の全ての Cloud SQL インスタンスを一覧にすることができます。組織内での Cloud SQL インスタンスの棚卸し等にご利用ください。 前提条件 当 bash スクリプトは、 Debian GNU/Linux 12 (bookworm) 上で開発され、動作確認されています。 また、以下のソフトウェアがインストールされていることが前提です。括弧内は開発時のバージョンです。 gcloud（ Google Cloud SDK 488.0.0 ） jq （ jq-1.6 ） また実行時は、gcloud コマンドの認証情報に、Cloud SQL インスタンスの一覧表示権限を持つ Google アカウントが設定されている必要があります。 参考 : ユーザー アカウントを使用して認可する 参考 : サービス アカウントを使用して承認する 参考 : Cloud SQL のロール なお、組織内の全プロジェクトを一覧取得する方法については、以下も参照してください。 blog.g-gen.co.jp 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 ソースコード 当ソースコードは、前述の 免責事項 をご理解のうえ、ご利用ください。 list_all_sql_instances.sh #!/bin/bash # 引数チェック if [ -z " $1 " ]; then echo " ERROR : Please specify project list file. " exit 1 fi # 変数定義 list_file = $1 datetime = `date " +%Y%m%d%H%M " ` output_file_name = " all_sqls_ ${datetime} .csv " # プロジェクトごとにループを実行 while read project; do ## インスタンス情報取得処理 result = `gcloud sql instances list --project = ${project} --format = json --quiet 2 >&1 ` ## エラーであればプロジェクトチェック一覧に記録 if [ $? -ne 0 ]; then echo " ${project} ,failed " | tee -a ${output_file_name} continue fi ## 出力ファイルに記録 IFS =$' \n '; for instance in ` echo ${result} | jq -c ' .[] ' ` ; do # JSON から各要素を抽出 name = ` echo ${instance} | jq -r .name` databaseVersion = ` echo ${instance} | jq -r .databaseVersion` region = ` echo ${instance} | jq -r .region` tier = ` echo ${instance} | jq -r .settings.tier` availabilityType = ` echo ${instance} | jq -r .settings.availabilityType` edition = ` echo ${instance} | jq -r .settings.edition 2 > /dev/null` # ファイルに記録 echo " ${project} , ${name} , ${databaseVersion} , ${edition} , ${region} , ${tier} , ${availabilityType} " | tee -a ${output_file_name} done done < ${list_file} echo "" echo " ##### Listing finished ##### " echo "" ls -la ${output_file_name} exit 0 出力例 以下のような CSV ファイルが出力されます。わかりやすいようにテーブル形式で掲載していますが、実際には出力は csv であり、ヘッダは出力されません。 プロジェクト ID インスタンス名 DB エンジン エディション リージョン インスタンスタイプ 高可用性設定 my-project-01 mysql-instance-01 MYSQL_8_0 ENTERPRISE asia-northeast1 db-custom-2-7680 REGIONAL my-project-02 mysql-instance-02 MYSQL_8_0 ENTERPRISE asia-northeast1 db-custom-2-7680 REGIONAL my-project-03 postgres-instance-01 POSTGRES_15 ENTERPRISE asia-northeast1 db-custom-1-3840 ZONAL エディション列には、 ENTERPRISE や ENTERPRISE_PLUS が入りますが、Cloud SQL editions がリリース以前に作成されたインスタンスは null になる場合もあります。 またインスタンスタイプの一覧は以下のドキュメントをご参照ください。 参考 : インスタンスの設定について 実行方法 入力ファイルの準備 まず、入力ファイルとして1行に1つの Google Cloud プロジェクト ID を記載したテキストファイルを用意します（プロジェクト名ではなく、ID であることに注意してください）。 projects.txt my-project-01 my-project-02 my-project-03 このファイルを作るには、以下の記事で紹介しているスクリプトを利用することもできます。 blog.g-gen.co.jp スクリプトの実行 その後、以下のようにスクリプトを実行します。 projects.txt は、用意したテキストファイル名に置き換えてください。 ./list_all_sql_instances.sh projects.txt 応用 ソースコードの28行目〜36行目を修正することで、任意の情報を CSV ファイルに含めることができます。 同箇所では、JSON 形式で取得したインスタンス情報を、jq コマンドでフィルタして情報を取得しています。参考として、Cloud SQL インスタンス情報は以下のようなフォーマットになっています（2024年10月現在）。 { " backendType ": " SECOND_GEN ", " connectionName ": " my-project:us-central1:test ", " createTime ": " 2024-10-10T10:55:21.856Z ", " databaseInstalledVersion ": " MYSQL_8_0_31 ", " databaseVersion ": " MYSQL_8_0_31 ", " etag ": " xxxxx ", " failoverReplica ": { " available ": true } , " gceZone ": " us-central1-a ", " geminiConfig ": { " activeQueryEnabled ": true , " entitled ": true , " flagRecommenderEnabled ": true , " indexAdvisorEnabled ": false } , " instanceType ": " CLOUD_SQL_INSTANCE ", " ipAddresses ": [ { " ipAddress ": " x.x.x.x ", " type ": " PRIMARY " } ] , " kind ": " sql#instance ", " maintenanceVersion ": " MYSQL_8_0_31.R20240915.01_02 ", " name ": " test ", " project ": " my-project ", " region ": " us-central1 ", " satisfiesPzi ": false , " secondaryGceZone ": " us-central1-c ", " selfLink ": " https://sqladmin.googleapis.com/sql/v1beta4/projects/my-project/instances/test ", " serverCaCert ": { " cert ": " -----BEGIN CERTIFICATE----- \n xxxx= \n -----END CERTIFICATE----- ", " certSerialNumber ": " 0 ", " commonName ": " C=US,O=Google \\ , Inc,CN=Google Cloud SQL Server CA,dnQualifier=xxxx ", " createTime ": " 2024-10-10T10:56:15.860Z ", " expirationTime ": " 2034-10-08T10:57:15.860Z ", " instance ": " test ", " kind ": " sql#sslCert ", " sha1Fingerprint ": " xxx " } , " serviceAccountEmailAddress ": " p1234567890-abcdefg@gcp-sa-cloud-sql.iam.gserviceaccount.com ", " settings ": { " activationPolicy ": " ALWAYS ", " availabilityType ": " REGIONAL ", " backupConfiguration ": { " backupRetentionSettings ": { " retainedBackups ": 7 , " retentionUnit ": " COUNT " } , " binaryLogEnabled ": true , " enabled ": true , " kind ": " sql#backupConfiguration ", " location ": " us ", " startTime ": " 08:00 ", " transactionLogRetentionDays ": 7 , " transactionalLogStorageState ": " CLOUD_STORAGE " } , " connectorEnforcement ": " NOT_REQUIRED ", " dataDiskSizeGb ": " 250 ", " dataDiskType ": " PD_SSD ", " deletionProtectionEnabled ": false , " edition ": " ENTERPRISE ", " insightsConfig ": {} , " ipConfiguration ": { " enablePrivatePathForGoogleCloudServices ": false , " ipv4Enabled ": true , " requireSsl ": false , " serverCaMode ": " GOOGLE_MANAGED_INTERNAL_CA ", " sslMode ": " ALLOW_UNENCRYPTED_AND_ENCRYPTED " } , " kind ": " sql#settings ", " locationPreference ": { " kind ": " sql#locationPreference ", " zone ": " us-central1-a " } , " maintenanceWindow ": { " day ": 0 , " hour ": 0 , " kind ": " sql#maintenanceWindow ", " updateTrack ": " stable " } , " pricingPlan ": " PER_USE ", " replicationType ": " SYNCHRONOUS ", " settingsVersion ": " 5 ", " storageAutoResize ": true , " storageAutoResizeLimit ": " 0 ", " tier ": " db-custom-8-32768 " } , " sqlNetworkArchitecture ": " NEW_NETWORK_ARCHITECTURE ", " state ": " RUNNABLE " } 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Cloud Run のマルチリージョンサービスについて解説します。 マルチリージョンサービスとは メリット サービスのレイテンシ低下 リージョン障害への耐性 各リージョンへの一括デプロイ 注意点 利用料金 構成は全リージョン一律 利用手順 マルチリージョンサービスの作成 マルチリージョンサービスの更新 ロードバランサのバックエンドにマルチリージョンサービスを設定 マルチリージョンサービスとは マルチリージョンサービス とは、一度の操作で複数リージョンに Cloud Run サービスをデプロイすることができる機能です。 Cloud Run は通常、サービスのデプロイ時に単一のリージョンを選択するリージョナルなサービスです。しかし、マルチリージョンサービス機能を用いることで、一度の操作で複数リージョンにサービスをデプロイすることができます。 参考 : Serve traffic from multiple regions Cloud Run の基礎知識については、以下の記事も参照してください。 blog.g-gen.co.jp メリット サービスのレイテンシ低下 グローバルアプリケーションロードバランサのバックエンドとして、複数リージョンで Cloud Run サービスを展開すると、ユーザーのトラフィックを最も近いリージョンにあるサービスにルーティングすることができます。これにより、リクエスト処理のレイテンシ低下が期待できます。 ユーザーに最も近いリージョンのサービスにトラフィックをルーティングする リージョン障害への耐性 サービスをマルチリージョンに展開することで、Google Cloud の障害により特定のリージョンが使用できなくなった場合でも、障害の影響がない正常なリージョンでサービスを継続することができます。 なお、アプリケーションロードバランサのデフォルトの設定では、リージョン障害等で特定リージョンのサービスが使用不可になった際、正常なリージョンに自動的にルーティングされることはありません。このようなユースケースでは、ロードバランサのバックエンドで 外れ値検出 を有効化し、ロードバランサが HTTP エラー率に基づいた異常を検知できるように構成しておく必要があります。 参考 : 外れ値検出の構成 ロードバランサのバックエンドで外れ値検出を有効化する 各リージョンへの一括デプロイ マルチリージョンサービス機能を使用しないでも、複数のリージョンでそれぞれサービスをデプロイすることで、 Cloud Run サービスを複数リージョンに展開することができます。しかしその場合、サービスを展開するリージョン数に応じたデプロイパイプラインを構築する必要があります。 マルチリージョンサービスを使用することで、単一のデプロイパイプラインから複数リージョンへのデプロイを一括で行うことができます。これにより、CI/CD パイプラインの構成をシンプルに保つことができます。 注意点 利用料金 マルチリージョンサービスでは、単にサービスを複数リージョンにデプロイする場合と同様に、リージョンごとに Cloud Run の利用コストが発生します。前述のメリットとコストのトレードオフを考慮し、サービスの要件に応じて利用を検討しましょう。 構成は全リージョン一律 マルチリージョンサービスでは、すべてのリージョンのサービスに同じ設定がされるため、リージョンごとに個別に設定を定義することはできません。例えば、リージョンごとに CPU、メモリの設定を最適化したり、異なる環境変数の設定などはできません。 たとえば、以下のように特定のリージョンを指定してサービスを更新しようとすると、エラーが発生してしまいます。 $ gcloud run services update run-multi-regions \ --cpu = 2 \ --memory = 1 \ --region = asia-northeast1 X Deploying... . Creating Revision... . Routing traffic... Deployment failed ERROR: ( gcloud.run.services.update ) service: Multi-region Services are read-only at the regional endpoint. Please use the multi-region Services API to manage them. 利用手順 マルチリージョンサービスの作成 2025年9月現在、Google Cloud コンソールからのマルチリージョンサービスのデプロイはサポートされていません。 gcloud CLI を利用する場合、マルチリージョンサービスをデプロイするための最小限のコマンドは以下のようになります。 # Cloud Run サービスをマルチリージョンサービスとしてデプロイする $ gcloud run deploy { サービス名 } \ --{コンテナイメージ} \ # コンテナイメージ --regions = { リージョン } # サービスをデプロイするリージョンをカンマ区切りで複数指定 # 実行例 $ gcloud run deploy run-multi-regions \ --image = us-docker.pkg.dev/cloudrun/container/hello \ --regions = asia-northeast1,us-central1 # asia-northeast1 と us-central1 にデプロイ マルチリージョンサービスを作成すると、コンソール上では以下のスクリーンショットのように表示されます。 作成したマルチリージョンサービスをコンソールで確認する リージョンごとの「サービスの詳細」画面を確認すると、それぞれのリージョンでリビジョンが作成され、 https://{サービス名}-{プロジェクトID}-{リージョン名}.run.app 形式の URL が発行されています。また、この画面からサービスを編集することができなくなっています。 各リージョンのサービスの「サービスの詳細」画面 マルチリージョンサービスの更新 マルチリージョンサービスの更新は gcloud run multi-region-services update コマンドを使用します。 --add-regions フラグを使用することで、新たに指定したリージョンにサービスをデプロイすることができます。リージョンは、複数指定することができます。 # リージョンを追加する $ gcloud run multi-region-services update { サービス名 } \ --add-regions = { リージョン } --remove-regions フラグにより、指定したリージョンのサービスを削除することができます（複数指定可）。 # リージョンを削除する $ gcloud run multi-region-services update { サービス名 } \ --remove-regions = { リージョン } 参考： gcloud run multi-region-services update ロードバランサのバックエンドにマルチリージョンサービスを設定 基本的には以下の記事で解説しているものと同様の手順でロードバランサを設定します。 blog.g-gen.co.jp ロードバランサのバックエンドとしてマルチリージョンサービスを設定する場合、リージョンごとにサーバーレス NEG を作成し、バックエンドサービスに設定します。 リージョンごとに作成したサーバーレス NEG をバックエンドサービスとして設定する 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の山崎です。2024年10月に Preview 公開され、2025年4月に一般公開（GA）された、BigQuery の Pipe syntax （パイプ構文）の概要と使い方を紹介します。 概要 はじめに パイプ構文とは 従来 SQL の課題 データ処理の順番と記述の順番が一致していない サブクエリによるコードのネスト化 冗長な構文 パイプ構文のメリット 柔軟性の向上 可読性の向上 デバッグ効率の向上 従来の SQL とパイプ構文の比較 サンプルデータ データの取得要件 従来の SQL の場合 パイプ構文の場合 パイプ構文によるクエリ全文 employee_master テーブルを取得 東京拠点のみのレコードでフィルタ sales テーブルと結合 2024年4月1日以降のレコードでフィルタ 従業員の単位で売上を集約 売上高合計が10,000の従業員でフィルタ 売上高合計で降順にソート 上位2位のデータのみにフィルタ 概要 はじめに 当記事では、BigQuery の Pipe syntax （以下、 パイプ構文 ）について、従来の SQL と比較しながら解説します。 なお BigQuery の基本的な知識については、以下の記事を参照してください。 blog.g-gen.co.jp パイプ構文とは パイプ構文 は、BigQuery で利用可能なクエリの記述方式です。パイプ演算子（ |> ）で各操作をつなげることで、 データの流れを明確にしながらクエリを作成、修正、デバッグ ができます。データの流れに沿ってコードを記述できるのが特徴であり、後述する従来の SQL の課題に対応したものといえます。 以下は、パイプ構文を用いて記述したクエリの例です。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) |> WHERE sales_date >= ' 2024-04-01 ' |> AGGREGATE SUM (sales_amount) AS total_amount GROUP BY employee_id, employee_name |> WHERE total_amount > 10000 |> ORDER BY total_amount DESC |> LIMIT 2 パイプ構文を使用するクエリはオプティマイザーにより最適化され、 従来の SQL で同等の処理をする場合と同じ処理コスト で使用可能です。パフォーマンスや利用料金を最適化したい場合は、BigQuery のクエリ記述のベストプラクティスに沿うことが望ましいといえます。 参考 : Pipe syntax パイプ構文の構文の詳細や使用可能な演算子は、以下の公式ドキュメントを参照してください。 参考 : Pipe query syntax 従来 SQL の課題 従来の SQL には、以下のような課題があります。 データ処理の順番と記述の順番が一致していない 従来の SQL の記述の順序は、データが処理される実際の順序と必ずしも一致しません。 例えば従来の SQL では、 SELECT 句、 FROM 句、 WHERE 句、 GROUP BY 句の順で記述します。しかし実際の処理は、 FROM 句から始まります。複雑なクエリでは、この順序の不一致が、理解を難しくする場合があります。 サブクエリによるコードのネスト化 サブクエリは「副問合せ」とも呼ばれ、SQL の中に入れ子で SQL を記述することを指します。 従来の SQL で複雑なロジックを実現する場合、サブクエリが必要となるケースが多くあります。サブクエリを多用すると、コードがネスト化し、可読性が低下します。また、どのサブクエリがどの部分に影響するのかを把握するのが難しくなり、デバッグの難易度も上がり、保守性が低下します。 冗長な構文 従来の SQL では、同じ意味合いの操作を別々の句で表現する必要が出てくる場合があります。 例えば、データの絞り込みには WHERE 句と HAVING 句がありますが、適用されるタイミングや条件が異なるため、構文のルールを正しく理解して使用しないと、構文エラーや想定外の結果が取得されます。この冗長性は、SQL を複雑にし、学習コストを高める要因となっています。 パイプ構文のメリット 一方、パイプ構文には以下のメリットがあります。 柔軟性の向上 パイプ構文では 句の順序に縛りがない ため、SQL の記述に 柔軟性 が生まれます。 例えば、集計結果に対してさらに絞り込みを行う場合、従来の SQL ではサブクエリが必要となるケースがありますが、パイプ構文では |> WHERE を追加するだけで実現できます。これにより、クエリの構造を シンプルに保ち ながら、 複雑なロジックを表現する ことが可能になります。 可読性の向上 パイプ演算子を使ってデータの流れを明確に表現することで、クエリの 可読性が向上 します。 特に、複雑なクエリやネストしたサブクエリが多い場合、パイプ構文のメリットは際立ちます。開発者はクエリ全体の構造を容易に把握し、コードの意図を理解することができます。 デバッグ効率の向上 パイプ構文では、 各パイプ演算子の結果を段階的に確認できる ため、 デバッグ効率が向上 します。 エラーが発生した場合でも、原因を特定しやすく、迅速に修正することができます。 従来の SQL とパイプ構文の比較 具体例を元に、従来の SQL とパイプ構文の比較を行います。 サンプルデータ 以下の employee_master テーブルと sales テーブルを例にとります。 サンプルデータ データの取得要件 以下の要件のデータを取得します。 東京拠点に所属し、2024年4月1日以降の売上高合計が10,000以上の従業員のうち、 売上高合計が上位2位に入る従業員の ID、氏名、売上高合計を取得する。 従来の SQL の場合 従来の SQL では、以下のクエリで要件にあうデータを取得することができます。 SELECT e.employee_id, e.employee_name, SUM (s.sales_amount) AS total_sales FROM `myproject.mydataset.employee_master` AS e INNER JOIN `myproject.mydataset.sales` AS s ON e.employee_id = s.employee_id WHERE e.location = ' Tokyo ' AND s.sales_date >= ' 2024-04-01 ' GROUP BY e.employee_id, e.employee_name HAVING SUM (s.sales_amount) >= 10000 ORDER BY total_sales DESC LIMIT 2 ; 従来の SQL の実行結果 従来型の SQL では、まず FROM 句や JOIN 句、 WHERE 句が最初に処理され、その後、集計関数や GROUP BY 句の処理を行い、 HAVING 句でその結果をフィルタし、 ORDER BY 句で結果をソート、 LIMIT 句で表示数を絞る、という処理順になっており、記述の順番と処理の順番が一致していません。 パイプ構文の場合 パイプ構文によるクエリ全文 一方のパイプ構文では、先ほどと同じクエリを以下のように記述します。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) |> WHERE sales_date >= ' 2024-04-01 ' |> AGGREGATE SUM (sales_amount) AS total_amount GROUP BY employee_id, employee_name |> WHERE total_amount > 10000 |> ORDER BY total_amount DESC |> LIMIT 2 パイプ構文は処理の順番と記述の順番が一致しているため、処理の流れを考えながら、順番に記述していくことができます。 employee_master テーブルを取得 はじめに、 employee_master テーブルの全体を取得します。 FROM `myproject.mydataset.employee_master` employee_master テーブルを取得 東京拠点のみのレコードでフィルタ location = 'Tokyo' でフィルタします。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' location = 'Tokyo' でフィルタ sales テーブルと結合 sales テーブルと employee_id を内部結合（INNER JOIN）します。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) sales テーブルと employee_id で結合 2024年4月1日以降のレコードでフィルタ sales_date >= '2024-04-01' でフィルタを行います。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) |> WHERE sales_date >= ' 2024-04-01 ' sales_date >= '2024-04-01' でフィルタ 従業員の単位で売上を集約 employee_id 列と employee_name 列で sales 列を集計します。 パイプ構文で、集計を行う場合は、 AGGREGATE パイプ演算子 を使用します。 参考 : AGGREGATE pipe operator FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) |> WHERE sales_date >= ' 2024-04-01 ' |> AGGREGATE SUM (sales_amount) AS total_amount GROUP BY employee_id, employee_name employee_id 列と employee_name 列で sales を集計 売上高合計が10,000の従業員でフィルタ total_amount > 10000 でフィルタを行います。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) |> WHERE sales_date >= ' 2024-04-01 ' |> AGGREGATE SUM (sales_amount) AS total_amount GROUP BY employee_id, employee_name |> WHERE total_amount > 10000 total_amount > 10000 でフィルタ 売上高合計で降順にソート total_amount 列で降順に並び替えます。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) |> WHERE sales_date >= ' 2024-04-01 ' |> AGGREGATE SUM (sales_amount) AS total_amount GROUP BY employee_id, employee_name |> WHERE total_amount > 10000 |> ORDER BY total_amount DESC total_amount で降順に並び替え 上位2位のデータのみにフィルタ limit 2 で、表示する行数のフィルタを行います。 FROM `myproject.mydataset.employee_master` |> WHERE location = ' Tokyo ' |> JOIN `myproject.mydataset.sales` USING (employee_id) |> WHERE sales_date >= ' 2024-04-01 ' |> AGGREGATE SUM (sales_amount) AS total_amount GROUP BY employee_id, employee_name |> WHERE total_amount > 10000 |> ORDER BY total_amount DESC |> LIMIT 2 limit 2 でフィルタ 従来の SQL と同じ結果がパイプ構文でも取得できました。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud Partner Top Engineer 2025 選出。 Google Cloud 11 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の山崎です。 当記事では Google マネージド SSL/TLS 証明書、ロードバランサ、Compute Engine 上の Apache HTTP Server という構成のシステムを構築したので、その手順を解説します。 システム構成 前提知識 Web サーバの構築 VM インスタンスの作成 Apache のインストール index.html の更新 Web サーバ接続確認 インスタンスグループの構築 Google マネージド SSL/TLS 証明書の作成 DNS 認証を作成する CNAME レコードを登録する DNS 構成に CNAME レコードを追加する DNS 認証を参照する Google マネージド証明書を作成する 証明書の有効性を確認する ロードバランサの構築 外部 IP アドレスを予約する ヘルスチェックを作成する バックエンドサービスを作成する インスタンスグループをバックエンドとしてバックエンドサービスに追加する 受信リクエストをデフォルトのバックエンドサービスに転送する URL マップを作成する ロードバランサと証明書を紐づける Certificate Map を作成する ドメイン名と Certificate を紐づける Certificate Map Entry を作成する リクエストを URL マップに転送するターゲット HTTPS プロキシを作成する 受信リクエストをプロキシに転送するグローバル転送ルールを作成する DNS 構成に A レコードを追加する アクセス確認 ロードバランサ構築時の注意事項 システム構成 今回構築したシステムの構成は、以下のとおりです。 システム構成 Google マネージド SSL/TLS 証明書は、無料かつスピーディに調達することができる、Google Cloud 提供の SSL/TLS 証明書です。この構成では、Google マネージド SSL/TLS 証明書を Cloud Load Balancing に登録することで、HTTPS プロトコルでのアクセスを可能にしています。 今回は、以下の順序で環境を構築しました。 Web サーバの構築 Google マネージド SSL/TLS 証明書の構築 ロードバランサの構築 前提知識 今回使用する Google Cloud サービスの詳細は、以下の記事をご参照ください。 Compute Engine blog.g-gen.co.jp Cloud Load Balancing blog.g-gen.co.jp Google マネージド SSL/TLS 証明書 blog.g-gen.co.jp Web サーバの構築 VM インスタンスの作成 コンソールにて、Compute Engine ＞ VMインスタンス と移動し、「インスタンスを作成」を押下します。 以下の箇所のみ設定を行い、「作成」を押下します。 項目名 設定値 名前 test-vm リージョン asia-northeast1 ゾーン asia-northeast1-a マシンタイプ e2-micro HTTP トラフィックを許可する オン HTTPS トラフィックを許可する オン Apache のインストール 作成した VM に SSH でログインします。 以下のコマンドで Apache HTTP Server をインストールします。 sudo apt update sudo apt install apache2 index.html の更新 Web サーバにアクセスした際に、 Hello,world が表示されるように index.html を更新します。 sudo nano /var/www/html/index.html index.html の記述 <!DOCTYPE html> < html > < head > < title > My Website </ title > </ head > < body > < h1 > Hello, world! </ h1 > < p > You are accessing web server. </ p > </ body > </ html > Web サーバ接続確認 VM インスタンスの外部 IP アドレスを確認します。 ブラウザを起動し、 http://{IPアドレス} で接続します。 先ほど更新した index.html の内容で画面が表示されていることを確認します。 http でのアクセスとなるため、 保護されていない通信 と表示される可能性があります。 インスタンスグループの構築 前の手順で作成した VM を選択し、「このVMに基づいてグループを作成」を押下します。 以下の箇所のみ設定を行い、「グループを作成」を押下します。 項目名 設定値 インスタンステンプレートの名前 test-vm-template インスタンスグループの名前 test-vm-instance-group インスタンス数 2 ポートマッピングのポート名 http ポートマッピングのポート番号 80 Google マネージド SSL/TLS 証明書の作成 DNS 認証を作成する 当記事では、DNS 認証を用いて、Google マネージド SSL/TLS 証明書を作成します。 まずは、DNS 認証を作成します。 gcloud certificate-manager dns-authorizations create test-dns-auth --domain =" {使用するドメイン} " CNAME レコードを登録する 先ほどのコマンドで作成した CNAME レコードを確認します。 gcloud certificate-manager dns-authorizations describe test-dns-auth 出力結果の CNAME レコードの data の値は、以降の処理で使用するため、控えておきます。 DNS 構成に CNAME レコードを追加する CNAME レコードを、ドメインを管理している DNS ゾーンに追加します。 # トランザクションの開始 gcloud dns record-sets transaction start --zone =" {DNS ゾーン名} " # CNAME レコードをターゲット DNS ゾーンに追加 gcloud dns record-sets transaction add { CNAME レコードの data の値 } \ --name =" _acme-challenge.{使用するドメイン}. " \ --ttl =" 30 " \ --type =" CNAME " \ --zone =" {DNS ゾーン名} " # トランザクションの終了 gcloud dns record-sets transaction execute --zone =" {DNS ゾーン名} " DNS 認証を参照する Google マネージド証明書を作成する 前の手順で作成した DNS 認証を参照する Google マネージド証明書を作成します。 gcloud certificate-manager certificates create test-cert --domains =" {使用するドメイン} " --dns-authorizations = test-dns-auth 証明書の有効性を確認する 証明書自体が有効であることを確認します。以下のコマンドを実行し、STATUS が ACTIVE となっていることを確認します。 証明書の作成には、10分以上時間がかかるのでご留意ください。 gcloud certificate-manager certificates describe test-cert ロードバランサの構築 外部 IP アドレスを予約する ロードバランサにユーザが接続する際に使用するグローバル静的外部 IP アドレスを設定します。 gcloud compute addresses create lb-ipv4 \ --ip-version = IPV4 \ --network-tier = PREMIUM \ --global 作成した IP アドレスは、以下のコマンドで確認できます。 gcloud compute addresses describe lb-ipv4 \ --format =" get(address) " \ --global ヘルスチェックを作成する サービスの正常性を確認するために、ヘルスチェックを作成します。 gcloud compute health-checks create http http-basic-check \ --port 80 バックエンドサービスを作成する バックエンドとのつなぎ役を担うバックエンドサービスを作成します。 gcloud beta compute backend-services create web-backend-service \ --load-balancing-scheme = EXTERNAL_MANAGED \ --protocol = HTTP \ --port-name = http \ --health-checks = http-basic-check \ --global インスタンスグループをバックエンドとしてバックエンドサービスに追加する 前の手順で作成したインスタンスグループをバックエンドとして、バックエンドサービスに追加します。 gcloud beta compute backend-services add-backend web-backend-service \ --instance-group = test-vm-instance-group \ --instance-group-zone = asia-northeast1-a \ --global 受信リクエストをデフォルトのバックエンドサービスに転送する URL マップを作成する 受信リクエストをデフォルトのバックエンドサービスに転送するための URL マップを作成します。 gcloud beta compute url-maps create web-map-https \ --default-service web-backend-service ロードバランサと証明書を紐づける Certificate Map を作成する ロードバランサと証明書を紐づけるための Certificate Map を作成します。 gcloud certificate-manager maps create test-cert-map ドメイン名と Certificate を紐づける Certificate Map Entry を作成する ドメイン名と Certificate を紐づけるための Certificate Map Entry を作成します。 gcloud certificate-manager maps entries create test-cert-map-entry \ --map =" test-cert-map " \ --certificates =" test-cert " \ --hostname =" {使用するドメイン} " リクエストを URL マップに転送するターゲット HTTPS プロキシを作成する リクエストを URL マップに転送するためのターゲット HTTPS プロキシを作成します。 gcloud compute target-https-proxies create https-lb-target-proxy \ --url-map =" web-map-https " \ --certificate-map =" test-cert-map " 受信リクエストをプロキシに転送するグローバル転送ルールを作成する 受信リクエストをプロキシに転送するためのグローバル転送ルールを作成します。 gcloud beta compute forwarding-rules create https-content-rule \ --load-balancing-scheme = EXTERNAL_MANAGED \ --network-tier = PREMIUM \ --address = lb-ipv4 \ --global \ --target-https-proxy =" https-lb-target-proxy " \ --ports = 443 DNS 構成に A レコードを追加する ロードバランサに関連付けられた IP アドレスを元に A レコードを作成し、ドメインがロードバランサを参照するようにします。 # トランザクションの開始 gcloud dns record-sets transaction start --zone =" {DNS ゾーン名} " # A レコードを作成 gcloud dns record-sets transaction add { 作成した外部 IP アドレス } \ --name =" {使用するドメイン} " \ --ttl = 300 \ --type = A \ --zone =" {DNS ゾーン名} " # トランザクションの終了 gcloud dns record-sets transaction execute --zone =" {DNS ゾーン名} " アクセス確認 ブラウザを起動し、 https://{DNS ゾーン名} で接続します。 前の手順でアクセスした時と同様に、更新した index.html の内容で画面が表示されていることを確認できます。また、 https でアクセスしているため、 保護されていない通信 と表示されることもありません。 ロードバランサ構築時の注意事項 ロードバランサの構築は、Google Cloud コンソールや gcloud コマンドラインで実施することができます。しかし、コンソールで実施する場合、 DNS 認証で作成した Google マネージド証明書をロードバランサに登録することはできません 。プルダウンメニューに表示されるのは、ロードバランサ認証で作成した Google マネージド証明書のみです。 これは2024年10月現在の Google Cloud コンソールの仕様によるもので、今後の改善が期待されます。 ロードバランサ認証で作成した証明書のみがアタッチ可能 ロードバランサ認証は、証明書のドメイン名でロードバランサに外部から HTTP（TCP 80番ポート）でアクセス可能であることをもって認証するという特性上、 ロードバランサを構築完了しなければ Google マネージド証明書が作成されません 。 これはセキュリティ上望ましくないほか、既存の Web サイトや Web アプリケーションを Google Cloud 移行する際には許容できないことが多いといえます。このような場合は、当記事のような手順で、gcloud コマンドラインを使って DNS 認証のマネージド証明書を作成してください。 参考 : ロードバランサ認証 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud 全 11 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-gen の杉村です。Google Cloud の仮想サーバーサービスである Compute Engine には、スナップショット、マシンイメージ、カスタムイメージというよく似た3つの機能があります。それらの違いと、ユースケースをご説明します。 はじめに マシンの状態を保存する3つの仕組み スナップショット 基本的な機能 増分バックアップ Web コンソール上の表記 保存先のロケーション 3種類のスナップショット 定期的な取得 データの整合性 料金 マシンイメージ 基本的な機能 Web コンソール上の表記 保存先のロケーション 定期的な取得 データの整合性 料金 イメージ（カスタムイメージ） 基本的な機能 Web コンソール上の表記 保存先のロケーション イメージファミリー Windows Server のイメージ作成 料金 はじめに Compute Engine は、Google Cloud（旧称 GCP）で仮想サーバーを起動するためのサービスです。仮想ネットワークである Virtual Private Cloud（VPC）内に、各種 Liniux ディストリビューションや Windows Server の仮想サーバーを起動することができます。 詳細な解説は、以下の記事をご参照ください。 参考 : Compute Engineを徹底解説！（基本編） - G-gen Tech Blog 参考 : Compute Engineを徹底解説！（応用編） - G-gen Tech Blog マシンの状態を保存する3つの仕組み Compute Engine には、 スナップショット 、 マシンイメージ 、 イメージ （カスタムイメージ）というよく似た3つの機能があります。 これらはいずれも、仮想マシン（VM）のある時点の状態を取得して保存するための機能ですが、役割とユースケースが異なります。 名称 用途 保存される情報 スナップショット 永続ディスクのバックアップ ・1つの永続ディスクのデータ マシンイメージ VM のバックアップ ・VM に接続されているすべての永続ディスクのデータ ・マシンタイプ ・インスタンスメタデータ ・ラベル ・ネットワークタグ ・メンテナンスポリシー 等 イメージ (ユーザーが 独自に作る場合 カスタムイメージ ) VM 起動用イメージ ・1つの永続ディスクのデータ ・イメージファミリー（バージョン） ・ファームウェア関連の設定情報 等 スナップショット 基本的な機能 スナップショット は、ある単一の永続ディスクの、ある時点のデータを保存したイメージファイルです。 スナップショットの用途は、 単一の永続ディスクのバックアップ です。 スナップショットの取得を実行すると、前回にスナップショットを取得してからの増分データのみをバックアップ（ 増分バックアップ ）します。またデータは自動的に圧縮されるため、ディスクの完全なコピーをバックアップとして作成するよりも高速、かつ低コストでバックアップを実現できます。 参考 : アーカイブ ディスクと標準ディスクのスナップショットについて 増分バックアップ Compute Engine のスナップショットでは、 増分バックアップ が行われます。 初回にフルバックアップが取得され、2回目以降は、前回のバックアップ取得時から変更されたデータのみが取得されます。 フルバックアップのスナップショットや、他のスナップショットに依存されているデータを持ったスナップショットを削除したとしても、必要なデータは 自動的に 次のスナップショットに移行されます。そのため、スナップショットを削除するときは「どのスナップショットがフルでどのスナップショットが増分なのか」「どのスナップショットにいつのデータが保存されているのか」といったことを気にする必要はありません。 この仕組みは、後述のマシンイメージでも同様です。 参考 : スナップショットの削除 Web コンソール上の表記 Google Cloud コンソール上は、Compute Engine の左部メニューで「スナップショット」と表記されています。この画面からスナップショットやスナップショットスケジュールを管理できます。 スナップショット 保存先のロケーション スナップショットは、Google Cloud の堅牢なストレージである Cloud Storage に保存されます。この Cloud Storage は、Google がバックエンドで管理しているものであり、私たちユーザーからは見えません。 スナップショットを作成する際、ストレージロケーションとして特定の リージョン （東京、アイオワなど）を選択するか、または マルチリージョン （US、ASIA、EU など）を選択することができます。なおリージョンやマルチリージョンを総称してロケーションと呼びます。 マルチリージョンをロケーションとして選択すると、より高い堅牢性と可用性が得られます。ただしストレージ料金単価が単一リージョンよりも高くなるのと、リージョン間のデータのネットワーク転送コストが発生します。金銭コストと、堅牢性および可用性のトレードオフを考慮して、ロケーションを選択してください。 また、ディスクと異なるロケーションにスナップショットを保存することができます。このときも、リージョン間のデータ転送料金が発生します。 参考 : スナップショットのストレージ ロケーション 3種類のスナップショット スナップショットには スタンダード （標準）、 アーカイブ 、 インスタント （即時）の3種類があり、以下のような性質を持っています。 比較観点 - - - - - - - リストア速度 [速い] インスタント > スタンダード > アーカイブ [遅い] コスト [高い] インスタント > スタンダード > アーカイブ [安い] 冗長性 [高い] アーカイブ = スタンダード > インスタント [低い] 参考 : アーカイブ ディスクと標準ディスクのスナップショットについて 参考 : インスタント スナップショットについて スタンダード（標準）スナップショット スタンダード（標準）スナップショットは最も基本的なスナップショットです。 通常のディスクバックアップは、スタンダードで取得することが推奨されます。 アーカイブスナップショット アーカイブスナップショットは、スタンダードスナップショットよりもリストアにかかる時間が長く、また90日間の最低保管期間が発生します。 スナップショットの保存料金は日割りですが、アーカイブスナップショットを最低保管期間より短い期間で削除すると、最低保管期間分の料金が発生します。 インスタント（即時）スナップショット インスタント（即時）スナップショットは、最も短いリストア時間でリストアすることができるスナップショットです。インスタントナップショットでは、スナップショットが作成された後に元ディスクで変更されたデータ量に対して保管料金が発生します。保管料金の単価は、元ディスクの料金単価と同じです。また、インスタントスナップショットの作成時にワンショットのオペレーション費用が発生します。 またインスタントスナップショットの保管ロケーションは対象ディスクと同じロケーションしか選べないことや、対象ディスクを削除するとスナップショットも削除されること、といった特徴があります。このことから、インスタントスナップショットは論理障害（データの誤削除や誤変更等）に対応するための、クイックさを重視したバックアップといえます。 定期的な取得 スナップショットスケジュール 機能を使用することで、スナップショットを定期的に取得することができます。スナップショットスケジュールは、Web コンソール画面や gcloud コマンドラインで簡単に作成することができます。 ただし、スナップショットスケジュールが対応しているのはスタンダードスナップショットのみであり、インスタントスナップショットやアーカイブスナップショットは取得できません。 参考 : ディスク スナップショットのスケジュールを作成する データの整合性 スナップショットは、 クラッシュ整合性 でデータを保存します。クラッシュ整合性では、ソフトウェアがディスクに読み書きをしている途中でスナップショットを取得したり、メモリの内容が完全にディスクに書き込まれていない瞬間にスナップショットを取得してしまうと、データの整合性に不都合が起きる可能性があります。 安全なバックアップのためにはソフトウェアを停止するか、VM を停止してからバックアップを取得することが望ましいといえます。 また明示的に、 アプリケーション整合性 のあるスナップショットの取得も行うことができます。アプリケーション整合性では、メモリの内容をすべてディスクに書き出し、ディスク I/O が完了してからスナップショットを取得するため、前述のような問題は起きません。 アプリケーション整合性のあるスナップショット取得を行うためには、Windows Server では VSS 機能、Linux サーバーでは独自のシェルスクリプトを追加で設定する必要があります。 参考 : Compute Engine ディスク スナップショットのベスト プラクティス 参考 : Windows アプリケーション整合性のあるディスク スナップショットを作成する 参考 : Linux アプリケーションの整合性のあるディスク スナップショットを作成する 料金 スタンダードスナップショットやアーカイブスナップショットの料金は、圧縮後のデータサイズに対して発生します。 リージョン標準スナップショットの料金は、2024年9月現在、以下のとおりです。最新の料金は必ず、公式ドキュメントを参照してください。 リージョン 単価 アイオワ（us-central1） $0.05 / GB 東京（asia-northeast1） $0.064 / GB インスタントスナップショットでは、前述の通り、スナップショットが作成された後に元ディスクで変更されたデータ量に対して保管料金が発生します。保管料金の単価は、元ディスクの料金単価と同じです。また、インスタントスナップショットの作成時にワンショットのオペレーション費用が発生します。 参考 : ディスクとイメージの料金 - ディスク スナップショットの料金 保管先としてマルチリージョンを選択した際や、ディスクと異なるロケーションを選択した場合は、スナップショット作成時やリストア時にネットワーク転送料金が発生します。 マシンイメージ 基本的な機能 マシンイメージ は、ある VM のある時点のデータやメタデータ、各種設定情報を保存したイメージファイルです。 マシンイメージの用途は、 VM 全体のバックアップ です。また、VM をまるごと複製してクローンを作成したい場合にも利用できます。 マシンイメージの取得を実行すると、スナップショットと同様に、前回の取得からの増分データのみがバックアップされる増分バックアップが行われ、データは自動的に圧縮されます。対象の VM にアタッチされているすべての永続ディスクのデータが、同時に取得されます。 前述のスナップショットが単一の永続ディスク内のデータのみをバックアップする点とは異なり、マシンイメージには以下の情報が含まれます。 VM にアタッチされているすべての永続ディスクのデータ VM の以下の情報 説明（description） マシンタイプ インスタンスメタデータ ラベル ネットワークタグ メンテナンスポリシー Unified Extensible Firmware Interface（UEFI）の変数 ボリュームマッピング（ローカル SSD / 永続ディスク） マシンイメージを利用すると、スナップショットでは保存されない上記のような情報を保持できるため、VM 全体のバックアップとしてはマシンイメージを使うことが推奨されます。 参考 : マシンイメージ Web コンソール上の表記 Google Cloud コンソール上は、Compute Engine の左部メニューで「マシンイメージ」と表記されています。後述のカスタムイメージ（イメージ）を管理する画面である「イメージ」と紛らわしいですが、VM のバックアップであるマシンイメージの表記は「マシンイメージ」です。 マシンイメージ 保存先のロケーション スナップショットと同様に、マシンイメージも、保存先のロケーションを特定リージョンまたはマルチリージョンから選択できます。 VM と異なるロケーションを選択したり、マルチリージョンを選択すると、ネットワーク転送料金が発生する点はスナップショットと同様です。 参考 : マシンイメージの保存場所 定期的な取得 マシンイメージを自動的に取得する仕組みは、基本機能としては用意されていません。 Cloud Run functions や Cloud Workflows を用いて、ユーザーが実装することができます。 以下の記事も参考にしてください。 参考 : Cloud Functionsを使用してCompute Engineのマシンイメージを自動で取得する - G-gen Tech Blog 参考 : Cloud Functionsを使用してCompute Engineのマシンイメージを自動で削除する - G-gen Tech Blog 参考 : Cloud Workflowsを徹底解説 - G-gen Tech Blog データの整合性 マシンイメージで確保される整合性は クラッシュ整合性 です。VM を起動したままマシンイメージを取得する場合は、アプリケーションの稼働が低いタイミングで実施することが推奨されます。 マシンイメージを取得すると、すべてのディスクのデータが同じタイムスタンプで取得されるため、複数ディスク間でのデータ整合性は保たれます。 参考 : 複数ディスクのバックアップ 料金 マシンイメージの料金は、圧縮後のデータサイズに対して発生します。 マシンイメージの保管料金は、2024年9月現在、以下のとおりです。最新の料金は必ず、公式ドキュメントを参照してください。 リージョン 単価 アイオワ（us-central1） $0.05 / GB 東京（asia-northeast1） $0.065 / GB スナップショットと比較すると、ほぼ同額がわずかにマシンイメージのほうが単価が高いです（アイオワリージョンでは同額、東京リージョンで は $0.001 / GB の差）。 スナップショットと同様に、マルチリージョンを選択した際や、ディスクと異なるロケーションをマシンイメージの保存先として選択した場合は、マシンイメージの作成時やリストア時にネットワーク転送料金が発生します。 参考 : ディスクとイメージの料金 - マシンイメージ イメージ（カスタムイメージ） 基本的な機能 カスタムイメージ は、VM のブートディスクとするためのイメージファイルです。 カスタムイメージの上位概念として イメージ （または OS イメージ ）があり、イメージには 公開イメージ と カスタムイメージ の2種類があります。 VM を新規作成する際に、Debian やUbuntu、Windows Server 等の各メーカーが公開しているオフィシャルなイメージを選択することがありますが、これらは 公開イメージ と呼ばれます。 一方で、ユーザーがカスタマイズした VM のブートディスクからスナップショットを取得し、そこから作成したイメージが カスタムイメージ です。 VM 起動時に、ブートディスクとして公開イメージやカスタムイメージを選択できます。前述のスナップショットもブートディスクとして選択することはできますが、イメージは特にブートディスクの管理に特化したリソースです。 VM 起動時にブートディスクとして選択できる また、VM の起動設定を定義する インスタンステンプレート でもブートディスクを選択しますが、選択できるのはイメージのみであり、スナップショットは選択できません。インスタンステンプレートはオートスケーリングを実装するときに用いる マネージドインスタンスグループ （MIG）の設定に必要です。 このように、イメージは VM のゴールデンイメージ（雛形イメージ）とするための専用リソースです。 参考 : イメージ管理のベスト プラクティス Web コンソール上の表記 Google Cloud コンソール上は、Compute Engine の左部メニューで「イメージ」と表記されています。前述の「マシンイメージ」と表記が似ている点に注意が必要です。この画面から、公開イメージとカスタムイメージの両方を確認できます。 イメージ（公開イメージとカスタムイメージ） 保存先のロケーション カスタムイメージでは、保存先のロケーションを特定リージョンまたはマルチリージョンから選択できます。 スナップショットやマシンイメージと異なり、カスタムイメージの作成時やカスタムイメージから VM の作成をする際に、ロケーションが異なっても、ネットワーク転送料金は発生しません。 参考 : イメージの保存ロケーションの選択 イメージファミリー イメージファミリー は、関連するイメージをグルーピングするためにイメージに付与するタグです。例えば、Debian 11 の公開イメージは debian-11 というイメージファミリーになっています。 新規インスタンス作成時に明示的なイメージ名を指定せず、イメージファミリーを指定することで、そのイメージファミリーの最新のイメージからインスタンスを起動することができます。同様に、インスタンステンプレートでも、明示的なイメージ名でなくイメージファミリーを指定できます。 参考 : イメージ ファミリー 参考 : イメージ ファミリーのベスト プラクティス Windows Server のイメージ作成 Windows Server のカスタムイメージを作成する場合、 Sysprep を実行することが推奨されます。 Sysprep は Windows OS のイメージ作成のために、マシン固有の情報を削除するための仕組みです。Windows OS のイメージ作成の前に、所定の手順に従って Sysprep を実行します。これを行わないと、特に Active Directory に Windows マシンを所属させたときなどに、複数のマシン間で情報が重複することによる想定外の挙動が発生する可能性があります。 参考 : Sysprep (システム準備) の概要 Windows Server が稼働する Compute Engine VM からカスタムイメージを作成する手順については、以下をご参照ください。 参考 : カスタム Windows Server イメージを作成する 料金 カスタムイメージは、保管容量に応じて料金が発生します。なおカスタムイメージは、マシンイメージやスナップショットとは異なり、増分バックアップではなく常にフルバックアップです。 2024年9月現在、カスタムイメージの保管料金は以下のとおりです。最新の料金は公式ページをご参照ください。 リージョン 単価 アイオワ（us-central1） $0.05 / GB 東京（asia-northeast1） $0.065 / GB 参考 : ディスクとイメージの料金 - カスタム イメージ ストレージ 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2024年末、Google の生成 AI 系サービスである Gemini アプリ（英名 Gemini app、旧 Bard）と Google Vids が、Google Workspace のコアサービスになります。 はじめに スケジュール 用語の解説 Gemini アプリ（Gemini app） Google Vids コアサービス エンタープライズ グレードのデータ保護 Gemini Business と Gemini Enterprise アドオンライセンス未適用ユーザーに Gemini アプリ利用を禁止する （コアサービス化以前） 概要 手順 はじめに 2024年末、Google の生成 AI 系サービスである Gemini アプリ （英名 Gemini app、旧 Bard）と Google Vids が、Google Workspace のコアサービスになることが発表されました。 参考 : Google Workspace extends Gemini benefits to millions of customers 上記発表には Google Vids が言及されていませんが、以下のドキュメントには詳細が記載されています。ただし前者のドキュメントは Google Workspace の管理者アカウントにログインした状態でないと閲覧できません。後者のドキュメントは全体向け発表のため、誰でも閲覧可能です。 参考 : Google Workspace に新しいコアサービスが登場 参考 : The Gemini app is now a core service with enterprise-grade data protection for more Google Workspace editions これらの発表では、Gemini アプリと Google Vids が、Google Workspace の Business、Enterprise、Frontline の各エディションでコアサービスとして扱われるようになることが明らかにされています。 これに伴い、Gemini アプリには「 エンタープライズ グレードのデータ保護 （enterprise-grade data protections）」が適用されます。これにより、入力されたプロンプトやファイル、生成されたテキストなどは人間のレビュワーによるレビュー対象にはなりませんし、Google のモデル改善に使われることがなくなります。 これまでの Gemini アプリは、Gemini Business、Gemini Enterprise、Gemini Education のアドオンライセンスが適用されたユーザーだけが、エンタープライズ グレードのデータ保護の適用対象でした。 また Google Vids は、Business Standard、Business Plus、Enterprise Standard、Enterprise Plus などのコアサービスになり、こちらもアドオンライセンスが不要になります。 スケジュール Gemini アプリと Google Vids のコアサービス化は、以下のスケジュールで開始され、順次ロールアウトされます。組織ごとに、開始の時期は違う可能性があります。 Gemini アプリのロールアウトは2024年10月25日以降に開始（当初は10月15日とされていたが後に訂正） Google Vids のロールアウトは2024年11月1日以降に開始 いずれも、ロールアウトは2024年末までに完了するとされています。 なお、2025年12月31日まで、全ユーザーは Google Vids の Help me create などの AI 補助機能を制限なしで利用可能です。2026年以降はアドオンライセンス等が必要になることがアナウンスされています。制限が適用される前に、Google から顧客への通知が行われます。 用語の解説 Gemini アプリ（Gemini app） Gemini アプリ （Gemini app）とは、以下の2つのチャットサービスの総称です。 Gemini ウェブアプリ（ gemini.google.com のこと。かつて Bard と呼ばれていた Web ブラウザ向け生成 AI チャットサービス） スマートフォン向け生成 AI チャットアプリ（Android および iOS 向け） いずれも、Google の生成 AI 基盤モデルである Gemini を基盤としたチャットアプリケーションです。 Google Vids Google Vids は生成 AI を使った、動画編集サービスです。2024年4月の Google Cloud Next 24（Las Vegas）で発表されました。 Google Vids は、テーマに沿ったストーリーボードを自動生成し、ユーザーが保有する動画、画像、音声などをもとに、容易に動画を編集することができるサービスです。他の Google Workspace サービスと一貫した操作性で利用でき、ブラウザ上で完結します。 なお Google Vids は、ユーザーがすでに持っている動画や画像を組み合わせて動画を完成させるサービスであり、ゼロから動画自体を生成するサービスではありません。 参考 : Google Vids 参考 : Empowering businesses of all sizes with new generative AI and security innovations in Google Workspace また前述のとおり、2025年12月31日まで、全ユーザーは Google Vids の Help me create などの AI 補助機能を制限なしで利用可能です。2026年以降はアドオンライセンス等が必要になることがアナウンスされています。制限が適用される前に、Google から顧客への通知が行われます。 コアサービス コアサービス とは、Google Workspace の中核をなすメインのサービス群を差します。Google ドライブ、Google ドキュメント、Google スプレッドシート、Google カレンダー、Google Chat などを指します。 参考 : サービスの概要 なおコアサービスは、Google の技術サポートの対象になることが明記されています。 参考 : サポート範囲 エンタープライズ グレードのデータ保護 エンタープライズ グレードのデータ保護 とは、Gemini の背景においては、「ユーザーが入力したテキストやアップロードしたファイルが、人間のレビュワーによって確認されたり、生成 AI モデルの改善（再トレーニング）に使われないこと」を指します。 Gemini アプリがコアサービス化する以前は、Gemini Business や Gemini Enterprise などのアドオンライセンスがない場合、エンタープライズ グレードのデータ保護が適用されないため、入力データやアップロードしたファイルは Google によって製品改善に利用される 可能性があり ます。 Google Workspace の管理者設定により、アドオンライセンスを割り当てていないユーザーの Gemini アプリの利用を禁止することができます。 なお、教育機関用のエディションである Gemini Education も、エンタープライズ グレードのデータ保護の対象です。 Gemini Business と Gemini Enterprise Gemini Business と Gemini Enterprise は、いずれも Google Workspace で Gemini の機能を使うためのアドオンライセンスです。 これらのアドオンを購入してユーザーに割り当てると、Gmail や Google ドキュメント、Google スライドといった Google Workspace アプリで Gemini の機能が追加で使えるようになります。Business と Enterprise では、管理者機能や、月間の使用量上限などに差があります。 参考 : Gemini for Google Workspace アドオンの比較 これらのアドオンライセンスを購入してユーザーに割り当てると、そのユーザーが Gemini に入力したデータには、エンタープライズ グレードのデータ保護が適用されます。 なお、Gemini Business、Gemini Enterprise に加え、AI Security や AI Meetings and Messaging といった生成 AI 系のアドオンライセンスを総称して、 Gemini for Google Workspace アドオン と呼びます。 参考 : Gemini for Google Workspace アドオンライセンス未適用ユーザーに Gemini アプリ利用を禁止する （コアサービス化以前） 概要 Gemini アプリのコアサービス化は、2024年10月25日から2024年12月末までの間の、順次ロールアウトです。 コアサービス化するまでの間は、前述の通り、Gemini Business や Gemini Enterprise、Gemini Education などのアドオンライセンスがない場合、Google Workspace ユーザーが Gemini アプリを使うと、エンタープライズ グレードのデータ保護が適用されないため、そのデータは Google によって製品改善に利用される 可能性があり ます。 その可能性を排除するため、アドオンライセンスが割り当てられていないユーザーは Gemini アプリを利用できなくなるよう、管理者設定で禁止することが可能です。 手順 Google Workspace の管理画面（ admin.google.com ）で、 生成 AI > Gemini > ユーザー アクセス に移動します。 デフォルトでは 次の条件下で、すべてのユーザーに Gemini へのアクセスを許可する の設定になっている可能性があります。こちらの設定だと、Gemini Business、Enterprise、Education のアドオンライセンスが割り当てられていないユーザーでも Gemini アプリが利用できます。それらのユーザーには、データ保護は適用されません。 以下のスクリーンショットのように、 Gemini for Workspace（Business、Enterprise、Education）のライセンスを持つユーザーのみに、コアサービスとしての Gemini へのアクセスを許可します（顧客データ保護が有効） に設定すると、アドオンライセンスを持っていないユーザーの Gemini アプリ利用は禁止されます。データ保護が適用されない状態での Gemini アプリ利用が不可能になり、データ保護の観点では、よりセキュアになります。 Gemini アプリ利用の制限 この設定の状態で、アドオンライセンスが割り当てられていない Google アカウントで Gemini ウェブアプリにアクセスしようとすると、以下のように表示されます。Gemini ウェブアプリが利用できなくなっていることがわかります。 利用が禁止された場合の表示 Gemini へのアクセス権がありません。このサービスを有効にするには、管理コンソールにログインしてください。 なおこの設定は、2024年末までに Gemini アプリがコアサービス化してエンタープライズ グレードのデータ保護が適用されれば、不要になります。適用された場合、Google Workspace の対象エディションのライセンスが割り当てられたユーザーは、自動的に Gemini アプリが利用可能になります。 また Google Vids については、コアサービス化が適用された時点で、明示的な設定変更なしに対象エディションの全ユーザーが Google Vids を使えるようになります。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。2024年9月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Cloud Run の Deterministic URL が Preview → GA BigQuery の VECTOR_SEARCH() と vector index が Preview → GA AppSheet で管理者コンソールが利用可能に（Preview） VPC SC のルールで Googleグループが利用可能に（Preview） Firestore でベクトル検索が Preview → GA Vertex AI Search で自然言語クエリフィルタ（Preview） Google Meet Add-ons SDK が一般公開 Cloud SQL(Enterprise Plus)シングルゾーンインスタンスで near-zero downtime メンテナンス Oracle Database@Google Cloud が Preview -> GA（一般公開） Application Load Balancers で Authorization policy （Preview） Priviliged Access Manager（PAM）が Preview -> GA 複数の Cloud Run 向け組織ポリシーが Preview 公開 Cloud Run の Direct VPC 経由で Secure Web Proxy が利用可能に GitLab on Google Cloud が一般公開 Colab Enterprise で CMEK が使えるように BigQuery workflows が Preview 公開 Spanner editions が提供開始 gemini-1.5-pro-002 と gemini-1.5-flash-002 が一般公開 複数の Gemini in Looker 機能が Preview Cloud KMS の Autokey 機能が Preview→GA Cloud SQL バックアップを AlloyDB free trial cluster として起動できるように Gemini apps、Google Vids が Google Workspace のコアサービスに Cloud Storage で cross-bucket replication が Preview はじめに 当記事では、毎月の Google Cloud アップデートのうち特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Cloud Run の Deterministic URL が Preview → GA Deterministic URL (2024-09-03) Cloud Run の Deterministic URL が Preview → GA。 URL は (サービス名)-(プロジェクト番号).(リージョン).run.app となり、サービス名とプロジェクト番号がわかれば URL が決め打ちになる。 コンソール画面のデフォルト表記もこちらになった（詳細情報を確認すると、従来型 URL も確認可能）。 BigQuery の VECTOR_SEARCH() と vector index が Preview → GA VECTOR_SEARCH (2024-09-04) 今年1月に Preview 公開されていた BigQuery の VECTOR_SEARCH() 関数と vector index が Preview → GA。 BigQuery 上でベクトル検索を実現し、意味論検索（セマンティック検索）が可能に。以下の記事も参照。 blog.g-gen.co.jp AppSheet で管理者コンソールが利用可能に（Preview） Manage using the AppSheet Admin Console (2024-08-30) ノーコード開発ツール AppSheet で管理者コンソールが利用可能に（Preview）。 ユーザー数やアプリ数量、利用状況、ポリシー管理などが可能。より統制を効かせ、セキュアに組織で AppSheet を使えるようになる。 利用には Enterprise Plus ライセンスが必要。 VPC SC のルールで Googleグループが利用可能に（Preview） Ingress rules reference (2024-09-05) VPC Service Controls の Ingress/Egress ルールで Google グループによる許可設定が可能に（Preview）。 従来は Google アカウントを個々に指定する必要があった。グループ指定で管理が大幅に楽になる。 また Workload/Workforce Identity の指定も可能になっている（Preview）。 Firestore でベクトル検索が Preview → GA Search with vector embeddings (2024-09-05) Firestore でベクトル検索が Preview → GA。 Vertex AI Text Embeddings API などを使って作成したベクトル値を Firestore に保存し、ベクトルインデックスを作成すれば、KNN ベクトル検索が可能になる。 Vertex AI Search で自然言語クエリフィルタ（Preview） Search with vector embeddings (2024-09-05) Vertex AI Search で自然言語クエリフィルタが利用可能に（Preview）。 構造化データストア（BigQuery / Cloud Storage）に対する検索の際、自然言語でのクエリを、「フィルタ」と「クエリ」に自動的に分解してくれる。以下はその例。 元のクエリ "Find a coffee shop serving banana bread" 変換後 "query": "banana bread", "filter": "type": ANY(\"cafe\") Google Meet Add-ons SDK が一般公開 Google Meet Add-ons SDK is now generally available (2024-09-11) Google Meet Add-ons SDK が一般公開。 この SDK を使って、iframe で独自アプリを Google Meet 画面に組み込みできる。Meet 会議を繋ぎながら、共同でインタラクティブな Web アプリを操作するような実装も可能。Marketplace での配布もできる。 Cloud SQL(Enterprise Plus)シングルゾーンインスタンスで near-zero downtime メンテナンス Near-zero downtime planned maintenance (2024-09-05) Cloud SQL for MySQL/PostgreSQL の Enterprise Plus エディションで、シングルゾーンのインスタンスでも near-zero downtime メンテナンスができるように。 これまでは高可用性（HA = マルチゾーン）である必要があった。near-zero downtime メンテナンスでは、計画メンテナンスによる停止時間が1秒未満となる。 なお near-zero downtime メンテナンスでない場合の停止時間は、通常は60秒未満。 Oracle Database@Google Cloud が Preview -> GA（一般公開） Oracle Database@Google Cloud overview (2024-09-16) Oracle Database@Google Cloud が Preview -> GA（一般公開）。 Google Cloud のデータセンターで稼働する Exadata Database Service と Autonomous Database Service が利用できる。インスタンスを Marketplace からデプロイし、VPC からプライベートネットワークでアクセスできる。 Application Load Balancers で Authorization policy （Preview） Authorization policy overview (2024-09-16) Google Cloud の Application Load Balancers（旧 HTTP(S)ロードバランサー）で Authorization policy が利用可能に（Preview）。 Authorization policy では、以下をベースにしてアプリへのアクセス制御（認証）が可能になる。 相互 TLS クライアント VM のサービスアカウント クライアント VM のリソースタグ YAML 形式でポリシーを定義し、ロードバランサー（Forwarding rules）にセットする。 Priviliged Access Manager（PAM）が Preview -> GA IAM release notes - September 16, 2024 (2024-09-16) Priviliged Access Manager（PAM）が Preview -> GA に。 IAM 権限付与の承認フローを簡単に実装。Google Cloud の Web コンソールで「申請→承認→権限付与」を自動化できる。今回、以下の機能も新規で追加された。 PAM 以外から権限追加された時のアラート VPC Service Controls との統合 Pub/Sub 統合 PAM については以下の記事を参照。 blog.g-gen.co.jp 複数の Cloud Run 向け組織ポリシーが Preview 公開 Apply custom constraints for projects (2024-09-16) 複数の Cloud Run 向け組織ポリシーが Preview 公開。組織レベル・フォルダレベル・プロジェクトレベルで利用可能。Cloud Run でのプロダクト開発に統制を効かせられる。 Restrict ingress settings Require a maximum memory limit Prevent non-GA launch stages Require Binary Authorization Require a liveness probe for every container Require a sidecar through a container image prefix and port Cloud Run の Direct VPC 経由で Secure Web Proxy が利用可能に Supported feature (2024-09-17) Cloud Run で、Direct VPC 経由で Secure Web Proxy が利用可能に。 Cloud Run からのアウトバウンドの HTTP トラフィックを検査し、URL ホワイトリスト、接続元サービスアカウント、HTTP メソッド等によるアクセス制御が可能。 なお Secure Web Proxy はフルマネージドの HTTP 出口制御プロキシ。VPC のネクストホップとしても設定できるため、クライアントでプロキシを明示的に指定する必要がない。 GitLab on Google Cloud が一般公開 GitLab on Google Cloud documentation (2024-09-20) GitLab on Google Cloud が一般公開。 GitLab と Google Cloud の間で、認証・認可やデプロイの連携がシンプルに行えるようになる。2024年4月の Google Cloud Next '24 で、Google Cloud と GitLab の連携強化のベータ版が発表されていた。 Colab Enterprise で CMEK が使えるように Use customer-managed encryption keys (CMEK) (2024-09-23) フルマネージドのノートブックサービス Colab Enterprise で CMEK（customer-managed encryption keys）が使えるようになった。 監査要件や高度なセキュリティ要件に対応可能になり、利用の幅が広がる。 BigQuery workflows が Preview 公開 Introduction to workflows (2024-09-23) BigQuery workflows が Preview 公開。 Google Cloud Next '24 で発表されていた機能が、Preview 利用可能に。クエリまたは notebook をスケジュールに基づいて順次実行できる。 Spanner editions が提供開始 Spanner editions overview (2024-09-24) 2024年9月24日から、Spanner editions が提供開始。Standard、Enterprise、Enterprise Plus の3エディション。 エディションごとに SLA、マルチリージョン可否、全文検索やベクトル検索の可否が異なる。旧料金プランからの移行スケジュールは以下のとおり。 2024-09-24 : editions が提供開始 2024-11-01 : 新規インスタンスで旧料金体系が使えなくなる 2025-01-13 : 旧料金体系の既存インスタンスは自動的に editions に切り替わる。機能停止が発生しないよう、最低限の edition が自動選択される gemini-1.5-pro-002 と gemini-1.5-flash-002 が一般公開 Available stable Gemini model versions (2024-09-24) Gemini の新しい安定版、 gemini-1.5-pro-002 と gemini-1.5-flash-002 が一般公開。以下で品質が向上したとされる。 ハルシネーション減少 RAG ユースケース 指示の遵守 多言語対応 SQL 生成 音声認識 文書認識 長いコンテキスト 計算と論理 複数の Gemini in Looker 機能が Preview Gemini in Looker (2024-09-24) 複数の Gemini in Looker 機能が Preview。 これまで発表された「Gemini in Looker」は、Looker ではなく Looker Studio Pro の機能だった。今回は Looker（Google Cloud core）の機能発表。利用可能になるのは、以下の2機能。 Create custom Looker visualizations HighCharts API による可視化において自然言語指示を受け付ける Generate LookML Looker IDE 上で利用 自然言語指示により、LookML の生成 Cloud KMS の Autokey 機能が Preview→GA Autokey overview (2024-09-24) Cloud KMS の Autokey 機能が Preview→GA に。 Autokey をフォルダに設定すると、配下のプロジェクトで CMEK 暗号化利用時にキーリング・キー作成、サービスアカウント作成、権限付与などが自動化される。組織ポリシーと組み合わせて CMEK の必須化も可能。 Autokey の簡単な解説は、以下も参照。 blog.g-gen.co.jp Cloud SQL バックアップを AlloyDB free trial cluster として起動できるように Migrate from Cloud SQL for PostgreSQL to AlloyDB for PostgreSQL (2024-09-25) Cloud SQL for PostgreSQL のバックアップを、AlloyDB の free trial cluster として起動できるようになった（Preview）。 Cloud SQL から AlloyDB への移行や PoC が、簡単に実現可能。 Gemini apps、Google Vids が Google Workspace のコアサービスに Google Workspace extends Gemini benefits to millions of customers (2024-09-25) Gemini apps（旧 Bard である Gemini web app = gemini.google.com と、Gemini モバイルアプリを指す）が Google Workspace Business、Enterprise、Frontline のコアサービスに含まれるようになる。 従来は Gemini アドオンライセンスがないと、データ保護（入力データや生成物が再学習に使われないこと）が適用されなかったが、コアサービス化により今後はアドオンなしでもデータ保護が適用される。スケジュールは以下のとおり。 Gemini apps は 2024-10-15 からロールアウト開始 Google Vids は 2024-11-01 からロールアウト開始 いずれも12月末までに完了 以下の公式ドキュメントも参照（ただし Google Workspace 管理者アカウントでログインしていないと閲覧できない）。 参考 : New core services coming to Google Workspace Cloud Storage で cross-bucket replication が Preview Use cross-bucket replication (2024-09-25) Cloud Storage で cross-bucket replication が Preview 公開。 あるバケットから別のバケットに、新規オブジェクトや更新されたオブジェクトが非同期でコピーされる。バックエンドでは Storage Transfer Service が使われている。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Cloud（旧称 GCP）のリソースインベントリサービスである Cloud Asset Inventory を解説します。 Cloud Asset Inventory とは 料金 用語 アセット アセットタイプ アセット関係 フィード エクスポート 代表的なユースケース アセット履歴の確認 プリンシパルの検索 リソースの IAM 許可ポリシーの検索 アセット変更の通知 Asset Insight Cloud Asset Inventory とは Cloud Asset Inventory とは、Google Cloud のリソースやポリシーの構成情報を取得、保存、検索するためのサービスです。 Cloud Asset Inventory は、Compute Engine VM、BigQuery テーブル、Cloud Storage バケットなどの Google Cloud リソースや、それらが持つ IAM 許可ポリシーなどのアセット情報（設定の状態）を過去35日間分、保存します。これらのアセット情報に対して、クエリを投入して検索したり、設定に変更が行われた際のリアルタイム通知を設定することもできます。 Cloud Asset Inventory は、以下のようなユースケースに役立ちます。 意図しない設定変更が行われた際に、管理者に通知する 意図しない設定変更が発生した際に、切り戻しのために過去の状態を参照する 過去の設定変更のタイミングや変更内容を確認する ある特定の Google アカウントが、組織（プロジェクト）内のどのリソースに IAM 権限を持っているか確認する 設定が想定どおりの状態かどうか、定期的に棚卸しする Cloud Asset Inventory は、何も設定しなくても Google Cloud 組織やプロジェクトで デフォルトで有効化 されており、最新のアセット情報に加えて、過去35日間分の履歴が保存されます。 過去35日間分より以前のデータを保持したい場合、Cloud Storage や BigQuery テーブルにエクスポートすることも可能です。 参考 : Cloud Asset Inventory の概要 料金 Cloud Asset Inventory は無料です。 エクスポートを実行した場合、書き込み先の Cloud Storage や BigQuery の料金が発生します。 参考 : Cloud Asset Inventory の料金 用語 アセット Cloud Asset Inventory における アセット とは、Google Cloud のリソース、ポリシー、またはランタイム情報のことです。 リソース とは Compute Engine VM、BigQuery テーブル、Cloud Storage バケットなどを指します。 ポリシー とは、IAM 許可ポリシー、組織のポリシー、Access Context Manager（VPC Service Controls）のアクセスポリシーのことです。 ランタイム情報 とは、OS Inventory Management（VM Manager が取得する Compute Engine VM 内部の OS やパッケージ情報）のことです。 これら3つを総称しアセットと呼びます。Cloud Asset Inventory は、これらアセットの状態を取得し、保存します。ただし、一部の Google Cloud サービスの中には Cloud Asset Inventory で対応されていないものもあります。どのタイプのリソースやポリシーがサポートされているかは、以下のドキュメントをご参照ください。 参考 : サポートされているアセットタイプ アセットのスナップショット情報（ある時点での設定の状態）は、履歴として35日間保存されます。この期間内であれば、リソースやポリシーの設定が変更された前後での状態の比較が可能です。 アセットタイプ Web コンソールや gcloud コマンド、REST API 等を使ってアセットをクエリする際、フィルタのために アセットタイプ を指定します。 アセットタイプには、以下のようなものがあります。クエリ時には、括弧の中の文字列を使用します。 組織（ cloudresourcemanager.googleapis.com/Organization ） フォルダ（ cloudresourcemanager.googleapis.com/Folder ） プロジェクト（ cloudresourcemanager.googleapis.com/Project ） BigQuery データセット（ bigquery.googleapis.com/Dataset ） BigQuery テーブル（ bigquery.googleapis.com/Table ） Compute Engine VM（ compute.googleapis.com/Instance ） Cloud Storage バケット（ storage.googleapis.com/Bucket ） アセット関係 アセット関係 （Asset relationships）は、関係性のあるアセット同士のリレーション情報です。 例えば、Compute Engine のインスタンスグループは、VM リソースとリレーションを持っています。アセット関係をクエリすることで、こういったリソース同士のリレーション情報も確認できます。 ただし、アセット関係を利用するには Security Command Center のプレミアムティアにサブスクライブする 必要があります。Security Command Center については以下の記事をご参照ください。 blog.g-gen.co.jp フィード フィード は、リソースやポリシーの設定変更を検知するために作成する、通知設定です。 対象のアセット名、もしくはアセットタイプを指定すると、そのアセットに変更が発生した際に通知が可能です。 エクスポート アセット情報は35日間分しか保持されないため、それ以上にアセット情報を保存しておきたい場合は、Cloud Storage バケットまたは BigQuery テーブルにアセットをエクスポートします。 2024年10月現在、エクスポートの設定は gcloud コマンドまたは REST API を使用して行います。Web コンソールから設定することはできません。 Cloud Storage へのエクスポートの場合、ファイルフォーマットは JSONL（改行区切り JSON）になります。 エクスポートはワンショットで行われるため、継続的にアセット情報をエクスポートするには、Cloud Run functions 等で定期的にエクスポート API を実行する必要があります。 参考 : BigQuery へのエクスポート 参考 : Cloud Storage へのエクスポート 代表的なユースケース アセット履歴の確認 最も一般的なユースケースは、ある時点と別の時点でのリソース（ポリシー）の設定状況の比較です。 たとえば、管理者が把握しないうちに Compute Engine VM の設定が変更されていたことに気がついたとします。Cloud Asset Inventory の Web コンソール画面で、以下のように、ある時点とある時点の設定状態の差分を確認することができます。 この画面では、VM のサービスアカウント設定やマシンタイプなどリソースの設定状態に加えて、各リソースの IAM 許可ポリシーへの変更も確認することができます。 アセット履歴は、Google Cloud の Web コンソールのほか、gcloud コマンドラインや REST API で取得することができます。 参考 : リソースの検索 参考 : アセット履歴の表示 プリンシパルの検索 アセットに対してクエリを行うことで、あるプリンシパル（Google アカウントやグループ）が組織やプロジェクトでどのリソースに対して IAM 権限を持っているかを一覧表示することができます。 参考 : IAM 許可ポリシーの検索 参考 : IAM 許可ポリシーの検索のサンプル 例えば、ID が 1234567890 の組織内で、 john@example.com アカウントがオーナー権限を持っている IAM 許可ポリシーを一覧化するには、以下のコマンドを実行します。 gcloud asset search-all-iam-policies \ --scope = organizations/ 1234567890 \ --query =" policy:(roles/owner john@example.com) " \ --format = json リソースの IAM 許可ポリシーの検索 Google Cloud コンソールの Cloud Asset Inventory 画面から、あるリソースの IAM 許可ポリシーにどのようなプリンシパルとロールが紐づいているか、クエリをかけることができます。以下は、あるプロジェクトに対してオーナー権限を持っているプリンシパルの一覧をクエリした様子です。 コンソール画面からのクエリ gcloud コマンドでは、あるリソースに対して紐づいている IAM ロールやプリンシパルを調べようとしたとき、単純にそのリソースの IAM 許可ポリシーを gloud 確認（describe）しても、そのリソースに直接的に書き込まれている IAM 許可ポリシーが見えるだけであり、親リソース（組織やプロジェクトなど）から継承した IAM 権限は表示されません。 gcloud コマンドで Cloud Assets Inventory に対して以下のようにクエリすることで、継承された権限を含めて、有効（effective）な IAM 権限を一覧表示することができます。 gcloud asset get-effective-iam-policy \ --scope = organizations/ 1234567890 \ --names = //bigquery.googleapis.com/projects/my-project/datasets/my_dataset/tables/my_table \ --format = json 出力は以下のようになります。 { " policyResults ": [ { " fullResourceName ": " //bigquery.googleapis.com/projects/my-project/datasets/my_dataset ", " policies ": [ { " attachedResource ": " //bigquery.googleapis.com/projects/my-project/datasets/my_dataset ", " policy ": { " bindings ": [ { " members ": [ " projectEditor:my-project " ] , " role ": " roles/bigquery.dataEditor " } , { " members ": [ " projectOwner:my-project ", " user:john@example.com " ] , " role ": " roles/bigquery.dataOwner " } , { " members ": [ " projectViewer:my-project " ] , " role ": " roles/bigquery.dataViewer " } ] } } , { " attachedResource ": " //cloudresourcemanager.googleapis.com/projects/my-project ", " policy ": { " bindings ": [ { " members ": [ " serviceAccount:firebase-measurement@system.gserviceaccount.com ", " serviceAccount:p1234567890-123123@gcp-sa-logging.iam.gserviceaccount.com ", " serviceAccount:search-console-data-export@system.gserviceaccount.com ", " serviceAccount:service-1234567890@gcp-sa-dataform.iam.gserviceaccount.com " ] , " role ": " roles/bigquery.dataEditor " } , ] } }, { " attachedResource ": " //cloudresourcemanager.googleapis.com/folders/098765432109 ", " policy ": { " bindings ": [ .... (略) } アセット変更の通知 アセット名もしくはアセットタイプ（ compute.googleapis.com/Network など）を指定してフィードを作成し、リソースやポリシーに設定変更が行われたときにニアリアルタイムで通知を受け取ることができます。 例として、頻繁に変更されないはずのプロジェクトの IAM 許可ポリシーに対する変更を監視する、などのユースケースが考えられます。 参考 : アセットの変更のモニタリング 通知は Pub/Sub に対して行われます。Pub/Sub へ投入されたメッセージは、Cloud Run functions などを通して取得し、Slack や E メール通知、その他の後続アクションにつなげることが可能です。 また通知先として Pub/Sub を指定しない場合、通知は Cloud Logging に対して記録されます。Cloud Logging へメッセージを記録すれば、プログラムを作成しなくても ログベースのアラート 機能により簡単に E メールや Slack への通知が実装できます。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログ監視 また、CEL（Common Expression Language）フォーマットで条件を記述し、詳細に通知条件をカスタマイズすることもできます。 参考 : 条件付きでアセットの変更をモニタリングする Asset Insight Asset Insight は、Cloud Asset Inventory が収集したアセット情報を Google Cloud の Recommender API が分析し、潜在的なリスクを検出するためのツールです。 2024年10月現在、gcloud コマンドラインや REST API 経由でのみ利用可能であり、Web コンソール画面は用意されていません。 Asset Insight では サブタイプ という検査種別を指定して分析を実行します。それぞれのサブタイプでは、以下のようなリスクを検知できます。 サブタイプ名 検知内容 EXTERNAL_MEMBER 別組織のアカウントまたはグループを含む IAM ポリシーを検出 EXTERNAL_POLICY_EDITOR IAM ポリシーを変更する権限が付与された別組織のアカウントまたはグループを含む IAM ポリシーを検出 EXTERNAL_CLOUD_STORAGE_OBJECT_VIEWER Cloud Storage のオブジェクト取得または一覧表示権限が付与された、別組織のアカウントまたはグループを含む IAM ポリシーを検出 EXTERNAL_SERVICE_ACCOUNT_IMPERSONATOR サービスアカウントの権限を借用（impersonate）する権限が付与されている、別組織のアカウントまたはグループを含む IAM ポリシーを検出 TERMINATED_MEMBER 無効化や削除されたアカウントまたはグループを含む IAM ポリシーを検出 PUBLIC_IAM_POLICY 任意の認証済みアカウント（ allUsers ）、つまりログイン済みのすべての Google アカウントに対する許可を含む IAM ポリシーを検出 OWNER_TERMINATED_PROJECT プロジェクトの IAM ポリシーにアクティブなアカウントまたはグループが含まれないプロジェクトを検出 以下は、あるプロジェクトに、組織外のメンバーが IAM 権限を持っていないかどうかを調べるコマンドラインです。 gcloud recommender insights list \ --project = my-test-project \ --location = global \ --insight-type = google.cloudasset.asset.Insight \ --filter =" insightSubtype:EXTERNAL_MEMBER " \ --format =" json " 出力は、以下のようになります。 [ { " category ": " SECURITY ", " content ": { " domain ": " example.co.jp ", " matchedPolicies ": [ { " matchedBindings ": [ { " matchedMembers ": [ " user:external-user@example.co.jp " ] , " role ": " roles/bigquery.dataViewer " } ] , " project ": " projects/1234567890 ", " resource ": " //bigquery.googleapis.com/projects/my-test-project/datasets/my_dataset/tables/my_table " } ] , " policyCount ": 1 , " policySearchQuery ": " policy: example.co.jp " } , " description ": " Domain example.co.jp detected in 1 IAM policies ", " etag ": " \" 12345678abcdefgh \" ", " insightSubtype ": " EXTERNAL_MEMBER ", " lastRefreshTime ": " 2024-09-16T08:13:25Z ", " name ": " projects/1234567890/locations/global/insightTypes/google.cloudasset.asset.Insight/insights/1234abcd-1234-12ab-12ab-123456sbcdef ", " observationPeriod ": " 0s ", " severity ": " LOW ", " stateInfo ": { " state ": " ACTIVE " } , " targetResources ": [ " //cloudresourcemanager.googleapis.com/projects/1234567890 " ] } ] 参考 : Asset Insights の使用 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。複数の Google Cloud プロジェクトの Compute Engine VM の情報一覧を取得する bash スクリプトを紹介します。 はじめに 概要 前提条件 免責事項 ソースコード 出力例 実行方法 入力ファイルの準備 スクリプトの実行 応用 はじめに 概要 当記事で紹介するのは、複数の Google Cloud プロジェクトに存在する Compute Engine VM の一覧を CSV ファイルに出力するためのスクリプトです。 当スクリプトを使うことで、Google Cloud 組織配下の全 VM を一覧にすることができます。組織内での VM の棚卸し等にご利用ください。 前提条件 当 bash スクリプトは、 Debian GNU/Linux 12 (bookworm) 上で開発され、動作確認されています。 また、以下のソフトウェアがインストールされていることが前提です。括弧内は開発時のバージョンです。 gcloud（ Google Cloud SDK 488.0.0 ） jq （ jq-1.6 ） また実行時は、gcloud コマンドの認証情報に、VM の一覧表示権限を持つ Google アカウントが設定されている必要があります。 参考 : ユーザー アカウントを使用して認可する 参考 : サービス アカウントを使用して承認する 参考 : Compute Engine IAM のロールと権限 なお、組織内の全プロジェクトを一覧取得する方法については、以下も参照してください。 blog.g-gen.co.jp 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 ソースコード 当ソースコードは、前述の 免責事項 をご理解のうえ、ご利用ください。 list_all_vms.sh #!/bin/bash # 引数チェック if [ $# -ne 1 ]; then echo " ERROR : Please specify project list file. " exit 1 fi # 変数定義 input_file = $1 datetime = `date " +%Y%m%d%H%M " ` output_file_name = " all_vms_ ${datetime} .csv " # プロジェクトごとにループを実行 while read project; do ## VM 情報取得処理 result = `gcloud compute instances list --project = ${project} --format = json --quiet` ## エラーの場合はスキップ if [ $? -ne 0 ]; then continue fi ## ファイルに記録 IFS =$' \n '; for vm in ` echo ${result} | jq -c ' .[] ' ` ; do # JSON から各要素を抽出 id = ` echo ${vm} | jq -r .id` name = ` echo ${vm} | jq -r .name` zone = ` echo ${vm} | jq -r .zone | rev | cut -d / -f 1 | rev` machine_type = ` echo ${vm} | jq -r .machineType | rev | cut -d / -f 1 | rev` internal_ip = ` echo ${vm} | jq -r .networkInterfaces [ 0 ] .networkIP` service_account = ` echo ${vm} | jq -r .serviceAccounts [ 0 ] .email` # ファイルと標準出力に出力 echo " ${project} , ${id} , ${name} , ${zone} , ${machine_type} , ${internal_ip} , ${service_account} " | tee -a ${output_file_name} done continue done < ${input_file} echo "" echo " ##### All VMs are listed in the file below ##### " ls -la ${output_file_name} exit 0 出力例 以下のような CSV ファイルが出力されます。わかりやすいようにテーブル形式で掲載していますが、実際には出力は csv であり、ヘッダは出力されません。 プロジェクト ID インスタンス ID インスタンス 名 ゾーン マシンタイプ 内部 IP アドレス サービスアカウント my-project-01 12345 my-test-vm-01 us-central1-b e2-micro 10.128.0.33 1234567890-compute@developer.gserviceaccount.com my-project-01 23456 my-test-vm-02-tokyo asia-northeast1-b e2-medium 10.146.0.2 1234567890-compute@developer.gserviceaccount.com my-project-02 78901 example-vm-1 us-central1-c e2-medium 10.128.0.2 0987654321-compute@developer.gserviceaccount.com my-project-03 54321 hoge-vm asia-northeast1-c e2-micro 10.146.0.5 2345678901-compute@developer.gserviceaccount.com 実行方法 入力ファイルの準備 まず、入力ファイルとして1行に1つの Google Cloud プロジェクト ID を記載したテキストファイルを用意します（プロジェクト名ではなく、ID であることに注意してください）。 projects.txt my-project-01 my-project-02 my-project-03 このファイルを作るには、以下の記事で紹介しているスクリプトを利用することもできます。 blog.g-gen.co.jp スクリプトの実行 その後、以下のようにスクリプトを実行します。 projects.txt は、用意したテキストファイル名に置き換えてください。 ./list_all_vms.sh projects.txt 応用 ソースコードの28行目〜36行目を修正することで、任意の情報を CSV ファイルに含めることができます。 同箇所では、JSON 形式で取得した VM 情報を、jq コマンドでフィルタして情報を取得しています。参考として、VM 情報は以下のようなフォーマットになっています（2024年9月現在）。 { " canIpForward ": false , " confidentialInstanceConfig ": { " enableConfidentialCompute ": false } , " cpuPlatform ": " Unknown CPU Platform ", " creationTimestamp ": " 2024-08-31T18:53:29.048-07:00 ", " deletionProtection ": false , " description ": "", " disks ": [ { " architecture ": " X86_64 ", " autoDelete ": true , " boot ": true , " deviceName ": " my-test-vm ", " diskSizeGb ": " 10 ", " guestOsFeatures ": [ { " type ": " UEFI_COMPATIBLE " } , { " type ": " VIRTIO_SCSI_MULTIQUEUE " } , { " type ": " GVNIC " } , { " type ": " SEV_CAPABLE " } , { " type ": " SEV_LIVE_MIGRATABLE_V2 " } ] , " index ": 0 , " interface ": " SCSI ", " kind ": " compute#attachedDisk ", " licenses ": [ " https://www.googleapis.com/compute/v1/projects/debian-cloud/global/licenses/debian-12-bookworm " ] , " mode ": " READ_WRITE ", " source ": " https://www.googleapis.com/compute/v1/projects/my-project/zones/us-central1-b/disks/my-test-vm ", " type ": " PERSISTENT " } ] , " displayDevice ": { " enableDisplay ": false } , " fingerprint ": " xxxxxxxxxxx= ", " id ": " 1234567890123456789 ", " keyRevocationActionType ": " NONE ", " kind ": " compute#instance ", " labelFingerprint ": " xxxxxxxxxxx= ", " lastStartTimestamp ": " 2024-09-02T19:49:37.720-07:00 ", " lastStopTimestamp ": " 2024-09-02T20:07:08.821-07:00 ", " machineType ": " https://www.googleapis.com/compute/v1/projects/my-project/zones/us-central1-b/machineTypes/e2-micro ", " metadata ": { " fingerprint ": " xxxxxxxxxxx= ", " items ": [ { " key ": " enable-oslogin ", " value ": " true " } ] , " kind ": " compute#metadata " } , " name ": " my-test-vm ", " networkInterfaces ": [ { " accessConfigs ": [ { " kind ": " compute#accessConfig ", " name ": " External NAT ", " networkTier ": " PREMIUM ", " type ": " ONE_TO_ONE_NAT " } ] , " fingerprint ": " xxxxxxxxxxx= ", " kind ": " compute#networkInterface ", " name ": " nic0 ", " network ": " https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default ", " networkIP ": " 10.0.0.2 ", " stackType ": " IPV4_ONLY ", " subnetwork ": " https://www.googleapis.com/compute/v1/projects/my-project/regions/us-central1/subnetworks/default " } ] , " reservationAffinity ": { " consumeReservationType ": " ANY_RESERVATION " } , " satisfiesPzi ": false , " scheduling ": { " automaticRestart ": true , " onHostMaintenance ": " MIGRATE ", " preemptible ": false , " provisioningModel ": " STANDARD " } , " selfLink ": " https://www.googleapis.com/compute/v1/projects/my-project/zones/us-central1-b/instances/my-test-vm ", " serviceAccounts ": [ { " email ": " 1234567890-compute@developer.gserviceaccount.com ", " scopes ": [ " https://www.googleapis.com/auth/devstorage.read_only ", " https://www.googleapis.com/auth/logging.write ", " https://www.googleapis.com/auth/monitoring.write ", " https://www.googleapis.com/auth/service.management.readonly ", " https://www.googleapis.com/auth/servicecontrol ", " https://www.googleapis.com/auth/trace.append " ] } ] , " shieldedInstanceConfig ": { " enableIntegrityMonitoring ": true , " enableSecureBoot ": false , " enableVtpm ": true } , " shieldedInstanceIntegrityPolicy ": { " updateAutoLearnPolicy ": true } , " startRestricted ": false , " status ": " TERMINATED ", " tags ": { " fingerprint ": " xxxxxxxxxxx= " } , " zone ": " https://www.googleapis.com/compute/v1/projects/my-project/zones/us-central1-b " } 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。特定の Google Cloud 組織配下にあるすべてのプロジェクトを取得する bash スクリプトを紹介します。 はじめに 概要 前提条件 免責事項 ソースコード 出力例 実行方法 入力情報の準備 スクリプトの実行 ソースコードの説明 注意点 はじめに 概要 当記事で紹介するのは、指定した Google Cloud 組織またはフォルダの配下にあるすべてのプロジェクトの一覧を CSV ファイルに出力するためのスクリプトです。当スクリプトを使うことで、特定の Google Cloud 組織やフォルダ配下の全プロジェクトを一覧化することができます。 前提として、gcloud コマンドを使うと、自分のアカウントが get/list 権限を持つプロジェクトの一覧が取得できます。 gcloud projects list ` しかしこのコマンドでは、もし自分が複数の組織に対して権限を持っている場合、すべての組織配下のプロジェクトが一覧表示されてしまいます。特定の組織のみに所属するプロジェクトを一覧表示したい場合、少し工夫したスクリプトを書く必要があります。 参考 : gcloud projects list 参考 : 階層内のすべてのプロジェクトとフォルダの一覧表示 前提条件 当 bash スクリプトは、 Debian GNU/Linux 12 (bookworm) 上で開発され、動作確認されています。 また、以下のソフトウェアがインストールされていることが前提です。括弧内は開発時のバージョンです。 gcloud（ Google Cloud SDK 488.0.0 ） jq （ jq-1.6 ） また実行時は、gcloud コマンドの認証情報に、フォルダやプロジェクト一覧表示権限を持つ Google アカウントが設定されている必要があります。 参考 : ユーザー アカウントを使用して認可する 参考 : サービス アカウントを使用して承認する 参考 : IAM を使用したフォルダのアクセス制御 参考 : IAM を使用したプロジェクトのアクセス制御 免責事項 当記事で紹介するプログラムのソースコードは、ご自身の責任のもと、使用、引用、改変、再配布して構いません。 ただし、同ソースコードが原因で発生した不利益やトラブルについては、当社は一切の責任を負いません。 ソースコード 当ソースコードは、前述の 免責事項 をご理解のうえ、ご利用ください。 list_projects.sh #!/bin/bash # 引数チェック if [ $# -ne 2 ]; then echo " ERROR : Please specify parent resource's ID and resource type (folder/organization). " echo " usage : $0 (resouce_id) (resource_type) " exit 1 fi # 変数定義 root_parent_id = $1 root_parent_type = $2 datetime = `date " +%Y%m%d%H%M " ` file_name = " projects_ ${datetime} .csv " # 引数が想定した値であることをチェック if [ " ${root_parent_type} " != " organization " -a " ${root_parent_type} " != " folder " ]; then echo " ERROR : resource_type must be (folder/organization). " echo " usage : $0 (resouce_id) (resource_type) " exit 1 fi # フォルダを再帰的に取得する関数 function get_folders() { local parent_id = $1 local resource_type = $2 local depth = $3 local next_depth = $(( ${depth} + 1 )) echo " Processing... parent_id: ${parent_id} , resource_type: ${resource_type} , depth: ${depth} " > `tty` if [ ${resource_type} == " organization " ]; then folders_result = `gcloud resource-manager folders list --format = json --organization = ${parent_id} ` elif [ ${resource_type} == " folder " ]; then folders_result = `gcloud resource-manager folders list --format = json --folder = ${parent_id} ` fi # system-gsuite フォルダを除外 folders =` echo ${folders_result} | jq -r ' .[] | select(.displayName != "system-gsuite") | .name ' | cut -d / -f 2 ` if [ -n " ${folders} " ]; then echo " ${folders} " fi for folder in ${folders} ; do get_folders ${folder} folder ${next_depth} done return 0 } echo " Processing... root_parent_id: ${root_parent_id} , root_parent_type: ${root_parent_type} " # プロジェクト一覧取得 projects = `gcloud projects list --format = json` if [ $? -ne 0 ]; then echo " ERROR : gcloud projects list command finished with error. " exit 1 fi folder_ids = `get_folders ${root_parent_id} ${root_parent_type} 1 ` LF = $' \n ' root_and_folder_ids = " ${root_parent_id}${LF}${folder_ids} " # 特定組織（フォルダ）の配下のみ抽出 for parent in ${root_and_folder_ids} ; do target_projects += ( ` echo ${projects} | jq -r " .[] | select(.parent.id == \" ${parent} \" ) | .projectId " ` ) done # ソートしてファイルに書き込み printf " %s \n " " ${target_projects[ @ ]} " | sort | tee -a ${file_name} # スクリプト終了 echo " -------------------------------- " echo " ${file_name} was generated. " ls -la " ${file_name} " exit 0 出力例 以下のようなテキストファイルが出力されます。 my-project-01 my-project-02 my-project-03 実行方法 入力情報の準備 まず、プロジェクトを一覧化したい組織やプロジェクトのリソース ID を確認します。リソース ID は、10桁〜13桁程度の数字です。 適切な権限を持っていれば、Google Cloud コンソールの「リソースの管理（Manage Resources）」画面から確認できます。 組織のリソース ID（組織 ID）を調べる方法については、以下でも詳細に説明されています。 blog.g-gen.co.jp スクリプトの実行 その後、以下のようにスクリプトを実行します。 第1引数の 123456789012 は、組織やフォルダのリソース ID に置き換えてください。第2引数は、組織の場合は organization を、フォルダの場合は folder を指定してください。 ./list_projects.sh 123456789012 organization ソースコードの説明 ネストされたフォルダ ID の取得 ソースコードの48行目では、 gcloud projects list --format=json を実行し、Google アカウントが表示権限を持つすべてのプロジェクトの情報を JSON 形式で一括取得しています。 しかしこの JSON には、表示権限を持つすべてのプロジェクトの情報が格納されます。JSON は、以下のようなフォーマットです。 [ { " createTime ": " 2024-08-22T03:15:08.530Z ", " lifecycleState ": " ACTIVE ", " name ": " my-project-01 ", " parent ": { " id ": " 3456789xxx ", " type ": " organization " } , " projectId ": " my-project-01 ", " projectNumber ": " 123456789xxx " } , { " createTime ": " 2024-08-28T11:22:45.210Z ", " lifecycleState ": " ACTIVE ", " name ": " my-project-02 ", " parent ": { " id ": " 234567890xxx ", " type ": " folder " } , " projectId ": " my-project-02 ", " projectNumber ": " 987654321xxx " } , ... ] JSON 内の parent.id というキーには、そのプロジェクトの親リソース（組織やフォルダ）のリソース ID が格納されています。 組織の直下にあるプロジェクトは、 parent.id が組織のリソース ID になります。またフォルダの中にあるプロジェクトは、 parent.id がフォルダのリソース ID になります。そのため、組織の配下にあるすべてのプロジェクトを抽出するには、組織 ID と、すべてのフォルダのリソース ID でフィルタする必要があります。 当スクリプトでは、get_folders() 関数（17行目から定義）で、フォルダ内にネストしているフォルダを含めて、すべてのフォルダの ID を再帰的に取得しています。そして、取得したフォルダ ID を使ってすべてのプロジェクトを抽出します。これにより、組織配下のすべてのプロジェクトをリストアップします。 当スクリプトを実行すると以下のように処理経過が画面に出力されます。これは、ネストされたフォルダ内のフォルダのリソース ID を取得している様子を表しています。 Processing... root_parent_id: 3456789xxx, root_parent_type: organization Processing... parent_id: 3456789xxx, resource_type: organization, depth: 1 Processing... parent_id: 234567890xxx, resource_type: folder, depth: 2 Processing... parent_id: 567890123xxx, resource_type: folder, depth: 3 ... depth は、スクリプト実行時に引数で与えた最初の組織またはフォルダを1として、ネストの深さを示しています。 システムに生成されたプロジェクトの除外 組織配下には、システムによって自動生成されたプロジェクトが存在する場合があります。 system-gsuite フォルダ配下の apps-script フォルダ内には、 sys- で始まる ID のプロジェクトが格納されています。これは、Google Apps Script によって作成されたプロジェクトです。 また system-gsuite フォルダ配下の appsheet フォルダ内には、 app- で始まる ID のプロジェクトが格納されています。これは、App Sheet によって作成されたプロジェクトです。 これらのプロジェクトを除外するため、get_folders() 関数内のソースコード32行目で、 system-gsuite という表示名のフォルダは除外しています。 注意点 実行する Google アカウントで表示できるプロジェクトの数が多すぎる場合は、 gcloud projects list コマンドが失敗する場合があります。 その場合、 --page-size オプションを指定してレスポンスを制限する必要がありますが、当スクリプトはそのような場合には対応していません。 --page-size オプションを指定しなかった場合、デフォルト値は unlimited であり、すべての結果が返されます。 参考 : gcloud プロジェクト リストのレイテンシの短縮 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

本記事では gcloud コマンドの --filter フラグと --format フラグを使った出力の制御について、具体例を交えて紹介します。 gcloud CLI コマンドの概要 出力結果を自在に操る デフォルトの出力 format フラグで出力形式を指定 filter フラグで特定の値を持つリソースを抽出 gcloud コマンドに関する他の記事 gcloud CLI コマンドの概要 Google Cloud CLI（gcloud CLI）は、リソースの作成と管理を行うためのツールです。このツールを利用することで、例えば以下のようなことが出来ます。 Compute Engine インスタンスの作成 Cloud SQL インスタンスのパラメータの確認 Google Kubernetes Engine クラスタの削除 参考 : gcloud CLI の概要 出力結果を自在に操る デフォルトの出力 まずは、何もフラグを指定せずに、リソース一覧を出力してみます。ここに様々な設定の Compute Engine インスタンスを3台用意しました。 次のコマンドを実行すると、内容を文字で確認することが出来ます。 $ gcloud compute instances list NAME: test1 ZONE: asia-northeast1-a MACHINE_TYPE: e2-small PREEMPTIBLE: INTERNAL_IP: 192 . 168 . 1 . 15 EXTERNAL_IP: 34 . 84 . 108 . 247 STATUS: RUNNING NAME: test2 ZONE: asia-northeast1-b MACHINE_TYPE: e2-medium PREEMPTIBLE: INTERNAL_IP: 192 . 168 . 1 . 16 EXTERNAL_IP: 35 . 187 . 200 . 2 STATUS: RUNNING NAME: test3 ZONE: asia-northeast1-c MACHINE_TYPE: e2-standard-2 PREEMPTIBLE: INTERNAL_IP: 192 . 168 . 1 . 17 EXTERNAL_IP: STATUS: TERMINATED シンプルなコマンドで、主な内容を確認することが出来ました。しかし、この出力だと次のようなケースには対応するのに一手間必要になります。 対象の VM が100台あり、インスタンス名だけをすべて取得したい インスタンス名とマシンタイプを Excel にまとめたい ステータスが RUNNING の VM のみ値を取得したい ここで用いるのが、gcloud コマンドの --filter フラグと --format フラグです。 format フラグで出力形式を指定 コマンドの後ろに --format フラグを付けることで、出力のフォーマットを変更することが出来ます。 例えば内容を JSON で出力したい場合、 --format=json を指定することで、次のようになります。 $ gcloud compute instances list -- format = json [ { " canIpForward ": false , " confidentialInstanceConfig ": { " enableConfidentialCompute ": false } , " cpuPlatform ": " Intel Broadwell ", " creationTimestamp ": " 2024-07-08T18:08:09.626-07:00 ", " deletionProtection ": false , " description ": "", " disks ": [ { " architecture ": " X86_64 ", " autoDelete ": true , " boot ": true , " deviceName ": " test1 ", " diskSizeGb ": " 10 ", " guestOsFeatures ": [ { " type ": " UEFI_COMPATIBLE " } , { " type ": " VIRTIO_SCSI_MULTIQUEUE " } , { " type ": " GVNIC " } , { " type ": " SEV_CAPABLE " } , { " type ": " SEV_LIVE_MIGRATABLE_V2 " } ] , " index ": 0 , （以下省略） また、 --format=table を使うと、特定の属性だけを抽出できます。例えば先程の例に上げた「インスタンス名だけを取得したい」場合、次のように指定出来ます。 $ gcloud compute instances list --format =" table(name) " NAME: test1 NAME: test2 NAME: test3 また、「インスタンス名とマシンタイプを取得したい」のように、複数の属性を取得することもできます。 $ gcloud compute instances list --format =" table(name,MACHINE_TYPE) " NAME: test1 MACHINE_TYPE: e2-small NAME: test2 MACHINE_TYPE: e2-medium NAME: test3 MACHINE_TYPE: e2-standard-2 また、csv 形式で出力することも可能です。結果をスプレッドシートや Excel に貼り付けたいときに有用です。 $ gcloud compute instances list --format =" csv(name,MACHINE_TYPE) " name,machine_type test1,e2-small test2,e2-medium test3,e2-standard-2 このように format フラグを利用すると、JSON 形式、テーブル形式、csv 形式など、出力フォーマットを変更できます。 そのほか、詳細な仕様は公式ドキュメントをご参照ください。 参考 : gcloud topic formats filter フラグで特定の値を持つリソースを抽出 コマンドの後ろに --filter フラグをつけることで、特定のパラメータを持つリソースだけを出力させることができます。 例えば、「RUNNING 状態の VM インスタンスの名前とインスタンスタイプを csv 出力したい」というケースの場合、次のように指定します。 $ gcloud compute instances list --format =" csv(name,MACHINE_TYPE) " --filter =" STATUS=RUNNING " name,machine_type test1,e2-small test2,e2-medium このように、出力結果の絞り込みに利用できるのが --filter フラグです。 詳細な仕様は公式ドキュメントをご参照ください。 参考 : gcloud topic filters なお、 --format フラグも --filter フラグも、ネストされた属性を指定することが可能です。 例えば「インスタンス名と、インスタンスに紐づいたサービスアカウント名を出力したい」というケースの場合、以下のように指定できます。 $ gcloud compute instances list --format =" table(name,serviceAccounts[].email) " NAME: test1 EMAIL: [' 53xxxx11-compute@developer.gserviceaccount.com '] gcloud コマンドに関する他の記事 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 三木宏昭 (記事一覧) クラウドソリューション部 HROne→ServerWorks→WealthNavi→G-gen。AWS 11資格、Google Cloud認定全冠。Google Cloud Partner Top Engineer 2024。Google Authorized Trainer Follow @cloudeep_miki

G-genの杉村です。Google Cloud（旧称 GCP）のフルマネージドなデータウェアハウスサービスである BigQuery の、ストレージ料金体系について解説します。 BigQuery の課金体系 2つの課金モデル 論理ストレージ（Logical Storage）課金 物理ストレージ（Physical storage）課金 アクティブと長期 ユースケース どちらのモデルを選択すべきか 圧縮率の例 圧縮率の確認（データセットごと、コンソール） 圧縮率の確認（組織レベル、システムビュー） 圧縮率の確認（プロジェクトレベル、システムビュー） タイムトラベル・フェイルセーフへの課金 制約 物理ストレージ課金モデルの利用可否 ストレージ課金モデルの変更のインターバル期間 BigQuery の課金体系 前提知識として、BigQuery の利用料金は以下の2つの合計であることを理解する必要があります。 ストレージ料金（格納したデータサイズに応じた課金） コンピュート料金（コンピュート処理リソースに対する課金） 当記事では、このうち 1. のストレージ料金について解説します。 参考 : ストレージの課金モデル BigQuery のコンピュート料金体系の1つである BigQuery Editions については、以下の記事を参照してください。 blog.g-gen.co.jp 2つの課金モデル 論理ストレージ（Logical Storage）課金 論理ストレージ 課金モデルは、テーブルに格納されたデータの、圧縮前の額面データサイズに対して課金するモデルです。 デフォルトでは、BigQuery データセットのストレージ課金モデルは 論理ストレージ （Logical Storage）に設定されています。 BigQuery では、データは透過的に圧縮されて格納されています。例えば100 MB のデータを格納したとしても、実際にはデータは圧縮されており、実際に Google のストレージを占有しているデータサイズはもっと小さいものになります。論理ストレージ課金では、実際に占有されているデータサイズ ではなく 、額面データサイズ（先の例では 100 MB）に対して課金するモデルです。 物理ストレージ（Physical storage）課金 一方の 物理ストレージ （Physical Storage）課金モデルは、 圧縮後のデータサイズに対して 計算が行われる課金モデルです。なお物理ストレージ課金モデルは、2023年7月に一般公開された新しいモデルです。 当然、データサイズは論理ストレージ課金モデルより小さく計算されますが、課金単価は論理ストレージよりも高いものが使われます。後述しますが、多くの場合でこちらの課金モデルのほうが、結果的に安価になる傾向があります。 重要な点として、物理ストレージ課金モデルを選択したか否かに関わらず、BigQuery のデータは透過的に圧縮されています。論理ストレージ課金か物理ストレージ課金かの選択は、あくまで課金の計算方法の選択肢であり、この選択により圧縮の有無が変わったり、パフォーマンスが変わるものではありません。 BigQuery の圧縮の内部的な仕組みについては、以下もご参照ください。 参考 : Experimenting with BigQuery data compression アクティブと長期 論理、物理のいずれの課金モデルを選択した場合でも、BigQuery のストレージには、アクティブストレージと長期ストレージがあります。 アクティブストレージ （Active storage）は、過去90日間以内にテーブルに挿入されたり、更新があったデータが格納される領域です。 長期ストレージ （Long-term storage）は、過去90日間の間、変更がないデータが格納される領域です。データの挿入または格納後、90日間放置すると、データは自動的に長期ストレージに移行します。 長期ストレージの課金単価は、アクティブストレージの半分です。BigQuery テーブルにデータを一度挿入したあとは、触れずに放置しておくことで、自動的に安価になります。 参考 : Storage pricing ユースケース どちらのモデルを選択すべきか BigQuery では、データセットごとに論理ストレージ課金モデルを適用するか物理ストレージ課金モデルを適用するかを選択できます。デフォルトでは、論理ストレージ課金モデルが適用されています。 以下は、2026年2月現在の東京リージョン（asia-northeast1）の料金単価です。 課金モデル 単価 論理ストレージ（アクティブ） $0.023 / GiB / 月 論理ストレージ（長期） $0.016 / GiB / 月 物理ストレージ（アクティブ） $0.052 / GiB / 月 物理ストレージ（長期） $0.026 / GiB / 月 物理ストレージ課金モデルは、論理ストレージ課金モデルの単価よりも、約2.26倍高いことがわかります。つまり、データが約44.3%以下まで圧縮されていれば、物理ストレージ課金を選択したほうが安価になります。 ストレージ単価は、データセットのリージョンによって異なります。リージョンごとの最新の料金は、以下のドキュメントを参照してください。 参考 : Storage pricing 圧縮率の例 あくまで一般的な傾向ですが、BigQuery では圧縮によりデータは4分の1〜12分の1程度、あるいはそれ以上の圧縮率になる可能性があります。 データ圧縮率の例をいくつか紹介します。 以下は、G-gen Tech Blog で収集している Google Analytics 4 のデータを BigQuery にエクスポートしたテーブルの情報です。ある日のテーブルは、論理バイト数は 11.69 MB ですが、物理バイト数は 638.69 KB であり、約 18 分の 1 になっています。 もう一つの例です。以下はパブリックデータセットの bigquery-public-data.baseball.games_wide テーブルの情報です。この例では 1.76 GB が 32.22 MB まで圧縮されており、約 56 分の 1 になっています。 上記の例ではいずれも、物理ストレージ課金モデルを選択したほうが、安価になることがわかります。 データの圧縮率はデータの性質によって異なるため一概には言えませんが、多くのケースで物理ストレージ課金モデルを選択することで安価になると考えられます。 圧縮率の確認（データセットごと、コンソール） データの実際の圧縮状況は、テーブルの詳細情報から確認できます。BigQuery の Web コンソールから、テーブルの詳細画面を開くと、論理バイト数と物理バイト数が確認できます。 以下の例だと、1.6%ほどにまでデータが圧縮されていますので、物理ストレージ課金を選択したほうが、安価になることがわかります。 圧縮率の確認（組織レベル、システムビュー） BigQuery のシステムビューである INFORMATION_SCHEMA にクエリすることで、Google Cloud 組織全体、あるいは特定のプロジェクトの情報を取得することが可能です。 以下のサンプルクエリでは INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION から情報を取得し、組織全体で、プロジェクトごとに圧縮状況を確認しています。 参考 : TABLE_STORAGE_BY_ORGANIZATION view このクエリにより、Google Cloud 組織全体で、プロジェクトごとの論理ストレージ（アクティブ）、論理ストレージ（長期）、物理ストレージ（アクティブ）、物理ストレージ（長期）それぞれのバイト数、また費用見積もりを確認することができます。クエリの内容は、環境にあわせて書き換えてください。 組織全体の情報を取得するサンプルクエリ DECLARE active_logical_pricing, longterm_logical_pricing, active_physical_pricing, longterm_physical_pricing NUMERIC ; SET active_logical_pricing = 0 . 023 ; SET longterm_logical_pricing = 0 . 016 ; SET active_physical_pricing = 0 . 052 ; SET longterm_physical_pricing = 0 . 026 ; -- 上記は2026-02時点の東京リージョン価格。適宜変更してください SELECT project_id, ROUND ( SUM (total_logical_bytes/POW( 1024 , 3 )), 2 ) AS total_logical_gigabytes, ROUND ( SUM ( ( active_logical_bytes/POW( 1024 , 3 ) ) * active_logical_pricing + ( long_term_logical_bytes/POW( 1024 , 3 ) ) * longterm_logical_pricing ), 2 ) AS total_logical_price, ROUND ( SUM (total_physical_bytes/POW( 1024 , 3 )), 2 ) AS total_physical_gigabytes, ROUND ( SUM (fail_safe_physical_bytes/POW( 1024 , 3 )), 2 ) AS fail_safe_physical_gigabytes, ROUND ( SUM ( ( (active_physical_bytes/POW( 1024 , 3 )) + (fail_safe_physical_bytes/POW( 1024 , 3 )) ) * active_physical_pricing + ( long_term_physical_bytes/POW( 1024 , 3 ) ) * longterm_physical_pricing ), 2 ) AS total_physical_price, ROUND (SAFE_DIVIDE( SUM (total_logical_bytes), SUM (total_physical_bytes)), 2 ) AS compression_ratio FROM `region-asia-northeast1.INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION` -- 上記はデータセットのリージョンに合わせて適宜変更してください GROUP BY 1 注意点として INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION をクエリするには、実行アカウントは 組織レベル で特定の権限を持っている必要があります。この権限を得るには、クエリするアカウントに対して組織レベルで BigQuery メタデータ閲覧者 （ roles/bigquery.metadataViewer ）ロールなどを付与します。組織レベルで例えば オーナー （ roles/owner ）ロールを持っているとしても、オーナーには bigquery.tables.get が含まれていないため権限不足となりますので、ご注意ください。 BigQuery の IAM 権限の詳細についてさらに知りたい場合は、以下をご参照ください。 blog.g-gen.co.jp 圧縮率の確認（プロジェクトレベル、システムビュー） あるプロジェクトの中で、データセットごとに圧縮率を確認したい場合、システムビュー ${プロジェクト ID}.region-${リージョン名}.INFORMATION_SCHEMA.TABLE_STORAGE から情報を取得します。このクエリの実行には、プロジェクトレベルで BigQuery メタデータ閲覧者 （ roles/bigquery.metadataViewer ）ロールなどが必要です。 参考 : TABLE_STORAGE view プロジェクトの情報を取得するサンプルクエリ DECLARE active_logical_pricing, longterm_logical_pricing, active_physical_pricing, longterm_physical_pricing NUMERIC ; SET active_logical_pricing = 0 . 023 ; SET longterm_logical_pricing = 0 . 016 ; SET active_physical_pricing = 0 . 052 ; SET longterm_physical_pricing = 0 . 026 ; -- 上記は2026-02現在の東京リージョン価格。適宜変更してください SELECT project_id, table_schema, ROUND ( SUM (total_logical_bytes/POW( 1024 , 3 )), 2 ) AS total_logical_gigabytes, ROUND ( SUM ( ( active_logical_bytes/POW( 1024 , 3 ) ) * active_logical_pricing + ( long_term_logical_bytes/POW( 1024 , 3 ) ) * longterm_logical_pricing ), 2 ) AS total_logical_price, ROUND ( SUM (total_physical_bytes/POW( 1024 , 3 )), 2 ) AS total_physical_gigabytes, ROUND ( SUM (fail_safe_physical_bytes/POW( 1024 , 3 )), 2 ) AS fail_safe_physical_gigabytes, ROUND ( SUM ( ( (active_physical_bytes/POW( 1024 , 3 )) + (fail_safe_physical_bytes/POW( 1024 , 3 )) ) * active_physical_pricing + ( long_term_physical_bytes/POW( 1024 , 3 ) ) * longterm_physical_pricing ), 2 ) AS total_physical_price, ROUND (SAFE_DIVIDE( SUM (total_logical_bytes), SUM (total_physical_bytes)), 2 ) AS compression_ratio FROM `my-project.region-asia-northeast1.INFORMATION_SCHEMA.TABLE_STORAGE_BY_PROJECT` -- 上記のプロジェクト ID、リージョンは、環境に合わせて適宜変更してください GROUP BY 1 , 2 上記のクエリにより、特定プロジェクト内のデータセットごとに圧縮率が取得されます。東京リージョンの場合、 compression_ratio 列が2.26以上になれば、物理ストレージを選択した方が安価になります。 タイムトラベル・フェイルセーフへの課金 BigQuery には タイムトラベル機能 と フェイルセーフ機能 があり、データを削除したり変更したりしても、デフォルトで過去14日間（タイムトラベルで7日間、フェイルセーフでさらに7日間）のデータが保持されます。 参考 : タイムトラベルとフェイルセーフによるデータの保持 物理ストレージ課金モデルを選択すると、このタイムトラベルとフェイルセーフのデータサイズにも課金が発生します。その一方で、論理ストレージ課金モデルでは課金されません。課金は、アクティブストレージの単価で行われます。 ストレージ料金を節約するために、タイムトラベルの保存期間をデフォルトの7日間から変更することも可能です。フェイルセーフの保存期間（タイムトラベル期間の後、追加で7日間）は変更できません。 この仕様から、データの削除や更新が頻繁なテーブルでは、物理ストレージ課金にすると料金が高くなるおそれがあります。デフォルト設定では、例えば定期的にデータを洗い替え（一度 TRUNCATE してから INSERT）しているようなテーブルだと、タイムトラベル領域とフェイルセーフ領域に削除されたデータが14日間、積み上がり続け、課金対象とされることになります。 また、BigQuery Data Transfer Serviceのデータセットコピー機能で Overwrite destination table オプションを使う場合も、この仕様に注意が必要です。以下の記事も参照してください。 参考 : BigQuery Data Transfer Serviceのデータセットコピーを解説 - 注意点 制約 物理ストレージ課金モデルの利用可否 物理ストレージ課金モデルの制約として、 同じ Google Cloud 組織 内のいずれかのプロジェクト、 同じリージョン で Flat-rate 課金が使用されている場合は、物理ストレージ課金モデルが利用できません。 Flat-rate（定額）課金は2023年7月に販売が終了した、BigQuery の古いコンピュート課金モデルです。現在では BigQuery Editions に置き換わっています。BigQuery Editions を利用中の場合は、問題ありません。 ストレージ課金モデルの変更のインターバル期間 BigQuery コンソールのデータセット詳細画面から鉛筆マークの「詳細を編集」リンクをクリックし、チェックボックス「物理ストレージの課金モデルを有効にする」をオンにして保存することで、課金体系が物理ストレージの課金モデルに変更されます。 このとき、変更が適用されるまでに24時間が必要です。 また、一度データセットの課金モデルを変更すると、再度モデルを変更するには14日間、待つ必要があります。 参考 : Update storage billing models 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の三木です。Google Cloud（旧称 GCP）の Cloud Monitoring のアラートポリシー機能で、通知文に VM 名称等を含める方法をご紹介します。 前提知識 Cloud Monitoring とは ログベースのアラートとラベル機能 改善前 設定値 課題 改善後 設定 テスト 改善後のアラート内容 前提知識 Cloud Monitoring とは Cloud Monitoring は、 Google Cloud における監視機能を提供するサービスです。以下の機能を提供します。 メトリクスの収集 可視化 アラート管理 インシデント管理 詳細は以下の記事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp ログベースのアラートとラベル機能 ログベースのアラート 機能では、Cloud Logging で収集したログに特定の文字列が現れた際に、E メールや Slack に通知することができます。 また、ログベースのアラートを定義する際に ラベル を指定することができます。ラベルとはログエントリの一部を抽出したテキスト値です。 ラベルを上手く活用することで、E メールや Slack へのアラート通知の本文に、様々な情報を出力することが出来ます。 参考 : ログベースのアラート ポリシーの構成 参考 : ログベースの指標にラベルを構成する 改善前 設定値 VM から出力されるログの重要度が ERROR の場合に通知を飛ばすために、以下のように設定しました。 ログベースの通知の設定方法について、詳細は以下のページをご参照ください。 参考 : ログベースのアラート ポリシーの構成 また、Slack への通知方法は以下のページをご参照ください。 参考 : Slack 通知を構成す 課題 ある Google Cloud 環境で、Compute Engine の VM インスタンスでエラーが発生した際に E メールと Slack へ通知されるよう、上記のようにアラートを設定しました。 動作確認したところ、通知の件名や内容には VM 名が記載されていないため、どの VM でエラーが起きているのかが分かりません。対象の VM を知るには Google Cloud コンソールにログインして詳細を確認する必要がありました。これは、運用上の課題となりました。 メールへの通知例 Slackへの通知例 改善後 設定 通知本文に VM の名称を表示させるために、ラベル機能を活用します。 次のように設定することで、VM 名をラベルとして定義できます。 Key Value Display name vm_name Log field name labels.isntance_name Log field name では、Cloud Logging に出力されるログエントリのキーを指定します。VM 名だけでなく、ログに出力される内容であれば、この方法で抽出することができます。 次に、定義したラベルを通知の本文にも表示させます。Documentation 設定を次のように書き換えます。 以下に示した ${log.extracted_label.vm_name} は、前述のラベルを指しています。 VM でエラーが発生しました。 対象のVM名は ${log.extracted_label.vm_name} です。 テスト 次に、通知内容の変化をテストします。 テストの際は logEntries.write リファレンス ページを活用するのが便利です。Google Cloud の API リファレンスでは、API に対してテストリクエストを送信することができます。 参考 : Method: entries.write このページの右側ペインの RequestBody に入力した内容が、Cloud Logging ログエントリとして記録されます。 今回は以下のリクエスト内容で、テストを行いました。 { " entries ": [ { " logName ": " projects/my-projecct/logs/GCEGuestAgent ", " jsonPayload ": { " message ": " Error happened " } , " severity ": " ERROR ", " labels ": { " instance_name ": " test01 " } , " resource ": { " type ": " gce_instance ", " labels ": { " project_id ": " my-projecct ", " location ": " asia-northeast1 ", " instance_id ": " 1234567890123456789 ", " zone ": " asia-northeast1-b " } } } ] } リクエストを記述したら Execute ボタンを押下することで、Cloud Logging にログエントリが記録され、アラートが発報します。 改善後のアラート内容 通知内容に、VM 名が表示されることが確認できました。 改善後のメール通知 改善後のSlack通知の内容 三木宏昭 (記事一覧) クラウドソリューション部 HROne→ServerWorks→WealthNavi→G-gen。AWS 11資格、Google Cloud認定全冠。Google Cloud Partner Top Engineer 2024。Google Authorized Trainer Follow @cloudeep_miki

G-gen の山崎です。 当記事では、Cloud Storage に格納されたテキストファイルに対して、Cloud Run functions にてVertex AI Gemini API を呼び出し、取得したテキストの要約結果を BigQuery に保存する処理を構築したので解説します。 システム構成 前提知識 環境構築 API の有効化 Cloud Storage の構築 バケットの作成 Cloud Storage サービスエージェントに権限付与 BigQuery の構築 Cloud Run functions の構築 Python のバージョン requirements.txt の作成 main.py の作成 サービスアカウントの作成（Cloud Run functions 起動用） サービスアカウントの作成（Cloud Run functions 実行用） Cloud Run functions のデプロイ 動作検証 検証に使用したダミー日報 検証の実施 システム構成 当記事では、Cloud Storage に格納されたテキストファイルに対して、イベントドリブンな処理を行う構成を検証したときの経緯をご紹介します。 今回構築したシステム構成は、以下のとおりです。 構成図 Cloud Storage の日報格納用バケットにテキストファイルがアップロードされると、それをトリガーにして Cloud Run functions が起動します。 起動した Cloud Run functions は、アップロードされたテキストファイルを Gemini で要約し、結果を BigQuery に保存します。 上記のように、ある1つの処理が完了したことをきっかけに、別の処理がトリガーされるようなアーキテクチャを イベントドリブン といいます。スケジュール起動のバッチ処理等に比べて、タイムラグなく処理を行うことが可能です。 前提知識 今回使用する Google Cloud サービスの詳細は、以下の記事をご参照ください。 Cloud Storage blog.g-gen.co.jp Cloud Run functions blog.g-gen.co.jp BigQuery blog.g-gen.co.jp 環境構築 以下の順序で環境を構築しました。 API の有効化 Cloud Storage の構築 BigQuery の構築 Cloud Run functions の構築 API の有効化 Google Cloud プロジェクトで、今回の構成に必要な Google Cloud サービスの API を有効化します。 gcloud services enable \ artifactregistry.googleapis.com \ cloudfunctions.googleapis.com \ run.googleapis.com \ logging.googleapis.com \ aiplatform.googleapis.com \ cloudbuild.googleapis.com \ storage.googleapis.com \ pubsub.googleapis.com \ eventarc.googleapis.com \ Cloud Storage の構築 バケットの作成 日報を格納するバケットを作成します。 以下のコマンドラインを用いました。実行する際には、変数 BUCKET_NAME 、 PROJECT_ID の値をご自身の環境に合わせて置き換えてください。 BUCKET_NAME = " BUCKET_NAME " PROJECT_ID = " PROJECT_ID " gcloud storage buckets create gs:// ${BUCKET_NAME} \ --project = ${PROJECT_ID} \ --location = asia-northeast1 Cloud Storage サービスエージェントに権限付与 Cloud Storage のサービスエージェントに対し、 Pub/Sub へパブリッシュするための IAM 権限を付与します。 PROJECT_ID の値をご自身の環境に合わせて置き換えてください。 PROJECT_ID = " PROJECT_ID " SERVICE_ACCOUNT = " $( gcloud storage service-agent --project = ${PROJECT_ID}) " gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_ACCOUNT} " \ --role =' roles/pubsub.publisher ' この作業の意味については、以下の記事の Cloud Storage サービスエージェントに権限付与 の項をご参照ください。 blog.g-gen.co.jp BigQuery の構築 日報の要約結果を保存するための BigQuery データセットとテーブルを作成します。作成するテーブルのスキーマ構成は以下のとおりです。 列名 データ型 説明 report_date DATE 日付 name STRING 名前 original_text STRING 日報の原文 summary STRING 日報の要約 以下のコマンドラインを用いました。実行する際は、 PROJECT_ID の値をご自身の環境に合わせて置き換えてください。 PROJECT_ID = " PROJECT_ID " # データセットの作成 bq --location = asia-northeast1 mk \ --dataset test # テーブルの作成 bq mk \ --table \ test .report \ report_date:DATE,name:STRING,original_text:STRING,summary:STRING Cloud Run functions の構築 Python のバージョン この記事では、Python 3.12.0 を使用しました。 $ python --version Python 3 . 12 . 0 requirements.txt の作成 以下のライブラリを requirements.txt に定義します。 requirements.txt は、Python のソースコードから利用するライブラリの依存関係を定義したテキストファイルです。 functions-framework== 3.5 . 0 google-cloud-aiplatform== 1.60 . 0 google-cloud-bigquery== 3.19 . 0 google-cloud-logging== 3.9 . 0 google-cloud-storage== 2.5 . 0 pandas-gbq== 0.20 . 0 pandas== 2.1 . 4 main.py の作成 ソースコードは以下のとおりです。15行目から25行目で参照している環境変数は、Cloud Run functions のデプロイ時に値を設定します。 import functions_framework import google.cloud.logging import logging import os import pandas as pd import pandas_gbq import vertexai from datetime import datetime, timezone, timedelta from google.cloud import bigquery from google.cloud import storage from vertexai.preview.generative_models import GenerativeModel # 環境変数を一箇所にまとめる ENV = { 'PROJECT_ID' : os.environ.get( 'PROJECT_ID' ), 'LOCATION' : os.environ.get( 'LOCATION' ), 'TEMPERATURE' : float (os.environ.get( 'TEMPERATURE' )), 'MAX_OUTPUT_TOKENS' : int (os.environ.get( 'MAX_OUTPUT_TOKENS' )), 'TOP_P' : float (os.environ.get( 'TOP_P' )), 'TOP_K' : int (os.environ.get( 'TOP_K' )), 'LOG_LEVEL' : int (os.environ.get( 'LOG_LEVEL' )), 'MODEL' : os.environ.get( 'MODEL' ), 'TABLE_ID' : os.environ.get( 'TABLE_ID' ), } # ロギング設定 logging.basicConfig(level=ENV[ 'LOG_LEVEL' ]) logger = logging.getLogger() # Vertex AI の初期化 vertexai.init(project=ENV[ 'PROJECT_ID' ], location=ENV[ 'LOCATION' ]) model = GenerativeModel(ENV[ 'MODEL' ]) # BigQuery のクライアントを作成 bigquery_client = bigquery.Client() def download_from_gcs (bucket_name, object_name): """GCS からファイルをダウンロードする""" storage_client = storage.Client() bucket = storage_client.bucket(bucket_name) blob = bucket.blob(object_name) return blob.download_as_string().decode( 'utf-8' ) def generate_summary (text): """Vertex AI を使用してテキストを要約する""" prompt = f "以下の文章を要約してください: \n {text} \n Summary: \n " responses = model.generate_content( prompt, generation_config={ "temperature" : ENV[ 'TEMPERATURE' ], "max_output_tokens" : ENV[ 'MAX_OUTPUT_TOKENS' ], "top_p" : ENV[ 'TOP_P' ], "top_k" : ENV[ 'TOP_K' ], } ) return responses.text def save_to_bigquery (report_date, name, original_text, summary): """BigQuery にデータを保存する""" records = [ { "report_date" : report_date, "name" : name, "original_text" : original_text, "summary" : summary} ] df = pd.DataFrame(records) df[ 'report_date' ] = pd.to_datetime(df[ 'report_date' ], errors= 'coerce' ) pandas_gbq.to_gbq(df, ENV[ 'TABLE_ID' ], ENV[ 'PROJECT_ID' ], if_exists= 'append' ) return @ functions_framework.cloud_event def main (cloud_event): # イベントデータの取得 event_data = cloud_event.data bucket_name = event_data[ "bucket" ] object_name = event_data[ "name" ] # ファイル情報のパース file_name = os.path.splitext(object_name)[ 0 ] report_date, name = file_name.split( "_" , 1 ) # ファイル名から日付と名前を抽出 # GCS からデータを取得 data = download_from_gcs(bucket_name, object_name) # 要約の生成 summary = generate_summary(data) # BigQuery に結果を保存 save_to_bigquery(report_date, name, data, summary) logger.info( "処理終了！" ) return サービスアカウントの作成（Cloud Run functions 起動用） アップロードをトリガーに Cloud Run functions を起動するサービスアカウントを作成します。 実行する際は、 PROJECT_ID の値をご自身の環境に合わせて置き換えてください。 PROJECT_ID = " PROJECT_ID " SERVICE_ACCOUNT_NAME =fnc-trigger # サービスアカウントの作成 gcloud iam service-accounts create ${SERVICE_ACCOUNT_NAME} \ --description =" トリガー用サービスアカウント " \ --display-name = ${SERVICE_ACCOUNT_NAME} # サービスアカウントへ権限付与 gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_ACCOUNT_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/run.invoker " gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_ACCOUNT_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/eventarc.eventReceiver " サービスアカウントの作成（Cloud Run functions 実行用） Cloud Run functions を実行するサービスアカウントを作成します。 実行する際は、 PROJECT_ID の値をご自身の環境に合わせて置き換えてください。 PROJECT_ID = " PROJECT_ID " SERVICE_ACCOUNT_NAME =register-daily-report # サービスアカウントの作成 gcloud iam service-accounts create ${SERVICE_ACCOUNT_NAME} \ --description =" Cloud Run functions実行用サービスアカウント " \ --display-name = ${SERVICE_ACCOUNT_NAME} # サービスアカウントへ権限付与 gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_ACCOUNT_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/bigquery.jobUser " gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_ACCOUNT_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/bigquery.dataEditor " gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_ACCOUNT_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/storage.objectViewer " gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member =" serviceAccount: ${SERVICE_ACCOUNT_NAME} @ ${PROJECT_ID} .iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " Cloud Run functions のデプロイ Cloud Run functions をデプロイします。 実行する際は、 PROJECT_ID の値をご自身の環境に合わせて置き換えてください。またソースコードや requirements.txt が存在するディレクトリに移動してからコマンドを実行してください。 PROJECT_ID = " PROJECT_ID " BUCKET = " BUCKET_NAME " function =register-daily-report service_account =register-daily-report trigger_service_account =fnc-trigger gcloud functions deploy ${function} \ --gen2 \ --project = ${PROJECT_ID} \ --region = asia-northeast1 \ --runtime = python312 \ --memory = 512Mi \ --entry-point main \ --timeout = 540 \ --trigger-bucket = ${BUCKET} \ --service-account = ${service_account} @ ${PROJECT_ID} .iam.gserviceaccount.com \ --trigger-service-account = ${trigger_service_account} @ ${PROJECT_ID} .iam.gserviceaccount.com \ --set-env-vars LOG_EXECUTION_ID =true, PROJECT_ID = ${PROJECT_ID} , LOCATION =asia-northeast1, LOG_LEVEL = 20 , TEMPERATURE = 1 . 0 , MAX_OUTPUT_TOKENS = 800 , TOP_P = 0 . 95 , TOP_K = 40 , MODEL =gemini-1.5-flash-001, TABLE_ID = ${PROJECT_ID} . test .report 動作検証 検証に使用したダミー日報 ダミーの日報データとして、以下のテキストファイルを使用します。 日報 日付 2024年9月10日 名前 営業一郎 業務報告 お疲れ様です。本日の活動について報告いたします。 本日午前中は、Z社との初回ミーティングを行いました。 Z社は我々の製品群に大いに興味を示しており、特にエコ効率とコスト効率について熱心に問い合わせがありました。 Z社の要望に対し、製品の特性を強調し、彼らの課題解決に最適な提案を行いました。 ミーティングの結果、Z社はさらに具体的な提案を求めてきましたので、次回は製品デモンストレーションを実施する予定です。 また午前中には、製品開発部門との内部ミーティングを行い、顧客からのフィードバックを共有しました。 これにより、製品改良のための具体的な提案を開発部門に伝えることができ、 これらのフィードバックが新製品開発に役立つと確信しています。 午後には、既存の大口顧客であるY社へ訪問しました。 我々の製品が彼らの業務改善にどのように寄与しているか、また、どのような改善が求められているのかを詳細に確認しました。 Y社からのフィードバックは非常に貴重であり、これを元に顧客満足度の向上、そして新製品開発の方向性に活かしていきたいと考えています。 最後に、R社との商談を進めました。 R社は最初から我々の製品に大いに期待していましたが、今日の商談でその期待をさらに上回る提案ができたと感じています。 製品の特性と価値をしっかりと伝え、R社の問題解決に対する当社のコミットメントを強調しました。 これにより、R社からは高い評価を頂き、次回の商談の設定を成功させることができました。 本日も新規顧客開拓や既存顧客との信頼関係強化に努めました。 今後も引き続き、我々の製品とサービスが顧客のビジネスにとって最大の価値を提供することを目指してまいります。 以上、本日の報告となります。よろしくお願いいたします。 検証の実施 日報格納用バケットにテキストファイル（ダミー日報）をアップロードします。 日報格納用バケットにテキストファイルをアップロード アップロードされた日報の原文と要約後の文章が、BigQuery に保存されていることを確認します。 BigQueryに保存されたデータを確認 以下は、要約後の文章です。 ## 日報要約：営業一郎 2024年9月10日 - Z社との初回ミーティングで製品への高い関心と具体的な提案を求められる。次回製品デモンストレーションを実施予定。 - 製品開発部門とのミーティングで顧客フィードバックを共有し、新製品開発に繋げる。 - 大口顧客Y社への訪問で顧客満足度向上と新製品開発の方向性に関する貴重なフィードバックを得る。 - R社との商談で期待以上の提案を行い、高い評価と次回商談設定に成功。 - 新規顧客開拓と既存顧客との信頼関係強化に積極的に取り組み、顧客ビジネスへの貢献を目指す。 なお、ダミー日報を Cloud Storage バケットにアップロードしてから、BigQuery に要約文が保存されるまでは、30秒もかかりませんでした。イベントドリブンな構成を取ることで、タイムラグのない逐次処理を実現できることがわかります。 山崎 曜 (記事一覧) クラウドソリューション部 元は日系大手SIerにて金融の決済領域のお客様に対して、PM／APエンジニアとして、要件定義〜保守運用まで全工程に従事。 Google Cloud 全 11 資格保有。 フルスタックな人材を目指し、日々邁進。 Follow @Akira_Yamasakit

G-genの杉村です。Google Cloud（旧称 GCP）のサービスではありませんが、Google 関連サービスである Ads Data Hub の初期セットアップについて、簡単に紹介します。 はじめに Ads Data Hub とは 2 つのモード アカウント開設の前提条件 Google アカウント Google Cloud プロジェクト 事前に必要な情報 Ads Data Hub アカウントの開設 留意点 Ads Data Hub のリージョンと Google Cloud のリージョン IAM 権限を適切に付与してもエラー表示 VPC Service Controls の使い方 はじめに Ads Data Hub とは Ads Data Hub （通称、ADH）とは、Google 広告の キャンペーン （広告の管理単位。予算やターゲット地域を定義）など、Google の広告系サービスのデータと、自社データ（ファーストパーティデータ）を組み合わせて分析し、広告効果を最適化するためのプラットフォームです。 Ads Data Hub は、以下のようなサービスのデータをインプットとします。 Google 広告 ディスプレイ＆ビデオ 360 キャンペーン マネージャー 360 YouTube これらのサービスを Ads Data Hub とリンクさせることができます。 また Ads Data Hub をユーザーの Google Cloud（旧称 GCP）のプロジェクトと連携させることで、BigQuery のリソースを利用し、また分析結果を書き込むことができます。 以下の模式図のような形で、Google の広告系サービスのデータと、自社データを、組み合わせて分析することができるのが、Ads Data Hub です。 参考 : Ads Data Hub 参考 : はじめに この記事の情報は2024年6月現在の仕様をもとにしており、今後変更される場合があります。 2 つのモード Ads Data Hub には2つのモードがあります。広告主、代理店、パブリッシャー向けのモードでは BigQuery との接続などを管理することができ、こちらは Ads Data Hub for Marketers と呼ばれる一方で、ベンダーとパートナー向けのモードは単に Ads Data Hub 呼ばれ、ドキュメント上では区別されます。 参考 : Introducing two new solutions powered by Ads Data Hub アカウント開設の前提条件 Google アカウント Ads Data Hub を利用するには、Google サービス共通のユーザーアカウントである Google アカウント が必要です。Ads Data Hub の利用者は、Google アカウントを使って Ads Data Hub のコンソール画面にログインし、各種操作を行います。 Google の広告系サービスも同様に Google アカウントを使ってログイン・操作を行う仕組みになっているため、これらのサービスをすでに利用している場合は、すでに Google アカウントを持っていることになります。 Google アカウントは、以下のいずれかの方法で作成・管理できます。 種類 対象 料金 ユースケース 個人用 Google アカウント 個人 無償 ・個人で Google サービスを利用する ・個人で Google Cloud を利用する Google Workspace アカウント 組織 有償 ・組織で Google のグループウェアを利用する ・組織で Google Cloud を利用する Cloud Identity アカウント 組織 無償 (※) ・組織で Google Cloud を利用する ※ 51 アカウント以上は有償 個人用 Google アカウントは「Gmail アカウント」とも呼ばれます。無償で簡単に作成できる反面、組織での管理には向いていません。Ads Data Hub では Google Cloud を利用することもあり、 Google Workspace もしくは Cloud Identity でアカウントを管理することが推奨されます。 Google アカウントの詳細については、以下の記事を参照してください。 blog.g-gen.co.jp また、Cloud Identity（無償版）で組織（テナント）を開設する手順については、以下の記事を参照してください。 blog.g-gen.co.jp Google Cloud プロジェクト Ads Data Hub の利用には、 Google Cloud プロジェクトが必須です。 Google Cloud プロジェクトとは、BigQuery データセットなどの「Google Cloud リソース」を管理するための管理単位であり、Google Cloud の「テナント」と言い換えることもできます。 必須ではありませんが、セキュアに環境を管理したり、環境全体にガバナンスを効かせるには Google Cloud 組織が必要です。組織を作成するには、Google Workspace もしくは Cloud Identity のアカウントが必要になります。このことからも、前述の通り、Ads Data Hub を利用するには Gmail アカウントではなく Google Workspace もしくは Cloud Identity が推奨されます。 組織についての詳細は、以下をご参照ください。 blog.g-gen.co.jp 事前に必要な情報 Ads Data Hub のアカウント開設には、以下の情報が必要です。 情報名 説明 Ads Data Hub アカウント名 Ads Data Hub アカウント（テナント）を識別するための任意の名称 サーバーのロケーション データを保存する地域。「米国」「EU」「北東アジア」「オーストラリア南東部」から選択 アカウント種別 単一階層型（Advertisers）または2階層型（Agencies） BigQuery プロジェクト ID ユーザー管理の Google Cloud のプロジェクト ID BigQuery データセット名 BigQuery のデータセット名（デフォルトだと full_circle_shared ） Google 広告系サービスの各種 ID ・Google Ads CID(s) | Google Ads MCC ・Campaign Manager Network ID(s) | Floodlight ID(s) Display & Video 360 Advertiser ID(s) | Partner ID(s) ・YouTube Reserve Media Plan ID(s) 管理者（Superuser）となるユーザーアカウント Google アカウントのメールアドレス Ads Data Hub アカウントの開設 Ads Data Hub アカウントの開設は、Google の担当者と連携して行います。 Ads Data Hub アカウントの開設には Google による審査があり、承認された場合にアカウントが開設されます。 承認後、申請した Google アカウントで所定の URL にアクセスすると、Ads Data Hub アカウント開設のウィザードが始まります。 ここで前述の、Ads Data Hub ロケーションなどを選択します。一部の設定値は、一度選択すると後から変更できないため、注意して選択する必要があります。 参考 : アカウントの設定 留意点 Ads Data Hub のリージョンと Google Cloud のリージョン Ads Data Hub のアカウント解説時にロケーションを「米国」「EU」「北東アジア」「オーストラリア南東部」から選択しますが、このロケーションと、データを入出力する ユーザー管理の BigQuery データセットのロケーションを合わせる 必要があります。 Ads Data Hub はバックエンドで BigQuery を利用しています。この Ads Data Hub の BigQuery は Google によって管理されており、ユーザーからは見えません。Ads Data Hub ではこの Google 管理の BigQuery と、ユーザーが保有する BigQuery の間でデータの結合などを行いますが、BigQuery テーブル間の結合やデータ移動は基本的には 同一ロケーションである必要がある ため、この仕様があると考えられます。 IAM 権限を適切に付与してもエラー表示 ファーストパーティデータ（自社保有データ）を Ads Data Hub と連携させるため、自社が保有する BigQuery データセットを Ads Data Hub とリンクできます。 この接続設定を作成する際、以下のスクリーンショットのように、エラーが表示されることがあります。 設定が無効です: For BigQuery connections, ensure that the following service accounts have read permissions: ${PROJECT_NUM_01}-compute@developer.gserviceaccount.com, service-${PROJECT_NUM_02}@gcp-sa-datafusion.iam.gserviceaccount.com on the table "projects/${PROJECT_ID}/datasets/${DATASET_ID}/tables/${TABLE_ID}". To grant permissions in BigQuery, see these instructions. ※ ${ } で囲われた部分は、環境固有の値 プロジェクトレベルに IAM 権限を正しく付与すれば、 IAM の継承 の仕組みによって BigQuery テーブルにも権限が伝搬しますが、その場合にこのエラーメッセージが表示されるときがあります。実際には、エラーメッセージが表示されても次の画面に遷移することができ、正しくテーブルから情報が取得できます。 このエラー表示は2024年6月現在の仕様であり、変更される場合があります。 VPC Service Controls の使い方 オプションとして、Google Cloud の API 保護の仕組みである VPC Service Controls を使うことで、BigQuery 上のデータに IP アドレスやデバイス情報をもとにした強固な保護を適用することができます。 blog.g-gen.co.jp Ads Data Hub からユーザーの BigQuery にアクセスする際、Ads Data Hub も VPC Service Controls 境界（perimeter）の外にありますので、境界の影響を受け、アクセスが拒否されます。 Ads Data Hub からユーザーの BigQuery へのアクセスには、サービスアカウントが使用されます。VPC Service Controls によってアクセスが拒否された場合、 Cloud Logging ログを確認し、どのサービスアカウントが拒否されているかを特定 し、 内向きルール（Ingress rules）で許可 することで、アクセスさせることができます。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、Cloud Run や Cloud Run functions（旧称：Cloud Functions）のパフォーマンス向上のコツとして、グローバル変数の活用方法を紹介します。 サーバーレスにおけるコールドスタート グローバル変数によるリクエスト間のオブジェクト再利用 グローバル変数のユースケース 検証 サンプルコード（Python） 動作検証 サーバーレスにおけるコールドスタート Cloud Run、Cloud Run functions といったサーバーレス コンピューティングサービスは、負荷に応じてインスタンスが自動的にスケーリングされます。リクエストがないときはインスタンス数をゼロまでスケールインすることで、リソース利用料を節約することができます。 この動的スケーリングの特徴はサーバーレスの強みであると同時に、 コールドスタート という特有の問題も引き起こします。インスタンスが起動するたびにリソースの確保とアプリケーションの初期化処理が行われるため、同じインスタンスを常時起動している場合よりも、レスポンスが遅延する場合があります。 Cloud Run におけるコールドスタートの詳細については以下の記事をご一読ください。 blog.g-gen.co.jp また、サーバーレスの特徴については、以下の記事でも解説しています。 blog.g-gen.co.jp グローバル変数によるリクエスト間のオブジェクト再利用 Cloud Run や Cloud Run functions では、リクエストによりインスタンスが起動すると、スケーリングが起こるまでは同じインスタンスを再利用して後続リクエストの処理を行います。 このとき、ソースコード上の グローバルスコープに記述された処理 は、アプリケーションの初期化、つまり コールドスタート発生時のみ評価される という特徴があります。 したがって、負荷の高い処理をグローバルスコープに記述すると、コールドスタート時のみ処理が行われ、別々のリクエスト間で処理結果を再利用することができます。 これにより、コールドスタート時のパフォーマンスは変わりませんが、それ以降のリクエストに対する処理時間を短縮することができます。 参考： Cloud Run - グローバル変数の使用 参考： Cloud Run functions - グローバル変数を使用して将来の呼び出しでオブジェクトを再利用する グローバル変数のユースケース 前述の通り、グローバル変数は別々のリクエスト間でも値が共有されます。そのため、すべてのリクエストで同じ値となっても問題がないような値を格納すべきです。以下は、その例です。 環境変数の値 初期化したクライアントオブジェクト 初期化した機械学習モデル定義 例えば、以下のような機械学習モデルの初期化は負荷のかかる処理であり、かつ結果をリクエスト間で使いまわすことができるため、グローバルスコープに記述することでパフォーマンス向上に繋がります。 # Gemini モデルの初期化 model = GenerativeModel( model_name= "gemini-1.5-pro" , ) 逆に、以下のようなものに対してはグローバル変数を使用しないようにしましょう。 リクエストごとに異なることが期待される値（ユーザー情報、リクエスト受信時刻など） 頻繁に変更される値（アクセストークン、データベースのクエリ結果など） 検証 サンプルコード（Python） このコードでは負荷の高い処理の例として、10秒待機してから現在時刻を返す heavy_computation 関数が定義されており、グローバル変数である heavy_result に結果を格納しています。この処理はグローバルスコープに記述されているため、インスタンスの起動時のみ実行されます。 したがって、 heavy_computation 関数による 10秒のウェイト処理は、インスタンスが処理する最初のリクエストに対してのみ発生することになります。また、変数 heavy_result に格納される時刻は、このインスタンスが処理するどのリクエストでも同じ値となります。 また、ここでは比較用に light_computation 関数を用意しています。この関数は実行された時刻を返すだけの処理であり、リクエストが来たときに実行される main 関数内から呼び出されます。したがって、結果を格納する light_result の値は、リクエストのたびに異なるものになります。 # main.py import os, time from datetime import datetime from flask import Flask, jsonify app = Flask(__name__) # 軽めの処理 def light_computation (): return datetime.now().strftime( "%Y-%m-%d %H:%M:%S" ) # 関数が完了した時刻を返す # 時間のかかる処理 def heavy_computation (): time.sleep( 10 ) # 10秒間の待機 return datetime.now().strftime( "%Y-%m-%d %H:%M:%S" ) # 関数が完了した時刻を返す # 時間のかかる処理の結果をグローバル変数に格納 # コンテナインスタンス起動時に一度だけ実行され、以降のリクエストでは値が使い回される heavy_result = heavy_computation() @ app.route ( "/" ) def main (): # リクエストのたびに実行される light_result = light_computation() return jsonify({ "light" : light_result, "heavy" : heavy_result}) # 2つの関数が完了した時刻をそれぞれ返す if __name__ == "__main__" : app.run(host= "0.0.0.0" , port= int (os.environ.get( "PORT" , 8080 ))) 上記のコードを Cloud Run サービスとしてデプロイします。このサービスにリクエストを送ると、 light_result と heavy_result の値が返ってきます。 動作検証 デプロイ直後はインスタンスが起動している状態のため、一度インスタンス数がゼロになってからリクエストを送信します。 # Cloud Run にリクエストを送信する $ curl ${Cloud RunのURL } ----- 出力 ----- # コールドスタートにより、10秒のウェイト処理のあと処理の結果が返ってくる light: 2024-08-10 07:22:38 heavy: 2024-08-10 07:22:38 コールドスタートによりグローバルスコープに記述した処理が実行され、 heavy_computation 関数の10秒のウェイト処理ののち、レスポンスが返ってきます。 初回呼び出し（コールドスタート）の処理内容 次に、5秒おきにリクエストを送信してみます。 # 5秒おきに Cloud Run にリクエストを送信する $ watch -n 5 -d -t curl ${Cloud RunのURL } ------ 出力（ 1 回目） ----- light: 2024-08-10 07:26:05 heavy: 2024-08-10 07:22:38 ------ 出力（ 2 回目） ----- light: 2024-08-10 07:26:10 heavy: 2024-08-10 07:22:38 ------ 出力（ 3 回目） ----- light: 2024-08-10 07:26:15 heavy: 2024-08-10 07:22:38 ------ 出力（ 4 回目） ----- light: 2024-08-10 07:26:20 heavy: 2024-08-10 07:22:38 ------ 出力（ 5 回目） ----- light: 2024-08-10 07:26:25 heavy: 2024-08-10 07:22:38 今回はコールドスタートが発生していないため heavy_computation 関数は実行されません。そのため10秒のウェイトがなく、レスポンスがすぐに返ってきます。 2回目以降の呼び出し（コールドスタートなし）の処理内容 また、グローバル変数である heavy_result の値は初回リクエスト時から維持され、どのリクエストでも一定になっています。それに対して、リクエストのたびに変更される light_result の値は5秒刻みになっていることがわかります。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の奥田梨紗です。オープンソースの Looker 拡張機能である Explore Assistant を使い、自然言語によってグラフを生成できる機能を実装しました。本記事ではその機能の紹介や、実装手順について紹介します。 はじめに Looker Explore Assistant の紹介 できること 1. Assistant 機能 2. Chat 機能 料金 利用事例 実装 構成 実装の手順 環境変数ファイルの作成と編集 はじめに 当記事では、Looker 拡張機能である Looker Explore Assistant を紹介します。 Looker Explore Assistant は、Looker Explore 上で自然言語の指示に基づいて生成 AI がグラフを作成してくれる拡張機能です。オープンソースで公開されており、Looker にアドオンとして組み込むことができます。 Looker Explore Assistant には、大きく分けて Assistant と Chat の2つの機能があります。いずれも自然言語によって Explore 経由でデータへの問い合わせを行い、クエリ結果を得たり、チャート（グラフ）を作成できます。Assistant がワンショットのクエリに対して結果を返答する機能であるのに対して、Chat はインタラクティブに生成 AI と会話し、フォローアップ質問をすることもできます。 使用する生成 AI 基盤モデルとして Gemini 1.5-flash （ Gemini ）がデフォルトで設定されています。 参考 : Looker Explore Assistant 類似の Looker 拡張機能として、 Looker Dashboard Summarization があります。こちらに関しては以下の記事で紹介しています。Looker、Looker 拡張機能、Looker 拡張フレームワークなどの前提知識については、以下の記事も参考にしてください。 blog.g-gen.co.jp Looker Explore Assistant の紹介 できること Looker Explore Assistant を使うと、指定したテーブルのデータを対象に、自然言語で対話しながら可視化や詳細分析ができます。 今回は例として、架空の顧客データを用いて分析しました。 顧客番号 氏名 性別 生年月日 年齢 居住地 累計売上高 GS00001 山田 太郎 男 1990-04-29 31 兵庫県 3704 GS00002 田中 花子 女 2005-09-30 20 兵庫県 5709 … … … … … … … Looker ダッシュボードの「アプリケーション」から「Explore Assistant」を選択すると、メインダッシュボードが表示されます。 youtu.be Looker Explore Assistant には、大きく分けて Chat 機能と Assistant 機能があります。どちらの機能も、自然言語で Explore に対する問い合わせができますが、 Chat 機能は会話を継続できる のに対し、 Assistant 機能は会話ごとに内容がリセット されます。 1. Assistant 機能 まずは、顧客の性別比を調べてみます。プロンプトには以下のように入力します。 男女比を棒グラフで教えて 入力した自然言語に基づき、Looker Explore によってグラフが生成されます。 次に、より複雑な分析を試みます。プロンプトには以下のように入力します。 性別が男で、顧客の居住地を多い順から順番に教えて 結果は下記の通りです。 一方、以下のように問い合わせた場合、結果は得られませんでした。表現によっては、生成 AI がうまく解釈できない場合もあるため、プロンプトを試行錯誤する必要があります。 性別が男性で、顧客の居住地を多い順から順番に教えて 2. Chat 機能 Chat 機能では、自然言語での対話を重ねることで、詳細な分析を行うことができます。 例えば、まず最初の質問で年齢の分布図を作成させ、フォローアップ質問（追加の質問）をすることで別の値をグラフに表現させるなど、探索的なクエリを行うことができます。 料金 この拡張機能の利用にあたり、 Looker に対する追加のライセンス費用は発生しません 。 ただし、 Looker Explore Assistant から呼び出すバックエンド （BigQuery または Cloud Run functions）や、Gemini API（Vertex AI）の利用料金が発生します。 バックエンドで Cloud Run functions を選択する場合、最小インスタンス数を設定すると、インスタンスのアイドル時間に対しても課金が発生します。 また、通常の Looker 利用と同じく、使用するデータセット（BigQuery 等）に対するクエリ料金も発生する点にご留意ください。 参考 : Cloud Run functions - Pricing Overview 参考 : BigQuery pricing 参考 : Vertex AI pricing 利用事例 Google Cloud Next Tokyo '24 の2日目に行われたセッション「公共機関で進む DX の現在と未来 〜 次世代に向けたイノベーション 〜」では、日本大学による検証が紹介されました。 この検証では、学籍・成績関連データを AI アシスタントとのチャットを通じて可視化する PoC が実施されました。 実装 構成 今回実装した Explore Assist の構成図は、以下のとおりです。 システム構成図 データの流れは以下の通りです。以下の項番は、図中の数字に対応しています。 ユーザーが Looker Explore Assistant 画面上でプロンプトを入力 バックエンドから Vertex AI の Gemini API を呼び出して推論を実行 Gemini がクエリ用 URL を生成 クエリ用の URL を Looker に返却 Looker Explore Assistant 画面上に、クエリ用 URL の実行結果を表示 実装の手順 実装の流れは以下のとおりです。 公開リポジトリをクローン（ GitHub レポジトリ ） フロントエンドの構築 バックエンドの構築 BigQuery データセットにクエリ生成に利用するサンプルプロンプトを格納 ローカルでテスト ビルド（npm コマンド） デプロイ（Looker の Web コンソール等） 環境変数ファイルの作成と編集 Looker Explore Assistant を利用する対象の Model と Explore は、環境変数ファイル .env に事前に定義しておく必要があります。 対象の Model と Explore を変更するには、環境変数ファイルを更新する必要があります。 環境変数ファイルは looker-explore-assistant/explore-assistant-extension フォルダに格納し、以下の様に作成します。 LOOKER_MODEL = < 分析で使用する Explore が存在するModel ファイル名 > LOOKER_EXPLORE = < 分析で使用する Explore 名 > VERTEX_BIGQUERY_LOOKER_CONNECTION_NAME = < BigQuery ML のリモートモデルに IAM 権限を持つサービスアカウントと紐づけた Looker の Connection 名 > VERTEX_BIGQUERY_MODEL_ID = < Google Cloud プロジェクト名 > .explore_assistant.explore_assistant_llm BIGQUERY_EXAMPLE_PROMPTS_CONNECTION_NAME = < サンプルプロンプト用データセットへの IAM 権限を持つ Looker の Connection 名 > BIGQUERY_EXAMPLE_PROMPTS_DATASET_NAME = < Google Cloud プロジェクト名 > .explore_assistant 奥田 梨紗 (記事一覧) クラウドソリューション部クラウドデベロッパー課 前職はベトナムのIT企業。 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。日々修行中です！ Follow @risa_hochiminh 菊池 健太 (記事一覧) クラウドソリューション部データアナリティクス課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、GCPは未経験なので現在勉強中。

G-gen の佐々木です。当記事では 2024年9月より Cloud Run で利用可能となった Deterministic URL について解説します。 Deterministic URLs とは Deterministic URL のユースケース（Terraform の例） 既存の Cloud Run サービスへの影響 新規に作成した Cloud Run サービス サービスの URL を無効化した場合 Deterministic URLs とは 2024年9月以降、Cloud Run サービスにアクセスするための URL として、従来の URL（Non-deterministic URL）に加え、 Deterministic URL が使用できるようになりました。 従来からある Non-deterministic URL は以下のような形式となっていました。 # Non-deterministic URL の形式 https:// { サービス識別子 } .run.app Non-deterministic URL のサービス識別子はランダムハッシュが含まれており、サービスの作成が完了するまで、サービスの URL がどうなるか予測することができませんでした。 それに対して、deterministic URL は以下のような形式となっています。 # Deterministic URL の形式 https:// { サービス名 } - { プロジェクト番号 } . { リージョン } .run.app このように、サービスの作成前から URL が予測できるような形式になっていることで、IaC やシェルスクリプトなどで Cloud Run サービスを扱いやすくなります。 参考 : Deterministic URL Deterministic URL のユースケース（Terraform の例） たとえば、バックエンド用の Cloud Run サービスと、それを呼び出すフロントエンド用の Cloud Run サービスを Terraform で作成する場面を想定してみます。フロントエンドのサービスの環境変数に、バックエンドのサービスの URL を設定します。 従来の Non-deterministic URL を使用する場合、バックエンドのサービスの URL はサービス作成後に判明します。したがって、それを呼び出すフロントエンドのサービスは、必ずバックエンドのサービスの作成後に作成する必要があります。 それに対して、deterministic URL の場合、バックエンドのサービスの URL は作成前に予測可能なため、フロントエンドとバックエンドのサービスを並行して作成することができます。 したがって、Cloud Run サービスの URL がわかるまで作成できないようなリソースは、deterministic URL を使用することで依存関係を解消し、並行して作成できるようになります。 既存の Cloud Run サービスへの影響 Google Cloud コンソールから既存のサービスを確認すると、以前までは Non-deterministic URL が表示されていた URL の項目が Deterministic URL になっています。 既存のサービスはコンソール上のURLがdeterministic URLになっている gcloud コマンドを使用することで、今まで使用していた Non-deterministic URL を確認することができます。コンソールの場合はサービス詳細画面の YAML タブから確認できます。 # 既存のサービスの URL を確認する（Non-deterministic URL が出力される） $ gcloud run services describe hello --region = asia-northeast1 --format =' value(status.url) ' https://hello-xxxxxxxxxx-an.a.run.app コンソールからNon-deterministic URLを確認する もしくは、インフォメーションマークをクリックして表示される情報パネルで確認することも可能です。 インフォメーションマークから2つの URL を確認 実際にサービスにアクセスしてみます。従来から存在していた Non-deterministic URL にアクセスすると、ステータスコード200が返り、サービスにアクセスできていることがわかります。 # Non-deterministic URL を使用し既存のサービスにアクセスする（ステータスコードのみ抽出） $ curl https://hello-xxxxxxxxxx-an.a.run.app -o /dev/null -w " %{http_code} \n " -s 200 続いて、Deterministic URL を使用してアクセスします。こちらも同様にステータスコード200が返ってきます。 # Deterministic URL を使用して既存のサービスにアクセスする（ステータスコードのみ抽出） $ curl https://hello-000000000000.asia-northeast1.run.app -o /dev/null -w " %{http_code} \n " -s 200 したがって、既存のサービスについては、コンソール上の URL が Deterministic URL に変更されたものの、 どちらの URL も使用できる 状態になっているため、今まで使っていた URL でサービスにアクセスできなくなるといった影響はありません。 新規に作成した Cloud Run サービス 続いて、Deterministic URL が一般公開されて以降に作成されたサービスについて確認してみます。 コンソール上では Deterministic URL が表示されています。 新しく作成したサービスもはコンソール上のURLがdeterministic URLになっている CLI で URL を確認すると、Non-deterministic URL が表示されます。したがって、新規に作成されたサービスについても Non-deterministic URL が発行されていることがわかります。 # 新しく作成されたサービスの URL を確認する（Non-deterministic URL が出力される） $ gcloud run services describe hello-new --region = asia-northeast1 --format =' value(status.url) ' https://hello-new-yyyyyyyyyy-an.a.run.app そして、どちらの URL にも問題なくアクセスできます。 # Non-deterministic URL を使用して新しいサービスにアクセスする（ステータスコードのみ抽出） $ curl https://hello-new-yyyyyyyyyy-an.a.run.app -o /dev/null -w " %{http_code} \n " -s 200 # Deterministic URL を使用して新しいサービスにアクセスする（ステータスコードのみ抽出） $ curl https://hello-new-000000000000.asia-northeast1.run.app -o /dev/null -w " %{http_code} \n " -s 200 したがって、 サービスの作成タイミングに関わらず、どちらの URL も使用できる 状態になっています。 サービスの URL を無効化した場合 Cloud Run ではサービスに付与される URL を無効化することもできます。無効化の方法やユースケースについては以下の記事をご一読ください。 blog.g-gen.co.jp URL の無効化を行った場合、Deterministic URL、Non-deterministic URL ともに無効化され、サービスの URL を使用したアクセスができなくなります。 URLを無効化したサービス # URL を無効化したサービスの URL を確認する $ gcloud run services describe hello-no-url --region = asia-northeast1 --format =' value(status.url) ' （※何も出力されない） Deterministic URL は形式が決まっているため、それに従った URL にアクセスしてみましたが、URL を無効化したサービスでは404エラーが返ってきました。 # Deterministic URL の形式に従った URL にアクセスしてみる $ curl https://hello-no-url-000000000000.asia-northeast1.run.app -o /dev/null -w " %{http_code} \n " -s 404 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。2024年8月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Google Cloud Next Tokyo '24 で新発表 Python SDK で API コールなしで Gemini のトークン数カウント（Preview） Gemini on Vertex AI で、1リクエストで複数回答候補の生成が可能に SCC の Cloud Infrastructure Entitlement Management（CIEM）機能が公開 Cloud Logging でログスコープ機能が Preview BigQuery で Short query optimized mode が Preview Cloud SQL の Extended suppport の料金表が発表 Vertex AI Search で検索のチューニングが可能に（GA） BigQuery の Recommendations (推奨事項)がまとめて閲覧可能に (Preview) Cloud Functions が Cloud Run functions にリブランディング Cloud Run（services）で GPU が利用可能に Cloud Run で自動セキュリティアップデート（Preview） VLAN Attachment で VPC Flow Logs を有効化できるように Google Workspace の Business Starter で共有ドライブが利用可能に BigQuery から Claude (Sonnet / Haiku / Opus) を呼び出せるように Cloud Run で Cloud Service Mesh が利用可能に（Preview） Google Meet で Take notes for me（自動議事メモ書き起こし）が利用可能に Gemini (http://gemini.google.com) で 各種ファイルのアップロードが可能に Gemini (http://gemini.google.com) で Gems（カスタムチャット）が利用可能に Cloud Run からの Cloud Storage / NFS マウントが Preview → GA 各種 Gemini in BigQuery 機能が Preview -> GA に BigQuery で ARRAY/STRUCT 型に対して GROUP BY / SELECT DISTINCT が使えるように はじめに 当記事では、毎月の Google Cloud アップデートのうち特に重要なものをまとめます。 また当記事は、Google Cloud に関するある程度の知識を前提に記載されています。前提知識を得るには、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp リンク先の公式ガイドは、英語版で表示しないと最新情報が反映されていない場合がありますためご注意ください。 Google Cloud Next Tokyo '24 で新発表 2024年8月1日〜2日、パシフィコ横浜ノースで Google Cloud Next Tokyo '24 が開催された。同イベントでは、以下のような技術的な新発表が行われた。 Imagen 3 が公開（Allow listed Generally Available） 「BigQuery データキャンバス」「マテリアライズド ビュー、 パーティション、クラスタリングの Recommender」が GA へ Data Preparation for Gemini BigQuery の Preview が開始へ Gemini Code Asisst と Gemini Cloud Asisst が GA へ Spanner Graph が Preview 公開 Spanner の全文検索とベクトル検索が Preview 公開 Spanner の料金体系が一新へ。Spanner Editions Bigtable で SQL が利用可能に（Preview） Model Armor が Preview 公開へ 以下のレポート記事では、キーノート（基調講演）の内容を紹介する。上記の技術的な発表については、主に2日目のキーノートの紹介記事で解説している。 blog.g-gen.co.jp blog.g-gen.co.jp Python SDK で API コールなしで Gemini のトークン数カウント（Preview） List and count tokens (2024-08-02) Vertex AI の Python SDK（1.60.0以降）で、API コールなしで Gemini のトークン数のカウントができるように（Preview）。 料金試算や大きすぎるインプットの抑制に使用できる。 Gemini on Vertex AI で、1リクエストで複数回答候補の生成が可能に Vertex AI release notes - August 09, 2024 (2024-08-09) Gemini on Vertex AI で、1リクエストで複数の回答候補を生成させることが可能に。 アウトプットトークン数は生成した分だけ課金されるが、インプットトークン数は1回しか課金されない。API request の generationConfig で生成する候補数を指定する。 SCC の Cloud Infrastructure Entitlement Management（CIEM）機能が公開 Overview of Cloud Infrastructure Entitlement Management (2024-08-12) Security Command Center で Cloud Infrastructure Entitlement Management（CIEM）が GA。 利用できるのは最上位ティアである Enterprise tier のみ。最小権限の原則を守るための機能であり、Google Cloud と AWS に対応している。Entra ID、Okta 等との外部 ID 連携にも対応。具体的な修正方法に関するガイダンスも提示してくれる。 Cloud Logging でログスコープ機能が Preview Create and manage log scopes (2024-08-13) Cloud Logging でログスコープ機能が Preview。 ログスコープは、Cloud Logging の Log Explorer で閲覧するログの範囲を指定するリソース。複数プロジェクトや複数ログビューを追加できる。これにより、Google Cloud プロジェクトを横断したログ閲覧が可能になる。なおスコープ自体はプロジェクトレベルリソース。 BigQuery で Short query optimized mode が Preview Short query optimized mode (2024-08-14) BigQuery で Short query optimized mode（短いクエリの自動最適化）が Preview。 コンソールや bq コマンド、SDK で明示的に有効化してクエリする。有効化して実行すると、最適化の適用可否は自動判断される。最適化が適用されると、ジョブが生成されず、同期的処理になる。 ダッシュボードやデータ探索等で発行される短い SELECT 文を想定。以下の記事では、実際に処理時間が短縮されたかどうか、検証結果が記載されている。 blog.g-gen.co.jp Cloud SQL の Extended suppport の料金表が発表 Extended support pricing (2024-08-15) Cloud SQL の MySQL/PostgreSQL の Extended support の料金表が発表。 Extended support とは、コミュニティサポート終了後の、Google Cloud による有償の延長サポートのこと。公式にサポートが修了したメジャーバージョンでも、Google Cloud によってセキュリティパッチ等が提供される。 サポート料金はインスタンス時間に対する時間課金であり、1〜2年目と3年目で単価が異なる。 Vertex AI Search で検索のチューニングが可能に（GA） Improve search results with search tuning (2024-08-16) Vertex AI Agent Builder（Vertex AI Search）で検索のチューニングが可能に（GA）。 非構造化データストアで使用可能。クエリと回答のペアを大量に登録することで、検索性能をチューニングできる。10,000程度のテキストスニペットを含ませることが推奨されている。 BigQuery の Recommendations (推奨事項)がまとめて閲覧可能に (Preview) Recommendations overview (2024-08-19) BigQuery のナビゲーションメニュー ＞ Recommendations（推奨事項）から推奨事項がまとめて閲覧可能に（Preview）。 以下を1画面で閲覧できる。組織レベル / プロジェクトレベルで表示を切替可能。 パーティションとクラスタリングのレコメンド マテリアライズド ビューのレコメンド IAM 権限のレコメンド Cloud Functions が Cloud Run functions にリブランディング Cloud Functions is now Cloud Run functions — event-driven programming in one unified serverless platform (2024-08-22) Cloud Functions が Cloud Run functions にリブランディング。名称変更だけなく、以下のような Cloud Run の機能が、functions でも利用可能になった。 GPU の使用（Preview） Direct VPC egress Cloud Storage バケットのマウント リビジョン間のトラフィック分割 既にデプロイ済みの関数には影響はない。詳細や影響については、以下の解説記事を参照。 blog.g-gen.co.jp Cloud Run（services）で GPU が利用可能に GPU (services) (2024-08-22) Cloud Run（services）で GPU が利用可能に（Preview）。 機械学習モデルや生成 AI のオンライン推論や、動画像エンコーディングなどに利用する想定。NVIDIA L4 GPUs with 24 GB VRAM。現在のところ、利用するには許可リストへの申請が必要で、利用可能リージョンは us-central1（Iowa）のみ。 Cloud Run で自動セキュリティアップデート（Preview） Configure automatic base image updates (2024-08-22) Cloud Run で自動ベースイメージアップデートが可能に（Preview）。 OS・ランタイムにセキュリティパッチが自動適用。再ビルド・再デプロイの必要がない。ただし、対応ベースイメージは限定されており、原則は deploy from source とセットで利用することが推奨されている。 VLAN Attachment で VPC Flow Logs を有効化できるように VPC Flow Logs (2024-08-23) VLAN Attachment で VPC Flow Logs を有効化できるように。従来は VPC 内部の VM 間通信しかトラフィックログを記録できなかった。 VLAN Attachment とは、Cloud VPN や Cloud Interconnect（専用線）の接続のために作成する VPC コンポーネント。 Google Workspace の Business Starter で共有ドライブが利用可能に Business Starter customers will soon have access to shared drives (2024-08-26) 2024年9月23日から、Business Starter エディションで共有ドライブが使えるようになる。 ただし以下のようなアクセス制御機能は使用できない。 組織外のユーザーとファイルを共有できないようにする 共有ドライブのメンバー以外とファイルを共有できないようにする コンテンツ管理者のアクセスレベルを持つメンバーにはフォルダの共有を許可しない 閲覧者（コメント可）または閲覧者のアクセスレベルを持つメンバーにはファイルのダウンロード、コピー、印刷を許可しない BigQuery から Claude (Sonnet / Haiku / Opus) を呼び出せるように ENDPOINT (2024-08-26) BigQuery から Claude（Sonnet / Haiku / Opus）を呼び出せるように。 従来までは BigQuery ML では Gemini などファーストパーティの生成 AI モデルだけが呼び出せたが、以下の Claude モデルが対応した。 claude-3-5-sonnet@20240620 claude-3-sonnet@20240229 claude-3-haiku@20240307 claude-3-opus@20240229 Cloud Run で Cloud Service Mesh が利用可能に（Preview） Configure Cloud Service Mesh for Cloud Run (2024-08-26) Cloud Run で Cloud Service Mesh（フルマネージドのIstio）を使って Cloud Run、Google Kubernetes Engine（GKE）、Compute Engine とのルーティングが可能に。 これによりマイクロサービスにおけるサービスメッシュの構成が容易になる。以下のようなメリット。 セキュリティポリシーの統一管理 トラフィックモニタリング デバッグ 負荷分散 GKE など他のコンテナサービスとまたがるトラフィック管理 Google Meet で Take notes for me（自動議事メモ書き起こし）が利用可能に “Take notes for me” in Google Meet is now available (2024-08-27) Google Meet で Take notes for me が利用可能に。AI を利用した議事録書き起こし機能。まず英語のみ対応。 書き起こしたメモは Google Docs としてカレンダーに添付される。利用には、以下いずれかのアドオンライセンスが必要。 Gemini Enterprise Gemini Education Premium AI Meetings & Messaging Gemini ( http://gemini.google.com ) で 各種ファイルのアップロードが可能に Upload additional types of documents to Gemini (gemini.google.com) for insights and analysis (2024-08-27) Google Workspace 向け Gemini（ http://gemini.google.com ）で TXT、DOCX、PDF、XLSX、CSV、Google Docs、Google Sheets などをアップロードできるようになった。従来は画像のみ。 アドオンライセンス購入済みユーザーが対象。 Gemini Enterprise Gemini Business Gemini Education Gemini Education Premium Gemini ( http://gemini.google.com ) で Gems（カスタムチャット）が利用可能に Customize Gemini (gemini.google.com) for your specific needs with Gems (2024-08-28) Google Workspace 向け Gemini（ http://gemini.google.com ）でカスタムチャットを作成するための機能である Gems が公開。 ペルソナや背景を予め設定しておくことで、プロンプトで目的やガイドラインを都度伝える必要がなくなる。以下のアドオンライセンスが必要。 Gemini Business Gemini Enterprise Gemini Education Gemini Education Premium 利用方法は、以下のマニュアルを参照。 Gemini アプリで Gem の使用を開始する 以下の記事も参照。 blog.g-gen.co.jp Cloud Run からの Cloud Storage / NFS マウントが Preview → GA Configure Cloud Storage volume mounts for services (2024-08-27) Cloud Run で Cloud Storage を volume としてマウントする機能が Preview → GA。また同時に、NFS ファイル共有のマウントも Preview → GA。 services と jobs の両方で対応している。Cloud Storage のマウントでは、背後で Cloud Storage FUSE が利用されている。 各種 Gemini in BigQuery 機能が Preview -> GA に BigQuery release notes - August 28, 2024 (2024-08-28) Gemini in BigQuery の各種機能が Preview -> GA に。生成 AI により BigQuery の業務や運用の工数を低減できる。 データキャンバス データインサイト（分析情報） SQL/Python コード生成 パーティショニング・クラスタリングの推奨事項 BigQuery で ARRAY/STRUCT 型に対して GROUP BY / SELECT DISTINCT が使えるように BigQuery release notes - August 28, 2024 (2024-08-28) BigQuery で ARRAY/STRUCT 型に対して GROUP BY / SELECT DISTINCT が使えるようになった。 従来は、これらの型に対するグルーピングを使った集計関数や SELECT DISTINCT は使用できなかった。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it