G-gen の佐々木です。当記事では Google Cloud（旧称GCP） のサーバレスコンピューティングサービスである Cloud Run functions を使用して、 Google Compute Engine (GCE) インスタンスからマシンイメージを定期的に取得する方法 を紹介します。 Cloud Run functions の概要については以下の記事をご一読ください。 blog.g-gen.co.jp マシンイメージとは 今回のテーマ 構成図 関数のサービスアカウントに必要な権限 Pub/Subトリガーの Cloud Run functions 関数を作成 requirements.txt の中身 main.py の中身 Cloud Scheduler ジョブの設定 ジョブの実行結果 料金について その他 イメージの削除 本番運用時の考慮事項 マシンイメージとは マシンイメージ とは、 GCE インスタンスの プロパティ、メタデータ、権限、接続されている全てのディスクのデータを格納するリソース で、インスタンスの複製やバックアップに使用することができます。 Amazon Web Services (AWS) の EC2 における AMI (Amazon Machine Image) 機能 によく似たリソースです。Google Cloud では今年1月に一般公開となりました。 マシンイメージはディスクの スナップショット と異なり、複数のディスクを含めたインスタンス全体の構成情報を保存するため、インスタンスの複製や復元を より手軽 に行うことができます。 今回のテーマ GCE では、ディスクのスナップショットは スナップショットスケジュール を使用することで定期的な取得が可能です。しかしながらマシンイメージの方では、スケジュールを設定することは できません 。 そこで Compute Engine APIのクライアントライブラリ を用いて、マシンイメージ取得の API を呼び出すコードを Cloud Run functions 関数に実装します。 この関数を定期実行することでマシンイメージの取得を自動化することができます。 今回は Python 用のクライアントライブラリを使用して Cloud Run functions 関数を作成していきます。 構成図 Pub/Sub トリガーの Cloud Run functions を使用します。処理の流れは以下の通りです。 マシンイメージの定期取得 - 構成図 Cloud Scheduler で cron を設定し、指定した時間に Pub/Sub に対してメッセージをパブリッシュします。 Pub/Sub にメッセージがパブリッシュされると、Pub/Sub トリガーにより Cloud Run functions 関数が呼び出されます。 Cloud Run functions 関数のコードから Compute Engine API を呼び出し、GCE インスタンスのマシンイメージを取得します。 a, bは Cloud Run functions 関数を用いた定期実行処理の基本形なので、様々なタスクに応用することができるでしょう。 関数のサービスアカウントに必要な権限 Cloud Run functions 関数から他の Google Cloud リソースを操作する場合、 サービスアカウント に必要なロールをアタッチし、そのサービスアカウントを関数に設定します。 マシンイメージの作成には最低でも以下の権限が必要です。（ 参考 ） プロジェクトに対する compute.machineImages.create 権限 対象となるインスタンスへの compute.instances.useReadOnly 権限 ディスクへの compute.disks.createSnapshot 権限 事前定義されたロール を使用する場合、マシンイメージの作成には最低でも Compute インスタンス管理者 のロールを付与しなければならないので、本番運用する場合はカスタムロールを作成することをおすすめします。 Pub/Subトリガーの Cloud Run functions 関数を作成 今回は単純な処理なので、コンソール上から Cloud Run functions 関数を作成していきます。 Cloud Run functions のコンソールから [関数の作成] をクリックし、 関数の作成 画面に進みます。 ① 基本 項目では、任意の関数名とリージョンを設定します。 ② トリガー 項目でトリガーのタイプを Cloud Pub/Sub に設定し、新たに Pub/Sub トピックを作成していきます。 Cloud Run functions 作成画面から Pub/Sub トピックを作成 ③Pub/Sub トピックの作成画面が表示されるので、トピック ID を入力して [トピックを作成] をクリックします。 トピックの作成 ④作成した Pub/Sub トピックを設定し、 [保存] をクリックします。 Pub/Sub トピック設定後、完了をクリック ⑤ ランタイム、ビルド、接続、セキュリティの設定 を開き、 ランタイム タブの ランタイム サービス アカウント 項目で Cloud Run functions 関数用に作成したサービスアカウントを選択します。選択後、 [次へ] をクリックします。 事前作成したサービスアカウントの設定 ⑥コードの編集画面に進むので、 ランタイム を Python 3.9 に設定し、この画面から、あらかじめ存在する main.py と requirements.txt の2つのファイルを編集していきます。 ランタイムを Python に設定 requirements.txt の中身 ここに追記した外部ライブラリは、関数内で使用することができるようになります。 今回は Compute Engine API のクライアントライブラリを追記するだけで OK です。 # Function dependencies, for example: # package>=version google-cloud-compute==1.3.2 main.py の中身 Pub/Sub トリガーの場合、デフォルトでは hello_pubsub 関数の部分から実行されます。 今回はマシンイメージ取得対象の GCE インスタンスの情報をコード内に直接記述していますが、複数のインスタンスで使用したい場合は、バックアップ対象一覧のファイルを別途用意したり、バックアップ対象であることを示すラベルがついたインスタンスの一覧を取得する処理を入れたりするのが良いでしょう。 また 同名のマシンイメージは取得できない ため、取得日をマシンイメージの名前末尾に付与する処理を入れています。 from google.cloud.compute_v1.services.machine_images import MachineImagesClient from google.cloud.compute_v1.types import MachineImage, InsertMachineImageRequest from datetime import datetime, timezone, timedelta # マシンイメージ取得対象インスタンスの情報 project_id = '{プロジェクトID}' # 対象インスタンスが存在するプロジェクトID instance_name = '{インスタンス名}' # 対象インスタンスの名前 instance_zone = '{ゾーン}' # 対象インスタンスが存在するゾーン # インスタンスの情報をURL形式にする url = f 'https://www.googleapis.com/compute/v1/projects/{project_id}/zones/{instance_zone}/instances/{instance_name}' def hello_pubsub (event, context): client = MachineImagesClient() # マシンイメージの名前末尾に付与する日付の情報 (UTC→JSTの変換もここで実施) today = datetime.now(timezone(timedelta(hours= 9 ))).strftime( '%Y-%m-%d' ) # マシンイメージ取得リクエストの中身 mimg_info = MachineImage( name = f 'mimg-{instance_name}-{today}' , # マシンイメージの名前 source_instance = url # 取得対象インスタンスの情報 ) mimg_request = InsertMachineImageRequest( project = project_id, machine_image_resource = mimg_info ) # マシンイメージの取得 client.insert( request = mimg_request ) コードの編集が終わったら、画面右下の [デプロイ] をクリックし、関数のデプロイが完了するまで数分待ちます。 Cloud Scheduler ジョブの設定 Cloud Run functions 関数を作成する際に一緒に作成した Pub/Sub トピックに対し、定期的にメッセージを送るジョブを設定します。 ①Cloud Scheduler のコンソール画面に移動し、 [ジョブを作成] をクリックします。 ② ジョブの作成 画面の各項目を入力していきます。 頻度 項目は cron 式 でジョブの実行間隔を指定します。それぞれ入力したら [続行] をクリックします。 Cloud Scheduler スケジュールを定義 ③ 実行内容を構成する では、ターゲット タイプとして Pub/Sub を選択し、Cloud Run functions 関数作成時に作成した Pub/Sub トピックを設定します。 メッセージ本文も必須項目になっていますが、今回は特にメッセージ内容は問わないので適当に入力してください。 全て入力したら [作成] をクリックします。 Cloud Scheduler 実行内容の構成 ここまで設定が完了すれば、Cloud Scheduler が指定された時間に Pub/Sub トピックにメッセージを送信し、Pub/Sub から Cloud Run functions 関数がトリガーされます。指定した時間になるのを待ちましょう。 待ち切れない場合はコンソールからジョブを手動実行することも可能です。（ 操作 から ジョブを強制実行する をクリックしてください） ジョブの実行結果 コンソールからジョブの実行結果を確認します。 前回の実行結果 が 成功 になっていれば OK です。 Cloud Scheduler ジョブの実行結果 ジョブの成功を確認したら、 Compute Engine のコンソールでマシンイメージ一覧を開きます。 作成されたマシンイメージが一覧に表示されるはずです。 作成されたマシンイメージの確認 このままでは毎日マシンイメージが作成されるので、検証目的であれば Cloud Scheduler のジョブを停止、もしくは削除するのを忘れないようにしましょう。 料金について マシンイメージを作成するまでの処理を実行するリソースは全て サーバレス であり、インフラを管理する必要がありません。そして、この程度の処理内容であれば僅かな課金で済むでしょう。 今回の処理に使用したサービスの料金を以下に記載します。 サービスの種類 料金 備考 Cloud Scheduler ジョブ1つあたり $0.10/月 毎月ジョブ3つまで無料（プロジェクトではなくアカウント単位の個数） Cloud Pub/Sub データ量1 TB あたり $40.00/月 最初の10 GB まで無料 Cloud Run functions こちらの記事 を参照 今回のケースでは月30回ほどの実行 また、ここで作成されるマシンイメージについては便利である反面、スナップショットと比べると料金が割高になる欠点もあります。 以下は asia-northeast1（東京リージョン）にそれぞれ作成した場合の料金です。（ 参考 ） タイプ 料金 スナップショット 1 GB あたり$0.034/月 マシンイメージ 1 GB あたり$0.065/月 料金を少しでも節約したい場合は、今回紹介した仕組みを応用し、マシンイメージ名の日付情報を用いて古いものを定期的に削除するなど、マシンイメージの世代管理の仕組みを用意することも必要となるでしょう。 その他 イメージの削除 マシンイメージの定期的な削除の仕組みは、以下の記事で紹介されています。 blog.g-gen.co.jp 本番運用時の考慮事項 前掲の記事 Cloud Run functionsを使用してCompute Engineのマシンイメージを自動で削除する の 考慮事項 の項に、本番運用時の留意事項が記載されています。当記事にも共通して言える内容ですのでご参照ください。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

こんにちは、G-genの開原です。当記事では Google Cloud が提供する Looker と データポータル （英名 Data Studio、旧称 Looker Studio）という2つのデータ可視化サービスの特徴についてご紹介した上で、選定のポイントを解説します。 Looker とデータポータル Looker とは データポータルとは 名称の変遷 データ分析における課題 Looker の特徴 データのアップロード不要 LookML によるデータの一元管理 豊富な業務連携 データポータルの特徴 無料で魅力的なダッシュボード 簡単・すぐに始められる手軽さ 多様なデータソース 機能比較と選定基準 機能比較 選定基準 データポータル Pro Looker とデータポータル Looker とは Looker は Google Cloud が提供する次世代型の「データプラットフォーム製品」です。 「データプラットフォーム製品!？BIツールじゃないの？」と思う人もいることでしょう。 Looker は一般的には BI ツールのカテゴリーに分類されますが、単純な BI ツールではありません。 LookML という独自のモデリング言語を記述することで データの一貫性やガバナンス を担保することができる製品です。 組織の全員が LookML でモデリングされた値や計算式を利用してデータ分析や可視化をするようになるため、 全員が同じ分析結果を得る ことができるようになります。 また Looker は、チャットツールや E メール、セールスフォース オートメーション製品との連携により、 データ分析と業務をシームレス （繋ぎ目なし） に連携させる 機能を多数備えています。 このように、Looker において BI（可視化）部分はあくまで機能の一部分に過ぎないと言えます。 参考 : Lookerの概要 データポータルとは データポータル （英名 Data Studio、旧称 Looker Studio）とは、Google Cloud が提供する完全クラウドベースのダッシュボードツールであり、基本的に 無料 で利用することができます。 データポータルを使うことで、Google アナリティクスや Google スプレッドシート等、様々なデータソースへの接続が可能であり、SQL 等の専門知識がなくても直感的にダッシュボード作成が可能です。無料とは思えない高機能なグラフや表を使ってダッシュボードを作成することができます。 Google アカウントさえあれば、基本的に無料ですぐに利用することが可能ですので、 簡単に使い始められる 点が特徴です。 参考 : データポータルへようこそ データポータルには有償アップグレード版の データポータル Pro （旧称 Looker Studio Pro）も存在しています。当記事では詳細には取り扱いませんので、以下の記事もご参照ください。 blog.g-gen.co.jp 名称の変遷 データポータルは以前、 Looker Studio と呼ばれていました。しかし、さらにそれ以前は現在と同様、「英名: Data Studio / 和名: データポータル」という名称でした。 2022年10月の Google Cloud Next '22 でデータポータルは「Looker Studio」に名前が変更され、Looker ブランドに統一されました。この変更により Looker と Looker Studio の2つの製品が存在する状態になり、混乱を呼びました。 しかし再度、2026年4月に「英名: Data Studio / 和名: データポータル」に戻りました。 日本では商標の関係で「Data Studio」という名称が使えないため「データポータル」と表記されています。 データ分析における課題 Looker とデータポータルの特徴について説明する前に、データ分析における一般的な課題について取り上げたいと思います。 自組織のデータ活用には、どのような課題があるでしょうか。まずはそこに着目し、これからご紹介する Looker とデータポータルの特徴が どのように課題にアプローチできるか に着目して、製品を選定することになります。 データが集約されておらず各システムのデータベースに分散している データは集まっているが、それを可視化するツールがない データベースへの問い合わせるためのクエリ（SQL）を書くスキルのある人がいない データ集計の計算式が人によって異なり、分析結果にずれが生じている 同じようなレポートが複数作られていて、どれが正しいか分からない BI ツールを各部署で個別に導入・管理しており、全体最適ができていない Looker の特徴 データのアップロード不要 Looker は独自のデータベースを持ちません。データウェアハウス等のデータソースに直接、都度アクセスして、自動生成された SQL でデータを取得するため、リアルタイムに 最新のデータを取得 することが可能です。 ただし、これには処理速度の早いデータベースを利用することが前提です。Google Cloud の BigQuery や Amazon Web Services （AWS）の Redshift、Snowflake などが想定されます。 LookML によるデータの一元管理 LookML という独自のデータモデリング言語によって 指標 （Measure）を集中管理するため、ユーザごとのデータのずれがなくなり、 データの一貫性を担保 することが可能です。 なお指標とは、ここでは「店舗別日次売上」「DAU（Daily Active User）」など、ビジネス判断のために用いられる数字を意味しています。このように管理された指標の管理レイヤを指して セマンティックレイヤ と呼ぶこともあります。 もしも複数のレポートで使われている指標の集計方法に変更があったとしても、各レポートに手を加える必要はなく、LookML にのみ手を加えれば良いので、 メンテナンスコストが低く なります。 また LookML は Git によるバージョン管理ができるため、いつ、だれが、何のために、何を変更したのかが明確になります。 豊富な業務連携 既存の SaaS や E メールなどと連携した業務フローを作り上げることが可能です。 例えば LookML で定義された指標に対して分析官がデータ探索を行い、その結果を E メールや Slack に シームレスに （Looker の画面を離れることなく） 連携 してビジネス部門に依頼をすることなどが可能です。 また iframe で自社ポータルサイトへ Looker のダッシュボードを配置することなどが可能なほか、 API 連携による柔軟な追加開発も可能です。 データポータルの特徴 無料で魅力的なダッシュボード 原則的に 全機能が無料 で利用可能です。ただし閲覧や権限管理のために Google アカウントが必要なため、利用者が50名を超えるなど、場合によっては有償の Google Workspace や Cloud Identity 契約が必要になります。 データポータルでは、無料とは思えないほど高機能でリッチなビジュアルを実現できます。 簡単・すぐに始められる手軽さ Web ブラウザ上の 簡単な操作 で表やグラフを追加可能です。SQL やプログラミング等の専門知識は不要です。 最初は慣れが必要なものの、ある程度習熟すれば、エンジニアではないビジネスユーザーでも自在にダッシュボードを作ったり、データベースの中身を探索できるようになります。 また、Looker と同じく、データポータルでもデータのアップロードは行いません。データポータルは、データベースに対して常に最新の情報を取得しますので、データを転送する前準備が必要ありません。 多様なデータソース 手元にある csv（カンマ区切りファイル）や Google Sheets（Google スプレッドシート）をデータソースとしてそのまま利用することができます。それ以外にも多くの データコネクタ があり、BigQuery、Redshift、Snowflake、MySQL などに対応しています。これによりデータ取得のイニシャルコストを大幅に削減可能です。 データポータルがどのデータソースに対応しているかは公式の コネクターギャラリー をご参照ください。以下にごく一部のみを挙げます。 BigQuery Amazon Redshift Azure Synapse Snowflake MySQL PostgreSQL Microsoft SQL Server Google Analytics Google Ads Google Sheets なお前述のとおり、Looker の特徴にも記載した「データのアップロード不要」という特徴はデータポータルでも同様です。データポータルでは、常にデータソース上の最新のデータが参照されます。 機能比較と選定基準 機能比較 以下は、それぞれの主要機能や特徴の比較表です。 項目 Looker データポータル 製品の目的 データドリブンな業務の実現 データ活用基盤の構築 現状分析、可視化 利用規模 組織全体からの関係者まで （パートナー、お客様） 小規模（特定の少人数） モデリング インスタンス全体を一元管理 ダッシュボード毎に定義 データソース データベース 500以上のデータソース (CSV、 Google スプレッドシート、 Google Analytics 等) データ ディクショナリ LookMLで定義可能 なし 権限設定・ セキュリティ ユーザー・グループ単位で アクセス制限可能 なし バージョン管理 Git によるバージョン管理 レポートの版管理が可能 データ連携 SaaS への埋め込み ifame 埋め込み Rest API 等 iframe 埋め込み URL 埋め込み アラート 任意条件でメールや Slack に通知 なし スケジューリング メール、ウェブフック、 Amazon S3、 SFTP サーバ等へ定期配信 メールへの定期配信 利用料金 有償 無償 選定基準 ここまでにご紹介した特徴や機能を踏まえて、製品選定する際の評価例をまとめました。 選定基準 Looker データポータル データ活用基盤を構築したい ◎ ◯ すぐに手軽にデータ分析を始めたい ◎ 組織全体でデータ分析をしたい ◎ ◯ 組織外にも共有したい ◎ ◯ 既存のワークフローを活用したい ◎ メンテナンスを効率化したい ◎ 安価に利用したい ◎ データポータルは原則無料で操作が簡単ですので、 小規模な BI 導入 や これからデータ分析を始める組織 に向いています。 一方で Looker は LookML の学習コストやライセンス料金の点で導入のハードルは高いながらも、 中〜大規模利用 に最適です。企業全体でのデータ分析基盤の構築や、新たなデータ文化を作っていきたい等の 明確なビジョン を持っている組織には大変魅力的となります。 データポータル Pro データポータル Pro（旧称 Looker Studio Pro）はデータポータルの有償版であり、IAM と統合された権限管理や技術サポート窓口での対応が追加されています。よりエンタープライズ向け機能が強化された製品が、データポータル Pro であると言えます。 詳細は以下の記事を参照してください。 blog.g-gen.co.jp 開原 大佑 (記事一覧) クラウドソリューション部 2022年5月にG-gen にジョイン。 前職までは関東を中心として、全国の医療機関へのシステム導入、運用保守を担当。現在は、Looker案件を中心に担当。Google Cloud スキルアップに向けて勉強中。

G-gen の杉村です。 Python のライブラリである pandas (パンダス) は、データ分析に用いられるツールとして有名です。 当記事では BigQuery から取得したデータを pandas で操作する方法をご紹介します。ごく基本的な内容ですが、コーディング時のメモとして、また Python による BigQuery データを扱う際の練習等にご利用ください。 基本編では簡単なテストデータを使いながら、 SQL での SELECT や 集計関数 + GROUP BY に相当する操作を確認します。 環境準備 gcloud コマンド python および関連ライブラリ テストデータの準備 BigQuery データセットおよびテーブルの作成 Python の実行 データフレームの準備 パッケージのインポート BigQuery からデータを取得 データフレームのプレビュー・射影・フィルタ プレビュー 射影 (SELECT) フィルタ (SELECT 〜 WHERE 〜) 一意の行を抽出 (SELECT DISTINCT) 集計 (最大値・最小値・平均値) データフレーム全体に対する集計 特定カラムごとの集計 (GROUP BY) 各行に対して操作 環境準備 gcloud コマンド 当記事の作業は、お使いの環境で gcloud コマンド が使えることが前提です。 インストールされていない場合、マニュアル Cloud SDK のインストール に従いインストールしてください。 インストールできたら gcloud init コマンドを実行し、プロジェクト情報等を設定します。 python および関連ライブラリ 当記事で利用する各種 SDK 、ライブラリの実行には Python 3.6 以上が必要です (2022 年 5 月現在) 。 Python や pip のインストール方法は、当記事では省略させていただきます。 必要なライブラリは、以下のコマンドでインストールしてください。インストールするのは pandas 、 BigQuery 等のための pandas のデータ型拡張ライブラリである db_dtypes 、 BigQuery 用 SDK である google-cloud-bigquery の 3 つです。 # pip にて必要なパッケージのインストール pip install --upgrade pandas pip install --upgrade db_dtypes pip install --upgrade google-cloud-bigquery テストデータの準備 今回は以下のような非常に簡単なカンマ区切りのデータを用意しました。 当記事に沿ってハンズオンする方は all_score.csv としてローカルにファイルとして保存してください。 class,name,subject,score 1,佐藤,国語,80 1,佐藤,数学,60 1,佐藤,英語,50 1,田中,国語,70 1,田中,数学,90 1,田中,英語,90 2,鈴木,国語,40 2,鈴木,数学,20 2,鈴木,英語,30 2,伊藤,国語,90 2,伊藤,数学,40 2,伊藤,英語,80 BigQuery データセットおよびテーブルの作成 テスト用のデータセットを作成します。ロケーションやデータセット名 ( ここでは my_test ) は適宜、任意の値に置き換えてください。 # テスト用のデータセット作成 bq mk --dataset --location=asia-northeast1 my_test テスト用データを投入するテーブルを作成します。テーブル名等は適宜、任意の値に置き換えてください。 以下のコマンドを実行すると、テストデータの csv ファイルが BigQuery のテーブルとしてロード (読み込み) されます。 # テストデータのテーブル作成 bq --location=asia-northeast1 load \ --source_format=CSV \ --skip_leading_rows 1 \ my_test.all_score \ ./all_score.csv \ class:INT64,name:STRING,subject:STRING,score:INT64 以下のようにコマンド実行すると、テーブルの中身がプレビューできます。 bq head my_test.all_score $ bq head my_test.all_score +-------+------+---------+-------+ | class | name | subject | score | +-------+------+---------+-------+ | 1 | 佐藤 | 国語 | 80 | | 1 | 佐藤 | 数学 | 60 | | 1 | 佐藤 | 英語 | 50 | | 1 | 田中 | 国語 | 70 | | 1 | 田中 | 数学 | 90 | | 1 | 田中 | 英語 | 90 | | 2 | 鈴木 | 国語 | 40 | | 2 | 鈴木 | 数学 | 20 | | 2 | 鈴木 | 英語 | 30 | | 2 | 伊藤 | 国語 | 90 | | 2 | 伊藤 | 数学 | 40 | | 2 | 伊藤 | 英語 | 80 | +-------+------+---------+-------+ Python の実行 以下のコマンドを実行することで 自分の Google アカウントで認証 して、その権限で Python SDK から API を実行することができるようになります。 コマンドを実行するとブラウザが開くので、 Google アカウントを選択して認証を行ってください。 # 認証情報を取得して Python SDK から利用できるようにする gcloud auth application-default login このコマンドを実行すると ~/.config/gcloud/application_default_credentials.json に認証情報ファイルが生成されます。 なお上記を実行しない場合は サービスアカウント を発行して秘密鍵を含んだ認証情報 JSON ファイルをダウンロードし、以下のコマンドで認証情報ファイルを指定する必要があります。 export GOOGLE_APPLICATION_CREDENTIALS=${PATH_TO_CREDENTIAL_FILE} 上記のいずれかで認証方法を決めたら、 python を実行します。 # 環境の設定内容により python もしくは python3 python3 データフレームの準備 パッケージのインポート pip でインストール済みのパッケージをインポートします。 # 必要なパッケージのインポート import pandas import db_dtypes from google.cloud import bigquery BigQuery からデータを取得 BigQuery からデータを取得し データフレーム と呼ばれるオブジェクトとして格納します。 データフレームとは、 表形式のデータを扱うためのオブジェクト であり、行と列を持つことができる形式です。 # クライアント インスタンス生成 client = bigquery.Client() # クエリ実行とデータフレーム取得 query_str = """ SELECT class, name, subject, score FROM my_test.all_score """ df = client.query(query_str).to_dataframe() 最後の行でクエリ文字列を実行 ( Google Cloud に対して API を実行 ) し、 データフレーム として変数 df に格納しています。 もし権限エラーが出た場合は、Google アカウントが対象プロジェクト (対象データセット) にて BigQuery ジョブユーザー + BigQuery データ閲覧者 + BigQuery 読み取りセッション ユーザー などのロールと紐付いているかご確認ください。検証環境であればプロジェクトに対する BigQuery 管理者 や オーナー でも問題ないでしょう。 ここからはデータフレームの操作を試してみます。 データフレームのプレビュー・射影・フィルタ プレビュー print 等で中身をプレビューすることができます。 量が多い場合は、中盤が自動的に省略して表示されます。 >>> print(df) class name subject score 0 1 佐藤 国語 80 1 1 佐藤 数学 60 2 1 佐藤 英語 50 3 1 田中 国語 70 4 1 田中 数学 90 5 1 田中 英語 90 6 2 鈴木 国語 40 7 2 鈴木 数学 20 8 2 鈴木 英語 30 9 2 伊藤 国語 90 10 2 伊藤 数学 40 11 2 伊藤 英語 80 射影 (SELECT) 以下のようにカラム名を指定することでデータフレームを射影 (SELECT) することができます。 >>> df['name'] 0 佐藤 1 佐藤 2 佐藤 3 田中 4 田中 5 田中 6 鈴木 7 鈴木 8 鈴木 9 伊藤 10 伊藤 11 伊藤 Name: name, dtype: object 複数列を指定する際は角括弧を二重に重ねます。 >>> df[['class', 'name']] class name 0 1 佐藤 1 1 佐藤 2 1 佐藤 3 1 田中 4 1 田中 5 1 田中 6 2 鈴木 7 2 鈴木 8 2 鈴木 9 2 伊藤 10 2 伊藤 11 2 伊藤 フィルタ (SELECT 〜 WHERE 〜) 角括弧の中に条件文を記載することでフィルタすることが可能です。 >>> df[(df.score > 50)] class name subject score 0 1 佐藤 国語 80 1 1 佐藤 数学 60 3 1 田中 国語 70 4 1 田中 数学 90 5 1 田中 英語 90 9 2 伊藤 国語 90 11 2 伊藤 英語 80 以下のように & でつなげることで複数条件を指定できます。 >>> df[(df.score > 50) & (df.subject == "国語")] class name subject score 0 1 佐藤 国語 80 3 1 田中 国語 70 9 2 伊藤 国語 90 フィルタしたデータフレームに角括弧を続けることで射影が可能です。 >>> df[(df.score > 50) & (df.subject == "国語")]['name'] 0 佐藤 3 田中 9 伊藤 Name: name, dtype: object なお単一のカラムを射影することで得られたオブジェクトは Series 型 です。データフレーム (DataFrame) が 2 次元の表を扱う形式であるのに対して Series は 1 次元を扱う形式です。 以下のように for に渡すことで一つ一つ処理することも可能です。 >>> series = df[(df.score > 50) & (df.subject == "国語")]['name'] >>> for row in series: ... print(row) ... 佐藤 田中 伊藤 一意の行を抽出 (SELECT DISTINCT) 以下のようにすることでデータフレームに対して、 SQL で言うところの SELECT DISTINCT を行うことができます。 >>> df[~df.duplicated(subset=['class', 'name'])][['class', 'name']] class name 0 1 佐藤 3 1 田中 6 2 鈴木 9 2 伊藤 なぜこんなに長いのか、分解していくと理解することができます。 まず df.duplicated(subset=['class', 'name']) だけを実行すると class と name の組み合わせで 前の行で出てきたことのある組み合わせを持つ行 のインデックスが True になります。 つまり False は初めて現れる組み合わせの行ということです。 >>> df.duplicated(subset=['class', 'name']) 0 False 1 True 2 True 3 False 4 True 5 True 6 False 7 True 8 True 9 False 10 True 11 True dtype: bool 先頭に ~ をつけると True/False が逆転します。 >>> ~df.duplicated(subset=['class', 'name']) 0 True 1 False 2 False 3 True 4 False 5 False 6 True 7 False 8 False 9 True 10 False 11 False dtype: bool df[] の中に先の文を入れると、 True の行だけを抽出してくれます。 >>> df[~df.duplicated(subset=['class', 'name'])] class name subject score 0 1 佐藤 国語 80 3 1 田中 国語 70 6 2 鈴木 国語 40 9 2 伊藤 国語 90 この結果はデータフレームであり、角括弧をつけて必要な列だけを射影することができます (最初の実行結果です) 。 >>> df[~df.duplicated(subset=['class', 'name'])][['class', 'name']] class name 0 1 佐藤 3 1 田中 6 2 鈴木 9 2 伊藤 集計 (最大値・最小値・平均値) データフレーム全体に対する集計 データフレームに対して .max() .min() .mean() メソッドを用いることでそれぞれ最大値、最小値、平均値を取得できます。 >>> df.max() class 2 name 鈴木 subject 英語 score 90 dtype: object >>> df.min() class 1 name 伊藤 subject 国語 score 20 dtype: object >>> df.mean() <stdin>:1: FutureWarning: Dropping of nuisance columns in DataFrame reductions (with 'numeric_only=None') is deprecated; in a future version this will raise TypeError. Select only valid columns before calling the reduction. class 1.500000 score 61.666667 dtype: float64 >>> >>> # 警告が出ないよう数値の列のみに適用。先のコマンドは、将来的にエラーとなる >>> df[['class','score']].mean() class 1.500000 score 61.666667 dtype: float64 必要な列の値のみ欲しい場合、以下のようにして得られます。 1つ目のコマンドと 2 つ目のコマンドは同じ結果となっていますが、データ量が多い場合は後者のほうが、先に射影したデータフレームに対して集計を行うためパフォーマンスが良くなる可能性が考えられます。 >>> df.max()['score'] 90 >>> >>> df['score'].max() 90 特定カラムごとの集計 (GROUP BY) 以下のようにして特定カラムで group by して集計することが可能です。 >>> df_grouped = df.groupby(['class', 'subject']) >>> df_grouped.max() name score class subject 1 国語 田中 80 数学 田中 90 英語 田中 90 2 国語 鈴木 90 数学 鈴木 40 英語 鈴木 80 この結果ですと、関係のない name も出力されてしまっています。以下のようにして必要な値のみを取得できます。 >>> df_grouped.max()['score'] class subject 1 国語 80 数学 90 英語 90 2 国語 90 数学 40 英語 80 Name: score, dtype: Int64 >>> df_grouped.max()['score'][1] subject 国語 80 数学 90 英語 90 Name: score, dtype: Int64 >>> df_grouped.max()['score'][1]['国語'] 80 各行に対して操作 データフレームは for 等に渡すことができますが、データフレームは列方向にデータを持つオブジェクトです (カラムナ) ので、これだと順に列名が渡されます 。 >>> for column in df: ... print(column) ... class name subject score これは多くの場合、やりたいことと異なるはずです。各行に操作を行いたい場合、以下のように itertuples() メソッドが利用できます。 >>> for row in df.itertuples(): ... print(row) ... Pandas(Index=0, _1=1, name='佐藤', subject='国語', score=80) Pandas(Index=1, _1=1, name='佐藤', subject='数学', score=60) Pandas(Index=2, _1=1, name='佐藤', subject='英語', score=50) Pandas(Index=3, _1=1, name='田中', subject='国語', score=70) Pandas(Index=4, _1=1, name='田中', subject='数学', score=90) Pandas(Index=5, _1=1, name='田中', subject='英語', score=90) Pandas(Index=6, _1=2, name='鈴木', subject='国語', score=40) Pandas(Index=7, _1=2, name='鈴木', subject='数学', score=20) Pandas(Index=8, _1=2, name='鈴木', subject='英語', score=30) Pandas(Index=9, _1=2, name='伊藤', subject='国語', score=90) Pandas(Index=10, _1=2, name='伊藤', subject='数学', score=40) Pandas(Index=11, _1=2, name='伊藤', subject='英語', score=80) ここで取り出して変数 row に入っている値は namedtuples という型です。 値は [n] または .(列名) で取り出すことができます。 >>> for row in df.itertuples(): ... print(row[3] + " ←これらは同じ意味→ " + row.subject) ... 国語 ←これらは同じ意味→ 国語 数学 ←これらは同じ意味→ 数学 英語 ←これらは同じ意味→ 英語 国語 ←これらは同じ意味→ 国語 数学 ←これらは同じ意味→ 数学 英語 ←これらは同じ意味→ 英語 国語 ←これらは同じ意味→ 国語 数学 ←これらは同じ意味→ 数学 英語 ←これらは同じ意味→ 英語 国語 ←これらは同じ意味→ 国語 数学 ←これらは同じ意味→ 数学 英語 ←これらは同じ意味→ 英語 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

