G-gen の佐々木です。当記事では Google Cloud（旧称 GCP）のサーバーレスなコンテナサービスである Cloud Run の提供形態の1つである Cloud Run jobs について解説します。 Cloud Run jobs とは Cloud Run jobs のリソースモデル ジョブ（job） 実行（execution） タスク（task） Cloud Run jobs の特徴 任意のタイミングでの実行 長時間の実行 並列処理 制限事項 コンピューティングリソース タスクの実行数と並列実行数 タスクのタイムアウト タスクの最大再試行回数 VPC リソースとの接続 料金 Batch との違い Batch とは Cloud Run jobs を使用するケース Batch を使用するケース Cloud Run jobs とは Cloud Run jobs とは、Google Cloud におけるサーバーレス コンテナコンピューティングサービスである Cloud Run の提供形態の1つです。 HTTPS リクエストをトリガーとして実行される Cloud Run services とは異なり、Cloud Run jobs は手動やスケジュール、ワークフローの一部など、任意のタイミングで実行されることを前提としているのが特徴です。 参考 : デプロイ オプションとリソースモデル - Cloud Run ジョブ Cloud Run の詳細については以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run jobs のリソースモデル Cloud Run Jobs はジョブ（job）、実行（execution）、タスク（task）という 3 つのリソースで構成されています。 参考 : デプロイ オプションとリソースモデル - Cloud Run ジョブ Cloud Run jobs のリソースモデル ジョブ（job） Cloud Run jobs にコンテナをデプロイすると、ルートリソースである ジョブ （job）が作成されます。 ジョブには、コンテナイメージ、タスク数、並列実行数、CPU、メモリ量、環境変数などの設定が保持されます。 ジョブの実行がトリガーされると、設定に応じてタスクが作成されます。 実行（execution） 実行 （execution）は、1回のジョブ実行を指します。ジョブが実行されると、指定したとおりにタスクが生成されます。 実行は、全てのタスクが完了した場合に成功とされます。 タスク（task） タスク （task）は、ジョブで指定された数だけ作成されます。1つのタスクにつき1つのコンテナインスタンスが起動して処理を行います。つまり、1タスク = 1コンテナインスタンスです。 ジョブの設定内容に応じて、複数のタスクを並行で実行することができます。 タスクが失敗した場合、事前に指定した最大試行回数の範囲で再試行が行われます。最大試行回数を超過した場合、タスクは失敗になり、そのタスクを含んだ実行も失敗となります。 また、タスクにはタイムアウト（最大実行時間）を設定することができ、デフォルトで10分、最長168時間（7日間）に設定できます。ただし GPU を使用するタスクの最大実行時間は1時間です。なおタスクが再試行された場合、タイムアウトは各試行ごとに適用されます。 なお Cloud Run jobs のコンテナインスタンスは、Cloud Run 第2世代の実行環境を使用します。 参考 : サービス実行環境について Cloud Run jobs の特徴 Cloud Run services との違いに着目した場合、Cloud Run jobs の主な特徴は 3 つあります。 任意のタイミングでの実行 Cloud Run services ではサービスを作成すると HTTPS エンドポイントが生成され、HTTP リクエストをトリガーとしてコンテナが実行されます。 それに対して Cloud Run jobs では、HTTPS エンドポイントを使用しません。以下のいずれかのトリガーで、ユーザーの任意のタイミングでコンテナを実行することができます。 実行方法 説明 手動実行 コンソールや gcloud コマンド、Google Cloud APIs 経由でジョブを実行します。 gcloud コマンドを使用する場合 --execute-now オプションを指定することで、ジョブの作成後すぐに実行することが可能です。 Cloud Scheduler トリガー Cloud Scheduler で cron ジョブを設定し、スケジュールに従ってジョブを実行することができます。 Workflows トリガー サーバーレスのジョブ自動化サービスである Cloud Workflows で Cloud Run Admin API コネクタ を使用することで、ワークフローからジョブを実行することができます。 Cloud Scheduler、Cloud Workflows の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 長時間の実行 タスクあたりの最大実行時間は、デフォルトで10分、最長で168時間（7日間）です。ただし、GPU を使用するタスクの場合は、最長1時間です。 なお、タスクには最大実行時間の制限がありますが、タスクの上位リソースであるジョブには最大実行時間には制限がありません。そのため、複数のタスクを直列で実行することで、より長時間の処理を実現することができます。 参考 : ジョブのタスク タイムアウトを設定する 並列処理 リクエストの負荷に応じてコンテナインスタンスをスケーリングする Cloud Run services とは異なり、Cloud Run jobs では並列して実行するコンテナインスタンス（= タスク）の数を明示的に指定することができます。 並列実行される各タスクには整数値のインデックスが割り当てられ、環境変数 CLOUD_RUN_TASK_INDEX を参照することで、その値を使用することができます。 インデックスを利用することで、タスクごとにデータベースや CSV ファイル内の異なるデータを参照するような処理を実装することが可能です。 また、環境変数 CLOUD_RUN_TASK_ATTEMPT にはタスクの再試行回数が格納され、再試行されるたびに値が 1 増加します。再試行回数に応じた処理を実装する場合にこの値を利用することができます。 制限事項 Cloud Run jobs を使用する際に意識する必要がある制限事項を記載します。 参考： Cloud Run の割り当てと上限 コンピューティングリソース タスクが実行するコンテナインスタンスに対して、割り当てる CPU 数・メモリ量を指定できます。 Cloud Run services 同様、CPU とメモリ量は、一方の値によってもう一方で設定できる値の範囲に制限があります。たとえば、CPU 数が 4 の場合、メモリ量は 2 GiB ~ 16 GiB の範囲で設定する必要があります。 項目 設定値 CPU 数 1・2・4・6・8 メモリ量 512 Mib・1 GiB・2 GiB・4 GiB・8 GiB・15 GiB・32 GiB （カスタム設定として 512 Gib ~ 34 GiB の範囲で設定することも可能） タスクの実行数と並列実行数 タスクは最大 10,000 個まで実行することができます。またタスクの並列で実行数の最大値は、ジョブを作成したリージョンと、コンテナインスタンスに割り当てた CPU 数・メモリ量に依存します。 リソースを多く持つリージョンではより多くのタスクを並列実行することができ、また CPU とメモリを多く割り当てる場合は、タスクの最大並列実行数が減少します。 デフォルトの設定では、可能な限り多くのタスクを並列実行するようになっています。 Cloud Run におけるコンテナインスタンスの最大実行数は、プロジェクト・リージョンごとに上限値が設定されており、Cloud Run jobs タスクで実行されるコンテナインスタンスと Cloud Run services で実行されるコンテナインスタンスは上限値を共有しているため、同じプロジェクト・リージョンで利用する場合は注意が必要です。 参考 : Cloud Run の割り当てと上限（公式ドキュメント） 参考 : プロジェクト・リージョンごとのコンテナインスタンス上限値（Google Cloud コンソール） タスクのタイムアウト タスクのタイムアウト（最長実行時間）は、デフォルトで10分間です。タイムアウトは秒単位で調整することができ、最長で 168時間 （7日間）に変更することが可能です。ただし、GPU を使用するタスクの場合、最長1時間です。 ジョブ設定で最大再試行回数が1以上に設定されている場合、タイムアウトは各試行回に適用されます。 なお、ジョブの実行中は、メンテナンスイベントにより、タスクを実行しているインスタンスが別のインスタンスに移行する可能性があります。メンテナンスは透過的に行われ、インスタンスの移行によってタスクの状態が失われることはありませんが、移行中は処理が短時間停止する可能性があります。 参考 : ジョブのタスク タイムアウトを設定する タスクの最大再試行回数 タスクの実行が失敗すると、設定した最大再試行回数だけ再試行されます。最大再試行回数のデフォルトは 3 回であり、0 ~ 10 の範囲で設定することが可能です。 参考 : ジョブの最大再試行回数を設定する VPC リソースとの接続 Cloud Run services 同様、Cloud SQL や Memorystore といった VPC に紐づくリソースに対してプライベートネットワーク経由で接続したい場合、 サーバーレス VPC アクセス または Direct VPC Egress を使用します。 参考 : VPC とコネクタ 参考 : VPC ネットワークによるダイレクト VPC 下り（外向き） サーバーレス VPC アクセス と Direct VPC Egress については、以下の記事でも解説しています。 blog.g-gen.co.jp 料金 Cloud Run jobs の料金体系は、実行時間とその間に割り当てた CPU、メモリ量に応じた従量課金です。Cloud Run jobs では処理を行っているときだけ料金が発生します。 us-central1 リージョンでの実行に限り、毎月の無料枠も用意されています。 参考 : Cloud Run の料金 - ジョブ Cloud Run jobs の料金単価は、Cloud Run services の インスタンスベースの課金 と同じ料金単価になっています。 参考 : Cloud Runを徹底解説！ - G-gen Tech Blog - インスタンスベースの課金 Batch との違い Batch とは Google Cloud 上でバッチ処理を行う場合のその他の選択肢として、 Batch が挙げられます。 参考 : Batch を使ってみる Batch は、マネージドな Compute Engine 仮想マシンを使用して大規模なバッチワークロードを実行できるプロダクトです。バッチジョブ作成時に記述したスクリプトをそのまま実行できるほか、Cloud Run jobs 同様、コンテナイメージを仮想マシンにデプロイして処理を行うこともできます。 以下の記事に Batch の概要、および Cloud Run jobs や Cloud Run functions との比較について記載があります。 blog.g-gen.co.jp Cloud Run jobs を使用するケース ジョブの実行時間が168時間（7日間）以内 負荷の軽いジョブを安価に実行する 処理をコンテナ化している、またはコンテナの可搬性を利用したい Cloud Run jobs ではコンテナ化した処理を簡単に繰り返し実行できるため、実装の容易さや、プラットフォーム間の可搬性が利点です。 Batch と比較すると使用できるコンピュートリソースの上限は低くなっていますが、月ごとの無料枠を上手く利用することで、負荷の軽いジョブであればかなり安価に実行することができます。 Batch を使用するケース ジョブの実行時間が168時間（7日間）以上 CPU、メモリを多く使用するジョブを実行する オンプレミスや Compute Engine 仮想マシン上で実行していたバッチスクリプトを移行する Batch ではジョブの実行時間に制限がないため、長時間のバッチ処理で利用します。また Compute Engine 仮想マシン上でジョブが実行されるため、Cloud Run jobs と比較して、より多くのコンピュートリソースを割り当てることができます。 さらに、Cloud Run jobs ではジョブをコンテナ化する必要があるのに対して、Batch ではスクリプトをそのまま使用できるため、少ない手間でバッチスクリプトをサーバーレスの実行基盤に移行することができます。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-gen の堂原です。 当記事では、 Terraform を用いて Google Cloud (旧称 GCP) の Identity and Access Management (IAM) を管理する際に、注意すべき点について紹介します。 はじめに google_xxx_iam の使い分け google_project_iam_xxx の使い分けと注意点 google_project_iam_policy google_project_iam_binding google_project_iam_member はじめに 改めて、当記事では Terraform を用いて Google Cloud の IAM を管理する際に注意すべき点として、 具体的には google_project_iam_policy 、 google_project_iam_binding 及び google_project_iam_member の使い分けについて紹介します。 これらは Terraform 公式の Google Cloud 用の Provider に存在するリソースとなります。 Terraform については以下の記事で紹介しています。 blog.g-gen.co.jp google_xxx_iam の使い分け 本題に入る前に、Google Cloud 用の Provider に存在する、以下の google_xxx_iam という名称のリソースの使い分けについて紹介します。 google_organization_iam google_folder_iam google_project_iam google_service_account_iam 正確には、これらの後ろに「_policy」や「_binding」、「_member」をくっつけた、 google_organization_iam_policy などがリソースとなります。 これらのリソースは、 google_xxx_iam の xxx を操作する 権限（ロール）について管理するものとなります。 例えばサービスアカウントを作成するためのリソースである google_service_account で作成したサービスアカウントに、 プロジェクトの権限を与えたい 場合は、 googe_service_account_iam ではなく google_project_iam を用いる ことになります。 当記事では、以降は google_project_iam についてのみ記載しますが、考え方はすべて同じとなります。 google_project_iam_xxx の使い分けと注意点 改めて、以下の 3 つの使い分けと使用時の注意点について紹介します。 google_project_iam_policy google_project_iam_binding google_project_iam_member そのために、以下のような表を用います。 サンプルのロール割当 例えばユーザ A には role/browser 、 role/run.admin 及び role/storage.admin が付与されているといった見方となります。 この状態で、それぞれのリソースを使ってサービスアカウント β に role/storage.admin を付与する場合について確認していきます。 google_project_iam_policy google_project_iam_policy は指定したプロジェクトの すべてのプリンシパル （ユーザおよびサービスアカウント）の すべてのロール を一括で管理するリソースとなります。 以下のようなリソースをデプロイするとします。 resource "google_project_iam_policy" "test" { project = "プロジェクトのID" policy_data = data.google_iam_policy.test.policy_data } data "google_iam_policy" "test" { binding { role = "roles/storage.admin" members = [ "サービスアカウントβ" ] } } この場合、影響範囲は以下の図の赤枠となります。 google_project_iam_policy の影響範囲 そのため、デプロイに成功すると、デプロイ後の環境は以下のようになります。 google_project_iam_policy デプロイ後 Terraform でプロジェクトの IAM を一括管理し、外的な変更がない環境であれば 1 つのリソースで完結するので便利ですが、 IAM 権限が別の方法で操作されるような環境であれば大変なことになります。 google_project_iam_binding google_project_iam_binding は指定したプロジェクトの すべてのプリンシパル の 特定のロール を一括で管理するリソースとなります。 以下のようなリソースをデプロイするとします。 resource "google_project_iam_binding" "test" { project = "プロジェクトのID" role = "roles/storage.admin" members = [ "サービスアカウントβ" ] } この場合、影響範囲は以下の図の赤枠となります。 google_project_iam_binding の影響範囲 そのため、デプロイに成功すると、デプロイ後の環境は以下のようになります。 google_project_iam_binding デプロイ後 前述の google_project_iam_policy と、後述する google_project_iam_member の中間のような挙動となります。 こちらも Terraform 以外の方法で IAM 管理をしている場合は競合してしまうため、使用の際は気をつける必要があります。 google_project_iam_member google_project_iam_member は指定したプロジェクトの 特定のプリンシパル の 特定のロール を一括で管理するリソースとなります。 以下のようなリソースをデプロイするとします。 resource "google_project_iam_member" "test" { project = "プロジェクトのID" role = "roles/storage.admin" member = "サービスアカウントβ" } この場合、影響範囲は以下の図の赤枠となります。 google_project_iam_member の影響範囲 そのため、デプロイに成功すると、デプロイ後の環境は以下のようになります。 google_project_iam_member デプロイ後 google_project_iam_member は指定した組合せ以外のロールには影響を与えないため、一番安全なリソースといえます。 ただ、各プリンシバルの各ロールについてリソースを作成する必要があるため、規模が大きいと多くのリソースを作成する必要があります。 堂原 竜希 (記事一覧) クラウドソリューション部。2023年4月より、G-genにジョイン。 Google Cloud Partner Top Engineer 2023に選出。休みの日はだいたいゲームをしているか、時々自転車で遠出をしています。 Follow @matayuuuu

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 みずほリサーチ&テクノロジーズ株式会社の舘山です。 当記事では Google Cloud でネットワーク外部接続の予防的統制を実現する方法として、組織ポリシーについて紹介します。 当ブログは G-gen × みずほRT によるコラボ記事です はじめに 当記事の観点 関連記事 外部接続の全体像 外部接続の制限に関する組織ポリシー はじめに 当記事の観点 当記事では、組織ポリシーを利用した Google Cloudネットワーク外部接続の予防的統制について紹介します。 ここでいう外部接続とは、インターネットとの接続のほかに、オンプレミスとの接続や Google Cloud 以外のクラウド環境との接続を含みます。自社の資産を安全に管理するために、組織ポリシーを利用した Google Cloud ネットワーク外部接続の予防的統制をご利用ください。 関連記事 blog.g-gen.co.jp 外部接続の全体像 統制範囲を理解するため Google Cloud のネットワークレイヤでの外部接続の全体像について、図で整理しました。 ネットワークレイヤの外部接続の全体像 外部接続の制限に関する組織ポリシー Google Cloud では組織レベルでリソース構成に制限を設定できる、 組織ポリシー という機能が利用できます。 組織ポリシーの概要については以下の記事をご参照ください。 組織のポリシーを解説 前掲のネットワーク外部接続の多くは、組織ポリシーにより制限することが可能です。 以下の表に外部接続の制限に関する組織ポリシーを整理しました。 サービス固有の機能については全てを網羅できないため、Cloud SQL 等一部のサービスのみの記載に留めています。 各組織ポリシーの詳細は下記のサイトにポリシー名を入力することで確認できます。 利用可能な制約 統制対象 組織ポリシー Cloud VPN VPNピアIPアドレス制限 constraints/compute.restrictVpnPeerIPs Cloud Interconnect Cloud Interconnectを利用できるネットワークの制限 constraints/compute.restrictDedicatedInterconnectUsage constraints/compute.restrictPartnerInterconnectUsage Cloud Shell 組織ポリシーではなく、 Cloud IdentityでCloud Shellを無効化する VPC ピアリング ピアリング先組織制限 constraints/compute.restrictVpcPeering Google管理VPCとのピアリングは許可したい場合、Google組織(433637338589)を許可リストへ追加する Private Service Connect 作成できるエンドポイントの制限 constraints/compute.disablePrivateServiceConnectCreationForConsumers サービスの公開を制限する組織ポリシーはない VMへのパブリックIPアドレス付与 （IPv4）パブリックIPアドレスを付与できるインスタンスの制限 constraints/compute.vmExternalIpAccess （IPv6）VPC の外部 IPv6 利用の制限 constraints/compute.disableVpcExternalIpv6 VMへのシリアルコンソール接続 シリアルコンソール接続の制限 constraints/compute.disableSerialPortAccess 外部ロードバランサー 作成できるロードバランサタイプの制限 constraints/compute.restrictLoadBalancerCreationForTypes 外部ロードバランサのみ利用制限する場合、INTERNALなロードバランサは許可設定する 外部プロトコル転送ルール 作成できる転送ルールタイプの制限 constraints/compute.restrictProtocolForwardingCreationForType 外部転送ルールのみ利用制限する場合、INTERNALな転送ルールは許可設定する Cloud NAT Cloud NATを利用できるサブネット制限 constraints/compute.restrictCloudNATUsage Cloud SQLインスタンスへのパブリックIPアドレス付与 パブリックIPアドレスを付与できるインスタンスの制限 constraints/sql.restrictPublicIp Cloud Functions内向きルール 許可される内向きルールの制限 constraints/cloudfunctions.allowedIngressSettings 内部通信のみ許可する場合、ALLOW_INTERNAL_ONLYを指定する Cloud Build環境からのインターネット接続 利用できるワーカープールの制限 constraints/Cloudbuild.allowedWorkerPools インターネット接続を制限する場合、パブリックIP無効化したプライベートプールのみ許可する Cloud Functionsからのインターネット接続 サーバレスVPCアクセスの利用必須 constraints/cloudfunctions.requireVPCConnector VPCコネクタの外向き設定の制限 constraints/cloudfunctions.allowedVpcConnectorEgressSettings インターネット接続を制限する場合、サーバレスVPCアクセス利用必須にし、外向き設定の制限はALL_TRAFFICを指定する 組織ポリシー違反の例として、ポリシーで禁止された外部ロードバランサーを作成しようとすると、以下のようなエラーになります。 ロードバランサタイプの組織ポリシー違反 舘山 浩之 みずほリサーチ&テクノロジーズ 先端技術研究部に所属。個人のキャリアではAWSの利用経験が長く、Google Cloudは2022年より利用開始。

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 みずほリサーチ&テクノロジーズ株式会社の舘山です。本日は Amazon Web Services (AWS) 経験者の視点から、ネットワークレイヤでの外部接続について、Google Cloud と AWS の差異について共有します。 当ブログは G-gen × みずほRT によるコラボ記事です はじめに 当記事の観点 関連記事 インターネットGatewayの削除可否 外部HTTPロードバランサーの通信経路 マネージドRDBMS等のパブリックIPアドレス宛通信の経路 FaaS（Lambda/Cloud Functions）のVPC接続 FaaS(Lambda/Cloud Functions)のデプロイに、ユーザーのCode Build/Cloud Build環境が利用されるか 内部ネットワーク経由のAPI呼び出し プライベートリポジトリ経由でのパブリックリポジトリの参照 通信先ドメインのホワイトリストによる通信制御 DNSサービスから外部ネームサーバへのクエリ制限 はじめに 当記事の観点 当記事では、クラウド環境のネットワークレイヤでの外部接続という観点で、Google Cloud と AWS の相違点を紹介します。 ここでいう外部接続とは、インターネットとの接続のほかに、オンプレミスとの接続や他のクラウド環境との接続を含みます。自社の資産を安全に保管するために、クラウド環境の外部接続を適切に制御する必要があります。 関連記事 blog.g-gen.co.jp blog.g-gen.co.jp インターネットGatewayの削除可否 AWS Google Cloud 削除可能 削除不可能 AWSではアカウント払い出し時にインターネットGatewayを削除し、開発者からインターネットGatewy作成権限を剥奪するだけで、外部接続制限が可能なケースが多いです。 外部HTTPロードバランサーの通信経路 AWS Google Cloud ・外部ロードバランサー自体のノードは利用者のVPC内に配置される ・ ルートテーブルにインターネットGatewayへの経路がなければ、開発者が外部ロードバランサを作成できても、インターネットからの通信は不可能 ・ 外部ロードバランサ自体のノードは、VPC外のGoogleフロントエンドに配置される ・利用者のVPCの ルートテーブル上、Ｇoogleフロントエンドとの経路は暗黙的に存在し、削除、上書き不可能 ・ GoogleフロントエンドのIP範囲 は、 内部ロードバランサのヘルスチェックの送信元IP範囲 でもあるため、ファイアウォールルールでアクセス制限をかけると、内部ロードバランサの利用に支障が出る AWSのApplication Load BalancerとGoogle Cloudのリージョン外部HTTPロードバランサーを比較しています。 Googleフロントエンドからの通信をファイアウォールルールで拒否すると、内部ロードバランサのヘルスチェックも疎通不可になります。 Google Cloudでの外部ロードバランサの利用制限はファイアウォールルールではなく、後述する組織ポリシーで実施します（関連記事参照）。 構成図で表すと以下のようになります。 Application Load Balancerへのアクセス経路 リージョン外部HTTPロードバランサーへのアクセス経路 マネージドRDBMS等のパブリックIPアドレス宛通信の経路 AWS Google Cloud ・DBインスタンスのネットワークインタフェースは利用者のVPCに配置される ・インターネットからの通信は、利用者のVPCのインターネットGatewayを経由する ・ ルートテーブルにインターネットGatewayへの経路がなければ、開発者がDBインスタンスにパブリックIPアドレスを付与できても、インターネットからの通信は不可能 ・ DBインスタンスのネットワークインタフェースは利用者のVPCとピアリングされた、Google管理のVPCに配置される ・インターネットからの通信は、利用者のVPCを経由しない AWSのRDSとGoogle CloudのCloud SQLを比較しています。 Cloud SQLインスタンスは利用者のVPCとピアリング接続されたGoogle管理VPCに配置されます。 Google Cloudでのインターネット接続制限は後述する組織ポリシーで実施します（関連記事参照）。 構成図で表すと以下のようになります。 RDS DBインスタンスへのアクセス経路 Cloud SQLインスタンスへのアクセス経路 FaaS（Lambda/Cloud Functions）のVPC接続 AWS Google Cloud ・ 任意のサブネットにLambda関数を紐づけることが可能 ・VPCに紐づいた関数の全通信はVPCを経由する ・ IAM条件でVPCに紐づく関数に限定した権限移譲が可能 ・Google Cloudのコネクタインスタンスに相当するリソースは不要 ・ サーバレスVPCアクセス 専用サブネット上のコネクタインスタンスを経由してVPCへアクセスする ・サーバレスVPCアクセスのデフォルト設定では、パブリックIPアドレス宛通信はVPCを経由しない ・IAM条件ではサーバレスVPCアクセスの利用を強制できない Google Cloudでのインターネット接続統制は後述する組織ポリシーで実施します（関連記事参照）。 Google Cloudでは コネクタインスタンスの稼働料金 を考慮する必要があります。 FaaS(Lambda/Cloud Functions)のデプロイに、ユーザーのCode Build/Cloud Build環境が利用されるか AWS Google Cloud ・ユーザーアカウントのCode Build環境は利用されない ・ ユーザープロジェクトのCloud Build環境が利用される パブリックIPアドレスを無効化 したCloud Build プライベートプール でCloud Functions関数をビルドする場合、依存ライブラリ取得先をArtifact Registry リモートリポジトリ （2023/3/31現在プレビュー）に変更するなどの工夫が必要です。 内部ネットワーク経由のAPI呼び出し AWS Google Cloud ・ VPCエンドポイント を利用する ・エンドポイントはサービス毎に作成する ・外部アカウントへの接続は、 VPCエンドポイントポリシー で制御する ・ 限定公開のGoogleアクセス 、 Private Service Connect を利用する ・外部プロジェクトへの接続は、 VPC Service Controls で制御する VPC Service Controlsはサービス間連携機能による間接的なデータ持ち出しの予防も可能です。 プライベートリポジトリ経由でのパブリックリポジトリの参照 AWS Google Cloud ・ Code Artifact経由で、npmレジストリ、PyPI、Maven Central等にアクセスが可能 ・ ECR プルスルーキャッシュリポジトリ は、Dockerイメージの初回プル時、VPCからインターネット経由で外部リポジトリ（ECR Public、Quay）へアクセスが必要 ・(2023/03/31現在プレビュー) Artifact Registryリモート リポジトリ経由でDocker Hub、Maven Central、npmレジストリ、PyPIへアクセスが可能 VPCエンドポイント/限定公開のGoogleアクセス、Private Service Connectを併用することで、インターネット接続不可のVPCでも間接的にパブリックリポジトリを参照できます。 通信先ドメインのホワイトリストによる通信制御 AWS Google Cloud ・ AWS Network Firewall で、Hostヘッダ、SNI拡張のserver_nameの値をチェックする ・（2023/03現在プレビュー） ファイアウォールポリシーFQDNオブジェクト で、通信の宛先IPアドレスをチェックする 両機能の詳細については、以下のブログ記事を参照してください。 VPC Firewall Policyで使えるFQDN制御オブジェクトなどを解説 AWS Network Firewallはアウトバウンド通信制御のセキュリティ対策にはならない AWS Network Firewallは、悪意ある内部犯やマルウェアがhostヘッダ、SNI拡張のserver_nameの値をホワイトリスのドメインに偽装することで、任意のIPアドレスとの通信が可能な点に注意が必要です。 DNSサービスから外部ネームサーバへのクエリ制限 AWS Google Cloud ・ Route 53 Resolver DNS Firewall を利用する ・ Cloud DNSレスポンスポリシー を利用する 参考サイト： Protecting from DNS exfiltration in GCP DNSの悪用方法については、以下のブログを参照してください。 DNSトンネリング: 攻撃者はDNSをどう悪用するのか Route 53 Resolver DNS Firewallでは、 AWS管理のドメインリスト が提供されています。 Cloud DNSレスポンスポリシーは、googleapis.comなどのドメインを、Private Service ConnectエンドポイントのプライベートIPアドレスに解決するための手段としても利用できます。 参考サイト： 新しい Cloud DNS レスポンス ポリシーで Google API へのアクセスが簡単に 舘山 浩之 みずほリサーチ&テクノロジーズ 先端技術研究部に所属。個人のキャリアではAWSの利用経験が長く、Google Cloudは2022年より利用開始。

