こんにちは、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 の設定時は ポリシー （コンテナイメージのデプロイを規定するルール）と 認証者 （）という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 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。さっそくですが、この度はじめて弊社 Tech Blog に投稿させてもらうことになりました。はじめての投稿ということもあり、まずは「Google Cloud 基本のキ」シリーズの1つとして、Google Compute Engine (GCE) 等の IaaS サービスを利用する上では欠かせない Virtual Private Cloud (仮想ネットワーク、以下 VPC) の構築手順について触れていきたいと思います。 VPC の概要 VPC の基本 オートサブネットモード グローバルリソース VPC の作成 Google Cloud コンソールへのログイン VPC 名の設定 サブネットの設定 ファイアウォールルール (IPv4 / IPv6) その他設定事項 VPC の作成後 サブネット 静的 IP アドレス ファイアウォールポリシー、ファイアウォールルール ルート VPC ネットワークピアリング プライベートサービス接続 VPC の概要 VPC の基本 VPC の基本的な知識については過去の投稿もありますので目を通していただけると幸いです。 カジュアルに VPC の概要を知りたい方 blog.g-gen.co.jp もう少し細かく VPC を知りたい方 blog.g-gen.co.jp オートサブネットモード 話の順番が少し逆転してしまうかもしれませんが、解説の便宜上、まずはサブネットについて説明します。 オートサブネットモードによって VPC 内に作成されるサブネット一覧 見ていただくと、画面中央、各リージョンに対してそれぞれ /20 のプレフィックスで切られたサブネットの一覧が表示されているかと思います。これは何かと言いますと、「オートサブネットモード」を利用した場合に、これから作成する VPC の中に払い出されるサブネットの一覧になります。 オートサブネットモードとはサブネット作成を自動化する Google Cloud 独自の機能のことで、このモードを選択して VPC を作成すると、その時点で利用可能なリージョンに自動的にサブネットが作成されます。例えば、「テスト環境等でサクッと何かを検証してみたいときにネットワークの検討まではしたくない！」なんてときに便利な機能になるかと思います。 試しに「yutakei-test-vpc」というリソース名で VPC を払い出した際の画面が以下となりますが、上記画面で一覧表示されていたものと同じ IP アドレス、プレフィックスで各リージョンにサブネットが作成されているのがお分かりいただけるかと思います。 オートサブネットモードで実際に払い出されたサブネット なお、従来どおり管理者がサブネットと IP 範囲を定義する「カスタムサブネットモード」というモードも用意されており、本番環境等でお使い頂く場合、こちらのカスタムサブネットモードの利用がベストプラクティスとなります。モードの選択については、VPC を作成する際の画面から選択いただけます。 サブネット作成モードの選択 グローバルリソース さて、ここまでのお話の中で違和感を感じられた方も多くいらっしゃるかもしれません。特に AWS を利用された経験のある方はそうだと思うんですが、実は Google Cloud の VPC では、リージョンをまたがるようにして VPC を構成することができるんです。 一般的に、他のパブリッククラウドでは VPC はリージョナルリソースとして定義されていますので、払い出された VPC は特定のリージョンに紐づく形で管理されます。 しかし Google Cloud の場合、VPC はグローバルリソースとして定義されていますので、例えば東京リージョン (asia-northeast1) と大阪リージョン (asia-northeast2) を使って2つのリージョンにまたがるような形で1つの VPC を形成することができます。また、各リージョンには通常3つのゾーン (AWS で言う AZ) がありますので、サービスの特性に応じて VPC や サブネットを柔軟に設計・構築することが可能となります。 例えばこれと同じような構成を AWS で実現させる場合、それぞれのリージョンに VPC を払い出し、VPC 間の通信が可能になるよう、VPC 間をピアリングで接続し、ルート情報を双方の VPC で追加したりする必要が出てくるので、設定や管理面での手間を省くことができます。 VPCやサブネットを柔軟に構成できる VPC の作成 Google Cloud コンソールへのログイン 今回は「Google Cloud 基本のキ」シリーズということもありますので、あらためて Cloud コンソールにログインするところから説明したいと思います。 以下が Google Cloud を管理するための GUI コンソール (Cloud コンソール) になります。 Cloud コンソールにて組織リソースを選択 まずは Google アカウントで Cloud コンソールにログインし、その後 VPC を払い出していく流れになりますが、VPC をはじめ、各種 Google Cloud リソースを利用する上で最初にやらなければいけないこととして、画面の赤枠内にて、組織、フォルダ、プロジェクトといった組織リソース (リソース階層) を正しく選択する必要があります。 組織リソースとは、Google Cloud を利用する組織の階層構造を管理する、他のパブリッククラウドにはない独自の概念になりますが、VPC 等の各種リソースはそのリソース階層の最も下位に位置づけられるため、上位にあたる各種組織リソースは間違えないよう注意が必要です。 なお、組織リソースやリソース階層については今回の本題から外れてしまうため、詳細については別途こちらの記事を参照いただくと理解が深まるかと思います。 blog.g-gen.co.jp VPC 名の設定 前述の通り、画面上から「VPC ネットワークの作成」をクリックし、遷移先の画面で詳細を設定していきます。 まず始めに VPC 名、説明 (任意) を設定します。 VPC設定 サブネットの設定 次にサブネットを設定します。サブネットモードは「カスタム」か「自動」を選択しますが、前述の通り、自動 (オートサブネットモード) はテスト環境等一時的な場面での利用にとどめ、本番環境等を想定して利用する場合はカスタムモードの選択がベストプラクティスになります。カスタムモードを選択すると、追加で以下の項目について設定します。 サブネット名 説明 リージョン IP アドレス範囲 プレフィックス長で設定 セカンダリ IP 範囲 (任意) Google アクセス (任意) 他のリソースの API アクセスに外部 IP を使わない、AWS で言う VPC エンドポイントに相当する機能 フローログ (任意) VPC へのインバウンド (上り)、アウトバウンド (下り) トラフィックに関するログを生成、保管する機能 追加のサブネット設定 (任意) 設定項目は上記同様 サブネット設定-1 サブネット設定-2 ファイアウォールルール (IPv4 / IPv6) VPC へのインバウンド、アウトバウンドトラフィックを制御する機能で、AWS で言うセキュリティグループやネットワーク ACL に相当します。 以下のように、デフォルトルールを VPC 作成の段階で適用することもできますし、あとから別途ファイアウォールのメニューで具体的に定義することも可能です。 セキュリティの観点からすると、例えば RDP や SSH のインバウンドルールが以下の画面では接続元を any としていますので、必要最小限に絞り込んだルールを別途作成するほうが望ましいでしょう。 ファイアウォールルール設定 その他設定事項 その他の設定事項としては以下が挙げられます。いずれもオンプレミス環境との VPN 接続を想定した項目となります。 動的ルーティングモード オンプレミスと VPN 接続する際、グローバルを選択することで VPC 側のルート情報がオンプレミス側に広報されます DNS サーバーポリシー オンプレミスと VPN 接続する際、オンプレミス側の DNS を参照させることができます 最大伝送単位 (MTU) オンプレミスと VPN 接続する際、1460 に設定することを推奨します (VPN トンネル内ではオリジナルパケットがトンネルヘッダでカプセル化されるため) その他設定事項 ここまで設定し終えたら、最後に作成をクリックして VPC を作成します。 VPC の作成後 VPC 作成後は要件通り作成できたのかを確認し、必要に応じて修正や追加の編集を加えることができます。 VPC ネットワーク一覧に作成した VPC が表示されるかと思いますので、そちらをクリックすることで詳細確認と編集が可能な画面に遷移します。今回私は東京リージョンと大阪リージョンをまたがるような形で VPC を作成しました。 作成された VPC VPC 詳細画面 サブネット 初回作成後、サブネットタブからサブネットの削除や追加が可能です。 サブネットの編集画面 静的 IP アドレス 今回は作成していませんが、例えば Compute Engine を作成すると、自動的に 内部 IP アドレスが割り当てられますが、内部 IP をスタティックに割り当てたいといった要望がある場合にはこちらのタブから管理することができます。 静的 IP アドレスの編集画面 ファイアウォールポリシー、ファイアウォールルール 役割や目的は同じなんですが、先にも述べたとおり Google Cloud にはリソース階層という概念があります。そのため、前者であれば組織リソースやフォルダリソースにアタッチすることで、配下のリソースにも同じポリシーを適用することができ、後者であれば、例えば特定のプロジェクトの特定の VPC にのみユニークなルールを適用したい場合などに利用することができます。 ファイアウォールルールはファイアウォールルールタブから編集できます ファイアウォールルールの編集画面 ファイアウォールポリシーについては Google の公式サイトをご確認ください。 cloud.google.com ルート VPC 内外へ通信するためのルート情報を管理します。デフォルトでは、インターネットへのデフォルトルートや、VPC 内のサブネットを宛先としたルートは登録される仕様となっています。このあたりは AWS も同じ仕様かと思います。 ルートの編集画面 VPC ネットワークピアリング 同一プロジェクト内の他の VPC や、別のプロジェクトの VPC に対して通信を行いたい場合、VPC ネットワークピアリングを設定します。設定すると、宛先となる VPC (サブネット) へのルート情報が自動的に登録されます。 また、ローカル VPC または 接続先 VPC がオンプレミスと VPN 接続している場合、オンプレミス側のルート情報をインポートしたり、また、オンプレミス側へ VPC 側のルートのエクスポートも行えます。 VPC ネットワークピアリングの編集画面 プライベートサービス接続 こちらも今回は利用していませんが、例えば Cloud SQL で作成した DB インスタンスにプライベート IP 接続を設定した場合など、他のリソースとの接続にプライベートサービス接続を利用した場合に管理する項目になります。 プライベートサービス接続の編集画面 武井 祐介 (記事一覧) 2022年4月入社 / クラウドソリューション部 / 技術2課所属 趣味はゴルフにロードバイク。IaC や CI/CD 周りのサービスやプロダクトが興味分野です。 Google Cloud 認定全冠達成！(2023年6月)

G-gen の杉村です。 BigQuery の Search Index 機能が 2022年4月7日にプレビュー公開、2022年10月27日に GA されました。BigQuery に対する特定文字列の検索を高速化する当機能を解説します。 BigQuery Search Index の基本 BigQuery Search Index とは ユースケース 料金 制限 対応しているカラムタイプ その他の制限 インデックスの作成と利用 基本的な使い方 全カラムへのインデックス作成・検索 インデックスが使われたかどうかの確認 その他のクエリ方法 インデックスの削除 BigQuery Search Index の基本 BigQuery Search Index とは BigQuery の Search Index とは、 BigQuery のテーブルから特定文字列を検索・抽出するようなクエリを高性能化するためのインデックス機能です。 テーブルに、カラムを指定して予めインデックスを作成しておき、SELECT 文の WHERE 句に SEARCH() 関数や = 、 IN 、 LIKE などの演算子を用いることで、インデックスを利用した高速なクエリを実行できるようになります。 インデックスの更新は 自動的に 行われますので、一度インデックスを作成してしまえば、メンテナンスは必要ありません。 またインデックスを用いたクエリではフルスキャンが回避できますので、スキャン料金の節約にもなります。クエリによっては劇的な料金節約になる可能性があります。 なお当機能は 10GB 以上のサイズを持つテーブルにのみ有効 であり、それ以下のサイズのテーブルにインデックスを作成しても、有効になりません。 参考 : Introduction to search in BigQuery 参考 : Search indexed text 参考 : Manage search indexes ユースケース 当機能は、以下のようなユースケースが想定されます。 ログデータの検索（システムログ、ネットワークログ、アプリのログ等） 法的規制などに対応するための、特定データを検索したり削除するクエリ セキュリティ監査 トラブルシューティング 狭い範囲の特定文字列を抽出するダッシュボード作成 SEARCH() 関数を使う場合は複数カラムを横断して文字列や数値の検索が可能ですし、後述のようにネイティブ JSON 型のカラムにも対応しています。Cloud Logging で収集した Google Cloud サービスのログに対する検索などにも役立つでしょう。 BigQuery には従来、インデックスの概念がなく、インデックス設計を考慮する負担が無いことも BigQuery のメリットの一つでした。その基本姿勢を変える必要はなく、特定文字列を抽出するクエリのユースケースがある際の選択肢が増えた、と捉えればよいでしょう。 料金 インデックスを保存するための BigQuery ストレージ料金が発生します ( 料金ページ ) 。 インデックスが使用しているストレージの量は INFORMATION_SCHEMA.SEARCH_INDEXES ビュー で確認することができます。 インデックス作成・更新処理のコンピューティング料金については、リージョンごとに規定された範囲内であれば課金されませんが、それを超える場合は Reservation を購入する必要があります。詳細は以下のドキュメントをご参照ください。 参考 : Introduction to search in BigQuery - Pricing 参考 : Quotas and limits - Indexes 制限 対応しているカラムタイプ 以下の型のカラムに対して、インデックスを作成できます。 STRING INT64 TIMESTAMP ARRAY STRUCT JSON 参考 : CREATE SEARCH INDEX statement その他の制限 その他には以下の制限があります。 インデックスが使われるのは SEARCH() 関数もしくは WHERE 句で = 、 IN 、 LIKE など特定の演算子（operator）を使ったクエリのみ 10 GB 以下のサイズのテーブルではインデックスが無効 ビューやマテリアライズド・ビューにはインデックス作成不可 ただしビューやマテリアライズド・ビューの元テーブルにインデックスが張ってあれば、ビューに対する SEARCH 関数の利用でもインデックスが利用される テーブルがリネームされるとインデックスが無効になる インデックスの作成と利用 基本的な使い方 インデックスは以下のような CREATE 文で作成できます。 CREATE SEARCH INDEX my_index ON my_dataset.my_table(column_a, column_c); 作成したインデックスを利用して高速なクエリを実行するには、以下のような SELECT 文を用います。 SELECT * FROM my_dataset.my_table WHERE SEARCH(column_a, ' hogehoge ' ); なお、クエリ実行結果の EXECUTION DETAIL (日本語コンソールでは 実行の詳細 ) を確認することで、クエリにインデックスが使われたかどうかを確認することができます。 全カラムへのインデックス作成・検索 以下のような CREATE 文で、対象テーブルの全てのカラム (対応タイプのカラムのみ) にインデックスを作成できます。 CREATE SEARCH INDEX my_index ON my_dataset.my_table( ALL COLUMNS); また、以下のような SELECT 文でテーブル全体に対してクエリを実行できます。 SELECT * FROM my_dataset.my_table WHERE SEARCH(my_table, ' hogehoge ' ); インデックスが使われたかどうかの確認 クエリを実行したあと、そのクエリでインデックスが使われたかどうかを確認するには、クエリ実行後に当該ジョブの ジョブ情報 （Job Information）を確認します。 コンソール画面等でジョブ情報の詳細画面を表示し、 インデックス使用のモード （Index Usage Mode）の項目を確認することでインデックスが使用されたかどうかがわかります。 UNUSED : インデックスが使用されなかった PARTIALLY_USED : クエリの一部でインデックスが使用された FULLY_USED : クエリの全部分でインデックスが使用された 参考 : Search index usage ジョブ情報 その他のクエリ方法 インデックスを使ったさまざまなクエリ方法や、実行結果の考え方については以下の公式ドキュメントを参照してください。 参考 : Search indexed data SEARCH 関数の注意点として、例えば 192.168.10.1 のようなピリオド区切りの文字列は、パースされて 192 168 10 1 といういずれかの文字列を含む場合として検索されてしまいます。 IP アドレスを検索するときなどは `192.168.10.1` のようにバッククォートで囲むことで、一連の文字列として認識させる必要があります。 SELECT * FROM my_dataset.my_access_log WHERE SEARCH(ip_addr, ' `192.168.10.1` ' ); SEARCH 関数の使い方については以下をご参照ください。 参考 : Search functions インデックスの削除 インデックスの削除には DROP 文を用います。 DROP SEARCH INDEX my_index ON my_dataset.my_table; なおテーブルが削除されるとインデックスも自動的に削除されますので、削除忘れによる無駄なストレージ課金の心配はありません。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の渡邉@norry です。Google Cloud（旧称 GCP）の 高可用性 Cloud VPN は、IPsec VPN によりオンプレミスネットワークと VPC ネットワークをプライベートに接続するサービスです。 HA VPN 概要 HA VPN とは ユースケース HA VPN の料金 オンプレミス側ルーターの仕様 HA VPN を構成する要素 HA VPN 用語のおさらい Cloud HA VPN ゲートウェイ VPN ゲートウェイ の構成要素 VPN トンネル VPN トンネル の構成要素 Cloud Router BGP セッション の構成要素 構成 HA VPN 構成 高可用性の確認 アクティブ / アクティブ または アクティブ / パッシブ 運用・ロギング ログの保存場所 アラート HA VPN 概要 HA VPN とは 高可用性 Cloud VPN （以下、 HA VPN ）とは、インターネット回線上で IPsec VPN を用いて「オンプレミスと VPC ネットワーク」または「VPC ネットワーク 同士」あるいは「Google Cloud の VPC と Amazon VPC や Azure VNet 等」と安全に接続ができるサービスです。 HA VPN はインターネット回線を使用してプライベート接続を実現できることに加え、VPN トンネルを冗長化する事で可用性や帯域を拡張できるため、専用線に比較してコストメリットに優れています。 自組織で既にインターネット VPN を利用して拠点間接続を行っている場合、Google Cloud を自社の一拠点として追加するようなイメージで捉えてください。 なお、クライアント端末からの VPN 接続や SSL を利用した VPN 接続はサポートされていませんのでご注意ください。 参考 : Cloud VPN の概要 構築手順の例は以下の記事もご参照ください。 blog.g-gen.co.jp また、Cloud VPN のもう1つの機能として Classic VPN がありますが、機能としては HA VPN でカバー可能なこと、また 特定の機能が非推奨 となる為、本記事では取り扱いません。 ユースケース HA VPN のユースケースとしては次の通りです。 Google Cloud の仮想マシンに プライベート接続 したい データ通信に必要な帯域が 12Gbps (理論値) より少ない トンネル一本あたり上り下りの合計で 3Gbps をサポート HA VPN ではトンネル2本以上を推奨 通信速度は ベストエフォート で良い アプリケーションレベルの暗号化では無く、 通信レベル の暗号化を利用する 低コストながらも最大 99.99% の可用性を担保し運用したい 利用状況によりますが、一般的な小中規模の環境であれば、合致するのではないでしょうか。 通信に対して帯域保証が必要な場合や 10 GBps 以上の速度が必要な場合は専用線接続の Dedicated Interconnect、Partner Interconnect をご検討ください。 Google Cloud のネットワーク接続においてどのサービスを選択するかは、以下のフローチャートをご利用ください。※ 公式 の抄訳になります。 Google Cloud 接続方式の選択 HA VPN の料金 HA VPN の料金は大きく分けて 利用時間 と 通信量 の2軸で計算されます。 "利用時間"は、ゲートウェイ利用 1時間 ごと、 トンネルの数 と 場所 が加味された料金が発生します。 "通信量"は、IPsecの通信量に応じて 月額 で料金が発生します。 2022年4月現在の料金は以下です。 ※ 東京リージョン内での通信を想定 1トンネル 1ヶ月あたり $54.75 Google Cloud から外向きの通信料 $0.14/GB 計算例です。例えばトンネルを 2 本接続し 2 TB のデータをオンプレミス側に受信した場合には VPN: $0.075 * 720 * 2本 = $108 ≒ 115 * 108 = ¥12,420/月 Premium Tier to APAC: $0.14 * 2,048 GB = $286.72 ≒ 115 * 286.72 = ¥32,973/月 約 ¥45,400/月 程度の費用になります ($1 = 115円換算) 。 ※インターネット回線、サービスプロバイダ料金、オンプレミス側の固定パブリックIP料金は別途契約が必要です。 また Google Cloud へ入るデータ (内向き) に関しては通信料金が発生しません。 最新の料金は以下を参照ください。 Cloud VPN の料金表 オンプレミス側ルーターの仕様 HA VPN 接続可能なオンプレミス側ルーターの仕様は次の通りです。 項目 内容 VPN 形式 IPsec VPN プロトコル ESP (IPsec)、(IKE) UDP 500、UDP 4500 ※ トンネルモードの ESP をサポートしている事 ※ IKEv1 または IKEv2 をサポートしている事 NAT-T を利用する場合 1:1 NAT 現在市場に流通している法人向けの一般的なルーターであれば、ほぼ対応していると思われますが詳しくは各メーカーにお問い合わせください。 HA VPN を構成する要素 HA VPN では大きく分けて以下の２つのリソースから成り立っています。 Cloud HA VPN ゲートウェイ Cloud Router 検討すべき要素を事項より記述します、設計の際にご参考ください。 HA VPN 用語のおさらい Cloud VPN で HA VPN 構成を組む場合に良く出てくる言葉を下記にまとめておきます、さらっと確認しておいていただいた方が全体の理解が深まるかと思います。 用語 簡単な解説 1 AS 番号 (Autonomous System number) ISP など大きなネットワークに割り当てられる一意の識別番号 2 BGP (Border Gateway Protocol) AS を他のAS に広告したりルーティングしたりするためのプロトコル 3 Cloud VPN ゲートウェイ（IP） Google Cloud の外側 (WAN) IP アドレス 4 ピア VPN ゲートウェイ（IP） オンプレミスの 外側 (WAN) IP アドレス 5 Cloud Router の BGP IP IPsec VPN でトンネルを張る時の Google Cloud 側 BGP 用 IP アドレス 6 BGP ピア IP IPsec VPN でトンネルを張る時のオンプレミス側の BGP用 IP アドレス 7 MED 値 BGP 通信をする際にどのパスを優先するかの重み付け Cloud HA VPN ゲートウェイ VPN ゲートウェイは Google Cloud の VPC リソース と オンプレミスネットワークや他の VPC リソースと接続する仮想的な出入り口です。 インターネットなどの公衆ネットワークを利用し、仮想的な専用ネットワークを構築することが可能となっています。 接続、認証、暗号化、復号などを担当しています。 Google Cloud の Virtual Private Cloud (VPC) は グローバル である事から複数のリージョンをカバーしています。 したがってHA VPN を利用したい VPC と同じリージョンにゲートウェイを配置する必要はなく、接続拠点から近いリージョンを選択する事で GCP に到達するまでのホップ数を少なくする事が出来ます。 VPN ゲートウェイ の構成要素 VPC: どのVPC と接続するか リージョン: どのリージョンに配置するか、選択後に 変更が出来ない 為注意 VPN ゲートウェイのパブリック IP アドレス: Google 側で割り当てされる IP VPN トンネル VPN トンネルでは接続先の パブリック IPアドレス、ASN、広報ルートなど主にトンネリングに必要な情報、暗号化に関する設定を行います。 VPN トンネル の構成要素 ピア (接続先) VPN ゲートウェイ オンプレミスまたは非 Google Cloud Google Cloud Cloud Router Google ASN アドバタイズルート ピア VPN ゲートウェイ インターフェース 1-4つのインターフェースの指定が可能 IKE のバージョン選択と事前共有キー Cloud Router Cloud Router ではオンプレミスとの BGP セッションの確率を行います。 また、 Google Cloud の VPC 内の新しいネットワークを自動的に学習しオンプレミスネットワークへ広報します。 BGP セッション の構成要素 ピア ASN プライベート ASN: 64512～65534 の値を設定します。 MED Cloud Router の BGP IP BGP ピア IP 対抗側で設定したローカルリンクアドレスを指定します。 構成 HA VPN 構成 HA VPN では適切にインターフェース、複数のトンネルをペアリングする事で 99.99% の可用性 SLA を享受することができます。 HA VPN ではトンネル１本の運用も可能ですが、その場合には SLA を得る事が出来ません。 なおこの SLA 適用時に実際の稼働がこれを下回ると Financial Credits を受け取ることができます ( 参考 ) 。 SLA 適用はトンネルを ペア (アクティブ / アクティブ または アクティブ / パッシブ) で構築する事により受けることができます。 したがって、以下のようなトンネル1本のパターンでは SLA 適用外となります。 トンネル1本の構成 一方で、トンネルペアの構成では SLA 適用対象となります。 この場合のオンプレミス側のゲートウェイ装置では1台でも2台でもよく、トンネルが ペア で作成される事がポイントで以下のような構成の場合は適用対象となります。 ただし、オンプレミス側ルーターの障害時の実用的な可用性を考慮に入れると、2台体制が望ましいと言えます。 トンネルペアの構成 高可用性の確認 HA VPN が構成され、 SLA 対象となっているかを確認する事が出来ます。 管理コンソール ＞ ハイブリッド接続 ＞ VPN ＞ CLOUD VPN ゲートウェイ ＞ ゲートウェイの名前を選択 HA VPN 高可用性の確認 高可用性が ◯ になっていれば適用されています。 アクティブ / アクティブ または アクティブ / パッシブ オンプレミスで IPsec VPN を組んだ事がある人であれば、通常アクティブ / パッシブ (アクティブ / スタンバイ) は 回線 の事をイメージされるかもしれません。 Google Cloud HA VPN ではその制御を BGP ルーティングの VPN トンネルの ルート優先度 (MED) を設定する事によって構成します。 アドバタイズされた優先度 (MED) MED の値は 0 から 65535 の整数で設定し値が 0 に近いほど優先度が高くなります。 デフォルトの基本優先度は 100 となっており、上記のように指定しない場合はデフォルトの値が適用されます。 トンネルの片側のMED優先度を変更する事によりアクティブ / パッシブの状態になります。 ただし、トンネルのステータスは アクティブ 状態のままであり、あくまでパケットがルートされる際の優先度の高低差で「アクティブ / パッシブ」を実現しています。 アクティブ / パッシブ deno HA VPN の高可用性について詳しく知りたい方は以下を参照ください。 cloud.google.com 運用・ロギング ログの保存場所 VPN のログはデフォルトで特定のログが Cloud Logging に送信されます。 デフォルトの保存期間は 30 日間です。それよりも長い期間ログを保持するには、 _default ログバケットの保存期間を変更するか、ログを別のストレージに転送する必要があります。 転送先として Pub/Sub 、 BigQuery 、 Cloud Storage 、 他のログバケットが利用可能です。 Cloud Logging の詳細については以下をご覧ください。 blog.g-gen.co.jp アラート Cloud Monitoring を利用してVPN トンネルに関連する指標を表示し、アラートを作成する事が出来ます。 例えばトンネルを利用する帯域が一定のしきい値をオーバーしたら通知する...といった事が可能です。 主な指標としては次のような物があります。 種類 説明 gateway/connections 接続数 VPN ゲートウェイあたりの HA 接続の数を示します。 network/dropped_received_packets_count 破棄された受信パケット トンネルで破棄された上り（内向き、ピア VPN からの受信）パケット。60 秒ごとにサンプリングされます。サンプリング後、データは最長 180 秒間表示されません。 network/dropped_sent_packets_count 破棄された送信パケット トンネルで破棄された下り（外向き、ピア VPN への転送）パケット。60 秒ごとにサンプリングされます。サンプリング後、データは最長 180 秒間表示されません。 network/received_bytes_count 受信バイト数 トンネルの上り（内向き、ピア VPN からの受信）バイト。60 秒ごとにサンプリングされます。サンプリング後、データは最長 180 秒間表示されません。 network/received_packets_count 受信パケット数 トンネルの上り（内向き、ピア VPN からの受信）パケット。60 秒ごとにサンプリングされます。サンプリング後、データは最長 60 秒間表示されません。 network/sent_bytes_count 送信バイト数 トンネルの下り（外向き、ピア VPN への転送）バイト。60 秒ごとにサンプリングされます。サンプリング後、データは最長 180 秒間表示されません。 network/sent_packets_count 送信パケット トンネルの下り（外向き、ピア VPN への転送）パケット。60 秒ごとにサンプリングされます。サンプリング後、データは最長 60 秒間表示されません。 tunnel_established 確立したトンネル > 0 の場合、成功したトンネル確立を示しています。60 秒ごとにサンプリングされます。サンプリング後、データは最長 180 秒間表示されません。 渡邉 宣之 (記事一覧) クラウドソリューション部 AI/ML、アプリケーションモダナイゼーション、データ分析基盤の構築、クラウド管理運用やネットワークなどインフラ系は何でも、Google Workspace 活用も推進中 週末フォトグラファーで、観葉植物や塊根植物にハマっていて種から育ててます。

