G-gen の佐藤です。当記事では Google のアイデンティティ管理サービスである Cloud Identity (Free Edition) の登録から組織作成までの手順について紹介します。 概要 Cloud Identity とは 2つのエディション Cloud Identity のユースケース 登録手順 前提 Cloud Identity Free Edition の初期登録の流れ Admin Console へのログイン ドメイン所有権の証明 Google Cloud Console ログイン ＆ 組織選択 トラブルシューティング 電話番号が使えない ドメインの所有権証明でエラー 概要 Cloud Identity とは Cloud Identity は、Google が提供するアイデンティティ管理サービスです。Google アカウントを集中管理し、認証・認可、アクセス権限管理などを行うことができます。二段階認証、パスワードポリシー、アカウントロックなどのセキュリティ機能が提供されています。 Google のアカウント管理サービスには他に Google Workspace がありますが、Cloud Identity は Google Workspace から Gmail やカレンダーなどのグループウェア機能を取り除いたサービスであり、アカウント管理に特化したものと考えればよいでしょう。 参考 : Cloud Identity とは 2つのエディション Cloud Identity には Free と Premium の 2 つのエディションがあります。 Free Edition は最大50人までのユーザー登録が可能であり、それ以上のユーザー追加には有償版である Premium Edition が必要です。また Free エディションのままでも、Google に申請することで上限数が緩和される場合があります。上限緩和には Google の審査が入りますので、必ず上限緩和が可能であるとは限らない点にご留意ください。 参考 : Cloud Identity Free Edition ユーザーの上限数 Free Edition にはほとんどの基本的な機能が揃っていますが、デバイス管理や DLP (Data Loss Prevention) など一部の高度な機能は Premium Edition でのみ使うことができます。 参考 : Cloud Identity の機能とエディションの比較 Cloud Identity のユースケース Cloud Identity の最も多いユースケースは「 Google Cloud を利用する。それにあたり開発・運用のための Google アカウントを集中管理する。また Google Cloud プロジェクトへの統制を行うために組織機能を利用する」というものです。 Google Cloud には「 組織 (Organization)」という機能があり、企業や官公庁が Google Cloud を利用するにあたりほぼ必須と言っていいほど重要な機能です。しかし組織の機能の利用には Google Workspace 組織または Cloud Identity 組織が必須です。そのため、その企業・官公庁で Google Workspace のグループウェア機能が不要である場合、Cloud Identity を利用することになります。 当記事ではそのようなケースのために、Cloud Identity Free Edition を新規登録して利用開始するための手順を記述します。 なお Google Cloud の 組織 (Organization) については以下の記事もご参照ください。 blog.g-gen.co.jp 登録手順 参考 : Cloud Identity に申し込む 前提 実際に登録を行う前に、以下をご準備ください。 SMS が受信可能 もしくは 音声電話を受電可能な 電話番号 組織に登録する ドメイン名 .tk など一部のドメイン名は利用不可です 手順の中で、ドメインを管理するゾーンに DNS レコードを登録します。DNS の管理を他部署や業者に委託している場合は、情報連携の準備をしておきます Cloud Identity Free Edition の初期登録の流れ 次の登録ページにアクセスします。 Cloud Identity Free に登録する ビジネス名、従業員の数 を指定し、次へ を押下 Google からの連絡受信用の連絡先を入力し、次へ を押下 ご利用のドメイン名 を入力し、次へ を押下 ご利用のドメイン名 を確認し、次へ を押下 任意で選択します ログイン情報 を入力し、ロボットによる操作でないことを確認したら、同意してアカウントを作成 を押下 ※ここで入力したログイン情報を後ほどの Admin Console ログイン画面で使用します。 以上で Cloud Identity アカウントの作成は完了です。 上記画面の続行ボタンを押下するとこの後の「Admin Console へのログイン」画面に遷移します。 Admin Console へのログイン 先程作成した管理者アカウント情報・パスワードを入力し、 次へ を押下 Sign in - Google Accounts 本人確認の実施 登録した電話番号にSMSが届きます。 理解しました を押下 次へ を押下 ドメイン所有権の証明 Cloud Identity の設定画面が表示されるので、先程登録したドメインを選択し、 保護 を押下 表示されたポップアップの内容を確認し、 ドメインを保護 を押下 DNS レコードまたは DNS 設定を探す ドメイン所有権を証明するためのTXTレコードが表示されるので、 コピー を押下 TXT レコードは、ドメイン取得事業者の管理画面、もしくはドメイン管理を委任している DNS サーバで設定する必要があります。 再度、 ドメインを保護 を押下 Google が TXT レコードを確認できるとドメインの所有権の確認が終わります。確認プロセスは通常は数分で終わりますが、ドメインを取得したばかりである等の理由で数日かかるケースもあります。本記事末尾の「トラブルシューティング」にも関連の事象を記載しましたので、ご確認ください。 Google Cloud Console ログイン ＆ 組織選択 以下のページにアクセス https://console.cloud.google.com/ 管理者アカウント情報・パスワードを入力し、 次へ を押下 利用規約にチェックを入れ、 同意して続行 を押下 Google Cloud を初めて使用し、まだプロジェクトを作成していない場合は、Google Cloud Console にログインして利用規約に同意すると、組織リソースが作成されます。 ※反映までに時間がかかります。 上記画面に反映されたら、ナビゲーションメニューから IAMと管理 を選択し、 IAM から作成された組織が確認可能です。 以上で、Cloud Identity Free Edition の登録から組織作成まで完了です。 トラブルシューティング 電話番号が使えない 管理者アカウントで初めてログインする際に本人確認のための電話番号を入力しますが、この際に「この電話番号は、既に何度も確認に使用されているため無効です。」という旨のメッセージが表示され、弾かれてしまうケースがあります。 特に、複数の Cloud Identity (Google Workspace) 組織を数日〜数ヶ月などの短期間で作成した際に、この現象が発生します。 これは、同一の電話番号でスパム的に多数の組織が作成されてしまうことを防ぐため、Google が機械的に電話番号をチェックしていることに起因しています。 これまで Google のアカウントサービス (Google Workspace、Cloud Identity、無償の Gmail アカウント等) で使用した実績がある電話番号は、機械的に拒否されてしまうため、同じ電話番号を利用する場合は期間を空けてから利用する必要があります。どうしても短期間のうちに複数の組織を作成する必要がある場合は、最初の一回の認証時のみ、別の電話番号を用意する必要があります。 ドメインの所有権証明でエラー ドメイン所有権の証明の手順中に、以下のメッセージが表示される場合があります。 現在、ドメインの所有権を証明することができません 現在、ドメインの所有権を証明することができません。ドメインホストで情報が更新されるまでにしばらくかかる可能性があります。更新がすぐに行われない場合は、所有権の証明をもう一度お試しください。 これは、ドメインを取得したばかりであったり、ドメイン登録事業者の Web UI から DNS レコードを登録したために実際の DNS サーバに情報が反映がされていない場合等に表示されることがあるメッセージです。 この表示がされた場合は、時間を置いて再度、管理画面を確認してください。前述のようにドメインや DNS 側が原因であれば自動的に解消されますが、最長 48 時間ほどかかる場合もあります。それ以外の理由の場合、DNS レコードが正しく登録できないことが原因の場合もありますので、設定値を十分確認してください。 参考 : ドメイン所有権の確認が失敗する 佐藤 亜由美 (記事一覧) ビジネス推進部 Google Cloud Authorized Trainer フロントエンドエンジニアからキャリアをスタート。Webアプリ開発や社内新卒向け技術研修担当を経て2023年に G-gen へ Join。Google Cloud を通じて、世界がもっとはたらきやすくなりますように♡ Follow @_satoayu_

Google Cloud（旧称 GCP）の 学習に役立つオンラインコンテンツ を、サービスカットや分野別でまとめました。Google Cloud 初学者の方の基本的な学習のほか、資格取得にもお役立てください。 はじめに Google Cloud 全般 課金・コスト削減 アーキテクチャ・ベストプラクティス セキュリティ・統制 セキュリティ（ネットワーク） コンピューティング サーバーレス ネットワーク ストレージ データベース データ分析 生成 AI、Gemini AI/ML（機械学習） 開発・IaC 監視・運用・SRE その他・Google プロダクト Google Workspace Google Cloud 認定資格 はじめに 当ページでは Google Cloud（旧称 GCP）の基礎学習や試験対策に役立つオンラインコンテンツを、サービス名別や分野別でまとめました。 「サービスカット」とは Compute Engine、Cloud Storage、BigQuery など、Google Cloud サービスごとに分類されていることを意味しています。ただし、学習に役立つ場合は、サービスを横断したコンテンツを紹介している場合もあります。 また各コンテンツには、当社の主観ではありますが [初級] [中級] [上級] のレベルを付記してあります。 レベル名 対象者 説明 初級 初めてそのサービスを学ぶ人 抽象的、あるいは比較的理解が容易。Google Cloud 初学者向け 中級 初めてそのサービスを学ぶ人もしくはある程度そのサービスを知っている人 初級と上級の中間程度 上級 ある程度そのサービスを知っている人 IT 知識やそのサービスに関する知識がある程度求められる Google Cloud 全般 サービス名 タイトル・リンク 種類 レベル 全般 プロダクト別 参考セッション 公式情報 初級〜上級 全般 Solution Design Pattern 公式情報 初級〜上級 全般 Google Cloudの利用に必要なGoogleアカウントを徹底解説！ 公式情報 初級 全般 Google Cloud主要サービスを50文字で解説！ G-gen Tech Blog 初級 全般 Google CloudとGCP、どっちが正しい？ G-gen Tech Blog 初級 全般 Google Cloud（旧GCP）無料で使ってみた！クラウド初心者もかんたんに開設、始め方大解説（前編：説明編） G-gen Tech Blog 初級 全般 gcloud CLIのインストール方法（Windows 編） G-gen Tech Blog 初級 全般 Preview版のサービスを使うとはどういうことなのか G-gen Tech Blog 初級 全般 Google Cloudの根幹を成すGoogle Cloud APIsとは何か G-gen Tech Blog 中級 全般 Google Cloudで理解する疎結合アーキテクチャとメッセージングサービス G-gen Tech Blog 上級 全般 Google Cloudにおける負荷テスト G-gen Tech Blog 初級 全般 クラウドと英語 G-gen Tech Blog 初級 課金・コスト削減 サービス名 タイトル・リンク 種類 レベル Cloud Billing (課金) クラウド料金の見積もり方法を解説！ G-gen Tech Blog 初級 Cloud Billing (課金) Google Cloudの請求の仕組みを分かりやすく解説してみた G-gen Tech Blog 初級 Cloud Billing (課金) 予算アラートの設定方法 G-gen Tech Blog 初級 BigQuery BigQuery のコスト削減方法まとめ G-gen Tech Blog 中級 Compute Engine (GCE) 確約利用割引(Compute Engine)を解説。AWSとの違いも確認 G-gen Tech Blog 中級 Compute Engine (GCE) Compute Engineの継続利用割引を計算例を使って解説 G-gen Tech Blog 中級 アーキテクチャ・ベストプラクティス サービス名 タイトル・リンク 種類 レベル アーキ・ベスプラ Google Cloud(旧GCP)利用してみたい！けど最初に対応すべきことは？初期設定のベストプラクティスを解説！ G-gen Tech Blog 初級 アーキ・ベスプラ Googleのクラウド導入フレームワークを翻訳して紹介 G-gen Tech Blog 初級 アーキ・ベスプラ Google Cloudで理解するサーバーレス・アーキテクチャ G-gen Tech Blog 初級 アーキ・ベスプラ セキュリティスイート for Google Cloudを徹底解説！ G-gen Tech Blog 初級 アーキ・ベスプラ メダリオンアーキテクチャ2.0とGoogle CloudのAIエージェント活用 G-gen Tech Blog 中級 セキュリティ・統制 サービス名 タイトル・リンク 種類 レベル Identity and Access Management (IAM) Google CloudのIAMを徹底解説！ G-gen Tech Blog 初級 Identity and Access Management (IAM) Privileged Access Manager（PAM）を解説！ G-gen Tech Blog 初級 Resource Manager Google Cloudの組織(Organization)を徹底解説 G-gen Tech Blog 初級 Resource Manager 組織のポリシーを解説 G-gen Tech Blog 初級 Resource Manager タグとラベルの違い（Tags / Labels） G-gen Tech Blog 初級 Cloud Asset Inventory Cloud Asset Inventoryを徹底解説！ G-gen Tech Blog 初級 Cloud Audit Logs Cloud Audit Logsを解説。Google Cloudの証跡管理 G-gen Tech Blog 中級 VPC Service Controls VPC Service Controlsを分かりやすく解説 G-gen Tech Blog 中級 Chrome Enterprise Premium（旧称 BeyondCorp Enterprise） Chrome Enterprise Premium（旧称 BeyondCorp Enterprise）を徹底解説 G-gen Tech Blog 中級 Security Command Center (SCC) Security Command Centerを徹底解説。Google Cloud(GCP)の脆弱性を自動検知 G-gen Tech Blog 中級 Cloud KMS Cloud KMSを徹底解説 G-gen Tech Blog 中級 セキュリティ（ネットワーク） サービス名 タイトル・リンク 種類 レベル Cloud Next Generation Firewall (Cloud NGFW) Cloud Next Generation Firewall(Cloud NGFW)を徹底解説！ G-gen Tech Blog 中級 Cloud Armor Cloud Armorを徹底解説。GoogleのフルマネージドWAF G-gen Tech Blog 中級 Cloud IDS Google CloudのCloud IDSを徹底解説 G-gen Tech Blog 中級 Identity-Aware Proxy (Cloud IAP) 踏み台サーバはもういらない。IAP(Identity-Aware Proxy)の便利な使い方 G-gen Tech Blog 中級 reCAPTCHA reCAPTCHAの料金体系を解説 G-gen Tech Blog 初級 コンピューティング サービス名 タイトル・リンク 種類 レベル コンピュート全般 Google CloudのComputingプロダクトを解説 G-gen Tech Blog 初級 Compute Engine (GCE) Compute Engineを徹底解説！（基本編） G-gen Tech Blog 初級 Compute Engine (GCE) Compute Engineを徹底解説！（応用編） G-gen Tech Blog 中級 Compute Engine (GCE) VMインスタンスの自動起動・終了をスケジューリングする設定方法 G-gen Tech Blog 初級 Compute Engine (GCE) Compute Engine の SSH 接続方法についてのまとめ G-gen Tech Blog 中級 Compute Engine (GCE) VM Managerを徹底解説！ G-gen Tech Blog 中級 Compute Engine (GCE) Windows Serverを完全日本語化してみた G-gen Tech Blog 初級 App Engine Google App Engine (GAE) を徹底解説 G-gen Tech Blog 初級 Kubernetes Kubernetes の基本を解説 G-gen Tech Blog 中級 Google Kubernetes Engine (GKE) Google Kubernetes Engine（GKE）を徹底解説 G-gen Tech Blog 中級 Migrate for Compute Engine Migrate for Compute Engineを解説 G-gen Tech Blog 中級 Managed Service for Microsoft Active Directory Managed Service for Microsoft Active Directoryを徹底解説 G-gen Tech Blog 中級 Google Cloud VMware Engine（GCVE） Google Cloud VMware Engine（GCVE）を徹底解説！ G-gen Tech Blog 中級 サーバーレス サービス名 タイトル・リンク 種類 レベル Cloud Run 入門！Cloud Runのススメ G-gen Tech Blog 初級 Cloud Run Cloud Run を徹底解説！ G-gen Tech Blog 中級 Cloud Run Cloud Run jobs を徹底解説！ G-gen Tech Blog 中級 Cloud Run Cloud Run worker poolsを徹底解説！ G-gen Tech Blog 中級 Cloud Run Cloud Run等における構造化ロギング G-gen Tech Blog 中級 Cloud Run functions Cloud Run functionsを徹底解説！ G-gen Tech Blog 中級 Cloud Run functions Cloud Run functionsでSlackのスラッシュコマンドを作ってみた G-gen Tech Blog 中級 ネットワーク サービス名 タイトル・リンク 種類 レベル Virtual Private Cloud (VPC) Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い G-gen Tech Blog 初級 Virtual Private Cloud (VPC) Google CloudのVPCを徹底解説！(基本編) G-gen Tech Blog 初級 Virtual Private Cloud (VPC) Google CloudのVPCを徹底解説！(応用編) G-gen Tech Blog 中級 Virtual Private Cloud (VPC) 限定公開の Google アクセスの仕組みと手順をきっちり解説 G-gen Tech Blog 上級 Virtual Private Cloud (VPC) Private Service Connect機能解説。Google Cloud APIにプライベート接続 G-gen Tech Blog 上級 Virtual Private Cloud (VPC) Private Service Connect でマネージドサービスを公開する G-gen Tech Blog 中級 Cloud VPN 高可用性Cloud VPNを解説。オンプレミスとGoogle CloudをVPNで接続 G-gen Tech Blog 中級 Cloud Load Balancing External Application Load Balancer (外部アプリケーションロードバランサ) を徹底解説！ G-gen Tech Blog 中級 Cloud Interconnect Cloud Interconnect の基本を解説！ G-gen Tech Blog 初級 Cross-Cloud Interconnect Cross-Cloud Interconnectを徹底解説！ G-gen Tech Blog 初級 Network Connectivity Center Network Connectivity Centerを徹底解説！ G-gen Tech Blog 初級 Network Intelligence Center Network Intelligence Centerを徹底解説！ G-gen Tech Blog 初級 ストレージ サービス名 タイトル・リンク 種類 レベル Cloud Storage (GCS) Cloud Storage(GCS)を徹底解説 G-gen Tech Blog 初級 Cloud Storage (GCS) Cloud Storage を gcloud storage コマンドで操作（基本編） G-gen Tech Blog 初級 Filestore Filestoreを徹底解説。Google Cloudのマネージドなファイルサーバ G-gen Tech Blog 初級 データベース サービス名 タイトル・リンク 種類 レベル Cloud SQL Cloud SQLを徹底解説！ G-gen Tech Blog 初級 Cloud Spanner Cloud Spanner を徹底解説！ G-gen Tech Blog 中級 AlloyDB for PostgreSQL AlloyDB for PostgreSQLを徹底解説！ G-gen Tech Blog 初級 Cloud Bigtable Bigtableを徹底解説！ G-gen Tech Blog 初級 データ分析 サービス名 タイトル・リンク 種類 レベル BigQuery BigQueryを徹底解説！(基本編) G-gen Tech Blog 初級 BigQuery BigQueryを徹底解説！(応用編) G-gen Tech Blog 中級 BigQuery Gemini in BigQueryを徹底解説！ G-gen Tech Blog 初級 BigQuery BigQuery Editionsを徹底解説 G-gen Tech Blog 中級 BigQuery BigQueryのストレージ料金を解説 G-gen Tech Blog 中級 BigQuery BigQueryのアクセス制御と権限設計を解説 G-gen Tech Blog 中級 BigQuery BigQueryのパーティションとクラスタリングについての解説 G-gen Tech Blog 中級 BigQuery BigQuery Data Transfer Serviceを使ってAmazon S3のデータをBigQueryに取り込む方法 G-gen Tech Blog 中級 BigQuery BigQueryの外部テーブルでスプレッドシートのデータをクエリする G-gen Tech Blog 初級 BigQuery / Connected Sheets コネクテッドシートで始めるデータ分析（Googleスプレッドシート+BigQuery） G-gen Tech Blog 初級 BigQuery Omni BigQuery OmniでAmazon S3のデータをクエリしてみた G-gen Tech Blog 中級 Dataplex Dataplexを徹底解説！ G-gen Tech Blog 中級 Dataplex Catalog Dataplex Catalogを徹底解説！ G-gen Tech Blog 中級 Looker / Looker Studio GoogleのBIツール、LookerとLooker Studioを比較してみた G-gen Tech Blog 初級 Looker Looker のデータガバナンス機能を解説 G-gen Tech Blog 中級 Looker Studio Pro Looker Studio Pro を徹底解説！ G-gen Tech Blog 初級 Dataform Dataformを徹底解説 G-gen Tech Blog 中級 Cloud Composer Cloud Composer (メジャーバージョン2)を徹底解説！ G-gen Tech Blog 中級 Dataflow Dataflowを徹底解説！ G-gen Tech Blog 中級 生成 AI、Gemini サービス名 タイトル・リンク 種類 レベル 生成 AI 全般 生成AIのよくある誤解を整理してAIの業務活用を推進する G-gen Tech Blog 初級 Gemini、NotebookLM Googleの生成AIサービスを整理。Geminiアプリ、Gemini Enterprise、NotebookLM等を比較 G-gen Tech Blog 初級 Gemini 全Geminiプロダクトを徹底解説！ G-gen Tech Blog 初級 Gemini Gemini Proを使ってみた。Googleの最新生成AIモデル G-gen Tech Blog 初級 Gemini Gemini CLIを解説 G-gen Tech Blog 初級 Gemini 生成AI「Gemini」をクラウドインテグレーター社員が活用した事例 G-gen Tech Blog 初級 Gemini Enterprise Gemini Enterpriseを徹底解説！ G-gen Tech Blog 初級 NotebookLM NotebookLM in Pro（旧称NotebookLM Plus）を使ってみた G-gen Tech Blog 初級 NotebookLM NotebookLM無償版・Pro・Enterpriseの違い G-gen Tech Blog 初級 Vertex AI (Generative AI) Google AI Studio vs Vertex AI。違いや選び方を解説 G-gen Tech Blog 初級 Vertex AI (Generative AI) Generative AI on Vertex AIを徹底解説！ G-gen Tech Blog 初級 Vertex AI Search Vertex AI Searchを徹底解説！ G-gen Tech Blog 中級 Vertex AI Search 生成AIのRAG構成を大手3社（AWS、Azure、Google Cloud）で徹底比較してみた G-gen Tech Blog 初級 Vertex AI Search 生成AIのAIエージェントを大手3社（AWS、Azure、Google Cloud）で徹底比較してみた G-gen Tech Blog 初級 Model Armor Model Armorを徹底解説！ G-gen Tech Blog 中級 Agent Development Kit（ADK） ナレッジ検索・回答AIエージェントG-gen Tech AgentをADKで開発した事例 G-gen Tech Blog 中級 Agent Development Kit（ADK） ADKのLLM AgentとWorkflow Agents、Toolsを解説 G-gen Tech Blog 中級 AI/ML（機械学習） サービス名 タイトル・リンク 種類 レベル Vertex AI Vertex AIを徹底解説！ G-gen Tech Blog 中級 Vertex AI Pipelines Vertex AI Pipelinesを解説 G-gen Tech Blog 中級 BigQuery ML BigQuery MLを徹底解説！ G-gen Tech Blog 中級 Document AI Document AIを徹底解説 G-gen Tech Blog 中級 開発・IaC サービス名 タイトル・リンク 種類 レベル Terraform TerraformをGoogle Cloudで使ってみた G-gen Tech Blog 初級 Cloud Workstations Cloud Workstationsを徹底解説！ G-gen Tech Blog 中級 Colab / Colab Enterprise Colab、Colab Pro+、Colab Enterpriseを比較して解説 G-gen Tech Blog 初級 Colab Enterprise / Vertex AI Workbench Colab EnterpriseとVertex AI Workbenchを徹底解説 G-gen Tech Blog 中級 Cloud Shell エディタ、Gemini Code Assist Gemini Code Assistを使ってChromebookで開発環境を整えてみた G-gen Tech Blog 初級 監視・運用・SRE サービス名 タイトル・リンク 種類 レベル Cloud Monitoring Cloud Monitoringを徹底解説！ G-gen Tech Blog 初級 Cloud Logging Cloud Loggingの概念と仕組みをしっかり解説 G-gen Tech Blog 初級 Cloud Logging Cloud Loggingのクエリ言語の構文を徹底解説 G-gen Tech Blog 初級 Cloud Scheduler Cloud Scheduler を徹底解説！ G-gen Tech Blog 中級 Cloud Workflows Cloud Workflowsを徹底解説 G-gen Tech Blog 中級 Personalized Service Health Personalized Service Healthを徹底解説 G-gen Tech Blog 初級 Gemini Cloud Assist Investigations Gemini Cloud Assist Investigationsを解説。AIエージェントでトラブルシューティング G-gen Tech Blog 初級 その他・Google プロダクト サービス名 タイトル・リンク 種類 レベル Firebase Firebase を徹底解説！ G-gen Tech Blog 中級 AppSheet AppSheet のはじめ方 G-gen Tech Blog 初級 Google Maps Platform Google Maps Platform の基本を解説！ G-gen Tech Blog 初級 Google Workspace サービス名 タイトル・リンク 種類 レベル Cloud Identity Cloud Identityの登録・組織作成手順 G-gen Tech Blog 初級 Google Workspace Google Workspace を徹底解説！ G-gen Tech Blog 初級 Google Workspace Google Workspace 各プラン比較！どのプランがオススメ？ G-gen Tech Blog 初級 Google Workspace Google Workspace レポートと監査ログを解説！プランによって何が違う？ G-gen Tech Blog 中級 Google Workspace Geminiウェブアプリのカスタマイズ機能「Gems」を徹底解説 G-gen Tech Blog 初級 Google Workspace Google Workspaceの新機能をいち早く使う方法 G-gen Tech Blog 初級 Google Workspace (Google Vids) Google VidsのAI機能で動画を作成してみた G-gen Tech Blog 初級 Google Workspace (Google Workspace Studio) Google Workspace Studioを徹底解説！ G-gen Tech Blog 初級 Google Cloud 認定資格 サービス名 タイトル・リンク 種類 レベル 認定資格 Google Cloud 認定資格の一覧を解説。全部で何個ある？難易度は？ G-gen Tech Blog 初級 認定資格 Cloud Digital Leader試験を非エンジニアが受験してみた G-gen Tech Blog 初級 認定資格 Cloud Digital Leader試験対策マニュアル G-gen Tech Blog 初級 認定資格 Associate Cloud Engineer試験対策マニュアル G-gen Tech Blog 初級 認定資格 Associate Data Practitioner試験対策マニュアル G-gen Tech Blog 初級 認定資格 Associate Google Workspace Administrator試験対策マニュアル G-gen Tech Blog 初級 認定資格 Professional Cloud Architect試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Cloud Developer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Data Engineer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Cloud DevOps Engineer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Cloud Security Engineer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Cloud Network Engineer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Google Workspace Administrator試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Cloud Database Engineer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Machine Learning Engineer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional Security Operations Engineer試験対策マニュアル G-gen Tech Blog 中級 認定資格 Professional ChromeOS Administrator試験対策マニュアル G-gen Tech Blog 初級 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の堂原です。本記事では、Looker Studio において、Google Sheets をソースとする BigQuery 外部テーブルに接続しようとすると発生する Permission denied エラーの対処法を紹介します。 はじめに 事象 : 外部テーブルへの接続でエラー 対処法 サマリ 各リソースの関係性 データの認証情報 手順 はじめに Google Cloud (旧称 GCP) が提供する BI ツールである Looker Studio では、データソースとして BigQuery が選択可能です。BigQuery のテーブルやビューのデータを取り込み、簡単にダッシュボードを作成することができます。 また BigQuery には 外部テーブル という機能があり、Google Drive 内の Google Sheets など、BigQuery の外に保存されたデータを直接参照する仮想的なテーブルを作成することができます。 事象 : 外部テーブルへの接続でエラー Looker Studio において、Google Sheets をソースとする BigQuery 外部テーブルに接続してみました。 やりたいことを図にすると、以下のようになります。 Looker Studio から BigQuery 外部テーブル経由で Sheets のデータを取得 Looker Studio では BigQuery 用のコネクタが用意されています。BigQuery への権限を持つ Google アカウントで Looker Studio にログインしていれば、簡単に接続設定ができます。 例えば作成中のレポートであれば、下図の「データを追加」から設定が可能です。 データの追加 外部テーブルについても、データソースとして追加する処理までは問題なく進みました。 しかし、いざ追加したデータソースを用いてグラフ等を作成しようとすると、以下のエラーが表示されました。 データセットの接続エラー エラー詳細 エラーメッセージは以下の通りであり、どうやら Google Drive に対する権限が無いようです。 BigQuery error: Access Denied: BigQuery BigQuery: Permission denied while getting Drive credentials. 対処法 サマリ 本エラーですが「 データの認証情報 」設定を「 サービス アカウント 」にして、Google Sheets への閲覧者権限を サービスアカウントに付与 することで解決しました。 意味合いとしては「レポートからデータソースへの認証をサービスアカウントに行わせる」「さらにそのサービスアカウントが BigQuery 外部テーブルと、さらにそのデータソースである Sheets の両方に対して権限を持つようにする」ということになります。 各リソースの関係性 今回登場する各リソースの関係性は以下の図のようになります。 各リソースの関係性 データの認証情報 Looker Studio のレポートからデータソースへ認証する際に データソースの認証情報 として次の 3 つの選択肢が存在します。 オーナーの認証情報 サービス アカウントの認証情報 閲覧者の認証情報 これらはデータソースのデータにアクセスするときに、誰の（何の）権限に依存するかを指定する設定となります。 「オーナーの認証情報」または「サービス アカウントの認証情報」であれば、レポートは共有されれば誰でも閲覧することが可能です。 一方で「閲覧者の認証情報」だと、たとえレポートを共有されたとしても、データソースそのものへのアクセス権が無い人はデータを閲覧することができません。 手順 次のような手順で設定すること可能です。 Google Cloud プロジェクトにサービス アカウント作成 BigQuery にアクセスさせるため、以下のロールをサービス アカウントに付与（ 参照 ） BigQuery ジョブユーザー BigQuery データ閲覧者 Looker Studio サービス エージェントに、サービス アカウントに対する「サービス アカウント トークン作成者」ロールを付与 Looker Studio サービス エージェントの確認方法は こちら のページの「Looker Studio サービス エージェントを取得する」に記載あります。 Google Sheets の共有設定にて、サービス アカウントのメールアドレスに対して「閲覧者」権限を付与 Google Sheetsの共有設定 Looker Studio にて、該当データセットの「データの認証情報」をサービス アカウントに変更する データの認証情報 堂原 竜希 (記事一覧) クラウドソリューション部。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023に選出。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @matayuuuu