こんにちは、G-genで営業をしている石川です。当記事では、Google Cloud(旧称 GCP)のノーコードツールである AppSheet でアプリを作ってみた！シリーズとして見積承認アプリを作ってみたのでご紹介いたします。 はじめに データの作成 テーブルの作成 アプリの作成 データの修正 「TYPE」「KEY?」「LABEL?」の修正 「SHOW」「EDITABLE?」「REQUIRE?」の修正 Initial valueの設定 「 EDITABLE?」の修正 Actionsの作成 ステータスを承認に変える ステータスを否認に変える Appearanceの設定 Viewsの設定 さいごに はじめに 普段、皆さまの社内では承認フローはどのような仕組みとなっておりますでしょうか？！ チャットで依頼をしたり、別のサービスでワークフローを作成したり、さまざまなケースが分かれるのではないでしょうか。 今回は AppSheet で見積承認をテーマとして、依頼内容の作成から承認者が行う承認機能を追加するところまでを表現してみましたのでご紹介したいと思います。 データの作成 まずはGoogle Sheetsをデータソースとして、2つのデータテーブルを作成していきます。 今回は、「申請内容」と「ユーザー」のそれぞれのシートにカラムとして必要な値を入力していきます。 テーブルの作成 申請内容シート 承認プロセスにおいて申請内容に必要なカラム名を入力します。 ユーザーシート こちらは、アプリ使用者であるユーザー情報として入力します。 アプリの作成 Sheetsのデータが準備できたら、 AppSheet 上でアプリの作成をしていきます。 Sheetsの[拡張機能] → [AppSheet] → [アプリを作成]で進めると、作成したSheetsのデータをもとに AppSheet が立ち上がります。 以下のとおりアプリが立ち上がりました。 しかし、「申請内容」と「ユーザー」２つのシートを作成したはずですが、「ユーザー」シートが反映されておりません。 まずは、「ユーザー」シートを追加したいと思います。 「＋」の Add new data から下図のとおりデータソースを選択します。 今回のデータソースであるGoogle Sheetsから対象のソースを選択します。 対象のシートである「ユーザー」を選択の上、 Add This Table で追加します。 データの修正 データの作成が完了したら、次に取り込んだデータの修正をしていきます。 「TYPE」「KEY?」「LABEL?」の修正 「TYPE」,「KEY?」,「LABEL?」を修正します。 「TYPE」の説明として一部ですが、以下のようなケースで使います。 Dateは日付を選択できるようにする場合。 Enumは複数選択用のリスト化したい場合。 LongTextは複数行の長いテキスト入力の場合(Textは1行のみの入力)。 「KEY?」と「LABEL?」は選択された値が代表のレコードとして、利用するための項目です。 「SHOW」「EDITABLE?」「REQUIRE?」の修正 次に、「SHOW」,「EDITABLE?」,「REQUIRE?」を修正します。 これらの設定はアプリの操作感に影響する項目となります。 SHOW はアプリ上に表示するかどうかを設定する。 EDITABLE? は編集可否を設定する。 REQUIRE? は入力必須項目であるかを設定する。 実際のアプリが完成したイメージをしながら修正していきましょう！ Initial valueの設定 各カラム名の編集画面あるいは、「INITIAL VALUE」から直接修正する事ができます。 今回は、以下のように各カラムを修正しました。 依頼日 = Today() 名前 = useremail() 所属 = [名前].[所属] 上司 = [名前].[上長名] ちなみにカッコ[]をドット(.)で繋ぐ事で先頭のカッコに対して後ろのカッコが Ref という参照関係をもち Initial value (初期値)として自動設定された状態となります。 名前に”いしかわ”を選択するとSheetsで予め設定した上司の名前(すずき)が自動入力されます。 「 EDITABLE?」の修正 上司コメントとステータスには管理者権限がないと編集できない設定を行います。 編集ボタンからUpdate Behaviorの Editable? に表示されたフラスコマークから設定する事ができます。 「Editable?」に以下を入力します。 any(select(ユーザー[管理者],[email]=useremail())) ここまで設定すると、申請を行う画面が作成できました。 Actionsの作成 次に、アプリ上で操作する挙動の設定を行っていきたいと思います。 ステータスを承認に変える New Actionを選択すると以下のようにアクション候補をサジェストしてくれます。 今回は Create a new action for 申請内容 から新規アクションを作成していきます。 下図のようにAction内容を作成しました。 Action Name = ステータス承認 For a record of this table = 申請内容(シート名) Do this = デフォルトのまま Set these colums = ステータス (カラム名)、 承認 (アクション後の表示したいステータス) ステータスを否認に変える 承認があれば当然、否認もあるので承認同様にアクションを作成します。 １つのアクションで承認と否認のアクションは設定できないため、必要な分だけアクションを作成する必要があります。 アクションを設定することで、申請した見積承認に対して承認、否認のアクションを行う事ができるようになりました。 Appearanceの設定 次に、Appearanceの設定ですが、先ほど作成したアクションのアイコンが同じのため、すこし見づらいかと思います。 これだと、否認したつもりが承認を選択してしまうケースも発生するかもしれませんので、視覚的にアイコンのデザインを変更し見やすいインターフェースにしたいと思います。 作成したアクションのAppearanceにあるAction iconで各アクションに対するアイコンの設定ができます。 それぞれのアイコンが変わりました。 Viewsの設定 申請内容のViewの設定をしていきます。 Viewsでは、アプリの操作画面のインターフェースを整えることができます。 ここまでの手順だと下図のように何の申請なのかが不明です。 今の状態だと、申請者である”いしかわ”から申請したのに上司の名前が表示されていますので、わかりやすいリストの表示に変えていきます。 以下のように各項目を修正します。 Group by = 申請者の名前 Primary header = 顧客 Secondary header = 案件種類 Summary column = 依頼日 これらの設定で申請内容がわかりやすくなりました。 さいごに 今回は、見積承認アプリを作成しました。 プログラミング言語は扱えないので、ノーコードで開発できるとノンエンジニアでもワークフローが作成できますね。 今後は AppSheet に関して機能やアプリ作成方法など発信していきます。 石川 励 (記事一覧) ビジネス推進部 2022年6月にG-gen にジョイン。 クラウドに魅力を感じてG-genでGoogle Cloudの普及に努めてます。 最近は子育て奮闘中。

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 みずほリサーチ&テクノロジーズ株式会社の舘山です。当記事では Google Cloud をハイブリッドクラウドとして利用する際の、プライベート IP アドレスの枯渇問題について考えます。また Amazon Web Services (AWS) の仕様と比較することで、さらに理解を深めます。 当ブログは G-gen × みずほRT によるコラボ記事です はじめに VPC で利用可能な IP アドレス範囲 制約事項 他クラウドの例 Google Cloud の場合 サブネットに PUPI を利用する場合の注意点 一般的な注意点 GKE の場合の注意点 専用サブネット・VPC が必要なユースケース 他クラウドの例 Google Cloud の場合 Google 管理 VPC とプライベートサービスアクセス 関連記事 はじめに 当記事では、組織のプライベート IP アドレス在庫枯渇問題への対応を考えます。なおあくまでプライベート IP アドレスの枯渇問題であって、IPv4 の "パブリック IP アドレス" 在庫枯渇問題 とは関係ありません。 VPC をオンプレミスに専用線接続する場合、オンプレミス側と重複しないプライベート IP アドレスを利用する必要があります。 大規模で、歴史が古く、統廃合を繰り返してきた組織においては、組織のネットワーク内でユニークとなることが担保されたプライベート IP アドレス在庫が枯渇しているケースがあります。そのような組織においては、新規システムの VPC にとりあえず /16 (65,536個) のプライベート IP アドレスを払い出すような贅沢は許されません。 また、プライベート IP アドレスとして RFC 1918 範囲だけでなく RFC 6598 範囲 (100.64.0.0/10) やパブリック IP アドレス範囲を利用しているケースがあります。 VPC で利用可能な IP アドレス範囲 制約事項 Google Cloud では RFC6598 範囲と一部を除くパブリック IP アドレス範囲は VPC のプライベート IP アドレスとして利用することが出来ます。ただし後述するように、サービスによっては固有の制約事項がありますので注意が必要です。 参考 : 有効なIPv4範囲 他クラウドの例 Google Cloud の仕様を明確に理解するために他のクラウドの仕様の例を挙げます。Amazon Web Services (AWS) では、大量の IP アドレスが必要なワークロードでは、以下の様な構成が考えられます。 外部との直接通信要否に応じてサブネットを分ける 大量のIPアドレスが必要なリソースは内部利用専用サブネットに配置する 内部利用専用サブネットには、当該システムの通信要件にない範囲からIPアドレスを割り当てる VPC に後から IP アドレス範囲を追加する場合は 最初に利用する IP アドレス範囲による制限事項あり 内部利用専用サブネットの IP アドレス範囲は、共通 VPC およびオンプレミスと経路交換しない VPC 外から内部利用専用サブネットへのインバウンド通信はロードバランサを経由する 内部利用専用サブネットから VPC 外へのアウトバウンド通信は Private NAT Gateway を利用する。 AWSにおける組織のプライベートIPアドレス節約構成例（シングルAZ） なお AWS ブログでは内部利用専用サブネットを利用する、別の構成例が紹介されています。 How to solve Private IP exhaustion with Private NAT Solution Google Cloud の場合 Google Cloud で同様の構成を採用する場合、以下の仕様差異に留意が必要です。 後から追加するサブネットのIPアドレス範囲は、AWSより制限が緩い AWS では RFC 6598 の IP アドレス範囲を利用する VPC に、後から RFC 1918 の IP アドレス範囲を追加できない AWS の Private NAT Gateway に相当するサービスが存在しないため、独自の NAT 構築が必要 ただし Google Kubernetes Engine のユースケースでは IP マスカレードエージェント が利用可能 VPC ピアリングで選択的にルートを設定するには サブネットにプライベートで使用されるパブリック IPv4 アドレス（PUPI）の利用が必要 専用サブネット・VPC が必要なユースケースの存在 サブネットに PUPI を利用する場合の注意点 一般的な注意点 各サービス毎に PUPI (Privately Used Public IP) の利用に関して固有の制限事項があります。以下は例です。 Memorystore インスタンスがプライベート サービス アクセス接続モードを使用している場合、 PUPI 範囲のクライアントは Memorystore インスタンスに接続できない Cloud SQL の 承認済ネットワークに PUPI のサブネットは自動追加されない Cloud SQL の Google 管理 VPC へ PUPI のサブネット経路は自動でエクスポートされない なお、各サービスにおける PUPI および RFC 6598 範囲のサポートについては、Google Cloud ガイドの記載が追いついていないケースがあるようですので注意が必要です。 Cloud SQLのガイド プライベート IP を構成する には、 Cloud SQL は、デフォルトでは VPC から RFC 1918 以外のサブネット ルートを学習しません。RFC 1918 以外のルートをエクスポートするには、Cloud SQL へのネットワーク ピアリングを更新する必要があります。 と記載されていますが、実際には RFC 6598 範囲のサブネットであれば経路が自動でエクスポートされます (2023年4月現在)。 多くの場合 RFC 1918 が言及されている箇所では、RFC 6598 の IP アドレス範囲も利用できそうですが、 マネージド Microsoft AD の IP アドレス範囲 など、本当に RFC 1918 範囲しか利用できない場合もあります。 プライベート IP アドレス不足から RFC 6598 範囲、 PUPI を活用せざるを得ない場合、最終的には実機での検証が必要になってきます。 GKE の場合の注意点 多数のIPアドレスが必要となる Googke Kubernetes Engine (GKE) については、Google からもガイドが提供されています。 ​​​​​​ ​GKE における IP アドレス管理の理解 GKE 用にプライベートで使用されるパブリック IP を構成する 専用サブネット・VPC が必要なユースケース 他クラウドの例 Google Cloud サービスでは固有の専用サブネットや VPC が必要になるケースが比較的多いといえます。ここでも、仕様を分かりやすくするために他クラウドの例を挙げます。 例えば AWS では、以下のネットワークインタフェースは全て Amazon EC2 インスタンスと同じサブネットに配置できます。 AWS Lambda 関数から VPC へのアクセスのためのネットワークインタフェース Amazon RDS インスタンスのネットワークインタフェース ロードバランサ (ALB) のネットワークインタフェース VPC エンドポイントのネットワークインタフェース PrivateLink サービス提供用 NLB のネットワークインタフェース EKS のポッドのネットワークインタフェース Google Cloud の場合 Google Cloud で同様の機能を利用するには、通常のサブネットとは別に、専用のIPアドレス、サブネット、VPC が必要になります。 Cloud Functions 関数から VPC へアクセスには サーバレス VPC アクセスコネクタ用サブネット が必要 Cloud SQL インスタンスには 利用者の VPC とピアリングされた Google 管理の VPC が必要 内部 HTTP ロードバランサには プロキシ専用サブネット が必要 Google API 用の Private Service Connect エンドポイントには サブネット範囲外の IP アドレス が必要 Private Service Connect サービス提供には 専用サブネット が必要 GKE のサービス、ポッドには サブネットのセカンダリ IP アドレス範囲 が必要 GoogleCloudのサブネット構成 Google 管理 VPC とプライベートサービスアクセス Google 管理 VPC を利用するサービスについて、同じ Google 管理 VPC を共用できるサービスと、そうでないサービスが存在します。 前者はプライベートサービスアクセスをサポートするサービス群です。 対象サービスの一覧は VPC のガイドを参照してください。 プライベート サービス アクセス サポート対象のサービス 例として、互いにプライベートサービスアクセスをサポートする Cloud Build プライベートプールから Cloud SQL インスタンスにはプライベート IP アドレスで直接通信することが可能です (ただし同じ VPC と関連付けている場合に限る)。 Cloud SQLガイド : Cloud Build から接続する 一方、GKE はプライベートサービスアクセスをサポートしません。GKE 限定公開クラスタのコントロールプレーンは専用の Google 管理 VPC に配置されます。 そのため Cloud Build プライベートプールから GKE の API サーバには、VPC ピアリング推移的アクセス制限により、プライベート IP アドレスで直接通信することはできません。 ２種類のGoogle管理VPC この問題のワークアラウンドは Cloud アーキテクチャセンターの記事を参照してください。 Cloud Build プライベート プールを使用した限定公開 Google Kubernetes Engine クラスタへのアクセス コントローラ アクセス用のネットワーク プロキシを持つ GKE 限定公開クラスタの作成 Cloud Filestore や Cloud Memorystore のように、両方の接続モードを選択できるサービスも存在します。 Memorystoreガイド : ネットワーキング GKE 以外にサービス固有の Google 管理 VPC を利用するサービスの例としてはマネージド Microsoft AD があります。 関連記事 blog.g-gen.co.jp blog.g-gen.co.jp 舘山 浩之 みずほリサーチ&テクノロジーズ 先端技術研究部に所属。個人のキャリアではAWSの利用経験が長く、Google Cloudは2022年より利用開始。

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 みずほリサーチ&テクノロジーズ株式会社の舘山です。当記事では、Google Cloud の専用線サービス Cloud Interconnect においてハブアンドスポーク (Hub-and-Spoke) 構成を取る際の注意点をご紹介します。 当ブログは G-gen × みずほRT によるコラボ記事です ハブアンドスポーク構成の注意点 VPC ピアリンググループに関する上限 VPC ピアリング推移的アクセス制限 関連記事 ハブアンドスポーク構成の注意点 Google Cloud の Cloud Interconnect 接続を複数の VPC で共用する構成には、いくつか選択肢があります。 代表的な選択肢は以下のとおりです。 各VPCにVLANアタッチメント作成 共有VPC VPCピアリングによる ハブアンドスポーク構成 Cloud VPNによる ハブandスポーク構成 上記の一番目の「各VPCにVLANアタッチメント作成」は、「 1つのInterconnect接続に関連付けることができるVLANアタッチメントの最大数が16である 」というハードリミットが存在することから、大規模な組織では採用が難しいはずです。 各方式の比較は割愛しますが、VPC ピアリングによる ハブアンドスポーク構成 を採用する場合の注意点について、続けてご説明します。 VPC ピアリンググループに関する上限 Google Cloud では、VPC ピアリング接続可能な VPC 数の上限の初期値は 25 です（サポートケースで増加をリクエスト可能）。 また VPC ピアリンググループ（起点となる VPC と直接ピアリングされた VPC の集合）単位で VM インスタンス数等の 上限 があります。 VPCピアリングによるハブアンドスポーク構成のクォータ ピアリンググループ単位の上限の消費状況を直接確認できる Cloud Monitoring 指標は提供されていません。 一方、各ネットワーク毎のVM数などは、 Cloud Monitoringの割り当て指標 で確認することができます。 ピアリンググループ単位のVM数などをモニタリングする方法として、 Cloud Monitoring 指標スコープ を利用し、グループを構成するプロジェクトの割り当て指標を合算する方法があります。 VPC ピアリング推移的アクセス制限 Google Cloud の VPC ピアリングには推移的アクセスが不可能であるという 制限事項 があります。 そのため、オンプレミスから2つの VPC ピアリングを経由して、Google 管理 VPC 内の Cloud SQL インスタンス等には直接アクセスするということは不可能です。 推移的アクセスはできない) Cloud SQL だけでなく、 Cloud Build プライベートプール 等も Google 管理 VPC 内からのアクセスとなるため、同様に制限を受けます。 オンプレミスと Google 管理の VPC 間の通信は、踏み台サーバ、プロキシサーバを経由する等の手当が必要です。VPC ピアリングではなく、VPN を利用することも制限回避策となります。 関連記事 blog.g-gen.co.jp blog.g-gen.co.jp 舘山 浩之 みずほリサーチ&テクノロジーズ 先端技術研究部に所属。個人のキャリアではAWSの利用経験が長く、Google Cloudは2022年より利用開始。

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 みずほリサーチ&テクノロジーズ株式会社の舘山です。本日は Amazon Web Services (AWS) 経験者の視点から、オンプレミスとの接続関連で注意が必要な、Google Cloud と AWS の差異について共有します。 当ブログは G-gen × みずほRT によるコラボ記事です はじめに 当記事の観点 関連記事 専用線接続を共有できるVPC数 DNSサービスからオンプレミスへのDNSクエリ転送 マネージドRDBMSのネットワークインタフェース配置先 VPCピアリングにおける選択的ルート設定可否 プライベートIPアドレス用のNAT Gateway 専用IPアドレス・サブネット・VPCが必要なユースケース VPCへのIPアドレス範囲事前割り当て要否 サブネットがゾーンを跨ぐか 内部HTTPロードバランサの負荷分散方式 マネージドRDBMSのフェイルオーバ時のIPアドレス 内部HTTPロードバランサへのアクセス制限 FaaSからのVPCへのアクセス はじめに 当記事の観点 当記事では主にオンプレミスとクラウド環境のネットワーク接続という観点で、Google Cloud と AWS の相違点を紹介します。AWS 経験者が Google Cloud を扱う際に困った部分をピックアップしたため、取り上げる差異の選定にある程度バイアスがかかっている点はご了承ください。 Google Cloud とオンプレミスとの接続の全体像については、以下のブログ記事を参照してください。 Cloud Interconnect の基本を解説！ また、両クラウドのネットワークの全般的な比較については、以下のブログ記事を参照してください。 Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い 関連記事 blog.g-gen.co.jp blog.g-gen.co.jp 専用線接続を共有できるVPC数 AWS Google Cloud ・ Direct Connect接続あたりのVIF：50 ・ Direct Connect Gateway毎のVGW：10 50 * 10 = 500 ・ Trangit Gatewayを併用する構成 パターンもあり ・ VLAN アタッチメント数のハードリミット：16 AWSのDirect Connect Gatewayに相当する機能なし AWSのVPCはリージョンに紐づくが、Google CloudのVPCはリージョンを跨ぐ Google Cloudで16を超えるVPCで専用線接続を共用するには、 共有VPC 又は ハブandスポーク構成 を採用する DNSサービスからオンプレミスへのDNSクエリ転送 AWS Google Cloud 接続元IPアドレスとしてサブネットの任意のプライベートIPアドレスを指定可能 ( Route53 Resolver Outbound Endpoint 利用) 接続元IPアドレスはGoogleが管理するパブリックIPアドレス範囲の 35.199.192.0/19 固定となる （ Cloud DNS転送ゾーン利用 ） Google Cloudの場合、オンプレミスNW側がプライベートIPアドレスとして35.199.192.0/19を受入れ可能か確認が必要 受入れができない場合、VPC内にDNSフォワーダを建てるなどの手当が必要 複数VPCから個別にクエリ転送すると送信元IPアドレスが重複してしまう 対応策として各VPCにDNSフォワーダを建てるか、 DNSピアリングを利用して代表VPCからのみクエリを転送する構成 が必要 マネージドRDBMSのネットワークインタフェース配置先 AWS Google Cloud 利用者のVPC 利用者のVPCとピアリングされたGoogle管理のVPC AWSではAmazon RDS、Google CloudではCloud SQLの仕様 Google Cloudの場合、VPCピアリングの推移的アクセス制限に注意が必要 VPCピアリングにおける選択的ルート設定可否 AWS Google Cloud ・ルートテーブルのピアリング先VPCへのルートは手動で設定する ・ ピアリング先VPC内の一部のIPアドレス範囲に限定したルート設定が可能 原則、ルートテーブルに ピアリング先VPCの全サブネットへのルートが強制的に自動登録される 。例外は プライベートで使用されるパブリック IPv4 アドレス（PUPI） を利用するサブネット 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要 プライベートIPアドレス用のNAT Gateway AWS Google Cloud サービスあり サービスなし （GKEのユースケースでは、 IPマスカレードエージェント が利用可能） 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要 専用IPアドレス・サブネット・VPCが必要なユースケース AWS Google Cloud 比較的少ない 比較的多い Google Cloud では Cloud SQL 等で専用サブネットが必要 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要 VPCへのIPアドレス範囲事前割り当て要否 AWS Google Cloud ・要。VPCのIPアドレス範囲からサブネットのIPアドレス範囲を切り出す ・異なるIPアドレス範囲を利用する場合、 VPCにセカンダリCIDRを割り当てる ・ セカンダリCIDRとして追加できるIPアドレスには制限事項 あり 不要。サブネットへ直接IPアドレス範囲を割り当てる 組織のプライベートIPアドレスを節約するため、内部利用専用のサブネットを構築する場合に注意が必要 サブネットがゾーンを跨ぐか AWS Google Cloud サブネットはAZを跨がない サブネットはゾーンを跨ぐ AWS のサブネットは Availability Zone (AZ) に閉じる Google Cloud のサブネットはゾーンをまたぐ (リージョン単位) 内部HTTPロードバランサの負荷分散方式 AWS Google Cloud DNSラウンドロビン ロードバランサの名前解決の都度、複数のIPアドレスが異なる順番で回答される IPエニーキャスト ロードバランサへは単一のIPアドレスを利用してアクセスする Google Cloudは、IPアドレスの固定が容易 マネージドRDBMSのフェイルオーバ時のIPアドレス AWS Google Cloud フェイルオーバー時IPアドレスが変化する。クライアントの接続先切り替えには、再度の名前解決が必要 フェイルオーバー時、IPアドレスは変化しない AWSではクライアント側のDNSキャッシュに注意が必要 内部HTTPロードバランサへのアクセス制限 AWS Google Cloud ロードバランサへのアクセスをセキュリティグループで制限することが可能 ・ ロードバランサにファイアウォールルールを適用することは不可能 ・2023年1月現在、Cloud Armorで内部HTTPロードバランサを保護することは不可能 Google Cloudでプライベートなアプリへの接続にプライベートIPアドレス制限が必要な場合、アプリ側でX-Forwarded-Forヘッダをチェックする等の実装が必要 FaaSからのVPCへのアクセス AWS Google Cloud 任意のサブネットに関数を紐づけることが可能 Google Cloudのコネクタインスタンスに相当するリソースは不要 サーバレスVPCアクセス 専用サブネット上のコネクタインスタンスを経由してVPCへアクセスする AWSとGoogle Cloudでアーキテクチャが大きく異なる Google Cloudでは コネクタインスタンスの稼働料金 を考慮 舘山 浩之 みずほリサーチ&テクノロジーズ 先端技術研究部に所属。個人のキャリアではAWSの利用経験が長く、Google Cloudは2022年より利用開始。