こんにちは、G-gen の渡邉です。 個人用 Gmail だけで無く Google Workspace の企業用 Gmail でも Google Workspace で利用しているドメイン以外のメールを受信する事ができます。 Google Workspace のユーザーアカウントとは別に他のメールサーバーで利用しているメール、例えばプロバイダのメールアドレスや、個人向けの gmail.com アカウントなどです。 この記事ではその設定方法をご案内します。 また、Google Workspace のユーザーアカウントで利用しているドメインの場合、ユーザーエイリアスとして30個まで可能です。 Gmail の設定 Gmail の設定 gmail.com の場合 個人用 Gmail の設定 Google Workspace 企業用 Gmail の設定 注意事項 Google Workspaceを導入するなら株式会社G-genにご相談ください。 Gmail の設定 Google Workspace の Gmail 画面に入ります。 Gmail の設定 右上部のギアマーク ＞ すべての設定を表示 をクリック。 アカウント タブ ＞ メールアカウントを追加する 追加したいメールアドレスを入力。 以下の項目を入力します。 内容については適宜追加したいメールアドレスの設定情報に基づいてください。 ※ SSL の利用も可能となっています。 ①ユーザー名 ①パスワード ①POP サーバー ②ポート番号の指定 ③SSL を利用する場合はチェック 入力後、アカウントを追加 を選択 メールを受信するだけでなく、Gmail から送信もしたい場合には、「はい。◯◯◯としてメールを送信できようにします。」をオンにして 次へ をクリックします。 メールの名前を入力して 次のステップ をクリック ウィンドウを閉じる で設定を終了 追加したメールアドレスにテストメールを送信すると以下のように受信されました。 メールアカウントを追加する際にラベルをつけておくと、どのメールアドレスで受信したかが分かりやすいのでおすすめです。 gmail.com の場合 個人用 Gmail の設定 個人用の gmail.com も同じ手順で追加する事が可能です。 ただし、POP での受信になりますので事前に 個人用 Gmail の設定で POP を有効化しておく必要があります。 個人用 Gmail の設定画面 Google Workspace 企業用 Gmail の設定 こちらの設定は前述と同じ操作になります。 個人用の gmail アドレスを入力。 ログインに必要な情報を入力します、POP サーバー、ポート番号などは自動的に設定されます。 注意事項 この設定によってGmail に複数のメールアドレスを集約しメールクライアントとして利用する事が可能ですが、以下の事にご注意ください。 定期的にGmail → メールサーバー にメール取得を実施している関係上タイムロスが発生します。 即時性が必要な場合はエイリアス (例: test@ドメイン名.test-google-a.com) に対し他のメールアカウントからメールを転送する形でご利用ください。 メール受信履歴 Google Workspaceを導入するなら株式会社G-genにご相談ください。 株式会社G-genではGoogle Workspace / Google Cloud（GCP）を5%割引でご提供しております。 g-gen.co.jp また、Google Workspace / Google Cloud（GCP）/ Chrome book の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 お問い合わせはこちらから docs.google.com 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-genの杉村です。 BigQueryでは、 列レベルのアクセス制御 や 行レベルのセキュリティ といった機能を使い、きめ細かいアクセス制御を行うことができます。 列レベルのアクセス制御 列レベルのアクセス制御 分類とポリシータグ 制限 行レベルのセキュリティ 行レベルのセキュリティとは 行レベルのアクセスポリシー 制限 列レベルのアクセス制御 vs 行レベルのセキュリティ 列レベルのアクセス制御 列レベルのアクセス制御 BigQuery の 列レベルのアクセス制御 （column-level access control）機能は、事前定義した ポリシータグ を列に付与することで、特定の Google アカウントやグループだけが列にアクセスできるようにする仕組みです。当機能は従来、列レベルのセキュリティ（column-level security）とも呼ばれていました。 例として、 BigQuery テーブルの個人情報を含む列に security-level : high のようなタグを付与して、このタグがついている列には manager@example.com グループのメンバーしかアクセスできないようにする、といった制御が可能です。 アクセスポリシーは SQL を実行する際に評価され、許可されていないメンバーからのクエリは Access Denied として拒否されます。 参考 : 列レベルのアクセス制御 列レベルのアクセス制御 分類とポリシータグ 列レベルのアクセス制御では、事前に 分類 （Taxonomy）を作成します。分類の中には複数の ポリシータグ を収容できます。 作成したポリシータグには、IAM ロールを紐づけることができます。ポリシータグにおいて、Google アカウントやグループを「きめ細かい読み取り（ roles/datacatalog.categoryFineGrainedReader ）ロール」等と紐づけることで、そのポリシータグがアタッチされた列へのアクセスを許可することが可能です。 分類とポリシータグ このポリシータグをテーブルの列ヘアタッチすることで、IAM で許可されたアカウントやグループのみが、列へアクセスできるようになります。 列へポリシータグをアタッチ 参考 : 列レベルのアクセス制御によるアクセス制限 参考 : BigQuery でポリシータグを使用する際のベスト プラクティス なお、ポリシータグには「子ポリシータグ（サブタグ）」を作ることができ、5段階までネストできます。親ポリシータグへのアクセス権限を持っていれば、権限は子へ継承され、子ポリシータグへのアクセスも可能です。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog - 継承 制限 列レベルのアクセス制御には、以下のような制限があります。 BigQuery Editions の Standard エディションでは利用できない（オンデマンド、Enterprise、Enterprise Plus では利用可能） 1つの列にアタッチできるポリシータグは1つだけ 1つのテーブルにアタッチ可能なポリシータグの種類は最大1,000個まで ポリシータグが1つでもついているとそのテーブルでは Legacy SQL が使えない 「ある列にはポリシータグを1つしかアタッチできない」という制限があるため、アクセス制御が複雑になりすぎないように、分類とポリシータグ作成には工夫が必要です。 参考 : 列レベルのアクセス制御の概要 - 制限事項 行レベルのセキュリティ 行レベルのセキュリティとは 行レベルのセキュリティ （row-level security）は、テーブルに 行レベルのアクセスポリシー を設定することで、Google アカウントやグループに対して、 特定の値を持った行にだけ アクセスできるように制御する機能です。 例として、顧客情報テーブルにおいて、地域情報が格納されている region 列の値が Kanto なら関東地域担当のセールスチームにだけ行が見えるようにし、関西担当チームからは見えないようにする、といったことが可能です。 アクセスポリシーは SQL を実行する際に評価され、許可されていない行はクエリ結果から取り除かれます。 参考 : BigQuery の行レベルのセキュリティの概要 行レベルのセキュリティ 行レベルのアクセスポリシー 行レベルのアクセスポリシー は、 CREATE ROW ACCESS POLICY 文を実行して作成します。 参考 : 行レベルのセキュリティを使用する 以下は、行レベルのアクセスポリシーを作成するための構文の例です。 CREATE ROW ACCESS POLICY region ON `myproject.mydataset.user_table` GRANT TO ( " group:team-kanto@example.com " ) FILTER USING (region = " Kanto " ); また以下のような指定も可能です。 CREATE ROW ACCESS POLICY region ON `myproject.mydataset.employee_table` GRANT TO ( " domain:example.com " ) FILTER USING ( emp_email = SESSION_USER() ); 上の例では、FILTER 句で指定する emp_email 列の値を SESSION_USER() としています。これは BigQuery の SESSION_USER 関数です。これにより、SQL を実行したメールアドレスを取得しています。この例では、従業員が自分のデータだけを、社員一覧テーブルから得られるようになります。 参考 : Security functions - SESSION_USER 制限 行レベルのセキュリティには、以下のような制限があります。 BigQuery Editions の Standard エディションでは利用できない（オンデマンド、Enterprise、Enterprise Plus では利用可能） クエリパフォーマンスが若干低下する 行レベルのセキュリティは、JSON 型の列には使えない 行レベルのセキュリティが適用されていると、ワイルドカードテーブルクエリが使えない すべての制限事項の一覧は、以下の公式ドキュメントを参照してください。 参考 : BigQuery の行レベルのセキュリティの概要 - 制限事項 列レベルのアクセス制御 vs 行レベルのセキュリティ 列レベルのアクセス制御と、行レベルのセキュリティは一見似ていますが、ユースケースの違いは明白です。 特定の Google アカウントやグループには、特定の列を、列ごと見せたくないときには、列レベルのアクセス制御を使います。例として、個人情報が格納されている列、機密情報が格納されている列などです。 一方で、列全体ではなく、列の値によって見せる行を分けたいときに、行レベルのセキュリティを使います。例えば、セールスチームのグループには「部署」列に sales という値が入っている行だけを見せたい時などです。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。 パブリッククラウドとして提供されるオブジェクトストレージの二大巨頭、 Cloud Storage (Google Cloud) と Amazon S3 (AWS) を比較してみました。 非常によく似ているサービスですが、どのような違いがあるのでしょうか。 Cloud Storage vs Amazon S3 Cloud Storage / Amazon S3 とは 共通点 基本スペック 管理機能・付加機能 ストレージクラスと料金の違い ストレージクラスの違い ストレージクラスごとの料金 標準ストレージ Nearline / Infrequent Access Coldline / Glacier Instant Retrieval / Glacier Flexible Retrieval Archive / Glacier Deep Archive ネットワーク料金 暗号化の違い バケットのリージョン データ連携 AWS の場合 Google Cloud の場合 Amazon S3 vs Cloud Storage Cloud Storage / Amazon S3 とは Cloud Storage とは Google Cloud (旧称 GCP) が提供するオブジェクトストレージサービスです。 一方で Amazon S3 は Amazon Web Services (AWS) が提供するオブジェクトストレージサービスです。 これら2つのサービスはよく似ており、比較対象にもなります。 オブジェクトストレージが何か、また Cloud Storage の詳細については以下の記事にて解説していますのでご参照ください。 共通点 基本スペック Cloud Storage と Amazon S3 はともにオブジェクトストレージ (キー・バリューストア) であり バケット や オブジェクト という概念、 フラットな構成 、 Web API による I/O などの共通点があります。 また、以下のような基本性能も共通しています。 容量無制限 99.999999999% (イレブンナイン) の耐久性 複数のデータセンターに冗長化 1 オブジェクトの最大サイズは 5 TiB IAM やオブジェクトレベル ACL によるアクセス制御 データ保管料金に加えリクエスト回数に対する料金やネットワーク利用料金がかかるなどの課金体系 Read-after-Write の強い整合性 これらのことから、ユースケースがほぼ同じであり、基本的な性能ではどちらも引けを取らないものだということが分かります。 管理機能・付加機能 以下のような管理機能も共通です。 監査ログ ライフサイクル管理 (自動でストレージクラスを変更したり古いファイルを削除) オブジェクトへのメタデータ付与 メトリクスのモニタリング 規制/法令対応のための削除ロック その他に、以下のような機能も共通しています。 静的ウェブサイトホスティング機能 オブジェクト変更をトリガとしたメッセージキューイングサービスへの通知 ストレージクラスと料金の違い ストレージクラスの違い Cloud Storage と Amazon S3 はともに ストレージクラス の概念を持っており、保管期間やアクセス頻度により使い分けます。 頻繁にアクセスされるオブジェクトを配置する標準的なストレージのほか、アクセス頻度が低いファイルを配置するストレージ、めったにアクセスされないアーカイブ用のストレージなどがあります。 アーカイブ寄りのクラスほど、保存データサイズに対する料金は安い反面、書き込み・読み取りリクエスト回数や取り出しデータ量に対する料金が高いことでバランスが取られています。 Cloud Storage と Amazon S3 のストレージクラスを比較すると以下のようになります。 (いずれも東京リージョン、 2022 年 3 月現在) Cloud Storage ( 料金ページ ) ( ストレージクラスに関するドキュメント ) ストレージクラス 保管料金 (GB/月) 最低保管期間 レイテンシ Standard Storage $0.023 なし ミリ秒レベル Nearline Storage $0.016 30 days ミリ秒レベル Coldline Storage $0.006 90 days ミリ秒レベル Archive Storage $0.0025 365 days ミリ秒レベル Amazon S3 ( 料金ページ ) ( ストレージクラスに関するドキュメント ) ストレージクラス 保管料金 (GB/月) 最低保管期間 レイテンシ S3 Standard $0.025 (最初の 50 TB) $0.024 (次の 450 TB) $0.023 (500 TB 以上) なし ミリ秒レベル S3 Standard - Infrequent Access $0.0138 30 days ミリ秒レベル S3 One Zone - Infrequent Access $0.011 30 days ミリ秒レベル S3 Glacier Instant Retrieval $0.005 90 days ミリ秒レベル S3 Glacier Flexible Retrieval $0.0045 90 days 数分から数時間 S3 Glacier Deep Archive $0.002 180 days 数時間 S3 Intelligent - Tiering (料金ページ参照) - - 細かな違いはありますが、概ね「標準ストレージ」「30日程度保管・月1回程度のアクセス向けのストレージ」「90日程度保管・四半期に一度程度のアクセス向けのストレージ」「年単位の長期保管向けの最も安価なストレージ」がどちらにも用意されていることが分かります。 一方で Amazon S3 のほうが選択できるストレージクラスが多く、ユースケースに応じてより柔軟に選択することができます。 また S3 Intelligent - Tiering というクラスが存在し、これはオブジェクトのアクセス頻度によって自動的に最適なストレージクラスに振り分けてくれる機能です (しかし扱いとしては S3 Intelligent - Tiering 自体がストレージクラスの一種に位置づけられています) 。 なお「最低保管期間」の意味については、 Cloud Storage / Amazon S3 ともに「オブジェクトを生成してからこの日数を超えないうちにオブジェクトを削除等すると、この日数分の保管料金がかかる」という仕組みになっています。 また大きな違いとしては Cloud Storage の Archive Storage では、オブジェクト取得にかかる時間が ミリ秒単位 とされていることです。 一方で Amazon S3 の Glacier では Flexible Retrieval で 数分から数時間単位 、 Glacier Deep Archive で 数時間単位 です (利用するオプションによっても変わります) 。 ストレージクラスごとの料金 前述の表ではデータサイズに対してかかる保管料金のみを記載しました。 しかし Cloud Storage / Amazon S3 の両方で、ほかにも「リクエスト回数に対する課金」「データ取り出し量に対する課金」「ネットワーク利用に対する課金」が存在します。 これらについても比較してみます。いずれも 2022 年 3 月現在の東京リージョンの料金を記載していきます。 標準ストレージ まずは 標準ストレージ の料金です。 ストレージクラス 保管料金(GB/月) 書込(/1,000回) 読取(/ 1,000回) データ取出リクエスト(/ 1,000回) データ取出量 (GB) 最低保管期間 Cloud Storage - Standard $0.023 $0.005 $0.0004 なし なし なし Amazon S3 - Standard ・ $0.025 (最初の 50 TB) ・ $0.024 (次の 450 TB) ・ $0.023 (500 TB 以上) $0.0047 $0.00037 なし なし なし データ保存料金や書込/読取リクエスト数に対する料金に若干の違いはありますが、ほぼ同等クラスといえます。 また Amazon S3 ではデータ保管量が大きくなるにつれ、単位あたりの料金が安くなっています。 Nearline / Infrequent Access 次に Cloud Storage の Nearline Storage と Amazon S3 の Infrequent Access (Standard と One Zone の2種類) の違いです。 これらのストレージクラスは、標準ストレージよりはアクセス頻度が低いが、まったくアクセスが無いわけでもない... 概ね月に1〜数回程度のアクセスがあるオブジェクトを入れるためのクラスです。 バックアップ用途、災害対策用途、ログの長期保存などに適しています。 ストレージクラス 保管料金(GB/月) 書込(/1,000回) 読取(/ 1,000回) データ取出リクエスト(/ 1,000回) データ取出量 (GB) 最低保管期間 Cloud Storage - Nearline $0.016 $0.01 $0.001 なし $0.01 30 days Amazon S3 - Standard - Infrequent Access $0.0138 $0.01 $0.001 なし $0.01 30 days Amazon S3 - One Zone - Infrequent Access $0.011 $0.01 $0.001 なし $0.01 30 days こちらは、若干 Amazon S3 のほうが安くなっています。 なお Amazon S3 の Standard - Infrequent Access と One Zone - Infrequent Access の違いですが、後者は冗長性が 1 ゾーンに閉じており、データの可用性・堅牢性を下げる代わりにより安い料金で提供されています。 Coldline / Glacier Instant Retrieval / Glacier Flexible Retrieval 次に Cloud Storage の Coldline Storage と Amazon S3 の Glacier Instant Retrieval および Glacier Flexible Retrieval を比較します。 これらのストレージクラスは、概ね3ヶ月に一度以下程度のアクセス頻度のオブジェクトを配置するためのクラスです。 ストレージクラス 保管料金(GB/月) 書込(/1,000回) 読取(/ 1,000回) データ取出リクエスト(/ 1,000回) データ取出量 (GB) 最低保管期間 取得にかかる時間 Cloud Storage - Coldline $0.006 $0.01 $0.005 なし $0.02 90 days ミリ秒レベル Amazon S3 - Glacier Instant Retrieval $0.005 $0.02 $0.01 なし $0.03 90 days ミリ秒レベル Amazon S3 - Glacier Flexible Retrieval $0.0045 $0.03426 $0.00037 $11.00 (Expedited) $0.033 (Expedited) 90 days 1〜5 分以内 (Expedited) Cloud Storage の Coldline と Amazon S3 の Glacier Instant Retrieval が同格だと考えて良いでしょう。 データサイズに対する料金は若干 Glacier Instant Retrieval の方が安くなっていますが、取り出しにかかる料金等は Cloud Storage - Coldline Storage のほうが安いです。 Amazon S3 の Glacier Flexible Retrieval は取り出しのためのオプションが複数ありますが、今回は Cloud Storage に合わせて素早い取り出しが可能な Expedited モードの料金を記載しました。 ほかにも 3〜5 時間単位で取り出し可能な Standard モードや 3〜12 時間程度 かかるが一括取り出しに適した Bulk モードなどがあります ( ドキュメント ) 。 Archive / Glacier Deep Archive 最後に Cloud Storage の Archive Storage と Amazon S3 の Glacier Deep Archive を比較します。 これらのストレージクラスは、概ね年単位に一度以下のアクセス頻度のオブジェクトを配置するためのクラスです。 ストレージクラス 保管料金(GB/月) 書込(/1,000回) 読取(/ 1,000回) データ取出リクエスト(/ 1,000回) データ取出量 (GB) 最低保管期間 取得にかかる時間 Cloud Storage - Archive $0.0025 $0.50 $0.50 なし $0.05 365 days ミリ秒レベル Amazon S3 - Glacier Deep Archive $0.002 $0.065 $0.00037 $0.1142 (Standard) $0.022 180 days 3〜5 時間 (Standard) ここでも料金には僅かな違いがあり、データ保管料金は Glacier の方が若干安いですが、取り出しにかかる金額は Cloud Storage の方が安くなっています。 その他の大きな違いは Cloud Storage - Archive Storage は ミリ秒レベルのレイテンシ であるのに対し、 Amazon S3 - Glacier Deep Archive は 数時間が必要 な点です。 前述の通り Glacier には複数の取り出しタイプがありますが、 Deep Archive では Expedited モードは使えず Standard か Bulk になります。 ここまで記載したように、 Cloud Storage と Amazon S3 では料金面で若干の差があります。 傾向としてはデータサイズに対する料金は Amazon S3 の方が若干安く、リクエスト数に対する料金は Cloud Storage の方が若干安いです。 差が小さいとはいえ データ保管ボリュームがかなり巨大な場合 や、アプリケーションからの アクセス頻度がかなり多い場合 は、差が出てくることになります。 ネットワーク料金 Cloud Storage / Amazon S3 の両方で、ストレージへのデータのアップロードが無料な一方、 ストレージからのダウンロード のボリュームに応じて料金が発生します。 Cloud Storage ティア 料金 0 - 1 TB $0.12 1 - 10 TB $0.11 10 TB - $0.08 Amazon S3 ティア 料金 0 - 10 TB $0.114 per GB 10 - 50 TB $0.089 per GB 50 - 150 TB $0.086 per GB 150 TB - $0.084 per GB これらを比べると、大きな違いはなく、データ転送ボリュームがかなり巨大になったときに差が出てきます。 なおポイントとして、Amazon S3 には 月 100 GB までのデータ転送量の無料枠 があります。 (この利用枠は Amazon S3 だけでなく Amazon EC2 など他のサービスとも共有されます。) 小〜中規模の利用であれば、この無料枠で大半が賄えるでしょう。 一方で Google Cloud Storage では 「月に 1 GB のデータ転送量」「月 5 GB のデータ保管量」「月 5,000 回の書き込みリクエスト」「月 50,000 回の読み込みリクエスト」の無料枠があるもののこれが適用されるのは us-east1, us-west1, us-central1 の 3 リージョンだけ です。日本のユーザーが最も使うであろう東京・大阪リージョンでは適用されません (2022 年 3 月現在) 。 暗号化の違い Cloud Storage では 全てのデータがデフォルトでサーバサイドで暗号化 されます。 この暗号化は 無効化することができません ので Cloud Storage では必ず保存時のデータが暗号化されることになります。 デフォルトでは Google が管理する暗号化鍵が利用されますが、ユーザ持ち込みの鍵を利用することも可能です。 一方で Amazon S3 では暗号化はオプションであり オフにすることができます 。 バケットごとの設定として暗号化をデフォルトとする選択が可能なほか、オブジェクトごとに暗号化の有無を選択できます。 Amazon S3 でも Amazon が管理する暗号化鍵を利用するか、ユーザ持ち込みの鍵を利用することが可能です。 暗号化の違いという点では Cloud Storage では暗号化をそもそもオフにできないため、設定漏れ等を未然に防ぐことができるといえます。 バケットのリージョン Cloud Storage 、 Amazon S3 ともにバケット作成時にリージョンを指定します。 Amazon S3 では単一のリージョンを指定する一方、 Cloud Storage では 単一リージョンの他に「 デュアルリージョン 」「 マルチリージョン 」が選択できます。 デュアルリージョンやマルチリージョンを指定すると、データは複数のリージョンに非同期で自動的にレプリケーションされます。 リージョン間でデータをコピーする目的としては、 DR 目的での堅牢性・可用性の向上や、国を跨いで利用されるアプリケーションやウェブサイトのためにレイテンシを小さくすることが挙げられます。 Amazon S3 でも明示的に クロスリージョンレプリケーション を設定すれば同様のことが可能です。 Cloud Storage の方が、単にバケットの設定をマルチリージョン/クロスリージョンとするだけでリージョン間コピーが可能であり、かつアプリケーションや利用者側からは透過的に一つのバケット・一つのオブジェクトを指定するだけで済むため、より 実装がシンプル になるといえます。 データ連携 AWS の場合 Amazon S3 は マネージドの RDB サービスである Amazon RDS 、 Amazon Aurora やデータウェアハウスである Amazon Redshift とのデータ連携が可能です。 また Amazon Kinesis Data Firehose など、各種 AWS サービスとの連携が容易にできるほか、 AWS サービスによってはログファイルの出力先が Amazon S3 になっているなど、 AWS をフル活用している場合は Amazon S3 を自然に活用することになります。 AWS を利用している場合は Amazon S3 がデータ保管の要 となります。 そのため AWS におけるデータ活用基盤では Amazon S3 がデータレイクとして使われる ケースが標準的です。 ※ RA3 ノードタイプのマネージドストレージは Amazon S3 相当のため安価であり、構造化データは始めからここに配置する場合もあります。 AWS におけるデータ活用基盤のストレージ Google Cloud の場合 同様に Cloud Storage では マネージドの RDB サービスである Cloud SQL や、世界的に非常に人気の高いデータウェアハウスである BigQuery とのデータ連携が可能です。 BigQuery のストレージは非常に安価です。 BigQuery では通常のストレージが $0.023 /GB 、 90 日間変更がなかったデータは Long-term Storage とされ $0.016 /GB になります。 これは Cloud Storage の Standard ($0.023 /GB) と Nearline ($0.016 /GB) の保管金額と同じです。 分析対象となり得るデータであり BigQuery のテーブルに入れられる構造化データであれば、 Cloud Storage でなく始めから BigQuery に入れる という選択肢が出てきます。 そのため Google Cloud におけるデータ活用基盤では、 データレイクとして構造化データは BigQuery に 、 非構造化データは Cloud Storage に 入れるというケースがよくあります。 Google Cloud におけるデータ活用基盤のストレージ Amazon S3 vs Cloud Storage クラウドサービスを比較検討している方の中には「 Amazon S3 と Cloud Storage はどちらのほうが 良い のか？」という疑問を持つ方もいらっしゃるかもしれません。 一つの考え方としてはこれらのサービスを 単純にストレージサービスとしての観点だけで見てしまう と Amazon S3 vs Cloud Storage という単純比較には あまり意味がない と言えます。 これまでに比較したように、これら 2 サービスは機能、堅牢性、料金などにおいてほとんど同等レベルを達成しています。 そうなったときに比較検討の基準となりえるのは、 他のクラウドサービスとの組み合わせ です。 "データ連携" の項で書いたように Amazon S3 は AWS の、 Cloud Storage は Google Cloud のデータ分析系サービスとの親和性が高いです。 例えば業務システムが AWS 上に配置されており、分析基盤も AWS の Amazon Redshift 等で構成されている場合は、データレイクのストレージは Amazon S3 が唯一の選択肢となります。 一方で業務システムが AWS にあるとしても、高性能・安価な BigQuery をデータウェアハウスとして利用したい場合、非構造化データは Cloud Storage に、構造化データは BigQuery に送信・保存するという選択肢は十分ありえます。 データの流れを上流から下流まで見たときに、データ連携において 「料金・性能・実装や運用の容易さ」の観点でどこにデータを配置するのが最も効率が良いか 、という点に着目してストレージを選択するべきです。 そのため Amazon S3 や Cloud Storage の機能のみならず、データの下流である Amazon Redshift, BigQuery, Snowflake などのデータウェアハウスサービスや BI ツールなどの仕様を確認して、オブジェクトストレージとの連携方法を把握することが望ましいでしょう。 なお参考として Google Cloud の BigQuery では Cloud Storage とは容易にデータを連携できることに加え BigQuery Omni 機能によって Amazon S3 のオブジェクトを外部テーブルとして定義し、直接クエリを投げることが可能です。(2022 年 3 月現在、東京リージョン未対応) 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。当記事では、Google Cloud の容量無制限・低価格・堅牢なオブジェクトストレージサービスである Cloud Storage を解説します。各用語の意味や料金、セキュリティに関する仕様について解説します。 概要 Cloud Storage とは オブジェクトストレージとは 使い方 ユースケース 料金 Cloud Storage の料金の概要 料金体系 ストレージクラス 用語 バケット オブジェクト メタデータ パス フォルダ ロケーション（リージョン） 概要 選択基準 ターボレプリケーション リージョンエンドポイント ライフサイクルマネジメント Autoclass Autoclass とは バケット作成後の有効化 制約 ユースケース Autoclass の料金 オブジェクトの保護 Soft delete ポリシー バージョニング 保持ポリシー（Bucket Lock） オブジェクト保持保持（Object Retention Lock） 静的ウェブサイトホスティング アクセスログ 2つのログ取得手法 データアクセス監査ログ 使用状況ログとストレージログ セキュリティ アクセス制御（IAM と ACL） パブリック公開 パブリック公開の禁止 IP アドレス制限 2つの手法 VPC Service Controls バケット IP フィルタリング マネージドフォルダ 暗号化 署名付き URL 組織のポリシー パフォーマンスと整合性 基本的な仕様 Anywhere Cache オブジェクトの命名 整合性 階層名前空間 データレイク データレイクとしての Cloud Storage BigQuery や他サービス連携 オブジェクトコンテキスト データの転送 Storage Transfer Service クロスバケット レプリケーション 他サービスとの連携 イベントドリブン・アーキテクチャ VM や Cloud Run からのマウント 概要 Cloud Storage とは Cloud Storage は、Google Cloud（旧称 GCP）の容量無制限・低価格・堅牢なオブジェクトストレージサービスです。Google Cloud Storage を略して GCS とも呼称される場合もあります。 データは少なくとも 2 つ以上のゾーン（ゾーンは1つ以上のデータセンターで構成）にわたって冗長化されており、 99.999999999%（イレブンナイン） の堅牢性を保つよう設計されています。 Cloud Storage では、ストレージクラスと呼ばれる価格帯の違う4種類の保管タイプが利用でき、アクセス頻度によって使い分けます。 参考 : Cloud Storage のプロダクト概要 参考 : データの可用性と耐久性 参考 : Cloud Storage がイレブンナインの耐久性を実現する仕組みと、その効果を高める方法 オブジェクトストレージとは Cloud Storage は オブジェクトストレージ と呼ばれるタイプのストレージサービスです。他社の代表的なオブジェクトストレージとして、Amazon S3 が挙げられます。 オブジェクトストレージはパソコンやサーバから使われるような、ファイルシステム経由で読み書きされるストレージとは異なります。データは「オブジェクト」という単位で管理され、これが通常のファイルシステムでいう「ファイル」に相当します。 Cluod Storage においては、オブジェクトは Web API 経由で読み書き されます。 Cloud Storage API 使い方 利用者は以下のいずれかの方法で Cloud Storage を利用できます。 Google Cloud コンソール CLI ツール (gcloud / gsutil) Cloud SDK クライアントライブラリ Google Cloud コンソールでは、Web ブラウザ上で容易に Cloud Storage の操作が可能です。 標準のコンソール画面 大量のオブジェクトの処理をしたり、自動化を行うには CLI ツールを利用すると便利です。CLI ツールには gcloud と gsutil の2種類があります。 gcloud は Google Cloud サービス全般を操作することができるコマンドラインツールであり、後述の gsutil よりも処理が高速とされています。 参考 : Introducing gcloud storage: up to 94% faster data transfers for Cloud Storage 一方の gsutil は、gcloud コマンドが Cloud Storage に対応する以前からあったコマンドラインツールです。過去には Cloud Storage を操作するための唯一の CLI ツールでした。今後は、gsutil で利用できるすべての機能が gcloud コマンドに移行され、gcloud が推奨となります。 gcloud コマンドラインの利用方法は、以下の記事も参照してください。 blog.g-gen.co.jp ユースケース Cloud Storage は以下のような用途がユースケースとなります。 画像ファイル・動画ファイルなど、変更がなくサイズが大きいファイルの保存 頻繁にアクセスされないファイルのバックアップ データレイク（データ分析基盤） システム間のデータの受け渡し なお Cloud Storage は、限定的な用途であれば、サーバー等からマウントして擬似的なファイルシステムとして読み書きすることが可能です。「VM や Cloud Run からのマウント」の項を参照してください。 料金 Cloud Storage の料金の概要 Cloud Storage の特徴は、安価であることです。東京リージョンの Standard Storage のデータ保管料金は2025年12月現在、 $0.023（GB/月） です。概ね、1TB で3,500円程度と認識すれば良いでしょう。 最新の料金は、公式の料金ページを参照したり、公式の Google Cloud 料金試算ツールをご利用ください。 参考 : Cloud Storage pricing 参考 : Google Cloud's pricing calculator ただし Cloud Storage の料金はデータ保管のボリュームだけでなく、 API リクエストの回数など、複数の軸で課金されます。 また Cloud Storage の料金には ストレージクラス という重要な考慮事項があり、選択するクラスによって料金単価が異なります。 料金体系 Cloud Storage では、保管するデータのサイズに加えて、複数の軸で従量課金が発生します。 保管するデータのサイズ（GB/月） 書き込みオペレーション回数 読み取りオペレーション回数 ネットワーク利用 (ダウンロード方向のみ、 GB) 取り出し料金 (GB) これらの料金単価は、後述のストレージクラスごとに異なります。 ストレージクラス Cloud Storage には、 Standard / Nearline / Coldline / Archive という4つの ストレージクラス が存在します。右に行くほど長期保存、かつ取り出し頻度が少ないデータに適しています。 参考 : ストレージ クラス 右のストレージクラスほど GB あたりのデータ保管料金が安くなりますが、オペレーション回数あたりの料金や取り出し GB あたりの料金が高くなります。料金単価は以下のとおりです（2025年12月現在、東京リージョン）。 ストレージクラス 保管料金 (GB/月) 書き込みオペレーション (10,000回あたり) 読み取りオペレーション (10,000回あたり) データ取り出し量 (GB) 最低保管期間 Standard Storage $0.023 $0.05 $0.004 $0 なし Nearline Storage $0.016 $0.10 $0.01 $0.01 30 日 Coldline Storage $0.006 $0.10 $0.05 $0.02 90 日 Archive Storage $0.0025 $0.50 $0.50 $0.05 365 日 長期保管用のストレージクラスほど、データサイズあたりの料金は安い代わりに、取り出しにお金がかかることが分かります。 最低保管期間 （Minimum storage duration）が各ストレージクラスごとに定められており、保管したオブジェクトがこの日数以内に削除・置換・移動された場合、この日数分の保管料金が発生してしまいます（削除できない訳ではありません）。 ストレージクラスはバケット作成時に デフォルトストレージクラス として指定できます。バケットにオブジェクトが作成されるとデフォルトストレージクラスに従ってストレージクラスが設定されますが、オブジェクトごとに個別にクラスを指定することもできますし、後から変更も可能です。また、後述の Autoclass 機能により、利用状況にあわせて自動でクラスが移行されていくように設定することもできます。 なお全てのストレージクラスで、データ取り出し時のレイテンシは「最初のバイト転送開始まで数十ミリ秒程度」とされています。AWS の Amazon S3 等ではアーカイブレベルのストレージの取り出しには時間がかかる場合がありますが、Cloud Storage においてはどのストレージクラスでも迅速にデータを取り出すことができます。 用語 バケット Cloud Storage における バケット とは、データを入れるための箱であり、個々のオブジェクト（ファイル）を入れるためのグルーピングオブジェクトです。バケットの単位でアクセス制御をしたり、どのリージョンに配置するかを決めることができます。 バケットには全世界で一意となる名前を付ける必要があります。 なお bucket とは英語で「バケツ」を意味します。 参考 : Cloud Storage バケットについて オブジェクト オブジェクト とは、バケットに入れられた個々のファイルを指します。 Cloud Storage のようなオブジェクトストレージでは基本的に、オブジェクトを一度書き込むと 「変更」という概念はありません 。削除するか同名のオブジェクトで上書きすることになります。既に存在するオブジェクトを開いて編集し、1行足す、といったことはできません。これを行いたい場合、1行を足した新しいファイルで既存オブジェクトを上書きすることになります。 1つのオブジェクトの最大サイズは 5 TiB です。バケット内に格納できるオブジェクトの数に制限はありません。 参考 : Cloud Storage オブジェクトについて メタデータ オブジェクトには メタデータ という付加情報を付与できます。メタデータはキー・バリューのペアの文字列です。 例としてオブジェクトに Cache-Control:no-store のようにメタデータを付与すれば、オブジェクトを一般公開した際に、 HTTP レスポンスヘッダーに Cache-Control:no-store が付与されキャッシュ可否をコントロールできます。 Content-Type なども同様の使い方ができます。 上記のような HTTP ヘッダーに関連するメタデータのみならず、ユーザーが任意のキー・バリューを文字列として保存しておくことができます。 メタデータには 固定キーメタデータ （Fixed-key metadata）と カスタムメタデータ （Custom metadata）があります。以下にその概要を示します。 名称 意味 例 固定キーメタデータ デフォルトでキーが設定されているメタデータ。バリューは自由に指定 Cache-Control、Content-Type、Content-Language 等 カスタムメタデータ キーとバリューの両方を任意に設定できるメタデータ 任意 参考 : オブジェクトのメタデータ パス パス とは特定のオブジェクトを指し示す文字列です。見た目は Linux のパスと似ています。 Cloud Storage オブジェクトのパスは、 gs://my-bucket/my-folder/myobject のように表されます。先頭の gs:// は Cloud Storage のオブジェクトのパスであることを示す接頭辞です。 フォルダ フォルダ とは、バケットの中を区切るためのグルーピングオブジェクトであり、パソコンのフォルダと同じような意味を持ちます。 ユーザー目線ではあまり意識する必要はありませんが、Cloud Storage の内部的には、フォルダは実体としては存在していません。Cloud Storage は、内部構造としてはキーバリューストアであり、平坦な構成になっています。 gs://my-bucket/my-folder/my-object というオブジェクトがあるとき、 my-folder にはフォルダという実体はなく、単に my-object というオブジェクトの名前（パス）の一部です。Web コンソールや CLI ツールで空のフォルダを作ることができますが、実際には 0 バイトのオブジェクトが作成されるという挙動をしています。 参考 : Cloud Storage オブジェクトについて - オブジェクトの名前空間 フォルダ分けされているように見えるが実際にはフラットな構成 なお、後述のマネージドフォルダ機能を使うと、通常のフォルダとは異なり、より細かい権限管理を行うことができます。マネージドフォルダに対して、通常のフォルダのことをシミュレートされたフォルダ（Simulated folders）と呼びます。 ロケーション（リージョン） 概要 Cloud Storage では、バケット作成時に ロケーション を選択します。データは物理的に、選択したロケーションに保管されます。 ロケーションは「 単一リージョン 」「 デュアルリージョン 」「 マルチリージョン 」のタイプがあり、それぞれのタイプでリージョンを選択可能です。 例として単一リージョンには「asia-northeast1（東京）」や「asia-northeast2（大阪）」が、デュアルリージョンには「asia1（東京・大阪）」が、マルチリージョンには「asia（アジア圏複数リージョン）」が存在します。 参考 : バケットのロケーション 選択基準 たとえ単一リージョンを選んだ場合でも、リージョン内の複数のゾーンにデータは冗長化されており、99.999999999%（イレブンナイン）の年間耐久性を実現します。しかしデュアルリージョンまたはマルチリージョンを選ぶことで、リージョンレベルの障害、災害、事故、政変などのリスクにも対応し、可用性と冗長性を向上させることができます。ロケーションは、以下のような基準で選ぶと良いでしょう。 コスト効率と低いレイテンシを求める場合は 単一リージョン レイテンシを抑えつつ、単一リージョンより高い地理的冗長性と可用性）が必要な場合は デュアルリージョン 複数地域からのアクセスが想定されるか、複数リージョンでの冗長性を確保したい場合は マルチリージョン デュアルリージョンは、マルチリージョンよりもストレージ料金が高いですが、より広い帯域幅（リージョンごと 200 Gbps）を確保できることに加え、同一リージョンからのダウンロードにはアウトバウンド料金が発生しません。マルチリージョンはその反対に、保管料金が安い代わりに帯域幅がより狭く（リージョンごと 50 Gbps）、データ読み取りには必ずアウトバウンド料金が発生します。このようなトレードオフを理解して選択します。詳細は以下のドキュメントを参照してください。 参考 : バケットのロケーション - ロケーションに関する留意事項 ターボレプリケーション デュアルリージョンやマルチリージョンバケットにおいて、リージョン間のレプリケーションは、オブジェクトの書き込みが完了してから 非同期 で行われます。同期には数分からそれ以上の時間がかかることがあります。デフォルトの非同期レプリケーションでは、1時間以内に99.9%のオブジェクトが複製され、12時間以内に100%に達します。 これでは RPO（Recovery Point Objective）要件を満たせない場合、 ターボレプリケーション （Turbo replication）を有効化することで、15分以内に100%のデータを複製できます。 ターボレプリケーションには追加料金が発生します。また、ターボレプリケーションはデュアルリージョンのバケットでのみ利用可能です。 参考 : データの可用性と耐久性 参考 : クラウド インフラストラクチャの停止に対する障害復旧の設計 - Google Cloudでアプリケーションの障害復旧を設計するための設定ガイド リージョンエンドポイント リージョンエンドポイント （Regional endpoints）は、特定のリージョンにおける Cloud Storage バケット専用のエンドポイント URL です。リージョンエンドポイントを使うと、データが転送中と保管中の両方で、特定の地域内に留まることを保証でき、データレジデンシー（data residency）やデータ主権（data sovereignty）を担保することができます。 リージョンエンドポイントは https://storage.europe-west3.rep.googleapis.com のような形式です。この URL の場合、データが europe-west3 リージョン（ドイツのフランクフルトリージョン）を出ないことが保証されます。 このエンドポイントを使うと、読み書き等のオペレーション対象となるバケットが、対象リージョン外にある場合、オペレーションはエラーとなります。 利用するには、gcloud コマンドの場合は環境変数にエンドポイントを設定します。REST API の場合は、リクエスト先のエンドポイント URL をリージョナルエンドポイントにします。 参考 : リージョン エンドポイント ライフサイクルマネジメント ライフサイクルマネジメント 機能は、オブジェクト作成後の経過日数などに従い自動的にストレージクラスを変更したり、削除したりできる機能です。 例えば「デフォルトストレージクラスは Standard Storage だが、 120 日経過したオブジェクトは自動的に Coldline Storage に移動する。360 日経過したオブジェクトは削除する」といった指定が可能です。 ルールを設定するだけで自動適用されるため、ハウスキーピングのためのプログラムを書く必要がありません。この機能を賢く使うことで、料金を節約することにも繋がります。 ルールを適用する条件として「オブジェクト作成後の経過日数 ( Age )」「絶対日時以前に作成されたオブジェクト ( CreatedBefore )」「バージョニングで過去版になってからの日数 ( DaysSinceNoncurrentTime )」「特定の接頭辞/接尾辞を持つオブジェクト ( MatchesPrefix / MatchesSuffix )」など様々な条件が選択できます。 ライフサイクルルールはバケット単位で作成します。ルールはバケット内の全てのオブジェクトに適用されますが MatchesPrefix / MatchesSuffix ルールと組み合わせることで「特定のフォルダ配下のみ」「特定の拡張子のオブジェクトのみ」に適用することなども可能です。 参考 : オブジェクトのライフサイクル管理 Autoclass Autoclass とは Autoclass は、バケット内のオブジェクトのアクセスパターンに応じて、ストレージクラスを自動で振り分ける機能です。AWS の Amazon S3 における「Intelligent-Tiering」と類似する機能といえます。 Autoclass バケットの「デフォルトのストレージ クラス」を Autoclass に設定することで、バケット単位で有効化します。有効化されたバケットでは、以下のルールでオブジェクトのストレージクラスが自動的に管理されます。 新規に書き込まれたオブジェクトは Standard storage になる オブジェクトが上書きされると Standard storage に変更される 一度でもアクセス（読み込み）されたオブジェクトは Standard storage に変更される 30日間アクセスがないオブジェクトは Nearline storage に変更される 90日間アクセスがないオブジェクトは Coldline storage に変更される 365日間アクセスがないオブジェクトは Archive storage に変更される つまり、アクセス頻度が小さいオブジェクトほど、より安いストレージに自動的に移行してくれます。Autoclass 有効化時は、デフォルトだと Nearline への移行のみを行う設定になっており、Coldline や Archive への自動移行は明示的に有効化する必要があります。 参考 : Autoclass バケット作成後の有効化 以前は制約として、バケット作成時にのみ Autoclass を有効化でき、バケット作成後の有効化はできませんでしたが、2023年11月3日のアップデートで、バケットでいつでも Autoclass を有効化できるようになりました。 ただし 有効化時に料金が発生する ことにご注意ください。Autoclass 有効化時に Standard 以外のストレージに入っているオブジェクトには「早期削除料金」「データ取り出し料金」が発生するほか、全オブジェクトに対して Class A オペレーションの API コール料金が発生しますので、十分ご注意ください。 参考 : Cloud Storage pricing - Autoclass charges 制約 Autoclass 機能には、以下の制約が適用されます。 128KB未満の小さいファイルにはストレージクラス変更がされず、Standard のままとなる ただし128KB未満の小さいファイルには管理費用（後述）が適用されない ユースケース あるバケットで、アクセス頻度がオブジェクトによりまちまちであり、予測が難しい場合には、Autoclass を使うことでコスト最適化が可能な場合があります。 逆に、オブジェクトのアクセス頻度がある程度予測しやすかったり、あるいはほとんどのオブジェクトのサイズが128KB以下である場合、無効化のままのほうがコスト効率が良い可能性があります。 また後述のように、Autoclass では本来 Nearline、Coldline、Archive storage で発生する「早期削除料金」や「データ取り出し料金」が発生しません。これらのメリットを享受したい場合は、Autoclass が適しています。 Autoclass の料金 Autoclass を有効化すると、 管理費用 として 1,000 オブジェクトごとに月あたり $0.0025 の費用が発生します。 ただし特筆すべき点として、Autoclass を有効化したバケットでは Nearline、Coldline、Archive storage のオブジェクトを削除しても 最低保管期間料金が発生しません 。また、Nearline、Coldline、Archive storage で本来発生する データ取り出し料金も発生しません 。 また Autoclass により自動的に行われる、より cold なストレージクラスの移動には、オペレーション料金が発生しません。逆に hot なストレージへの移動については、Nearline -> Standard では料金が発生しませんが、Coldline -> Standard や Archive -> Standard では Class A オペレーションとしての課金が発生します。ただし、オペレーション料金の単価は、Standard のものが適用されます。 参考 : Autoclass - Pricing 参考 : Cloud Storage pricing - Autoclass charges なお2023年10月16日以前は、オペレーション課金に関連する課金体系は現在と異なっていました。詳細は以下を参考にしてください。 参考 : Cloud Storage release notes - July 17, 2023 オブジェクトの保護 Soft delete ポリシー Soft delete ポリシー とは、削除された Cloud Storage オブジェクトが、削除後も一定の期間保持され、期間内であれば復元可能となる設定です。日本語コンソールや日本語ドキュメントでは「削除（復元可能）ポリシー」と表記されますが、当記事ではよりわかりやすい Soft delete という用語を使用します。 Soft delete ポリシーはバケット単位で設定でき、デフォルトでは7日間に設定されています。この期間のうちは、オブジェクトを誤って削除しても復旧可能です。最長90日間、最短は0日間（オフ）です。 参考 : 削除（復元可能） Soft delete されたオブジェクトを復旧するには、 gcloud storage restore コマンドを使うか、Google Cloud コンソールを使ってリストア操作を行います。 参考 : 削除（復元可能）オブジェクトを使用する バージョニング オブジェクトには、 バージョニング を設定可能です。バケットごとに有効化できます。 バージョニングが有効化されている場合、オブジェクトを上書きすると、過去のバージョンとして指定した世代数だけ保管されます。削除も同様で、オブジェクトを削除しても、過去のバージョンとしてデータが残ります。最新のバージョンのオブジェクトは「 現行のバージョン 」、過去のバージョンは「 非現行のバージョン 」と呼ばれます。 非現行のバージョンは 現行のバージョンと同様に課金される ので、注意が必要です。 参考 : オブジェクトのバージョニング 非現行のバージョンとなったオブジェクトを削除するには、先に記述したオブジェクトライフサイクル機能を使って「非現行バージョンになってから 14 日経過後に完全に削除する」のように設定します。バージョニングとライフサイクルを組み合わせて利用する方法については、以下の記事も参照してください。 blog.g-gen.co.jp 保持ポリシー（Bucket Lock） 各種規制やコンプライアンス要件への対応のため 保持ポリシー （Bucket Lock）を設定することができます。 「保持ポリシー」をバケットに設定すると、設定した期間中、オブジェクトを削除したり更新 できなく なります。これによりログデータ等の改ざん・消去が不可能になります。このように「書き込み（新規追加）はできるが削除したり改ざんできない」「読み取りは可能」という状態を「write once, read many（WORM）」と呼び、監査ログ等の保持施策の原則です。 また「保持ポリシーのロック」を設定すると保持ポリシーを 永久に 解除できなくすることができます。ロックすると保持期間の 延長はできます が、逆に期間を短縮したり、ポリシーを削除できなくなります。 法的規制で保管が義務付けられているログデータ等の保管に役立つ一方、保持期間が満了するまでオブジェクトの削除や変更は一切できなくなりますので十分ご注意ください。 参考 : バケットロック オブジェクト保持保持（Object Retention Lock） 前述の保持ポリシーがバケット単位での設定であるのに対し、オブジェクト単位での設定である オブジェクト保持保持 （Object Retention Lock）を設定することも可能です。 「オブジェクト保持」をオブジェクトに対してに設定すると、設定した期間まで、オブジェクトを削除したり更新できなくなります。保持ポリシーより細かい粒度でログデータ等の改ざん・消去を防ぎ、法的規制への対応を可能にします。 さらに設定したオブジェクト保持期間に対する変更を防ぐためロック状態（Locked）にすることも可能です。ロック状態にすると、保持期間を延長することはできますが、設定を削除したり短縮することは二度とできなくなります。 バケット単位の保持ポリシーとの併用が可能で、併用する場合は両方の期限が満了するまでオブジェクトが保持されます。 参考 : オブジェクト保持ロック 静的ウェブサイトホスティング Cloud Storage に配置した HTML ファイル等をインターネット公開することで、ウェブサイトのホスティングをすることができます。 HTML ファイルを配置し、先に記述したパブリック公開にすることで https://storage.googleapis.com/(BUCKET_NAME)/(OBJECT_NAME) という URL が払い出されます。 また Cloud Load Balancing の外部アプリケーションロードバランサーと組み合わせることで、カスタムドメイン名 + TLS 証明書でサイトを公開することが可能です。 詳細な手順は、以下の公式ドキュメントを参照してください。 参考 : 静的ウェブサイトをホストする 静的ウェブサイトホスティング アクセスログ 2つのログ取得手法 Cloud Storage バケットへのアクセスログを取得したい場合、以下の2つの方法が考えられます。 Cloud Audit Logs のデータアクセス監査ログを有効化する 使用状況ログとストレージログを有効化する データアクセス監査ログ Cloud Audit Logs の データアクセス監査ログ は、Google Cloud の監査ログを追加で有効化する方法です。アクセス時刻、プリンシパル（アクセスしたユーザー）、リクエストの詳細などが記録されます。ログは Cloud Logging に出力され、ログエクスプローラで閲覧可能です。 詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 使用状況ログとストレージログ 使用状況ログとストレージログ は、Cloud Storage 独自のログをバケットごとに有効化できる機能です。監査ログと比較して、インターネット公開のオブジェクトのアクセスログも追えること、レイテンシに関する情報、リクエストやレスポンスのサイズの情報などが記録されます。 ログは CSV 形式で、ロギング対象のバケットとは別の Cloud Storage バケットに出力されます。詳細な利用状況を記録したい場合には、こちらを選択します。 参考 : 使用状況ログとストレージログ セキュリティ アクセス制御（IAM と ACL） Cloud Storage のセキュリティにおいて、最も重要なのはアクセス制御の仕組みです。 参考 : アクセス制御の概要 バケットのアクセス制御設定には、「均一（Uniform）」と「きめ細かい管理（Fine-grained）」があり、バケットごとに選択できます。可能な限り前者の均一（Uniform）を利用することが推奨されています。前者の均一（Uniform）はバケットレベルで IAM （Identity and Access Management）を使って制御します。後者のきめ細かい管理（Fine-grained）はオブジェクトごとに ACL を使って制御します。 きめ細かい管理（Fine-grained）は Amazon S3 との相互運用性のために用意された機能ですが、細かいオブジェクトごとの権限管理は煩雑であり、運用工数が高くなるおそれがあります。これが、前者の均一（Uniform）管理が推奨される理由です。 このことから、バケットは「アクセス権限のユースケースごと」に作成し、そのうえでバケットごとに権限管理をすることが望ましいといえます。 また Google Cloud の IAM の基本的な仕組みについては以下の記事で詳細に解説していますので、ご参照ください。 blog.g-gen.co.jp パブリック公開 Cloud Storage のオブジェクトは、パブリック公開設定にすることでインターネットのどこからでもアクセスできるように設定できます。 パブリック公開されたデータへアクセスする方法は以下のようなものがあります。 URI（ https://storage.googleapis.com/(BUCKET_NAME)/(OBJECT_NAME) ） Google Cloud コンソール Google Cloud CLI（gsutil、gcloud） パブリック公開の禁止 意図しないバケットやオブジェクトに、誤ってパブリック公開設定をしないように注意が必要です。 Cloud Storage では、バケット単位で パブリック公開の禁止 （public access prevention）を設定することができます。設定すると、オブジェクト個別の設定に関わらず、オブジェクトへのアクセスには Google アカウントによる認証が必須になります。つまり、オブジェクトのインターネット公開を防ぐことができます。 参考 : 公開アクセスを防止する Cloud Storage で意図しないデータ漏洩を防ぐには、以下のようにバケットを使用します。 「インターネットに公開するオブジェクト」と「公開しないオブジェクト」を、同じバケットに混在させない インターネット公開の可能性がないバケットでは、パブリック公開の禁止設定を有効化する IP アドレス制限 2つの手法 基本的に、Cloud Storage をはじめとするパブリッククラウドサービスは、API エンドポイントがインターネットに公開されている状態であり、従来型の IP アドレス制御等（境界型セキュリティ） ではなく 、IAM などの認証・認可の仕組みでセキュリティを担保するのが原則です。 接続元 IP アドレス制限を設定すると、運用の煩雑化やアクセス権限管理の軽視につながるおそれもあることから、 本当に接続元 IP アドレス制限が必要かどうか慎重に検討 することが推奨されます。 しかしながら、Cloud Storage では以下の2つの方法のいずれかで、接続元 IP アドレス制限を実現できます。 VPC Service Controls バケット IP フィルタリング VPC Service Controls 前者の VPC Service Controls は、Google Cloud API 全般に対して、接続元 IP アドレス、接続元 VPC やデバイスポリシーなどに基づいたアクセス制御を設定するための Google Cloud サービスです。詳細は以下の記事をご参照ください。 blog.g-gen.co.jp バケット IP フィルタリング 後者の バケット IP フィルタリング （Bucket IP filtering）は、Cloud Storage に備え付けの接続元 IP 制限の仕組みです。VPC Service Controls と同様に、接続元 IP アドレスや接続元 VPC を制限できます。相違点は、バケット単位での設定が可能な点、またデバイスポリシーに基づいた制御機能は存在していない点です。 注意点として、バケットで IP フィルタリングを有効化すると、Cloud Storage から BigQuery へのデータロードや外部テーブルの読み込みなど、一部の機能が使用できなくなります。このような機能を使っている場合で接続元の制御がしたいときは、VPC Service Controls の使用を検討してください。詳細は以下の公式ドキュメントを参照してください。 参考 : バケット IP フィルタリング マネージドフォルダ Cloud Storage バケットの内部にはフォルダを作成することができます。通常の手順でフォルダを作成すると、そのフォルダは シミュレートされたフォルダ （Simulated folders）という種類になります。シミュレートされたフォルダは、 マネージドフォルダ にアップデートすることが可能です。 マネージドフォルダでは、フォルダ単位での IAM 権限管理ができ、よりきめ細かい権限管理が可能です。より詳細な内容は、以下の記事をご参照ください。 blog.g-gen.co.jp 暗号化 Cloud Storage に保管されるデータは、デフォルトで、自動的に暗号化されます。 参考 : データ暗号化オプション デフォルトの自動的な暗号化はストレージレベルの暗号化であり、利用者からは透過的に行われるため、意識されることはありません。 透過的な暗号化は、Google の内部犯行や物理的な盗難などに効果を発揮するものであり、 不正アクセスに対抗できるものではない ことに注意が必要です。 この暗号化は Google が管理する鍵で行われますが、各種規定や監査への対応のため必要であれば利用者側の提供する鍵で暗号化をすることもできます。 その場合、 Cloud KMS を用いて鍵を管理する Customer-managed encryption key という方法のほか、Cloud Storage API へのリクエストの度に鍵を指定する Customer-supplied encryption key という方法があります。 いずれも利用者側で 暗号化鍵を運用するという運用負荷 が発生しますので、本当に必要なときにのみ検討するべきです。 署名付き URL 署名付き URL （signed URL）機能を使うことで、英数字の署名トークン付きの URL を知っている人がアクセスできる、時間制限付きの URL を発行することができます。 クエリ文字列内に認証情報が入っているため、制限時間内であれば、 URL を知っている人であれば誰でも アクセスできます。 Google アカウントやサービスアカウントによる認証が使えない場面で、限定的なアクセス（オブジェクトのアップロードやダウンロード）を提供したいときに利用します。 署名付き URL は、以下のようなフォーマットになります。 https://storage.googleapis.com/example-bucket/cat.jpeg?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6 (中略) c56c5ca81ff3447032ea7abedc098d2eb14a7 署名付き URL は gsutil コマンド や各プログラミング言語の Google authentication library などを用いて生成することができます。生成する際は、Google アカウント等による認証が必要です。 参考 : 署名付き URL 組織のポリシー 組織のポリシー 機能を使うことで、同じ 組織 （Organization）に所属している全ての Google Cloud プロジェクトで Cloud Storage の設定を強制することができます。 例えば、パブリックアクセスを組織配下の全ての Cloud Storage バケットで禁止する、などの統制が可能です。 Cloud Storage に対して使える組織のポリシーは他にも複数あり、以下の公式ドキュメントにリストされています。 参考 : Cloud Storage の組織のポリシーに関する制約 組織のポリシー機能の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp パフォーマンスと整合性 基本的な仕様 Cloud Storage はフルマネージドなサーバーレスサービスです。原則として、他のユーザーと物理リソースを共用するマルチテナントのサービスです。 特定のバケットのアクセス負荷が上昇すると、Cloud Storage は自動スケーリングを行い、複数サーバーにリクエストを分散します。 詳細な仕様は、以下のドキュメントを参照してください。 参考 : リクエスト レートとアクセス分散のガイドライン Anywhere Cache Anywhere Cache は、Cloud Storage バケットに付与できる、ゾーンベースのキャッシュ機構です。ゾーンにキャッシュを作成することで、レイテンシの短縮や、マルチリージョンバケットの場合のリージョン間データ転送料金の節約に役立ちます。 ただし、キャッシュを使えるのは、キャッシュと同じゾーンの Compute Engine VM のみです。Compute Engine VM から Cloud Storage バケットへの頻繁なアクセスがある場合に、Anywhere Cache の利用を検討します。特に、機械学習モデルのトレーニングやデータ分析など、データの更新は少なく読み取りが多いワークロードに適しています。 Anywhere Cache の詳細な仕様は、以下の公式ドキュメントを参照してください。 参考 : Anywhere Cache オブジェクトの命名 Cloud Storage は分散アーキテクチャであり、バックエンドには複数のサーバーがあります。またオブジェクト名などを管理するインデックスは辞書順に並び替えられており、分散管理されています。このインデックスの読み書き時の負荷分散には、オブジェクト名（パス）が使われます。 もし、オブジェクト名が以下のように連続的だと、負荷分散がされずに同一のインデックス範囲がアクセスされ続けてしまい、負荷分散ができないため、 同時大量リクエストの際にパフォーマンスが低下 します。 /2022-03-18-19-24-00/access_log.txt /2022-03-18-19-24-01/access_log.txt /2022-03-18-19-24-02/access_log.txt 同時大量リクエストがありえる場合は、以下のように オブジェクト名の最初にランダムな文字列を付与 することで、パフォーマンスを向上できます。例として、MD5 でオブジェクト名をハッシュ化して最初の6文字を取る方法などがあります。 /q84ic3-f2022-03-18-19-24-00/access_log.txt /zbfg9t-2022-03-18-19-24-01/access_log.txt /2w99uk-2022-03-18-19-24-02/access_log.txt 参考 : リクエスト レートとアクセス分散のガイドライン - 命名規則を使って負荷をキーの範囲に均等に分散する 整合性 Cloud Storage は分散アーキテクチャのストレージですが、書き込みや削除の後の読み取りオペレーションは 強整合性 で実現されています。 整合性 とは、ストレージやデータベースにおいて、書き込み処理が完了をした後に読み取りをした場合に、いつの時点のデータが読み取られるかを示す概念です。 分散アーキテクチャのストレージでは、書き込みオペレーションが完了した後でも、その書き込み内容が全ての分散ノードに複製されるまでの間、書き込みオペレーション実行前の古い情報が読み取られる可能性があり、一定の時間が経ってから整合性が取られる可能性があります。このような整合性の性質は、 結果整合性 と呼ばれます。 一方で、ある書き込みオペレーションが完了した後に読み取りオペレーションを実行した場合に、その書き込み内容が必ず読み取られる場合、その性質は 強整合性 といいます。Cloud Storage は、オブジェクトの書き込み後の読み取りや削除後の読み取りなど、ほとんどのオペレーションでグローバルな強整合性を実現しています。 ただし、アクセス制御設定の変更など一部のオペレーションは、結果整合性です。設定変更後、適用されるまで1分〜数分程度の時間がかかる場合があります。 参考 : Cloud Storage の整合性 階層名前空間 階層名前空間 （Hierarchical namespace）は、Cloud Storage でファイルシステムライクな階層構造、すなわちフォルダによるオブジェクト整理を定義することで、パフォーマンス向上を図る機能です。主に以下のようなユースケースで設定します。 Hadoop、Spark から Cloud Storage コネクタ等で接続してオブジェクトへアクセスするとき バッチ分析処理、HPC などからオブジェクトへアクセスするとき TensorFlow、Pandas、PyTorch などの AI/ML フレームワークからオブジェクトへアクセスするとき 上記のようなワークロードにおいては、階層名前空間を使用することで、オブジェクトの管理や検索が最適化されたり、ファイルやフォルダの名前変更のようなファイルシステムライクな処理が最適化されることで、パフォーマンスが向上する可能性があります。 階層名前空間の有効化は、バケット作成時に指定する必要があります。なお有効化すると、保持ポリシー（Bucket Lock）やクロスバケット レプリケーション、バージョニングなど多くの機能が使用できなくなる点に留意してください。詳細は以下のドキュメントを確認してください。 参考 : 階層名前空間 データレイク データレイクとしての Cloud Storage 東京リージョンの BigQuery のストレージ料金は、Active ストレージが $0.023/GB 、Long-term ストレージが $0.016 です。これは東京リージョンの Cloud Storage のストレージ価格が、Standard で $0.023、Nearline で $0.016 であるのと一致しています（いずれも 2025年12月現在）。 参考 : BigQuery pricing 参考 : Cloud Storage pricing このことから Google Cloud では データレイク用のストレージ として （半）構造化データは BigQuery に保管 、 非構造化データは Cloud Storage に保管 、という使い分けをすることが多いといえます。 これは AWS において「データレイクは Amazon S3 、データウェアハウスに Amazon Redshift」という使い方をするのとは、少し異なっています。始めから構造化データをデータウェアハウスである BigQuery に入れておくことで、データの移送が不要になります。 BigQuery や他サービス連携 Cloud Storage は BigQuery との連携の面でも優れています。 Cloud Storage オブジェクトとして配置した CSV、JSON、Avro、ORC、Parque 等のファイルを、 BigQuery のテーブルにロード（読み込み）することができます。例として以下のような方法があります。 BigQuery の既存テーブルに Cloud Storage オブジェクトをロード BigQuery のテーブル作成時に元ファイルとして Cloud Storage オブジェクトを指定 BigQuery Data Transfer Service で自動ジョブを作成 また BigQuery から 外部テーブル定義 を行うことで、直接 Cloud Storage オブジェクトに対してクエリをかけることも可能です。 オブジェクトコンテキスト オブジェクトコンテキスト （Object contexts）は、オブジェクトにコンテキスト情報（背景情報）を添付して、データの管理や検出に役立てる機能です。オブジェクトコンテキストでは、Cloud Storage オブジェクトに文字列をキー・バリューのペアとして付与できます。 参考 : オブジェクト コンテキスト 文字列をキー・バリューで保存できる点ではオブジェクトメタデータと同様ですが、オブジェクトコンテキストの場合は、コンテキスト情報の追加、変更、削除に対する独自の IAM 権限が存在している点が異なります。オブジェクトメタデータの読み取り・書き込み権限は、オブジェクトそのものの権限と同一です。一方のオブジェクトコンテキストには、専用の IAM 権限が用意されています。これにより、オブジェクトのデータそのものと、オブジェクトコンテキストで、それぞれ別々の管理者を当てられることになります。 オブジェクトコンテキストのユースケースとして、以下のようなものが挙げられます。 個人識別情報（PII）を含むオブジェクトの明示 ワークフローの状態の追跡（ レビュー待ち 、 承認済み 等） アプリケーションから使用する付加情報 データの転送 Storage Transfer Service Cloud Storage の関連サービスとして、 Storage Transfer Service があります。Storage Transfer Service を使うと、Amazon S3 やファイルシステムなどの様々なデータソースから、ファイルを Cloud Storage に対して転送できます。 ジョブを設定することで、ファイル数やデータ量が大量の場合に、効率的なデータ転送を行うことができます。 参考 : Storage Transfer Service また Amazon S3 からの転送の際にオプションで Google が管理するプライベート ネットワーク を有効化すると、AWS からのネットワーク転送料金が発生せずに、代わりに Google Cloud 側の料金が発生します。これにより、安価な転送料金で Amazon S3 から Cloud Storage へのデータ転送を実現できます。 参考 : Amazon S3 から Cloud Storage への転送 - 下り（外向き）オプション クロスバケット レプリケーション クロスバケット レプリケーション （cross-bucket replication）機能を使うと、あるバケットに作成された新しいオブジェクトや更新されたオブジェクトを、非同期に別のバケットに複製できます。 この機能のバックエンドでは、Storage Transfer Service が使われています。 参考 : データの可用性と耐久性 - クロスバケット レプリケーション 他サービスとの連携 イベントドリブン・アーキテクチャ 新しいオブジェクトが作成されたときや削除されたときなど、対応しているイベントが発生した際に、 Cloud Pub/Sub に通知したり、 Cloud Run functions を起動することができます。 参考 : Cloud Storage の Pub/Sub 通知 これにより、例えば以下のような処理が可能になります。 ユーザーがアプリケーションを通じて画像ファイルを Cloud Storage にアップロード（= オブジェクト作成） オブジェクト作成をトリガーにして Eventarc が起動。Pub/Sub にメッセージが投入される Cloud Run が Pub/Sub メッセージを読み取り、画像をサムネイル化して別の Cloud Storage バケットに配置 このように、オブジェクトの作成など何らかのイベントをトリガに処理が走る構成を、 イベントドリブン・アーキテクチャ と呼びます。 このイベントドリブンの考え方は、サーバーレス、従量課金、疎結合といった利点が活用できるため、クラウドのメリットを最大限享受できる方法の1つです。 イベントドリブンな処理 VM や Cloud Run からのマウント Cloud Storage FUSE を使うと、Linux や macOS へ Cloud Storage バケットをマウントすることができます。 Cloud Storage は、本来は Web API で読み書きをする仕組みです。Cloud Storage FUSE は、OS からファイルシステムライクにバケットにアクセスできるよう、システムコールを Cloud Storage への API リクエストへ書き換えてリクエストします。よって Cloud Storage FUSE が適しているのは、レイテンシが比較的大きくても構わない、かつアクセス頻度が多すぎないという限定的な条件の場合であり、利用に当たっては十分な検証が必要です。 参考 : Cloud Storage FUSE また同じ仕組みを用いて、Cloud Run の services や jobs で、ボリュームとして Cloud Storage バケットをマウントすることができます。ファイルの読み書きの際、ステージング領域としてメモリを利用するため、コンテナインスタンスのメモリ量等に注意が必要です。 参考 : Cloud Run サービスに対して Cloud Storage のボリューム マウントを構成する 参考 : ジョブの Cloud Storage ボリュームのマウントを構成する Cloud Run からの Cloud Storage バケットのマウントについては、以下の記事も参照して下さい。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genのすずたつです。 当記事では、Google Workspaceの利用ログを集計するためにBigQuery Exportを利用しようとしたところハマってしまった件について解説いたします。 Google WorkspaceのBigQuery Exportとは Google WorkspaceのBigQuery Exportの設定方法 データセット作成 BigQuery Export有効化 Exportされない Exportがされない理由と対応方法 Google WorkspaceのBigQuery Exportとは まずはGoogle WorkspaceにおけるBigQuery Exportはどのような機能なのでしょうか？ こちらは、一言でいうとGoogle Workspaceの日々のログデータをすべてGoogle CloudのBigQuery にExportし、可視化、分析できるような連携のための機能になります。 利用用途としては以下のように解説記事がありますので、ぜひ参考にしてみてください。 japan.zdnet.com Google Workspaceを利用中の社員がどのような働き方を実施しているのか。を可視化するためには便利な機能であると考えます。 例えばいまの時期ですと、社員がどのくらいMeetを利用しているか。や、どこから働いているのか。など、ログ情報をもとにそういった情報を集計、分析することが可能となります。 さて今回、せっかくなのでG-genでも実施してみよう。ということで、実際に本機能を利用してみようとしたところハマってしまった。という点に関して、簡単に説明していきたいと想います。 Google WorkspaceのBigQuery Exportの設定方法 まずは簡単に設定方法に関して説明いたします。BigQuery Exportの設定に関してはいたってシンプルです。 (1)Google Cloud BigQueryに入れ物となるデータセットを用意する。 (2)Google Workspaceの管理者設定において、上記(1)で作成したデータセットに対してExportを有効化する。 この2点になります。至ってシンプルですね。いまのところ、どこにもハマる要素はないですね。 データセット作成 詳細の説明は省きますが、まずはGoogle CloudのBigQueryの画面にてデータセットを作成いたします。 以下のような形で作成が完了しております。 データセットの作成 BigQuery Export有効化 こちらも実際の設定はものすごくシンプルで、管理者ユーザーでログイン後の画面にて 「レポート＞BigQuery Export」にて、BigQueryのプロジェクトIDおよびデータセットの名前を指定して終了。 Google Workspace 管理者設定画面 これでGoogleからの正式回答によると、以下とのことなので数日待てば確実にExportされていることでしょう。 一般的なご案内としまして管理コンソール上での設定が反映されるまで最大 24 時間かかる場合がございます。また、データが生成されるのは太平洋時間の日時となることから、エクスポートにお時間がかかっていた可能性がございます。 Exportされない 片手間に検証してしまっていた。というのもあるのですが、待てども待てどもExportされない。ログがみれない。という状況になってしまいました。 ということで一旦Googleのサポートに問い合わせを実施。様々なやりとりの結果・・・(事項に続く) Exportがされない理由と対応方法 いくつかのやりとりの結果、以下のGoogle CloudのBigQueryにおいて データセットを”asia-northeast1”に指定してしまっていることが原因 だということがわかりました。 データセットのロケーション 日本人だとやりがちな気がしますが、正式回答としては ロケーションを EU、US といった、マルチリージョンを指定いただく必要がある ということのようで、どおりで待っても待ってもExportされない。。。という状況だったようです。 いくつかGoogleサポートより有益なURLをいただきましたので共有いたします。 ※とはいえEU、USという記載はどこにも無い気がしますが。。。 バケットの移動と名前変更 | Cloud Storage | Google Cloud https://cloud.google.com/storage/docs/moving-buckets データの保存場所であるリージョンにつきましては、下記ページをご参考いただけます。 バケットの保存場所 | Cloud Storage | Google Cloud https://cloud.google.com/storage/docs/locations#available-locations なお、本件の BigQuery Export に関してご参考いただけるヘルプ記事は下記となります。 BigQuery プロジェクトをログレポート用に設定する - Google Workspace 管理者 ヘルプ https://support.google.com/a/answer/9082756?hl=ja サービスログの BigQuery への書き出しを設定する - Google Workspace 管理者 ヘルプ https://support.google.com/a/answer/9079365?hl=ja BigQuery側のデータセットを作成し直したところ以下のように正しくExportされ、これでようやく分析可能となりました。 正しくExportされたあとの画面 今回は正しくExportできた。というところまでにしますが、以下のようにGoogle Workspaceでは様々な方法でログの解析が可能ですので、ぜひ試してみてはいかがでしょうか。 blog.g-gen.co.jp 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-genの杉村です。 Professional Cloud Network Engineer は Google Cloud (旧称 GCP) のプロフェッショナルレベルの認定資格の一つです。　Google Cloud のネットワーク系サービスや専用線・ VPN 等に関する高度な知識を確認する難関試験です。 当記事では合格に役立つ Tips、勉強方法、 出題傾向等をご紹介いたします。 Professional Cloud Network Engineer 試験について 概要 難易度 勉強方法 持つべきネットワーク基礎知識 持つべき Google Cloud 知識 VPC ハブアンドスポーク型トポロジ カスタムルート広報とピアリング VPC 間の推移的ピアリング 参考情報 VPC Firewall Firewall の基本とベストプラクティス gcloud による設定 Firewall Policy Shared VPC Cloud Router Monitoring Packet Mirroring Firewall Logging Cloud NAT Cloud Load Balancing VPC Service Controls Cloud Interconnect Dedicated Interconnect Partner Interconnect トポロジ L2 と L3 適切な Interconnect の選択 Direct Peering / Carrier Peering Cloud VPN BGP セッション 組織のポリシー Cloud DNS inbound policy forwarding zone DNS Peering Cloud Armor Network Intelligence Center Connectivity Tests Firewall Insights Professional Cloud Network Engineer 試験について 概要 Professional Cloud Network Engineer 試験では Google Cloud のネットワーク系サービスや専用線・ VPN 等に関する知識が問われます。 試験問題は50問、試験時間は120分です。2023年7月現在、当試験は英語版と日本語版が提供されています（従来は英語版しかありませんでしたが、2023年7月に日本語版がリリースされました）。 当試験では問題文が長く、複雑なネットワーク構成が説明されるため、ネットワーク設計に慣れていないと読み解きに時間がかかることが想定されます。構成図で説明してくれるような問題は無く、問題文をしっかり読み解く必要があります。 参考 : Professional Cloud Network Engineer 難易度 Professional Cloud Network Engineer 試験の難易度は、 中〜高程度 だと言えます。 VPC を中心に、Google Cloud のネットワークの仕様に関する深い知識が問われます。特に、専用線や Cloud VPN を使用したり、VPC Network Peering で複数の VPC Network を接続する際の、ルーティングの仕様が細かく問われます。また、Cloud DNS を複数の VPC から、あるいはオンプレミスから利用するなどの特別なユースケースに関する問題も問われます。 公式の試験要項には「業界経験が 3 年以上（Google Cloud を使用したソリューションの設計と管理の経験 1 年以上を含む）。」という要件が記載されていますが、必ずしもここまでの経験は必要ありません。 Google Cloud に関する Professional Cloud Architect 程度の知見に加えて、一般的なネットワーク技術の知見、特にルーティングやファイアウォールに関する知識を持っていることが望ましいです。とはいえ、Google Cloud の VPC は独特の仕様を持っていますので、一般的な知識に加えて、Google Cloud 特有のネットワーク仕様をしっかりと学んでおく必要があります。 勉強方法 推奨の勉強方法は、以下となります。 試験ガイド を読む 試験ガイドで把握した試験範囲について勉強する この際 Google Cloud に限らない一般的なネットワーク知識についても穴埋めをする 模擬試験 を受ける 当記事を読み、出題傾向を把握し、知らない知識を穴埋めする 特に VPC や Cloud VPN などは、Google Cloud の検証環境があれば、実際に構築してみることをお勧めします。コンソールの構築画面や CLI のコマンド構造を見ることで、Google Cloud のリソース構成が直感的に理解できるため、理解が飛躍的に進みます。 ルーティングや Cloud DNS、Cloud Interconnect などについては、以下の書籍が設計要素などについて詳しく解説しており、オススメです。 参考 : エンタープライズのためのGoogle Cloud 〜 クラウドを活用したシステムの構築と運用 持つべきネットワーク基礎知識 まず、この試験の出題内容を適切に理解するには、Google Cloud の知識以前に、一般的なネットワーク用語（特に L3 〜 L4 レイヤ）を理解している必要があります。もし以下のような用語の概要を理解していない場合、まずはそこから学習することを強く推奨します。 TCP/IP 参照モデル、OSI 参照モデル、TCP、UDP、IP、パケット、フレーム ルーター、ルーティング、ルート（経路）、ルート広報（Advertisement）、ネクストホップ ネットワーク、サブネット、VLAN ルーティングプロトコル、BGP、AS 番号（ASN） ファイアウォール、ステートフルインスペクション、ステートレスインスペクション、L3/L4 レイヤネットワークセキュリティ Web Application Firewall（WAF）、IPS/IDS、L7 レイヤネットワークセキュリティ NAT（Network Address Translation） ロードバランシング HTTP、HTTPS、SSL/TLS、証明書、非対称暗号化 専用線、インターネット VPN、IPSec DNS、ドメインツリー、権威 DNS サーバー、ゾーン、ゾーンフォワーディング 持つべき Google Cloud 知識 VPC のルーティングや専用線、 Cloud DNS に関する問題が非常に多く出題されます。「Google Cloud のネットワーク設計の際に、適切なトポロジを選択できるか」「可用性とセキュリティを考慮した設計ができるか」「実運用時のトラブルに対処できるか」といった観点の出題が多いです。 出題範囲は、以下のような Google Cloud サービスです。 VPC Routing Firewall Shared VPC Packet Mirroring Cloud Router Cloud NAT Cloud Load Balancing VPC Service Controls Dedicated / Partner Interconnect Cloud VPN Cloud DNS Cloud Armor Network Intelligence Center 本記事ではこれ以降、試験合格のために「具体的に何を知っているべきか」について細かく記述します。試験の利用規約の関係上、具体的な出題内容はご紹介できませんが、当記事が試験合格のための参考になれば幸いです。 VPC ハブアンドスポーク型トポロジ カスタムルート広報とピアリング VPC Peering や Cloud VPN を駆使した複雑なネットワーク構成について問われる問題が多く出題されます。 なかでも Hub-and-Spoke 型 (スター型とも呼ばれる) のネットワークトポロジに関する問題が頻出です。以下に例を挙げます。 Hub-VPC を中心としたネットワーク このネットワークは VPC (A) をハブとして、オンプレミスサイト、 VPC (B) 、 VPC (C) と接続されています。VPC (A) と オンプレミスは Cloud VPN (IPSec VPN) で接続されており、 VPC 間は VPC Peering で接続されています。 このとき、Cloud Router や VPC Peering がデフォルトの設定のままだと、「オンプレミスから VPC (B) へ」といったハブ VPC を経由した通信は できず 、直接接続されているネットワーク間のみでしか通信できません。 しかし、適切に設定しさえすれば、図右下の表のように相互にネットワーク間通信が実現できます。設定内容は、以下のとおりです。 Cloud Router にてオンプレミスの対向ルーターに広報するルートを 明示的に設定 する デフォルトだと Cloud Router が紐づいている VPC (A) のサブネットの CIDR しか広報されない Peering で繋がっている VPC (B) と (C) のルートも追加で広報するよう、明示的に設定 VPC (A) 側の 2 つある Peering 設定にてカスタムルートを エクスポートするよう設定 する これにより対向である VPC (B) および (C) にカスタムルート (オンプレから受け取った 10.0.0.0/8 のルート) を渡せる VPC (B) および (C) の Peering 設定にて対向である 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 (B) と (C) 同士の通信ですが、これは VPC Peering で繋がった VPC を経由して通信をする 推移的ピアリング と呼ばれる形になり、 VPC ではこの通信が できない仕様 になっています。これは AWS の VPC Peering でも同様で、「2 ホップ制限」とも呼ばれています。 VPC Peering では 直接繋がっている VPC 間でしか通信できない と覚えておきましょう。 VPC (B) と (C) を通信させたい場合は、これらを 直接、VPC Peering で繋ぐ 必要があります。つまり VPC Peering で複数の VPC 間通信を実現したい場合、接続は フルメッシュ になります。フルメッシュ構成ではネットワークの数を n とすると n * (n-1) / 2 の数の Peering を作成することになります。 しかし、そのようなフルメッシュ構成は複雑性を高め、運用性を下げるため、これを避ける方法もあります。それは VPC 間を Peering ではなく、 Cloud VPN で接続する ことです。 Cloud VPN で繋がっていれば、先程の図でオンプレミスと行ったのと同じように経路の交換ができますので、ハブ VPC を中心としたトポロジで VPC 間通信をさせることができます。 Cloud VPN には 利用料金 がかかってしまうため、実際の設計ではコストと運用性のトレードオフを検討することになります。 参考情報 Google Cloud のルーティングに関する詳細は、以下の記事もご参照ください。 medium.com blog.g-gen.co.jp VPC Firewall Firewall の基本とベストプラクティス VPC Firewall Rules の仕組みを問う問題が出題されます。ステートフルインスペクションや Ingress、 Egress、 ターゲット、ネットワークタグ、サービスアカウントの概念が分かれば解けるものとなっています。 Google Cloud のベストプラクティスとして、 VPC Firewall で VM 間通信を制御する際は、ネットワークタグよりもサービスアカウントを利用することが 推奨 されています。このようなベストプラクティスも押さえておく必要があります。 ネットワークタグは VM に対する管理権限 ( Compute Instance Admin ロール等 ) を持っていれば編集ができてしまうのに対し、サービスアカウントはサービスアカウントごと個別に IAM でアクセス制御ができるため、インスタンス管理者がネットワーク管理者の許可なく、禁止されている通信を可能にしてしまう、ということを抑止することができます。これがポイントとされる問題も出題されます。 gcloud による設定 gcloud compute firewall-rules create コマンド ( Reference ) を使って適切にファイアウォールを設定した経験があるか、問われる問題もあります。 例えば、 --direction オプションを省略するとデフォルト値は INGRESS になるなど、ある程度細かい仕様も押さえておく必要があるかもしれません。 Firewall Policy Firewall Policy の継承、評価順、goto_next などを理解していれば解ける問題も出題されます。 上位リソースにアタッチされた Firewall Policy がどのように下位リソースに渡って評価されるか、 ドキュメント で確認しておきましょう。 Shared VPC ネットワークを IT 管理者が中央管理し、各ユーザー部門の開発部隊にそれを使わせたい、といったときに Shared VPC が活躍します。 Host project や Service projects といった言葉など、基本的な概念をドキュメントで押さえておきましょう。 細かいところでは、Shared VPC の IAM に関する出題があります。 Shared VPC Admin というロールがありますが、これは組織レベルもしくはフォルダレベルにアタッチする必要があることに注意が必要です。 Shared VPC Admin がサブネットリソースに Network User ロール (Service Project Admin として言及されることも) を付与することで、利用者側は自分の VM 等を共有されたサブネットに配置することができるようになります。 このあたりは一度、実際にコンソール等で構築をしてみると分かりやすいでしょう。 Cloud Router Cloud Router の以下のような仕様を知っておく必要があります。 Cloud Router は特定のリージョンに紐づくリージョンリソースである Cloud Router は特定の VPC ネットワークに紐づく Cloud Router は AS 番号（ASN）を持つ Cloud Router はデフォルトでは、紐づく VPC ネットワークのすべてのサブネットへの経路を対向ルーターに広報する Cloud Router が学習したルートがどのリージョンに広報されるかは「動的ルーティングモード」がリージョンかグローバルかによって挙動が異なる 動的ルーティングモードがリージョンの場合、Cloud Router と同じリージョンに動的ルートを作成する 動的ルーティングモードがグローバルの場合、すべてのリージョンに動的ルートを作成する 特に最後の動的ルーティングモードについては、設定をリージョンにするかグローバルにするかによって、Cloud Router のあるリージョン（VPN や Cloud Interconnect を接続したリージョン）とは違うリージョンのサブネットにある VM 等が、オンプレミスと通信できるかどうかが決まってきます。この仕様をある程度理解しておきましょう。 参考 : 動的ルーティング モードの影響 Monitoring Packet Mirroring 例えば「VM から Egress する全てのトラフィックを検査しなければならない」といったセキュリティ要件がある際に活躍するのが Packet Mirroring です。 Packet Mirroring では VM のネットワークインターフェイスからパケットをミラーして、別の VM へ渡す機能です。これにより、パケット解析などを行うことができます。VPC を流れる全てのパケットをミラーできる訳ではなく VM へ出入りするパケットのみです。 また Filter により「プロトコル」「 IP アドレスレンジ」「トラフィックの方向 (VM へ入るパケットのみ / VM から出るパケットのみ / 両方) 」でミラーするパケットを絞ることができます。受け取り手の VM の手前には Internal TCP/UDP Load Balancer が必要です。 Firewall Logging Firewall Logging の基本も押さえておきましょう。 Firewall Logging はルールごとに有効化します。もちろん、取得できるのはそのルールに評価されたパケットだけです。問題文に書かれている要件に Firewall Logging が本当に合致しているかには注意して回答が必要です。 Cloud NAT セキュリティ上、VM に Public IP を持たせることはできれば避けたいものです。Cloud NAT を使えば Public IP を持たない VM もインターネットへ出ていくことができます。 Cloud NAT は意外と細かい設定が可能です。とはいえ、全てを覚える必要はありません。 ただし Cloud NAT が VM のパケットを NAT するのはパケットが「0.0.0.0/0 → default internet gateway 」のルートを使うとき だけである 、といった基本的な内容は押さえておくべきです。ネクストホップが default internet gateway 以外（Cloud VPN 等）であったり、0.0.0.0/0 より狭いターゲットが指定されている場合は、Cloud NAT は使われません。 Cloud Load Balancing 各種用途のために適切な ロードバランサーを選択 できるようにしておきましょう。 ロードバランサーは種類が多く、一見大変に思えますが、軸を覚えてしまえばそこまで大変ではありません。「Internal / External」「Regional / Global」「Proxy / Pass-through」「TCP & UDP / HTTP(S) / SSL」などです。 例えば「一般公開するシステムで、パススルー型の (接続元 IP を書き換えない) ロードバランサーが必要だ」と問われたならば、これだけで選択肢は External TCP/UDP Network load balancer であると定まります。 また「アメリカの西海岸リージョンと東海岸リージョンにそれぞれ AP サーバーがあり、顧客は HTTPS でアクセスする」ならば Global external HTTP(S) load balancer となります。 VPC Service Controls VPC Service Controls と 限定公開の Google アクセス (Private Google Access) を組み合わせるような問題が頻出です。 オンプレミスと VPC が Cloud Interconnect や VPN で接続されており、オンプレミスのクライアントから Google API を「限定公開の Google アクセス」経由でアクセスするよう構成されているネットワークにおいて、VPC Service Controls を使った API を保護実現したいケースが出題されます。 このようなケースで、限定公開の Google アクセスのためのドメイン名として restricted.googleapis.com を使うのか private.googleapis.com を使うのか、答えられるようにしておきましょう。 また VPC Service Controls に対して直ちに設定を変更すると本番影響が恐ろしいため、どう事前精査するか、といった実用的な内容も問われます。 VPC Service Controls や限定公開の Google アクセスについては、ぜひ以下の記事をご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp これらを読めば、先の問いには答えられるようになります。 「限定公開の Google アクセス」は難解なので、実際に検証環境で構築してみると理解が深まります。 Cloud Interconnect Dedicated Interconnect Cloud Interconnect は自ら検証するのが非常に難しいサービスです。ドキュメントを中心に、理解を深めましょう。 例えば Dedicated Interconnect の利用開始手順は ドキュメント に記載されているため、流れを把握しておきます。 Partner Interconnect トポロジ Partner Interconnect で Google が推奨するトポロジーはどのようなものか、についても把握しておきましょう。 99.99% の可用性を確保するには このドキュメント の図の構成にする必要があります。 別々の 2つのリージョンにそれぞれ Cloud Router を配置 各 Cloud Router からは違うゾーンに向けた2つずつの VLAN Attachment を作成する Cloud Router の 動的ルーティングモード を Global にする Cloud Router のルーティングモードを Global にすることで片方の回線が落ちてもルーティングが活きるようになる、という点に注意してください。 L2 と L3 Partner Interconnect には Layer 2 と Layer 3 の 二種類が存在 します。 L2 だと自社ルーターと Cloud Router 間で BGP Session 確立が必須です。 L3 だと Cloud Router とオンプレミスの間で BGP を貼るのは、ネットワーク業者のルーターです。そのルーターから自社への経路をどうするかは、パートナーによります。 適切な Interconnect の選択 Dedicated Interconnect / Partner Interconnect Layer 2 / Partner Interconnect Layer 3 の間で、適切な選択をできるかどうか問う問題もでてきます。 Dedicated Interconnect は Google の PoP (Point of Presence) まで回線が引けることが必須です。それができない場合は Partner Interconnect を選択することになりますが、自社のルーターの BGP 対応可否などで Layer 2 か Layer 3 を選ぶことになります。 Direct Peering / Carrier Peering Direct Peering / Carrier Peering は Google Workspace 等のパブリックな Google サービスと接続するためのサービスです。深追いする必要はありませんが、その存在と概要は把握しておきましょう。 Cloud VPN BGP セッション Cloud VPN については先の VPC 間接続のハブアンドスポーク型トポロジの解説で記載したことをしっかり押さえておきましょう。 これに加え、 BGP セッションの設定方法 などは、実際に一度検証してみることが望ましいです。 Google Cloud では VPC 間で VPN 接続を行うことが可能ですため、Google Cloud 検証環境があれば試してみることができます。 BGP IP アドレスは 169.254.x.x (リンクローカルアドレス) であり、また ASN が Private ASN (64512-65535 or 4200000000 - 4294967294) となっている必要があります。 組織のポリシー 組織のポリシーを使うことで、VPN で接続する先のインターフェイスの Public IP を制限することができます。 ドキュメント Restricting peer IP addresses through a Cloud VPN tunnel に記載の constraints/compute.restrictVpnPeerIPs がそれです。 これにより接続可能な IP アドレスのホワイトリストを作ることで不用意な Internet VPN 接続を防ぐことができます。 Cloud DNS inbound policy inbound policy を定義することで、オンプレミスのクライアントから Cloud DNS で名前解決クエリを投げたり、オンプレミスの DNS サーバから一部のリクエストを Cloud DNS へフォワーディングすることができます。 inbound policy を作成して VPC に適用すると、オンプレミスのクライアントや DNS サーバから Cloud DNS にリーチするための Private IP アドレス ( inbound forwarder entry points ) が払い出されます。 forwarding zone 逆に forwarding zone は Cloud DNS から一部のドメイン名をオンプレミスや VM 上の DNS にフォワードするための設定です。 特定ドメインの名前解決を Cloud DNS からフォワードして、オンプレの DNS や VM で稼働する DNS へ投げることができるようになります。このCloud DNS からオンプレミス DNS 等へ投げるクエリを Cloud Interconnect や Cloud VPN 経由にすることも可能です。 ただし注意点として、そのとき転送を受ける方の DNS サーバから見たクエリの 接続元 IP は 35.199.192.0/19 となります。プライベートネットワーク経由でクエリが来ているのに、接続元 IP が RFC 1918 のプライベートアドレスではないので若干の気持ち悪さはありますが、こういう仕様です。 Cloud DNS からオンプレミス DNS へのフォワーディングを実現するためには「オンプレミス側ファイアウォール設定で 35.199.192.0/19 からの TCP/UDP 53 番ポートを許可する」「オンプレミス側 DNS の設定でこの IP アドレス帯からの DNS クエリを許可する」「パケットを返せるように経路を設定する ( BGP で Cloud Router から広報する等) 」などの必要がある点、問題でも問われることがあります。 DNS Peering DNS Peering は、特定ドメインの名前解決を異なるプロジェクト/ VPC の Cloud DNS にフォワードするための設定です。 例えば以下のようなケースで使うことができます。 VPC (A) はオンプレミスサイトと Cloud Interconnect で接続されている VPC (A) の Cloud DNS では onpremiss.local のドメイン名をオンプレミスのDNSサーバにフォワードするよう設定されている VPC (B) は VPC (A) と VPC Peering で接続されている VPC (B) で onpremiss.local を名前解決したい DNS Forwarding と DNS Peering このようなときに VPC (B) から VPC (A) への DNS Peering を設定することで要件を満たせます。VPC (B) の中にいる VM は Cloud DNS に対して onpremiss.local の名前解決クエリを投げると、 DNS Peering に従い VPC (A) に名前解決をフォワードします。VPC (A) は forwarding zone に従いオンプレミス DNS に名前解決をフォワードします。クエリへの返答は、VPC (B) に返ります。 このような構成を、前述のハブアンドスポーク型トポロジを前提としてルーティングの知識と合わせて問う問題が出題されます。 Cloud Armor WAF サービスである Cloud Armor も出題範囲です。 概要を理解することに加え、細かいところでは、 Cloud WAF で偽陽性などが発生した際に、どのログを見て調査すれば良いか、などは把握しておきましょう。Cloud Armor の検知に関するログは Cloud Armor の Cloud Audit Log ではなく 、 Cloud Load Balancing のアクセスログ に出力されます。 その点を含め Cloud Armor でできることについては、当社記事もご参照ください。 blog.g-gen.co.jp Network Intelligence Center Connectivity Tests Shared VPC や オンプレミスとの Cloud VPN / Cloud Interconnect による接続、 VPC Peering などが絡み合った複雑なネットワークでは、ノード間の疎通ができない等のトラブル時の切り分けが複雑化します。 このようなときに Network Intelligence Center の Connectivity Tests が威力を発揮します。 接続元・先 IP を指定してテストを実行することで、疎通の可否を論理的に確認できます。接続元と接続先の間にある VPC Firewall、VPC Route、Cloud Router などの設定が確認され、どこに問題があるかを速やかに特定できます。 ただし、 実務で扱うときは各種 考慮事項 を理解 しましょう。Connectivity Tests は Google Cloud 上のリソースの設定情報に基づいて判断するので、オンプレミスのネットワーク機器等の設定を考慮しておらず、実際の通信可否を必ずしも表すものではありません。 Firewall Insights Network Intelligence Center の Firewall Insights を利用することで 以下のような情報 を得ることができます。 VPC ファイアウォールの Deny ルールへのヒットの急増 実質的に使われていないファイアウォールルールの棚卸し この機能を効率的に使うことで、ネットワーク運用における分析の時間を節約することができます。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Cloud（旧称 GCP）の Identity and Access Management （IAM）における 拒否ポリシー （Deny policies）について解説します。 はじめに IAM とは 拒否ポリシーとは IAM ポリシーの評価順 仕組み 拒否ポリシーの性質 拒否ポリシーを管理するための IAM 権限 拒否ポリシーの管理 拒否ポリシーの構成要素 継承 IAM ポリシーの例 拒否ポリシー利用の注意点 使い所 拒否できるアクション はじめに IAM とは Google Cloud（旧称 GCP）の Identity and Access Management （以下、IAM）は Google Cloud リソースの操作権限を管理する仕組みです。IAM は、認証された Google アカウント等に対して、どんな権限を与えるか（認可）を司ります。 IAM の基本的な解説については以下の記事をご参照ください。 blog.g-gen.co.jp 拒否ポリシーとは 拒否ポリシー （Deny policies）とは、リソースへの操作を明示的に拒否する IAM 設定のことです。 Google Cloud の IAM では、何も設定しないデフォルト状態だと、すべての操作が拒否されます。各リソースが持っている IAM ポリシーにおいてプリンシパル（Google アカウントやグループ等）を IAM ロールと紐づけると、操作が許可されます（明示的な Allow）。 拒否ポリシーは、最も強い優先度を持ちます。IAM ポリシーで明示的な Allow が与えられても、拒否ポリシーが最も優先され、操作は拒否されます。 参考 : 拒否ポリシー IAM ポリシーの評価順 IAM のポリシーが評価される際、以下のような順番で評価されます。 明示的な Deny > 明示的な Allow > 暗黙の Deny IAM では、権限がリソース階層の親から子へ（上から下へ） 継承 されます。階層のどこかで Deny ルールが存在すると、これが最も優先されることになります。図示すると、以下のようになります。 IAM Policy 評価フロー 仕組み 拒否ポリシーの性質 拒否ポリシーは、通常の IAM ポリシーとは独立したオブジェクト です。 そのため gcloud projects get-iam-policy などでリソースの IAM ポリシーを閲覧しても、拒否ポリシーは表示されません。 例として、あるプロジェクトの通常の IAM ポリシーを取得するための gcloud コマンドを示します。 gcloud projects get-iam-policy your-project-name 上記のコマンドを実行すると、明示的な許可を示す IAM bindings が表示されるのみで、拒否ポリシーは表示 されません 。 拒否ポリシーを表示するには、以下のようなコマンドを実行します。 gcloud iam policies get my-deny-policy \ --attachment-point=cloudresourcemanager.googleapis.com/projects/your-project-name \ --kind=denypolicies また、以下のようなコマンドを実行します。 gcloud projects get-ancestors-iam-policy sugimura --include-deny 拒否ポリシーの作成は、以下のようなコマンドを実行します。 gcloud iam policies create my-deny-policy \ --attachment-point=cloudresourcemanager.googleapis.com/projects/your-project-name \ --kind=denypolicies --policy-file=policy.json これらから、拒否ポリシーは通常の IAM ポリシーとは異なるオブジェクト であることが分かります。 拒否ポリシーを管理するための IAM 権限 拒否ポリシーの閲覧・作成・編集・削除には、 Deny Admin（roles/iam.denyAdmin） などのロールが必要です。 たとえプロジェクトレベルでオーナー（roles/owner）ロールを持っていても、拒否ポリシーの作成・編集・削除はできず、閲覧ができるのみです。 参考 : Required roles 拒否ポリシーの管理 拒否ポリシーは、Web コンソール、gcloud コマンドライン、REST API 経由で管理できます。 拒否ポリシーに関する各種手順については、以下のドキュメントを参照してください。 参考 : リソースへのアクセスを拒否する 拒否ポリシーの構成要素 拒否ポリシーは、以下のような要素で構成されています。 拒否対象のプリンシパル 除外するプリンシパル（オプション） 拒否するパーミッション 拒否する条件（オプション） はじめに、 1. の「拒否対象のプリンシパル」とは、操作を拒否する対象のプリンシパルを指定します。プリンシパルとは、Google アカウントや Google グループ、サービスアカウント等、Google Cloud API を実行する主体を指します。ここでは、複数のプリンシパルを指定することができます。 2. の「除外するプリンシパル」は、 1. で指定したプリンシパルのうち、対象外とするプリンシパルを指します。例えば 1. で拒否対象のプリンシパルとして hogehoge@example.com という Google グループを指定したとします。 2. にて john@example.com というプリンシパルを除外対象として指定すれば、 john が hogehoge グループに所属していても、拒否対象にはなりません。 3. の「拒否するパーミッション」は例として cloudresourcemanager.googleapis.com/projects.delete などの、パーミッションを指定します。通常の IAM ポリシーでは権限の指定方法として IAM Role を指定 するのに対して、拒否ポリシーでは パーミッションを指定 することに注意が必要です。 4. の「拒否する条件」は、アクションを拒否する条件を指定します。この条件に一致したときだけ、アクションが拒否されます。例えば、特定のリソースタグを付与したリソースに対する操作だけを拒否できます。 継承 通常の IAM ポリシーと同様に、拒否ポリシーも上位リソースから下位リソースに継承されます。 組織レベルで付与したポリシーは下位のフォルダーやプロジェクトに継承されます。また、フォルダーレベルで付与したポリシーは下位のプロジェクトに継承されます。プロジェクトに付与したポリシーは、プロジェクト内の全てのリソースに継承されます。 拒否ポリシーは最も優先されるため、上位リソースの IAM ポリシーで明示的に許可された権限を、下位リソースに追加した拒否ポリシーで拒否する、といったことが可能です。 IAM ポリシーの例 以下は、公式ドキュメントから引用した拒否ポリシーです。 参考 : Structure of a deny policy { "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion", "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816", "kind": "DenyPolicy", "displayName": "Only project admins can delete projects.", "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=", "createTime": "2021-09-07T23:15:35.258319Z", "updateTime": "2021-09-07T23:15:35.258319Z", "rules": [ { "denyRule": { "deniedPrincipals": [ "principalSet://goog/public:all" ], "exceptionPrincipals": [ "principalSet://goog/group/project-admins@example.com" ], "deniedPermissions": [ "cloudresourcemanager.googleapis.com/projects.delete" ], "denialCondition": { "title": "Only for non-test projects", "expression": "!resource.matchTag('12345678/env', 'test')" } } } ] } この Deny ルールでは deniedPrincipals にて、すべての Google ユーザーが対象となっています。 しかし exceptionPrincipals にて project-admins@example.com が指定されているため、このグループだけはこの拒否ポリシーの対象外です。とはいえ、明示的な拒否の対象外となるだけですので、このグループがリソースに対して操作を行うには、IAM ポリシーで 明示的な許可が必要 です。 deniedPermissions にて、この拒否ルールの対象が cloudresourcemanager.googleapis.com/projects.delete 、すなわちプロジェクトを削除する権限であることが分かります。 denialCondition にて、 env : test というリソースタグがついているプロジェクトに限られていることが分かります。 拒否ポリシー利用の注意点 使い所 ポリシーの評価順は 明示的な Deny > 明示的な Allow > 暗黙の Deny であり、明示的な Deny が最も強いです。 そのため IAM 権限体系の設計時は、まず拒否ポリシーを使わずに、通常の IAM ポリシー（明示的な Allow）を付与するかしないか、で管理することを原則とし、どうしても強い権限で拒否したい（権限にフタをしたい）ときだけ明示的な Deny を使う、という方針にすることが望ましいです。拒否ポリシー（明示的な Deny）は強力すぎるため、安易に使うと後から修正が難しくなる場合があるためです。 拒否できるアクション 拒否ポリシーでは、すべてのアクションが拒否対象にできるわけではありません。拒否できるアクションの一覧が公開されており、サポート対象の権限（アクション）以外は、拒否できません。 最新の対象権限（アクション）は、以下のドキュメントをご参照ください。 参考 : Permissions supported in deny policies 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは、G-genの荒井（@arapote）です。 前編ではGoogle Cloud (GCP) の利用開始に向けて、説明や準備を進めました。 今回の後編では実際にGoogle Cloud を開始する手順や、開始後のポイントを解説します。 前編のブログはコチラになります。必要なものを用意して利用手続きを始めましょう。 blog.g-gen.co.jp Google Cloud 利用開始 初期セットアップ Google Cloud コンソール画面について コンソール画面の見方について Google Cloud を始める際のポイント 予算アラート 無料トライアル枠の確認 各種プロダクトの始め方 各種機能の学習 Google Cloud ドキュメント さいごに ※本記事の内容は2022年3月6日時点の情報となります。 Google Cloud 利用開始 初期セットアップ では早速Google Cloud を始めましょう！ まず Google Cloud へアクセスします。 ※画面イメージは2022年3月6日のものです、画面は予告なく変更となる場合がございます。 今回は無料で利用するため「無料で使ってみる」をクリックして進みます。 ログインを求められます。前編で準備したGoogleアカウントを利用しログインします。 作成したGoogleアカウントのパスワードを入力し次に進みます。 Google Cloud を利用するためのセットアップ画面が表示されます。 国と組織のタイプ、利用規約を確認し次に進みます。 SMSが受信できる携帯電話を用意し、電話番号を入力しましょう。 SMSで受信したコードを入力します。 アカウントの種類とお支払情報を入力し「無料トライアルを開始」をクリックします。 Google Cloud のコンソール画面が開き、利用できる状態となりました。 いかがでしたでしょうか「クラウドでサーバーを構築する準備」などと言ってしまうと大層な準備が必要と思ってしまいがちですが、ごらんの通り、かなり容易に始めることができます。 さて！これでGoogle Cloud が利用できるようになったのですが、何から始めたら良いかわからない方のために少しポイントをご説明いたします。 Google Cloud コンソール画面について コンソール画面の見方について まず最初にGoogle CLoud のコンソール画面について、コンソール画面ではどんなことができるか解説します。 ①プロジェクト どのプロジェクトで作業をしているか確認することができます。またプロジェクトの切り替えも可能です。 ②検索ボックス プロダクトを検索することができます。Google Cloud はプロダクトが非常に多いため、検索はよく利用します。 ③Cloud Shell コマンドラインで Google Cloud を操作できるツール Cloud Shell を起動することができます。 ④固定（ショートカット） 固定したプロダクトに素早くアクセスすることができます。 ⑤ナビゲーションメニュー 利用したいプロダクトを選択し、詳細画面に入ります。またよく利用するプロダクトの画鋲マークをクリックすることで、上部に固定することができます。 Google Cloud を始める際のポイント Google Cloud を開始する上で、最初に設定（確認）をしておかなければならない点がいくつかあります。 項目やチェックリストは下記のブログに要点がまとまっていますので、こちらをご参照ください。 blog.g-gen.co.jp 予算アラート やはり気になってしまう料金ですが、前回解説した通り 課金の有効化 を行わない限り課金は発生しません。 とはいえ無料トライアル枠の$300を超えたら利用ができなくなってしまうため、料金は気にしておかなければなりません。 そのため利用料金の閾値を設定し、アラートが通知されるよう設定を行いましょう。 今回は月に指定した金額（￥30,000）に対して50%/90%/100%に到達した際メール通知がされる設定を行います。 コンソール画面で「予算とアラート」を検索します。 「予算を作成」をクリックします。 「手順1：範囲」で期間や対象プロジェクト・サービスを設定します。 項目 内容 名前 （任意設定） 期間 月別 プロジェクト すべてのプロジェクト サービス すべてのサービス クレジット 有効：割引、プロモーションなど 「手順2：金額」で予算タイプや金額を設定します。 項目 内容 予算タイプ 指定額 目標金額 ￥30000 「手順3：操作」でアラートの閾値とアラート方法を設定します。 No 予算の割合 金額 トリガー対象 1 50% ￥15000 実値 2 90% ￥27000 実値 3 100% ￥30000 実値 無料トライアル枠の確認 無料トライアル枠の$300と90日ですが、リアルタイムでの残額と日数を確認したい場合下記の画面で確認することができます。 残りクレジットと終了日には注意しておきましょう。 左上のナビゲーションメニューボタンからナビゲーションメニューを展開し「お支払い」をクリックします。 画面右に残りクレジットと終了日の表示があります。 ※アップグレードボタンには注意しましょう！！ 請求に関する仕組みについては、本ブログの別記事で詳細内容が記載されています。 いざ Google Cloud を本格活用される際には参考にしていただければと思います。 blog.g-gen.co.jp 各種プロダクトの始め方 諸々の準備が整ったので次は肝心の、プロダクト利用です。 Google Cloud では初めて利用するかた向けにチュートリアルがあります。チュートリアルから Google Cloud 各種プロダクトの利用方法を学習しましょう。 「ヘルプ」から「チュートリアルを開始」をクリックします。 チュートリアルを開始したいプロダクトをクリックします。 内容を確認し「開始」をクリックし、チュートリアルを開始します。 各種機能の学習 チュートリアルは特定のプロダクトのみを対象としていますが、それ以外の Google Cloud サービスの仕組みや機能を学習したい際には「学ぶ」が有効です。 ページ右上に「学ぶ」が表示されている場合「学ぶ」をクリックすると、関連したドキュメントや動画を確認することができます。 「学ぶ」をクリックします。 関連するドキュメントや動画が表示されます。 Google Cloud ドキュメント 最後に Google Cloud に関するドキュメントのリンクをご紹介します。各種プロダクトの概要や技術情報が掲載されいています。初心者から上級者まで頻繁に確認することが多いと思います。 googlecloudcheatsheet.withgoogle.com また、以下のリンク集では各プロダクトをわかりやすく解説した当社記事がまとまっています。ブックマーク必須です！！ blog.g-gen.co.jp さいごに お疲れさまでした、以上で Google Cloud を無料で楽しむことができます！ Google Cloud を無料でご利用いただき「継続して使ってみたい」と思った方は、是非G-genにご相談ください。 Google Cloud を3%OFF〜 でお得にご利用いただけます！！ それでは、快適なクラウドライフをお楽しみください！！ 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

