はじめに 当記事について おまけ画像 コンピューティング Compute Engine コンテナ Artifact Registry Cloud Build Cloud Deploy Google Kubernetes Engine（GKE） データ分析 BigQuery Looker Dataproc Dataflow Pub/Sub データベース Bigtable Spanner Cloud SQL Firestore Memorystore サーバーレス App Engine Cloud Run functions Cloud Run ストレージ Cloud Storage ネットワーキング Cloud Armor Cloud CDN Cloud DNS Cloud Next Generation Firewall（Cloud NGFW） Cloud Load Balancing VPC Service Controls 運用 Cloud Logging Cloud Monitoring セキュリティと ID Sensitive Data Protection Cloud Key Management Service (KMS) Secret Manager Identity and Access Management (IAM) さいごに はじめに 当記事について 当記事は、「Google Cloud（旧称 GCP）の主要サービスを、それぞれ50文字程度で解説してみる」という記事です。 「Google Cloudの主要サービス一覧がみたい」とか「概要をざっくり理解しておきたい」といったご要望にお答えできるように作成しました。以下のカテゴリ別に、私が重要だと思ったサービスを取り上げています。サービス区分は https://cloud.google.com/products?hl=ja を元にしています。複数カテゴリに所属するサービスは、どちらか一方に寄せています。 コンピューティング コンテナ データ分析 データベース サーバレス ストレージ ネットワーキング 運用 セキュリティと ID おまけ画像 当記事の内容を1枚の画像にまとめました。印刷して自然と目に入る壁に貼っていただくことで、自然と覚えられる！...かもしれません。 50文字で説明 仕様上、ブログ上ではこれ以上の画質にすることが難しそうでしたが、ご了承ください。 コンピューティング Compute Engine オンプレミスサーバーと同等の仮想マシンサービス。世界中の Google のデータセンターで提供。(48文字) コンテナ Artifact Registry コンテナイメージなどを保存するリポジトリサービス。暗号化、アクセス制御、脆弱性スキャンも可能。(47文字) Cloud Build ソースコードからコンテナイメージをビルドするサービス。ソースコードさえあれば簡単にビルドを実行可能。 (50文字) Cloud Deploy CI/CDプロセスを自動化して、コンテナイメージやバイナリファイルをアプリケーションにデプロイする。(50文字) Google Kubernetes Engine（GKE） Kubernetes クラスターを簡単に作成管理できるサービス。コンテナアプリの実行に最適。(45文字) データ分析 BigQuery 大規模なデータ分析に最適なクラウドデータウェアハウスサービス。ログデータや顧客データの分析に活用。 (49文字) Looker データの可視化・分析を統合したBIサービス。データを簡単に接続して、直感的にレポートを作成可能。(48文字) Dataproc 大規模データ処理ツール（Apache Hadoop や Apach Spark など）を提供するサービス。(47文字) Dataflow ストリーム処理サービス。センサーデータのリアルタイム分析などに活用可能。(36文字) Pub/Sub 非同期メッセージングサービス。イベント通知やアプリ連携などに活用可能。(35文字) データベース Bigtable 大規模な時系列データやログデータの格納に最適なNoSQLデータベース。低レイテンシで大量データ。(48文字) Spanner グローバル分散で高いスケーラビリティを備えたRDB。可用性99.999%と、ミリ秒単位のレイテンシ。(50文字) Cloud SQL MySQL、PostgreSQL、SQLServerをクラウド上で利用できるサービス。(43文字) Firestore ドキュメント型のデータモデルを採用し、リアルタイムでのデータアクセスが可能なNoSQL DB。(46文字) Memorystore Redis または Memcached をクラウド上で利用できる、フルマネージドのインメモリデータストア。(50文字) サーバーレス App Engine サーバーレスなアプリケーション実行環境。Web、モバイル、IoT など、様々なアプリケーションに対応。(50文字) Cloud Run functions イベントドリブンな関数実行サービス。コードをアップロードするだけで、イベントに応じて関数が実行可能。(50文字) ※2024年8月、Cloud Functions は Cloud Run functions にリブランディング（名称変更）されました。 Cloud Run コンテナアプリケーション実行サービス。コンテナをアップロードするだけで、アプリケーションが実行可能。(50文字) ストレージ Cloud Storage 高耐久性、高可用性なオブジェクトストレージ。ウェブコンテンツからログデータ保管まで幅広く活用可能。(49文字) ネットワーキング Cloud Armor DDoS 攻撃をはじめ悪意のあるトラフィックからウェブアプリケーションを保護するサービス。(44文字) Cloud CDN 世界中にキャッシュサーバーを展開し、Web コンテンツをユーザーに近い場所から配信するサービス。(47文字) Cloud DNS マネージドDNSサービス。グローバルなネットワークで、高可用性と低レイテンシを実現。(42文字) Cloud Next Generation Firewall（Cloud NGFW） VPC のネットワークトラフィックを制御。ポート、プロトコル、IPアドレス等の条件で制御可能。(47文字) Cloud Load Balancing トラフィックを複数のサーバーに分散し、アプリケーションの可用性とパフォーマンスを向上させるサービス。(50文字) VPC Service Controls Google Cloud リソースへのアクセスをIP アドレス、デバイス等の条件で制御するサービス。(50文字) 運用 Cloud Logging ログデータを収集・保存・分析するサービス。可視化・分析により、問題の早期発見と解決を支援。 (45文字) Cloud Monitoring アプリケーションやインフラのパフォーマンスや状態を監視。メトリクス、ログ、アラート等を統合的に管理。(50文字) セキュリティと ID Sensitive Data Protection 機密データの流出を防ぐためのサービス。機密データの識別、検出、保護を行い、情報漏洩リスクを低減。(48文字) ※Cloud Data Loss Prevention（Cloud DLP）は Sensitive Data Protection の一部になりました。ただし、API 名や機能名として Data Loss Prevention（DLP）が残っています。 Cloud Key Management Service (KMS) 暗号化キーの管理を提供するサービス。強固な暗号化キーを安全に管理し、データの機密性と整合性を保護。(49文字) Secret Manager パスワード、API キー、トークンといった機密情報を安全に管理するためのサービス。(40文字) Identity and Access Management (IAM) Google Cloudにおけるユーザーの認証とアクセス権の管理を提供するサービス。(41文字) さいごに 以下のリンク集には、各サービスの徹底解説記事がまとめられています。これから Google Cloud を学ぼうとしている方は、ぜひ参考にしてください！ 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 の杉村です。2023年11月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Duet AI が Cloud Logging のログを要約・説明 (GA) 復数の Duet AI 関連アップデート BigQuery で異なるユーザ間でもキャッシュが効くように BigQuery で過去〜現在のストレージ使用量を取得可能に (Preview) BigQuery で TEXT_ANALYZE 関数が登場 (Preview) Generative AI support on Vertex AI で東京含むリージョン拡大 Looker Studio Pro の Android/iOS 用アプリがリリース Cloud Spanner のパフォーマンス (読み・書き QPS) が従来の1.5倍 Network Connectivity Center で VPC スポークが GA Cloud SQL で Enterprise Plus へのインプレイス・アップグレード Cloud Spanner で Managed autoscaler が Preview 公開 Cloud Run のサイドカーコンテナが Preview => GA Duet AI in Google Workspace が2024年に日本語対応 Egress/Ingress という言葉が Data Transfer Out/In に変更 BigQuery based の Vertex AI Feature Store が Preview => GA Cloud Storage で Object Lock 機能が使えるように Cloud Armor で Network edge security polices が使えるように Google Slides で録画機能 はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 Duet AI が Cloud Logging のログを要約・説明 (GA) Summarize log entries with Duet AI assistance (2023/11/01) Duet AI が Cloud Logging のログを要約・説明してくれる機能が GA。 Cloud Logging のログエクスプローラにて、ログを選択して要約ボタンを押すと、ログの意味を自然言語で解説してくれる。 2023/11/02のリリース時点では、英語版にしないとボタンが出て来ない。 復数の Duet AI 関連アップデート Duet AI release notes (2023/11/01) 前述のログエントリの解説機能のほか、以下のアップデートも発表された。 Duet AI for Cloud Shell (コード補完) Duet AI for Cloud Workstations (コード補完) Colab Enterprise での Inline code completion with Duet AI assistance (コード補完) VPC Service Controls での Duet AI support BigQuery で異なるユーザ間でもキャッシュが効くように Cross-user caching (2023/11/01) BigQuery で異なるユーザ間でも、クエリ結果にキャッシュが効くようになった (GA)。 従来は同一プロジェクトかつ同一アカウント（ユーザ）である必要があった。当アップデートで、同一プロジェクトであればキャッシュが効くようになり、パフォーマンスとスキャン料金に良い影響がある。 ただし Enterprise または Enterprise Plus edition のみで有効。 BigQuery で過去〜現在のストレージ使用量を取得可能に (Preview) TABLE_STORAGE_USAGE_TIMELINE view (2023/11/01) BigQuery で過去〜現在のストレージ使用量を取得可能に (Preview)。 システムビュー INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE から過去状況のスナップショットを取得可能になった。過去90日間のストレージ使用量が記録されている。 INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE_BY_ORGANIZATION のほうでは組織レベルで取得可能。 BigQuery で TEXT_ANALYZE 関数が登場 (Preview) TEXT_ANALYZE (2023/11/02) BigQuery で TEXT_ANALYZE 関数が登場 (Preview)。 インプットしたテキストを単語分割したり特定条件に基づいて正規化できる。同様のオプション群が SEARCH INDEX でも使えるようになっている。 以下は出力例。 SELECT TEXT_ANALYZE( ' I like pie, you like-pie, they like 2 PIEs. ' , analyzer=> ' PATTERN_ANALYZER ' ) AS results /*----------------------------------------------------------------* | results | +----------------------------------------------------------------+ | ['like', 'pie', 'you', 'like', 'pie', 'they', 'like', 'pies' ] | *----------------------------------------------------------------*/ Generative AI support on Vertex AI で東京含むリージョン拡大 Generative AI on Vertex AI locations (2023/11/02) Generative AI support on Vertex AI の API エンドポイントを提供するリージョンが拡大。北米、ヨーロッパ、アジアの 12 リージョンで API が提供開始。 アジアでは以下リージョンで利用可能。 Tokyo, Japan Seoul, Korea Singapore Looker Studio Pro の Android/iOS 用アプリがリリース Looker Studio Pro now available for Android and iOS (2023/11/04) Looker Studio Pro の Android/iOS 用アプリがリリース。 既存のPC用レポートもダイナミックにモバイル用デザインで表示できる。 Looker Studio Pro については以下の記事も参照。 blog.g-gen.co.jp 画像は 公式ブログ より引用 Cloud Spanner のパフォーマンス (読み・書き QPS) が従来の1.5倍 Increased performance throughput (2023/11/07) Cloud Spanner のパフォーマンスが従来の1.5倍になった。追加コスト / 追加作業なしで、読み取り・書き込みの QPS (Query per second) が従来の1.5倍になる。 2023年10月に大阪リージョン等に適用されていたが、今回東京リージョンなども追加で対象になった。 Network Connectivity Center で VPC スポークが GA VPC spokes overview (2023/11/08) Network Connectivity Center で VPC 同士をフルメッシュ接続する「VPC スポーク機能」がPreview から GA に。 AWS Transit Gateway のごとく、ハブアンドスポーク構成で複数の VPC を接続できるようになった。フルメッシュで VPC peering をするよりも効率的になる。 Network Connectivity Center については以下の記事も参照。 blog.g-gen.co.jp VPC スポークによる構成と VPC peering による構成 Cloud SQL で Enterprise Plus へのインプレイス・アップグレード Introducing Cloud SQL in-place upgrade: move from Enterprise to Enterprise Plus with ease (2023/11/10) Cloud SQL で Enterprise エディションから Enterprise Plus エディションへのインプレイス・アップグレードが可能に。 これまではスナップショット → リストアする必要があったが、コマンド一発でアップグレード可能になった。IP アドレスなども変わらない。60秒未満のダウンタイムが発生する。 Cloud Spanner で Managed autoscaler が Preview 公開 Managed autoscaler (2023/11/13) Cloud Spanner で Managed autoscaler が Preview 公開。 CPU 使用率やストレージ使用率に応じてノード数が増減。ストレージのリバランスも自動的に行われる。 Cloud Run のサイドカーコンテナが Preview => GA Deploying multiple containers to a service (sidecars) (2023/11/13) Cloud Run のサイドカーコンテナが Preview => GA。 モニタリング系コンテナ、Envoy、AlloyDB Auth Proxy などサイドカーコンテナが Cloud Run service で動かせるようになった。 Duet AI in Google Workspace が2024年に日本語対応 G-gen Tech Blog - Google Cloud Next Tokyo '23速報レポート (2023/11/15) Duet AI in Google Workspace が2024年中に日本語対応することが、Google Cloud Next Tokyo '23 で発表された。 Duet AI in Google Workspace は、生成 AI で業務補助を行う Google Workspace のアドオン。以下の記事も参照。 参考 : Duet AI for Google Workspace をプレビューしてみた (Google Docs 編) 参考 : Duet AI for Google Workspace をプレビューしてみた (Gmail 編) 参考 : Duet AI for Google Workspace をプレビューしてみた (Google Slides 編) Egress/Ingress という言葉が Data Transfer Out/In に変更 FAQ: Renaming Egress to Data Transfer (2023/11/16) Google Cloud の利用明細の SKU から「Egress」「Ingress」という言葉が無くなり、「Data Transfer Out」「Data Transfer In」に変更される。 2023/12/15 から適用。SKU ID は変更なし。もし分析で SKU description でフィルタする SQL を書いている場合は、SQL の変更が必要となる。 BigQuery based の Vertex AI Feature Store が Preview => GA Vertex AI release notes - November 17, 2023 (2023/11/17) 新しい Vertex AI Feature Store が Preview => GA。従来の Feature Store と異なり、BigQuery が基盤になっている。 推論のための Online serving も可能で、こちらの機能も GA。Online serving の裏では Bigtable が稼働している。 一部機能は Preview のままのため注意が必要。 Cloud Storage で Object Lock 機能が使えるように Object Retention Lock (2023/11/21) Cloud Storage で Object Lock 機能が使えるようになった。 Object Lock 機能では、オブジェクトを指定日時まで削除・更新できなくなり write once, read many (WORM) を実現。従来からバケット単位で設定する「保持ポリシー」は存在したが、今回のobject lock (object retention) ではオブジェクト単位で設定可能。 以下の記事でも解説。 blog.g-gen.co.jp Cloud Armor で Network edge security polices が使えるように Configure network edge security policies (2023/11/21) Cloud Armor で Network edge security polices と呼ばれる新しいセキュリティポリシーが使えるようになった（申請した利用者のみ使える）。 Public IP を持つ VM などにもアタッチ可能なポリシー。アタッチ可能なフロントエンドは以下の通り。 External passthrough Network Load Balancers Protocol forwarding パブリック IP を持つ VM Network edge security polices ではソース IP、ソース ASN、地域などで制限がかけられる。VPC Firewall とできることは似ているが、今後の拡張への布石か。 Google Slides で録画機能 Create shareable video presentations in Google Slides (2023/11/28) Google Slides で録画機能が使えるようになった。 プレゼンテーションを録画でき、音声を含ませることができる。ウェビナーなどに利用可能。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の堂原です。本記事では Google Cloud (旧称 GCP) のセキュリティサービスである VPC Service Controls において、IP アドレスを許可したにも関わらずアクセスが弾かれるケースにおける見落としがちな原因について紹介します。 はじめに 事象 : IP アドレスを許可したはずがアクセス失敗 原因 : IPv6 アドレスでアクセスしていた 確認方法 解消方法 はじめに VPC Service Controls は Google Cloud が提供しているセキュリティサービスです。 「サービス境界」と呼ばれる論理的な囲いを作成し、境界を跨ぐような API コールを制限します。 VPC Service Controls については、以下の記事で解説していますのでご参照ください。 blog.g-gen.co.jp VPC Service Controls においては、 アクセスレベル を設定することで、特定の条件を満たす通信が境界の外から中にアクセスすることを許可することができます。 条件には IP アドレス範囲や地域を指定することが可能です。 事象 : IP アドレスを許可したはずがアクセス失敗 改めて、VPC Service Controls ではアクセスレベルを用いることで、特定の IP アドレス範囲から境界内へのアクセスを許可することができます。 そのためにはまずはアクセスレベルを作成し、その際に許可したい IP アドレスを設定します。 次に今しがた作成したアクセスレベルを設定したサービス境界を作成します。 以上の設定で、境界で指定したプロジェクト (上図では黒塗りしている部分に記載) の BigQuery には、アクセスレベルで許可した IP アドレスのみがアクセスできるはずです。 しかしアクセス元の通信環境次第では、アクセスレベルで IP アドレスを正しく許可したと思っても、アクセスが弾かれるケースがあります。その際以下のようなエラーメッセージが出力されますが、これだけでは「VPC Service Controls によってアクセスが拒否された」という事実しか分かりません。 VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxx 原因 : IPv6 アドレスでアクセスしていた もちろん、上記エラーメッセージだけだと単に IPv4 アドレス範囲の指定が誤っていたことが原因の場合もあります。 しかし、IPv4 アドレスの指定は正しいはずなのにアクセスが拒否される場合は、Google Cloud に IPv6 アドレスで アクセスしようとしていないかを確認していただきたいです。 VPC Service Controls の IP アドレス制限では、Web API の呼び出しに用いられた接続元 IP アドレスがチェックされるので、 接続元 IP アドレスが IPv6 アドレス の場合は アクセスレベルでも IPv6 アドレスを許可 する必要があります。 普段は VPC Service Controls や VPC Firewall など、IPv4 アドレスでの CIDR 指定に慣れていたことに加え、今回の作業元である自宅のインターネット回線が IPv6 対応の契約だったことを失念していたことから気が付きにくい事象でした。 確認方法 Cloud Logging を見ることで、どの IP アドレスでアクセスしようとしていたかを確認することができます。 ログエクスプローラにて、VPC Service Controls によって弾かれたアクセスのみを取得するクエリは以下の通りです。 resource.type="audited_resource" severity="ERROR" ヒットしたログの protoPayload.requestMetadata.callerIp にアクセス元の IP アドレスが記載されています。 具体的なアドレス値をマスクしているため見づらくはなっていますが、「: (コロン)」続きの形式となっていることから IPv6 アドレスでのアクセスであることがわかります。 解消方法 上記の通り、アクセスレベルで IPv6 アドレスを許可することでアクセス可能となります。 堂原 竜希 (記事一覧) データアナリティクス準備室。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @matayuuuu