G-gen の武井です。 当記事では GitHub Actions の Self-hosted runners (セルフホストランナー) を使って Google Cloud (旧称 GCP) 環境に Terraform を実行する方法を紹介します。 GitHub Actions はじめに 実行環境について 概要 ランナーの種類 ランナーの特徴 管理 構成自由度 料金 その他 セルフホストランナーを使った Terraform の実行方法 セルフホストランナー用 VM マシンの準備 セルフホストランナー用 VM マシンのセットアップ 設定用コマンドの取得 設定用コマンドの実行 一般ユーザで実行する場合 root で実行する場合 プロセスの自動起動設定 定義ファイルの作成 ワークフローの実行 はじめに GitHub Actions の概要や実行方法については以下の記事で解説しています。 一読いただくと後述の理解が深まりますで是非ご参照ください。 blog.g-gen.co.jp 実行環境について 概要 GitHub Actions では、ワークフローの実行環境を ランナー と呼びます。 ランナーの種類 ランナーは以下の2種類から選択可能です。 # 種類 特徴 1 GitHub-hosted runners GitHub 側で用意される実行環境。ユーザーによる管理は不要だが条件次第で課金が発生 2 Self-hosted runners ユーザーが用意する実行環境。管理は必要だが利用料金は不要で HW/SW 構成も自由 ランナーの特徴 各ランナーの特徴について整理します。 項目 GitHub-hosted Self-hosted 管理 GitHub が管理 ユーザーが管理 構成自由度 小さい (契約プランに依存) 大きい 料金 パブリックリポジトリ：無料 プライベートリポジトリ：従量課金型 (無料枠あり) 無料 管理 前者の場合、ランナーの管理は GitHub 側で行われますが、後者の場合はユーザー側に責任が生じるため管理に伴う工数やコストが発生します。 参考： GitHub ホステッド ランナーの概要 参考： セルフホステッド ランナーの概要 構成自由度 前者の場合、ハードウェアやソフトウェア仕様の選択は契約プランに依存しますが、後者の場合はありません。ジョブの規模などに応じて柔軟な調整が可能です。 参考： サポートされているランナーとハードウェアリソース 料金 前者の場合、パブリックリポジトリにおけるランナーの利用は無料ですが、プライベートリポジトリにおけるランナーの利用については契約プランに応じた無料の使用時間 (分) とストレージ (サイズ) が各アカウントに付与されます。無料枠を超過した場合に使用時間による従量課金が発生します。 ランナーの使用時間は毎月リセットされますが、ストレージはリセットされません。契約プランごとの無料枠や費用計算、その他詳細は以下をご確認ください。 参考： GitHub Actions の課金について 参考： GitHub 料金計算ツール その他 上記の他にも両者の仕様上の違いがありますので詳細は以下をご確認ください。 参考： セルフホスト ランナーと GitHub ホステッド ランナーの違い セルフホストランナーを使った Terraform の実行方法 では実際にセルフホストランナーを使用して Google Cloud 環境に Terraform を実行する方法をご紹介していきます。 セルフホストランナー用 VM マシンの準備 以下は Terraform から VM マシン ( OS : Debian11 ) と関連リソースをデプロイする場合のソースです。ご利用される場合、リソース名や変数をご自身の環境に合わせて置き換えてください。 # vpc resource "google_compute_network" "runner_vpc" { project = var.terraform_project_id name = "runner-vpc" auto_create_subnetworks = false mtu = 1460 } # subnet resource "google_compute_subnetwork" "runner_subnet" { name = "runner-subnet" ip_cidr_range = "192.168.10.0/24" region = "asia-northeast1" network = google_compute_network.runner_vpc.id project = var.terraform_project_id private_ip_google_access = true log_config { aggregation_interval = "INTERVAL_5_MIN" flow_sampling = 0 . 5 metadata = "EXCLUDE_ALL_METADATA" } } # firewall resource "google_compute_firewall" "allow_ssh { name = " allow-ssh " network = google_compute_network.runner_vpc.name project = var.terraform_project_id priority = "100" direction = " INGRESS " description = " Cloud IAP の SSH 通信を許可 " allow { protocol = "tcp" ports = [ "22" ] } log_config { metadata = "EXCLUDE_ALL_METADATA" } source_ranges = [ "35.235.240.0/20" ] } # compute engine resource "google_compute_instance" "runner" { name = "runner-01" machine_type = "e2-micro" zone = "asia-northeast1-b" project = var.terraform_project_id boot_disk { initialize_params { image = "debian-cloud/debian-11" size = "10" type = "pd-balanced" labels = { instance = "runner-01" } } } network_interface { subnetwork = google_compute_subnetwork.runner_subnet.name subnetwork_project = var.terraform_project_id network_ip = "192.168.10.11" access_config {} } service_account { email = "$ { TERRAFORM_SERVICE_ACCOUNT } " // サービスアカウント scopes = [ "cloud-platform" ] } } 参考： google_compute_instance google_compute_network google_compute_subnetwork google_compute_firewall セルフホストランナー用 VM マシンのセットアップ 設定用コマンドの取得 以下の手順でコマンドを取得します。 GitHub リポジトリ にログイン Settings > Actions > Runners の順に画面を遷移 [New self-hosted runner] をクリック [Runner image] を Linux 、 [Architecture] を x64 に選択、表示されるコマンドを取得 上記手順を実行して表示される設定用コマンド 参考： リポジトリへのセルフホストランナーの追加 設定用コマンドの実行 一般ユーザで実行する場合 先程取得した設定用コマンドを VM マシンにログインして OS 上で実行します。 config.sh の実行コマンドで以下のエラーが表示された場合、エラーメッセージ内の依存関係解消用のコマンド ( sudo ./bin/installdependencies.sh ) を実行した後にリトライしてください。 $ ./config.sh --url https://github.com/{OWNER_NAME}/{REPOSITORY_NAME} --token {VALUE} Libicu's dependencies is missing for Dotnet Core 6.0 Execute sudo ./bin/installdependencies.sh to install any missing Dotnet Core 6.0 dependencies. セルフホストランナーが GitHub に紐付きプロセスが正常に起動すると Connected to GitHub と表示されます。 ランナープロセスが起動した状態 また、GitHub の画面には登録されたセルフホストランナーのマシン名が表示されます。 GitHub 側の画面でも確認可能 root で実行する場合 root にスイッチ ( sudo su - ) した後に先程取得した設定コマンドを実行しても config.sh の実行コマンドがエラーとなります。 以下のように変数 ( RUNNER_ALLOW_RUNASROOT ) を設定しつつコマンドを実行します。その際、依存関係を示すエラーが表示された場合は前述と同じように対応します。 # RUNNER_ALLOW_RUNASROOT="1" ./config.sh --url https://github.com/{OWNER_NAME}/{REPOSITORY_NAME} --token {VALUE} 変数を設定する理由としては、 config.sh を実行したユーザの UID が "0" (root の UID は "0") の場合はプログラムが終了する作りになっているためです。 #!/bin/bash user_id = `id -u` # we want to snapshot the environment of the config user if [ $user_id -eq 0 -a -z " $RUNNER_ALLOW_RUNASROOT " ]; then echo " Must not run with sudo " exit 1 fi プロセスの自動起動設定 取得したコマンドではセルフホストランナーのプロセスを ./run.sh コマンドで手動起動する前提になっています。 プロセスを自動起動させたい場合は以下のリンク先に記載の設定を実行してください。 参考： セルフホストランナーアプリケーションをサービスとして設定する 定義ファイルの作成 セルフホストランナーを使用する場合、15行目に記載のある通りジョブ定義の中で runs-on: self-hosted と指定するだけです。 name : terraform # main ブランチへの Pull request と Merge on : pull_request : branches : - main push : branches : - main # ジョブ (Self-hosted runners で実行) jobs : terraform-workflow : runs-on : self-hosted permissions : id-token : write contents : read pull-requests : write # main.tf のあるディレクトリを指定 strategy : matrix : tf_working_dir : - ./env/yutakei steps : - uses : actions/checkout@v3 name : Checkout id : checkout # https://github.com/marketplace/actions/setup-tfcmt - uses : shmokmt/actions-setup-tfcmt@v2 name : Setup tfcmt # https://github.com/marketplace/actions/setup-github-comment - uses : shmokmt/actions-setup-github-comment@v2 name : Setup github-comment # https://github.com/actions/setup-node # https://github.com/hashicorp/setup-terraform/issues/84 - uses : actions/setup-node@v3 with : node-version : '16' - uses : hashicorp/setup-terraform@v2 name : Setup terraform - name : Terraform fmt id : fmt run : | cd ${{ matrix.tf_working_dir }} terraform fmt -recursive continue-on-error : true - name : Terraform Init id : init run : | cd ${{ matrix.tf_working_dir }} terraform init -upgrade - name : Terraform Validate id : validate run : | cd ${{ matrix.tf_working_dir }} terraform validate # main ブランチへの pull request した際のみ terraform plan を実行 - name : Terraform Plan id : plan if : github.event_name == 'pull_request' run : | cd ${{ matrix.tf_working_dir }} export GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} tfcmt -var target:${{ matrix.tf_working_dir }} plan -- terraform plan --parallelism=50 github-comment hide -condition 'Comment.Body contains "No changes."' continue-on-error : true # terraform status で失敗した際に workflow を停止 - name : Terraform Plan Status id : status if : steps.plan.outcome == 'failure' run : exit 1 # main ブランチへの push した際のみ terraform apply を実行 - name : Terraform Apply id : apply if : github.ref == 'refs/heads/main' && github.event_name == 'push' run : | cd ${{ matrix.tf_working_dir }} export GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }} tfcmt -var target:${{ matrix.tf_working_dir }} apply -- terraform apply -auto-approve -input= false --parallelism=50 ワークフローの実行 定義ファイルに記載のトリガー条件を満たすとセルフホストランナーによってワークフローが実行されます。 所定のブランチに Pull request を実行すると tarraform plan が実行 所定のブランチに Merge を実行すると tarraform apply が実行 Pull request (terraform plan) と Merge (terraform apply) に関するワークフロー セルフホストランナーにて実行されたことがわかる 武井 祐介 (記事一覧) 2022年4月入社 / クラウドソリューション部 / 技術2課所属 趣味はゴルフにロードバイク。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 Google Cloud 認定全冠達成！(2023年6月)

インターネット上でソフトウェアや開発環境などを提供するクラウドサービスは、ユーザーのカスタマイズできる範囲の自由度によって、SaaS、PaaS、IaaSの3種類に分類されます。それぞれのサービスの基本的な情報や、メリットやデメリット、注意点について解説します。 クラウドの基礎知識を身につけ、業務をよりスムーズに進行させるためのヒントにしてください。 クラウドサービスとは クラウドの種類 SaaSとは PaaSとは IaaSとは SaaS・PaaS・IaaSのメリット SaaSのメリット PaaSのメリット IaaSのメリット SaaS・PaaS・IaaSのデメリット SaaSのデメリット PaaSのデメリット IaaSのデメリット クラウドサービスを使う注意点 情報消失のリスクに備える 信頼できるサービスを選ぶ セキュリティファーストな施策 まとめ クラウドサービスとは クラウドサービスとは、サーバーやネットワーク、ソフトウェアなどの IT リソースを、ネットワークを経由して利用できるサービスのことです。これらは従来であれば、企業が独自に構築し、所有する必要があったものです。 総務省の「令和3年版 情報通信白書」によると、2020年の段階でクラウドサービスを利用している企業は約7割にのぼります。ほとんどの企業が、なんらかの形でクラウドサービスを利用していることが分かります。 ※参考： 令和3年版 情報通信白書｜総務省 クラウドサービスは大まかに、SaaS、PaaS、IaaS の3種類に分類することができます。この3種類は、クラウド提供事業者がどのレイヤまでを提供しているかによって分類されます。 クラウドの種類 SaaSとは SaaS (サース : Software as a Service) は「サービスとしてのソフトウェア」を意味する言葉です。ネットワーク経由でソフトウェアを提供するもので、SNSや電子メール、ブログサービス、顧客管理ツール (CRM) などのなじみ深いツールがSaaS形式で提供されています。多くの場合で、Webブラウザを通して利用します。 システム基盤を意識する必要がないことに加え、従来であれば必要であったソフトウェアの購入やインストールといった手間も不要です。必要とするサービスを手軽かつスピーディに利用できます。 PaaSとは PaaS (パース・パーズ : Platform as a Service) は「サービスとしてのプラットフォーム」を意味します。ネットワークを経由してサーバーやOS、ミドルウェアなどを提供するサービスで、主にアプリケーションの動作基盤として利用されます。 従来、アプリケーションを開発・公開するためには、サーバーを物理的にセットアップし、ミドルウェアをインストールしたりバックアップを設定するなどシステム基盤の領域にも取り組む必要がありました。PaaSではこれらが予めサービスとして提供されているため、ユーザーはアプリケーション開発に集中することができます。またアプリケーション公開後も、基盤運用が不要である点も魅力です。 IaaSとは IaaS (イアース・アイアース : Infrastructure as a Service) とは「サービスとしてのインフラ」を意味する言葉です。コンピューターの基礎である、インフラ（ネットワークやサーバー、ストレージ、CPUなど）を提供します。IaaSは高いカスタマイズ性を持つため、企業の情報システム全体のIT基盤を構築する際に利用されることが多くなっています。 ハードウェアを自社で所有する必要がなく、多くの場合で利用時間に応じた従量課金のため、柔軟にリソースを増減することが可能です。また自社ネットワークとIaaSを専用線やインターネットVPNで接続して組み合わせて利用する「ハイブリッドクラウド」も一般的です。 SaaS・PaaS・IaaSのメリット SaaSのメリット SaaSのメリットは、導入コストが低いことです。また、サービスを提供している事業者が運用と保守の大部分を担うため、管理コストを抑えることができます。 また従来のソフトウェアを利用する場合は、多くの場合で利用者の端末にソフトウェアをインストールしたり、また自社ネットワークに配置したサーバーへの接続性を確保する必要がありました。これに対してSaaSは、インターネットに接続でき、Webブラウザを備えたPC環境であれば、どこからでもサービスを利用できます。 PaaSのメリット PaaSも同様に、初期コストや運用コストが抑えられます。自社で専用のアプリケーションを開発したい場合に、インフラの各種非機能要件の実現をサービス側に任せられるのがメリットです。 また、導入後はすぐにアプリケーションの開発に取り組めるため、開発にかかる時間を大幅に短縮できます。開発後に基盤のスペックを増減させることも容易なため、無駄な費用が発生せず、ビジネスの規模にフィットした環境を用意できます。 IaaSのメリット IaaSでは、自社でITリソースを所有し管理や運用をするオンプレミスに匹敵するほどの、自由度の高いIT基盤環境を構築できます。一方でオンプレミスとは異なり、物理機器のメンテナンスや障害対応の必要はなくなります。 またオンプレミスの場合、将来の業務規模拡大を予め見越したスペックのサーバーやストレージを購入する必要がありました。一方で従量課金制のIaaSは、現時点で必要な容量だけを利用でき、あとから容易に拡張することができます。 SaaS・PaaS・IaaSのデメリット SaaSのデメリット SaaSで利用できるソフトウェアは事業者によって構築されているため、企業独自の事業形態などに合わせたカスタマイズや外部のソフトウェアとの連携は難しいこともあります。 また、ソフトウェアをオンプレミスで所有する場合と異なり、サービスのメンテナンスの時間は事業者によって決められてしまいます。 PaaSのデメリット PaaSでは、アプリケーションの開発に必要なサーバー、OS、ハードウェアといった開発環境がパッケージで提供されます。このため、開発に利用する言語やデータベースの種類などについては、提供されている選択肢の中から選ぶ必要があります。事業やアプリケーションの種類によっては、意図した内容での開発が難しい場合もあります。サービスの仕様によりアーキテクチャが限定されるため、事前によく確認しましょう。 IaaSのデメリット IaaSはオンプレミスに匹敵する高い自由度を持ちます。このため、OSやミドルウェア、アプリケーションについては、インストールから管理まで、全てユーザー側が対応しなければならない点がデメリットとしてあげられます。 利用するにはオンプレミスと変わらない専門知識が要求されるため、IaaSの導入には事前にインフラ担当要員の確保が必要です。 クラウドサービスを使う注意点 情報消失のリスクに備える クラウドであってもオンプレミスと同様に、システムの物理障害や論理障害が原因でデータが消失する可能性があります。このため、導入前に必ず、サービス事業者が用意しているバックアップ機能の内容を確認し、自社の情報を保護する方法を把握し、適切な設定を実施しましょう。必要によっては、オプションサービスなどを利用することも検討します。 また、BCP計画を適切に策定し、災害などの際にも事業が継続できる体制を整えることも重要です。 信頼できるサービスを選ぶ クラウドサービス導入時には、利用したいサービスの事業者がどのように災害や障害、不正アクセスなどの対策をとっているのか確認しましょう。 信頼性の目安となるのが、各クラウドサービスが取得している第3者機関からの認証規格です。代表的なものに、情報セキュリティマネジメントに関する国際規格である「ISO27001」やクラウドセキュリティに関する国際規格「ISO27017」などがあります。 セキュリティファーストな施策 情報漏洩や消失のリスクを最大限に減らすための施策を練りましょう。事業者が提供しているセキュリティ機能について確認し、自社の情報データが適切に保護されているか常に点検をします。 また、従業員が利用するツールが変わる場合、従業員にも改めてセキュリティ教育を施しましょう。 まとめ クラウドサービスはサーバーやネットワーク、OS、ソフトウェアなどをネットワーク経由で利用できるようにするものです。提供されるレイヤに応じて、SaaS・PaaS・IaaSの3種類に分けられます。自社でITインフラを構築・所有するよりもスピーディに導入でき、運用コストも抑えられるメリットを持ちます。 一方で、導入時には、サービスのセキュリティの信頼性やサポートの範囲などを把握しておく必要があります。業務をよりいっそう効率化させるためにも、自社に合ったクラウドサービスの導入を検討しましょう。 クラウドサービス導入の際は、G-genが運用代行・伴走をお手伝いします。新規・既存どちらのGoogle Cloud環境についても、お客様の環境に合ったハイブリッドクラウド・マルチクラウドを実現し、豊富な実績にもとづく技術サポートを安価な利用環境とセットで提供いたします。 お問い合わせはこちら G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、2021年よりクラウドの導入から最適化までを支援しているGoogle Cloud専業のクラウドインテグレーターです。