G-gen の堂原です。 Artifact Registry に溜まった、タグなしの Docker イメージ ダイジェストを一括で削除する Python プログラムを紹介します。 はじめに ソースコードの解説 処理の流れ ソースコード クライアントライブラリ Python Client for Artifact Registry API 現在は「delete_docker_image」が存在しない parent の記載方法 はじめに Google Cloud (旧称 GCP) の Artifact Registry では、同じタグのイメージがプッシュされると、古いイメージ ダイジェストはタグが外されタグなしの状態となり保管されます。 このイメージ ダイジェストは勝手に消えないため、気づくとタグなしイメージ ダイジェストだらけになることもあるかと思います。 現在こういったイメージ ダイジェストを自動で削除するような機能は、プレビュー版としては一部のユーザには提供されているものの、一般公開されていません。（ ドキュメント ） そこで今回は、 作成されてから一ヶ月以上経過したタグなし Docker イメージ ダイジェストを一括削除する Python プログラム を紹介します。 本記事では実施していませんが、本コードを Cloud Functions にデプロイして、Cloud Scheduler で定期実行するなどといった運用が考えられます。 ソースコードの解説 処理の流れ 本プログラムの処理の流れは以下のようになります。 list_tags 関数でタグ情報一覧を取得する タグが付いている全てのイメージ ダイジェスト名を取得 list_versions 関数で全てのイメージ ダイジェスト情報を取得 タグが付いていないイメージ ダイジェストを判断 イメージ ダイジェストの作成日を確認 基準時間よりも古ければ、 delete_version 関数で削除 ソースコード 以下がソースコードの全容となります。 #!/usr/bin/env python from google.cloud import artifactregistry_v1 from datetime import datetime, timedelta project_id = "${プロジェクトID}" location = "${Artifact Registryリポジトリのリージョン}" repository = "${リポジトリ名}" package = "${イメージ名}" def main (): client = artifactregistry_v1.ArtifactRegistryClient() # 対象のイメージに存在する全てのタグ情報を取得 response = client.list_tags( parent=f "projects/{project_id}/locations/{location}/repositories/{repository}/packages/{package}" ) # タグが付いている全てのイメージ ダイジェストを取得 tag_list = [] for tag in response: tag_list.append(tag.version) # 対象のイメージに存在する全てのダイジェスト情報を取得 response = client.list_versions( parent=f "projects/{project_id}/locations/{location}/repositories/{repository}/packages/{package}" ) # 基準となる時間を取得 now = datetime.utcnow() cutoff_time = now - timedelta(days= 30 ) for version in response: # タグが付いているかを判断（tag_list[] に存在するかどうか） if version.name not in tag_list: create_time = version.create_time.replace(tzinfo= None ) # 基準時間よりも前に作成されたか判断→削除 if create_time < cutoff_time: print (f "delete: {version.name}" ) client.delete_version(name=version.name) if __name__ == "__main__" : main() クライアントライブラリ Python Client for Artifact Registry API Artifact Registry の操作には Python Client for Artifact Registry API を用います。 本記事では、投稿時点の最新バージョンである 1.8.1 を用いています。 Cloud Functions 等で、requirements.txt が必要な場合は以下の通りとなります。 google-cloud-artifact-registry == 1.8.1 現在は「delete_docker_image」が存在しない 現在こちらのライブラリには 、 Docker イメージ（Docker イメージ ダイジェスト）一覧を取得する list_docker_images 関数 Docker イメージ ダイジェストの情報を取得する get_docker_image 関数 は存在しますが、 Docker イメージ（あるいは Docker イメージ ダイジェスト）を削除するような関数 は存在しません。 そのため list_docker_images で取得した情報に基づいて Docker イメージ ダイジェストを削除といったことができず、本記事ではこのような流れで処理を記述しました。 parent の記載方法 list_tags 関数や list_versions 関数の引数となっている parent について、最初は何を記載したら良いのかわかりませんでした。 ライブラリ紹介のページには記載がありません。 そんなときは、各サービスの API をまとめたドキュメントを調べてみてください。 Artifact Registry なら こちら のドキュメントになります。 例えばこのドキュメントにて、 REST Resource: v1.projects.locations.repositories.packages.tags を確認してもらうと、 {parent=projects/*/locations/*/repositories/*/packages/*} のように parent の書き方が記載されています。 堂原 竜希 (記事一覧) クラウドソリューション部。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023に選出。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @matayuuuu

こんにちは、G-genの遠目塚です。当記事では Google Forms (以下Forms) と Google AppSheet( 以下 AppSheet) の連携についてご紹介します。 概要 AppSheet とは Google Forms とは Forms と AppSheet の連携 フォーム準備 Formsで問合せ受付フォームを作成する アドオンを起動 AppSheetの設定 Dataの設定 問合せフォームとの連携を確認 概要 AppSheet とは AppSheet は、プログラミングの知識や開発経験のない人でも、簡単にWeb・スマホアプリケーションが開発可能なノーコードツールです。 AppSheetの始め方や概要については以下の記事で解説しています blog.g-gen.co.jp blog.g-gen.co.jp Google Forms とは Google Forms は、簡単にアンケートや申込みフォームを作成し、Sheets で情報を蓄積できるサービスです。Gmailの無償アカウントはもちろん、Google Workspace を利用されている方であれば誰でも利用可能です。 Forms と AppSheet の連携 Forms から問合せがきたら AppSheet 側の案件管理と連携してくれたら、業務が楽になると思い作ってみることにしました。 今回は Forms からのアプリ作成を紹介します。 フォーム準備 Formsで問合せ受付フォームを作成する まずは、Forms で問合せ受付フォームを作成してみましょう。G-genでは Google Workspaceを活用して業務を実施していますので、Google Workspaceのメニュー上から Forms にアクセスします。 新しいフォームを作成から問合せ受付フォームを作成していきます。 詳細は割愛しますが、直感的にWebに公開できるフォームを作成することができます。 問合せ内容を Sheets に格納するため Forms の「回答」から「スプレッドシートにリンク」をクリックします。 「回答の送信先を選択」画面が表示されますので「作成」をクリックしてください。 問合せ内容の保存先の Sheets が作成されました。 こちら後々、 AppSheet 側のテーブルになってきますので シート名を変更しておきます。 アドオンを起動 AppSheet と Forms の連携はアドオンを利用して簡単に行うことができます。 Form の右上にあるメニューから「アドオン」をクリックします。 私の場合は、過去連携設定を行っているので「AppSheet」が表示されます。 ※初めての方は、Google Workspace Marketplace画面が表示されアドオンを追加する必要があります。 真ん中の「Launch」をクリックします。 アドオン画面が起動しますので「PREPARE」をクリックします。 「LAUNCH!」をクリックします。 AppSheetが立ち上がりました、アプリの設定を見ていきましょう AppSheetの設定 Dataの設定 Dataとはアプリで利用するデータを設定・管理するメニューとなります、設定内容を見てみましょう。 ほとんどの項目はFormsでの設定内容を反映し、自動的に設定されています。 今回は返信用メールアドレスのTYPEが「Text」となっていますので、「Email」に変更します。 問合せフォームとの連携を確認 問合せフォームとの連携を確認してみます 問合せ受付フォームに入力します。 AppSheetを見てみましょう、開発画面右側のエミュレーターで確認します。 データが入力されています、問合せフォームとの連携ができました。 次回は案件アプリとの連携編についてお伝えしたいと思います。 遠目塚美優希 (記事一覧) ビジネス推進部 G-genに飛び込んで、GoogleCloudの営業として日々奮闘中！ 福岡でフルリモートワーク勤務、在宅なのに毎朝お手製弁当を作成中

G-gen 又吉です。Google Cloud (旧称 GCP) のデータ変換パイプラインツールである Dataform を解説します。 概要 Dataform とは 特徴とメリット 料金 Dataform のコンポーネント コンポーネント構成 リポジトリ リポジトリとは ファイル構成 開発ワークスペース 開発ワークスペースとは 開発ワークスペースの初期化 開発手法 リリース設定 (release configuration) アクセス制御 Dataform のアクセス制御 Dataform から BigQuery へのアクセス制御 Dataform core と SQL Dataform core / SQLX とは Dataform core の機能 SQLX ファイル ファイル構成 config ブロック body ブロック データソースの宣言 ワークフローの実行 実行契機 (トリガ) 定期実行 (workflow configurations) 定期実行 (他のワークフローツール) ロギング 実行ログ ログ監視・通知 監査ログ 開発体験 コードの編集 DAG の表示 実行ログの表示 Dataform CLI 注意点と Tips CMEK は非対応 VPC Service Controls は非対応 リポジトリ構成の考えかた 公式のサンプルコード 概要 Dataform とは Dataform とは、BigQuery のためのフルマネージドなデータパイプライン管理ツールです。任意の SQL を実行し、テーブル間の依存関係を維持しながら テーブルやビューをテスト・開発・デプロイすることができます。 Dataform は ELT (Extract/Load/Transform) のうちの Transform を管理するためのツールである、と言えます。また、完全にサーバーレスであり、基盤の管理は必要ありません。また利用料金が無償であることも特徴です。 Dataform は 2022/08/25 に Preview 公開され、2023/05/04 に GA となりました。 ELT 処理の例 特徴とメリット 従来、BigQuery 上で SQL を組み合わせてデータ変換を実装しようとすると、複数の スケジュールされたクエリ (Scheduling queries) や ストアド・プロシージャ でクエリを定義し、それらの依存関係を管理するための仕組みとして Cloud Workflows などのワークフローツールを使うか、 dbt Cloud のような外部 SaaS ツールを使用するなどの工夫が必要でした。 Dataform は独自のスケジューラを有しています。また SQL ワークフローの開発に Dataform core というオープンソースのメタ言語を使用しており、このツールを使うことで、複数の SQL 間の依存関係を管理することができます。さらに、データの品質テストを行ったり、テーブルやフィールドの文書化を行うなどの機能も提供しています。これにより、BigQuery 上で行うデータ変換パイプラインが効率化され、 開発スピードの向上と運用負荷の軽減 に繋がります。 また Dataform は Git 統合されており、バージョン管理とチームによる SQL ワークフローの共同開発が可能です。 料金 Dataform の利用自体は 無料 です。 ただし、BigQuery でクエリを実行したり、データ変換パイプラインを構成するために Cloud Composer や Cloud Workflows を利用する際は、別途使用したリソースに対して課金されます。 参考 : BigQuery の料金 参考 : Cloud Composer の料金 参考 : Cloud Workflows の料金 Dataform のコンポーネント コンポーネント構成 Dataform のコンポーネント全体像は、以下のように図示されます。 リポジトリと開発ワークスペースの関係性 リポジトリ リポジトリとは Dataform で SQL ワークフローを開発する際、まず リポジトリ を作成します。リポジトリとは SQL ワークフローを構成する SQLX ファイル および JavaScript ファイルや Dataform 設定ファイル、パッケージ定義ファイルが格納するためのファイルリポジトリであり、その実体は Dataform 側で管理されている Git リポジトリです。 リポジトリ内のファイル操作は 開発ワークスペース の中で行います。 各リポジトリは Dataform 内部の Git リポジトリと統合されており、バージョン管理されます。また Dataform リポジトリを GitHub または GitLab リポジトリに接続可能です。 参考 : Connect to a third-party Git repository ファイル構成 リポジトリは以下の種別のファイルで構成されています。 Config files : JSON またはSQLX ファイル。一般的な設定・実行スケジュール等 Definitions : SQLX および JavaScript ファイル。テーブル/ビュー定義・SQL オペレーションの定義 Includes : JavaScript ファイル。変数や関数の定義 SQLX とはオープンソースの、SQL の拡張言語です。Dataform ではメタ言語 Dataform core でワークフローを記述しますが、その記述は主に SQLX で記述されることに加え、再利用可能な関数を JavaScript で定義可能です。つまり Dataform core は SQLX と JavaScript で構成されている、と考えることができます。 開発ワークスペース 開発ワークスペースとは 開発ワークスペース とは、リポジトリ内のファイルを編集・開発するための開発環境の定義です。チームで共同開発を行う際、Git でブランチを切って開発を行うのと同じように、開発ワークスペースを分けてファイル編集を行い、変更を commit/push することができます。 Git ブランチと同様、ある開発スペースで行ったファイルへの変更は、他の開発ワークスペースに影響しません。 参考： Create a Dataform development workspace 開発ワークスペースの初期化 リポジトリを作成すると、最初はファイルが一つも登録されておらず、また開発ワークスペースも存在しません。 最初の開発ワークスペースを作成し、初期化 (Initialize) を行うと、最小限の構成でファイルが生成されます。以後、これらのファイル群を編集してワークフローを開発していきます。 . ├── definitions/ ├── includes/ ├── dataform.json └── package.json No ディレクトリ or フォルダ 概要 1 definitions/ アセットを定義する SQLX もしくは JavaScript ファイルを格納するディレクトリ 2 includes/ リポジトリ全体で再利用可能なスクリプトと変数を格納するディレクトリ 3 dataform.json アセットをデプロイするプロジェクト ID と BigQuery スキーマを含むデフォルトの Config file 4 package.json デフォルトの依存関係ファイル 開発手法 開発ワークスペースではバックエンドで Git が利用されていることから、開発フローは Git でのそれと同じです。 開発ワークスペース上でファイルを編集したうえで、ワークスペースのローカルブランチに コミット を行うことで変更を確定できます。後から過去にコミットしたリビジョンへ巻き戻すことも可能です。 またワークスペースにコミットを行うと デフォルトブランチ (GitHub 等外部リポジトリと連携している場合はトラック対象リポジトリ) との差分が発生します。このデフォルトブランチは一般的な Git での main ブランチに相当します。デフォルトブランチへ push を行うことができ、逆にデフォルトブランチから開発ワークスペースに pull を行うことも可能です。 リリース設定 (release configuration) リリース設定 (release configuration) は SQL ワークフローのコンパイル作業を定義する設定です。 Dataform は、Dataform core (SQLX ファイル) で定義されたワークフローを実行する際に、コンパイルし SQL 化して BigQuery に投入します。コンパイル結果は compilation result というオブジェクトとなります。 デフォルトでは dataform.json に記載したプロジェクト ID や BigQuery のスキーマ情報等のパラメータが自動的に適用されますが、リリース設定ではこれをカスタマイズすることができます。リリース設定の作成はオプショナルであり、必須ではありません。 リリース設定の利用シーンとしては、同一の SQLX ファイルから複数環境向けに複数パターンの SQL を生成したい時が挙げられます。例えば、環境毎 ( prod , dev ) のパラメータをリリース設定のコンパイル変数に設定することで、Dataform 設定ファイルのパラメータをオーバーライドして SQL がコンパイルされ、環境別に異なるパラメータの SQL が生成されます。 参考 : Create a release configuration アクセス制御 Dataform のアクセス制御 Dataform 自体のアクセス制御は Cloud IAM で行われます。 Google Cloud により事前定義ロールが用意されており、開発者の Google アカウントにプロジェクトレベルで適切なロールを付与することで、Dataform へのアクセス制御が可能です。 ロール名 ロール ID 説明 Dataform 管理者 roles/dataform.admin Dataform リソースへのフルアクセス権限 Dataform 編集者 roles/dataform.editor リポジトリの読み取りとワークスペースへの編集権限 Dataform 閲覧者 roles/dataform.viewer Dataform リソースへの読み取り権限 参考： Control access with IAM Dataform から BigQuery へのアクセス制御 次に、Dataform 自体ではなく、Dataform から BigQuery へのアクセス制御について説明します。 Dataform が BigQuery に対してワークフローを実行するには、必要な権限を Dataform サービスアカウントに対し 付与する必要があります。 Dataform サービスアカウントは Dataform がバックエンドで用いるサービスアカウントであり サービスエージェント の一種です。最初の Dataform リポジトリを作成すると、以下の名称で自動的に作成されます。 service- ${ プロジェクト番号 } @gcp-sa-dataform.iam.gserviceaccount.com 例えばある Dataform から、あるプロジェクトの BigQuery の全テーブルに対し読み書きを許可したい場合は、プロジェクトレベルで BigQuery データ編集者 (roles/bigquery.dataEditor) と BigQuery ジョブユーザー (roles/bigquery.jobUser) のロールを付与します。 より権限範囲を絞るため、特定のデータセットまたはテーブルに対して BigQuery IAM 権限を付与することも可能です。 参考： Grant Dataform access to BigQuery BigQuery のアクセス制御と権限設計については以下の記事で詳細に解説されています。 blog.g-gen.co.jp Dataform core と SQL Dataform core / SQLX とは Dataform core はオープンソースのメタ言語であり、Dataform での SQL ワークフロー開発に利用されます。 Dataform core は主に SQLX で記述されます。SQLX はオープンソースの、SQL の拡張言語です。Dataform core を構成するファイルを SQLX ファイル と呼びます。 また JavaScript ブロックを SQLX ファイルの中に記述することで、再利用可能な関数を定義可能です。 つまり Dataform core は SQLX と JavaScript で構成されており、SQLX ファイルに記述するものである、と言うことができます。 参考 : Overview of Dataform core 参考 : GitHub - dataform-co/dataform Dataform core の機能 Dataform core では、以下のような定義が可能です。 BigQuery で実行される SQL の依存関係を管理 データの条件を予め定義し、条件に違反したデータが入力された場合に検知 テーブルと列の説明を記述 異なるクエリ間で関数や変数を再利用 このような特徴を活かし、ガバナンスを効かせたデータ変換パイプラインを構築することができます。 SQLX ファイル ファイル構成 SQLX ファイルはテキストファイルです。大きく config ブロックと body ブロックに分かれています。 SQLX ファイルの例 config ブロック config ブロックでは、出力テーブルタイプやラベルなどの構成メタデータを記述します。config ブロックで定義できる主要なオプションを以下に記載します。 No オプション 概要 備考 1 type 出力テーブル タイプを指定 テーブル (table)、増分テーブル (incremental) 、ビュー (view) 、マテリアライズド ビュー (materialized) を サポート しています 2 schema スキーマを指定 スキーマとは、BigQuery データセットを示します 3 tags ユーザー定義タグのリスト 例えば、 "daily" のタグが付いたアクションのみをワークフローとして実行したい場合などのユースケースで利用できます 4 description テーブルの説明 - 5 columns テーブル内の各列の説明 - 6 bigquery BigQuery 固有のウェアハウス オプションを指定 例えば、テーブルの パーティショニングやクラスタリング を定義できます 7 assertions 指定された 1 つ以上のルールに違反する行が検出可能 一意性、null 値、またはカスタム条件を定義し、違反した行を検知できます 8 dependencies config ブロックで依存関係を定義 body ブロックの SQL 内で依存関係が定義されてない場合でも依存関係を定義できます 参考： ITableConfig body ブロック body ブロックでは、主に SQL を定義します。Dataform core の組み込み関数等が利用可能です。body ブロックで実行できる主要なアクションを以下に記載します。 No アクション 概要 備考 1 依存関係の定義 ref 関数 を用いて Dataform で定義されたテーブルが参照可能 ref 関数を用いたクエリは、ref 関数で指定したテーブル作成後に実行されるため依存関係が確立されます 2 追加の SQL 操作を定義 クエリ前またはクエリ後に 1 つ以上の SQL を実行可能 (例) 先程の SQLX ファイルの例 44〜46 行目では、クエリ後のデータセットに対して閲覧者権限を付与する GRANT 文を記述しています 3 Java Script で SQL を生成 Java Scrept を用いて再利用可能な関数が定義可能 (カプセル化) 例えば、複数の SQLX ファイルで実行される SQL をカプセル化することで、SQL に修正が発生してもカプセル化したソースのみを修正するだけで済みます (保守性の向上) 参考： SQLX file body 参考： Dataform core reference 参考： Introduction to JavaScript in Dataform データソースの宣言 Dataform では、BigQuery テーブルをデータソースとして宣言できます。SQLX ファイルでは、以下のように記述します。 config { type: " declaration " , database: ${PROJECT_ID} , schema: ${DATASET_NAME} , name: ${TABLE_NAME} , } No オプション名 概要 1 type declaration を記述 2 database BigQuery が属するプロジェクト ID 3 schema データソースが存在する BigQuery データセットを入力 4 name データ ソースとして使用するテーブルまたはビューの名前を入力 参考 : Declare a data source ワークフローの実行 実行契機 (トリガ) Dataform の SQL ワークフローは以下をトリガにして実行することが可能です。 自動 workflow configurations による定期実行 Cloud Workflows と Cloud Scheduler を使用した定期実行 Cloud Composer による定期実行 手動 Google Cloud コンソール Dataform CLI Dataform クライアントライブラリ REST API 定期実行 (workflow configurations) Dataform 内で定期実行を行いたい場合に一番シンプルなのは workflow configurations を用いたスケジュールによる定期的な実行です。 workflow configurations は Dataform に組み込みのスケジューラです。workflow configurations 作成時は リリース設定 (release configuration) と実行対象の SQL ワークフローを選択し、スケジュールを設定します。 workflow configurations による定期実行の例 参考 : Schedule executions with workflow configurations 定期実行 (他のワークフローツール) より大きなデータパイプラインが存在し、Dataform はその中での一要素である場合、他のワークフロー管理ツールから API 経由で Dataform ワークフローを実行することも検討します。 以下は、Cloud Workflows から Dataform のワークフローを呼び出す例です。Google Cloud サービスの中では他に Cloud Composer なども考えられます。 Cloud Workflows と Cloud Scheduler を使用した定期実行の例 参考 : Schedule executions with Workflows and Cloud Scheduler 参考 : Schedule executions with Cloud Composer ロギング 実行ログ Dataform は Cloud Logging と統合されています。 ワークフローの実行ログは自動的に Cloud Logging に出力されます。タイムスタンプ、レポジトリ ID、終了コードなどが記録されます。 参考 : View Cloud Logging for Dataform ログ監視・通知 ログ監視によりワークフローの異常終了時にメールや Slack へ通知することも可能です。Cloud Logging の「ログベースの指標 + アラートポリシー」か「ログベースのアラート」機能で、ログ監視と通知を実装できます。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログ監視 監査ログ Dataform では監査ログも自動的に取得されます。Cloud Audit Logs の機能により監査ログが取得され、Cloud Logging に保存されます。 リポジトリや開発ワークスペースに対する作成、削除などの更新系操作はデフォルトで記録されます。 Git に関するコミット操作やファイル関連の操作はデータアクセス監査ログと呼ばれ、明示的に有効化する必要があります。 参考 : Dataform audit logging information 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - G-gen Tech Blog 開発体験 コードの編集 開発ワークスペース Web UI の CODE タブでは、リポジトリ内の SQL ワークフローの開発ができます。 CODE の画面例 また、開発中の SQL ワークフローを手動でコンパイルし実行することも可能です。その際、すべてもしくは一部のアクションのみを選択して実行したり、 タグ を指定して実行することもできます。 参考： Trigger execution DAG の表示 Web UI の COMPILED GRAPH タブでは、開発ワークスペースで定義された SQL ワークフローを directed acyclic graph (DAG) として表示できます。 DAG で可視化することで SQL の依存関係が一目でわかります。 DAG の例 実行ログの表示 実行された SQL ワークフローの実行ログは、Cloud Logging のログエクスプローラで確認できるほか、開発ワークスペース画面でも表示できます。 SQL ワークフローの詳細からは、各アクションのステータスや実行したクエリが確認でき、特定のアクションでエラーが発生した場合はそのエラーの理由を表示してくれます。 Dataform CLI ここまで紹介した Google Cloud の Dataform は、もともとオープンソースであった Dataform のフルマネージドサービスです。一方で、オープンソース版の Dataform CLI も引き続き存在します。 オープンソース版 Dataform CLI を利用すると、Google Cloud 環境外で Dataform を利用することができます。オープンソース版は、以下のようなデータベースに対応しています。 BigQuery Snowflake Redshift Azure SQL Data Warehouse PostgreSQL Dataform CLI の使用方法については、以下のドキュメントをご参照ください。 参考： Use the open-source Dataform CLI 注意点と Tips CMEK は非対応 2023年5月現在、Dataform は顧客管理の暗号鍵 (CMEK) で暗号化された BigQuery データセット・テーブルに対応していません。 VPC Service Controls は非対応 2023年5月現在、Dataform は VPC Service Controls の境界 (perimeter) で保護されたプロジェクト内の BigQuery に対応していません。 Dataform を使用するには、BigQuery リソースを含むプロジェクトを VPC Service Controls 境界から除外するか、Dataform CLI を用いてユーザー管理の環境から SQL ワークフローを実行する必要があります。 リポジトリ構成の考えかた 小規模の開発であれば SQL ワークフロー単位で一つのリポジトリを作成することが推奨されます。 しかし、リポジトリサイズが大きくなり、開発メンバーが増えるにつれ、以下のようなデメリットが生まれます。 マージ時のコンフリクト 可読性の低下 パフォーマンスの低下 クォータ制限に当たりやすくなる このような場合は、リポジトリの分割を検討します。しかし、リポジトリ分割には依存関係が分かりづらくなったり、ワークフロー実行スケジューリングの管理オーバヘッドの増加などデメリットもあるため、メリット / デメリットを把握してリポジトリ構成を設計する必要があります。 参考： Overview of repository size 参考： Splitting repositories 公式のサンプルコード 様々なユースケースに応じたサンプルコードが公式に用意されていますのでご参照ください。 参考 : Sample Dataform scripts 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Champion Innovator (AI/ML)。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリスト。好きな分野は生成 AI。 Follow @matayuuuu

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 サーバーレス構成ではクラウドサービスのポテンシャルを最大限引き出すことができます。モダンなアプリケーションの設計にはサーバーレスへの理解が必須であり、あらためて整理することにしました。 G-gen の佐々木です。当記事ではクラウドサービスにおける サーバーレス・アーキテクチャ について、Google Cloud のプロダクトを例に解説します。 サーバーレスの概要 サーバーレス・アーキテクチャとは 用語の定義 サーバーレスの特徴 メリットとデメリット 特徴① インフラリソースのプロビジョニング・運用管理が不要 インフラを意識しない 柔軟性は劣る 利用者の責任範囲 特徴② 動的なスケーリング 動的リソース確保とゼロスケール コールドスタート 特徴③ 従量課金制 コストメリット 課金の仕組みの例 料金予測の難しさ ユースケース サーバーレスに適した処理 Google Cloud プロダクトでの例 サーバーレスに向かないパターン アプリケーション実行環境に特有の要件があるケース リクエストに対する即応性が求められるケース リクエストを常時受信するケース サーバーレスを用いたシステム構築時の注意点 ステートレスな実装 ステートレスな実装 セッション情報の外部への保存 データの永続化 べき等性を考慮した実装 解説記事リンク サーバーレスの概要 サーバーレス・アーキテクチャとは サーバーレス・アーキテクチャ (サーバーレスコンピューティング) とは、Google Cloud (旧称 GCP) のようなクラウドプロバイダが所有している CPU やメモリ、ストレージなどの膨大なリソースの一部を、サービス利用者が 必要なときに必要な量だけ利用し 、 利用したぶんだけ料金を支払う 方式で提供されるサービスのアーキテクチャを指します。以下、単にサーバーレスと呼称します。 代表的なプロダクトとして Amazon Web Services (AWS) の AWS Lambda や、Google Cloud の Cloud Functions、Cloud Run 等の開発者向けサービスがあります。また Google Cloud の BigQuery に代表されるように、データベースなどのサービスを基盤を意識することなく利用できるようなサービスも、サーバーレスであるとされます。 つまりサーバーレスという言葉は、サーバリソースを意識せずに利用できるようなサービス全般を指します。 サーバーレスとその基盤 用語の定義 用語の定義にも触れておきます。クラウドネイティブを推進するための非営利団体 Cloud Native Computing Foundation (CNCF) は、サーバーレスという言葉の定義を「 FaaS、および API サービスとして提供される BaaS の双方あるいは一方を意味する言葉 」としています。 定義にある FaaS および BaaS は、以下のようなサービスを指します。 サーバーレスの種類 説明 該当する Google プロダクト FaaS (Function as a Service) イベントドリブンコンピューティングを提供する。 利用者はイベントや HTTP リクエストによってトリガーされる 関数 を利用して、アプリケーションコードを実行できる。 ・Cloud Functions (コンピューティング) BaaS (Backend as a Service) 認証やデータベースなどのアプリケーションのサブセットとなる機能を API 経由で提供する。 ・Firebase (データベース、認証ほか) ・Cloud Endpoints ・Cloud Run (コンテナ用プラットフォーム) ・BigQuery (分析用データベース) サーバーレスの特徴 メリットとデメリット サーバーレスの特徴は大きく 3 つあり、それぞれメリットとデメリットは以下のようになります。 特徴 メリット デメリット インフラリソースのプロビジョニング・運用管理が不要 インフラ構築・運用の負荷を削減 構成の柔軟性が低い 動的なスケーリング ・キャパシティプランニングが不要 ・ゼロスケールによるコスト削減 コールドスタートによる即応性の低さ 従量課金制 リソースに対するコスト効率が良い コスト予測がしにくい 特徴① インフラリソースのプロビジョニング・運用管理が不要 インフラを意識しない サーバーレス (Serverless) と書くとサーバーが存在しないように思えますが、実際にはクラウドプロバイダのデータセンターには物理的にサーバーが存在しています。 サーバーレスとは、実際には利用者が サーバーの存在を意識しなくてもよい ことを意味しています。コードやコンテナイメージなどを用意するだけで、それを動かすインフラのプロビジョニングや運用管理はクラウドプロバイダに任せることができます。 なお「 プロビジョニング 」という用語はサーバーリソースを割り当てて仮想サーバーなどのインフラリソースを作成することを指しており、「予め構築しておく」のようにイメージしておけば問題ありません。 サーバーレスの利用者は、バックアップや冗長化などの耐障害性の考慮や、OS やミドルウェアのパッチ適用などに労力を費やす必要がなくなり、アプリケーションの開発に集中することができます。 柔軟性は劣る このようなメリットのトレードオフとして、サーバーレスではアプリケーション実行環境に対する自由度はある程度制限されます。 たとえば Google Cloud の FaaS である Cloud Functions では、使用できる開発言語やコードの実行時間、同時実行数などの制限があり、IaaS である Compute Engine (GCE) と比較すると、インフラ構成の柔軟性は劣ります。 利用者の責任範囲 次の図は Google Cloud のドキュメント からの引用で、クラウドプロバイダと利用者の責任共有範囲を示したものです。サーバーレスの責任共有範囲は "SaaS" の列を見ればよいとお考えください。 サーバーレスは、アプリケーションロジック (Content) とリソースに対するアクセス制御 (Access policy) 以外の管理をクラウドプロバイダに任せることができます。 リソースに対するクラウドプロバイダと利用者の責任範囲 ( Google Cloud ドキュメントより引用) 特徴② 動的なスケーリング 動的リソース確保とゼロスケール サーバーレスでは必要に応じてインフラリソースが動的にスケーリングされるため、リソース量を事前に計画する必要がありません。 高負荷でリソースが足りなくなれば自動で追加 され、処理が完了して 不要になったリソースは自動的に解放される というように、待機状態のリソースがなくなるように動作します。 これにより、利用者が何もしなくても、アプリケーションに対する不測のリクエスト増加に対応できるほか、過剰にリソースを確保することによる料金の増加を抑えることができます。 特に重要な点として、サーバーレスでは処理を全く行っていないとき、リソースをゼロまでスケーリングすることができます ( ゼロスケール )。 後述の従量課金の特徴と合わせ、何も処理を行わないときはリソースの使用料金をゼロに抑えることができます。 コールドスタート スケーリングにおけるこのような特徴のデメリットとして、 コールドスタート によるレイテンシの増加があります。 リソースがゼロスケールされている状態でアプリケーションに対してリクエストが送信されると、まずリソースを確保し、アプリケーションを実行する準備ができてから実際の処理が行われるため、リクエストに対する即応性が損なわれます。 特徴③ 従量課金制 コストメリット Compute Engine のような IaaS や Google Kubernetes Engine (GKE)、Cloud SQL のようなマネージド型のクラウドサービスのうち「インスタンス」「ノード」といったリソースで仮想サーバーが事前にプロビジョニングされるサービスでは、使用するリソース量を事前に確保するので、何も処理を行っていなくても リソースが確保されている間は課金される のが基本的な仕組みとなっています。 それに対してサーバーレスでは、確保したリソースではなく 実際の処理でリソースを使用したぶんだけ課金される 仕組みとなっています。アプリケーションが実行されている時間や、リクエストの回数などに応じて料金が発生します。 課金の仕組みの例 Google Cloud の代表的なサーバーレスプロダクトの料金設定は以下のようになっています。 プロダクト 課金対象 無料枠 Cloud Functions ・CPU、メモリを実際の処理で使用した時間 ・呼び出し回数 ・外向きのネットワーク転送データ量(インターネット or 別リージョン宛の転送) ・毎月 200,000 GHz 秒 (CPU)、400,000 GB 秒(メモリ)まで無料 ・毎月 200 万回まで無料(呼び出し回数) ・毎月 5 GB まで無料(ネットワーク) Firebase (例：Firestore) ・実際に保存したデータ量 ・外向きのネットワーク転送量 ・書き込み操作の回数 ・読み取り操作の回数 ・削除操作の回数 ・毎月 1 GiB まで無料(データ量) ・毎月 10 GiB まで無料(ネットワーク) ・1 日 2 万件まで無料(書き込み) ・1 日 5 万件まで無料(読み取り) ・1 日 2 万件まで無料(削除) Cloud Endpoints ・API の呼び出し回数 ・毎月 200 万回まで無料 BigQuery ・クエリによって処理されたバイト数 ・ストレージに保存されたデータ量 ・毎月 1 TB まで無料(クエリ料金) ・毎月 10 GB まで無料(ストレージ料金) Cloud Run ・CPU、メモリを実際の処理で使用した時間 ・呼び出し回数 ・外向きのネットワーク転送データ量(インターネット or 別リージョン宛の転送) ・毎月 180,000 vCPU 秒 (CPU)、360,000 GiB 秒(メモリ)まで無料 ・毎月 200 万回まで無料(呼び出し回数) ・毎月 5 GB まで無料(ネットワーク) 表に記載したように、サーバーレスのプロダクトは無料枠が豊富に提供されており、単純な処理であれば無料枠の範囲にすべて収めることも可能です。 料金予測の難しさ サーバーレスの従量課金制のデメリットとして、 コスト予測がしにくい 点が挙げられます。 あらかじめ確保したリソースで料金を計算できる IaaS などと異なり、サーバーレスの料金は実際にどれだけ処理が行われるかに依存するため、運用を始める前にコストを見積もる難易度が高くなります。 ユースケース サーバーレスに適した処理 ここまで解説したサーバーレスの特徴により、以下のような用途でサーバーレスを活用することができます。 1回の処理時間が短い処理 常時動いているわけではなく、いつ呼ばれるか分からない処理 具体的には、以下のような処理が、サーバーレスに向いていると言えます。 アクセス量が小さいウェブサイトのバックエンド処理 データベースの変更 (挿入、更新、削除) をトリガーとしたロジックの実行 ETL (ELT) ジョブの実行 チャットボットのバックエンド処理 スケジュールされたバッチジョブの実行 機械学習モデルのホスティング Google Cloud プロダクトでの例 Cloud Functions や Cloud Run は、HTTP リクエストから直接呼び出せるほか、Eventarc や Pub/Sub との統合により、各種イベントをトリガーとした呼び出しができます ( イベントドリブン )。 Cloud Scheduler との統合により、cron ジョブを用いた関数の定期呼び出しが可能となっており、一定時間に収まるバッチ処理にも適しています。 また Cloud Run では、運用負荷を最小限に抑えながらウェブアプリケーションをホスティングしたり、機械学習で生成したモデルをコンテナイメージに含めてデプロイすることで、モデルを用いたオンライン予測 API をサーバーレスで実装したりできます。 サーバーレスに向かないパターン アプリケーション実行環境に特有の要件があるケース サーバーレスではクラウドプロバイダにリソースの運用管理を任せることができる代わりに、アプリケーション実行環境の構成が制限されます。 例えば Cloud Functions はコードをアップロードするだけで利用することができますが、開発言語の種類やバージョンに制限があります。 Cloud Run ではアップロード対象がコンテナイメージとなるため、構成の柔軟性はかなり高まりますが、2023年5月現在で GPU がサポートされていないため、GPU を用いた処理を実装する場合は Compute Engine や GKE を利用する必要があります。 また、これらのサーバーレスコンピューティングのプロダクトは、アプリケーション実行の際に確保できる CPU やメモリの上限が Compute Engine よりも低く設定されています。 リクエストに対する即応性が求められるケース リソースがゼロスケールされている状態からリクエストを処理する場合、コールドスタートにより、常時リソースを確保している非サーバーレスの実装よりもレイテンシが劣る場合があります。 コールドスタートによるレイテンシの増加 ただし、対策はあります。Cloud Run ではコールドスタートの対策として、最低限のリソースを常時確保しておくような設定ができます。この場合は当然ながら、ゼロスケールによるコストメリットとトレードオフです。 さらに Cloud Run では Startup CPU boost という機能があり、ある程度の追加課金によりコールドスタート時のパフォーマンスを改善するオプションも用意されています。これらの対策により、ゼロスケール時のレイテンシ問題はある程度対策可能です。 リクエストを常時受信するケース リソースの使用時間、および呼び出し回数に比例して料金が発生するサービス仕様上、アプリケーションに対するリクエストを常時受信するようなケースでは、IaaS や非サーバーレスのマネージドサービスを用いたほうが、リソースの 確約利用割引 などによるコストメリットが得られる可能性があります。 サーバーレスを用いたシステム構築時の注意点 ステートレスな実装 ステートレスな実装 動的スケーリングの特徴により、サーバーレスで構築するアプリケーションは、処理が内部でステート (状態) を持たない、つまり ステートレス な実装にすることが求められます。 セッション情報などのステートや永続化するべきデータは、スケーリングの際に失われないよう、外部のデータストアに保存するようにアプリケーションを設計します。 ステートレスな実装 上記の図は一例です。以下に、その意義を解説します。 セッション情報の外部への保存 例えば、サーバーレスなコンテナ実行環境が提供される Cloud Run で Web アプリケーションをホストする場合、リクエスト量に応じてコンテナの動的スケーリングが行われ、 同一クライアントからのリクエストが、常に同じコンテナに送られる保証はありません 。 そのためセッション情報などの一時データは、外部のインメモリデータベース等に保存するケースが多くなります。Google Cloud ではインメモリ DB である Redis や Memcached をホストするためのマネージドサービスである Cloud Memorystore が用意されています。 なお参考情報として、Cloud Run にはベストエフォートの セッションアフィニティ機能 は用意されていますが、主にキャッシング用途のための機能でありコンテナをステートフルにするための機能ではありません。 データの永続化 動的スケーリングによりリクエストが少ない場合にスケールインが行われる、つまりコンテナが破棄されるため、永続化する必要のあるデータは コンテナ側に保存することができません 。 永続化する必要のあるデータは Cloud SQL (マネージドの RDBMS) や Cloud Storage (オブジェクトストレージ) に格納するなど、Cloud Run のコンテナ側でデータを保持しないようにアプリケーションを設計します。 べき等性を考慮した実装 べき等性 (冪等性) とは、 ある操作を 1 回行っても複数回行っても結果が同じである 性質のことです。 たとえば Cloud Functions のような FaaS では、最大リソース量や実行時間の制限があることから、1 つの Cloud Functions 関数でアプリケーションのすべての処理を行うのではなく、複数の小さな処理ごとに関数を作成する マイクロサービス の形式で処理を実装します。 一連の処理フローを複数の関数で実装する場合、フローの途中で問題が発生した場合のキャンセル (ロールバック) 処理が複雑になり、途中の処理結果がデータストアに残ったまま最初からリトライしてしまうなど、べき等な結果が得られない危険性があります。 例えば、データベースへの書き込みがリトライにより2回行われたとき、同じレコードが重複して2行存在してしまうような結果になると、これはべき等ではありません。 べき等性がない場合のリトライ処理 逆に、以下のような実装がべき等な例であると言えます。 データの書き込み前に、データが存在することをチェックし、存在していれば書き込みを行わない データが既に存在していれば上書き、存在しなければ追記 (SQL における UPSERT ) べき等性がある場合のリトライ処理 解説記事リンク Google における代表的なサーバーレスプロダクトの詳細については、以下のブログ記事で解説しています。 BigQueryを徹底解説！(基本編) - G-gen Tech Blog Cloud Functionsを徹底解説！(基本編) - G-gen Tech Blog Cloud Run を徹底解説！ - G-gen Tech Blog Firebase を徹底解説！ - G-gen Tech Blog 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。最近は Dataflow を勉強中。 Follow @sasashun0805