G-gen の佐々木です。当記事では Google Cloud (旧称 GCP) のサーバーレス コンピューティング プロダクトの1つである Google App Engine (GAE) を解説します。 Google App Engine (GAE) とは App Engine アプリのコンポーネント アプリケーション サービス バージョン インスタンス インフラストラクチャ 可用性 ストレージ セキュリティ 他の Google Cloud サービスへのアクセス制御 カスタムドメインの使用 上り（内向き）設定 App Engine ファイアウォール モニタリング・ロギング デプロイと実行環境 アプリケーションのデプロイ 2つの実行環境 スタンダード環境 ランタイム ランタイム環境の世代について 第1世代ランタイム（レガシーランタイム） 第2世代ランタイム ランタイムのライフサイクル スケーリングタイプ スケーリングタイプとは 動的スケーリング コールドスタート ウォームアップリクエスト インスタンスクラス VPC ネットワークへの接続 フレキシブル環境 ランタイム スケーリングタイプ マシンタイプ VPC ネットワークへの接続 その他の Computing プロダクトとの比較 Google App Engine (GAE) とは Google App Engine (GAE) は Google Cloud のプロダクトの中でも最初期から提供されている PaaS（Platform as a Service）であり、アプリケーションを稼働させるためのマネージドな実行基盤を提供するサービスです。GAE とも略されますが、当記事では以降、App Engine と記載します。 App Engine ではアプリケーションのコードと設定ファイルをデプロイするだけで、Google Cloud 上でアプリケーションを実行することができます。ユーザーが VM やコンテナといった実行基盤の運用をする必要がなく、オートスケーリングや障害発生時のオートヒーリングなどの機能が提供されます。 参考 : App Engine App Engine アプリのコンポーネント アプリケーション 当記事では、App Engine にホストしたアプリケーションのことを App Engine アプリ と呼びます。 App Engine アプリを開発するには、まずプロジェクト内に アプリケーション というリソースを作成します。App Engine はこのアプリケーションを最上位のリソースとして、サービス、バージョン、インスタンスというリソースが連なる階層型のリソース構成となっています。 App Engine のリソース構成 アプリケーションはサービス以下のリソースを束ねるだけでなく、App Engine アプリの設定、認証情報、アプリケーションのメタデータのコレクションを作成、管理することができるコンポーネントであり、それらはアプリケーション作成時に指定したリージョンに格納されます。 参考： App Engine の概要 サービス アプリケーションは最低1つの サービス リソースを持ちます。App Engine アプリを単一のサービスで実行することもできますが、複数のサービスで1つのアプリを構成することで、マイクロサービスのようにアプリの機能を分離することができます。 各サービスはアプリのソースコードとそれに対応する App Engine 構成ファイルで構成されます。サービスをデプロイするたびに、サービス内に バージョン が追加されていきます。 バージョン デプロイされたサービスは バージョン リソースとしてバージョニングされており、バージョン間で トラフィック移行 を行うことで、特定のバージョンに対してトラフィックのルーティングを素早く切り替えることができます。 また、 トラフィック分割 により複数バージョンに対してトラフィックをルーティングすることもできます。これらの機能により、App Engine アプリのテストやロールバックを容易に行うことができます。 インスタンス バージョンは1つ以上の インスタンス で実行され、負荷に応じてスケーリングすることができます。 インスタンスの実行基盤は App Engine の実行環境（後述）により異なります。スタンダード環境では Google のインフラストラクチャ上で実行されるコンテナインスタンス、フレキシブル環境ではユーザープロジェクトの VPC で起動される Compute Engine 仮想マシン上の Docker コンテナで実行されます。 後述する App Engine の 実行環境 によって、インスタンスの実行基盤は異なります。 インフラストラクチャ 可用性 App Engine はリージョナルサービスであり、App Engine アプリを実行するインフラストラクチャはユーザーが指定したリージョンに配置され、自動的にリージョン内のすべてのゾーンで冗長化されます。 参考 : App Engine のロケーション ストレージ App Engine アプリは基本的にインスタンスに状態を持たない（ステートレス）設計となるため、データは App Engine の外に保存します。 リレーショナルデータベースとして Cloud SQL、NoSQL データベースとして Firestore、オブジェクトストレージとして Cloud Storage の使用が推奨されています。 参考 : データとファイルのストレージについて また、スタンダード環境では /tmp ディレクトリに対して一時ファイルの読み書きを行うことができます。このディレクトリに保存されたファイルはすべてインスタンスのメモリに格納されます。 参考 : 一時ファイルの読み取りと書き込み セキュリティ 他の Google Cloud サービスへのアクセス制御 App Engine アプリでは、バージョン単位でサービスアカウントを設定することで、他の Google Cloud サービスのアクセス権限を付与することができます。 Compute Engine 同様、 編集者（role/editor） ロールをもつデフォルトのサービスアカウントが提供されていますが、最小権限の原則に従ったユーザー管理のサービスアカウントを使用することが推奨されています。 参考 : アクセス制御の設定（スタンダード環境）]( https://cloud.google.com/appengine/docs/standard/access-control?hl=ja&tab=go ) カスタムドメインの使用 App Engine アプリでは、デフォルトで生成される appspot.com ドメインの URL を使用することで HTTPS によるアクセスを行うことができます。 また、App Engine の機能でマネージド SSL 証明書を発行することで、HTTPS アクセスにカスタムドメインを使用することもできます。 参考 : アプリのセキュリティの概要 上り（内向き）設定 以下の3種類の 上り（内向き）設定 により、App Engine アプリへのネットワークアクセスを制限することができます。 設定名 許可するアクセス元 内部 ・同一プロジェクト内の VM ・共有 VPC ・サーバーレス VPC アクセスコネクタ（スタンダード環境） 内部と Cloud Load Balancing ・ 内部の設定で許可されているもの ・外部アプリケーションロードバランサ すべて すべて デフォルトでは、インターネット上のすべてのリソースが App Engine アプリにアクセスすることができます。 参考 : 上り（内向き）設定 App Engine ファイアウォール App Engine ファイアウォール を使用することで、App Engine アプリにリクエストを送信できる IP アドレス範囲を制限することができます。 Compute Engine のファイアウォールルールと異なり、App Engine のファイアウォールは受信トラフィック（上り/内向き）に対してのみ適用されます。 対象となる IP アドレス範囲ごとに許可/拒否のルールを作成し、ルールには優先度（1 ~ 2147483647）を設定します。デフォルトでは、すべての IP アドレスからのアクセスが許可する優先度最低（2147483647）のルールのみ登録されています。 App Engine ファイアウォールについて モニタリング・ロギング App Engine は Cloud Monitoring と統合されており、コンピューティングリソースの使用率やレスポンスのレイテンシ、実行中のインスタンス数などのメトリクスがデフォルトで提供されます。 また Cloud Logging では、App Engine のログとして以下の2種類のログを収集できます。 ログの種類 説明 リクエストログ App Engine アプリに送信されるリクエストのログ。自動で収集される。 アプリログ アプリケーションのログ。アプリで使用する言語ごとに用意された方法でログエントリを作成する必要がある。 アプリログついては、 stdout または stderr にテキスト文字列を送信するだけで Cloud Logging のログエントリを作成することができます。しかし、重要度でログをフィルタリングする必要がある場合などは ログを構造化データとしてフォーマットする 必要があります。 参考 : ログの書き込みと表示 デプロイと実行環境 アプリケーションのデプロイ App Engine では、 app.yaml という設定ファイルに実行環境やランタイム、コンピューティングリソースなどの構成（それぞれ後述）を記述し、コードと一緒にデプロイすることでアプリケーションを実行することができます。 以下は Python を使用する App Engine アプリの app.yaml ファイルの例です。使用ランタイムやインスタンスクラス、リクエストの URL パターンごとの処理方法などが記述されています。 runtime : python312 instance_class : F2 env_variables : BUCKET_NAME : "example-gcs-bucket" handlers : # Matches requests to /images/... to files in static/images/... - url : /images static_dir : static/images - url : /.* secure : always redirect_http_response_code : 301 script : auto 設定ファイルの記述内容は実行環境により異なります。詳しくは以下のドキュメントを参照してください。 参考 : App Engine app.yaml リファレンス（スタンダード環境） 参考 : app.yaml 構成ファイル（フレキシブル環境） 2つの実行環境 App Engine でアプリケーションを実行する場合、 スタンダード環境 と フレキシブル環境 のどちらかを選択します。 スタンダード環境 ではサポートされる言語の種類とバージョンに制限がある代わりに、Cloud Functions や Cloud Run のようなサーバーレスの実行基盤が利用できます。アプリケーションは gvisor ベースのコンテナインスタンスで実行され、高速なスケーリングと ゼロスケーリング （インスタンス数を0にスケールインする）によるコスト削減が大きなメリットとなります。 フレキシブル環境 では、マネージドな Compute Engine 仮想マシン上で Docker コンテナとしてアプリケーションが実行されます。スケーリングの単位が仮想マシンのため、スタンダード環境のようなスケーリングのメリットはありませんが、サポートされる言語の制限がなく構成の自由度の高さがメリットとなります。 実行基盤がサーバーレスか、Compute Engine 仮想マシンかの違いにより、実行環境ごとの機能に違いがあります。 以下の表は実行環境ごとの違いを一部抜粋したものです。 機能 スタンダード環境 フレキシブル環境 インスタンスの起動時間 秒単位 分単位 リクエストの最大タイムアウト ランタイムとスケーリングタイプ（後述）によって異なる。（ 参考 ） 自動スケーリングの場合は基本的に10分 60 分 バックグラウンドプロセス × ○ SSH 接続 × ○ ゼロスケーリング ○ × ローカルディスクへの書き込み Python 2.7、PHP 5.5 以外のランタイムで /tmp ディレクトリが利用可能 VM のエフェメラルディスクを利用可能 ランタイムの変更 × ○ デプロイ時間 秒単位 分単位 Websocket × ○ 料金 インスタンス時間 vCPU、メモリ、永続ディスクの使用量 実行環境（スタンダード/フレキシブル）はサービスごとに選択することができ、1つのアプリケーションに異なる実行環境のサービスを混在させることができます。これにより、各サービスの役割に応じて適切な実行環境を選択することができます。 参考： 環境ごとの機能比較 参考： App Engine スタンダード環境ユーザーのための App Engine フレキシブル環境 スタンダード環境 ランタイム ランタイム環境の世代について スタンダード環境ではフレキシブル環境と比較して、ランタイム環境としてサポートされている言語や API、ファイルシステムへのアクセス可否などの制限があります。 ランタイム環境には第1世代と第2世代があります。これから App Engine を利用する場合は、機能が大幅に改善されている第2世代を使用することになるでしょう。 スタンダード環境の世代間比較については以下のドキュメントを参照してください。当記事では特に指定のない限り、「スタンダード環境」と記載がある場合は第2世代を指しています。 参考： App Engine スタンダード環境のランタイム 第1世代ランタイム（レガシーランタイム） 第1世代は App Engine リリース当初から存在し、 レガシーランタイム と呼ばれます。 以下のように、ランタイムとしてサポートされている言語のバージョンが古く、それぞれの言語のコミュニティで既に管理されていないバージョンが含まれています。 Python 2.7 Java 8 PHP 5.5 Go 1.11 これらのランタイムは2024年1月31日のサポート終了がアナウンスされています。公式ドキュメントでは第 2世代ランタイムへの 移行ガイド が提供されています。 参考： レガシー ランタイムのサポート 第2世代ランタイム 第2世代ランタイムでは以下の言語がサポートされており、ベースとなる OS はすべて Ubuntu となっております。 Go Java Node.js PHP Python Ruby サポートされている言語のバージョンについては、以下のページから最新の情報を確認できます。 参考 : ランタイム サポート スケジュール ランタイムのライフサイクル ランタイムは プレビュー → 一般提供（GA） → サポート終了 → 非推奨 → 廃止 のライフサイクルを辿ります。このうち一般提供（GA）の期間において、セキュリティやバグの修正などの定期的なアップデート、仕様変更の通知（リリースノート）、テクニカルサポートの提供が行われます。 サポート終了期間に入る90日前に、Google Cloud からの通知を受け取ることになります。ランタイムのサポート終了日になってもアプリケーションは引き続き実行されますが、Google Cloud によるセキュリティのアップデートが行われず、テクニカルサポートの対象外となってします。また、サポートが終了したランタイムを使用するアプリケーションは作成、更新ができなくなります。 したがって、ランタイムのアップグレードは定期的に行うことが強く推奨されています。 非推奨の期間に入って以降も基本的にはアプリケーションをそのまま実行できますが、重大なセキュリティ脆弱性が発覚した場合など、事前の通知なしに無効化される可能性があります。 参考 : ランタイム ライフサイクル スケーリングタイプ スケーリングタイプとは スタンダード環境では3種類のスケーリングタイプが提供されており、後述のインスタンスクラスによって使用できるスケーリングタイプが異なります。 以下のように、スケーリングタイプによってリクエストのタイムアウトやスケーリング方式などが異なります。動的スケーリングについては後述します。 - 自動スケーリング 基本スケーリング 手動スケーリング リクエストのタイムアウト 10分 24時間 24時間 スケーリング 動的スケーリング 動的スケーリング 構成ファイルでインスタンス数を指定 スケーリングタイプごとの詳細な比較については以下のドキュメントを参照してください。 参考 : インスタンスの管理方法 動的スケーリング 基本スケーリングもしくは自動スケーリングを使用する場合、受信リクエストの量に応じたインスタンス数のスケーリングを自動で行うことができます。 なお、動的スケーリングの仕様は基本スケーリングと自動スケーリングで異なります。 基本スケーリングでは、受信したリクエストを処理できるインスタンスがない場合にのみ新しいインスタンスが起動します。したがって、新しいインスタンスが立ち上がるまでの間、受信したリクエストを処理できない場合があります。 自動スケーリングでは、スケーリングのトリガーとして以下の3つが使用できます。 トリガー 説明 CPU 使用率 CPU 使用率の閾値を事前に設定し、それを超えたときに新しいインスタンスを起動する。 スループット スループットの閾値を事前に設定し、それを超えたときに新しいインスタンスを起動する。 同時リクエスト数 インスタンスが処理できる最大同時リクエスト数を事前に設定し、それを超えたときに新しいインスタンスを起動する。 自動スケーリングでは基本スケーリングと異なり、CPU 使用率やスループットを基準としてスケーリングをトリガーすることで、既存のインスタンスがリクエストを処理する余地を残したまま新しいインスタンスを用意することができます。 コールドスタート App Engine では、以下のような状況でリクエストに対するレイテンシが発生する可能性があります。 スケーリングによって新たなインスタンスを起動するとき サービスの別のバージョンをデプロイしたとき 基盤となるインフラストラクチャのメンテナンスが行われるとき これは、新たに起動されたインスタンスがリクエストを処理するために、アプリケーションのコードやライブラリを事前に読み込む必要があるためです。 ウォームアップリクエスト スケーリングタイプが自動スケーリングの場合のみ、 ウォームアップリクエスト を有効化することで、App Engine がスケールアウトのタイミングを事前に検知し、インスタンスが実際に必要になる前にコードの読み込みを行うことができます。 ウォームアップリクエストを有効化するには、設定ファイル（app.yaml）への追記と、コードにウォームアップリクエストを処理するハンドラを実装しておく必要があります。詳細については以下のドキュメントを参照してください。 なお、ウォームアップリクエストは常に実行されることが保証されているわけではありません。インスタンス数が0から1になるときや、リクエスト数のスパイクがあった場合などはコールドスタートが発生してしまいます。ただし、ウォームアップリクエストが有効化されている場合は、すでに実行されているインスタンスに対してリクエストを優先的にルーティングし、コールドスタートの影響をできる限り少なくするような仕様になっています。 参考 : ウォームアップ リクエストを構成してパフォーマンスを改善する インスタンスクラス スタンダード環境の App Engine では、アプリケーションを実行するインスタンスのコンピューティングリソースを App Engine 独自の インスタンスクラス で指定します。 選択できるインスタンスクラスは以下の通りで、クラスによって使用可能なスケーリングタイプが異なります。 インスタンスクラス メモリ CPU サポートされているスケーリングタイプ F1（デフォルト） 384 MB 600 MHz 自動 F2 768 MB 1.2 GHz 自動 F4 1,536 MB 2.4 GHz 自動 F4_1G 3,072 MB 2.4 GHz 自動 B1 384 MB 600 MHz 手動、基本 B2（デフォルト） 768 MB 1.2 GHz 手動、基本 B4 1,536 MB 2.4 GHz 手動、基本 B4_1G 3,072 MB 2.4 GHz 手動、基本 B8 3,072 MB 4.8 GHz 手動、基本 参考 : App Engine スタンダード環境 | インスタンスのクラス VPC ネットワークへの接続 Cloud Run や Cloud Functions と同様に、スタンダード環境のインスタンスは VPC の外側にあり、Cloud SQL、Memorystore、Cloud NAT などの VPC リソースに対するプライベート IP を用いた接続には サーバーレス VPC アクセス の設定が必要になります。 以下の図は、VPC リソースである Cloud SQL のインスタンスに接続する場合の構成です。ユーザー VPC に作成したコネクタインスタンスを経由してプライベート IP を用いた接続を行っています。 スタンダード環境の App Engine から Cloud SQL に接続する場合の構成 コネクタインスタンスは常時起動となっており、起動時間ぶんのコストが常に発生してしまいます。したがって VPC に接続する必要があるケースでは、VPC 内に App Engine インスタンスを起動することができるフレキシブル環境の利用も検討する必要があるでしょう。 参考 : VPC ネットワークへの接続 フレキシブル環境 ランタイム フレキシブル環境では以下のランタイムがサポートされています。ベースとなる OS はスタンダード環境同様に Ubuntu ですが、設定ファイル（app.yaml）でバージョンを指定することができます。 Go Java Node.js PHP Python Ruby .NET カスタムランタイム スタンダード環境よりも使用可能ランタイムの種類が多いほか、 カスタムランタイム としてユーザが用意した Docker イメージを使用することができます。 参考 : App Engine フレキシブル環境 スケーリングタイプ フレキシブル環境では自動スケーリングと手動スケーリングの2種類のスケーリングタイプを使用することができます。 スタンダード環境と異なる点として、スケーリングのたびに Compute Engine 仮想マシンが新規に起動されるためスケーリング速度が遅く、また最低1つのインスタンスを常時起動している必要があります（ゼロスケールできない）。 マシンタイプ フレキシブル環境にはスタンダード環境のようなインスタンスクラスは存在せず、設定ファイル（app.yaml）で指定した CPU とメモリの量に基づいて Compute Engine のマシンタイプが割り当てられます。 したがって、スタンダード環境よりもコンピューティングリソースの量を細かく調整することができます。 VPC ネットワークへの接続 フレキシブル環境のインスタンスは Compute Engine 仮想マシンであり、ユーザーが作成した VPC 内で起動します。したがって スタンダード環境のようにサーバーレス VPC アクセスを設定することなく VPC リソースにプライベート IP アドレスで接続することができます。 その他の Computing プロダクトとの比較 以下の記事で、Google Cloud の Computing プロダクトの比較解説を行っています。 blog.g-gen.co.jp サーバーレスな Web アプリケーション実行基盤としては、Cloud Run と比較することが多いと思われます。 比較的新しいプロダクトであり積極的にアップデートが行われている Cloud Run と比較すると、リリースから15年以上の実績をもつ App Engine はいわゆる枯れたプロダクトであると言えます。したがって、App Engine のほうがユーザーによるナレッジの蓄積が多く、アップデートによる仕様変更に振り回されにくいプロダクトであるといえるでしょう。 また、Cloud Run はコンテナの利用が必須となるため、より手軽にアプリケーションをデプロイしたい場合の選択肢となります。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

2022年10月より提供が開始された Professional ChromeOS Administrator 試験は、管理コンソールの操作や ChromeOS の運用、管理方法を問う試験です。当記事では試験合格に役立つ内容をご紹介します。 はじめに Professional ChromeOS Administrator とは 難易度 学習方法 注意点・出題傾向 管理コンソール 管理コンソールとは ChromeOS デバイスポリシーとユーザーポリシー デバイスの登録 手動登録 ゼロタッチ登録 ワイプしたデバイスの再登録 運用・管理 OS のアップデート 自動更新 リリースチャンネル ライセンス シングルサインオン (SSO) セキュリティ ドメインの所有権 確認済みブート 新機能のリクエスト はじめに Professional ChromeOS Administrator とは Professional ChromeOS Administrator 試験は、Google の提供するコラボレーションツールである Google Workspace や ChromeOS デバイスの管理者向けの試験です。Google Workspace 管理コンソールの操作や ChromeOS の運用、管理方法が問われます。 当試験は Google Cloud の公式ブログ で紹介されているものの、 Google Cloud 認定試験一覧 には記載されていません。 試験申込時に Google Cloud 認定試験とは別のアカウントが必要です。 当試験は英語と日本語で受験できます。問題数は 50 問で、試験時間は 120 分です。試験の提供開始当初はハンズオンラボも含まれていましたが、2023年11月現在はハンズオンラボが廃止され、Google Cloud 認定試験と同様に複数選択式となっています。 当試験は 2024年1月まで無料で受験可能であり、それまでの間は受験費用125ドルを Google が負担するとされています。 参考 : Professional ChromeOS Administrator 難易度 当試験の難易度は 中程度 と言えます。 前提知識として、IPA の IT パスポート試験程度の IT 基礎知識に加え、PC や OS に関する基礎知識があると良いでしょう。 既に Professional Google Workspace Administrator を取得している人や、日常的に管理コンソールを触っている人、Chrome OS に関わらず情報システム部門などで PC 管理をしている人であれば、当記事を参考に知識をアドオンしていけば、合格は難しくありません。 学習方法 おすすめの学習方法は、以下です。 公式の 試験ガイド に掲載されている動画とドキュメントを確認する 試験範囲の中で理解できない内容や知らない単語を無くす 実際に管理コンソールを触る 管理画面をある程度自由に触れるのが理想的 自由に変更できない環境の場合は、閲覧権限だけでも手に入れ、各種設定画面を確認する 当記事を読んで知らない範囲を無くす 注意点・出題傾向 当試験の注意点として以下のようなものがあります。 日本語版試験は、英語版試験を翻訳したものですので、若干の違和感を感じる文章もあります。特に公式ドキュメントやコンソールの日本語訳と、試験の日本語訳が違う場合もあります 管理コンソールにおける細かい操作 (設定箇所) を問われる場合があります 出題傾向は、基本的には試験ガイドに沿うものになりますが、当記事ではより詳細に記載しますので、学習の参考にしてください。 当記事ではこれ以降、試験の出題傾向をジャンルごとに提示します。 管理コンソール 管理コンソールとは 管理コンソール とは、 Google Workspace サービスのユーザー追加や削除、デバイスの管理設定を行う画面です。 管理コンソールにログインするには管理者ロールが必要です。そのため既定の管理者ロールもしくはカスタム管理者ロールを作成し、システム管理者に付与します。 参考 : 管理コンソールについて ChromeOS デバイスポリシーとユーザーポリシー ChromeOS デバイスには、 デバイスポリシー と ユーザーポリシー を適用できます。 デバイスポリシーは、管理対象の ChromeOS デバイスに対して適用されます。そのため、ChromeOS デバイスにログインするユーザーアカウントの種類 (会社アカウントや個人 Gmail アカウント、ゲストなど) に関わらず適用されます。 それに対してユーザーポリシーは、Google アカウントに対しての適用となります。 これは Active Directory のグループポリシーで、ユーザーとコンピューターに対するポリシーの違いに似ています。 両者の違いと管理コンソールでの設定方法を押さえておきましょう。 また、これらのポリシーを使ってリモート管理するには、Chrome Enterprise Upgrade または Chrome Education Upgrade ライセンスが必要です。 参考 : Chrome ポリシー管理の概要 参考 : 概要: ChromeOS デバイスのポリシーの管理 参考 : ユーザーまたはブラウザに Chrome のポリシーを設定する デバイスで有効になっているポリシーは、管理対象デバイスで chrome://policy にアクセスすることで確認できます。 参考 : デバイスの現在の Chrome ポリシーを表示する デバイスの登録 手動登録 ポリシーを適用するには、ChromeOS デバイスを管理対象とする必要があります。ChromeOS デバイスを管理下とするには、「手動」または「自動」で ChromeOS デバイスを登録します。 それぞれの登録方法について押さえておきましょう。 参考 : 端末の登録と消去 ゼロタッチ登録 ゼロタッチ登録 とは、ChromeOS デバイスにメーカーや販売業者などが顧客ドメインを自動設定するサービスです。 通常、会社用端末として ChromeOS デバイスを使う場合にポリシーを適用するには、管理コンソールからデバイスを手動で登録する必要があります。しかしゼロタッチ登録を使うことで、システム管理者は大量のデバイスを手動で登録する必要がなくなります。利用者がデバイスをインターネットに接続すると、デバイスはドメインに自動登録されます。 この時、システム管理者がメーカーや販売業者に提供する情報や事前プロビジョニングトークンの生成方法を押さえておきましょう。 参考 : ゼロタッチ登録 ワイプしたデバイスの再登録 デバイスを出荷時の状態に戻すことを ワイプ と言います。 ChromeOS では、管理対象のデバイスを管理コンソールからワイプできます。これによってデバイスが紛失や盗難にあった場合に、データの悪用を防げます。 参考 : ChromeOS デバイスのデータをワイプする ワイプした ChromeOS デバイスは、デフォルトでは自動的に再登録されます。 参考 : ワイプした ChromeOS デバイスを自動的に再登録する 運用・管理 OS のアップデート 自動更新 ChromeOS は特定の周期でアップデートがリリースされます。アップデートにはセキュリティ修正も含まれているため、定期的にアップデートを適用する必要があります。手動での適用では、適用漏れも出てきてしまうため、 自動更新 が推奨されます。 参考 : ChromeOS デバイスの更新を管理する 自動更新がされない場合のトラブルシューティング方法も把握しておきましょう。 参考 : ChromeOS のバージョンが自動更新されない リリースチャンネル リリースチャンネル を設定することで、どのアップデートを展開するか制御できます。リリースチャンネルには以下の 5 つがあります。 Stable 長期サポート (LTS) 長期サポート候補 (LTC) Beta Dev 特に Stable と長期サポート (LTS) チャンネルのユースケースや展開時のベストプラクティスについて、以下のようなドキュメントを押さえておきましょう。 参考 : ChromeOS デバイスの更新を管理する 参考 : Chrome OS リリースのおすすめの使用方法 ライセンス 前述の通り、ChromeOS デバイスをリモート管理するには Chrome Enterprise Upgrade または Chrome Education Upgrade ライセンスが必要です。 ライセンスの割り当て状況の確認方法を押さえておきましょう。 参考 : Chrome のアップグレードを使用する シングルサインオン (SSO) Chrome アプリで SAML (Security Assertion Markup Language) シングルサインオン (SSO) を設定するには、 SAML SSO for Chrome Apps 拡張機能を使います。 この時、ユーザー情報である Cookie は許可リストに登録されたドメインにのみ渡されます。 参考 : Chrome アプリに SAML シングル サインオンを設定する 参考 : ChromeOS デバイスのポリシーを設定する > シングル サインオン Cookie の動作 セキュリティ ドメインの所有権 取得したドメインが第三者に利用されないようにするために、 ドメインの所有権を証明 する必要があります。Google Workspace を利用開始するには、ドメインの証明が必須です。 ドメインの所有権の証明方法、また DNS 設定時に TXT レコードが必要 な点を押さえておきましょう。 参考 : ドメインの所有権を証明して、さらに多くの機能を利用できるようにする（メール確認によるアカウント用） 参考 : ドメインの所有権を TXT レコードで証明する 確認済みブート ChromeOS は起動時に 確認済みブート (確認付きブート / Verified boot) と呼ばれるセルフチェックが行われます。この機能によってシステムの改ざんや破損が検出された場合、自動修復されます。 英語のドキュメントではありますが、以下のドキュメントを一読しておきましょう。 参考 : Verified Boot in Chrome OS and how to make it work for you 新機能のリクエスト Chrome Enterprise Trusted Tester に登録すると、Chrome の新機能のテストと Google のプロダクトチームへ直接フィードバックすることができます。 参考 : Chrome Enterprise Trusted Tester になる G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の佐々木です。当記事では、Cloud Run などのサーバーレス サービスが VPC リソースにプライベート IP で接続するために使用する サーバーレス VPC アクセス のスケールインをダウンタイムなしで行う方法を解説します。 サーバーレス VPC アクセスとは コネクタインスタンスのスケールイン問題 問題 再作成を安全に行う方法 手順 前提条件 新コネクタインスタンスの作成 使用するコネクタインスタンスの切り替え 旧コネクタインスタンスの削除 サーバーレス VPC アクセスとは サーバーレス VPC アクセスとは、Cloud Run、Cloud Functions などのサーバーレスなサービスがプライベート IP を使用して Cloud NAT や Cloud SQL、Memorystore などの VPC リソースに接続するための機能です。 サーバーレス VPC アクセスでは、接続先となる VPC 内のサブネット、もしくは専用に確保した IP アドレス範囲を使用して VPC 内に サーバーレス VPC アクセスコネクタ と呼ばれるインスタンス（以下、 コネクタインスタンス ）を作成します。 VPC の外にあるサーバーレスサービスは、このコネクタインスタンスを経由することで VPC 内リソースにプライベート IP アドレスで接続できるようになります。 参考： Serverless VPC Access サーバーレスVPCアクセスコネクタを使用したVPCリソースへの接続例 コネクタインスタンスのスケールイン問題 問題 サーバーレス VPC アクセスでは、VPC に接続するために作成するコネクタインスタンスの最小数（2~9）と最大数（3~10）をあらかじめ設定します。コンテナインスタンスの負荷が高まると、最大で設定した値までインスタンスがスケールアウトします。 このスケーリングの仕様として、一度スケールアウトしたインスタンス数は 二度とスケールインすることがありません 。 サーバーレス VPC アクセスの料金はコネクタインスタンスの数に比例して増加するため、一度のスパイクでスケールアウトしただけであっても、スケールアウト後のコストがずっと発生してしまうことになります。 コスト節約のため一度スケールアウトしたコネクタインスタンスを減らしたい場合、コネクタインスタンスを 再作成 する必要があります。 再作成を安全に行う方法 コネクタインスタンスを減らすためには一度削除してから再作成が必要ですが、コネクタインスタンスを一度削除すると、アプリケーションから Cloud SQL などへの接続は一時的にできなくなってしまいます。 この接続断の影響を最小限に抑えるためには、以下のような手順を踏みます。 旧コネクタインスタンスを残したまま新コネクタインスタンスを作成 接続元のサービス側設定において使用するコネクタインスタンスを新コネクタインスタンスに切り替え 旧コネクタインスタンスを削除 コネクタインスタンスはサブネット、もしくは IP アドレス範囲に紐づくリソースであり、VPC 内には複数のコネクタインスタンスを作成することができます（アドレス重複は不可）。これを利用して、サービスがコネクタインスタンスを使用できない時間が発生しないようにします。 手順 前提条件 当記事では、Cloud Run からコネクタインスタンスを経由して Cloud SQL に接続しているケースを例として使用します。 初期状態として、以下の図のようにコネクタインスタンスがスケールアウトした後の状況を想定します。 コネクタインスタンスがスケールアウトした後の状態 新コネクタインスタンスの作成 既存のコネクタインスタンスを残したまま 、任意のインスタンス数を設定したコネクタインスタンスを新規に作成します。 新規作成するために、コネクタインスタンス用のサブネット、もしくは IP アドレス範囲を新たに確保する必要があります。 コネクタインスタンスを新規作成する 使用するコネクタインスタンスの切り替え 接続元のサービス側でサーバーレス VPC アクセスの設定を修正します。 Cloud Run の場合はリビジョン機能を使用して、新規作成したコネクタインスタンスを使用するように設定し直した新しいリビジョンをデプロイします。 使用するコネクタインスタンスを切り替える 旧コネクタインスタンスの削除 最後に、無駄なインスタンス料金が発生しないように、古いコネクタインスタンスを削除します。 注意点として、 使用中のコネクタインスタンスも削除できてしまいます。 現在使用されているほうを削除してしまい、接続断が発生してしまうといったことが起こらないように気をつけましょう。 古いコネクタインスタンスを削除する 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。 Follow @sasashun0805

G-genの田中です。当記事では、Cloud Storage を利用する中で、意図していない高額の請求が発生してしまった事例について解説していきます。 はじめに 背景 Cloud Storage とは Cloud Storage の料金 Storage Transfer Service とは 事件のあらまし 背景 落とし穴 莫大な課金の発生 後日譚 はじめに 背景 今回、G-gen でサポートさせて頂いているお客様が Storage Transfer Service を利用して Cloud Storage へデータ移行を行ったところ、 3日間で数十万円の課金が発生してしまった という事件があり、注意喚起のために記事化させて頂くことになりました。 本記事は、お客様名の許諾を得た上で、実際に起きた内容を少し改変して記事化しました。お客様の社内事情のため数値等を事実とは違うものにして記載していますが、記事の目的に沿うように、重要なエッセンスには影響しないよう改変してあります。 Cloud Storage とは Cloud Storage とは Google Cloud (旧称 GCP) の容量無制限・低価格・堅牢なオブジェクトストレージサービスです。Google Cloud Storage を略して GCS と呼ばれることもあります。 データは少なくとも 2 つ以上のゾーンで冗長化され 99.999999999%（イレブンナイン）の堅牢性を誇ります。詳細は以下の記事もご参照ください。 blog.g-gen.co.jp Cloud Storage の料金 Cloud Storage は、安価であることが特徴です。東京リージョンの Standard Storage のデータ保管料金は2023年11月現在で $0.023 (GB/月) です。ドル・円レートにもよりますが概ね 1 TB で3,000円〜3,500円程度と認識すれば良いでしょう。 ただし Cloud Storage の料金はデータ保管ボリュームだけでなく、API リクエスト回数など、複数の軸で課金されます。 最新の料金は以下の料金ページをご参照ください。 参考 : Cloud Storage の料金 Storage Transfer Service とは Storage Transfer Service は Google Cloud サービスの1つで、異なるストレージ間で自動的にデータを移行するためのツールです。 オンプレミスのデータセンター、他のクラウドプロバイダー等の異なるデータソースから、高い信頼性で迅速に Cloud Storage へデータを移行できます。 参考 : Storage Transfer Service とは 事件のあらまし 背景 本来実施したかったことは「 Google Drive 内の約 6TB のファイルを Cloud Storage にバックアップ したい」ということでした。 お客様は、当初は「データ量が 6TB なので、2万円程度のデータ容量課金が発生する程度だろう」と試算し、本作業を実施しました。 落とし穴 このバックアップ作業には、大きな落とし穴がありました。 それは ファイル数 です。これを課金体系の観点から正しい言い方をすると「 API コール数 」です。 前述の通り Cloud Storage ではデータサイズの他に、データの読み込みや書き込みといった API コールの数に応じて課金されます。今回のような作業では Storage Transfer Service が Cloud Storage にデータを書き込むため、その際に API コールと課金が発生します。 参考 : Cloud Storage の料金 - オペレーション料金 参考 : Storage Transfer Service の料金 - ファイル システム転送の料金の詳細 莫大な課金の発生 あとで分かったことですが、今回の件では Google Drive の中に1ファイルあたり数バイトのログファイルが 約8億個 ありました。 ファイルサイズは約 6TB のためデータ保管料金は当初見積もった通り「2万円程度」でしたが、約8億個のファイルを書き込むために約8億回の Cloud Storage API 書き込みオペレーション料金が発生してしまいました。 Standard Storarge への書き込みは、1,000回あたり$0.005です（Archive Storage への書き込み等であれば、さらに高価になります）。8億回であれば $4,000（約580,000円）となります。これが、課金の原因でした。 後日譚 後日お話をお伺いした所、この作業を行った担当者様は入社2ヶ月ほどで、前任担当者からは膨大なファイルサイズについては引き継ぎを受けていませんでした。データサイズから想像できないファイル数が存在したことが、この事案を引き起こしたと言えます。 Cloud Storage の利用料金はデータ保管ボリュームだけでなく、API リクエストの回数による課金も発生することを念頭に置いて利用することが大切だと、改めて実感する事例となりました。 田中 祐平 (記事一覧) ビジネス推進部 営業1課 2022年8月よりG-gen にジョイン。 大手製造の販売会社から、Google専業の営業へ。広島県在住でGoogle Workspaceをメインに活動中。週末はキャンプで山に籠もってます。

G-gen の堂原です。本記事では Google Cloud (旧称 GCP) の生成 AI サービスである Vertex AI Search の活用事例 として、技術サポート窓口支援ツールを紹介します。 はじめに 本ツールの概要 デモ 処理フロー 技術的ポイント Vertex AI text-bison model Vertex AI Search 生成 AI アプリケーションの開発 はじめに 当記事では、G-gen の技術サポート窓口にて実際に運用されている生成 AI アプリケーションである Tech Support Powered by Generative AI （以降、「本ツール」）について解説します。 G-gen では Google Cloud および Google Workspace の 請求代行サービス を契約いただいているお客様に、無償の技術サポート窓口を提供しています。この窓口では、Google Form にて問い合わせが投稿されると担当エンジニアが調査・検証を行い、メールで回答しています。 過去のケースにおけるメールのやりとりは蓄積されていますが、これまでは担当エンジニアが類似したケースを都度、手で検索して利用していました。そこで G-gen では生成 AI を活用して過去ケースや公式ドキュメント、G-gen Tech Blog からの情報抽出を効率的に行う本ツールを開発しました。本ツールについてはプレスリリースも公開しております。 g-gen.co.jp 本ツールの概要 本ツールは、お客様より Google Form で問い合わせが投稿されると「その問い合わせに類似する過去ケース」「関連する公式ドキュメント」「G-gen Tech Blog 記事」から検索を行い、関連情報を取得します。 検索後は Vertex AI Search により要約文の生成が行われ、最終的に Slack にメッセージとして投稿されます。 デモ 以下は本ツールのデモ動画です。 youtu.be 技術サポート用の Google Form から問い合わせが投稿されると、本ツールは「お問い合わせ内容詳細」に記載された文章に対して処理を行います。動画内では以下のような問い合わせを行っています。 Compute Engine から Cloud Storage のファイルにアクセスしたいです。 社内システムの開発がストップしており困っております。 試しに gsutil でバケットの一覧を 検索してみたのですが、 403 Permission 'storage.objects.list' denied on resource (or it may not exist) とエラーになってしまいます。 また、 gsutil で特定のオブジェクトをダウンロードする方法もご教授ください 上記の質問文は、質問内容と直接関係のない「困っております」といった文言や、文章の途中での改行など、機械的な検索の支障になりえる要素が含まれています。 フォーム投稿後、約 30 秒ほどで Slack に bot によるメッセージが投稿されます。 この際、先程の問い合わせ文章が 質問 と エラーメッセージ に分解されます。動画内では 2 つの質問と 1 つエラーメッセージが出力されています。 質問 Compute Engine から Cloud Storage のファイルにアクセスしたい gsutil で特定のオブジェクトをダウンロードする方法 エラーメッセージ 403 Permission 'storage.objects.list' denied on resource (or it may not exist) 最後に各質問とエラーメッセージについて 回答 (Vertex AI Search による要約文) 、 関連リンク および 類似過去ケース が出力されています。 処理フロー 本ツールでは、次のようなフローで処理が進められます。 フォーム投稿をトリガーとして Google Apps Script (GAS) が起動し Cloud Functions を呼び出す Vertex AI text-bison model を用いて、問い合わせ文章から質問とエラーメッセージを切り出す Vertex AI Search を用いてウェブサイト (公式ドキュメント、G-gen Tech Blog) および過去ケース (Cloud Storage に格納されたテキストファイル) の検索を行い、要約文の生成を行う Slack にメッセージとして出力する 技術的ポイント Vertex AI text-bison model 本ツールでは、 Vertex AI text-bison model による質問およびエラーメッセージの切り出しが行われています。 これは、問い合わせ文章そのままでは Vertex AI Search で十分な検索結果が得られないためです。 text-bison を用いることで、エラー解決には必要のない文や文章中の改行等がうまく処理され、必要な部分のみを綺麗に抽出することができます。 プロンプト設計においては Few-shot prompting を用いることで出力イメージのチューニングを行っています。 Vertex AI Search ウェブサイトや過去ケースからの検索と回答文の生成には Vertex AI Search を用いています。 Vertex AI Search の最大の強みは プロンプト設計やモデルチューニングが必要ない ことです。 過去ケースの検索は、テキストファイルを Cloud Storage にアップロードして非構造データのデータストアとしてを指定するだけで実装できます。この際、何かしらの制約に従ってテキストファイルを整形する等の前処理も必要ありません。 Vertex AI Search については、以下の記事で徹底解説していますのでご参照ください。 blog.g-gen.co.jp 生成 AI アプリケーションの開発 もし自組織で生成 AI アプリケーションの開発を検討中なら、G-gen 社の Generative AI 活用支援ソリューションをご検討ください。 プロフェッショナルが、貴社の生成 AI 活用を支援します。詳細は以下からお問い合わせください。 g-gen.co.jp 堂原 竜希 (記事一覧) クラウドソリューション部データアナリティクス課。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @ryu_dohara

G-gen の杉村です。2023/11/15から2023/11/16までの二日間、東京ビッグサイトにて4年ぶりの現地開催となる Google Cloud Next Tokyo '23 が開催されました。当記事ではその発表内容についてレポートします。 開催場所 展示内容 一日目 基調講演（キーノート） 二日目 基調講演（キーノート） Vertex AI におけるグラウンディング G-gen スポンサーセッション 動画の公開 開催場所 Google Cloud Next Tokyo '23 は4年ぶりの東京ビッグサイトにおける現地開催となりました。 展示内容 Google Cloud がホストする基調講演（キーノート）、ジャンルごとに分類されたブレイクアウトセッションをはじめ、G-gen も登壇したスポンサーセッションなど、多くの発表がされました。 また協賛企業が展示ブースを出展するスポンサーブース、Google Cloud の操作を体験できるハンズオンセッション、エンジニアのための Innovators Hive などの展示が行われました。 当社 G-gen も「G-gen Tech Booth」と称して出典しており、お客様をお呼びしたブース内セッションを行うなどして賑わいました。 基調講演会場 ブレイクアウトセッションルーム スポンサーブース Innovators Hive G-gen Tech Booth 一日目 基調講演（キーノート） 2023/11/15 (水) の朝10:00、Google Cloud Next Tokyo '23 は基調講演（キーノート）から始まりました。 同講演では、Google Cloud Japan の代表である平手 智行氏が、 AI First である従来からの姿勢を再度、強調しました。 ユーザーとして中外製薬株式会社 志済 聡子 氏が、同社での Google Cloud や生成 AI の利用事例に加え、医療機関向けの生成 AI モデルである Med-PaLM 2 を活用することなどを発表しました。また株式会社ZOZO 風間 昭男 氏が登壇し、ファッションコーディネートの紹介文等における生成 AI の活用について語りました。 技術的な目新しい発表内容としては、以下のようなものがありました。 Duet AI in Google Workspace 日本語対応（2024年を予定） Generative AI support on Vertex AI でグラウンディングが可能になる PaLM 2 各種モデルでファインチューニング方法の拡張 Duet AI in Google Workspace は既に英語版では GA（一般提供）されているサービスです。Google Workspace による人間の業務を生成 AI が補助するサービスです。通常の Google Workspace ライセンスとは別のアドオンライセンスとして提供されます。この Duet AI in Google Workspace の日本語対応が、2024年に予定されていることが発表されました。 また Generative AI support on Vertex AI におけるグラウンディング機能 の公開予定もデモを交えて発表されました。グラウンディングとは、生成 AI が事実と異なる結果を生成してしまう「ハルシネーション」を抑制するために、Web サイトやドキュメント類を引用して生成結果を補強する技術です。今回発表されたのは、Vertex AI 経由の PaLM 2 等生成 AI モデルの利用の際、Vertex AI Search に登録済みのデータストアを利用してグラウンディングを行うことができるようになります。Vertex AI Search は生成 AI を利用した検索機能を提供するサービスであり、既に GA されています。 PaLM 2 各種モデルでファインチューニング方法の拡張としては、少量のサンプルや人のフィードバックによる精度向上を可能にする機能の公開予定が発表されました。 二日目 基調講演（キーノート） 二日目のキーノートでは、Borg、Colossus といった Google の基盤技術について再確認するとともに、開発にフォーカスした発表がされました。 ユーザー事例として、株式会社カプコンの井上 真一 氏、北國フィナンシャルホールディングスの杖村 修司 氏、株式会社 TBSテレビの山本 善尚 氏、株式会社Luupの岡田 直道 氏らが登壇し、各社の Google Cloud や Google Workspace の活用事例が語られました。 2023年8月のGoogle Cloud Next in San Francisco でも発表された Duet AI in Google Cloud のデモも行われました。自然言語での指示に応じて自動的に BigQuery へのクエリが生成され、Looker Studio でデータが可視化される様子が実演されました。 Vertex AI におけるグラウンディング ここまで見たように、Google Cloud Next Tokyo '23 の基調講演の発表内容は概ね、これまで既に発表されている内容の再確認でした。 しかし生成 AI に関しては、一日目の基調講演で Generative AI support on Vertex AI に関するデモで新機能が実演されました。 同デモでは Vertex AI の生成 AI 開発のための Web UI である Generative AI Studio から Vertex AI Search の「データストア」をグラウンディング先として指定し、その情報に基づいてテキストが生成される様子が実演されました。 Vertex AI Search については以下の記事もご参照ください。 blog.g-gen.co.jp これは現在提供されていない新機能であり、公開されれば PaLM 2 API での生成時に、LangChain 等のフレームワークや独自実装を用いずに容易にグラウンディングを実装できるようになると考えられます。 具体的な機能の詳細や公開時期については発表されませんでしたが、進化する Google Cloud の生成 AI 関連機能の一端が垣間見えるものとなりました。 G-gen スポンサーセッション G-gen の CTO 杉村はセッション「11 冠エンジニアを輩出した組織とは？チーム立ち上げのための 6 つのキーポイント」で登壇しました。 G-gen が設立された2021年9月から2023年11月までに、Google Cloud 認定資格を11個コンプリートしたエンジニアを8人、Partner Top Engineer を9人輩出したエンジニア組織文化などについて紹介しました。 動画の公開 基調講演のアーカイブ動画は、以下の公式サイトから視聴可能です。 G-gen の CTO 杉村が登壇したセッション「11 冠エンジニアを輩出した組織とは？チーム立ち上げのための 6 つのキーポイント」を含む、その他のセッション動画は 12 月中旬に公開が予定されています。 cloudonair.withgoogle.com 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

当記事では、LangChain と Vertex AI Search で Google Cloud 公式ドキュメントから回答を生成する LLM を構築してみたいと思います。 はじめに Vertex AI Search and Conversation とは LangChain とは 今回の構成 環境構築 API の有効化 Vertex AI Search データストア アプリ 実行環境 初期設定 ライブラリインストール ユーティリティ関数 モデルの初期化 Vertex AI Search 関数 テキスト分割関数 RAG を実行する関数 実行 はじめに Vertex AI Search and Conversation とは Vertex AI Search and Conversation とは、Google の生成 AI 技術を簡単に利用するためのフルマネージドの Google Cloud プロダクトであり、インフラの構築・運用を意識する必要がなく、API 経由で自社の Web サイトやアプリから呼び出して利用します。 今回は Vertex AI Search and Conversation の「Vertex AI Search」を使って、Google Cloud の公式ドキュメント (Web サイト) を検索対象として検索を実装します。 Vertex AI Search and Conversation の詳細については、以下の記事をご参照ください。 blog.g-gen.co.jp LangChain とは LangChain とは、LLM を用いてアプリケーションを効率よく開発するためのフレームワークです。 今回は、LangChain を用いてテキスト分割を行ったり、ベクトルデータベースの構築とベクトル検索の実装などを行っていきます。 LangChain の詳細については、以下の記事をご参照ください。 blog.g-gen.co.jp 今回の構成 Web サイト検索結果の要約を行いたい場合、Vertex AI Search の「 Web サイト検索の検索要約 」という機能を使うことで Web サイト検索結果の要約が可能となります。 しかし、この機能を利用するためには Advanced website indexing というオプションを有効にする必要があり、この Advanced website indexing の有効には、その Web サイトのドメインに対する ドメイン所有権を確認 する必要があります。 つまり、自社の管理するドメインでサイトを運営していればいいが、Google Cloud 公式ドキュメント ( https://cloud.google.com/* ) などの外部 Web サイトでは通常このオプションを有効にできないため、Web サイト検索の検索要約機能を使うことができません。 そこで今回は、以下の構成で Google Cloud 公式ドキュメントを要約するアーキテクチャを実装してみたいと思います。 ユーザーの質問に対し類似する公式ドキュメントを上位 3 件抽出 1000 文字以下の Chank に分割 ユーザーの質問に対し類似する Chank を上位 3 件抽出 LLM で要約回答を生成 このアーキテクチャのポイントは、以下 2 点です。 LLM で要約を求める際の入力トークン制限に引っかからないように、最大 3,000 文字 (3 つの Chaink の最大文字数) の入力とした 分割した Chank に対しても再度ベクトル検索を行い、ユーザーの質問と類似しているテキストを部分的に抽出する 構成図 環境構築 API の有効化 対象プロジェクトで以下の API を有効化します。 discoveryengine.googleapis.com aiplatform.googleapis.com dataform.googleapis.com compute.googleapis.com Vertex AI Search データストア Web コンソールで [Vertex AI Search and Convasation] > [データストア] > [新しいデータストアを作成] から、以下のパラメータを設定してデータストアを作成します。 ソース [ウェブサイトの URL]を選択 データ [ウェブサイトの高度なインデックス登録]を "オフ" [インデックス登録する URL を指定] で cloud.google.com/* を入力 構成 [データストア名] に任意の名前を入力し "作成" を押下 作成後コンソール画面（データストア） アプリ Web コンソールで [Vertex AI Search and Convasation] > [アプリ] > [新しいアプリを作成] から、以下のパラメータを設定してアプリを作成します。 種類 [検索] を選択 構成 [Enterprise エディションの機能] を "オン" [アプリ名] は任意のアプリ名 [会社名] は任意の会社名 [アプリのロケーション] は "global" データ ${先ほど作成したデータストア} を選択して "作成" を押下 作成後コンソール画面（アプリ） 実行環境 当記事では、 Colab Enterprise の Notebook 上で Python を実行します。Colab Enterprise は、マネージドな Notebook のためインフラストラクチャを管理せず実装に注力できます。 Colab Enterprise の Notebook 作成方法は公式ドキュメントのクイックスタートをご参考下さい。 cloud.google.com 初期設定 ライブラリインストール Notebook が立ち上がり、ランタイムと接続できましたら以下のコードを実行してライブラリのインストールを行います。 # input:[1] !pip install google-cloud-discoveryengine langchain faiss-cpu ライブラリのインストールができたら、ランタイムを再起動してから以下を実行します。 # input:[2] import time from typing import List import vertexai from google.cloud import aiplatform from google.cloud.discoveryengine import SearchServiceClient, SearchRequest from google.protobuf.json_format import MessageToDict from pydantic import BaseModel from langchain.llms import VertexAI from langchain.embeddings import VertexAIEmbeddings from langchain.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.document_loaders import WebBaseLoader from langchain.vectorstores import FAISS ユーティリティ関数 Vertex AI Embedding API for Text で使用するユーティリティ関数を定義します。 # input: [3] # レート制限 def rate_limit (max_per_minute): period = 60 / max_per_minute print ( "Waiting" ) while True : before = time.time() yield after = time.time() elapsed = after - before sleep_time = max ( 0 , period - elapsed) if sleep_time > 0 : print ( "." , end= "" ) time.sleep(sleep_time) class CustomVertexAIEmbeddings (VertexAIEmbeddings, BaseModel): requests_per_minute: int num_instances_per_batch: int # Overriding embed_documents method def embed_documents (self, texts: List[ str ]): limiter = rate_limit(self.requests_per_minute) results = [] docs = list (texts) while docs: # Working in batches because the API accepts maximum 5 # documents per request to get embeddings head, docs = ( docs[: self.num_instances_per_batch], docs[self.num_instances_per_batch :], ) chunk = self.client.get_embeddings(head) results.extend(chunk) next (limiter) return [r.values for r in results] モデルの初期化 モデルの初期化を行います。 # input: [4] # LLM model llm = VertexAI( model_name= "text-bison@001" , max_output_tokens= 1024 , temperature= 0.1 , top_p= 0.8 , top_k= 40 , verbose= True , ) # Embedding model EMBEDDING_QPM = 100 EMBEDDING_NUM_BATCH = 5 embeddings = CustomVertexAIEmbeddings( requests_per_minute=EMBEDDING_QPM, num_instances_per_batch=EMBEDDING_NUM_BATCH, ) Vertex AI Search 関数 プロジェクト ID と Vertex AI Search のデータストア ID を置き換えて以下を実行してください。 # input: [5] PROJECT_ID = ${プロジェクト ID} DATA_STORE_WEB = ${データストア ID} discov_client = SearchServiceClient() # Enterprise Search（Website）で各質問内容に関連する Web ページを検索 def search_questions_web (question: str ) -> dict : # 重要なキーワードを抽出 template = f "次の文から主要なキーワードやフレーズのみを抜き出してください: {question}" keyword = llm(template) serving_config = discov_client.serving_config_path( project=PROJECT_ID, location= 'global' , data_store=DATA_STORE_WEB, serving_config= 'default_config' ) # 検索の実行 results = discov_client.search( SearchRequest( serving_config=serving_config, query=keyword, page_size= 3 ) ) documents = [] # Web 検索の結果が 0 件だった場合の処理 if not results.results: print (f "0 search results" ) return else : for r in results.results: document_info = {} r_dct = MessageToDict(r._pb) document_info[ 'title' ] = r_dct[ 'document' ][ 'derivedStructData' ][ 'title' ] document_info[ 'link' ] = r_dct[ 'document' ][ 'derivedStructData' ][ 'link' ] documents.append(document_info) responses = { "question" : question, "keyword" : keyword, "answer" : documents } return responses 今回は、Vertex AI Search のクエリに、ユーザーの質問 (question) を直接入力させず、重要なキーワードのみを検索対象としました。 「重要なキーワードのみを検索対象とする」とはどのようなことかというと、以下に例と実行結果を記載します。 [原文] 「 BigQuery で行レベルセキュリティを実装する方法を教えてください 」の検索結果は以下のとおりです。 よくある質問 | Datastream | Google Cloud 料金 | BigQuery: クラウド データ ウェアハウス | Google Cloud リソースへのラベルの追加 | BigQuery | Google Cloud [重要なキーワードのみ] 「 BigQuery, 行レベルセキュリティ, 実装 」の検索結果は以下のとおりです。 BigQuery の行レベルのセキュリティの概要 | Google Cloud BigQuery の行レベルのセキュリティにより、データへのアクセスの ... BigQuery の行レベルのセキュリティに関するベスト プラクティス ... 重要なキーワードのみで検索した方が欲しい検索結果を得られているため、今回はこちらの方法で実装します。 参考： Python Client for Discovery Engine API テキスト分割関数 # input: [6] def text_split_func (search_res: dict ) -> list : text_li = [] for answer in search_res[ "answer" ]: url = answer[ "link" ] # web ページからテキストを取得 loader = WebBaseLoader(url) documents = loader.load() # テキスト分割してリストに格納 text_splitter = RecursiveCharacterTextSplitter(chunk_size= 1000 , chunk_overlap= 200 ) text_li.extend(text_splitter.split_documents(documents)) return text_li RecursiveCharacterTextSplitter を用いて、Vertex AI Search の検索結果で得られた Google Cloud 公式ドキュメントの本文を、1,000 文字 (オーバーラップ 200 文字) ずつの Chank (テキスト) に分割を行います。 RAG を実行する関数 # input: [7] def rag (question: str , text_li: list ) -> list : # 分割したテキストをエンベディングしてベクトルデータベースに保存 db = FAISS.from_documents(text_li, VertexAIEmbeddings()) # question に対し類似したテキストをベクター検索して上位 3 つのテキストを取得 docs = db.similarity_search(question, 3 ) # 上位 3 つのテキストを結合 facts = " \n " .join([doc.page_content for doc in docs]) # 次のquestionに対して、factsに基づいてanswerを生成してください。 final_prompt = f """ 次の質問については、事実に基づいて回答を作成してください。 質問: {question} 事実: {facts} 回答: """ print ( "LLM Output:" ) print (llm(final_prompt)) print ( "Reference URL:" ) print (search_res[ 'answer' ]) ベクトルベータベースには、 FAISS を用いて、LangChain で操作します。 from_documents メソッドでテキスト分割したリストを、Vertex AI Embedding API を用いてエンべディングしベクトルデータベースに格納しています。 また、similarity_search メソッドでベクトル検索を実行して、ユーザーの質問と類似しているテキストを抽出します。 最後に、上記で抽出したテキストをもとに LLM に回答を生成させることで、RAG を実現しています。 参考： langchain.vectorstores.faiss.FAISS 実行 それでは、以下を実行して動作確認してみます。 # input: [8] question = "BigQuery で行レベルセキュリティを実装する方法を教えてください" search_res = search_questions_web(question) text_li = text_split_func(search_res) rag(question, text_li) # output: [8] LLM Output: BigQuery で行レベルセキュリティを実装するには、次の手順に従います。 1 . ターゲット BigQuery テーブルに行レベルのアクセス ポリシーを作成します。 2 . ポリシーで、ユーザーまたはグループを許可リストに追加します。 3 . 許可リストに含まれていないユーザーまたはグループは、テーブルへのアクセスを拒否されます。 Reference URL: [ { ' title ' : ' BigQuery の行レベルのセキュリティの概要 | Google Cloud ' , ' link ' : ' https://cloud.google.com/bigquery/docs/row-level-security-intro?hl=ja ' } , { ' title ' : ' BigQuery の行レベルのセキュリティにより、データへのアクセスの ... ' , ' link ' : ' https://cloud.google.com/blog/ja/products/data-analytics/bigquery-provides-tighter-controls-over-data-access ' } , { ' title ' : ' BigQuery の行レベルのセキュリティに関するベスト プラクティス ... ' , ' link ' : ' https://cloud.google.com/bigquery/docs/best-practices-row-level-security?hl=ja ' } ] LLM Output には、最終的な LLM の要約が含まれております。 Reference URL には、Vertex AI Search で取得した検索結果 (上位 3 件) が取得されています。 別の質問でもいくつか実行してみます。 # input: [9] question = "Cloud Run と Cloud Functions の使い分けについて教えてください。" search_res = search_questions_web(question) text_li = text_split_func(search_res) rag(question, text_li) # output: [9] LLM Output: Cloud Functions は、プラットフォームの接続に適しています。Cloud Run は、サービスの実行に適しています。 Reference URL: [ { ' title ' : ' Cloud run vs cloud functions for serverless | Google Cloud Blog ' , ' link ' : ' https://cloud.google.com/blog/products/serverless/cloud-run-vs-cloud-functions-for-serverless ' } , { ' title ' : ' Cloud Functions と Cloud Run: それぞれの使いどころ | Google ... ' , ' link ' : ' https://cloud.google.com/blog/ja/products/serverless/cloud-run-vs-cloud-functions-for-serverless ' } , { ' title ' : ' Cloud Run: サーバーレス コンテナの話 | Google Cloud 公式ブログ ' , ' link ' : ' https://cloud.google.com/blog/ja/topics/developers-practitioners/cloud-run-story-serverless-containers ' } ] # input: [10] question = """ BigQuery で料金を制限したいです。いい方法を教えてください。 """ search_res = search_questions_web(question) text_li = text_split_func(search_res) rag(question, text_li) # output: [10] LLM Output: BigQuery の料金は、クエリの実行時間、使用したデータ量、保存したデータ量に基づいて計算されます。 料金を制限するには、次の方法があります。 * クエリをより効率的に実行する。 * 使用したデータ量を減らす。 * 保存したデータ量を減らす。 クエリをより効率的に実行するには、次の方法があります。 * クエリを最適化する。 * クエリを分割する。 * クエリを並列実行する。 使用したデータ量を減らすには、次の方法があります。 * 必要なデータのみをクエリする。 * クエリ結果をキャッシュする。 * クエリ結果を圧縮する。 保存したデータ量を減らすには、次の方法があります。 * 不要なデータを削除する。 * データを圧縮する。 * データをアーカイブする。 これらの方法を組み合わせることで、BigQuery の料金を大幅に削減することができます。 Reference URL: [ { ' title ' : ' コストの見積りと管理 | BigQuery | Google Cloud ' , ' link ' : ' https://cloud.google.com/bigquery/docs/best-practices-costs?hl=ja ' } , { ' title ' : ' 料金 | BigQuery: クラウド データ ウェアハウス | Google Cloud ' , ' link ' : ' https://cloud.google.com/bigquery/pricing?hl=ja ' } , { ' title ' : ' 割り当てと上限 | BigQuery | Google Cloud ' , ' link ' : ' https://cloud.google.com/bigquery/quotas?hl=ja ' } ] Vertex AI Search の単体の機能では外部サイトの要約は実装できませんが、このように LLM と組み合わせて RAG を構築することで外部サイトの要約を実装することができました。また、LangChain を用いることで、実装工数も大幅に短縮できますね。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の杉村です。Google Cloud のメタデータ管理ツールである Knowledge Catalog （旧称 Dataplex Universal Catalog）を解説します。 概要 Knowledge Catalog とは 過去に存在した Data Catalog 名称の変遷 データカタログとメタデータ データカタログとは メタデータとは ビジネスメタデータとテクニカルメタデータ データ検索機能 検索方法 自然言語検索（セマンティック検索） 検索結果の表示 クエリの構文 メタデータの取り込み メタデータの自動収集 テクニカルメタデータの自動収集 サードパーティのメタデータ Knowledge Catalog のリソース エントリ、エントリグループ、エントリタイプ アスペクト、アスペクトタイプ 必須アスペクト データの自動登録（Discovery） Data products 料金 アクセス制御（IAM） IAM の基本 メタデータの検索 カタログの管理 Dataplex による権限管理 監査ログ 概要 Knowledge Catalog とは Knowledge Catalog （旧称 Dataplex Universal Catalog）とは Google Cloud のメタデータ管理サービスです。フルマネージドであり、インフラの管理は全く必要ありません。生成 AI モデル Gemini と高度に統合されており、組織のデータ資産にコンテキスト（背景情報）を付加したり、それらを従業員から検索可能にしたり、ガバナンスを向上させるのに役立ちます。 参考 : Knowledge Catalog の概要 Knowledge Catalog では、BigQuery のテーブルや Cloud Storage バケット内の非構造化データなど、Google Cloud 上のデータにメタデータを付与して データカタログ 化し、ユーザーが検索できるようになります。BigQuery や Spanner、Bigtable、Dataproc、Pub/Sub など、多くの Google Cloud サービスのデータは何もしなくても 自動的にカタログに登録される ほか、Cloud SQL 上のデータも、明示的に有効化することで登録できます。 さらに、Google Cloud リソース以外にも、オンプレミスのデータベースや Snowflake、Databricks など、サードパーティのメタデータも、カスタムコネクタを開発することで管理対象にできます。 参考 : Knowledge Catalog のデータカタログ管理について - サポート対象のソース 過去に存在した Data Catalog 過去には、Google Cloud に Data Catalog というプロダクトが存在していました。Data Catalog はサービス終了が発表されており、2026年1月30日にシャットダウンされました。Data Catalog の利用者は、Knowledge Catalog に移行する必要がありました。 参考 : Data Catalog から Knowledge Catalog に移行 参考 : Knowledge Catalog と Data Catalog 名称の変遷 Knowledge Catalog は、かつて Dataplex Universal Catalog という名称であり、その前は Dataplex Catalog という名称でした。2025年4月に米国ラスベガスで開催された Google Cloud Next '25 において、Dataplex Catalog という名称から BigQuery universal catalog への改名が発表されたあと、さらに Dataplex Universal Catalog に変更されました。そして2026年4月の Google Cloud Next '26 の直前に、現在の Knowledge Catalog に改称されました。 現在では各種ドキュメントでも Knowledge Catalog という名称が使用されていますが、API エンドポイントやコマンドラインインターフェイスなどには影響がでないようになっています。 参考 : Knowledge Catalog release notes - April 10, 2026 データカタログとメタデータ データカタログとは データカタログ とは、メタデータをカタログ化し、利用者が必要なデータを探し出しやすくするためのツールです。データカタログは Google Cloud に特有の概念ではなく、メタデータを管理するためのツール全般を指す一般的な用語です。当記事で紹介する Knowledge Catalog は、Google Cloud がフルマネージドで提供するデータカタログサービスであるとお考えください。 データカタログが無いと、従業員はデータが必要になったときに、BigQuery や Cloud Storage の専門知識を使って一つ一つの Google Cloud プロジェクトを開いてテーブル名やファイル名を確認し、設計書を漁ったり、システム管理者に質問して回る必要があります。 データカタログでメタデータを集約管理することで、このような無駄なコミュニケーションを節約し、組織（企業や官公庁）の従業員は、必要なデータを探し出しやすくなります。 メタデータとは そもそも メタデータ とは何でしょうか。以下のようなテキストデータがあったとします。 [Data] 吾輩は猫である。名前はまだ無い。どこで生れたかとんと見当が...... このデータに、メタデータを付与すると以下のようになります。 [Metadata] Title: 吾輩は猫である Author: 夏目漱石 Page count: 380 [Data] 吾輩は猫である。名前はまだ無い。どこで生れたかとんと見当が...... ここでは、小説の本文を データ として、タイトルや著者名、ページ数などを メタデータ としました。一般的にメタデータは「データ本体を説明するためのデータ」といえます。 データ分析基盤を構築しても、メタデータなしには、利用者が必要なデータを探し出すことは容易ではありません。メタデータがあるからこそ、データは活用されます。 現実世界の例でいうと、他に以下のようなものが挙げられます。 名前 データ メタデータ PC 上のファイル ファイルの中身 ファイル名、サイズ、作成日時、更新日時、アクセス権限 データベースのテーブル レコード テーブル名、列名、テーブルや列に関する説明 ビジネスメタデータとテクニカルメタデータ メタデータは、 ビジネスメタデータ と テクニカルメタデータ に分類されることがあります。 ビジネスメタデータとは、メタデータのうち、業務に関連するものを指します。そのデータの所有者、部門、業務上の意味、カラムの説明、利用上の注意などです。 テクニカルメタデータとは、メタデータのうち、より技術的な意味合いのものを指します。スキーマ定義、アクセス権限、パーティショニングやクラスタリングなどのテーブル属性などです。 なお、ここまで説明した「メタデータ」「テクニカルメタデータ」「ビジネスメタデータ」は、書籍や製品などによって独自の呼び方をしていることがありますのでご注意ください。 データ検索機能 検索方法 データに対する検索は、Google Cloud コンソール、あるいは API 経由で行うことができます。 Google Cloud コンソールは、Dataplex の画面と統合されています。Dataplex 画面で「検索」を選択するか、Web コンソール上部の検索ボックスに Catalog search と入力して表示されるサジェストをクリックすることでも、検索画面に遷移できます。 検索画面 検索可能な範囲は、検索を実行者の Google アカウントが持つ IAM 権限に応じて決まります。データそのものにアクセス権がなくても、メタデータへのアクセス権があれば検索結果として表示されます。また、複数のプロジェクトを横断した検索が可能です。ただし、検索結果に表示されるのは、同じ Google Cloud 組織内のリソースだけです。 権限があれば、BigQuery、Pub/Sub、Cloud Storage、Spanner など、Knowledge Catalog でカタログ化された全てのデータが対象となって検索されます。テーブル名、列名、Description など広い属性が検索対象になるため、ある程度あいまいな語でもデータに辿り着くことが可能です。 また検索対象のサービスや、リソースのタイプ、Dataplex のレイク、ゾーン、Google Cloud プロジェクトなどで、検索対象をフィルタすることが可能です。 参考 : Knowledge Catalog でリソースを検索する 自然言語検索（セマンティック検索） Knowledge Catalog では、キーワード検索ができることに加えて、自然言語での検索も可能です。この機能では AI が検索をサポートし、自然言語（人間が普段使う言葉）で検索を行うことができます。 自然言語で入力した検索語句は意味として解釈され、セマンティック検索（意味論検索）が行われます。 検索結果の表示 以下のスクリーンショットは、検索結果に表示された BigQuery テーブルの詳細画面の例です。 BigQuery テーブルの検索結果 スクリーンショットでは「スキーマ」タブを表示しています。テーブルの所属データセット、プロジェクトや、スキーマ、そのスキーマに設定された説明（Description）などが表示されます。BigQuery のコンソール画面（BigQuery Studio）等でテーブルや列に設定した説明（Description）は、自動的に反映されて表示されます。 「詳細」タブには、Dataplex で設定したアスペクト（後述）なども表示されます。 その他のタブで、Dataplex によって作成されたデータリネージや、データ品質、データプロファイリングの結果も閲覧できます。 クエリの構文 Knowledge Catalog では、単純に語を入れて検索することもできますし、記号を使った様々な構文も利用できます。 例えば name:foo とすると、エントリの名称に foo を含むエンティティを検索します。 : は部分一致ですが、 = だと完全一致になります。他にも column label location updatetime など、検索対象とする属性を指定することが可能です。 以下は、例です。 検索クエリ 意味 location=asia-northeast1 name:my-entry 東京リージョンにある、名称に my-entry を含むエントリ updatetime>=2025-04-04T06:00:00 2025-04-04T06:00:00 (GMT) 以降に更新されたエントリ (タイムゾーンは GMT のみサポート。+9時間で日本時間) 詳細は以下の記事も参考にしてください。 参考 : Knowledge Catalog の検索構文 メタデータの取り込み メタデータの自動収集 Knowledge Catalog は、以下の Google Cloud プロダクトのメタデータを 自動的に取り込み 、検索可能にします。カタログ化されたメタデータは、すぐに Knowledge Catalog の UI や API 経由で検索可能です。 プロダクト名 対象リソース BigQuery ・データセット ・テーブル ・BigQuery ML モデル ・ルーチン（ストアドプロシージャ、ユーザー定義関数、テーブル関数） ・接続 （Connections） ・リンクされたデータセット AlloyDB for PostgreSQL ・クラスタ、インスタンス（デフォルトで有効化） ・データベース、スキーマ、テーブル、ビュー（要有効化） Analytics Hub ・エクスチェンジ ・リスティング Bigtable ・インスタンス ・クラスタ ・テーブル Dataform ・リポジトリ ・コードアセット Cloud SQL ・インスタンス（デフォルトで有効化） ・データベース、テーブル、ビュー（要有効化） Pub/Sub ・トピック Dataproc Metastore ・サービス ・データベース ・テーブル Spanner ・インスタンス ・データベース ・テーブル ・ビュー Vertex AI ・モデル ・データセット ・特徴グループ ・特徴ビュー ・オンラインストアインスタンス 参考 : Knowledge Catalog のメタデータ管理について - サポート対象のソース テクニカルメタデータの自動収集 前述の対応プロダクトのリソースのテクニカルメタデータは、自動的に収集されます。 BigQuery テーブルのテーブル名、カラム名、カラムの型や説明（description）など、リソースに付与されたテクニカルメタデータは、ユーザーが何もしなくても**自動的に収集され、すぐに検索可能です。 サードパーティのメタデータ Knowledge Catalog では、前述の Google Cloud サービス以外にも、 カスタムエントリ （後述）を作成することで、オンプレミスや他クラウドのデータのメタデータを登録することが可能です。 また、サードパーティのデータソースから Dataplex にメタデータを継続的、自動的にインポートするには、 マネージド接続 （Managed connectivity）機能を使います。これには独自のカスタムコネクタの開発が必要です。カスタムコネクタは、PySpark 等を用いて、Dataproc Serverless で実行できる Artifact Registry イメージとして作成する必要があります。 参考 : マネージド接続の概要 参考 : メタデータのインポート用にカスタム コネクタを開発する マネージド接続用のカスタムコネクタとして、コミュニティによって開発されたコネクタを利用することもできます。これらのコネクタは Google によって公式にサポートされるものではありませんが、PostgreSQL、SQL Server、Oracle、Snowflake などに向けたコネクタが公開されています。 参考 : マネージド接続の概要 - コミュニティ提供のカスタム コネクタ Knowledge Catalog のリソース エントリ、エントリグループ、エントリタイプ エントリ とは、BigQuery データセットやテーブル、Pub/Sub トピックなど、1つ1つのリソースを指します。メタデータは、エントリ内のアスペクト（後述）に記述されます。 エントリグループ は、エントリをグルーピングする管理単位です。 @bigquery や @pubsub などの Google Cloud リソースのエントリグループが、Knowledge Catalog によって自動的に作成されます。 エントリタイプ は、エントリのテンプレート（雛形）です。Knowledge Catalog によって定義済みのエントリタイプはシステムエントリタイプといい、例として BigQuery テーブルや Pub/Sub トピックなど、自動で登録されるエントリには、システムエントリタイプが適用されます。 参考 : Knowledge Catalog のデータカタログ管理について - メタデータ管理の仕組み ユーザー側で、カスタムエントリやカスタムエントリグループ、カスタムエントリタイプを作成することもできます。これにより、Knowledge Catalog が自動的に取り込まないリソースのメタデータや、Google Cloud 外のデータのメタデータも、Knowledge Catalog に登録することができます。 参考 : エントリを管理してカスタムソースを取り込む アスペクト、アスペクトタイプ エントリ内には アスペクト と呼ばれるフィールドがあり、メタデータはここに記述されます。 アスペクトには、キー（名前）とバリュー（値）を登録できます。これにより、ビジネスメタデータや、追加のテクニカルメタデータを記述できます。 アスペクトタイプ とは、複数のアスペクトのプリセットです。例えば、あらかじめ Data Governance というアスペクトタイプを定義しておき、その中にはデータの管理者や所有者の連絡先、機密レベル、保持期限などのエントリの名前を登録しておきます。アスペクトタイプは再利用できるので、統一したフォーマットでエントリにメタデータを登録することができます。 以下は、Data Governance というアスペクトタイプを BigQuery データセットに適用して、値を入力した例です。 アスペクト BigQuery の場合、テーブル全体にアスペクトを付与することもできますし、カラムに付与することもできます。 ユーザーで定義したアスペクトタイプは、組織内で公開できます。これにより、メタデータのフォーマットを統一できます。運用上は、組織でデータガバナンスルールを定義し、どのようなメタデータを必須として付与すべきかを定義することが望ましいといえます。 参考 : アスペクトを管理してメタデータを拡充する 必須アスペクト 例えば BigQuery テーブルのエントリには、Knowledge Catalog によって予め「BigQuery Table」と「Storage」という 必須アスペクト が付与され、値が自動的に登録されます。 必須アスペクト データの自動登録（Discovery） Dataplex Discovery は、Dataplex にアセットとして登録されているデータレイク内のデータから、メタデータを自動でスキャンして抽出し、Dataproc Metastore、BigQuery、Knowledge Catalog に登録して利用可能にする機能です。 Dataplex の機能の一部として提供されているので、詳細は以下の記事をご参照ください。 参考 : Dataplexを徹底解説！ - Dataplex Discovery Data products Data products （データ製品）は、データの提供者が、組織内の利用者向けにデータアセット（BigQueryデータセットやテーブル）をパッケージして、キュレーションするための機能です。権限管理の運用もシンプルにすることができます。 1つの Data product は論理的なオブジェクトであり、中に BigQuery データセット、テーブル、ビューといったアセットを含むことができます。Data product には アクセスグループ として Google グループを設定でき、データへのアクセス管理を行うことができます。 参考 : About data products 料金 Knowledge Catalog の料金として、メタデータストレージの料金が発生します。2025年11月現在、メタデータストレージ料金の単価は、$2/GiB/月です。 参考 : Knowledge Catalog (formerly Dataplex) pricing また、Dataplex のデータリネージ機能の保存データも、このストレージ料金として加算されます。データリネージについては、以下を参照してください。 参考 : Dataplexを徹底解説！ - G-gen Tech Blog - データリネージ アクセス制御（IAM） IAM の基本 メタデータの検索、エントリへのタグ付け、データリネージの閲覧などは、全て IAM （Identity and Access Management）によってアクセス制御されます。 「メタデータは検索可能で、リソース名称やメタデータまでは表示させて良いが、データそのものにはアクセスさせない」といった権限管理も可能です。 Google Cloud の IAM では、Amazon Web Services（AWS）と異なり、 リソースに対して 、誰が、何をできるかを設定します（IAM ポリシーをリソースが持ちます）。Google Cloud の IAM の基本は、以下の記事をご参照ください。 blog.g-gen.co.jp メタデータの検索 Knowledge Catalog を使って検索を行う Google アカウントは、検索を実行するプロジェクトに対して、Dataplex Catalog 閲覧者（roles/dataplex.catalogViewer）ロール等を持っている必要があります。 ただし、検索結果に出てくるリソースは、検索を実行したアカウントがメタデータへのアクセス権限を持っているリソースだけです。 逆に、メタデータへのアクセス権限を持っていれば、検索を実行したプロジェクト以外のプロジェクトのリソースも、検索結果に表示されます（ただし、同じ Google Cloud 組織内のリソースのみ）。つまり、Knowledge Catalog では、複数のプロジェクトを横断した検索が可能です。 参考 : Knowledge Catalog でリソースを検索する - 必要なロール カタログの管理 Knowledge Catalog のリソース（エントリやアスペクト等）の管理を行うには、操作者の Google アカウントがプロジェクト等に対して管理に関するロールを持っている必要があります。 プロジェクトレベルでオーナー（ roles/owner ）や編集者（ roles/editor ）を持っていれば、Knowledge Catalog リソースの管理が可能です。また、Dataplex Catalog 管理者（ roles/dataplex.catalogAdmin ）、Dataplex Catalog 編集者（ roles/dataplex.catalogEditor ）などの事前定義ロールが用意されています。 参考 : Knowledge Catalog の IAM ロール Dataplex による権限管理 Dataplex による権限管理と、カタログの検索権限に関するイメージは、以下の記事をご参照ください。 参考 : Dataplexによる権限管理の仕組みを徹底解説 - G-gen Tech Blog - リソースの検索（Dataplex Univeresal Catalog） 監査ログ Knowledge Catalog では、 Cloud Audit Logs により、監査ログ（誰が、いつ、どこで、何をしたか）が Cloud Logging に記録されます。 デフォルトでは、カスタムアスペクトの作成や編集といった、管理アクティビティログが記録されます。 参考 : Knowledge Catalog の監査ロギング Cloud Audit Logs についての詳細は以下の記事をご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

本記事では、Google Cloud のスケーラブルでサーバレスなデータ管理ツールである Dataplex を徹底解説します。 Dataplex の概要 Dataplex とは Dataplex Universal Catalog メリット データメッシュとは 構成とオブジェクト アクセス制御機能 認証・認可（IAM） IAM の基本的な理解 アセットと IAM プロジェクトをまたぐ権限管理 権限管理の詳細 VPC Service Controls データの品質チェック Dataplex におけるデータ品質の検証 自動データ品質 自動データ品質とは データ品質タスク データプロファイリング データリネージ データリネージとは 有効化 追跡可能な情報 保持期間 Dataplex Discovery Dataplex Discovery とは Discovery Action ロギングとモニタリング ロギング モニタリング 料金 その他の機能 メタデータのインポート（マネージド接続） ビジネス用語集 Gemini in Dataplex（分析情報） Dataplex の概要 Dataplex とは Dataplex は Google Cloud（旧称 GCP）で提供されている、 分散されたデータの統合・管理を自動化するためのサービス です。以下のことが実現できます。 組織内の複数の Google Cloud プロジェクトにまたがるデータを統合して データメッシュ （後述）を構築する データの 権限管理を一元化 する メタデータを付けることで データをカタログ化 し、検索しやすくする データの品質やライフサイクルを管理する Dataplex はフルマネージドサービスであり、インフラの管理は一切必要ありません。また、使用されたリソース量や保存データ量に応じた従量課金であり、一般的には安価に利用することができます。 参考 : Dataplex の概要 Dataplex Universal Catalog Dataplex には、 Dataplex Universal Catalog （旧称 Dataplex Catalog）というサービスも内包されています。Dataplex Universal Catalog は、BigQuery や Cloud Storage など、Google Cloud 環境にあるデータのメタデータを管理し、カタログ化するフルマネージドサービスです。 当記事では Dataplex Universal Catalog の詳細には触れません。詳細は、以下の記事を参照してください。 blog.g-gen.co.jp メリット Dataplex を使うことにより、組織内の散らばったデータを一箇所に集約せずに、そのままの状態で統合管理できます。データの移動やコピーは必要ありません。 具体的には、Cloud Storage や BigQuery に入っているデータがさまざまなプロジェクト、バケット、データセットに分散していても、統合管理をすることができるようになります。 「統合管理」にはデータの検索性のほか、データ品質の自動的なチェックやセキュリティ設定も含まれています。 Dataplex が管理対象にできるデータは、BigQuery、Cloud Storage、Dataproc Metastore などの Google Cloud サービスのほか、Apache Spark や Presto との統合も可能です。 データメッシュとは Dataplex は「ドメイン」を中心とした「 データメッシュ 」を提供するプロダクトです。 組織内で、各部署やシステムごとに個別にデータを持ってしまい、かつどこにデータがあるか分からないためにデータの活用ができない状態は データのサイロ化 と呼ばれ、組織のデータの課題として有名です。これを回避するために、従来は単一のデータ基盤にデータを収集することでこれを解決しようとしてきました。 しかしこのアプローチは、データの移動（コピー）が必要になります。この実現には複雑なデータパイプラインの構築が必要なことに加え、コンピュートやストレージリソース、そしてそれらを管理する人のリソースも必要となります。 このような中央集権的な方式とは一線を画する解決策が データメッシュ です。論理的な管理レイヤで仮想的にデータをグルーピングすることで、データを分散配置したままで統合管理を可能にするアプローチです。これにより、データのコピーは不要でありながら、データのサイロ化を回避して、また認証・認可やデータ品質のモニタリングなどを実現できます。 Dataplex で実現するデータメッシュを理解するには、併せて以下の用語も把握してください。 用語 説明 ドメイン ・特定の ビジネス分野や領域 を表す概念 ・企業内で共通の言語やルールで情報を管理するための基盤となる ・例えば「セールス」「小売」「財務経理」など また、以下は、データメッシュにおける登場人物に関する用語です。 用語 説明 データプロダクトオーナー データプロデューサーとも呼ばれる。データを生み出す人またはチームであり、ビジネスやデータのドメインに 最も詳しい 。売上や受発注データに詳しい販売部門、EC サイトのアクセスログや顧客情報に詳しいマーケティング部門等にそれぞれデータプロダクトオーナーが存在する データコンシューマー データアナリストやデータサイエンティスト、あるいはビジネス部門の従業員といった データを消費 (利用) する人またはチーム データスチュワード 組織全体のデータ基盤を管理 する人またはチーム。データの管理人であり、データ品質やガバナンス、権限管理、機密情報のマスキングなどを司る これらの登場人物が、ドメインごとにデータを生成・管理し、利用可能にする組織アーキテクチャがデータメッシュです。Dataplex はそのデータメッシュを実現するためのプロダクトであると言えます。 参考 : Build a modern, distributed Data Mesh with Google Cloud 参考 : データメッシュ内のアーキテクチャと機能 データメッシュの考え方 構成とオブジェクト Dataplex の主要オブジェクトは以下のとおりです。前述の用語は組織や概念に関するものでしたが、ここからは実際に Dataplex を触るとシステム的に登場します。 参考 : 用語 名称 説明 レイク データの論理的なまとまり。ドメインごとにレイクを持つことが想定されている ゾーン レイクの中に存在するサブドメイン。データレイク、DWH、データマートのような段階を表現したり、給与や人事情報といった機密性の度合いで分類する。ゾーンには以下の2タイプが存在する。 　・Raw zone : 無加工・未チェックの生データ 　・Curated zone : データクレンジング済みでいつでも分析できるデータ。Parquet や Avro などの構造化データ、BigQuery テーブルなどのアセットを含む アセット 実データであり、実体は Cloud Storage バケットや BigQuery データセット。実データが異なる Google Cloud プロジェクトに所属していても、単一ゾーンに所属することができる エンティティ 非構造化・半構造化・構造化データに対するメタデータ 上記のオブジェクトは、以下のように 階層構造 を構成します。 Dataplex のアセット管理方式 従来だとデータは、Google Cloud プロジェクトでグルーピングし、BigQuery のデータセット名や Cloud Storage のバケット名などの命名規則で管理していました。 しかし Dataplex では Google Cloud プロジェクトが何であろうと、リソース名が何であろうと、 レイクで階層化することで統合管理 できます。 レイクは複数のゾーンを含めることができますが、 ゾーンは1つのレイクにしか所属できない ため、ゾーンをドメインに対するタグのように扱うことはできません。また、ゾーンの下位リソースである アセットも、1つのゾーンにしか所属できません 。 アクセス制御機能 認証・認可（IAM） IAM の基本的な理解 当項目の内容を理解するには、以下の記事をお読みになり、Google Cloud の IAM の基礎的な理解をしていただくことが前提となります。Amazon Web Services（AWS）の IAM 等とは概念が異なりますため、以下の記事をぜひご参照ください。 blog.g-gen.co.jp アセットと IAM Dataplex では、Cloud Storage や BigQuery といった Dataplex アセットの上に 仮想化階層 を追加し、そこに対してユーザやサービスアカウントの IAM 権限を付与することで権限を管理します。 Dataplex でデータへのアクセス権限を管理するメリットとして、以下のようなものが挙げられます。 様々なプロジェクトに分散したデータの 権限管理を集約 ユーザーにとって 意味のある単位 （レイク、ゾーン等）で 権限を付与 できる レイクの IAM ポリシーはゾーンに 伝播 （継承）され、さらにはゾーンが保持するアセットに伝播されます。Dataplex 経由の IAM ポリシーは、リソースにもともとついている 通常の IAM ポリシーとは別 で管理されます。プロジェクトレベルでロールを管理しなくて良くなり、リソースレベルの IAM 管理になるため、 最小権限の原則 が守りつつ、管理工数を削減することができます。 参考 : IAM を使用したアクセス制御 なお、ある Google アカウントが例えば BigQuery データセットに IAM ロールを持っており、同時に Dataplex でも権限を持っている場合、 どちらかで権限が付与されていればアクセスが可能です 。つまり、通常の IAM と Dataplex のアクセス制御は、OR で評価されます。運用上は、どちらかに権限管理を寄せるのが理想的です。 プロジェクトをまたぐ権限管理 管理対象のアセットが Dataplex とは別の Google Cloud プロジェクトに存在している場合は、Dataplex のプロジェクトの「Dataplex サービスアカウント（サービスエージェント）」に対して、アセットが存在するプロジェクトの IAM 権限（Cloud Storage 管理者ロールや BigQuery 管理者ロール）を付与する必要があります。 Dataplex サービスアカウントは service-${プロジェクト番号}@gcp-sa-dataplex.iam.gserviceaccount.com という名称で、Dataplex のプロジェクトに存在しています。 このように、Dataplex サービスアカウントに IAM 権限を委任することで、Dataplex は仮想的な権限レイヤを実現できるのです。 参考 : レイク内のデータアセットを管理する - ロールの付与 権限管理の詳細 Dataplex による権限管理の仕組みは、以下の記事でサンプルアーキテクチャを用いて解説しています。 権限管理手法や、運用のイメージをつけたい場合にご参照ください。 blog.g-gen.co.jp VPC Service Controls VPC Service Controls を使って Dataplex に追加のアクセス制御層を作り、データ流出のリスクを軽減することができます。 VPC Service Controls は Google Cloud API へのアクセス制御を行うための独立した Google Cloud サービスです。以下の記事をご参照ください。 blog.g-gen.co.jp また以下の公式ドキュメントもご参照ください。 参考 : Dataplex で使用する VPC Service Control データの品質チェック Dataplex におけるデータ品質の検証 Dataplex には データの品質チェック機能 があり、以下の3種類の機能が用意されています。 自動データ品質 データ品質タスク データプロファイリング 自動データ品質 自動データ品質とは 自動データ品質 機能は、事前に定義したデータ品質に基づいてデータの品質をチェックし、品質要件を満たしていない場合にアラートを発報できる機能です。 ルールは以下の方法で定義できます。 Dataplex からサジェストされる推奨事項を利用 事前定義ルール カスタム SQL ルール 自動データ品質チェックをすることで、品質定義を自動化・簡素化することができ、また品質を満たしていない場合の初動対応も迅速に行うことができるようになります。 参考 : 自動データ品質の概要 データ品質タスク Dataplex データ品質タスク は、ユーザが独自にカスタマイズ可能なデータ品質チェックの機能です。BigQuery と Cloud Storage に対して実行できます。 データパイプラインに組み込んでデータ検証に用いたり、あるいは定期的なデータ品質チェックに用いることができます。 ルールは YAML で定義します。定義したルールは SQL に変換され、BigQuery 上で処理されるため、インフラ設定は不要です。また、スケジュールに基づいてチェックを実行できるほか、API 経由で呼び出し可能なため、既存のデータパイプラインに組み込むこともできます。 バックエンドではオープンソースの データ品質エンジン である CloudDQ が使われています。CloudDQ は BigQuery 用のデータ品質検証コマンドラインツールであり、クラウドネイティブ、宣言型、スケーラブルといった特性を持ちます。 参考 : データ品質タスクの概要 データプロファイリング データプロファイリング は、BigQuery テーブルの列の統計的特性をレポーティングする機能です。 テーブルの各列の「値の分布」「null の数」「ユニークな値の数（概算）」「最大値・最小値・平均値・標準偏差・近似中央値」などを出すことができます。 スキャンの対象テーブルを指定し、スケジュール実行することもできますし、結果を別の BigQuery テーブルにエクスポートすることもできます。 参考 : データ プロファイリングについて データリネージ データリネージとは Dataplex の データリネージ 機能とは、ある BigQuery テーブルのデータがどこから来て、どこに渡されているかなど、データの出自を特定できる機能です。 「リネージ（lineage）」とは、血統、系統などを指す英単語です。データの家系図のようなものを連想させます。 有効化すると、テーブルごとにグラフが生成され、BigQuery のコンソール画面（BigQuery Studio）からデータの流れをグラフィカルに確認することができます。 INSERT SELECT や CREATE TABLE AS SELECT などのジョブが追跡され、以下の画像のようなリネージグラフとして表示可能になります。 参考 : データリネージについて 参考 : BigQuery テーブルのリネージを追跡する 有効化 データリネージを有効化するには、プロジェクトで以下の3つの API を有効化するだけです。API 有効化後、リネージ情報の取得が開始されます。そのため、有効化前のリネージは確認できないことに注意が必要です。有効化すると、Dataplex 料金が発生することに留意してください。 Dataplex API BigQuery API Data lineage API 追跡可能な情報 データリネージは、BigQuery の以下の情報を自動的に記録します。 COPY ジョブ（テーブルの複製） Cloud Storage からの LOAD ジョブ 以下の QUERY ジョブ（DDL） CREATE TABLE CREATE TABLE AS SELECT CREATE TABLE COPY CREATE TABLE CLONE CREATE TABLE FUNCTION CREATE TABLE LIKE CREATE VIEW CREATE MATERIALIZED VIEW 以下の QUERY ジョブ（DML） SELECT（ビュー、マテリアライズドビュー、外部テーブル） INSERT SELECT MERGE UPDATE DELETE BigQuery Data Transfer Service による定期的な LOAD ジョブは自動記録されないので注意が必要です。 また、データリネージは他にも Cloud Data Fusion、Cloud Composer、Dataproc、Vertex AI に対応しています。 さらに、対応していないソースでも、Data Lineage API 経由で記録させることが可能です。 参考 : データリネージについて - データリネージの自動追跡 保持期間 リネージ情報の保持期間は30日間です。 なお、BigQuery テーブルなどを削除したとしても、リネージ情報は30日間は残り続けます。 参考 : 制限事項 Dataplex Discovery Dataplex Discovery とは Dataplex Discovery は、データレイク内のデータからメタデータを 自動でスキャン して抽出し、メタデータ化して Dataproc Metastore、BigQuery、Dataplex Universal Catalog に登録して利用可能にする機能です。 新しいゾーンやアセットを作成すると、自動で Dataplex Discovery が有効になりますが、オプショナルで無効にすることもできます。 Discovery が有効になっている Dataplex アセット（Cloud Storage バケット等）では、画像ファイルのような非構造化データや、Parquet / Avro / ORC / JSONL / CSV などの構造化ファイルが 自動でスキャンされます。テーブル名、スキーマ、パーティション定義などの テクニカルメタデータ が収集され、Dataproc Metastore に Hive-style テーブルとして、また BigQuery では 外部テーブル として登録されるため、自動的にデータがクエリ可能になります。 これによって、組織内で管理されるデータソースが増えた場合に、わざわざ BigQuery にロードまたは外部テーブル定義したり、Jupyter Notebook で読み込める形に整形加工したりといった作業をせずとも、すぐさまこれらのツールで分析ができます。 参考 : データを検出します Discovery Action データのスキャン中に問題が検出されると、 Discovery Action （検出操作）と呼ばれるアラートが上がります。以下のような問題が検出されたときに、Discovery Action が起票されます。 無効なデータ形式 互換性のないスキーマ 無効なパーティション定義 データの欠損 機能名的に誤解を招きそうですが、Discovery Action はあくまで問題のアラートを上げるだけで、実際の改善アクションはユーザが行う必要があります。 参考 : 検出操作 異なるシステムのインターフェースをつなぐデータパイプラインでは、関係者内であらかじめ設計・合意されたスキーマのデータソースが流れていくはずです。 前述のようなデータ不正は想定外の恒久的エラーであるケースが多く、クラウドリソースの枯渇のような一時的エラーとは異なります。システムの自動リトライによって回避できるものではないため、迅速に検知して人が対処する必要があります。Discovery Action はそのような事態の迅速な検知に役立ちます。 ロギングとモニタリング ロギング Dataplex のログは Cloud Logging に自動的に出力されます。アセットを検出したり、スケジューリングされたタスクが実行されると、Cloud Logging にログが出力されます。 また監査ログ（「誰が、いつ、どこで、何をしたか」）も同様に、Cloud Logging に出力されます。 参考 : Dataplex のログをモニタリングする 参考 : 監査ログの管理 モニタリング Dataplex は Cloud Monitoring と統合されており「アセットの合計サイズ」「ファイルセットの数」「テーブルの数」などに加え、未解決の管理アクションの有無などもメトリクスとして閲覧できます。 また、アプリケーションのパフォーマンスや稼働状況を視覚的に把握できます。Dataplex から収集した指標やメタデータを Cloud Monitoring のダッシュボードやグラフで表示し、詳細な分析情報を提供します。 これらの指標は自動的に有効化され、直感的にアクセスできます。 参考 : Dataplex の指標をモニタリングする 料金 Dataplex の料金は Dataplex が使った「コンピュートリソース」「ストレージ」によって課金されます。 コンピュート課金には Standard と Premium の2ティアがあり、例えば Dataplex Discovery 機能は Standard ティアの単価で課金され、データリネージやデータ品質タスクは Premium ティアの単価で課金されます。 どの機能にどの課金が適用されるか、詳細は以下をご参照ください。 参考 : Dataplex pricing その他の機能 メタデータのインポート（マネージド接続） マネージド接続 （Managed connectivity）機能を利用すると、サードパーティのソースからメタデータを Dataplex にインポートできます。 コネクタを開発することで、MySQL、SQL Server、Oracle、Snowflake、Databricks などのソースからメタデータを抽出できます。 コネクタは、Dataproc Serverless で実行できる Artifact Registry イメージとして、PySpark 等で開発する必要があります。 参考 : マネージド接続の概要 参考 : メタデータのインポート用にカスタム コネクタを開発する ビジネス用語集 ビジネス用語集 （Business glossaries）は、組織全体でビジネス関連の用語を定義して一元管理する機能です。 用語はカテゴリ分け・階層化することができ、また用語間の関係を定義することもできます。その用語の管理者を明記しておくことも可能です。 さらに定義された用語は、データエントリのカラムにアタッチすることができるため、メタデータ管理の際に表記の揺れを防ぐことにも繋がります。 参考 : Dataplex のビジネス用語集の作成と管理 Gemini in Dataplex（分析情報） Dataplex では、Google の生成 AI モデル Gemini を利用して、BigQuery テーブルや外部テーブル、ビューの データ分析情報 （data insights）を生成することができます。 この機能では、BigQuery テーブルに付与されたメタデータを使用して、テーブルとクエリに関する自然言語の質問を生成したり、その質問に回答するための SQL を生成できます。これにより、テーブルのデータから、パターンの検出、データ品質の評価、統計分析を行うことが可能です。 参考 : Dataplex のデータ分析情報にアクセスする Gemini が生成した質問とクエリ データ分析情報は、Gemini in BigQuery の機能です。Gemini in BigQuery については、以下も参照してください。 参考 : BigQueryを徹底解説！(基本編) - G-gen Tech Blog - Gemini in BigQuery G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

当記事では、Google Cloud の LLM (Vertex AI PaLM API) と LangChain を組み合わせて、自然言語から BigQuery 上の統計データを取得する方法を紹介します。 はじめに 準備 実行環境 使用するデータ 実装 ライブラリのインストール 関数の定義 概要 解説 実行 はじめに LangChain とは、大規模言語モデル (LLM) アプリケーションを効率よく実装するためのフレームワークです。LangChain についての詳細は以下の記事をご参照ください。 blog.g-gen.co.jp LangChain にはさまざまな機能が提供されておりますが、今回は Agents 機能を用いて SQL データベースと対話するエージェントを作成します。 LLM の ハルシネーション (幻覚) を抑制する手法として、指定した情報源だけに基づいて LLM に回答を生成させることを グラウンディング といいます。 最近では、テキストや画像をエンべディング (ベクトル化) する技術とベクトル検索の技術を組み合わせて RAG (Retrieval Augmented Generation) を行うグラウンディング手法が人気となっています。 しかし、自社のデータベースに保存された構造化データに対し、LLM が自然言語を理解して SQL を生成し、最終的に分析結果 (統計データ) を取得して回答を生成させたい場合にはどうしたらよいでしょうか。 例えば「先月の売上を教えて」というユーザーの入力に対し、LLM がデータベースに対して適切な SQL を発行し、先月の売上を算出して回答を生成するなどです。この場合も、指定した情報源（自社の売上データ）を基に回答を生成しているため、グラウンディングにあたります。 今回は、この構成を LangChain を用いて実装してみたいと思います。 今回の構成図 準備 実行環境 当記事では、 Colab Enterprise の Notebook を使用します。Colab Enterprise は、マネージドな Notebook のためインフラストラクチャを管理せず実装に注力できます。 Colab Enterprise の Notebook 作成方法は公式ドキュメントのクイックスタートをご参考下さい。 cloud.google.com 使用するデータ 今回使用するデータは、架空の販売データ ( sample-data ) を使用します。 尚、BigQuery テーブルの作成は省略しますが、作成後のテーブルプレビューは以下になります。 sales_data テーブル 実装 ライブラリのインストール Notebook が立ち上がり、ランタイムと接続できましたら以下のコードを実行してライブラリのインストールとインポートを行います。 # input:[1] !pip install sqlalchemy sqlalchemy-bigquery google-cloud-bigquery langchain ライブラリのインストールができたら、ランタイムを再起動してから以下を実行します。 # input:[2] from google.cloud import bigquery from sqlalchemy import * from sqlalchemy.engine import create_engine from sqlalchemy.schema import * from langchain.agents import create_sql_agent from langchain.agents.agent_toolkits import SQLDatabaseToolkit from langchain.sql_database import SQLDatabase from langchain.llms import VertexAI from langchain.agents import AgentExecutor 関数の定義 概要 ユーザーの入力 (自然言語) を引数に、BigQuery 上のデータから分析結果を出力する関数を定義します。 # input:[3] project = ${PROJECT_ID} dataset = ${DATASET_ID} sqlalchemy_url = f "bigquery://{project}/{dataset}" # SQLAlchemy エンジンを初期化 db = SQLDatabase.from_uri(database_uri=sqlalchemy_url) # Vertex AI 基盤モデルを初期化 llm = VertexAI( model_name= "text-bison@001" , max_output_tokens= 1024 , temperature= 0.1 , top_p= 0.8 , top_k= 40 , verbose= True , ) # SQL データベースと対話するエージェントの初期化 toolkit = SQLDatabaseToolkit(db=db, llm=llm) agent_executor = create_sql_agent( llm=llm, toolkit=toolkit, verbose= True , top_k= 10 , ) def run_query (query): res = agent_executor.run(query) return res 解説 SQLAlchemy エンジンを初期化 8 行目で SQLAlchemy エンジンを初期化しています。 SQLDatabase オブジェクトの from_uri メソッドで URI から SQLAlchemy エンジンを初期化できます。 URI の記法については、 Python-bigquery-sqlalchemy のドキュメントをご参照ください。また、BigQuery への認証情報については、 google-api-core のドキュメントをご参照ください。 SQL データベースと対話するエージェントの初期化 20-26 行目でSQL データベースと対話するエージェントの初期化しています。 SQLDatabaseToolkit オブジェクトは、SQL データベースと対話するためのツールキットであり、 create_sql_agent でエージェントを初期化しています。 このエージェントによって、ユーザーの入力から「次にどのようなアクションを取るか」を考え、実行、観測して答えがでるまで繰り返します。今回の場合は、ユーザーの入力に対して、SQL を生成して BigQuery にジョブを実行する操作を、最終的な結果を得るまで繰り返してくれます。 実行 それでは、実行してみましょう。 # input:[4] run_query( "プロダクト別の売上の上位10位を教えてください。" ) # output:[4] > Entering new AgentExecutor chain... Action: sql_db_list_tables Action Input: Observation: sales_data Thought:I found the table sales_data. I should query the schema of this table to see what columns I can use in my query. Action: sql_db_schema Action Input: sales_data Observation: CREATE TABLE `sales_data` ( `ctm_id` STRING, `ctm_name` STRING, `ctm_gender` STRING, `ctm_birthdate` DATE, `ctm_age` INT64, `ctm_postcode` STRING, `ctm_prefecture` STRING, `ctm_prefecture_code` INT64, `ctm_phone` STRING, `ctm_email` STRING, `ctm_ip_address` STRING, `sls_date` DATE, `sls_product` STRING, `sls_amount` INT64 ) /* 3 rows from sales_data table: ctm_id ctm_name ctm_gender ctm_birthdate ctm_age ctm_postcode ctm_prefecture ctm_prefecture_code ctm_phone ctm_email ctm_ip_address sls_date sls_product sls_amount C1000000044 矢部 剛 男 1996-07-07 25 134-5508 北海道 1 080-5565-3368 GCK5pwtZy@ test .jp 168 . 52 . 65 . 10 2021-02-28 Chromebook 3631 C1000000044 矢部 剛 男 1996-07-07 25 134-5508 北海道 1 080-5565-3368 GCK5pwtZy@ test .jp 168 . 52 . 65 . 10 2020-02-28 Chromebook 3631 C1000000044 矢部 剛 男 1996-07-07 25 134-5508 北海道 1 080-5565-3368 GCK5pwtZy@ test .jp 168 . 52 . 65 . 10 2022-02-28 Chromebook 3631 */ Thought:The table sales_data has the columns sls_product and sls_amount. I can use these columns to query the product and amount of sales. Action: sql_db_query Action Input: SELECT sls_product, SUM ( sls_amount ) FROM sales_data GROUP BY sls_product ORDER BY SUM ( sls_amount ) DESC LIMIT 10 Observation: [ ( ' Chromebook ' , 19160341 ), ( ' Mac ' , 11702719 ), ( ' マウス ' , 8605347 ), ( ' iPhone ' , 8178375 ), ( ' Windows ' , 5620327 ), ( ' HDD ' , 5419557 ), ( ' Android ' , 4475812 ), ( ' キーボード ' , 4391927 ), ( ' SSD ' , 3995346 ), ( ' 充電器 ' , 2162517 ) ] Thought:I now know the final answer Final Answer: The top 10 products by sales are: Chromebook, Mac, マウス, iPhone, Windows, HDD, Android, キーボード, SSD, 充電器. > Finished chain. The top 10 products by sales are: Chromebook, Mac, マウス, iPhone, Windows, HDD, Android, キーボード, SSD, 充電器. 処理の流れを一部見てみます。 [3 行目] Action : BigQuery データセットのテーブル一覧を取得 [5 行目] Observation : sales_data テーブルを検出 [6 行目] Action : sales_data テーブルのスキーマを取得して列を確認する [33 行目] Thought : sales_data テーブルには、sls_product 列と sls_amount 列があり、これらの列を使用してプロダクトと売上高をクエリできます。 [35 行目] Action Input : SELECT sls_product, SUM(sls_amount) FROM sales_data GROUP BY sls_product ORDER BY SUM(sls_amount) DESC LIMIT 10 上記のように、ユーザーの入力に対して、「次にどのようなアクションを取るか」とエージェントが考えて実行しています。 そして最終的なアプトプットが Finished chain として 40 行目に出力されてます。なお、統計結果は正しいものでした。 せっかくなので、別のクエリも試してみます。 # input:[5] run_query( "2020年9月1日から2020年9月30日までの売上合計を教えてください。" ) # output:[5] > Entering new AgentExecutor chain... Action: sql_db_list_tables Action Input: Observation: sales_data Thought:I found the table sales_data. I should query the schema of this table to see what columns I can use in my query. Action: sql_db_schema Action Input: sales_data Observation: CREATE TABLE `sales_data` ( `ctm_id` STRING, `ctm_name` STRING, `ctm_gender` STRING, `ctm_birthdate` DATE, `ctm_age` INT64, `ctm_postcode` STRING, `ctm_prefecture` STRING, `ctm_prefecture_code` INT64, `ctm_phone` STRING, `ctm_email` STRING, `ctm_ip_address` STRING, `sls_date` DATE, `sls_product` STRING, `sls_amount` INT64 ) /* 3 rows from sales_data table: ctm_id ctm_name ctm_gender ctm_birthdate ctm_age ctm_postcode ctm_prefecture ctm_prefecture_code ctm_phone ctm_email ctm_ip_address sls_date sls_product sls_amount C1000000044 矢部 剛 男 1996-07-07 25 134-5508 北海道 1 080-5565-3368 GCK5pwtZy@ test .jp 168 . 52 . 65 . 10 2021-02-28 Chromebook 3631 C1000000044 矢部 剛 男 1996-07-07 25 134-5508 北海道 1 080-5565-3368 GCK5pwtZy@ test .jp 168 . 52 . 65 . 10 2020-02-28 Chromebook 3631 C1000000044 矢部 剛 男 1996-07-07 25 134-5508 北海道 1 080-5565-3368 GCK5pwtZy@ test .jp 168 . 52 . 65 . 10 2022-02-28 Chromebook 3631 */ Thought:The table sales_data has the columns sls_date and sls_amount. I can use these columns to query the total sales for the period 2020-09-01 to 2020-09-30. Action: sql_db_query Action Input: SELECT SUM ( sls_amount ) FROM sales_data WHERE sls_date BETWEEN ' 2020-09-01 ' AND ' 2020-09-30 ' Observation: [ ( 997305 ,) ] Thought:I now know the final answer Final Answer: The total sales for the period 2020-09-01 to 2020-09-30 is 997305 . > Finished chain. The total sales for the period 2020-09-01 to 2020-09-30 is 997305 . こちらも最終的なアプトプットは正しいものでした。 このような LangChain を用いることで、自然言語によるインプットから LLM が自社の構造化データから統計的な分析結果を返してくれるグラウンディング手法も容易に実装ができますね。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の佐々木です。当記事では Cloud Run jobs のジョブ実行時に利用できる、 ジョブ構成のオーバーライド について解説します。 Cloud Run jobs とは ジョブ構成のオーバーライド 必要な権限 ジョブ構成のオーバーライドを試してみる 使用するコード（Go） Cloud Run ジョブのデプロイ デフォルトのジョブ構成でジョブを実行する ジョブ構成をオーバーライドしてジョブを実行する トラブルシューティング (CLI) Cloud Run jobs とは Cloud Run jobs は、サーバーレス コンテナコンピューティング サービスである Cloud Run の 1 機能です。Cloud Run services が HTTP リクエストを処理の起点とするのに対して、Cloud Run jobs はコンテナイメージとして実装したジョブを、手動、スケジュール、ワークフローなど、ユーザの任意タイミングで並列して実行することができます。 Cloud Run jobs の詳細については、以下の記事で解説しています。 blog.g-gen.co.jp ジョブ構成のオーバーライド Cloud Run jobs では、ジョブの作成時に環境変数、タスク数（処理を並列実行する数。各実行は タスク と呼ばれる）、タイムアウトなどの値をジョブ構成として設定します。 これらのジョブ構成のうちのいくつかは、ジョブを実行する際にオーバーライドすることが可能です。つまり、 ジョブ構成として設定された値を変更することなく、一度のジョブ実行でのみ有効な値を設定する ことができます。 ジョブ構成のうちオーバーライド可能なパラメータは以下の 4つです。 コンテナのエントリポイントとなるコマンドに渡す引数 ジョブの環境変数 タスク数（タスクの並列実行数） タスクのタイムアウト（最大実行時間） ジョブ構成のオーバーライドは以下のようなユースケースが考えられます。 日付や処理対象テーブルなどを引数や環境変数に設定し、ジョブに処理させるデータの範囲を実行ごとに切り替える ジョブに処理させるデータ量が通常より多い場合に、並列実行数やタイムアウトの値を増やす 参考： ジョブを実行する | 特定の実行のジョブ構成をオーバーライドする 必要な権限 ジョブ構成のオーバーライドには、ジョブの実行に必要な run.jobs.run 権限に加えて run.jobs.runWithOverrides 権限が必要となります。 当該権限は Cloud Run 開発者（roles/run.developer） ロールのほか、ジョブの実行に必要な最小権限であれば オーバーライドを使用する Cloud Run ジョブ エグゼキュータ（roles/run.jobsExecutorWithOverrides） という事前定義ロールを利用することができます。 オーバーライドを使用する Cloud Run ジョブ エグゼキュータ ロール ジョブ構成のオーバーライドを試してみる 使用するコード（Go） 当記事では、オーバーライド可能な各種パラメータを標準出力するだけのシンプルな処理を実行するコードを使用し、ジョブ構成のオーバーライドを試してみます。 コード内でオーバーライドの対象となっているのは、ジョブ実行時の引数となる --user の値と、ジョブ自体に設定する TARGET_ENV 環境変数の値です。これらを標準出力するだけのシンプルな処理となっています。 また、ジョブの実行時に タスク数 と タイムアウト の値もオーバーライドします。Cloud Run jobs でタスクを並列実行する際、 CLOUD_RUN_TASK_INDEX 環境変数からタスク番号を取得できるため、これもあわせて出力します。 package main import ( "flag" "fmt" "os" ) func main() { // 引数の定義と値の取得 var u = flag.String( "user" , "unknown" , "user name" ) // --userオプション（デフォルト値：unknown） flag.Parse() taskNum := os.Getenv( "CLOUD_RUN_TASK_INDEX" ) // 並列実行タスクのタスク番号（インデックス） userName := *u // ジョブ実行時に与えた引数 targetEnv := os.Getenv( "TARGET_ENV" ) // ユーザーが設定した環境変数 // タスク番号、引数、環境変数を標準出力 fmt.Printf( "TASK#%v USER:%v TARGET:%v \n " , taskNum, userName, targetEnv) } Cloud Run ジョブのデプロイ gcloud run jobs deploy コマンドで Cloud Run jobs のジョブをデプロイします。 以下のコマンドを使用することで、Dockerfile を用意することなくソースコードからジョブをデプロイすることができます（ 参考 ）。 当記事では「run-jobs-override」という名前でジョブをデプロイします。 # ソースコードから Cloud Run ジョブをデプロイする $ gcloud run jobs deploy { ジョブ名 } \ --source . \ --tasks 1 \ --set-env-vars TARGET_ENV =dev \ --region asia-northeast1 \ --project { プロジェクトID } ---出力例--- $ gcloud run jobs deploy run-jobs-override \ --source . \ --tasks 1 \ --set-env-vars TARGET_ENV =dev \ --region asia-northeast1 \ --project myproject This command is equivalent to running `gcloud builds submit --pack image = [ IMAGE ] .` and `gcloud run jobs deploy run-jobs-override --image [ IMAGE ] ` Building using Buildpacks and deploying container to Cloud Run job [ run-jobs-override ] in project [ myproject ] region [ asia-northeast1 ] ✓ Building and creating job... Done. ✓ Uploading sources... ✓ Building Container... Logs are available at [ https://console.cloud.google.com/cloud-build/builds/2350151f-1af8-4ef8-99b4-980ce5f761ea?project = xxxxxxxxxxxx ] . Done. Job [ run-jobs-override ] has successfully been deployed. To execute this job, use: gcloud run jobs execute run-jobs-override なお、上記のコマンドでジョブをデプロイすると、ビルドされたコンテナイメージは「cloud-run-source-deploy」という名前の Artifact Registry リポジトリに格納されます。このリポジトリがプロジェクトにまだ存在していない場合、ジョブのデプロイ時にリポジトリを新規作成するかどうか確認されます。 Deploying from source requires an Artifact Registry Docker repository to store built containers. A repository named [ cloud-run-source-deploy ] in region [ asia-northeast1 ] will be created. Do you want to continue ( Y/n ) ? Y デフォルトのジョブ構成でジョブを実行する まず、デプロイしたジョブをそのまま実行してみます。 ジョブの実行には gcloud run jobs execute コマンドを使用し、ジョブをデプロイしたリージョンのみオプションに指定して実行します。 # ジョブ構成の通りにジョブを実行する $ gcloud run jobs execute { ジョブ名 } --region asia-northeast1 ---出力例--- $ gcloud run jobs execute run-jobs-override --region asia-northeast1 ✓ Creating execution... Done. ✓ Provisioning resources... Done. Execution [ run-jobs-override-94g9h ] has successfully started running. View details about this execution by running: gcloud run jobs executions describe run-jobs-override-94g9h Or visit https://console.cloud.google.com/run/ jobs /executions/details/asia-northeast1/run-jobs-override-94g9h/tasks? project =xxxxxxxxxxxx 出力内の View details about this execution by running: に記載されている gcloud run jobs executions describe コマンドで、実行したジョブの詳細を確認します。 以下のように、並列実行タスク数（ Tasks ）、タイムアウト（ Task Timeout ）がそれぞれデフォルトの値に、 TARGET_ENV 環境変数（ Env vars: TARGET_ENV ）がデプロイ時に指定した値になっていることがわかります。 項目 値 Tasks 1 Task Timeout 600s Env vars: TARGET_ENV dev $ gcloud run jobs executions describe { ジョブの実行ID } ---出力例--- # 実行したジョブの詳細を確認する $ gcloud run jobs executions describe run-jobs-override-94g9h --region asia-northeast1 ✔ Execution run-jobs-override-94g9h in region asia-northeast1 1 task completed successfully Elapsed time: 12 seconds Log URI: https://console.cloud.google.com/logs/viewer? project =myproject& advancedFilter =resource. type %3D%22cloud_run_job% 22 %0Aresource.labels.job_name%3D%22run-jobs-override% 22 %0Aresource.labels.location%3D%22asia-northeast1% 22 %0Alabels.%22run.googleapis.com/execution_name% 22 %3D%22run-jobs-override-94g9h% 22 Image: asia-northeast1-docker.pkg.dev/myproject/cloud-run-source-deploy/run-jobs-override Tasks: 1 Memory: 512Mi CPU: 1000m Task Timeout: 600s Max Retries: 3 Parallelism: 1 Service account: xxxxxxxxxxxx-compute@developer.gserviceaccount.com Env vars: TARGET_ENV dev 出力されたジョブ詳細の Log URI: に記載されている URL から Cloud Logging のコンソールに遷移してログ出力を確認します。 タスクが 1つしか実行されていないため、コード内の fmt.Printf 関数から出力されたログは以下の 1件のみとなっています。 TASK#0 USER:unknown TARGET:dev ジョブ構成をオーバーライドしない場合の実行ログ タスクが 1つなので TASK# （タスク番号）は 0 、 TARGET_ENV 環境変数の値として TARGET が dev になっています。 USER はジョブ実行時に --user 引数を指定しなかったため、デフォルトに設定しておいた unknown になっていることがわかります。 ジョブ構成をオーバーライドしてジョブを実行する 次に、ジョブ構成をオーバーライドしてジョブを実行してみます。 以下のオプションを使用して各種パラメータをオーバーライドすることができます。 オプション 説明 --args コンテナのエントリポイントとなるコマンドに渡す引数 --update-env-vars ジョブの環境変数 （ {KEY1}={VALUE1},{KEY2}={VALUE2} の形式で指定） --tasks タスクの並列実行数 --task-timeout タスクの最大実行時間 （たとえば 10分の場合、 10m もしくは 600s の形式で指定） --user 引数に sasashun を指定し、TARGET_ENV 環境変数を prod 、並列実行タスク数を 3 、タイムアウトを 10m30s でオーバーライドしてジョブを実行します。 # ジョブ構成をオーバーライドしてジョブを実行する $ gcloud run jobs execute { ジョブ名 } \ --region asia-northeast1 \ --args =" --user=sasashun " \ --update-env-vars TARGET_ENV =prod \ --tasks 3 \ --task-timeout 10m30s ---出力例--- $ gcloud run jobs execute run-jobs-override \ --region asia-northeast1 \ --args =" --user=sasashun " \ --update-env-vars TARGET_ENV =prod \ --tasks 3 \ --task-timeout 10m30s ✓ Creating execution... Done. ✓ Provisioning resources... Done. Execution [ run-jobs-override-cd2f8 ] has successfully started running. View details about this execution by running: gcloud run jobs executions describe run-jobs-override-cd2f8 Or visit https://console.cloud.google.com/run/ jobs /executions/details/asia-northeast1/run-jobs-override-cd2f8/tasks? project =xxxxxxxxxxxx gcloud run jobs executions describe コマンドで実行したジョブの詳細を確認します。 出力例にあるように、実行時にオーバーライドした値が反映されていることがわかります。 項目 ジョブ構成の値 オーバーライドした値 Tasks 1 3 Task Timeout 600s 10m30s Env vars: TARGET_ENV dev prod # 実行したジョブの詳細を確認する $ gcloud run jobs executions describe run-jobs-override-cd2f8 --region asia-northeast1 ---出力例--- $ gcloud run jobs executions describe run-jobs-override-cd2f8 --region asia-northeast1 ✔ Execution run-jobs-override-cd2f8 in region asia-northeast1 3 tasks completed successfully Elapsed time: 18 seconds Log URI: https://console.cloud.google.com/logs/viewer? project =myproject& advancedFilter =resource. type %3D%22cloud_run_job% 22 %0Aresource.labels.job_name%3D%22run-jobs-override% 22 %0Aresource.labels.location%3D%22asia-northeast1% 22 %0Alabels.%22run.googleapis.com/execution_name% 22 %3D%22run-jobs-override-cd2f8% 22 Image: asia-northeast1-docker.pkg.dev/myproject/cloud-run-source-deploy/run-jobs-override Tasks: 3 Args: --user = sasashun Memory: 512Mi CPU: 1000m Task Timeout: 10m30s Max Retries: 3 Parallelism: 3 Service account: xxxxxxxxxxxx-compute@developer.gserviceaccount.com Env vars: TARGET_ENV prod ジョブ詳細の Log URI: に記載されている URL から Cloud Logging のコンソールに遷移してログ出力を確認します。 オーバーライドされたタスク数である 3タスクが実行され、 --user 引数と TARGET_ENV 環境変数の値がジョブに反映されていることがわかります。 TASK#0 USER:sasashun TARGET:prod TASK#1 USER:sasashun TARGET:prod TASK#2 USER:sasashun TARGET:prod ジョブ構成をオーバーライドした場合の実行ログ トラブルシューティング (CLI) ジョブ構成のオーバーライドは 2023年 10月に GA となった機能であり、使用している gcloud CLI のバージョンによっては各種オプションが指定できない場合があります。 gcloud CLI のバージョンが古くオプションが指定できない場合、以下のようなエラーメッセージが出力されます。 ERROR: ( gcloud.run. jobs .execute ) unrecognized arguments: --args flag is available in one or more alternate release tracks. Try: gcloud alpha run jobs execute --args gcloud beta run jobs execute --args --args = --user = sasashun ( did you mean ' --async ' ? ) このようなエラーにより CLI からのジョブ実行が上手くいかない場合、まずは gcloud run jobs execute --help でオーバーライドに関するオプション（ --args など）が表示されているか確認してください。 # 使用できるオプションを確認する $ gcloud run jobs execute --help NAME gcloud run jobs execute - qexecute a job SYNOPSIS gcloud run jobs execute [ JOB ] [ --args =[ ARG,... ]] [ --region = REGION ] [ --task-timeout = TASK_TIMEOUT ] [ --tasks = TASKS ] [ --update-env-vars =[ KEY = VALUE ,... ]] [ --async | --wait ] [ GCLOUD_WIDE_FLAG ... ] ~~~以下省略~~~ オプションが無い場合、使用している gcloud CLI のバージョンによっては gcloud bata run jobs execute もしくは gcloud alpha run jobs execute コマンドでオプションを指定して実行することができますが、可能であれば gcloud CLI をアップグレードすることを推奨します。 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。2023年10月のイチオシ Google Cloud アップデートをまとめてご紹介します。記載は全て、記事公開当時のものですのでご留意ください。 はじめに Looker Studio と BigQuery のさらなる統合 (Private Preview) Cloud SQL で異エディション間でバックアップ→リストアが可能に Looker Studio Pro がユーザ単位で利用可能に BigQuery のリージョン間テーブルコピーが Private Preview 一部リージョンの Spanner がパフォーマンス改善 Colab Enterprise が Preview -> GA Cloud Domains の一部機能が廃止 Regional external Application Load Balancer で Cloud Armor が使用可能に プロジェクト管理者が予算アラートを作れるように (Preview => GA) BigQuery change data capture (CDC) が Preview => GA Cloud Run jobs の実行時のジョブ設定オーバーライドが Preview => GA はじめに 月ごとの Google Cloud アップデートのうち、特にイチオシなものをまとめています。 ある程度の事前知識が必要な記載となっています。サービスごとの前提知識は、ぜひ以下の記事もご参照ください。 blog.g-gen.co.jp またリンク先の公式ガイドは英語版にしないと最新情報が反映されていない場合がありますためご注意ください。 Looker Studio と BigQuery のさらなる統合 (Private Preview) BigQuery native integration in Looker Studio preview (2023/10/02) Looker Studio と BigQuery の間で INFORMATION_SCHEMA 、 execution graph 、 Cloud Monitoring メトリクス との統合が強化。BigQuery のシステムビューである INFORMATION_SCHEMA.JOBS には looker_studio_report_id や looker_studio_datasource_id が記録されるようになる。 すなわち、どの Looker Studioレポートからクエリが発行されたかが分かるようになった。 どのレポートがどのくらい課金に影響しているか、の可視化が容易になる。 Cloud SQL で異エディション間でバックアップ→リストアが可能に About restoring an instance (2023/10/02) Cloud SQL で異なるエディション間 (Enterprise <-> Enterprise Plus) でバックアップ→リストアが可能になった。 既存の Enterprise インスタンスを容易に Enterprise Plus にアップグレードする一つの手段として考えられる。 Looker Studio Pro がユーザ単位で利用可能に Looker Studio release notes (2023) - October 2, 2023 (2023/10/02) Looker Studio Pro がユーザ単位で利用可能になった。従来は「組織単位で有効化」のみであり、MAU 全員に課金されてしまった（MAU = Monthly Active User）。 料金は $9 / user / month。 さらに従来はオフラインオーダー（都度、営業を介して注文）だったが、、コンソールからユーザ自身で Looker Studio Pro へアップグレード可能になった。 Looker Studio Pro の詳細な解説は以下を参照。 blog.g-gen.co.jp BigQuery のリージョン間テーブルコピーが Private Preview リージョン間でテーブルをコピーする (2023/10/04) BigQuery でテーブルのリージョン間コピーが Private Preview に。 Private Preview のため、利用には申込みが必要。 これまでは同一リージョン間でしかテーブルをコピーできないため BigQuery Data Transfer Service を使うなど工夫する必要があった。 一部リージョンの Spanner がパフォーマンス改善 Cloud Spanner is now half the cost of Amazon DynamoDB, and with strong consistency and single-digit ms latency (2023/10/12) 大阪リージョンを含む一部のリージョンの Spanner が、コスト据え置きのままパフォーマンスが向上。Read & Write の QPS が従来の 1.5 倍になる。 対象リージョンは大阪、台湾、ムンバイ、オランダ等で、今後拡大予定。 Cloud Spanner の詳細な解説は以下を参照。 blog.g-gen.co.jp Colab Enterprise が Preview -> GA Introduction to Colab Enterprise (2023/10/11) Colab Enterprise が Preview -> GAに。 Colab Enterprise はフルマネージドな Notebook。Vertex AI や BigQuery とのシームレスな統合や Duet AI によるコーディング補助などが最低限の管理コストで手に入る。類似サービスで Vertex AI Workbench がある。 なお Colab Enterprise と Vertex AI Workbench のどちらを選ぶかは 公式ドキュメント )に以下のように記載されている。 Colab Enterprise: 優先事項が他のユーザーとコラボレーションし、インフラストラクチャの管理に時間を費やすことを避けることである場合、Colab Enterprise が最適な選択肢となる可能性があります。 Vertex AI Workbench: 優先事項が制御とカスタマイズ性である場合、Vertex AI Workbench が最適な選択肢となる可能性があります。 Cloud Domains の一部機能が廃止 Cloud Domains feature deprecation (2023/10/20) Squarespace 社が Google Domains を買収したため Google Cloud プロダクトである Cloud Domains も影響を受ける。 ドメインの管理機能は引き続き利用できるが、主に DNS 関連機能が影響を受ける。以下のドキュメントで、いつ何の機能が影響されるのか確認可能。 参考 : Cloud Domains feature deprecation Regional external Application Load Balancer で Cloud Armor が使用可能に Regionally scoped security policies (2023/10/20) Cloud Armor (Google Cloud のフルマネージド WAF) が Regional external Application Load Balancer でも使えるようになった (Preview => GA)。 これまで Cloud Armor は Global なロードバランサでしか利用できなかったが、今後はネットワーク料金を抑えつつWebアプリをセキュアにできる。 プロジェクト管理者が予算アラートを作れるように (Preview => GA) Create, edit, or delete budgets and budget alerts (2023/10/23) プロジェクト管理者・編集者が予算アラートを作れるように (Preview => GA)。 これまでは「請求先アカウント管理者」でないと予算アラートが作れなかったが、今後はプロジェクトレベルで予算アラートが作成できるようになった。 請求先アカウントの仕組みについては以下を参照。 blog.g-gen.co.jp BigQuery change data capture (CDC) が Preview => GA Stream table updates with change data capture (2023/10/31) BigQuery change data capture (CDC) が Preview => GA。 BigQuery にリアルタイムでデータを流し込む際、複雑な MERGE 構文を使わなくとも UPSERT/DELETE を含む更新が可能に。 max_staleness 設定により反映インターバルを調整し、パフォーマンス調整も可能。 ※名称から誤解しやすいが BigQuery のデータ変更をキャプチャする仕組み、ではないため注意。 Cloud Run jobs の実行時のジョブ設定オーバーライドが Preview => GA Override job configuration for a specific execution (2023/10/31) Cloud Run jobs が、ジョブ実行にジョブ設定をオーバーライドできるように（Preview => GA）。オーバーライド可能なパラメータは以下の 4つ。 コンテナのエントリポイントとなるコマンドに渡す引数 環境変数 タスク並列実行数 タスクのタイムアウト 当アップデートは以下の記事で詳細に解説している。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Cloud Run 上のアプリケーションで Cloud SQL Auth Proxy を使って Cloud SQL へ接続する際に接続が失敗した事象と、その対策について解説します。 はじめに 前提知識 各種サービスについて Cloud Run から Cloud NAT を使用するケース 事象 発生した事象 想定していた通信経路 実際の通信経路 原因 解決策 余談 はじめに Cloud Run 上のアプリケーションから Cloud SQL への接続に Cloud SQL Auth Proxy を利用している状況において、意図せず通信が Cloud NAT を経由してしまったことにより、Cloud NAT のポート数上限に抵触して DB 接続が失敗する事象がおきました。 その原因と対策について解説します。 前提知識 各種サービスについて 当記事内に出てくる各種サービスの内容については説明を割愛します。 それぞれ以下の記事で詳細に解説されているので、こちらをご一読ください。 ■ Cloud Run blog.g-gen.co.jp ■ Cloud SQL blog.g-gen.co.jp ■ Cloud NAT blog.g-gen.co.jp Cloud Run から Cloud NAT を使用するケース Cloud Run ではサーバーレスの仕様により、処理を行っていないときはインスタンスを終了してインフラリソースを解放してしまうため、インスタンスが使用する IP アドレスは都度変わってしまいます。 Cloud Run 上のアプリケーションから アクセス元 IP を制限するような外部サービスに接続する必要がある場合 には、Cloud Run からインターネットへのアウトバウンド接続は Cloud NAT を経由するようにすることで、接続元 IP アドレスを Cloud NAT の静的 IP アドレスに固定できます。 Cloud Run から Cloud NAT のような VPC リソースにアクセスするためには、 サーバーレス VPC アクセス を構成する必要があります。詳細は以下の記事で解説しています。 blog.g-gen.co.jp 事象 発生した事象 ある Cloud Run 上のアプリケーションは、Cloud NAT を経由して外部サービスの API にアクセスする必要があります。外部サービス側で接続元 IP アドレスをホワイトリスト制限しているため、Cloud NAT を経由することで接続元 IP を固定したいためです。 またそのアプリケーションはデータベースとして Cloud SQL を利用しており、Cloud SQL への認証をシンプルにするため Cloud SQL Auth Proxy を使っていました。 このアプリにおいて、リリースに向けた負荷試験を実施したとき、以下のようなエラーメッセージが出力されました。 "Cloud SQL connection failed. Please see https://cloud.google.com/sql/docs/mysql/connect-run for additional details: connection to Cloud SQL instance at {Cloud SQLインスタンスのパブリックIP}:3307 failed: timed out after 10s" 想定していた通信経路 この構成で当初想定していた通信経路は以下のようなものでした。 Cloud Run から Cloud SQL と Cloud NAT に接続する構成（想定しているもの） サーバーレス VPC アクセスのコネクタインスタンスは、負荷によってスケールアウトすると、その後一切スケールインできない仕様があります（スケールインするためには作り直しが必要です）。 そのためサーバーレス VPC アクセスは外部 API へのアクセスのみで使用し、Cloud SQL への接続は Cloud SQL Auth Proxy を使用してパブリック IP で接続したいと考えていました。Cloud SQL Auth Proxy を使うと接続先は Cloud SQL のパブリック IP アドレスとなるため、直感的には Cloud Run から Cloud SQL への接続は VPC (サーバーレス VPC アクセス) を通らず、直接 Cloud SQL に届くようなイメージでした。 実際の通信経路 しかしその想定は、実際には異なっていました。前述のエラーメッセージが出力されたことから詳細に調べた結果、実際の通信経路は以下のようなものでした。 実際の通信経路 Cloud Run から Cloud SQL にパブリック IP で直接接続してほしかったのですが、実際には サーバーレス VPC アクセスのコネクタインスタンスと Cloud NAT を経由して 接続されていました。 これにより、想定していなかった負荷がコネクタインスタンスや Cloud NAT にかかってしまい、コネクタインスタンスのリソース不足や Cloud NAT のポート数制限などがデータベース接続に影響を及ぼしていました。 原因 Cloud SQL への通信がサーバーレス VPC アクセスと Cloud NAT を経由してしまう原因は、Cloud Run から送信されるトラフィックのルーティングの仕様にあります。 Cloud Run でサーバーレス VPC アクセスを使用する際、どのトラフィックをサーバーレス VPC アクセスコネクタに送信するかを設定する項目があります。外部 API のようなパブリック IP へのリクエストを Cloud NAT 経由で行うには、ここで「 すべてのトラフィックを VPC にルーティングする 」を選択する必要があります。 Cloud Run のアウトバウンド通信をすべてサーバーレス VPC アクセスコネクタに送信する設定 これにより、Cloud Run は全てのアウトバウンド通信を VPC へルーティングしてしまい、よって Auth Proxy を使った Cloud SQL への通信であっても、Cloud NAT 経由となってしまったのでした。 Cloud Run の仕様からすると当然の挙動なのですが、Cloud SQL Auth Proxy を使うことで Cloud SQL に直接接続すると直感的に感じてしまったことが、原因へ気がつくことを遅らせました。 解決策 仕様上、Cloud SQL に対する通信だけを Cloud NAT を使わない直接通信とすることはできません。 妥協案となってしまいますが、すべての通信がサーバーレス VPC アクセスコネクタを経由することは許容し、プライベート IP を使用して Cloud SQL に接続することで、データベース接続が Cloud NAT を経由してしまうことを防ぐことができます。 これにより、少なくとも Cloud NAT の上限に抵触することでデータベース接続が失敗してしまうような状況は回避できます。 Cloud SQL への接続にプライベート IP を使用し、Cloud NAT を経由しないようにする 余談 Cloud NAT 同様、Cloud Run からの接続にサーバーレス VPC アクセスが必要となるサービスとして Memorystore などがありますが、こちらはプライベート IP 接続以外の選択肢がないため、Cloud Run で「プライベート IP へのリクエストのみを VPC にルーティングする」の設定がされていれば、Cloud SQL への接続はパブリック IP で行うことが可能です。 プライベート IP へのアウトバウンド接続のみサーバーレス VPC アクセスコネクタに送信する設定 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。 Follow @sasashun0805

G-gen の佐々木です。当記事では Cloud Run や Cloud Functions などで使用する サーバーレス VPC アクセス のコネクタインスタンスで発生するメンテナンスと、それに関する注意点を記載します。 はじめに 前提知識 サーバーレス VPC アクセスとは コネクタインスタンスのスケーリングについて コネクタインスタンスのメンテナンス メンテナンス時に何が起こるのか メンテナンスの注意点 はじめに 長期起動とする Cloud Run サービスがサーバーレス VPC アクセスを使う場合は、コネクタインスタンスの突発メンテナンスに備えて、データベース接続断を検知して再接続を行う処理をアプリケーション側に実装する必要があります。 その理由と仕組みについて、詳述していきます。 前提知識 サーバーレス VPC アクセスとは サーバーレス VPC アクセス とは、Cloud Run、Cloud Functions、Google App Engine（Standard 環境）などのサーバーレスなサービスがプライベート IP を使用して VPC 内リソースに接続するための方法です。 サーバーレス VPC アクセスでは、各種サービスから接続したい VPC に サーバーレス VPC アクセスコネクタ と呼ばれるインスタンス（以下、 コネクタインスタンス ）を作成します。このコネクタインスタンスを経由することで、Compute Engine VM や Cloud SQL などの VPC 内リソースにプライベート IP で接続することができるようになります。 参考 : Serverless VPC Access サーバーレス VPC アクセスを使用した Cloud SQL への接続例 Cloud Run では、VPC 内リソースにプライベート IP で接続する方法として、サーバーレス VPC アクセスのほかに Direct VPC Egress があります。Direct VPC Egress の詳細、およびサーバーレス VPC アクセスとの違いについては以下の記事をご一読ください。 blog.g-gen.co.jp コネクタインスタンスのスケーリングについて サーバーレス VPC アクセスでは、VPC に接続するために作成するコネクタインスタンスの最小数（2~9）と最大数（3~10）をあらかじめ設定します。 コンテナインスタンスの負荷が高まると、最大で設定した値までインスタンスがスケールアウトしますが、その後負荷が解消されてもインスタンスがスケールインすることはありません。 たとえば、最小数 2、最大数 5の設定でコンテナインスタンスが 5までスケールアウトすると、その後インスタンスの数が 4以下にスケールインすることはありません。インスタンス数を減らしたい場合、サーバーレス VPC アクセスを再設定（削除→新規作成）する必要があります。 コネクタインスタンスのメンテナンス メンテナンス時に何が起こるのか サーバーレス VPC アクセスにおけるコネクタインスタンスの裏側では Compute Engine VM インスタンスが実行されており、Google によるセキュリティアップデートなどのメンテナンスが数分間行われる場合があります。 メンテナンスが発生すると、利用できるコネクタインスタンスの数を維持するために、 最大数に設定されているコネクタインスタンス数を一時的に超過してスケールアウトする場合 があります。 参考 : Throughput and scaling たとえば、コネクタインスタンスの数が 3つであり、それが設定している最大数だった場合、メンテナンス時にインスタンス数が 6までスケールアウトする可能性があります。メンテナンスが終了すると、インスタンスの数は 3にスケールインされます。 したがって、 コネクタインスタンスのメンテナンス時には、設定値を超過するスケールアウトと本来起こらないはずのスケールインが起こる 可能性があります。Cloud Monitoring などの監視ツールで、メンテナンス時の一時的なインスタンス数増加を確認することができます。 メンテナンスの注意点 メンテナンス時に発生するスケールアウトは、利用可能なコネクタインスタンスの数を保ち、コネクタインスタンスを使用するサービスが中断しないようにするための仕様です。しかし、これまで接続していたメンテナンス対象のインスタンスに接続できなくなることで、サービス中断が発生する可能性があります。 以下の例では、Cloud Run 上のアプリケーションからサーバーレス VPC アクセスを使用して Cloud SQL に接続しています。 サーバーレス VPC アクセスを使用した Cloud SQL への接続 メンテナンスが発生してコネクタインスタンスがスケールアウトし、元々あったインスタンスに接続できなくなったとします。 このとき、Cloud Run 上のアプリケーションから Cloud SQL への接続を維持できず、サービス中断が発生する可能性があります。 メンテナンスによるコネクタインスタンスのスケールアウト サービス中断を防ぐためには、データベース接続のエラーを検知して再接続を行う処理をアプリケーション側に実装する必要があります。 再接続により正常なコネクタインスタンスへの接続が行われ、Cloud SQL への接続を継続することができます。 再接続ロジックにより新しいコネクタインスタンスに接続する 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の杉村です。BigQuery の特殊な GROUP BY 構文である GROUP BY GROUPING SETS GROUP BY CUBE GROUP BY ROLLUP について解説します。 はじめに GROUP BY GROUPING SETS GROUP BY CUBE GROUP BY ROLLUP はじめに BigQuery で以下の特殊な GROUP BY 構文が、2023年10月9日に Preview 公開、2024年2月26日に一般公開（GA）されました。 GROUP BY GROUPING SETS GROUP BY CUBE GROUP BY ROLLUP (以前からあったが groupable items sets を指定できるようになった) これらの構文は他の分析用データベース製品でも一般的なものです。改めて、どのように使うのかを確認してみました。 参考 : Group rows by GROUPING SETS 参考 : Group rows by CUBE 参考 : Group rows by ROLLUP GROUP BY GROUPING SETS GROUP BY GROUPING SETS は GROUP BY 句で列を複数指定して、それぞれの集計結果を合わせて一つの結果として返すための構文です。 実例を見てみましょう。 WITH Products AS ( SELECT ' shirt ' AS product_type, ' t-shirt ' AS product_name, 3 AS product_count UNION ALL SELECT ' shirt ' , ' t-shirt ' , 8 UNION ALL SELECT ' shirt ' , ' polo ' , 25 UNION ALL SELECT ' pants ' , ' jeans ' , 6 ) SELECT product_type, product_name, SUM (product_count) AS product_sum FROM Products GROUP BY GROUPING SETS (product_type, product_name) ORDER BY product_name; 出力結果 product_type product_name product_sum shirt ( null ) 36 pants ( null ) 6 ( null ) jeans 6 ( null ) polo 25 ( null ) t-shirt 11 このように、異なる列をキーとした集計結果が一つの結果テーブルとなって返ってきました。使わない列には null が入っています。つまり出力結果には product_type ごとの集計 (product_name 列が null ) product_name ごとの集計 (product_type 列が null ) が入っています。 これは、以下のように通常の GROUP BY を使った集計クエリを2つ実行して UNION ALL した結果と全く同じです。 WITH Products AS ( SELECT ' shirt ' AS product_type, ' t-shirt ' AS product_name, 3 AS product_count UNION ALL SELECT ' shirt ' , ' t-shirt ' , 8 UNION ALL SELECT ' shirt ' , ' polo ' , 25 UNION ALL SELECT ' pants ' , ' jeans ' , 6 ) SELECT product_type, NULL AS product_name, SUM (product_count) AS product_sum FROM Products GROUP BY product_type UNION ALL SELECT NULL AS product_type, product_name, SUM (product_count) AS product_sum FROM Products GROUP BY product_name ORDER BY product_name; GROUP BY CUBE GROUP BY CUBE は GROUP BY 句で複数列を指定し、指定された全ての列の全ての組み合わせの集計結果を返す構文です。 WITH Products AS ( SELECT ' shirt ' AS product_type, ' t-shirt ' AS product_name, 3 AS product_count UNION ALL SELECT ' shirt ' , ' t-shirt ' , 8 UNION ALL SELECT ' shirt ' , ' polo ' , 25 UNION ALL SELECT ' pants ' , ' jeans ' , 6 ) SELECT product_type, product_name, SUM (product_count) AS product_sum FROM Products GROUP BY CUBE (product_type, product_name) ORDER BY product_type, product_name; 出力結果 product_type product_name product_sum ( null ) ( null ) 42 ( null ) jeans 6 ( null ) polo 25 ( null ) t-shirt 11 pants ( null ) 6 pants jeans 6 shirt ( null ) 36 shirt polo 25 shirt t-shirt 11 出力結果には 全ての行の集計 (product_name 列も product_type 列も null ) product_name ごとの集計 (product_type 列が null ) product_type ごとの集計 (product_name 列が null ) product_type + product_name の集計 ( null が無い) が含まれています。つまり GROUP BY CUBE (product_type, product_name) の括弧内で指定した列 (+ 列なし) の全ての組み合わせで集計をしています。 GROUP BY ROLLUP GROUP BY ROLLUP は集計に使う列を複数指定して、その列で合計結果を積み上げて一つの結果として返す構文です。 実例を見てみましょう。 WITH Products AS ( SELECT ' shirt ' AS product_type, ' t-shirt ' AS product_name, 3 AS product_count UNION ALL SELECT ' shirt ' , ' t-shirt ' , 8 UNION ALL SELECT ' shirt ' , ' polo ' , 25 UNION ALL SELECT ' pants ' , ' jeans ' , 6 ) SELECT product_type, product_name, SUM (product_count) AS product_sum FROM Products GROUP BY ROLLUP (product_type, product_name) ORDER BY product_type, product_name; 出力結果 product_type product_name product_sum ( null ) ( null ) 42 pants ( null ) 6 pants jeans 6 shirt ( null ) 36 shirt polo 25 shirt t-shirt 11 出力結果には 全ての行の合計 (product_name 列も product_type 列も null ) product_type ごとの集計 (product_name 列が null ) product_type + product_name の集計 ( null が無い) が含まれています。考え方としては「積み上げ」で、細かい集計から次々により大きい項目へ集計している、と考えることができます。 次の例のほうが分かりやすいかもしれません (数字はでたらめです)。 WITH cities AS ( SELECT ' 日本 ' AS nation, ' 東京 ' AS prefecture, ' 新宿区 ' AS city, 100 AS population UNION ALL SELECT ' 日本 ' , ' 東京 ' , ' 豊島区 ' , 80 UNION ALL SELECT ' 日本 ' , ' 東京 ' , ' 品川区 ' , 50 UNION ALL SELECT ' 日本 ' , ' 埼玉県 ' , ' ふじみ野市 ' , 60 UNION ALL SELECT ' 日本 ' , ' 埼玉県 ' , ' さいたま市 ' , 70 UNION ALL SELECT ' アメリカ合衆国 ' , ' カリフォルニア州 ' , ' サンディエゴ市 ' , 50 ) SELECT nation, prefecture, city, SUM (population) AS population_sum FROM cities GROUP BY ROLLUP (nation, prefecture, city) ORDER BY prefecture, city; 出力結果 nation prefecture city population_sum ( null ) ( null ) ( null ) 410 日本 ( null ) ( null ) 360 アメリカ合衆国 ( null ) ( null ) 50 アメリカ合衆国 カリフォルニア州 ( null ) 50 アメリカ合衆国 カリフォルニア州 サンディエゴ市 50 日本 埼玉県 ( null ) 130 日本 埼玉県 さいたま市 70 日本 埼玉県 ふじみ野市 60 日本 東京 ( null ) 230 日本 東京 品川区 50 日本 東京 新宿区 100 日本 東京 豊島区 80 GROUP BY ROLLUP (nation, prefecture, city) の括弧の中で指定したのと逆順に、積み上げて合計しています。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

当記事では Atlantis を使って GitHub のプルリクエスト上で Terraform を実行する方法を紹介します。 当記事で扱うツール Terraform 概要 ローカルから実行する場合の注意点 自動化ツール Atlantis 概要 アーキテクチャ 構築方法 ロック機能と Web UI 構築にあたり アーキテクチャ 前提と注意点 事前準備 GitHub App の作成 Terraform ファイル Atlantis サーバーの構築 Terraform の実行 動作確認 サービスアカウントへ権限付与 プルリクエストを作成 適用 当記事で扱うツール Terraform 概要 Terraform は Infrastructure as Code (IaC) を実現する OSS のツールです。 IT インフラをコードによって構築、管理し CI/CD (継続的インテグレーション / 継続的デリバリ) を可能にします。IT インフラをコードで定義できることのメリットの１つとして、Git によるバージョン管理ができる点が挙げられます。 Terraform を Google Cloud で使う際は、以下の記事をご参照ください。 blog.g-gen.co.jp ローカルから実行する場合の注意点 複数のエンジニアによって開発される場合、どこから Terraform を実行するか注意が必要です。 例えばそれぞれのローカルマシンから Terraform を実行する運用では、ヒューマンエラーによる実行ミスのリスクや実行結果の履歴が残らない等の課題があり、チームでの作業の見える化や過去の変更を追いにくくなる恐れがあります。 自動化ツール Terraform 実行の自動化ツールとして、当記事で紹介する Atlantis の他にも Terraform Cloud や GitHub Actions 等があります。 Atlantis ではプルリクエスト上で Terraform の実行ができるため、前述のローカルマシンから実行する時に生じる課題を解消できます。 GitHub Actions を使った自動化は以下の記事をご参照ください。 blog.g-gen.co.jp Atlantis 概要 Atlantis は プルリクエストを使って Terraform の実行を自動化する OSS ツールです。 以下のように、プルリクエストを作成すると自動で terraform plan が実行され、実行結果がプルリクエストのコメントに記載されます。 そのプルリクエストで atlantis apply をコメントすると terraform apply が実行され、その結果が同じようにコメントに記載されます。 実行イメージ ( 公式ドキュメント より引用) また、 atlantis コマンドの実行条件 (main ブランチへマージ可能な状態であることやプルリクエストが Approve されていること等) を定義できます。 例えば、Terraform で IT インフラを構築する際に、 terraform plan は通ったとしても terraform apply で失敗することもあります。 GitHub でコードを管理している場合に、 terraform plan が通ったものを main ブランチにマージして terraform apply を実行するような運用フローでは、 terraform apply で失敗した時に再度ブランチを切るなど手戻りが発生します。 Atlantis では、プルリクエストのコメント上で Terraform の実行ができるため、実環境へ適用されたものを main ブランチにマージすることができ手戻りが発生しにい等のメリットもあります。 アーキテクチャ Atlantis は以下のように動作します。 アーキテクチャ Atlantis は セルフホスト型 のため、自身で Atlantis サーバーを構築しなければなりません。 Google Cloud の場合、Compute Engine と Google Kubernetes Engine のモジュールが提供されているため、必要な設定を入れるだけで容易に構築ができます。 当記事では 公式から提供されているモジュール を使って Compute Engine 上に Atlantis サーバーを構築し、動作を確認します。 参考： Deployment 構築方法 基本的には公式の インストールガイド に従って構築します。 Git Host のアクセス資格情報を作成 アクセス資格情報は Atlantis が Git Host の API を呼び出す際に使います Git Host には GitHub や GitLab 等が使えます GitHub を Git Host として使う場合、Personal Access Token (PAT) ではなく GitHub App が推奨されます Webhook Secret を作成 Atlantis が Git Host からの Webhook が正しいものかを判別するために設定します ２４文字以上である必要があります Atlantis サーバーを構築 Webhook を構成 Git Host に GitHub、アクセス資格情報に GitHub App を使っている場合は Webhook が自動生成されるため不要です プロバイダーの資格情報を構成 Google Cloud の場合、Atlantis サーバーを構築する基盤 (Compute Engine 等) のサービスアカウントが使われます ロック機能と Web UI Atlantis は、Terraform の ロック機能 とは別に独自のロック機能を持っています。 複数のプルリクエストが同一のディレクトリや Terraform Workspaces を変更している場合、最初のプルリクエストがマージされるまで他のプルリクエストの変更は実行できないようになっています。 Atlantis は Web UI も提供しており、ここからロックの確認や解除ができます。 Web UI 但し、この Web UI にはデフォルトでは認証機能がありません。 そのため、Atlantis がデプロイされるとインターネット上からこの Web UI が閲覧できてしまいセキュリティリスクが高まります。 Atlantis からは Basic 認証 が提供されており、また Google Cloud の場合は Identity-Aware Proxy (IAP) と組み合わせることで閲覧制限がかけられます。 また、このロック機能の実現には外部データベース (永続ディスク) が必要です。 Atlantis は外部データベースに terraform plan やプルリクエストのマージ情報などを保存します。 当記事で使う モジュール でも Compute Engine に永続ディスクがアタッチされています。 以下は atlantis apply をした時にプルリクエストのコメントに記載されたエラーログです。Atlantis は /home/atlantis/.atlantis 配下に情報を保存しています。 running " /usr/local/bin/terraform apply -input=false -no-color \" /home/atlantis/.atlantis/repos/REPO_OWNER/REPO_NAME/5/default/default.tfplan \" " in " /home/atlantis/.atlantis/repos/REPO_OWNER/REPO_NAME/5/default " : exit status 1 google_compute_network.vpc_network: Creating... Error: Error creating Network: googleapi: Error 409: The resource ' projects/PROJECT_ID/global/networks/atlantis-vpc ' already exists, alreadyExists with google_compute_network.vpc_network, on main.tf line 12 , in resource " google_compute_network " " vpc_network " : 12: resource " google_compute_network " " vpc_network " { 構築にあたり アーキテクチャ 当記事で作成する構成と、Atlantis サーバーによって作られるリソースは以下の通りです。 アーキテクチャ 前提と注意点 当記事では検証目的のため簡易的な構成としています。本番運用する際は、以下の前提と注意点を踏まえて構築してください。 提供されているモジュール の examples/complete を使用します examples/complete/main.tf では 106 行目 で Cloud DNS へ Cloud Load Balancing の IP アドレスを A レコードに登録しています そのため、既にドメインを取得しており、Cloud DNS でゾーンを管理していることが前提となります Web UI の認証はかけていません 前述の通り、Atlantis には Web UI が提供されますが当記事では認証を設定していません examples/complete/main.tf は以下の点を踏まえ一部変更します Git Host アクセス資格情報 に Personal Access Token (PAT) ではなく GitHub App を使用します (PAT は個人に紐づく点や有効期限がある等の観点から望ましくありません) GitHub App の Private Key を main.tf の local 変数として記載していますが、実際はセキュリティ上の観点から Secret Manager 等で管理することが推奨されます 事前準備 GitHub App の作成 ドキュメント に従って GitHub App を作り、対象のリポジトリへインストールします。 固有の設定箇所は以下の通りです。 項目 設定値 備考 Webhook URL https:// ドメイン名>/events Atlantis は Webhook を /events で受け付ける Webhook secret (optional) 24 文字以上 の任意の文字列 Permissions Administration : Read-only Checks : Read and write Commit statuses : Read and write Contents : Read and write Issues : Read and write Metadata : Read-only (default) Pull requests : Read and write Webhooks : Read and write Members : Read-only ドキュメント に記載 Subscribe to events Check run / Create / Delete / Issue comment / Issues / Pull request / Pull request review / Pull request review comment / Push Atlantis によって自動生成 した際の項目を手動でも設定 作成後、Private keys を生成します。 GitHub App の App ID、Installations ID、Private keys は Terraform で使います。 参考： Git Host Access Credentials Terraform ファイル 公式モジュールの main.tf を以下のように変更します。 # main.tf locals { project_id = "<your-project-id>" region = "<your-region>" zone = "<your-zone>" domain = "<example.com>" managed_zone = "<your-managed-zone>" github_repo_allow_list = "github.com/<repo-owner>/<repo-name>" github_app_id = "<your-github-app-id>" github_app_installation_id = "<your-github-app-installation-id>" github_webhook_secret = "<your-github-webhook-secret>" github_app_key = <<-EOT -----BEGIN RSA PRIVATE KEY----- <your-github-app-private-key> -----END RSA PRIVATE KEY----- EOT services = toset ( [ "compute.googleapis.com" , ] ) } # Enable APIs resource "google_project_service" "service" { for_each = local.services project = local.project_id service = each.value disable_dependent_services = false disable_on_destroy = false } # Create a service account and attach the required Cloud Logging permissions to it resource "google_service_account" "atlantis" { account_id = "atlantis-sa" display_name = "Service Account for Atlantis" project = local.project_id } resource "google_project_iam_member" "atlantis_log_writer" { role = "roles/logging.logWriter" member = "serviceAccount:$ { google_service_account.atlantis.email } " project = local.project_id } resource "google_project_iam_member" "atlantis_metric_writer" { role = "roles/monitoring.metricWriter" member = "serviceAccount:$ { google_service_account.atlantis.email } " project = local.project_id } resource "google_compute_network" "default" { name = "example-network" auto_create_subnetworks = false project = local.project_id } resource "google_compute_subnetwork" "default" { name = "example-subnetwork" ip_cidr_range = "10.2.0.0/16" region = local.region network = google_compute_network.default.id project = local.project_id private_ip_google_access = true log_config { aggregation_interval = "INTERVAL_5_SEC" flow_sampling = 0 . 5 metadata = "INCLUDE_ALL_METADATA" } } # Create a router, which we associate the Cloud NAT too resource "google_compute_router" "default" { name = "example-router" region = google_compute_subnetwork.default.region network = google_compute_network.default.name bgp { asn = 64514 } project = local.project_id } # Create a NAT for outbound internet traffic resource "google_compute_router_nat" "default" { name = "example-router-nat" router = google_compute_router.default.name region = google_compute_router.default.region nat_ip_allocate_option = "AUTO_ONLY" source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES" project = local.project_id } module "atlantis" { source = "bschaatsbergen/atlantis/gce" name = "atlantis" network = google_compute_network.default.name subnetwork = google_compute_subnetwork.default.name region = local.region zone = local.zone service_account = { email = google_service_account.atlantis.email scopes = [ "cloud-platform" ] } # Note: environment variables are shown in the Google Cloud UI # See the `examples/secure-env-vars` if you want to protect sensitive information env_vars = { ATLANTIS_ATLANTIS_URL = "https://$ { local.domain } " ATLANTIS_REPO_ALLOWLIST = local.github_repo_allow_list ATLANTIS_WRITE_GIT_CREDS = true ATLANTIS_REPO_CONFIG_JSON = jsonencode ( yamldecode ( file ( "$ { path.module } /server-atlantis.yaml" ))) ATLANTIS_GH_APP_ID = local.github_app_id ATLANTIS_GH_INSTALLATION_ID = local.github_app_installation_id ATLANTIS_GH_WEBHOOK_SECRET = local.github_webhook_secret ATLANTIS_GH_APP_KEY = local.github_app_key } domain = local.domain project = local.project_id } # As your DNS records might be managed at another registrar's site, we create the DNS record outside of the module. # This record is mandatory in order to provision the managed SSL certificate successfully. resource "google_dns_record_set" "default" { name = "$ { local.domain } ." type = "A" ttl = 60 managed_zone = local.managed_zone rrdatas = [ module.atlantis.ip_address ] project = local.project_id } resource "google_compute_ssl_policy" "default" { name = "example-ssl-policy" profile = "RESTRICTED" min_tls_version = "TLS_1_2" project = local.project_id } Atlantis サーバーの構築 Terraform の実行 Atlantis サーバーと必要なリソースを作成します。 # 初期化 fujioka@penguin:~$ terraform init Initializing the backend... ... fujioka@penguin:~$ # 適用確認 fujioka@penguin:~$ terraform plan ... Plan: 23 to add, 0 to change, 0 to destroy. ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Note: You didn ' t use the -out option to save this plan, so Terraform can ' t guarantee to take exactly these actions if you run " terraform apply " now. fujioka@penguin:~$ # 適用 fujioka@penguin:~$ terraform apply ... Apply complete! Resources: 23 added, 0 changed, 0 destroyed. fujioka@penguin:~$ 動作確認 サービスアカウントへ権限付与 Terraform の実行により、 atlantis-sa@PROJECT_ID-prj.iam.gserviceaccount.com のサービスアカウントが作られます。 GitHub のプルリクエスト上で atlantis コマンドを実行すると Atlantis サーバー (Compute Engine) のサービスアカウントの権限で Terraform が実行されます。 今回は Atlantis サーバーが構築されたプロジェクトとは異なるプロジェクトに対して VPC を作ります。 そのため、VPC を作成するプロジェクトで atlantis-sa@PROJECT_ID-prj.iam.gserviceaccount.com のサービスアカウントに編集者 (roles/editor) ロールを付与して動作を確認します。 プルリクエストを作成 GitHub App をインストールしたリポジトリで main.tf を作成し、プルリクエストを作成します。 今回は検証目的のため、ルートに main.tf を置いています。 main.tf プルリクエストを作成するとリポジトリにインストールされた GitHub App の Subscribe to events に該当するため、Atlantis サーバーへ Webhook され terraform plan の結果がコメントされます。 プルリクエストを作成 適用 プルリクエスト上で atlantis apply をコメントすると、実環境へ適用されリソースが作られます。 適用 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

Google Cloud (旧称 GCP) の生成 AI チャットモデルである PaLM 2 の chat-bison モデルを使い、運用を考慮に入れたチャットツールを作成してみましたのでご紹介します。 はじめに 前提知識 Vertex AI PaLM API サンプルコード (Python) ステートフルとステートレス 運用化のポイント ポイント1: チャットボットをステートレスにする 課題 解決策 運用性の検証 応用 ポイント2: 回答スタイルを指定 概要 やり方 動作確認 トラブルシューティング 初期設定 ロジック適用 FastAPI を App Engine でデプロイ PaLM 2 の chat-bisonモデルの運用化のコツ はじめに 先日、「Googleの生成AI、PaLM 2をSlack連携して社内ツールとして導入してみた」というブログ記事で、PaLM 2 の text-bison (テキスト生成用モデル) を使用した簡易的なチャットボットアプリの開発について語りました。 blog.g-gen.co.jp その時、私は PaLM 2 の text-bison が1問1答形式の入力出力にしか対応できないと理解し、その改善点について同記事の「アプリケーションの改善」の章で取り上げました。 この課題を解決するために、当記事では使用モデルを PaLM 2 の chat-bison (チャットモデル) に切り替えましたのでご共有します。前述の記事をまだお読みになっていない方でも、本記事の内容を理解できるように、可能な限り PaLM 2 の chat-bison の説明に焦点を当てて記述します。 前提知識 Vertex AI PaLM API PaLM 2 は Google が開発した生成 AI モデルであり、一般向けチャットツール「Bard」のバックエンドでも使用されています。モデルは Vertex AI の PaLM API として公開されており、Google Cloud 経由で有償で利用できます。 我々開発者はこの Vertex AI PaLM API を使うことで、自社アプリに生成 AI 機能を追加することができます。 今回は Vertex AI PaLM API の中でも、会話に特化した chat-bison を使用します。 Vertex AI PaLM API の詳細については、以下の記事をご確認ください。 blog.g-gen.co.jp サンプルコード (Python) chat-bison モデルのサンプルコード (Python) は以下のリンクをご参照ください。 Test chat prompts https://github.com/GoogleCloudPlatform/python-docs-samples/blob/d5ca4a4518cb20040287129624466fd36b5a646a/generative_ai/chat.py ステートフルとステートレス 当記事では「アプリケーションの状態を維持する」という課題について述べます。アプリケーションのステートフルとステートレスについては以下のリンクをご参照ください。 ステートフル (stateful) とステートレス (stateless) の違い 運用化のポイント 運用化する際に考慮すべきポイントを2つまとめました。1つ目は、インフラの課題を解消するためにチャットボットをステートレスにすること、そして2つ目は回答を改善するためのコツです。 ポイント1: チャットボットをステートレスにする 課題 chat-bison モデルの簡単なサンプルコードは Vertex AI の Web コンソール画面 の右上にある「VIEW CODE」から確認できます。 import vertexai from vertexai.language_models import ChatModel, InputOutputTextPair vertexai.init(project= "thanab" , location= "us-central1" ) chat_model = ChatModel.from_pretrained( "chat-bison" ) parameters = { "max_output_tokens" : 1024 , "temperature" : 0.2 , "top_p" : 0.8 , "top_k" : 40 } chat = chat_model.start_chat( context= """my context""" , ) response = chat.send_message( """my message no. 1""" , **parameters) print (f "Response from Model: {response.text}" ) response = chat.send_message( """my message no. 2""" , **parameters) print (f "Response from Model: {response.text}" ) このコードでは、会話履歴（以下、会話のステート）は chat オブジェクトに格納されます。それにより、再度 chat.send_message 関数を呼び出した際に、過去の会話を考慮した回答が PaLM 2 から得られます。 会話のステートはこのコードを実行するインスタンスのメモリに保存されているため、ステートフルなアプリケーションになります。それにより、運用時に以下の課題が生じます。 1. スケーラビリティ ユーザー数が増えると、会話のステートのボリュームが大きくなり、コストの高い資源であるメモリが多く必要となります。 2. フェイルオーバーと復旧 インスタンスが停止した場合、以前の会話のステートは消えてしまい、インスタンスを再開した後に会話を継続することが難しくなります。 以下のようにこの課題を再現してみます。まず chat_1 チャットセッションで私の名前を覚えさせます。その後、このコードを実行するインスタンスが停止するシナリオを再現するために、関連オブジェクトを削除しました。インスタンスが再開し、同じ会話を続けようとしたところ chat_2 チャットセッションでは私の名前は忘れられてしまいました。 ステートフルの場合、インスタンスが停止した後、チャットセッションが再開したときの動作 解決策 考え方 以下のコードのように、チャットオブジェクトの ._message_history 属性を何処かに保存しておき、再度チャットのオブジェクトを作成する際に chat_model.start_chat 関数の引数として用いることで、会話を再開した後も会話を継続することが可能になります。 Python SDK においては、チャット履歴の内容はチャットオブジェクトの ._message_history 属性に保存されています。これはドキュメントには明記されていません (当記事を書いた理由の一つは、この発見のご共有です)。 ここでは、可読性のために会話のステートを my_historical_chat という変数に保存しました。 ステートレスの場合、インスタンスが停止した後、チャットセッションが再開したときの動作 変数 my_historical_chat の内容はこのようになります。 chat-bisonのチャット履歴の内容 運用性の検証 では、次に外部のデータストレージに会話のステートを保存し、それを復元してみましょう。 データを保存できるサービスは様々ありますが、今回は安価に利用できる Cloud Storage (以下、GCS) に保存し、ステートレス化します。会話のステートを GCS バケットに書き込み、後で読み込む動作を次のように行います。GCS バケットは事前に作成済みの前提です。 まず、以下のように会話のステートをシリアル化してから、GCS バケットに書き込みます。ここで利用している pickle は、Python オブジェクトをシリアル化 (シリアライズ = 直列化。バイト列に変換することでファイル保存等を可能にする) するための Python 標準モジュールです。 import pickle from google.cloud import storage import vertexai from vertexai.language_models import ChatModel # パラメータ設定 bucket_name = "historical-chat-object" destination_blob_name = "会話識別番号_001.pkl" parameters = { "max_output_tokens" : 1000 , "temperature" : 0.2 , "top_p" : 0.95 , "top_k" : 40 } # 関数宣言 def upload_blob (bucket_name, source_file_name, destination_blob_name): """Uploads a file to the bucket.""" storage_client = storage.Client(credentials = credentials) bucket = storage_client.bucket(bucket_name) blob = bucket.blob(destination_blob_name) blob.upload_from_string(source_file_name) def serialize_to_pickle (python_object): # Serialize the Python object to a pickle serialized_object = pickle.dumps(python_object) return serialized_object # アプリ vertexai.init(project= "thanab" , location= "us-central1" , credentials = credentials) # あるユーザーがチャットセッションを開始 chat__1 = chat_model.start_chat() response = chat__1.send_message( """my name is thana""" , **parameters) response = chat__1.send_message( """my age is 30""" , **parameters) response = chat__1.send_message( """what is my name""" , **parameters) print (f "Response from chat__1: {response.text}" ) my_historical_chat = chat__1._message_history # 会話のステートをシリアル化 serialized_chat_state = serialize_to_pickle(my_historical_chat) # GCSへアップロード upload_blob(bucket_name, serialized_chat_state, destination_blob_name) 上記のコードを実行すると、このように GCS バケットに会話のステートがアップロードされました。 次は、このステートを読み込んで会話を再開するコードです。 import pickle from google.cloud import storage import vertexai from vertexai.language_models import ChatModel bucket_name = "historical-chat-object" source_blob_name = "会話識別番号_001.pkl" def download_blob (bucket_name, source_blob_name): """Downloads a blob from the bucket.""" storage_client = storage.Client(credentials = credentials) bucket = storage_client.bucket(bucket_name) blob = bucket.blob(source_blob_name) return blob.download_as_bytes() def deserialize_from_pickle (serialized_object): # Deserialize the object from a pickle python_object = pickle.loads(serialized_object) return python_object # GCS から会話のステートをダウンロード serialized_object = download_blob(bucket_name, source_blob_name) # シリアル化された会話のステートを逆シリアル化し、使える形にする my_loaded_historical_chat = pickle.loads(serialized_object) vertexai.init(project= "thanab" , location= "us-central1" , credentials = credentials) # インスタンス再開 chat_model = ChatModel.from_pretrained( "chat-bison@001" ) # ユーザーが続いて会話する chat__2 = chat_model.start_chat(message_history = my_loaded_historical_chat) response = chat__2.send_message( """what is my name""" , **parameters) print (f "Response from chat__2: {response.text}" ) 上記のコードを実行すると、私の名前を覚えていて会話を継続できることが確認できます。 応用 チャットボットに適用するシナリオを以下のように考えてみます。会話識別番号ごとに、会話のステートを管理します。そのために、会話の識別番号を GCS オブジェクト名にして会話のステートを保存します。 過去の会話ステートの有無の確認は、会話の識別番号に一致する GCS オブジェクトの有無で確認します。Slack でチャットボットを開発する場合、Slack のスレッド番号を会話識別番号として利用できるでしょう。 運用時のロジックの例 ポイント2: 回答スタイルを指定 概要 PaLM 2 のデフォルトの出力スタイルは簡潔なものです。より記述的な回答が望ましい場合は、入出力の例を指定することで、希望に近い出力スタイルを引き出すことができます。 入力出力例の有無によって、回答がどのように変わるか見てみましょう。 入出力例がない場合 入力出力の例 (example)がない場合のchat-bisonの回答 入出力例がある場合 入力出力の例 (example)がある場合のchat-bisonの回答 やり方 Google Cloud 公式の GitHub レポジトリ を参考にして以下のように試しました。 1. 入出力例を用意 オリジナルで作成しても構いませんが今回は Hugging Face からいくつかのサンプルを拾って利用しました。一つをピックアップすると、以下のようなものです。 example_1_ja_output = """印刷された新聞とオンラインニュースメディアの強みと弱みは、多くの面で比較することができます。以下にそれぞれの面について詳しく説明します。 内容 印刷された新聞は、選択された記事を深く言及し、詳細な調査報告を提供することができます。一方、オンラインニュースメディアは、新しい情報にアクセスする速度が速く、即座に編集することができます。また、オンラインニュースメディアは、読者が自由に記事を共有できるため、より幅広い読者層に到達することができます。 配信方法 印刷された新聞は、紙を介して届けられるため、読者が手に取って読むことができます。しかし、紙のニュースメディアは、定期的な配信サイクルに従う必要があります。一方、オンラインニュースメディアは、広範なデバイスで直接アクセスでき、随時更新されます。また、オンラインニュースメディアは、記事を即座に共有することができるため、情報の速度が向上します。 対象読者 印刷された新聞は、購読者を対象にしています。しかし、オンラインニュースメディアは、より広範な読者層に到達することができます。特に、若い読者は、オンラインニュースメディアを使用することが多いです。 広告モデル 印刷された新聞は、大部分の収益を広告から得ています。しかし、紙のニュースメディアは、競合が増える中で広告料が下がっています。一方、オンラインニュースメディアは、デジタル広告モデルを使用して収益を得ています。これは、読者層に対するターゲット広告を提供することができるためです。 社会への影響 印刷された新聞は、コミュニティとのつながりにおいて重要な役割を果たしています。また、新聞社による深く詳細な調査報道は、社会問題の解決に役立ちます。一方、オンラインニュースメディアは、情報へのアクセス性が向上することで、より多くの読者層を影響することができます。 バイアスの可能性 印刷された新聞には、報道規模の制限があります。報道の範囲や、編集方針によっては、バイアスが生まれる可能性があります。一方、オンラインニュースメディアは、より多岐にわたる記事を提供しており、バイアスの可能性を減らすことができます。 第2のJSONコードを使用することで、デジタルジャーナリズムの移行の影響を評価することができます。多段階の推論プロセスを組み込むことで、印刷メディアが直面する課題について検討し、競争力を維持するための新しい戦略を探索することができます。このプロセスには、将来の印刷メディアの不確実性とイノベーションの必要性についても認識することが含まれます。""" 上記の入出力例をチャットモデルが使える形にします。 from vertexai.language_models import InputOutputTextPair examples = [ InputOutputTextPair( input_text=example_1_ja_input, output_text=example_1_ja_output, ), InputOutputTextPair( input_text=example_2_ja_input, output_text=example_2_ja_output, ), InputOutputTextPair( input_text=example_3_ja_input, output_text=example_3_ja_output, ), ] 2. examples を chat_model.start_chat 開始時に渡す 上記コードで作成した examples 配列オブジェクトを chat_model.start_chat 関数に引き渡します。 chat = chat_model.start_chat(examples = examples) response = chat.send_message( """円高とは""" , **parameters) print (f "Response from Model: \n {response.text}" ) 動作確認 前回の記事「 Googleの生成AI、PaLM 2をSlack連携して社内ツールとして導入してみた 」を書く際に開発したアプリへ、上記のロジックを適用してみました。会話が継続しており、かつ記述的な回答が得られている様子が確認できました。 PaLM 2のchat-bisonを運用化してみた 上記の例では、私の2つ目のプロンプトでは「 それを 」という曖昧な表現を使いました。それでも PaLM 2 の chat-bison がちゃんと過去の会話の内容を考慮して回答を返してくれました。 トラブルシューティング 読者が再現する際に起こり得る他のトラブルシューティングを以下のようにまとめました。 初期設定 Slack チャットボットのアーキテクチャや初期設定に興味がある方は以下のリンクをご参照ください。 blog.g-gen.co.jp ロジック適用 開発コードに興味がある方は、以下のレポジトリを確認することができます。 github.com バックエンドフレームワークはSlackと連携する専用のPythonライブラリを利用しています。該当ライブラリについては以下のURLをご覧ください。 https://slack.dev/bolt-python/concepts GitHub - slackapi/bolt-python: A framework to build Slack apps using Python · GitHub FastAPI を App Engine でデプロイ FastAPI のアプリを開発環境で実行する際、次のコマンドで実行できます。 uvicorn app:api --port 8080 しかし App Engine などの運用環境では、uvicorn でアプリをデプロイするとエラーが発生することがあります。その解決策として App Engine の app.yaml を用意する際に次のコマンドを entrypoint として指定すると、無事にアプリをデプロイすることができます。 gunicorn -w 2 -k uvicorn.workers.UvicornWorker -b 0 . 0 . 0 .0:8080 app:api -w と uvicorn.workers.UvicornWorker は それぞれワーカー数とワーカークラス を指定するものです。 また instance class が F1 の場合、ワーカー数を2個に指定すれば無事に動作することを確認しました。その値を超えた場合、リソースが不足し、アプリがダウンする可能性があります。 当記事についてご興味を持たれ、自社でも実装してみたい場合は、G-gen の Web サイトからお気軽にお問い合わせください。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。