はじめまして！G-gen の営業の守﨑です。今回はノーコード開発ツールである AppSheet にて簡単なアプリ作成にチャレンジしたのでその作成過程をまとめてみました。 はじめに データソースの作成 アプリの立ち上げ データ定義 テーブルの定義 カラム (列) の定義 UX の設定 UX 画面へ遷移 View の設定 動作確認 さいごに はじめに 営業の仕事の中で日頃から「お客様との約束不履行や社内処理漏れを防ぎたい」「効率よく業務を進めていく為にタスクを簡単に整理するアプリがあれば便利だな」と思っていました。 プログラムの知識もなく AppSheet を初めて触る営業マンでも作成できるものは何か？と考え、今回は「To Doリスト」というアプリを作成してみました。PCやスマホの画面で発生したタスクをその場で簡単に入力でき、タスクの一覧を簡単に画面上でアイチェックできるアプリになりました。 データソースの作成 今回は Google Sheets のスプレットシートをデータソースとします。 まず新規スプレッドシートを作成し、カラム (列) の名称を入力します。 このとき、1行目をカラム名として、その下にデータを予め入れておいても構いません。 アプリの立ち上げ 次にメニュー「拡張機能」→「AppSheet」→「アプリを作成」を選びます。 下記のような画面が立ち上がります。 データ定義 テーブルの定義 ここからは、AppSheet のアプリケーションの側からのデータ定義を設定していきます。 左部メニューから Data を選択します。まずは Table name (テーブル名) と Are updates allowed? (テーブルにどの操作を許可するか) を設定します。 今回は下記のように Table name を「To Do リスト」とし、 Are updates allowed? を Updates Adds Deletes と設定しました。 カラム (列) の定義 次にテーブルの列を定義していきます。画面上部の Columns を選びます。 先程定義したテーブル名「To Doリスト」が表示されているので、こちらをクリックします。下記のような設定項目画面がでてきますので必要に応じて TYPE 、 KEY？ 、 LABEL？ 、 FORMULA などの設定をします。それぞれ、列の型 (数字か、文字か...等) や主キーとなる値か、を意味していますが、今回は詳細な説明は省略いたします。 今回は以下のように設定しました。 UX の設定 UX 画面へ遷移 次は UX の設定をおこなっていきます。UX とは User Experience (ユーザー体験) の略語であり、AppSheet においてはユーザーに見える操作画面の設定を意味しています。 左部メニューの UX を選択します。 View の設定 View の設定画面に切り替わったので ViewType と Position を設定します。今回は ViewType は「Card」を、 Position は「middle」を選択しました。これにより実際の操作画面では、タスク一覧がカード形式で表示されるようになります。 ViewType を「Card」に決めたので次にそのレイアウトを設定します。今回のレイアウトは「list」を選択します。 最後に表示名とアイコンを設定します。 動作確認 これだけの操作で、アプリが完成しました。 画面の右部分では実際のアプリの動作を確認することができます。 　　　 　　　 さいごに AppSheet 初心者でも、スプレットシートをデータソースとすることで、驚くほど簡単にアプリケーションを作成することができました。 アプリの構築作業も、 Data と UX のわずか2項目を操作するだけである程度作成できてしまうので、エンジニアでなくても利用できるとても便利なツールであると感じました。今回は初めて AppSheet を触るため極々簡単なアプリを作成しましたが、今後は様々なアプリ作成にチャレンジし、ちょっとした業務改善に繋がるアプリを紹介していければと思います！！ 守﨑 亮太 (記事一覧) ビジネス推進部 2022年7月にG-gen にジョイン。 日々G-genの新規顧客開拓に奮闘中。趣味はランニング、走っているときにふと仕事のアイデアが思いつく事も！

G-gen の藤岡です。GCE（Windows Server）から Filestore をマウントしようとしたところ、 Network Error - 53 のエラーが出力されマウントに失敗する事象が起きました。原因と対策を紹介します。 事象 調査 原因 対処 参考 事象 以下の構成において、Filestore を instance-1 からマウントしようとするとエラーとなり、マウントに失敗。instance-2 からはマウントが可能（OS は共に Windows Server）。 構成図 # instance-1 でマウント時のエラー C:\Users\fujioka>mount -o mtype=hard 192.168.0.2:/vol1 z: Network Error - 53 Type 'NET HELPMSG 53' for more information. C:\Users\fujioka> 調査 GCE で ドキュメント に記載の NFS インストールやユーザー ID の構成済み Cloud Logging へエラーログはない ファイアウォールは問題ない Filestore（ 192.168.0.2 ）へ 2049/tcp の疎通は instance-1 は不可、instance-2 は可 # instance-1 の結果 PS C:\Users\fujioka> ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : asia-northeast1-b.c.xxxx.internal Link-local IPv6 Address . . . . . : xxxx IPv4 Address. . . . . . . . . . . : 100.0.0.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 100.0.0.1 PS C:\Users\fujioka> PS C:\Users\fujioka> Test-NetConnection 192.168.0.2 -Port 2049 WARNING: TCP connect to (192.168.0.2 : 2049) failed WARNING: Ping to 192.168.0.2 failed with status: TimedOut ComputerName : 192.168.0.2 RemoteAddress : 192.168.0.2 RemotePort : 2049 InterfaceAlias : Ethernet SourceAddress : 100.0.0.2 PingSucceeded : False PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : False PS C:\Users\fujioka> # instance-2 の結果 PS C:\Windows\system32> ipconfig Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : asia-northeast1-b.c.xxxx.internal Link-local IPv6 Address . . . . . : xxxx IPv4 Address. . . . . . . . . . . : 10.0.0.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.0.0.1 PS C:\Windows\system32> PS C:\Windows\system32> Test-NetConnection 192.168.0.2 -Port 2049 ComputerName : 192.168.0.2 RemoteAddress : 192.168.0.2 RemotePort : 2049 InterfaceAlias : Ethernet SourceAddress : 10.0.0.2 TcpTestSucceeded : True PS C:\Windows\system32> 原因 クライアントが RFC 1918 （ 10.0.0.0/8 / 172.16.0.0/12 / 192.168.0.0/16 ）以外のサブネット範囲の場合、Filestore のアクセス制御は、 IP ベースのアクセス制御 を使用しなければなりません。 コンソールから Filestore を作成する際、アクセス制御は、以下の 2 つから選択できます。 VPC ネットワーク上のすべてのクライアントにアクセス権を付与する IP アドレスまたは IP アドレス範囲でアクセスを制限する アクセス制御 ここで VPC ネットワーク上のすべてのクライアントにアクセス権を付与する を選択すると、クライアント側の IP アドレスが RFC 1918 範囲外の場合、マウントができません。 Filestore はサービスプロデューサーのネットワークと呼ばれる Google が管理する専用ネットワークに配置されます。サービスプロデューサーのネットワークにおいて、RFC 1918 範囲外のようなパブリック IP アドレスから無制限にアクセスを許可することはセキュリティ上のリスクとなります。 そのため、ユーザーが管理する VPC からの接続であっても RFC 1918 範囲外の IP アドレスの場合は、明示的に許可する IP アドレスを指定する仕様となっています。これは、 Cloud SQL や GKE の承認済みネットワークと同様です。 参考： RFC 1918 以外の範囲のクライアント 対処 Filestore の編集で IP アドレスまたは IP アドレス範囲でアクセスを制限する を選択し、クライアントの IP アドレス範囲を許可します。 アクセス制御 追加した IP アドレス範囲のクライアントのアクセスレベルは、管理者・管理閲覧者・編集者・閲覧者があります。各アクセスレベルの詳細は ドキュメント をご参照ください。 追加すると、instance-1 で Filestore がマウントができるようになります。 C:\Users\fujioka>mount -o mtype=hard 192.168.0.2:/vol1 z: z: is now successfully connected to 192.168.0.2:/vol1 The command completed successfully. C:\Users\fujioka> 参考 GCE（Windows Server）から Filestore のマウント方法については以下の記事をご参照ください。 blog.g-gen.co.jp 藤岡 里美 (記事一覧) クラウドソリューション部 接客業からエンジニアへ。2022年9月 G-gen にジョイン。Google Cloud 認定資格は全冠。2023 夏アニメのオススメは、ダークギャザリング。箏を習っています :) Follow @fujioka57621469