G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) のサーバーレスコンテナサービスである Cloud Run の セッションアフィニティ 機能について解説します。 セッションアフィニティを使用することで、同じユーザーからのリクエストを特定のコンテナインスタンスにルーティングすることができます。 前提知識：Cloud Run とは Cloud Run におけるセッションアフィニティ ユースケース 注意点 セッションアフィニティはベストエフォート リビジョンのトラフィック分割との併用 プログラムから Cloud Run を呼び出す場合 設定方法 Cloud Run 前提知識：Cloud Run とは Cloud Run はサーバーレスな環境でコンテナを実行できるサービスです。 セッションアフィニティは、Cloud Run のうち、HTTP リクエストをトリガーとしてコンテナアプリケーションを実行する Cloud Run services に関する機能となります。 Cloud Run services の詳細については以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run におけるセッションアフィニティ Cloud Run でコンテナインスタンスが複数起動しているとき、クライアントからのリクエストはいずれかのインスタンスにルーティングされます。セッションアフィニティ機能により、クライアントごとのリクエストを同じコンテナインスタンスにルーティングすることができます。 セッションアフィニティを有効にすると、Cloud Run はクライアントからのリクエストに対する応答にセッションアフィニティ Cookie を追加します。Cloud Run はこの Cookie を使用してクライアントを識別し、以降のリクエストを同じコンテナインスタンスにルーティングします。 参考： Setting session affinity（ドキュメント） Cloud Run services のセッションアフィニティ ユースケース セッションアフィニティがベストエフォートである (後述) という仕様上、使用できる場面はいくぶん限定的なものになります。従来の「ロードバランサによる Web/AP サーバへのセッションアフィニティ (スティッキーセッション)」のイメージとは、少し違った使い方になります。 以下のようなユースケースが想定されます。 Cloud Run の背後にある Cloud SQL からユーザーデータを読み出すようなケースを考えてみます。Cloud SQL から読み出したデータはキャッシュとしてコンテナインスタンスに保持して、セッションアフィニティを有効にすることで、同じユーザーがアクセスしてきたときはコンテナインスタンスに保持されたキャッシュを利用することができます。 このケースでは、クエリを省略することでレスポンス速度の向上が見込めるほか、データベースへの余計な接続を減らし、Cloud SQL インスタンスのスペックを低めに抑えることができます。元のデータは Cloud SQL のデータベースで永続化されているため、たとえセッションアフィニティが解除されたとしても、再度クエリが行われるだけでデータが失われることはありません。 また Google Cloud の公式ブログでは、ダッシュボードのバックエンドとして Cloud Run を使用している場合に、データベースに対するクエリ結果をコンテナインスタンスにキャッシュし、セッションアフィニティでユーザーごとのクエリのキャッシュを有効活用することでダッシュボードの応答性を高める例が紹介されています。 参考： Cloud Run のセッション アフィニティで応答性を向上（プレビュー版公開時の公式ブログ） 注意点 セッションアフィニティはベストエフォート セッションアフィニティ Cookie の 有効期限（TTL）は 30 日 に設定されていますが、Cloud Run の自動スケーリングの仕様により、 クライアントがアフィニティを持っているかどうかにかかわらず、コンテナインスタンスはスケールインのタイミングで削除されてしまいます。 これは「Cloud Run のセッションアフィニティはベストエフォートである」のように表現されます。 したがって、通常は Cloud Run の外部で永続化するようなデータをコンテナインスタンスに保持し、セッションアフィニティを使用してユーザーを同一インスタンスにルーティングする、といった使い方は推奨されません。 たとえば、ショッピングカートのデータをコンテナインスタンスに保持するような場合、リクエストの減少によってコンテナインスタンスがスケールインしたタイミングで、そのインスタンスに接続していたユーザのショッピングカートの情報が失われてしまいます。 また、インスタンスあたりの同時接続数の上限に当たっている場合や、CPU 使用率が高くなっている場合でも、アフィニティが解除されてしまう可能性があります。 リビジョンのトラフィック分割との併用 Cloud Run services では、サービスをデプロイしたり構成を変更したりすると、 リビジョン（版） が作成されます。最新のリビジョンにリクエストを全てルーティングするだけではなく、複数のリビジョンに対してトラフィックを分割することができます。 Cloud Run のセッションアフィニティは リビジョン単位 で有効/無効にすることができ、トラフィック分割と併用した場合、 セッションアフィニティが優先 されます。 たとえば、「リビジョン A とリビジョン B にトラフィックを 50 % ずつ分割し、リビジョン A のみセッションアフィニティを有効にしている」場合を考えます。リビジョン A にルーティングされたリクエストは Cookie によってその後もリビジョン A にルーティングされ、リビジョン B にルーティングされたリクエストは Cookie がないため次回も A・B ランダムにルーティングされます。したがって、リクエストは徐々にリビジョン A にシフトされていくことになります。 また、リビジョン A・B の両方でセッションアフィニティを使用した場合、あるユーザーをリビジョン A のみ、別のユーザーをリビジョン B のみにルーティングさせることが可能です。 しかしセッションアフィニティはあくまでもベストエフォートであり、コンテナインスタンスがスケールインで削除されるなどした場合、次のリクエストが同一のリビジョンにルーティングされる保証はありません。 プログラムから Cloud Run を呼び出す場合 Web ブラウザから Cloud Run にアクセスする場合は Cookie は透過的に処理されます。一般的な Web ブラウザでは、同じドメインのサイトにアクセスする際は、Cookie を付与してリクエストするためです。 しかしそのような仕様のないプログラムから Cloud Run を呼び出す場合、初回のリクエストに対する応答に付与された Cookie を後続のリクエストに明示的に追加する必要がある点に注意しましょう。 設定方法 セッションアフィニティは Cloud Run services のサービス作成時、もしくは更新時に有効化 / 無効化することができます。 参考： セッション アフィニティを設定する（ドキュメント） 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。最近は Dataflow を勉強中。 Follow @sasashun0805