Cloud Digital Leader 試験は Google Cloud（旧称 GCP）の認定資格の中でも最も基礎的な内容を扱う試験です。試験対策や出題傾向について解説します。 基本的な情報 Cloud Digital Leader とは Cloud Digital Leader の難易度 体験記 試験対策方法 1. IT 基礎知識の習得 2. 公式の試験ガイドで試験範囲を把握する 3. Google Cloud の関連書籍を読む 4. 公式の模擬試験を受験で感覚を掴む 5. 模試試験で得たギャップを再学習する 出題範囲・出題傾向 概要 セクション1 : Google Cloud によるデジタルトランスフォーメーション IT インフラの基本 クラウドテクノロジー 新しいテクノロジーとビジネス セクション2 : Google Cloudによるデータトランスフォーメーションの探求 データの役割・データドリブン文化 スマートアナリティクス セクション3 : Google CloudのAIを活用したイノベーション Google Cloud の AI サービス TPU と GPU セクション4 : Google Cloudによるインフラストラクチャとアプリケーションのモダナイゼーション IT インフラストラクチャのモダナイズ アプリケーションのモダナイズ サーバーレス API の価値 セクション5 : Google Cloudで実現する信頼とセキュリティ セキュリティの基本 責任共有モデル セクション6 : Google Cloud運用でのスケーリング クラウドにおける財務ガバナンス クラウド運用 カスタマーケア 組織 合格したら 基本的な情報 Cloud Digital Leader とは Cloud Digital Leader 試験は Google Cloud（旧称 GCP）の「基礎の基礎」を理解しているかどうか問われる試験です。 Google Cloud 認定資格の中で 最も基礎的な資格 であり、 Google Cloud の世界に足を踏み入れたいエンジニアのみならず、 SIer の営業担当、クラウド利用企業の経理担当、新社会人など、幅広い人におすすめできる試験となっています。 試験内容は Google Cloud に限定されていません。 オンプレミス環境と比べたクラウドのメリット や 一般的な情報セキュリティ に関する問いも出題されます。 出題の幅は広いですが、深い知識までは問われないため、Google Cloud を中心に IT やクラウドについて 浅く、広い知識 を身につける必要があると言えます。 試験時間は90分、問題数は50問です。テストセンター（オンサイト）かオンライン（遠隔監視）のどちらでも受験することが出来ます。 参考 : Cloud Digital Leader Cloud Digital Leader の難易度 Cloud Digital Leader の難易度は 比較的低い と言えます。情報処理推進機構（IPA）の「IT パスポート試験」程度の IT 基礎知識を前提に、パブリッククラウドや Google Cloud について基礎的な学習を行えば、合格は難しくありません。 認定試験ガイドには「Cloud Digital Leader の認定試験は特定の職に就いていることを条件とせず、Google Cloud の実務経験も必要ありません。」とあります。このことから、 クラウド入門者に適した資格 といえるでしょう。 しかし、繰り返しになりますが「IT パスポート試験」程度の IT の基礎知識は必要 です。クライアント、サーバー、ネットワーク、IP アドレスといった IT の基本的な用語を、自分の言葉で説明できるでしょうか。当試験の学習がなかなかはかどらないと感じたら、これらの IT 基礎知識を身につけることを検討してください。 体験記 以下の記事は、G-gen 社のセールスメンバーが当試験を受験した体験記です。 非エンジニアが当試験を勉強するためのヒントになりますので、ぜひご参照ください。 blog.g-gen.co.jp 試験対策方法 あくまで一例となりますが、以下の方法で試験の対策が可能です。 1. IT 基礎知識の習得 もし受験者が、IT 全般の初心者である場合は、IPA（独立行政法人情報処理推進機構）の国家資格である IT パスポート や 基本情報技術者試験 など、初級レベルの IT 資格を学習することをおすすめします。 必ずしも受験、合格まで目指す必要はありません。基礎知識の習得は、今後の IT 人生や社会人生活において有用なはずです。 2. 公式の試験ガイドで試験範囲を把握する 本試験の出題内容と出題範囲を 試験ガイド で確認しましょう。 試験ガイドには 出題範囲が記載 されてます。一字一句、意味を考えながら熟読することをおすすめします。 3. Google Cloud の関連書籍を読む 以下の書籍が例に挙げられます。Google Cloud の書籍は、これ以外にも数多く出版されています。必ず1冊は熟読するようにしましょう。 書籍名 説明 合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題 Cloud Digital Leader の参考書です。クラウド基礎知識に加えて、試験合格のための知識が得られます。模擬問題も収録されています。 図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書 全編オールカラーで図解が多く、Google Cloud の主要サービスが丁寧に解説されています。 参考書籍 1. 合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題 2. 図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書 4. 公式の模擬試験を受験で感覚を掴む 公式ページから 模擬試験 を 無料 で受けることが可能です。 模擬試験は20問で、最後にフィードバックを確認できます。間違った問題だけでなく正解した問題もきちんと解説を読むことで、理解が進みぐっと合格へ近づくことが出来ます。 また、前述の参考書にも、模擬問題が掲載されています。 正答以外の選択肢に登場したものを含めて、サービスの概要や特徴は理解しておくと良いでしょう。 5. 模試試験で得たギャップを再学習する 模擬試験の解説で、理解が足りない部分があれば 書籍に戻り再学習 します。 ただ各サービスの概要を理解することだけではなく、 各サービスに適したユースケース （使われる場面）を理解していることが重要です。そのサービスを使うと「誰が、なぜ嬉しいのか」という点が重要になります。 教科書の内容を丸暗記するのではなく、本質的な理解を心がけましょう。 出題範囲・出題傾向 概要 当記事ではこれ以降、 試験ガイド をベースにして、出題の傾向について解説します。 関連する Google Cloud の公式ページへのリンクも併記しますので、勉強の方針決めや、受験前の最後の仕上げとしてご利用いただければ幸いです。 これ以降の記述は、ある程度の技術的な基礎知識があることを前提にしています。以下に登場する用語がわからない場合、Google 検索や書籍などを使ってその用語を理解できるように知識を強化してください。 セクション1 : Google Cloud によるデジタルトランスフォーメーション IT インフラの基本 クライアント、サーバー、ネットワーク、IP アドレス、レイテンシ、Web アプリケーション、DNS、といった IT の基本的な用語を理解しておいてください。 クラウドテクノロジー パブリッククラウド、データ分析、デジタルトランスフォーメーション、IaaS、PaaS、SaaS などの 主要な用語の意味 は理解しておきます。 参考: Google Cloud を選ぶ理由 またクラウド導入を検討する際、 リフト&シフト という言葉が取り上げられることがあります。 企業がオンプレミスに所有する既存の IT 資産を、まずはそのままクラウドの仮想サーバー等に移行することを「 リフト （クラウドに持ち上げる）」と表現しています。 まずリフトを実現し、その後、よりクラウドの強みを活かしたアーキテクチャに変換することを「 シフト 」と呼びます。リフトしてからシフトする、というのが一種のベストプラクティスとなっています。 新しいテクノロジーとビジネス クラウドと従来のオンプレミスの違いを言えるでしょうか。どんなことがオンプレミスだと実現が出来ないのか、またどんなことがクラウドだと実現できるのか、という点が問われます。 一般的に言われるパブリッククラウドの利点は、以下でしょう。 パブリッククラウドでは ハードウェアの調達が不要 開発の アジリティが向上 （スピードが上がる） 情報システムの TCO （Total Cost of Ownership = 総所有コスト） が低下 セクション2 : Google Cloudによるデータトランスフォーメーションの探求 データの役割・データドリブン文化 クラウドを使うことでデータにどのような価値が生まれ、どのようなメリットが企業や利用者に生まれるのかが問われます。特に以下の用語を把握しておいてください。 データレイク データウェアハウス 構造化データ ・ 非構造化データ これらの用語について分かりやすく解説された Web サイトが多数あるので、まずはそちらを参照するのがよいでしょう。 ポイントとして、こういった「分析用途で使われるデータベース」と「業務用のアプリケーションで使われるデータベース」は 違う仕組み であるという点は押さえておきましょう。 関連する Google Cloud サービスとしては Cloud Storage 、 BigQuery などがあります。それぞれ、どのような役割を担っているのか、理解します。 以下は、参考ドキュメントです。 参考 : データクラウド 参考 : Cloud Storage(GCS)を徹底解説 - G-gen Tech Blog 非常に簡単に言うと Google Cloud では 非構造化データは Cloud Storageに 、 構造化データは BigQuery に 入れるというのが基本となります。もし「構造化データ」や「非構造化データ」について、自分の言葉で説明できないと感じた場合、これらの用語をきちんと調べ、自分の言葉で説明できるようになっていることが望ましいです。 スマートアナリティクス Google Cloud のデータベースサービスには Cloud SQL、BigQuery、Cloud Spanner など、多数のサービスがあります。それぞれの サービスの特徴や特性を理解 して、ユースケースに合致したサービスを選択できるようにする必要があります。 データベース系サービスとユースケースを、以下に簡単に列挙します。 サービス名 ユースケース Cloud SQL ・高い費用対効果でリレーショナルデータベース（RDB）をクラウドに移行したい ・MySQL / PostgreSQL / SQL Server などをクラウドに移行したい Cloud Spanner ・世界（リージョン）をまたいで同期する、ミッションクリティカルでトランザクション処理が可能なリレーショナルデータベース BigQuery ・構造化データを保存し、分析するための分析用データベース この表を見て「リレーショナルデータベース」「ミッションクリティカル」「トランザクション処理」「構造化データ」「同期（レプリケーション）」といった用語が分からないことに気がついた場合、調べて理解することをおすすめします。クラウドに限らず、 IT 一般知識として有用です。 上記のサービス名と、ユースケースに出てくるキーワードが頭の中で結びついていれば、複数の問題に回答できるはずです。 参考 : スマート アナリティクス ソリューション 参考 : Cloud SQLを徹底解説！ 参考 : Cloud Spanner を徹底解説！ 参考 : BigQueryを徹底解説！(基本編) セクション3 : Google CloudのAIを活用したイノベーション Google Cloud の AI サービス Google Cloud の機械学習や AI サービスについて、 サービス名と一般的なユースケースを理解 しておきましょう。 機械学習とは、 本来は人間の認知力が必要な作業を、コンピューターに代わりに行わせる ための技術です。 例えば Google Cloud では Cloud Vision API というサービスが公開されています。このサービスに画像を読み込ませると、「写真にどんなオブジェクト（犬、風船、車...）が映っているか」「写真の中の顔や企業ロゴの検出」「画像内のテキスト検出」などを行わせることができます。 機械学習では一般的に、「 学習 」という作業が必要です。教師データを読み込ませる等して、機械学習の頭脳である「 モデル 」を構築する必要があります。しかし Google Cloud の Vision API では学習が必要ありません。 Vision API は、 Google が持つ大量のデータを使って既に学習済みです。我々利用者は、この学習済みのモデルに仕事を投げるだけでよいので、 機械学習の専門的な知識は必要ありません 。 一方で、そういった Google の一般的なデータを使って学習済みのモデルでは、ニーズを満たせないこともあります。工場の生産ラインで、不良品を検知したいような場合、大量の「不良品の写真」「正常な製品の写真」を使ってカスタムなトレーニングを行い、独自のモデルを作りたいはずです。 そのような場合は AutoML Vision といったサービスが役に立ちます。AutoML では、教師データさえあれば、簡単な操作で学習・モデル構築を行うことができます。 また AutoML では飽き足らず、独自のモデル、独自のアルゴリズムなどを用いたい場合、 Vertex AI を使うことができます。 このように Google Cloud には実装難易度の異なる3段階（画像認識で言えば Vision API / AutoML Vision / Vertex AI）の AI サービスが存在しています。 また、BigQuery ML では、BigQuery に対する SQL の知識をベースに、AI/ML を利用することができます。 TPU と GPU Google Cloud では、機械学習のために、 GPU や TPU が提供されています。 TPU は、Google が開発した機械学習向けのプロセッサです。Tensorflow、PyTorch、JAX などのフレームワークで利用可能であり、このような AI/ML フレームワークが使われている場合は、TPU の利用を検討します。 セクション4 : Google Cloudによるインフラストラクチャとアプリケーションのモダナイゼーション IT インフラストラクチャのモダナイズ 「モダナイズ（modernize）」とは近代化・現代化を意味する英語の動詞です（名詞形はモダナイゼーションです）。暗にオンプレや従来型のシステムアーキテクチャを "旧" 、クラウドやコンテナなど新しいアーキテクチャを "新" として、クラウド移行をきっかけに IT インフラやアプリケーションを現代的に再構築することを意味しています。 Google Cloud では以下のようなサービスを IT インフラとして利用することができます。 Compute Engine Google Kubernetes Engine Cloud Run functions Cloud Run App Engine 参考 : インフラストラクチャのモダナイゼーション アプリケーションのモダナイズ 「 コンテナ 」や「 サーバーレス 」といった用語に馴染みがあるでしょうか。もしなければ、これを機に、検索する等して調べてみてください。概要だけでも大丈夫です。 コンテナを活用するための代表的なサービスが Google Kubernetes Engine （GKE）です。アプリケーションをコンテナ化し、 GKE に移行することで「 アプリケーション開発の高速化 」「 スケーラビリティ （拡張性） の向上 」などのメリットを得ることができます。 参考 : アプリケーションのモダナイゼーション また、 マイクロサービス という用語も出題されます。意味について調べ、マイクロサービスがもたらすメリットを理解してください。 サーバーレス Cloud Run functions や Cloud Run も出題範囲です。いずれもサーバーレスなサービスではありますが、例えば イベントドリブン なシステムであれば、Cloud Run functions が適切です。一方で単一コンテナをベースとした Web アプリであれば、Cloud Run が望ましいといえます。 参考 : Cloud Run functionsを徹底解説！ 参考 : Cloud Run を徹底解説！ API の価値 API とは何か 、また API をアプリケーションに用意することで、 どのようなメリット が生まれるのか理解しておきましょう。 API の意味を調べると、色々な情報が出てきて混乱するかもしれません。 API とは Application Programming Interface の略であり、当試験で指す API は概ね Web API のことであり「アプリケーションに外部からアクセスするための出入り口。そこからデータを出したり、入れたりできる」と理解して差し支えありません。 API という「出入り口」をアプリケーションに用意することで、他のアプリケーションとのデータ連携が リアルタイムに行える などのメリットがあります。以下の公式ページから辿ると API を使用することのメリットが分かりやすく解説されています。 参考 : API とアプリケーション アプリケーションに API を実装するための Google Cloud ソリューションとして Apigee API Management があります。 セクション5 : Google Cloudで実現する信頼とセキュリティ セキュリティの基本 以下のようなキーワードを理解しておいてください。 認証、認可、監査 DDoS（Google Cloud Armor） ゼロトラストセキュリティ データ主権 責任共有モデル クラウドサービスで 責任共有モデル を正しく理解しましょう。責任共有モデルは Google Cloud に固有の言葉ではなく、多くのクラウドサービスで一般的に使われる用語です。 どこまでがクラウド事業者側の責任範囲で、どこからが利用者側の責任範囲なのか正しく理解しましょう。 簡単に言うと IaaS では 「ハードウェアの管理（導入、保守、セキュリティ）」まで がクラウド事業者の責任です。一方で「クラウドサービスを使ったインフラのアーキテクチャ」「サービスの設定などによるセキュリティ」「OS やミドルウェア」「アプリケーション」などは 利用者の責任 となります。この責任範囲は IaaS / PaaS / SaaS により、異なります。 参考 : セキュリティ基盤のブループリント そして、各 Google Cloud でサービスで責任共有モデルが具体的に何を意味するかも、把握しておきます。 例えば「Compute Engine では利用者はどこまで責任があるのか」「Cloud SQL では」など、それぞれのサービスにおいて責任分界点を把握しておきます。 IaaS である Compute Engine では「 OS から上のレイヤ 」は全て 利用者の責任 です。OS やミドルウェアのインストール、セキュリティの維持、ソフトウェアの開発などです。 一方で PaaS である Cloud SQL や App Engine では、ハードウェアに加えて OS ・ミドルウェアレベルまで Google の責任です。利用者は アプリケーションやデータベース だけが責任範囲となります。 上記の責任共有モデル以外にも、 Google Cloud のセキュリティについて紹介している公式ページがあります。以下には必ず目を通しておきましょう。 参考 : 信頼とセキュリティ セクション6 : Google Cloud運用でのスケーリング クラウドにおける財務ガバナンス オンプレミスとクラウドでの、費用の違いについて理解しましょう。オンプレミスのような固定費用ではなく、クラウドは 使った分だけの従量課金 です。 また、以下のキーワードを押さえてください。 クラウド導入で TCO （Total Cost of Ownership = 総所有コスト） を低減 できる TCO 低減はシステム投資に対する ROI （Return on Investment: 投資収益率） の向上 に寄与する オンプレミスとクラウドのコストの性質の違い オンプレミスはサーバー買い切りからの減価償却、つまり CapEx（資本的支出） である クラウドを利用するということは、毎月変動する経費的な支出であり OpEx（経費的支出） である CapEx（資本的支出） や OpEx（経費的支出） というキーワードについては、検索して理解しておきましょう。 クラウド運用 IT 運用に関する以下の用語は、意味をざっくりでよいので、押さえてください。 CI/CD （Continuous Integration / Continuous Delivery） DevOps Site Reliability Engineering（ SRE ） 上記の言葉を調べると、以下の用語に出会います。以下の用語も、意味を簡単に説明できるくらいに理解しておく必要があります。 SLA （Service Level Agreement） SLO （Service Level Objective） SLI （Service Level Indicator） エラーバジェット 以下に、参考となるドキュメントへのリンクを配置します。ただしこれらの公式ページは翻訳文であることもあり、予備知識がないと理解しづらいでしょう。インターネットを検索して、日本語の分かりやすい記事で予備知識をつけてから、改めて公式ページを学ぶのが良さそうです。 参考 : 継続的インテグレーション（CI） 参考 : 継続的デリバリー 参考 : サイト信頼性エンジニアリング（SRE） SRE は Google の提唱する、サービス運用管理体制の概念です。オライリーから重厚な書籍も発行されています。技術的な点が注目されがちですが、重要なのはそのマインドです。「批判しない文化」「継続的な改善」など、ポイントとなる概念がいくつかあります。 カスタマーケア Google Cloud には、顧客からの質問を受け付ける窓口である カスタマーケア があります。 ベーシック、スタンダード、エンハンスト、プレミアムとプランが分かれており、それぞれの初回応答時間、TAM（Technical Account Manager）の有無などを把握しておきましょう。 参考 : Google Cloud カスタマーケア 組織 Google Cloud には 組織 の概念があります。以下の記事を参考にしてください。 blog.g-gen.co.jp 合格したら Cloud Digital Leader 試験に合格したら、次はぜひ Associate Cloud Engineer 試験 に挑戦してください。 他の Google Cloud 認定資格や対策方法については、以下の記事で紹介されています。 blog.g-gen.co.jp 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、あとはゴルフと筋トレ。 Follow @ggenyutakei 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの佐々木です。当記事では Google Cloud の Cloud Run functions （旧 Cloud Functions）について解説します。 Cloud Run functions の基本 Cloud Run functions とは 最長実行時間 リブランディング サーバーレス サポートされている言語 ユースケース 関数の種類 2種類の関数 HTTP トリガー イベントトリガー ロギング Cloud SDK の利用 Cloud SDK のユースケース Cloud SDK の認証 モジュールの依存関係 料金 第1世代 第1世代の料金の基本 関数の呼び出し回数 関数の実行時間 データ転送料金 関数のイメージの保存 料金例 第2世代 第2世代の料金の基本 料金例 制限 関連情報 G-gen Tech Blog 疎結合アーキテクチャ 公式ドキュメント Cloud Run functions の基本 Cloud Run functions とは Cloud Run functions （旧 Cloud Functions）とは Google Cloud（旧称 GCP）が提供するサーバーレスのコンピューティングサービスです。ユーザーがサーバーやコンテナをプロビジョニング、管理することなくクラウド上でコードを実行することができます。いわゆる FaaS（Function as a Service） と呼ばれるプロダクトです。 HTTP リクエストをトリガにして起動する HTTP 関数 や 、特定のイベントが発生するとコードが実行される イベントトリガー関数 としてデプロイでき、トリガとなるイベントによって Web API やリアルタイム ETL 処理、定期実行タスクなど様々な使い道があります。 他のクラウドベンダーの類似サービスとして AWS の AWS Lambda 、 Microsoft Azure の Azure Functions などがあります。 Cloud Run functions には第1世代と第2世代があり、現在では後発の第2世代を使うことが強く推奨されます。Cloud Run functions 第2世代では基盤となる仕組みとして Google Cloud のサーバーレスコンテナ実行サービスである Cloud Run が使われています。 参考 : デプロイ オプションとリソースモデル - 関数 参考 : 関数を Cloud Run にデプロイするタイミング 最長実行時間 Cloud Run functions（第2世代）の最長実行時間は 60分間 です。ただし Cloud Run functions（第1世代）の場合は9分間であり、より短い処理の実行が想定されています。 なお、以前は Cloud Run functions（第2世代）の最長実行時間は HTTP 関数で60分間、イベントトリガー関数で10分間と関数の種類により差がありましたが、2025年10月現在、差はなくどちらも60分間になっています。 参考 : 割り当て - 時間に関する上限 リブランディング 2024年8月22日（日本時間）、Cloud Functions は Cloud Run functions としてリブランディングされました。これに伴い、名称は以下のようになりました。 旧称 新名称 Cloud Functions（第1世代） Cloud Run functions（第1世代） Cloud Functions（第2世代） Cloud Run functions 当記事では便宜上、従来 Cloud Functions（第2世代）と呼ばれていたものを Cloud Run functions（第2世代）と記載している箇所があります。 リブランディングについては、以下の記事も参照してください。 blog.g-gen.co.jp サーバーレス Cloud Run functions はいわゆる サーバーレス （Serverless）なコンピューティングサービスです。 Serverless という語は「サーバーのない」という意味になりますが、実際には Google の各リージョンのデータセンターにサーバーが存在しています。ここでのサーバーレスとは、ユーザーが 「サーバーの存在を意識することなく」 コードを実行できることを意味します。 Cloud Run functions では、サーバーのプロビジョニング、スケールアップ、メンテナンス等の管理を全て Google に任せ、ユーザーはその上で動かすコードの開発のみに集中することができます。 ユーザーがコードをデプロイした後、その実行がトリガーされると、実行環境が即座にプロビジョニングされ、また必要に応じて自動でスケーリングします。 サポートされている言語 2024年8月現在、Cloud Run functions では以下の言語（ランタイム）がサポートされています。 Node.js Python Go Java Ruby PHP .NET 最新のサポート状況については、以下の公式ドキュメントをご参照ください。 参考 : Supported language runtimes and base images ユースケース Cloud Run functions のユースケースを紹介します。[公式ドキュメント](にも代表的なものがいくつか紹介されているので、併せてご確認ください。 参考 : Cloud Run functions - ユースケース 以下はPub/Subトリガーの関数を用いた、Compute Engineインスタンスの自動停止・起動の仕組みとなります。 GCEインスタンスの自動停止・起動 Cloud Schedulerでcronを設定し、指定した時間にPub/Subに対してメッセージをパブリッシュします。 Pub/Subにメッセージがパブリッシュされると、Pub/SubトリガーによりCloud Run functions関数が呼び出されます。 Cloud Run functions関数のコードからCompute Engine APIを呼び出し、Compute Engineインスタンスを停止もしくは起動します。 上記の処理の中で、ユーザーが行わなければならないのはコードの記述と各サービスの設定のみとなっており、各サービスの設定は慣れていれば30分もかからないくらい簡単なものとなっています。 このような非常に少ない手間で決められた処理を実行することができる点が、Cloud Run functions の魅力です。 関数の種類 2種類の関数 Cloud Run functions にデプロイしたコード（これ以降は Google のドキュメントに倣い、「 関数 」と表記します）の実行をトリガーするイベントとして、大きく分けて HTTP トリガー とイベントトリガーの2種類があります。 HTTP トリガー HTTP トリガーでは、関数をデプロイした際に発行されるエンドポイント URL に対して、 HTTP リクエストが送信されることで関数が実行 されます。 HTTP の呼び出しは同期的で、関数の実行結果は HTTP リクエストのレスポンスとして呼び出し元に返されます。 イベントトリガー イベントトリガーでは HTTP トリガーのような URL は発行されず、関数が存在するプロジェクト内の イベントに応答する形で実行 されます。代表的なものとしては以下のトリガーがあります。 トリガー名 説明 Eventarc トリガー Cloud Run functions（第2世代）では原則、イベントトリガー関数は Eventarc トリガーとして実装されます。第1世代では利用できません。 Pub/Sub トリガー Pub/Sub トピックにパブリッシュされたメッセージによって関数がトリガーされます。 Cloud Storage トリガー Cloud Storage オブジェクトの作成、更新、削除などのイベントによって関数がトリガーされます。 Cloud Firestore トリガー Firestore ドキュメントの作成、更新、削除などのイベントによって関数がトリガーされます。第1世代のみ。 Cloud Storage のイベントをトリガにして起動する Cloud Run functions について以下の記事で取り上げていますので、ご参照ください。 blog.g-gen.co.jp ロギング Cloud Run functions では標準出力に出力されたテキストデータは、自動的に Cloud Logging に送出され、コンソール画面や API コールで取り出せるようになります。 Python を例に取ると print() や logger で出力された文字列が、自動的に Cloud Logging に送られます。 しかしこの方法ですと Cloud Logging 上でログレベル表記に反映されないなどの問題があります。 Cloud Run functions（Python）におけるロギングについて記載した以下の記事も、ご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp Cloud SDK の利用 Cloud SDK のユースケース Cloud Run functions の最も多いユースケースの一つは、関数内で Cloud SDK を用いて他の Google Cloud API を呼び出して操作を行うことです。 例えば、以下の記事のように、 Compute Engine API をコールして VM のバックアップを自動化すること等が考えられます。他にも Cloud Storage のオブジェクトを操作することなども一般的に行われています。Cloud Fucntions と Cloud SDK は切っても切れない関係性にあると言えます。 blog.g-gen.co.jp Cloud SDK の認証 Google Cloud API をコールするには認証・認可が必要です。 Cloud Run functions に サービスアカウント というプログラム専用の Google アカウントをアタッチすることができます。 Cloud Funcitons で Cloud SDK を実行すると、自分にアタッチされているサービスアカウントの認証情報で API コールを実行してくれます。 モジュールの依存関係 Cloud Run functions のプログラムから、Cloud SDK を始めとしたランタイム組み込みではないモジュールを呼び出すときは、依存関係にあるモジュールをデプロイパッケージに含ませる必要があります。 利用例が多い Python を例に取ると、以下の2つの方法があります。 main.py と同じディレクトリに requirements.txt ファイルを配置する (デプロイ時に自動的にインストールされる) zip 化したデプロイパッケージに依存関係ファイルを含ませる Cloud Run functions のランタイムにはデフォルトで組み込まれているパッケージもあり、各言語ごとに異なります。詳細は、以下のドキュメントをご参照ください。 参考 : Python での依存関係の指定 各言語ごとのドキュメントは左部メニューから遷移可能 料金 第1世代 第1世代の料金の基本 Cloud Run functions (第1世代) の料金は以下の項目によって決まります。（ 公式ドキュメント ） 関数の呼び出し回数 関数の実行時間 データ転送料金（関数によって送信ネットワークリクエストが作成された場合） 関数のイメージの保存（Container Registry利用料） それぞれ安価かつ月ごとの無料枠も存在するため、先のユースケースで紹介したような使い方であれば、ほとんど、あるいは全く課金されることなく使用することができるでしょう。 関数の呼び出し回数 関数を実行した回数に応じた課金となります。 呼び出し回数（1ヶ月あたり） 料金（100万回あたり） 最初の200万回 無料 200万回を超えた分 $0.40 呼び出し料金は1回あたり$0.0000004円と非常に安価であり、そのうえ 1ヶ月のうち最初の200万回は無料で呼び出すことが可能 です。 関数の実行時間 関数の呼び出しから完了までの時間に応じた課金となります。 Cloud Run functionsでは関数のデプロイの際、関数が使用できるメモリ容量を7段階から指定することができます。 指定したメモリ容量に応じてvCPUが割り当て られ、また単価も高くなります。 また、リージョンごとに Tier 1 と Tier 2 に料金設定が分かれており asia-northeast1 (東京リージョン) は Tier 1 となります ( 参考 ) 。 メモリ vCPU 料金/100 ms（Tier 1 料金） 料金/100 ms（Tier 2 料金） 128 MB .083 vCPU (200MHz) $0.000000231 $0.000000324 256 MB 0.167 vCPU (400MHz) $0.000000463 $0.000000648 512 MB 0.333 vCPU (800MHz) $0.000000925 $0.000001295 1,024 MB 0.583 vCPU (1.4GHz) $0.000001650 $0.000002310 2,048 MB 1 vCPU (2.8GHz) $0.000002900 $0.000004060 4,096 MB 2 vCPU (4.8GHz) $0.000005800 $0.000008120 8192 MB 2 vCPU (4.8GHz) $0.000006800 $0.000009520 こちらの無料枠は少々分かりづらいのですが、メモリの使用時間とvCPUの使用時間に分かれており、以下のようになっています。 1ヶ月あたり400,000 GB秒（GB秒 = 1GBのメモリを使用した場合の1秒）のメモリ使用 1ヶ月あたり200,000 GHz 秒（GHz秒 = 1GHzのCPUを使用した場合の1秒）のvCPU使用 データ転送料金 関数から外に送られるデータのサイズに応じて課金されます。ただし同一リージョン内の Google API に対する送信は無料です。別リージョンの API を呼んだり、インターネットへ通信をするサイズに課金されます。 タイプ 料金/GB 送信データ $0.12 受信データ 無料 同じリージョン内のGoogle APIへの送信データ 無料 こちらは、 1ヶ月あたり5GBのデータ送信までが無料枠 となっています。 関数のイメージの保存 関数はデプロイされると Container Registry または Artifact Registry にコンテナイメージとして保存されるため、保存したイメージの容量分だけ課金されます。デフォルトではイメージファイルが Container Registry に保存されます。 1GBあたり Container Registry の場合は$0.026/月、 Artifact Registry の場合は$0.10/月（こちらは0.5GBまで無料）です。 料金例 試しに、以下の条件で料金を計算してみます。 計算には Google Cloud Pricing Calculator を使用します。 関数の呼び出し回数 → 300万回 / 月 関数の実行時間 → 1,000ms / 回 関数に割り当てるメモリ容量 → 256 MB Google Cloudのリージョン内で完結する処理（asia-northeast1を使用） この条件では、1ヶ月あたり $ 4.40 となります。 第2世代 第2世代の料金の基本 Cloud Run functions（第2世代）は Cloud Run を基盤としているため、 Cloud Run の料金 が適用されます。 実行時間ごとの料金 (CPU/Memory) + リクエスト数ごとの料金 + データ転送料金 + イメージの保存料金がかかる点で、原則は第1世代と同じです。 vCPU は毎月最初の 180,000 vCPU 秒、メモリは最初の 360,000 GiB 秒、リクエスト数は毎月 200 万リクエストまでが無料枠として用意されています。 また第2世代ではイメージの保存に Container Registry は使われず、 Artifact Registry の保管料金が適用されます。 料金例 第1世代の料金例と同条件で試算してみます。 関数の呼び出し回数 → 300万回 / 月 関数の実行時間 → 1,000ms / 回 関数に割り当てるメモリ容量 → 256 MB Google Cloudのリージョン内で完結する処理（asia-northeast1を使用） この条件では、1ヶ月あたり $0.40 となります。 制限 Cloud Run functions の制限事項 はいくつかありますが、その中から特に重要なものだけ抜粋します。 制限対象 上限 備考 最長実行時間 9分 (第1世代) / 60分 (第2世代) 上限を過ぎた場合は関数がタイムアウトとして強制終了されます。 最大同時実行数 3,000 同じ関数を同時に実行できる数 最大呼び出しレート 1,000 / 秒 同じ関数が秒間あたりに応じられるリクエストレート 重要なポイントとして Cloud Run functions の最大実行時間は、第1世代で 9分 、第2世代で 60分 です。このことから Cloud Run functions は 処理時間が長いバッチ処理には向かない ことが分かります。そのような場合は60分以上の処理が実現できる Cloud Run jobs 等、別のサービスを検討することになります。 関連情報 G-gen Tech Blog ローカル PC 環境における Cloud Run functions 検証に関する記事もありますので、併せてご一読いただければと思います。 blog.g-gen.co.jp blog.g-gen.co.jp 疎結合アーキテクチャ Cloud Run functions などのサーバーレスプラットフォームを利用して実現可能な疎結合アーキテクチャについて、以下の記事もご参照ください。 blog.g-gen.co.jp 公式ドキュメント 参考 : Cloud Run functions 公式ドキュメント 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

はじめまして。6月にG-genにジョインした佐々木です。 私はこれまでにAWSのEC2やGoogle CloudのCompute Engineなど、クラウドの仮想マシンサービスに触れる機会が多くありました。 今回はその仮想マシンサービスに関する、まれに起こるからこそ困ってしまう事象について書こうと思います。 当ブログではGoogle CloudのCompute Engineを題材としますが、AWSのEC2やAzureのAzure VMでも同様の事象が起こり得ます。 原因や対処法についても大きく変わることはないでしょう。 事象 原因と対処 原因 対処① インスタンスの起動を再度試してみる。 対処② マシンタイプを変えて起動してみる。 対処③ 別のゾーンにインスタンスを起動する。 対処④ サポートを利用する。 予防策 参考 事象 Compute Engineを利用していると、こんな経験をすることがあります。 昨日の夜に止めるまではちゃんと動いていたインスタンスが、朝になって起動できなくなった！ 新しくインスタンスを立てようとしたけど、エラーが出て起動できない！ こういった場合、Google Cloudのコンソールには以下のような表示が出ているかもしれません。 "The zone 'projects/{プロジェクトID}/zones/{ゾーン名}' does not have enough resources available to fulfill the request. Try a different zone, or try again later." コンソール右上の通知 コンソール下部の通知 また、Cloud Loggingにはインスタンス起動を試みた時刻に以下のようなログが残っているでしょう。（以下、Cloud Loggingから抜粋） "message": "ZONE_RESOURCE_POOL_EXHAUSTED", 原因と対処 原因 エラー文に書いてある通りなのですが、 Google Cloudの特定ゾーン内にインスタンスを起動するためのキャパシティがない 場合にこのエラーが発生します。 クラウドサービスはユーザーが物理的なインフラを意識することなく利用することができますが、当然、クラウドベンダーのデータセンターにはサーバーが存在しています。 インスタンスを停止してデータセンター内のリソースを解放しているうちに、他のユーザーがそのリソースを使ってしまい、昨日まで使えていたリソースが無くなっているという、クラウドサービス特有の事象と言えるでしょう。 より単純化して説明すると、クラウドベンダーがユーザーに貸し出しているサーバーが、一時的に在庫切れを起こしてしまっている状況です。 対処① インスタンスの起動を再度試してみる。 現行の環境に対して最も影響が少なく、即座に実行することができる対処となります。 いずれは起動することができますが、 いつ起動できるようになるかは全く予想できません。 ですが、まずは数回トライしてみるのがいいでしょう。運良くキャパシティができた隙に起動できるかもしれません。 対処② マシンタイプを変えて起動してみる。 異なるマシンタイプに変更する ことで、インスタンスを起動できることがあります。 マシンタイプの変更は即座に実施できるため、 対処① と組み合わせて行うのも良いでしょう。 マシンタイプを小さくすればスペックの低下、大きくすれば料金の増加とそれぞれデメリットがあります。 また、こちらもゾーンのキャパシティ状況によってはすぐに起動できない可能性があります。 対処③ 別のゾーンにインスタンスを起動する。 キャパシティ不足はゾーン単位で起こっているため、 他のゾーンにインスタンスを起動します。 マシンイメージ を利用することで、インスタンスの構成やディスク内のデータを保持したまま別のゾーンに複製することができます。 外部IPアドレスを使用している場合は、インスタンスを複製した後に付け替えると良いでしょう。 また、インスタンス名はプロジェクト内で、内部IPアドレスはVPC内で重複することができません。 もしそれらを保持したまま別のゾーンで起動したいのであれば、 マシンイメージを作成（忘れずに！）した後、 既存のインスタンスを削除してインスタンス名や内部IPアドレスを使用できるようにしてから、別のゾーンに起動しましょう。 対処④ サポートを利用する。 おそらく 対処③ までやれば解決するかと思いますが、それでも解決しない or 何かしらの事情で上記の対処を行えない場合、最終手段としてGoogle Cloudのサポートに連絡することになるでしょう。 予防策 リソースの予約 を用いることで、ゾーン内リソースのキャパシティを予め確保しておくことができます。 しかし、インスタンスを停止している間も課金が継続されてしまうため、日中帯のみ稼働するようなインスタンスには向かないのが実情です。 リソースの予約については 弊社ブログ にも解説がありますので、こちらもご一読いただければと思います。 クラウドでは、ゾーン障害の対策として複数ゾーンを用いた冗長構成が推奨されますが、こういったキャパシティ不足の状況を想定した場合でもそれは有効であるということでしょう。 参考 VM の作成と更新のトラブルシューティング（公式ドキュメント） 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。最近は Dataflow を勉強中。 Follow @sasashun0805

G-gen の大津です。今回は Google Cloud (旧称 GCP) の BigQuery Data Transfer Service を使って、東京リージョンの Amazon S3 にあるデータを BigQuery に取り込む方法をご紹介します。 はじめに BigQuery Data Transfer Service とは 料金 注意点 Storage Transfer Serviceとの違い 設定手順 AWSでの操作 S3バケットの作成 IAMユーザーの作成 Google Cloudでの操作 BigQueryデータセットとテーブルの作成 転送ジョブの作成 転送ジョブを手動実行 はじめに 前回の記事ではBigQuery Omniを使ってAmazon S3のデータに対してBigQueryからクエリを実行する方法をご紹介しました。 blog.g-gen.co.jp BigQuery Omni を使うことでBigQueryにデータ転送することなく、簡単にBigQueryからAmazon S3へクエリを発行できます。 しかし BigQuery の特徴である超高速なクエリを活用するには、データを BigQuery 内部ストレージに配置したほうが、高いパフォーマンスが出ます。 また BigQuery Omni の制約として、まだ AWS 東京リージョンの S3 バケットをデータソースとして使用することが出来ません (2022 年 6 月現在) 。 そこで今回は別機能である BigQuery Data Transfer Service を使って、東京リージョンの Amazon S3 のデータを BigQuery に取り込む方法をご紹介したいと思います。 BigQuery Data Transfer Service とは BigQuery Data Transfer Service とは Google の SaaS アプリケーションや Amazon S3 、 Azure Blob Storage などの外部ストレージサービスから BigQueryの内部ストレージにデータをコピーする Google Cloud のフルマネージドサービスです。 当機能では GUI 操作・ノーコード でデータ転送ジョブを作成できます。 決まった間隔や日時に実行される 定期実行 のほか、任意のタイミングでの オンデマンド実行 も可能です。 転送処理の失敗時にはメールで担当者へエラー通知をしたり、あるいは Cloud Pub/Sub へのメッセージ投入が可能です。 サービスの詳細は以下の Google Cloud 公式ページを参照ください。 cloud.google.com 料金 BigQuery Data Transfer Service の利用自体は 無料 です。 ただし、以下の課金は発生することにご留意ください。 BigQuery のストレージ料金 Amazon S3など転送元クラウドサービスのアウトバウンドのデータ転送料金 注意点 対応ファイル形式は csv / JSON / Avro / Parquet / ORC BigQuery から外部へのエクスポートは不可 AWS など外部ストレージの 認証情報が必要 Amazon S3 での転送スケジュールの最短間隔は24時間に1度 24 時間よりも短い時間で定期的なファイルを取り込むときは 転送スケジュールを複数に分けるなどの工夫 が必要 転送先である BigQuery のテーブルには 予めスキーマを定義 する必要あり Storage Transfer Serviceとの違い Google Cloud には似た名前である Storage Transfer Service と言うサービスがあります。 これは当記事でご紹介する BigQuery Data Transfer Service とは別サービスになります。 簡単に違いを説明すると BigQuery Data Transfer Serviceは 転送先がBigQuery Storage Transfer Service は 転送先がCloud Storage であるという点です。 では実際に BigQuery Data Transfer Service を使って Amazon S3 のデータを BigQuery に取り込みましょう。 設定手順 AWSでの操作 S3バケットの作成 AWSの東京リージョンにS3バケットを作成し、サンプルデータを保存しました。 サンプルデータは過去120年のオリンピックの結果データを使っています。 IAMユーザーの作成 続いてBigQuery Data Transfer Serviceで使用するIAMユーザーを作成し、シークレットキーとアクセスキーを発行します。 また作成したIAMユーザーに「AmazonS3ReadOnlyAccess」のアクセスポリシーをアタッチします。 Google Cloudでの操作 BigQueryデータセットとテーブルの作成 コピー先となるBigQueryに空のテーブルを用意します。 空のテーブルには、事前にスキーマの定義が必要です。 サンプルデータの内容を確認し、テーブルのスキーマを定義します。 これで受け入れ先となるBigQueryの準備が出来ました。 転送ジョブの作成 BigQuery Data Transfer Serviceの転送設定を行います。BigQueryのメニューから「データ転送」をクリックします。 今回はAmazon S3からの転送を行うのでデータソースはAmazon S3を選択します。 BigQuery Data Transfer ServiceはAmazon S3以外にもさまざまなデータソースに対応しています。 データ転送のスケジュールを設定します。設定はオンデマンド（手動実行）から毎日・毎週・毎月と柔軟なスケジュールを設定が可能です。 今回は毎日の夜間バッチと言う想定でAM00:30に設定しています。 コピー元であるAmazon S3の情報とIAMユーザー（シークレットキーとアクセスキー）の情報、そしてコピー先であるBigQueryのデータセットとテーブルを指定します。 Amazon S3に格納したファイルの拡張子を選択します。 今回はcsvファイルを選択が、csv以外にもJSON（改行区切り）、CSV、Avro、Parquet、ORC を選択できます。 エラー通知も設定可能です。夜間等に設定した転送スケジュールが失敗してもメール等で検知することが出来ます。 以上でBigQuery Data Transfer Serviceの転送ジョブが作成されます。 転送ジョブを手動実行 スケジュールを設定した転送ジョブは、Webコンソールから手動実行が可能です。 今回はスケジュールで実行される前に手動でデータ転送を実行してみます。 手動実行後、すぐに転送ジョブが開始されデータのコピーが始まります。 転送ジョブが完了すると緑色のチェックマークが表示され、問題なくBigQuery Data Transfer ServiceでAmazon S3からBigQueryにデータの取り込みが出来ました。 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の杉村です。当記事では、Google Cloud の認定資格である Professional Cloud DevOps Engineer 試験の対策や、出題傾向について解説します。 基本的な情報 Professional Cloud DevOps Engineer とは 難易度 試験対策 試験対策の流れ いわゆる SRE 本との関係 出題範囲・出題傾向 Site Reliability Engineering（SRE） SRE の基本 インシデント対応 エラーバジェット SLO、SLI エンドポイントの監視 ポストモーテム トイルの削減 オブザーバビリティ Cloud Monitoring Cloud Logging ログフィールドの保護 OpenTelemetry、Cloud Trace、Cloud Profiler CI/CD 構成管理 CI/CD パイプラインのセキュリティ Binary Authorization Cloud Build Cloud Deploy Artifact Registry Terraform コスト管理 予算アラート Compute Engine のコスト ネットワークのコスト ネットワーク ネットワークのログ Network Intelligence Center 共有 VPC Google Kubernetes Engine（GKE） GKE の基本 スケーリング デプロイ戦略 セキュリティ 可用性 オブザーバビリティ Helm Cloud Run Cloud Run の基本 デプロイと運用 Cloud Run から機密情報を利用する 基本的な情報 Professional Cloud DevOps Engineer とは Professional Cloud DevOps Engineer は、Google Cloud の認定資格の1つです。Google Cloud で稼働するアプリケーションの運用や、Google が提唱するシステム運用とソフトウェアエンジニアリングの考え方である Site Reliability Engineering （SRE）に関する知見を問う資格試験です。試験は、日本語または英語で受験することができます。 試験費用は $200、試験時間は2時間、問題数は50〜60問の多肢選択式です。 参考 : Professional Cloud DevOps Engineer 技術面では、Google Kubernetes Engine（GKE）や Cloud Run、Compute Engine 等のコンピュートプラットフォーム上で稼働するアプリケーションに関する監視、運用、インシデント管理、CI/CD に関する知識が問われます。 技術以外の面では、SRE に関するベストプラクティスが数多く問われます。SRE の考え方や方法論は、従来型の「監視・運用」とは異なり、ユーザー目線からの信頼性や計測データに基づく意思決定を重視するアプローチです。すべての情報システムに手法をそのまま適用する必要はありませんが、そのエッセンスを学ぶ価値は高いと言えます。 難易度 Professional Cloud DevOps Engineer の難易度は 中程度〜高い と言えます。 Google Kubernetes Engine（GKE）や Cloud Run、Compute Engine 等、 Google Cloud のサービスに関する専門的な知識を問われるほか、SRE に関するベストプラクティスを問われるため、この試験に向けて集中した学習が必要になります 試験の概要には、推奨される経験として Google Cloud を使用した本番環境システムの設計と管理の 1 年以上の経験を含む、3 年以上の業界経験 が記載されています。しかし、必ずしもここまでの経験は必要ありません。Google Cloud に関する Professional Cloud Architect 程度の知見に加えて、一般的なアプリケーション監視・運用に関する知見がある人にとっては、十数時間程度の追加学習でキャッチアップできるものと考えられます。また IPA の基本情報処理技術者試験または応用情報技術者試験程度の一般的な IT インフラやアプリケーション開発に関する知見もあることが望ましいです。 また、一部に Professional Cloud Developer 試験と重複する知識分野もありますので、こちらの試験を先に学習するのも有効です。 試験対策 試験対策の流れ 以下はあくまで一例であり、予め自分が持っている知識や経験によって異なるものとお考えください。 Professional Cloud Architect 試験 を学習し、合格することで Google Cloud の基本的な知見を得る オライリー発行の書籍『SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム』を読み SRE の原則を理解する 公式の 試験ガイド を確認して試験範囲を理解する Cloud Monitoring、 Google Kubernetes Engine (GKE)、Cloud Run などよく問われるサービスを学習する 公式の 模擬試験 を受験して感覚を掴み、足りない知識を把握する 当記事の出題傾向を読み、足りない知識領域をカバーする学習を行う いわゆる SRE 本との関係 書籍『SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム』は、SRE に関する有名な書籍です。この本を読むことで、SRE、SLI / SLO、トイル、エラーバジェット、ポストモーテム、DevOps といった SRE に関する基本的な考え方を把握することができます。これらの用語が、直接的に問題で問われることがあります。 また Google は、この書籍をオンラインで無料公開しています。ただし、英語版のみです。 参考 : Table of Contents それなりにボリュームがあるので、すべてを読むことができない場合は、重要な用語について記載された章に限って読むことも可能です。どの単語が重要かは、当記事を参考にしてください。 試験に向けて、その内容を丸暗記する必要があるというよりは、 原理・原則を理解すれば答えられる 問題がほとんどです。またこれらの方法論を学ぶことで、普段の IT 運用業務や運用設計に落とし込めるような、普遍的なノウハウも得られます。学んで損のない内容だと言えるでしょう。 出題範囲・出題傾向 以下のような分野・サービスが出題範囲です。 Site Reliability Engineering（SRE） Google Kubernetes Engine（GKE） Cloud Run Compute Engine Identity and Access Management（IAM） オブザーバビリティ OpenTelemetry Cloud Monitoring、Cloud Logging、Error Reporting Cloud Trace、Cloud Profiler CI/CD Cloud Build Cloud Deploy Terraform コスト管理 特に目立って出題が多い分野は GKE、Cloud Run、オブザーバビリティです。 当記事のこれ以降の見出しは、各分野での出題内容の傾向について解説しています。学習方針を決めるために利用したり、受験前の最後の仕上げとして参考にして下さい。 Site Reliability Engineering（SRE） SRE の基本 SRE 、 SLI / SLO 、 トイル 、 エラーバジェット 、 ポストモーテム 、 DevOps といった用語を理解することが重要です。 試験問題ではこれらの用語を理解しているか、また SRE の提唱するベストプラクティスを理解しているかを問われます。 インシデント対応 SRE において、大規模障害が発生した際の体制を問われます。これは SRE 本の Chapter 9 - Incident Response に記載があります。 参考 : Chapter 9 - Incident Response まずインシデント対応の司令塔となる Incident Commander （IC）が任命されます。 IC の最初の仕事は、オペレーションのリーダーである Operations Lead （Ops Lead、OL）と関係者コミュニケーションのリーダーとなる Communications Lead （Comms Lead、CL）を経験あるメンバーの中から選任することです。この3つの役職名は覚えましょう。 インシデント対応チームには、IC が適切にタスクを委任したり、メンバー間で効果的にコミュニケーションすることが重視されます。またユーザーや経営陣などステークホルダーへの情報公開も重要な要素の一つです。一人のヒーロー的存在が活躍するのではなく、組織としてインシデント対応が管理されている状態が理想とされます。 MTTD （Mean time to detect）、 MTTR （Mean time to recover）、 MTBF （Mean time between failure）といった一般的な用語についても、正しく意味を理解してください。 エラーバジェット エラーバジェット （Error Budget）は消費しすぎても、しなさすぎてもいけないというのが SRE の考え方です。 消費しすぎている状態は、システムの信頼性に問題があることを示します。所定の期間（ウインドウ）の間でエラーバジェットが枯渇している場合は、リリースを延期するのが原則です。 逆に消費しなさすぎている状態は、リリースのスピードがビジネスニーズに対応しきれていない、もしくは SLO の設定が不適切であるということを意味しています。 健全な消費具合 にすることが重要であり、そのためには開発がビジネスニーズに追随するか、あるいは SLO を適切に設定しなおすということが必要になります。 SLO、SLI 適切な SLI と SLO の設定が大事です。SLO の制定には ステークホルダーの同意が必須 です。 参考 : Chapter 2 - Implementing SLOs SLI の設定が間違っていれば、それを満たして SLO を達成しても意味がなくなってしまいます。ユーザー体験を適切に反映するような SLI を設定する必要があります。 なお、Cloud Monitoring には SLO を監視するための SLO モニタリング機能 が用意されています。これにより、SLO が所定の基準を下回ったときにアラートを発報することができます。 参考 : サービスのモニタリングにおけるコンセプト 参考 : Cloud MonitoringでSLOモニタリングを設定する方法 エンドポイントの監視 可用性に関連して、エンドポイントの正常性を監視する機能として、Cloud Monitoring の 稼働時間チェック （uptime checks）機能があります。稼働時間チェックには、インターネット公開されているエンドポイント向けの パブリック稼働時間チェック と、プライベートネットワーク内でのエンドポイント向けの プライベート稼働時間チェック があります。 参考 : パブリック稼働時間チェックを作成する 参考 : プライベート稼働時間チェックを作成する また、クライアントからの複雑なリクエストを模した 外形監視 （あるいは合成監視、Synthetic monitoring）が必要になるケースでは、 合成モニター （synthetic monitor）を作成できます。合成モニターを作成するには Cloud Run functions を使って処理を記述する 必要があります。 参考 : 合成モニターを作成する ポストモーテム ポストモーテム （Postmortem）とは、重大な障害が発生した後に、原因、影響、および将来の再発防止策を詳細に分析して記録するプロセスのことです。ポストモーテムの原則は SRE 本の Chapter 15 - Postmortem Culture: Learning from Failure に記載のとおりです。 参考 : Chapter 15 - Postmortem Culture: Learning from Failure 以下は、ポストモーテムの重要な考え方の例です。 批判しない（Blameless）。「この問題は誰の責任なのか」といったことを書かない 組織内で広く共有される 経営層などのリーダーシップによる深い理解 トリガー（いつポストモーテムを書くのか）を定義する トイルの削減 手動であり、繰り返し行われ、自動化の余地があるもの、価値を生み出さず、しかもサービス成長に応じて線形に増加していくようなタスクは トイル と呼ばれ、 SRE の背景でよく言及されます。 Google Cloud などのパブリッククラウドサービスは、Web API で操作できることが強みであり、これはプログラムによる自動化の可能性を広げるものです。 わざわざエンジニアに電話連絡をしなくてもいいような、単純なインスタンスの再起動や再構築などは、自動化を検討することができます。 オブザーバビリティ Cloud Monitoring Cloud Monitoring の基本機能は、以下の記事を参照してください。 blog.g-gen.co.jp Ops Agent による メトリクスやログの収集 、複数のプロジェクトの指標を まとめて可視化 する方法、アラート機能による Slack や SMS、Pub/Sub への通知 などは把握しておいてください。 なお上記の記事にあるように、複数の Google Cloud プロジェクトの指標をまとめてダッシュボード化する方法として 指標スコープ という手法があります。これは、Cloud Monitoring で収集された指標を、Google Cloud プロジェクトを横断して1箇所で確認できるようにする手法です。 スコーピングロジェクト （Scoping Project）に、指標を閲覧可能な対象プロジェクトを定義しておくことで、このプロジェクト経由で複数のプロジェクトの指標を確認できます。 参考 : 指標スコープの概要 また カスタムメトリクス については、一通りの仕様は抑えておくべきです。値の型（ BOOL 、 INT64 、 DOUBLE 、 STRING ）や指標の種類（ GAUGE 、 DELTA 、 CUMULATIVE ）などを問題で問われて面食らうことのないようにしておきましょう。それぞれがどのような場面で使われるかは、以下のドキュメントを参照してください。 参考 : 値の型と指標の種類 Cloud Logging Cloud Logging の基本機能は、以下の記事で確認してください。 blog.g-gen.co.jp 特に、 Agent によるログ収集 や、ログシンクを使って 組織全体でログを集約する方法 や、検知したログをメトリクス化（数値化）する ログベースの指標 などは重要です。 また、以下のような IAM ロールについても把握しておいて下さい。 IAM ロール 概要 ログ構成書き込み（ roles/logging.configWriter ） ログシンクの作成や編集に必要 プライベート ログ閲覧者（ roles/logging.privateLogViewer ） データアクセス監査ログの閲覧に必要 ログフィールドの保護 アプリケーションから Cloud Logging でログエントリを出力し、ログバケットに保存しているとき、ログエントリの特定のフィールドに PII（個人を特定できる情報）等の機密情報は入っているケースを考えます。 指定の Google アカウントやグループだけがこの機密フィールドを閲覧できるように制限をかけたい場合、ログバケットに フィールドレベルのアクセス を構成することができます。以下のドキュメントでその設定手順や、制限をかけたフィールドに何の IAM ロールが必要なのかを確認してください。 参考 : フィールド レベルのアクセスを構成する OpenTelemetry、Cloud Trace、Cloud Profiler OpenTelemetry、Cloud Trace、Cloud Profiler については、それぞれの用途を概要レベルで理解しておきましょう。 Cloud Trace と Cloud Profiler については、以下の記事の「監視（オブザーバビリティ）」の章を参照してください。 参考 : Professional Cloud Developer試験対策マニュアル - 監視、オブザーバビリティ OpenTelemetry とは、アプリケーションからログや指標などのデータを収集・管理するための規格とツール群です。以下のドキュメントもか確認してください。 参考 : 計測とオブザーバビリティ CI/CD 構成管理 「ずさんなソースコード管理をしているチームに、Git の使用を検討させる」といった状況の問題文がいくつか提示されます。Git のブランチ、プルリクエスト、diff 機能など、基礎的な知識があれば答えられる問題が出題されます。ソースコードを「ファイルサーバーで管理する」「Cloud Storage で管理する」「Google ドライブで管理する」などの選択肢は排除することができます。 CI/CD パイプラインのセキュリティ 従来は、開発終了後の試験フェイズにおいて脆弱性診断を行うなど、セキュリティの担保は開発の後工程に行われていました。セキュリティの向上施策を、より開発の前工程に移していく動きをセキュリティの シフトレフト （Shift left）といいます。 Binary Authorization Binary Authorization により、コンテナイメージに適切な 署名 （attestation）がある場合のみデプロイを許可する、といった構成についても理解しておきましょう。これは以下の記事でも紹介している通りですので、各記事を参照してください。 参考 : Professional Cloud Developer試験対策マニュアル - 脆弱性の管理 参考 : Professional Cloud Security Engineer試験対策マニュアル。出題傾向・勉強方法 - DevSecOps（CI/CD） Cloud Build Cloud Build は GitHub などの外部ツールと連携させることができます。 トリガー を作成すると、GitHub 等のリポジトリへの Push などを検知して Cloud Build のビルドがトリガーされるように設定できます。 参考 : Cloud Build トリガー Cloud Build ではビルド完了時等に Pub/Sub 通知ができることから、Pub/Sub のプッシュサブスクリプションを用いて Webhook 通知ができることなどを押さえてください。これにより、ビルド完了を契機にサードパーティ製品に通知を送って後続の処理を実行することができます。 参考 : ビルド通知に登録する 参考 : プッシュ サブスクリプション Cloud Deploy Cloud Deploy の管理等に関する問題が問われます。以下のドキュメントで、 デリバリーパイプライン や ターゲット などの用語を確認してください。 参考 : Cloud Deploy の用語 デリバリーパイプラインなどの各リソースへのアクセス権限は、IAM で管理されます。 roles/clouddeploy.developer など、いくつかのロールとその付与の仕方を確認しておきます。 参考 : IAM を使用した Cloud Deploy アクセスの制限 - 特定のデリバリー パイプラインへのアクセスを許可する Artifact Registry Artifact Registry には、 Artifact Analysis により、新規にアップロードされたコンテナイメージの 自動スキャン と、既存イメージの 継続スキャン を設定できます。これにより、コンテナイメージの脆弱性を継続的にモニタリングできます。 参考 : コンテナ スキャンの概要 Terraform Google は、ベストプラクティスに沿った一連の Terraform テンプレートである Cloud Foundation Toolkit を配布しています。再現性のある形でセキュアなインフラを展開するために利用できます。 参考 : Terraform による迅速なクラウド基盤の構築とワークロードのデプロイ 参考 : Google Cloud リソースを操作するときのベスト プラクティス コスト管理 予算アラート 請求先アカウントに作成する予算と予算アラートの仕様を理解してください。なお予算アラートは組織やフォルダのレベルで作成することもできます。その場合、その組織やフォルダの配下のすべての Google Cloud プロジェクトに発生した課金の 合計額 を監視することができます。 参考 : 予算と予算アラートの作成、編集、削除 Compute Engine のコスト 確約利用割引 （Commited Use Discounts、CUD）や Spot VM の基本を理解して下さい。 確約利用割引については、以下の記事も参考にしてください。 参考 : 確約利用割引(Compute Engine)を解説。AWSとの違いも確認 - G-gen Tech Blog Compute Engine の Spot VM は、 Google 側の都合で中断されることがあるため「キューイングされたジョブを次々に処理するワーカー」など、 ステートレスで一時的な処理基盤 としての利用が適切です。長時間に渡り保持が必要なデータベースサーバーや、Web サーバーなどには適しません。 参考 : Spot VM また、長期的に使っている Compute Engine VM を最適なマシンタイプに変更するには、 Recommender API が提供する マシンタイプに関する推奨事項 を確認します。これが最も効率良く、適切なマシンタイプを知る方法です。 参考 : VM インスタンスに推奨マシンタイプを適用する ネットワークのコスト ネットワーク関連の料金の節減のため、デフォルトである プレミアムティア の代わりに スタンダードティア を使うなど、適切な ネットワークサービスティア を選択できるようにしておきましょう。 参考 : Network Service Tiers の概要 ネットワーク ネットワークのログ Google Cloud の VPC で採取できるログとしては「VPC フローログ」「ファイアウォールルールのログ」が代表的です。以下の記事で、それぞれの特徴を確認してください。 参考 : Google CloudのVPCを徹底解説！(基本編) - 運用 これらを使うことで、検査の実装の手間がかかる「パケットミラーリング機能」などを使わなくても、ある程度のパケットの情報と傾向を得ることができます。Google Cloud の VPC ネットワークには Packet Mirroring 機能が備わっていますが、パケットを収集する VM が必要だったり、その手間に内部パススルーネットワークロードバランサが必要になります。 参考 : Packet Mirroring Network Intelligence Center Network Intelligence Center の概要を理解して下さい。Network Intelligence Center には 接続テスト （Connectivity Test）機能があります。Compute Engine や GKE のノード間のネットワーク到達性をテストでき、トラブルシューテイングにも役立ちます。 参考 : Network Intelligence Centerを徹底解説！ - G-gen Tech Blog 共有 VPC 共有 VPC を使うと、1つのプロジェクト（ ホストプロジェクト ）に VPC ネットワークを配置して、それを他のプロジェクト（ サービスプロジェクト ）に貸し出すことができます。ネットワークやその設定の管理を一箇所に集約することができます。 参考 : 共有 VPC ホストプロジェクトが誤って削除されると影響が甚大なため、プロジェクトを誤削除しないように リーエン を設定することができます。リーエンとは、プロジェクトを誤って削除しないように設定するロック設定のことです。さらに、リーエン自体を誤って、あるいは意図的に削除できないようにするには、組織のポリシーの制約である constraints/compute.restrictXpnProjectLienRemoval を設定します。なお、API やコマンドラインインターフェイス上では共有 VPC を指して xpn と表記されます。 参考 : リーエンでプロジェクトを保護する Google Kubernetes Engine（GKE） GKE の基本 Google Kubernetes Engine（GKE）の基本的な知識は把握しておいてください。 Pod、ReplicaSet、Deployment など Kubernetes リソースの概要や、クラスタの自動スケーリング、水平 Pod 自動スケーリング、垂直 Pod 自動スケーリング、多次元 Pod 自動スケーリングの意味の違いなど、基本的な事項は押さえておきます。 GKE や Kubernetes の基本は、以下の記事を参照してください。 参考 : Kubernetes の基本を解説 - G-gen Tech Blog 参考 : Google Kubernetes Engine（GKE）を徹底解説 - G-gen Tech Blog スケーリング 最低限、以下のスケーリング手法は理解しておく必要があります。 クラスタ自動スケーリング（cluster autoscaling） 水平 Pod 自動スケーリング（horizontal Pod autoscaling） 垂直 Pod 自動スケーリング（vertical Pod autoscaling） 多次元 Pod 自動スケーリング（multidimensional Pod autoscaling） クラスタ自動スケーリング によって、GKE のノードプールのサイズが自動で変更され、 ノード数が 増減します。そのノードに載る Pod は、 水平 Pod 自動スケーリング により数量が増減します。個々の Pod へ割り当てられるリソースは、 垂直 Pod 自動スケーリング によって調整されます。水平と垂直の Pod 自動スケーリングを併せて使うのが 多次元 Pod 自動スケーリング です。どのような状態でどのスケーリングが使われるべきか、イメージできるようになっておく必要があります。 例えば、問題文で、GKE によるバッチ処理のパフォーマンス改善が求められるシチュエーションが出題されたとします。ノードの CPU 使用率やメモリ使用率が大幅に余っているのであれば、それ以上ノード数を増やしてもパフォーマンス改善は見込めません。Pod 数を増やして一度に処理できるワークロードを増やして方がよいでしょう。 参考 : クラスタの自動スケーリングについて 参考 : 水平 Pod 自動スケーリング 参考 : 垂直 Pod 自動スケーリング 参考 : 多次元 Pod 自動スケーリングの構成 デプロイ戦略 Kubernetes におけるアプリケーションの デプロイ戦略 に関する問題が多く出題されます。GKE に固有のものではありませんが、Blue/Green デプロイ、カナリアリリース、バージョン間のトラフィック移行、などのデプロイ手法は理解をしておきましょう。 参考 : Kubernetes 環境におけるアプリケーションのデプロイメント 「サービスへの影響を可能な限り抑えてロールアウトし、問題があれば素早くロールバックする」ために Blue/Green デプロイを採用するなど、デプロイ戦略ごとのメリット / デメリットを把握し、要件に応じて適切なものを選択できるようにしましょう。 例えば、Kubernetes において Blue/Green デプロイを行った際に切り戻しを行うには、Service の Selector が Blue（切り替え前）のバージョンを向くように変更することになります。これがマニフェストファイルでどのように表現されるかを確認しておきましょう。 セキュリティ GKE でパスワードや API キー等の機密情報（シークレット）を扱う際の手法も重要です。 参考 : アプリケーション レイヤで Secret を暗号化する 参考 : Google Kubernetes Engine で Secret Manager アドオンを使用する また、Cloud KMS に関する基本的な事項も押さえておきましょう。以下の記事を参照して下さい。 参考 : Cloud KMSを徹底解説 - G-gen Tech Blog GKE クラスタ内のワークロードから他の Google Cloud サービスを利用する場合の認証方法についても問われます。GKE では、Google Cloud APIs の認証には Workload Identity の使用が推奨されています。Kubernetes の ServiceAccount リソースと Google Cloud の IAM サービスアカウントを紐付けることで、クラスタ内のワークロードから IAM サービスアカウントを使用して Google Cloud APIs にアクセスすることができます。以下の記事で、手順の概要を確認してください。 参考 : GKE クラスタ内のワークロードから Google Cloud APIs にアクセスする（Workload Identity） - G-gen Tech Blog 可用性 livenessProbe を設定することで、Pod に異常が起きた時、自動的に再起動させることができます。 参考 : コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス - アプリケーションに有用な readiness probe と liveness probe を設定する オブザーバビリティ GKE のモニタリングに際しては、フルマネージドサービスである Google Cloud Managed Service for Prometheus が用いられるケースがあります。 マルチクラウドの環境や複数のプロジェクトを横断した、広範囲なモニタリングやアラートを、最小限の工数で構成することができます。 参考 : Google Cloud Managed Service for Prometheus Helm 深くは問われませんが、Kubernetes のパッケージ マネージャーである Helm が出題される場合があります。 Google Cloud のフルマネージドの成果物レジストリである Artifact Registry では、OCI 形式で Helm のチャートを保存することができ、クローズドな環境下で活用することができます。 参考 : Artifact Registry に Helm チャートを保存する Cloud Run Cloud Run の基本 以下の記事を読み、Cloud Run の基本を理解してください。 blog.g-gen.co.jp デプロイと運用 Cloud Run services のリビジョン管理に関する問題が多く出題されます。リビジョン間の トラフィック分割 機能を活用した段階的なロールアウト手法や、 タグ付きリビジョン を使用した新しいリビジョンのテストなど、Cloud Run 特有の機能を理解しておきましょう。 参考 : リビジョンを管理する 参考 : ロールバック、段階的なロールアウト、トラフィックの移行 参考 : Cloud Run services でタグ付きリビジョンを使用して新しいリビジョンをテストする - G-gen Tech Blog Cloud Run から機密情報を利用する Cloud Run 上のアプリケーションからサードパーティの API にアクセスする際などに、API キーなどの機密情報を利用したいときがあります。このような機密情報は Secret Manager に保存し、Cloud Run の環境変数経由でアクセスすることができます。 参考 : サービスのシークレットを構成する Cloud Run からシークレットを参照するには2つの方法があることに注意して下さい。 環境変数 から参照する方法と、ボリュームとしてシークレットを マウント する方法です。環境変数方式では、シークレットの値が更新されても起動中のコンテナインスタンスには反映されません。常に最新のシークレットを参照させたい場合は、後者のマウント方式を選択します。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

はじめまして！５月にG-genにジョインした片岩です。 まだGoogle Cloud(旧称GCP)をあまり触ったことがない方も多いと思います。Compute EngineとCloud SQLを利用したWebアプリを動かしてみたので、今回はその手順についてご紹介します。WebアプリにはMattermostというチャットアプリを利用しました。 Compute Engine および Cloud SQL とは 構成イメージ 全体の流れ 重要なポイント 構築手順 Cloud SQL Compute Engine 動作確認 Compute Engine および Cloud SQL とは Compute Engine および Cloud SQL のサービスの解説は、以下の記事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 構成イメージ 今回の構成は以下のとおりです。 全体の流れ 全体のざっくりした流れは以下になります。 Cloud SQLインスタンスを作成します。（PostgreSQLを利用） Cloud SQLインスタンス上にデータベースを作成します。 VMインスタンスを作成します。 VMインスタンスにPostgreSQLクライアントをインストールします。 VMインスタンスにMattermostサーバーをインストールします。 Webアプリ（Mattermost）が起動していることを確認します。 重要なポイント 重要なポイントは以下の２点です。 Cloud SQLのプライベートIPを有効にする VMインスタンスにファイアウォールルールを適用する Cloud SQLのプライベートIPを有効にすることでVMインスタンスからCloud SQLへの通信を可能にしています。また、外部からVMインスタンスへの通信を許可するために、VMインスタンスにファイアウォールルールを適用しています。 それでは実際の手順を見ていきましょう。 構築手順 Cloud SQL まずコンソールからCloud SQLインスタンスを作成します。 その際、ネットワーキングの設定でプライベートIPを有効にします。パブリックIPは無効で構いません。 Cloud SQLインスタンスができたらデータベースを作成します。データベース名をmattermostとします。 Compute Engine 今回のアプリではTCP8065ポートを利用します。 外部からTCP8065ポートにアクセスできるよう、ファイアウォールルールを作成します。 ファイアウォールルールのタグを付与したVMインスタンスを作成します。 VMインスタンスにPostgreSQLクライアントをインストールします。 VMインスタンスにSSHで接続し、以下のコマンドを実行します。 sudo apt-get update sudo apt-get install postgresql-client wgetコマンドを有効にします。 sudo apt install wget Mattermostをインストールします。詳細は インストールガイド をご参照ください。 sudo apt install wget wget https://releases.mattermost.com/6.7.0/mattermost-6.7.0-linux-amd64.tar.gz tar -xvzf mattermost*.gz sudo mv mattermost /opt sudo mkdir /opt/mattermost/data sudo useradd --system --user-group mattermost sudo chown -R mattermost:mattermost /opt/mattermost sudo chmod -R g+w /opt/mattermost 管理者権限で /opt/mattermost/config/config.json ファイルを開き、MattermostサーバーからCloud SQLへ接続するように以下の設定を変更します。 <パスワード>にはご自身のPostgreSQLのパスワードを、<IPアドレス>にはCloud SQLインスタンスのプライベートIPアドレスをご利用ください。 key value "DriverName" "postgres" "DataSource" "postgres://postgres:<パスワード>@<IPアドレス>/mattermost? Cloud SQLへの疎通を確認します。 cd /opt/mattermost sudo -u mattermost bin/mattermost Server is listening on :8065 と出力されれば問題なく起動しています。Crlt + C で停止させます。 次にデーモンがサービスを起動するように設定変更作業を進めます。 sudo touch /lib/systemd/system/mattermost.service 作成した/lib/systemd/system/mattermost.serviceを開いて以下の内容をペーストします。 [Unit] Description=Mattermost After=network.target [Service] Type=notify ExecStart=/opt/mattermost/bin/mattermost TimeoutStartSec=3600 KillMode=mixed Restart=always RestartSec=10 WorkingDirectory=/opt/mattermost User=mattermost Group=mattermost LimitNOFILE=49152 [Install] WantedBy=multi-user.target ファイルを保存したら以下のコマンドを実行します。 sudo systemctl daemon-reload sudo systemctl status mattermost.service sudo systemctl start mattermost.service curl http://localhost:8065 HTMLが返却されれば問題ありません。 動作確認 別のPCからブラウザを起動し、 http://IPアドレス:8065 にアクセスします。 Mattermostの画面が表示されました。 問題なく動作しているようですね。 片岩 裕貴 (記事一覧) データアナリティクス準備室 2022年5月にG-gen にジョイン。 AI/ML系に関心が強く、ディープラーニングE資格とProfessional Machine Learningを取得。最近話題のGenerative AIにも興味がある。毎日の日課は三人乗りの電動自転車で子供を幼稚園に送り迎えすること。和歌山県在住。

こんにちは、G-gen の武井です。当記事では、Google Cloud（旧称 GCP）の割り当て（Quota）を上限緩和する方法をご紹介します。 割り当て（quota）とは 割り当ての引き上げリクエスト 割り当ての自動調整 注意点 権限（IAM ロール） プロジェクトの支払いステータス カスタマーケア契約は不要 割り当て（quota）とは Google Cloud の VPC や Compute Engine など各種サービスでは、 使用できるリソースの割り当て量 に上限が設けられています。これらは、サービスの過負荷を防いだり、意図せず突発的に大量のリソースを作成してしまうことを防ぐために設定されています。 Google Cloud ではこのような上限値として、 割り当て （quota）と システム上限 （system limits）があります。割り当て（quota）は場合によっては上限緩和可能であり、システム上限（system limits）は原則的に緩和できません。 この割り当てや上限を意識せずに Google Cloud を利用していると、ある日突然「VM インスタンスに新しく外部 IP アドレスを割り当てられなくなった」**というような、予期せぬトラブルに繋がる可能性があります。 多くのリソースの割り当ては、正しい手順を踏むことで 上限緩和が可能 です。当記事では、リソース割り当ての増加を Google にリクエストする方法や、それに関する注意点について紹介します。 参考 : 割り当て値とシステムの上限について 割り当てやシステム上限の詳細は、以下の記事も参考にしてください。 参考 : Google Cloudの根幹を成すGoogle Cloud APIsとは何か - 割り当てとシステム上限 割り当ての引き上げリクエスト Google Cloud コンソールの「割り当てとシステム制限」の画面から、Google に対してリソース割り当て量の増加をリクエストできます。ナビゲーションメニュー、または検索ボックスから IAM と管理 > 割り当て と遷移してください。 以下のように、フィルタにサービス名を入力して絞り込みます。 次に、割り当てを変更したいリソースにチェックを入れ、 割り当ての編集 をクリックします。 変更後の割り当て数と、リクエストの正当な理由を記載したら、 次へ をクリックします。 最後に、名前、メールアドレス、電話番号を入力したら、 リクエストを送信 をクリックします。 申請は、通常は2〜3営業日以内に評価され、過去の利用実績に基づいて審査されます。リクエストの申請が承認されたら、リソースの割り当てが変更されたことを確認しましょう。 割り当ての自動調整 Google Cloud プロジェクトで、自動調整機能である 割り当ての調整 （quota adjuster）を有効化できます。デフォルトでは自動調整は無効になっており、Google Cloud コンソールの「IAM と管理 > 割り当て > 構成」画面から有効化することができます。 自動調整が有効の場合、所定の期間内におけるピーク使用量が割り当てに近づいたとき、10%〜20%程度、割り当ての引き上げリクエストが試みられます。リクエストがされたタイミングで、アラートを発報することもできます。 参考 : 割り当ての調整 なお、割り当ての調整はすべての割り当てに対して使用できるわけではありません。サポートされているのは、以下のリストに記載されている割り当てのみです。 参考 : 割り当ての調整 - サポートされている割り当て なお、2026年1月現在、組織レベルおよびフォルダレベルの割り当て調整は Preview 段階であり、gcloud コマンドラインまたは API 経由で有効化できます。 注意点 権限（IAM ロール） リクエストを起票するアカウントに、プロジェクトレベルで以下の IAM ロールが必要です。 resourcemanager.projects.get onitoring.timeSeries.list serviceusage.services.list serviceusage.quotas.get serviceusage.quotas.update これらの権限は、基本ロールである オーナー と 編集者 、また事前定義ロールである Service Usage 管理者 などに含まれています。 以下は、権限が不足しているアカウントで割り当て変更リクエストを申請しようとした際のスクリーンショットです。 「この割り当てを編集するのに必要な権限がありません。」 と表示された場合は、操作しているアカウントの権限を確認してください。 参考 : 割り当て増加リクエストを表示する権限 プロジェクトの支払いステータス 無料トライアル中の Google Cloud 環境では割り当て増加のリクエストはできません。また、変更リクエストを実施しようとしているプロジェクトは、支払いプロファイルが紐付いた請求先アカウントに紐付いている必要があります。 つまり、割り当て増加リクエストを行うには、Google Cloud プロジェクトが 利用料を支払える状態 である必要があります。 以下は、トライアル中の Google Cloud プロジェクトで割り当て増加リクエストを申請しようとした際のスクリーンショットです。このようなメッセージが表示された場合は、まずはプロジェクトの状態をご確認ください。 サービス利用状況の履歴に基づき、現時点で割り当て増加はご利用いただけません。 現在ご利用いただける割り当てをご活用ください。 また、追加のリソースが必要な場合は、Google のセールスチーム（https://cloud.google.com/contact/）にご連絡のうえ、 割り当て増加の資格を得るためのその他のオプションについてご相談ください。 Google Cloud の請求の仕組みについては、以下の記事もあわせて参照してください。 blog.g-gen.co.jp カスタマーケア契約は不要 他のパブリッククラウドでは、割り当ての上限緩和のためにサポート窓口でサポートケースを起票する必要がある場合があります。Google Cloud ではサポートケースを起票しなくても、Google Cloud コンソールの「割り当てとシステム上限」画面から割り当ての引き上げリクエストを申請できます。Google Cloudの技術サポート窓口である「カスタマーケア」は有償です。割り当ての引き上げリクエストのためだけに、有償のカスタマーケアを契約する必要はありません。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 趣味はロードレースやサッカー観戦、ゴルフ、筋トレ。 Follow @ggenyutakei

こんにちは、G-gen の武井です。今回は Google Cloud (旧称 GCP) の Cloud Functions ローカル実行環境 (Functions Framework) で、 Pub/Sub トリガのイベント関数を検証する方法 について紹介したいと思います。 検証イメージ Pub/Sub エミュレータのセットアップ 1. Pub/Sub エミュレータのインストール 2. gcloud コンポーネントのアップグレード 3. Pub/Sub エミュレータの起動 4. Pub/Sub エミュレータスクリプトの取得 5. venv 仮想環境の作成 6. 環境変数の設定 Pub/Sub トピック、サブスクリプションの作成 1. Pub/Sub トピックの作成 2. Push サブスクリプションの作成 動作確認 1. Functions Framework の起動 2. イベント関数のテスト 検証イメージ 今回の検証における構成は以下のとおりです。 検証イメージ Cloud Scheduler が定期的に Cloud Pub/Sub キューにメッセージを投入、そして Pub/Sub をトリガとして Cloud Functions のイベント関数が実行されるイメージです。 ローカル環境での検証にあたって、次のツールを準備しました。 Functions Framework Cloud Functions のローカル実行環境です。インストール方法等についてはこちらのブログを参照ください。 blog.g-gen.co.jp Pub/Sub エミュレータ Cloud Pub/Sub のローカル実行環境です。インストール方法等についてはのちほど説明します。 cloud.google.com ※ Cloud Scheduler についてはローカル環境で使用可能なツールはありませんので、サンプルスクリプトを用意しました。 Pub/Sub エミュレータのセットアップ 1. Pub/Sub エミュレータのインストール まずは Pub/Sub エミュレータをインストールします。 gcloud components install pubsub-emulator apt-get で gcloud をインストールしている場合は以下のエラーが想定されます。 > ERROR: (gcloud.components.install) > You cannot perform this action because the Google Cloud CLI component manager > is disabled for this installation. You can run the following command > to achieve the same result for this installation: > > sudo apt-get install google-cloud-sdk-pubsub-emulator その場合は代替コマンドでエミュレータをインストールします。 (コマンドは Debian の場合) sudo apt-get install google-cloud-sdk-pubsub-emulator 2. gcloud コンポーネントのアップグレード 続けて gcloud コンポーネントをアップグレードします。 gcloud components update apt-get で gcloud をインストールしている場合は以下のエラーが想定されます。 > Beginning update. This process may take several minutes. > ERROR: (gcloud.components.update) > You cannot perform this action because the Google Cloud CLI component manager > is disabled for this installation. You can run the following command > to achieve the same result for this installation: > > sudo apt-get update && sudo apt-get --only-upgrade install google-cloud-sdk-app-engine-go その場合は代替コマンドでコンポーネントをアップグレードします。 (コマンドは Debian の場合) sudo apt-get update && sudo apt-get --only-upgrade install google-cloud-sdk-app-engine-go google-cloud-sdk-minikube google-cloud-sdk-spanner-emulator kubectl google-cloud-sdk-skaffold google-cloud-sdk-app-engine-grpc google-cloud-sdk-cloud-build-local google-cloud-sdk-pubsub-emulator google-cloud-sdk-datastore-emulator google-cloud-sdk-kubectl-oidc google-cloud-sdk-bigtable-emulator google-cloud-sdk google-cloud-sdk-cloud-run-proxy google-cloud-sdk-config-connector google-cloud-sdk-app-engine-java google-cloud-sdk-anthos-auth google-cloud-sdk-firestore-emulator google-cloud-sdk-cbt google-cloud-sdk-app-engine-python-extras google-cloud-sdk-datalab google-cloud-sdk-local-extract google-cloud-sdk-nomos google-cloud-sdk-app-engine-python google-cloud-sdk-gke-gcloud-auth-plugin google-cloud-sdk-terraform-tools google-cloud-sdk-kpt 3. Pub/Sub エミュレータの起動 プロジェクト名を指定して Pub/Sub エミュレータを起動します。 gcloud beta emulators pubsub start --project=my-project なお、エミュレータを停止すると 作成したトピック等は削除されてしまうので、その都度作り直す 必要があります。 また、エミュレータはフォアグラウンドに滞在して実行されるため、以降の作業は別ターミナルを起動して実施する必要があります。 4. Pub/Sub エミュレータスクリプトの取得 GitHub から Python リポジトリをクローンして Pub/Sub エミュレータスクリプトを取得します。前述の通り、エミュレータを起動した際に使用したものとは別のターミナルを起動して実行します。 git clone https://github.com/googleapis/python-pubsub 5. venv 仮想環境の作成 先ほどクローンした python-pubsub/samples/snippets ディレクトリに venv 仮想環境を作成し、依存関係をインストールします。 cd python-pubsub/samples/snippets python3 -m venv venv source venv/bin/activate pip3 install -r requirements.txt 6. 環境変数の設定 Pub/Sub エミュレータ上にトピックやサブスクリプションを作成する際に必要となる情報を環境変数を設定します。 export PUBSUB_PROJECT_ID=my-project export TOPIC_ID=cf-test export PUSH_SUBSCRIPTION_ID=my-subscription また、Pub/Sub API の向き先がローカルにインストールした Pub/Sub エミュレータになるよう、以下の環境変数を設定します。 $(gcloud beta emulators pubsub env-init) Pub/Sub トピック、サブスクリプションの作成 1. Pub/Sub トピックの作成 Pub/Sub トピックを作成します。トピックとはメッセージキューに相当します。 作業ディレクトリは 引数で指定するファイル (publisher.py) が存在する python-pubsub/samples/snippets です。 python3 publisher.py ${PUBSUB_PROJECT_ID} create ${TOPIC_ID} 作成したトピックを確認するには以下のコマンドを実行します。 python3 publisher.py ${PUBSUB_PROJECT_ID} list 2. Push サブスクリプションの作成 イベント関数のトリガとなる Push サブスクリプションを作成します。 Push サブスクリプションが宛先としている http://localhost:8080 は、のちほど Functions Framework で実行するイベント関数となります。 python3 subscriber.py $PUBSUB_PROJECT_ID create-push $TOPIC_ID $PUSH_SUBSCRIPTION_ID http://localhost:8080 作成ができると、以下のような戻り値が表示されます。 Push subscription created: name: "projects/my-project/subscriptions/my-subscription" topic: "projects/my-project/topics/cf-test" push_config { push_endpoint: "http://localhost:8080" } ack_deadline_seconds: 10 message_retention_duration { seconds: 604800 } . Endpoint for subscription is: http://localhost:8080 動作確認 1. Functions Framework の起動 Functions Framework を起動してイベント関数をデバッグモードでモニタするため、これまでの作業で使用したものとは別のターミナルを起動します。 今回準備したイベント関数 (main.py) は、Pub/Sub エミュレータのサブスクリプションからメッセージを受信したら、それをトリガとしてメッセージ内容を出力する仕組みです。任意のディレクトリに配置してからコマンドを実行します。 (以下のコードはご自由にご利用いただけますが、あくまでサンプルコードであり、ご利用によって発生したトラブル等に関して当社では責任を持ちかねます。以下、全てのコードで同様です) main.py import base64 import json 　 def main (event, context): if 'data' in event: message = base64.b64decode(event[ 'data' ]).decode( 'utf-8' ) 　 message_dict = json.loads(message) 　 if message_dict[ "text" ]: print ( "Received:" ) print (message_dict[ "text" ]) 実行コマンド functions-framework --target=main --signature-type=event --debug --port=8080 なお、イベント関数についてもフォアグラウンドに滞在して実行されますので、以降の作業は別のターミナルを起動して実行します。 2. イベント関数のテスト Cloud Scheduler が担うはずの「メッセージの送信 (パブリッシュ)」については、ローカル環境で代替可能なツールが存在しないため、自作のサンプルスクリプト (ggen_publisher.py) を用いて実現します。 ggen_publisher.py #!/usr/bin/env python 　 import datetime import sys from google.cloud import pubsub_v1 def publish_message (project_id: str , topic_id: str , file_path: str ): # パブリッシャークライアントを作成 publisher = pubsub_v1.PublisherClient() topic_path = publisher.topic_path(project_id, topic_id) 　 # JSON ファイルを読み込み with open (file_path) as f: data_str = f.read() 　 # メッセージをパブリッシュする data = data_str.encode( "utf-8" ) future = publisher.publish(topic_path, data ) future.result() 　 return 0 　 if __name__ == "__main__" : args = sys.argv project_id = args[ 1 ] topic_id = args[ 2 ] file_path = args[ 3 ] 　 publish_message(project_id, topic_id, file_path) 次に test.json というファイル名で、 Cloud Functions に送信するメッセージの本文を定義し、スクリプトと同じディレクトリに配置します。 test.json { " text " : " this is a test message " } 次のコマンドを実行してスクリプトを動かします。 Pub/Sub 関連の変数を定義した際の作業ターミナルとは異なるため、こちらのターミナルでも変数を定義する必要があります。 引数で指定したファイル (test.json) ですが、Cloud Scheduler で送信するメッセージに相当します。スクリプトと同じディレクトリに配置した上でコマンドを実行します。 実行コマンド export PUBSUB_PROJECT_ID=my-project export TOPIC_ID=cf-test export PUSH_SUBSCRIPTION_ID=my-subscription $(gcloud beta emulators pubsub env-init) python3 ggen_publisher.py $PUBSUB_PROJECT_ID $TOPIC_ID ./test.json コマンドを実行したターミナルでは、 トピック (cf-test) に対して JSON 形式のメッセージをパブリッシュした旨のログが出力 されたことがわかります。 コマンド実行画面の出力 また、イベント関数を実行したターミナルでは、 サブスクリプションから受信したメッセージを出力 していることがわかります。 デバッグ画面の出力 これにより、今回の目的であった Pub/Sub をトリガとしたイベント関数が無事に実行されたことがわかりましたので、検証は成功です。 武井 祐介 (記事一覧) 2022年4月入社 / クラウドソリューション部 / 技術2課所属 趣味はゴルフにロードバイク。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 Google Cloud 認定全冠達成！(2023年6月)

G-genの大津です。 Google Cloud (旧称 GCP) において Amazon S3 にあるデータを BigQuery に取り込む方法のひとつとして、 BigQuery Omni があります。 BigQuery Omni を使うと、 Amazon S3 を外部データソースとして、 BigQuery からクエリを実行することができます。 今回は BigQuery Omni の使い方や注意点などをまとめてみました。 BigQuery Omni とは AWS側での操作 Amazon S3 にデータを用意する IAM ポリシーと IAM ロールの作成 Google Cloud 側の操作 BigQuery Connection API を有効にする BigQuery 外部接続の作成 データセットを作成する テーブルを作成する BigQuery から Amazon S3 にクエリを実行する BigQuery スロットの購入 まとめ BigQuery Omni とは BigQuery Omni とは、 Amazon S3 または Azure blob ストレージに保存されているデータに対して BigQuery からクエリを実行できるサービスです。これにより利用者は AWS や Azure にあるデータを BigQuery に複製することなくクエリを実行し、分析を行うことが可能です。 Amazon Redshift Spectrum の Google Cloud 版と言えばイメージしやすいでしょうか！？ すでに AWS を使用していて、分析の元データは Amazon S3 にあり、データ分析には Google Cloud の BigQuery を使用したいなどのユースケースにおいて、 BigQuery Omni は非常に有効なサービスです。 2022 年 5 月現在、 BigQuery Omni の利用にあたり以下の点にご注意ください。 BigQuery Omni が利用できる AWS 対応リージョンは「米国東部（バージニア北部）us-east-1」のみです。AWS の東京リージョン（ap-northeast-1）にあるバケットのデータにはクエリ出来ませんのでご注意ください。 BigQuery Omni は「定額 (BigQuery Reservations)」を利用する必要があります。「オンデマンド」ではご利用できません。 BigQuery Omni の詳細は、以下のページを参照ください。 cloud.google.com では、実際に BigQuery Omni を使って、 Amazon S3 のデータをクエリしたいと思います。 AWS側での操作 Amazon S3 にデータを用意する まずは Amazon S3 に、元データをアップロードしましょう。 Amazon S3 にデータをアップロードする前に、 Amazon S3 にバケットを作成します。 ※今回は「us-east1-sample-data-20220517」という名前を付けています。 バケットを作成するときに、一点注意が必要です。 2022年5月現在、 BigQuery Omni で利用できるリージョンは 「米国東部（バージニア北部）us-east-1」のみ です。 ※今後、BigQuery Omni の対応リージョンが増え「アジアパシフィック (東京) ap-northeast-1」が利用できるようになれば良いですね。 S3 バケットのリージョンに注意 IAM ポリシーと IAM ロールの作成 S3 バケットが作成できたら、次は BigQuery Omni 向けに IAM ポリシーと IAM ロールを作成します。 まずは IAM ポリシーを作成します。 IAM ページにアクセスし、左メニューの「ポリシー」をクリックし「ポリシーの作成」に進みます。ポリシーの作成は「JSON」をクリックして、以下の JSON コードを貼り付けます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::"上で作成したバケットの名前"] }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": ["arn:aws:s3:::"上で作成したバケットの名前"/*"] } ] } 実際の画面では、このような感じになります。 最後に分かりやすい名前とタグを入力して、ポリシーを作成します。 ※今回は「Googlecloud-connect」という名前を付けています。 続いて IAM ロールの作成です。以下のパラメータで IAM ロールを作成します。 信頼されたエンティティタイプ ウェブアイデンティティ アイデンティティプロバイダー Google Audience 0000（あとで正しい値に修正します） IAM ロールの作成画面 次に先程作成した IAM ポリシーをアタッチします。 ※前述で作成したIAMポリシー「Googlecloud-connect」にチェックを入れます。 最後に分かりやすい名前とタグを入力して、IAMロールを作成します。 ※今回は「googlecloud-connect-role」という名前を付けています。 IAM ロールを作成後、作成した IAM ロールを選択し、詳細画面を確認します。 「編集」をクリックして「最大セッション時間」をデフォルトの1時間から 12時間 に修正します。 この IAM ロールの ARN は、このあとの手順で使用しますので、コピーしておきましょう。 Google Cloud 側の操作 BigQuery Connection API を有効にする BigQuery Omni は BigQuery Connection API を利用します。 ナビゲーションメニューから「API とサービス」を選択し「有効な API とサービス」の画面から「API とサービスの有効化」から「BigQuery Connection API 」を検索して有効化してください。 BigQuery 外部接続の作成 BigQuery から Amazon S3 に接続するために、まずは外部接続を作成します。 外部接続の作成は、 BigQuery のコンソールから「＋データを追加」から「外部データソース」を選択します。 外部データソースは、以下のパラメータを入力し、外部接続を作成します。 接続タイプ AWS 接続 ID この外部接続リソースの名前です。 接続ロケーション aws-us-east1（デフォルトで入力済み） AWS ロール ID 前述で作成したAWS IAMロールのARNを入力します。 正しく外部接続が作成できると BigQuery のメニューに、作成した外部接続が表示されます。 ※今回は「amazon-s3-connect」という名前を付けています また作成した外部接続の詳細画面から「BigQuery Google ID」が表示されます。 ※上記キャプチャ画面ではマスキング処理しています この「BigQuery Google ID」を、前述で作成した IAM ロールの Audience に入力します。 データセットを作成する 次に BigQuery にデータセットを作成します。 作成するデータセットには Amazon S3 を指定したいので「データのロケーション」に「aws-us-east1」を指定します。 ※データのロケーションに「aws-us-east1」を指定しない場合、後述するテーブル作成時に外部接続が表示されません。 テーブルを作成する 最後に BigQuery のテーブルを作成します。 前述で作成したデータセットのアクションメニューから「テーブルを作成」を実行します。 テーブルの作成元には「Amazon S3」を選択します。 S3パスには、S3 形式を使用して Amazon S3 のパスを指定します。 ファイル形式は、S3にアップロードしたファイル形式を選択します。 対応しているファイル形式は「csv」「JSONL」「Avro」「Parquet」「ORC」です。 接続 ID には、前述で作成した外部接続が表示されますので選択します。 これまでのパラメータが正しく入力できると、以下のようなテーブルが作成されます。 BigQuery から Amazon S3 にクエリを実行する BigQuery Omni を通じて、 Amazon S3 のデータが BigQuery のテーブルとして表示されました。クエリを実行してみましょう！ クエリを実行したところ上記のエラーが表示されました。 BigQuery には「オンデマンド」と「定額 (BigQuery Reservations)」の料金モデルがありますが、 BigQuery Omni では「定額」プランでのみ利用可能 です。 そのため BigQuery Omni でクエリを実行するには BigQuery Reservations のスロットを購入する必要があります。 しかし、ご安心ください。 BigQuery Reservations には Flex という購入プランがあり、 最低 1 分単位で購入可能 です。1時間あたり約 600 円程度で検証することが可能です。 BigQuery Reservations については、以下の記事で解説されています。 blog.g-gen.co.jp BigQuery スロットの購入 BigQuery スロットを購入するには、 BigQuery コンソールの左部メニューから「容量管理」をクリックします。 スロットを購入する際のパラメータは以下の通り。 コミット期間 Flex ロケーション Amazon US East（N. Virginia） スロット数 100（最低値） まとめ BigQuery Omni を使って、非常に簡単に Amazon S3 のデータを BigQuery の外部テーブルとして表示することができました。しかし、当機能を利用するには BigQuery Reservations を購入する必要があります。 今後 Google Cloud のアップデートでオンデマンドの料金モデルが選択できるようになると、使いやすいサービスになると言えます。 大津 和幸 (記事一覧) クラウドソリューション部 2022年4月にG-gen にジョイン。 前職まではAWSをはじめインフラ領域全般のなんでも屋。二刀流クラウドエンジニアを目指して、AWSのスキルをGoogle Cloudにマイグレーション中の日々。

G-gen の杉村です。BigQuery にはアクセス制御のための仕組みが多数存在します。その中でも、 承認済みビュー と 承認済みデータセット というよく似た名前の2つの機能をご紹介します。 はじめに 当記事について BigQuery へのアクセス制御について 訳語 承認済みビュー 承認済みビューとは ユースケース 設定手順 制約 承認済みデータセット 承認済みデータセットとは ユースケース 設定手順 制約 はじめに 当記事について Google Cloud（旧称 GCP）の BigQuery には、 承認済みビュー と 承認済みデータセット というよく似た名前の2つの機能が存在します。 これらの機能を使うと、利用者に公開するデータの範囲（カラムやレコード）を制御したり、 BigQuery の権限管理に関する運用を楽にしたりすることができます。 BigQuery へのアクセス制御について 当記事でご紹介する「承認済みビュー」機能と「承認済みデータセット」機能を理解するには、 Google Cloud の IAM の仕組みの基本と、 BigQuery のアクセス制御に関する知識が前提として必要です。これらの前提知識については、以下の記事をご参照ください。 Google Cloud の IAM の基本 blog.g-gen.co.jp BigQuery における IAM blog.g-gen.co.jp 訳語 承認済みビュー（Authorized view）と承認済みデータセット（Authorized datasets）は、以前の日本語版ドキュメントではそれぞれ「承認されたビュー」「承認されたデータセット」と翻訳されていました。 現在でも、日本語版の Google Cloud 認定資格の問題文等にはこの表現で記載されている場合があります。 承認済みビュー 承認済みビューとは 承認済みビュー （Authorized views）とは、利用者に対して、ビューの元となるソーステーブルへのアクセス権限を 与えることなく 、 ビューへのアクセス権限のみを与える ことにより、アクセス制御を楽にしたり、利用者に見せるデータの粒度を制御したりできる機能です。 参考 : 承認済みビューとマテリアライズド ビュー 図で説明します。 承認済みビューの概念 この図の例の場合、利用者はビューへの権限を持っていますが、 ビューの元となっているテーブル（ソーステーブル）への権限は持っていません 。 通常ですと、利用者がビューへクエリするとき、ビューへのデータアクセス権限を持っていたとしても、同時にビューのソーステーブルへのデータアクセス権限も持っていなければ、クエリは 権限エラーで失敗 します。 しかし承認済みビューの機能により、ソーステーブルの所属するデータセットに対して「 特定のビューからのアクセスを承認する 」という設定を実施することで、利用者は、 ビューへのアクセス権限さえもっていればクエリを実行することができる ようになります。 これにより、利用者はビューだけに閲覧権限を持つので、ビューの SQL で定義された範囲のデータだけを見られるようになります。ビュー作成時の SQL の SELECT 句や WHERE 句で適切にデータを絞れば、 利用者に見せたいデータの範囲を絞って見せることができる ようになります。 なお、この機能では、データセットが承認対象のビューの一覧を持ちます。例として上記の図では source_dataset の承認対象ビュー一覧に view_a を加えることで、利用者はソーステーブルやソースデータセットに権限がなくても、 view_a にクエリを投げることができます。 ソーステーブルとビューは、同じデータセットに存在していても、違うデータセットに存在していても構いません。また、異なるプロジェクトでも問題ありません。ただしアクセス権限設定を分かりやすくするために、ソーステーブルとビューは 異なるデータセットにしたほうが望ましい でしょう。 ユースケース 以下のようなユースケースで用います。 利用者の権限をビューやそのデータセットにのみ与えることで、 IAM 管理運用を楽にする 権限をソーステーブルやソースデータセットに付与する必要がないため、権限管理のポイントを集約できる ビュー生成 SQL で 見せたいデータだけを抽出することで、 利用者が見ることのできるカラムやフィールドを制限する ただしこの場合、管理者側で任意のデータだけを抽出する SQL を書いてビューを作成し、利用者はビューの SQL を編集できないようにする必要がある 設定手順 おおまかな手順は以下のとおりです。 ソーステーブルからビューを作成 ビューまたはそのデータセットに、利用者からのアクセス権限を付与（ BigQuery データ閲覧者 等） ソーステーブルが所属するデータセットの承認対象ビュー一覧に承認したいビューを追加 詳細な設定手順は、以下のドキュメントに記載されています。 参考 : ビューを承認する ポイントは、ソーステーブルが所属するデータセットが、承認対象ビューの一覧を持つという点です。ソーステーブルでビューを承認するのではなく、ソーステーブルが所属しているデータセットの方でビューを承認します。 ソーステーブルの所属するデータセットで、承認対象のビューを追加する 制約 制約として、ソーステーブルとビューは、 同じリージョン に存在する必要があります。 もう1つの考慮点は Quota（割り当て）です。1つのデータセットで承認可能なリソース数は最大 2,500 個という制限があります。この数には後述の承認済みデータセットや、この記事で扱っていない承認済み関数（Authorized Functions）も含まれます。 参考 : BigQuery - 割り当てと上限 - データセット 承認するビューの数が多すぎてこの制限に抵触しそうな場合は、後述の承認済みデータセット機能を使って、データセット単位に「まとめる」ことを考えましょう。 承認済みデータセット 承認済みデータセットとは 承認済みデータセット （Authorized datasets）は、承認済みビューの拡張機能です。基本となる考え方は承認済みビュー機能と同じですが、承認する対象の単位がビューではなく、データセットになっています。 参考 : 承認済みデータセット 承認済みビュー機能ではソースデータセット側から ビュー単位 で個別に承認するのに対し、承認済みデータセット機能では データセット単位 で承認をするという点が異なります。 この機能を用いて、あるデータセットが別のデータセットを承認すると、 承認済みデータセットに入っている全てのビューが承認され 、クエリを受け付けることができます。 承認対象ビューの数が多い場合、個別にビューを承認すると手間だったり、ビューを作成するたびに承認を追加する必要がありますが、データセット単位で承認しておけばそのような手間がなくなります。 ユースケース ユースケースは、「承認済みビュー」と同様です。以下のような場合に「承認済みビュー」ではなく「承認済みデータセット」を使うと良いでしょう。 承認対象のビューの数が多い 承認対象のビューが増えたり減ったりする頻度が多く、都度メンテナンスする手間を減らしたい 設定手順 おおまかな手順は以下のとおりです。 ビューを入れるデータセットを作成 ソーステーブルから、ビューを作成 ビューまたはそのデータセットに、利用者からのアクセス権限を付与（ BigQuery データ閲覧者 等） ソーステーブルが所属するデータセットの承認対象データセット一覧に、承認対象のデータセットを追加 設定手順は基本的に「承認済みビュー」と同じですが、承認対象がビューなのか、データセット全体なのか、が異なります。 承認対象がビューなのか、データセット全体なのか、の違い 詳細な手順は、以下のドキュメントを参照してください。 参考 : 承認済みデータセット - データセットの承認 制約 承認する側とされる側のデータセットは、同じリージョンに存在する必要があります。 参考 : 承認済みデータセット - 制限事項 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。当記事では Google Cloud（旧称 GCP）の Virtual Private Cloud （VPC）について徹底解説します。当記事は、VPC の基本的な仕様を解説した「 基本編 」に続く「 応用編 」です。 基本編へのリンク VPC 間通信・サブネット間通信 同一 VPC 内のサブネット間通信 VPC 間の通信 VPC ネットワークピアリング VPC ネットワークピアリングとは 利点 制限 Cloud VPN による推移的な通信（カスタムルート広報） 共有 VPC 共有 VPC とは ホストプロジェクトとサービスプロジェクト 共有 VPC 管理者 その他 サーバーレス VPC アクセス サーバーレス VPC アクセスとは ユースケース コネクター サーバーレス VPC アクセスの料金 Direct VPC Egress 限定公開の Google アクセス / Private Service Connect Google Cloud APIs へのプライベート接続 サードパーティサービスへのアクセス Packet Mirroring Packet Mirroring とは ユースケース コレクタ宛先 フィルタリング アーキテクチャのベストプラクティス 基本編へのリンク 当記事は VPC の細かい仕様を解説した「 応用編 」です。以下の基本的な仕様については基本編で扱っていますので、そちらの記事をご参照ください。 Virtual Private Cloud (VPC) とは ネットワークとサブネット オンプレミスや他のクラウドとの接続 ルート ファイアウォール（Cloud NGFW） インターネットとのアクセス Google Cloud サービスへのプライベートサービスアクセス VPC フローログ ファイアウォールルールのログ VPC ネットワークの監査ログ 料金 blog.g-gen.co.jp VPC 間通信・サブネット間通信 同一 VPC 内のサブネット間通信 同一 VPC ネットワーク内のサブネット間の通信のポイントは、「同一 VPC ネットワーク内のサブネット同士は、互いに通信できる」「 リージョンが異なっても通信可能 」という点です。この柔軟性が Google Cloud の VPC の特徴です。 同一 VPC 内の VM 同士はリージョンが異なっても通信できる VPC 間の通信 異なる VPC ネットワーク同士を通信させるには、いくつか方法があります。 VPC ネットワークピアリングで接続する Cloud VPN で接続する VM（Compute Engine）を構築して、2つのサブネットにそれぞれ NIC を作成する。VM を仮想ルーターとして利用する Network Connectivity Center の VPC スポーク機能を使う 1つ目の VPC ネットワークピアリングでは、 推移的ピアリングができない （いわゆる2ホップ制限）という制約があります。これについては後述します。 2つ目の Cloud VPN では、 カスタムルート広報 により、推移的な VPC 間通信が可能です。こちらについても後述します。 3つ目のパターンは、IDS（Intrusion Detection System）やファイアウォール等の仮想アプライアンスを VM で構築するパターンでよく利用されます。VPC ネットワーク間通信の経路のネクストホップをその VM にすることで、VPC 間で通信されるパケットをインラインで検査することができます。この方法は仮想アプライアンス VM の運用・管理が必要になり、運用や設計の複雑化に繋がるため、かなり高度なセキュリティが必要なときのみ用いられるべきといえます。 参考 : 複数のネットワーク インターフェース 4つ目の Network Connectivity Center という Google Cloud プロダクトの VPC スポーク機能は、3つ以上の VPC を接続したいときに有用です。n:n で VPC ネットワークピアリングを構成しなくても、容易にフルメッシュ接続が実現できます。詳細は以下の記事の「VPC 間接続 (VPC スポーク)」の項をご参照ください。 blog.g-gen.co.jp VPC ネットワークピアリング VPC ネットワークピアリングとは VPC ネットワークピアリング （または単にピアリング）は、異なる VPC ネットワーク同士を接続できる機能です。 ピアリングで接続されたネットワーク同士は、Internal IP（Private IP）アドレスで相互に通信することができます。 また、異なるプロジェクトや異なる組織に所属する VPC ネットワーク同士でも接続することが可能です。VPC ネットワークピアリングの確立には、双方の VPC で お互いに コネクションを作成する必要があります。 参考 : VPC ネットワーク ピアリング 利点 異なる VPC に所属する Compute Engine VM 同士は、ピアリングを使わなくても External IP（Public IP）アドレスを使えば相互に通信できますが、External IP アドレスを使った通信に比べ、 VPC ピアリングでは以下の利点があります。 低レイテンシ VM に External IP アドレスを持たせる必要がないためよりセキュア 同一リージョン、同一ゾーンの VM 同士の通信に限り、VPC の下り（Egress）料金が発生しない VM 間通信時に発生するネットワーク料金については、以下の公式料金表をご参照ください。 参考 : Google Cloud 内の VM 間データ転送の料金 制限 VPC ネットワークピアリングには、以下のような制限があります。 推移的ピアリング はできない（いわゆる2ホップ制限。ある VPC をまたいでその先にいる VPC とは通信できない） VPC ネットワークピアリングは1:1で作成する。3つ以上の VPC を接続するには、フルメッシュでピアリングコネクションを作成する必要がある 接続する VPC ネットワーク同士は CIDR が重複してはいけない 1つ目の 推移的ピアリング の不可という制約は、以下の図のとおりです。A、B、C の3つの VPC ネットワークが、B を中央にして VPC ネットワークピアリングで接続されています。A と C は互いには繋がっていない状態です。このような状態では、A と C は通信することができません。 推移的ピアリングはできない なお推移的な接続を実現させたい場合、 Cloud VPN の利用を検討します。Cloud VPN であれば、 カスタムルート の Import / Export により、推移的な接続が実現できます。これについては、後述します。 2つ目は、VPC ネットワークピアリングは1:1で接続を作る必要がありますので、3つ以上のネットワークを接続したい場合は、全てのネットワーク間でフルメッシュで接続を作成する必要があります。ある VPC ネットワークに作成できるピアリングコネクションの上限は25個です。 3つ目は、VPC ネットワークピアリングで接続される VPC は、CIDR（IP アドレス帯）が重複してはいけません。ピアリング接続された VPC ネットワーク同士は、サブネットへのルートが自動的に全て交換されるため、選択的にルートを交換させることもできません。IP アドレス帯が重複した VPC ネットワーク同士を接続することを試みると、接続の作成が失敗します。 Cloud VPN による推移的な通信（カスタムルート広報） Cloud VPN を用いると、以下のような Hub-and-Spoke 型 （スター型とも呼ばれる）のネットワークトポロジを構成することが可能です。 Hub-VPC を中心としたネットワーク このネットワークは VPC (A) をハブとして、オンプレミスサイト、VPC (B)、VPC (C) と接続されています。VPC (A) とオンプレミスは、 Cloud VPN （IPsec VPN）で接続されており、VPC 間は VPC ネットワークピアリング で接続されています。 このとき、Cloud Router や VPC ネットワークピアリングがデフォルト設定のままだと、オンプレミスから VPC (B) へといった、ハブ VPC を経由した通信は できず 、直接接続されているネットワーク間のみでしか通信できません。 しかし、適切に設定すれば、図右下の表のように相互にネットワーク間通信が実現できます（ただし VPC (B) ⇔ VPC (C) 間の通信は実現 できません 。前述したとおり、推移的 VPC ピアリングとなっているからです）。 設定方法は、以下のとおりです。 Cloud Router にて、オンプレミスの対向ルーターに広報するルートを 明示的に設定 する デフォルトだと Cloud Router が紐づいている VPC (A) のサブネットの CIDR しか広報されない ピアリングで繋がっている VPC (B) と (C) のルートも追加で広報するよう、明示的に設定する VPC (A) 側の2つのピアリング設定にて、カスタムルートを エクスポートするよう設定 する これにより対向である VPC (B) および (C) にカスタムルート（オンプレから受け取った 10.0.0.0/8 のルート）が広報される VPC (B) および (C) のピアリング設定にて、対向である VPC (A) からカスタムルートを インポートするよう設定 する これにより対向である VPC (A) からカスタムルート（オンプレから受け取った 10.0.0.0/8 のルート）を受け取れる 1つ目の設定をしないと、オンプレミスルーターは VPC (B) と (C) への経路を知ることができません。Cloud Router はデフォルトだと、自分が紐付いている VPC のルートしか、対向ルーターへ広報しないためです。VPC (B) と (C) の経路を対向ルーターへ広報するよう、明示的に設定する必要があります。これを カスタムルート広報 （またはカスタムアドバタイズ）といいます。 参考 : カスタム アドバタイズ 2つ目と3つ目の設定をしないと、VPC (B) と (C) はオンプレミスへの経路を知ることができません。 カスタムルートのインポート・エクスポート の設定をすることで、VPC (A) がオンプレミスから受け取った 10.0.0.0/8 というルートを、VPC (B) と (C) に教えることができます。 なおここでいう カスタムルート とは、Google Cloud によって自動的に生成されるルート（デフォルトルートやサブネット間のルート） 以外 の動的 / 静的なルートを指しています。この図でいえば、オンプレミスから BGP で受け取った 10.0.0.0/8 へのルートがカスタムルートになります。 参考 : ルートのタイプ 上記のような一通りの設定を済ますと、VPC (A) をハブとした相互通信が可能になります。 共有 VPC 共有 VPC とは 共有 VPC （Shared VPC）機能を使うと、ある Google Cloud プロジェクトに配置した VPC ネットワークを、他のプロジェクトに 共有 することができます。 共有された側のプロジェクトでは、共有された VPC ネットワーク内に、VM 等のリソースを配置することができます。ルートやファイアウォールなどの設定は、共有元のプロジェクトでしか変更できないため、ネットワークセキュリティの管理を集約して一元化することができます。 なお API 名や IAM ロールなどにおいて、共有 VPC は xpn と表現されることがあります（ roles/compute.xpnAdmin など）。 参考 : 共有 VPC ホストプロジェクトとサービスプロジェクト 共有 VPC を設計する際は、1つの ホストプロジェクト を決めます。 このホストプロジェクトが、共有 VPC の「親」となり、 VPC ネットワーク自体の設定、サブネットの追加・削除、セカンダリアドレスレンジの設定、ファイアウォールルールの設定などを行うことができます。 そして共有された VPC を利用する「子」プロジェクトが サービスプロジェクト です。サービスプロジェクトは、共有 VPC に対して Compute Engine の VM 等のリソースを配置して利用することができます。 なお、プロジェクトはホストプロジェクトであると同時にサービスプロジェクトになることはできません。 共有 VPC 管理者 共有 VPC 管理者 （Shared VPC Admin）は、共有 VPC を管理する Google アカウントです。 共有 VPC 管理者が、ホストプロジェクトにしたいプロジェクトにおいて、ホストプロジェクトを有効化します。さらに、共有先のプロジェクトをサービスプロジェクトとして追加することができます。 共有を受けたサービスプロジェクト側は、その VPC ネットワークのサブネットに対して、VM 等を構築することができます。 その他 共有 VPC には、他にいくつかの重要な概念があります。 組織のポリシー（ホストプロジェクトになれるプロジェクトを制限可能） IAM（ホスト側、サービス側） コスト（Egress traffic cost はサービスプロジェクト側に課金） 詳細は、公式ドキュメントをご参照ください。 参考 : 共有 VPC サーバーレス VPC アクセス サーバーレス VPC アクセスとは サーバーレス VPC アクセス とは、Cloud Run、App Engine（Standard）、Cloud Run functions などのサーバーレス実行環境から VPC ネットワーク内のリソースにアクセスするための仕組みです。 サーバーレス VPC アクセスを設定すると、VPC 内に コネクター が作成されます。コネクターは、VPC ネットワーク内の専用サブネットとコネクタインスタンスで構成されています。このコネクタインスタンスは Compute Engine のコンソールからは見えない、Google によって管理される VM です。 Cloud Run などのサーバーレス環境で実行されるプログラムから、VPC ネットワーク内の Compute Engine VM にリクエストを投げようとすると、通常はインターネット経由で、VM の Public IP アドレスへ通信することになります。Cloud Run services 等の作成時に接続先コネクターを指定することで、Private IP アドレス宛のパケットがコネクター経由で VPC ネットワークにルーティングされるようになります（Public IP アドレス宛てのパケットは、引き続きインターネット経由で送信されます）。 参考 : サーバーレス VPC アクセス ユースケース 例として Cloud Run、App Engine（Standard）、Cloud Run functions で実行するプログラムから、以下のリソースへアクセスを行うとき等に、サーバーレス VPC アクセスの利用を検討します。 Memorystore にデータをキャッシュする Compute Engine VM でホストされた Web API へアクセスする オンプレミスのデータベースに Cloud VPN や Cloud Interconnect を経由してアクセスする コネクター 前述の通り コネクター は、VPC ネットワーク内の専用サブネットとコネクタインスタンスを指します。 コネクターの作成時には /28 のプレフィクスで新しいサブネットを作成するか、作成済みで未使用の /28 のサブネットを指定します。 またコネクター作成時に、コネクタインスタンスの min-instances と max-instances を指定して、スケールの最小値・最大値を指定します。ただし2025年3月現在の仕様として、インスタンス数の変動はスケールアウトのみとなっており、スケールインはされません。またコネクタ作成後は min-instances と max-instances の値を変更することはできません。インスタンス数が多いと、その分の料金が発生します。なお min-instances の設定可能最小値は2、 max-instances の設定可能最大値は10です。 コネクタインスタンスは f1-micro 、 e2-micro 、 e2-standard-4 から選択します。左記の順に1台あたりのスループットが高くなりますが、利用料金も高くなります。1台あたりで処理可能な帯域は、以下のとおりです。 マシンタイプ 1 台あたりの帯域 f1-micro 50 Mbps e2-micro 100 Mbps e2-standard-4 1,600 Mbps サーバーレス VPC アクセスの料金 コネクタインスタンスのマシンタイプと、インスタンス数に応じて課金されます。料金単価は、Compute Engine VM の通常の料金表を参照します。 例として2025年3月現在の東京リージョンで、マシンタイプを f1-micro 、 min-instances を2として、スケールアウトが発生することなく1ヶ月間利用した場合、利用料金は $13.432/月です。 参考 : VM インスタンスの料金 Direct VPC Egress サーバーレス VPC アクセスより後発の機能として、Cloud Run には Direct VPC Egress があります。Cloud Run で Direct VPC Egress を有効化すると、サーバーレス VPC アクセスコネクタを使用せずに VPC ネットワークにトラフィックを送信できるようになります。 Direct VPC Egress ではコネクタインスタンスの料金が発生しないことに加え、より低レイテンシーで通信することができます。制限に抵触しない場合は、Cloud Run ではまず、Direct VPC Egress の利用を検討します。詳細は以下を参照してください。 blog.g-gen.co.jp 限定公開の Google アクセス / Private Service Connect Google Cloud APIs へのプライベート接続 限定公開の Google アクセス と Private Service Connect は、 VPC ネットワーク内の VM 等から Google Cloud の API へアクセスする際に、Private IP アドレスでアクセスするための仕組みです。 Google Cloud APIs はインターネットからの接続を受け付けますので、通常は Public IP アドレスでアクセスすることになりますが、限定公開の Google アクセスや Private Service Connect を使うことで、VM 等は Public IP アドレスを持つことなく、 Private IP アドレスで Google Cloud APIs にアクセス できます。 限定公開の Google アクセスと Private Service Connect はよく似た機能ですが、後者のほうが後発であり、より充実した機能を持っています。 詳細はそれぞれ、以下の記事で紹介していますので、ご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp サードパーティサービスへのアクセス Private Service Connect にはもう1つの機能があります。それは サードパーティサービスへのプライベート接続 です。 この機能により、Google Cloud ユーザーは、VPC ネットワークピアリングや Cloud VPN を使うことなく、自身の VM でホストしたサービスを他の Google Cloud ユーザーに公開することができます。公開されたサービスへは、Private Service Connect エンドポイントを介して、Private IP アドレスでアクセスすることができます。 トラフィックは NAT されるため、サービス利用者と IP アドレスが重複することを気にする必要がありません。 参考として、当機能は AWS でいう AWS PrivateLink に相当します。 当機能に関する詳細はは、以下の記事を参考にしてください。 blog.g-gen.co.jp Packet Mirroring Packet Mirroring とは Packet Mirroring （パケットミラーリング）とは、指定のインスタンスに出入りするパケットをキャプチャ・複製し、別のインスタンスに対して送信する機能です。 当機能は、VPC ネットワークのある地点でパケットを監視するのではなく、 特定インスタンスに出入りするパケット をミラーします。 また、VM はインスタンスタイプごとにネットワーク帯域の上限が決まっていますが、Packet Mirroring はこの帯域を消費します。 Packet Mirroring では、サブネット全体やネットワークタグを指定して、複数のインスタンスをまとめて対象にすることもできます。 参考 : Packet Mirroring ユースケース Packet Mirroring は、主にセキュリティ目的のモニタリングと分析で使用することが想定されています。 また場合によっては、パケットの詳細な解析が必要なネットワークのトラブルシューティングにも活用できます。 コレクタ宛先 Packet Mirroring は、指定インスタンスからパケットを複製して、 コレクタ宛先 （collector destination）に送信します。 コレクタ宛先は Internal TCP/UDP Load Balancer とその背後の VM（パケット分析用）で構成されます。宛先 VM はロードバランサーの背後にあるため、冗長化したり、マネージドインスタンスグループによる Autoscaling を利用することができます。 コレクタ宛先となる VM にパケットを解析する仕組みを配置することで、リアルタイムにパケットを分析することができます。 フィルタリング Packet Mirroring は、すべてのパケットをキャプチャすることもできますが、以下の軸でフィルタすることもできます。 プロトコル IP アドレス範囲（CIDR） トラフィックの方向 ... 上り（Ingress）のみ / 下り（Egress）のみ / 両方 このフィルタは、 パケットミラーリングポリシー で設定します。パケットミラーリングポリシーは複数設定でき、優先度は一定のルールに基づいて判断されます。 プロトコルが重複 → 最も狭い IP アドレス範囲のルールが優先（ 10.240.1.0/24:ALL > 10.240.0.0/16:TCP ） IP アドレス範囲が完全に一致 → 最も特定されているプロトコルが優先（ 10.240.1.0/24:TCP > 10.240.1.0/24:ALL ） これにより、あるインスタンスのパケットが複数のポリシーに一致してしまったときにどのポリシーが適用されるかが決定され、パケットがミラーされるか無視されるかが決まります。 アーキテクチャのベストプラクティス 以下の公式ドキュメントには、VPC 設計におけるベストプラクティスや、リファレンスアーキテクチャが掲載されています。 参考 : VPC 設計のためのおすすめの方法とリファレンス アーキテクチャ 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは、G-gen の武井です。今回は Google Cloud (旧称 GCP) で Cloud Functions の関数をローカルで検証できる Functions Framework のインストール方法について紹介したいと思います。 cloud.google.com 前提条件 1. Linux 開発環境 を有効化 2. gcloud コマンドのインストール・初期化 Functions Framework の導入 1. venv・pip3 のインストール 2. venv 仮想環境の作成 3. Functions Framework のインストール 動作確認 1. ソースの準備 2. Functions Framework の実行 仮想関数からの Cloud SDK 実行 前提条件 1. Linux 開発環境 を有効化 当社では全社員が Chromebook (Chrome OS) を使って業務をしています。 そのため本記事では、ローカル環境とは Chromebook のデベロッパー向け機能である「 Linux 開発環境」を指しています。 もちろん Chromebook でなくても Functions Framework は使用できるので、 Chromebook ではない環境へ Functions Framework をインストールする場合は、当項目はスキップしてください。 Chromebook の Linux 開発環境機能を用いると Chromebook 内に Linux (Debian) のコンテナが起動し、ターミナルで操作することができます。 Linux 環境を有効化するには 設定 > 詳細設定 > デベロッパー > Linux 開発環境 から同機能を有効化します。 設定画面 (このスクリーンショットでは既に有効化済み) 2. gcloud コマンドのインストール・初期化 ※この手順は通常の gcloud コマンドと同じです。また、実施が必要なのは始めの1回だけです。 ドキュメント「 Cloud SDK のインストール 」に従い Linux 環境に gcloud コマンドをインストールします。 上記リンク先の Debian/Ubuntu の手順に従ってください。 インストールできたら gcloud init コマンドで初期化します。 アカウントやプロジェクトを指定しましょう。 Functions Framework の導入 1. venv・pip3 のインストール Chromebook の Linux 開発環境にはあらかじめ Python3.x がインストールされています。 マイナーバージョンは Linux 開発環境を有効にしたタイミングによって異なる場合があり、私の場合は v3.9 がインストールされていました。 ただ、venv や pip についてはインストールされていませんでしたので、以下のコマンドを実行してインストールします。 sudo apt update && sudo apt install python3-pip 2. venv 仮想環境の作成 ​ Functions Framework を実行するための venv 仮想環境を準備して、そこにパッケージ類をインストールしたいと思います。 ​ ・プロジェクトの作成 (プロジェクト名は ”function” とする) ​ mkdir function ・仮想環境の作成と初期化 ​ cd function python3 -m venv venv source venv/bin/activate 仮想環境が起動していると、プロンプトに仮想環境名が表示されます。 venv 仮想環境が起動している状態 ​ 3. Functions Framework のインストール ​ 準備した venv 仮想環境に Functions Framework をインストールします。 ​ ​ pip3 install functions-framework 動作確認 1. ソースの準備 こちらの Quickstart にしたがって簡単な動作確認を実施したいと思います。 github.com venv 仮想環境上に任意の作業ディレクトリを作成し、そこにソースファイル (main.py) を準備します。 Chromebook の場合、 vscode.dev を使えばファイルの作成と Linux 開発環境への配置が簡単に行なえます。 vscode.dev から Linux コンテナのファイルを編集 vscode.dev から Linux コンテナのファイルを編集 2. Functions Framework の実行 ソースファイルを配置したディレクトリ上で Functions Framework をデバッグモードで実行します。"hello" はソースファイル上で定義した関数名です。 functions-framework --debug --target hello ターミナル画面にデバッグが出力されますので、 http://localhost:8080 にアクセスします。 関数で定義したとおり Hello world! が表示されれば Quickstart にしたがった動作確認は完了です。 関数 (Hello world!) が表示 仮想関数からの Cloud SDK 実行 functions-framework で起動した仮想的な function の中から Cloud SDK を実行する場合があると思います。 例えば BigQuery へデータを投入したり Cloud Storage のオブジェクトを操作する、などです。 Cloud SDK は IAM 認証を必要とします。そのとき、どのように認証すればよいのでしょうか。 そんなときは functions-framework の実行環境で以下のコマンドを実行します。 gcloud auth application-default login このコマンドを実行することで gcloud に設定されている認証情報で ~/.config/gcloud/application_default_credentials.json に認証情報ファイルが作成され、これを使って Cloud SDK が実行されるようになります。 参考 : リファレンス 武井 祐介 (記事一覧) 2022年4月入社 / クラウドソリューション部 / 技術2課所属 趣味はゴルフにロードバイク。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 Google Cloud 認定全冠達成！(2023年6月)

G-gen の杉村です。当記事では Google Cloud の Virtual Private Cloud（略称 VPC）について徹底解説します。なお当記事は VPC の基本機能に絞った「 基本編 」です。「 応用編 」もあわせてご参照ください。 Virtual Private Cloud（VPC）とは ネットワークとサブネット ネットワーク サブネット サブネットの IP アドレス サブネット作成モード VPC 間接続 オンプレミスや他のクラウドとの接続 ルート ファイアウォール（Cloud NGFW） インターネットとのアクセス VM とインターネット間の通信 Cloud NAT インターネットとの通信を防ぐ方法 プレミアムティアとスタンダードティア Google Cloud サービスへのプライベートサービスアクセス 運用 VPC Flow Logs ファイアウォールルールのログ VPC ネットワークの監査ログ 料金 概要 トラフィック量への課金 IP アドレスへの課金 その他機能への課金 応用編へのリンク Virtual Private Cloud（VPC）とは Virtual Private Cloud （以下、VPC）とは Google Cloud（旧称 GCP）に仮想ネットワークを構築するためのサービスです。構築された VPC ネットワークは、他の Google Cloud 利用者からは完全に独立したプライベートネットワークとなります。 VPC ネットワークは サブネット と呼ばれる小分けしたネットワークに分割され、サブネットにはプライベート IP アドレス帯が割り当てられます。サブネット内には Compute Engine の仮想マシン（VM）を配置したり、Google Kubernetes Engine（GKE）のクラスタを配置したり、App Engine（Flexible）のアプリを配置することができます。 VPC ネットワークは、IPSec VPN（サービス名 Cloud VPN ）や専用線（サービス名 Cloud Interconnect ）を使って、オンプレミスのネットワークや、他のパブリッククラウドのネットワークと接続することもできます。 参考 : Virtual Private Cloud（VPC）の概要 VPC は、Andromeda という Google のネットワーク仮想化技術を使って実装されています。仮想的なネットワークのため、物理ネットワークで考慮が必要な「セグメントを小さく分けることでブロードキャストドメインを分割し、ネットワークの輻輳を軽減する」といった考慮は 必要ありません 。そのため、物理的なネットワークとはネットワーク設計の勘所が異なる点に注意が必要です。 ネットワークとサブネット ネットワークとサブネット ネットワーク VPC ネットワーク または単に ネットワーク とは、VPC で構築された1つのネットワークのことを指しています。 ネットワークは グローバルリソース です。これは、ネットワークが リージョンをまたぐ存在 であることを示しています。 他のパブリッククラウドの代表例として Amazon Web Services（AWS）を例に取ると、VPC はリージョンリソースであり、リージョンごとに VPC を作成する必要があります。これに対して Google Cloud の VPC はグローバルリソースであるため、作成時にリージョンを指定する必要がありません。ネットワークの中にサブネットを作成する際に、リージョンを指定します。 また VPC ネットワークは IP アドレス帯を 持ちません 。Google Cloud では VPC 内のサブネットが、 サブネットごとに IP アドレス帯を持ちます 。このことから、VPC は「サブネットをまとめるグルーピングリソースである」と解釈することもできます。 ネットワークは中に「ルート」「ファイアウォールルール」などの子リソースを持ちます。これらもグローバルリソースです。 参考 : VPC ネットワーク サブネット サブネット （もしくはサブネットワーク）は、VPC ネットワークの中に存在する、小分けされたネットワークです。 サブネットは リージョンリソース であるため、作成時にリージョンを指定します。また、作成時に IP アドレス帯 を CIDR 形式 で指定します。 サブネットを作って初めて、その中に Compute Engine の VM（仮想サーバー）などを配置することができるようになります。 前述しましたが、VPC ネットワークやサブネットは仮想的な存在のため「セグメントを小さく分けることでブロードキャストドメインを分割し、ネットワークの輻輳を軽減する」といった考慮は 必要ありません 。 また、セグメントを分けることは通信制御にはなりません。同一 VPC に所属するサブネット同士は自動的にルートが生成され、 相互に通信することができます 。サブネット同士の通信制御を行いたいときは、後述のファイアウォールルールにより行います。 「同一 VPC に所属するサブネット同士は通信できる」という原則は、リージョンが異なっても変わりません。違うリージョンのサブネット同士でも、同一 VPC に所属していれば相互に通信することができます。 参考 : サブネット サブネットの IP アドレス サブネットには CIDR 形式 で IP アドレス範囲を指定します。サブネットには IPv4 または IPv6 範囲を割り当てることが可能です。 IPv4 では、 10.0.0.0/8 、 172.16.0.0/12 、 192.168.0.0/16 、すなわち RFC 1918 のプライベート IP アドレス範囲の中から割り当て可能なほか、その他のいくつかの範囲が利用可能です。 最小のサブネットサイズは /29 （IP アドレス数が8個。後述の予約アドレスを除くと利用可能は4個のみ）です。 参考 : 有効な IPv4 範囲 参考 : IPv4 サブネット範囲の制限事項 なおサブネットの IP アドレスの第4オクテットのうち、最初の2つと最後の2つの IP アドレスは Google Cloud によって予約されているため、ユーザーは利用することができません。 例えば 10.1.2.0/24 というサブネットであれば、 10.1.2.0 、 10.1.2.1 、 10.1.2.254 、 10.1.2.255 は予約アドレスであり、VM インスタンス等を配置することができないことになります。 参考 : IPv4 サブネット範囲で使用できないアドレス その他に、禁止されているサブネット範囲が存在します。Google に予約されている 199.36.153.4/30 や 199.36.153.8/30 、リンクローカルアドレスである 169.254.0.0/16 などです。詳細なリストは以下の公式ドキュメントに記載があります。 参考 : 禁止されている IPv4 サブネット範囲 サブネット作成モード VPC 構築時にサブネットを作成する際、 自動モード と カスタムモード から選択できます。 自動モードを選択すると、全リージョンに1つずつ、自動的にサブネットが作成されます。各サブネットの CIDR ブロックは 10.128.0.0/9 の範囲から決まった CIDR が自動的に設定されます。このモードでは、不要なリージョンにも自動的にサブネットが作成されること、また CIDR が特定のものになってしまうことから、 検証目的等 でのみ使うことが推奨されます。 自動モードの VPC で割り当てられる IP アドレス範囲は、以下のドキュメントを参照してください。 参考 : 自動モードの IPv4 範囲 一方のカスタムモードでは、自動的にサブネットが作成されることはなく、サブネット作成先のリージョンや CIDR はユーザーが指定します。VPC ネットワークを作成すると、サブネットのない空のネットワークができあがるため、「東京リージョンに 192.168.0.0/24 でサブネットを作成」のように個別にサブネットを作成していきます。 本番用途等ではこちらのカスタムモードを利用 することが推奨されています。 参考 : サブネット作成モード VPC 間接続 異なる VPC 間同士は、 VPC ネットワークピアリング 機能で接続することができます。当機能では、異なる Google Cloud プロジェクトにある VPC とも接続させることが可能です。 VPC ネットワークピアリングの使用条件として、サブネットの IP アドレス範囲が重複していないことがあります。また VPC ネットワークピアリング経由では、 推移的ピアリングはできない などの制限もあります。つまり、 VPC A <=> VPC B <=> VPC C がそれぞれピアリングされている場合で、 VPC A と VPC C が直接ピアリングされていない場合、 VPC A と VPC C は通信することができません（間の VPC B を経由して反対側に到達することはできません）。これは、いわゆる「2ホップ制限」として知られています。 参考 : VPC ネットワーク ピアリング また Cloud VPN を使って VPC 間を接続することも可能です。Cloud VPN では推移的な接続が可能ですが、料金が発生する点が VPC ネットワークピアリングとの違いです。 これらの仕様は、 応用編 の記事で紹介します。 オンプレミスや他のクラウドとの接続 VPC は Cloud VPN と呼ばれる IPSec VPN の仕組みや、 Cloud Interconnect という専用線サービスを使うことで、オンプレミスの既存ネットワークや、他のパブリッククラウドのネットワークと接続することが可能です。 これによりインターネットを介さず、プライベート IP を用いて他のネットワークから Google Cloud の VPC 内のリソースにアクセスすることができます。 他のネットワークと VPC の接続においては、原則として接続される他のネットワークと VPC サブネットの IP アドレス帯が 重複していないこと が条件です。ルーティングの設定によっては一部が重複していても通信が可能になる場合がありますが、シンプルなルート設計のためには、 VPC 設計の際に他のネットワークとの接続の可能性は十分考慮に入れる ことが推奨されます。 当記事では Cloud VPN や Cloud Interconnect については詳述しないため、以下のドキュメントをご参照ください。 参考 : Cloud VPN の概要 参考 : Cloud Interconnect の概要 また Cloud VPN については以下の記事もご参照ください。 blog.g-gen.co.jp さらに、Google Cloud の VPC と、Amazon Web Services（AWS）や Microsoft Azure など他クラウドのネットワークを接続することができる Cross-Cloud Interconnect と呼ばれる専用線サービスも存在します。以下の記事をご参照ください。 blog.g-gen.co.jp ルート ルート は、VPC ネットワーク内のパケットが従う、ルーティングのルールです。VPC ネットワーク単位でルートテーブルが存在します。 注意すべき点は、VPC のルートは「VPC ネットワークの 中から外へ パケットが到達するための経路を指定する」ルールである、という点です。逆方向、つまり VPC の 外から中方向への 経路は 自動的に生成され、削除することができません 。 ルートには、最初から Google Cloud により生成される システム生成ルート とユーザーが自分で定義する カスタムルート があります。インターネットへ通信するためのデフォルトゲートウェイルートや、同一 VPC 内のサブネット同士のルートは自動的に生成されます。なお、前者は削除したり置換したりできますが、後者は削除や変更ができません。 参考 : ルート 前述の通り、同一 VPC ネットワーク内のサブネット同士の通信は自動的にできるようになりますので、特に追加の設定は必要ありません。また VPN や専用線で VPC ネットワークを他のネットワークと接続する際も、仕様上、多くの場合で BGP による動的ルート交換が行われるため、VPC ルートテーブルに手動でルートを追加することは稀です。ルートの追加設定が必要になるのは、以下のような限られた場面です。 特定ネットワークへのパケットを VM 上の仮想アプライアンスへルーティングしたい場合 Cloud VPN の Classic VPN 機能を使っており、静的ルートの追加が必要な場合 このように、Google Cloud の VPC では、ルートを手動で編集する機会は少ないといえます。むしろ VPN、専用線、VPC Peering 等で他ネットワークへ接続する際に、ルート交換が正常に行われているかを確認する際などに参照する方が多いです。 ファイアウォール（Cloud NGFW） Google Cloud の VPC には備え付きのファイアウォール機能があります。これは Cloud Next Generation Firewall （以下、Cloud NGFW）という Google Cloud プロダクトとしてブランディングされていますが、VPC と密に連携しています。 参考 : Cloud NGFW の概要 Cloud NGFW はフルマネージドの分散システムであり、一般的なファイアウォールアプライアンスのようなイメージではなく、VPC 内の通信に対して透過的に制御をかけます。ユーザは、Google Cloud コンソールや gcloud コマンドラインでルールを追加するだけでよく、インフラの管理などを考える必要がありません。 当機能は Amazon Web Services（AWS）における「セキュリティグループ」に相当しています。 詳細は以下の記事で解説しています。以下の記事は Cloud NGFW の全体像を解説していて読むのに時間がかかるので、基本的な理解だけをしたい人は、まずは以下記事の「概要」「VPC ファイアウォールルール」だけをお読みください。 blog.g-gen.co.jp インターネットとのアクセス VM とインターネット間の通信 VPC ネットワーク（サブネット）内からインターネットへ接続することも可能です。 VPC には デフォルトインターネットゲートウェイ （default-internet-gateway）が存在し、サブネット内の VM はこれを通じてインターネットと通信することができます。 VM がインターネットと通信するには以下の条件を 全て 満たしている必要があります。 VPC のルートにデフォルトインターネットゲートウェイへの経路が存在する VM が External IP（外部 IP、いわゆる Public IP）アドレスを持つ VM とインターネット上のノード間の通信が VPC ファイアウォールで許可されている VPC ネットワークが作成されると、いくつかのルートがシステムによって自動生成されます。その中には 0.0.0.0/0 をデフォルトインターネットゲートウェイへ向けるルートも存在しているため 1. に関して、追加の手順は必要ありません。 参考 : システム生成のデフォルト ルート 2. について、全ての VM は Internal IP（内部 IP、Private IP）アドレスを持ちますが、インターネットと通信するための External IP（いわゆる Public IP）アドレスについては、VM の構築時に持たせるかどうかを選択できます。VM 構築後でも、停止時であれば Exnternal IP アドレスの有無を変更できます。 参考 : 外部 IP アドレス 3. については、VPC のファイアウォール（Cloud NGFW）にて VM とインターネット上のノードの間の通信が許可されている必要があります。VM から始まる 通信であれば下り（Egress）ルールで、 外部から始まる 通信であれば上り（Ingress）ルールで許可されている必要があります。VPC ファイアウォールルールでは、デフォルトでは下り（Egress）ルールで 0.0.0.0/0 に対する通信を許可、上り（Ingress）ルールでは 0.0.0.0/0 からの通信を拒否しているので、上り通信を許可するには明示的にルール追加する必要があります。 参考 : 暗黙のルール Cloud NAT Cloud NAT はフルマネージドな NAT 機器です。External IP を持っていない VM でも、インターネットへの通信（VM から開始しインターネットへ到達する方向の通信）が可能になります。 フルマネージド とは、このサービスの基盤が Google Cloud によって完全に管理されていることを意味しています。我々利用者は、一度 Cloud NAT を使用する設定を追加すれば「障害対応」「パッチ適用」「性能監視・スケーリング」などを行う必要がありません。Cloud NAT のバックエンドは仮想化・分散アーキテクチャになっており、スケーラビリティ・可用性・パフォーマンスが確保されています。 Cloud NAT を VPC ネットワークに追加すれば、 External IP を持たない VM でもインターネットへ通信することができます。逆にインターネットから開始して VM へ到達する方向の通信は許可されません。これにより例えば「パッチ配信サーバからのファイルダウンロード」「インターネット上のソースコードレポジトリからのソースコード取得」「SaaS サービスの HTTP API 呼び出し」などがセキュアに可能になります。 以下の条件を 全て 満たすと、VM は Cloud NAT を利用してインターネットへ出ていくことができます。 VM の所属するサブネットが Cloud NAT を利用するよう紐付けられている VM に External IP（外部 IP）アドレスが割り振られていない VPC のルートにて 0.0.0.0/0 のネクストホップがデフォルトインターネットゲートウェイになっている ファイアウォールの下り（Egress）ルールで通信が許可されている Cloud NAT はフルマネージドであるため多くの場合で簡単に利用できますが、様々な機能や仕様を持っています。詳細は以下の公式ドキュメントをご参照ください。 参考 : Cloud NAT の概要 インターネットとの通信を防ぐ方法 セキュリティ上の理由で VPC 内の VM とインターネットの接続をさせないようにするには、以下のような方法があります。 VPC のルートを編集してデフォルトインターネットゲートウェイへのルートを削除する VM に External IP アドレスを持たせない ファイアウォール（Cloud NGFW）で通信を制限する 1. のようにルートを削除してしまえば、 VPC 内の全ての VM はインターネットと通信できなくなります。 影響範囲は VPC 全体 となるので、もし同一 VPC 内にインターネットとの通信要件の異なる複数の VM がある場合は、この方法は取れません。AWS を例に取ると「パブリックサブネット」「プライベートサブネット」のように通信要件ごとにネットワークセグメントを分けるケースがありますが、 Google Cloud においてはこれは実現できません。実現する場合は VPC ごと分割することになります。 2. は読んで字のごとく、 VM に External IP アドレスを持たせないことで、ルート設定等に関係なく通信できなくさせてしまう方法です。ただし前述の Cloud NAT が設定されていると、External IP を持たない VM はインターネットへ 出ていく ことは可能となってしまいます。これを防ぐには 3. を実施します。 参考 : 外部 IP アドレスを使用しない方法 3. は VPC のファイアウォールでブロックする方法です。前述のように VPC を分割すると管理面で煩雑になる場合があるため、Google Cloud の場合は、 ファイアウォールでインターネットとの通信可否を制御することが多い といえます。なお前述の通りファイアウォールの 上り（Ingress）はデフォルトで 拒否（Deny）のため、インターネット から VM への通信は明示的に許可しなければ到達しません。逆に下り通信はデフォルトで許可（Allow）のため、明示的に拒否ルールを追加しなければ、VM から外部方向への通信は可能なままです。 プレミアムティアとスタンダードティア VPC ネットワーク内の VM とインターネット間の通信では、料金の異なる ネットワークティア を、VM やロードバランサーごとに選択することができます。 プレミアムティア と スタンダードティア の2種類があり、前者は Google の持つ高品質な専用バックボーンネットワークを利用し、後者はコストパフォーマンスに優れた通常のインターネットを利用するティアです。デフォルトでは前者が利用されるようになっており、また Google の推奨は前者です。 前者は高品質・高パフォーマンスであり、特にグローバルに利用されるシステムでの利用が推奨されています。一方で後者は、単一の地域で利用されるシステムで、かつコスト最適化が望まれる場合に利用されます。 参考 : Network Service Tiers の概要 前述のとおり、料金は 下り方向のパケットのデータ量 に応じて課金されます。具体的な料金単価は、以下のページから確認できます。 参考 : Network Service Tiers の料金 Google Cloud サービスへのプライベートサービスアクセス いくつかの Google Cloud サービスは、リソース配置に専用の VPC ネットワークとサブネットを使います。例えば以下のようなサービスです。 Cloud SQL Memorystore Cloud Build Vertex AI 上記のサービスでは、リソースを作成すると サービスプロデューサーのネットワーク と呼ばれる専用の VPC ネットワークに配置されます。例として AWS の Amazon RDS ではユーザーの VPC・サブネット内にインスタンスが配置されますが、Google Cloud の Cloud SQL では、ユーザーの VPC ではなく 、Google が管理する専用 VPC ネットワークの中にインスタンスが配置されます。 ユーザーの VPC ネットワークとサービスプロデューサーのネットワークは VPC ネットワークピアリングで接続 され、ユーザーの VM からはピアリング経由で、Cloud SQL インスタンス等に到達します。 このサービスプロデューサーのネットワークの IP レンジ（CIDR）は、ユーザー側で指定できます。その際には、ユーザーの VPC ネットワークと重複しない CIDR を指定する必要があります。 一度サービスプロデューサーのネットワークを作成すれば、その中に複数の Cloud SQL インスタンスや Memorystore インスタンスを配置することが可能です。 なお、この一連の仕組みは プライベートサービスアクセス と呼ばれます。 参考 : プライベート サービス アクセス プライベートサービスへのアクセス 運用 VPC Flow Logs VPC Flow Logs （VPC フローログ）とは、VM によって送受信されたトラフィック記録のサンプルをログとして保存する仕組みです。利用目的としては以下が挙げられます。 ネットワークモニタリング トラブルシューティング 費用最適化 セキュリティ（フォレンジック、リアルタイム分析） VPC Flow Logs では全てのトラフィックが記録対象となるわけではなく、事前に指定するサンプリングレート（%指定）に基づいた割合のトラフィックのログだけが記録されます。また「特定の VM のみ」「特定送信元 IP のトラフィックのみ」といったように記録する対象トラフィックをフィルタすることもできます。 なお VPC Flow Logs は、VPC の仮想化基盤に高度に組み込まれていることから、有効化してもパフォーマンス遅延等は発生しません。 参考 : VPC Flow Logs VPC Flow Logs にはいわゆる 5 タプル（送信元 IP アドレス、送信元ポート番号、送信先 IP アドレス、送信先ポート番号、プロトコル番号) が含まれる他、時刻、バイト数、 TCP の ACK のレイテンシなどが含まれます。VPC Flow Logs ではこういった パケットの関連情報 が記録されるのであり、 パケットそのものがキャプチャされるのではありません 。 オプションで メタデータの記録 を有効化すると、ログのサイズは大きくなりますが、通信を行った VM や VPC ネットワークに関する追加情報も記録されるようになります。 参考 : VPC Flow Logs のレコードについて VPC フローログの有効化有無や、サンプリングレート等の設定は、 サブネットごと に設定できます。サブネット作成時に決定するほか、あとからでも変更可能です。 参考 : VPC Flow Logs を構成する 当機能で記録されたログは、デフォルトでは Cloud Logging のログバケットに保管されます。Cloud Logging の詳細や料金については以下をご参照ください。 blog.g-gen.co.jp デフォルトのログバケットであれば、ログは30日間保存され、この範囲内であれば保存料金は無料です。ただし保存料金とは別に、取り込んだログのサイズに応じた料金が発生します。2025年3月現在では $0.50/GiB/月です。これは、Cloud Logging の Vended Network Logs ストレージ料金（$0.25/GiB/月）と、VPC のネットワークテレメトリー料金（$0.25/GiB/月）を併せた金額です。ネットワークテレメトリー料金は、取り込み量に応じて徐々に単価が安くなります。詳細は公式ドキュメントを参照してください。 参考 : Cloud Logging の料金概要 参考 : ネットワーキングのすべての料金体系 ファイアウォールルールのログ ファイアウォールルールのログ は、ファイアウォールのルールの監査、検証、分析のために用いるログです。以下のような目的で利用されます。 意図通りにファイアウォールルールが許可/拒否しているか確認 特定のルールが何台の VM に影響を与えているか調査 トラブル時に通信にファイアウォールが影響しているかの確認 特徴として、ファイアウォールルールのロギングはファイアウォールの ルールごと に設定します。VPC ごと（ルールテーブルごと）ではありません。1行のルールごとに「ロギングの有効、無効」と「メタデータを含むか否か」を設定します。ログは、VPC Flow Logs と同様、Cloud Logging に出力されます。 なお当ロギング機能は VPC ファイアウォールとファイアウォールポリシーの両方で使用可能です。 参考 : ファイアウォール ルールのロギング ファイアウォールルールのログには、以下のような内容が記載されます。 日時 5タプル（送信元 IP アドレス、送信元ポート番号、送信先 IP アドレス、送信先ポート番号、プロトコル番号） 許可されたか拒否されたか 該当するファイアウォールルールの詳細 また、 メタデータ の記録も有効化すると、VPC ネットワークや VM の詳細など追加情報が記録されます。 参考 : ファイアウォール ログ形式 VPC ネットワークの監査ログ ネットワーク関連設定が作成、変更、削除された履歴は、監査ログとして自動的に記録されるようになっています。記録を無効化することはできません。 これは Cloud Audit Logs の機能で実現されており、「 誰が、いつ、どこで、何をしたか 」が記録されます。Cloud Audit Logs については、以下の記事をご参照ください。 blog.g-gen.co.jp 設定の作成、変更、削除など、更新系 API リクエストに関するログは、 管理アクティビティ監査ログ と呼ばれます。前述の Cloud Audit Logs の記事にあるように、デフォルトではログは400日間保存されます。デフォルトで有効化されている管理アクティビティ監査ログについては、料金は発生しません。 一方で、設定の読み取りや一覧表示など、読取系 API リクエストに関する履歴は、 データアクセス監査ログ と呼ばれ、ログサイズが膨大になりがちなことからデフォルトでは無効化されています。前述の記事にある通りデータアクセス監査ログは有償のため、有効化の際は料金を意識する必要があります。 参考 : Virtual Private Cloud（VPC）の監査ロギング 料金 概要 VPC の利用料金は、以下の要素で構成されます。 下り（Egress）トラフィックのデータ量 確保した External IP（外部 IP）アドレスの利用時間 なお、VPC を作成するのみであれば無償です。 参考 : ネットワーキングのすべての料金体系 トラフィック量への課金 1. は、VPC ネットワーク内を通るトラフィックの量に応じた課金です。特徴的なのは、パケットの通信方向によって課金の有無が異なります。VPC ネットワークを上側 / Internal 側とみなし、インターネットやオンプレミス側を下側 / External 側としたときに、上り（Ingress）パケットは課金 されません 。反対に、下り（Egress）パケットは 課金されます 。 例えば VPC ネットワーク内の VM に Web サーバーを配置した時、ユーザーからの HTTP リクエストや、データのアップロードには課金されません。反対にユーザーがデータをダウンロードした際には、データ量に応じて課金されます。これは他の多くのパブリッククラウドのネットワーク課金体系と類似しています。 例として、2025年3月現在、東京リージョンから日本国内へのインターネットへの通信は、GiB あたり$0.12ドルです（プレミアムティアの場合）。月に100GiBの外向き通信が発生するとして、概ね￥1,800円程度の課金が発生することになります（1ドル150円換算）。なおこの料金は通信先の地域や、月間の総データ量によっても変化します。 また、インターネットに対する通信だけではなく、VPC 内の VM 同士の通信であっても、 異なるゾーンや異なるリージョン同士 の通信には課金が 発生します 。こちらも、同一リージョン内の異ゾーンとの通信なのか、リージョン間であればどのリージョンへの通信なのか、によって料金が変動します。 参考 : Google Cloud 内の VM 間データ転送の料金 IP アドレスへの課金 2. は、VM（Compute Engine の仮想マシン）に付与するための IP アドレスに対する課金です。Internal IP アドレス（内部 IP アドレス）には課金 されません が、インターネットとの通信に必要な External IP アドレス（外部 IP アドレス）には割り当て時間に応じた課金が発生します。External IP アドレスには、VM を停止すると解放されてしまう一時的な エフェメラル IP アドレス と、固定的に確保できる 静的 IP アドレス がありますが、どちらも同様に課金されます。 その他機能への課金 Private Service Connect、Packet Mirroring など、他のさまざまな VPC 機能に関する課金も、必要に応じて発生します。 詳細は公式の料金ページをご参照ください。 参考 : ネットワーキングのすべての料金体系 応用編へのリンク 当記事は VPC の基本機能に絞った基本編でした。応用編の記事では以下の機能を扱っていますので、ご参照ください。 VPC 間・サブネット間の通信 VPC ネットワークピアリング Cloud VPN による推移的な通信（カスタムルート広報） 共有 VPC サーバーレス VPC アクセス 限定公開の Google アクセス / Private Service Connect Packet Mirroring blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Chromebook（Chrome OS）から Cloud IAP のトンネリング機能を使い、 Compute Engine の Windows Server へリモートデスクトップ（RDP）する方法について紹介します。 前提知識 前提作業 1. Linux 開発環境の有効化 2. gcloud コマンドのインストール・初期化 トンネル確立とRDP 1. Linux コンテナの IP アドレスを確認 2. 変数設定と IAP トンネル確立 3. リモートデスクトップ接続 トラブルシューティング 前提知識 Cloud IAP （Cloud Identity-Aware Proxy）は、Google Cloud（旧称 GCP）が提供するフルマネージドのリバースプロキシです。IAP を使うと、Compute Engine VM に踏み台サーバー不要で SSH や RDP を使ってログインすることができます。 Cloud IAP による VM への接続方法自体の解説については、以下の記事で解説していますのでご参照ください。 blog.g-gen.co.jp 前提作業 1. Linux 開発環境の有効化 本手順では Chromebook のデベロッパー向け機能「 Linux 開発環境」を使います。 この機能を用いると Chromebook 内に Linux (Debian) のコンテナが起動し、ターミナルで操作することができます。 まだ Linux 環境を有効化していない場合は 設定 > 詳細設定 > デベロッパー > Linux 開発環境 から同機能を有効化します。 設定画面 (このスクリーンショットでは既に有効化済み) 2. gcloud コマンドのインストール・初期化 ※この手順は通常の gcloud コマンドと同じです。また、実施が必要なのは始めの1回だけです。 ドキュメント「 Cloud SDK のインストール 」に従い Linux 環境に gcloud コマンドをインストールします。 上記リンク先の Debian/Ubuntu の手順に従ってください。 インストールできたら gcloud init コマンドで初期化します。 対象のインスタンスがあるプロジェクトを指定しましょう。 トンネル確立とRDP 1. Linux コンテナの IP アドレスを確認 以下のコマンドで自分の Chromebook 上の Linux コンテナの内部 IP アドレスを確認します。 ip -4 addr 出力は以下の例のようになります。 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0 inet 100.115.92.206/28 brd 100.115.92.207 scope global eth0 valid_lft forever preferred_lft forever 下から2行目、 eth0 の inet 100.115.92.206/28 と表記されている部分の 100.115.92.206 が IP アドレスになります。 2. 変数設定と IAP トンネル確立 以下のように Linux 変数を設定します。後のコマンドで使うためです。 <カッコ> の中身はご自身の環境のものと置き換えてください。 ZONE=<対象インスタンスのゾーン> INSTANCE_NAME=<対象インスタンス名> IP_ADDR=<先ほど ip コマンドで調べたコンテナの IP アドレス> その後以下のコマンドを実行します。 gcloud compute start-iap-tunnel ${INSTANCE_NAME} 3389 --zone=${ZONE} --local-host-port=${IP_ADDR}:13389 なお 13389 は任意のポート番号で問題ありません。 Linux コンテナ上で使われていないものを選択してください。 出力が以下のように出たら、トンネル確立が完了です。 Testing if tunnel connection works. Listening on port [13389]. なお、以下のような warning が出ることがありますが、通常利用で問題はありません。 WARNING: To increase the performance of the tunnel, consider installing NumPy. To install NumPy, see: https://numpy.org/install/. After installing NumPy, run the following command to allow gcloud to access external packages: export CLOUDSDK_PYTHON_SITEPACKAGES=1 3. リモートデスクトップ接続 RD Client アプリ等、任意のリモートデスクトップクライアントで以下のアドレスに接続します。 <先ほど ip コマンドで調べたコンテナの IP アドレス>:13389 これで IAP と結んだトンネル経由で Windows Server へリモートデスクトップできます。 トラブルシューティング gcloud init や gcloud compute start-iap-tunnnel コマンドを実行する際、プロンプトが数分以上返ってこないような状態に陥ることがあります。 また以下のようなエラーメッセージが現れることもあります。 ERROR: (gcloud.compute.start-iap-tunnel) While checking if a connection can be made: Unexpected error while connecting. Check logs for more details. これはコンテナから API エンドポイントに接続する際に ipv6 で接続を試行しているために起こっている可能性があります。 対処として Debian の ipv6 を無効にすると改善する場合があります。 /etc/sysctl.conf を vim 等で編集し、以下の行を追加します。 net.ipv6.conf.eth0.disable_ipv6 = 1 その後 sysctl コマンドを実行します。 sudo sysctl -p 実施後 ip addr コマンドを打ち、 eth0 から ipv6 アドレスの表記が無くなっていれば対処完了です。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。かつて公開されていた Google Cloud（GCP）認定試験である Professional Google Workspace Administrator 試験（旧称 Professional Collaboration Engineer）の受験に向けて、役立つ内容をご紹介します。 ※ 当試験は2025年1月に 廃止 されました。しかしながら当記事は Google Workspace の製品知識の取得に役立ててもらう意味を込めて、公開のままとさせていただきます。 現在は後継資格である Associate Google Workspace Administrator 試験が存在しています。以下の記事も参照してください。 blog.g-gen.co.jp はじめに Professional Google Workspace Administrator とは 難易度 学習方法 注意点・出題傾向 ディレクトリ設計・管理 組織部門設計 カスタムディレクトリ 設定グループ データリージョン ドメイン名（セカンダリドメイン） アカウント保護 コンテキストアウェアアクセス コンプライアンス（Google Vault） Google Vault の基本 注意点 Gmail メールのセキュリティ 迷惑メール カレンダー 会議室とリソース Google Meet 通話品質 ドライブ 共有ドライブ 共有ドライブにおける権限 グループ 共同トレイ ディレクトリ管理 アカウントの一時停止と削除 データのエクスポート プログラマブルなディレクトリ管理 Google Cloud Directory Sync (GDCS) デバイス管理 Workspace で可能な管理 iOS はじめに Professional Google Workspace Administrator とは Professional Google Workspace Administrator 試験は、 Google の提供するグループウェアである Google Workspace の専門知識を問う試験です。 企業 IT の管理者や導入担当者が Google Workspace に関する専門知識を得るために有用な試験となっています。 なお、当試験はかつて Professional Collaboration Engineer と呼称されていましたが2022年4月29日に改称され Professional Google Workspace Administrator となりました。既に試験に合格していた人の保有資格名も自動的に改称されます。 当試験では Google Workspace の知識のみならず、企業 IT に関する幅広い知識が問われるため、情報システム部門のエンジニアにとっては知見を持っていることを示す良い客観材料となります。 当試験は英語と日本語で受験することができます。問題数は 50 問で、試験時間は 120 分です。 参考 : Professional Google Workspace 管理者 難易度 当試験の難易度は 比較的高い と言えます。 前提知識として、 IPA の基本情報処理技術者程度の IT 基礎知識に加え、 Active Directory などのディレクトリサービスに関する基礎知識や、E メール基盤の基礎知識、シングルサインオン、SAML、OAuth、OpenID Connect など、認証・認可や ID 連携に関する基礎知識があると良いでしょう。 これらの一般的な知識がある方が、公式 試験ガイド や当記事を参考に Google サービスの知識をつけていけば、合格できるでしょう。Google Workspace 管理コンソールの細かい利用経験が無いと回答が難しい問題もあるため、高難易度としました。 問題数 50 問に対して試験時間は 120 分のため 1 問あたり 2.4 分という数字は厳しいようにも見えるかもしれませんが、落ち着いて解けば時間には余裕がある試験です。 学習方法 おすすめの学習方法は、以下です。 一般的な IT 知識として以下のキーワードを理解する シングルサインオン (SSO) Active Directory SAML OAuth, OpenID Connect (OIDC) E メールに関する一般的な知識 (SPF/DKIM などの送信ドメイン認証に関する知識含む) 実際に Google Workspace の各サービスと管理画面に触る 管理画面をある程度自由に触れるのが理想 自由に変更できない環境の場合は、閲覧権限だけでも手に入れ、各種設定画面を確認する 試験ガイド を読んで試験範囲を確認する 試験範囲の中で理解できない内容や知らない単語を潰す 模擬試験 を受験し、分からなかった範囲をカバー勉強する 最後に、当記事を読んで知らない範囲を潰していく 注意点・出題傾向 当試験の注意点として以下のようなものがあります。 日本語版試験は、英語版試験を翻訳したものですので、若干の違和感を感じる文章もあります。特に Google Workspace ドキュメントやコンソールの日本語訳と、試験の日本語訳が違う場合もあります。原文を想像して読む必要が出てきます 管理コンソールにおける細かい操作（設定箇所）を問われる場合があります 出題傾向は、基本的には試験ガイドに沿うものになりますが、当記事ではより詳細に記載しますので、学習の参考にしてください。 当記事ではこれ以降、試験の出題傾向をジャンルごとに提示します。 ディレクトリ設計・管理 組織部門設計 組織部門 (Organizational Unit = OU) の設計に関する問題が出てきます。ユースケースを想像しながら学習すると良いでしょう。 組織部門を分けることで、 Gmail やカレンダーなどの設定を部門ごとに分けることができます。 参考 : 組織構造の仕組み カスタムディレクトリ 連絡先等の共有範囲を細く設定可能な カスタムディレクトリ 機能を把握しておきましょう。 デフォルトでは、組織内のユーザーから他の全ユーザーのプロフィール情報を確認できます。しかしカスタム ディレクトリを設定すると、連絡先、検索に表示するユーザーを限定することができます。 社外のメンバーを組織のディレクトリに追加し、社内の一部メンバーとだけコラボレーションさせたいときなどに活用できます。 参考 : チームやグループのディレクトリをカスタマイズする 設定グループ 設定グループ の概念が問題で繰り返し問われます。設定グループとは、管理画面等で作成した Google グループを、各種設定の適用のために使う場合を指します。 設定グループに適用した設定は、組織部門への設定よりも優先されます。また、ユーザーは複数のグループに所属することができます（組織部門には1つしか所属できません）。この仕様を押さえておきましょう。 参考 : 設定グループを使用してサービスの設定をカスタマイズする データリージョン データリージョン 設定により、データの配置先の地域を指定することができます。 特にヨーロッパでは、法的規制（GDPR）により EU 地域外に個人情報が出ることを規制していることが有名です。データリージョン設定ではデータの配置先として米国あるいはヨーロッパを指定できます。設定単位は「ドメイン全体」「組織部門」「設定グループ」のいずれかの粒度です。この設定粒度も含めて押さえておいてください。 参考 : データ リージョン: データの地理的な保管場所を選択する ドメイン名（セカンダリドメイン） Google Workspace の組織（テナント）はドメイン名（例 : example.com）を必ず1つ持ちます。ただし、2つ目以降のドメイン名を持たせることもできます。このとき、1つ目を プライマリドメイン と呼び、2つ目以降を セカンダリドメイン と呼びます。 ユーザには2つのドメインのメールアドレスを持たせることもできますし、片方だけ持たせることも可能です。 参考 : ユーザー エイリアス ドメインまたはセカンダリ ドメインを追加する アカウント保護 コンテキストアウェアアクセス コンテキストアウェアアクセス というセキュリティ機能が重要です。 コンテキストアウェアはその名の通り背景情報（コンテキスト）を考慮して（アウェア）認証・認可に組み入れる手法です。この機能を利用すると、ユーザーの アカウント、場所、デバイスのセキュリティ状態（会社端末かどうか）、IP アドレスなどの属性に基づいてアクセスの許可を行うことができます。 Enterprise Standard など特定のエディションでないと使えないことにも注意してください。 またログインできる PC 端末を会社端末に限る場合、 Endpoint Verification というツール（Chrome ブラウザの拡張機能）をインストールする必要がある、という点も押さえておいてください。 参考 : コンテキストアウェア アクセスの概要 参考 : コンテキストアウェア アクセスでビジネスを保護する コンプライアンス（Google Vault） Google Vault の基本 コンプライアンス準拠のための重要なツールとして Google Vault があります。 Gmail のメール、ドライブのファイル、 Google Chat のメッセージなどを長期保管し、インシデント発生時の事後調査や訴訟に活かすことができます。 Google Vault には 案件 という管理単位があり、記録保持 (リティゲーション ホールド) 、検索、書き出しを管理できます。何か起きた際には、Vault で案件を作成し、法務部門に権限を付与する、というアクションが定番となります。 参考 : Google Vault 参考 : 案件を作成、管理する 注意点 重要ポイントとして、従業員が退職した際に Google アカウントを削除してしまうと そのユーザーの Vault データもすべて削除 されます。 アカウントを削除するのではなく アーカイブユーザーライセンス の利用を検討しましょう。 参考 : 離職した従業員とそのデータを管理する Google Vault に関して基本機能を理解したら、以下の FAQ を読んでおきましょう。 参考 : Google Vault に関するよくある質問 Gmail メールのセキュリティ Google Workspace の管理者にとって、メール（Gmail）のスパム対策やマルウェア対策は重要です。 検疫 という機能を押さえてください。Google による検査に抵触した不審なメールは検疫のため隔離され、管理者が承認しなければ配信されません。 また、検疫により隔離されたメールを承認/不承認するというタスクは、特権管理者がすべて実施しなくとも、別の人に委任することができます。このときは最小権限の原則に従い、 カスタムロール を作ることが望ましいです。 参考 : メール検疫を設定、管理する また、メールに添付されている不審なファイルがマルウェアでないかどうかは、 セキュリティサンドボックス という仮想環境で検査することができます。 参考 : 有害な添付ファイルを検出するルールを設定する メールのTLS 接続を必須化する管理者オプションもあります。有効化したときに、非 TLS で送受信されたメールがどうなるかについては、ドキュメントを確認してください。 参考 : メールのセキュアな接続を必須にする 迷惑メール Gmail は優れた迷惑メールフィルタを持っていますが、誤検知もあります。迷惑メールと分類すべきでない送信元を明示的に許可するリストには 許可リスト と 承認済み送信者 があり、この2つは意味が異なります。この違いを理解しておいてください。 参考 : 許可リスト、拒否リスト、および承認済み送信者 カレンダー 会議室とリソース Google カレンダーには リソース管理機能 があります。 会議室をリソースとして登録しておき、適切に設定することで利用者が快適に会議室の予約を行うことができます。以下のようなドキュメントを押さえておいてください。 参考 : Google カレンダーの会議室の自動提案機能を設定する 参考 : 不要なカレンダーの会議室の予約を取り消す Google Meet 通話品質 オンライン会議ツール Google Meet では、管理者は動画・音声品質に関するトラブルへの対処を求められるかもしれません。 以下のドキュメントを押さえておいてください。 参考 : 会議の品質と統計情報を確認する - Meet 品質管理ツール ドライブ 共有ドライブ Google ドライブは Google Workspace の強力なコラボレーション機能の中核です。特に 共有ドライブ機能 を押さえておいてください。 参考 : 共有ドライブとは 共有ドライブにおける権限 ユーザーに与えられる権限は、管理者、コンテンツ管理者、投稿者、コメント投稿者、閲覧者などがあります。投稿者の権限は特殊で、ファイルの追加や編集はできるが、削除はできないというものです。 参考 : 共有ドライブのファイルへのアクセスの仕組み グループ 共同トレイ Google グループは、Google アカウントを一括りのグループとしてまとめる機能です。またメーリングリストとしても機能します。 グループに特徴的なのが 共同トレイ 機能です。例えばカスタマーサクセスチームが、顧客からのリクエストをチームとして対応したい場合にこの機能が役に立ちます。 参考 : グループを共同トレイとして使用する 以下の当社記事もご参照ください。 blog.g-gen.co.jp ディレクトリ管理 アカウントの一時停止と削除 Google アカウントは、一度削除してしまうと原則的にはデータがすべて消えてしまいます。ただし削除後20日間以内であれば復元できます。 参考 : 最近削除したユーザーを復元する また、長期休暇などで従業員が離れるが復帰後は従前どおり勤務させたい場合などは、アカウントの削除ではなく一時停止を検討しましょう。 参考 : ユーザーを一時的に停止する データのエクスポート もし組織のアカウントが持っているデータを外部に書き出したい場合、 データエクスポートツール を使用すると、すべてのユーザーのデータを書き出すことができます。 ただし、組織のユーザー数が 1,000を超える場合 はツール利用前に Google Workspace サポートまで連絡が必要です。 参考 : 組織のすべてのデータを書き出す プログラマブルなディレクトリ管理 Directory API を使うことで、プログラマブルにユーザーの管理やグループの管理を行うことができます。 例えば人事情報管理システムから、API 経由でデータを取得して自動的に Google Workspace に同期するプログラムを構成可能です。 参考 : Directory API の概要 Google Cloud Directory Sync (GDCS) Google Cloud Directory Sync (GDCS) は、Active Directory や他の LDAP ディレクトリから Google Workspace へディレクトリ情報を同期するためのツールです。 サーバにインストールして利用するツールであり、AD と Google Workspace のアカウント同期などに用いられます。なお、複数のディレクトリから1つの Google Workspace への同期はできません。 参考 : Google Cloud Directory Sync 参考 : 2. LDAP ディレクトリの準備 デバイス管理 Workspace で可能な管理 Google Workspace は iOS や Android などのモバイル端末、Windows や Mac などの PC 端末を管理することができます。 「基本のエンドポイント管理」「高度なエンドポイント管理」「エンタープライズ エンドポイント管理」の3ティアに分かれていて、エディションごとに使える機能が異なります。それぞれオン・オフが可能です。 参考 : Google エンドポイント管理機能の比較 iOS エンタープライズ エンドポイント管理では iOS に対して、例として「Workspace の仕事用のデータを、個人の Gmail アカウントやサードパーティアプリにコピーすることを禁止する」といった制御が可能です。 これは「デバイス > モバイルとエンドポイント > iOS 設定 > データ共有」から行います。 参考 : iOS デバイスの管理について 参考 : iOS デバイスに設定を適用する 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。当記事は「BigQuery Reservation (Flat-rate pricing)」について説明する記事です。 注意 : BigQuery の料金体系について BigQuery Reservations とは 用語 コミットメント (Commitment) 予約 (Reservation) 割り当て (Assignment) 料金 BigQuery Reservation の料金 購入是非の判断 安くなるのか？ 制限 応用 管理プロジェクト スロットスケジューリングとアイドルスロット モニタリング 注意 : BigQuery の料金体系について 当記事で解説されている「BigQuery Reservation (Flat-rate pricing)」は 2023/07/05 で販売が終了 し、以後は BigQuery Editions が Flat-rate pricing に代わる仕組みとなります。 以降の当記事の記載は、古い制度のものですのでご注意ください (アーカイブの意味合いで残しています)。 現在の BigQuery の料金体系は、以下の記事を参考にしてください。 blog.g-gen.co.jp BigQuery Reservations とは BigQuery Reservations とは事前に BigQuery のクエリ処理容量を購入することで BigQuery のクエリ料金を定額 (flat-rate) 化できる機能です。 オンデマンド課金では BigQuery が処理したバイト数に応じて従量で課金が決まるのに対して flat-rate 課金では 事前にクエリ処理容量を購入 することになります。 なお BigQuery Reservations という言葉と Flat-rate pricing という言葉があります。 BigQuery Reservations は機能名であり、この機能を使うことで Flat-rate pricing に料金体系を切り替えられる、と理解すればよいでしょう。 Flat-rate pricing (定額課金) の対義語は On-demand pricing (従量課金) です。 なお BigQuery Reservations で予約できるのは クエリ処理の課金に対してのみ です。 ストレージの課金は別途、従量課金で発生します のでご注意ください。 用語 コミットメント、予約、割り当て コミットメント (Commitment) コミットメント (Commitment) とは BigQuery の処理容量の購入単位です。 BigQuery では スロット という概念があります。スロットは単純に言うと BigQuery で使用される仮想 CPU であり、 BigQuery のクエリを処理する頭脳たちです。このスロットを事前購入することを「コミットメントを作成 (購入) する」のように表します。 コミットメントプランは以下の 3 つが存在します。 年間 月次 Flex 年間では 365 日間、月間では 30 日間、 Flex では 60 秒間が購入の 最小単位 となります。 この最小単位の期間が過ぎれば、コミットメントをキャンセルしたりプラン変更することができます。 コミット期間が長いほど、スロットあたりの料金が安くなります。 なお最小期間が過ぎてもキャンセルになるわけではなく、スロットは保持されて課金されます ( 参照 )。 Flex は 60 秒単位で購入可能なため、ワークロード管理のテスト用にスロット購入したい場合や、税務申告など季節性・短期の処理増加への対応などに適しています。また応用的な使い方として「重いバッチ処理の直前に Flex スロットを購入して割り当てる。バッチ処理が終わったらスロットをキャンセルする (スロットの購入・キャンセルはワークフローツールで自動的に行う) 。」といった使い方も可能です。 予約 (Reservation) 予約 (Reservation) とは購入したコミットメントをプロジェクトに割り当てるための管理単位です。 例えばボリュームの異なるコミットメントを 2 つ購入してそれぞれ prod と test という予約に割り当て、 prod は本番環境用プロジェクトに、 test はテスト環境用プロジェクトに割り当てる、といったことが可能です。 なおコミットメントを購入すると最初に default という名前の予約に割り当てられます。 割り当て (Assignment) 割り当て (Assignment) とは予約 (Reservation) を「プロジェクト」「フォルダ」「組織」のいずれかに割り当てることを意味します。 一つの予約を複数の「プロジェクト」「フォルダ」「組織」に割り当てることも可能です。 割り当てには 継承 の概念があり、例えばあるプロジェクトに予約の割り当てが存在しない場合、上位のフォルダか組織の割り当てが適用されます。 明示的に割り当てを None に指定することもできます。例えば組織全体に予約を割り当てているが、一部プロジェクトだけ None に設定すれば、そのプロジェクトだけは購入したスロットを使わずオンデマンド課金を使わせる、といったことが可能です。 コミットメント、予約、割り当て (同じ図を再掲) 料金 BigQuery Reservation の料金 年間、月間、 Flex の順で、コミット期間が長いほどスロットあたりの料金が安くなります。 2022 年 4 月現在の金額では 100 スロットあたりの金額は以下です。 Plan Price 単位 年間 $2,040 100 スロット / 月額 月間 $2,400 100 スロット / 月額 Flex $3,504 100 スロット / 月額 最新の料金は公式ページをご参照ください。 cloud.google.com 購入是非の判断 BigQuery Reservations (Flat-rate pricing) はどのようなときに使うべきなのでしょうか。 以下のいずれかに当てはまるときだと言えます。 BigQuery の料金を定額・予測可能にしたいとき 多重実行されるジョブ (クエリ) が非常に多く、オンデマンドプランのスロット上限である 2,000 スロットを定常的に超えるとき 1つ目の「料金を定額・予測可能にしたいとき」の意味は読んで字のごとくです。BigQuery の特徴は従量課金ですが、これが会社の支払いの仕組みや財務上の理由で望ましくない場合は Flat-rate pricing が選択肢になります。 また、社内の BigQuery 利用者が多く、クエリのボリュームが予測困難である場合に安全柵としてスロット利用料を固定化する、という使い方も考えられるかもしれません。 2 つ目の「オンデマンドプランのスロット上限である 2,000 スロットを定常的に超えるとき」は性能上の理由です。 スロットの スケジューリング は BigQuery によって自動的に行われています。必ずしも多くのスロットがあると処理が早くなる、というわけではなく、複数クエリが効率的に実行されるように最適化されます。またスロットが一時的足りない場合は、実行できないクエリはエラーになるわけではなくキューで待たされて、最終的には実行されます。なおオンデマンドモードでの最大スロットはプロジェクトごとに 2,000 ですがベストエフォートで一時的に バースト します。 オンデマンドモードの上限である 2,000 スロットは相応に大きいものです。また、前述のように「 Flat-rate を購入すれば速くなる」わけではありませんし後述のように「 Flat-rate を購入すれば必ず安くなる」わけでもありません。 現在のスロット利用状況を確認 した上で 本当に Flat-rate の導入が必要かどうかを適切に判断 するべきです。 現在のクエリワークロードにおいてどのくらいのスロットが消費されているのかを確認するには、以下のような方法があります。 スロット見積もりツール を利用する Cloud Monitoring の slots/allocated_for_project メトリクスで確認 INFORMATION_SCHEMA ビューで確認 ( 参考 ) また、以下のツール "Slot Recommender" で購入すべきスロット数のリコメンデーションを受けることもできます。 スロットの推奨事項と分析情報の表示 安くなるのか？ Flat-rate を購入すれば必ず安くなる、というわけではありません。この点が、例えば Compute Engine の 確約利用割引 (Committed Use Discounts) などのリソース予約購入制度とは異なる点です。 BigQuery の通常モードであるオンデマンド課金では「クエリでスキャンしたデータのサイズ」と「ストレージの料金」の 2 軸で課金されます。このうち BigQuery Reservation (Flat-rate) と関係があるのは前者です (2022 年 4 月現在の東京リージョンでは 1 TB あたり $6) 。 その一方で Flat-rate 料金は「スロットの予約を購入する」という概念であり、オンデマンド料金の「スキャンしたデータ量」とは計測の対象が異なります。そのため、どちらのほうがコストパフォーマンスがよくなるかは クエリの利用状況によって異なる のです。傾向としては、 定常的にクエリが発行されておりスロットの使用状況が一定であるほど Flat-rate のコストメリットが出てくる と言えます。 また Flat-rate とオンデマンド課金は組み合わせて使うこともできます。最適な利用方法を検討することが重要です。 制限 購入したスロットや予約は 他の「組織」とは共有できません 。 組織ごとにスロット購入や予約の管理を検討する必要があります。 またコミットメント (スロット購入) は リージョンリソース です。 例えば東京リージョンで購入したスロットを別のリージョンで使ったり、あるいは移動することはできません。 応用 管理プロジェクト BigQuery のコミットメントや予約 (Reservation) といったリソースは、一つの 管理プロジェクト で集約管理することが 推奨 されています。 この管理プロジェクトでコミットメント購入や予約の作成を行い、 BigQuery ジョブが実行される各プロジェクトに予約を割り当てていくことが望ましいとされます。 これにより請求の管理やスロット割り当ての管理が中央集約され、シンプルになります。 ただし 1 つの組織の中で権限を複数部門に移譲しており、 BigQuery Reservations 機能の利用も各部門に任せ、請求負担も明確にしたい場合はこの限りではありません。自分の組織の運用形態に応じて、適切な管理方法を選ぶのが良いでしょう。 スロットスケジューリングとアイドルスロット ある一つの予約 (Reservation) が複数プロジェクトに割り当てられているとします。 すると、その予約のスロットはまずプロジェクト間で均等に分配されます。 次にプロジェクト内で実行されているジョブ (クエリ等) に分配されます。 BigQuery 内部のスケジューラが分配をうまくコントロールし、不均衡や無駄が置きないように調整してくれます。 しかし気になるのは、このようなケースではないでしょうか。 例: 10,000 スロットを 購入して 2 つの予約 ( batch , analyst ) にそれぞれ 7,000 、 3,000 で割り当てた その予約 batch , analyst をそれぞれプロジェクト project-batch と project-bi に割り当てた ある時間では project-batch はクエリがかなり回っていてスロットが足りない一方、タイミング的に project-bi はクエリが回っておらずスロットが余っている このような状態ではせっかく購入したスロットが有効活用されないのでは、と考えるかもしれません。 しかし実は、 BigQuery はこのような状況も賢くハンドリングしてくれます。 予約に割り当てられているが使用されていない「遊んでいる」スロットや、そもそも予約に割り当てられていないスロットは アイドルスロット という扱いになります。 BigQuery では予約経由でクエリが実行されると 自動的にこれらのアイドルスロットを使用 します。 そのように別の予約に使われているスロットも、元の所属している予約でクエリが実行されて必要とされる状態になると、元の予約のクエリで優先的に使われるように戻ります。 このように自動的にうまくスロットが活用されるようになっています。 なお予約の ignore_idle_slots というパラメータを true に設定することで他の予約のアイドルスロットに手を出さないように設定することも可能です。 モニタリング BigQuery Reservations を購入した後も、割り当てが適切か、無駄ではないか、など定常的にモニタリングすることが望ましいです。 前述のように Cloud Monitoring のメトリクスを確認する方法や INFORMATION_SCHEMA ビューから情報を得られるほか 管理リソースグラフ が利用可能です。 管理リソースグラフでは過去 30 日間に遡ってスロットの利用率、ジョブのパフォーマンス推移などをグラフィカルに確認可能であり、データは INFORMATION_SCHEMA に基づいたものです。 Google Cloud コンソールの BigQuery > モニタリング から確認することができます。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。 Google Cloud（旧称 GCP）におけるアプリケーション開発者向けの認定資格である Professional Cloud Developer 試験の勉強方法や出題傾向など、合格に向け役立つ情報をご紹介します。 試験情報 Professional Cloud Developer 試験とは Professional Cloud Developer 試験の難易度 Professional Cloud Developer 試験の勉強方法 出題範囲と傾向 マイクロサービスアーキテクチャ Identity and Access Management（IAM） Google Kubernetes Engine（GKE） Workload Identity 認証情報の管理 サービスメッシュ デプロイ戦略 サービス間通信 クラスタ外からの通信 Network Policy / Authorization Policy Pod のライフサイクル Cloud Run Cloud Run の基礎 Cloud Run へのデプロイ Dockerfile なしでのデプロイ Cloud Run functions App Engine Cloud Storage Firestore Compute Engine 基本 モニタリングとロギング データベース選定 Cloud SQL Pub/Sub 開発環境 CI/CD Cloud Build Cloud Build のプライベートプール 脆弱性の管理 監視、オブザーバビリティ Cloud Endpoints Google Cloud の API 呼び出し ワークフロー管理（ジョブの自動化） Apigee Apigee とは Apigee Analytics トラフィック管理とレート制限 バックエンドサーバーへの負荷分散 試験情報 Professional Cloud Developer 試験とは Professional Cloud Developer 試験は、クラウドネイティブなアプリケーション開発を行うための知識を問う Google Cloud 認定資格です。 Google Cloud 上でアプリケーションの高可用性、スケーラビリティ、セキュリティを確保し、マネージドサービスの活用やサーバーレスの活用により運用性の高いアーキテクチャを設計する知見が求められます。CI/CD や開発ツールに関する知識や、認証・認可に関する知識も試験範囲に含まれます。 試験時間は120分、問題数は50〜60問です。1問1問はそこまで問題文が長いわけではなく、また当記事をお読みのほとんどの方の第一言語であろう日本語で受験できるため、試験時間が足りなくて苦しい印象は持たないはずです。 試験は日本語と英語で提供されており、申し込み時に選択します。 参考 : Professional Cloud Developer Professional Cloud Developer 試験の難易度 Professional Cloud Developer 試験の難易度は 中程度 であるといえます。 IPA の「応用情報技術者試験」相当の ITやシステム開発に関する基礎知識に加えて、Google Cloud の各種サービスに関する知見が求められます。試験では Google Cloud の知識のみならず、アプリケーション開発やコンテナに関する一般的な知識を求めるものもあります。そのため学習の際は Google Cloud に限ることなく「基本的な IT 知識」「基本的なアプリケーション開発に関する知識」も押さえるべきといえます。 公式ガイドでは「3年以上の業界経験」「1年以上の Google Cloud を使用したソリューションの設計と管理の経験」が求められるレベルであると記載されていますが、実際にはそこまでの経験がなくても、ポイントを押さえた学習をすれば、合格は難しくありません。 Professional Cloud Developer 試験の勉強方法 以下のような勉強方法が推奨です。しかしながら以下にこだわることなく、各自の現在の知識量や得意領域に応じた学習をすることが推奨されます。 モダンな開発手法に関する知識を別途、学習する Associate Cloud Engineer 試験 を学習し、取得することで Google Cloud の基本を理解 試験ガイド を確認して試験範囲を理解する 公式ドキュメントを中心に試験範囲を学習する 当記事を読み、試験範囲の詳細を把握し、知らない知識を補填する 模擬試験 を受け、出題される問題の形式と内容をよく理解する Associate Cloud Engineer 試験については、以下の記事を参考にしてください。 blog.g-gen.co.jp 前述の 1. は「モダンな開発手法」というあいまいなワードで表現されています。具体的には、以下のような用語の理解を深めると良いでしょう。これらは Google Cloud に限らず、開発に関する一般的な知識としても重要です。具体的にこれらの用語が試験で問われるわけではないかもしれせんが、これらの用語のエッセンスを理解することで回答を選択する際の判断基準になります。 CI/CD（継続的インテグレーション / 継続的デリバリ） DevOps / DevSecOps テスト駆動開発 オブザーバビリティ イベントドリブンアーキテクチャ サーバーレスアーキテクチャ 疎結合アーキテクチャ マイクロサービスアーキテクチャ ステートレスなアプリケーション、ステートフルなアプリケーション 出題範囲と傾向 当記事では、主に Google Cloud のサービスカットで、出題範囲や傾向をご紹介します。また、知っているべき知識をできるだけ公式ドキュメント等へのリンク付きでご紹介します。ぜひ学習に役立てていただき、合格を目指してください。 この記事で全ての技術要素の解説をするわけではありません。記載があったりリンクが貼付されている場合は、そのあたりが試験における重要ポイントだとご認識ください。 マイクロサービスアーキテクチャ マイクロサービスアーキテクチャ に関する知見が問われる問題が出題されます。 以下の公式ドキュメントは App Engine のドキュメントですが、マイクロサービスの RESTful API 設計における基本的な考え方を示しており、参考になります。 「 API コントラクト 」「 API バージョンを示す URL 」「 互換性を損なう変更と互換性を損なわない変更 」などについて、用語の意味を押さえておきましょう。 参考 : マイクロサービスのコントラクト、アドレス指定、API Identity and Access Management（IAM） ほぼすべての Google Cloud 認定試験で共通して言えることとして、 Cloud IAM に関する正しい理解が必須です。 以下の記事を読み、 IAM Policy が リソースに紐づく概念である ことを正しく理解してください。 blog.g-gen.co.jp また、そのうえで サービスアカウント を正しく理解してください。 例えば Compute Engine や Cloud Run functions で稼働するプログラムが、Google Cloud の他のサービスの API を呼び出す際には、認証情報（サービスアカウントキー）をテキストとして保存しておき呼び出すのではなく、サービスアカウントをインスタンスや関数にアタッチして使うのが最適です。 Google Kubernetes Engine（GKE） Workload Identity Google Kubernetes Engine （GKE）で稼働するアプリケーションが Google Cloud の API へアクセスする際の認証・認可には Workload Identity を使うことが 第一選択肢として推奨 されています。 参考 : Authenticate to Google Cloud APIs from GKE workloads Workload Identity を使うと Cloud IAM で作成した "Google Cloud の" サービスアカウントと、Kubernetes リソースとして作成した "Kubernetes の" サービス アカウントを 紐づけ することができます。 これにより Kubernetes 上での権限管理と Google Cloud 上での権限管理を疎結合にすることができ、セキュリティや運用性が向上します。 この原則を問う問題が複数出題されますので、確実に押さえておきましょう。 認証情報の管理 Workload Identity を使い Google Cloud サービスへの認証を管理する方法は前述の通りですが、オンプレミスに存在するデータベースへの認証などのために ID・パスワードが必要とされる場面もあります。 コンテナ内やストレージにこういった認証情報を永続化するよりも、Google Cloud サービスである Secret Manager に認証情報を保管すれば、セキュアな保管やローテーションの管理などが容易になります。 認証情報自体は Secret Manager に保存しますが、GKE から Secret Manager にアクセスするにはやはり前述の通り Workload Identity が使われます。 参考 : Using Secret Manager with other products サービスメッシュ Istio on Google Kubernetes Engine は、2024年6月現在では非推奨となり Cloud Service Mesh の利用が推奨されています。2024年6月現在の当試験では Istio に関して問われますが、詳細な仕様まで問われるわけではありませんし、基本的な考え方は Cloud Service Mesh と同じです。 サービスメッシュの考え方や、 mTLS によるサービス間通信の暗号化 について、概要だけでも理解しておきましょう。重要なのは、Istio や Cloud Service Mesh を導入することにより、サービス間通信を少ない労力で暗号化することができます。 デプロイ戦略 Blue/Green デプロイ 、 ローリングアップデート 、 カナリアリリース 、 A/B テスト といったデプロイ戦略を理解してください。 「それらがどのような方法なのか」「メリットとデメリット」「ロールバックの迅速さ」などに着目しましょう。これらのデプロイ戦略は Google Cloud や GKE に特有のものではなく、現代のデプロイ戦略の考え方として共通のものです。 以下の公式ドキュメントも参照してください。 参考 : アプリケーションのデプロイとテストの戦略 参考 : GKE でのデプロイとテストの戦略の実装 サービス間通信 Kubernetes リソースである Service には ClusterIP 、 NordPort 、 LoadBalancer などがあります。 これらのうちクラスタ "内" のサービス間通信を担うのは ClusterIP で、クラスタ "外" からの通信を受け付けるのが NodePort や LoadBalancer です。 また、GKE クラスタ内でマイクロサービス間の通信を実現するにはどのようなリソース構成とするべきか、理解しておきましょう。 これらについても当ページでは詳細に解説しません。参考として、以下の書籍で Kubernetes リソースの詳細な解説がされています。 参考 : ハンズオンで分かりやすく学べる Google Cloud実践活用術 データ分析・システム基盤編 クラスタ外からの通信 Ingress に関する知見も問われます。たとえば External HTTPS Load Balancer に複数のホスト名用の SSl/TLS 証明書を設定する方法について押さえてきましょう。 参考 : Using multiple SSL certificates in HTTPS load balancing with Ingress Network Policy / Authorization Policy Network Policy や Authorization Policy を概要レベルでも構いませんので、押さえておきましょう。 これらはクラスタ内の Pod 間、サービス間の通信を制御する仕組みです。 参考 : Control communication between Pods and Services using network policies 参考 : Authorization policy overview Pod のライフサイクル Pod を停止させる際、データベースとのセッションを正しく切断してから終了するなど、Pod 終了前のアクションを設定したい場合、 PreStop を利用します。 参考 : コンテナライフサイクルフック Cloud Run Cloud Run の基礎 Cloud Run の基本は、以下の記事を読んで理解しておきましょう。Cloud Run はフルマネージド・サーバーレスのコンテナ実行プラットフォームです。 blog.g-gen.co.jp Cloud Load Balancing の背後に置いて Web アプリ として動作させることも、 Pub/Sub の push/pull サブスクリプションの背後に置いて イベントドリブンなプログラム を動作させることも、 Cloud Scheduler によって定期的なジョブとして呼び出すこともできます。 Cloud Run へのデプロイ Cloud Run へのアプリケーションデプロイの基本的な流れを押さえてください。 ソースコードと Dockerfile が格納されているディレクトリで docker build を実行（コンテナイメージのビルド） Docker イメージをコンテナイメージレポジトリへ Push（レポジトリへの格納） イメージの URL を指定して gcloud run deploy （Cloud Run へのデプロイ） また、上記のほかに、以下のように Cloud Build を利用した方法もあります。 ソースコードと Dockerfile が格納されているディレクトリで gcloud builds submit を実行（コンテナイメージのビルドとレポジトリへの格納） イメージの URL を指定して gcloud run deploy （Cloud Run へのデプロイ） このような基本的な流れを理解して、問いに答えられるようにしておいてください。 参考 : Cloud Run へのデプロイ 参考 : コンテナ イメージをビルドします Dockerfile なしでのデプロイ Cloud Run へのアプリケーションのデプロイは、レポジトリに格納したコンテナイメージの URL を指定して行うことが基本ですが、ソースコードの存在するディレクトリからデプロイコマンドを実行することでも実現できます。この場合、自動的にコンテナイメージのビルド、イメージの Artifact Registry レポジトリへの格納、デプロイが行われ、Dockerfile の定義も必要ありません。 参考 : ソースコードからデプロイする Cloud Run functions Cloud Run functions はフルマネージドのサーバーレスサービスで、任意のコードを動かすことができるサービスです。Function as a Service（FaaS）と分類されることもあります。Cloud Run functions は Node.js、Python、Go、Java、.NET、Ruby、PHP などのプログラミング言語に対応しています。 その際に押さえておいたほうが良い知識として、セキュアコーディングは必須です。セキュアなコーディングについては、以下のような書籍が役に立ちます。 参考 : 体系的に学ぶ 安全なWebアプリケーションの作り方 例えば CORS （Cross-Origin Resource Sharing）という概念を押さえておきます。これは Google Cloud 特有ではなく、一般的な用語です。詳細は当記事では解説しないため、必ずご自身で調べ、理解してください。 例えばフロントエンドの Web サイトのドメイン名と、Cloud Run functions に設定するカスタムドメイン名が異なる場合は、 Access-Control-Allow-Origin: ${呼び出し元ドメイン名} をレスポンスヘッダに含ませる必要があります。 以下の記事も参照してください。 blog.g-gen.co.jp App Engine App Engine はマネージドな Web アプリケーションプラットフォームであり、高度にスケーラブルな構成を簡単に構築できます。開発者は、インフラの構築・運用の工数を省き、アプリケーション開発に集中することができます。 App Engine に限らず様々なマネージドプラットフォームやコンテナアーキテクチャに共通して言えることですが、アプリケーションはステートレスである必要があります。そのためセッション管理には Redis や Memcached といったインメモリデータベースを利用するというアーキテクチャが、問題文の前提として設定されることが多くなっています。 そして Google Cloud では Redis / Memcached のマネージドサービスである Memorystore があり、これもセットで出題されます。 細かいところですが例えば Memorystore を App Engine から利用する場合のアクセス方法を理解しておきます。 App Engine（Standard）から Memorystore へ接続するには、サーバレス VPC アクセスが必要 App Engine（Flexible）から Memorystore へ接続するには、App Engine が authorized network 内にいる必要がある App Engine の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp Cloud Storage Cloud Storage は堅牢で安価なオブジェクトストレージです。Cloud Storage については当社記事で詳細に解説していますので、以下を参照してください。 blog.g-gen.co.jp ライフサイクルマネジメント機能 、 署名付き URL など、便利な機能をしっかりと押さえておいてください。「署名付き URL で制限時間付きの専用 URL を発行し、認証済みの利用者だけが Cloud Storage 上のオブジェクトをダウンロード可能にする」などのユースケースが頻出です。 参考 : 署名付き URL また記事でも説明されている静的ウェブサイトホスティング機能により Cloud Load Balancing と組み合わせて、ウェブサイトのホスティングに使うことができます。 マルチリージョンの Cloud Storage + 外部 HTTP ロードバランサー + Cloud CDN 有効化 のようなアーキテクチャにすることで、安価かつフルマネージドな形で、世界中の利用者をターゲットとしたウェブサイトを簡単に構築することができます。このような構成を、頭の中で描けるようにしておいてください。 Firestore Firestore は、モバイルアプリや Web アプリのバックエンドデータベースとして利用できる、フルマネージドな NoSQL データベースです。 旧称 Datastore から発展した「Firestore（Datastore モード）」と、Web アプリ・モバイルアプリに最適な「Firestore（ネイティブモード）」が存在し、これらはほとんど別々の製品であると考えることができます。 参考 : Feature comparison 試験に向けては、特にネイティブモードの Firestore について重点的に理解したほうが良いでしょう。 Firestore ネイティブモードはドキュメント志向データベースであることから、テーブル、カラム、レコードといった概念はありません。その代わりに「 ドキュメント 」「 コレクション 」という概念が存在します。 参考 : Cloud Firestore データモデル また Firestore ネイティブモードはモバイルアプリを想定しており、モバイル機器のローカル側と Firestore の通信が切れても、ローカル側でデータを保持してアクセスできるようにしておき、 通信が回復した際に同期 するようにできます。また開発担当者の PC のローカル上で稼働するエミュレーターも用意されています。 Compute Engine 基本 仮想サーバーのサービスである Compute Engine も出題範囲です。Compute Engine のインフラ寄りの内容よりも、アプリケーションのデプロイに関わる点が重視されます。 たとえば「 VM メタデータ 」（インスタンスごとに Key/Value で情報を持たせられる機能）に、デプロイ先の環境ごとに異なる情報を格納しておき、デプロイの際の初期化処理時に利用する、といったユースケースが出題されます。 参考 : About VM metadata またメタデータには「プロジェクトレベルのメタデータ」と「インスタンスレベルのメタデータ」があります。プロジェクトレベルで設定したメタデータは全てのインスタンスから取得でき、インスタンスレベルのメタデータはそのインスタンスからのみ取得できます。 Compute Engine の詳細は、以下の記事を参照してください。 参考 : Compute Engineを徹底解説！（基本編） 参考 : Compute Engineを徹底解説！（応用編） モニタリングとロギング アプリケーションのログを Cloud Logging へリアルタイムに送付したい場合、 Ops Agent をインストールすることで任意のログを Cloud Logging へ送出できます。以下の記事を参考にしてください。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog 参考 : Google Cloud (GCP) Windows VM の Ops エージェント で Cloud Logging に任意のログファイルを収集する方法 - G-gen Tech Blog データベース選定 Cloud SQL、Bigtable、Cloud Spanner、Firestore といった Google Cloud のデータベースの違いを、しっかり把握しておきましょう。以下の記事の「その他のデータベース」の項を参照してください。 blog.g-gen.co.jp 整合性の強弱、トランザクションの有無、SQL の利用可否などを、データのアクセスパターンと照らして選定する必要があります。 Cloud SQL Cloud SQL とは、Google Cloud のマネージドなリレーショナルデータベースサービスです。 blog.g-gen.co.jp 試験に向けては、サービス概要に加え、Cloud Run や Comptue Engine から Cloud SQL インスタンスへ、プラベート IP アドレスで接続をする際の方法について、以下記事を参考にイメージを確認しておくと良いでしょう。サーバーレス VPC アクセスコネクタや、Cloud SQL Auth Proxy を使った接続方法を理解しておいてください。 blog.g-gen.co.jp Pub/Sub Pub/Sub はフルマネージドなメッセージキューイングサービスです。 システムコンポーネント同士を 疎結合にする ために重要なサービスであり、クラウドらしいアーキテクチャの要となります。 Pull サブスクリプション と Push サブスクリプションの 2種類がある 点、またストリーミングデータの受け口としても使われる点などから、Amazon Web Services (AWS) でいう Amazon SQS、Amazon SNS、Amazon Kinesis Streams を組み合わせたような位置付けのサービスです。 またローカルで動作する も存在しており、これが問題で問われることもあります。 参考 : Testing apps locally with the emulator 開発環境 Cloud Code というツールの存在を押さえておきましょう。 VSCode、IntelliJ などの IDE 向けのプラグインであり、Google Cloud における開発を便利にしてくれます。 参考 : Cloud Code and Gemini Code Assist IDE Plugins また Cloud Shell は Google Cloud を実際に利用・運用している人はほぼ使ったことがあるはずです。もし一度も使ったことがない場合、多少は触っておきましょう。Cloud Shell には 5 GB の永続ディスクが割り当てられますが、120日間アクセスがない場合、中身が削除されます。 参考 : Cloud Shell: アクティビティのない状態 CI/CD Cloud Build Google Cloud で CI/CD パイプラインを構築する際に要になるのは Cloud Build です。 Cloud Build はその名の通り、ソフトウェアのビルドのためのサービスですが、 Google Cloud 上の各プラットフォームへのデプロイにも用いることが可能です。ソースコードレポジトリへの Push を検知して Code Build が動き、ビルド・テスト・デプロイを実施させることができます。 フルマネージドの Git レポジトリサービスである Cloud Source Repositories と、Cloud Build を連携させて上記のような CI/CD パイプラインを実現することができます（ただし、2024年6月以降、Cloud Source Repositories の新規利用受け付けは終了しました）。 参考 : Cloud Build を使用したビルドの自動化 なお Cloud Build には ビルドステップ （または単にステップ）という概念があります。ステップはその名の通りビルドの各ステップを処理する単位です。ステップごとにマネージドなコンテナが起動して処理を行います。YAML または JSON で記述した構成ファイルに、一つ以上のステップを定義し、実行することでビルドやデプロイを実行するイメージです。 各ビルドステップは別々のコンテナで実行されますが、 /workspace ディレクトリ配下に配置したファイルは ステップ間で引き継がれ ます。 参考 : ビルドステップ Cloud Build のプライベートプール プライベートプール を使用すると、ビルドプロセスをVPCネットワーク内に限定し、データが外部に漏洩するリスクを軽減することができます。VPC Service Contorls を併せて利用することで、よりセキュアなビルド環境を実現できます。 参考 : プライベート プールの概要 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog 脆弱性の管理 CI/CD にセキュリティの概念を取り込み、開発・運用にセキュリティ担保の仕組みを継続的に取り込む体制は、DevSecOps とも呼ばれます。 コンテナイメージの格納レジストリである Artifact Registry では、 脆弱性スキャン を有効化することができます。 参考 : Artifact Analysis と脆弱性スキャン またスキャンで問題がなかったコンテナイメージにのみ 署名 （attestation）を付与し、 Binary Authorization により署名がないイメージのデプロイを禁止することで、セキュリティを向上することができます。Binary Authorization の設定時は ポリシー （コンテナイメージのデプロイを規定するルール）と 認証者 （Attestors）という2つのオブジェクトの作成が必須です。 参考 : Binary Authorization のコンセプト 参考 : Cloud Build パイプラインで Binary Authorization 証明書を作成する 署名と Binary Authorization を使ったコンテナイメージのセキュア化は、Professional Cloud Security Engineer 試験でも問われる、一種の定石です。以下の記事もご参照ください。 blog.g-gen.co.jp 監視、オブザーバビリティ Google Cloud における監視・運用といえば Cloud Monitoring です。 blog.g-gen.co.jp 上記の基本は押さえつつ、 Cloud Trace 、 Cloud Profiler を押さえておきます。 Cloud Trace は、アプリケーションの 分散トレース を実現する仕組みです。アプリケーションがユーザのリクエストを処理するのにかかる時間を計測したり、マイクロサービス間のレイテンシを継続できるので、 SLI/SLO の計測 にも利用できます。アプリケーションに必要なクライアントライブラリを追加し、必要なコードを追加することで利用可能になります。 Cloud Profiler はアプリケーションの CPU やメモリなど リソース使用状況 を継続収集するための仕組みです。アプリケーションにおいて、 ソースコードのどの部分が 最もリソースを消費しているのか、などを特定できるので、非効率なアプリケーションの オーバーヘッドの特定 に利用できます。 Cloud Endpoints Cloud Endpoints は公開 API を実装するためのサービスです。Cloud Endpoints を介して API を公開することで モニタリング、セキュア化、分析、クォータの設定 などが実現できます。 Cloud Endpoints では Nginx ベースの Extensible Service Proxy （ESP）と呼ばれるプロキシ機能により、さまざまな機能を実現します。ESP は「Cloud Load Balancing の後」「VM / GKE などバックエンドアプリケーションの前」に配置されます。 以下のドキュメントの構成図をよく覚えておいてください。この構成図の中で ESP がどこに配置されているか = Cloud Endpoints の配置場所を分かっているだけでも回答に役立ちます。 参考 : Cloud Endpoints のアーキテクチャの概要 Google Cloud の API 呼び出し Google Cloud の各種サービスの API を呼び出す際、Google Cloud 側の一時的な障害などにより、5xx 系のエラーが発生する可能性があります。 そのため、呼び出し側のアプリケーションでは エクスポネンシャルバックオフ （指数バックオフ）を実装することが推奨されています。これは、再試行の際に、徐々に実行間隔を広げながら、最大試行回数に達するまで再リクエストを繰り返す戦略のことです。 参考 : Exponential backoff Google Cloud APIs の詳細は、以下の記事も参照してください。 blog.g-gen.co.jp ワークフロー管理（ジョブの自動化） Google Cloud においてワークフロー管理（ジョブの自動化）を実装する場合、 Workflows や Cloud Composer を検討します。両者ともジョブのワークフロー管理のためのマネージドサービスですが、それぞれ異なる特徴とユースケースを持っています。 特徴 Workflows Cloud Composer 基盤技術 独自 Apache Airflow ジョブ定義 YAML または JSON Python スケジューリング Cloud Scheduler Airflow スケジューラ（内蔵） 複雑性 比較的シンプルなワークフローに適する 高度なワークフロー制御が可能 学習コスト 比較的低い 比較的高い 主な用途 API オーケストレーション、シンプルな自動化 複雑なデータパイプライン、バッチ処理 以下の記事も参考にしてください。 参考 : Cloud Workflowsを徹底解説 - G-gen Tech Blog 参考 : Cloud Composer (メジャーバージョン2)を徹底解説！ - G-gen Tech Blog 試験では上記のポイントを押さえ、問題文にある要件からどちらがマッチするかイメージすると良いです。 Apigee Apigee とは Apigee とは、Google Cloud が提供する API 管理プラットフォームです。API の設計、セキュリティ保護、公開、分析などを SaaS 形式で一元管理することができます。Apigee で API プロキシを作成することで、バックエンドサービスを抽象化し、セキュリティやトラフィック制御などのポリシーを適用することで、開発者はAPIのライフサイクル全体を効率的に管理することができます。 参考 : Apigee について 以下の機能の紹介をピックアップします。 Apigee Analytics Apigee Analytics は、API プロキシを介して流れるリクエスト、レスポンス、エラーなどの大量の情報を収集・分析し、可視化するサービスです。 API のパフォーマンスボトルネックやエラーの原因を特定し、改善に役立てることができます。類似の役割を持つサービスとして Cloud Monitoring がありますが、インフラストラクチャやアプリケーション全体のパフォーマンス監視ではなく、API プログラムの利用状況や API 固有の課題に特化した分析をしたい場合は、Apigee Analytics を利用する方が適しています。 参考 : Apigee API Analytics の概要 トラフィック管理とレート制限 ユーザーアクセスの多い外部アプリケーションなどで、バックエンド API への過剰なリクエストによるパフォーマンスを維持するため、Apigee でレート制限を設定することができます。 SpikeArrest ポリシーや Quota ポリシーについて概要レベルで押さえておきましょう。 参考 : レート制限 バックエンドサーバーへの負荷分散 API アクセスの可用性を高めるため、Target Servers を構成することにより、バックエンドサーバーの負荷分散を実現できます。名前、ホスト、プロトコル、ポートを事前設定して、API プロキシを構成します。 参考 : バックエンド サーバー間のロード バランシング 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it