G-genの杉村です。Google Cloud（旧称 GCP）のフルマネージドなデータウェアハウスサービスである BigQuery の料金体系である BigQuery Editions について解説します。 概要 BigQuery の課金体系 BigQuery Editions とは 過去の経緯 3つのエディション 概要 クエリがプロジェクトをまたぐ場合 BigQuery Autoscaler BigQuery Autoscaler とは Baseline と Max コミットメント（長期契約） 2つの割引制度 キャパシティコミットメント 費用ベースの CUD 選び方 いつ Editions を使うべきか オンデマンド課金が適しているケース BigQuery Editions が適しているケース ケーススタディ ケース ① ケース ② ケース ③ ケース ④ サイジングと料金の見積もり サイジングの概要 スモールスタート 料金の基本的な考え方 スロット見積もりツール 過去実績の確認 予約、割り当て、コミットメント 基本的な概念 予約（Reservation） 割り当て（Assignment） コミットメント（Commitment） 管理プロジェクト アイドルスロット プロジェクト内での予約の使い分け 概要 BigQuery の課金体系 前提知識として、BigQuery の利用料金は以下の2つの合計であることを理解する必要があります。 ストレージ料金（格納したデータサイズに応じた課金） コンピュート料金（コンピュート処理リソースに対する課金） このうち、 2. のコンピュート料金は、Google Cloud プロジェクトごとに「 オンデマンド課金 」と「 BigQuery Editions 」のいずれかから選ぶことができます。デフォルトでは、BigQuery はオンデマンド課金モードに設定されています。 オンデマンド課金は、スキャンしたデータのサイズに応じた課金が発生する料金体系です。課金額が予測しやすい反面、スキャン対象のデータサイズに比例してリニアに（直線的に）料金が高額になります。 当記事では、もう一方の BigQuery Editions を解説します。 参考 : ワークロード管理の概要 BigQuery のストレージ料金については、以下の記事も参照してください。 blog.g-gen.co.jp BigQuery Editions とは BigQuery Editions とは、BigQuery の課金モデルの1つです。デフォルトのオンデマンドモードでは、データのスキャン量に応じてコンピュート料金がかかります。一方で、BigQuery Editions を選択すると、 スロット と呼ばれる BigQuery のコンピュートリソース（仮想的な CPU の単位）を確保した量と時間に応じて課金されます。 なお、BigQuery Editions を使ったコンピュート課金方式のことを、オンデマンド課金の対義語として、 容量ベースの課金 （Capacity-based billing）と呼ぶこともあります。 参考 : スロットについて スロットは、 BigQuery Autoscaler によって動的に確保されます。BigQuery Editions はオンデマンド課金と比較すると課金額が予測しづらいものの、利用ボリュームが大きいときや、利用者が多かったり、利用頻度が多いときなどにコストメリットが得られます。 BigQuery Editions には、単価の異なる3つの価格ティアがあります。 Standard 、 Enterprise 、 Enterprise Plus の3つであり、それぞれ料金単価と、利用可能な機能に違いがあります。 また BigQuery Editions では、後述の BigQuery Autoscaler 機能が有効になります。適切に設定すれば、従量課金のメリットを受けることができ、料金の最適化に繋がります。 参考 : BigQuery pricing 参考 : BigQuery エディションの概要 過去の経緯 2023年7月以前は、BigQuery の料金プランは「オンデマンド課金」と、事前に購入したスロットを定額利用する「Flat-rate 課金（定額課金）」の2種類でした。 2023年3月29日の Google Data Cloud & AI Summit において、BigQuery の新しい料金体系である BigQuery Editions が発表され、Flat-rate 課金は廃止されることになりました。また、新しいストレージ課金モデルである Physical storage 課金もこのときに公開されました。 変更は以下のようなタイムラインで行われました。 日付 内容 2023-03-29 ・BigQuery Editions の販売開始 2023-07-05 ・Flat-rate の新規販売の終了 　・Flex slots は Editions に移行 　・Monthly/Annual slots は期間終了すると Editions に移行 ・オンデマンド課金の単価が新料金に変更 参考 : New BigQuery editions: flexibility and predictability for your data cloud 3つのエディション 概要 BigQuery Editions には、単価の異なる3つの価格ティア（ エディション ）があります。 Standard 、 Enterprise 、 Enterprise Plus の3つであり、それぞれ料金単価と、利用可能な機能に違いがあります。 エディションごとの機能差異や料金は以下のとおりです。なお記載の情報は一部抜粋であり、2025年4月現在のものです。最新情報は必ず公式の料金表やドキュメントをご参照ください。 比較項目 Standard Enterprise Enterprise Plus 単価 (US) $0.04/slot/h $0.06/slot/h $0.10/slot/h 単価 (Tokyo) $0.051/slot/h $0.0765/slot/h $0.1275/slot/h 1年/3年コミット × ○ ○ SLA 99.9% 99.99% 99.99% スロット数 最大1,600slots 制限なし 制限なし CMEK × × ○ VPC Service Controls × ○ ○ 動的データマスキング × ○ ○ 列レベルセキュリティ × ○ ○ 行レベルセキュリティ × ○ ○ BI Engine × ○ ○ BigQuery ML × ○ ○ キャッシュ利用 単一ユーザのみ ユーザー間でキャッシュをシェア ユーザー間でキャッシュをシェア エディションごとに単価が違うことと、利用可能な機能に差があることに留意してください。 例として CMEK 暗号化（Customer Managed Encryption Key。Cloud KMS で管理する秘密鍵によるストレージの透過的暗号化）や VPC Service Controls といった重要なセキュリティ機能が、Standard エディションでは使えません。このような機能の制約に着目して、適切なエディションを選択します。 なお BigQuery Editions を利用せずオンデマンド課金で BigQuery を利用すると、概ね Enterprise Plus 相当の機能が利用可能ですが、利用可否は機能により異なりますので、以下の公式ドキュメントを参照してください。 参考 : BigQuery エディションの概要 - BigQuery エディションの機能 クエリがプロジェクトをまたぐ場合 BigQuery では、ある Google Cloud プロジェクトの BigQuery API から、別の Google Cloud プロジェクトの BigQuery テーブルに対するクエリを実行することができます。しかし、 データを持つプロジェクト と クエリする側のプロジェクト で 異なるエディションが使われている場合 はどうなるでしょうか。 以下のようなケースを考えます。 プロジェクト名 内容 Google Cloud プロジェクト A ・BigQuery は Enterprise Plus エディションを設定 ・データセット・テーブルを保有 ・テーブルには CMEK 暗号化や列レベルセキュリティが設定されている Google Cloud プロジェクト B ・BigQuery は Standard エディションを設定 ・データセット・テーブルは存在しない このとき、プロジェクト A のテーブルに対するクエリを、プロジェクト B の BigQuery API に投入すると、エラーになります。プロジェクト B では Standard エディションが設定されており、CMEK 暗号化や列レベルセキュリティはサポートされていないからです。 つまり、 クエリする側のプロジェクト （ジョブを実行するプロジェクト） で、機能をサポートするエディションを選択する 必要があります。 BigQuery Autoscaler BigQuery Autoscaler とは BigQuery Autoscaler は、需要に応じて自動でスロット確保量を増減する機能です。BigQuery Editions では BigQuery Autoscaler が有効化されており、確保するスロット量が自動的に最適化されます。 BigQuery Autoscaler には、以下のような特徴があります。 クエリ（ジョブ）の需要に応じて、スロット数が自動増減 利用したスロット時間（確保した量 × 時間）に対して課金 Baseline（最低確保量）と Max（上限確保量）を設定可能 Baseline を0に設定すると、BigQuery が使われていない時間帯はスロットがゼロになる Max 値を設定することで突発課金を防ぐ スケール幅は50スロットずつ 1秒単位で課金 ただし最低でも60秒分から課金される。60秒経過後は1秒単位での課金になる（billed per second with a one minute minimum） 当機能により、BigQuery Editions をオンデマンド課金と同様に柔軟・効率的に利用できます。 参考 : スロットの自動スケーリングの概要 参考 : BigQuery pricing - Capacity compute pricing Baseline と Max BigQuery Editions 利用時は、Autoscaler の Baseline（最低値）を0スロットに設定することで、クエリが発生していない時間帯はスロット確保がゼロになり、課金が発生しません。また、Max 値を指定することで、想定外の突発課金を防ぐことができます。 ただし制約として、Standard Edition だけは Baseline が必ず 0 になり、任意の Baseline を設定できません。 スロット確保量が Max 値に達した場合は、クエリがエラーになるわけではありません。新しいクエリはスロットが空くまで待たされます。また投入済みのクエリは、スロット確保量の範囲内で時間をかけて（引き伸ばされて）処理が行われます。 夜間や休日を含めて連続的に BigQuery にクエリが発生している環境の場合、BigQuery Editions の1年または3年のコミットメント（後述）を購入して、購入した分のスロット数を Baseline として設定し、Baseline を超える分については Autoscaler で必要なときのみ確保することで、コスト効率よく利用することが可能です。 コミットメント（長期契約） 2つの割引制度 BigQuery Editions は、 コミットメント （長期契約）を購入することで、割引価格で使用することができます。原則的に、一度購入するとキャンセルはできません。 BigQuery Editions で購入可能なコミットメントには2種類あります。 名称 呼び名に関する備考 説明 キャパシティコミットメント （または Resource CUDs あるいは スロットコミットメント ） 公式ガイドだと前者、料金表だと後者で記載。単にコミットメントとも呼称 従来からある基本的な割引制度。1年または3年。Enterprise または Enterprise Plus のみで購入可能 費用ベースの CUD （または BigQuery CUD ） 公式ガイドだと前者、料金表だと後者で記載 2025年4月に新設された割引制度。1年または3年。全 Edition に適用可能なほか Dataplex Universal Catalog など他の SKU にも適用 ※ CUD とは、Commited use discounts のこと（「確約利用割引」とも訳される） 2つの詳細や違いについては後述します。 参考 : BigQuery pricing - Capacity compute pricing 参考 : Workload management using reservations - Slot commitments 参考 : Committed use discounts - BigQuery キャパシティコミットメント キャパシティコミットメント （または Resource CUDs 、あるいは スロットコミットメント ）は、従来からある基本的な BigQuery の割引の仕組みです。単にコミットメントと言う場合、こちらを指すことが多いといえます。 参考 : Workload management using reservations - Slot commitments 1年間または3年間の利用を確約することと引き換えに、割引価格が適用されます。割引率は、後述の費用ベースの CUD よりも大きいものとなっています。 キャパシティコミットメントは、Enterprise または Enterprise Plus のみで購入可能であり、Standard エディションでは購入できません。 キャパシティコミットメントは、コミットメントは50スロット単位で購入できます。スロットを購入すると、その分のスロットは常に確保されます。購入したスロットは 予約 （Reservation）という管理オブジェクトに Baseline として設定し、Google Cloud プロジェクトに割り当てることができます。 スロットは、Baseline として確保されていても、クエリの処理に使われていない間は アイドルスロット の扱いとなり、他の予約（ただし同等エディションのみ）で分け合って使われます。アイドルスロットについては後に詳述します。 また、予約、割り当て、コミットメントといった概念の詳細については、当記事の「予約、割り当て、コミットメント」の項で詳述します。 費用ベースの CUD 費用ベースの CUD は、請求先アカウントに紐づく、BigQuery 用の確約利用割引（Commited use discounts）です。名称としては、公式ガイドだと「費用ベースの CUD（Spend-based CUDs）」と記載されていますが、料金表だと BigQuery CUD と記載されています。2025年4月に新設された割引の仕組みです。 参考 : Committed use discounts - BigQuery 1年間または3年間の利用を確約することと引き換えに、割引価格が適用されます。割引率は、前述のキャパシティコミットメントよりも浅く、1年間コミットの場合は10%、3年間コミットの場合は20%です。 全 Standard、Enterprise、Enterprise Plus の全エディションに適用可能です。またこの CUD は、BigQuery Editions に加えて、以下の SKU にも適用されます。 BigQuery editions Composer 3（別名 BigQuery engine for Apache Airflow） Dataplex Universal Catalog BigQuery services（Earth Engine in BigQuery、Python UDF を指す） Google Cloud Serverless for Apache Spark（旧称 Dataproc Serverless） 費用ベースの CUD の特徴として、 利用料金をコミットする という購入体系になっている点が挙げられます。前述のキャパシティコミットメントが「 使用するリソースの量をコミットする 」というものだったのに対して、費用ベースの CUD は、「いくら利用するか」という金額をコミットし、コミットした金額を毎月取り崩していく形になります。またこの CUD は BigQuery だけのものではなく、前述の複数の Google Cloud サービスにも適用されます。これらのサービスの利用料金が、コミットした CUD から消費されていきます。 費用ベースの CUD は、請求先アカウントごと、またリージョンごとに購入します。特定のプロジェクトに紐づくわけではなく、その請求先アカウントに紐づくプロジェクトの SKU に適用されます。 選び方 ここまで、2つの割引制度を説明しました。それぞれの違いを以下にまとめます。 比較項目 キャパシティコミットメント 費用ベースの CUD 割引率 相対的に高い (安価) 相対的に低い (高価) 適用対象 BigQuery Editions（Enterprise / Enterprise Plus） BigQuery の全 Edition のほか、複数の SKU ひも付き 管理プロジェクトに紐づく（他のプロジェクトにも適用可能） 請求先アカウントに紐づく リージョン 特定のリージョンで購入 同左 Enterprise または Enterprise Plus エディションを使っている場合で、特に BigQuery の高い割引率を得たい場合はキャパシティコミットメントを選択します。 一方で、Standard エディションを使っている場合、あるいは Composer 3 や Dataplex Universal Catalog など他の SKU にも割引を適用したい場合で、金額をまとめてコミットしたい場合などに、費用ベースの CUD が適しています。 いつ Editions を使うべきか オンデマンド課金が適しているケース デフォルトでは、BigQuery はオンデマンド課金モードに設定されています。 オンデマンド課金を使い続けるべきか、BigQuery Editions を選択すべきかの判断はどのようにすべきでしょうか。 無料枠内に収まる場合 オンデマンド課金モードには月あたり 1 TB のデータをスキャンできる無料枠 （Free tier）があります。スキャンのボリュームが 1 TB を超えない場合は、オンデマンド課金で利用することで、コンピュート料金を無料に抑えることができます（ストレージ料金は発生する点に注意してください）。 BigQuery の利用が散発的な場合 BigQuery へのクエリが発生する頻度が少なく、散発的な利用に留まっている場合も、オンデマンド課金で利用するほうが安価になります。Editions では、一度スロットが確保されると、最低課金時間である60秒分の課金が発生してしまいます。 連続的にクエリが発生しない場合は、オンデマンド課金のほうがコスト効率が良いと言えます。 料金を正確に予測したい場合 オンデマンド課金では、データのスキャン量に応じて課金が発生するため、料金が予測しやすい点も重要です。BigQuery の Web コンソールやコマンドラインでは、クエリのドライランにより、事前にデータのスキャン量を確かめることもできます。 セキュリティ機能の PoC 例えば「普段は Standard Edition を使っているが、VPC Service Controls の機能を検証したい」などの場合に、一時的にオンデマンド課金を利用することも考えられます。なぜなら、オンデマンド課金では Enterprise Plus エディションと概ね同等の機能が利用できるためです（キャッシュのユーザー間シェアなど、一部例外はあります）。 VPC Service Controls や動的データマスキングなどのセキュリティ機能を検証する場合、オンデマンド課金は一時的には選択肢には成り得ます。 BigQuery Editions が適しているケース 連続的に BigQuery へクエリが投入される時間帯がある場合 、BigQuery Editions が適している可能性があります。 夜間はバッチジョブが実行され、昼間はダッシュボード参照により継続的にクエリが発行されている場合、データのスキャン量は膨大になります。BigQuery Editions を使えば、スロットを時間ベースの課金で確保できるため、コスト効率が良くなります。 オンデマンド課金で既に BigQuery を利用している場合、後述する スロット見積もりツール を使い、Editions へ移行したあとの料金がどのくらいになるかを確認し、より安くなる可能性があるのであれば、Editions への移行を検討します。 ケーススタディ ケース ① BigQuery に対する夜間バッチ等が少なく、利用が日中帯に集中している場合は、以下のような利用方法になります。 BigQuery Editions + BigQuery Autoscaler を利用 コミット購入なし Baseline を0に設定 安全柵として Max slot を100に設定 設定値は数ヶ月間の Slot 利用実績を確認して調整 Baseline が 0 のため、BigQuery が利用されていない間はコンピュート課金が発生しません。 利用ボリュームが小さいのにも関わらず Max 値に 800 などの高すぎる値を設定すると、ジョブ（クエリ）が散発的な場合、ジョブ実行時間が短くても重い処理だと 800 スロット × 60 秒の最低課金が発生してしまい、これが積み重なって料金が高くなってしまう場合があります。 まずは 100 や 200 などの小さい値から始め、ジョブ実行時間が実業務で耐えうる範囲なのかどうかを確認するのが望ましいでしょう。後述する管理リソースグラフを使い、スロットの利用状況をモニタリングすることができます。 ケース ② 夜間・休日はバッチ処理が BigQuery に対して実行されており、日中帯は従業員の BI ツールやオンデマンドなクエリにより BigQuery が利用されているというケースを想定します。このようなケースでは、1日を通して、また月間を通して BigQuery の利用ボリュームが比較的大きく、ほぼ常時、スロットが使われているとします。 BigQuery Editions + BigQuery Autoscaler を利用 コミットメントを購入し、Baseline 値として設定 常に確保しておくスロット分、コミットメントを購入 リソースグラフを確認して無駄なく使い切れる値に設定する 安全柵として Max 値を設定 設定値は数ヶ月間の Slot 利用実績を確認して調整 利用料金と処理効率のバランスを取って設定 Max 値が高すぎると、クエリが散発的で小さい場合でも60秒分の課金が発生するので注意 ケース ③ 一部の部署のみが BigQuery を利用している。もしくは PoC レベルであり無料枠に収まる可能性が高い場合、オンデマンド課金が適しています。 オンデマンド課金を利用 まだ BigQuery の利用が小規模であり、スキャン量が 1 TB に満たない可能性がほとんどの場合は、無料枠が用意されているオンデマンド課金を利用します。ストレージ容量も、10 GB までは無料です。 ケース ④ 一部の部署のみが BigQuery を利用しており、データアナリストやマーケティング部門による、探索的なクエリが散発的に発生する場合を考えます。このような場合、オンデマンド課金が適しています。 オンデマンド課金を利用 散発的で小さいクエリが主なユースケースの場合、BigQuery Editions を使うと、60秒の最低課金が逆にコスト効率を悪くする場合があります。このようなとき、オンデマンド課金を選択します。 サイジングと料金の見積もり サイジングの概要 BigQuery Editions では 予約 （Reservation）というオブジェクトを作成してプロジェクトに BigQuery Editions を適用します。予約を作成する際、適用するエディション（Standard、Enterprise、Enterprise Plus）と、Autoscaler の Baseline 値と Max 値を指定します。 Baseline 値は、1年または3年のコミットメントを購入していれば、それを使い切るように設定するのが一般的です。 一方の Max 値は、パフォーマンスとコスト（料金）を天秤にかけて決定する必要があります。 コンソール画面では、Max 値はプルダウンメニューで以下のように選択できるようになっています。S、M、L といった名称が付いてはいますが実際には利用環境に応じて適切な値を選択することが望ましいです。 名称 スロット数 Extra Small 50 S 100 M 200 L 400 XL 800 2XL 1,600 3XL 3,200 4XL 4,800 Custom 任意の数値 スモールスタート まずは 50〜200 など小さめのスロット数を Max に設定しで スモールスタート することを検討します。 BigQuery に対するクエリが散発的であるのにも関わらず 800 など大きめのスロット数を Max としてしまうと、以下のようなことが起こります。 比較的重いクエリが1個、投入される そのクエリを処理するために800スロットが確保され、処理が1秒で終わる 処理が1秒で終わっても、スロットの最低課金時間は60秒のため、800 スロット × 60秒の課金が発生 このケースでは、1個のクエリを実行するためだけに800スロット × 60秒の課金が発生することになり、無駄が大きいことがわかります。 一方で同じクエリを処理する場合で Max 値が200の場合、以下のような挙動になります。 先程と同じクエリが投入される 200スロットが確保され、処理が4秒で終わる スロットの最低課金時間は60秒のため200スロット × 60秒の課金が発生 この場合はスロット数が4分の1のため処理時間が4倍掛かっていますが、料金も4分の1です。 ただし、同時間帯に多数のクエリが投入されるような環境であれば、60秒間で確保されたスロットが無駄なく使われることになりますので、どのくらいの頻度・密度でクエリが実行されるかを考慮に入れて、Max 値を検討する必要があります。 料金の基本的な考え方 BigQuery Editions の料金を見積もるには、 （スロット単価）×（スロット時間） を計算します。 スロット単価 はエディションによって異なりますので、料金ページを確認します。どのエディションを選択するかは、前掲の機能表を参考にしてください。 参考 : BigQuery pricing スロット時間 は、 （確保されたスロット量） × （確保された時間） を意味しています。スロット量は、クエリの需要に応じて Baseline から Max の間で確保されます。また、確保時間は、クエリの頻度と処理の重さに依存しますので、予測が難しいものとなります。 例えば、100スロットが6分間（=0.1時間）確保されると、スロット時間は「10スロット時間（10 slot hour）」となります。US リージョンの Enterprise エディションの単価は $0.06 / slot hour ですので、このときかかるコンピュート料金は、$0.06 × 10 = $0.6 となります。 もし既に BigQuery を利用中であれば、後述のスロット見積もりツールで実績ベースの見積もりを確認することができますが、これから初めて BigQuery を使う場合は、見積もりの難易度は高くなります。 オンデマンド課金で PoC を行ってある程度のスロット利用量の目算をつけたり、小さめの Max 値でスモールスタートして利用実績を積み、徐々にスロット数を増やしていくのが望ましいといえます。 スロット見積もりツール BigQuery の Web コンソールには スロット見積もりツール （Slot estimator）が用意されており、既存の BigQuery ユーザーであれば、BigQuery Editions の見積もりに利用できます。 スロット見積もりツールは、過去30日間の利用実績から、パフォーマンスをできるだけ落とさずにコスト最適化するために推奨される Baseline 値や Max 値を表示したり、想定月額費用を表示します。 スロット見積もりツールは、BigQuery コンソールの「容量管理」画面から「スロット見積もりツール」画面へ遷移することで閲覧が可能です。 ただし、あくまで目安であり、コストを優先したい場合は表示されているよりも Max 値を小さくして設定するなど、判断はあくまで運用者がする必要があります。 参考 : スロットの容量要件の見積もり BigQuery slot estimator また BigQuery コンソールでは、費用の最適化に関するレコメンデーション（推奨事項）を表示する Slot Recommender が利用できます。Slot Recommender は過去30日間のスロット使用量に基づいて自動スケーリングの使用量を推定し、推奨される設定値をレコメンドしてくれます。 参考 : エディションのスロットに関する推奨事項を表示する 過去実績の確認 既に BigQuery を利用中の場合、前述の基本的な考え方を踏まえた上で、これまでのクエリのスロット利用実績から Max 値の当たりをつけることもできます。 管理リソースグラフ （administrative resource charts）を使うことで、過去のスロット利用実績を確認可能です。 オンデマンドモードを利用中の場合、セレクタで利用リージョンを選択のうえ、チャートを「オンデマンド料金」「スロットの使用状況」とすることで、過去の特定時間帯の平均スロット利用量を確認できます。これにより、Max 値を例えば 100 に設定した際に、どの時間帯のジョブのパフォーマンスが落ちる可能性があるかを確認することができます。 リソースグラフの例 例えば上記の例だと、あるオンデマンド課金を利用している組織の、99パーセンタイル（全ジョブの中でスロット使用量が上位1%のジョブ）の「平均スロット使用量」を表示しています。スパイク的に 2,000 近くまでスロットが確保されている時間帯がある一方で、ほとんどの時間帯は 100 以下に収まっていることが分かります。 選択した期間中の平均は 9.3 スロットでした。 このような場合、Max 値を例えば「100 スロット」に設定することを検討します。しかし、スパイクしている時間帯のジョブはその分引き伸ばされてしまうことになります。具体的にどんなクエリが影響を受けるかは INFORMATION_SCHEMA.JOBS ビューなどで個別に確認してください。 参考 : 健全性、リソース使用率、ジョブをモニタリングする - BigQuery リソースの使用状況を表示する 予約、割り当て、コミットメント 基本的な概念 BigQuery Editions を利用するには、 予約 （Reservation）、 割り当て （Assignment）、 コミットメント （Commitment）と呼ばれる管理用オブジェクトを作成します。 これらの管理オブジェクトの関係の例を模式図にすると、以下のようになります。 予約、割り当て、コミットメント 予約（Reservation） 予約 （Reservation）は BigQuery Editions の管理オブジェクトです。利用するエディション、Baseline 値、Max 値などの設定値を持っています。 「予約」という名称から、1年間や3年間の利用コミットがされてしまうのではないか、と誤解されがちですが、「予約」は長期コミットメントとは関係がありません。予約と、後述する割り当てを作成して BigQuery Editions を利用開始しても、割り当てを削除することで、Editions の利用をやめて いつでもオンデマンド課金に戻ることができます 。 参考 : 予約を使用したワークロード管理 - スロットの予約 予約は Google Cloud プロジェクト内に作成し、またロケーション（リージョン）ごとに作成します。 割り当て（Assignment） 割り当て （Assignment）は、予約と Google Cloud プロジェクトを紐づけるリレーションです。BigQuery Editions を利用するには、予約を作成した後、割り当てを作成して予約と Google Cloud プロジェクトを紐づけます。 割り当ては Google Cloud プロジェクトに対してだけでなく、組織やフォルダに対して作成することもできます。組織やフォルダに割り当てを作成した場合、予約が配下のプロジェクトに 継承 されます。プロジェクトに割り当てがない場合、継承された親リソースの予約（割り当て）が利用されます。 参考 : 予約を使用したワークロード管理 - 予約の割り当て なお、継承された予約（割り当て）を使用せず、明示的にオンデマンド課金を利用するようにプロジェクトを設定することもできます。 参考 : 予約割り当てを操作する - プロジェクトを none に割り当てる 割り当てを作成するときには、 ジョブタイプ を指定します。プロジェクトに割り当てられた予約は、指定されたジョブタイプのジョブのために使われます。 ジョブタイプ 説明 QUERY SQL や BigQuery ML の組み込みモデルの実行 BACKGROUND 検索インデックス管理、CDC、BigLake メタデータキャッシングなどのバックグランドジョブ (※1) CONTINUOUS 継続的クエリ ML_EXTERNAL BigQuery ML の外部モデルの CREATE MODEL クエリ (※1) PIPELINE LOAD や EXPORT 等 (※2) (※1) Standard エディションの予約は、BACKGROUND と ML_EXTERNAL としては割り当てることができません。 (※2) LOAD や EXPORT 等のジョブは無料ですが、スループットを保証していません。性能を確保したい場合に PIPELINE として割り当てを作成します。 コミットメント（Commitment） コミットメント （Commitment）は1年間また3年間のスロット予約を確約ための仕組みです。コミットメントを作成することで、割引価格でスロットを利用することができます。コミットメントは一度作成すると、解約することはできません。コミットメントや予約はロケーション（リージョン）ごとに作成します。コミットメントで確保されたスロットは、同じロケーションの予約によって利用されます。 コミットメントは、50スロットを最小とし、50スロットの倍数で購入することができます。 また、コミットメントの自動更新を設定することもできます。コミットメントには 更新プラン を「なし（None）」「年間（Annual）」「3年間（Three-Year）」の中から選択でき、コミットメント期限が切れたときの自動更新の挙動を事前に設定できます。「なし」であれば更新はされません。「年間」であれば、1年間のコミットメントとして、「3年間」であれば3年間のコミットメントとして更新されます。 参考 : 予約を使用したワークロード管理 - スロットのコミットメント 管理プロジェクト 予約、割り当て、コミットメントは、Google Cloud プロジェクトの中に作成されます。 Google は、これらのオブジェクトを単一の管理用の Google Cloud プロジェクトに集約して作成することを推奨しています。このプロジェクトを 管理プロジェクト と呼びます。 管理プロジェクトにこれらの管理オブジェクトを集約することで、後述するアイドルスロットを共有できるようになったり、見通しが良くなって管理工数が低減するなどのメリットがあります。 参考 : ワークロード管理の概要 - 組織のワークロードを管理する アイドルスロット コミットメントによって購入されたスロットは、予約の Baseline 値として使用されます。原則的には、Baseline として設定された分のスロットは常時確保されるのですが、クエリが処理されていないときには、スロットは アイドルスロット という扱いになります。 また、コミットメントとして購入されているが、どの予約のベースラインとしても使われていないスロットも、アイドルスロットになります。 アイドルスロットは、他の予約から利用することができます。ただし、エディションやロケーションが同じであること、スロットを共有する予約同士が同じ管理プロジェクトに所属していること、などが条件です。 予約で、設定値 ignore_idle_slots を true に設定することで、他の予約のアイドルスロットを使用しないように明示的に設定することもできます。 参考 : スロットについて - アイドル スロット 管理プロジェクト内に複数の予約が存在し、アイドルスロットがどのように予約に分配されるかを細かく調整したい場合は、 予約ベースの公平性 （Reservation-based fairness）と、 予約の予測可能性 （Reservation predictability）いう設定値を使って、調整することもできます。 参考 : Understand slots - Reservation-based fairness 参考 : Workload management using reservations - Reservation predictability プロジェクト内での予約の使い分け Google Cloud プロジェクトで実行される BigQuery ジョブは、デフォルトではロケーション（リージョン）ごとに作成される予約を使用します。そのため、あるプロジェクトのあるロケーションで実行されるジョブは、Editions を使うか、オンデマンド課金を使うか、原則的にどちらか1つになります。しかし、ジョブ（クエリ）実行時に、使用する予約を明示的に指定することもできます。 ジョブ実行時に明示的に予約を指定することで、Editions を使うか、オンデマンド課金を使うかをジョブごとに切り替えることができます。以下のドキュメントのとおり、SQL の記述、Web コンソール上での設定、bq コマンド、API 経由でのジョブ実行時に、使用する予約を指定できます。 参考 : Workload management using reservations - Flexibly assign reservations 参考 : Work with reservation assignments - Override a reservation on a query SQL での指定の例 SET @@reservation= ' projects/my-project/locations/asia-northeast1/reservations/my-reservation ' ; SELECT * FROM `my-project.my_dataset.my_table` ; また、予約には IAM ポリシーを設定できるので、誰がどの予約を使用可能か、アクセス制御を行うこともできます。 参考 : Manage enhanced control on reservations 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、Google Kubernetes Engine (以下、GKE) のクラスタにデプロイした Pod から Google Cloud APIs にアクセスする方法を解説します。 GKE の概要 GKE クラスタ内の Pod から Google Cloud APIs にアクセスする方法 ノードに紐付いたサービスアカウントを使用する サービスアカウントのキーを Kubernetes Secret として GKE クラスタに登録する Workload Identity を使用する（推奨） GKE で Workload Identity を使用する方法 GKE クラスタでWorkload Identity を有効化する ノードプールで Workload Identity を有効化する Google Cloud の サービスアカウント（GSA）を作成する Kubernetes の ServiceAccount リソース（KSA）を作成する KSA と GSA を紐付ける API アクセスの確認 GKE の概要 GKE は、Google Cloud のインフラストラクチャ上に構築された マネージドな Kubernetes クラスタ を利用することができるサービスです。 サービスの詳細は以下の記事で解説しています。 blog.g-gen.co.jp GKE クラスタ内の Pod から Google Cloud APIs にアクセスする方法 GKE のワークロードでクラスタ外の Cloud Storage バケットを使用する場合など、Pod から Google Cloud APIs にアクセスするためには、Google Cloud の IAM サービスアカウントを使用します。 Pod で IAM サービスアカウントを使用する方法については以下の 3 パターンがあります。 ノードに紐付いたサービスアカウントを使用する サービスアカウントのキーを Kubernetes Secret として GKE クラスタに登録する Workload Identity を使用する（推奨） ※ 限定公開クラスタの場合、Google Cloud APIs にアクセスするには 限定公開の Google アクセス （デフォルトで有効）もしくは Cloud NAT が必要となります。 ノードに紐付いたサービスアカウントを使用する 利用可能なクラスタモード Standard クラスタのみ GKE のノードは Compute Engine VM で構成されており、ノードプールに設定した IAM サービスアカウントが、各ノード VM に紐付けられます。 ノードに紐付いたサービスアカウントは、Pod に対して何も設定していなくても、Google Cloud APIs にリクエストを送信する際に自動的に使用されます。 試しに、gcloud コマンドがプリインストールされたコンテナイメージを使用して、以下の Pod を GKE クラスタにデプロイします。 apiVersion : v1 kind : Pod metadata : name : gcloud-pod spec : containers : - name : cloud-sdk image : google/cloud-sdk:slim command : [ "sleep" , "infinity" ] Pod の作成後、 gcloud auth list コマンドで Pod から gcloud コマンドを実行する際に使用されるクレデンシャルを確認します。 # Pod が使用する IAM サービスアカウントを確認する $ kubectl exec -it gcloud-pod -- gcloud auth list Credentialed Accounts ACTIVE ACCOUNT * xxxxxxxxxxxx-compute@developer.gserviceaccount.com 今回使用した GKE クラスタのノードには Compute Engine のデフォルトのサービスアカウント が紐付いているため、Pod から Google Cloud APIs へのリクエストには {プロジェクトID}-compute@developer.gserviceaccount.com のサービスアカウントが使用されています。 ノードプールを作成する際にサービスアカウントを指定しなかった場合は、Compute Engine のデフォルトのサービスアカウントがノードに紐付くようになっています。 Compute Engine のデフォルトのサービスアカウントは IAM 基本ロールである 編集者（roles/editor） のロールが付与されているため、クラスタ内で起動する Pod がかなり過剰な権限を持ってしまいます。 また、このようにノードに紐付いたサービスアカウントを使用する場合、 そのノードに割り当てられた Pod は全て同じサービスアカウントを使用して Google Cloud APIs にリクエストを送信します。 したがって、1 つの Pod のために様々な権限をサービスアカウントに付与する必要がある場合などには、その他の Pod が 最小権限の原則 に反する運用になってしまいます。 Pod からノードに紐付いたサービスアカウントを使用する場合 サービスアカウントのキーを Kubernetes Secret として GKE クラスタに登録する 利用可能なクラスタモード Standard クラスタ・Autopilot クラスタ サービスアカウントのキーをエクスポートし、Kubernetes の Secret としてクラスタに登録することで、Pod から Secret に保存されたサービスアカウントキーを使用できます。 サービスアカウントキーをエクスポート したあと、以下のコマンドを使用して GKE クラスタに Secret リソースとして登録します。 # サービスアカウントキーを保存する Secret を作成する $ kubectl create secret generic gsa-key --from-file=key.json={サービスアカウントキーのファイルパス} サービスアカウントキーが保存された Secret リソースを Pod にマウントし、環境変数 GOOGLE_APPLICATION_CREDENTIALS でサービスアカウントキーを参照できるように設定します。 クライアントライブラリから Google Cloud APIs にアクセスする際、環境変数 GOOGLE_APPLICATION_CREDENTIALS に設定されたサービスアカウントキーが自動的に使用されます（ 参考 ）。 apiVersion : v1 kind : Pod metadata : name : gcloud-pod-gsa-key spec : volumes : - name : google-cloud-key secret : secretName : gsa-key # 登録した Secret の名前 containers : - name : cloud-sdk image : google/cloud-sdk:slim command : [ "sleep" , "infinity" ] volumeMounts : - name : google-cloud-key mountPath : /var/secrets/google env : - name : GOOGLE_APPLICATION_CREDENTIALS # サービスアカウントキーを環境変数に指定 value : /var/secrets/google/key.json この方法では、Pod ごとに別々のサービスアカウントキーを使用することで、最小権限の原則を遵守した運用が可能です。 しかし、サービスアカウントキーが増えるたびに、漏洩対策やライフサイクル管理が煩雑になっていきます。 サービスアカウントのキーを使用する場合 Workload Identity を使用する（推奨） 利用可能なクラスタモード Standard クラスタ・Autopilot クラスタ Workload Identity では、 Kubernetes の ServiceAccount リソース と Google Cloud の IAM サービスアカウント を紐付けることができます。 ここでは 2 種類のサービスアカウントが登場するので、わかりやすいように「Kubernetes の ServiceAccount リソース」を「 KSA 」、「Google Cloud の IAM サービスアカウント」を「 GSA 」と記載します。 KSA は本来、Kubernetes API に対するアクセス権を Pod に付与するための Kubernetes リソースです。 Workload Identity を使用すると、サービスアカウントキーを使用することなく、Pod に対して KSA を設定するだけで、KSA に紐付いた GSA の権限で Google Cloud APIs にアクセスできるようになります。 Workload Identity を使用する場合 また、2024年3月のアップデートにより、KSA と GSA の紐づけを行うことなく、KSA に対して IAM ロールを直接付与することができるようになりました。新しい方法については以下の記事で解説しています。 blog.g-gen.co.jp GKE で Workload Identity を使用する方法 ここからは、スタンダードモードの GKE クラスタで Workload Identity を有効化し、Pod から Google Cloud APIs にリクエストを送信してみます。 参考： Workload Identity を使用する GKE クラスタでWorkload Identity を有効化する Autopilot モードの GKE クラスタでは、デフォルトで Workload Identity が有効化されているため、この手順を実施する必要はありません。 まず、GKE クラスタで Workload Identity を有効化します。 ここでは既存のクラスタに対して更新を行っていますが、クラスタの作成時にあらかじめ有効化することもできます。 # クラスタで Workload Identity を有効化する $ gcloud container clusters update { クラスタ名 } \ --zone = { クラスタのゾーン } \ --workload-pool = { プロジェクト名 } .svc.id.goog ※ ゾーンクラスタの場合は --zone オプション、それ以外の場合は --region オプションを指定します。 ノードプールで Workload Identity を有効化する ノードプールに対しても Workload Identity を有効化していきます。 この手順についても Autopilot モードの GKE クラスタでは実施する必要はありません。 Workload Identity を有効化すると、Pod からノードに紐付いたサービスアカウントが使用できなくなるため、Google Cloud APIs を使用している既存のワークロードが中断する可能性があります。 本番環境では、 Workload Identity を有効化したノードプールを新たに作成し、既存のノードからワークロードを移行することをおすすめします。 # ノードプールで Workload Identity を有効化する $ gcloud container node-pools update { ノードプール名 } \ --cluster = { クラスタ名 } \ --zone = { ノードプールのゾーン } \ --workload-metadata = GKE_METADATA Google Cloud の サービスアカウント（GSA）を作成する Google Cloud APIs にアクセスするための GSA を作成します。 # GSA を作成する $ gcloud iam service-accounts create { GSAの名前 } --project={プロジェクト名} 作成した GSA に対して任意の IAM ロールを紐付けます。 当記事では Kubernetes Engine クラスタ閲覧者 (roles/container.clusterViewer) を GSA に紐付けます。 # GSA に IAM ロールを紐付ける $ gcloud projects add-iam-policy-binding { プロジェクト名 } \ --member " serviceAccount:{GSAの名前}@{プロジェクト名}.iam.gserviceaccount.com " \ --role " roles/container.clusterViewer " Kubernetes の ServiceAccount リソース（KSA）を作成する 以下のマニフェストファイルを用いて、GKE クラスタに KSA を登録します。 アノテーション iam.gke.io/gcp-service-account の値に、この KSA に紐付ける GSA を指定します。 apiVersion : v1 kind : ServiceAccount metadata : name : { KSAの名前 } annotations : # Workload Identity で紐付ける GSA を指定する iam.gke.io/gcp-service-account : { GSAの名前 } @ { プロジェクト名 } .iam.gserviceaccount.com KSA と GSA を紐付ける GSA に対する Workload Identity User (roles/iam.workloadIdentityUser) ロールを KSA に紐付けることで、KSA が GSA の権限を借用できるようになります。 # KSA と GSA を紐付ける $ gcloud iam service-accounts add-iam-policy-binding { GSAの名前 } @ { プロジェクト名 } .iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member " serviceAccount:{プロジェクト名}.svc.id.goog[{KSAを作成したNamespace}/{KSAの名前}] " 例えば、各リソースを以下のように作成したとします。 項目 設定値 プロジェクト名 myproject GSAの名前 gsa-workloadid KSAの名前 ksa-workloadid KSAを作成したNamespace default この場合、KSA と GSA を紐付けるコマンドは以下のようになります。 # KSA と GSA を紐付ける（例） $ gcloud iam service-accounts add-iam-policy-binding gsa-workloadid@myproject.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member " serviceAccount:myproject.svc.id.goog[default/ksa-workloadid] " API アクセスの確認 KSA と GSA の紐付けが完了したので、GKE クラスタに Pod をデプロイし、Google Cloud APIs にリクエストを送信してみます。 以下のマニフェストファイルを用いて、GSA に紐付けた KSA を使用する Pod を作成します。 apiVersion : v1 kind : Pod metadata : name : gcloud-pod-workloadid spec : containers : - name : cloud-sdk image : google/cloud-sdk:slim command : [ "sleep" , "infinity" ] serviceAccountName : { KSAの名前 } nodeSelector : # Autopilot モードの場合は不要 iam.gke.io/gke-metadata-server-enabled : "true" クラスタ内に Workload Identity が有効化されているノードとされていないノードが混在している場合、 nodeSelector を記述して Workload Identity が有効なノードで Pod を起動するように明示します。 Autopilot モードのクラスタでは各ノードで Workload Identity が必ず有効化されるため、この nodeSelector は不要です。 Pod のデプロイが完了したら、GKE クラスタの一覧を出力する gcloud コマンドを Pod 上で実行してみます。 KSA に紐付いた GSA の権限を借用することで、GKE クラスタの一覧を取得することができます。 # Pod 上で gcloud コマンドを実行 $ kubectl exec -it gcloud-pod-workloadid -- gcloud container clusters list ----- 出力例 ----- NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS mycluster-standard asia-northeast1-b 1 . 24 .9-gke. 3200 35 . 243 . 123 . 64 e2-small 1 . 24 .9-gke. 3200 1 RUNNING 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 Web サービスの可用性や運用効率を最大化するには、ユースケースにあったコンピューティングプロダクトの選定が重要です。Google Cloud では複数のコンピューティングプロダクトが提供されており、速やかなアーキテクチャ選定ができるようにそれぞれの特徴を体系的に整理することにしました。 G-gen の佐々木です。当記事では、Google Cloud (旧称 GCP) が提供している Computing プロダクトについて、それぞれの特徴とユースケース、ノックアウトファクターなどを解説します。 Google Cloud の Computing プロダクト Google Compute Engine (GCE) 特徴 料金 ユースケース ノックアウトファクター Google Kubernetes Engine (GKE) 特徴 料金 ユースケース ノックアウトファクター Cloud Run 特徴 料金 ユースケース ノックアウトファクター Google App Engine (GAE) 特徴 料金 ユースケース ノックアウトファクター Cloud Functions 特徴 料金 ユースケース ノックアウトファクター Google Cloud の Computing プロダクト Google Cloud の Computing プロダクトでは、Google が世界各地に保有するデータセンターのインフラリソースを使用し、ユーザーがハードウェアの調達、設定、管理を行うことなくアプリケーションを実行することができます。 大きく分けて 5 種類の Computing プロダクトが存在し、アプリケーションによって適切な環境が提供されるプロダクトを選ぶことが極めて重要です。 プロダクト 提供されるもの Google Compute Engine (GCE) 特定の OS が動作する仮想マシン (VM) Google Kubernetes Engine (GKE) マネージドな Kubernetes クラスタ Cloud Run フルマネージドなコンテナ実行環境 Google App Engine (GAE) フルマネージドなウェブアプリケーション実行環境 Cloud Functions フルマネージドな関数（コード）実行環境 プロダクトによって、OS やミドルウェア、パッケージなどの構成の柔軟性や、ユーザーが運用管理に責任を持たなければならない範囲が異なり、基本的に構成の柔軟性とインフラの運用負荷はトレードオフの関係になっています。 Google Cloud の Computing プロダクト Google Compute Engine (GCE) 特徴 GCE では、Google Cloud のインフラストラクチャ上で実行される仮想マシンが提供されます。 ユーザーは仮想マシンの CPU、メモリ、ディスク、GPU の構成をプロビジョニングし、実行する OS や追加のソフトウェアを決定することができます。 Computing プロダクトの中では最高の柔軟性があり、他の Computing プロダクトにデプロイできるものは GCE にもデプロイすることができます。 その代わり、OS 以上のレイヤはすべてユーザーが構築・管理する必要があり、最も運用保守にコストがかかるプロダクトとなります。 GCE の詳細については以下の記事もご一読ください。 blog.g-gen.co.jp 料金 GCE においてメインとなる料金はコンピュートリソース（CPU・メモリ）の使用料であり、仮想マシンのために確保したコンピュートリソースの量に応じて、 仮想マシンを実行している間、常に料金が発生します。 CPU 数とメモリ量の組み合わせが マシンタイプ としてまとめられており、必要なリソースを確保できるマシンタイプを選択します（カスタムマシンタイプとして CPU 数とメモリ量を個別に選択することも可能）。 Cloud Run や Cloud Functions といったサーバーレスのプロダクトと異なり、 仮想マシンが実行されている（コンピュートリソースがその仮想マシンのために確保されている）ときは、何も処理していなくても確保リソース分の料金が発生する ため、ホストされているサービスによっては仮想マシンを休日夜間などに停止し、コンピュートリソースを一時的に解放して課金を防ぐ運用を考える必要があります。 また、GCE ではインスタンスの実行時間が 730時間/月 を超えた場合に、 継続利用割引 が自動的に適用されます。 参考： Google Compute Engine の料金 ユースケース 仮想マシン用に確保するコンピュートリソース（vCPU数とメモリ量）を柔軟に選択することができ、上限もかなり大きめに設定されているため、Cloud Run などのサーバーレスプロダクトでは実現できないステートフルなアプリケーションの実行に向いています。また、仮想マシンには GPU を追加することもでき、機械学習やデータ処理などの負荷の高いワークロードを高速化することができます。 既存システムの Google Cloud へのマイグレーション（リフト & シフト）。オンプレミスで動作している既存システムの変更を最小限に抑えてクラウド移行したい場合などに選択します。 他のマネージドな Computing プロダクトでは要件を満たせないワークロードで使用します。たとえば、Windows Server や Oracle DB など、システムが特定の OS やライセンスに依存している場合や、サードパーティアプリケーションを実行したい場合などがあります。 参考： Google Compute Engine のユースケース ノックアウトファクター Computing プロダクトの中では運用負荷が最も高く、OS やミドルウェアのパッチ適用、可用性の確保など、非機能要件に関する考慮事項が多くなります。 自動スケーリングの設定をすることで負荷の分散ができますが、スケーリングが仮想マシン単位のため、コンテナを使用する他プロダクトと比較するとスケーリング速度が劣ります。 Google Kubernetes Engine (GKE) 特徴 GKE は Google Cloud 上に構成された マネージドな Kubernetes クラスタ が提供されるプロダクトです。 ユーザーはアプリケーションをコンテナ化し、Kubernetes リソースとしてクラスタにデプロイすることで、オートスケーリングやセルフヒーリングなどの Kubernetes によるオーケストレーションの恩恵を受けることができます。 GKE には Standard モードと Autopilot モードの 2 つの運用モードがあります。 Standard モードではユーザー自身がクラスタ構成を詳細に制御することができる代わりに、ノードのスケーリング設定、クラスタのセキュリティ、Kubernetes のバージョン管理なども、ユーザー自身が運用管理する必要があります。 Autopilot モードではクラスタの構成が GKE のベストプラクティスを反映したものになり、運用管理の大部分が自動で行われますが、ユーザーによるカスタマイズ可能な項目が大きく制限されます。 基本的には Autopilot モードの利用が推奨されており、Autopilot モードでは実現できない要件がある場合に Standard モードの利用を検討します。 GKE の詳細については以下の記事もご一読ください。 blog.g-gen.co.jp 料金 GKE では Standard モードと Autopilot モードで課金の単位が異なり、Standard モードでは Kubernetes ノードとして構成されている GCE 仮想マシンの実行時間、Autopilot モードではノードで実行中の Pod がリクエストしている CPU、メモリ、エフェメラルストレージの量だけ料金が発生します。 Standard モードではノードを構成している仮想マシンを停止することができないため、仮想マシン の台数分のリソース料金が常に発生します（GCE 同様、継続利用割引は適用されます）。 それに対して Autopilot モードでは、未使用のリソースに対しては料金が発生せず、クラスタで実行している Pod ごとに設定されたリソースのリクエストに応じて料金が発生します。 また、各モード共通の料金として、クラスタの管理手数料として $74.40/月 の料金が発生します（条件を満たせば 1 クラスタまで無料）。 参考： Google Kubernetes Engine の料金 ユースケース コンテナを利用するワークロードにおいて、コンテナ実行環境の OS、コンピュートリソース、ネットワーキングなどを完全に制御したい場合に選択します。 GCE 同様、ノード用に確保するコンピュートリソース（vCPU数とメモリ量）を柔軟に選択することができ、サーバーレスのプロダクトでは実装しにくいステートフルなアプリケーションや、GPU を利用するワークロードに向きます。 各機能をコンテナ化し、複数のコンテナでアプリケーションを構成するマイクロサービスアーキテクチャで利用します。フルマネージドのサービスメッシュである Anthos Service Mesh を使用することで、複雑なワークロードにおけるトラフィックの制御、保護を実現することができます。 アプリケーションを OSS である Kubernetes のリソースとして構成することで、オンプレミスや Amazon Elastic Kubernetes Service (EKS) 、Azure Kubernetes Service (AKS) などの GKE 以外の Kubernetes クラスタへの移植が容易になり、ベンダーロックインを回避することができます。また、Google Cloud で提供されている Anthos を利用することで、ハイブリッドクラウド、マルチクラウドに展開した Kubernetes 環境を統合管理することも可能です。 参考： Google Kubernetes Engine のユースケース ノックアウトファクター アプリケーションを Kubernetes リソースとしてデプロイするため、Kubernetes を用いた開発・運用の知識が必要となり、アプリケーションのコンテナイメージだけではなく、Kubernetes マニフェストの管理・運用も考慮する必要があります。 Kubernetes は 4 ヶ月に 1 回ほどのマイナーバージョンリリースがあり、非推奨となった API が使用できなくなる可能性があるため、定期的なアップグレード作業が必須となります。マイナーバージョンのサポート期限は 14 ヶ月間となっています。 Cloud Run 特徴 Cloud Run は Google Cloud のフルマネージドなコンテナ実行環境を使用して、インフラストラクチャを運用管理することなく、コンテナを直接実行することができる サーバーレス のプロダクトです。 負荷に応じたスケーリングは Cloud Run が自動で行い、 コンテナ単位の高速なスケーリング を行われるほか、 処理を行っていないときはコンテナインスタンスの数が 0 までスケールインする のが大きな特徴です。 ユーザーが Docker コンテナのイメージをデプロイするだけで、実行環境や HTTPS エンドポイントのプロビジョニングが自動で行われ、それらの運用管理をユーザー側で行う必要はありません。 また、デプロイ単位がコンテナイメージのため、後述の GAE、Cloud Functions と比べると実行環境の制約が少なく、ある程度のカスタマイズができます。 サーバーレスなウェブアプリケーション実行環境というコンセプトは GAE と共通する部分がありますが、Cloud Run は Knative という OSS をベースとしており、デプロイしたコンテナは GKE やその他 Kubernetes クラスタ上に容易に移植することが可能です。 Cloud Run の詳細については以下の記事もご一読ください。 blog.g-gen.co.jp 料金 Cloud Run では、サーバーレスプロダクトの特徴として、処理のためにプロビジョニングしたリソースの料金ではなく、 実際の処理に使用したリソース に料金が発生します。 コンテナインスタンスに割り当てた CPU 数とメモリ量に応じて処理時間あたりの料金が発生し、またコンテナインスタンスがスケールアウトした場合、その分だけ料金が発生します。 前述したように、処理を行わないときはコンテナインスタンスの数を 0 までスケールインし、コンピュートリソースを完全に解放することができるため、ユースケース次第ではかなり安価で利用することが可能です。 反面、料金が実際の処理の量に依存するということは、発生する料金の予測がしにくいという欠点にもなります。 参考： Cloud Run の料金 ユースケース 開発言語の制約を受けず、柔軟かつサーバーレスな実行環境にアプリケーションをホストしたい場合に選択します。ウェブサイトのホスティングや、バックエンド処理の実行環境として使用できます。 Cloud Scheduler をトリガーとした Cron ジョブ、Cloud Storage へのデータ格納をトリガーとした ETL ジョブといったイベントドリブンな定型処理にも利用できます。 参考： Cloud Run のユースケース ノックアウトファクター コンテナに対するリクエスト 1 つあたりの処理時間に 最大 60 分 の制約があり、それを超えるとタイムアウトとなります。 インスタンスを 0 までスケールインできる反面、インスタンス数が 0 のときにリクエストがあった場合に、1 つ目のインスタンスが起動されるまでのレイテンシが発生してしまいます（ コールドスタート ）。コンテナインスタンスの最小数を 1 以上にすることでレイテンシを改善できますが、起動しているインスタンスの料金が常に発生してしまうため、サーバーレスの利点が損なわれてしまいます。 コンテナインスタンスあたりの使用できる CPU 数、メモリ量の上限が GCE、GKE と比べると低く、極端に重い処理を行うのには向いていません。また、GPU を使用することができないため、GPU が必須となるワークロードでは GCE もしくは GKE の使用を検討する必要があります。 VPC 内に作成されるリソース (Cloud SQL や Memorystore など) にプライベート接続するには専用のコネクタインスタンスを VPC に作成する必要があり、構成が複雑になります。 Google App Engine (GAE) 特徴 GAE は Cloud Run 同様、Google Cloud が管理する実行環境に Web アプリケーションをホストすることができるサーバーレスのプロダクトです。 2008 年から提供されている Google Cloud 最初期のプロダクトであり、Cloud Run の前身のような位置づけにありますが、こちらはコンテナイメージではなく、プログラムと設定ファイルをデプロイするだけでアプリケーションを稼働させることができます。 GAE では スタンダード環境 と フレキシブル環境 の 2 種類の実行環境が提供されています。 スタンダード環境ではサポートされる言語の制限があるものの、Cloud Run 同様にサーバーレスな実行基盤にアプリケーションをホストすることができ、Google によって事前構成されたコンテナ環境でアプリケーションが実行されます。 スタンダード環境では、以下の言語がサポートされています（ 参考 ）。 Node.js Python Go Java Ruby PHP またスタンダード環境では、Cloud Run 同様、負荷に応じて 0 ~ N 個のインスタンスに高速でスケーリングすることができます。 それに対してフレキシブル環境では、サポートされる言語の制限がなく、アプリケーションはマネージドな GCE 仮想マシン上の Docker コンテナにホストされます。 フレキシブル環境は名前の通り柔軟な構成が可能ですが、GCE 仮想マシン上で動作するため、スタンダード環境のような 0 ~ N のスケーリングはできず、必ず 1 台以上のインスタンスが実行されます。 また、スケーリングが仮想マシン単位となるため、スタンダード環境と比較してスケーリング速度が遅いという欠点があります。 フレキシブル環境ではアプリケーションが GCE 仮想マシン上で動作し、したがってインスタンスは VPC 内で実行されます。 VPC 外で実行されるスタンダード環境のインスタンスや Cloud Run とは異なり、Cloud SQL や Memorystore といった VPC に紐づくリソースをシンプルな構成で利用することができるほか、SSH でインスタンスに接続してデバッグを行うことも可能です。 GAE の詳細については以下の記事もご一読ください。 blog.g-gen.co.jp 料金 GAE の料金設定は環境ごとに異なります。 スタンダード環境では、事前定義された CPU 数とメモリ量の組み合わせである インスタンスクラス によって、インスタンスの実行時間あたりの料金が発生します。 インスタンスクラスには接頭辞が「B」のものと「F」のものがあり、「B」のクラスは 9時間/日 、「F」のクラスは「 28時間/日 」の無料枠があります。 たとえば 2 台のインスタンスが 24 時間実行されている場合、実行時間の合計は 48 時間/日 となるため、「B」のクラスは 39 時間/日 、「F」のクラスは 20 時間/日 の料金が発生します。 フレキシブル環境では、GCE と同様にマシンタイプを選択し、マシンタイプに設定された CPU 数、メモリ量に応じてインスタンスの実行時間あたりの料金が発生します。 参考リンク： App Engine の料金 ユースケース Cloud Run 同様、ユーザの管理が不要な Google マネージドな実行環境にウェブアプリケーションをホストしたいときに選択します。ユーザがコンテナイメージを用意し、それを実行する環境が提供される Cloud Run とは異なり、GAE ではサポートされている言語であれば、アプリケーションコードと設定ファイルをデプロイするだけでアプリケーションを実行することができるため、Cloud Run よりも柔軟性は低くなる代わりに、よりアプリケーションコードの開発のみに集中することができます。 ノックアウトファクター Google Cloud プロジェクト 1 つあたりにデプロイできる GAE アプリケーションは 1 つとなっています。1 つのサービスに複数の GAE 環境を利用したい場合はプロジェクトを都度作成する必要があり、管理が煩雑になります。 スタンダード環境の GAE では開発言語の制限があるため、サポート対象外の言語でサーバーレスなアプリケーション実行基盤を利用したい場合は Cloud Run を、コンテナイメージの管理をしたくない場合や GAE の機能を利用したい場合はフレキシブル環境の GAE を使用します。 フレキシブル環境の GAE はアプリケーション GCE 仮想マシン上にホストされるため、GCE 同様の料金が発生します。スケーリングの単位が仮想マシンとなるためスケールアウトが遅く、またインスタンス数を 0 までスケールインできないため、「実際に使用したぶんだけ料金を支払う」サーバーレスの特性が損なわれます。 Cloud Functions 特徴 Cloud Functions はいわゆる FaaS (Functions as a Service) と呼ばれるタイプのプロダクトであり、Cloud Run や GAE よりもさらにシンプルに、特定の開発言語で書かれたコードのみをアップロードするだけで、サーバーやコンテナをプロビジョニング、管理することなく処理を実行することができる 関数 をデプロイすることができます。 Cloud Functions では、以下の言語がサポートされています（ 参考 ）。 Node.js Python Go Java .NET Ruby PHP Cloud Run と同様のサーバーレスなプロダクトであり、処理を行っていないときは関数の実行環境を 0 までスケールインすることができ、需要に応じた高速な自動スケーリングが可能です。 第 1 世代と第 2 世代の実行環境が提供されており、最大実行時間の制限などが改善されていることから、現在は後発の第 2 世代の利用が推奨されています。 また、Cloud Functions は Functions Framework というオープンソースライブラリにより、Google Cloud 以外の様々な場所に関数を移植して実行することが可能となっています。 Cloud Functions の詳細については以下の記事もご一読ください。 blog.g-gen.co.jp 料金 Cloud Functions の料金は主に 関数の呼び出し回数 と 関数の実行時間 で決定します。 呼び出し回数については 200万回/月 の無料枠があり、関数の用途次第では無料枠の範囲内に収まることもあります。 関数の実行時間あたりの料金は、関数に割り当てたコンピュートリソースに応じて単価が増加します。Cloud Run 同様、処理を行っていないときはコンピュートリソースが確保されないため、料金が発生しません。 参考： Cloud Functions の料金 ユースケース HTTP リクエストや Pub/Sub 、Google Cloud 上のリソースの更新などのイベントを起点とした、単純な処理を実行することに向いています。デプロイに必要なものはコードのみであり、最小限の運用負荷で処理を実装することができます。Cloud Scheduler をトリガーとした Cron ジョブや、Cloud Storage に格納されたデータの ETL ジョブ、Firebase 上にホストされたアプリケーションのバックエンド処理などのユースケースが一般的です。 参考： Cloud Functions のユースケース ノックアウトファクター 開発言語の制限があるため、サポートされていない言語を使用してサーバーレスに処理を行いたい場合は、より柔軟な構成ができる Cloud Run による実装を検討します。 Cloud Run 同様、インスタンス数が 0 のときにリクエストがあった場合はコールドスタートが発生します。 第 1 世代の関数ではトリガーの種類を問わず 9 分、第 2 世代の関数では HTTP トリガーが 60 分、イベントトリガーが 10 分の最大実行時間制限があります。このことから、処理時間の長いバッチ処理には向きません。 Cloud Run 同様、Cloud SQL などの VPC に紐付いたリソースへのアクセスには専用のコネクタインスタンスを経由する必要があり、構成が複雑になる上、インスタンスぶんの追加の料金が発生してしまいます。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-genの杉村です。Google Cloud (旧称 GCP) のジョブ自動化サービスである Cloud Workflows （または単に Workflows）を解説します。 概要 Cloud Workflows とは ユースケース 料金 課金の仕組み 内部ステップと外部ステップ ワークフロー定義 定義の基本 ランタイム引数 サービス呼び出し エラー処理 待機 コールバック スリープ ワークフローの実行 実行契機 (トリガ) Cloud Scheduler による定期実行 イベントドリブン実行 Eventarc での実行 Cloud Run functions での実行 実行履歴 ワークフローのサンプル サンプルコード 公式のサンプルコード データパイプラインのサンプル 概要 Cloud Workflows とは Cloud Workflows （または単に Workflows）はGoogle Cloud のジョブ自動化サービスです。フルマネージドかつサーバーレスであるためインフラの管理は必要なく、また非常に安価に利用できるのが特徴です。 参考 : ワークフローの概要 Cloud Workflows のワークフローからは、定義した順番通りに Cloud Run functions や Cloud Run などで定義したプログラムを実行したり、BigQuery へ SQL を発行したり、任意の HTTP エンドポイントへリクエストを送信することができます。 参考 : Cloud Run functionsを徹底解説！ - G-gen Tech Blog 参考 : Cloud Runを徹底解説！ - G-gen Tech Blog 実行契機として、Cloud Scheduler による定期実行のほか、API 経由のオンデマンド実行も可能です。また実行時にはワークフローに引数を渡すことができます。 参考 : Cloud Scheduler を徹底解説！ - G-gen Tech Blog ワークフローは YAML または JSON フォーマットで定義され、順次実行のほか、条件分岐、繰り返し、並列実行などを定義できます。以下は、ワークフローの例です。 ワークフローの例 ユースケース Cloud Workflows は以下のようなユースケースで利用されます。 No ユースケース名 例 1 データパイプライン 業務システムからデータ抽出して、BigQuery へロード。その後、SQL で変換（ELT） 2 バッチジョブ 日次でファイルを転送する / 機械学習ジョブを実行する 3 イベントドリブンジョブ Cloud Storage にアップロードされた画像ファイルを変換して別バケットに格納後、メタデータを Firestore に書き込む 参考 : 主なユースケース 料金 課金の仕組み Cloud Workflows の料金は、実際に実行されたワークフローの ステップ数 に応じた従量課金です。 ステップ とは、ワークフローに定義された個別の手順です。例えば「Cloud Run functions の関数 A を実行する」「A の処理が完了後、Cloud Run functions 関数 B を実行する」というワークフローがあるとき、これは計2ステップとなります。 後述しますが、ステップには内部ステップと外部ステップが存在します。内部ステップは 5,000回/月、外部ステップは 2,000回/月の無料枠があります。1ヶ月間に実行されたステップ数が無料枠内であれば、Cloud Workflows を完全無料で利用することができます。 無料枠を超過した後は、内部ステップは 1,000 ステップあたり $0.01、外部ステップは 1,000 ステップあたり $0.025 が課金されます。 なお上記は2025年4月現在の料金単価です。最新の料金は公式の料金表をご参照ください。 参考 : ワークフローの料金 内部ステップと外部ステップ ステップは内部ステップと外部ステップに分けられます。外部ステップのほうが単価が高く設定されています。 内部ステップ とは、 *.googleapis.com API や *.appspot.com ドメインに送信されるリクエストや、Cloud Run functions や Cloud Run の実行、またワークフロー内の変数割当や評価など、Google Cloud の中で完結するステップを指します。 一方の 外部ステップ は、Google Cloud の外部への HTTP API のリクエストや、Google Cloud リソースであってもカスタムドメインを使っているエンドポイントへのリクエストのことです。また、後述の コールバック待機 のステップも外部ステップとして扱われます。 参考 : ワークフローの料金 - 内部および外部のステップ ワークフロー定義 定義の基本 ワークフローは YAML または JSON で定義します。文法のリファレンスは以下に用意されています。 参考 : Syntax overview ワークフローの基本的な概念として以下があります。 No 名称 説明 1 Step (ステップ/手順) ステップで変数を定義したり、Cloud Functions をコールしたり、BigQuery へ SQL を投入する 2 Condition (条件) switch 条件式によりワークフローを分岐 3 Iteration (繰り返し) for により繰り返し処理を実行 4 Parallel step (並列ステップ) parallel によりステップを並列実行 5 Subworkflow (サブワークフロー) プログラミング言語の関数のように、再利用可能なステップ群を定義して実行できる これらを組み合わせることで、順次・分岐・繰り返しを含む複雑なワークフローを構築することができます。 ランタイム引数 ワークフローの実行時に JSON 形式で引数を渡すことができます。 例えば、以下の 2 ステップのみのシンプルなワークフローに {"myName": "John Doe"} という引数を渡して実行します。 main : params : [ arguments ] steps : - getName : assign : - result : ${"Hello, " + arguments.myName + " ! "} - finalize: return: ${result} すると、返り値は以下の通りとなります。 "Hello, John Doe!" サービス呼び出し 各ステップでは以下のような呼び出しが可能です。 HTTP API コネクタ 標準ライブラリ 環境変数 HTTP API は、ステップから HTTP リクエスト（GET/POST/PUT 等）を実行することを指します。Cloud Run functions や Cloud Run の呼び出しも、これを使って行います。 参考 : HTTP リクエストを行う コネクタは、Cloud Workflows が用意する各種 Google Cloud サービスへのコネクタを指します。BigQuery、Cloud Storage、Cloud Build、Dataflow、Compute Engine など多くの Google Cloud サービス用コネクタが用意されており、API コールを実行することができます。認証はワークフローに紐付けられたサービスアカウントの IAM 権限により行われます。 参考 : コネクタを理解する 参考 : Connectors reference 標準ライブラリは、ワークフロー内で利用可能な組み込み処理です。数値を計算したり、テキストを結合・分解したり、base64 エンコード・デコードや wait を入れることができます。 参考 : Standard library overview 環境変数は、Cloud Workflows によって用意された組み込みの変数です。プロジェクト ID やサービスアカウント名、ワークフローの実行 ID を得ることができます。 参考 : Built-in environment variables エラー処理 ワークフローでは、エラー処理が可能です。 raise 、 try 、 except などをワークフロー内で利用できます。 参考 : Workflow errors またエラーを Cloud Logging に出力させることで、そのログから文字列を検知してメールや Slack に発報するなどの監視も可能です。 Cloud Logging におけるログの監視についての詳細は、以下の記事もご参照ください。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - ログ監視 待機 コールバック ワークフロー内で何らかの処理の完了を待ってから次のステップへ進みたい場合、 コールバックエンドポイント を利用することができます。 実行したサービスによる処理が完了したら、ワークフローのコールバックエンドポイントへリクエストを投げるように処理を記述することで、一時停止していたワークフローを再開できます。タイムアウトを設定することも可能です。 参考 : コールバックを使用して待機する スリープ 標準ライブラリに sys.sleep が用意されており、一定時間待機することができます。 処理終了をポーリングして確認する繰り返し処理を組み合わせることで、ポーリングによる待機を実現することが可能です。ただしこの場合は、タイムアウト処理は自前で実装する必要があります。 参考 : ポーリングの使用を待機する なお以下の当社記事では、 sys.sleep と switch による評価を組み合わせたポーリング待機処理を実装しています。 blog.g-gen.co.jp ワークフローの実行 実行契機 (トリガ) Cloud Workflows のワークフローは以下をトリガにして実行することができます。 自動 Cloud Scheduler による定期実行 Eventarc によるイベントドリブン実行 Pub/Sub メッセージによるイベントドリブン実行 手動 Google Cloud コンソール Google Cloud CLI（gcloud コマンド） Cloud SDK クライアントライブラリ（Java、Node.js、Python...） REST API Cloud Scheduler による定期実行 最も一般的な実行方法は、Cloud Scheduler のスケジュールによる定期的な実行です。 スケジュールにはサービスアカウントを設定し、ワークフロー起動元（ roles/workflows.invoker ）ロールを付与することで、ワークフローを起動する権限を与える必要があります。 またスケジュール実行時に、ワークフローに引数を渡すことができます。 詳細な手順は以下をご参照ください。 参考 : Cloud Scheduler を使用したワークフローのスケジュール設定 また Cloud Scheduler の詳細は、以下の当社記事もご参照ください。 blog.g-gen.co.jp イベントドリブン実行 Eventarc での実行 例えば Cloud Storage へのオブジェクトの Put をトリガにワークフローを開始したい場合、Eventarc を利用することでイベンドリブンでワークフローを起動することが可能です。 参考 : Eventarc の概要 Eventarc からは、 CloudEvents 形式で、イベントの内容がワークフローに引数として渡されます。 参考 : CloudEvents - JSON event format ワークフローに渡す引数を特定の形式に変更したい場合は、後述の Cloud Run functions を用いた起動方法を検討します。 参考 : イベントまたは Pub/Sub メッセージでワークフローをトリガーする イベントドリブンなワークフロー① Cloud Storage の例のほかにも、特定の監査ログ（Cloud Audit Logs）の出力をトリガにしてワークフローを起動するなど、Eventarc が対応している様々なイベントをトリガにしてワークフローを実行できます。 Cloud Run functions での実行 Eventarc を使う方法のほかに、Cloud Run functions からワークフローを起動することもできます。 以下は、Cloud Storage へのオブジェクト Put をトリガとして Cloud Run functions 関数が起動し、Cloud SDK クライアントライブラリを使って Cloud Workflows を実行する場合の例です。 イベントドリブンなワークフロー② 実行履歴 ワークフローの実行履歴は、Cloud Workflows の Web UI や、REST API 経由で確認できます。 ステップごとの履歴確認 参考 : 実行ステップの履歴を表示する ワークフローのサンプル サンプルコード 以下は YAML で定義したワークフローのサンプルです。2つの Cloud Run functions 関数を順番にコールするシンプルなものです。最初の関数の戻り値を次の関数に渡しています。 main : steps : - initialize : assign : - my_parameter_01 : "hogehoge" - execute_01 : call : http.post args : url : https://asia-northeast1-your-project-name.cloudfunctions.net/my-function-01 body : my_parameter : ${my_parameter_01} auth : type : OIDC result : my_parameter_02 - execute_02 : call : http.post args : url : https://asia-northeast1-your-project-name.cloudfunctions.net/my-function-02 body : my_parameter : ${my_parameter_02} auth : type : OIDC result : result - finalize : return : ${result} 公式のサンプルコード 様々なユースケースに応じたサンプルコードが公式に用意されていますのでご参照ください。 参考 : すべての Workflows のコードサンプル データパイプラインのサンプル 以下の記事で、Cloud Workflows と BigQuery の Scheduled query、Bigquery Data Transfer Service を組み合わせた簡易的なデータパイプラインをご紹介しています。 Cloud Workflows の YAML も公開していますので、ご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。 当記事は gcloud と jq コマンドシリーズの第2弾として、Google Cloud (旧称 GCP) の IAM に関する情報の取得方法についてご紹介します。 組織 / フォルダ / プロジェクト 編の記事 組織の IAM Policy IAM ポリシーの表示 プリンシパルの抽出 jq コマンドの利用 重複値の除外 ( unique 構文 ) 特定のプリンシパルに紐づくロールの抽出 特定のロールに紐づくプリンシパルの抽出 フォルダの IAM Policy プロジェクトの IAM Policy 組織 / フォルダ / プロジェクト 編の記事 組織 / フォルダ / プロジェクト編 については以下の記事をご参照ください。 gcloud コマンドや jq コマンドの概要の他、コマンドの実行方法についても解説しています。 blog.g-gen.co.jp 組織の IAM Policy IAM ポリシーの表示 組織の IAM Policy 情報を取得するには、 gcloud organizations get-iam-policy コマンドを使用しますが、その中から特定の値を抽出する方法をいくつかご紹介します。 出力例は以下のとおりです。 $ gcloud organizations get - iam - policy $ { ORG_ID } -- format = json | \ jq - r '.bindings[]' { " members ": [ " group:tech@example001.co.jp " ] , " role ": " roles/accesscontextmanager.gcpAccessAdmin " } { " members ": [ " domain:example001.co.jp " ] , " role ": " roles/browser " } (〜中略〜) { " members ": [ " serviceAccount:service-org-1111111111@security-center-api.iam.gserviceaccount.com " ] , " role ": " roles/securitycenter.serviceAgent " } { " members ": [ " group:tech@example001.co.jp ", " serviceAccount:service-org-1111111111@security-center-api.iam.gserviceaccount.com " ] , " role ": " roles/serviceusage.serviceUsageAdmin " } プリンシパルの抽出 jq コマンドの利用 members というキーにプリンシパルが入っています。以下のように gcloud の出力結果をパイプで jq コマンドに渡すことで、プリンシパルだけを抽出できます。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '.bindings[] |.members[]' group:tech@example001.co.jp domain:example001.co.jp (〜中略〜) serviceAccount:service-org-1111111111@security-center-api.iam.gserviceaccount.com group:tech@example001.co.jp serviceAccount:service-org-1111111111@security-center-api.iam.gserviceaccount.com 重複値の除外 ( unique 構文 ) IAM Policy は members (プリンシパル) と role (権限) の組み合わせなので、プリンシパルに対して複数の権限が紐付いている場合は重複して表示されます。 このような場合、 unique 構文を使用すると重複値を除外できます。Linux コマンドで言う uniq コマンドや SQL で言う DISTINCT に相当します。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '[.bindings[].members[]] | unique | .[]' domain:example001.co.jp group:it-grp@example001.co.jp group:tech@example001.co.jp serviceAccount:sa-cloud-identity@pj002.iam.gserviceaccount.com serviceAccount:service-org-1111111111@security-center-api.iam.gserviceaccount.com serviceAccount:tf-exec@pj001.iam.gserviceaccount.com user:mike@example001.co.jp user:su@example001.co.jp 以下の例では、最後に sed コマンドに出力を渡し、プリンシパル種別 ( group: や user: など) の文字列を消しています。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '[.bindings[].members[]] | unique | .[]' | \ sed -e "s|.*:||" example001.co.jp it-grp@example001.co.jp tech@example001.co.jp sa-cloud-identity@pj002.iam.gserviceaccount.com service-org-1111111111@security-center-api.iam.gserviceaccount.com tf-exec@pj001.iam.gserviceaccount.com mike@example001.co.jp su@example001.co.jp 以下の例では、特定のプリンシパル種別 ( user: ) に絞って抽出しています。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '[.bindings[].members[]] | unique | .[] | select(startswith("user:"))' | \ sed -e "s|.*:||" mike@example001.co.jp su@example001.co.jp 特定のプリンシパルに紐づくロールの抽出 以下のように jq コマンドの select 構文を用いることで、特定のプリンシパルに与えられているロールだけを抽出することもできます。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '.bindings[] | select(.members[] == "group:it-grp@example001.co.jp") | .role' roles/cloudsupport.admin roles/orgpolicy.policyAdmin roles/resourcemanager.folderAdmin roles/resourcemanager.organizationAdmin roles/resourcemanager.projectCreator roles/securitycenter.admin 以下のように roles/ という文字列を除外することができます。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '.bindings[] | select(.members[] == "group:it-grp@example001.co.jp") | .role' | \ sed -e "s|roles/||" cloudsupport.admin orgpolicy.policyAdmin resourcemanager.folderAdmin resourcemanager.organizationAdmin resourcemanager.projectCreator securitycenter.admin 特定の文字列を含むプリンシパルを抽出することも可能です。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '.bindings[] | select(.members[] | test("it-grp")) .role' | \ sed -e "s|roles/||" cloudsupport.admin orgpolicy.policyAdmin resourcemanager.folderAdmin resourcemanager.organizationAdmin resourcemanager.projectCreator securitycenter.admin 特定のロールに紐づくプリンシパルの抽出 以下の例ではオーナー権限を持つプリンシパルを抽出します。 $ gcloud organizations get-iam-policy ${ORG_ID} --format=json | \ jq -r '.bindings[] | select(.role == "roles/owner") | .members[]' serviceAccount:sa-cloud-identity@pj002.iam.gserviceaccount.com user:su@example001.co.jp フォルダの IAM Policy フォルダの IAM Policy 情報を取得するには、 gcloud resource-manager folders get-iam-policy コマンドを使用します。 出力例は以下のとおりです。 $ gcloud resource - manager folders get - iam - policy $ { FLDR_ID } -- format = json | \ jq - r '.bindings[]' { " members ": [ " user:su@example001.co.jp " ] , " role ": " roles/resourcemanager.folderAdmin " } { " members ": [ " user:yutakei@example002.co.jp " ] , " role ": " roles/resourcemanager.folderCreator " } { " members ": [ " user:su@example001.co.jp ", " user:yutakei@example001.co.jp " ] , " role ": " roles/resourcemanager.folderEditor " } { " members ": [ " user:yutakei@example002.co.jp " ] , " role ": " roles/resourcemanager.folderViewer " } 先程と同じように、出力をパイプで jq や sed に渡すことで、様々な出力の加工が可能です。 プロジェクトの IAM Policy プロジェクトの IAM Policy 情報を取得するには、 gcloud projects get-iam-policy コマンドを使用します。 出力例は以下のとおりです。 $ gcloud projects get-iam-policy ${PRJ_ID} --format=json | \ jq -r '.bindings[]' { "members": [ "user:yutakei@example001.co.jp" ], "role": "roles/accesscontextmanager.policyAdmin" } { "members": [ "serviceAccount:service-999999999999@gcp-sa-servicemesh.iam.gserviceaccount.com" ], "role": "roles/anthosservicemesh.serviceAgent" } (〜中略〜) { "members": [ "serviceAccount:wada2@pj003.iam.gserviceaccount.com", "serviceAccount:wada@pj003.iam.gserviceaccount.com" ], "role": "roles/secretmanager.secretAccessor" } { "members": [ "serviceAccount:service-999999999999@service-networking.iam.gserviceaccount.com" ], "role": "roles/servicenetworking.serviceAgent" } やはり先程と同じように、出力をパイプで jq や sed に渡して出力を加工できます。 武井 祐介 (記事一覧) 2022年4月入社 / クラウドソリューション部 / 技術2課所属 趣味はゴルフにロードバイク。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 Google Cloud 認定全冠達成！(2023年6月)