G-gen の杉村です。当記事では、AWS Lambda のサーバーレス関数から Google Cloud の Cloud Storage にファイルをアップロードする方法をご紹介します。認証・認可には Workload Identity を利用します。 はじめに 検証の概要 留意事項 構成 AWS から Google Cloud への認証 Workload Identity の概要 構築の流れ [A] IAM ロール作成・権限付与 [G] Cloud Storage バケット作成 [G] サービスアカウント作成 [G] サービスアカウントへの権限付与 [G] Workload Identity Pool 作成 [G] Workload Identity Pool にサービスアカウントを接続 [L] デプロイパッケージ作成 サンプルコード パッケージング [A] Lambda 関数デプロイ [A] S3 バケット作成・動作テスト はじめに 検証の概要 当記事では、Amazon Web Services（AWS）の AWS Lambda 関数から、Google Cloud の Cloud Storage バケットにファイルをアップロードする方法をご紹介します。 AWS Lambda 関数はサーバーレスプラットフォームであり、Python や Node.js のような各種言語のプログラムを動作させることができます。プログラムに Google Cloud のクライアントライブラリ（Cloud SDK）を組み込めば、Google Cloud の API へリクエストを送信して、Cloud Storage 等にデータを投入することが可能です。 留意事項 当記事では簡易化のため、IAM 権限の割り当てに関する考慮を最小限にしています。実際には最小権限の原則に基づき、適切な権限設定をしてください。 またサンプルコードでは例外処理やロギングに関する考慮を省略しています。実際には適切な考慮が必要です。 構成 当記事では、以下のような構成で検証を行います。 検証環境 Amazon Web Services (AWS) Amazon S3 バケット AWS Lambda 関数（Python） IAM ロール Google Cloud Cloud Storage バケット Workload Identity Pool サービスアカウント AWS から Google Cloud への認証 クロスクラウドのデータ移送では、認証と認可がポイントになります。 Google Cloud API へリクエストを行うには、Google アカウントまたはサービスアカウントの認証情報が必要です。まず思いつく方法は「Google Cloud でサービスアカウントを作成する。サービスアカウントキー（秘密鍵）を発行する。これを AWS Secrets Manager に保存する。キーを Lambda プログラムから参照して、Google Cloud への認証に用いる」といった方法でしょう。 参考 : Google での認証方法 - サービス アカウント 参考 : Authentication - google-api-core documentation - Service Accounts しかしこれには、キーローテーションの手間や、キー漏洩の危険性がつきまといます。 当記事では Workload Identity を使うことで、サービスアカウントキーを発行することなく、AWS から Google Cloud へ認証する方法を検証します。 Workload Identity の概要 Workload Identity では信頼する対象の AWS アカウントと IAM ロール名等を指定することで、AWS の IAM プリンシパルが Google Cloud サービスアカウントの権限を借用することを許可します。 参考 : Workload Identity 連携 参考 : AWS または Azure との Workload Identity 連携を構成する Google Cloud 側では、サービスアカウントに必要な IAM 権限を付与しておきます。AWS の IAM ロール等は、そのサービスアカウントから権限を借用して、Google Cloud API へリクエストを実行できます。 Workload Identity の概要 なお「権限の借用」とは、実際には OAuth 2.0 仕様に従ったトークン交換を指します。一時的なトークンが Google Cloud から AWS へ払い出されることで、これを用いて AWS 環境から Google Cloud API へのリクエストが可能になります。 構築の流れ 以下の流れで上記環境を構築します。 [AWS] IAM ロールを作成・権限付与 [Google Cloud] Cloud Storage バケットを作成 [Google Cloud] サービスアカウントを作成・権限付与 [Google Cloud] Workload Identity Pool を作成 [Google Cloud] Workload Identity Pool にサービスアカウントを接続 [ローカル] デプロイパッケージを作成 [AWS] Lambda 関数をデプロイ [AWS] S3 バケット作成 [AWS] 動作テスト 以降では、見出しの [G] は Google Cloud 側での作業を、 [A] は AWS 側での作業を、 [L] はローカル環境での作業を意味します。 [A] IAM ロール作成・権限付与 まずは、Lambda 関数にアタッチするための IAM ロールを作成します。Google Cloud 側の設定で、信頼する対象の IAM ロールとして名称が必要なため、先に作成します。 AWS マネジメントコンソールの IAM の画面に遷移し、左部メニューから ロール を選択します。 ボタン「ロールを作成」を押下します。 「信頼されたエンティティタイプ」として「AWS のサービス」を、ユースケースとして「Lambda」を選択し、ボタン「次へ」を押下します。 ロールの作成 次のステップ 許可を追加 では、付与する IAM ポリシーとして以下を追加します。 AWSLambdaBasicExecutionRole AmazonS3ReadOnlyAccess 後者の AmazonS3ReadOnlyAccess については、AWS アカウント内の全てのバケットの全オブジェクトに読取アクセスができてしまう強力な権限です。実際のプロジェクトでは、対象バケットを絞った独自の IAM ポリシーを作成することを推奨します。 次のステップではロール名を s3-to-gcs-role とし、最下部のボタン「ロールを作成」を押下します。 [G] Cloud Storage バケット作成 Google Cloud コンソールで Cloud Storage 画面へ遷移し、Cloud Storage バケットを作成します（Cloud Storage > バケット > ボタン「作成」）。 今回のバケット名は my-target-bucket-01 とします。 CREATE ボタンから作成 [G] サービスアカウント作成 次に IAM と管理 画面の左部メニューから サービス アカウント を選択して画面遷移し、サービスアカウントを作成します。（IAM と管理 > サービス アカウント > ボタン「サービス アカウントを作成」） 今回のサービスアカウント名は s3-to-gcs とします。割り当てられるメールアドレスは s3-to-gcs@(your-pj-name).iam.gserviceaccount.com となりました。 なおウィザードの中で以下のように「このサービス アカウントにプロジェクトへのアクセスを許可する」というプロセスがありますが、ここでは何の権限もつけなくても構いません。次のステップで、権限を付与します。 サービスアカウントの作成画面 [G] サービスアカウントへの権限付与 再び Cloud Storage 画面へ遷移し、先程作成したサービスアカウントに、対象の Cloud Storage バケットへのオブジェクト管理権限を付与します。 バケット一覧画面から先程のバケット名を選択したあと、 権限 タブへ移動します。画面中程にあるボタン「アクセス権を付与」をクリックします。 バケットへのアクセス権を付与 新しいプリンシパル に先ほど作成したサービスアカウントのメールアドレスを、ロールとして Storage オブジェクト管理者 を割り当てます。 IAM ロールの割り当て なお必要な処理がアップロードだけであれば Storage オブジェクト作成者 でも構いません。この権限の場合、オブジェクトの読み取り（ダウンロード）や削除、上書きはできません。なお、Cloud Storage のおいては、上書き処理は「一度削除してから再度書き込み」という処理と同等です。 [G] Workload Identity Pool 作成 IAM と管理 画面の左部メニューから Workload Identity 連携 を選択します。 ボタン「プールを作成」を押下し、新しい Workload Identity プール を作成します。Workload Identity プールとは、Workload Identity 設定の管理単位です。 作成画面を遷移すると以下の順で入力することになります。今回は以下のような値を入力しました。各名称は任意ですので、実際の環境では適切な名称を付けてください。 設定名 値 名前 my-aws-environment プール ID my-aws-environment プロバイダの選択 AWS プロバイダ名 my-aws-account プロバイダ ID my-aws-account AWS アカウント ID (自分の AWS アカウント ID を入力) なお最後に「プロバイダ属性を構成する」がありますが、ここは何も手を加えずにボタン「保存」を押下します。 プロバイダ属性は今回は編集しない ここで詳細な属性マッピングを構成することもできますが、デフォルトのままで通常の用途には足ります。詳細は以下のドキュメントをご参照ください。 参考 : AWS または Azure との Workload Identity 連携を構成する ‐ 属性のマッピングと条件を定義する [G] Workload Identity Pool にサービスアカウントを接続 Workload Identity プール作成が完了すると、プールの詳細画面に遷移します。 上部のボタン「アクセスを許可」を押下し、このプールとリンクさせるサービスアカウントを選択します。 先程作成したサービスアカウント s3-to-gcs を選択します。 プリンシパル（サービス アカウントにアクセスできる ID）の選択 では、デフォルトでは プール内のすべての ID が選択されています。この状態だと、先程指定した AWS アカウント ID 内の全てのプリンシパル（IAM ユーザーや IAM ロール等）がサービスアカウント権限を借用できるようになります。 フィルタに一致する ID のみ を選択し、属性名として aws_role を選択、属性値に arn:aws:sts::(AWS Account ID):assumed-role/(IAM ロール名) を入力することで、特定の IAM ロールだけを許可することもできます。 サービスアカウントを接続 ボタン「保存」を押下すると、構成ファイルのダウンロードができます。このファイルは単なる設定ファイルであり、機密データは含まれていません。このファイルをデプロイパッケージに入れることになります。プロバイダとして先程の my-aws-account を選択して、ボタン「構成をダウンロード」を押下し、ローカル環境にダウンロードしてください。 [L] デプロイパッケージ作成 サンプルコード Lambda 関数のソースコードは以下を使います。繰り返しになりますが、以下はあくまでサンプルコードであり、実際には例外処理やロギング、セキュアなコーディングに関する考慮をしたうえでご利用ください。 import boto3 from google.cloud import storage def get_from_s3 (s3_bucket_name, s3_object_name): # クライアント生成等 s3 = boto3.client( 's3' ) s3_object_path=f "my_s3_path/{s3_object_name}" tmp_file_path=f "/tmp/{s3_object_name}" # ファイルを Lambda の一時領域にダウンロード s3.download_file(s3_bucket_name, s3_object_path, tmp_file_path) print (f "{s3_bucket_name}/{s3_object_path} was downloaded to {tmp_file_path}." ) return tmp_file_path def upload_to_gcs (tmp_file_path, gcs_bucket_name): # クライアント生成等 gcs = storage.Client() file_name=tmp_file_path.split( '/' )[- 1 ] gcs_object_path=f "my_gcs_path/{file_name}" bucket = gcs.bucket(gcs_bucket_name) blob = bucket.blob(gcs_object_path) # オブジェクトを Cloud Storage バケットにアップロード blob.upload_from_filename(tmp_file_path) print (f "{tmp_file_path} was uploaded to {gcs_bucket_name}/{gcs_object_path}." ) return None def lambda_handler (event, context): # event から各種情報を取得 s3_bucket_name=event[ 's3_bucket_name' ] s3_object_name=event[ 's3_object_name' ] gcs_bucket_name=event[ 'gcs_bucket_name' ] # オブジェクトを S3 バケットから取得 tmp_file_path=get_from_s3( s3_bucket_name=s3_bucket_name, s3_object_name=s3_object_name ) # オブジェクトを Cloud Storage バケットにアップロード upload_to_gcs( tmp_file_path=tmp_file_path, gcs_bucket_name=gcs_bucket_name ) return { 'statusCode' : 200 } この Lambda 関数のソースコードは、以下のような処理を行います。 event として s3_bucket_name s3_object_path gcs_bucket_name を受け取る s3_bucket_name : ファイル取得元の S3 バケット s3_object_name : 取得対象の S3 オブジェクト名 gcs_bucket_name : アップロード先の Cloud Storage バケット名 Amazon S3 バケットの my_s3_path/ パスからオブジェクトを Lambda 内の /tmp にダウンロード /tmp にダウンロードしたオブジェクトを Cloud Storage の my_gcs_path/ パスにアップロード クライアントライブラリの詳細な使用方法については、以下の公式ドキュメントを参照してください。 参考 : Boto3 documentation - S3 参考 : google-cloud-storage - Class Blob パッケージング ローカル環境で、新規ディレクトリを作成してそのディレクトリに移動したあと、上記ソースコードを lambda_function.py として配置します。 また先程ダウンロードした Workload Identity Pool の構成ファイルも同じディレクトリに配置します。 Lambda では、Google Cloud クライアントライブラリのような外部ライブラリはデプロイパッケージに含ませる必要があるため、以下のコマンドでディレクトリ内に展開します。 pip install google-cloud-storage -t . pip コマンドの -t オプションは、指定ディレクトリに Python パッケージをダウンロードできるオプションです。 -t . によりカレントディレクトリに、依存関係を含む各種モジュールが展開されます。 次に以下のコマンドで1段階上位のディレクトリに zip ファイルを作成します。 zip -r ../function.zip . [A] Lambda 関数デプロイ 以下のコマンドで作成した zip パッケージを Lambda 関数としてデプロイします。 aws lambda create-function コマンドを用います。 Lambda 関数には環境変数を持たせることができます。Workload Identity 構成ファイル名と、Google Cloud プロジェクト ID を環境変数として持たせます。以下コマンドの最初の3行はご自身の環境の値に置き換えてください。 AWS_ACCOUNT_ID = " 123456789012 " CONFIG_FILE_NAME = " clientLibraryConfig-my-aws-account.json " GOOGLE_CLOUD_PROJECT_ID = " my-project-id " aws lambda create-function \ --function-name s3-to-gcs \ --zip-file fileb://../function.zip \ --handler lambda_function.lambda_handler \ --role arn:aws:iam:: ${AWS_ACCOUNT_ID} :role/s3-to-gcs-role \ --runtime python3. 10 \ --region ap-northeast-1 \ --environment " Variables={GOOGLE_APPLICATION_CREDENTIALS= ${CONFIG_FILE_NAME} ,GOOGLE_CLOUD_PROJECT= ${GOOGLE_CLOUD_PROJECT_ID} } " \ --timeout 120 一度デプロイしたあとの関数は、以下のコマンドで修正できます。もちろん、コンソール画面から修正することもできます。 参考 : aws lambda update-function-configuration 参考 : aws lambda update-function-code [A] S3 バケット作成・動作テスト Lambda の Web コンソール画面でデプロイした関数を選択し、 テスト タブから今回の関数の動作確認を行うことができます。 事前に適当な S3 バケットを作成し、 my_s3_path フォルダ配下に test.txt を配置します。 その後、以下の JSON を イベント JSON に入力し、右上のボタン「テスト」を押下して動作テストを実行してください。JSON の値は自環境のものに置き換えます。 { "s3_bucket_name": "my-test-bucket", "s3_object_name": "test.txt", "gcs_bucket_name": "my-target-bucket-01" } イベント JSON を指定してテストを実行 画面上に標準出力や標準エラー出力が表示されます。実際に Cloud Storage バケットの中身も確認してください。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の藤岡です。当記事では、Google Workspace の Enterprise、Education Standard、Education Plus エディションで使えるセキュリティセンターの機能を紹介します。 概要 Google Workspace とは セキュリティセンターとは 利用の前提 利用可能なエディション 権限 セキュリティセンターの機能 セキュリティダッシュボード 調査ツール セキュリティの状況ページ 類似機能との比較 概要 Google Workspace とは Google Workspace は、Google が提供するクラウド型グループウェアサービスです。Gmail や Google カレンダー、Google ドライブなど様々なアプリケーションがパッケージングされています。 詳細は以下の記事をご参照ください。 blog.g-gen.co.jp セキュリティセンターとは Google Workspace の セキュリティセンター は「組織のアカウント設定の可視化」「ユーザーのアクティビティ調査」「潜在的な脅威への対処」などに役立つツール群です。 機能には大きく分けて以下の 3 つがあります。各機能の説明は後述します。 セキュリティダッシュボード 調査ツール セキュリティの状況ページ セキュリティセンターの各機能は Google Workspace の Admin コンソール で [ セキュリティ ] > [ セキュリティ センター ] へ遷移することで利用できます。 セキュリティ センターの表示 利用の前提 利用可能なエディション セキュリティセンターは以下のエディションで利用可能です。 Enterprise の全エディション Enterprise Essentials Enterprise Standard Enterprise Plus Education の以下のエディション Education Standard Education Plus ただし、調査ツール使用時には、データソースによってサポートされているエディションが異なるため注意してください。 例えば、 ユーザーのログイベント と ドライブのログイベント で比較した場合、Enterprise Standard エディションのユーザーは「ユーザーのログイベント」は表示できますが「ドライブのログイベント」は表示できません。他にもプレミアムエディション（Enterprise Plus, Education Plus）は、調査ツールの高度な機能を使用できます。 データソース 利用可能なエディション ユーザーのログイベント Enterprise Plus, Education Plus, Cloud Identity Premium, Enterprise Standard, Education Standard ドライブのログイベント Enterprise Plus, Education Plus データソースごとに、どのエディションが対応しているのかは ドキュメント に記載されています。 参考： セキュリティ センターについて / Google Workspace の各エディションの比較 権限 セキュリティセンターを使用するためには、閲覧に使う Google アカウントに セキュリティ センターの権限 が必要です。 セキュリティ センターの権限の中でも、以下のように「ダッシュボード」や「セキュリティの状況」など機能ごとにより厳密に権限を制限することもできます。 セキュリティ センターの権限 最も強い管理者ロールである「 特権管理者ロール 」にも、セキュリティ センターの管理者権限が含まれています。しかし、ユーザーに業務上必要となる最小の権限だけを与えるべきであるという「 最小権限の原則 」に従い、セキュリティ センターを使うユーザーに特権管理者ロールを付与するのではなく、セキュリティ センターの権限の中から必要な権限を選択した カスタムロール を作成し付与することが推奨されています。 参考： セキュリティ センターの管理者権限 セキュリティセンターの機能 セキュリティダッシュボード セキュリティ ダッシュボード は、外部とのファイル共有状況や不審なユーザーからのログイン試行の回数などセキュリティに関する情報を時系列でダッシュボードとして確認できる機能です。 表示方法は、Admin コンソールの [ セキュリティ ] > [ セキュリティ センター ] > [ ダッシュボード ] です。 セキュリティの状況 ダッシュボードはカスタムが可能で、並び替えや不要なレポートを削除することができます。 ダッシュボードで閲覧できるデータは、最大で現在の日付から 180 日間のデータです。 ダッシュボードに使用できるレポートは ドキュメント をご参照ください。 調査ツール 調査ツール は、Gmail や データポータル、デバイスのログに加え、組織のデータに Google のスタッフがアクセスした際の操作ログである「アクセスの透過性に関するログイベント」など様々なデータソースのログから調査できるツールです。 選択できるデータソースの詳細については ドキュメント をご参照ください。 また、調査ツールで管理者が行った操作は 管理ログイベント で確認できます。 表示方法は、Admin コンソールの [ セキュリティ ] > [ セキュリティ センター ] > [ 調査ツール ] です。 調査ツール 前述の通り、選択できるデータソースはエディションによって異なるため注意してください。また、プレミアムエディション（Enterprise Plus, Education Plus）は、調査ツールの高度な機能を使用できます。高度な機能の一例は以下の通りです。 調査の保存や共有、削除 調査のコピーを作成 検索結果を属性別にグループ化 なお、 権限 の項にあるように、調査ツールのデータソースごとに権限を割り当てることができます。そのため、調査に必要なデータソースへのアクセスが許可されているのか確認が必要です。 参考： セキュリティ調査ツールのプレミアム機能 セキュリティの状況ページ セキュリティの状況ページ は、推奨のセキュリティ設定やおすすめのセキュリティ対策についてアドバイスを得られる機能です。 通常であれば、カレンダーやドライブ、Gmail など各サービスのセキュリティに関わる設定を個別で設定、確認するところを、セキュリティの状況のページから一覧で確認できます。 表示方法は、Admin コンソールの [ セキュリティ ] > [ セキュリティ センター ] > [ セキュリティの状況 ] です。 セキュリティの状況 類似機能との比較 Gmail のログは、調査ツール以外にも、 メールログ検索 で確認できます。しかし、検索可能な属性や期間が異なります。 メールログ検索 メールログ検索は、送受信者や件名のいずれかで検索できますが、30 日以上前のログは受信者とメッセージ ID の情報がないと検索できません。 30 日以上前のメールログを検索 それに対して調査ツールでは、DKIM や SPF ドメイン、位置情報や添付ファイルなど様々な属性から検索できます。それぞれ検索可能な属性については各ドキュメントをご参照ください。 参考： メールログ検索を使用してメールを検索する / 調査ツールで Gmail のログイベントを検索する 藤岡 里美 (記事一覧) クラウドソリューション部 接客業からエンジニアへ。2022年9月 G-gen にジョイン。Google Cloud 認定資格は全冠。2023 夏アニメのオススメは、ダークギャザリング。箏を習っています :) Follow @fujioka57621469

G-gen の堂原です。 ChatGPT (GPT-4) を使ってほぼ頭を使うことなく、Cloud Functions を作成してみたので、その過程を紹介します。 はじめに 事前準備 事前準備も ChatGPT を使用 Cloud Functions コード生成 一発で Python コード生成 エラー修正も可能 動作確認 さいごに はじめに 今や知らない人はいないであろう、OpenAI 社が公開している AI チャットサービスである ChatGPT。対話能力もさることながら、コード生成能力の高さも注目されています。 G-gen では ChatGPT の利用が会社で補助されていることもあり、早速使ってみました。 prtimes.jp 当記事では ChatGPT を使って、以下のような仕様の Cloud Functions を作成、デプロイしてみました。 言語は Python。 Google Cloud Storage (GCS) に CSV ファイルがアップロードされたことをトリガーに実行される。 GCS から、アップロード CSV ファイルを読み取る。 読み取ったデータは BigQuery のテーブルに保存する。 事前準備 今回、事前準備として以下のことを実施しました。 サンプルの CSV ファイル生成 GCS バケット作成 BigQuery データセット作成 BigQuery テーブル作成 生成されたコード的には不要でしたが今回は事前に用意しました。 事前準備も ChatGPT を使用 サンプルとなる CSV ファイルと、それに対応するテーブル作成についても ChatGPT におまかせしました。 [ 質問文 ] Please create a sample CSV file. すると以下のような CSV を出力してくれました。 id,name,category,price 1,Wireless Mouse,Electronics,25.99 2,Bluetooth Keyboard,Electronics,49.99 3,32GB USB Flash Drive,Electronics,15.99 4,Portable Charger,Electronics,29.99 5,Water Bottle,Sports,12.99 6,Yoga Mat,Sports,21.99 7,Dumbbell Set,Sports,59.99 8,Running Shoes,Sports,89.99 続けて、上記 CSV に対応する BigQuery テーブルを作成してもらいます。 [ 質問文 ] Please tell me the query to create a BigQuery table for this CSV file. すると以下のようなクエリを出力してくれました。 CREATE TABLE your_dataset.products ( id INT64, name STRING, category STRING, price FLOAT64 ); ちなみにコンソールでどうやってこのクエリを実行するかも解説してくれてます。 BigQuery テーブルの作成方法についての回答文 Cloud Functions コード生成 一発で Python コード生成 では、本命であるコード生成を実行してもらいます。 [ 質問文 ] I would like to deploy a function on Google Cloud Functions that retrieves CSV files from Google Cloud Storage and stores their data in BigQuery. Please provide me with the corresponding code and a requirements.txt file. すると以下のようなコード、requirements.txt 及び Cloud Functions をデプロイする gcloud コマンドを出力してくれました。 requirements.txt google-cloud-storage==1.42.3 google-cloud-bigquery==2.28.1 main.py import os import tempfile from google.cloud import storage from google.cloud import bigquery def csv_to_bigquery (event, context): """Triggered by a change to a Cloud Storage bucket. Args: event (dict): Event payload. context (google.cloud.functions.Context): Metadata for the event. """ bucket_name = event[ 'bucket' ] file_name = event[ 'name' ] dataset_id = os.environ.get( 'BIGQUERY_DATASET_ID' ) table_id = os.environ.get( 'BIGQUERY_TABLE_ID' ) # Create BigQuery client bigquery_client = bigquery.Client() # Create Storage client storage_client = storage.Client() bucket = storage_client.get_bucket(bucket_name) blob = storage.Blob(file_name, bucket) # Download the CSV file to a temporary file with tempfile.NamedTemporaryFile(mode= 'wb' , delete= True ) as temp_csv: blob.download_to_file(temp_csv) temp_csv.flush() # Load CSV into BigQuery dataset_ref = bigquery_client.dataset(dataset_id) table_ref = dataset_ref.table(table_id) job_config = bigquery.LoadJobConfig() job_config.source_format = bigquery.SourceFormat.CSV job_config.autodetect = True with open (temp_csv.name, "rb" ) as source_file: job = bigquery_client.load_table_from_file(source_file, table_ref, job_config=job_config) job.result() # Wait for the job to complete print (f "Loaded {job.output_rows} rows into {dataset_id}:{table_id} from {file_name}." ) gcloud コマンド gcloud functions deploy csv_to_bigquery \ --runtime python310 \ --trigger-resource YOUR_TRIGGER_BUCKET_NAME \ --trigger-event google.storage.object.finalize \ --set-env-vars BIGQUERY_DATASET_ID=YOUR_DATASET_ID,BIGQUERY_TABLE_ID=YOUR_TABLE_ID requirements.txt と main.py をカレントディレクトリに設置し、 YOUR_TRIGGER_BUCKET_NAME 、 YOUR_DATASET_ID 及び YOUR_TABLE_ID に適切な値を設定してコマンドを実行します。 エラー修正も可能 しかし、コマンドを実行すると google-cloud-bigquery のバージョンエラーが表示されてしまいました。 そこでエラー文をそのまま記載して、対処法を聞いてみます。 [ 質問文 ] I encounterd the following error: """ ERROR: (gcloud.functions.deploy) OperationError: code=3, message=Build failed: Collecting google-cloud-storage==1.42.3 Downloading google_cloud_storage-1.42.3-py2.py3-none-any.whl (105 kB) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 106.0/106.0 kB 3.0 MB/s eta 0:00:00 ERROR: Ignored the following versions that require a different python version: 2.10.0 Requires-Python >=3.6, <3.10; 2.11.0 Requires-Python >=3.6, <3.10; 2.12.0 Requires-Python >=3.6, <3.10; 2.13.0 Requires-Python >=3.6, <3.10; 2.13.1 Requires-Python >=3.6, <3.10; 2.14.0 Requires-Python >=3.6, <3.10; 2.15.0 Requires-Python >=3.6, <3.10; 2.16.0 Requires-Python >=3.6, <3.10; 2.16.1 Requires-Python >=3.6, <3.10; 2.17.0 Requires-Python >=3.6, <3.10; 2.18.0 Requires-Python >=3.6, <3.10; 2.19.0 Requires-Python >=3.6, <3.10; 2.20.0 Requires-Python >=3.6, <3.10; 2.21.0 Requires-Python >=3.6, <3.10; 2.22.0 Requires-Python >=3.6, <3.10; 2.22.1 Requires-Python >=3.6, <3.10; 2.23.0 Requires-Python >=3.6, <3.10; 2.23.1 Requires-Python >=3.6, <3.10; 2.23.2 Requires-Python >=3.6, <3.10; 2.23.3 Requires-Python >=3.6, <3.10; 2.24.0 Requires-Python >=3.6, <3.10; 2.24.1 Requires-Python >=3.6, <3.10; 2.25.0 Requires-Python >=3.6, <3.10; 2.25.1 Requires-Python >=3.6, <3.10; 2.25.2 Requires-Python >=3.6, <3.10; 2.26.0 Requires-Python >=3.6, <3.10; 2.27.0 Requires-Python >=3.6, <3.10; 2.27.1 Requires-Python >=3.6, <3.10; 2.28.0 Requires-Python >=3.6, <3.10; 2.28.1 Requires-Python >=3.6, <3.10; 2.29.0 Requires-Python >=3.6, <3.10; 2.6.2 Requires-Python >=3.6, <3.9; 2.7.0 Requires-Python >=3.6, <3.10; 2.8.0 Requires-Python >=3.6, <3.10; 2.9.0 Requires-Python >=3.6, <3.10 ERROR: Could not find a version that satisfies the requirement google-cloud-bigquery==2.28.1 (from versions: 0.20.0, 0.21.0, 0.22.0, 0.22.1, 0.23.0, 0.24.0, 0.25.0, 0.26.0, 0.27.0, 0.28.0, 0.29.0, 0.30.0, 0.31.0, 0.32.0, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0, 1.7.2, 1.8.0, 1.8.1, 1.8.2, 1.9.0, 1.9.1, 1.10.0, 1.10.1, 1.11.1, 1.11.2, 1.11.3, 1.11.4, 1.12.0, 1.12.1, 1.12.2, 1.13.0, 1.13.1, 1.14.0, 1.14.1, 1.15.0, 1.15.1, 1.16.0, 1.16.1, 1.17.0, 1.17.1, 1.18.0, 1.18.1, 1.19.0, 1.19.1, 1.20.0, 1.21.0, 1.22.0, 1.23.0, 1.23.1, 1.24.0, 1.25.0, 1.26.0, 1.26.1, 1.27.2, 1.28.0, 1.28.1, 1.28.2, 1.28.3, 2.0.0, 2.1.0, 2.2.0, 2.3.1, 2.4.0, 2.5.0, 2.6.0, 2.6.1, 2.30.0, 2.30.1, 2.31.0, 2.32.0, 2.33.0, 2.34.0, 2.34.1, 2.34.2, 2.34.3, 2.34.4, 3.0.0b1, 3.0.0, 3.0.1, 3.1.0, 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.3.3, 3.3.5, 3.3.6, 3.4.0, 3.4.1, 3.4.2, 3.5.0, 3.6.0, 3.7.0, 3.8.0, 3.9.0, 3.10.0) ERROR: No matching distribution found for google-cloud-bigquery==2.28.1; Error ID: 656dd225 """ How can I resolve this issue? すると requirements.txt を次のように修正してくださいと返信されました。 requirements.txt google-cloud-storage==1.43.0 google-cloud-bigquery==3.10.0 ということで、上記の通り修正し gcloud コマンドを再実行すると、今度はちゃんとデプロイすることができました。 動作確認 事前準備で ChatGPT に作ってもらった CSV ファイルをトリガー指定した GCS バケットにアップロードしてみます。 すると数分もしないうちに BigQuery テーブルにデータが追加されました。 BigQuery テーブルに格納されたデータ さいごに コードに関しても一回ぐらいはエラー修正が必要になるのかなと思っていたのですが、まさかの一発成功でした。 今回は検証としてシンプルなコードを生成してもらいました。 このコードをもとに自身で機能を追加していっても良いですし、追加したい機能をそのまままた ChatGPT にお願いするのも良いと思います。 最近日本でも公開された Google の AI チャットサービスである「Bard」ですが コード生成機能がつい先週実装された ということで、そちらのほうも近日検証してみたいと思います。 堂原 竜希 (記事一覧) データアナリティクス準備室。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023, 2024に選出 (2024年はRookie of the yearにも選出)。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @matayuuuu