G-gen の杉村です。当記事では、Google Cloud の仮想サーバーサービスである Compute Engine の割引制度の1つである 継続利用割引 （Sustained use discounts）について解説します。 はじめに 継続利用割引とは 他の割引制度 割引対象 割引率 計算例 前提条件 試算 補足 はじめに 継続利用割引とは 継続利用割引 （Sustained use discounts）は、Google Cloud の仮想サーバーサービスである Compute Engine の割引制度の1つです。インスタンスを停止せずに起動したままにするだけで、割引メリットを得ることができます。 継続利用割引では、1ヶ月のうち25%以上の期間（例えば3月であれば、31 日間 = 744 時間ですので、25%は186時間になります）、VM を起動したままにしておくと自動的に適用され、それ以降は段階的に割引額が上がっていき、総額として最大20%〜30%の割引が適用されます。 参考 : 継続利用割引 他の割引制度 似た名称の割引制度として 確約利用割引 （Committed use discounts）が存在します。確約利用割引については以下の記事をご参照ください。 blog.g-gen.co.jp 割引対象 継続利用割引は、 Compute Engine と Google Kubernetes Engine （GKE）で起動された VM が対象になります。 以下は対象外であるため、注意が必要です。 App Engine（スタンダード、フレキシブル）で起動された VM Dataflow により起動された VM 確約利用割引の対象となっている VM（使用量） E2、A2、T2D マシンタイプなど、対象となっているマシンタイプ以外のマシンタイプ 最も安く汎用的に使えるため出番の多い E2 マシンタイプですが、E2 には継続利用割引が適用されません。また最新のマシンタイプには適用されない場合があります。詳細や最新情報は以下のドキュメントの英語版を参照してください。 参考 : Sustained use discounts - Limitations また注意点として、継続利用割引が適用されるのは vCPU コアとメモリに対してであり、 永続ディスクには適用されない 点に注意してください。 割引率 継続利用割引は、VM を起動していた時間に応じて、段階的に割引額が増えます。以下に、例を記載します。 月内で起動していた時間 課金額 c2-standard-4 インスタンスの場合の価格 0%–25% 定価の 100% $0.2088 /h 25%–50% 定価の 86.78% $0.1811 /h 50%–75% 定価の 73.3% $0.1530 /h 75%–100% 定価の 60% $0.1252 /h このように、長期間起動したままであれば、 起動していた時間分の課金に対して所定の割合の割引 が適用されます。 大事なポイントとして、 起動していた分に対しての割引額 が大きくなっていくので、「停止せずにあと◯時間起動しておけば、停止したときよりも安くなる」といったことは発生しません。 計算例 以下に、継続利用割引の計算例を示します。 前提条件 マシンタイプ : c2-standard-4 定価 : $0.2088 /h 時期 : ある年の3月 上記の条件で、VM を月中に589時間起動していたと仮定して、継続利用割引の計算例を示します。これは、毎日深夜1時から朝6時まで VM を停止している場合を想定しています。 試算 589時間 を分解すると、以下の通り。 186時間（0%-25%）+ 186時間（25%-50%）+ 186時間（50%-75%）+ 31時間（75%-100%） それぞれの課金額の計算は、以下の通り。 $0.2088 * 186h = $38.8368 $0.1811 * 186h = $33.6846 $0.1530 * 186h = $28.458 $0.1252 * 31h = $3.8812 上記を合計すると、以下の通り。 $38.8368 + $33.6846 + $28.458 + $3.8812 = $104.8606 計 $104.8606 これは、定価である $0.2088 × 589 時間と計算した $122.9832 と比べると、 総額では約15%安価 になっていることが分かります。 なお、永続ディスクの料金は上記の計算からは外してあります。前述のように、永続ディスクは継続利用割引の対象外ですので、ご注意ください。 図による説明 補足 継続利用割引は自動的に計算され、課金額に反映されますので、ユーザー側で計算をする必要はありません。 また、事前に料金を見積もりたい場合は、公式の利用料計算ツールである Google Cloud's pricing calculator を利用することで、継続利用割引を考慮に入れた金額を見積もることができます。 参考 : Google Cloud's pricing calculator 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは、G-genの渡邉 @norry です。 昨今クラウドネイティブというワードを当たり前のように耳にするようになりました。 自分はクラウドの利点を徹底的に活用する！というような意味合いで捉えいています、システムを構築・運用する際にまずクラウドをベースにして使い倒していく感じでしょうか。 弊社はフルリモートで働くベンチャー企業である事もあり、社内にオンプレミスのサーバーを保有しておらず、VPN環境も利用していません。 とはいえ、日本の多くの企業では社内にサーバーがあり、これからクラウドへ移行し、まずはオンプレミスとクラウドのハイブリッドでの運用や、インターネット側には公開せず社内システムを利用したいと言う事もあると思います。 本番環境なら専用線サービスであるCloud Interconnect を利用して閉域網で接続する事をおすすめしますが、予算の関係や気軽に開始したい方々へ向けて社内 LAN から Google Cloud (旧GCP ) で簡単に VPN接続する手順をご案内いたします。 Cloud VPN とは アーキテクチャ 構成図 Cloud VPN のタイプ HA (High Availability) VPN とは VPN 接続で理解しておくべき用語 Google Cloud 側の設定 VPC の設定 Google Cloud Engine (GCE) インスタンスの作成 ファイアウォールルールの設定 Cloud VPN を作成 社内オンプレミスルーター (RTX1210) の設定 IPsecトンネルの設定1 IPsecトンネルの設定2 IPsecトンネル 共通設定 BGPの設定 BGPの設定 有効化 接続確認 Ping と RDP 接続確認 Cloud VPN とは Cloud VPN とは IPsec VPN 接続を使用して、オンプレミス ネットワーク と VPC ネットワークをプライベートに接続するサービスです。 詳細は以下の記事で解説していますので、ご参照ください。 blog.g-gen.co.jp アーキテクチャ 構成図 今回はシンプルな下図のような構成で構築します。 構成図 オンプレミス側で利用したルーターは RTX1210 になります。(少し古い機種ですがベースの部分は現行モデルとほぼ変わらないはず。。。) Cloud VPN のタイプ 公式ドキュメント の引用になりますが Google Cloud には、HA VPN と Classic VPN の 2 種類の Cloud VPN ゲートウェイがあります。ただし、Classic VPN の特定の機能が 2022 年 3 月 31 日に非推奨となります。 とありますので今回は HA VPN 構成で設定していきます。 HA (High Availability) VPN とは 単一リージョン内の IPsec VPN 接続を使用して、オンプレミス ネットワークを VPC ネットワークに安全に接続できる、高可用性（High Availability）Cloud VPN ソリューションです。 オンプレミス ネットワークとしていますが、実際には IPsec VPN 接続可能な AWS や Microsoft Azure とも接続出来ます。 HA VPN は2 つのインターフェースに1つずつ、2 つの外部 IP アドレスを自動的に選択し、99.99% のサービス可用性の SLA を提供します。 アクティブインターフェイスを１つ、外部アドレス１つでも実は通信可能ですがその場合 SLA は99.99% となりません。 VPN 接続で理解しておくべき用語 Cloud VPN で HA VPN 構成を組む場合に良く出てくる言葉を下記にまとめておきます、さらっと確認しておいていただいた方が全体の理解が深まるかと思います。 用語 簡単な解説 1 AS 番号 (Autonomous System number) ISP など大きなネットワークに割り当てられる一意の識別番号 2 BGP (Border Gateway Protocol) AS を他のAS に広告したりルーティングしたりするためのプロトコル 3 Cloud VPN ゲートウェイ（IP） Google Cloud の外側 (WAN) IP アドレス 4 ピア VPN ゲートウェイ（IP） オンプレミスの 外側 (WAN) IP アドレス 5 Cloud Router の BGP IP IPsec VPN でトンネルを張る時の Google Cloud 側 BGP 用 IP アドレス 6 BGP ピア IP IPsec VPN でトンネルを張る時のオンプレミス側の BGP用 IP アドレス Google Cloud 側の設定 VPC の設定 まずは VPC (Virtual Private Cloud) を設定します。VPCって何？ という方は以下を参照ください。 blog.g-gen.co.jp 管理コンソール ＞ VPCネットワーク ＞ VPC ネットワークの作成 から以下のように作成しました。 VPC サブネット作成 また、合わせて組織ポリシーで以下の設定を実施しておく事をおすすめします。 ポリシーID ポリシー概要 理由と説明 constraints/compute.skipDefaultNetworkCreation デフォルト ネットワークの作成をスキップ デフォルトネットワークは通常使わないため、自動作成されないよう設定する constraints/iam.automaticIamGrantsForDefaultServiceAccounts デフォルトのサービス アカウントに対する IAM ロールの自動付与の無効化 有効にすることで VM を最初に作成する時に作成されるデフォルトの Compute Engine サービスアカウントに Owner 権限が付与されることを防ぐ Google Cloud Engine (GCE) インスタンスの作成 管理コンソール ＞ Compute Engine ＞ VM インスタンス ＞ + インスタンスを作成 設定内容は次のとおりです、今回は外部 IP を持たず、インターネット側から直接アクセス出来ない形にしています。ただし VM 側からは Cloud NAT を通じてインターネット接続が可能です。 項目 設定値 名前 windows-1 ゾーン asia-northeast2-a マシンタイプ e2-medium OS windows-server-2019 ネットワーク norry-vpc サブネットワーク private プライマリ内部 IP 10.0.1.2 外部 IP なし ファイアウォールルールの設定 管理コンソール ＞ VPCネットワーク ＞ ファイアウォール ＞ + ファイアウォールを作成 作成した VPC に対しファイアウォールの設定を行います。今回は VM に 社内 LAN (192.168.100.0/24) からの RDP と Ping を通す為の icmp を許可しました。 ファイアウォール設定 Cloud VPN を作成 VPC の作成、VMの作成、ファイアウォールの設定が完了しましたので実際に Cloud VPN の設定に入っていきます。 HA VPN では Cloud VPN ゲートウェイで IP を2つ、トンネルも2本張る構成にしています。 ASN はプライベート ASN を利用しています。 設定するパラメータは次の通りです。 項目 設定値 名前 norry-ha-vpn ネットワーク norry-vpc リージョン asia-northeast2 Cloud VPN ゲートウェイ（IP) ① 34.xxx.xxx.xxx Cloud VPN ゲートウェイ（IP) ② 35.xxx.xxx.xxx トンネル名 ① norry-inhouse-tn トンネル名 ② norry-inhouse-tn2 ピア VPN ゲートウェイ（IP） 118.xxx.xxx.xxx Cloud Router ASN 65001 ピアルーター ASN 65002 Cloud Router の BGP IP ① 169.254.0.1 Cloud Router の BGP IP ② 169.254.1.1 BGP ピア IP ① 169.254.0.2 BGP ピア IP ② 169.254.1.2 IKEバージョン IKEv2 共有シークレット 任意 ルーティングオプション ポリシーベース リモートネットワークIPの範囲 192.168.100.0/24 ローカルIP範囲 10.0.1.0/24 では Google Cloud 側の設定に入っていきましょう。 管理コンソール ＞ ハイブリッド接続 ＞ VPN ＞ + VPN 設定ウィザード から 高可用性 (HA) VPN を選択します。 VPN 設定ウィザード - VPN の作成 「VPN ゲートウェイの名前」「ネットワーク」「リージョン」を選択し、作成して実行 ピア VPN ゲートウェイはオンプレミスまたは非 Google Cloud を選択し、「新しい VPN ゲートウェイを作成する」 「名前」とインターフェース 1 つのインターフェース を選択し、RTX1210 のグローバル IP を設定します。グローバル IP を複数お持ちの場合はインターフェースを増やす事が可能です。 次に新しくルーターを作成します 「名前」と「ASN」を設定し作成します。 続いて IKE まわりの設定をします。「名前」「 IKE バージョン」「 IKE 事前共有キー」を入力。 BGP セッションの作成、「名前」「ピア ASN」「Cloud Router の BGP IP」「BGP ピア IP」を入力。BGP IP はリンクローカルアドレスを使用しました。 1つ目のトンネル作成まで終わりましたので 「 VPN トンネル作成」で 2 本目のトンネルを作成してください。 社内オンプレミスルーター (RTX1210) の設定 Config は Yamaha 公式ページ を参照して以下の設定をしています。 IPsecトンネルの設定1 tunnel select 1 ipsec tunnel 1 ipsec sa policy 1 1 esp aes-cbc sha-hmac ipsec ike version 1 2 ipsec ike always-on 1 on ipsec ike encryption 1 aes-cbc ipsec ike group 1 modp1024 ipsec ike hash 1 sha ipsec ike keepalive log 1 on ipsec ike keepalive use 1 on rfc4306 ipsec ike local address 1 192.168.100.1 ipsec ike local name 1 118.xxx.xxx.xxx ipv4-addr ipsec ike nat-traversal 1 on ipsec ike pfs 1 on ipsec ike pre-shared-key 1 text (事前共有鍵) ipsec ike remote address 1 34.xxx.xxx.xxx ipsec ike remote name 1 34.xxx.xxx.xxx ipv4-addr ip tunnel address 169.254.0.2 ip tunnel remote address 169.254.0.1 ip tunnel tcp mss limit auto tunnel enable 1 IPsecトンネルの設定2 tunnel select 2 ipsec tunnel 2 ipsec sa policy 2 2 esp aes-cbc sha-hmac ipsec ike version 2 2 ipsec ike always-on 2 on ipsec ike encryption 2 aes-cbc ipsec ike group 2 modp1024 ipsec ike hash 2 sha ipsec ike keepalive log 2 on ipsec ike keepalive use 2 on rfc4306 ipsec ike local address 2 192.168.100.1 ipsec ike local name 2 118.xxx.xxx.xxx ipv4-addr ipsec ike nat-traversal 2 on ipsec ike pfs 2 on ipsec ike pre-shared-key 2 text (事前共有鍵) ipsec ike remote address 2 35.xxx.xxx.xxx ipsec ike remote name 2 35.xxx.xxx.xxx ipv4-addr ip tunnel address 169.254.1.2 ip tunnel remote address 169.254.1.1 ip tunnel tcp mss limit auto tunnel enable 2 IPsecトンネル 共通設定 ipsec auto refresh on BGPの設定 bgp use on bgp autonomous-system 65002 bgp neighbor 1 65001 169.254.0.1 local-address=169.254.0.2 bgp neighbor 2 65001 169.254.1.1 local-address=169.254.1.2 bgp import filter 1 equal 192.168.100.0/24 bgp import 65001 static filter 1 BGPの設定 有効化 bgp configure refresh 接続確認 Ping と RDP 接続確認 以上で設定完了です、社内 PC から Ping のテストをしてみます。 norry@penguin:~$ ping 10.0.1.2 PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data. 64 bytes from 10.0.1.2: icmp_seq=1 ttl=124 time=30.1 ms 64 bytes from 10.0.1.2: icmp_seq=2 ttl=124 time=29.6 ms 64 bytes from 10.0.1.2: icmp_seq=3 ttl=124 time=27.5 ms 64 bytes from 10.0.1.2: icmp_seq=4 ttl=124 time=26.6 ms 64 bytes from 10.0.1.2: icmp_seq=5 ttl=124 time=25.6 ms 64 bytes from 10.0.1.2: icmp_seq=6 ttl=124 time=29.2 ms 64 bytes from 10.0.1.2: icmp_seq=7 ttl=124 time=44.0 ms ^C --- 10.0.1.2 ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 16ms rtt min/avg/max/mdev = 25.586/30.368/43.999/5.770 ms RDP も接続出来ました。 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-gen の杉村です。Google Cloud（旧称 GCP）の仮想サーバーサービスである Compute Engine（GCE）等には、 確約利用割引 （Committed use discounts）という割引の仕組みがあります。本記事では確約利用割引の仕組みを分かりやすく解説します。また、Amazon Web Services（AWS）の類似制度である Reserved Instance や Savings Plans との違いについても言及します。 確約利用割引の基本 確約利用割引とは 料金 金額の例 2種類の確約利用割引 リソースベースの CUD 仕組み 購入・適用方法 フレキシブル CUD 仕組み 購入・適用方法 GKE や Cloud Run への適用 どんなときに購入すべきか 購入すべきとき 購入すべきではないとき コミットメントの更新・延長 コミットメントの更新 コミットメントの延長 コミットメント期間のアップグレード ゾーンリソースの予約（reservation） 確約利用割引の応用 推奨の確認 プロジェクト間で確約利用割引を共有する リソースベースの CUD の場合 フレキシブル CUD の場合 コミットメントの結合・分割 注意点 確約の変更やキャンセルはできない 確約利用割引の適用範囲 割り当て（クォータ）の確認 常時起動していないインスタンスへは適用されない場合がある 確約利用割引が適用できないケース リソースベースの CUD フレキシブル CUD AWS との違い 確約利用割引の基本 確約利用割引とは 確約利用割引 とは、一定の利用を Google にコミット（確約）することと引き換えに、通常よりも割引された料金で Google Cloud リソースを利用できる割引プランのことです。英語で Committed Use Discounts と表記されるため、 CUD と略称されることもあります。 ポイントをまとめると、以下の通りです。 1年間または3年間 の利用を確約することで 割引 を得られる 前払いはなく、 支払いは毎月 Google Compute Engine や Cloud SQL、Google Kubernetes Engine で利用できる ただしそれぞれの確約利用割引の間で融通はできない（別々で購入する必要がある） 当記事では、Compute Engine の CUD について解説します。Compute Engine の CUD は、2種類存在します。 1つ目は、 リソースベースの CUD です。別名として、 リソースベースのコミットメント とも呼ばれます。一定の Compute Engine リソースを1年間または3年間使用することの確約と引き換えに、最大57%の割引料金が適用されます。リソースベースの CUDは、 プロジェクト単位 で購入します。 参考 : リソースベースのコミットメント 2つ目は、 フレキシブル CUD です。別名として、 費用ベースのコミットメント とも呼ばれます。フレキシブル CUD はリソースベースの CUD とは異なり、「いくら金額を使うか」をコミットすることで、最大46%の割引を受けることができます。フレキシブル CUD は、その名の通りリージョンやマシンシリーズに縛られない柔軟性があります。フレキシブル CUD は、 請求先アカウント単位 で購入します。 参考 : 費用ベースのコミットメント 参考 : Compute のフレキシブル CUD 料金 確約利用割引の料金は、公式ページに記載があります。 参考 : Compute Engine pricing 確約利用割引の料金はオンデマンド料金（通常料金）やプリエンプティブル料金（「売れ残りインスタンス」の安売り料金）とともに併記されています。また公式の料金計算ツールである「Google Cloud's pricing calculator」でも算出することができます。 参考 : Google Cloud's pricing calculator 確約利用割引を購入すると、 月単位で料金の支払いが発生 します。AWS の Reserved Instance や Savings Plans とは異なり、Google Cloud の確約利用割引には 前払いはありません 。 金額の例 e2-standard-2（vCPU 2 cores、8 GB RAM) でリソースベースの CUD を購入する場合を例に取ります。 このマシンタイプのオンデマンド（通常料金）の月額は、東京リージョンでは $62.75372 / 月です（2024年9月現在。ストレージ料金は計算に入れていません）。 1年コミットメントの場合、これが $33.8876872 となり、 約37%オフ になります。 2種類の確約利用割引 リソースベースの CUD 仕組み 2種類ある確約利用割引のうちの1つ目は、 リソースベースの CUD です。vCPU、メモリ、GPU、ディスクなどに対してそれぞれ確約利用割引を購入できます。リソースベースの CUDは、 プロジェクト単位 で購入し、そのプロジェクトの中で適用されます（後述しますが、別のプロジェクトに共有することもできます）。 参考 : リソースベースのコミットメント なお購入は「 コミットメント （commitment）」を「 作成する （create）」と表現することもあります。 コミットメントの作成はコンソールや CLI、 API 経由で可能です。コンソールの場合は「Compute Engine コンソール＞確約利用割引」から購入します。 以下の例では Google Cloud コンソールで「 東京リージョン に E2タイプ で vCPU を4コア 、 RAM を 8 GB 購入する。期間は1年間のコミット。」といった指定の仕方をしています。 リソースベースの CUD の購入画面 購入・適用方法 コンソールの場合は「Compute Engine コンソール＞確約利用割引」から購入します。 購入時には「 利用するリソースの量・期間の確約 」を指定します。購入すると、リージョン内に存在している そのスペックを持ついずれかの VM に、自動的に割引が適用されます。 そのため、当初に割引対象として想定していた VM の設定を変更して、別のインスタンスタイプに変えたとしても、同じタイプのインスタンスが他に存在していれば、自動的にそちらに割引が適用されます。 また、確約利用割引では「カスタムマシンタイプ」と「事前定義のマシンタイプ」は区別されません。 購入方法の例として、公式ドキュメントの記述を引用します。 参考 : 確約利用割引の仕組み 例として 8 コアのコミットメントを購入し、その月に 24 コアを実行した場合、8 コア分のみ確約利用割引が適用されます。 残りの 16 コアは標準料金 (確約利用でない料金) で課金されます。 8コアの確約を購入。実際使ったのは24コア このように、購入したコア数を超える分については、 自動的に標準料金で請求 されるようになります。 逆に、購入したコミットメントに対しては、 たとえ使用していなくても毎月請求があります 。8コアのコミットメントを購入したとして、実際には Compute Engine を4コア分しか使っていなくても、必ず8コア分が請求されます。 無駄になるパターン フレキシブル CUD 仕組み 2種類目の フレキシブル CUD （費用ベースのコミットメント）は、 請求先アカウント単位 で購入し、同じ請求先アカウントを共有するプロジェクト間で共有されます。 参考 : 費用ベースのコミットメント 参考 : Compute のフレキシブル CUD 「1年または3年の長期利用をコミットして割引を享受する」「前払いなしで毎月支払い」という点はリソースベースの CUD と同様です。しかしフレキシブル CUD の場合は、以下の特徴があります。 vCPU 数やメモリ量ではなく、費用ベース（いくら分、利用するか）でコミットする 費用をコミットしたら、リージョン、プロジェクト、マシンシリーズに関係なく適用される 1年コミットメントは28%割引、3年コミットメントは46%割引される 例えばフレキシブル CUD を以下の条件で購入したとします。 オンデマンド費用 $100 / 時間でコミット 3年コミットメント 3年コミットでは 46% の割引が適用されます。毎時の vCPU/Memory の利用料金のうち、通常料金で $100 消費した分までが、$54 の支払いで済みます。 ある時刻の利用が $100 を超えなかった場合でも、最低 $54 の支払いが発生します。逆に $100 を超えて $150 使った場合、$100 までが CUD でカバーされ $54 になり、残りの $50 は定価で支払うことになります。 なお、残った $50 は「継続利用割引」の対象にはなります。継続利用割引は、自動的に適用される Compute Engine の割引の仕組みです。以下の記事も参照してください。 blog.g-gen.co.jp 購入・適用方法 フレキシブル CUD は請求先アカウント単位で購入します。コンソールでは「お支払い＞確約利用割引」の画面から購入することができます。 同じ請求先アカウント内であればリージョン、プロジェクト、マシンシリーズに関係なく適用されます。 ただし、フレキシブル CUD を適用できるマシンタイプは以下のみです。 General purpose : C3、C3D、C4、E2、N1、N2、N2D、N4 Compute-optimized : C2、C2D Storage-optimized : Z3 なお上記のリストは2024年9月現在のものです。最新の対応リストは以下をご参照ください。 参考 : Eligible resources フレキシブル CUD がどのリソースに適用されるかはユーザー側で選択できず、自動で適用されます。自動適用のロジックは以下の通りです。 まずリソースベースの CUD（通常の CUD）が各リソースに適用される 残りのリソースに、フレキシブル CUD が適用される 残りのリソースに継続利用割引が適用される GKE や Cloud Run への適用 フレキシブル CUD は、2024年7月のアップデートにより、Google Kubernetes Engine（GKE）の Autopilot モードや Cloud Run（CPU always allocated の Cloud Run services と Cloud Run Jobs）にも適用されるようになりました。 GKE Standard はインフラとして Compute Engine を使っているため、従来から Compute Engine の CUD で割引の適用が可能でしたが、このアップデートにより GKE Autopilot も Compute Engine のフレキシブル CUD でカバーされるようになります。これに伴い、もともと存在していた GKE Autopilot 用の CUD は廃止になります。 詳細は以下の公式ドキュメントをご参照ください。 参考 : Google Kubernetes Engine (GKE) - Committed use discounts 参考 : Cloud Run - Committed use discounts どんなときに購入すべきか 購入すべきとき 確約利用割引は「最低限必要なリソース量が、長期に渡ってある程度予測できるシステム」において購入すべきです。 例えば「 基本的に24時間稼働 であり、 利用者数が概ね決まって いて、稼働開始から 3ヶ月程度経過 してワークロードが安定化した社内システム」などが最も分かりやすいでしょう。 購入すべきではないとき 逆に、以下のようなケースでは購入 すべきではありません 。 立ち上げたばかりのビジネスであり先行きが不明な場合 稼働したばかりのシステムであり本番利用の負荷の様子を見たい場合 平日昼間しか稼働させない開発用 VM など特定時間だけ起動する VM の場合 確約利用割引は1年または3年の利用を確約する必要があり、 途中で解約や変更はできません 。 例 1. は、ビジネスが確約した期間より短いスパンで撤退になったり、縮小になる可能性があるケースです。購入した確約利用割引が無駄になってしまうかもしれません。 例 2. は、撤退は考えられないまでも、新設/移行からカットオーバーしたばかりで本番利用して間もないケースです。もしかしたら思っていたよりも小さいインスタンスタイプで十分かもしれません。本番稼働開始から 3 〜 6 ヶ月程度は様子見の期間を設けるのが定石です。 例 3. は、こまめに停止・起動したほうが安くなるパターンです。確約利用割引を購入した場合の費用と、こまめに停止した場合の費用を比べて、どちらが安くなるかを正しく見定めましょう。公式の料金計算ツールや料金ページを見ることで、自分で計算できます。 参考 : Compute Engine pricing 参考 : Google Cloud's pricing calculator また一般的には、3年間の確約の購入には慎重になるべきです。3年が経つと、より安価で高性能なマシンタイプが発表される可能性がありますし、ワークロード（利用のボリュームや性質）が変化する可能性も高くなるからです。 コミットメントの更新・延長 コミットメントの更新 コミットメントは1年または3年で作成しますが、期限が切れると割引が終了し、その日からは 通常料金での請求 となります。 引き続き CUD を利用したい場合、フレキシブル CUD の場合は、手動で再購入する必要があります。リソースベースの CUD は、再度手動で購入することもできますが、 コミットメントの自動更新 機能を利用することもできます。 参考 : コミットメントを自動的に更新する コミットメントの自動更新を設定すると、更新後のコミットメントの期間は、元のコミットメントと同じになります。 自動更新をオンにすると、自動更新をキャンセルしない限り、コミットメントの終了日に自動的に更新されます。なおキャンセルは、更新日の午後12時（太平洋標準時間 = PST）までに行う必要があります。 コミットメントの延長 リソースベースの CUD では、 コミットメントの延長 機能により、1年または3年を超えて、こみっとめんと期間を延長することができます。 1年コミットメントは、1年〜3年未満のカスタム期間を指定できます。 3年コミットメントは、3年〜6年未満のカスタム期間を指定できます。 期間を延長しても、割引率は変更されません。1年コミットメントを利用中の場合で、もし今より高い割引率を受けたい場合は、1年→3年へ「コミットメント期間のアップグレード」を検討してください。 参考 : 確約利用期間を延長する コミットメント期間のアップグレード 1年コミットメントを利用中の場合、 コミットメント期間のアップグレード を行って3年コミットメントに変更することで、より高い割引料金が適用されます。 アップグレードすると、適用期間が2年間延長されます。 参考 : コミットメント期間をアップグレードする ゾーンリソースの予約（reservation） 確約利用割引を購入したとしても、これはキャパシティが必ず確保されることを 意味しません 。まれではありますが、Google 側のコンピュートリソースが物理的に足りない場合、必要なときに VM を起動したり、ストレージを追加したりできないことがあります。このような状態を キャパシティ不足 と言います。 確約利用割引とは別の概念として、 ゾーンリソースの予約 （reservation of zonal resources）を行うことで、予めキャパシティを予約することができます。予約時は、ゾーンやマシンタイプなどを指定します。 リソースの予約を行うと、その分のリソースを利用できることが確定しますが、予約しただけで 実際には使っていなくても、料金が発生します 。リソースの予約は、確約利用割引と組み合わせることで、キャパシティを確保しつつ割引料金の適用が得られます。 特定の VM に関して言えば、VM を常時起動したままにしておけば原則的にリソースの予約は必要ありませんが、何かの機会に VM を一時的に停止したときに、再び起動する際にキャパシティ不足の状態であり、起動できないという可能性はゼロではありません。 常時起動は確約利用割引の割引を最大限活かせる使い方であるため、必ずしも予約は必要ありません。しかしながら、GPU やローカル SSD の場合、確約利用割引の購入時に リソース予約が必須 という仕様になっています。GPU とローカル SSD の確約利用割引の購入の際は、同時にリソース予約も作成する必要があります。 参考 : Compute Engine ゾーンリソースの予約 また、 将来の予約リクエスト （future reservation requests）によって、最長で1年先までの予約を予めリクエストできます。リクエストが Google Cloud によって審査され、承認されると、将来の特定日付以降に、指定した容量が確保されます。多数の VM を移行する際や、新規システムの開発スケジュールに備える際などに利用できます。 参考 : 将来の予約リクエストについて 確約利用割引の応用 推奨の確認 Google Cloud コンソールの「お支払い > 費用の最適化 > CUD 分析」などから、どれくらいの確約利用割引を購入するべきか、などの 推奨事項 を見ることができます。 これは Google Cloud のサービスである Recommender API により、機械学習等を用いて生成された推奨事項です。参考にしたうえで、購入の判断に活用しましょう。 参考 : 確約利用割引の推奨事項を適用する プロジェクト間で確約利用割引を共有する リソースベースの CUD の場合 リソースベースの CUD はプロジェクト単位の購入であるものの、明示的に指定することで同じ 請求先アカウント を共有する複数のプロジェクト間で、購入した確約利用割引を共有できます。 参考 : プロジェクト間で確約利用割引を共有する 請求先アカウントについては、以下の記事も参照してください。 blog.g-gen.co.jp これにより、例えば大規模に Google Cloud を利用している会社等では、組織として確約利用割引を購入しておき、利用者の意識しないところで割引を適用し費用の全体最適を図ることができます。フレキシブル CUD でも同様のことが簡単に実現できますが、割引率はリソースベースのほうが大きくなります。 また アトリビューション という仕組みで、確約利用割引がどのプロジェクトに割り当てられるかを制御することができます。 デフォルトでは 比例アトリビューション モードとなっており、各プロジェクトで消費された対象リソースの合計使用量に応じた割合で、確約利用割引がプロジェクトに配分されます。 一方の 優先アトリビューション では、明示的に割当の優先順位を指定できます。 参考 : 確約利用割引の料金とクレジットのアトリビューション フレキシブル CUD の場合 フレキシブル CUD においては同じ請求先アカウント内でコミットメントが共有・分配されます。 そのため「プロジェクト間で共有する」ことはそもそも考える必要がありません。 コミットメントの結合・分割 リソースベースの CUD は購入後に 結合・分割 が可能です。 コミットメントを結合するメリットは、複数のコミットメントを結合することで期限切れになる期間を調整することができる点です。結合されたコミットメント群のうち最も遅い有効期限が、結合後の有効期限になります。 ただし結合するコミットメント同士は、同じプロジェクト・リージョン・期限（1 or 3 years）・マシンタイプ等は同等である必要があります。 コミットメントを分割するメリットも同様に、終了期限を管理しやすくなる点です。大きなコミットメントを分割し、一部は期限が来たら終了させ残りは自動更新させる、といったことができます。 参考 : コミットメントを統合して分割する 注意点 確約の変更やキャンセルはできない 確約利用割引は一度購入すると、変更やキャンセルはできません。購入時には「購入間違い」「不必要な分まで購入してしまう」などに十分注意する必要があります。 後から足りなくなった分については追加購入が可能ですが、減らしたりキャンセルすることはできない点に、十分注意です。 なお、2023年2月のアップデートで1年コミットを3年コミットに [アップグレードできる ようになりました。コミット期間を伸ばすことでより深い割引を得ることができます。 参考 : コミットメント期間をアップグレードする 確約利用割引の適用範囲 リソースベースの確約利用割引はリージョン単位での購入となります。そのためリージョンをまたいでリソースを利用しても、割引が適用されない点に注意が必要です。 一方のフレキシブル CUD はプロジェクト、リージョン、マシンシリーズをまたいで適用されます。 割り当て（クォータ）の確認 Google Cloud には 割り当て（クォータ） という概念があります。 参考 : Compute Engine の割り当てと上限の概要 プロジェクトごとやリージョンごとに、使用可能なリソースの最大値が決まっており、誤って大量消費してしまうことを防いでいます。 確約利用割引でもリージョンごとに購入可能な確約利用割引の割り当て (クォータ) が決まっています。コンソールの「割り当て」画面等から、上限緩和をすることが可能です。 常時起動していないインスタンスへは適用されない場合がある VM を月の中で長期間停止していたり、あるいは1日の中で頻繁に起動・停止しているような場合、そのインスタンスには確約利用割引が適用されない場合があります。確約利用割引は常時起動している VM を対象として想定しています。公式ドキュメントでは以下のように表現されています。 コミットメントはバースト シナリオ用にスタックすることはできません。たとえば、ある月に 10 コア分を購入した後、その月の半分の期間で 20 コアを稼働させた場合、使用量が半分になったという理由だけでは、20 コア全体に対するコミットメントは適用されません。 参考 : コミットメントの効率的な使用 確約利用割引が適用できないケース リソースベースの CUD インスタンスタイプの制限としては、f1-micro および g1-small マシンタイプ (N1 共有コアマシン) はリソースベースの確約利用割引の対象になりません。 また、Spot VM やプリエンプティブルインスタンス、VM にアタッチした拡張メモリにも適用されません。 さらに、確約利用割引はバックエンドで Compute Engine を使う Google Kubernetes Engine、Dataproc、Cloud Composer 1 の VM には適用されますが、一方で App Engine、Dataflow、Cloud Composer 2 には適用されません。 参考 : 制限事項 フレキシブル CUD 対象となるマシンタイプは以下のみであり、それ以外には適用されません。 General purpose : C3、C3D、C4、E2、N1、N2、N2D、N4 Compute-optimized : C2、C2D Storage-optimized : Z3 なお上記のリストは2024年9月現在のものです。最新の対応リストは以下をご参照ください。 参考 : Eligible resources AWS との違い Amazon Web Services（AWS）にも Reserved Instance や Savings Plans といった、類似の割引プランが存在しています。 それぞれ、仮想サーバ等コンピューティングリソースの利用を 1 年または 3 年でコミットし「全額前払い / 一部前払い / 前払いなし」 のいずれかから選択して割引料金の適用を得られるものです。 Reserved Instance と Savings Plans の違いは、サーバーワークス社の以下のブログで非常に分かりやすく解説されています。 blog.serverworks.co.jp AWS の Reserved Instance / Savings Plans は、 Google Cloud の確約利用割引とよく似た制度ですが、以下のような違いがあります。 前払いオプション (全額前払い / 一部前払い / 前払いなし) があること （Savings Plans）インスタンスファミリー（Google Cloud でいうマシンシリーズ）をまたいで柔軟に適用される （Reserved Instance）購入した Reserved Instance を Marketplace で売却できる その他にも Reserved Instance ではアベイラビリティゾーン指定の購入オプションがある、など細かい違いは多数あります。 最も大きな違いは、AWS には 前払いオプションが存在し、前払い額が大きいほど割引額が大きくなる という点です。 Google Cloud の確約利用割引では前払いオプションがなく、月額での支払いとなるので、この点が大きな違いだと言えます。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it