当記事は みずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画 で執筆されたものです。 みずほリサーチ＆テクノロジーズ株式会社の高瀬です。 Google Cloud（旧GCP）上に HashiCorp 社の Vault Enterprise クラスタを構築したので流れをまとめました。 未経験の状態で構築しましたので、つまずきポイントも併記しています。 当ブログは G-gen × みずほRT によるコラボ記事です はじめに Vault (HashiCorp) とは 構築のおおまかな流れ Terraform Cloudの設定 Terraformモジュールの準備 クラスタの作成 prereqs_quickstart を実行 terraform-gcp-vault-ent-starterを実行 まとめ はじめに Vault (HashiCorp) とは Vault とは HashiCorp 社の製品で、プラットフォームフリーで、シークレットを一元管理することができる製品です。 例えばVaultでは一時的なユーザの発行も行え、有効期限を1週間にしたユーザーを作成すると1週間後に自動的にユーザが削除されます。自動でユーザが削除されるのはとても便利ですね。 詳細は こちら をご確認ください。 構築のおおまかな流れ 構築にはTerraform Cloud BusinessとCloud Shellを利用します。 今回構築するのは下図のVault Enterpriseの構成で、複数のアベイラビリティゾーンにクラスタを分割する可用性の高い構成です。 図は 公式マニュアル より引用 構築は以下の順に行います。 Terraform CloudとGoogle Cloudを連携 Vault Enterpriseクラスタを構築するためのTerraformモジュールを入手 Cloud ShellでTerraformを実行 後で触れるTerraformモジュールの実行にはVaultのライセンスファイルが必要なため、必要な際は こちら より HashiCorp社へお問い合わせ下さい。 Terraform Cloudの設定 まず Terraform Cloud と Google Cloud を連携させるための認証情報の登録を行います。 Google Cloudの資格情報が必要ですので Google CloudのIAMと管理>サービスアカウントからサービスアカウントを作成し、キーを控えておいてください。 今回は静的にGoogle Cloudの資格情報を設定していますが、Terraform CloudではOpenID Connectを利用し、動的にGoogle Cloudの資格情報を利用する事が可能です。セキュアにTerraformを扱うための必要な機能がビルドインされています。 Dynamic Credentials with the GCP Provider それではTerraform CloudとGoogle Cloudの連携を実施していきます。 はじめにTerraform Cloudの設定から行います。 Terraform Cloudの Projects & workspaces からワークスペースを作成し、CLI-drivenを選択してください。 次にSettings>Generalに移動し、Execution ModeをAgentに変更します。 ※Agentモードが利用できるのはBusinessプランのみとなります。他のモードでも実行できると思いますが、今回はAgentモードを利用していきます。 Terraform VersionはCloud ShellとのTerraformバージョンと同じものに変更します。その後、下までスクロールして保存してください。 TerraformのバージョンはCloud Shellから以下コマンドで確認可能です。 terraform --version 次にTerraform CloudにGoogle Cloudの認証情報を設定します。設定方法については以下URLがわかりやすいのでご参考ください。 How-to set up Google Cloud (GCP) credentials in Terraform Cloud 最後にCloud Shellからterraform loginコマンドを実行し、Terraform Cloudにログインします。設定方法については以下URLをご参考ください。 Log in to Terraform Cloud from the CLI Terraformモジュールの準備 Vault Enterpriseクラスタを構築するためのTerraformモジュール、 vault-ent-starter があるためダウンロードしていきます。 このモジュールを利用すると、 Vault with Integrated Storage Reference Architecture に沿った構成をGoogle Cloud上にプロビジョニングできます。 今回の構築にはvault-ent-starterを利用していきます。 vault-ent-starterモジュールをダウンロードします。Google CloudからCloud Shellを立ち上げてコマンドを実行してみてください。 ちなみに私はvault-testというフォルダを作成してその中で実行しています。 cd vault-test git clone https://github.com/hashicorp/terraform-gcp-vault-ent-starter コマンドを実行すると terraform-gcp-vault-ent-starter がダウンロードされます。中に examples/prereqs_quickstart と modules が入っていることを確認してください。 modulesを実行するためには先にVPCとTLS証明書を用意する必要があり、examplesにはVPCとTLS証明書を作成するためのモジュールが入っています。 今回はexampleを使ってVPC、TLS証明書を作成していきます。 本番利用の際はそれぞれ非機能要求にあったものをご準備ください。 gcp-vpc ： Vault対応のVPCを作成するためのモジュールです。 gcp-tls ： Load Balancerに設定するTLS証明書を作成するためのモジュールです。VaultクラスタはLoadBalancerで負荷分散されます。 vault-ent-starter ： Enterprise Vaultクラスタを作成するためのモジュールです。実行にはVPCとTLS証明書の作成および、Vaultのライセンスファイルを用意しておく必要があります。 ダウンロードした terraform-gcp-vault-ent-starter フォルダ。 terraform-gcp-vault-ent-starter の直下から vault-test に examples を移動してください。検証時、examplesを移動せずに実行するとエラーが発生しました。 modulesはterraform-gcp-vault-ent-starter直下で実行するため移動不要です。 クラスタの作成 prereqs_quickstart を実行 prereqs_quickstartを実行し、VPCとTLSを作成します。 Terraform Cloudで実行するための設定がモジュールには記載されていませんので、main.tfとvariables.tfに設定を追加していきます。 examples/prereqs_quickstart/main.tf にTerraform Cloudの設定を追加してください。 terraform { cloud { organization = "Terraform Cloudのorganization名" workspaces { name = "Terraform Cloudのworkspaces名" } } } examples/prereqs_quickstart/variables.tf にデプロイ先であるGoogle CLoudのプロジェクトIDとリージョン名を追加します。 variable "network_name" { type = string default = "consul-test-network" description = "The name of the VPC network being created" } variable "project_id" { type = string description = "The GCP project ID in which to launch resources" # 追加 default = "Google CloudのプロジェクトID" } variable "region" { type = string description = "GCP region in which to launch resources" # 追加（今回は東京リージョンに構築していきます） default = "asia-northeast1" } Google CloudのプロジェクトIDが不明の場合はCloud Shellから以下コマンドで取得可能です。 gcloud projects list --format ' value(projectId) ' --filter name =プロジェクト名 Terraformで定義したvariables（変数）はdefault値が指定されていなかったり、コマンドラインで値が指定されていなかったりした場合、applyの際に対話式で設定値の入力を促されます。 Terraform Cloudでのapplyでは対話入力できなかったため、今回はdefault値を設定しました。（下記のエラーが発生しました） │ Error: No value for required variable │ │ on variables.tf line 7: │ 7: variable " project_id " { │ │ The root module input variable " project_id " is not set , and has no default │ value. Use a -var or -var-file command line argument to provide a value for │ this variable. ここまででTerraform Cloudで実行するための準備が完了しました。 Terraformでは実際にリソースを作成する前に、terraform planコマンドでどのようなリソースが作成されるか確認することができます。tfファイルの構造が正しいか確認するためにも使用できます。 まずはteraform planでエラーが発生しないことを確認します。planでエラーがなかった場合、terraform applyを実行しリソースを作成してください。 実行後、Outputsに作成されたVPCやTLS証明書の情報が出力されます。のちの手順で利用しますので控えておいてください。 cd examples/prereqs_quickstart/ terraform init terraform plan terraform apply Outputs: leader_tls_servername = " vault.server.com " ssl_certificate_name = " vault-xxxxxxx " subnetwork = " https://xxxxxxxx " tls_secret_id = " terraform_example_module_vault_tls_secret " terraform-gcp-vault-ent-starterを実行 prereqs_quickstart が無事に実行できたら、次は terraform-gcp-vault-ent-starter を実行し、Enterprise Vaultクラスタを作成します。 実行の前提条件としてVaultのライセンスファイルが必要です。 ライセンスファイルを terraform-gcp-vault-ent-starter の直下に配置してください。 入手したままではTerraform Cloudで実行するための設定が記載されていません。examples/prereqs_quickstart実行時と同じように、Terraform Cloudで実行するための設定をmain.tfとvariables.tfに追記していきます。 terraform-gcp-vault-ent-starter/main.tf に以下を追加してください。 terraform { cloud { organization = "Terraform Cloudのorganization名" workspaces { name = "Terraform Cloudのworkspaces名" } } } terraform-gcp-vault-ent-starter/variables.tf にdefaultを追加していきます。defaultにはexamples実行時のOutputsで出力された値を入力してください。 variable "leader_tls_servername" { type = string description = "One of the shared DNS SAN used to create the certs used for mTLS" # 追加 default = "vault.server.com" } variable "project_id" { type = string description = "GCP project in which to launch resources" # 追加 default = "Google CloudのプロジェクトID" } variable "resource_name_prefix" { type = string description = "Prefix for naming resources" # 追加（お好きなprefixを付けてください） default = "demo" } variable "ssl_certificate_name" { type = string description = "Name of the created managed SSL certificate. Required when create_load_balancer is true" # 追加 default = "vault-xxxxxxx" } variable "subnetwork" { type = string description = "The self link of the subnetwork in which to deploy resources" # 追加 default = "https://xxxxxxxx" } variable "tls_secret_id" { type = string description = "Secret id/name given to the Google Secret Manager secret" # 追加 default = "terraform_example_module_vault_tls_secret" } variable "vault_license_filepath" { type = string description = "Filepath to location of Vault license file" # 追加（ライセンスファイルをterraform-gcp-vault-ent-starter直下に配置した場合） default = "vault.hclic" } 修正が終わったらterraform-gcp-vault-ent-starterを実行し、Enterprise Vaultクラスタを作成します。planでエラーがないことを確認後、applyを実行して下さい。 cd ../../terraform-gcp-vault-ent-starter/ terraform init terraform plan terraform apply もしrequired field is not setエラーが発生した場合は、エラーが発生したmain.tfにパラメータを追加します。 │ Error: project: required field is not set │ │ with module.iam.google_service_account.main, │ on modules/iam/main.tf line 5 , in resource " google_service_account " " main " : │ 5: resource " google_service_account " " main " { │ 下記エラーですと modules/iam/main.tf の5行目、 google_service_account に project を追加します。検証時は設定がうまくいっていなかったのかprojectとregionのエラーが頻発したため都度追加していきました。 resource "google_service_account" "main" { account_id = "${var.resource_name_prefix}-vault-${random_id.vault.hex}" display_name = "Vault KMS and auto-join for auto-unseal" # 追加 project = プロジェクトID } 以下のように既存リソースが削除されるメッセージが出力された場合は、 prereqs_quickstart と terraform-gcp-vault-ent-starter で同じTerraform Cloudのワークスペースを参照している可能性があります。 新規でワークスペースを作成し、 terraform-gcp-vault-ent-starter/main.tf の workspaces の name を作成したワークスペース名に修正してください。 # module.secrets.google_compute_region_ssl_certificate.main will be destroyed # (because google_compute_region_ssl_certificate.main is not in configuration) - resource " google_compute_region_ssl_certificate " " main " { - certificate = ( sensitive value ) - certificate_id = xxxxxxxxxxxxxx - > null .... } Applyが表示され、VMインスタンスが立ち上がれば成功です！ 立ち上げたインスタンスにSSHでログイン可能か確認してください。 まとめ はじめての構築のため不格好ではありますが、無事に実行することができました。Vaultを使うにあたってテンプレートがあるのは非常に便利だなと思います。 もし本記事がこれからVaultを使おうとしている方の助けになれましたら幸いです。 高瀬　優紀 みずほリサーチ&テクノロジーズ株式会社 先端技術研究部に所属。Google Cloudは触り始めて数か月。社内のAWS人材育成を主に担当している。