G-gen の杉村です。Google Cloud (旧称 GCP) の PostgreSQL 互換のフルマネージドサービスである AlloyDB for PostgreSQL について解説します。 概要 AlloyDB とは サービスの位置づけ PostgreSQL との互換性 料金 無料トライアル アーキテクチャ クラスタ プライマリインスタンス 読み取りプールインスタンス ネットワーク クロスリージョンレプリケーション 可用性 スタンバイインスタンス 読み取りワークロードの可用性 可用性 SLA 災害対策 (DR) スケーラビリティ 分析（OLAP） AlloyDB カラムナエンジンとは 自動カラムナ化 手動でのカラムストア管理 BigQuery からの連携クエリ バックアップ・リストア バックアップの種類 継続バックアップとそのリストア オンデマンドバックアップ・自動バックアップとそのリストア 接続 クライアント ネットワーク 認証・認可 AlloyDB Auth proxy AlloyDB Auth proxy とは パブリック IP を使った接続 通信要件 Cloud Run における Auth proxy 利用 マネージドコネクションプール データのインポート・エクスポート インポート エクスポート 移行ツール AI 機能 自然言語によるクエリ モデルエンドポイント管理 AI 支援によるトラブルシューティング セキュリティ・監査 暗号化 監査ログ クラスタ管理オペレーションの監査ログ DB オペレーションの監査ログ 運用とモニタリング モニタリング インスタンスの停止・起動・再起動 チューニング Query Insights adaptive autovacuum インデックスアドバイザ Cloud SQL からの移行 AlloyDB Omni 概要 AlloyDB とは AlloyDB for PostgreSQL は、Google Cloud が提供する高性能な PostgreSQL 互換のフルマネージドサービスです。様々なアプリケーションから高性能なオペレーショナルデータベースとして利用できます。 Cloud SQL と同じく DBaaS（DB as a Service）として分類することができますが、AlloyDB はパフォーマンス・可用性・スケーラビリティの面で通常の PostgreSQL よりも優れており、特に厳しい非機能要件があるエンタープライズシステムに対応できるデータベースとして位置づけられています。 参考 : AlloyDB の概要 AlloyDB はストレージ機構などに独自の技術が使用されており、その性能は標準の PostgreSQL と比較してトランザクション処理では「4倍以上高速」、分析処理では「最大100倍高速」と公称されています。またバックアップ、パッチ適用、ストレージの拡張など多くの運用タスクが自動化されており、運用の容易さも特徴です。可用性 SLA は 99.99% です。 参考 : AlloyDB for PostgreSQL の仕組み: データベース対応のインテリジェントなストレージ 参考 : AlloyDB Service Level Agreement (SLA) サービスの位置づけ Google Cloud のフルマネージドのデータベースサービスとしては、他に Cloud SQL がありますが、AlloyDB は特に高いパフォーマンスが求められるシステムに対応できるデータベースとして位置づけられています。 このサービス展開は、Amazon Web Services（AWS）において、Amazon RDS と Amazon Aurora が別個に存在するのと似ています。Google Cloud サービスとしての位置づけは、Amazon RDS が Cloud SQL、Amazon Aurora が AlloyDB にそれぞれ対応していると考えて良いでしょう。 なお名前に for PostgreSQL と冠してはいますが、他の DB エンジン版の AlloyDB の提供は今のところありません。 Cloud SQL についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp PostgreSQL との互換性 2026年1月現在では、PostgreSQL 14、15、16、17、18 との互換性を持った AlloyDB クラスタを構築できます。 参考 : Create a cluster and its primary instance - Create a new cluster and primary instance AlloyDB は PostgreSQL との「100% 互換」を謳っています。AlloyDB のデータベースへの接続には、psql コマンドラインなどの PostgreSQL 用クライアントを用いることができます。また AlloyDB は、PostgreSQL の各種パラメータや拡張機能（extension）に対応しています。 通常の PostgreSQL では postgresql.conf 等で設定する各種パラメータは、AlloyDB では データベースフラグ と呼ばれる設定値として管理され、Web コンソールや gcloud コマンドで管理します。 既存の PostgreSQL データベースから AlloyDB への移行を検討する際、パラメータや拡張機能が AlloyDB でも利用可能なのか、以下の公式ドキュメントで確認する必要があります。 参考 : Supported database flags 参考 : Supported database extensions 料金 AlloyDB は、利用した分だけ料金が発生する従量課金です。以下の軸で課金されます。 割り当てた CPU/Memory 利用したストレージ (バックアップ用含む) ネットワーク (他リージョンへの egress のみ) AlloyDB には「プライマリインスタンス」と「読み取りプールノード」が存在し、それぞれスペック（CPU、Memory）を指定できます。インスタンスが存在した時間に応じ、時間単位で課金が発生します。 またストレージはデータベースに必要な分のサイズが自動的に割り当てられ、自動でスケールアップ・ダウンします。利用したデータサイズ分だけの課金が発生します。 以下は、N2 または C4A マシンタイプにおける 2 vCPU / 16 GB のプライマリインスタンス + スタンバイインスタンスという構成で、ストレージ利用が 100 GB の場合の利用料金の試算です（2026年1月現在、東京リージョン）。 vCPU: $0.08458 * 2 vCPU * 730h * 2 VMs = $246.9736 /月 Memory: $0.01434 * 16 GB RAM * 730h * 2 VMs = $334.9824 /月 Storage: $0.000526 * 100 GB * 730h = $38.398 /月 → 計 $620.354 /月 上記に加えて、バックアップストレージにも課金が発生します。 最新の料金は、以下の公式ページをご参照ください。 参考 : AlloyDB for PostgreSQL pricing 無料トライアル AlloyDB では 無料トライアルクラスタ （free trial clusters）を作成可能です。 無料トライアルクラスタでは 8 vCPU と最大 1 TB のストレージを利用でき、30日間の試用が可能です。SLA は適用されず、バックアップも取得できませんが、有償版とほとんど同等の機能を使うことができます。 無料期間中の30日が経過した後は、データベースへのリクエストが受け付けられなくなり、そこから15日後にはデータも削除されます。無料クラスタは、有償クラスタにアップグレードすることが可能です。 無料トライアルクラスタの作成には、有効な請求先アカウントと紐づけられた Google Cloud プロジェクトが必要です。 参考 : AlloyDB 無料トライアル クラスタの概要 アーキテクチャ クラスタ AlloyDB for PostgreSQL の基本の管理単位は クラスタ です。クラスタの全体像は以下の図の通りです。 クラスタの全体像 参考 : AlloyDB の概要 プライマリインスタンス クラスタは プライマリインスタンス を持ちます。プライマリインスタンスはクラスタに1つだけですが「高可用性」設定にすると、フェイルオーバ用のレプリカ（スタンバイインスタンス）を持つことができます。 クライアントは読取・書込アクセスをこのプライマリインスタンスに向けて行います。そのための単一の IP アドレスが発行されます。IP アドレスはフェイルオーバしても変わりません。 プライマリインスタンスのスタンバイインスタンスが存在するクラスタを「高可用性（High available）クラスタ」と呼び、単一のプライマリインスタンスしか持たないクラスタを「基本（Basic）クラスタ」と呼びます。なおサービスリリース当初は高可用性クラスタのみでしたが、2023年9月21日のアップデートにより、基本クラスタが作成可能になりました。 参考 : AlloyDB の概要 - ノードとインスタンス 読み取りプールインスタンス 読み取りプールインスタンス （Read pool instance）は、読取専用アクセスを提供するノードの 集合体 です。つまり読み取りプールインスタンスという語は単一のノードを指すのではなく、読取専用ノードのグループを指します。 読み取りプールインスタンスには読取用の IP アドレスが発行され、その IP アドレスへのアクセスは読み取りプールインスタンスのいずれかのノードに割り振られます。ノードの数を増減することで、読取ワークロードを負荷分散することが可能です。 プライマリインスタンスは必須ですが、読み取りプールインスタンスの作成は任意です。作成すると利用料金が発生する代わりに、分析的な用途を含む読取ワークロードを分散させることができます。 参考 : AlloyDB の概要 - ノードとインスタンス また、AlloyDB の読み取りプールインスタンスには、オートスケーリングを設定できます。CPU 使用率またはスケジュールに基づいて、読み取りプールインスタンス内のノード数を自動的に増減できます。 参考 : Scale an instance - Autoscale a read pool instance ネットワーク AlloyDB のクラスタはユーザが管理する VPC（Virtual Private Cloud）ネットワークの中ではなく、Google Cloud が管理する VPC ネットワークの中に作成されます。 ユーザの VPC ではなく Google Cloud が管理するマネージドな VPC であるという点がポイントです。これは、 プライベートサービスアクセス という仕組みであり、クラスタが配置される Google Cloud 管理の VPC を サービスプロデューサーのネットワーク と呼びます。これは Cloud SQL や Cloud Memorystore などと同じ仕組みです。 サービスプロデューサーのネットワークとユーザの VPC ネットワークは、VPC ネットワークピアリングで接続することになります。 AlloyDB のネットワーク構成 参考 : プライベート IP の概要 参考 : プライベート サービス アクセスの概要 なお AlloyDB へは、プライベートサービスアクセスを使う接続方法の他に、パブリック IP アドレスを使用して接続する方法や、Private Service Connect を用いて接続する方法もあります。 参考 : パブリック IP を使用して接続する 参考 : Private Service Connect の概要 クロスリージョンレプリケーション AlloyDB ではオプションとして、 クロスリージョンレプリケーション を利用可能です。クロスリージョンレプリケーションを有効化すると、メインのクラスタ（プライマリクラスタ）とは別のリージョンにセカンダリクラスタが作成され、非同期でデータがレプリケーションされます。 セカンダリクラスタは読み取り専用のクラスタであり、手動でプライマリに昇格させることができます。 クロスリージョンレプリケーションは災害対策目的のほか、ユーザやアプリケーションに近いリージョンに読み取り専用のセカンダリクラスタを置くことで、読み取りレイテンシの改善にも用いることができます。 参考 : クロスリージョン レプリケーションの概要 可用性 スタンバイインスタンス 前述の通り、プライマリインスタンスは任意でフェイルオーバ用レプリカ（ スタンバイインスタンス ）を持つことができます。 アクティブ系のプライマリインスタンスに異常が検知されると、自動的にスタンバイインスタンスにフェイルオーバが発生します。 フェイルオーバしても、読取・書込用の IP アドレスは変わりませんので、アプリケーションからは一定時間のダウンタイムのあと、設定変更なしで再度コネクションを張ることができます。 またフェイルオーバをテストするため、手動でフェイルオーバを発生させることも可能です。 読み取りワークロードの可用性 読み取りプールインスタンスには複数のノードを含むことができます。 読み取り専用 IP アドレスが一つ払い出され、この単一の IP アドレスにアクセスすれば、いずれかのノードに割り振られます。読み取りプールインスタンスに複数のノードを作成することで、読取専用ワークロードの可用性を高めることが可能です。 可用性 SLA AlloyDB for PostgreSQL の可用性 SLA は 99.99% です。 所定の計算方法に従った月間稼働率がこれを下回った場合、Financial Credits が還元されます（要申請）。 なお SLA が適用されるには、クラスタが「 Multi-zone instance 」である必要があります。これは「プライマリインスタンスの高可用性設定が有効化されている」または「最低2ノードの読み取りプールインスタンスを持っている」状態を指します。 参考 : AlloyDB Service Level Agreement (SLA) 災害対策 (DR) 前述のクロスリージョン・レプリケーションを用いることで、リージョンをまたいだ災害対策（Disaster Recovery）を実現できます。 クロスリージョン・レプリケーションを有効化すると、別リージョンのセカンダリクラスタ（読み取り専用）にデータが非同期でレプリケーションされます。プライマリクラスタのリージョンがダウンした際には、セカンダリクラスタを読み書き用のプライマリクラスタに 昇格 させることができます。 参考 : クロスリージョン レプリケーションを使用する - セカンダリ クラスタをプロモートする スケーラビリティ AlloyDB のスケーラビリティの概念を整理すると、大まかに以下のようになります。 対象 垂直スケール 水平スケール プライマリインスタンス 可 (マシンタイプ変更) 不可 読み取りプールインスタンス 可 (マシンタイプ変更) 可 (ノード数変更) プライマリインスタンスは読み書きを司る単一のインスタンスのため、水平にスケールすることはできませんが、スペック変更による垂直スケールは可能です。 読み取りプールインスタンスは読み取り専用のノード集団ですので、ノード数を増やして水平にスケールすることも、スペックを上げて垂直にスケールすることも可能です。また、CPU 使用率やスケジュールに基づいたオートスケーリングも可能です。 参考 : Scale an instance 分析（OLAP） AlloyDB カラムナエンジンとは AlloyDB は業務用データベースとして OLTP （Online Transaction Processing）処理に向いたデータベースです。しかし AlloyDB カラムナエンジン を搭載しており、分析的処理（ OLAP 、Online Analytical Processing）も高速に行うことができます。 なおこのように OLTP と OLAP の両方のワークロードを処理できる特性を持つデータベースを、 HTAP （Hybrid Transaction Analytical Processing）データベースと呼ぶこともあります。 カラムナ とは「列指向」を意味しており BigQuery を始めとする多くの分析用データベースが列指向データベースです。AlloyDB ではカラムナエンジンにより、テーブルの特定データを列志向でメモリ上に保持することで、集計等の分析的なクエリを高速に処理できます。 カラムナエンジンはデータベースフラグ（AlloyDB の設定パラメータ）である google_columnar_engine.enabled を on にすることで有効化されます（インスタンス再起動が発生）。デフォルトだとインスタンスのメモリの30%が割り当てられますが、この値もデータベースフラグで設定可能です。 カラムナエンジンによりメモリ上に保持される領域はカラムストア（column store）と呼ばれます。カラムストアには特定の型のデータしか入りませんが、一般的な型はサポートされています。詳細は以下のドキュメントをご参照ください。 参考 : AlloyDB カラム型エンジンについて 自動カラムナ化 カラムナエンジンでは、 自動カラムナ化 （auto-columnarization）が利用可能です。 自動カラムナ化は、アプリケーションのワークロードを自動で分析して、割り当て容量も考慮しつつカラムストアに入れるべき列を決定します。 新規インスタンスでは自動カラムナ化はデフォルトで有効で、1 時間に一度、カラムストアの内容を更新・最適化します。 自動カラムナ化は無効化したり、頻度を変更したり、あるいは即時実行することが可能です。 参考 : 自動列化を使用して列ストア コンテンツを管理する 手動でのカラムストア管理 前述の自動カラムナ化のほか、手動でカラムストアを管理することもできます。 google_columnar_engine.relations フラグに DATABASE_NAME.SCHEMA_NAME.TABLE_NAME(COLUMN_LIST) の形式で定義することで、明示的にカラムストアに入れるべき列名を指定できます。 参考 : カラムストア コンテンツを手動で管理する BigQuery からの連携クエリ Google Cloud の高性能でスケーラブルなデータウェアハウスである BigQuery から、AlloyDB へ 連携クエリ （federated queries）を投入することが可能です。 連携クエリにより、BigQuery のユーザーインターフェイスから SQL を投入し、AlloyDB 上のテーブルデータを SELECT できます。この機能により、BigQuery に保持しているテーブルと AlloyDB 上のテーブルを結合（JOIN）することや、AlloyDB のデータを BigQuery に移動（Extract）すること等が可能になり、分析の利便性が向上します。 なお連携クエリでは、SQL が自動的に最適化され、AlloyDB 上の計算リソースも利用してフィルタしたうえで BigQuery にデータが転送される点に留意してください。この仕組みを SQL プッシュダウン （SQL pushdown）と呼びます。 参考 : AlloyDB 連携クエリ 参考 : 連携クエリの概要 バックアップ・リストア バックアップの種類 AlloyDB のバックアップは、 バックアップ という名称のクラウドリソースとして取得することができます。バックアップには以下の3種類があります。 なおバックアップの取得はストレージレイヤで完結するため、実行してもパフォーマンス影響は無いとされています。 名称 説明 継続バックアップ (Continuous backups) デフォルトは有効化。ポイントインタイムリカバリを可能にするバックアップ オンデマンドバックアップ (On-demand backups) 手動で採取されたバックアップ。Google Cloud コンソールや gcloud コマンド等で実行 自動バックアップ (Automated backups) 自動スケジュールで取られたバックアップ。デフォルトで有効 (日次・14日保持) 参考 : データのバックアップと復元の概要 継続バックアップとそのリストア 継続バックアップ （Continuous backup）はポイントインタイムリカバリ（point-in-time recovery、クラスタを任意の時点に巻き戻すリカバリのこと）を可能にするバックアップです。デフォルトで有効化されています。 継続バックアップが有効化されていると、1日に1回、データの変更に対する変更ログが増分でバックアップされるようになります。このバックアップを使い、既存クラスタを任意の時点まで巻き戻す（ポイントインタイムリカバリ）ことが可能です。マイクロセカンドの粒度で、最大で過去35日まで巻き戻すことができます。 継続バックアップは1〜35日間分のバックアップ取得するよう設定できます。デフォルトでは14日間の設定になっています。 オンデマンドバックアップ・自動バックアップとそのリストア オンデマンドバックアップ と 自動バックアップ は、クラスタのある時点のスナップショットを取得するバックアップです。これら2つの違いは取得契機が手動か自動か、の違いです。 最長1年の保存期間を設定可能で、期限が過ぎたバックアップは自動的に削除されます。 オンデマンドバックアップは毎回フルバックアップになるのに対して、自動バックアップは増分バックアップ（incremental backup）です。これは、データ保存料金に影響するため、料金試算に留意が必要です。 デフォルトでは、バックアップはクラスタと同じロケーション（リージョン）に保存されますが、オンデマンドバックアップは、別のロケーションを保存先として選択できます。これにより、災害対策やリージョンレベルの大規模障害に対処することができます。 オンデマンドバックアップまたは自動バックアップからのリストアは、 新しいクラスタとして 行われます。つまり、既存クラスタの中身がバックアップの時点に巻き戻るのではなく、バックアップを取った時点のデータを使って新規クラスタを作成することになります。なおこれは Compute Engine や Cloud SQL のバックアップ（スナップショット）と同様です。 接続 クライアント AlloyDB for PostgreSQL へは psql コマンドなど、通常の PostgreSQL のクライアントソフトウェアから接続することができます。 参考 : psql クライアントをインスタンスに接続する ネットワーク クライアントから、プライマリインスタンスもしくは読み取りプールインスタンスが提供する IP アドレスに接続します。 IP アドレスは、インターネットに公開されないプライベート IP アドレスが払い出されるほか、オプションでパブリック IP アドレスも有効化できます。パブリック IP アドレスを有効化する場合、承認された外部ネットワーク（Authorized external networks）を CIDR 形式で指定することで、接続を許可する接続元 IP アドレス範囲を限定できます。 基本的にはプライベート IP アドレスのみを使って利用することが望ましいですが、Clodu Run などのサーバーレスプラットフォームから、後述の AlloyDB Auth proxy を使ってアクセスさせる場合などにパブリック IP が利用できます。 VPC ファイアウォールで TCP ポート 5432 への Egress (外向き) 通信が許可されている限り、AlloyDB クラスタを作成したサービスプロデューサーネットワークと接続されている VPC 内の VM からは、AlloyDB クラスタに接続することができます。 参考 : 接続の概要 認証・認可 後述の AlloyDB Auth proxy を使わない限り、データベースユーザの考え方は PostgreSQL と同様です。 クラスタ作成直後は postgres ユーザでログインすることができます。ログイン用パスワードはクラスタ作成時に指定します。開発やアプリケーションからの接続のためには、管理特権を持たないユーザを新規作成することが推奨されます。 参考 : AlloyDB for PostgreSQL のデータベース ユーザー管理について AlloyDB Auth proxy AlloyDB Auth proxy とは AlloyDB Auth proxy は AlloyDB を利用するアプリケーション側のローカルにインストールする、プロキシソフトウェアです。AlloyDB Auth proxy の利用は必須ではありませんが、推奨されています。 AlloyDB Auth proxy 経由で AlloyDB に接続することで、AlloyDB に IAM 権限で認証・認可 (ログイン) することができます。またアプリケーションからデータベースへの通信が TLS（TLS 1.3, 256-bit AES cipher）で暗号化されます。 AlloyDB Auth Proxy の概要図 アプリケーションからは、ローカルで動作する AlloyDB Auth proxy クライアントソフトウェアに向けて TCP 5432 ポートで接続します（ 127.0.0.1:5432 もしくは localhost:5432 。複数の読み取りプールインスタンスなど、複数のインスタンスをターゲットするときポート番号が1ずつ増える）。すると AlloyDB Auth proxy クライアントは、AlloyDB に向けてコネクションを張ります。 アプリケーションが Compute Engine や Cloud Run など Google Cloud 環境で動作している場合、インスタンス等にアタッチされているサービスアカウントの権限（ roles/alloydb.client ロール）でデータベースにログインすることが可能です。 参考 : AlloyDB Auth Proxy について パブリック IP を使った接続 前掲の構成図では、AlloyDB Auth proxy から AlloyDB のプライベート IP アドレスへ接続していますが、パブリック IP アドレスを使って接続させることもできます。 Cloud Run などのサーバーレスプラットフォームから AlloyDB へ接続する際は、AlloyDB Auth proxy を利用してパブリック IP 経由でアクセスすることで、ネットワークのオーバーヘッドを抑えながらセキュアにアクセスさせることができます。 参考 : パブリック IP を使用して接続する 詳細は以下の記事も参照してください。 blog.g-gen.co.jp 通信要件 アプリケーションの動作環境からは以下の外向き（Egress）ネットワーク通信要件が存在します。 0.0.0.0/0 への 443/TCP（ alloydb.googleapis.com への接続のため） AlloyDB インスタンスの IP アドレスへの 5433/TCP Cloud Run における Auth proxy 利用 Cloud Run のサイドカーコンテナ機能を利用して AlloyDB Auth Proxy を使用する方法については、以下の記事もご参照ください。 blog.g-gen.co.jp マネージドコネクションプール マネージドコネクションプール （managed connection pooling）は、AlloyDB 側で管理されたコネクションプールを利用できる機能です。 有効化すると、データベースクライアントとのコネクションがプールの中から動的に割り当てられ、リソース使用量とレイテンシが最適化されます。これにより、突然のコネクション量のスパイクがあっても、既存のコネクションを再利用するなどにより対処できます。また、短時間のコネクションが頻発するようなケースでも有用です。 接続モードとして、トランザクションレベルまたはセッションレベルでのコネクション割り当てが選択できます。また最大、最小のプールサイズなど、複数の設定項目があります。 参考 : マネージド接続プーリングを構成する データのインポート・エクスポート インポート 以下のフォーマットのファイルを、AlloyDB にインポートすることができます。 CSV（1テーブル = 1ファイル。 psql コマンドライン使用） DMP（PostgreSQL のバイナリアーカイブファイル。 pg_restore 使用） SQL（ psql コマンドライン使用） インポートするには、ファイルを Cloud Storage に配置して、コマンドラインを実行します。 参考 : 移行の概要 - データのインポート エクスポート AlloyDB のデータは、以下のフォーマットでエクスポートできます。 CSV（1テーブル/1ファイル。 psql 使用） DMP（PostgreSQL のバイナリアーカイブファイル。 pg_dump 使用） SQL（ pg_dump 使用） コマンドライン等を用いて AlloyDB からローカルマシンへデータをエクスポートする方法が公式ドキュメントで紹介されています。 参考 : 移行の概要 - データのエクスポート 移行ツール Database Migration Service を利用することで、他のデータベースエンジンのデータベースから、AlloyDB にデータを移行することができます。Database Migration Service は、データベースのデータを移行するための Google Cloud サービスです。 詳細は以下のリンクから公式ドキュメントをご参照ください。 ソース（移行元） ドキュメントリンク 備考 PostgreSQL Database Migration Service for PostgreSQL to AlloyDB Amazon Aurora にも対応 Oracle Database Database Migration Service for Oracle to AlloyDB - AI 機能 自然言語によるクエリ AlloyDB AI natural language を使うと、生成 AI により、自然言語を使って AlloyDB のデータベースに対してクエリが実行できます。アプリケーションのエンドユーザーによる自然言語の質問に対して、AI が SQL を自動生成し、結果を返答するような仕組みを構築可能です。 有効化するには、 alloydb_ai_nl 拡張機能をインストールする必要があります。 参考 : AlloyDB AI 自然言語の概要 モデルエンドポイント管理 モデルエンドポイント管理 は、SQL 経由で外部の AI モデルを呼び出しできる機能です。 Vertex AI のエンベディングモデルを呼び出したり、マルチモーダルな生成 AI モデルを呼び出すことができます。 参考 : AlloyDB でのリモート AI モデルの登録と呼び出しの概要 AI 支援によるトラブルシューティング AlloyDB のトラブルシューティングの際、AI の支援を受けることができます。 利用には、Gemini Cloud Assist の有効化が必要です。 参考 : AI アシスタンスによるモニタリングとトラブルシューティング セキュリティ・監査 暗号化 AlloyDB のストレージのデータは、他の Google Cloud サービスと同様に、デフォルトで透過的に暗号化されています。つまり何もしなくても、AlloyDB のストレージのデータは暗号化で保護されており、ストレージ機器の盗難等には対処されています。このデフォルト暗号化の暗号鍵は、Google Cloud によって管理されています。 オプションで、Cloud KMS で管理する、顧客管理の鍵（Customer-managed Encryption Key = CMEK）を用いてストレージを暗号化することもできます。CMEK で暗号化することにより、鍵の管理（作成、廃止、ローテーション等）をコントロールすることができ、厳しい監査要件に耐えることができます。 参考 : CMEK について Cloud KMS についての詳細は、以下の記事も参照してください。 参考 : Cloud KMSを徹底解説 - G-gen Tech Blog 監査ログ クラスタ管理オペレーションの監査ログ AlloyDB は、 Cloud Audit Logs と統合されており、クラスタの管理系オペレーションの監査ログが出力されます。 クラスタの作成・削除、設定値の編集、バックアップの作成・削除などの更新系オペレーションは「管理アクティビティ監査ログ」と呼ばれ、デフォルトで記録される設定になっています。オフにはできません。 一方でクラスタ一覧の表示やクラスタ設定の取得などの参照系オペレーションは「データアクセス監査ログ」と呼ばれ、明示的に有効化する必要があります。 Cloud Audit Logs で採取されたログは、 Cloud Logging のログエクスプローラ等で閲覧することができます。 なおこれらはあくまでクラスタの管理系オペレーションに関する監査ログであり、データベースの中身の操作に対する監査ログは次に紹介する pgAudit で取得することになります。 参考 : AlloyDB for PostgreSQL の監査ロギング Cloud Audit Logs の詳細は、以下の記事も参照してください。 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - G-gen Tech Blog DB オペレーションの監査ログ PostgreSQL データベースの中身の操作に対する監査ログはオープンソースの拡張機能（extension）である pgAudit により提供されます。 pgAudit で採取される情報は SELECT INSERT UPDATE DELETE などの各種 SQL (DDL/DML/DCL) です。記録する対象のオペレーションはデータベースフラグで定義できます。 有効化するにはデータベースフラグ alloydb.enable_pgaudit を on にセットしたうえでデータベースに接続して CREATE EXTENSION で拡張機能を有効化します。 pgAudit により生成されたログは、 データアクセス監査ログとして Cloud Audit Logs 経由で Cloud Logging に送信 されます。よって、ログを閲覧するためにはデータアクセス監査ログを有効化する必要があります。有効化後、Cloud Logging のログエクスプローラ等でログを閲覧することができます。 参考 : pgAudit について 運用とモニタリング モニタリング AlloyDB は Cloud Monitoring と統合されており、何も設定しなくても、CPU 使用率やメモリ使用率、ストレージの使用量などをグラフで閲覧することができます。 Cloud Monitoring のコンソール画面から各種メトリクス（採取されたパフォーマンス情報）を閲覧できるほか、AlloyDB のコンソール画面からもプレフィクスされたダッシュボードを確認できます。 参考 : インスタンスをモニタリングする 参考 : Google Cloud 指標: A～B - alloydb Cloud Monitoring についての詳細は、以下の記事も参照してください。 参考 : Cloud Monitoringを徹底解説！ - G-gen Tech Blog インスタンスの停止・起動・再起動 AlloyDB クラスタのプライマリインスタンスや読み取りプールインスタンスは、 停止・起動・再起動 が可能です。 セカンダリインスタンスやリードプールインスタンスの個別ノードは、再起動のみが可能です。 停止したインスタンスに対しては、コンピューティング料金が発生しませんが、ストレージ料金は引き続き発生します。 インスタンスを停止すると、自動アップデートは行われなくなります。ただし、バックアップは行われます。 参考 : インスタンスを起動、停止、再起動する チューニング Query Insights Query Insights は AlloyDB に組み込まれたクエリ分析ツールです。実行されているクエリのパフォーマンス情報を分析し、チューニングに活かすことができます。 Google Cloud の Web コンソールから閲覧できるほか、Cloud Monitoring API を経由してプログラマブルに情報を取得できるので、既存の APM（Application Monitoring）ツール等に情報を連携することも可能です。 Query Insights ではクエリの user、database、IP address、time range、CPU capacity、CPU and CPU wait、IO Wait、Lock Wait といった情報を閲覧できます。情報は1週間前のものまでが保存されます。 参考 : Query Insights について なお、Query Insights 自体に料金は発生しません。Cloud Monitoring API 経由で情報を取得した場合は、API 呼び出し回数に応じた課金が発生します。 参考 : Google Cloud Observability pricing - Cloud Monitoring adaptive autovacuum AlloyDB には adaptive autovacuum （適応的オートバキューム）という機能があります。 PostgreSQL には VACUUM（バキューム）の概念があります。PostgreSQL ではデータを update したり delete しても、そのデータには削除フラグが付くだけで、実際にはまだ存在しています。この不要領域を回収して使えるようにするのが VACUUM です。また VACUUM コマンドにオプションに応じて統計情報の更新やトランザクション ID のラップアラウンド防止のための処理などがされています。 AlloyDB ではデフォルトで adaptive autovacuum が有効化されており、パフォーマンス影響を最小限に抑えながら VACUUM 処理が自動化されています。 enable_google_adaptive_autovacuum フラグにより、有効化/無効化を設定することができます。 参考 : 適応型自動バキュームを構成する インデックスアドバイザ インデックスアドバイザ （index advisor）は、AlloyDB で処理されるクエリを分析し、パフォーマンス改善のためのインデックスを推奨してくれる機能です。2023/05/08 に GA となりました。 google_db_advisor.enabled フラグを on にすることで有効化できます（再起動が発生）。有効化してから1日程度経過して以降、定期的に分析が実行されます。 アドバイザによる推奨事項は SELECT * FROM google_db_advisor_recommended_indexes; のように SQL で照会することができます。 詳細は以下のドキュメントをご参照ください。 参考 : インデックス アドバイザーを使用する Cloud SQL からの移行 Cloud SQL のバックアップを AlloyDB クラスタとして起動 することで、Cloud SQL から AlloyDB への移行を容易に実現できます。 Cloud SQL から採取したバックアップを、AlloyDB の標準クラスタまたは無料トライアルクラスタとして起動できます。 ただし、起動先は同一プロジェクト、同一リージョンである必要があります。また、CMEK 暗号化された Cloud SQL インスタンスや、IAM グループ認証が設定された Cloud SQL インスタンスのバックアップはサポートされていません。 参考 : Cloud SQL for PostgreSQL から AlloyDB for PostgreSQL に移行する AlloyDB Omni AlloyDB Omni は Linux サーバ上で動作する、AlloyDB for PostgreSQL のダウンロード版です。 カラムナエンジンや adaptive autovacuum、インデックスアドバイザなど、クラウド版 AlloyDB の持っている機能の一部を搭載しています。 Linux で動作するコンテナベースであり、ハイブリッドクラウド（オンプレミスとクラウドをミックスして利用するアーキテクチャ）や検証用途などのユースケースが想定されます。 詳細は以下のドキュメントをご参照ください。 参考 : AlloyDB Omni のドキュメント 参考 : AlloyDB Omni, the downloadable edition of AlloyDB, is now generally available 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 みずほリサーチ&テクノロジーズ株式会社の藤根です。 本日はKaggle初心者を対象に、データ分析サービスであるVertexAIのワークベンチ上にKaggle環境をサクッと構築する手順を解説します。 Vertex AI はじめに Kaggle環境構築の必要性 Kaggle Notebooks環境の制約 Google Colaboratory環境の制約 事前準備 VertexAI ワークベンチの起動 VertexAI ワークベンチの新規作成 VertexAI ワークベンチ新規作成画面の表示 機械学習プラットフォームの選択 詳細設定画面の表示 インスタンス名とリージョン/ゾーンの設定 環境（機械学習プラットフォーム）の確認 マシンタイプの選択 ディスクとバックアップの設定 ネットワークの設定 IAMとセキュリティの設定 システムの状態とReportingの設定 VertexAI ワークベンチの確認 インスタンスの起動確認 Pythonと各パッケージのバージョン確認 Kaggle APIの認証設定 LightGBMによるタイタニックコンペの学習・予測 データの準備 パッケージのインポート 学習データの読み込み 学習データの分割 学習開始 スコアの確認 特徴量の寄与率の確認 Tree構造の可視化 テストデータ（未学習のデータ）によるモデルの検証 予測精度の向上に関する考察 事後作業 さいごに はじめに 本ブログではVertexAIのワークベンチ上にKaggle環境を構築する手順を解説します。 この記事を読むことで、 Kaggleのカーネルと同じ環境をVertex AIで構築する Kaggle APIを使って、学習データのダウンロードや予測結果を提出する LightGBMを使ってタイタニックコンペに挑戦してみる ことが出来るようになることを目指します。Kagglerを目指す方々が最初に躓きやすい「環境構築」を楽にするきっかけになれば幸いです。 ※本記事では環境構築をテーマとするため、AIの理論や各パッケージの解説は割愛いたします。 Kaggle環境構築の必要性 Kaggle Notebooks環境の制約 一般的に、AI・データ分析を行うためには大量のCPU/GPUやメモリなどのコンピューティングリソースを必要とします。幸い、KaggleではPython/Rのプログラムを無料で実行できる Kaggle Notebooks サービスを提供しており、インターネットに接続可能なPCさえあれば、GPU/TPUアクセラレーターの無料使用や、コンペデータのダウンロードや予測結果の提出までを誰でもワンストップで実行できる環境が整っています。 「じゃあNotebooksで十分では？」と思いたくなりますが、 Notebooksの技術仕様 には以下制約が記載されており、長時間の学習やマシンリソースの拡張には適していません。 Notebookの連続稼働時間は、CPU/GPUマシンで最大12時間、TPUマシンで最大9時間まで GPU/TPUアクセラレーターの利用可能時間は、それぞれ30時間/1週間まで 1時間以上アクティブな画面操作がないと、セッションタイムアウトが発生（学習途中のモデルの重みや変数は、外部ストレージに都度保存しない限り削除される） CPU/GPU/TPU毎のマシンスペックは固定であり、拡張できない また、近年は Code Competitions という、予測結果ファイルではなく予測プログラムを提出するコンペ形式が増えてきました。このため、Notebooks以外でコンペ用の学習環境を別途準備する場合、Pythonと使用パッケージのバーションを一致させる必要性があります。 Google Colaboratory環境の制約 Notebooks以外で無料で使えるAI学習環境としては、 Google Colaboratory も有名です。しかし、 無料版ではハイスペックなGPUリソースをほとんど利用できない 使用するパッケージのバージョンをKaggle Notebooksに合わせる作業が必要 データセットや学習モデルが巨大な場合、Google Driveの無料ストレージ枠に収まらないことがある 等の理由から、安定した学習環境を得るにはPro/Pro+へのアップグレードが前提と思われます。 本記事では、そんな環境構築のいくつかの選択肢の一つとして、VertexAIによる構築を試したものになります。 事前準備 Google Cloudのアカウントをご用意下さい。本記事では小規模のインスタンスタイプを使用するため、少額の費用が発生します。 続いて、 Kaggleにサインイン してアカウントを取得後、 Kaggle API Documentation を参考にAPIトークン（ kaggle.json ファイル）をダウンロードします。1度発行されたファイルやトークン値は再発行されないため、無くさないようにご注意下さい。 VertexAI ワークベンチの起動 VertexAI ワークベンチの新規作成 VertexAI ワークベンチ新規作成画面の表示 ワークベンチのインスタンスを新規作成します。gcloudにも VertexAI用のCLIコマンドがある のですが、以降で使用するKaggle用コンテナが起動できなかったため、マネージドコンソール画面での操作手順を解説します。 サイドバーから「VertexAI」⇒「ワークベンチ」を選択します。API承認画面が出たら有効化します。 機械学習プラットフォームの選択 「ユーザー管理のノートブック」から「新しいノートブック」をクリックし、「Kaggle Python[BETA]」を選択します。 詳細設定画面の表示 ポップアップ左下の「詳細オプション」を選択します。 インスタンス名とリージョン/ゾーンの設定 インスタンス名とリージョン/ゾーンを入力します。もしGPU使用する場合は、GPUリソースを使用可能なリージョンとゾーンを GPUのリージョンとゾーンの可用性 から確認して下さい。今回はCPUで実行します。 環境（機械学習プラットフォーム）の確認 環境が「Kaggle Python[BETA]」となっていることを確認します。 マシンタイプの選択 マシンタイプを選択します。今回はデータサイズが小規模なため「n1-standard-1」とします。マシンタイプはインスタンス生成後でも変更可能です。セキュアブートにもチェックを入れます。 ディスクとバックアップの設定 ディスクのサイズやバックアップ有無などを設定します。 デフォルトのディスクタイプ(Standard)は安価ですが低速なHDDのため、DataディスクタイプだけでもSSD（もしくはより上位）に変更した方がディスクI/Oが改善されます。ストレージタイプ毎の性能は ストレージオプション をご参照下さい。 コンペデータが100GB以上の場合は、ディスクサイズも増やしましょう。 また、「ゴミ箱に移動しますか？」にチェックを入れます。これにより、インスタンス削除と連動してディスクも削除されるため、不要ディスク残存によるコスト発生を防ぎます。 ネットワークの設定 ネットワークを設定します。 IAMとセキュリティの設定 IAMとセキュリティを設定します。セキュリティの「Root access to the instance」にもチェックを入れます。 システムの状態とReportingの設定 システムの状態を設定します。想定外の環境差異発生を防ぐため、「環境の自動アップグレード」はチェックを外したままにします。Reportingの設定は任意です。 最後に作成ボタンをクリックします。 VertexAI ワークベンチの確認 インスタンスの起動確認 インスタンスが作成・起動されるまで、数分待ちます。グリーンのチェックマークが出たら完了です。 「JUPYTERLABを開く」リンクをクリックします。しばらくして、Jupyter Labの以下画面が表示されたら成功です。 Pythonと各パッケージのバージョン確認 ターミナルを起動し、Pythonと各パッケージのバージョンを確認します。 $python -V Python 3 . 7 . 12 $ pip freeze | grep -E " ^(kaggle|lightgbm|pandas|scikit-learn)== " kaggle = = 1 . 5 . 13 lightgbm = = 3 . 3 . 2 pandas = = 1 . 3 . 5 scikit-learn == 1 . 0 . 2 同日にKaggle Notebooksで同じコマンドを実行した結果は以下となります。Pythonと各パッケージのバージョンが完全一致していることが確認できます。 Kaggle APIの認証設定 続いて、ワークベンチでKaggle APIを使用できるようにします。 事前準備で取得した kaggle.json ファイルをワークベンチにアップロード後、以下コマンドでjsonファイルをコピーし、アクセス権限を変更します。 $ cp kaggle.json /root/.kaggle/ $ chmod 600 /root/.kaggle/kaggle.json kaggle コマンドを稼働確認します。以下のようにバージョン情報が出力されれば成功です。 $ kaggle --version Kaggle API 1 . 5 . 13 もし、 OSError: Could not find kaggle.json. Make sure it's located in /root/.kaggle. Or use the environment method. というメッセージが出た場合は、jsonファイルの名前か配置ディレクトリが間違っている可能性がありますので、ご確認下さい。 LightGBMによるタイタニックコンペの学習・予測 データの準備 いよいよ、 タイタニックコンペ の学習・予測を行います。このコンペでは、タイタニック号の乗客情報から、乗客が生存したかどうかを予測する2値分類タスクです。データサイズが小さく、Kaggle初心者向けのコンペです。 始めに、タイタニックコンペのデータセットをダウンロード&解凍します。 ls コマンドで3つのCSVファイルが出力されれば成功です。 $ kaggle competitions download -c titanic $ unzip titanic.zip $ ls *.csv gender_submission.csv test .csv train.csv パッケージのインポート 以降では、notebookを起動してPythonプログラムを実装していきます。まずは使用するパッケージをインポートします。 import numpy as np import pandas as pd import lightgbm as lgb from sklearn.model_selection import train_test_split 学習データの読み込み カラム毎のデータ型を定義し、学習データを読み込みます。 features_dtype = { 'PassengerId' : int , 'Pclass' : 'category' , 'Sex' : 'category' , 'Age' : np.float16, 'SibSp' : np.uint8, 'Parch' : np.uint8, 'Fare' : np.float32, 'Cabin' : 'category' , 'Embarked' : 'category' } target_dtype = { 'Survived' : bool } train_dtype = {**features_dtype, **target_dtype} train = pd.read_csv( 'train.csv' , index_col= 'PassengerId' , usecols= list (train_dtype), dtype=train_dtype) label = train.pop( 'Survived' ) train.info() <class 'pandas.core.frame.DataFrame'> Int64Index: 891 entries, 1 to 891 Data columns (total 8 columns): # Column Non-Null Count Dtype --- ------ -------------- ----- 0 Pclass 891 non-null category 1 Sex 891 non-null category 2 Age 714 non-null float16 3 SibSp 891 non-null uint8 4 Parch 891 non-null uint8 5 Fare 891 non-null float32 6 Cabin 204 non-null category 7 Embarked 889 non-null category dtypes: category(4), float16(1), float32(1), uint8(2) memory usage: 23.9 KB 学習データの分割 学習データを、学習用と検証用データに8:2で分割します。 splits = train_test_split(train, label, random_state= 0 , test_size= 0.2 , stratify=label) X_train, X_valid, y_train, y_valid = splits len (X_train), len (X_valid) (712, 179) 学習開始 LightGBMの学習パラメータを設定し、学習を開始します。 cls = lgb.LGBMClassifier(objective= 'binary' , learning_rate= 0.5 , class_weight=label.value_counts().to_dict()) cls.fit(X_train, y_train, eval_set=[(X_valid, y_valid)], callbacks=[lgb.early_stopping( 20 )]) Training until validation scores don't improve for 20 rounds Early stopping, best iteration is: [5] valid_0's binary_logloss: 0.469881 LGBMClassifier(class_weight={False: 549, True: 342}, learning_rate=0.5, objective='binary') スコアの確認 スコアを確認しましょう。上記パラメータでは、学習データで0.869、検証データで0.832となりました。 cls.score(X_train, y_train), cls.score(X_valid, y_valid) (0.8693820224719101, 0.8324022346368715) 特徴量の寄与率の確認 どの特徴量が予測に重要なのか、寄与率をグラフ化します。 Fare (乗船料金)と Age (年齢)が同率で重要なことが分かります。 lgb.plot_importance(cls, height= 0.5 ) Tree構造の可視化 LightGBMは決定木を用いた手法のため、データの値からどのように予測しているかを分岐グラフで可視化することができます。 graph = lgb.create_tree_digraph(cls, orientation= 'vertical' , filename= 'graph' , format = 'svg' ) graph.render() graph テストデータ（未学習のデータ）によるモデルの検証 最後に、テストデータから予測結果を生成し、 submission.csv ファイルに出力します。 predict = pd.read_csv( 'gender_submission.csv' , index_col= 'PassengerId' ) test = pd.read_csv( 'test.csv' , index_col= 'PassengerId' , usecols= list (features_dtype), dtype=features_dtype) predict[ 'Survived' ] = cls.predict(test).astype(np.uint8) predict.to_csv( 'submission.csv' ) ターミナルを起動し、以下コマンドで予測結果を提出します。 $ kaggle competitions submit -f submission.csv -m " first submission " titanic 100 %|███████████████████████████████████████████████| 2 .77k/ 2 .77k [ 00:01 < 00:00, 1 .46kB/s ] Successfully submitted to Titanic - Machine Learning from Disaster 1分ほど待ち、以下コマンドで予測結果のスコアを確認します。今回のスコアは0.784となりました。 $ kaggle competitions submissions titanic fileName date description status publicScore privateScore -------------- ------------------- ---------------- -------- ----------- ------------ submission.csv 2023-04-10 02:40:58 first submission complete 0 . 78468 予測精度の向上に関する考察 ここまではシンプルな実装に留めましたが、更に より高度な特徴量の生成 交差検証(cross validation) LightGBMのパラメータチューニング 深層学習の適用 などを行うことで、予測精度を向上できると思われます。 事後作業 最後に、ワークベンチの管理画面に戻り、インスタンスを削除して下さい。 さいごに 本日は、「VertexAIのワークベンチ上にKaggle環境をサクッと構築する手順」を解説させていただきました。 今回はワークベンチのみを使用しましたが、他にも Cloud Source Repositories : notebookや予測結果をバージョン管理 Vertex AI Dataset : データセットを保管・可視化 Vertex AI Feature Store : 生成した特徴量を保存・再利用 などのサービスを組み合わせることで、より充実したKaggle環境になると思われます。 藤根 成暢 みずほリサーチ&テクノロジーズ 先端技術研究部に所属。Pythonによるデータ分析やAI開発、Google Cloudの技術検証などを担当。保有資格はACE、PDE。

G-genの佐伯です。当記事では Vertex AI の AutoML 及びバッチ予測の基本的な操作方法や、簡易で安価に予測データを収集する手法を解説します。後編では Vertex AI AutoML で作成した機械学習モデルをローカルの docker で動作させ、安価に予測値を取得する方法をご紹介します。 はじめに 検証内容 当記事で活用するモデル Vertex AI Model Registry からモデルをエクスポート ローカル Docker コンテナで推論を実行 トレーニングデータを大幅に増やし推論を実行 まとめ はじめに 検証内容 Vertex AI AutoML 表形式のモデルはエクスポートしてローカル環境で動作させることができます。 当記事では以下のドキュメントを参考にして、検証してみます。 参考 : AutoML 表形式のモデルをエクスポートする 当記事で活用するモデル 当記事では、以下の記事で使用した米国の国勢調査局のデータベースから抽出した、ある個人に関する様々な情報（年齢、職業、結婚歴など）と「年収（income）が$50,000よりも高いか、$50,000以下か」が記録されたデータセットから作成されたモデルを活用します。 blog.g-gen.co.jp Vertex AI Model Registry からモデルをエクスポート Vertex AI の Model Registry から、Cloud Storage にモデルをエクスポートします。 今回は saikio-vertexai-test という名前の Cloud Storage バケットを使用します。 モデルのエクスポート① モデルのエクスポート② Cloud Storage へのエクスポートが完了したら、ローカル環境から以下のコマンドを実行し、モデルを Cloud Storage からローカルの Linux 環境にコピーします。 $ gsutil cp -r gs://vertex_ai_test2 . コピーした Cloud Storage バケット名のディレクトリに移動します。 以降、ローカル環境で実行するコマンドは、ここから実行します。 cd vertex_ai_test2 $ ls model-8435048588018450432 ローカル Docker コンテナで推論を実行 エクスポートしたモデルをローカルの Docker 環境にデプロイし、予測リクエストを処理してみます。基本的には ドキュメント に記載されている手順を参考にします。 モデルは以下のようなディレクトリの配下にコピーされています。 ./model-<model-id>/tf-saved-model/<export-timestamp> Docker ではタイムスタンプが含まれるディレクトリが無効にされてしまうので、ディレクトリ名を変更し、model というディレクトリ名に変更しました。以上のことから、今回モデルが存在するディレクトリは ~/vertex_ai_test2/model-8435048588018450432/tf-saved-model/model としています。 次に、Google Cloud が提供する、 Vertex AI のモデルを実行するためのモデルサーバーのコンテナイメージを使用して、モデルをデプロイします。 先述のドキュメント通りにコマンドを実行した場合、 asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server-v1 からモデルサーバーの Docker イメージを pull しますが、このイメージを使用してデプロイした場合、予測リクエストに対してエラーが返り、リクエストを正常に処理することができませんでした。 そこで、この Issue を参考に asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server:20230123_0325_RC00 のイメージを pull し、コンテナを実行します。 ここでは、コンテナに serene_cerf という名前をつけています。 $ docker run -dit --name serene_cerf \ -v `pwd`/model-8435048588018450432/tf-saved-model/model:/models/default \ -p 8080:8080 \ asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server:20230123_0325_RC00 docker稼働状況 以下のコマンドを実行して、1つだけのテストデータを作成します。 cd ~/vertex_ai_test2; sudo vim request.json 作成したデータをvertex_ai_test2フォルダ内に配置します。 vertex_ai_test2フォルダ内で以下のコマンドを実行し、予測値を確認します。ローカルで動作する Docker コンテナに対して推論を実行させています。 curl -X POST --data @request.json http://localhost:8080/predict {"predictions": [{"scores": [0.0018795928917825222, 0.9981204271316528], "classes": ["<=50K", ">50K"]}]} 無事、予測値が算出され 99.8%以上の確率で、年収50K以上であること が確認できました。 トレーニングデータを大幅に増やし推論を実行 上記では、データが1つのみでしたがこれを更に300行と増加させて、予測させてみます。 前編 のトレーニングデータで使用した『pred_data.csv』を用意します。 pred_data.csv(テストデータ) 以下のpythonプログラム(AutoML_pred.py)にて、pred_data.csvを読み込ませ、予測値を算出してみます。 AutoML_pred.pyとpred_data.csvは同じ階層で実行。 import os import csv import subprocess, json import sys, traceback from loguru import logger # out_put for log logger.add( "./AutoML_pred_log/my_error.log" , rotation= "100MB" , retention= "1 year" ) # key_columns data_key = [ 'age' , 'workclass' , 'fnlwgt' , 'education' , 'education.num' , 'marital.status' , 'occupation' , 'relationship' , 'race' , 'sex' , 'capital.gain' , 'capital.loss' , 'hours.per.week' , 'native.country' ] #データから予測値を出力し、得られたデータをcsv形式で出力 def Data_Predict (): # predict data(data for csv_type) MyPath = 'pred_data.csv' # read pred_data.csv with open (MyPath, "r" , encoding= "utf-8" ) as f: reader = csv.reader(f) rows = [ dict ( zip (data_key, row)) for row in reader] try : # delete 1 row del rows[ 0 ] # all predictionaled data on making model out_put = list () for i in range ( len (rows)): # setting data for curl command curl_data = { "instances" : [rows[i]]} # curl command for request cmd = "cd ~/vertex_ai_test2;curl -H {} -X POST --data '{}' http://localhost:8080/predict" .format( '"content-type: application/json"' , json.dumps(curl_data)) # shell=True,setting string from standard output result = subprocess.run(cmd, shell= True , capture_output= True , text= True ).stdout my_data = json.loads(result) # dictionary data set mm = dict () # key of [income_<=50K_value] key1 = 'income_{}_value' .format(my_data[ "predictions" ][ 0 ][ "classes" ][ 0 ]) # value of [income_<=50K_value] val1 = my_data[ "predictions" ][ 0 ][ "scores" ][ 0 ] # key of [income_>50K_value] key2 = 'income_{}_value' .format(my_data[ "predictions" ][ 0 ][ "classes" ][ 1 ]) # value of [income_>50K_value] val2 = my_data[ "predictions" ][ 0 ][ "scores" ][ 1 ] mm[key1] = val1 mm[key2] = val2 # 予測値を蓄積 out_put.append(mm) except Exception as e: logger.warning( "exceptions2 : {} : {}" .format(e, traceback.format_exc())) # csv出力 with open ( 'out_put.csv' , 'w' , encoding= 'utf-8' , newline= "" ) as f: writer = csv.DictWriter(f, fieldnames=[key1,key2]) writer.writeheader() writer.writerows(out_put) if __name__ == '__main__' : Data_Predict() プログラム簡易説明: pred_data.csv(テストデータ)を一行ずつ読み込ませ、ローカルのDockerコンテナ内のモデルにcurlコマンドにてリクエストし、その結果をcsvに記載していく。 (黄色の列が)予測値算出結果 上記のプログラムを活用することで、より多くの予測値を算出することができました。 まとめ 今回は、ローカルの Docker コンテナで機械学習モデルを動作させ、非常に安価に予測値を算出する方法をご紹介しました。 Google Cloud の Cloud Run や Vertex AI であれば、データ量が多くなればその分課金が発生しますが、今回の場合手軽にそして安価にモデルの予測値を取得できます。 佐伯　修 (記事一覧) クラウドソリューション部 前職では不動産業でバックエンドを経験し、2022年12月G-genにジョイン。 入社後、Google Cloudを触り始め、日々スキル向上を図る。 SEの傍ら、農業にも従事。水耕を主にとする。

「クラウドリフト」は自社で所有するシステムやデータなどをクラウドに移行することを指します。リフト＆シフトという言葉も一般的になる中、この記事ではその前半であるクラウドリフトにフォーカスします。クラウドリフトの基礎知識やメリット、注目される背景や方法論を紹介しますので、クラウド化推進のヒントにしてください。 クラウドリフトとは？ クラウドリフトが推進される理由 クラウドリフトの手順 クラウドリフトの注意点 1. 一時的な対応にとどまる 2. 保守や運用の業務は引き続き存在 3. 移行ができないケースもある まとめ クラウドリフトとは？ クラウドリフトとは、自社所有 (オンプレミス) の情報システムを、最小限の構成変更でクラウド (IaaS) へ移行することを意味します。 クラウド移行の方法論が語られる際に「リフト＆シフト (Lift & Shift)」という言葉が使われることがあります。これは、まずは最小限の構成変更でシステムをまずクラウドへ移行 (=リフト、雲の上へシステムをそのまま持ち上げるイメージ) してから、その後にクラウドに適したアーキテクチャにブラッシュアップしていく (=シフト、横滑りしてクラウドに最適化していくイメージ) という、段階を踏んでシステムをクラウド化していく方法論です。 クラウドリフトはリフト＆シフトにおける前半の段階を指しており、企業 IT のクラウド化の第一歩です。 クラウドリフトが推進される理由 経済産業省の「DXレポート」では、DX化が進まない日本の状況が2025年ごろには経済的損失といった深刻な形で顕在化するとの予想があり、これは2025年の崖問題と呼ばれています。 また近年では、歴史あるシステムの多くがサポート終了を予定しており、この点からも、多くの企業がクラウド化に乗り出しています。 参考： DXレポート｜経済産業省 また総務省がまとめた「令和2年版 情報通信白書」によると、企業がクラウドを利用している理由として最も多いのは「資産、保守体制を社内に持つ必要がないから（45.9％）」です。 次いで、「場所、機器を選ばずに利用できるから（43.3％）」、「安定運用、可用性が高くなるから（36.8％）」といった理由が並んでいます。 ※参考： 令和2年版 情報通信白書｜総務省 クラウドリフトの手順 クラウドリフトでは、オンプレミスの情報システム資産を IaaS へ移行します。移行の手順などは、以下の記事でも紹介していますのでご参照ください。 blog.g-gen.co.jp クラウドリフトの注意点 1. 一時的な対応にとどまる クラウドリフトでは、自社で所有していたシステムなどを、構成や内容の変更なしにクラウド上に移行させます。このため、これまで利用していたシステムやアプリケーションなどのサポートが終了しまうリスクは残ります。 クラウドリフトはあくまで、業務をクラウド化するための一時的な対応であると考えるべきでしょう。 2. 保守や運用の業務は引き続き存在 クラウドリフト前にはどのような保守・運用業務が必要になるのか可視化することが必要不可欠です。 クラウドリフトでは IaaS を利用します。物理機器の保守・運用は無くなる一方で、引き続き仮想サーバやミドルウェア、アプリケーションの保守・運用はユーザ側で行う必要があります。 3. 移行ができないケースもある 業種やシステム、製品によっては、クラウド移行が適さないケースも存在します。また、クラウド移行自体はできても、移行に大きなコストがかかったり、移行後の運用が非常に難しくなったりするケースも懸念点です。無理にクラウドに移行しないことや場合によってはシステム自体を廃棄する、といった選択肢も柔軟に検討しましょう。 特にソフトウェアのライセンスは、クラウド (IaaS) 上での利用に制限がある場合があります。代表として Microsoft や Oracle のライセンスがあります。必ずメーカや代理店に確認しましょう。 まとめ DX化における最初のステップとして、クラウドリフトを効果的に活用しましょう。クラウド移行の際は、G-genが運用代行・伴走をお手伝いします。新規・既存どちらのGoogle Cloud環境についても、お客様の環境に合ったハイブリッドクラウド・マルチクラウドを実現しました。豊富な実績にもとづく技術サポートを安価な利用環境とセットで提供いたします。 お問い合わせはこちら G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。