G-gen 又吉です。今回は Vertex AI Workbench を用いて JupyterLab の開発環境から BigQuery ML を実行し機械学習モデル(クラスタリング)を作成していきたいと思います。 概要 概要 今回使用するデータ K-means 法とは 準備 Vertex AI Workbench の作成 BigQuery データセットとテーブルの作成 JupyterLab 起動 実行 データの確認 ハイパーパラメータチューニング ハイパーパラメータチューニング機能の確認 モデルの作成 概要 概要 今回は、 Vertex AI Workbench を用いて JupyterLab の開発環境から BigQuery ML を使い K-means 法を用いたクラスタリングモデルを作成してみたいと思います。 Vertex AI Workbench とは、Vertex AI の機能の一つであり、 JupyterLab の開発環境が利用できます。 開発環境は マネージドノートブック と ユーザー管理のノートブック の 2 種類がありますが、今回はユーザー管理のノートブックを利用します。 Vertex AI Workbench を利用することで、BigQuery や Cloud Storage のデータへ容易にアクセスできたり、JupyterLab から BigQuery に対しクエリ発行も行うことができるため、データ移行の工数が削減でき開発スピードが上がります。 Vertex AI 全般について知りたい方は、以下の記事をご覧いただけますと幸いです。 blog.g-gen.co.jp また、以下の記事では BigQuery ML で 2 項ロジスティック回帰モデルの作成を行っております。 blog.g-gen.co.jp 以下の記事では BigQuery ML を詳細に解説していますので、ご参照ください。 blog.g-gen.co.jp 今回使用するデータ 今回は、筆者が塾の教師を務めている想定で、塾に通う生徒のクラス分けを行いたいと仮定します。 筆者の手元には、生徒の直近の テスト結果 (test_results.csv) があるとします。 A 列に生徒 ID が入り、B~F 列は各教科のテストの点数が入っています。 test_results.csv の中身 このデータをもとに、BigQuery ML の組み込みモデルの一つ、K-means モデルを用いていくつかのグループにクラスタリングを行ってみたいと思います。 K-means 法とは K-means 法とは互いに近いデータ同士を k 個のまとまりに分ける (クラスタリング) 手法を用いて、テスト結果データをもとに生徒をいくつかのクラスに分けたいと思います。 今回のように正解データ (教師データ) のない状態で、 学習データのみ をアルゴリズムに与え、データの特徴を求めることを 教師なし学習 といいます。 参考： k-means Clustering Algorithm 準備 Vertex AI Workbench の起動と BigQuery のテーブル作成は、 Cloud Shell 環境から gcloud コマンドを用いて行います。 Vertex AI Workbench の作成 以下のコマンドで Vertex AI Workbench の作成します。 # 環境変数の設定 export INSTANCE_NAME=<インスタンス名> # API の有効化 gcloud services enable notebooks.googleapis.com # Vertex AI Workbench の作成 gcloud notebooks instances create ${INSTANCE_NAME} \ --vm-image-project=deeplearning-platform-release \ --vm-image-family=caffe1-latest-cpu-experimental \ --machine-type=n1-standard-4 \ --location=asia-northeast1-a \ --machine-type=n1-standard-1 Vertex AI Workbench で作成するインスタンスについて、今回は Google が提供している Deep Learning VM Images から caffe1-latest-cpu-experimental イメージファミリーを選択しました。 その他利用可能な Deep Learning VM Images については以下をご覧ください。 参考： Listing all available versions BigQuery データセットとテーブルの作成 続いて、BigQuery の準備を行います。 はじめに、先程の成績データを CSV でローカルにダウンロードして、Cloud Shell にアップデートします。 その後、Cloud Shell 上に、schema.json というファイルを新規作成し、以下の json で定義したスキーマを記入します。 [ { " name ": " student_id ", " type ": " INTEGER ", " description ": " 生徒 ID " } , { " name ": " national_language ", " type ": " INTEGER ", " description ": " 国語の点数 " } , { " name ": " english ", " type ": " INTEGER ", " description ": " 英語の点数 " } , { " name ": " mathematics ", " type ": " INTEGER ", " description ": " 数学の点数 " } , { " name ": " science ", " type ": " INTEGER ", " description ": " 理科の点数 " } , { " name ": " sociology ", " type ": " INTEGER ", " description ": " 社会の点数 " } ] Cloud Shell 上のディレクトリが以下のように構成できれば必要なファイルの準備は揃っています。 . ├── test_results.csv └── schema.json 以下コマンドで BigQuery データセットとテーブルの作成を作成します。 # 環境変数の設定 export PROJECT_ID=<プロジェクトID> export DATASET_NAME=<データセット名> export TABLE_NAME=<テーブル名> # データセットの作成 bq mk --dataset --location=asia-northeast1 ${DATASET_NAME} # テーブルの作成 bq mk --table ${PROJECT_ID}:${DATASET_NAME}.${TABLE_NAME} schema.json # テーブルにデータをロード bq --location=asia-northeast1 load \ --source_format=CSV \ --skip_leading_rows=1 \ ${PROJECT_ID}:${DATASET_NAME}.${TABLE_NAME} test_results.csv JupyterLab 起動 それでは、JupyterLab を起動していきたいと思います。 Web コンソールから [Vertex AI ] > [ワークベンチ] > [ユーザー管理のノートブック] を選択し、先ほど作成した Vertex AI Workbench インスタンスの [Jupyterlab を開く] をクリックします。 以下の画面がでたら、Notebook の Python3 をクリックします。 JupyterLab画面① JupyterLab 画面② 実行 以降は、JupyterLab のノートブック内で以下のコマンドを実行して進めていきます。 データの確認 BigQuery に保存されたテーブルデータを確認します。 Vertex AI Workbench では、 %%bigquery (マジックコマンド)を用いることでノートブックファイル内から BigQuery に対しクエリを実行することができます。 %%bigquery SELECT * FROM `<プロジェクトID>.<データセット名>.<テーブル名>` ORDER BY student_id データの確認 ハイパーパラメータチューニング BigQuery ML で K-means クラスタリングモデルを作成する前に、何個 (k個) のクラスタに分けたいかユーザー側で決める必要があります。 今回は、BigQuery ML の ハイパーパラメータチューニング機能 を用いて k=2 or 3 or 4 の 3 つから適切な k を求めてみたいと思います。 %%bigquery CREATE OR REPLACE MODEL `<プロジェクトID>.<データセット名>.<モデル名>` OPTIONS ( MODEL_TYPE= ' KMEANS ' , KMEANS_INIT_METHOD= ' KMEANS++ ' , NUM_TRIALS= 3 , NUM_CLUSTERS=HPARAM_RANGE( 2 , 4 ), MAX_PARALLEL_TRIALS= 3 ) AS SELECT * EXCEPT(student_id) FROM `<プロジェクトID>.<データセット名>.<テーブル名>` CREATE OR REPLACE MODEL 構文を用いてモデルを構築していきます。 OPTIONS の中に各種パラメータを定義します。 model_type には [KMEANS] を選択します。 KMEANS_INIT_METHOD には [KMEANS++] を指定します。こちらは Centroid という重心となる点を最初にどのように決めるかを指定しています。 ハイパーパラメータチューニングでは、以下のオプションを追記します。 NUM_TRIALS で指定した数値分、探索してくれます。 NUM_CLUSTERS で [HPARAM_RANGE(min, max)] を指定することで min から max までの連続値でクラスタの数を調整してくれます。 MAX_PAEALLEL_TRAIALS で指定した数値分、並行で処理を行います。 参考： Hyperparameter tuning for CREATE MODEL statements ハイパーパラメータチューニング機能の確認 %%bigquery SELECT * FROM ML.TRIAL_INFO(MODEL `<プロジェクトID>.<データセット名>.<モデル名>`) ML.TRIAL_INFO 関数でハイパーパラメータチューニングの結果を確認します。 ハイパーパラメータチューニングの結果 num_clusters 列には各クラスタの数が入力されております。 hparam_tuning_evaluation_metrics 列には各クラスタ数でモデルを作成した際の評価指標である、 Davies–Bouldin 指標 が記載されています。この指標が小さいほど高品質なモデルとされています。 最後に、is_optimal 列では、今回のハイパーパラメータチューニングで最も適切なクラスタ数であるレコードに True が付きます。 ハイパーパラメータチューニングより、クラスタ数 3 の時 is_optimal が True となっていたので、今回はそのパラメータでモデルを作成してみたいと思います。 モデルの作成 以下のコマンドでモデルを作成します。 %%bigquery CREATE OR REPLACE MODEL `<プロジェクトID>.<データセット名>.<モデル名>` OPTIONS ( MODEL_TYPE= ' KMEANS ' , KMEANS_INIT_METHOD= ' KMEANS++ ' , NUM_CLUSTERS= 3 ) AS SELECT * EXCEPT(student_id) FROM `<プロジェクトID>.<データセット名>.<テーブル名>` モデルが作成できましたら、作成したモデルを使用し、先程のテスト結果データの 2 列目に centroid_id 列を追加し出力します。 この centroid_id がいわゆる各クラスタの ID のような位置づけとなります。今回ですと 3 つのクラスタに分けたので、centroid_id は 1~3 の値をとります。 %%bigquery SELECT student_id, CENTROID_ID AS centroid_id, national_language, english, mathematics, science, sociology FROM ML.PREDICT( MODEL `<プロジェクトID>.<データセット名>.<モデル名>`,( SELECT * FROM `<プロジェクトID>.<データセット名>.<テーブル名>` ) ) ORDER BY student_id モデルから推論を実行 また、centroid_id でグループ化し、各教科は平均点で集約させるクエリとその結果は以下となります。 %%bigquery SELECT CENTROID_ID AS centroid_id, ROUND ( AVG (national_language)) AS national_language, ROUND ( AVG (english)) AS english, ROUND ( AVG (mathematics)) AS mathematics, ROUND ( AVG (science)) AS science, ROUND ( AVG (sociology)) AS sociology FROM ML.PREDICT( MODEL `<プロジェクトID>.<データセット名>.<モデル名>`,( SELECT * FROM `<プロジェクトID>.<データセット名>.<テーブル名>` ) ) GROUP BY centroid_id ORDER BY centroid_id centroid_id に対する各教科の平均点 centroid_id によって分けられた 3 つのクラスタには、それぞれ以下のような特徴がありそうです。 centroid_id 特徴 1 全科目の点数にあまり差がない 2 比較的に数学と理科が高く、国語と英語が低い傾向にある 3 比較的に国語と英語が高く、数学と理科が低い傾向にある 上記より、[centroid_id = 1] のクラスには全科目の基礎硬めを、[centroid_id = 2] のクラスには比較的伸びしろが高い国語と英語、[centroid_id = 3] のクラスには数学と理科にそれぞれ重点をおいた授業を組むなど、 次回テストの点数 UP に向けた戦略 を練ることができるのかと思います。 このようなクラスタリング手法は、ビジネスにおいても自社の顧客分析や、競合他社との差別化戦略を考える際に使われたりと幅広く利用されています。 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Champion Innovator (AI/ML)。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリスト。好きな分野は生成 AI。 Follow @matayuuuu