G-gen の藤岡です。当記事では、Terraform と Ansible を組み合わせて、Google Cloud（旧称 GCP）のネットワークリソースの作成をします。 サービスの概要 Terraform とは Ansible とは Terraform と Ansible の違い 検証の背景 前提 構成 インスタンス情報 ディレクトリ構成 Playbook の解説 Terraform のインストール Ansible のインストール ADC の設定と Terraform の初期化 構文チェック リソースの作成 リソースの削除 サービスの概要 Terraform とは Terraform は、 Infrastructure as Code (IaC) を実現するオープンソースのツールです。使用方法については以下の記事をご参照ください。 blog.g-gen.co.jp Ansible とは Ansible は、Red Hat 社が開発するオープンソースの構成管理ツールです。サーバーの設定やソフトウェアのデプロイ、パッケージのインストール等のタスクを自動化できます。またサーバーだけでなく、Cisco や Juniper といったネットワーク機器の管理にも使うことができます。 代表的な構成管理ツールには、Ansible の他に Puppet や Chef がありますが、Ansible は管理対象の機器へエージェントのインストールが不要です。例えば管理対象機器が Linux の場合、Ansible サーバーから SSH できる環境であれば実行可能です。 Ansible では、ソフトウェアのインストールや設定といった特定のアクションを タスク といい、YAML 形式で記述します。タスクが書かれたファイルを Playbook と呼びます。 後述する ansible-playbook コマンドで Playbook を実行することで、記載されたタスクが処理されていきます。 Terraform と Ansible の違い Terraform と Ansible は共に構成管理ツールですが、得意とする領域が異なります。 Terraform はインフラ層の構成管理を得意とするのに対し、Ansible は OS やミドルウェア層の構成管理を得意とします。 Red Hat 社が両者の違いに関する ドキュメント を公開していますので、そちらもご参照ください。 検証の背景 当記事で作成するリソースはネットワークリソースのため、本来であれば Terraform のみで完結します。 しかし、今後 Ansible でソフトウェアの設定ファイル管理についても検証したいため、その前段としてネットワークリソースのみを Terraform と Ansible を組み合わせて作成してみました。 前提 構成 構成は以下の通りです。構成図内の ansible-server の作成は当記事では触れません。今回は VPC リソースのみを作成しますが、Ansible の ダイナミックインベントリ を機能を使うことで、Terraform で作成したインスタンスの OS レイヤ以上のソフトウェアの設定等の管理をすることもできます。ダイナミックインベントリを Google Cloud 環境で使うには、 google.cloud.gcp_compute inventory のプラグインが必要です。 構成図 インスタンス情報 GCE インスタンス（ ansible-server ）の OS 情報は以下の通りです。 fujioka@ansible-server:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy fujioka@ansible-server:~$ ディレクトリ構成 ディレクトリ構成は以下の通りです。 fujioka@ansible-server:~$ tree . └── ansible-playbook ├── apply.yml ├── destroy.yml └── terraform └── main.tf 2 directories, 3 files fujioka@ansible-server:~$ 各ファイルの中身は以下の通りです。 apply.yml：Ansible リソース作成用 Playbook - hosts: localhost tasks: - name: create and update resources by terraform community.general.terraform: project_path: 'terraform/' state: present destroy.yml：Ansible リソース破棄用 Playbook - hosts: localhost connection: local gather_facts: no tasks: - name: destroy resources by terraform terraform: project_path: 'terraform/' state: absent main.tf：Terraform ファイル（ ${PROJECT_ID} は自身のプロジェクト ID に置き換えます） # difine provider provider "google" { project = "${PROJECT_ID}" region = "asia-northeast1" zone = "asia-northeast1-a" } terraform { required_version = "~> 1.2" required_providers { google = ">= 4.32.0" } } # create vpc resource "google_compute_network" "vpc" { name = "vpc" auto_create_subnetworks = "false" routing_mode = "GLOBAL" } # create subnet resource "google_compute_subnetwork" "subnet" { name = "subnet" ip_cidr_range = "10.0.10.0/24" network = google_compute_network.vpc.name } Playbook の解説 当記事では apply.yml と destroy.yml の 2 つの Playbook を使用します。ここでは以下の Ansible リソース作成用 Playbook である apply.yml について簡単に解説します。 # Ansible リソース作成用 Playbook - hosts: localhost tasks: - name: create and update resources by terraform community.general.terraform: project_path: 'terraform/' state: present hosts 対象のホスト Ansible サーバー自身の terraform/ 配下にあるファイルを実行するため localhost としています。 tasks hosts に記載のホストが実行する処理 name タスクの名前 ansible-playbook apply.yml で Playbook を実行すると TASK [create and update resources by terraform] のようにタスク名が表示されます。 community.general.terraform モジュール名 Ansible で Terraform を実行するための モジュール です。 project_path Terraform ディレクトリのルートのパス state ターゲットの状態を定義 present は Terraform で定義されたリソースを作成します。 absent の場合はリソースを削除します。 community.general.terraform モジュールでは デフォルト は present です。 参考： Playbook の概要 Terraform のインストール ドキュメント に従い、Terraform をインストールします。 $ sudo apt-get update && sudo apt-get install -y gnupg software-properties-common $ wget -O- https://apt.releases.hashicorp.com/gpg | \ gpg --dearmor | \ sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg $ gpg --no-default-keyring \ --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \ --fingerprint $ echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \ https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \ sudo tee /etc/apt/sources.list.d/hashicorp.list $ sudo apt update $ sudo apt-get install terraform インストール後のバージョンは以下の通りです。 fujioka@ansible-server:~$ terraform --version Terraform v1.4.4 on linux_amd64 fujioka@ansible-server:~$ Ansible のインストール ドキュメント に従い、Ansible をインストールします。 $ sudo apt update $ sudo apt install software-properties-common $ sudo add-apt-repository --yes --update ppa:ansible/ansible $ sudo apt install ansible インストール後のバージョンは以下の通りです。 fujioka@ansible-server:~$ ansible --version ansible [core 2.14.4] config file = /etc/ansible/ansible.cfg configured module search path = ['/home/fujioka/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python3/dist-packages/ansible ansible collection location = /home/fujioka/.ansible/collections:/usr/share/ansible/collections executable location = /usr/bin/ansible python version = 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] (/usr/bin/python3) jinja version = 3.0.3 libyaml = True fujioka@ansible-server:~$ ADC の設定と Terraform の初期化 Google Cloud 環境に対して Terraform が実行できるよう、アプリケーションのデフォルト認証情報（ADC）を設定します。 fujioka@ansible-server:~/ansible-playbook$ gcloud auth application-default login You are running on a Google Compute Engine virtual machine. The service credentials associated with this virtual machine will automatically be used by Application Default Credentials, so it is not necessary to use this command. If you decide to proceed anyway, your user credentials may be visible to others with access to this virtual machine. Are you sure you want to authenticate with your personal account? Do you want to continue (Y/n)? Go to the following link in your browser: ~ Credentials saved to file: [/home/fujioka/.config/gcloud/application_default_credentials.json] These credentials will be used by any library that requests Application Default Credentials (ADC). ~ fujioka@ansible-server:~/ansible-playbook$ 参考： アプリケーションのデフォルト認証情報を設定する / Terraform を使用して環境を作成する ~/ansible-playbook/terraform に移動をし、Terraform の初期化をします。 fujioka@ansible-server:~/ansible-playbook/terraform$ terraform init Initializing the backend... ~ Terraform has been successfully initialized! ~ fujioka@ansible-server:~/ansible-playbook/terraform$ 構文チェック ansible-playbook コマンドに --syntax-check をつけることで Playbook の構文チェックができます。 ~/ansible-playbook に移動をし、実行します。 fujioka@ansible-server:~/ansible-playbook$ ansible-playbook apply.yml --syntax-check [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' playbook: apply.yml fujioka@ansible-server:~/ansible-playbook$ リソースの作成 ansible-playbook apply.yml コマンドで Playbook を実行します。 fujioka@ansible-server:~/ansible-playbook$ ansible-playbook apply.yml [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' PLAY [localhost] *************************************************************** TASK [Gathering Facts] ********************************************************* ok: [localhost] TASK [create and update resources by terraform] ******************************** changed: [localhost] PLAY RECAP ********************************************************************* localhost : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 fujioka@ansible-server:~/ansible-playbook$ Terraform で記述したリソースである、VPC とサブネットが作成されています。 作成リソース terraform.tfstate にリソースの状態が記載されています。（一部省略 / 伏せ字） fujioka@ansible-server:~/ansible-playbook$ cat terraform/terraform.tfstate { "version": 4, "terraform_version": "1.4.4", "serial": 10, "lineage": "xxxx", "outputs": {}, "resources": [ { "mode": "managed", "type": "google_compute_network", "name": "vpc", "provider": "provider[\"registry.terraform.io/hashicorp/google\"]", ~ { "mode": "managed", "type": "google_compute_subnetwork", "name": "subnet", "provider": "provider[\"registry.terraform.io/hashicorp/google\"]", ~ fujioka@ansible-server:~/ansible-playbook$ リソースの削除 ansible-playbook destroy.yml コマンドで Playbook を実行します。これで作成したリソースが破棄されます。 fujioka@ansible-server:~/ansible-playbook$ ansible-playbook destroy.yml [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all' PLAY [localhost] *************************************************************** TASK [destroy resources by terraform] ****************************************** changed: [localhost] PLAY RECAP ********************************************************************* localhost : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 fujioka@ansible-server:~/ansible-playbook$ terraform.tfstate 上も更新されています。（一部伏せ字） fujioka@ansible-server:~/ansible-playbook$ cat terraform/terraform.tfstate { "version": 4, "terraform_version": "1.4.4", "serial": 13, "lineage": "xxxx", "outputs": {}, "resources": [], "check_results": null } fujioka@ansible-server:~/ansible-playbook$ 藤岡 里美 (記事一覧) クラウドソリューション部 接客業からエンジニアへ。2022年9月 G-gen にジョイン。Google Cloud 認定資格は全冠。2023 夏アニメのオススメは、ダークギャザリング。箏を習っています :) Follow @fujioka57621469

G-gen の神谷です。本記事では、Google Cloud のデータ分析系プロダクトのアップデートを取り上げ、変更点やその背景を考察し、プロダクトや機能についての理解を深めます。 新料金体系 BigQuery Editions BigQuery ML における推論での Vision API 等の呼び出し機能強化 リリース概要 当リリースのポイント CREATE TABLE AS SELECT 文による S3→BQ 移送時のデータフィルタリング機能がプレビュー リリース概要 BigQuery Omni とは BigLake とは 当リリースのポイント BigQuery のクエリで再帰処理が書ける WITH RECURSIVE 句が GA リリース概要 再帰処理とは 当リリースのポイント 大文字と小文字を区別しない照合のサポートを含む多数の関数が GA リリース概要 照合順序とは 当リリースのポイント 新料金体系 BigQuery Editions BigQuery ユーザであればおなじみであったオンデマンドプラン（スキャンしたデータ量に応じた課金モデル。コンピュートに相当するスロットは 2000 スロットまで使い放題）による従量料金モデルから BigQuery Editions と呼ばれる料金体系に主軸が変わり、従来の BigQuery Reservation (flat-rate) を置き換えることになりました。 BigQuery Editions は定額制というわけではなく、新機能である BigQuery Autoscaler 機能により、費用を柔軟化・最適化することができます。 従来のオンデマンドプランは残りますが 単価が 25% 上がります。そのため、総じて「BigQuery がいきなり値上げした！」と勘違いされそうですが、そうではありません。詳細については弊社ブログで徹底解説されていますので、そちらを参照ください。 blog.g-gen.co.jp 新料金プランの仕様を踏まえて適切な移行を行うことで、ほとんどのケースで料金削減が期待できます。逆に、変更内容を知らずに放置しておくと、いつの間にか値上げされていたということが起きます。変更ポイントをしっかりと理解した上で、適切な対策を検討・実施することを強く推奨します。 BigQuery ML における推論での Vision API 等の呼び出し機能強化 リリース概要 BigQuery ML から Cloud Vision API、Cloud Natural Language API、Cloud Translation API の呼び出しが可能になりました。 参考 : Cloud AI service table-valued functions overview その他にも、ONNX、XGBoost、TensorFlow Lite 形式のモデルインポートが可能になりました。従来は TensorFlow のモデルだけでしたが、PyTorch や schikit-learn 等のメジャーなフレークワークのモデルもインポートできるようになったため、より使い勝手が良くなったと言えます。また、Vertex AI にホストしたリモートモデルの呼び出しも可能です。 当リリースのポイント やはり、BigQuery の オブジェクトテーブル の存在が大きいです。 構造化データだけでなく、非構造化データに対しても BigQuery のフルマネージドのサーバレス環境と、コンピューティング能力が活用できます。単に推論するだけでなく、もともと入っている構造化データと、非構造化データの推論結果を組み合わせて、機械学習モデルを構築といったことが可能になります。 以下は画像データに対する推論結果から新たにテーブルを作成する例です。 CREATE TABLE my_dataset.my_inference_results AS -- ③ BQ の別テーブルに保存 SELECT uri, content_type, vision_feature FROM ML.PREDICT( -- ② 画像の特徴量から推論結果を取得 MODEL my_dataset.vision_model, -- 任意のモデルを指定 SELECT ML.DECODE_IMAGE(data) AS vision_input -- ① 画像ファイルのパスから特徴量生成 FROM my_dataset.object_table -- オブジェクトテーブルを指定 ); 「ML.DECODE_IMAGE(data)」関数を使って、画像データ（ GCS へのファイルパス）を特徴量（「vision_input」）に変換 「ML.PREDICT」であらかじめ用意した画像モデルに対して特徴量を入力して、推論を実行 推論結果を別テーブルに保存 データの移動や複雑なプログラミングをすることなく、一瞬にして異なるフォーマットのデータを統合し、後の分析に活かせる点がポイントです。 CREATE TABLE AS SELECT 文による S3→BQ 移送時のデータフィルタリング機能がプレビュー CREATE TABLE AS SELECT 文による Amazon S3 および Azure Blob Storage ファイルデータのフィルタリング結果書き込み機能がプレビューになりました。（ March 10, 2023 ） これによって、より柔軟にマルチクラウド間のデータ移送を実現できます。 リリース概要 本リリースの概要は以下の通りです。 S3（Blob Storage）→ BigQuery への転送前にデータを絞り込む機能 S3 や Blob Storage を参照する BigLake テーブルを作成する必要がある クラウド間の転送に伴う料金はかからない 注意点は以下の通りです。 BigQuery Omni リージョンのスロットが必要になる BigQuery Omni の最大クエリ結果サイズは非圧縮で 20GiB。これを超えるとエラーになる 5MB 未満の複数ファイルのロードは非推奨（なるべく大きなファイルを S3 や Blob Storage に置く） BigQuery Omni とは BigQuery Omni は、Google Cloud、AWS、Azure などの複数のクラウドプロバイダーにまたがるデータを、BigQuery のインターフェースで統一的に分析できるマルチクラウドデータウェアハウスです。これにより、データを異なるクラウド間で移動させずにクエリを実行でき、分析を効率化できます。 詳細については当社ブログを参照してください。 blog.g-gen.co.jp BigLake とは BQ 管理のストレージや GCS のファイル、S3 や Blob Storage といった別クラウドまで含めた異なるデータソースを統合的に扱える抽象化レイヤーです。 BigLakeの概要 Dataproc（Apache Spark） や Dataflow（Apache Beam）といった外部ツールを間に挟んで、BigQuery からデータソースにアクセスすることができます。 また、 BigLake メタデータ キャッシュ対応テーブル を使うことで、GCS のファイルへのクエリパフォーマンスが向上します。 当リリースのポイント BigQuery Omni はわざわざファイルを移動することなく、BigQuery から直接データソースにアクセスできるので、少ないコストで BigQuery のパワーを利用することができます。 メインのクラウドはAWSだが、BigQuery に関しては使ってみたいというケースで有効です。 今回のアップデートによって、例えば日次で増える S3 の Big Lake に対して増加分だけ絞り込んで移送といったことが可能です。 必要なデータだけ持ってこれるため、転送料やクエリ料が削減でき、データパイプラインも短くなります。 データパイプラインが長くなればなるほど、処理の依存関係を定義することや可用性を担保することの難易度があがるため、今回のアップデートはそういった問題を緩和することに繋がるでしょう。 BigQuery のクエリで再帰処理が書ける WITH RECURSIVE 句が GA リリース概要 BigQuery のクエリで再帰処理が書ける機能が GA になりました。 参考 : BigQuery release notes 参考 : WITH clause 再帰処理とは 再帰処理とは、ある処理が自分自身を繰り返し呼び出すことで、階層的なデータ構造や繰り返しのパターンを効率的に処理するプログラミング手法です。データベースのクエリにおいては、階層的なデータやグラフ構造を扱う際に再帰処理が用いられます。 当リリースのポイント WITH RECURSIVE 句が GA になることで、BigQuery ユーザーは階層的なデータ構造やグラフデータを効率的に処理できるようになります。また、再帰処理を利用することで、従来は複数のクエリや外部プログラムを用いて実現していた処理を、1つのクエリで完結させることが可能になります。これにより、データ処理の効率化やパフォーマンス向上が期待できます。ただし、再帰処理を適切に設計・実装しないと、クエリ料金が大幅に増加したり、無限ループに陥る可能性があるため、注意が必要です。 大文字と小文字を区別しない照合のサポートを含む多数の関数が GA リリース概要 大文字と小文字を区別しない照合のサポートを含む多数の関数が GA になりました。 参考 : BigQuery release notes 照合の詳細な仕様については こちら を参照してください。 以下の機能に対して有効です。 MIN、MAX、COUNT with DISTINCT、PERCENTILE_DISC によるウィンドウ関数 WINDOWS 句内の ORDER BY および PARTITION BY 制限付きの LIKE 演算子 ビュー 制限付きのマテリアライズドビュー 制限付きのテーブル関数 BigQuery BI エンジン 照合順序とは 照合順序とは、文字列データの比較やソートを行う際に使用される、文字の大小関係や等価性を決定するルールです。照合順序には、大文字と小文字を区別するものと、区別しないものがあります。 照合順序を明示的に指定しない場合、デフォルトの挙動は以下のようになります。 SELECT * FROM UNNEST([ ' B ' , ' b ' , ' a ' , ' A ' , ' C ' , ' c ' ]) AS character ORDER BY character デフォルトのソート順（大文字小文字が区別される。先に大文字、次に少文字） 半角大文字のあとに半角小文字が並びます。 次に、照合順序を明示的に指定した場合の順序です。 SELECT * FROM UNNEST([ ' B ' , COLLATE( ' b ' , ' und:ci ' ), ' a ' , ' A ' , ' C ' , ' c ' ]) AS character ORDER BY character 照合順序を明示的に指定した場合のソート順（大文字少文字が混在） 大文字と少文字を区別しないため、両者は等価だと見なされ、アルファベット順で並んだあとは、もともとの配列のインデックス順でソートされています。 照合がサポートされているデータ型は以下の通りです。 通常の STRING 型 STRUCT（構造体） 内の STRING 項目 ARRAY（配列） 内の STRING 要素 照合は、データセットやテーブル、列単位で定義できます。 -- データセットレベルでの定義 CREATE SCHEMA (...) DEFAULT COLLATE ' und:ci ' -- テーブルレベルでの定義 CREATE TABLE (...) DEFAULT COLLATE ' und:ci ' -- 列レベルでの定義 CREATE TABLE ( case_insensitive_column STRING COLLATE ' und:ci ' ) 当リリースのポイント 今回のリリースによって、BigQuery ユーザーは文字列データの比較やソートを、大文字と小文字の違いを気にせずに行えるようになります。これまで独自の関数や前処理を入れて処理していたことが BigQuery の標準機能だけで実現できます。 神谷 乗治 (記事一覧) データアナリティクス準備室 室長 クラウドエンジニア。2017 年頃から Google Cloud を用いたデータ基盤構築や ML エンジニアリング、データ分析に従事。クラウドエース株式会社システム開発部マネージャーを経て現職。Google Cloud Partner Top Engineer 2023、Google Cloud Champion Innovators（Database）、 著書：「GCPの教科書III【Cloud AIプロダクト編】」 　

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 G-gen の藤岡です。組織内アクセス制限は、承認された Google Cloud 組織へのみアクセスを許可する Resource Manager の機能の 1 つです。当記事では組織内アクセス制限機能の解説と、検証を行います。 概要 組織内アクセス制限 とは 使用時の考慮点 サポート対象のサービス Google 所有のリソースへのアクセス Cloud Shell の使用 下り（外向き）プロキシの構成 類似機能 検証の準備 アーキテクチャ 前提条件 Squid と SSL Bump SSL Bump による SSL/TLS 復号 注意点 検証環境の構築 事前準備 Squid のインストール 自己署名 SSL 証明書の作成 証明書を Windows の信頼されたルート証明書機関にインポート SSL Bump の設定 クライアントの設定 検証 補足 概要 組織内アクセス制限 とは 組織内アクセス制限 (Organization restrictions) は、ユーザーがアクセスできる Google Cloud 組織を制限する機能です。この機能を使うことで、フィッシングやインサイダー攻撃などにより、組織内からデータが引き出され、別の Google Cloud 組織に持ち出されてしまうこと等を防ぐことが出来ます。 当機能を使うには、組織内ネットワークの HTTP プロキシでユーザーのリクエストに X-Goog-Allowed-Resources という HTTP ヘッダを追加し、ヘッダの値としてアクセスを許可する Google Cloud 組織の ID を設定します。 Google Cloud API へのリクエストにこのヘッダが存在すると ヘッダの値で許可されていない組織へのアクセスは拒否 されます。 つまり、当機能を使用するには、組織 (会社や官公庁) で HTTP プロキシを使っており、それ以外にインターネットへの抜け道が無いことが前提となります。 画像は 公式 より引用 使用時の考慮点 組織内アクセス制限を使用する際の考慮点を 4 点紹介します。記載の項目以外にも、既存環境を考慮した上で導入する必要があります。 サポート対象のサービス サポートされているサービスは ドキュメント にある通りです。 組織内アクセス制限は、Google Cloud コンソールから発信されるこのサービスへのリクエストでのみ部分的にサポートされています。 と記載のあるサービスもあります。 ほとんどの Google Cloud サービスが対象になってはいますが、念の為自分の環境で使われている Google Cloud サービスが対象となっているか、確認しましょう。 Google 所有のリソースへのアクセス BigQuery や Compute Engine（以下 GCE）等で使う Google の公開リソースは、Google 所有の Google Cloud 組織でホストされています。それらを使用する場合には、組織 ID の 433637338589 を組織内アクセス制限ヘッダに追加します。 Google 所有の Google Cloud 組織（組織 ID： 433637338589 ）を追加しないでコンソールから GCE の [インスタンスを作成] をクリックすると以下のエラーとなりました。 これは GCE の公開 OS イメージが、前述の Google Cloud 組織で管理されているためです。 Access denied by organization restriction. Please contact your administrator for additional information on this feature. 組織内アクセス制限エラー 参考： Google 所有のリソースへのアクセスを有効にする Cloud Shell の使用 Cloud Shell の実態は Google Cloud が所有する GCE インスタンス上の Docker コンテナです。そのため Cloud Shell から gcloud コマンド等を利用すると、その API コールは組織ネットワークの HTTP プロキシを通りません。つまり組織内アクセス制限機能によるヘッダは付与されず、制限は発生しません。 以上を踏まえ、当機能を用いて Google Cloud 組織へのアクセスを制御したい場合、 Cloud Shell の無効化 が必須 となります。Cloud Shell は Google Workspace / Cloud Identity の管理画面から無効にすることができます。 上記の挙動を簡単に検証してみます。 組織内アクセス制限適用時の Cloud Shell の使用 図にあるようにユーザー A が組織 A と B を使用できる権限がある場合でも、Web コンソールからは組織 A のみが表示され、組織 B への操作ができません。しかし Cloud Shell 経由で操作すると、Google Cloud API への API コールは社内のプロキシサーバを経由しないため、ヘッダが追加されず、制限がかかりません。 Cloud Shell から組織の一覧表示（ gcloud organizations list ）をすると組織 B も表示がされ、権限に従ってリソースの作成も可能 です。 参考： Cloud Shell の仕組み 下り（外向き）プロキシの構成 組織内アクセス制限を使用するにあたり、ヘッダの付与を Google Cloud 以外のターゲットに追加しないようにすることも可能です。ターゲットに入れるべきドメインは ドキュメント にある通りです。 入れるべきターゲットには *.google.com も含まれており、これは組織内アクセス制限を使うためには一般の Google 検索のリクエストへもヘッダの付与が必要であることを意味し、プロキシの処理量にも影響があるため、利用時には検討が必要です。 類似機能 当記事で紹介する組織内アクセス制限は、Google Cloud 組織の ID を使用し、利用できる Google Cloud の組織を制限しますが、類似機能としてユーザーアカウントを使用して Google サービスの利用を制限する機能もあります。この機能を使うことで、特定のドメインから組織の Google サービスの利用を許可し、一般ユーザー向けのアカウント（例： 〜@gmail.com ）や別ドメインからの利用を防ぐことができます。 詳細は ドキュメント をご参照ください。 検証の準備 アーキテクチャ 当記事で構築する構成は以下の通りです。 Amazon Web Services (AWS) 環境を会社や官公庁の組織ネットワークに見立てます。Amazon EC2 で HTTP プロキシに見立てた Squid サーバーを構築します。 Squid で組織内アクセス制限ヘッダを付与することで、クライアントからの操作を 組織 A のみに制限 します。 構成図 前提条件 インスタンス情報は以下の通りです。AWS の VPC や EC2、セキュリティグループの設定は当記事では触れません。 インスタンス名 OS プライベート IP アドレス パブリック IP アドレス windows-client Windows10 - xxx.xxx.xxx.6 proxy-server Amazon Linux 2 172.31.15.234 xxx.xxx.xxx.66 windows-client 情報 # proxy-server 情報 [ec2-user@ip-172-31-15-234 ~]$ cat /etc/os-release NAME="Amazon Linux" VERSION="2" ID="amzn" ID_LIKE="centos rhel fedora" VERSION_ID="2" PRETTY_NAME="Amazon Linux 2" ANSI_COLOR="0;33" CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2" HOME_URL="https://amazonlinux.com/" [ec2-user@ip-172-31-15-234 ~]$ Squid と SSL Bump SSL Bump による SSL/TLS 復号 当記事では AWS 環境に構築した EC2 インスタンスに Squid と SSL Bump をセットアップし、社内 HTTP プロキシサーバとして見立てて検証を行います。 SSL Bump は、HTTPS 通信をクライアントと Squid で終端します。Squid で復号し、再度暗号化することで、通常時はリクエスト先の URL はドメインまでしか確認できない HTTPS 通信の中身を見ることができます。これは、MITM 攻撃（Man-In-The-Middle：中間者攻撃）と同じ手法です。 SSL Bump を使うことでリクエストに HTTP ヘッダを追加できます。設定ファイル（squid.conf）の request_header_add で追加するヘッダが構成されますが、ヘッダを Google Cloud 以外のターゲットに追加しないようにすることもできます。そのためには、 ドキュメント に記載のリクエストにのみヘッダを追加するよう構成します。 注意点 Squid で SSL Bump を使うには、 configure options パラメータの値に --with-openssl と --enable-ssl-crtd のオプションが必要です。 ディストリビューションによって、 インストールされるデフォルトオプションが異なる ため、必要なオプションがない場合にはソースからビルドしなければなりません。 例として、GCE の OS を CentOS と Debian のそれぞれで Squid をインストールした時のパラメータ値を比べます。 # CentOS の場合 [fujioka@centos ~]$ cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" [fujioka@centos ~]$ [fujioka@centos ~]$ sudo yum install squid ... [fujioka@centos ~]$ [fujioka@centos ~]$ squid -v Squid Cache: Version 3.5.20 Service Name: squid configure options: '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-strict-error-checking' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=$(localstatedir)/log/squid' '--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' '--enable-eui' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,SMB_LM,getpwnam' '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos' '--enable-external-acl-helpers=file_userip,LDAP_group,time_quota,session,unix_group,wbinfo_group,kerberos_ldap_group' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-ssl-crtd' '--enable-storeio=aufs,diskd,rock,ufs' '--enable-wccpv2' '--enable-esi' '--enable-ecap' '--with-aio' '--with-default-user=squid' '--with-dl' '--with-openssl' '--with-pthreads' '--disable-arch-native' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fpie' 'LDFLAGS=-Wl,-z,relro -pie -Wl,-z,relro -Wl,-z,now' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fpie' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' [fujioka@centos ~]$ # Debian の場合 fujioka@debian:~$ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" fujioka@debian:~$ fujioka@debian:~$ sudo apt install squid ... fujioka@debian:~$ fujioka@debian:~$ sudo squid -v Squid Cache: Version 4.13 Service Name: squid Debian linux configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' 'BUILDCXXFLAGS=-g -O2 -ffile-prefix-map=/build/squid-Nhk3MN/squid-4.13=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now ' 'BUILDCXX=g++' '--with-build-environment=default' '--enable-build-info=Debian linux' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--libexecdir=/usr/lib/squid' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,SMB_LM' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,time_quota,unix_group,wbinfo_group' '--enable-security-cert-validators=fake' '--enable-storeid-rewrite-helpers=file' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/run/squid.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' '--with-systemd' '--with-gnutls' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/squid-Nhk3MN/squid-4.13=. -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now ' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -ffile-prefix-map=/build/squid-Nhk3MN/squid-4.13=. -fstack-protector-strong -Wformat -Werror=format-security' fujioka@debian:~$ 比較すると、 --with-openssl と --enable-ssl-crtd のオプションが CentOS ではデフォルトで入っていることがわかります。当記事で構築する Amazon Linux 2 の EC2 ではデフォルトで必要なオプションが入っています。 検証環境の構築 事前準備 ドキュメント に従ってヘッダを作成します。 前述の Google 所有のリソースへのアクセス にある通り、Google の組織 ID（ 433637338589 ）も追加します。ヘッダの作成は Cloud Shell から実行しました。 # 作成されたヘッダ fujioka@cloudshell:~ (xxxx)$ cat authorized_orgs.json { "resources": ["organizations/<組織 A の ID>", "organizations/433637338589"], "options": "strict" } fujioka@cloudshell:~ (xxxx)$ 次に、作成したヘッダを base64 エンコードします。エンコード結果は、後述の SSL Bump の設定 で使用します。 # エンコード fujioka@cloudshell:~ (xxxx)$ cat authorized_orgs.json | basenc --base64url -w0 ewxxxxxxxxxxxxx fujioka@cloudshell:~ (xxxx)$ Squid のインストール proxy-server インスタンスに Squid をインストールします。インストールされたバージョンは 3.5.20 です。 # パッケージのアップデート [ec2-user@ip-172-31-15-234 ~]$ sudo -i [root@ip-172-31-15-234 ~]# [root@ip-172-31-15-234 ~]# yum update [root@ip-172-31-15-234 ~]# # インストール [root@ip-172-31-15-234 ~]# yum install squid [root@ip-172-31-15-234 ~]# # バージョン確認 [root@ip-172-31-15-234 ~]# squid -v Squid Cache: Version 3.5.20 Service Name: squid configure options: '--build=x86_64-koji-linux-gnu' '--host=x86_64-koji-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-strict-error-checking' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=$(localstatedir)/log/squid' '--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' '--enable-eui' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,SMB_LM,getpwnam' '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos' '--enable-external-acl-helpers=file_userip,LDAP_group,time_quota,session,unix_group,wbinfo_group,kerberos_ldap_group' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-ssl-crtd' '--enable-storeio=aufs,diskd,rock,ufs' '--enable-wccpv2' '--enable-esi' '--enable-ecap' '--with-aio' '--with-default-user=squid' '--with-dl' '--with-openssl' '--with-pthreads' '--disable-arch-native' 'build_alias=x86_64-koji-linux-gnu' 'host_alias=x86_64-koji-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fpie' 'LDFLAGS=-Wl,-z,relro -pie -Wl,-z,relro -Wl,-z,now' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fpie' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' [root@ip-172-31-15-234 ~]# # 起動 [root@ip-172-31-15-234 ~]# systemctl start squid [root@ip-172-31-15-234 ~]# [root@ip-172-31-15-234 ~]# systemctl status squid ● squid.service - Squid caching proxy Loaded: loaded (/usr/lib/systemd/system/squid.service; disabled; vendor preset: disabled) Active: active (running) since Sun 2023-03-19 00:42:48 UTC; 5s ago ... [root@ip-172-31-15-234 ~]# # 自動起動設定 [root@ip-172-31-15-234 ~]# systemctl enable squid Created symlink from /etc/systemd/system/multi-user.target.wants/squid.service to /usr/lib/systemd/system/squid.service. [root@ip-172-31-15-234 ~]# [root@ip-172-31-15-234 ~]# systemctl is-enabled squid enabled [root@ip-172-31-15-234 ~]# 自己署名 SSL 証明書の作成 proxy-server インスタンスで自己署名 SSL 証明書を作成します。 # Squid ディレクトリへ移動 [root@ip-172-31-15-234 ~]# cd /etc/squid/ [root@ip-172-31-15-234 squid]# # 自己署名 SSL 証明書を作成（証明書の有効期間は 30 日で設定） [root@ip-172-31-15-234 squid]# openssl req -new -newkey rsa:2048 -days 30 -nodes -x509 -keyout bump.key -out bump.crt ... ----- Country Name (2 letter code) [XX]:JP State or Province Name (full name) []: Locality Name (eg, city) [Default City]: Organization Name (eg, company) [Default Company Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:SQUID Email Address []: [root@ip-172-31-15-234 squid]# # 証明書ファイル（bump.crt）と秘密鍵ファイル（bump.key）が作成される [root@ip-172-31-15-234 squid]# ls -l total 56 -rw-r--r-- 1 root root 1261 Mar 19 00:47 bump.crt -rw-r--r-- 1 root root 1704 Mar 19 00:47 bump.key ... [root@ip-172-31-15-234 squid]# # 証明書をクライアントにインポートできるように DER 形式に変換 [root@ip-172-31-15-234 squid]# openssl x509 -in bump.crt -outform DER -out bump.der [root@ip-172-31-15-234 squid]# # bump.der が作成される [root@ip-172-31-15-234 squid]# ls -l total 60 -rw-r--r-- 1 root root 1261 Mar 19 00:47 bump.crt -rw-r--r-- 1 root root 891 Mar 19 00:51 bump.der -rw-r--r-- 1 root root 1704 Mar 19 00:47 bump.key ... [root@ip-172-31-15-234 squid]# 証明書を Windows の信頼されたルート証明書機関にインポート proxy-server で作成した bump.der を windows-client に scp コマンド等で転送し、任意の場所に置きます。 windows-client のエクスプローラー windows-client で証明書をインポートします。 [証明書 - ローカルコンピューター] > [信頼されたルート証明機関] を右クリックし、 [すべてのタスク] > [インポート] をクリックします。 証明書のインポート① ウィザードに従って設定をし、[完了] をクリックします。 証明書のインポート② インポートが成功すると、 正しくインポートされました。 と表示され、proxy-server で作成した自己署名SSL 証明書が表示されます。 証明書のインポート③ SSL Bump の設定 proxy-server で SSL Bump の設定をします。 # Diffie-Hellman アルゴリズムの設定ファイルを生成 [root@ip-172-31-15-234 squid]# openssl dhparam -outform PEM -out /etc/squid/bump_dhparam.pem 2048 [root@ip-172-31-15-234 squid]# # bump_dhparam.pem が作成される [root@ip-172-31-15-234 squid]# ls -l total 64 -rw-r--r-- 1 root root 1261 Mar 19 00:47 bump.crt -rw-r--r-- 1 root root 891 Mar 19 00:51 bump.der -rw-r--r-- 1 root root 424 Mar 19 01:00 bump_dhparam.pem -rw-r--r-- 1 root root 1704 Mar 19 00:47 bump.key ... [root@ip-172-31-15-234 squid]# # ファイルのパーミッション設定 [root@ip-172-31-15-234 squid]# chown squid:squid /etc/squid/bump* [root@ip-172-31-15-234 squid]# [root@ip-172-31-15-234 squid]# chmod 400 /etc/squid/bump* [root@ip-172-31-15-234 squid]# [root@ip-172-31-15-234 squid]# ls -l total 64 -r-------- 1 squid squid 1261 Mar 19 00:47 bump.crt -r-------- 1 squid squid 891 Mar 19 00:51 bump.der -r-------- 1 squid squid 424 Mar 19 01:00 bump_dhparam.pem -r-------- 1 squid squid 1704 Mar 19 00:47 bump.key ... [root@ip-172-31-15-234 squid]# # サービス停止 [root@ip-172-31-15-234 squid]# systemctl stop squid [root@ip-172-31-15-234 squid]# systemctl status squid ● squid.service - Squid caching proxy Loaded: loaded (/usr/lib/systemd/system/squid.service; enabled; vendor preset: disabled) Active: inactive (dead) since Sun 2023-03-19 01:14:22 UTC; 10s ago ... [root@ip-172-31-15-234 squid]# # 証明書データベース用ディレクトリの作成と初期化 [root@ip-172-31-15-234 squid]# mkdir /var/lib/squid [root@ip-172-31-15-234 squid]# [root@ip-172-31-15-234 squid]# /usr/lib64/squid/ssl_crtd -c -s /var/lib/squid/ssl_db Initialization SSL db... Done [root@ip-172-31-15-234 squid]# Squid の設定ファイル（squid.conf）を SSL Bump 用に変更します。検証用のため、Basic 認証等の設定はしていない簡易的な設定です。 # 差分（squid.conf.default には変更前の内容が記載されているため差分で表示） [root@ip-172-31-15-234 squid]# diff -u -B squid.conf.default squid.conf --- squid.conf.default 2023-02-13 20:53:51.000000000 +0000 +++ squid.conf 2023-03-31 04:48:08.831966864 +0000 @@ -11,7 +11,7 @@ acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines -acl SSL_ports port 443 +acl SSL_ports port 443 3128 # 3128 ポート追加 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https @@ -24,6 +24,8 @@ acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT +acl client src xxx.xxx.xxx.6/32 # windows-client +http_access allow client # 許可 # # Recommended minimum Access Permission configuration: # @@ -56,7 +58,12 @@ http_access deny all # Squid normally listens to port 3128 -http_port 3128 +# http_port 3128 # コメントアウト +# 以下1行追加 +http_port 3128 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB cert=/etc/squid/bump.crt key=/etc/squid/bump.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,NO_SSLv2,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/bump_dhparam.pem + +# 以下1行追加（組織 A と Google Cloud 所有組織 のみに制限） +request_header_add X-Goog-Allowed-Resources ewxxxxxxxxxxxxx all # Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/spool/squid 100 16 256 @@ -71,3 +78,8 @@ refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 + +# 以下3行追加 +sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 20MB +sslproxy_cert_error allow all +ssl_bump stare all [root@ip-172-31-15-234 squid]# # 変更後の squid.conf 全文 [root@ip-172-31-15-234 squid]# cat squid.conf # # Recommended minimum configuration: # # Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 10.0.0.0/8 # RFC1918 possible internal network acl localnet src 172.16.0.0/12 # RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7 # RFC 4193 local private network range acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines acl SSL_ports port 443 3128 # 3128 ポート追加 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl client src xxx.xxx.xxx.6/32 # windows-client http_access allow client # 許可 # # Recommended minimum Access Permission configuration: # # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost http_access allow localhost manager http_access deny manager # We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on "localhost" is a local user #http_access deny to_localhost # # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed http_access allow localnet http_access allow localhost # And finally deny all other access to this proxy http_access deny all # Squid normally listens to port 3128 # http_port 3128 # コメントアウト # 以下1行追加 http_port 3128 tcpkeepalive=60,30,3 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=20MB cert=/etc/squid/bump.crt key=/etc/squid/bump.key cipher=HIGH:MEDIUM:!LOW:!RC4:!SEED:!IDEA:!3DES:!MD5:!EXP:!PSK:!DSS options=NO_TLSv1,NO_SSLv3,NO_SSLv2,SINGLE_DH_USE,SINGLE_ECDH_USE tls-dh=prime256v1:/etc/squid/bump_dhparam.pem # 以下1行追加（組織 A と Google Cloud 所有組織 のみに制限） request_header_add X-Goog-Allowed-Resources ewxxxxxxxxxxxxx all # Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/spool/squid 100 16 256 # Leave coredumps in the first cache dir coredump_dir /var/spool/squid # # Add any of your own refresh_pattern entries above these. # refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 # 以下3行追加 sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 20MB sslproxy_cert_error allow all ssl_bump stare all [root@ip-172-31-15-234 squid]# 設定を適用します。 # 再起動 [root@ip-172-31-15-234 squid]# systemctl restart squid [root@ip-172-31-15-234 squid]# [root@ip-172-31-15-234 squid]# systemctl status squid ● squid.service - Squid caching proxy Loaded: loaded (/usr/lib/systemd/system/squid.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2023-03-19 02:17:42 UTC; 5s ago ... [root@ip-172-31-15-234 squid]# クライアントの設定 windows-client でプロキシの設定をします。 アドレス には proxy-client の IP アドレスを、 ポート は 3128 を設定します。 クライアントのプロキシ設定 検証 windows-client から Google Cloud コンソールを表示させます。 ブラウザは Google Chrome（バージョン: 111.0.5563.65（Official Build） （64 ビット））を使用しました。組織内アクセス制限で構成した通り、組織 A のみに制限されています。 組織内アクセス制限：適用 一方で windows-client で HTTP プロキシを利用しないように設定した場合、同一ユーザーでコンソールを確認すると、組織 B も表示されます（ユーザーに組織 A, B への権限があるため）。 組織内アクセス制限：未適用 HTTP プロキシを経由したアクセスの場合のみ、アクセス先 Google Cloud 組織が制限されることが確認できました。 補足 EC2 の Amazon Linux 2023 （以下 AL2023）では Squid パッケージがリポジトリにないため、インストールするにはソースのダウンロードからしなければなりません。また、AL2023 ではデフォルトのパッケージ管理ツールは DNF になっています。 [ec2-user@ip-172-31-12-52 ~]$ cat /etc/system-release Amazon Linux release 2023 (Amazon Linux) [ec2-user@ip-172-31-12-52 ~]$ [ec2-user@ip-172-31-12-52 ~]$ sudo yum search squid Last metadata expiration check: 0:06:57 ago on Sun Mar 19 11:17:05 2023. No matches found. [ec2-user@ip-172-31-12-52 ~]$ [ec2-user@ip-172-31-12-52 ~]$ sudo dnf search squid Last metadata expiration check: 0:07:06 ago on Sun Mar 19 11:17:05 2023. No matches found. [ec2-user@ip-172-31-12-52 ~]$ 参考： パッケージ管理ツール 藤岡 里美 (記事一覧) クラウドソリューション部 接客業からエンジニアへ。2022年9月 G-gen にジョイン。Google Cloud 認定資格は全冠。2023 夏アニメのオススメは、ダークギャザリング。箏を習っています :) Follow @fujioka57621469

G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) のサーバーレスコンテナサービスである Cloud Run の Startup CPU boost 機能について解説します。Startup CPU boost は、Cloud Run の弱点とも言える コールドスタート による影響を軽減することができる機能です。 前提知識 Cloud Run とは Cloud Run におけるコールドスタート Startup CPU boost とは 料金 ユースケース 設定方法 前提知識 Cloud Run とは Cloud Run はサーバーレスな環境でコンテナを実行できるサービスです。 Startup CPU boost は、Cloud Run のうち、HTTP リクエストをトリガーとしてコンテナアプリケーションを実行する Cloud Run services に関する機能となります。 Cloud Run services の詳細については以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run におけるコールドスタート Cloud Run の大きな特徴として、リクエストがないときには、アプリケーションの実行基盤であるコンテナインスタンスを 0 までスケールインするように設定することができます。 このように、コンテナインスタンスの最小数が 0 に設定されている場合、Cloud Run はリクエストを処理しているときに使用した CPU / Memory リソースのぶんだけ料金が発生するため、リクエストがないときには料金を節約することが可能です。 そのトレードオフとして、コンテナインスタンスの数が 0 になっているときにリクエストがあると、Cloud Run がコンテナインスタンスを起動するまでの数秒間、リクエストの処理に レイテンシが発生 してしまいます。これを コールドスタート といいます。 コールドスタートの詳細は、以下の記事も参照してください。 blog.g-gen.co.jp これを回避するために、最小インスタンス数を 1 以上にすることで、常に 1 台以上のインスタンスを起動した状態でリクエストを待ち受けることはできますが、その場合、Cloud Run の料金はコンテナインスタンスに割り当てた CPU / Memory のぶんだけ常に発生するようになります。 ここまで説明した Cloud Run の CPU / Memory に関する課金方式をまとめると以下のようになります。 最小インスタンス数 CPU / Memory の課金方式 0 リクエストを処理している時間だけ課金 1 以上 起動しているインスタンスのぶんは常に課金 つまり、最小インスタンス数を増やしてコールドスタートを回避しようとすると、Cloud Run がもつサーバーレスの強みが損なわれてしまうことになります。 また、最小インスタンス数が 1 以上に設定されていても、リクエスト数が急激に増加した場合、コンテナインスタンスのスケールアウトがリクエスト数の増加に間に合わないと、 新しく起動されるコンテナインスタンスでは同様にコールドスタートが発生する ため、根本的な解決にはなりません。 Startup CPU boost とは Startup CPU boost は、Cloud Run services におけるコンテナインスタンスの 起動中に追加の CPU を割り当てる ことで、インスタンス数が 0 のときにリクエストがあった場合や、インスタンスがスケールアウトする場合に、 コールドスタートによるレイテンシを軽減する ことができる機能です。 起動時に追加で割り当てることができる CPU 数は、コンテナインスタンスに設定した CPU 数の上限値に依存しています。 設定した CPU 上限 ブースト時の CPU 数 0-1 2 2 4 4 8 6 8 8 8（ブーストされない） 参考： 起動時 CPU ブーストを設定する 料金 Startup CPU boost の料金は、ブースト時間中に使われた CPU 数で計算されます。 たとえば、ブーストを有効にした CPU 数 2 のコンテナインスタンスの起動時間が 10 秒の場合、起動中の 10 秒間だけ CPU 数 4 のときの料金が発生します。 ユースケース Startup CPU boost ではコールドスタートによるレイテンシの軽減が見込めるものの、コンテナインスタンス起動中は追加の CPU 利用料が発生する点に注意が必要です。コールドスタートのレイテンシを許容できるアプリケーションであれば、料金の節約のためにブーストを使用しないほうが無難です。 ブーストはレスポンス速度が求められるアプリケーションにおいて有用であり、最小インスタンス数を 1 以上にする前に、まずはブーストを有効化してパフォーマンス要件が満たせるか検討してみるのがよいでしょう。 設定方法 Startup CPU boost は Cloud Run services のサービス作成時、もしくは更新時に有効化 / 無効化することができます。 参考： 起動時 CPU ブーストを設定する 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の藤岡です。当記事では、Google Cloud（旧称 GCP）の Cloud Shell の $HOME ディレクトリのアーカイブを Cloud Storage へアップロードし、Cloud Shell を初期化する方法について紹介します。 サービスの概要 Cloud Shell 永続ディスクストレージ Cloud Storage 実施内容 事前確認 アーカイブの作成 GCS にアップロード Cloud Shell の初期化 サービスの概要 Cloud Shell Cloud Shell は Google Cloud コンソールから利用できる、オンラインの開発および運用環境です。 利用者は、Debian ベースの Linux OS である Compute Engine VM を一時的にプロビジョニングしたものを使用します。 gcloud CLI や Git 等のツールや、Java、Go、Python 等の言語がプレインストールされています。なお、Cloud Shell は 無料 で利用できます。 参考： Cloud Shell の仕組み 永続ディスクストレージ Cloud Shell にプロビジョニングされた VM には $HOME ディレクトリに 5 GB の永続ディスクストレージがマウントされます。 ユーザーごとに永続ディスクストレージが割り当たるため、他のユーザーからアクセスすることはできません。 120 日間 Cloud Shell にアクセスがないと、 $HOME ディレクトリが削除されます。削除前に以下のようなメールが届きます。 送信元： noreply-cloudshell@google.com 件名： Google Cloud Shell ホーム ディレクトリの削除通知 メール内容 Cloud Storage Cloud Storage (以下 GCS) は、容量無制限・低価格・堅牢なオブジェクトストレージサービスです。詳細は以下の記事をご参照ください。 blog.g-gen.co.jp 実施内容 事前確認 Cloud Shell の初期化前の容量を確認します。 # 設定の確認 fujioka@cloudshell:~ (xxxx)$ gcloud config configurations list NAME: cloudshell-xxxx IS_ACTIVE: True ACCOUNT: PROJECT: xxxx COMPUTE_DEFAULT_ZONE: COMPUTE_DEFAULT_REGION: fujioka@cloudshell:~ (xxxx)$ # 容量確認 fujioka@cloudshell:~ (xxxx)$ df -h Filesystem Size Used Avail Use% Mounted on overlay 60G 47G 14G 78% / tmpfs 64M 0 64M 0% /dev /dev/disk/by-id/google-home-part1 4.8G 1.2G 3.4G 27% /home /dev/sda1 60G 47G 14G 78% /root /dev/root 2.0G 999M 959M 52% /usr/lib/modules shm 64M 0 64M 0% /dev/shm tmpfs 3.2G 1.3M 3.2G 1% /google/host/var/run fujioka@cloudshell:~ (xxxx)$ アーカイブの作成 Cloud Shell の $HOME のアーカイブを作成します。 # アーカイブの作成 fujioka@cloudshell:~ (xxxx)$ tar -czvf backup.tar.gz $HOME ... tar: /home/fujioka: file changed as we read it fujioka@cloudshell:~ (xxxx)$ # アーカイブが作成されたことを確認 fujioka@cloudshell:~ (xxxx)$ ls -l total 335832 ... -rw-r--r-- 1 fujioka fujioka 343831350 Apr 5 12:03 backup.tar.gz ... fujioka@cloudshell:~ (xxxx6)$ GCS にアップロード 作成した backup.tar.gz を GCS にアップロードします。 # バケットの作成 fujioka@cloudshell:~ (xxxx)$ gcloud storage buckets create gs://cloudshell-home-backup Creating gs://cloudshell-home-backup/... fujioka@cloudshell:~ (xxxx)$ # バケットの確認 fujioka@cloudshell:~ (xxxx)$ gcloud storage ls gs://cloudshell-home-backup/ fujioka@cloudshell:~ (xxxx)$ # オブジェクトのアップロード fujioka@cloudshell:~ (xxxx)$ gcloud storage cp backup.tar.gz gs://cloudshell-home-backup ... Completed files 1/1 | 327.9MiB/327.9MiB Average throughput: 199.9MiB/s fujioka@cloudshell:~ (xxxx)$ # オブジェクトの確認 fujioka@cloudshell:~ (xxxx)$ gcloud storage ls --recursive gs://cloudshell-home-backup/* gs://cloudshell-home-backup/backup.tar.gz fujioka@cloudshell:~ (xxxx)$ 参考： gcloud storage Cloud Shell の初期化 Cloud Shell を初期化します。 # ホーム ディレクトリからすべてのファイルを削除 fujioka@cloudshell:~ (xxxx)$ sudo rm -rf $HOME -bash: history: /home/fujioka/.bash_history: cannot create: No such file or directory fujioka@cloudshell:~ (xxxx)$ Cloud Shell のメニューで [さらに表示] > [再起動] をクリックします。 再起動① 任意の理由にチェックを入れ、[再起動] をクリックします。 再起動② 再接続をすると、新しい VM がプロビジョニングされ /home の使用可能な容量も増えていることが確認できます。 fujioka@cloudshell:~ (xxxx)$ df -h Filesystem Size Used Avail Use% Mounted on overlay 60G 47G 14G 78% / tmpfs 64M 0 64M 0% /dev /dev/disk/by-id/google-home-part1 4.8G 68K 4.6G 1% /home /dev/sda1 60G 47G 14G 78% /root /dev/root 2.0G 999M 959M 52% /usr/lib/modules shm 64M 0 64M 0% /dev/shm tmpfs 3.2G 1.3M 3.2G 1% /google/host/var/run fujioka@cloudshell:~ (xxxx)$ 参考： Cloud Shell をリセットする 藤岡 里美 (記事一覧) クラウドソリューション部 数年前までチキン売ったりドレスショップで働いてました！2022年9月 G-gen にジョイン。ハイキューの映画を4回は見に行きたい。 Google Cloud All Certifications Engineer / Google Cloud Partner Top Engineer 2024 Follow @fujioka57621469