G-gen の藤岡です。当記事では、Google Cloud（旧称 GCP）の Compute Engine（以下 GCE）のインスタンス名の重複について、2 種類の内部 DNS タイプの観点から深堀していきます。 はじめに インスタンス名の重複 検証結果 サービスの概要 メタデータサーバー GCE と内部 DNS 内部 DNS 内部 DNS タイプ 設定方法 確認方法 検証 前提条件 例外 作成コマンド 作成順序 結果 まとめ はじめに インスタンス名の重複 コンソールや gcloud コマンドで GCE インスタンスを作成する際に、以下のようなエラーが出る場合があります。これはインスタンス名が既存のものと重複している場合に表示されます。 ERROR: (gcloud.compute.instances.create) Could not fetch resource: - The resource 'projects/demo-project/zones/asia-northeast1-a/instances/my-instance' already exists コンソールのインスタンス名重複エラー 実際にはゾーンが異なる場合、 gcloud コマンドでは同じインスタンス名でインスタンスを作成することができます。但し、作成の際に留意すべき点があります。そこで今回は、2 種類の内部 DNS タイプの観点からこのエラーを深堀していきます。 同一インスタンス名 検証結果 結論から書くと、以下のような結果になりました。 両者の内部 DNS タイプが ゾーン DNS の時は、異なるゾーンにインスタンスを作成することができる 一方の内部 DNS タイプが グローバル DNS のときは、グローバル DNS インスタンスを先に作成すれば、次に ゾーン DNS のインスタンスを作成することができる このことから、インスタンス名の名前空間はゾーンである (しかしインスタンスの作成順によってはバリデーションに引っかかる) ということがわかりました。 ここから、詳細な検証の過程を記載していきます。 サービスの概要 メタデータサーバー メタデータサーバーには、GCE インスタンスに関する様々な情報である メタデータ が保存されています。メタデータは key:value の形で保存されており、適用範囲の異なる以下の 2 種類があります。 プロジェクトメタデータ： プロジェクト内のすべて の VM に適用 インスタンスメタデータ： 単一 の VM にのみ適用 さらにその中で、 デフォルトのメタデータ とユーザーが定義する カスタムメタデータ があります。詳細は以下の記事の「メタデータ」の項目をご参照ください。 blog.g-gen.co.jp 後述の「検証」の項目では、インスタンスメタデータで内部 DNS タイプを指定します。 GCE と内部 DNS GCE インスタンスを作成すると、 インスタンスメタデータ の hostname にインスタンス名やプロジェクト ID、ゾーン名等が含まれる完全修飾ドメイン名（以下 FQDN）が保存されます。 この FQDN は後述する内部 DNS タイプによって異なります。また、GCE インスタンスの命名規則は ドキュメント に記載の通りです。 内部 DNS 内部 DNS は、 同じネットワーク内 の仮想マシン（以下 VM）が内部 DNS 名で相互にアクセスができるようにするサービスで、 Virtual Private Cloud（VPC） の機能の 1 つです。 .internal の DNS ゾーンに VM の内部 A レコードが作成されます。 内部 DNS タイプ 内部 DNS タイプには、以下の 2 種類があります。 ゾーン DNS グローバル DNS デフォルトの内部 DNS タイプがどちらになるかは、 プロジェクトで Compute Engine API を有効にしたタイミング によって決まります。タイプ別の FQDN やプロジェクトのデフォルトは以下の表の通りです。 VM は ゾーンリソース です。個々のゾーンへの DNS 登録で発生した障害を分離するためにゾーン DNS が推奨されています。 内部 DNS タイプ FQDN プロジェクトのデフォルトタイプ 備考 ゾーン DNS < VM 名>.<ゾーン名>.c.<プロジェクト ID>.internal 2018 年 9 月 6 日以降 に Compute Engine API を有効にした組織またはスタンドアロンプロジェクトのデフォルトタイプ VM 名は 各ゾーンで一意 。ゾーンが異なる場合、同じ VM 名をつけることができる。 グローバル DNS < VM 名>.c.<プロジェクト ID>.internal 2018 年 9 月 6 日より前 に Compute Engine API を有効にした組織またはスタンドアロンプロジェクトのデフォルトタイプ VM 名は プロジェクト全体で一意 。 参考： 内部 DNS 名のタイプ 設定方法 2023 年 3 月時点で Google Cloud の利用を開始し、GCE インスタンスを作成すると上述の通り、内部 DNS タイプはゾーン DNS になります。但し、カスタムメタデータキーとして、 VmDnsSetting を設定することで内部 DNS タイプを指定することができます。 gcloud コマンドで GCE インスタンスを作成する場合、以下のオプションを追加することで内部 DNS タイプを指定できます。 グローバル DNS ： --metadata=VmDnsSetting=GlobalDefault ゾーン DNS ： --metadata=VmDnsSetting=ZonalOnly コンソール上からもメタデータの設定はできます。しかし、後述の「例外」の項目にある通り コンソールからは ゾーンに関わらず既存の GCE インスタンスと同じ名前は使えません 。 参考： プロジェクトまたは VM の DNS 名を構成する / gcloud compute instances create 確認方法 Linux の場合、以下のコマンドで GCE インスタンスの FQDN を確認できます。デフォルトで VM のメタデータサーバー（ 169.254.169.254 ）が名前解決します。 curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \ -H "Metadata-Flavor: Google" # 実行例 fujioka@my-instance:~$ curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \ -H "Metadata-Flavor: Google" my-instance.c.demo-project.internal fujioka@my-instance:~$ fujioka@my-instance:~$ curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \ -H "Metadata-Flavor: Google" my-instance.asia-northeast1-a.c.demo-project.internal fujioka@my-instance:~$ 参考： VM の内部 DNS 名を特定する 検証 内部 DNS タイプを明示的に指定し、同じインスタンス名で作成可能な組み合わせを検証していきます。 前提条件 CloudShell からコマンドを実行 作成するGCE インスタンスの OS は debian-11 インスタンス名は my-instance VPC やサブネットの構成は以下の通り 構成 例外 2023 年 3 月時点で、コンソール画面からはゾーンに関係なく、既存のインスタンス名と同じ名前の場合 名前 はすでに使用中です。 （英語表記： Name is already in use ）のエラーが表示されます。そのため、検証は gcloud コマンドで GCE インスタンスを作成します。 コンソールのインスタンス名重複エラー 作成コマンド ゾーンごと、内部 DNS タイプごとに以下の 4 種類のコマンドで GCE インスタンスを作成します。 ################################### ゾーン：asia-northeast1-a ################################### # ① 内部 DNS タイプ：ゾーン DNS # 作成される FQDN：my-instance.asia-northeast1-a.c.demo-project.internal gcloud compute instances create my-instance \ --machine-type=e2-micro \ --image-project debian-cloud \ --image-family debian-11 \ --zone asia-northeast1-a \ --network=demo-vpc \ --subnet=demo-subnet \ --metadata=VmDnsSetting=ZonalOnly # ② 内部 DNS タイプ：グローバル DNS # 作成される FQDN：my-instance.c.demo-project.internal gcloud compute instances create my-instance \ --machine-type=e2-micro \ --image-project debian-cloud \ --image-family debian-11 \ --zone asia-northeast1-a \ --network=demo-vpc \ --subnet=demo-subnet \ --metadata=VmDnsSetting=GlobalDefault ################################### ゾーン：asia-northeast1-b ################################### # ③ 内部 DNS タイプ：ゾーン DNS # 作成される FQDN：my-instance.asia-northeast1-b.c.demo-project.internal gcloud compute instances create my-instance \ --machine-type=e2-micro \ --image-project debian-cloud \ --image-family debian-11 \ --zone asia-northeast1-b \ --network=demo-vpc \ --subnet=demo-subnet \ --metadata=VmDnsSetting=ZonalOnly # ④ 内部 DNS タイプ：グローバル DNS # 作成される FQDN：my-instance.c.demo-project.internal gcloud compute instances create my-instance \ --machine-type=e2-micro \ --image-project debian-cloud \ --image-family debian-11 \ --zone asia-northeast1-b \ --network=demo-vpc \ --subnet=demo-subnet \ --metadata=VmDnsSetting=GlobalDefault 作成順序 結果は 作成順序によって結果が異なる ため、図にします。赤枠の縦軸のインスタンスを 1 つ作成し、それに対し横軸のインスタンスを 1 つ作成し結果を確認していきます。それを全ての縦軸のインスタンスごとに確認していきます。 グローバル DNS の場合、 ドキュメント に以下の記載があることから、表には 2 つの FQDN（ <VM 名>.<ゾーン名>.c.<プロジェクト ID>.internal / <VM 名>.c.<プロジェクト ID>.internal ）を記載しています。 VM がグローバルとゾーンの両方の DNS 名を登録するように VmDnsSetting=GlobalDefault を設定しますが、デフォルトのドメイン名と検索パスのエントリにはグローバル名のみを使用します。 作成順序 結果 結果は以下の表の通りです。項番ごとに結果と理由を確認していきます。 結果 項番 結果 理由 (1) 不可 FQDN が同じのため (2) 不可 グローバル DNS の場合は、ゾーン DNS 名も登録され FQDN が同じのため (3) 不可 グローバル DNS の場合は、ゾーン DNS 名も登録され FQDN が同じのため (4) 不可 FQDN が同じのため (5) 可 FQDN が異なるため (6) 不可 ※後述 (7) 可 ※後述 (8) 不可 FQDN が同じのため 以上の結果から、(6), (7) は作成ゾーンが異なり、FQDN も異なることからどちらも「可」となるはずが、(6) は「不可」となっています。その理由は、 ドキュメント の以下の部分です。 推奨: VmDnsSetting=ZonalOnly を設定すると、VM の参照はゾーン DNS 名でのみ可能になります。VM は引き続き、ゾーンとグローバルの両方の検索パスを保持しますが、グローバル DNS 名は機能しなくなります。 グローバル DNS 名は機能しなくなるということは、(6) で先にゾーン DNS によって my-instance.asia-northeast1-b.c.demo-project.internal が作成された後、そのグローバル DNS 名である my-instance.c.demo-project.internal は機能しなくなります。つまり、ゾーン DNS を作成した後にグローバル DNS を作成しようとするとエラーとなります。そのため、(7) では「可」だった結果が (6) では「不可」となります。 それに対して、(7) のように先にグローバル DNS によって my-instance.c.demo-project.internal が作成されている場合は、その後にゾーン DNS 名の my-instance.asia-northeast1-a.c.demo-project.internal を作成することができます。 まとめ 以上の結果から、同一インスタンス名で作成が可能なパターンは以下の通りです。 両者の内部 DNS タイプが ゾーン DNS の時に異なるゾーンにインスタンスを作成する 一方の内部 DNS タイプが グローバル DNS のインスタンスを先に作成し、次に ゾーン DNS のインスタンスを作成する このことから、インスタンス名の名前空間はゾーンである (しかしインスタンスの作成順によってはバリデーションに引っかかる) ということがわかりました。 なお補足すると、あくまで推奨の内部 DNS タイプはゾーン DNS であり、現在はデフォルトの設定もゾーン DNS となっています。今回は検証のため、グローバル DNS も設定し確認しました。 藤岡 里美 (記事一覧) クラウドソリューション部 接客業からエンジニアへ。2022年9月 G-gen にジョイン。Google Cloud 認定資格は全冠。2023 夏アニメのオススメは、ダークギャザリング。箏を習っています :) Follow @fujioka57621469