G-gen の杉村です。 Google Cloud (旧称 GCP) の強力なネットワークインフラサービスである External Application Load Balancer (外部アプリケーションロードバランサ) について解説します。 サービスの概要 Cloud Load Balancing とは ロードバランサーの種類 名称変更 External Application Load Balancer とは 3 種類の External Application Load Balancer ユースケース 料金 Cloud Load Balancing の料金体系 計算例 計算条件 計算式 ロードバランサーの選び方 9 種類からの選択 Global vs Regional Global vs Regional の留意点 新型 vs 従来型 External Application Load Balancer の機能 バックエンドへの負荷分散 ヘルスチェック トラフィック管理 SSL/TLS SSL/TLS の終端 (オフロード) Google マネージド証明書 バックエンドまでの暗号化 耐障害性 プロキシと HTTP ヘッダー ロギング モニタリング Cloud CDN と Cloud Armor プレミアムティアとスタンダードティア Google のネットワークティア ロードバランサーの利用するティア プレミアムティアの挙動 External Application Load Balancer の内部構成（アーキテクチャ） アーキテクチャの概要 転送ルール（Forwarding rule） ターゲットプロキシ（Target proxy） URL マップ（URL map） バックエンドサービス / バックエンドバケット Web コンソールの表記 高度なアーキテクチャ VPC・プロジェクトをまたぐ負荷分散 グローバルな可用性 サービスの概要 Cloud Load Balancing とは Cloud Load Balancing とは Google Cloud が提供する仮想的なロードバランサです。 クライアントからのリクエストを受け、背後にある複数の Compute Engine VM や Cloud Storage バケット等にトラフィックを負荷分散 (ロードバランス) します。 Cloud Load Balancing は仮想的・論理的な存在であり、 分散型アーキテクチャ です。また フルマネージドサービス でもあります。そのため、我々利用者はインフラを考慮・管理する必要がありません。 毎秒 100 万件以上のリクエストに対応でき、安定した高パフォーマンス・低レイテンシが提供されます。 またスケーリングも自動的に行われます。トラフィックがゼロの状態から例え急激なスパイクが発生しても対応できます。プレウォーミング (暖機運転) も必要ありません。 ロードバランサーの種類 Cloud Load Balancing には9種類の用途別のロードバランサーが用意されており、適切なものを選択して利用することになります。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer Regional internal Application Load Balancer Global external proxy Network Load Balancer Regional external proxy Network Load Balancer Regional internal proxy Network Load Balancer Regional external passthrough Network Load Balancer Regional internal passthrough Network Load Balancer 種類が多く難しいようですが「Global か Regional か」「External か Internal か」「Application か Network か (プロトコル)」「プロキシ型かパススルー型か」といった軸で別れています。 名称変更 Cloud Load Balancing は 2023/06/21 にリブランディングが行われ、旧名称から変更されました。 これまで10種類だったロードバランサは9種類に統合され HTTP(S) トラフィックを扱う Application Load Balancer とその他の TCP/UDP トラフィックを扱う Network Load Balancer に大別できるようになりました。 Cloud Load Balancing の名称変更 なお当記事で扱う External Application Load Balancer は、従来でいう External HTTP(S) Load Balancing に当たります。 External Application Load Balancer とは 9 種類のロードバランサーのうち、当記事では以下の 3 つを総称して External Application Load Balancer (外部アプリケーションロードバランサ) として解説します。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer External Application Load Balancer は「外部向け (External)」の「HTTP(S) プロトコル」用ロードバランサの総称です。パブリック IP アドレスを持っており インターネットからのリクエスト を受け付けます。これが「外部 (External)」の意味です。 また External Application Load Balancer は「プロキシ型」であり TCP コネクションをいったんロードバランサーで終端 します。 その後、再度バックエンドの VM 等に TCP コネクションを作成します。そのため、バックエンドから見ると 接続元 IP アドレスはロードバランサになります 。 また「レイヤ 7」ロードバランサーであり、対応しているプロトコルは HTTP / HTTPS です。使える TCP ポート番号は 80/8080 (HTTP) と 443 (HTTPS) のみであり、その他のプロトコルやポート番号を使いたい場合は別のロードバランサを選択します。 3 種類の External Application Load Balancer 当記事で取り上げる以下の 3 種類のロードバランサーの違いについて説明します。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer 1. Global external Application Load Balancer と 2. Global external Application Load Balancer (Classic) は新型・旧型の関係であり、細かい違いがあるものの基本的には同じ理解が適用できます。 1. Global external Application Load Balancer と 3. Regional external Application Load Balancer の違いは、Global か Regional かです。 Global は、複数のリージョン (世界中) にフロントエンドが分散しています。世界中のユーザーは、自動的に最も近いフロントエンドにルーティングされ、最適なネットワーク経路を辿ってバックエンドまで到達できます (プレミアムティアの場合。後述) 。 Regional は、特定のリージョンにのみフロントエンドを配置します。バックエンドが同一のリージョン内に存在するためスタンダードティアネットワークを使って料金を抑えたい (後述) 場合や、法令遵守のためにトラフィックを特定のリージョンに留めたい場合に用います。 ユースケース External Application Load Balancer が活躍する最も代表的なケースは以下のような、Web/AP サーバへのリクエストの振り分けです。 Web/AP サーバへのリクエスト振り分け ロードバランサの配下の Compute Engine VM は インスタンスグループ でまとめられており、オートスケーリングを設定することもできます。この場合、負荷状況に応じてインスタンスが増減し、自動的にロードバランサーがトラフィックを振り分けます。 その他にも複雑なユースケースが考えられます。以下の参考ドキュメントもご参照ください。 参考 : 外部アプリケーション ロードバランサのユースケース 料金 Cloud Load Balancing の料金体系 Cloud Load Balancing の料金 は「 内部 (Internal) の Application Load Balancer」と「それ以外」で料金体系が異なります。当記事でご紹介しているのは 3 つとも Application Load Balancer ですので、同じ料金の計算方法が適用できます。 Application Load Balancer の料金には以下の軸があります。 転送ルール数 × 利用時間 の従量課金 内向き (Inbound = Ingress) のデータ処理量 (GB) に応じた従量課金 外向き (Outbound = Egress) のデータ処理量 (GB) に応じた従量課金 1つ目の料金軸の 転送ルール (Forwarding rules) については後述しますが、簡単に言うとロードバランサーの「入り口」です。転送ルールの料金はロードバランサを構築後、存在し続けている限り発生すると考えればよいでしょう。 計算例 計算条件 大まかな料金のイメージを掴むために実際の例で計算してみます。 以下のような構成のロードバランサーの料金を試算してみます。 課金軸 数量 転送ルール HTTPS (443/tcp) / Premium tier 内向きトラフィック 1 KB のリクエストが 1000 万回 / 月 ≒ 10 GB 外向きトラフィック 0.1 MB のレスポンスが 1000 万回 / 月 ≒ 1,000 GB 計算式 記載の単価は2023年6月現在の Global external Application Load Balancer・東京リージョンのものです。最新の料金や詳細は必ず 公式の料金表 をご参照ください。 課金軸 計算式 計 転送ルール ( ※ ) $0.025 * 730h $18.25 /月 内向きトラフィック $0.012 * 10 GB $0.12 /月 外向きトラフィック $0.012 * 100 GB $1.2 /月 合計 $18.25 + $0.12 + $1.2 $19.57 / 月 ※ 最初の5ルールまでの範囲内とする なお、上記はロードバランサだけの料金であり、これに加えて Google Cloud のネットワーク外向き (Outbound = Egress) の 転送料金 が発生することに注意が必要です。上記の例では $0.14 * 100 GB で $14 となります。 ロードバランサーの選び方 9 種類からの選択 9 種類あるロードバランサーから適切な選択をするには、以下のドキュメントを参照します。 参考 : ロードバランサの選択 以下は同ドキュメントから引用したフローチャート図です。 このドキュメントと図に沿って適切なロードバランサーを選択するのが基本的な考え方になります。 公式ドキュメント から引用 当記事で取り上げる External Application Load Balancer は「バックエンドのサービスが提供するプロトコルが HTTP(S) である場合」に選択するロードバランサですので、最も利用機会が多いものとなります。 次に 3 つの External Application Load Balancer の中からどのように適切なロードバランサを選択するか、について解説します。 Global vs Regional 3種類ある External な Application Load Balancer は、以下のうち前者の2つが Global で、最後が Regional です。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Regional external Application Load Balancer 以下の 全て に当てはまる場合は Regional が選択できます。 サービス利用者が特定の国や地域だけである バックエンド (VM 等) が単一リージョンだけであり利用者の地域と一致している バックエンドサービスは Compute Engine Cloud Run GKE など Regional に対応しているサービスである Cloud CDN は使わない (将来も利用予定がない) 一方で以下の いずれか に当てはまる場合は Global なロードバランサーが適切です。 サービスの利用者が複数の国や地域に跨っている バックエンド (VM 等) が複数リージョンに跨っている バックエンドとして Cloud Functions App Engine Cloud Storage を使いたい (Regional では対応していない) Cloud CDN を使う (または将来使う可能性がある) Global vs Regional の留意点 見落としがちなポイントとして、 Global と Regional では対応しているバックエンドのサービスが異なることに注意が必要です。 3. Regional external Application Load Balancer ではバックエンドに Cloud Storage バケットや Cloud Functions 関数を指定することができません。 対応しているバックエンドを始め、ロードバランサー種別ごとの機能の差異は以下のドキュメントで確認できます。 参考 : ロードバランサの機能比較 新型 vs 従来型 Global を使おうと考えたとき、 1. Global external Application Load Balancer と 2. (Classic) は「新旧」の差ですので、原則的には新型である 1. を選択するべきです。 公式ドキュメントの詳細な機能比較を見て、従来型 ( 2. ) でしか実現できない要件がある場合のみ、従来型を選びます。 参考 : 機能の違い また、新型 ( 1. ) のほうが従来型より高度な信頼性・スケーラビリティを実現できるよう、アーキテクチャが改善されています。Google としては、従来型から新型への移行を推奨しています。 参考 : Increasing Resiliency with Load Balancers 参考 : グローバル外部アプリケーション ロードバランサへの移行を計画する External Application Load Balancer の機能 バックエンドへの負荷分散 External Application Load Balancer の最も基本的な機能は、インターネットからのトラフィックをバックエンドに負荷分散することです。 バックエンドとして以下のような多様な選択肢があります。 Compute Engine Cloud Storage Cloud Run App Engine Cloud Functions Google Kubernetes Engine (GKE) オンプレ (ハイブリッド NEG) ただし前述の通り Global か Regional かによって 利用可能なバックエンド が異なりますので注意が必要です。 ヘルスチェック 配下のインスタンス等が障害を起こしてサービス停止状態になった場合、ロードバランサーはトラフィックを正常なインスタンスにのみ振り分けます。それには、ロードバランサーが配下のサービスが正常動作しているかを知る必要があります。 ロードバランサーからは定期的に ヘルスチェック が実行されます。例えば 1 分に一度、 HTTPS リクエストを各インスタンスに投げ、 200 OK を正常とみなすなどです。 ロードバランサーから配下のサービスへのヘルスチェックが通るようにするためには VPC ファイアウォール 等での許可設定が必要です。 External Application Load Balancer では以下の IP アドレスを接続元としたアクセスを許可する必要があります。 35.191.0.0/16 130.211.0.0/22 詳細な設定内容等は以下のドキュメントを参照してください。 参考 : ヘルスチェックの概要 トラフィック管理 外部ロードバランサには トラフィック管理機能 があり「トラフィックのミラーリング」「重み付けに基づくトラフィック分割」「リクエスト / レスポンス ベースのヘッダー変換」などを実現できます。大まかに分けると以下のようになります。 名称 概要 トラフィックステアリング HTTP(S) パラメータ (ホスト、パス、ヘッダー、その他のリクエスト パラメータ) に基づいたルーティング トラフィック アクション リクエストとレスポンスに基づいたリダイレクト、ヘッダー変換、URL 書き換えなどのアクション トラフィック ポリシー セッションアフィニティ、バランシングのアルゴリズムなどの指定 トラフィック管理は Cloud Load Balancing の最も強力な機能の一つです。 例えば「 通常のトラフィックは VM の Web サーバに振り分ける。 /image/* 以下の画像ファイルは Cloud Storage バケットに振り分ける 」のような振り分けも、簡単にできてしまいます。これによりストレージコストの削減とレスポンスの改善が実現されます。 ロードバランサにより実現可能な機能が細かく異なるため、詳細は以下をご参照ください。 参考 : グローバル外部アプリケーション ロードバランサのトラフィック管理の概要 参考 : 従来のアプリケーション ロードバランサにおけるトラフィック管理の概要 参考 : リージョン外部アプリケーション ロードバランサのトラフィック管理の概要 SSL/TLS SSL/TLS の終端 (オフロード) 今日の Web サービスでは HTTPS による通信の暗号化がほぼ必須と言えます。 Cloud Load Balancing では SSL/TLS の終端 (オフロード) が可能です。 自分で別途証明書を用意して セルフマネージド証明書 として Google Cloud にアップロードし、ロードバランサで利用することができます。 一方で Google Cloud から証明書を発行することもでき、これは Google マネージド証明書 と呼ばれます。 なお、ロードバランサ側で簡単に HTTP から HTTPS へのリダイレクトを設定 することができます。 Google マネージド証明書 Google Cloud 側で発行する SSL/TLS 証明書を Google マネージド証明書 と呼びます。 Google マネージド証明書は ドメイン検証（DV）証明書 です。また複数のドメイン名を登録することが可能ですが、ドメイン名にワイルドカードを使うことはできません (例 : *.example.com ) 。 ただし Google マネージド証明書は Regional のロードバランサでは使えないことに注意が必要です 。Google マネージド証明書が使えるのは、以下のロードバランサーのみです。 Global external Application Load Balancer Global external Application Load Balancer (Classic) Global external proxy Network Load Balancer (with a target SSL proxy) また Google マネージド証明書はエクスポートしたりダウンロードしたりすることは できません 。Cloud Load Balancing でのみ使用できる証明書です。 発行するには証明書のドメインの DNS ゾーンに Google から払い出された CNAME レコードを登録する、もしくはロードバランサーの IP アドレスを A レコードとして登録する必要があります。詳細な手順は以下を参照してください。 参考 : Google マネージド SSL 証明書を使用する バックエンドまでの暗号化 ロードバランサーが SSL/TLS を終端した後、ロードバランサとバックエンドの通信は非暗号化の HTTP プロトコルで通信させることができます。 この場合でも Google Cloud の標準の仕組みにより 通信は全て透過的に暗号化され ます ( ネットワークレベルの自動暗号化 ) 。 耐障害性 Cloud Load Balancing は分散アーキテクチャの仮想的なロードバランサであり、高い可用性を持ちます。 Global なロードバランサはその名の通り全リージョンに分散されているのでゾーンレベルの可用性に加えあるリージョン全体が万一停止しても可用性を維持できます。 Region のロードバランサは、選択したリージョン内の複数ゾーンに分散されるので、ゾーン停止に対しての可用性は維持されますがリージョン全体が停止した場合には利用できなくなります。 なお Cloud Load Balancing では Compute Engine サービスの一部の扱いで Service Level Agreement (SLA) が定義されており、詳細は以下のドキュメントで確認可能です。 参考 : Compute Engine Service Level Agreement (SLA) プロキシと HTTP ヘッダー External Application Load Balancer はプロキシ型のロードバランサであるため、一度 TCP 接続を終端します。つまりバックエンドのサーバから見ると IP ヘッダの送信元 IP アドレスはロードバランサーのものとなります。 これでは本来の接続元であるクライアントの IP アドレスを特定することはできません。 これに対処するため (こういったプロキシ型のロードバランサでは一般的ですが) HTTP リクエストに X-Forwarded-For ヘッダがロードバランサによって 追記されます 。 また他にも、ロードバランサまでの接続プロトコル (http or https) を示す X-Forwarded-Proto や Google サービスを経由したことを示す Via : 1.1 google なども付与されます。 これらはデフォルトでロードバランサによって付与されるヘッダですが、任意の カスタムヘッダ を付与するように指定することも可能です。 ロギング Cloud Load Balancing ではアクセスログを有効化して Cloud Logging に出力することができます。 ロードバランサーのコンポーネントの一つである バックエンドサービス / バックエンドバケット (後述) でデフォルトで有効化されています (バックエンド バケット では無効化不可) 。 ログを表示するには Cloud Logging コンソールや gcloud コマンドを利用します。また ログルーティング を用いて、ログをシームレスに BigQuery に投入することも可能です。 Cloud Load Balancing のログには例として以下のような要素が含まれます ( 詳細 ) 。 Key 名 概要 一般的な情報 重大度 / プロジェクト ID / タイムスタンプ等 HttpRequest requestUrl, userAgent, remoteIp, serverIp など HTTP リクエストに関する情報 ( 詳細 ) statusDetails 正常/異常終了時メッセージ。値としてキャッシュヒット有無 (正常時) やエラーの原因 (異常時) が入る モニタリング Cloud Load Balancing は Cloud Monitoring によって自動的にモニタリングされます。 External Application Load Balancer では 1 分毎に指標 (メトリクス) が Cloud Monitoring に送出され、6週間保持されます。 Cloud Monitoring の アラート機能 を使えば、指標に閾値を設定してアラートメールを発報する等の仕組みが簡単に実装できます。 以下はモニタリングされる指標の例です。詳細は 公式ドキュメント を確認してください。 指標名 概要 https/request_count ロードバランサによって処理されたリクエスト数 https/request_bytes_count クライアントからロードバランサへのリクエストとして送信されたバイト数 https/response_bytes_count ロードバランサからクライアントへのレスポンスとして送信されたバイト数 https/backend_latencies GFE がバックエンドに最初のリクエスト バイトを送信してから、バックエンドから最後のレスポンス バイトを受信するまでのレイテンシの分布 Cloud CDN と Cloud Armor Global な External Application Load Balancer では コンテンツ・デリバリ・ネットワークである Cloud CDN やマネージドな WAF である Cloud Armor が利用可能です。 一方で Regional external Application Load Balancer ではこれらの機能は使えません。 ただし、Cloud Armor については Regional external Application Load Balancer での利用が2023年6月に Public Preview 公開され、将来的に一般公開になる見込みです。 参考 : 外部アプリケーション ロードバランサの概要 プレミアムティアとスタンダードティア Google のネットワークティア Google Cloud のネットワークには プレミアムティア と スタンダードティア があります。 プレミアムティアは Google の持つグローバルネットワークを使用するものです。低レイテンシで信頼性の高いことが特徴で、世界中に 100 以上の接続点 (PoP) を持っています。一方のスタンダードティアは、通常のインターネット経由でのトラフィック配信です。 Google Cloud のネットワークティアでは Google Cloud から 出ていくトラフィック量 (= ダウンロードされるデータサイズ) に対して料金が発生します。スタンダードティアのほうがプレミアムティアより安価な値段設定となっていますが、パフォーマンスは劣ります。 参考 : Network Service Tiers の概要 ロードバランサーの利用するティア ロードバランサーの種別によって利用されるティアが異なり、以下のようになっています。 ロードバランサー種別 プレミアムティア スタンダードティア Global external Application Load Balancer ◯ ✕ Global external Application Load Balancer (Classic) ◯ ◯ Regional external Application Load Balancer ✕ ◯ 2. Global external Application Load Balancer (Classic) でのみ、プレミアムとスタンダードから選択できるようになっています。スタンダードを選択した場合は、ロードバランサーのフロントエンドを配置するリージョンを選択することになり、実質的にリージョナルな挙動をしますし、バックエンドもフロントエンドと同じリージョンにある必要があります。 ※このときの Regional external Application Load Balancer との違いは、バックエンドの VPC ネットワークを選ばないという点です ( 参考 )。 プレミアムティアの挙動 プレミアムティアを用いたロードバランサでは エニーキャスト IP アドレス が用いられます。 Google の持つ世界中の PoP の中からクライアントに一番近い PoP が選択されトラフィックが Google のネットワークに入ることで、最適なネットワーク経路が選択されて高いパフォーマンスが発揮されます。その代わり、ダウンロード方向のトラフィックの課金が割高となります。 参考 : All networking pricing このプレミアムティアの利用により、世界中からのトラフィックの経路を最適化できるのが、 Cloud Load Balancing の最大の特徴でもあります。 External Application Load Balancer の内部構成（アーキテクチャ） アーキテクチャの概要 Cloud Load Balancing では、内部的に Google Front End（GFE）、Envoy、Maglev、Andromeda といったテクノロジーが使われています。その実体は Google Cloud の世界中のロケーション（データセンター）に分散配置されています。 参考 : Cloud Load Balancing の概要 External Application Load Balancer の内部構造は、論理的には 4つのコンポーネント で構成されています。ロードバランサを構築・運用していくにあたり、これらの構成に対するある程度の理解が必要です。 転送ルール（Forwarding rule） ターゲットプロキシ（Target proxy） URL マップ（URL map） バックエンドサービス / バックエンドバケット Web コンソールや gcloud コマンドラインでロードバランサを構築したり管理するときにも、上記の用語が登場します。 Google Cloud の Web コンソールからロードバランサを構築する場合、ウィザードに沿って順番にパラメータを指定していくと、これら4つのコンポーネントが自動的に出来上がることになります。 External Application Load Balancer の内部構造 転送ルール（Forwarding rule） 転送ルール は、外部 IP アドレスを持ち、特定のポート・プロトコルをリッスンする（待ち受ける）コンポーネントです。転送ルールは、受け取ったトラフィックをターゲットプロキシ（次項で説明）へルーティングします。 参考 : 転送ルールと IP アドレス 外部ロードバランサを構築すると1つのパブリック IP アドレスが割り当てられますが、これは転送ルールに割り当てられているものです。もしロードバランサに対して www.example.com のようなドメイン名を割り当てる場合、 DNS で CNAME レコードを作り、この IP アドレスに向けることになります。 転送ルールは、待ち受けるポート番号とプロトコルも設定値として持ちます。なお HTTP(S) ロードバランサでは、HTTP では 80/tcp もしくは 8080/tcp 、 HTTPS では 443/tcp しか待ち受けられない仕様です。 また転送ルールには、 Global と Regional の区別、また Premium tier と Standard tier の区別があります。 ターゲットプロキシ（Target proxy） ターゲットプロキシ は、クライアントからの HTTP(S) 接続を終端するコンポーネントです。 参考 : ターゲットプロキシ ターゲットプロキシは、参照する URL マップ（次項で説明）を設定値として持っており、URL マップの設定に基づいてバックエンドサービス / バックエンドバケットにトラフィックを転送します。 前述したとおり、 HTTP リクエストにデフォルト / カスタムの追加ヘッダを付与するのは、このコンポーネントです。 証明書を保持して SSL/TLS を終端するのもこのコンポーネントです。なお Global なロードバランサーの場合、プロキシとバックエンドは異なるリージョンに配置することもできますが、前述の通りロードバランサとバックエンドの間は非暗号化プロトコルでも「ネットワークレベルの自動暗号化」が行われ、透過的に暗号化されます。 参考 : ロードバランサからバックエンドへの暗号化 URL マップ（URL map） URL マップ は、トラフィックルーティングのルール一覧です。前項のターゲットプロキシは、URL マップに定義された URL パターンに基づいて、バックエンドサービス / バックエンドバケットにトラフィックをルーティングします。 参考 : URL マップ 例として、URL マップには以下のような設定を定義できます。 デフォルトのバックエンドサービスを Compute Engine の Web サーバとする /images/* というパスへのアクセスが来たら静的ファイルを保持する Cloud Storage のバックエンドバケットに振り分ける バックエンドサービス / バックエンドバケット バックエンド サービス と バックエンド バケット （Backend service / Backend bucket）は、バックエンドの VM インスタンスや Cloud Storage バケットをグルーピングする論理的なリソースです。 参考 : バックエンド サービスとバックエンド バケット バックエンドサービスの実体として、インスタンスグループ（Compute Engine VM のグループ）を指定したり、サーバーレス NEG（Cloud Run / Cloud Functions / App Engine 等のグループ）指定したりできます。 またバックエンドに通信する際のプロトコル（HTTP、HTTPS、HTTP/2）を指定可能です。 前述のヘルスチェック機能の設定値を保持するのも、バックエンドサービスです。 130.211.0.0/22 か 35.191.0.0/16 の範囲からバックエンドサービスに対してヘルスチェックが行われますが、このときのプロトコルやパスも指定可能です。 Web コンソールの表記 ここまで、External Application Load Balancer を構成する4つのコンポーネントを紹介しました。 しかし、Google Cloud の Web コンソールからロードバランサを構築したり、あるいは設定を表示したりすると、前述の名称とは表記が異なっていることに気が付きます。これが Google Cloud のロードバランサーの理解を難しくしている要因でもあります。 分かりやすく表示するために、Web コンソール画面では4つのコンポーネントをまとめて「ロードバランサ」という1つの論理コンポーネントとして表現しています。 Web コンソールでロードバランサを構築するときの表記と、実際に API リソースとして存在するリソース構成との対照表は、以下のとおりです。 Web 画面での表現 実際のリソース フロントエンド 転送ルール + ターゲットプロキシ ルーティングルール URL マップ バックエンドサービス / バケット バックエンドサービス / バケット 図示すると以下のとおりです。 Web コンソールでの表現と実際のリソース構成の対照 また Web コンソールで構築すると「ロードバランサ」「フロントエンド」などに名称を入力しますが、実際のリソース名称への反映は以下のとおりです。 Web 画面での表現 リソース 「ロードバランサ」の名称 URL マップの名称となる。またターゲットプロキシの名称は ${ロードバランサ名称}-target-proxy となる 「フロントエンド」の名称 転送ルールの名称となる 「バックエンドサービス / バケット」の名称 実際の「バックエンドサービス / バケット」のリソース名称は Web 画面と同じ なお、gcloud コマンドにより単独で URL マップを作成 ( gcloud compute url-maps create ) すると、その URL マップを何にも紐付けなくても、コンソール画面上には「ロードバランサ」として表示されます。 コンソールでは URL マップが「ロードバランサ」として扱われている 高度なアーキテクチャ VPC・プロジェクトをまたぐ負荷分散 External Application Load Balancer では共有 VPC (Shared VPC) を用いることで、VPC ネットワークやプロジェクトをまたいだ負荷分散を行うことができます。 ロードバランサ自体 (転送ルール / ターゲットプロキシ / URL マップ) はホストプロジェクト (共有 VPC の親プロジェクト) またはサービスプロジェクト (共有 VPC を利用する側のプロジェクト) のいずれにも作成できます。一方のバックエンド (負荷分散先の VM 等) は、これらロードバランサ本体コンポーネントと同じプロジェクトに作成することもできますし、他のプロジェクトに作成することもできます。 参考 : Shared VPC architecture グローバルな可用性 特に External Load Balancer で非常に高度な対障害性を得たい場合、以下のようなアーキテクチャも提唱されています。 メインのトラフィックは Global external Application Load Balancer で処理する Regional external Application Load Balancer を各リージョンに配置する 障害時は Global から Regional へ振り分け先をフェイルオーバする Global external Application Load Balancer と Regional external Application Load Balancer はそれぞれ独立した基盤のうえで稼働しているため、片方の大規模障害がもう片方に影響しないという利点があります。そのため、こういったアーキテクチャが可能となっています。 参考 : Increasing Resiliency with Load Balancers なお補足情報として、Google Cloud のフルマネージドサービスである Cloud DNS には ヘルスチェック機能 がありますが Internal passthrough Network Load Balancer と internal Application Load Balancer にしか対応していないため、上記のアーキテクチャで障害時に Global から Regional への自動フェイルオーバさせるためには、Cloud DNS 以外の仕組みでヘルスチェック・自動フェイルオーバを構築する必要があります。 参考 : Manage DNS routing policies and health checks 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では、 Google Cloud (旧称: GCP ) の サーバーレスなコンテナ実行基盤である Cloud Run にデプロイしたサービスに対して、許可された Google アカウントだけがアクセスできるように、 Identity-Aware Proxy を用いたアクセス制限を設定していきます。 さらに、 Cloud Armor を使用することで、サービスのアクセス元ネットワークの IP アドレス範囲を制限します。 アーキテクチャ 構成図 使用するサービス Cloud Run Cloud Load Balancing Identity-Aware Proxy Cloud Armor Cloud Run サービスの作成 IP アドレスの確保と DNS 設定 HTTPS Load Balancing の設定 ロードバランサの種類を選択する ロードバランサのフロントエンドを構成する ロードバランサのバックエンドを構成する SSL/TLS 証明書のプロビジョニング状態を確認する IAP の設定 OAuth 同意画面を設定する ロードバランサに対して IAP を有効化する ユーザーに対して IAP 経由のアクセスを許可する IAP が Cloud Run サービスに対して認証できるようにする IAP 有効化を確認する Cloud Armor の設定 Cloud Armor ポリシーを作成する ポリシーの適用を確認する アーキテクチャ 構成図 当記事では、社内向けの Web サービスを想定し、Cloud Run で実行するサービスの前段にロードバランサを配置して、 IAP によるユーザー認証機能 と Cloud Armor による アクセス元 IP アドレス制限 を実装します。 Cloud Run がサーバーレスの特性を持つため、非常に安価に社内向けサービスを構築することができます。 構成図 使用するサービス 当記事で主に使用する Google Cloud のサービスは以下の 4 つです。 いずれも、ユーザによるインフラの管理が不要なマネージドサービスとなります。 Cloud Run Cloud Run はサーバーレスな環境でコンテナを実行できるサービスです。 サービスの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Cloud Load Balancing Cloud Load Balancing は、レイヤ 4 、レイヤ 7 のトラフィック分割を提供する、マネージドなロードバランサです。 Cloud Run サービスに対して、後述する Identity-Aware Proxy や Cloud Armor を使用したアクセス制御を行いたい場合、フロントエンドに Cloud Load Balancing の 1 つである、 HTTP(S) ロードバランサ を使用する必要があります。 当記事で使用する グローバル外部 HTTP(S) ロードバランサ は、単一の外部 IP アドレスを用いてグローバルな (リージョンを跨いだ) トラフィック分割を実現できる、プロキシベースのレイヤ 7 ロードバランサです。 ロードバランサのバックエンドとして Cloud Run を使用する場合、Cloud Run サービスを サーバーレス ネットワーク エンドポイント グループ ( サーバーレス NEG ) として設定します。 外部 HTTP(S) ロードバランサの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Identity-Aware Proxy Identity-Aware Proxy ( 以下、 IAP と記載 ) は、Web アプリケーションや、仮想マシンなどのクラウドリソースに対して、アプリケーションレベルの認証機能を提供するサービスです。 IAP を用いることで、Web アプリケーションや仮想マシンにアクセスできるユーザーを、IAP を利用できる IAM ロール がアタッチされた組織内 Google アカウント / グループ に制限することができます。 Cloud Armor Cloud Armor は Google 製のクラウド型 WAF ( Web Application Firewall ) を利用できるサービスです。 Cloud Load Balancing に対して設定することで、DDoS 保護機能や、セキュリティポリシーによるネットワークアクセス元の制限など、ロードバランサの背後にあるサービスを保護する機能が提供されます。 Cloud Armor の詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run サービスの作成 以降は、基本的には ドキュメント に記載されている手順を参考にしていきます。 まず、Cloud Run サービスを作成していきます。 当記事ではサービスに対するアクセス制御をメインに扱うので、コンテナはサンプルで用意されているものを使用します。 「 サンプル コンテナでテスト 」 をクリックすることで、サンプルのコンテナイメージが自動で選択されます。 サンプルコンテナの使用 内向きトラフィックの許可を設定する項目で「 内部 」を選択し、「 外部 HTTP(S) ロードバランサからのトラフィックを許可する 」にチェックを入れます。 これにより、Cloud Run サービスの URL に対して、インターネットからの直接アクセスができなくなります。 認証 項目では「 認証が必要 」を選択します。 後ほど、IAP から Cloud Run サービスに接続できるように、IAP のサービスアカウントに対して権限を付与します。 内向きトラフィックの許可と認証の設定 ここまで設定したら、あとはデフォルトの設定のまま Cloud Run サービスを作成します。 デプロイが完了したら、サービスの URL に対して直接アクセスできないことを確認します。 Cloud Run サービスの URL インターネットから直接サービスにアクセスすることはできない IP アドレスの確保と DNS 設定 ロードバランサのバックエンドとして Cloud Run のようなサーバレス NEG を使用する場合、通信プロトコルは HTTPS のみに制限されます。 そのためにロードバランサに設定する SSL/TLS 証明書は、 セルフマネージド SSL 証明書 と Google マネージド SSL 証明書 が使用できます（ 参考 ）。 今回は Google Cloud によって取得・管理される Google マネージド SSL 証明書を使用していきます。 Google マネージド SSL/TLS 証明書 は ドメイン認証型（DV） の証明書です。ロードバランサの IP アドレスを参照する A または AAAA レコードをドメインの DNS ゾーンに登録するだけで、Google がドメイン所有権を確認して、証明書が発行されます。 そこで、ロードバランサに使用する IP アドレスを事前に確保し、DNS レコードの設定を行っておきます。 ロードバランサは グローバル外部 HTTP(S) ロードバランサ を使用するため、タイプを グローバル に設定して IP アドレスを予約します。 ロードバランサ用の IP アドレスの確保 確保した IP アドレスを参照する A レコードを Cloud DNS に設定します。 確保した IP アドレスを Cloud DNS に設定 HTTPS Load Balancing の設定 ロードバランサの種類を選択する Cloud Run サービスの前段に配置するロードバランサを作成していきます。 ロードバランサの作成画面で「 HTTP(S) ロードバランシング 」を選択し、次の画面では「 インターネットから VM またはサーバーレス サービスへ 」と「 グローバル HTTP(S) ロードバランサ 」にチェックを入れます。 HTTP(S) ロードバランシングを選択 グローバル HTTP(S) ロードバランサを選択 ロードバランサのフロントエンドを構成する ロードバランサのフロントエンドを構成していきます。 プロトコル 項目に「 HTTPS（HTTP/2 を含む） 」を選択し、先ほど確保した IP アドレスを設定して、証明書を新規に作成していきます。 フロントエンドの構成 「 Google マネージドの証明書を作成する 」を選択し、 ドメイン 1 項目 に今回使用するドメイン名を入力します。 ここに入力したドメイン名で、ロードバランサに設定する IP アドレスを名前解決することができれば、ロードバランサ作成後に証明書のプロビジョニングが成功します。 証明書の作成 フロントエンドの構成は以上なので、次にバックエンドの構成をしていきます。 ロードバランサのバックエンドを構成する バックエンドサービスとして、Cloud Run を使用するサーバーレス NEG を作成していきます。 バックエンド タイプ 項目で「 サーバーレス ネットワーク エンドポイント グループ 」を選択し、 新しい バックエンド 項目でサーバーレス NEG を作成します。 バックエンドの構成 「 Cloud Run 」を選択し、始めに作成した Cloud Run サービスを選択します。 サーバーレス NEG の作成 サーバーレス NEG を作成したらバックエンドサービスとして設定し、ロードバランサを作成します。 バックエンドサービスを設定してロードバランサを作成 SSL/TLS 証明書のプロビジョニング状態を確認する 作成されたロードバランサの詳細画面から、証明書のステータスを確認していきます。 証明書の確認 ロードバランサの作成からしばらく待つと、証明書のステータスが ACTIVE になります。 証明書のステータスの確認 IAP の設定 ロードバランサ経由で Cloud Run サービスにアクセスできましたが、このままではインターネット上のすべてのユーザーがサービスにアクセスできてしまいます。 ここからロードバランサに対して IAP を設定し、組織内のユーザーのみがサービスにアクセスできるようにします（ 参考 ）。 OAuth 同意画面を設定する IAP を使用するためには、プロジェクトで OAuth 同意画面 を作成しておく必要があります。 User Type 項目に「 内部 」を選択し、 サポートメール 項目に自身のメールアドレスなどを入力して、任意のアプリケーション名を設定して保存します。 同意画面の作成 ロードバランサに対して IAP を有効化する 作成したロードバランサで IAP を使用するように設定します。 これで、Cloud Run サービスにログインする際に、Google アカウントの認証が要求されるようになります。 IAP の有効化 ユーザーに対して IAP 経由のアクセスを許可する IAP 経由のアクセスができるように、サービスにアクセスする組織内ユーザーに対して「 IAP-secured Web App User 」ロールを設定します。 IAP にプリンシパルを追加 IAP-secured Web App User ロールの付与 IAP が Cloud Run サービスに対して認証できるようにする プロジェクトごとに存在する IAP のサービスアカウントに対して、Cloud Run サービスを呼び出す権限を付与します。 IAP のサービスアカウントのプリンシパル名は以下のような形式になっています。 service-<プロジェクト番号>@gcp-sa-iap.iam.gserviceaccount.com ※プロジェクト番号は Google Cloud コンソールの Welcome ページ などで確認できます。 上記のプリンシパルに対して「Cloud Run 起動元」ロールを付与します。 Cloud Run にプリンシパルを追加 Cloud Run 起動元ロールの付与 IAP 有効化を確認する ロードバランサ経由で Cloud Run サービスにアクセスすると、Google アカウントのログイン画面が表示されるようになります。 先ほど IAP-secured Web App User ロールを付与した組織内ユーザーでログインします。 IAP 有効化の確認 サンプルのコンテナでは、サービスにアクセスすると以下のような画面が表示されます。 サンプルアプリケーションの表示 組織外の Google アカウントを使用してログインを試みると、以下のような画面が表示され、アクセスが拒否されます、 組織外の Google アカウントを使用した場合 Cloud Armor の設定 Cloud Armor ポリシーを作成する 最後に、ロードバランサに対して Cloud Armor を設定し、Cloud Run サービスにアクセスできる IP アドレス範囲を制限します。 バックエンド セキュリティポリシー で デフォルトのルール アクション を「 許可しない 」に設定し、許可ルールに一致しないアクセスはすべて拒否するようにします。 デフォルトの拒否ルールを設定 ルールの追加 から、許可ルールを設定していきます。 サービスへのアクセスを許可する IP アドレス範囲を設定し、 アクション 項目で「 許可 」を選択します。 優先度 は拒否ルールより小さい数字になっていればよいので、 1000 を設定しておきます。 許可ルールにサービスアクセスを許可する IP アドレスを設定 ターゲットへのポリシーの適用 項目でロードバランサ作成時に設定したバックエンドサービスを選択し、Cloud Armor ポリシーを作成します。 ロードバランサのバックエンドサービスにポリシーを適用 ポリシーの適用を確認する Cloud Armor ポリシーにより、許可された IP アドレス範囲からしか Cloud Run サービスにアクセスできないことを確認します。 許可された IP アドレス範囲からアクセスした場合、IAP による Google アカウント認証のあと、サービスへのアクセスが成功します。 許可された IP アドレス範囲からのアクセス 許可されていない IP アドレス範囲からアクセスした場合は、エラー画面が表示されます。 許可されていない IP アドレス範囲からのアクセス これで、許可された IP アドレス範囲からアクセスし、かつ サービスへのアクセスが許可された Google アカウントを持つ組織内ユーザーのみが、Cloud Run サービスにアクセスできるようになりました。 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。最近は Dataflow を勉強中。 Follow @sasashun0805

G-gen の荒井です。 当記事ではGoogle Cloud (旧称 GCP) で汎用的に利用される Windows Server について、日本語化する手順をご紹介します。 なぜ日本語化が必要か システム環境 Windows Server 日本語化手順 手順1 日本語パックのインストールと適用 手順2 タイムゾーン 手順3 国と地域 手順4 システムロケール 手順5 表示言語と地域設定 手順6 ハードウェア キーボード レイアウト 手順7 プロファイル 参考情報 レジストリ変更 タスクバー キーボードタイプ変更 なぜ日本語化が必要か Google Cloud (旧称 GCP) で Windows Server を利用する場合、Windows OS イメージはデフォルトで英語設定となっております。（2022年8月25日時点） そのため Windows Server の言語設定を日本語に変更する必要があります。 日本語設定を行わずに運用した場合、導入アプリケーションによっては文字化けや不整合が発生し、想定した挙動にならない場合がありますので、ご注意ください。 システム環境 今回のシステム環境は以下の通りです。 クライアント環境、特にリモートデスクトップアプリケーションによっては、アプリケーション固有設定でキーボード設定などが別途必要な場合があります。 日本語化するサーバー Windows Server 2022 Datacentar 21H2（英語OS） PowerShell Version : 5.1.20348.859 ※ Google Cloud 上の Compute Engine で動作 クライアント環境 Windows 10 Professional 21H2（日本語OS） リモートデスクトップ接続（Windows標準アプリケーション） Windows Server 日本語化手順 設定方法については、効率を重視しGUIとCLIの作業を併用します。 手順1 日本語パックのインストールと適用 日本語パックのインストールと適用を行います。 本手順はコマンドでも実行可能ですが、コマンドが多くなることと時間もかかってしまうためGUIで進めます。 Windows（右クリック） > Run ms-settings:regionlanguage と入力し OK Language > Add a language 日本語 > Next チェックボックスを全て有効 > Install インストールが開始されます。 インストール完了後、サインアウトの確認画面が表示されるので Yes, sign out now でサインアウトを行います。 再度サインインし、言語が日本語になっていることを確認します。 念のため、PowerShell からも実行結果を確認してみます。 ※ Power Shell を起動する際は 管理者として実行 を選択してください 万が一設定が反映されていない場合 Set-WinUserLanguageList -LanguageList ja-JP,en-US -Force で設定を行ってください。 実行するコマンド 説明 Get-WinUserLanguageList 現在のユーザー アカウントの言語リストと関連プロパティの設定情報を確認 Set-WinUserLanguageList -LanguageList ja-JP,en-US -Force 現在のユーザー アカウントの言語リストとプロパティを日本語に設定 PowerShell 実行結果 PS C:\Windows\system32> Get-WinUserLanguageList LanguageTag : ja Autonym : 日本語 EnglishName : Japanese LocalizedName : Japanese ScriptName : Japanese InputMethodTips : {0411:{03B5835F-F03C-411B-9CE2-AA23E1171E36}{A76C93D9-5523-4E90-AAFA-4DB112F9AC76}} Spellchecking : True Handwriting : True LanguageTag : en-US Autonym : English (United States) EnglishName : English LocalizedName : English (United States) ScriptName : Latin InputMethodTips : {0409:00000409} Spellchecking : True Handwriting : False #設定が反映されていない場合、以下を実行 PS C:\Windows\system32> Set-WinUserLanguageList -LanguageList ja-JP,en-US -Force GUI上での変更箇所 手順2 タイムゾーン 本手順は、PowerShell で進めます。 タイムゾーンを設定します。 実行するコマンド 説明 Get-TimeZone タイムゾーンの設定情報を確認 Set-TimeZone -Id "Tokyo Standard Time" タイムゾーンを (UTC+09:00) Osaka, Sapporo, Tokyo に変更 PowerShell 実行結果 PS C:\Windows\system32> Get-TimeZone Id : Greenwich Standard Time DisplayName : (UTC+00:00) Monrovia, Reykjavik StandardName : Greenwich Standard Time DaylightName : Greenwich Daylight Time BaseUtcOffset : 00:00:00 SupportsDaylightSavingTime : False PS C:\Windows\system32> Set-TimeZone -Id "Tokyo Standard Time" PS C:\Windows\system32> Get-TimeZone Id : Tokyo Standard Time DisplayName : (UTC+09:00) Osaka, Sapporo, Tokyo StandardName : Tokyo Standard Time DaylightName : Tokyo Daylight Time BaseUtcOffset : 09:00:00 SupportsDaylightSavingTime : False GUI上での変更箇所 手順3 国と地域 本手順は、PowerShell で進めます。 国と地域を設定します。 実行するコマンド 説明 Get-WinHomeLocation 国と地域の設定情報を確認 Set-WinHomeLocation 122 国と地域を 日本 に変更 PowerShell 実行結果 PS C:\Windows\system32> Get-WinHomeLocation GeoId HomeLocation ----- ------------ 244 United States PS C:\Windows\system32> Set-WinHomeLocation 122 PS C:\Windows\system32> Get-WinHomeLocation GeoId HomeLocation ----- ------------ 122 Japan GUI上での変更箇所 手順4 システムロケール 本手順は、PowerShell で進めます。 システムロケールを設定します。 実行するコマンド 説明 Get-WinSystemLocale システムロケールの設定情報を確認 Set-WinSystemLocale -SystemLocale ja-JP システムロケールを 日本語（日本） に変更 Restart-Computer システムを再起動 PowerShell 実行結果 PS C:\Windows\system32> Get-WinSystemLocale LCID Name DisplayName ---- ---- ----------- 1033 en-US English (United States) PS C:\Windows\system32> Set-WinSystemLocale -SystemLocale ja-JP #再起動後に適用されるため、再起動を実施 PS C:\Windows\system32> Restart-Computer PS C:\Windows\system32> Get-WinSystemLocale LCID Name DisplayName ---- ---- ----------- 1041 ja-JP 日本語 (日本) GUI上での変更箇所 手順5 表示言語と地域設定 本手順は、PowerShell で進めます。 表示言語と地域設定を設定します。 実行するコマンド 説明 Get-WinUILanguageOverride 表示言語と地域設定の設定情報を確認 Set-WinUILanguageOverride -Language ja-JP 表示言語と地域設定を 日本語 に変更 PowerShell 実行結果 PS C:\Windows\system32> Set-WinUILanguageOverride -Language ja-JP PS C:\Windows\system32> Get-WinUILanguageOverride LCID Name DisplayName ---- ---- ----------- 17 ja 日本語 GUI上での変更箇所 手順6 ハードウェア キーボード レイアウト 本手順は、GUI で進めます。 ハードウェア キーボード の レイアウト を変更します。 Windows（右クリック） > Run ms-settings:regionlanguage と入力し OK 日本語 > オプション レイアウトを変更する 日本語キーボード（106/109 キー） > 今すぐ再起動する 手順7 プロファイル 本手順は、PowerShell と GUI で進めます。 ようこそ画面、新規ユーザー向けにプロファイルをコピーします。 実行するコマンド 説明 Control international 表示言語と地域設定の設定情報を確認 PowerShell 実行結果 PS C:\Windows\system32> Control international 上記コマンド実行後 地域 ダイアログボックスがポップアップされます。 管理 > 設定のコピー 現在の設定のコピー先 のチェックボックスを両方有効にする > OK 今すぐ再起動 以上で、Windows Server の日本語化は完了です。 参考情報 リモートデスクトップアプリケーションとの相性により、日本語キーボードのレイアウトが適用されていない場合があります。 次の手順を実施することでキーボードレイアウトが適用されることがありますが、レジストリの変更を伴うためシステム環境にご注意いただき作業の実施をお願いいたします。 レジストリ変更 Windows（右クリック） > ファイル名を指定して実行 regedit と入力し OK レジストリパス HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\00000411 レジストリの値を以下の通り変更 設定項目 パラメータ 値の名前 Layout File 値のデータ KBDJPN.DDL を kbd106.dll に変更 タスクバー キーボードタイプ変更 タスクバーの入力方式を 日本語 Microsoft IME に変更 荒井 雄基 (記事一覧) クラウドソリューション部 オンプレ環境のネットワーク・サーバーシステムを主戦場としていましたが、クラウド領域にシフト。まだまだ駆け出しなので、みなさんと一緒に勉強をしていきたいです！ 最近の楽しみは、子供と遊ぶこととマイホーム計画を進めること。

今回は Eventarcトリガーを利用して、Cloud Storage のファイルメタデータを BigQuery へ格納してみました。 概要 作成するもの Eventarcとは？ Cloud Strage の準備 Cloud Storage トリガーとは Cloud Storage サービス アカウントへの権限付与 ファイルアップロード用のバケットの作成 BigQuery のテーブル作成 Cloud Functions の作成 Cloud Functions の作成 main.py の内容 requirements.txt の内容 Cloud Functions サービスアカウントへの権限付与 動作確認 概要 作成するもの 今回のアーキテクチャは以下のとおりです。 ローカルから Cloud Strage にファイルをアップロード 1 を検知してEventarc トリガーが Cloud Functions を呼び出す Cloud Storage から受け取ったメタデータを BigQuery へ追加 Eventarcとは？ Eventarc とは、サーバーレスかつ標準化されたイベント配信により、Google Cloud を用いた イベントドリブンアーキテクチャ の構築が容易になるプロダクトです。 以下の記事で、 Eventarc の概要について説明しています。 blog.g-gen.co.jp Cloud Strage の準備 Cloud Storage トリガーとは Cloud Storage トリガー を使用することで、Cloud Strorage にファイルのアップロードや更新、削除などのイベントをトリガーして Cloud Functions (第一世代) を呼び出すことができます。 Cloud Functions (第二世代) から、Cloud Storage トリガーは Eventarc トリガーの一部として実装されます。 今回は、Cloud Functions (第二世代) で実装していきたいと思います。 Cloud Storage サービス アカウントへの権限付与 Cloud Storage トリガー を実行するには、Cloud Storage サービス アカウントに Pub/Sub パブリッシャー（roles/pubsub.publisher）を含むロールが必要です。（ 参考 ） 以下に、 Cloud Strage サービスエージェントへの権限付与手順 を説明します。 コンソールで、 Cloud Storage ＞ バケット ＞ 設定 へ移動 [ Cloud Storage サービス アカウント ] のメールアドレスをコピー コンソールで、 IAMと管理 ＞ IAM へ移動し、[ 追加 ]をクリック [ $Cloud Storage サービス アカウント ]に対し、[ Pub/Sub パブリッシャー ]ロールを追加 ファイルアップロード用のバケットの作成 コンソールで、 Cloud Storage ＞ バケット へ移動し、[ 作成 ] をクリック 任意のバケット名を入力 ロケーションタイプに[ Region ]を選択し、[ asia-northeast1(東京) ]を選択 その他はデフォルトのまま、[ 作成 ]をクリック 上記のように、作成したバケットが表示されてればOKです。 BigQuery のテーブル作成 Cloud APIs を用いて、Google Cloud 上のリソースを API 経由で操作できます。 今回は、その中でも BigQuery API 使用して、Cloud Functions からBigQuery 上のテーブルにデータをINSERTしていきます。 BigQuery API でデータセットとテーブルの作成もできてしまいますが、今回は事前にスキーマを定義した空のテーブル作成までコンソールで行いたいと思います。 以下に、 BigQuery テーブル作成手順 を説明します。 コンソールで、 BigQuery ＞ SQLワークスペース へ移動 ご自身のプロジェクトの[ ︙ ]から、[ データセットを作成 ]をクリック [ データセットID ]と[ データロケーション ]を選択し、[ データセットを作成 ]をクリック 3 で作成したデータセットの[ ︙ ]から、[ デーブルを作成 ]をクリック テーブル名とスキーマを入力したら[ デーブルを作成 ]をクリック Cloud Functions の作成 Eventarc トリガーから呼び出される Cloud Functions を作成します。 Cloud Functions の作成 以下に、 Cloud Functions の作成手順 を説明します。 コンソールで、 Cloud Functions へ移動し、[ 関数の作成 ] をクリック [ 環境 ]は[ 第２世代 ]を選択し、[ 関数名 ]と[ リージョン ]を入力 [ EVENTARC トリガーを追加 ]を選択し、[ イベントプロバイダ ]、[ イベント ]、[ バケット ]、[ サービスアカウント ]を入力し[ トリガーを保存 ]をクリック [ ランタイム環境変数 ]を設定 [ 次へ ]をクリック [ ランタイム ]に[ Python 3.9 ]を選択し、[ エントリポイント ]はデフォルトのまま、 main.py と rerequirements.txt のファイルをそれぞれ以下のコードに書き換え、[ デプロイ ]をクリック main.py の内容 BigQuery にデータを格納するため BigQuery API と、関数実行時に任意のログ出力を実装するため Cloud Logging API を使用しています。 import os import logging import google.cloud.logging import functions_framework from google.cloud import bigquery # ランタイム環境変数から[PROJECT_ID]と[TEBLE_ID]を取得 PROJECT_ID = os.environ.get( 'PROJECT_ID' ) TEBLE_ID = os.environ.get( 'TEBLE_ID' ) # Cloud Logging クライアントのインスタンス化 client = google.cloud.logging.Client() client.setup_logging() logger = logging.getLogger() logger.setLevel(logging.DEBUG) # エントリポイントに [ hello_gcs ] を設定 @ functions_framework.cloud_event def hello_gcs (cloud_event): # cloud_event の[ID]と[TYPE]を取得 event_id = cloud_event[ "id" ] event_type = cloud_event[ "type" ] # cloud_event からファイルのメタデータを取得 data = cloud_event.data content_type = data[ "contentType" ] bucket_name = data[ "bucket" ] file_name = data[ "name" ] created_date = data[ "timeCreated" ].split( '.' )[ 0 ] # DATETIME型に合わせるため形成 updated_date = data[ "updated" ].split( '.' )[ 0 ] # DATETIME型に合わせるため形成 # gcs_fanalized_list に cloud_event の[ID]と[TYPE]、各メタデータを格納 gcs_fanalized_list = [event_id, event_type, content_type, bucket_name, file_name, created_date, updated_date] insert_bq(gcs_fanalized_list) # BigQuery のデーブルにデータをINSERTする関数 def insert_bq (gcs_fanalized_list): # BigQuery クライアントのインスタンス化 client = bigquery.Client(project=PROJECT_ID) table = client.get_table(TEBLE_ID) # 行情報をリスト型で、さらに列情報を辞書型で記述 rows_to_insert = [ { "event_id" : gcs_fanalized_list[ 0 ], \ "event_type" : gcs_fanalized_list[ 1 ], \ "content_type" : gcs_fanalized_list[ 2 ], \ "bucket_name" : gcs_fanalized_list[ 3 ], \ "file_name" : gcs_fanalized_list[ 4 ], \ "created_date" : gcs_fanalized_list[ 5 ], \ "updated_date" : gcs_fanalized_list[ 6 ] } ] # 1行 7列 # client.insert_rows() の戻り値は、INSERTエラーがあればエラー情報を、INSERTエラーがなければ何もなし errors = client.insert_rows(table, rows_to_insert) if errors == []: # エラーがない場合はログに[success]と表示させる logger.debug( "success" ) else : # エラーがある場合はエラー内容を表示させる logger.debug(errors) requirements.txt の内容 コード内で使用するライブラリを記載します。 functions - framework==3.* google - cloud - logging==3.2.2 google - cloud - bigquery==3.3.2 今回 Eventarc トリガーのイベントとして[ google.cloud.storage.object.v1.finalized ]を選択しました。こちらは、新しいオブジェクトが作成されるか、既存のオブジェクトが上書きされ、そのオブジェクトの新しい世代が作成されるとイベントが実行されます。 他にもいくつかの イベントタイプ がサポートされています。 Cloud Functions サービスアカウントへの権限付与 合わせて、Cloud Functions から BigQuery にジョブが実行 できるようCloud Functions サービスアカウントにBigQuery ジョブユーザー（roles/bigquery.jobUser）権限を付与していきます。 コンソールで、 IAMと管理 ＞ IAM へ移動し、[追加]をクリック [ $Cloud Functions のサービスアカウント ]に対し、[ BigQuery ジョブユーザー ]ロールを追加 筆者は今回、Cloud Functions のデフォルトのサービスアカウント（Compute Engine default service account）に権限を付与しました。 動作確認 Cloud Storage にファイルをアップロードして、BigQuery のテーブルにファイルのメタデータが挿入されるか確認します。 ローカルにある「電子印.jpg」というファイルを、先程作成したバケットにアップロードしました。 BigQuery 上のテーブルを確認すると、1行目にデータが追加されていることを確認できました。 Cloud Logging でログを確認してみると、テーブルへのINSERTが成功した時に出力する[ success ]が記載されてました。 また、複数のファイルを同時にアップロードした場合の挙動も確認するため、3つのファイルを同時に Cloud Storage にアップロードしました。 BigQuery 上のテーブルを確認すると、2-4行目に新しいデータが追加されていることを確認できました。 こちらもログを確認してみると、同じく、テーブルへのINSERTが成功したことが確認できます。 ファイルを同時にアップロードした場合でも、1ファイル 1 関数 が実行されていたことがわかります。 Cloud Functions は関数の呼び出し回数でも課金が発生するため (毎月最初の200万回は無料) 、ファイル数が大きく増える際には Eventarc トリガーを使わず別のアーキテクチャを検討するのも良いかもしれません。 Eventarc トリガーを用いることで、Cloud Storageのイベントを検知して Cloud Functions を実行できたり、また Cloud SDK により Cloud APIs をコールすることで BigQuery と Cloud Logging を操作できました。 今後も積極的に Eventarc × Cloud APIs で イベントドリブンアーキテクチャ を試していきたいです。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

Google Cloud (旧称 GCP) の仮想サーバーサービスである Compute Engine へサーバーを移行する方法はいくつかあります。今回はその手法の一つである 手動インポート 機能を実際に使ってみました。 手動インポートとは？ 前提条件 移行元環境イメージ化 カスタムイメージ の作成 カスタムイメージからVMを構築 手動インポートとは？ Google Cloud の Compute Engine へサーバーを移行する方法は、以下のようなものがあります。 Migrate for Compute Engine 自動インポート 手動インポート このうち、当記事では手動インポートを実際にやってみます。 手動インポートでは、オンプレミスの既存サーバ（物理・仮想）のブートディスクをオンプレ環境側でイメージ化したあと Google Cloud のオブジェクトストレージサービスである Cloud Storage に 手動でインポート することで、 Compute Engine のカスタムイメージを作成することができます。 このカスタムイメージを使用して、 Google Cloud 上に Compute Engine VM を構築する事が出来ます。 前提条件 手動インポートを行うには前提条件が複数あります。 No 前提条件 詳細リンク 1 Linux である リンク 2 ブートディスクの容量が 2TB以下 である リンク 3 qemu-img check コマンドで問題がない リンク 4 イメージファイル名が disk.raw である リンク 5 単一のディスクである リンク 6 論理ボリュームマネージャ (LVM) で分割されたディスクではない リンク 7 quiet, rhgb, splashimage=** のコマンドライン引数が含まれていない リンク 8 シリアルコンソールを使用するためコマンドライン引数 console=ttyS0,38400n8d が追加されている リンク 移行元環境イメージ化 これからは、実際の手順を見ていきます。この記事では CentOS 8 での作業例をご紹介します。 初めに移行元環境の確認を行います。 ディスクイメージを作成するために 移行対象サーバ に ログイン し lsblk コマンドと df コマンド を使用して、イメージ 作成元ブートディスクの容量と、作成する イメージファイル を書き込むための十分な空き領域があることを確認します。 下記の例では vda がイメージ化対象のブートディスク、 vdb にマウントされている /tmp が作成したイメージを書き込む空き領域になります。 $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 10G 0 disk |_vda1 252:1 0 1G 0 part /boot |_vda2 252:2 0 9G 0 part |_cl-root 253:0 0 8G 0 lvm / |_cl-swap 253:1 0 1G 0 lvm [ SWAP ] vdb 252:16 0 50G 0 /tmp $ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 devtmpfs 646M 0 646M 0 % /dev tmpfs 663M 0 663M 0 % /dev/shm tmpfs 663M 8 .6M 655M 2 % /run tmpfs 663M 0 663M 0 % /sys/fs/cgroup /dev/mapper/cl-root 8 .0G 1 .4G 6 .7G 18 % / /dev/vda1 976M 135M 774M 15 % /boot tmpfs 133M 0 133M 0 % /run/user/ 0 /dev/vdb 50G 2 .8G 48G 6 % /tmp 確認して問題が無ければ、移行元VMのブートローダーが ブートローダー / GRUB 構成ファイルの前提条件 を満たしているか確認します。GRUB 構成ファイルを編集した場合は grub2-mkconfig コマンドで ブートローダーを再構成 します。 $ grub2-mkconfig -o /boot/grub2/grub.cfg ブートローダーの再構成が終われば、ブートディスクのイメージ化をします。カレントディレクトリを /tmp に移動し dd コマンドでブートディスクである /dev/vda を disk.raw というファイル名で /tmp 以下に作成します。 $ cd /tmp $ dd if =/dev/vda of =/tmp/disk.raw bs =4M conv =sparse イメージ化された disk.raw ファイルを tar コマンドにて /tmp 領域に compressed-image.tar.gz と言うファイル名で圧縮します。 $ tar --format = oldgnu -Sczf /tmp/compressed-image.tar.gz disk.raw 圧縮された compressed-image.tar.gz ファイルを クライアントPC にダウンロードしておきます。 カスタムイメージ の作成 Google Cloud コンソール を開き Cloud Storage に移動し バケットを作成 をクリックします。 バケット名 、 データの保存場所 を指定し、 ストレージ クラス は Standard を指定して 作成 をクリックします。 バケット が作成されると作成された新しいバケットに画面が移動するので ファイルをアップロード をクリックし、ダウンロードしておいた compressed-image.tar.gz をアップロードします。 Google Cloud コンソールで Compute Engine の画面の中にある イメージ ページに移動し イメージを作成 をクリックします。 名前に作成するイメージ名、ソース に Cloud Storage ファイル を選択し、作成したバケットにアップロードした compressed-image.tar.gz を指定して 作成 をクリックします。 以上でカスタムイメージの登録が完了しました。 カスタムイメージからVMを構築 Google Cloud コンソールで VM インスタンス ページに移動し インスタンスを作成 をクリックします。 VM 名 、 リージョン 、 マシンの構成 を選択します。 ブートディスクの 変更 をクリックします。 ブートディスクの選択画面で カスタムイメージ を選択し、登録した カスタムイメージ を含む プロジェクト を選択し、登録した カスタムイメージ を選択します。 ブートディスクの種類 、 サイズ（GB） を移行元サーバに合わせて設定し、 選択 をクリックします。 以上で、カスタムイメージ から VM を構築する準備が完了しましたので 作成 をクリックします。 構築が完了すると、 VM インスタンス一覧画面で作成した VM が起動していることを確認できます。 表示されている外部 IP 宛にターミナルで SSH ログインすると、今回手動インポートした移行元サーバが、 Google Cloud で起動しているのが確認できます。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

今回は、Google Cloud のビルドサービスであるCloud Build を使って、Cloud Functions のCD/CDパイプラインを構築してみました。 Cloud Build を用いた Cloud Functions のCI/CDパイプライン Cloud Build の概要 Cloud Build とは 実行方法 ライフサイクル 2つの利用パターン 料金 作成するもの Cloud Functions の作成 Cloud Build の作成 ビルドトリガーの作成 Github リポジトリを変更 Github からローカルにクローンを作成 開発用ブランチ（dev）を作成 Cloud Buildの構成ファイルを作成 コミット プッシュ mainブランチにdevブランチをマージ Cloud Build の確認 Cloud Build の概要 Cloud Build とは Cloud Build とは Google Cloud でビルドを実行するサーバレスかつマネージドなビルドサービスです。 Cloud Build は Github をはじめ様々なリポジトリサービスと連携し仕様に合わせてビルドを実行したり、Pub/Sub 等のイベントに応じてビルドを実行できます。 また、ビルドのみならず Cloud Run や Google Kubernetes Engine (GKE) 、 Cloud Functions へのデプロイにも Cloud Build が用いられます。 Cloud Build では ビルド構成ファイル と呼ばれる設定ファイルでビルドやデプロイの方法を指示します。構成ファイルの指示に基づき、コンテナが起動してタスクが自動的に実行される仕組みです。 実行方法 Cloud Build は、Google Cloud コンソールやgcloud CLI からも実行できますが、 ビルドトリガー を使用してビルドを実行することも可能です。 ビルドトリガーとは、GithubなどのソースリポジトリとCloud Build を連携しておくことで、ソースリポジトリに変更があった際、 Cloud Build を実行してビルドを自動化できる機能です。 ライフサイクル 一般的な Cloud Build のライフサイクルを以下に記載します。 Cloud Build の命令が含まれる YAML または JSON 形式のビルド構成ファイルを作成 Cloud Build にビルドを送信（または、ビルドトリガーが起動） Cloud Build はビルド構成ファイルに基づいてビルドを実行 2つの利用パターン Cloud Build には、 デフォルトプール と プライベートプール という2つの利用パターンがあります。 従来からあったデフォルトプールは、クラウド上でホスティングされたリソースにしか機能できないことが課題でした。 そこで、ユーザーのプライベートネットワーク内でもサーバレスのビルド環境を活用するためにプライベートプールがリリースされた背景があります。 プライベートプールではその他にも、マシンタイプを柔軟に選べたり、最大同時実行数が引き上げられたりと、デフォルトプールに比べカスタマイズ性が高いのも特徴です。 料金 Cloud Build はマシンタイプとビルドの実行時間（分単位）で料金が決まります。 デフォルトプールでは、以下のマシンタイプ毎に、1ビルド分あたりの料金が変わってきます。 また、e2-medium には無料枠があり、1日あたり120ビルド分が無料となります（2022年8月現在）。 ※クイックスタートとは、プロビジョニングの遅延なしにビルドを実行します。 プライベートプールでは、以下のマシンタイプ毎に、1ビルド分あたりの料金が変わってきます。 例として、デフォルトプールでマシンタイプがe2-medium の場合、1ヵ月での合計ビルド実行時間が4,500分 [1日あたり150分、1ヵ月は30日換算] だとすると 351円 / 月です（2022年8月時点、東京リージョン、130円/ドル）。 最新の利用料金は以下の公式ページでご確認ください。また、公式の見積もりツールで料金が試算できます。 Cloud Build の料金 Google Cloud Pricing Calculator 作成するもの 今回は、Cloud Functions のコード管理をGithub 上で行い、Github のmain ブランチの更新をトリガーに Cloud Functions へデプロイを自動化してくれる仕組みを構築したいと思います。 Cloud Functions の作成 まずはCloud Functions を新規作成していきます。 Cloud Functions ＞ 関数の作成 から、関数を新規作成します。 関数名は「cloud-build-demo」として、認証は「未認証の呼び出しを許可」にして、その他はそのままで次に進みます。 コードでは、ランタイムに「Pyrhon3.9」を選択し、その他はデフォルトのままデプロイします。 また、Github上にCloud Functions のデフォルトのソースコードを記述したcloud-build-demoリポジトリを作成しておきます。 Cloud Build の作成 ビルドトリガーの作成 Cloud Build ＞ トリガー から、ビルドトリガーを作成します。 名前を「cloud-build-demo」とし、ソースのリポジトリから「新しいリポジトリに接続」を選択します。 Githubを選択すると認証画面に切り替わりますので認証を済ませると、Githubの「アカウント」と「リポジトリ」を選択できます。 対象のGithubアカウントとリポジトリを選択して接続します。 これでビルドトリガー の設定は完了です。 Github リポジトリを変更 Github からローカルにクローンを作成 ローカル環境にクローンを作成して、ローカルでファイルの追加や編集を行っていきます。 対象リポジトリのリモートURLをコピーして、ターミナルから以下を実行します。 matayuuu@penguin:~$ git clone https://github.com/ggen-matayuuu/cloud-build-demo.git Cloning into ' cloud-build-demo ' ... remote: Enumerating objects: 4 , done . remote: Counting objects: 100 % ( 4 / 4 ) , done . remote: Compressing objects: 100 % ( 4 / 4 ) , done . remote: Total 4 ( delta 0 ) , reused 0 ( delta 0 ) , pack-reused 0 Receiving objects: 100 % ( 4 / 4 ) , done . クローンが作成されたことを確認します。 matayuuu@penguin:~$ ls cloud-build-demo 開発用ブランチ（dev）を作成 次に、開発用ブランチを作成します。 まずは、クローンしたディレクトリへ移動します。 matayuuu@penguin:~$ cd cloud-build-demo matayuuu@penguin:~/cloud-build-demo$ # ブランチ一覧を表示（*がついているのが現在いるブランチ） matayuuu@penguin:~/cloud-build-demo$ git branch *main # 開発用ブランチを作成 matayuuu@penguin:~/cloud-build-demo$ git branch dev # ブランチ一覧を表示（確認） matayuuu@penguin:~/cloud-build-demo$ git branch dev *main # 開発用ブランチに移動 matayuuu@penguin:~/cloud-build-demo$ git checkout dev Switched to branch ‘dev’ # ブランチ一覧を表示（確認） matayuuu@penguin:~/cloud-build-demo$ git branch *dev main Cloud Buildの構成ファイルを作成 Cloud Functions のデプロイは gcloud functions deploy コマンドを使用して関数をデプロイできるため、Cloud Build から gcloud functions deploy コマンドを実行させるよう構成ファイルのビルドステップを作成します。 今回の構成ファイルは、main.py と同階層に、ファイル名を「cloudbuild.yaml」として作成します。 構成ファイルの記述方法は、 こちら の公式リファレンスを参考にしました。 「cloudbuild.yaml」には以下のビルドステップを記述しました。 steps : - name : 'gcr.io/google.com/cloudsdktool/cloud-sdk' args : - gcloud - functions - deploy - cloud-build-demo - --region=us-central1 - --source=. - --trigger-http - --runtime=python39 また、変更箇所がわかるようにmain.py のreturn（戻り値）を「Hello World!matayuuu!」に修正しました。 def hello_world (request): """Responds to any HTTP request. Args: request (flask.Request): HTTP request object. Returns: The response text or any set of values that can be turned into a Response object using `make_response <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>`. """ request_json = request.get_json() if request.args and 'message' in request.args: return request.args.get( 'message' ) elif request_json and 'message' in request_json: return request_json[ 'message' ] else : return f 'Hello World!matayuuu!' コミット まずは今いるディレクトリ配下の全ての変更箇所を保存します。 # 追加・変更ファイルの保存 matayuuu@penguin:~/cloud-build-demo$ git add ./ # 追加・変更したファイルをGitに登録 matayuuu@penguin:~/cloud-build-demo$ git commit -m " created cloudbuild.yaml and modified main.py " [ dev bdf826f ] created cloudbuild.yaml and modified main.py 1 file changed, 11 insertions ( + ) create mode 100644 cloudbuild.yaml プッシュ # Githubへプッシュ matayuuu@penguin:~/cloud-build-demo$ git push origin dev Enumerating objects: 4 , done . Counting objects: 100 % ( 4 / 4 ) , done . Delta compression using up to 8 threads Compressing objects: 100 % ( 3 / 3 ) , done . Writing objects: 100 % ( 3 / 3 ) , 473 bytes | 157 . 00 KiB/s, done . Total 3 ( delta 0 ) , reused 0 ( delta 0 ) , pack-reused 0 remote: remote: Create a pull request for ' dev ' on GitHub by visiting: remote: https://github.com/ggen-matayuuu/cloud-build-demo/pull/new/dev remote: To https://github.com/ggen-matayuuu/cloud-build-demo.git * [ new branch ] dev - > dev mainブランチにdevブランチをマージ # mainブランチに移動 matayuuu@penguin:~/cloud-build-demo$ git checkout main Switched to branch ' main ' Your branch is up to date with ' origin/main ' . # mainブランチにdevブランチをマージ matayuuu@penguin:~/cloud-build-demo$ git merge dev Updating 9e27d6a..bdf826f Fast-forward cloudbuild.yaml | 11 +++++++++++ 1 file changed, 11 insertions ( + ) create mode 100644 cloudbuild.yaml 無事、Githubのリポジトリが更新されました。 Cloud Build の確認 Github のmain ブランチが変更された為、Cloud Build のログを確認します。 ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Permission 'cloudfunctions.functions.get' denied on resource 'projects/matayuuu/locations/us - central1/functions/cloud - build - demo' (or resource may not exist).] ビルドトリガーは実行されていましたが、ビルドステップ中にエラーが発生しました。 エラーログによると、Cloud Build サービス アカウントに「cloudfunctions.functions.get 」という権限が不足しているとのことでした。 Cloud Build ＞ 設定 より、Cloud Functions のステータスを「有効にする」に変更し、「すべてのサービスアカウントにアクセス権を付与」を選択すると Cloud Build のサービスアカウントに Cloud Functions 開発者 の権限が付与されます。 再度、Githubのリポジトリを変更し、Cloud Build をトリガーしたいと思います。 ローカル側のmain.py の戻り値を「Hello World!matayuuu!g-gen!」に変更して、先程の要領で Github にプッシュしました。 Github 上のmain ブランチの変更により、Cloud Build が実行されます。 再度、ログを確認すると、ビルド成功です。 念の為、Cloud Functions のソースも確認すると変更箇所も反映されてました。 Cloud Build を用いると、リポジトリの変更をトリガーにデプロイの自動化を実現できるため、デプロイ工数が削減できました。 Cloud Functionsだけでなく、Google Cloud のさまざまなサービスと容易に連携ができるので、今後は積極的に活用していきたいです。 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

こんにちは！G-genの片岡です。本記事では、Cloud Monitoring で利用可能な監視の静観設定(Snooze)について見ていきます。 ノイズアラートをどう抑止するか、頭を悩ませていた日々から開放される日も近そうですね！ Cloud Monitoring 振り返り モニタリング Ops エージェント Ops エージェントのセットアップ アラート設定 1．CPU utilization 2．Memory utilization 3．稼働時間チェック 動作確認 1．CPU負荷をかけてみる 2．メモリ負荷をかけてみる 3．VMインスタンスを停止してみる 静観設定(Snooze)設定 Cloud Monitoring 振り返り Cloud Monitoring では、アラートポリシーを用いて、アラートを通知する条件と方法を定義することができます。 例えば Google Compute Engine (以下GCE) の運用において、VMの負荷や稼働状況を収集し、指定した条件に応じてメールやSlack 通知を行うことで、事象に素早く気付くことが可能となります。 Cloud Monitoring の概要及び基本機能については、以下の記事で解説しています。 blog.g-gen.co.jp モニタリング 今回は、GCE のリソースモニタリングとアラートの設定例を取り上げていきます。 検証用 VMは、Debian GNU/Linux 11 (bullseye)で、Apache2 HTTP Server をインストールした環境を利用しています。 Ops エージェント Cloud Monitoring はデフォルトで標準的な指標(Google Cloud の指標)を取得することができます。 一方で、 メモリ使用率 , ディスク使用率 , スワップ利用率 等は「Ops エージェント」を VM にインストールすることで取得可能となります。 " Google Cloud の指標 " で収集できる項目 " Ops エージェントの指標 " で収集できる項目 Monitoring ＞ ダッシュボード ＞ VM Instances を確認すると、作成した直後のVMはエージェントが "未検出” の状態です。 Opsエージェントがインストールされていない場合、 メモリ使用率 や ディスク使用率 の指標が取得できていません。 Ops エージェントのセットアップ 今回は こちら の手順を参考に、Opsエージェントのインストールを行っていきます。 インストールコマンドを実行後、数分でOpsエージェントが検出されます。 ＊インストール後、数分経ってもエージェントステータスが"未検出"の場合、VM にアタッチされているサービスアカウントに、以下のロールが付与されているかご確認ください。 モニタリング指標の書き込み (roles/monitoring.metricWriter) その他要件については、 こちら をご確認ください。 正常にインストールが完了すると、先程まで取得できていなかった メモリ使用率 や ディスク使用率 の指標が取得できています。 アラート設定 次の３つのポリシー作成を行います。 1."Google Cloud の指標" を用いた CPU utilization ポリシー 2."Ops エージェントの指標” を用いた Memory utilization ポリシー 3. 稼働時間チェックを用いたポリシー Monitoring ＞ アラート からポリシーの作成を行います。 1．CPU utilization CPU使用率がしきい値を超えた場合に、メール通知を行うポリシーを作成します。 アラート条件を指標から選択します。 本設定では、1分間のCPU 使用率をしきい値と比較します。 今回はしきい値を 80％より上 と定義しました。 通知チャンネルを設定します。今回はメールでの通知とします。 アラート ポリシー名 を設定します。 2．Memory utilization メモリ使用率がしきい値を超えた場合に、メール通知を行うポリシーを作成します。 アラート条件を指標から選択します。 本設定では、1分間のメモリ使用率をしきい値と比較します。 今回はしきい値を 80％より上 と定義しました。 通知チャンネルを設定します。今回はメールでの通知とします。 アラート ポリシー名 を設定します。 3．稼働時間チェック Monitoring ＞ 稼働時間チェック から設定を行います。 GCE で稼働しているサービスエンドポイントにアクセスできなくなった場合に、メール通知を行うポリシーを作成します。 以下の通り設定を行います。 動作確認 1．CPU負荷をかけてみる 以下のコマンドを負荷状況に応じて複数回実行 yes > /dev/null & 設定した通りに、アラートがトリガーされました。 2．メモリ負荷をかけてみる 以下のコマンドを負荷状況に応じて複数回実行 /dev/null < $(yes) & 設定した通りに、アラートがトリガーされました。 3．VMインスタンスを停止してみる コンソールからVMインスタンスを停止 設定した通りに、アラートがトリガーされました。 静観設定(Snooze)設定 定期的なバックアップ処理、ウイルススキャン、各種バッチ処理によるリソース消費のスパイク時、またはメンテナンス時など、特定の期間においてアラート発報を抑止したいといったニーズがあるかと思います。Snooze機能を使うことで、アラート発報を一定期間無効にすることが可能です。 参考: スヌーズの作成と管理 ここまで設定してきたアラートを用いて、Snooze機能を検証してみます。 Monitoring ＞ アラート 画面中段に "Snoozes" という項目ができています。 ユースケース①：緊急メンテナンス等で、今から30分間アラート発報を無効にしたい場合 ユースケース②：毎日22:00から24:00までアラート発報を無効にしたい場合 最後に、停止する対象アラートを選択して設定完了です。 実際に、Snooze期間内に上記同様の動作確認３項目を実施しましたが、インシデントとしてはカウントされずアラート発報を抑止できました。 指定した期間が終わると、Snoozeが解除され通常のアラート動作が再開されます。 Snooze期間内の場合は、手動でSnoozeを終了することも可能です。 事前にメンテナンスウィンドウを設定しておくことで、ノイズアラートの撲滅に貢献できる機能となります。 曜日単位での設定やラベリングによる対応等、今後の機能拡張にも期待したいところです。 片岡 義就 (記事一覧) クラウドソリューション部 2022年7月 G-genにジョイン。 前職ではAWSをはじめインフラ全般の設計構築、販促企画に従事。お客様にとって最適なクラウドジャーニーを伴走支援すべく、スキルUPに奔走中。

G-gen の杉村です。Google Cloud の認定資格である Professional Cloud Database Engineer 資格の試験対策に有用な情報を記載します。 基本的な情報 Professional Cloud Database Engineer とは 難易度 出題傾向 試験対策 Cloud SQL 基本的な知識 接続と認証・認可 高可用性（HA） 高可用性構成（HA 構成）とは フェイルオーバー HA 構成への変更 リードレプリカ リードレプリカとは 非同期レプリケーション 同期パフォーマンスの改善 フェイルバック バックアップ・リストア モニタリング 暗号化 アップデート・メンテナンス スペック変更 メンテナンスウインドウ Cloud Spanner Cloud Spanner の基本 テーブル設計 バックアップとステイル読み取り Compute Engine Bigtable Bigtable の基本 テーブル設計 Firestore Bare Metal Solution (BMS) データベースの移行 適切なデータベースの選択 Database Migration Service (DMS) Datastream 基本的な情報 Professional Cloud Database Engineer とは Professional Cloud Database Engineer は Google Cloud (旧称 GCP) の認定資格の一つです。当試験は Preview 期間を経て、2022年7月に Generally Available (一般公開) となりました。 当試験は Professional レベルの資格であり Google Cloud の各種データベース系サービスの知識・技能 に関する問題が出題されます。 試験時間は120分、問題数は50問であり、日本語版と英語版の試験が提供されています。 難易度 Professional Cloud Database Engineer 試験の難易度は、主観的ではありますが 中程度 と言えます。 基本情報技術者試験〜応用情報技術者試験レベルの IT 一般に関する知識に加えて Associate Cloud Engineer 試験 レベルの Google Cloud の基礎知識があれば、追加の学習を 1 〜 2 ヶ月程度することで十分でしょう。 受験者に推奨される経験として公式サイトには「データベースと IT に関する全般的な経験 5 年以上（Google Cloud データベース ソリューションの実務経験 2 年以上を含む）」とありますが、これに満たなくても、データベース (DBMS) に関する一般的な知識とある程度の試験対策で十分に合格を狙える資格となっています。 出題傾向 Google Cloud におけるインフラ寄りのデータベース管理に関する出題がされます。例として「スケーラブルで可用性の高いアーキテクチャを組むにはどういったサービスと機能を選べばいいか」「オンプレミスのデータベースからクラウドへの移行手法」「モニタリングやパフォーマンス測定」「バックアップなどの管理運用」といった内容です。 一方で SQL の記述やデータモデリングに関する知識は問われません。 Cloud SQL に関する問題が大半を占めており、続いて Cloud Spanner、 Bigtable、 Firestore などのデータベースサービスが続き、 Database Migration Service (DMS) などの移行ツールやデータベース移行手法も出題されます。 当試験では BigQuery など分析系データベースに関する出題は ありません 。データ分析に関する出題は、名前はよく似ているものの全く別の Google Cloud 認定資格である Professional Data Engineer 試験 が担っています。データ分析に関する知見を磨きたい方は、そちらの試験の合格を目指して学習する方が望ましいでしょう。 試験対策 以下の勉強方法はあくまで一例であり、最適な方法は、受験者の予備知識や経験によって異なるものとご了承ください。 Associate Cloud Engineer 試験 を学習し、合格することで Google Cloud の基本的な知見を得る 公式の 試験ガイド で試験範囲を理解する Cloud SQL の知識を全体的に学ぶ Cloud Spanner、Bigtable、Firestore、Oracle DMS などよく問われるサービスの公式ドキュメントを読んで学習する 当記事の出題傾向を読み足りない知識領域をカバーする学習を行う 当記事ではこれ以降、出題傾向や勉強すべき内容を解説します。とはいえ、これらが全てではありません。あくまで公式の試験ガイドを基準として、自分に足りない知識を補ってから試験に挑むようにしてください。 Cloud SQL 基本的な知識 Cloud SQL は当試験に向けて最も押さえておくべきサービスです。半分以上が Cloud SQL に関する知識・経験を問うものと思っていいでしょう。 以下の徹底解説記事を読み、また記事中のリンクから公式マニュアルへ飛んで詳細を把握するなどしてまずは Cloud SQL の全体像を掴んでください。 blog.g-gen.co.jp 高可用性構成におけるフェイルオーバーの仕組み、バックアップやダンプのエクスポート、モニタリング、接続方法などについては、上記記事上のリンクから公式マニュアルに飛んでより詳細を把握しておいて損はありません。 接続と認証・認可 Cloud SQL インスタンスへの接続は独特です。徹底解説記事や公式ドキュメントを読み、 Cloud SQL で Private IP アドレスを構成した際のマネージドネットワークへのプライベートサービスアクセスの仕組みや、 Cloud SQL Auth Proxy など特有のキーワードを押さえてください。以下がキーワードです。 Cloud SQL インスタンスへの External IP アドレスを使った接続と Private IP アドレスを使った接続 External IP : 承認されたネットワーク Internal IP : プライベートサービスアクセス 似た用語である「Private Google Access」と間違えないこと（名前が似ているが Private Google Access は 限定公開の Google アクセス のこと） Cloud Auth Proxy Cloud Auth Proxy とは IAM データベース認証とは データベースフラグ cloudsql.iam_authentication （ 参考 ） 高可用性（HA） 高可用性構成（HA 構成）とは 前掲の徹底解説記事にあるように、 高可用性 （HA） 構成 と リードレプリカ は、似ていますが 異なるもの です。目的はそれぞれ「可用性」と「負荷分散」である点に留意してください。 選択肢には HA 構成を選ぶか、リードレプリカを選ぶか迷う場合は、それぞれの機能の本来の目的を考えれば、正しい選択肢が選べます。 フェイルオーバー HA 構成でのフェイルオーバーの挙動は公式ドキュメントで確認できます。短い RTO（Recovery Time Objective）が求められる場合に HA 構成が有用であることが分かります。 参考 : フェイルオーバーの概要 また HA 構成においてはテスト目的やフェイルバック等のためにフェイルオーバーを 意図的に発生 させることができます。コンソールから実行できるほか gcloud sql instances failover ${PRIMARY_INSTANCE_NAME} というコマンドを使います。 HA 構成への変更 シングル構成の既存インスタンスを HA 構成に、 後から変更 することができます（再起動が発生します）。 変更にはコンソールからの操作か、あるいは gcloud sql instances patch コマンドを使用します。このコマンドは HA 構成への変更だけでなく、 vCPU やメモリ量を変更するとき等にも使いますので、覚えておいて損はありません。 リードレプリカ リードレプリカとは リードレプリカ は読み取り専用のコピーインスタンスです。メインであるプライマリインスタンスから非同期レプリケーションを受けて、読み取りリクエストを受け付けます。 基本的な目的は読み取りワークロードの負荷分散ですが、プライマリインスタンスへの 昇格 も可能なため、リージョンを跨いだ DR 目的にも利用されます。この利用用途をしっかり把握してください。 非同期レプリケーション HA 構成が同期レプリケーションであるのに対し、 リードレプリカは非同期レプリケーションです。アプリケーションがトランザクションをコミットしても、内容が同期されるまでにラグが発生します。 レプリケーションラグは Cloud Monitoring のメトリクス で確認可能です。 また上記リンク先ドキュメントから、レプリケーションラグを最適化する方法も確認しておきましょう。 非同期レプリケーションであるため、プライマリインスタンスで障害が起き、リードレプリカにフェイルオーバーした際、データに不整合が発生する場合もあります。これが原因で、プライマリインスタンスで問題なかった処理が、昇格後のリードレプリカではエラーになるといったケースも想定できます。 同期パフォーマンスの改善 リードレプリカへのデータ同期は非同期であるため、ラグが発生します。同期のパフォーマンスが問題になる場合、 並列レプリケーション （parallel replication）を設定できます。 設定手順は以下のようになります。どちら（プライマリか、リードレプリカか）のインスタンスにどの順番で設定を行うか、把握しておきましょう。 リードレプリカでレプリケーションを無効化する リードレプリカのフラグでパラレルレプリケーションを有効化する リードレプリカでレプリケーションを再開する 必要に応じて、プライマリインスタンスのフラグでパフォーマンスを調整する 参考 : 並列レプリケーションを構成する フェイルバック リードレプリカが昇格したあと、元のプライマリインスタンスにボタン1つでフェイルバックするということはできません。 元のリージョンにフェイルバックしたい場合、昇格したインスタンスから再度、元のリージョンにリードレプリカを作り直し、そのインスタンスを昇格させるという手順が必要になります。 参考 : 元のプライマリ リージョンにフォールバックする バックアップ・リストア Cloud SQL の基本的なバックアップ・リストアの仕様は解説記事から確認しておきましょう。 また Cloud SQL Serverless Export 機能を確認しておいてください。 Cloud Storage にダンプファイルをエクスポートする機能です。同機能では一時的なエクスポート用インスタンスが自動的に作成され、このインスタンスに対してダンプ処理が走るので、 本番インスタンスに負荷がかかりません 。 モニタリング Cloud SQL のリソースモニタリングは Cloud Monitoring を使って行います。何も設定しなくても Cloud Monitoring がメトリクスを収集します。 これに加えて当試験でたびたび問われるのは Query Insights 機能です。 Cloud SQL で稼働するデータベースにおいて、負荷の高い SQL やその実行計画を確認できます。 問題文や選択肢の中で Cloud SQL Insights と表記されていることもありますが Query Insights と同じものを指しています。 またアプリケーション側で ORM を使っている場合でも、 Sqlcommenter というオープンソースライブラリを使うことで、SQL の特定に役立ちます。 暗号化 Cloud SQL 利用の際のセキュリティ要件として、「データを暗号化する」「暗号鍵は自分で管理する」「暗号鍵の所在地はコントロールできる」「データへのアクセス制御を厳密にする」などがある際の対応を問われます。 Cloud KMS ではユーザー側で用意した暗号鍵を登録・管理でき、 KMS に登録した鍵を使って Cloud SQL のストレージを暗号化できます。このユーザー側で管理する鍵のことを CMEK (Customer Managed Encryption Key) といい、大事なキーワードになります。 Google Cloud では何もしなくてもデフォルトでストレージが暗号化されますが、この場合の鍵は Google 側で管理されます。ユーザー側で管理しなくてよいのが魅力ですが、各種セキュリティ監査要件などの要求によりユーザー側で鍵を管理する必要がある際は、ユーザー側で鍵を用意して Cloud KMS に登録し (= CMEK) この鍵を使って Cloud SQL のストレージを暗号化します。 blog.g-gen.co.jp アップデート・メンテナンス スペック変更 Cloud SQL は構築後も vCPU やメモリ量を変更することができます (再起動が伴います) 。 コンソール画面から編集できる他、 gcloud sql instances patch コマンドで変更が可能です (このコマンドは前述の通り既存インスタンスを HA 構成に変更するとき等にも使われます) 。 メンテナンスウインドウ データベースのマイナーバージョンへのパッチや OS / Cloud SQL 自体のパッチなどはメンテナンスウインドウの時間帯で適用されます。 時間は 1 時間のウインドウで曜日・時間が指定できます。また 最大 90 日間のメンテナンス拒否期間 が設定でき、この期間はメンテナンスを延期できます。業務繁忙期にメンテナンスを避けたい、などのシチュエーションが考えられます。 Cloud Spanner Cloud Spanner の基本 Cloud Spanner はリレーショナルデータベースでありながら分散アーキテクチャであるという変わった DBMS です。Cloud Spanner の学習には以下の記事をご参照ください。 blog.g-gen.co.jp Cloud Spanner のユースケースや、主要なキーワードを押さえておきましょう。 グローバルにまたがる（リージョンをまたぐ）アプリから利用する リレーショナルデータベースである トランザクション処理（ACID 特性を持つ） 99.999 % の SLA 自動シャーディング テーブル設計 Cloud Spanner は分散アーキテクチャであり、データが複数のノードに分散して保管されます。 データは主キーの範囲に基づいて分散先のノードが決まるため、主キーの設計を誤ると、データが特定ノードに集中して ホットスポット ができてしまいます。複数ノードに負荷を分散させるためには、ホットスポットを回避するような主キー設計をする必要があります。 参考 : スキーマとデータモデル バックアップとステイル読み取り Spanner では バックアップ を取得することが可能です。そのバックアップからは、別インスタンスとしてデータをリストアできます。 参考 : バックアップの概要 論理的バックアップの代替となり得る手段として、 ステイル読み取り があります。ステイル読み取りでは、タイムスタンプを指定して、過去データを読み取ることができます。また、強い整合性を求めない読み取りの場合に、より高い読み取りパフォーマンスのためにステイル読み取りを使う場合もあります。 参考 : 読み取りのタイプ 参考 : タイムスタンプの範囲 誤ってデータを削除した場合など、論理的なデータ破損が発生した際に、規模の小さい復元の場合はこのステイル読み取りを使うこともできます。デフォルトでは最短1時間でデータがガベージコレクションされてしまいますが、データが残っていれば、ステイル読み取りによって過去のデータを読み取ることができます。 Compute Engine Compute Engine にデータベースをホストするケースも出題されます。 Compute Engine の基本は、以下の記事で押さえてください。 blog.g-gen.co.jp また以下のような運用タスクの方法も簡単に押さえておきましょう (永続ディスク拡張後、 VM にログインして resize2fs コマンドを使う等 ※ ext4 の場合) 。 参考 : 永続ディスクのサイズの変更 Bigtable Bigtable の基本 Bigtable は NoSQL ビッグデータ向けのフルマネージドなデータベースサービスです。Bigtable は、IoT デバイスからのデータを受け取るというユースケースで語られることも多いデータベースです。 基本的な仕様の理解には、以下の記事も参考にしてください。 blog.g-gen.co.jp テーブル設計 Bigtable は NoSQL の分散データベースであり、スキーマ設計は通常の RDB とは大きく異なります。Bigtable では入れるデータの 行キー によってデータ配置先のノードが決まります。キー設計を誤ると ホットタブレット / ホットスポット と呼ばれる、データの偏りが発生してしまいます。 例えば、行キーがタイムスタンプだったりすると、値がシーケンシャルであるため特定のノードに連続してデータが書き込まれてしまい、分散データベースの利点を活かせなくなってしまいます。「Bigtable 上の特定データセットのみパフォーマンスが悪い」といった場合、データの偏りを疑います。 データの偏りを特定するために Key Visualizer といったツールが用意されています。 以下の公式ドキュメントは押さえておいてください。 参考 : スキーマ設計のベスト プラクティス 参考 : Key Visualizer の概要 Firestore Firestore はフルマネージドでサーバーレスなドキュメントデータベース（NoSQL データベース）です。 モバイルアプリ（App）のデータベースとして使われるケースが多く出題されます。 参考 : Firestore の概要 特徴として、 オフラインモード が挙げられます。この機能を使うと、アプリが頻繁に使用するデータはローカルのキャッシュに保存されるため、インターネットに接続できなくてもアプリが利用できます。インターネット接続が復旧すると、ローカルキャッシュのデータが Firestore に同期されます。 インターネット接続環境が不安定な場合 （intermittent internet connectivity）でもアプリが使えるようにしたい、という要件が出題されたら、Firestore が使えないかを検討します。 参考 : オフライン データを有効にする Bare Metal Solution (BMS) Bare Metal Solution (BMS) は Google Cloud の持つベアメタルサーバーを利用できるサービスです。 このサービスの主目的は Oracle ワークロードの Google Cloud への移行 にあります。かつてはライセンスの問題から、Compute Engine の VM や Cloud SQL では Oracle Database を稼働させることができなかったことから、ベアメタルサーバーの扱いとなる BMS が利用されていました。 ただし、2024年6月に Oracle が Google Cloud を Authorized Cloud Environments として認定したため、現在では Compute Engine でも Oracle を利用することができます。 参考 : Accelerating cloud transformation with Google Cloud and Oracle 参考 : Licensing Oracle Software in the Cloud Computing Environment データベースの移行 適切なデータベースの選択 ユースケースに応じて、適切なデータベースサービスを選択させる問題があります。概ね以下の表のユースケースが理解できていれば、適切な DB を選択できます。 No ユースケース 選択するサービス 1 オープンソースデータベースが利用可能で、費用対効果に優れたマネージドサービス Cloud SQL 2 世界中に分散するアプリから使われる RDB。トランザクション（ACID）あり。99.999% の SLA Cloud Spanner 3 IoT デバイスから高スループットでデータを受け取る Bigtable 4 モバイル端末から使う。インターネット接続が無いとき (オフライン時) でもキャッシュ利用可能 Firestore Database Migration Service (DMS) Database Migration Service (DMS) の仕様を理解しましょう。 Continuous Migration 機能を使うことで「初回同期」と CDC (Change Data Capture) を使った「継続同期」を行い、最小限のダウンタイムで DB を移行することができます。 例として DMS を使った同種間移行では、オンプレミスの MySQL / PostgreSQL / SQL Server を Cloud SQL に移行することができます。 なお DMS は Cloud SQL への移行ツール なので、 Compute Engine でホストされたデータベースへの移行は できません 。 機能の概要を押さえておきましょう。 Datastream Datastream も Google Cloud が提供する移行ツールの一つです。 Datastream は Oracle または MySQL から CDC (Change Data Capture) により Cloud Storage にデータをストリーミングします。 Dataflow と組み合わせることで BigQuery や Cloud SQL 、 Cloud Spanner などに対してデータを同期することが可能です。 機能の概要を、大まかで良いので押さえておきましょう。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの開原です。当記事では、Looker のデータガバナンス機能について解説します。 データガバナンスとは？ Looker の運用フロー Lookerのガバナンス機能 LookML による指標・集計ロジックの集中管理 分析結果を活用するためのアクション機能 セキュリティーを強化する権限管理 システムアクティビティ機能 データガバナンスと BI ツール データガバナンスとは？ ガバナンス（governance）とは、日本語では、「統治」、「管理」、「支配」等を意味する言葉です。 データガバナンス とは、データの取り扱いを統制していく取り組みを指します。たとえば、データガバナンスが効いていない状態では、以下のようなことが起こります。 どのデータがビジネス判断に使うべき正しいデータかわからない 同じ会社の中で、様々な部署が別々にデータを管理している。集計方法も異なる データが、閲覧すべきでない人に見えてしまっている データの管理コストが過剰にかかっているが、誰にも管理されていない このような状態は、多くの組織で現実に発生しています。特に、データ活用を推進しはじめた初期は意識されていなかったこれらの問題が、データ活用が広がるにつれ、顕在化するケースも多くあります。逆にいうと、上記のような状態を解消する営みが データガバナンスの構築 であるといえます。 データガバナンスを効かせるためには、以下を行う必要があります。 データの定義 データに関するルールの策定 データ活用の効率化 データに関するセキュリティの強化 Looker の運用フロー Google が提供するデータプラットフォームツール（BI ツール）である Looker では、以下のような運用フローで、データガバナンスが確保されます。 Lookerの運用フロー データアナリストやデータスチュアード、データエンジニア等のチームが LookML で指標や集計ロジックを定義する ビジネスユーザは、定義された情報を Explore 画面で可視化したいデータ項目（ディメンションとメジャー）を選択する Looker は、選択されたデータから SQL を自動生成し、データベースへクエリを投入する データベースから取得した結果が Explore に表示される ビジネスユーザは、表やグラフを必要に応じてダッシュボードに追加する 作成されたダッシュボードを他のユーザーが参照する 共有が必要なものは、スケジュール機能やアラート機能を使って定期配信する データアナリストは、各ユーザーの検索履歴やアクセス状況を確認する データアナリストは、必要に応じて LookML をメンテナンスする Lookerのガバナンス機能 上記運用フロー図の中で、具体的にどのようなデータガバナンス機能が実装されているかを以下にまとめました。 LookML による指標・集計ロジックの集中管理 指標、集計ロジックとダッシュボードを 分離 することで、ビジネスユーザーはデータ項目を選択するだけで表やグラフを作成することができる セルフサービス系のBIツールでよくある、ユーザー毎による指標の違いによる数値のズレを無くし、 誰が操作しても同じ結果 を取得することができる データの修正や変更が必要な場合は、LookMLの定義を 一箇所変更するだけ で、全てのダッシュボードへ変更内容を反映することができる Gitによるバージョン管理は、 いつ・だれが・何のために 変更したかを管理したり、リリース前のレビュー等に活用したりすることができる 分析結果を活用するためのアクション機能 スケジュール機能 で、ダッシュボードの定期配信ができるので、組織内だけでなく組織外のパートナーも含めて簡単に分析結果を 共有 することができる Googleサイトや社内ポータル等にダッシュボードを 埋め込む ことができる 約40種類程 のクラウドサービスへの連携ができ、開発することで連携先を追加することもできる 設定した任意のしきい値に応じて、Slackやメールで通知する アラート機能 がある API から分析結果を取得することができる セキュリティーを強化する権限管理 ユーザー、またはグループ単位でのデータアクセス権の管理ができる データセット、ビュー、列レベルでのアクセス権の制御ができる ユーザー属性や引数に応じて、検索条件や集計ロジックを 動的 に変更することができる システムアクティビティ機能 各ユーザーのデータの 検索履歴 を記録するため、ユーザーやグループ単位での利用状況を確認できる 履歴データを可視化して、ダッシュボード表示することができる アクセスされていないダッシュボード等を洗い出し、不要なものを削除したり、改善したりすることができる データガバナンスと BI ツール BI ツールによる分析結果は、組織における意思決定を行う上で非常に重要な情報です。そのためには、分析に使われるデータが正確であり、かつ統制が効いている状態、すなわち、データガバナンスが効いている状態にある必要があります。BI ツールを選定する上で、データガバナンス機能は重要な選定基準です。 通常、BI ツールと呼ばれる製品は、データガバナンスに関する機能を持っていないか、乏しいことがほとんどです。しかしながら Google が提供する Looker は、特にデータガバナンス機能が充実しているツールです。 BIツールの選定については Looker と Looker Studio（旧称データポータル）を比較した記事もご参照ください。 blog.g-gen.co.jp 開原 大佑 (記事一覧) クラウドソリューション部 2022年5月にG-gen にジョイン。 前職までは関東を中心として、全国の医療機関へのシステム導入、運用保守を担当。現在は、Looker案件を中心に担当。Google Cloud スキルアップに向けて勉強中。

G-gen の佐々木です。当記事では Google Cloud (旧称: GCP ) の Eventarc と Cloud Run を使用して、Google Cloud 上でリソースが作成されたことを通知する処理を、サーバーレスで実装していきます。 Eventarc の概要 Eventarc とは Eventarc で利用できるイベントソース Eventarc で利用できるイベントコンシューマ Cloud Run とは？ 作成するもの Eventarc に必要なサービスアカウントの作成 Cloud Run サービスの作成 Docker コンテナの作成に必要なリソースの準備 main.py の内容 requirements.txt の内容 Dockerfile の内容 GitHub リポジトリにコードをアップロードする Cloud Run サービスをデプロイする Eventarc の設定 動作確認 Eventarc & Cloud Run Eventarc の概要 Eventarc とは Eventarc は、Google Cloud もしくは外部のイベントソースで発生したイベントを、 Pub/Sub サブスクリプション 経由 で 様々な宛先（イベントコンシューマ）に転送するサービスです。 インフラストラクチャの管理は不要で、Eventarc を介したイベントはすべて CloudEvents 形式 に標準化され、コンシューマに配信されます。 Eventarc のサーバーレスかつ標準化されたイベント配信により、Google Cloud を用いた イベントドリブンアーキテクチャ の構築が容易になります。 Eventarc で利用できるイベントソース Eventarc のイベントソースとしては以下がサポートされています（ 参考 ）。 この中には現在プレビュー中のイベントソースが多く含まれているため、使用には注意が必要です。 Google Cloud のサービスからイベントを直接受け取る（ Cloud Storage 、Firebase など） Cloud Audit Logs イベント（ Google Cloud リソースの作成・更新・削除など） Pub/Sub トピックにパブリッシュされたメッセージ サードパーティのサービス（ Datadog など ） Eventarc で利用できるイベントコンシューマ Eventarc のイベント送信先となるイベントコンシューマには以下のサービスが選択できます。 Cloud Run Cloud Run for Anthos（プレビュー） Workflows（プレビュー） Cloud Run とは？ Cloud Run はサーバーレスなコンテナ実行基盤を提供するサービスです。 具体的にどんなサービスなのかについては、以下の記事で解説しています。 blog.g-gen.co.jp 作成するもの 当記事では、Cloud IAM でサービスアカウントを作成した際のイベントをCloud Audit Logs と Eventarc を用いて検知し、イベントの情報を Cloud Run に送信して、Slack に通知する仕組みを実装していきます。 Eventarc のドキュメントに チュートリアル があるので、こちらを参考にしつつ進めていきます。 処理の流れ Eventarc に必要なサービスアカウントの作成 Eventarc で使用するサービスアカウントを作成します。 Eventarc は Augit Logs からのイベント読み取りと、Cloud Run サービスへのリクエスト送信を行うため、以下のロールをサービスアカウントに付与します。 Eventarc イベント受信者 ( Eventarc Event Receiver ) Cloud Run 起動元 ( Cloud Run Invoker ) サービスアカウントの作成 Cloud Run サービスの作成 Eventarc からイベントを受け取り、Slack に通知する Cloud Run サービスを作成していきます。 Docker コンテナの作成に必要なリソースの準備 Cloud Run には Docker コンテナの形式でデプロイするので、メインの処理を記述したコード main.py （今回は Python を使用しています ）と、コード内で使用するライブラリを記載した requirements.txt 、そして Dockerfile を作成します。 Google Cloud から提供されている コードサンプル を参考にして作成しています。 main.py の内容 Slack への通知処理は slackweb ライブラリ を使用しています。 今回、通知に使用する Slack Webhook URL は Cloud Run の環境変数「 SLACK_URL 」に設定するため、コード内では環境変数を取得する処理を入れています。 from flask import Flask, request import slackweb import os # Cloud Runの環境変数からSlack WebhookのURLを取得 slack_url = os.environ.get( 'SLACK_URL' ) app = Flask(__name__) @ app.route ( '/' , methods=[ 'POST' ]) def index (): # Eventarcから受け取ったイベントの情報から、通知に必要なものを抽出 res = request.json email = res[ 'protoPayload' ][ 'authenticationInfo' ][ 'principalEmail' ] # サービスアカウント作成者の情報 project_id = res[ 'protoPayload' ][ 'response' ][ 'project_id' ] # プロジェクトID sa_name = res[ 'protoPayload' ][ 'request' ][ 'service_account' ][ 'display_name' ] # 作成されたサービスアカウント名 # Slack通知文 text = f '''作成者: {email} プロジェクトID: {project_id} サービスアカウント名: {sa_name} ''' attachments = [ { 'title' : 'google.iam.admin.v1.CreateServiceAccount' , 'pretext' : '以下の Cloud Audit Logs イベントを検知' , 'text' : text, 'mrkdown_in' : [ 'text' , 'pretext' ] } ] # Slack通知処理 slack = slackweb.Slack(url=slack_url) slack.notify(attachments=attachments) return ( 'success!' , 200 ) if __name__ == '__main__' : app.run(debug= True , host= '0.0.0.0' , port= 8080 ) requirements.txt の内容 Flask==2.2.0 gunicorn==20.1.0 slackweb==1.0.5 Dockerfile の内容 Dockerfile はサンプルコードの内容をそのまま使用しています。 FROM python:3.10-slim ENV PYTHONUNBUFFERED True COPY requirements.txt ./ RUN pip install -r requirements.txt ENV APP_HOME /app WORKDIR $APP_HOME COPY . ./ CMD exec gunicorn --bind :$PORT --workers 1 --threads 8 --timeout 0 main:app GitHub リポジトリにコードをアップロードする Cloud Run では、デプロイ時のソースとして GitHub などのリポジトリプロバイダを選択することで、コンテナのビルドから Cloud Run サービスのデプロイまでを自動で行うことができます。 内部的には Cloud Build によって コンテナイメージがビルドされ、Cloud Run サービスにデプロイされます。 また、ここで作成されたコンテナイメージは Container Registry に格納されます。 リポジトリへの変更があった際に、変更を反映したコンテナイメージを自動で Cloud Run にデプロイするように設定することもできます（ 参考 ）。 Cloud Run サービスをデプロイする Cloud Run サービスの作成画面で ソース リポジトリから新しいリビジョンを継続的にデプロイする を選択し、設定を行っていきます。 GitHub リポジトリを使用したデプロイ① リポジトリプロバイダとリポジトリを選択し、GitHub のコンテンツが Google Cloud プロジェクトに移行されることに同意するチェックボックスにチェックを入れます。 GitHub リポジトリを使用したデプロイ② 使用するブランチと、Dockerfile のパスを指定します。 GitHub リポジトリを使用したデプロイ③ 環境変数に Slack Webhook の URL を設定していきます。 URL の発行手順は こちら を参考にしました。 環境変数の設定 その他の設定値は デフォルトのまま、 Cloud Run サービスを作成します。 Eventarc の設定 Eventarc で Cloud Run サービスにリクエストを送信するトリガーを作成していきます。 今回はサービスアカウントの作成イベントを検知して通知を行いたいので、 イベントプロバイダ に「 Cloud IAM 」、 イベント に「 google.iam.admin.v1.CreateServiceAccount 」を選択します。 また、Cloud IAM に対する Cloud Audit Logs のイベントキャプチャが有効化されていない場合、ここで有効化します。 イベントプロバイダとイベントの設定 Eventarc から 宛先となる Cloud Run へのリクエスト送信は、内部的には Pub/Sub サブスクリプション経由で行われます。 以下の指示が表示された場合は、Pub/Sub がCloud Run の API を呼び出せるように、Pub/Sub のサービスアカウントに対して ID トークン発行の権限（ iam.serviceAccountTokenCreator ）を付与します（ 参考 ）。 Pub/Sub サービスアカウントへの権限付与 あらかじめ作成した Eventarc トリガー用のサービスアカウントと、Cloud Run サービスを設定し、Eventarc トリガーを作成します。 サービスアカウントと Cloud Run サービスの設定 これで、サービスアカウント作成のイベントを検知し、Cloud Run サービスにイベントの内容を送信することができるようになりました。 動作確認 Cloud IAM でサービスアカウントを作成し、Slack に通知が届くことを確認します。 Cloud Run から送信された Slack 通知 今回は Slack への通知のみを行いましたが、Eventarc で Cloud Audit Logs をイベントソースにすることで、Google Cloud上で作成したリソースへのラベルの自動付与や、ファイアウォールルールなどのセキュリティ上重要なリソースの変更を検知して通知するなど、様々な応用方法が考えられます。 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-genの片岩です。当記事では AutoML を利用して、実際におもちゃの画像分類をしてみた事例をご紹介します。 画像分類とは 画像データの確保 画像データの前処理 Vertex AI のデータセット作成 トレーニング トレーニング結果確認 予測 画像分類とは 画像分類とは、ある画像を見たときに、その画像のラベルを予測することです。さまざまな分野で応用されていますが、たとえば以下のような用途が挙げられます。 大量の建築物件の画像を、玄関やキッチン、浴室や外観などに分類する 原材料の不良品を検知する Google Cloud の機械学習サービスである Vertex AI には、容易に画像分類できる AutoML サービス が含まれます。今回はそのサービスを利用してプラレール、アンパンマン、ブロックの写真を分類しました。 なお、Vertex AI について詳しく知りたい方は、以下の記事をご覧ください。 blog.g-gen.co.jp 画像データの確保 人間の子供でも同じですが、プラレール、アンパンマン、ブロックの画像を用意して、各画像がどのラベルに属するかをあらかじめ学習させる必要があります。そのために必要な写真を撮影して画像データを確保します。 画像データの前処理 公式ドキュメント では、ラベルごとに1,000枚のトレーニング画像を用意することが推奨されています。撮影する労力を削減するために、上下左右にシフトした画像や回転させた画像を生成し、画像データ数を20倍に増やしました。あわせて、今回は非常にシンプルな画像しか扱わないため、画像データの解像度を下げてデータを軽量化しました。 参考までに回転させた画像を生成するプログラムを掲載します。 import glob import os import cv2 dataName = "block" dataPath = "drive/MyDrive/testData/test/" + dataName + "/1_input/*" files = glob.glob(dataPath) for file in files: basename = os.path.basename(file) print(basename) img = cv2.imread(file) img_rotate_90_clockwise = cv2.rotate(img, cv2.ROTATE_90_CLOCKWISE) img_rotate_180 = cv2.rotate(img, cv2.ROTATE_180) img_rotate_90_counterclockwise = cv2.rotate(img, cv2.ROTATE_90_COUNTERCLOCKWISE) dataPath2 = "drive/MyDrive/testData/test/" + dataName + "/2_rotate/" path = os.path.join(dataPath2,basename) cv2.imwrite(path, img) path = os.path.join(dataPath2,'rot90_' + basename) cv2.imwrite(path, img_rotate_90_clockwise) path = os.path.join(dataPath2,'rot180_' + basename) cv2.imwrite(path, img_rotate_180) path = os.path.join(dataPath2,'rot270_' + basename) cv2.imwrite(path, img_rotate_90_counterclockwise) print("完了") Vertex AI のデータセット作成 Vertex AI のメニューから画像分類（単一ラベル）のデータセットを作成します。 次に、前処理した画像データを Cloud Storage に保存します。 そして、トレーニングさせたい画像ファイルのパスとラベルを以下のように記載した csv ファイルを作成し、Cloud Storage に保存します。 gs://xxxxx_bucket/IMG_6291.jpg,block gs://xxxxx_bucket/IMG_6292.jpg,block gs://xxxxx_bucket/IMG_6293.jpg,block gs://xxxxx_bucket/IMG_6294.jpg,train 上記で作成した csv ファイルを指定して、インポートを実行します。 各画像ファイルにラベルが付与された状態でインポートされます。 今回は2,300枚の画像と3種類のラベルになりました。 トレーニング トレーニングに費やすノード時間を設定してトレーニングを実行します。 今回はノード時間に最小値である8を設定しました。 今回の検証の主な費用として、トレーニングに約3,800円掛かりました。 ノード時間は費用に直結する部分になります。 トレーニングに掛かる料金は 公式ドキュメント をご覧ください。 トレーニング結果確認 トレーニング完了後に結果を確認します。 トレーニング中に内部的に実行されるテストでは、100%分類できた結果となりました。 予測 新しい画像のラベルを予測するために、エンドポイントにデプロイします。 デプロイ完了後に新しい画像アップロードして予測させたところ、ほぼ100%で的中しています。今回のデータくらいシンプルだと、簡単に分類できることが判ります。 データが複雑な場合でも、ラベルの特徴を捉えた画像を用意すれば分類できそうです。 片岩 裕貴 (記事一覧) データアナリティクス準備室 2022年5月にG-gen にジョイン。 AI/ML系に関心が強く、ディープラーニングE資格とProfessional Machine Learningを取得。最近話題のGenerative AIにも興味がある。毎日の日課は三人乗りの電動自転車で子供を幼稚園に送り迎えすること。和歌山県在住。

G-gen の武井です。 Google Cloud（旧称 GCP）の Identity and Access Management（IAM）にて、権限不足に伴うエラーが発生した場合の対処方法について説明します。 前提知識 用語 図説 IAM ロール IAM の基本知識 事象 対処手順 原因と対処法の特定 Policy Troubleshooter 最適な IAM ロールの選択 IAM roles and permissions index プロダクトごとの IAM 関連ドキュメント ロール候補の確認 Gemini による支援 ロールの決定 IAM ロールの付与 前提知識 用語 Google Cloud (旧称 GCP) の Identity and Access Management（IAM）を理解する上で、重要な用語は以下のとおりです。 用語 意味 Google アカウント IAM の実行主体 (人) Google グループ 上記をグループ化したもの サービスアカウント IAM の実行主体 (サービス) IAM ロール 各種リソースに対して実行可能な権限のセット IAM ポリシー 各種リソースに対して「誰が」、「何をできるか」を規定するもの 図説 用語同士の関係を、図と実例で説明します。 用語の理解 Google アカウント / グループ (実行主体) に対し、Compute Engine で VM マシンの作成や削除が可能な権限を含む IAM ロール を付与 VM マシンに紐づけた サービスアカウント (実行主体) に対し、Cloud Storage でバケット内オブジェクトの表示や取得が可能な権限を含む IAM ロール を付与 上記の関係性 (リソースに対し誰が何をできるか) を実現するために規定 (設定) したものが IAM ポリシー IAM ロール IAM ロール とは、Google Cloud リソースに対して、特定の操作を実行可能にするための権限セットです。プリンシパル（実行主体。Google アカウント、グループ、サービスアカウント等）に対して、リソース上で付与します。 IAM ロールは以下の3種類に分類されます。 タイプ 管理者 特徴 基本ロール Google Cloud Cloud IAM 導入前より存在。オーナー / 編集者 / 閲覧者 の 3 ロールのみ 事前定義ロール Google Cloud 特定のサービス (リソース) へのアクセスを細かく制御したロール カスタムロール ユーザー ユーザーが指定する権限に応じたきめ細かなアクセス制御を可能としたロール 上記のうち「基本ロール」には広い権限が含まれているため、可能であればより狭い範囲の権限を持つ 事前定義ロール か、ユーザー独自で定義する カスタムロール を使うことが推奨されています。 IAM の基本知識 IAM の基本知識については、以下の記事も参考にしてください。 blog.g-gen.co.jp 事象 実例をもとに、IAM の権限不足に起因するエラーが発生した際の対処方法について説明します。 Cloud Run functions で動作するプログラムが、Secret Manager のシークレット値を取得する処理で例外が発生しました。Cloud Run functions には、サービスアカウントを紐づけており、その権限でシークレット値を取得する想定です。 エラーログには、以下のメッセージが含まれています。 403 Permission 'secretmanager.versions.access' denied for resource 'projects/myproject/secrets/mysecret/versions/latest' (or it may not exist). 対処手順 原因と対処法の特定 Cloud Logging からエラーログを確認します。以下は実際のスクリーンショットです。先ほど記載したものと同様のエラーメッセージが表示されています。 不足する権限が記されたエラーログ ログには secretmanager.versions.access と記されていることから、この権限が不足していることで例外が発生していると推測できます。あるいは、このシークレットが存在していない可能性もありますが、存在は確認できているものとします。 このことから、Cloud Run functions に紐づけているサービスアカウントに対して、上記の権限を含む IAM ロールを紐づけることでエラーが解消できると判断します。 Policy Troubleshooter Policy Troubleshooter を使うと、あるプリンシパルが特定の権限を実行できないとき、その原因が「許可ポリシー」「拒否ポリシー」「プリンシパルアクセス境界ポリシー」のいずれにあるのかを調査できます。 参考 : IAM 権限のトラブルシューティング Policy Troubleshooter このツールは、Google Cloud コンソールの「IAM と管理 > ポリシーに関するトラブルシューティング」画面から使用できます。原因調査のために便利なツールですが、以下の制限には注意してください。 あくまで設定の 論理的なチェック であり、実際にアクセスできることを示すものではない Cloud Storage オブジェクトの ACL や、VPC Service Controls はチェックできない（考慮されない） プリンシパルとして指定できるのは Google アカウントまたはサービスアカウント のみ IAM の許可ポリシー、拒否ポリシー、プリンシパルアクセス境界ポリシーについては、以下の記事を参考にしてください。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog 参考 : Google CloudのIAMにおけるDenyポリシーを解説 - G-gen Tech Blog 参考 : プリンシパルアクセス境界ポリシー（Principal access boundary policies）を解説 - G-gen Tech Blog 最適な IAM ロールの選択 IAM roles and permissions index 足りていない権限が判明し、また拒否ポリシーやプリンシパルアクセス境界ポリシーにブロックされているわけではなく、許可ポリシー不足であると判明した場合、次は付与すべき最適なロールを検討します。 最適な IAM ロールを選択する際に役立つのが、公式リファレンスです。 ある権限がどのロールに含まれているかを確認するには、 IAM roles and permissions index というドキュメントを使います。 参考 : IAM roles and permissions index このドキュメントでは、 権限（permission）名から IAM ロールを検索 できるようになっており、今回のようなエラーが発生した際に活用できます。 今回の例では secretmanager.versions.access という権限が不足していましたので、この権限がどの IAM ロールに含まれるか調べてみます。 ページ内の検索ボックスに権限名を入力すると、一致する権限名が表示されます。この権限名をクリックすると、その権限を持つロールの一覧が確認できます。 リファレンスによる IAM ロールの検索 また同ドキュメントでは逆に、IAM ロール名で検索して、その IAM ロールがどんな権限（permission）を持っているかを検索することもできます。 プロダクトごとの IAM 関連ドキュメント 前述の IAM roles and permissions index には、すべての基本ロールと事前定義ロールの情報が記載されていますが、一般的には Google Cloud プロダクトごとに、IAM ロールがまとまっているページが存在しますので、そちらを参照しても構いません。 参考 : Secret Manager - IAM を使用したアクセス制御 ロール候補の確認 次に最適な IAM ロールの候補選定です。 最小権限の原則 にもとづき、必要最低限の権限セットで構成された IAM ロールを選択します。 さきほどのリファレンスドキュメントで検索し、結果として表示されたロール名をクリックすると、そのロールがどの権限（permissions）を持っているかが一覧表示されます。 以下は IAM ロールの記載の例です。 オーナー（ roles/owner ） オーナー（roles/owner）ロールの説明 Secret Manager 管理者（ roles/secretmanager.admin ） Secret Manager のシークレット アクセサー（ roles/secretmanager.secretAccessor ） IAM ロールが持つ権限（permissions）の一覧 Gemini による支援 適切なロール選定にあたっては、生成 AI モデル Gemini の力を借りることもできます。Google Cloud コンソール上で、実現したいアクションを自然言語で入力すると、最適なロールを提案してくれます。詳細は以下の記事を参照してください。 blog.g-gen.co.jp ロールの決定 オーナー（ roles/owner ）やSecret Manager 管理者（ roles/secretmanager.admin ）は、エラーは解決できますが最適なロールではありません。なぜなら今回実現したい操作は「シークレット値の取得」だけですが、必要以上の権限が付与されているためです。 最小権限の原則にもとづけば、Secret Manager のシークレット アクセサー（ roles/secretmanager.secretAccessor ）が適切であるとわかります。 ロール名 概要 評価 roles/owner オーナー権限レベル △ roles/secretmanager.admin Secret Manager の管理者レベル △ roles/secretmanager.secretAccessor シークレットへのアクセスを許可 ◯ IAM ロールの付与 最適な IAM ロールが選択できたら、あとはそれをサービスアカウントや Google アカウントに紐づけることでエラーが解消されます。 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 趣味はロードレースやサッカー観戦、ゴルフ、筋トレ。 Follow @ggenyutakei

G-gen の佐々木です。当記事では Google Cloud（旧称 GCP）の機械学習サービスである Vertex AI の AutoML で作成した機械学習モデルを、サーバーレスなコンテナ実行基盤である Cloud Run にデプロイしていきます。 Vertex AI および Cloud Run とは？ Vertex AI で作成したモデルのデプロイについて 当記事で Cloud Run にデプロイするモデル Vertex AI Model Registry からモデルをエクスポートする ローカルの Docker コンテナで予測を実行する Artifact Registry にモデルをアップロードする Cloud Run にモデルをデプロイする Cloud Run サービスに予測リクエストを送信する Vertex AI & Cloud Run Vertex AI および Cloud Run とは？ Vertex AI および Cloud Run がどんなサービスなのかについては、以下の記事で解説しています。 blog.g-gen.co.jp blog.g-gen.co.jp Vertex AI で作成したモデルのデプロイについて Vertex AI では、サービスの機能の 1 つである Vertex AI Endpoints を使用することで、数クリックでモデルをデプロイし、提供されたエンドポイントに対して予測リクエストを送信することができます。 この方法では、モデルを簡単にデプロイして Vertex AI で管理することができる反面、デプロイされたモデルに対しては、予測リクエストが全くない場合でも常に課金されてしまいます（ 参考 ）。 そこで、サーバーレスコンピューティングのサービスである Cloud Run にモデルをデプロイすることで、 予測リクエストを処理するときだけ、モデルを利用可能な状態にします。 Cloud Run では、リクエストがないときはコンテナインスタンス数を 0 までスケールインすることができ、コンピューティング料金は実行時間分の課金となっているため、リクエストの頻度によっては、 Vertex AI Endpoints でモデルをデプロイするよりもかなり安く済ませることができます。 ただし、Cloud Run では GPU を使用することができない点には注意が必要です。 当記事で Cloud Run にデプロイするモデル 以下の記事で作成した、表形式データを学習に使用した二項分類モデルをデプロイしていきます。 機械学習初心者がVertex AIでモデルを構築してみた（AutoML） - G-gen Tech Blog このモデルでは、ある個人に関する様々な情報（年齢、職業、結婚歴など）をもとに、「年収が $50,000 よりも高いか、$50,000 以下か」を予測することができます。 Vertex AI Model Registry からモデルをエクスポートする Vertex AI の Model Registry から、Cloud Storage にモデルをエクスポートします。 今回は sasashun-vertexai-test という名前の Cloud Storage バケットを使用していきます。 モデルのエクスポート① モデルのエクスポート② Cloud Storage へのエクスポートが完了したら、ローカル環境から以下のコマンドを実行し、モデルを Cloud Storage からローカルにコピーします。 $ gsutil cp -r gs://sasashun-vertexai-test . コピーした Cloud Storage バケット名のディレクトリに移動します。 以降、ローカル環境で実行するコマンドは、ここから実行していきます。 $ cd sasashun-vertexai-test $ ls model-5478593762324119552 ローカルの Docker コンテナで予測を実行する まずは、エクスポートしたモデルをローカルの Docker 環境にデプロイし、予測リクエストを処理してみます。 基本的には ドキュメント に記載されている手順を参考にしていきます。 モデルは以下のようなディレクトリの配下にコピーされています。 ./model-<model-id>/tf-saved-model/<export-timestamp> 今回モデルが存在するディレクトリは ./model-5478593762324119552/tf-saved-model/2022-08-17T15:13:50.712659Z となっています。 $ ls -l model-5478593762324119552/2022-08-17T15\:13\:50.712659Z/ total 28 -rw-r--r-- 1 sasashun sasashun 206 Aug 18 00:21 environment.json -rw-r--r-- 1 sasashun sasashun 454 Aug 18 00:21 feature_attributions.yaml -rw-r--r-- 1 sasashun sasashun 3080 Aug 18 00:21 final_model_structure.pb -rw-r--r-- 1 sasashun sasashun 1249 Aug 18 00:21 instance.yaml drwxr-xr-x 1 sasashun sasashun 6 Aug 18 00:21 predict -rw-r--r-- 1 sasashun sasashun 697 Aug 18 00:21 prediction_schema.yaml -rw-r--r-- 1 sasashun sasashun 13 Aug 18 00:21 tables_server_metadata.pb -rw-r--r-- 1 sasashun sasashun 219 Aug 18 00:21 transformations.pb Docker ではタイムスタンプが含まれるディレクトリが無効にされてしまうようなので、ディレクトリ名を変更します。 今回は model というディレクトリ名に変更しています。 $ mv model-5478593762324119552/tf-saved-model/2022-08-17T15\:13\:50.712659Z/ \ model-5478593762324119552/tf-saved-model/model 次に、Google Cloud が提供する、 Vertex AI のモデルを実行するためのモデルサーバーのコンテナイメージを使用して、モデルをデプロイしていきます。 先述のドキュメント通りにコマンドを実行した場合、 asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server-v1 からモデルサーバーの Docker イメージを pull しますが、このイメージを使用してデプロイした場合、予測リクエストに対してエラーが返り、リクエストを正常に処理することができませんでした。 そこで、この Issue を参考に、 asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server:20220616_1125 のイメージを pull し、コンテナを実行します。 ここでは、コンテナに adult-census-pred という名前をつけています。 $ docker run -dit --name adult-census-pred \ -v `pwd`/model-5478593762324119552/tf-saved-model/model:/models/default \ -p 8080:8080 \ asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server:20220616_1125 次に、予測リクエストの際に payload フィールドに指定する JSON 形式のファイルを作成します。 JSON には予測に必要な列の列名と値をすべて含めます（複数行も可能）。 今回は ファイル名を request.json としています。 { "instances": [ { "age": "47", "workclass": "Private", "fnlwgt": "264052", "education": "Bachelors", "education.num": "13", "marital.status": "Married-civ-spouse", "occupation": "Exec-managerial", "relationship": "Husband", "race": "White", "sex": "Male", "capital.gain": "15024", "capital.loss": "0", "hours.per.week": "50", "native.country": "United-States" } ] } ローカルで実行されているモデルサーバーのコンテナに対して、予測リクエストを送信します。 $ curl -X POST --data @request.json http://localhost:8080/predict {"predictions": [{"scores": [0.0009153289720416069, 0.9990846514701843], "classes": ["<=50K", ">50K"]}]} 今回使用するモデルでは、「年収が $50,000 よりも高い」場合は >50K 、そうでない場合は <=50K に分類されます。 予測リクエストの結果は、モデルに与えたデータは 99.9% の確率で >50K に分類されることを示しています。 Artifact Registry にモデルをアップロードする Cloud Run にモデルをデプロイするために、Google Cloud 上でコンテナイメージを管理する Artifact Registry のリポジトリにモデルをアップロードします。 まず、Artifact Registry のリポジトリを作成します。 リポジトリの作成時に Docker 形式を選択します。 Artifact Registry リポジトリの作成 次に、ローカル環境で、モデルを内包した Docker イメージを作成していきます。 先ほどローカル環境で起動したコンテナは、モデルが配置されているローカルのディレクトリに対して、コンテナの /models/default ディレクトリをマウントしているだけであり、コンテナ側にモデルの実体は存在していません。 以下のコマンドを使用して、ディレクトリのマウントを設定していないコンテナ（ adult-census-pred-2 ）を新たに作成し、モデルをコンテナの /models/default 配下にコピーします。 $ docker create --name adult-census-pred-2 -p 8080:8080 asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server:20220616_1125 2fa13f09689d0007423654a3dbb254304f8d4ffc75ad786d015a554908c0ae42 $ docker cp `pwd`/model-5478593762324119552/tf-saved-model/model adult-census-pred-2:/models/default adult-census-pred-2 コンテナから、モデルを内包したコンテナイメージを新たに作成します。 Artifact Registry のリポジトリにイメージを push する場合、イメージ名に Google Cloud のプロジェクト ID などを含めたリポジトリの情報を含めます（ 参考 ）。 イメージ名は以下の形式となります。 <location>-docker.pkg.dev/<project-id>/<repository-name>/<image-name>:<tag> 今回は、以下のようにイメージを作成しました。 $ docker commit adult-census-pred-2 asia-northeast1-docker.pkg.dev/sasashun/vertexai-docker-repo/adult-census-pred:20220818 sha256:7fc68d6458dcda72e9bec6e4432792d071c81b6e23d9bf409cde92ed904cafdb $ docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE asia-northeast1-docker.pkg.dev/sasashun/vertexai-docker-repo/adult-census-pred 20220818 7fc68d6458dc 4 seconds ago 3.06GB asia-docker.pkg.dev/vertex-ai/automl-tabular/prediction-server 20220616_1125 46441e5efec4 2 months ago 3.06GB Artifact Registry のリポジトリに、新たに作成したコンテナイメージを push します。 $ docker push asia-northeast1-docker.pkg.dev/sasashun/vertexai-docker-repo/adult-census-pred:20220818 push したコンテナイメージ Cloud Run にモデルをデプロイする Artifact Registry のリポジトリから、コンテナイメージを Cloud Run にデプロイします。 リポジトリ上でコンテナイメージを選択し、 Cloud Run にデプロイする を選択します。 コンテナイメージを Cloud Run にデプロイ 今回は 未認証の呼び出しを許可 にチェックを入れ、Cloud Run サービスを公開した状態で作成します。 Cloud Run サービスの作成 デプロイが失敗しました。 ログを見てみると、どうやらサービスに割り当てたメモリが不足しているようです（ 参考 ）。 Memory limit of 512M exceeded with 515M used. Consider increasing the memory limit, see https://cloud.google.com/run/docs/configuring/memory-limits Cloud Run へのデプロイの失敗 メモリの割り当てを変更し、再度デプロイします。 メモリの値を変更 今度はデプロイに成功しました。 URL の項目に、Cloud Run サービスのエンドポイントが記載されています。 サービスのエンドポイント Cloud Run サービスに予測リクエストを送信する サービスのエンドポイントの URL に対して、ローカル環境から予測リクエストを送信します。 リクエストには、ローカル環境で試したときと同じ request.json を使用しています。 $ curl -X POST --data @request.json https://adult-census-pred-ai4qoprwhq-an.a.run.app/predict {"predictions": [{"classes": ["<=50K", ">50K"], "scores": [0.0009153289720416069, 0.9990846514701843]}]} Cloud Run にデプロイしたモデルを用いて、予測リクエストを処理することができました。 Cloud Run のログ 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。最近は Dataflow を勉強中。 Follow @sasashun0805

G-gen の杉村です。 Google Cloud のマネージドの RDBMS サービスである Cloud SQL について徹底的に解説します。 Cloud SQL とは 料金 Cloud SQL の料金 無料トライアルインスタンス 確約利用割引 延長サポート（Extended Support） Cloud SQL editions Cloud SQL editions とは Enterprise と Enterprise Plus の違い データキャッシュ 料金の違い Enterprise Plus への移行 Cloud SQL Studio Cloud SQL Studio とは Gemini in Database インスタンス インスタンス とは 起動と停止 データベースフラグ マネージドコネクションプール vCPU とメモリ マシン構成 運用中の変更 ストレージ（ディスク） 種類 容量 ストレージの自動増量 パフォーマンス 高可用性構成（HA 構成） 概要 フェイルオーバー 可用性 SLA リードレプリカ リードレプリカとは クロスリージョンリードレプリカ レプリカと災害対策（DR） 外部レプリカ 読み取りプール（read pools） ネットワークと接続方法 Cloud SQL とネットワーク Cloud SQL インスタンスへの接続 方法1. パブリック IP アドレスで接続 仕組み アクセス制御 方法2. プライベートサービスアクセス経由でプライベート IP アドレスに接続 仕組み サービスプロデューサーのネットワークの作成 設定方法 アクセス制御 書き込みエンドポイント 方法3. Private Service Connect 経由でプライベート IP アドレスに接続 仕組み メリット アクセス制御 オンプレミスからの接続のアクセス制御 バックアップとリストア バックアップ 仕組み インスタンス削除時の仕様 料金 オンデマンドバックアップと自動バックアップ 最終バックアップ 保存先ロケーション トランザクションログ リストア インポート・エクスポート サポート問い合わせによるリストア Cloud SQL Auth Proxy Cloud SQL Auth Proxy とは メリット 接続の流れ 他の Cloud SQL コネクタ 設定と接続の方法 認証・認可 データベースログインのための認証 ユーザー・パスワードによる認証 IAM による認証の概要 IAM による認証（自動） IAM による認証（手動） メンテナンス 概要 メンテナンスウインドウ、メンテナンスタイミング、拒否期間 事前通知 メンテナンスの延期・即時適用 メンテナンスの仕組み インプレースアップグレード モニタリング・ロギング Cloud Monitoring によるメトリクス収集 Query Insights ロギング 監査 クラウドリソースとしての監査ログ データベースとしての監査ログ 暗号化 デフォルトの暗号化 その他の暗号化 その他留意事項 データベースエンジンごとの機能差 標準的なデータベースとの違い Cloud SQL とは Cloud SQL は、Google Cloud（旧称 GCP）のマネージドな RDBMS サービスです。 Cloud SQL では、利用者は OS レイヤや物理基盤を意識することなく、MySQL や PostgreSQL 等のデータベースを利用することができます。いわゆる DBaaS とも呼ばれる分類のサービスであり、他社サービスでは Amazon Web Services（AWS）の Amazon RDS がこれにあたります。 Cloud SQL の対応データベースエンジンは MySQL 、 PostgreSQL 、 Microsoft SQL Server です。データベースエンジンはインスタンス作成時に選択し、後から変更することはできません。 作成したデータベースは、プライベート IP アドレスまたはパブリック IP アドレス経由で、通常のデータベースクライアントからアクセスできます。また Cloud SQL Studio という Web インターフェイスも用意されており、Google Cloud コンソール画面からテーブルの管理や SQL の実行が可能です。 Cloud SQL は簡単に利用開始できるほか、データベースエンジンのインストールやアップデート、バックアップやモニタリング、 CPU やメモリ、ストレージの拡張などの工数を大幅に削減することができます。また複数のゾーンにまたがる冗長化設定やリードレプリカの作成も容易です。 また、BigQuery など他の Google Cloud サービスとの連携もシームレスに行うことができます。 Google Cloud にホストするアプリケーションでリレーショナルデータベースを利用する際は、第1に採用を検討するべきサービスといえます。 参考 : Cloud SQL overview 料金 Cloud SQL の料金 Cloud SQL は使用したボリュームと時間に応じた 従量課金 です。インスタンスに割り当てた vCPU コア数、メモリ、ストレージ量などに対して、秒単位で課金されます。 データベースエンジンとして Microsoft SQL Server を選択した場合は、起動時間に応じて1時間単位でライセンス料金が発生します。 また Cloud SQL for MySQL と for PostgreSQL には エディション の概念があります（後述）。Enterprise エディションと Enterprise Plus エディションがあり、後者は vCPU/メモリあたりの単価が高い代わりに、より高い可用性 SLA・短いダウンタイム・キャッシュ用ストレージなどが利用可能です。 月額費用の例として、東京リージョンで Enterprise エディションの Cloud SQL for PostgreSQL を vCPU 2 コア、メモリ 7.5 GiB、100 GiB ストレージで1ヶ月間（31日間）稼働させると、$153.207456になります（2025年9月現在）。 最新の利用料金は以下の公式ページでご確認ください。 参考 : Cloud SQL pricing 参考 : Introduction to Cloud SQL editions また、公式の見積もりツールである Google Cloud Pricing Calculator で、料金が試算できます。 参考 : Google Cloud Pricing Calculator 無料トライアルインスタンス Cloud SQL では、MySQL 版と PostgreSQL 版に限り、 無料トライアルインスタンス （Free trial instance）が作成可能です。ただし、SQL Server 版には用意されていません。 無料トライアルインスタンスでは、いくつかの機能制限があるものの、Cloud SQL の Enterprise Plus エディションのほとんどの機能を試用することができます。 参考 : Free trial instance overview 無料トライアルインスタンスの試用期間は30日間です。試用期間の30日間が経過するとインスタンスはリクエストの受付を停止しますが、90日間の猶予期間の間はインスタンスとデータが保持されます。猶予期間が終了すると、インスタンスは削除されます。試用期間中または猶予期間中に、いつでも有償版にアップグレードすることができます。 無料トライアルインスタンスは Google Cloud プロジェクトにつき1回だけ、1つ作成することができます。 無料トライアルインスタンスには、以下のような制限があることに留意してください。 SLA 適用なし バックアップ/リストアは不可 インスタンスのスペックは固定（N2 マシンシリーズ、8 vCPU、64 GB RAM、100 GB ストレージ、375 GB データキャッシュ） リードレプリカは使用不可 クロスリージョンレプリカは使用不可 確約利用割引 Cloud SQL には 確約利用割引 （Committed use discount、CUD）の仕組みがあります。 1年間または3年間の利用を確約（コミット）することで最大52%の割引を受けることができます。確約利用割引は、Google Cloud のコンソール画面から購入します。 確約利用割引は vCPU とメモリの料金に対して利用することができますが、ストレージ / バックアップ / ライセンス / ネットワーク料金には適用することができません。 詳細は以下の公式ドキュメントをご確認ください。 参考 : 確約利用割引 確約利用割引 (CUD) の購入画面 延長サポート（Extended Support） Cloud SQL では MySQL や PostgreSQL からのコミュニティサポートが終了後、Google Cloud による有償の 延長サポート （Extended support）を受けることができます。 延長サポートの期間中は、セキュリティパッチ、バグフィックスなどが提供され、SLA の対象にもなります。 参考 : Extended support for Cloud SQL 延長サポート期間に入ったインスタンスは、稼働時間に応じた追加のインスタンス料金が発生します。追加の料金は、秒単位で課金されます。 参考 : Extended support pricing Cloud SQL editions Cloud SQL editions とは Cloud SQL for MySQL と for PostgreSQL には エディション の概念があります。 Enterprise と Enterprise Plus エディションが存在し、前者は一般的なユースケースに、後者はより高い可用性とパフォーマンスが求められる場合に利用します。 Enterprise Plus エディションでは読み取り・書き込みの両パフォーマンスが Enterprise と比較して高くなります。公称では Cloud SQL Enterprise Plus for MySQL で「読み取りスループットが最大 3 倍、書き込みレイテンシが最大 2 倍向上」とされます。また可用性 SLA の向上、メンテナンス時のダウンタイムの短縮、トランザクションログの保持期間の長期化など、よりエンタープライズ・レディな仕様です。 エディションはインスタンスごとに選択することが可能で、1つのプロジェクトの中で複数のエディションを併用することは問題ありません。 参考 : Introduction to Cloud SQL editions 参考 : Cloud SQL Enterprise Plus エディションを発表：新エディションでは MySQL のパフォーマンスが最大 3 倍に向上 Enterprise と Enterprise Plus の違い それぞれのエディションには以下のような違いがあります。表記は、2025年10月初旬現在のものです。 参考 : Cloud SQL の各エディションの概要 比較観点 Enterprise Enterprise Plus 料金 - vCPU/Memory の時間単価が Enterprise の約1.3倍 DB バージョン MySQL 5.6、5.7、8.0、8.4 PostgreSQL 9.6、10、11、12、13、14、15、16、17、18 SQL Server 2022（Standard、Enterprise、Express、Web）、SQL Server 2019（Standard、Enterprise、Express、Web）、SQL Server 2017（Standard、Enterprise、Express、Web） MySQL 8.0、8.4 PostgreSQL 12、13、14、15、16、17 SQL Server 2022 Enterprise、SQL Server 2019 Enterprise マシンタイプ ・汎用共有コア (PostgreSQL/MySQL) ・汎用専用コア ・N4 ・N2 ・C4A (PostgreSQL/MySQL) ・Memory-optimized-N2 (SQL Server) マシンスペック最大値 最大 96 vCPU 最大 624 GB RAM コア:メモリ比 = 1:6.5 最大 128 vCPU 最大 864 GB RAM コア:メモリ比 = 1:8 （パフォーマンス最適化タイプの場合） 可用性 SLA 99.95% 99.99% メンテナンス時ダウンタイム 60 秒未満（MySQL） 30 秒未満（PostgreSQL） 120 秒未満（SQL Server） 1 秒未満（MySQL） 1 秒未満（PostgreSQL） 120 秒未満（SQL Server） データキャッシュ 利用不可 オプションで利用可 ポイントインタイムログ保持期間 最大7日間 最大35日間 書込レイテンシ - Enterprise と比較して最大2倍向上 自動チューニング - 基盤に応じたエンジン設定の自動チューニング (MySQL / PostgreSQL) データキャッシュ Enterprise Plus エディションでは データキャッシュ が利用可能です。高速なローカル SSD をバッファ領域とすることで、読み取りパフォーマンスが向上します。 データベースはメインメモリ＞ローカル SSD (データキャッシュ)＞ストレージの順にデータを探します。書き込み時には、ストレージへの書き込みとローカル SSD (データキャッシュ) への書き込みを同時に行います。 当機能の利用はオプションであり、インスタンス作成時の設定または作成後の変更が可能です。割り当てた SSD の GB 数に応じて料金が発生します。 以下のような場合に当機能の利用が推奨されています。 ワークロードがメインメモリに収まらない場合 書き込みよりも読み取りが多いワークロードの場合 また MySQL インスタンスでは、インスタンスに 16 コア以上の vCPU を割り当てられている場合にデータキャッシュの恩恵がより受けられるとされています。 参考 : Data cache overview (MySQL) 参考 : Data cache overview (PostgreSQL) 料金の違い Enterprise Plus エディションでは、vCPU とメモリの時間単価が Enterprise と比較して約1.3倍となります。 またオプションで割り当てたデータキャッシュ用ストレージにも、GB あたりの料金が発生します。HA 構成にする場合、スタンバイインスタンスにもデータキャッシュ用ストレージを割り当てるため、倍の料金が発生します。 参考 : Cloud SQL pricing Enterprise Plus への移行 Enterprise エディションのインスタンスを Enterprise Plus エディションに移行するには、gcloud コマンドラインを使います。 gcloud sql instances patch コマンドで --edition=ENTERPRISE_PLUS オプションを指定します。変更には60秒未満のダウンタイムを伴います。Enterprise Plus エディションから Enterprise エディションへのダウングレードも可能です。 参考 : Upgrade an instance by using in-place upgrade 参考 : Introducing Cloud SQL in-place upgrade: move from Enterprise to Enterprise Plus with ease Cloud SQL Studio Cloud SQL Studio とは Cloud SQL には Cloud SQL Studio という Web ユーザーインターフェイスが用意されています。 Cloud SQL Studio は Google Cloud コンソールからアクセスできる Web 画面であり、データベース名とパスワードを入力することで、Web ブラウザから Cloud SQL のデータベースに接続できます。 Web 画面でテーブルの管理や SQL の実行が可能です。なおこの Web 画面は BigQuery の Web ユーザーインターフェイスと似ています。 Cloud SQL Studio 参考 : Cloud SQL Studio を使用してデータを管理する Gemini in Database Cloud SQL Studio では、Google が開発する生成 AI 基盤モデルである Gemini を利用することができます。この機能は、 Gemini in Database と呼ばれます。 Gemini を使うと、日本語での指示によって自動的にクエリを生成し、データベースに投入することが可能です。以下の記事もご参照ください。 blog.g-gen.co.jp インスタンス インスタンス とは Cloud SQL は インスタンス という単位で管理します。インスタンスは1台の仮想サーバーであるとイメージすればよいでしょう。 インスタンスには、データベースエンジン（MySQL、PostgreSQL、SQL Server）、vCPU コア数、メモリ数、ストレージサイズなどを指定できます。また、エディション（Enterprise または Enterprise Plus）もインスタンスごとに指定します。 参考 : 主な用語 - Cloud SQL インスタンス 参考 : インスタンスの設定について 起動と停止 Cloud SQL インスタンスは、データベースを利用しない間は 停止 することができます。 停止されたインスタンスには vCPU とメモリの料金が発生しません。ただし確保されたストレージに対しては料金が発生し続けるほか、確保された IP アドレスの利用料金もわずかに発生します。 なおインスタンスのストレージ容量が上限に近づくと、データロスを防ぐためインスタンスが自動的に停止されることがあります。オンプレミスや仮想サーバーで動作するデータベースと同様に、ストレージ使用率の適切なモニタリングが必要です。必要に応じて、後述のストレージ自動拡張機能を有効化することも検討します。 なお後述のリードレプリカインスタンスは停止することができません。 参考 : インスタンスの起動、停止、再起動 データベースフラグ データベースフラグ とは、データベースエンジン（MySQL、PostgreSQL、SQL Server）が持つパラメータを設定するための Cloud SQL インスタンスの設定値です。 Cloud SQL では OS レイヤやミドルウェアレイヤを Google Cloud が管理しているため、例えば PostgreSQL でいう postgresql.conf ファイルなどの設定ファイルを直接編集できません。 そのため Cloud SQL ではデータベースパラメーターは、データベースフラグという Cloud SQL インスタンスの設定値として管理されます。 データベースエンジンが用意している全てのパラメータが Cloud SQL でも利用可能というわけではなく、パラメータによっては変更不可なものがあります。対応状況は以下のドキュメントをご参照ください。 参考 : データベース フラグを構成する なお、上記は PostgreSQL 版ドキュメントへのリンクとなっていますが、タイトルの見出し横のリンクから別のデータベースエンジンのドキュメントへ移動することができます。以下、全てのドキュメントで同じです。 ドキュメントの切り替え マネージドコネクションプール マネージドコネクションプール （managed connection pooling）は、Cloud SQL インスタンス側で管理されたコネクションプールを利用できる機能です。 当機能は、Enterprise Plus エディションの MySQL および PostgreSQL インスタンスで利用できます。Enterprise エディションのインスタンスや、SQL Server では利用できません。 有効化すると、データベースクライアントとのコネクションがプールの中から動的に割り当てられ、リソース使用量とレイテンシが最適化されます。これにより、突然のコネクション量のスパイクがあっても、既存のコネクションを再利用するなどにより対処できます。また、短時間のコネクションが頻発するようなケースでも有用です。 接続モードとして、トランザクションレベル（デフォルト）またはセッションレベルでのコネクション割り当てが選択できます。また最大、最小のプールサイズなど、複数の設定項目があります。 参考 : マネージド接続プーリングの概要 vCPU とメモリ マシン構成 Cloud SQL では、vCPU 数とメモリ量をカスタムして、適切なサイズのインスタンスを作成できます。 参考 : インスタンスを作成する なお検証目的等のため、比較的スペックが低い 共有コア CPU を使用するインスタンスを構築することもできます。共有コアを使う場合は、通常とは別単価が設定されているほか、SLA が適用されません。 参考 : Cloud SQL Service Level Agreement (SLA) 運用中の変更 vCPU とメモリ量は前述の通り、インスタンスの初期作成時にマシンタイプを指定することで決定しますが、インスタンスを編集することで 後から変更できます 。 ただし vCPU やメモリーの割り当て変更にはインスタンスの 再起動が必要 です。再起動を行うと、一時的にデータベースに接続できなくなります。 参考 : インスタンスを編集 参考 : インスタンスの設定について ストレージ（ディスク） 種類 Cloud SQL を作成時、使用するストレージ（ディスク）を HDD （ハードディスクドライブ）か SSD の中から選ぶことができます。どちらの場合でも複数の物理ドライブにデータが複製されているので、高い堅牢性が確保されます。 一般的な用途では SSD が推奨されます。一方の HDD は SSD よりもパフォーマンスに劣りますが、料金単価が安い点が特徴です。 通常のユースケースでは SSD を選択します。一方で、データ容量が大きくかつレイテンシが問題にならない場合、特にランダムリードアクセスの頻度が低く、シーケンシャルライトが中心のワークロードの場合のみ、HDD を選択すると良いでしょう。 参考 : SSD ストレージと HDD ストレージのいずれかを選択する 容量 ストレージの容量はインスタンス作成時に指定できます。またインスタンス作成後にも拡張が可能です。ただし、ストレージの 縮小はできません 。 ストレージの拡張は、インスタンスを起動したまま行うことができ、ダウンタイムは発生しません。 参考 : インスタンスの設定について - ストレージ容量 ストレージの自動増量 Cloud SQL インスタンスでは、オプションで ストレージの自動増量 を有効化することができます。ストレージの自動増量を有効化すると、ストレージの残容量が 30 秒ごとにチェックされ、残容量が一定回数以上、閾値を下回るとストレージが追加されます。 またストレージの自動増量には上限値を設定することもできます。 ストレージ自動拡張のトリガとなる閾値の計算方法などの詳細は、以下のドキュメントを参照してください。 参考 : インスタンスの設定について - ストレージの自動増量を有効にする パフォーマンス Cloud SQL のストレージのパフォーマンスは IOPS と スループット で表されます。 Cloud SQL ではバックエンドに Compute Engine（Google Cloud の仮想サーバーサービス）を使われており、IOPS とスループットが決まる仕組みは Compute Engine の永続ディスクと同じです。 原則的に、ストレージのサイズを大きくすればするほど IOPS とスループットが大きくなっていきます。詳細は、以下の記事の「永続ディスクのパフォーマンス」の項を参考にしてください。 参考 : Compute Engineを徹底解説！（応用編） ‐ 永続ディスクのパフォーマンス また MySQL/PostgreSQL で利用可能な Cloud SQL Enterprise Plus エディションでは、書き込みレイテンシが最適化されているためより高い性能が発揮できるほか、データキャッシュにより読み取りレイテンシの最小化を図ることもできます。 高可用性構成（HA 構成） 概要 Cloud SQL インスタンスでは、簡単に 高可用性構成 を有効化することができます。インスタンス作成時に、高可用性のオプションのチェックマークを入れるだけで、プライマリインスタンス（主系）と、別のゾーンで起動するスタンバイインスタンス（従系）を作成できます。高可用性構成は HA 構成（High Availability 構成）とも呼ばれます。 高可用性構成では、プライマリインスタンスに障害が発生した際、自動的にスタンバイインスタンスに フェイルオーバー します。 プライマリインスタンスからスタンバイインスタンスへは、永続ディスクにデータが 同期レプリケーション されます。つまり高可用性構成のデータベースのトランザクションは、両方のゾーンのディスクに書き込まれて初めてコミット完了となります。 そのため、高可用性構成のインスタンスの書き込みパフォーマンスは、高可用性構成でない場合と比べて劣る可能性があります。どのくらいの影響が出るかは、ディスク容量に応じた IOPS やデータ量などによるため一概には言えず、検証する必要があります。 また高可用性構成を有効化するとインスタンスが2台稼働するため、インスタンスの CPU、メモリ、ストレージ料金が2倍発生します。 参考 : 高可用性について フェイルオーバー Cloud SQL は毎秒、データベースに対してハートビート（ヘルスチェック）を送ります。プライマリインスタンスが約60秒間応答しない、またはプライマリインスタンスのゾーンで Cloud SQL としてのサービス停止が発生した場合にフェイルオーバーが発動します。 セカンダリインスタンスがプライマリに昇格すると IP アドレスも引き継がれる ため、アプリケーションから見ると、若干のダウンタイムの後に透過的に新プライマリインスタンスに接続できるようになります。 なおフェイルオーバー後に旧プライマリインスタンスが正常に戻っても、自動的にフェイルバックはしません。プライマリを元のゾーンに戻したい場合は明示的に再度、手動でフェイルオーバーを実行してフェイルバックする必要があります。 参考 : フェイルオーバーを開始する フェイルオーバーの発生履歴は オペレーションログ から確認できます。 参考 : インスタンスのオペレーション ログを表示する 可用性 SLA Cloud SQL SLA では「高可用性構成であること」「共有コアインスタンスではないこと」など一定の条件のもとに、 Cloud SQL サービスのダウンタイムが一定期間を超えるとクレジットの払い戻しが受けられることが定義されています。 Enterprise エディション（MySQL、PostgreSQL）および Microsoft SQL Server インスタンスでは条件を満たしていれば月間 99.95% 以上の可用性が、Enterprise Plus エディション（MySQL/PostgreSQL）では月間 99.99% 以上の可用性が定義されています。 詳細な定義は、以下の公式ドキュメントをご参照ください。 参考 : Cloud SQL Service Level Agreement (SLA) リードレプリカ リードレプリカとは リードレプリカ は、Cloud SQL インスタンスのコピーであり、読み取りリクエストを負荷分散する目的で利用します。 参考 : Cloud SQL でのレプリケーションについて プライマリインスタンスのデータが更新されると、ニアリアルタイムでデータがリードレプリカに非同期レプリケーションされます。レプリケーションの遅延は Cloud Monitoring のメトリクスで確認することができます。 参考 : レプリケーションのステータスを確認する リードレプリカは読み取りリクエストを受け取れますが、書き込みリクエストを受け取ることはできません。 リードレプリカは高可用性構成（HA 構成）と似ているように思えますが、高可用性構成は可用性の向上が目的である一方、リードレプリカは 読み取りワークロードの負荷分散が目的 であるという点で異なります。 リードレプリカは高可用性が目的ではないものの、リードレプリカをプライマリインスタンスに手動で昇格させることが可能です。これにより後述のクロスリージョンリードレプリカを用いて、リージョン間の災害対策（DR）を実現することも可能です。 参考 : レプリカをプロモートする クロスリージョンリードレプリカ リードレプリカには通常のリードレプリカの他に、 クロスリージョンリードレプリカ が存在します。 クロスリージョンリードレプリカは、異なるリージョン間でデータを同期します。以下のような目的で利用されます。 他リージョンのアプリケーションからのデータベース読み取りのレイテンシを抑える リージョン間のデータ移行 リージョン間の災害対策（DR） レプリカと災害対策（DR） 高可用性構成（HA 構成）は「可用性の向上」が目的であり、一方のリードレプリカは「読み取りワークロードの負荷分散が目的であるという違いがあります。これらは異なる仕組みですが、高可用構成とリードレプリカを併用した以下のような構成が可能です。 構成図 また、 クロスリージョンリードレプリカ を用いることで、別のリージョンにリードレプリカを構成し、リージョンレベルの災害対策（DR）を行うことができます。レプリカをプライマリインスタンスに昇格させる際は、手動で昇格を指示する必要があります。 参考 : Cloud SQL の障害復旧（DR）について また Enterprise Plus エディションでは、 高度な障害復旧 （advanced disaster recovery）機能を使うことができます。高度な障害復旧では、レプリカをプライマリインスタンスに昇格させると、旧プライマリインスタンスはレプリカになります。また、スイッチオーバーという操作で、旧プライマリインスタンスを再びプライマリインスタンスに昇格させることもできます。 参考 : 高度な障害復旧（DR）を使用する 外部レプリカ Cloud SQL では 外部レプリカ （External replica）も構成可能です。 外部レプリカを構成すると、オンプレミスや他のパブリッククラウドの MySQL、PostgreSQL、SQL Server から Cloud SQL に対してデータを同期できます。 MySQL ではさらに、逆に Cloud SQL のデータベースを外部にレプリケーションできるなど、データベースエンジンによって実現可能なことが異なります。 外部レプリカは高可用性目的や災害対策（DR）目的の他、データベースの移行の目的で利用されることもあります。 参考 : 外部レプリカを構成する 読み取りプール（read pools） 読み取りプール （read pools、リードプール） とは、読み取りワークロードを負荷分散するための仕組みです。読み取りプールはリードレプリカの集合体であり、単一 IP アドレスをエンドポイントとして、読み取りワークロードを負荷分散できます。読み取りプール機能は、MySQL、PostgreSQL、SQL Server の Cloud SQL Enterprise Plus エディションでのみ利用可能です。 従来のリードレプリカとの違いは、読み取りエンドポイントが単一 IP アドレスであることと、プールとして一括管理できる点です。アプリケーション側からはリードレプリカの存在は意識することなく、読み取りワークロードの負荷分散が可能になります。 読み取りプールの中の1台1台のレプリカは読み取りプールノードと呼ばれます。ノード数は調整可能で、最大20ノードまで拡張できる（スケールアウト・スケールイン）ほか、ノードのマシンタイプを調整することもできます（スケールアップ・スケールダウン）。 参考 : 読み取りプールについて また、読み取りプールには オートスケーリング （autoscaling）が設定可能です。CPU 使用率やコネクション数によって自動でスケールインまたはスケールアウトさせることができます。 参考 : Read pool autoscaling ネットワークと接続方法 Cloud SQL とネットワーク Cloud SQL インスタンスは Google Cloud が管理する VPC（Virtual Private Cloud）ネットワーク内に作成されます。ユーザーが管理する VPC ネットワークではなく、 Google が管理する VPC ネットワーク である点がポイントです。この Google 管理の VPC ネットワークは、Google Cloud コンソール等で見ることができず、ユーザーの視点からは隠されています。 対比のために Amazon Web Services（AWS）の Amazon RDS を例に取ると、Amazon RDS インスタンスはユーザーが所有する VPC に作成されます。一方、Cloud SQL インスタンスはそうではなく、Google が管理するマネージドな VPC ネットワーク内にインスタンスが作成されるのが特徴です。 Cloud SQL インスタンスへの接続 ユーザーのアプリケーションから Cloud SQL に接続するには、以下の選択肢があります。 方法1. パブリック IP アドレスに接続 方法2. プライベートサービスアクセス経由でプライベート IP アドレスに接続 方法3. Private Service Connect 経由でプライベート IP アドレスに接続 方法1. は Cloud SQL インスタンスにパブリック IP アドレスを割り振り、インターネット経由でアクセスする方法です。 方法2. は Cloud SQL インスタンスに割り振られたプライベート IP アドレスに接続する方法です。ユーザーの VPC と Cloud SQL が存在するサービスプロデューサーのネットワークを VPC ネットワークピアリング で接続して、ユーザーの VPC にある VM 等から Cloud SQL インスタンスのプライベート IP アドレっすに接続できます。この仕組みは プライベートサービスアクセス と呼ばれます。 方法2. プライベートサービスアクセス経由でプライベート IP アドレスに接続 方法3. は、 Private Service Connect エンドポイント と呼ばれるアクセス用のエンドポイントをユーザーの VPC ネットワーク内に作成します。Private Service Connect エンドポイントにはプライベート IP アドレスが割り振られます。この方法では、ユーザーの VPC ネットワークに VPC ネットワークピアリングで接続された他の VPC ネットワークから、エンドポイントに対して 推移的に 接続することができます。 方法1. パブリック IP アドレスで接続 仕組み Cloud SQL にはパブリック IPv4 アドレスを持たせ、インターネット経由でアクセスすることができます。IPv6 には未対応です。パブリック IP アドレスは無効化することができ、その場合は後述のプライベート IP アドレスを使用して接続します。 参考 : パブリック IP を構成する パブリック IP アドレスを使う場合、インターネット経由でのアクセスとなりますので、アプリケーションと Cloud SQL インスタンス間の通信は SSL/TLS で暗号化 することが強く推奨されます。 また後述の Cloud SQL Auth Proxy 等を使えば、通信は自動的に暗号化されるため、セキュアにアクセスすることができます。 参考 : SSL / TLS 証明書を使用して承認する アクセス制御 インターネットからの無制限のアクセスを許可することはセキュリティ上のリスクであるため、Cloud SQL では、明示的に許可する接続元 IP アドレスをホワイトリスト形式で指定できます。 この許可対象の接続元 IP アドレスリストは 承認済みネットワーク と呼ばれます。逆に、承認済みネットワークを一つも設定しない場合、インスタンスへの接続は不可能です。 承認済みネットワークは CIDR 形式 で指定します。 xx.yy.zz.0/24 のようにプレフィックスを指定して、IP アドレス範囲を登録することができます。 方法2. プライベートサービスアクセス経由でプライベート IP アドレスに接続 仕組み 多くの場合、セキュリティ上の理由から Cloud SQL にはパブリック IP アドレスを持たせないことが推奨されます。この場合、プライベート IP アドレスを用いて Cloud SQL インスタンスに接続します。 参考 : プライベート IP の使用方法の詳細 前述したとおり、Cloud SQL インスタンスは Google 管理の VPC ネットワークに作成されます。そのためユーザーの VPC と Google の VPC を VPC ネットワークピアリング と呼ばれる仕組みで接続します。 なおこのように、インスタンスが Google 管理の VPC ネットワーク（サービスプロデューサーのネットワーク）に作成され、ユーザー管理の VPC ネットワークと接続して利用する仕組みを プライベートサービスアクセス と言います。 Cloud SQL 以外にも Memorystore、Cloud Build、Vertex AI などで利用されるネットワーク形態です。 参考 : プライベート サービス アクセス サービスプロデューサーのネットワークの作成 サービスプロデューサーのネットワーク（プライベートサービスアクセス用のサブネット）は、プロジェクトで Cloud SQL インスタンスを初めて起動するときに IP アドレスレンジを指定して作成します。 指定可能な最小サイズは /24 ですが、推奨は /16 とされています。このとき、Cloud SQL を利用する予定の接続元ノード（Compute Engine VM 等）があるネットワークと 重複しない IP アドレス帯 を割り当てる必要があります。重複すると、適切なルーティングができず、クライアントと Cloud SQL インスタンスは通信できません。 一度サービスプロデューサーのネットワークを作成すれば、次回以降に Cloud SQL や Memorystore のインスタンスを構築する際は、そのネットワークを流用することができます。 設定方法 コンソール画面では、指示に沿って設定を進めることで Cloud SQL にプライベート IP アドレスを割り当て、サービスプロデューサーのネットワーク（プライベートサービスアクセス用のサブネット）を作成し、ユーザー管理の VPC との接続を有効化することで、Compute Engine VM 等から Cloud SQL インスタンスへ到達することができるようになります。 なおプライベート IP アドレスの割り当ては、Cloud SQL インスタンスの初期構築時のほか、既存のパブリック IP アドレスを利用する Cloud SQL インスタンスを設定変更して、プライベート IP アドレスの利用に変更することも可能です。 アクセス制御 Cloud SQL インスタンスが存在するサービスプロデューサーのネットワークには VPC ファイアウォールルールを設定できません 。 またパブリック IP アドレスでアクセス制御に用いる「承認済みネットワーク」の仕組みは、 プライベート IP アドレスでは使えません 。RFC 1918 アドレス範囲 ( 10.0.0.0/8 、 172.16.0.0/12 、 192.168.0.0/16 ) は自動的に許可される仕様となっています。ただし、クライアントが RFC 1918 以外のアドレス範囲に存在する場合のみ、明示的に承認済みネットワークに追加する必要があります。 参考 : 制限事項 そのためプライベート IP アドレスを用いる場合は、アクセス元 VPC ネットワークのファイアウォールルール等で、アウトバウンド接続を制限するなどしてトラフィックを制御します。 ただし VPC ファイアウォールは原則的に VM のネットワーク I/O を制御する機能です。よって、Cloud SQL へ オンプレミスから VPN や専用線経由でアクセスする経路がある場合、VPC ファイアウォールでは 制御できない ことに留意が必要です。この場合、オンプレミス側のファイアウォール等でアクセスを制御する必要があります。 アクセス元を厳しく制限したい場合は、プライベート IP アドレスではなくあえてパブリック IP アドレス接続を設定し、承認済みネットワークに1つも CIDR を登録せず、 Cloud SQL Auth Proxy （後述）での IAM 接続元承認を用いることで、特定のサービスアカウントからのみ接続できるように制限する方法も考えられます。 書き込みエンドポイント 書き込みエンドポイント （write endpoint）は、常にプライマリインスタンスのプライベート IP アドレスを指す DNS 名です。書き込みエンドポイントを使って接続することで、別リージョンに構成したリードレプリカをプライマリインスタンスとして昇格した際も、アプリケーション側で向き先 IP アドレスを変更する必要がなくなります。 書き込みエンドポイントは、プライベート IP アドレスを有効化した Enterprise Plus エディション の Cloud SQL インスタンスのみで利用可能です。そのため、基本的な使い方は、前述のプライベート IP アドレスに関する項目をご参照ください。 また、Cloud SQL Auth Proxy では書き込みエンドポイントを使えないことに注意が必要です。 参考 : Connect by using a write endpoint 方法3. Private Service Connect 経由でプライベート IP アドレスに接続 仕組み 方法3. では、 Private Service Connect エンドポイント と呼ばれるアクセス用のエンドポイントをユーザーの VPC ネットワーク内に作成します。Private Service Connect エンドポイントにはプライベート IP アドレスが割り振られます。 参考 : Private Service Connect の概要 メリット この方法のメリットは、ユーザーの VPC ネットワークに VPC ネットワークピアリングで接続された他の VPC ネットワークから、エンドポイントに対して 推移的に 接続することができる点です。方法2. のプライベートサービスアクセスを使った方法では、VPC ネットワークピアリングでサービスプロデューサーネットワークに直接接続された VPC ネットワーク内の VM や、VPN や専用線で接続されたオンプレミスのクライアントは Cloud SQL インスタンスに到達できますが、他の VPC ネットワークの VM は原則的に Cloud SQL インスタンス（サービスプロデューサーネットワーク）に到達できません。 参考 : Google CloudのVPCを徹底解説！(応用編) - - G-gen Tech Blog - Cloud VPN による推移的な通信（カスタムルート広報） 例外として、Network Connectivity Center のプロデューサー VPC スポークを使うことで他の VPC からサービスプロデューサーネットワークに到達することができますが、ネットワーク構成の大きな変更を伴う可能性があります。 参考 : Network Connectivity Centerを徹底解説！ - G-gen Tech Blog - プロデューサー VPC スポークと Private Service Access これを解消するには、方法3. で Private Service Connect を構成し、ユーザーの VPC ネットワーク内にエンドポイントを作成することで、その VPC ネットワークにピアリング接続された VPC ネットワーク内の VM からエンドポイントに到達することができるようになります。 アクセス制御 Private Service Connect エンドポイントに対しては、 VPC ファイアウォールを構成できません 。VPC ファイアウォールは基本的に、Compute Engine VM のネットワークインターフェイスに適用されるものであり、Private Service Connect エンドポイントに対しては設定できません。 よって Private Service Connect エンドポイントに対してアクセス制御を適用するには、接続元 VPC ネットワークの VPC ファイアウォールのアウトバウンドルール等で制御をする必要があります。 オンプレミスからの接続のアクセス制御 Cloud SQL インスタンスに対してオンプレミス上のクライアントから接続する際のアクセス制御は、原則的に Google Cloud 側の機能ではできません 。 VPC ファイアウォールは原則的に VM のネットワーク I/O を制御する機能です。よって、Cloud SQL インスタンスへ、オンプレミスから VPN や専用線経由でアクセスする経路がある場合、VPC ファイアウォールでは 制御できない ことになります。これは方法2.（プライベートサービスアクセス）でも方法3.（PrivateService Connect）でも同様です。 アクセス制御を実現したい場合は、オンプレミス側のファイアウォール等でアクセスを制御する必要があります。 あるいは、Cloud SQL インスタンスにプライベート IP アドレスではなくパブリック IP アドレス接続を設定し、承認済みネットワークに1つも CIDR を登録せず、 Cloud SQL Auth Proxy （後述）での IAM 接続元承認を用いる方法も考えられます。 バックアップとリストア バックアップ 仕組み Cloud SQL にはインスタンス稼働中にデータをバックアップする機能があります。 バックアップには オンデマンドバックアップ （手動）と 自動バックアップ があります。どちらも同じ仕組みをベースとしており、バックアップを手動で開始するか、自動でスケジューリングするかの違いです。また、インスタンス削除時には 最終バックアップ （final backups）が取得できます。 Cloud SQL インスタンスのバックアップを取得すると、取得開始した時点のインスタンスのデータが保存されます。既にバックアップが存在するインスタンスで複数回バックアップを取得すると、2回目以降は 増分バックアップ になります。つまり、前回のバックアップ時点から変更されたデータのみがバックアップされます。なお、最も古いバックアップが削除されたとしても、その次に古いバックアップにフルバックアップが引き継がれるため「どれがフルバックアップでどれが増分バックアップか」を気にする必要はありません。 リストアの項で後述しますが、バックアップからのリストアは 既存の Cloud SQL インスタンスを上書きする 、あるいは 新しい Cloud SQL インスタンスを生成する ことになります。 参考 : Cloud SQL バックアップについて インスタンス削除時の仕様 Cloud SQL インスタンスを削除しても、オンデマンドバックアップおよび自動バックアップは残ります。残ったバックアップから、インスタンスを起動することが可能です。 オンデマンドバックアップは、明示的に削除するか、Google Cloud プロジェクト自体が削除されるまでは保持されます。 自動バックアップは、インスタンス削除前に設定されていた自動バックアップの保持設定に基づいて保持されます。保持期限が過ぎた自動バックアップは自動的に、1日に1回のペースで削除されます。 参考 : Retained backups なお以前の仕様では、Cloud SQL インスタンスを削除すると、最終バックアップを残してその他のバックアップは削除されてしまいましたが、2025年3月25日のアップデートにより、オンデマンドバックアップと自動バックアップも残るようになりました。 料金 保存するバックアップの容量に応じて、保持している期間だけ料金が発生します。料金は2025年10月現在、東京リージョンで $0.104/GB/月 です。 例として 100 GB ストレージの Cloud SQL インスタンスのバックアップを 7 世代保存するとします。1 世代目のバックアップの容量は 100 GB であり、その後の世代は 10 % ずつ変更があるとすると、料金は以下のようになります。 100 GB + (10 GB × 6) = 160 GB → 160 GB × $0.104 = $16.64 / 月 参考 : Cloud SQL の料金 オンデマンドバックアップと自動バックアップ オンデマンドバックアップ は、任意のタイミングのタイミングで取得する Cloud SQL インスタンスのバックアップです。 一方の 自動バックアップ は、指定した時間帯で毎日取得される、日次の定期バックアップです。 Cloud SQL ではデフォルトで、7世代の自動バックアップが日次で取得されます。世代数は 0（無効化）〜365世代の間で設定できます。 自動バックアップの取得は日次で行われ、取得時刻は4時間の幅で指定された バックアップウインドウ の時間帯で行われます。バックアップ取得によりダウンタイムが発生することはありませんが、多少のパフォーマンス影響はありえるため、可能な限り利用者が少ない時間帯に設定することが望ましいです。 最終バックアップ Cloud SQL では、インスタンスの削除時に 最終バックアップ を取得できます。 最終バックアップの保持期間はデフォルトでは30日間で、1日〜365日の間で選択できます。 参考 : Final backups Google Cloud コンソールでインスタンスを削除する場合、最終バックアップを取得するチェックボックスがデフォルトでチェックされています。一方で gcloud コマンドでインスタンスを削除する場合は、明示的に --enable-final-backup フラグを true に指定する必要があるため、注意が必要です。 参考 : Delete an instance 保存先ロケーション バックアップの保存先のロケーション（リージョン）を指定することができます。 何も指定しない場合はインスタンスに最も近い「マルチリージョン」のロケーションに保存されます。インスタンスが東京リージョンにあれば asia というマルチリージョンに保存されます。データが複数リージョンに冗長化されるため、リージョン単位の大規模障害でもデータの堅牢性が保持されます。 トランザクションログ リストアの項でも記載しますが、Cloud SQL では ポイントインタイムリカバリ （PITR）が可能です。ポイントインタイムリカバリは Cloud SQL 用語というわけではなく、データをある日時・時刻の状態に巻き戻すというリカバリ方法を指す一般的な用語です。 参考 : ポイントインタイム リカバリ（PITR）を使用する ポイントインタイムリカバリには、データベースのトランザクションログを用います。トランザクションログは、MySQL ではバイナリログ（binlog）、PostgreSQL では WAL（Write Ahead Logging）と呼ばれます。 トランザクションログの保持期間は、Enterprise エディションでは1～7日の範囲で、Enterprise Plus エディションでは1〜35日の範囲で設定できます。デフォルト値は7日です。トランザクションログの保持期間は PITR の必要性に応じて期間を設定します。ただし、自動バックアップの保持期間より長く設定することはできません。 なお以前は、トランザクションログは通常のデータ領域と同じディスクに保存されていましたが、PostgreSQL は2023年1月から、MySQL は2023年8月から、SQL Server は2024年5月から、Cloud Storage に保存されるようになりました。それ以前からポイントインタイムリカバリを有効にしている場合はトランザクションログがディスク領域を圧迫していますが、一度無効化してから再度有効化することでログが Cloud Storage に保管されるようになります。ただしこれを行った場合、直近のログは消えてしまいますので注意が必要です。 リストア バックアップからの Cloud SQL インスタンスの リストア は、以下のいずれかの方法で実現できます。 名称 説明 条件・制約等 同じインスタンスへの復元 元のインスタンスの中身をバックアップ時の状態に復元 - 別のインスタンスへの復元 バックアップから別のインスタンスを生成 別プロジェクトにも復元可。データベースフラグは復元されない ポイントインタイムリカバリ 特定時点の状態に復元。ただし別インスタンス生成となり元のインスタンスは巻き戻せない 対象時点のバックアップとトランザクションログが必要 参考 : インスタンスを復元する 参考 : ポイントインタイム リカバリ（PITR）を使用する 注意点として、ポイントインタイムリカバリ（PITR）の場合は、元のインスタンスの中身を復元することはできず、別のインスタンスへの復元になります。 そのため PITR 実施後にはアプリケーションの向き先を新しいインスタンスに変更したり、あるいは復元した新インスタンスから必要なデータだけを抜き取るなどが必要です。 インポート・エクスポート Cloud SQL のオンデマンドバックアップや自動バックアップ、最終バックアップは、Google Cloud の外にエクスポートすることは できません 。 ただし、各データベースエンジンの機能によるダンプファイルのエクスポートや CSV ファイルとしてのエクスポートおよびインポートは可能です。 データベースエンジンによりますが、Google Cloud コンソールや gcloud コマンドによる操作で、Cloud Storage へこれらのファイルを直接エクスポートさせることも可能です。 また Cloud SQL for MySQL と for PostgreSQL では、 サーバーレスエクスポート 機能があります。エクスポートジョブを実行するための一時的なインスタンスが作成され、そこからダンプファイルが Cloud Storage バケットへエクスポートされるため、本番インスタンスへのパフォーマンス影響を回避できます。 詳細は以下のドキュメントやその周辺リンクからご確認ください。 参考 : SQL ダンプファイルを使用したエクスポートとインポート サポート問い合わせによるリストア 誤って Cloud SQL インスタンスを削除してしまい、また1つもバックアップが残っていない状況でも、インスタンスの削除後4日間以内であれば、Google Cloud カスタマーケアに問い合わせることでインスタンスを復旧できる可能性があります。 このようなカスタマーケアへの技術的な問い合わせを行うには、有償のカスタマーケアプランに登録する必要がある点にご注意ください。カスタマーケアへの登録は、Google Cloud コンソールから可能です。 参考 : バックアップの復元 参考 : Google Cloud カスタマーケア Cloud SQL Auth Proxy Cloud SQL Auth Proxy とは Cloud SQL に接続するには、パブリック/プライベート IP アドレス宛てに直接接続する以外にも、 Cloud SQL Auth Proxy というプロキシソフトウェアを使う方法があります。 参考 : Cloud SQL Auth Proxy について Cloud SQL Auth Proxy は、アプリケーションと同じサーバーで動作して、Cloud SQL への接続をプロキシ（中継）するソフトウェアです。 アプリケーション（データベースクライアント）から Cloud SQL Auth Proxy へは、ローカル通信（127.0.0.1 または localhost）で接続し、その後は Cloud SQL Auth Proxy から Cloud SQL へ TLS で通信します。 Cloud SQL Auth Proxy から Cloud SQL インスタンスへの通信は、TLS 1.3 で暗号化されます。 Cloud SQL Auth Proxy は、Linux、macOS、Windows 用のバイナリが用意されています。また Go のソースコードが公開されているため、他の OS 用にコンパイルして利用することも可能です。 Cloud SQL Auth Proxy による Cloud SQL への接続 (PostgreSQL の場合) メリット Cloud SQL Auth Proxy を使う利点は、以下のようなものがあります。 通信が TLS 暗号化される。データベース側の設定や SSL/TLS 証明書の管理は不要 パブリック IP アドレスを利用する場合でも「承認済みネットワーク」の追加が不要（接続元の認証は IAM） IAM データベース認証が利用可能（IAM 権限でデータベースにログイン。ユーザー・パスワード不要） 3 つ目の IAM データベース認証については後述します。 接続の流れ アプリケーションが Cloud SQL Auth Proxy を通じて Cloud SQL へ通信するフローは以下のとおりです。 アプリケーションからローカルマシン上の Cloud SQL Auth Proxy へ接続（通常のデータベースのプロトコル） Cloud SQL Auth Proxy は Cloud SQLインスタンスへの既存コネクションがあるかチェックし、存在すればそれを使う 存在しない場合、 Cloud SQL Admin API へアクセスし一時的な SSL/TLS 証明書を取得 Cloud SQL Auth Proxy から Cloud SQL インスタンスへコネクション確立 上記の 3. では Cloud SQL Auth Proxy から sqladmin.googleapis.com へ 443/TCP で通信が発生します。このドメインの IP アドレスは固定ではないので、VPC ファイアウォールルール等でアプリケーションサーバーから 0.0.0.0/0 へのアウトバウンド通信を許可する必要があります。 また 4. では Cloud SQL Auth Proxy から Cloud SQL インスタンスへ 3307/TCP でアウトバウンド通信が発生します。やはり VPC ファイアウォールルール等で、Cloud SQL インスタンスの IP アドレスに対してアウトバウンド通信の許可が必要です。 以下は、psql コマンドから Cloud SQL Auth Proxy 経由で Cloud SQL に接続するときのコマンドライン例です。 psql "host=127.0.0.1 sslmode=disable dbname=DB_NAME user=USERNAME" 他の Cloud SQL コネクタ Cloud SQL Auth Proxy の他にも、Cloud SQL への接続をプロキシする仕組みがあります。プログラムのランタイムに組み込むことのできる Cloud SQL 言語コネクタ （Cloud SQL Language Connectors）です。 参考 : Cloud SQL 言語コネクタの概要 2025年10月現在、Java、Python、Go、Node.js 用のコネクタが存在しており、これらの言語環境であれば、Cloud SQL Auth Proxy のように外部プロセスを稼働させることなく、通信の暗号化や IAM データベース認証のメリットを受けることが出来ます。 ライブラリとしてインポートして利用できるため、Cloud SQL Auth Proxy とは異なり実行環境に配置してプロセス起動する必要がありません。お使いのプログラミング言語が対応していれば、第1選択肢として有用です。 設定と接続の方法 Cloud SQL Auth Proxy を利用するには、アプリケーションやデータベースクライアントが稼働するローカルマシン上に Cloud SQL Auth Proxy をインストールします。 また Cloud SQL インスタンスへの接続元として承認されるために、IAM 権限が必要です。なおこの「接続元の承認」はデータベース（MySQL、PostgreSQL、SQL Server）の ユーザー認証とは異なる概念 であるという点に注意しましょう。日本語ドキュメントではどちらも「認証」とされているため紛らわしいのですが、当記事では「接続元の承認」という言葉と「（データベースの）（ユーザー）認証」という言葉で区別しています。前者の「承認」という言葉はパブリック IP アドレスの接続元アドレスを許可する際の「承認済みのネットワーク」と同じ意味合いです。 接続元の承認のための IAM 権限は、Google アカウントやサービスアカウント等に紐づきます。Cloud SQL Auth Proxy の実行環境が Compute Engine VM 等であれば、その VM インスタンス等にサービスアカウントをアタッチすることで、サービスアカウントが持つ IAM 権限で承認することが推奨されます。実行環境がオンプレミス等である場合は、サービスアカウントの認証情報キーを JSON ファイルとしてダウンロードして利用することになります。 詳細は以下のドキュメントを参照してください。 参考 : Cloud SQL Auth Proxy を使用して接続する 認証・認可 データベースログインのための認証 Cloud SQL のデータベースにログインするための認証方法は、2通りあります。 ユーザー・パスワードによる認証 IAM による認証 前者は、通常の MySQL、PostgreSQL、SQL Server の組み込みのユーザー・パスワードを使ってログインする方法です。通常のデータベースと変わりありません。 後者は、Google Cloud の IAM の認証情報を使ってログインする方法です。また IAM による認証にも「手動」と「自動」の2種類があります。 データベースエンジンにより、利用可能な認証方法が異なります。以下の表は 2025年10月現在の対応状況です。 DB エンジン ユーザー・パスワード認証 IAM 認証（手動） IAM 認証（自動） MySQL ◯ ◯ ◯ PostgreSQL ◯ ◯ ◯ SQL Server ◯ ✕ ✕ ユーザー・パスワードによる認証 通常の MySQL、PostgreSQL、SQL Server と同様に、ユーザー名とパスワードを使って認証します。mysql コマンドや psql クライアントなどを用いて、通常通りアクセスすることが可能です。 ユーザーの作成・管理は、原則的に通常の DB と同じ用に作成できます。また Google Cloud コンソール画面や gcloud コマンド等からもユーザー作成・削除やパスワードリセットが可能です。 インスタンス作成直後には デフォルトユーザーアカウント が作成されており、初期パスワードの設定は Google Cloud コンソールから実施する必要があります。 Cloud SQL のデフォルトユーザーアカウント名は、MySQL では root 、PostgreSQL では postgres 、SQL Server では sqlserver です。 IAM による認証の概要 データベースに対して、Google Cloud の IAM の仕組みで認証できます。Cloud SQL インスタンスに対し、ユーザーアカウントまたはサービスアカウントが cloudsql.instances.login 権限を持っている必要があります。 この権限は、Cloud SQL 管理者（ roles/cloudsql.admin ）ロール、Cloud SQL インスタンス ユーザー（ roles/cloudsql.instanceUser ）ロール等に含まれています。 このとき、Google Workspace や Cloud Identity の Google グループ に権限を持たせることもできます。ユーザーアカウントやサービスアカウントを Google グループにまとめておき、グループにアクセス許可を与えることで、異動や退職の際の運用が効率化されます（以前はグループを紐づけることはできませんでしたが、2024年7月末のアップデートで可能になりました）。 IAM 認証のうち、「自動認証」では Cloud SQL Auth Proxy や各種コネクタが IAM 権限を使って認証情報の取得を認証を自動的に行ってくれます。「手動認証」ではアプリケーションのコードで明示的にアクセストークンを取得して、これを使って認証します。 参考 : IAM 認証 IAM による認証（自動） IAM 自動認証を使うためには、データベースへの接続に通常の DB クライアントではなく前述の Cloud SQL Auth Proxy もしくは Cloud SQL 言語コネクタ を利用します。 参考 : 自動 IAM データベース認証を使用してログインする IAM による認証（手動） 手動認証は、自動認証とは異なり、プログラム内で明示的にアクセストークン（一時的な認証情報文字列。形式は OAuth 2.0 トークン）を Google API 経由で取得する必要があります。 ユーザーアカウント / サービスアカウントで gcloud コマンドを実行し Google Cloud へ認証 ユーザーアカウントの場合 : gcloud auth login サービスアカウントの場合 : gcloud auth activate-service-account コマンド gcloud sql generate-login-token でアクセストークンを取得 DB クライアントで DB へ接続 ユーザー名 : ユーザーアカウント / サービスアカウントのメールアドレス パスワード : 取得したアクセストークン 以下は、コマンド例です。 gcloud auth login PGPASSWORD=$(gcloud sql generate-login-token) psql --host=localhost --username=hoge@example.com --dbname=mydatabase 参考 : 手動 IAM データベース認証を使用してログインする メンテナンス 概要 Cloud SQL はマネージドサービスなので、物理基盤、OS、データベースエンジンは Google Cloud によって管理されます。 ただし、数か月に1度程度の頻度で、ダウンタイムを伴う メンテナンス が必要となります。メンテナンスには例として、Cloud SQL 自体の機能アップデート、データベースエンジンのマイナーバージョンアップデート、OS に対するパッチ適用などが含まれます。 参考 : Cloud SQL インスタンスでのメンテナンスについて メンテナンスによる平均的なダウンタイムは30秒未満とされています（Enterprise エディションの PostgreSQL の場合）。また特定の条件を満たした Enterprise Plus エディションの場合、「ダウンタイムがほぼゼロの計画的メンテナンス（Near-zero downtime planned maintenance）」が適用され、この場合はダウンタイムが一般的に1秒未満とされています。 メンテナンスウインドウ、メンテナンスタイミング、拒否期間 メンテナンスを実施する時間を指定するため Cloud SQL インスタンスには メンテナンスウインドウ （メンテナンスの時間枠）を設定します。 メンテナンスウインドウには 曜日 と1日の中の 1時間枠 を設定できます。例えば「日曜日 01:00〜02:00」のように設定すると、メンテナンスが必要な際にこの時間枠の中でアップデートが実施されます。最もシステムの利用率が低い時間帯に設定するのが望ましいでしょう。 また メンテナンスタイミング という設定値により、メンテナンス通知から何週間のうちにメンテナンスが行われるかを制御することができます。 Any 、 Week 1 、 Week 2 、 Week 5 の中から選択可能です。 さらに、システムの繁忙期等の理由で安定稼働が求められる場合は メンテナンス拒否期間 を最長で90日間設定できます。これが設定されている期間はメンテナンスが行われません。 参考 : Cloud SQL インスタンスでのメンテナンスについて - メンテナンスの設定 事前通知 Cloud SQL インスタンスのメンテナンス通知をメールで受け取れるように設定可能です。また、詳細は Google Cloud コンソールのインスタンス詳細ページ等から確認可能です。 通知後、どのくらいの期間のあとにメンテナンスが行われるかは、前述の「メンテナンスタイミング」設定値によります。 参考 : Cloud SQL インスタンスでのメンテナンスについて - 今後のメンテナンスに関する通知 参考 : Opt in to maintenance notifications メンテナンスの延期・即時適用 元々のメンテナンス予定日時から28日以内の範囲で、メンテナンスのスケジュールを変更することができます。スケジュールは「次回（1週間後）のメンテナンスウインドウ」あるいは「任意の日時」に変更可能です。 反対に、予告されているメンテナンスに対して即時実行を指示することもできます。 メンテナンスの仕組み 通常のメンテナンスの平均的なダウンタイムは30秒未満とされています。これはアップデートを短期間で終わらせる仕組みを Cloud SQL がバックエンドで実現しているからです。 ユーザー側からは特に意識する必要はありませんが、以下のようなプロセスでアップデートが行われることが明らかにされています。 アップデート適用済みの新規インスタンスがバックエンドで起動される 既存データベースを停止する ディスクと IP アドレスを新規インスタンスに引き継ぐ 新規インスタンス側でデータベースを起動する 参考 : メンテナンスの仕組み インプレースアップグレード データベースのマイナーバージョンアップデート等は、前述のメンテナンスにより行われます。これとは別で、ユーザーが明示的に指示することにより メジャーバージョンのアップグレード も可能です。 既存の Cloud SQL インスタンスのデータベースのメジャーバージョンをアップグレードすることを、 インプレースアップグレード （In-place Upgrade）と言います。 インプレースアップグレードでは既存インスタンスが直接アップグレードされるので、インスタンス名、 IP アドレス、データベースフラグ、データなどは引き継がれます。アップグレードにはダウンタイムが伴いますが、通常は10分以内に収まります。ただし所要時間はインスタンスの vCPU やメモリ量、データサイズに応じて変化します。またアップグレードの前後にバックアップが自動的に取得されます。 なおインプレースアップグレード以外には、新しいメジャーバージョンの新規インスタンスを構築して、データを移行するという方法があります。 実施の手順や対応しているバージョン等は DB エンジンによって異なります。詳細は以下のドキュメントをご参照ください。 参考 : データベースのメジャー バージョンをインプレースでアップグレードする モニタリング・ロギング Cloud Monitoring によるメトリクス収集 Cloud SQL の主要なパフォーマンスを測定する指標（メトリクス）は Cloud Monitoring の機能により自動的に収集されています。収集される指標は多岐にわたりますが、以下は代表的なものです。 CPU 使用率、メモリ使用量、ストレージ使用量 ディスク I/O ネットワーク I/O アクティブなコネクション数 秒間トランザクション数 Google Cloud コンソールには、これらの情報をわかりやすく可視化した システム分析情報ダッシュボード の画面が閲覧できます。 参考 : システム分析情報を使用してシステム パフォーマンスを向上させる また、取得可能な指標はデータベースエンジン（MySQL、PostgreSQL、SQL Server）によって異なります。指標の一覧は、以下のドキュメントをご参照ください。 参考 : Google Cloud metrics Cloud Monitoring の詳細は、以下の記事もご参照ください。 blog.g-gen.co.jp Query Insights Query Insights 機能により、データベースに対するクエリのパフォーマンスを精査できます。Query Insights では、以下のような事項が確認できます。 データベースの負荷状況 クエリごとの負荷状況 特に負荷が高いクエリの特定、実行計画・所要時間等の表示 Query Insights を利用するには、インスタンスごとに明示的に有効化する必要がありますが、料金は発生しません。有効化すると7日分の情報が保存されます。 参考 : Query Insights を使用してクエリのパフォーマンスを向上させる また、アプリケーションで OR マッパー（ORM）を使っている場合、ソースコードに直接 SQL を記述しないため、負荷の大きいクエリを特定しづらいときがあります。そのような場合に sqlcommenter というオープンソースライブラリを使うことで、クエリにタグ付けし、Query Insights でクエリを特定しやすくすることができます。 参考 : ORM での sqlcommenter の使用 ロギング Cloud SQL の各種ログは Cloud Logging に出力されます。Cloud Logging は Google Cloud のフルマネージドなログ管理サービスです。Cloud Logging では、Google Cloud コンソール画面からログを参照したり、BigQuery や Cloud Storage にログをエクスポートしたりできます。 例として PostgreSQL であれば、 postgres.log ファイルの内容等が Cloud Logging に自動的に出力されます。 デフォルトでは、ログは Cloud Logging の _Default ログバケットに入り、30日間保存されます。この場合、料金は発生しません。これ以上の期間の保管が必要な場合、Cloud Logging で「シンク（ログルーター）」を作成して、より長期間のログバケットへログを格納します。 Cloud Logging の機能の詳細は以下の記事をご参照ください。 blog.g-gen.co.jp 監査 クラウドリソースとしての監査ログ Cloud SQL のクラウドリソースとしての監査ログは、 Cloud Audit Logs の機能を通じて Cloud Logging に出力されます。 参考 : 監査ログ Cloud SQL に対する「インスタンスの作成、削除、設定変更、起動、停止」のような変更オペレーションは、デフォルトで自動的に記録されます。これらのログは、管理アクティビティ監査ログと呼ばれます。 一方で「インスタンス一覧の表示、設定情報の取得」のような閲覧系オペレーションや「Google Cloud コンソールや gcloud コマンドからのデータベースユーザーの作成」のようなオペレーションは、明示的に有効化する必要があります。これらのログは、データアクセス監査ログと呼ばれます。 これらの監査ログを記録する機能である Cloud Audit Logs の詳細は、以下の記事をご参照ください。 blog.g-gen.co.jp データベースとしての監査ログ データベース内のデータへのアクセス履歴やデータ変更の履歴等は、 データベースエンジンごとの監査ログの仕組み で記録する必要があります。 例として PostgreSQL では pgAudit エクステンションを有効化して、ログを出力するよう明示的に設定することができます。データベースエンジンごとに、監査ログを有効化する方法は異なります。以下の公式ドキュメントをご参照ください。 参考 : MySQL データベースの監査 参考 : pgAudit を使用して PostgreSQL の監査を行う 参考 : SQL Server データベースの監査 暗号化 デフォルトの暗号化 Google Cloud では、すべてのデータは 保存時に暗号化される 仕様になっています。このデフォルトの暗号化の仕組みは、ストレージの透過的な暗号化であり、私たちユーザーには意識されません。このデフォルト暗号化が対抗できる脅威は「物理的な持ち去り」「データセンターの従業員による直接のアクセス」などです。 参考 : デフォルトの保存データの暗号化 また同様に、VPC ネットワーク内を転送中のデータも自動的に暗号化されます。この暗号化が対抗できる脅威は「データセンター内での通信の盗聴」等です。 参考 : 転送データの暗号化 これらの暗号化は Cloud SQL でも適用されており、私たちユーザーが何もしなくても、保存時のデータは暗号化されていますし、通信が Google Cloud 内にとどまっている限り、通信も暗号化されます。 その他の暗号化 前述のように、Cloud SQL では何もしなくても、データが保存時や転送時に暗号化されています。ただし、「各種セキュリティ監査の対応」「パブリックインターネットでのデータ転送」「データセンターの内部犯行への対策を含むより強固なセキュリティが求められる」「クラウドリソースに対する追加のアクセス制御を施したい」などの理由がある場合、追加の選択肢もあります。 Cloud KMS に暗号鍵を登録することで、 Google が管理する鍵ではなくユーザーが管理する鍵でストレージを暗号化するよう指定できます。これを、顧客管理の暗号鍵（Customer-managed Encryption Keys、 CMEK ）による暗号化と呼びます。ほとんどのセキュリティ要件ではデフォルトの暗号化で十分ですが、監査上の目的や前述のような理由で自前での鍵管理が求められており、かつ自前での鍵管理が 運用上可能 である場合は、Cloud KMS を使った CMEK 暗号化を検討します。 参考 : 顧客管理の暗号鍵（CMEK）の利用 通信時の暗号化に関しては、SSL/TLS 証明書を登録し、SSL/TLS 暗号化を強制させることもできます。また前述の Cloud SQL Auth Proxy を用いると、通信は TLS 暗号化されます。 参考 : SSL/TLS 暗号化 なお、ストレージの透過的な暗号化では Web アプリケーションやミドルウェアの脆弱性を突く攻撃手法の多くに対抗できません。以下のドキュメントでは、Cloud KMS によって管理された鍵を使い、データを エンベロープ暗号化 したうえでデータベースに格納する手法が紹介されています。 参考 : クライアントサイドの暗号化 その他留意事項 データベースエンジンごとの機能差 Cloud SQL では MySQL、PostgreSQL、SQL Server の3種類のデータベースエンジンをサポートしていますが、エンジンごとに利用可能な Cloud SQL 機能に差があります。 以下のドキュメントでは機能差を一覧表で確認できます。 参考 : データベース エンジンによる Cloud SQL の機能サポート 標準的なデータベースとの違い Cloud SQL で動作するデータベースエンジンには、一般的な MySQL、PostgreSQL、SQL Server との違いが存在し、いくつかの機能や特殊なコマンドが使えない場合があります。 詳細は以下のドキュメントでご確認ください。 参考 : Cloud SQL の機能 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Google Cloud の機械学習プラットフォームである Vertex AI を解説します。 Vertex AI とは Vertex AI と生成 AI Generative AI on Vertex AI Vertex AI Studio AI Applications（Vertex AI Search / Vertex AI Agents） AutoML AutoMLとは Vertex AI における AutoML AutoML の料金 カスタムトレーニング カスタムトレーニングを使用したモデル作成 カスタムトレーニングの料金 AutoML vs カスタムトレーニング 構成要素 マネージドデータセット トレーニング Vertex AI Model Registry エンドポイント Batch predictions Vertex AI に統合されたその他のツール 概要 Vertex AI Workbench Vertex AI Feature Store Vertex AI Pipelines Vertex ML Metadata Vertex AI Experiments Vertex AI Vizier Vertex AI Vector Search Vertex AI Model Garden Colab Enterprise Vertex AI とは Vertex AI とは、Google Cloud で機械学習ワークロードを構築したり、モデルをトレーニングしたり、あるいは推論エンドポイントをデプロイするためのツールを統合したプロダクトです。 Vertex AI では、トレーニング用データの管理から機械学習モデルのトレーニング、作成したモデルのデプロイまでを一気通貫で行うことができるほか、機械学習の開発、運用に役立つ様々なツールが提供されます。Vertex AI という名前の付いたプロダクトは多数存在し、それぞれ役割が異なります。 独自モデルの開発には AutoML の仕組みを利用することもでき、トレーニングデータをアップロードするだけでモデルの作成を行うことも可能です。 また、Gemini や Claude など、生成 AI モデルによる推論やファインチューニングも、Vertex AI の API 経由で行うこともできます。 参考 : Vertex AI のドキュメント Vertex AI と生成 AI Generative AI on Vertex AI Google Cloud では、生成 AI に関するプロダクトは、Vertex AI ブランドに統合されています。これらのプロダクトを利用することで、機械学習に関する専門知識がなくても、生成 AI を組み込んだアプリケーションを容易に構築することができます。 Vertex AI 経由で生成 AI を利用することに関する各種機能は、 Generative AI on Vertex AI と総称されます。 参考 : Vertex AI の生成 AI の概要 私たちユーザーは、Vertex AI 経由で提供される Gemini モデルなどの API に対してプロンプト等を送信することで、簡単にモデルからのレスポンスを受け取ることができます。認証は Google Cloud の IAM で行うことができるため、Google Cloud 上でホストされるアプリケーションと容易に統合できます。 Vertex AI API 経由でのモデル利用 Vertex AI Studio Vertex AI Studio は、Google が提供する生成 AI モデルを、Web コンソール上でプロトタイピングしたり、テストできる UI ツールです。言語・音声・画像・動画の生成モデルを使用することができます。 ソースコードを書かずに Gemini をはじめとする Google 製の生成 AI モデルを呼び出せるため、モデルの性能を気軽に試すのに最適です。 参考 : Vertex AI Studio で Gemini プロンプトを作成して最適化する Vertex AI Studio の Web UI Vertex AI Studio の使用例は、以下の記事を参照してください。 blog.g-gen.co.jp Vertex AI Studio で利用できる言語モデルの詳細、プロンプト設計の例などは以下の記事で解説しています。 blog.g-gen.co.jp AI Applications（Vertex AI Search / Vertex AI Agents） AI Applications は、機械学習の専門知識を持っていない開発者でも、生成 AI による検索やチャットアプリケーションを構築することができるサービスです。 AI Applications には Vertex AI Search と Vertex AI Agents の2種類のツールが組み込まれており、特に前者の Vertex AI Search では、セマンティック検索（意味論検索）を簡単に構築することができます。 参考 : What is AI Applications? 詳細は以下の記事も参照してください。 blog.g-gen.co.jp AutoML AutoMLとは AutoML （Automated Machine Learning）は Google Cloud に特有の用語ではなく、機械学習モデルの反復的な学習を自動化する仕組みを指します。 機械学習では、コンピュータの処理能力を活かして大量のデータを解析し、その規則性や関連性を自動で発見、学習させることで、未知のデータに対して高い精度で予測を行うことができる モデル を作成します。 しかし、モデル作成時の以下のような作業については、予測精度に大きな影響を及ぼすにもかかわらず自動化することが難しく、基本的にはモデル開発者の手に委ねられることになります。 学習アルゴリズムの選択（ex. ランダムフォレスト、ロジスティック回帰、サポートベクターマシン...） ハイパーパラメータのチューニング（ex. ペナルティ、コストパラメータ...） 学習データの前処理 これらは開発者個人の知識と経験に大きく左右され、機械学習の導入における高いハードルとなります。このような人力で行う必要があるタスクについては、主に以下のような課題があります。 ハイパーパラメータのチューニングやデータ前処理には試行錯誤が必要であり、時間がかかる モデルの作成が終わったあとも、予測精度を保つために一定期間で再学習を行う必要がある（再度、試行錯誤しなければならない） そもそも機械学習を扱えるエンジニアがいない また、「時間をかけてモデルを開発したが、期待していたよりも予測精度が低く、そもそも機械学習に向いている課題ではないことがわかった」といったことも起こり得ます。 AutoML では、上記の人力によるタスクも含めたモデルの作成工程がすべて自動化され、トレーニング用のデータを用意するだけで、一定程度に高精度なモデルを作成することができます。 これにより、機械学習を扱えるエンジニアがいなくても簡単にモデルを作成することができるほか、目の前の課題に対して機械学習を用いた PoC を気軽に行うことができるようになります。 AutoML によるモデル作成の自動化 Vertex AI における AutoML Vertex AI における AutoML （以降、当記事内の「AutoML」は Vertex AI における AutoML を指します）では、トレーニング用のデータを Google Cloud にアップロードするだけで、モデルを作成することができます。 参考 : 独自のモデルをトレーニングして使用する - AutoML AutoML におけるモデル作成の工程は以下の通りです。 工程 説明 ①マネージドデータセットの作成 トレーニングデータのソースを指定し、マネージドデータセットとして定義します。 ②モデルのトレーニング トレーニングデータとして使用するマネージドデータセットを選択すると、AutoML がモデルを作成します。 ③モデルのデプロイ（任意） モデルをデプロイし、オンライン予測のためのエンドポイントを作成します。 また、AutoML で作成することができるモデルのタイプは以下の通りです。 データの種類 モデルのタイプ 画像 分類 / オブジェクト検出 表形式 回帰 / 分類 / 予測 テキスト 分類 / エンティティ抽出 / 感情分析 動画 分類 / オブジェクトトラッキング / 動作認識 AutoML の料金 AutoML を使用したモデルのトレーニングでは、トレーニングの際に Google Cloud 上で実行される、コンピューティングノードの使用時間に応じて課金されます。 データの種類ごとのトレーニング料金は以下の通りです。 データの種類 料金 画像 $ 3.465 / 時間 表形式 $ 21.252 / 時間 テキスト $ 3.30 / 時間 動画 $ 3.234 / 時間（分類 / オブジェクトトラッキング） $ 3.300 / 時間（動作認識） 参考 : Vertex AI の料金 - AutoML モデルの料金 カスタムトレーニング カスタムトレーニングを使用したモデル作成 AutoML によって目的のモデルが作成できない場合、もしくはモデルの開発環境や工程を細かく制御したい場合、カスタムトレーニングによってモデルを作成することになります。 カスタムトレーニングではモデルのトレーニングを実行するコード（ トレーニングコード ）をユーザー側で用意し、以下のリソースを作成して、Google Cloud のインフラストラクチャ上でモデルのトレーニングを行います。 参考 : トレーニング コードを準備する リソース名 説明 カスタムジョブ トレーニングコードを実行するジョブ。 ハイパーパラメータ調整ジョブ 様々なハイパーパラメータのセットを使用してトレーニングコードのトライアルを実行し、最適なハイパーパラメータの組み合わせを検出するジョブ。 トレーニングパイプライン カスタムジョブまたはハイパーパラメータ調整ジョブを実行し、作成されたモデルを出力するパイプライン。 カスタムトレーニングの料金 カスタムトレーニングの実行には、Google Cloud のプロジェクトで起動される Compute Engine VM が使用されます。 カスタムトレーニングでは、Compute Engine のマシンタイプごとに設定されたコンピューティングリソースの料金、アクセラレータやディスクの使用に応じた料金が発生します。 参考 : Vertex AI の料金 - カスタム トレーニング済みモデル AutoML vs カスタムトレーニング AutoML とカスタムトレーニングを比較する場合、モデル作成の手軽さと自由度の高さがトレードオフとなります。 まずは AutoML の使用を検討し、AutoML でモデルの精度が上がらなかったり、AutoML を使用できない要件があったりする場合にカスタムトレーニングを使用するとよいでしょう。 参考 : トレーニング方法を選択する AutoML カスタムトレーニング データサイエンスの専門知識 不要。 必要。 トレーニングコードの開発や、特徴量エンジニアリングなどのデータ準備を行う必要がある。 プログラミングスキル 不要。 必要。 トレーニングコードを開発する必要がある。 モデルのトレーニングに要する時間 開発やデータ準備の必要がないため、短め。 トレーニングコードの開発やデータ準備を行う必要があるため、AutoML と比べると長め。 機械学習の目標に関する制限 AutoML で定義されている目標 のいずれかをターゲットにする必要がある。 なし。 パフォーマンス最適化のためのハイパーパラメータ調整 できない。 自動でハイパーパラメータ調整が行われる。 できる。 トレーニング環境の制御 制御できる要素が少ない。 トレーニングに使用するノード時間と早期停止 ( Early stopping ) の指定のみ可能。 制御できる要素が多い。 開発環境として使用する Compute Engine VM のマシンタイプ、ディスクサイズ、機械学習フレームワーク、ノード数などの要素を指定できる。 データサイズの制限 制限あり。 Vertex AI で管理される マネージドデータセット を使用する必要があるが、データの種類によってサイズの制限がある（ 参考 ）。 （例）表形式データの CSV ファイルの場合：最大 100 GB 制限なし。 マネージドデータセットを使用する場合のみ AutoMLと同様の制限あり。 構成要素 マネージドデータセット マネージドデータセット （managed datasets）とは、機械学習モデルのために収集したデータを格納するオブジェクトです。データをマネージドデータセットとして登録すると、データを一元的に管理することが可能です。 マネージドデータセットのソースとしては、たとえば表形式データであれば、ローカル PC もしくは Cloud Storage にある CSV ファイル、BigQuery のテーブル、ビューから選択することができます。 マネージドデータセットはデータソースの URI を持ち、トレーニングの際にデータソースからデータがインポートされます。ローカル PC からデータをインポートした場合は、データは Cloud Storage に格納され、データセットにはその URI の情報が渡されます。 AutoML を使用する場合、まずマネージドデータセットを作成し、それをトレーニング時に読み込む必要があります。 参考 : Vertex AI でのマネージド データセットの作成の概要 トレーニング トレーニング （Training）は、AutoML によるトレーニング、もしくはカスタムトレーニングを実行する際に作成するオブジェクトです。トレーニングにより開発されたモデルは、 Vertex AI Model Registry で一元管理されます。 なお、 Vertex Explainable AI を使用することで、トレーニングで作成したモデルの 特徴アトリビューション の情報を得ることができます。 参考 : Vertex Explainable AI の概要 特徴アトリビューションは、各特徴（表形式データの場合はそれぞれの列）が予測にどの程度影響を及ぼしたかを可視化することができます。現在は表形式データ、画像データのモデルにおいてのみ使用することが可能となっています。 特徴アトリビューション Vertex AI Model Registry Vertex AI Model Registry では、作成した機械学習モデルを一元管理できるビューが提供されます。 ここでは Vertex AI で作成したモデルのほか、BigQuery ML や、Google Cloud 以外でトレーニングしたモデルをインポートし、バージョニング等の管理をすることができます。 Vertex AI Model Registry で管理しているモデルは、TensorFlow のパッケージとしてエクスポートすることができ、Google Cloud 以外の場所にもデプロイすることが可能です。 参考 : Vertex AI Model Registry の概要 エンドポイント エンドポイント （Endpoints）は、作成したモデルをデプロイし、オンライン予測のリクエストを処理する API エンドポイントです。 参考 : エンドポイントにモデルをデプロイする 1つのエンドポイントに対して複数のモデルをデプロイすることもでき、モデルごとにトラフィック転送の割合を指定できます。 これを利用することで、モデルの新しいバージョンをデプロイする際、同じエンドポイントにデプロイしてトラフィックの一部を割り当てることで、エンドポイントを新たに生成することなく、モデルをカナリアリリースすることも可能となります。 また、デプロイしたモデルに Vertex AI Model Monitoring を使用することで、オンライン予測の入力データから トレーニング / サービング スキュー や 予測ドリフト をモニタリングすることができます。 モニタリング対象 説明 トレーニング / サービング スキュー 本番環境での特徴データの分布が、モデルのトレーニングに使用された特徴データの分布と異なることで、モデルの予測パフォーマンスが低下する現象。 予測ドリフト 本番環境において、特徴データの分布が時間の経過とともに大きく変化してしまい、モデルの予測パフォーマンスが低下する現象。 参考 : Vertex AI Model Monitoring の概要 Batch predictions バッチ推論 （バッチ予測、Batch predictions）では、モデルをデプロイすることなく、非同期リクエストによるバッチ予測を行うことができます。 参考 : Vertex AI での予測取得の概要 エンドポイントを使用したオンライン予測とは異なり、1回のリクエストで複数の予測用データを処理することができます。 バッチ予測では、モデルのタイプ（画像・動画・表形式など）に応じて、予測用データのソースと予測結果の出力先を選択します。 たとえば表形式データの予測では、データソースとしてローカルにある CSV ファイル、Cloud Storage にある CSV ファイル、BigQuery のテーブルやビューを選択でき、出力先には Cloud Storage 、BigQuery を選択できます。 Vertex AI に統合されたその他のツール 概要 Vertex AI に統合されている、モデル作成の効率化やモデル品質の継続的な改善のためのツールを、概要レベルで解説します。これらのツールは同じ Vertex AI の名前を冠していますが、それぞれ異なる役割を持っています。 これらは、Vertex AI という共通のブランディングを持っていながら、別々のツールであると考えることができます。 Vertex AI Workbench Vertex AI Workbench は、機械学習モデルを作成するための Jupyter Notebook ベースの開発環境を提供するマネージドサービスです。 環境は JupyterLab でパッケージ化されており、TensorFlow や PyTorth などの各種機械学習フレームワークがプリインストールされています。 Vertex AI Workbench を利用することで、BigQuery や Cloud Storage のデータへのアクセス、BigQuery のクエリ発行、Vertex AI パイプラインの構築と実行など、モデル作成に関する様々なタスクをすべてノートブック上で行うことができます。 参考 : Vertex AI Workbench の概要 詳細については以下の記事でも解説しています。 blog.g-gen.co.jp Vertex AI Feature Store Vertex AI Feature Store は、機械学習に用いる 特徴量 （features）を一元化して管理するためのリポジトリを提供するマネージドサービスです。 特徴量を一元的に管理することで、組織内のモデル開発者ごとに特徴量の計算方法が異なったり、特徴量の情報が分散してしまったりすることを防ぎ、特徴量の共有・再利用を促すことができます。 また、Feature Store では特徴量の分布変化が監視され、トレーニング / サービング スキューや、予測ドリフトの回避に役立てることができます。 Vertex AI Feature Store では、特徴データは BigQuery のテーブルまたはビューで管理されており、BigQuery データソースから直接オンラインで提供することができます。 参考 : Vertex AI Feature Store について Vertex AI Pipelines Vertex AI Pipelines では、データの前処理、データ変換、モデルのトレーニングなどをコンポーネントとしてパイプラインを構成し、オーケストレートするためのマネージドサービスです。 参考 : Vertex AI Pipelines の概要 パイプラインは Kubeflow Pipelines SDK または TensorFlow Extended を使用して構築された、コンテナベースの機械学習ワークフローとして動作します。 参考 : パイプラインのビルド - 使用するパイプライン SDK の選び方 Vertex ML Metadata や Vertex AI Model Monitoring などと併用することで、パイプラインを用いたモデルの迅速かつ継続的なデプロイと、モニタリングを通じたモデルの品質維持、改善による MLOps を実践することができます。 Vertex AI Pipelines の詳細については以下の記事でも解説しています。 blog.g-gen.co.jp Vertex ML Metadata Vertex ML Metadata は、機械学習ワークフローによって生成されるデータセットやモデルなどのアーティファクト、実行、イベント、コンテキストなどのリソースに対して付与されるメタデータを管理するためのマネージドサービスです。 各リソースには ID や リージョンのほか、作成日、更新日、保存場所、リソースの作成に使用された要素などの Key-Value 形式のメタデータが付与されることに加え、モデルのリネージの分析や、実行されたパイプラインの追跡を行うことができます。 参考 : Vertex ML Metadata の概要 Vertex AI Experiments Vertex AI Experiments は、モデルのアーキテクチャ、ハイパーパラメータ、トレーニング環境を分析して比較し、最適なモデルを選択するのに役立てることができるツールです。 モデルのトレーニングにおける入力（各種パラメータ）や出力（モデル精度の指標）、使用されたデータセットなどの組み合わせを テスト （experiment）という1つの単位としてまとめて追跡し、それぞれのテストを比較できます。 また、Vertex AI Pipelines との統合により、複数のパイプラインのテストを比較することも可能です。 参考 : Vertex AI Experiments の概要 テストの追跡、可視化には Vertex ML Metadata と、マネージドな TensorBoard インスタンスである Vertex AI TensorBoard が使用されます。 参考 : Vertex AI TensorBoard の概要 Vertex AI Vizier Vertex AI Vizier は、ハイパーパラメータのチューニングを支援するツールです。 複雑な機械学習モデルのトレーニングにおいて、既知の目的関数（モデル予測で最大化 / 最小化したい関数。予測と正解のズレを表す 評価関数 など）がない場合や、目的関数を使用したモデルの評価が困難な場合に、ハイパーパラメータを自動で最適化する ブラックボックス最適化 が提供されます。 参考 : Vertex AI Vizier の概要 Vertex AI Vector Search Vertex AI Vector Search は、ベクトル検索を自前で開発することなくシステムに組み込むことができるサービスです。 ベクトル検索は、YouTube や Google 画像検索、Google Play などのサービスでレコメンデーションや情報検索の際に使われています。情報を予め エンベディング と呼ばれる数列に変換して格納しておくことで、文字列一致ではない、意味に基づいた検索が可能になります。 参考 : Vertex AI Vector Search の概要 Vertex AI Model Garden Vertex AI Model Garden は、機械学習モデルなどの製品をカタログ形式で閲覧でき、購入できるプラットフォームです。様々なタスク、データセットに対応した 100 以上のモデルが Google やサードパーティによって提供されています。 Model Garden により、Gemini などの Google が提供するモデルのみならず、Claude や Llama などのサードパーティのモデルも、Google Cloud（Vertex AI）経由で利用することができます。 参考 : Model Garden で AI モデルを確認する Model Garden で利用可能なモデルは以下の 3 カテゴリに分類されます。これらのモデルは、タスクに合わせてカスタマイズできるものや、特定のタスクであればそのまま使用できるものがあります。 カテゴリ 説明 Foundation models（基本モデル） 事前トレーニングされた大規模モデルで、Generative AI Studio、Vertex AI API、Vertex AI SDK for Python を使用することで、特定のタスクに合わせてカスタマイズできる。 Fine-tunable models（ファインチューニング可能なモデル） カスタムノートブックやパイプラインを使用してファインチューニングができるモデル。 Task-specific solutions（タスク固有のソリューション） すぐに使用することができる事前構築済みモデル。独自のデータを使用してカスタマイズできるものを含む。 Colab Enterprise Colab Enterprise は、Vertex AI に統合されたマネージドな Google Colaboratory 環境です。インフラストラクチャの管理をすることなく、Jupyter ノートブック上で開発や作業を行うことができます。 ランタイム という単位でノートブック内のコードを実行する仮想環境（VM）が起動され、マシンタイプに応じた時間料金が発生します。ランタイムは使用していないときに自動でシャットダウンし、コストを節約することができます。 また、ノートブックでは Gemini によるコード補完を利用することができます。 参考 : Colab Enterprise の概要 詳細については、以下の記事で Vertex AI Workbench との比較とともに解説しています。 blog.g-gen.co.jp 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

事象 原因 解説 SQL における BigQuery のテーブル名の指定 バッククォートの要否 対策 対症療法 原則 事象 BigQuery で 標準 SQL を実行しようとした際に以下のエラーが発生した。 エラーメッセージで示された該当箇所は、テーブル名の指定であり、一見しておかしなところは見当たらない。 実行しようとした SQL INSERT my-project.mydataset.mytable (id, name, subject, score) VALUES ( " 1111 " , " John Doe " , " Math " , 90 ), ( " 2222 " , " Jane Doe " , " Math " , 95 ) エラーメッセージ Syntax error: Expecting VALUES list or query at [2:7] ※ 末尾の大括弧内の数字はエラー構文の位置を示すため改行やインデント等により異なる SQL の構文は正しいはずなのにエラーとなる 原因 当事象の原因は、プロジェクト ID にダッシュ記号 (別名ハイフン : - ) が使われているのにも関わらず、テーブル指定をバッククォート ( ` ) で囲わなかったことです。 BigQuery では INSERT 句のテーブル識別子がバッククォートで囲まれていない場合、プロジェクト ID にダッシュ記号が使われていると構文エラーとなります。 解説 SQL における BigQuery のテーブル名の指定 BigQuery で標準 SQL を使う際、以下のように、テーブル指定をバッククォート (英語では backquote または backtick) 記号で囲むのが原則です。 SELECT * FROM `my-project.mydataset.mytable` BigQuery のテーブル識別子は、以下のような構成です。 `(プロジェクト ID).(データセット名).(テーブル名)` bq コマンドやコンソールからの SQL 投入時等、プロジェクト名が自明の場合は省略することもできます。 またバッククォートは 場合により 省略することができます。しかし 場合により バッククォートで囲まないとエラーとなる場合があります。 バッククォートの要否 ドキュメント「 語彙の構造と構文 」の「テーブル名」の項を確認します。 引用符で囲まれていない識別子は、 FROM 句または TABLE 句で参照される場合にダッシュをサポートします。テーブルパスの最初の識別子（プロジェクト ID またはテーブル名）のみがダッシュを使用できます。ダッシュはデータセットではサポートされていません。 プロジェクト名等にダッシュ記号 (ハイフン記号) が使われている場合でかつバッククォートで囲まれていない場合、 FROM 句や TABLE 句の場合は問題なく使えますが、 当記事冒頭で示したような INSERT 句の後ではエラーになってしまうのです。 なおエラーとならない場合として FROM 句や TABLE 句 の他に UPDATE 等もあります。 エラーにならない SELECT * FROM my-project.mydataset.mytable CREATE OR REPLACE TABLE my-project.mydataset.mytable ( id STRING, name STRING, subject STRING, score INT64 ) UPDATE my-project.mydataset.mytable SET score = 100 WHERE id = " 1111 " エラーになる INSERT my-project.mydataset.mytable (id, name, subject, score) VALUES ( " 1111 " , " John Doe " , " Math " , 90 ), ( " 2222 " , " Jane Doe " , " Math " , 95 ) 対策 対症療法 以下のように SQL を修正すると、構文エラーは発生しません。 バッククォートで囲む INSERT `my-project.mydataset.mytable` (id, name, subject, score) VALUES ( " 1111 " , " John Doe " , " Math " , 90 ), ( " 2222 " , " Jane Doe " , " Math " , 95 ) バッククォートで囲む (プロジェクト名のみでも可) INSERT `my-project`.mydataset.mytable (id, name, subject, score) VALUES ( " 1111 " , " John Doe " , " Math " , 90 ), ( " 2222 " , " Jane Doe " , " Math " , 95 ) INTO をつける INSERT INTO my-project.mydataset.mytable (id, name, subject, score) VALUES ( " 1111 " , " John Doe " , " Math " , 90 ), ( " 2222 " , " Jane Doe " , " Math " , 95 ) 原則 コーディング規則として、テーブル識別子はバッククォートで囲むこととするのが望ましいと言えます。 ただし Bash (Linux) 等で bq コマンドを実行する際はバッククォートが別の意味を持つため、適切にエスケープする必要があります。 Bash ではバッククォートは「コマンドの展開」の意味となってしまいますので、バックスラッシュ記号 ( \ ) でバッククォートをエスケープします。 エラーとなるケース $ bq query --use_legacy_sql=false "SELECT * FROM `my-project.mydataset.mytable`" -bash: my-project.mydataset.mytable: command not found Error in query string: Error processing job 'my-project:bqjob_abcde_0000012345_1': Syntax error: Unexpected end of script at [1:14] 問題ないケース $ bq query --use_legacy_sql=false "SELECT * FROM \`my-project.mydataset.mytable\`" +------+----------+---------+-------+ | id | name | subject | score | +------+----------+---------+-------+ | 1111 | John Doe | Math | 90 | | 2222 | Jane Doe | Math | 95 | +------+----------+---------+-------+ 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の佐々木です。当記事では Google Cloud（旧称 GCP）のサーバーレスなコンテナプラットフォームサービスである Cloud Run を解説します。 Cloud Run とは 4種類の Cloud Run 4つの実行モデル Cloud Run サービス（services） Cloud Run ジョブ（jobs） Cloud Run 関数（functions） Cloud Run ワーカープール（worker pools） Cloud Run サービスの基本 動的スケーリング サービスの冗長性 デプロイ デプロイ元のコンテナイメージ コンテナの要件 トラフィック移行とロールバック コンテナ実行環境（世代） サービスの構成 エンドポイント URL コンテナインスタンスの最大・最小数 コールドスタートとその対処 Startup CPU boost CPU・メモリ リクエストのタイムアウト コンテナインスタンスあたりの同時リクエスト最大数 サービス間連携（トリガー） ネットワーク Cloud Run サービスに対する接続 Cloud Run サービスから VPC ネットワークへの接続 認証 非公開サービスの認証 公開アクセスの許可 独自のユーザー認証 料金 料金体系 リクエストベースの課金 インスタンスベースの課金 Recommender による最適化 他サービスとの比較 Compute プロダクトの考え方 Cloud Run と Compute Engine の比較 Cloud Run と Google Kubernetes Engine の比較 Cloud Run と App Engine の比較 Cloud Run を使ってみる Cloud Run とは Cloud Run とは、Google Cloud（旧称 GCP）のサーバーレスなコンテナプラットフォームサービスです。任意のプログラミング言語でコードを記述して、コンテナイメージ化すれば、デプロイするだけでアプリケーションを実行することができます。Cloud Run は フルマネージドサービス であり、クラスタの作成や、インフラの管理は必要ありません。 コンテナを実行するインスタンスは 負荷に応じて自動的にスケールアウト し、処理がないときは インスタンス数を 0 までスケールイン させることができす。 参考 : Cloud Run とは Cloud Run では、アプリケーションをコンテナイメージからデプロイできるため、実行環境の柔軟性が高く、ユースケースは多岐に渡ります。ウェブサイトやモバイルバックエンド、API バックエンドやバッチデータ処理など、以下の公式ドキュメントにいくつかのユースケースが紹介されています。 参考 : 一般的な使用例 なお Cloud Run は、Kubernetes 上にサーバーレスなコンピューティング基盤を構築できるオープンソースソフトウェアの Knative が基盤技術となっています。 参考 : Knative 4種類の Cloud Run 4つの実行モデル Cloud Run には、以下の4つの実行モデルがあります。 Cloud Run サービス（Cloud Run services） Cloud Run ジョブ（Cloud Run jobs） Cloud Run 関数（Cloud Run functions） Cloud Run ワーカープール（Cloud Run worker pools） Google Cloud プロダクトとして「Cloud Run」があり、その中のリソースとして「サービス（services）」と「ジョブ（jobs）」、「関数（functions）」、「ワーカープール（worker pools）」を作成できるイメージです。 当記事では、主に「Cloud Run サービス」にフォーカスして解説しています。 Cloud Run サービス（services） Cloud Run サービス では、コンテナイメージをデプロイするだけで、コンテナの実行環境（コンテナインスタンス）とリクエストを受信する HTTPS エンドポイントが提供されます。 Cloud Run サービスは、リクエストを受けてレスポンスを返す、ウェブサイトや API バックエンドなどのユースケースに用いられます。 参考 : デプロイ オプションとリソースモデル - Cloud Run サービス Cloud Run サービス Cloud Run ジョブ（jobs） Cloud Run ジョブ では、コンテナインスタンスを使用して、ユーザーが作成したコードを ジョブ として実行することができます。 ジョブは任意のタイミングで実行することができ、コンテナインスタンスを複数組み合わせて実行することにより、60 分以上のジョブ実行や並列処理を実現できます。 Cloud Run ジョブは、コンテナでリソース効率の高いバッチ処理を行いたい場合に選択肢となります。 参考 : デプロイ オプションとリソースモデル - Cloud Run ジョブ 参考 : Cloud Run jobs を解説する Cloud Run ジョブの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run 関数（functions） Cloud Run 関数は、元々は Cloud Functions という独立したプロダクトでしたが、2024年8月には Cloud Run に統合されました。 Cloud Run functions は、HTTP リクエストをトリガーとする HTTP 関数 と、特定のイベントをトリガーとする イベントドリブン関数 の2種類に分けられます。 参考 : Cloud Run functions の概要 Cloud Run 関数は Cloud Run サービスと似た使い方ができますが、構築の容易さと、柔軟性に差異があります。 Cloud Run 関数では、コンテナイメージを用意することなく、ソースコードだけをデプロイすることで、 ランタイム 上でアプリケーションを実行することができます。その代わり、ランタイムにはライフサイクルが存在し、古いバージョンのプログラミング言語を使用している場合はランタイムの非推奨化や廃止に気を配る必要があります。また、ランタイムでサポートされるプログラミング言語の種類にも制限があります。 参考 : ランタイム サポート 参考 : Cloud Functions と Cloud Run: それぞれの使いどころ Cloud Run 関数の詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run ワーカープール（worker pools） Cloud Run ワーカープールはここまで紹介した3種類の実行モデルとは異なり、外部からのリクエストをトリガーとする実行ではなく、Pub/Sub や Kafka といったメッセージキューなどに対して、コンテナインスタンスが能動的にメッセージやタスクの取得を行う pull 型のワークロード をサーバーレスに実行することができます。 2025年7月1日現在は、パブリックプレビュー版のサービスとなっています。 Cloud Run ワーカープール Cloud Run ワーカープールの詳細については、以下の記事で解説しています。 blog.g-gen.co.jp Cloud Run サービスの基本 動的スケーリング Cloud Run サービスは、HTTPS エンドポイントで受信したリクエストを迅速に処理するために、コンテナインスタンスを自動でスケールアウトします。 コンテナインスタンスはデフォルトで最大 1000 までスケールアウトでき、リクエストのないときはインスタンス数が 0 になるまでスケールインします。 参考： Cloud Run サービスでのインスタンスの自動スケーリングについて サービスの冗長性 Cloud Run サービスは特定のリージョンに作成され、冗長性とフェイルオーバーのため、リージョン内の複数のゾーンに自動的に複製されます。 Cloud Run は「リージョナルサービス」です。つまり、利用リージョンは選択できますが、その中のゾーンは選択しません。逆に言うと、利用者はゾーンを意識する必要がなく、適切に負荷分散されますし、ゾーン障害も自動的に対応されます。 参考 : クラウド インフラストラクチャの停止に対する障害復旧の設計 デプロイ デプロイ元のコンテナイメージ Cloud Run にデプロイするコンテナイメージは、Google Cloud のマネージドなコンテナレジストリである Artifact Registry に格納します。 また、Cloud Run サービスとは別のプロジェクトにある Artifact Registry リポジトリに格納されたコンテナイメージを使用することもできます。 参考 : デプロイ オプションとリソースモデル - ソース サーバーレス CI / CD プラットフォームである Cloud Build を使用することで、Git リポジトリへの push をトリガーとして、Cloud Run への継続的なデプロイを実現することも可能です。 参考 : Cloud Build の概要 参考 : Cloud Build を使用した Git からの継続的なデプロイ コンテナの要件 Cloud Run サービスで実行することができるコンテナにはいくつかの要件があります。 参考 : コンテナ ランタイムの契約 要件の詳細については上記の公式ドキュメントに記載されています。以下は、一部を抜粋したものです。 コンテナイメージ内の実行可能ファイルは、Linux 64 ビット用にコンパイルする必要がある リクエストの送信先ポート（デフォルトのポートは 8080）で 0.0.0.0 のリクエストをリッスンする必要がある リクエストを受信してからリクエストのタイムアウト設定で指定された時間内に、レスポンスを返す必要がある トラフィック移行とロールバック サービスをデプロイもしくは構成を変更すると、新しい リビジョン （版）が作成されます。 新しいリビジョンを作成した際に、既存のリビジョンに対する全てのトラフィックを即座に移行するか、段階的に移行するかを選択することができます。 また、複数のリビジョンでトラフィックを分割したり、古いリビジョンにロールバックしたりできます。 参考 : ロールバック、段階的なロールアウト、トラフィックの移行 コンテナ実行環境（世代） Cloud Run のコンテナ実行環境として、 第 1 世代 と 第 2 世代 から選択できます。gcloud コマンド等でサービスをデプロイする際に実行環境を指定しなかった場合、デフォルトでは、設定にあわせて自動的に世代が選択されます。第 2 世代を使用するには、少なくとも 512 MiB のメモリを指定する必要があります。 世代ごとの特徴とユースケースは以下の通りです。 参考 : サービス実行環境について 世代 特徴 ユースケース 第 1 世代 ・高速なコールドスタート ・Cloud Run サービスに対するバーストトラフィックが予測される場合 ・アプリケーションがコールドスタートの影響を受けやすい場合 ・Cloud Run サービスに対する定常的なトラフィックがなく、コンテナインスタンスの数が頻繁にゼロまでスケールインする場合 ・512 MiB 未満のメモリを使用したい場合（第 2 世代は最低 512 MiB） 第 2 世代 ・ネットワークファイルシステムのサポート ・Linux との完全な互換性（すべてのシステムコール、名前空間、cgroup が利用可能） ・CPU とネットワークパフォーマンスの高速化 ・アプリケーションからネットワークファイルシステムを使用する場合 ・Cloud Run サービスに対する定常的なトラフィックがあり、コールドスタートが多少遅くても許容できる場合 ・CPU やネットワークに高いパフォーマンスが求められるワークロードの場合 ・第 1 世代ではサポートされていない OS のシステムコールを使用する場合（ 参考 ） ・Linux の cgroup 機能を使用したい場合 ・Cloud Run Threat Detection を使用したい場合（ 参考 ） サービスの構成 エンドポイント URL デフォルトでは、Cloud Run サービスには *.run.app ドメインの一意のサブドメインがサービスの HTTPS エンドポイント URL として提供されます。 Cloud Run サービスをデプロイすると、 Deterministic URL と Non-deterministic URL の2つが発行されます。前者は、サービス名とリージョンによって一意に定まる URL であり、後者はランダムハッシュが含まれておりデプロイするまで決定しない URL です。 # Deterministic URL の形式 https:// { サービス名 } - { プロジェクト番号 } . { リージョン } .run.app # Non-deterministic URL の形式 https:// { サービス識別子 } .run.app グローバル外部 HTTPS ロードバランサ 、または Firebase Hosting を利用することで、カスタムドメインを設定することもできます。 参考 : HTTPS リクエストで呼び出す - 決定論的 URL 参考 : カスタム ドメインのマッピング コンテナインスタンスの最大・最小数 動的スケーリングの最大・最小インスタンス数は、あらかじめ設定することができます。 最大インスタンス数はデフォルトが 100 、上限は 1000 です。この上限は、Google Cloud コンソールの「割り当てとシステム上限」ページから、引き上げ申請が可能です。 最小インスタンス数はデフォルトで 0 となっており、リクエストがないときはインスタンス数が 0 になるまでスケールインします。 参考 : Cloud Run の割り当てと上限 コールドスタートとその対処 Cloud Run サービスでは、インスタンス数が 0 の状態のときにリクエストが発生した場合、最初のインスタンスの起動が完了するまで、処理の遅延が発生します。これを コールドスタート といいます。 最小インスタンス数を 1 以上 にすることにより、コンテナインスタンスのウォーム状態（いつでも呼び出し可能な状態）を維持し、リクエストをすぐに処理することが可能になります。 最小インスタンス数が 1 以上の場合、指定した数のコンテナインスタンスがアイドル状態で常に起動しており、リクエストを処理していないときでも、アイドル状態のインスタンスの料金が発生します。 アイドル状態のインスタンスの料金は、実際にリクエスト処理をしているときの料金よりも安く設定されています（課金モードがデフォルトの「リクエストベースの課金」の場合）。 参考 : サービスの課金設定 参考 : Cloud Run pricing 以下の記事では、コールドスタートやその対処についてさらに深堀りしています。 blog.g-gen.co.jp blog.g-gen.co.jp Startup CPU boost コールドスタート対策、すなわちゼロスケールからのコンテナ起動や、リクエスト数が上昇してスケールアップする際のコンテナ起動を高速化するために、 Startup CPU boost 機能が存在します。 参考 : 起動時の CPU ブーストを設定する Startup CPU boost については、以下の記事で詳細に解説しています。 blog.g-gen.co.jp CPU・メモリ Cloud Run サービスのデプロイ時に、コンテナインスタンス 1 つあたりに割り当てる CPU の数と、メモリ容量の上限を設定できます。デプロイ後も変更が可能です。 CPU の数に応じて、割り当てることができるメモリ容量の幅が決まります。 CPU（個） メモリ容量 1 未満（最小 0.08） 128 MiB ~ 512 MiB（CPU 数が 0.08 の場合） 1 128 MiB ~ 4 GiB 2 128 MiB ~ 8 GiB 4 2 GiB ~ 16 GiB 6 4 GiB ~ 24 GiB 8 4 GiB ~ 32 GiB 参考 : サービスの CPU 上限を構成する 参考 : サービスのメモリ上限を構成する リクエストのタイムアウト Cloud Run サービスでは、エンドポイントで受信したリクエストの処理に使用できる時間を設定できます。 デフォルトは 300秒 で、 1~3600秒 の範囲で設定することができます。 参考 : サービスのリクエスト タイムアウトを設定する コンテナインスタンスあたりの同時リクエスト最大数 1つのコンテナインスタンスが処理できる同時リクエストの数を設定できます。 デフォルトは 80 で、 1~1000 の範囲で設定することができます。 参考 : サービスの最大同時リクエスト数 サービス間連携（トリガー） Cloud Run サービスでは、クライアントからの HTTPS リクエスト経由の呼び出しのほか、gRPC や WebSocket を使用した通信や、他の Google Cloud サービスからの呼び出しをサポートしています。 Google Cloud のサービスからの呼び出しは、Pub/Sub、Cloud Scheduler、Cloud Tasks、Eventarc、Workflows などが利用できます。 参考 : HTTPS リクエストで呼び出す 参考 : Cloud Run で Pub/Sub を使用するチュートリアル ネットワーク Cloud Run サービスに対する接続 デフォルトでは、ネットワークレベルでは任意のアクセス元から Cloud Run サービスにアクセスすることが可能です。 上り（内向き）設定 を変えることで、ネットワークアクセス元について 3 段階の制限をかけることが可能です。 参考 : Cloud Run のネットワーク上り（内向き）を制限する 設定名 許可するアクセス元 内部 (Internal) ・ 内部アプリケーションロードバランサ ・ VPC Service Controls 境界内のリソース ・ 同一プロジェクトの VPC ・ Eventarc, Pub/Sub, Workflows 内部 (Internal) と Cloud Load Balancing ・ 内部 (Internal) で許可されているもの ・ 外部アプリケーションロードバランサ すべて (All) すべて なお Google Cloud で「上り」「内向き」「Ingress」という言葉は、サービス（Google Cloud）に入る方向のトラフィックを指します。サービスの外部や Google Cloud の外部を「下」「外」とみなし、外方向へのトラフィックに対して「下り」「外向き」「Egress」という言葉を使います。 Cloud Run サービスから VPC ネットワークへの接続 Compute Engine VM や Google Kubernetes Engine（GKE）クラスタ等とは異なり、Cloud Run サービスは VPC ネットワークの 外に 作成されるため、デフォルトでは VPC 内のリソースに Internal IP（内部 IP）アドレスでアクセスすることができません。 サーバーレス VPC アクセス 、もしくは Direct VPC Egress を使用することにより、Cloud Run サービスから Internal IP アドレスを使用して、VPC リソース接続することができます。 参考 : VPC とコネクタ 参考 : VPC ネットワークによるダイレクト VPC 下り（外向き） サーバーレス VPC アクセスと Direct VPC Egress については、以下の記事で解説しています。 blog.g-gen.co.jp 認証 非公開サービスの認証 Cloud Run サービスは、デフォルトでは 非公開 サービスとしてデプロイされます。非公開のサービスを呼び出す際には、リクエスト時に IAM の認証情報が必要です。つまり IAM 認証情報を持っていない人やプログラムからのリクエストは受け付けません。 他の Google Cloud サービスから Cloud Run サービスを呼び出す場合は、 Cloud Run 起動元 （ roles/run.invoker ）ロール、もしくは同等の権限をもつカスタムロールが付与されたサービスアカウントによる認証が必要です。 参考 : 認証の概要 なお、 Workload Identity 連携 を用いることで、OpenID Connect（OIDC）もしくは SAML 2.0 をサポートする外部 ID プロバイダを使用した認証も可能となっています。 参考 : Workload Identity 連携 公開アクセスの許可 Cloud Run サービスを、一般公開する API やウェブサイトとして公開する場合、 公開アクセスを許可 することができます。 コンソールや CLI から、 allUser メンバータイプ に対して Cloud Run 起動元 （ roles/run.invoker ）ロールを割り当てるだけで、未認証のサービス呼び出しを許可することができます。 参考 : 公開（未認証）アクセスを許可する また上記の方法以外でも、Cloud Run サービス呼び出し時の IAM チェックを無効化することで、Cloud Run サービスを一般公開することもできます。組織のポリシーで、IAM ロールを付与できるドメインを限定している場合には、こちらの方法を使います。 参考 : サービスの Cloud Run 起動元を無効にする 以下の記事も参考にしてください。 blog.g-gen.co.jp 独自のユーザー認証 サービスに対して、許可されたエンドユーザーのみにアクセスを制限する場合において、エンドユーザーが Google アカウントによる認証を利用できれば通常の IAM の仕組みで呼び出し元を制御できますが、独自の認証機構を実装したい場合、 Identity Platform を使用することもできます。 Identity Platform は独立した Google Cloud プロダクトであり、Cloud Run とは別プロダクトです。Identity Platform では、メールアドレスとパスワード、電話番号、Google、Facebook、GitHubなどのソーシャルプロバイダや、カスタム認証メカニズムを用いたユーザー認証が可能となっています。 参考 : Identity Platform 料金 料金体系 Cloud Run サービスの料金体系は、デプロイしたサービスごとに、 リクエストベースの課金 と、 インスタンスベースの課金 から選択できます。 デフォルトでは、サービスは、 リクエストベースの課金 としてデプロイされます。この場合、Cloud Run サービスはリクエストを処理しているときにのみ CPU が割り当てられ、割り当て時間に応じて料金が発生します。また、リクエスト数に応じた課金も発生します。 Cloud Run サービスを インスタンスベースの課金 モードでデプロイすることもできます。この場合、リクエストがない場合でもコンテナインスタンスに CPU を常に割り当てて、バックグラウンドタスクや非同期処理タスクを実行することができます。リクエスト数に応じた課金はありません。 インスタンスベースの課金では、リクエストの処理中だけではなく、コンテナインスタンスの起動から終了まで CPU が割り当てられ、そのライフサイクル全体で料金が発生します。ただし、料金単価は通常よりも安価です。そのため、常時何かしらの処理が発生しているような場合、インスタンスベースの課金のほうが結果的に安価になります。 参考 : サービスの課金設定 参考 : CPU の割り当て（サービス） 最新の料金単価は、以下のページから確認できます。 参考 : Cloud Run の料金 リクエストベースの課金 コンテナインスタンスがリクエストを処理している間に割り当てられた CPU とメモリの利用時間について、 100 ミリ秒 の粒度で課金されます。 最小インスタンス数を 1 以上にしている場合、最小インスタンス数に設定している数のインスタンスは、処理をしていない間、低い単価の アイドル状態の料金 が発生します。 またリクエストベースの課金では、サービスに対するリクエストの数に対して、 100 万リクエスト 単位で課金されます。 CPU メモリ リクエスト 無料枠 毎月最初の 180,000 vCPU 秒 毎月最初の 360,000 GiB 秒 毎月 200 万リクエスト 通常料金 $0.00002400 / vCPU 秒 アイドル状態の場合 $0.00000250 / vCPU 秒 (最小インスタンス数が1以上のとき) $0.00000250 / GiB 秒 アイドル状態の場合 $0.00000250 / GiB 秒 (最小インスタンス数が1以上のとき) $0.40 / 100 万リクエスト 確約利用割引 $0.00001992 / vCPU 秒 $0.000002075 / GiB 秒 CUD $0.332 / 100 万リクエスト ※2025年4月現在、東京リージョンのもの vCPU 秒 : vCPU が 1 つのインスタンスを 1 秒間 実行すること GiB 秒 : メモリ容量が 1 ギビバイトのインスタンスを 1 秒間実行すること アイドル状態 : 最小インスタンス数でウォーム状態を維持している場合 インスタンスベースの課金 CPU を常に割り当てる場合、リクエスト単位の課金はなく、CPU とメモリの利用時間についての課金のみとなっています。コンテナインスタンスの起動から終了までの間、リソースの利用料金が発生します。常時リソースが割り当てられている分、単価は安くなっています。 CPU メモリ 無料枠 毎月最初の 240,000 vCPU 秒 毎月最初の 450,000 GiB 秒 通常料金 $0.00001800 / vCPU 秒 $0.00000200 / GiB 秒 確約利用割引 (1年間の Flex CUD) $0.00001296 $0.00000144 ※2025年4月現在、東京リージョンのもの Recommender による最適化 Cloud Run サービスの課金設定の選択にあたり、Recommender を参考にすることができます。Recommender は、Cloud Run サービスの過去 1 ヶ月間のトラフィック受信状況から、料金が安くなる場合にインスタンスベースの課金に変更するよう推奨してくれます。 参考 : Recommender による最適化 他サービスとの比較 Compute プロダクトの考え方 Google Cloud が提供する Compute プロダクト （プログラムが動作するためのプラットフォームを提供するプロダクト。Compute Engine、GKE、Cloud Run 等）は、 構築の柔軟性 と 運用負荷 に差があります。 例として、Compute Engine は仮想サーバーのサービスのため、OS やミドルウェアなどを柔軟にカスタマイズできます。これは、柔軟性が高い代わりに、運用負荷が高いことを意味します。 Google Cloud の Compute プロダクト比較 どこまでの柔軟性が必要か、運用負荷をどれだけ抑えたいか、などの観点で適切なサービスを選択することが重要です。 Cloud Run は、柔軟性と運用負荷において、Compute プロダクト内でも 中間の位置 にあります。 コンピュート系サービスの選択方法については以下の記事でも論じています。当記事では Cloud Run を軸として説明しますが、以下の記事もぜひご参照ください。 blog.g-gen.co.jp Cloud Run と Compute Engine の比較 Compute Engine は、Google Cloud の VPC ネットワーク内に仮想マシンを構築することができる、 IaaS プロダクトです。 Compute プロダクトの中で最高の柔軟性があり、他のプロダクトにデプロイできるものは概ね、Compute Engine の VM にデプロイすることができます。その代わり に、Compute Engine では、仮想マシンの OS から上のレイヤにあるものは、すべてユーザーが構築したり、管理する必要があります。また Cloud Run のようなサーバーレスアーキテクチャではないため、仮想マシンの実行中は何も処理をしていなくても課金され続けます。 Compute Engine については以下の記事も参考にしてください。 blog.g-gen.co.jp Cloud Run と Google Kubernetes Engine の比較 Google Cloud の代表的なコンテナサービスである Google Kubernetes Engine （GKE）では、コンテナをデプロイする Kubernetes クラスタをユーザーが管理します。フルマネージドの Cloud Run と比較して、OS、CPU、GPU、ディスク、メモリ、ネットワークなどの柔軟な構成が可能です。 また GKE には、Kubernetes クラスタの管理の大部分を Google Cloud に任せることのできる Autopilot モードがあります。 Cloud Run と GKE では、主に以下のような点が異なります。 リクエストがないとき、GKE は 0 までスケールインできない。Cloud Run ではゼロスケールが可能 GKE はマイクロサービスアーキテクチャ等の複雑な構成が可能。Cloud Run では、設計が複雑になる GKE は VPC ネットワーク内で動作するため、VPC 内 のリソースとの接続が容易。Cloud Run では VPC 内のリソースと通信するためには、サーバーレス VPC アクセスや Direct VPC Egress などの設定が必要 Cloud Run と GKE は、どちらもコンテナ実行環境を提供するサービスですが、GKE は「高度なコンテナオーケストレーションを実現できるサービス」、 Cloud Run は「コンテナをサーバーレスで容易に実行することができるサービス」という位置づけです。 GKE については以下の記事も参考にしてください。 blog.g-gen.co.jp Cloud Run と App Engine の比較 Cloud Run と コンセプトが似ているサービスとして、 App Engine （GAE）があります。 GAE は、コードと構成ファイルをデプロイするだけで、アプリケーションを容易に実行できるサービスとなっています。 スタンダード環境の GAE では開発言語の制限がありますが、Cloud Run 同様、リクエストがないときにインスタンスが 0 までスケールインします。 GAE と Cloud Run の主な違いは以下の点となります。 GAE ではデプロイに必要なのはコードと構成ファイルのみであり、Cloud Run よりも実行環境の柔軟性が劣る代わりに、容易にアプリケーションを実行することができる また、フレキシブル環境の GAE のみのデメリットとして、VM ベースの実行環境のためスケーリングが遅い、0 までスケールインできないなどがあります。 GAE との比較では、デプロイの容易さで GAE、環境の柔軟性で Cloud Run が優れています。 GAE については以下の記事も参考にしてください。 blog.g-gen.co.jp Cloud Run を使ってみる 以下の記事では、Cloud Run のサービスをデプロイするまでの基本的な手順や設定項目、Cloud Run を中心とした一般的なサービス構成について解説しています。 blog.g-gen.co.jp 佐々木 駿太 (記事一覧) G-gen最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805

G-genの片岩です。 当記事ではオンプレミスの仮想マシンやディスクを Google Cloud のイメージとしてインポート する方法について解説します。 自動インポートとは 料金 前提条件 移行元ファイル形式 移行対象 OS 制限事項 作業プロセス 1. 権限付与 2. 事前チェックツール 3. Cloud Storage へのアップロード 4. イメージ作成 (インポート) OVF ファイルなし OVF ファイルあり 5. イメージから VM インスタンスを作成 ユースケース 自動インポートとは 自動インポートとは、仮想マシンのイメージファイル (VMDK / VHD / OVF) を Google Cloud にインポートすることにより Google Cloud にイメージや VM を作成する機能 です。 オンプレミスのサーバーやディスクをそのまま Google Cloud へ移行したい時に利用します。 参考 : 仮想ディスクのインポート 参考 : 仮想アプライアンスのインポート 料金 自動インポート機能自体の利用は無料ですが、付随して利用される以下について料金が発生します。 名称 説明 Cloud Storage へのデータ保存 インポートするイメージファイルを Cloud Storage にアップロードするため、 Cloud Storage の保存料金が発生します イメージの保存 インポートしたイメージの保存には容量に応じて料金が発生します 前提条件 移行元ファイル形式 移行元のファイル形式 は以下のとおりです。 タイプ ファイル形式 仮想ディスク VMDK ファイルまたは VHD ファイル 仮想アプライアンス OVF ファイル (仮想ディスクは VMDK または VHD) VMDK / VHD ファイルを仮想ディスクとしてインポートするか、あるいは OVF ファイルの持つマシン全体の情報をマシン (=仮想アプライアンス) としてインポートすることができます。 移行対象 OS 代表的な サポート対象の OS は以下です。 以下は主要な OS のみをピックアップしたものですので、完全な一覧は ドキュメント をご参照ください。 Windows Server 2008 R2 以上 Red Hat Enterprise Linux (RHEL) 6, 7, 8 CentOS 7 制限事項 代表的な 制限事項 をピックアップしました。詳細は 公式ドキュメント をご確認ください。 論理ボリュームマネージャ (LVM) は非サポート Linux の仮想ディスクは、ブートローダーとして grub を使用する必要がある ファイルのインポートに 24 時間以上掛かる場合はインポートに失敗する 作業プロセス 1. 権限付与 公式ドキュメント の記載に沿って Google Workspace / Cloud Identity 等のユーザーアカウントや Google Cloud サービスアカウントに所定の IAM 権限を付与 します。 2. 事前チェックツール 移行元の仮想サーバーで 事前チェックツール を実行します。 このツールをサーバー上で動かすことで、仮想サーバーをイメージ化して Google Cloud に インポートできる状態にあるか を事前に確認することができます。 3. Cloud Storage へのアップロード 仮想マシンを停止して VMDK / VHD / OVF ファイルを準備します。 これらのファイルを Cloud Storageにアップロード します。 4. イメージ作成 (インポート) VMDK / VHD / OVF ファイルをもとに イメージ または VM インスタンス を作成します。 OVF ファイルの有無 により、以下のように実施方法と出力内容が異なります。 OVF ファイル 実施方法 インポート後の状態 OVF ファイルなし gcloud / GUI から実施可能 イメージ OVF ファイルあり gcloud (Google Cloud CLI) のみ イメージ または VM それぞれの場合をご説明します。 OVF ファイルなし VMDK / VHD ファイルだけインポートする場合は、 GUI または gcloud コマンド から実施できます。結果として Compute Engine の イメージ が作成されます。 参考まで、手元の環境で試したところ 4.25 GB の VMDK ファイルをインポートしたところ約 45 分間かりました。データサイズが大きいほど時間がかかります。 OVF ファイルあり VMDK / VHD ファイルだけでなく OVF ファイルもインポートする場合は、 GUI から実施することはできません。　 gcloud コマンド から実施します。 以下は OVF ファイルをインポートして Compute Engine イメージを作成するコマンドの一例です ( 参考 )。 gcloud compute machine-images import my-machine-image \ --source-uri=gs://my-bucket/Ubuntu.ovf 5. イメージから VM インスタンスを作成 イメージを作成した場合は、以下のように作成したイメージをブートディスクに設定して VM インスタンスを作成 します。 ユースケース 自動インポート手法は シンプルでわかりやすい ことが特徴です。以下のような場合に当手法が適しています。 移行対象のサーバーが 1 台から数台のみ等、移行規模が小さい サーバーのダウンタイムが十分確保できる 当手法は 1 台ずつ手作業でインポートする必要があるため大規模な環境の移行には向いていません。また、リアルタイム同期も行わないため、ダウンタイムが必要となります。 移行台数が多い場合やダウンタイムを小さくしたい場合は、以下のブログで解説している Migrate for Compute Engine 等、別の方法を利用することをお勧めします。 blog.g-gen.co.jp 片岩 裕貴 (記事一覧) データアナリティクス準備室 2022年5月にG-gen にジョイン。 AI/ML系に関心が強く、ディープラーニングE資格とProfessional Machine Learningを取得。最近話題のGenerative AIにも興味がある。毎日の日課は三人乗りの電動自転車で子供を幼稚園に送り迎えすること。和歌山県在住。

Google Cloud (旧称 GCP) には、 Google Cloud への移行を支援してくれる Migrate for Compute Engine という移行ツールがあります。 今回の記事は Migrate for Compute Engine について解説します。 Migrate for Compute Engine とは Migrate for Compute Engine v4 と v5 の違い 環境構成 Migrate Connector 通信要件 料金 移行プロセス 1. オンボード 2. レプリケーション 3. 移行設定 4. テストクローン 5. カットオーバー 6. 移行完了 ユースケース 注意事項 Migrate for Compute Engine とは Migrate for Compute Engine は Google Cloud が提供するサーバー移行ツールです。 対応している移行元として VMware vSphere 、 Amazon EC2 (AWS) 、 Virtual machine (Microsoft Azure) 環境があります。 このツールを使うことで、ダウンタイムを最小限にしながらサーバーを Google Cloud へ移行することが出来ます。 移行元にセットアップした Migrate Connector 等と呼ばれるツールがデータを継続的に Google Cloud へ転送してくれることで、移行が実現されます。 Migrate for Compute Engine v4 と v5 の違い Migrate for Compute Engine には v4 と v5 があり、それぞれできることが異なります (2022 年 7 月現在) 。 例えば v4 と v5 ではサポートされる移行元環境が異なります。 v4 では VMware 環境の他、 AWS 、 Azure のサーバーを移行可能です。 一方の v5 では、 VMware 環境のサーバーしか移行できません。 原則は、最新版である v5 を利用することが推奨 ですが、 AWS / Azure 環境のサーバーを移行したい場合は v4 を選択します。 当記事ではこれ以降、 v5 をベースに解説していきます。 環境構成 Migrate Connector Migrate for Compute Engine (v5) では、移行元の vSphere 環境に Migrate Connector と呼ばれるツールをデプロイする必要があります。 同ツールをデプロイするためには、公式サイトの OVA ファイルを使います。 参考 : Migrate Connector のインストール 通信要件 Migrate Connector は Google Cloud の API との間に HTTPS (443/tcp) を使用して通信を行い、データを転送します。 そのため移行元 vSphere 環境の Migrate Connector からインターネット経由で Google Cloud の API に到達する経路を確保する必要があります。 ただし Cloud VPN (IPSec) や Cloud Interconnect (専用線) を経由して通信させることも可能です。 画像は 公式ドキュメント から引用 料金 Migrate for Compute Engine は無料で利用できます。 ただし、データ移行に必要なストレージなど、 Migrate for Compute Engine 以外の Google Cloud 利用料金が発生することにご注意ください。以下のような料金が発生します。 No 項目名 説明 1 Compute Engine 移行先 VM の関連リソースの料金。永続ディスク等含む 2 Cloud Storage 移行元環境から実施される 増分レプリケーションを蓄積するための費用 3 スナップショット 定期的に VM の状態を保存するために使用されます。 移行プロセス Migrate for Compute Engine を使ったサーバー移行は、以下の 6 つのプロセスに分けられます。 1. オンボード 移行する対象 VM を選択するプロセスです。 Google Cloud コンソールに vSphere データセンター内のすべての VM が表示されるので 移行対象となる VM のみ を選択します。 2. レプリケーション 移行元 VM から Google Cloud にデータをレプリケート (複製) するプロセスです。 データ レプリケーションは、最終的なカットオーバーまたは移行中止まで、 バックグラウンドで継続的 に行われます。 レプリケーションされたデータは安価なストレージである Cloud Storage に保存されます。 この Cloud Storage バケットはコンソールからは見えませんが、バックエンドでデータがコピーされ続けています。 3. 移行設定 Compute Engine の設定を決定するプロセスです。 VM を配置するプロジェクト、ネットワーク、インスタンスタイプ、メモリなど Compute Engine インスタンスの 詳細な設定値を決定 します。 4. テストクローン 正常に移行できるか、テストするプロセスです。 Cloud Storage に溜まっているレプリケーションデータから Compute Engine インスタンスをテスト的に生成 (クローン) します。このインスタンスで、正常にインスタンスが動作するかのテストを実施することができます。 このテストは必須ではありませんが、 強く推奨 されています。いきなりのカットオーバーだと、正常に VM が起動するか、また起動してもアプリケーションが正常に稼働するか分からないためです。 5. カットオーバー 最終的な移行と本番 VM のローンチ (起動) をするプロセスです。 以下の順序で実施されます。 移行元 VM の停止 (静止点が生まれる) 最終レプリケーション レプリケーション停止 移行先 Compute Engine インスタンス作成 移行元 VM のシャットダウン 6. 移行完了 移行完了後、ファイナライズ (クリーンアップ) を実施するプロセスです。 ファイナライズの中では、移行に利用した Cloud Storage のデータを削除するなどの最終処理が行われます。 ファイナライズ実施前で有ればデータが残っているため、レプリケーションをやりなおすこともできますが、 Cloud Storage に残っているデータの課金が発生し続けることにご留意ください。 ユースケース 移行元が VMWare 環境であり、一定以上の台数のサーバー移行が必要な場合に Migrate for Compute Engine が活躍します。 また、継続的にデータのレプリケーションを行うため、ダウンタイムが最小限に抑えられるのも特徴です。 逆にサーバー台数が 1 台のみであったり、 VMWare 環境以外の移行元である場合にはサードパーティツールや Google Cloud の 他の移行方式 を検討することになります。 注意事項 Migrate for Compute Engine (v5) を利用できるリージョンは 公式ドキュメント 参照 asia-northeast1 (東京) および asia-northeast2 (大阪) は対応 VMware vSphere の バージョン 5.5 以降 をサポート サポート対象の移行元 OS は 公式ドキュメント 参照 例 : CentOS 6, 7, 8 例 : RHEL 6, 7, 8 例 : Windows Server 2008 R2 SP1, 2012, 2012 R2, 2016, 2019, 2022 G-gen 編集部 (記事一覧) 株式会社G-genは、サーバーワークスグループとして「クラウドで、世界を、もっと、はたらきやすく」をビジョンに掲げ、クラウドの導入から最適化までを支援している Google Cloud 専業のクラウドインテグレーターです。

G-gen の杉村です。 Google Cloud (旧称 GCP) には 組織のポリシー 機能があり、企業や官公庁など、組織における Google Cloud 利用に統制を効かせることができます。当記事では組織のポリシーを徹底解説します。 組織のポリシーとは 仕組み 制約 継承 有効化時の影響 3種類の制約 事前定義の制約 カスタム制約 マネージド制約 デフォルトで適用される制約 デフォルトの制約 gcloud でリストできないデフォルトの制約 組織のポリシーの運用 IAM 権限 ドライラン タグによる制御 有効にすべき組織ポリシー 関連記事 組織のポリシーとは 組織のポリシー （organization policy）とは、組織で管理されたプロジェクトに対し一定のルールを課し、統制を効かせるための機能です。 参考 : 組織ポリシー サービスの概要 Google Cloud（旧称 GCP）には 組織 （organization）の機能があり、複数のプロジェクトを統合管理することができます。会社や官公庁などで組織的に Google Cloud を利用するに当たり、組織の利用は強く推奨されます。組織についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 組織には、 フォルダ （folders）を使って階層構造を作り、個別のテナントにあたる Google Cloud プロジェクト （projects）を格納することができます。このように組織で管理されたプロジェクトに対し一定のルールを設定し、統制を効かせるための機能が、組織のポリシーです。 例として、組織のポリシーでは以下のようなことが実現できます。 特定のリージョン（ロケーション）以外は使えないように制限する 特定のサービス（Compute Engine 等）だけを使えるように制限する 組織外部との IAM ロールの紐づけを禁止する 仕組み 制約 組織ポリシーの個々のルールは 制約 （constraints）と呼ばれます。 例として Google Cloud Platform - リソース ロケーションの制限 (Resource Location Restriction) という制約は Google Cloud リソースを作成できるロケーション (リージョンやマルチリージョン) を制限できます。 制約は リスト か ブール の2タイプに分けられます。リスト型制約は「許可する値」または「拒否する値」をリストとして持つことができます。先ほど例に挙げた リソース ロケーションの制限（Resource Location Restriction） はリスト型であり、許可対象あるいは拒否対象のロケーションのリストを持たせることができます。 ブール型制約は True か False で指定する制約です。例として サービス アカウント キーの作成を無効化（Disable service account key creation） があります。 制約には 表示名 と 名前 （または ID）があります。先ほど例に上げた リソース ロケーションの制限（Resource Location Restriction） は表示名であり、正式名称（ID）は constraints/gcp.resourceLocations です。 参考 : 制約 参考 : 制約の使用 また制約には、事前定義の制約、カスタム制約、マネージド制約の3種類があります。それぞれの違いは後述します。 継承 組織のポリシーには、 継承 という特性があります。 組織のポリシーの制約は「組織（ルート）」「フォルダ」「プロジェクト」のレベルでそれぞれ設定することができます。階層の上位に設定した制約は、下位のリソースに継承させることができます。 制約を設定する際に 親のポリシーを継承する（inheritFromParent） を有効化すると、上位リソースに設定された制約を引き継ぎます。 リスト型制約では、制約を上位から継承したうえで 親と結合する を選択することもできます。これを選択した場合、リストに値を追加することができます。 参考 : 階層評価について 画像は公式ドキュメントより引用 有効化時の影響 組織のポリシーの制約を有効化すると、その制約の影響が既存の Google Cloud リソースにどのように及ぶか（遡及的に影響を及ぼすか）は、 制約によって異なり ます。 例えば、「サービス アカウント キーの作成を無効化（ iam.disableServiceAccountKeyCreation ）」という制約を有効化すると、これから新規でサービスアカウントキーを作成する際にだけ影響を及ぼします。すでに作成済みのサービスアカウントキーには影響がありません。つまり、遡及的に影響は発生しません。 参考 : サービス アカウントの使用の制限 一方で、Cloud Storage の「公開アクセスの防止を適用する（ storage.publicAccessPrevention ）」という制約は、有効化すると、既存のバケットの公開状態がブロックされ、インターネットからアクセスできなくなります。つまり、この制約は遡及的に影響が発生します。 参考 : 公開アクセスを防止する - 考慮事項 この仕様は制約によって異なるため、制約の有効化前に各種ドキュメントをよく確認したり、検証を行うことで、影響を理解する必要があります。 参考 : 組織ポリシーの制約 3種類の制約 事前定義の制約 事前定義の制約 は、Google によって定義された制約です。多くの事前定義の制約が用意されており、組織のポリシー機能では基本的にこの事前定義の制約を用いて、組織に統制を効かせることになります。 事前定義の制約の一覧は、以下ドキュメントの「Constraints supported by multiple Google Cloud services」「Constraints for specific services」から閲覧可能ですので、ご参照ください。 参考 : Organization policy constraints カスタム制約 カスタム制約 （custom constraints）は、ユーザーが自ら作成できる制約です。 YAML ファイルで制約を定義し、条件の詳細は Common Expression Language（CEL）という言語で定義します。 参考 : カスタム制約 参考 : カスタム制約の作成と管理 マネージド制約 マネージド制約 （managed constraints）は、カスタム制約の仕組み上に Google によって定義された制約です。 マネージド制約は通常の制約と似た使い方ができますが、ドライランが使えたり、Policy Simulator というポリシーの影響をシミュレーションする機能を使うことができます。 参考 : マネージド制約 参考 : 組織のポリシーでマネージド制約を使用する 参考 : Policy Simulator で組織のポリシーの変更をテストする 例として、 iam.managed.disableServiceAccountCreation が挙げられます。このマネージド制約は、事前定義の制約である iam.disableServiceAccountCreation と同様の機能を持ちますが、ドライランにより本適用前に影響範囲を確認したり、Policy Simulator を使って影響範囲の事前調査が可能です。 マネージド制約の一覧は、以下ドキュメントの「Managed Constraints」から閲覧可能ですので、ご参照ください。 参考 : Organization policy constraints デフォルトで適用される制約 デフォルトの制約 2024年初頭以降に新しく作成された Google Cloud 組織では、いくつかの制約がはじめから有効化されています。以下に、その制約の一覧を記載します。 なお、それ以前から Google Cloud 組織を保有している場合は、初期状態ではどの制約も有効化されていません。2024年2月から2024年4月の間に作成された組織の一部には、これらのデフォルトの制約が適用されている場合と、されていない場合があります。2024年5月3日以降に作成されたすべての組織には、これらのデフォルトの制約が適用済みです。 参考 : デフォルトで安全な組織リソースを管理する なお、これらの制約が有効化されている場合、 gcloud resource-manager org-policies list --organization=${ORG_ID} コマンドで一覧化できます。 表示名 ID 説明 Disable service account key creation iam.managed. disableServiceAccountKeyCreation サービスアカウントキーの作成を禁止 Disable service account key upload iam.managed. disableServiceAccountKeyUpload サービスアカウントキーの公開鍵のアップロードを禁止 Disable automatic role grants to default service accounts iam. automaticIamGrantsForDefaultServiceAccounts Compute Engine 等のデフォルトサービスアカウントに編集者ロールが付与されることを防ぐ Restrict identities by domain iam. allowedPolicyMemberDomains 許可した組織以外に所属するアカウントへの権限付与を禁止する Restrict contacts by domain essentialcontacts.managed. allowedContactDomains 許可した組織以外に所属するアカウントに対してGoogle Cloudからの重要な通知が届く設定をできないようにする Restrict protocol forwarding based on type of IP address compute.managed. restrictProtocolForwardingCreationForTypes Protocol forwarding を内部 IP アドレスだけに制御 Uniform bucket-level access storage. uniformBucketLevelAccess Cloud Storage バケットで均一なバケットレベルのアクセスを必須にする gcloud でリストできないデフォルトの制約 また上記以外にも、Allow extending lifetime of OAuth 2.0 access tokens to up to 12 hours （iam.allowServiceAccountCredentialLifetimeExtension）、Allowed Sources for Importing Resources（resourcemanager.allowedImportSources）など、いくつかの制約が最初から有効になっている場合があります。 これらの制約は gcloud resource-manager org-policies list --organization=${ORG_ID} のようなコマンドラインでは出力されません。Google Cloud コンソールの組織のポリシー一覧で、適用状態を「アクティブ」でフィルタすることで、有効になっている制約を確認することができます。 スクリーンショットは2025年2月に開設された組織のもの 組織のポリシーの運用 IAM 権限 組織のポリシーを管理するには、管理者の Google アカウントが 組織レベル で組織ポリシー管理者（ roles/orgpolicy.policyAdmin ）ロールを持っている必要があります。 なおポリシーを作成・変更できる権限である orgpolicy.policies.create や orgpolicy.policies.update を持つ事前定義ロールは、 組織ポリシー管理者 ロールなど限られたロールだけです。オーナー（ roles/owner ）や組織の管理者（ roles/resourcemanager.organizationAdmin ）でさえも、ポリシーをリスト表示することはできますが、作成や変更はできません。 また組織ポリシー管理者ロールを付与できる最下位のリソースは組織レベルです。フォルダやプロジェクトレベルに付与することでフォルダ・プロジェクトの管理者に管理を委任することはできません。これは、管理を委任できてしまうと、下位リソースでポリシーを上書き・置換できてしまうため、統制が効かなくなってしまうためです。 参考 : IAM を使用した組織リソースのアクセス制御 参考 : IAM permissions reference ドライラン 一部の制約では ドライラン を用いて、実際に制約を適用する前に影響を確かめることができます。ドライランモードで制約を適用すると、制約に違反したアクションは Cloud Logging へ記録されますが、実際に拒否されません。 ドライランが利用可能な制約は、一部の事前定義の制約と、マネージド制約、カスタム制約のみです。どの制約でドライランが使用可能かは、以下のドキュメントをご参照ください。 参考 : ドライラン モードで組織のポリシーを作成する タグによる制御 組織のポリシーでは、 タグ を使って、特定のプロジェクトのみを制約の対象外とするなどの制御が可能です。 参考 : タグを使用した組織のポリシーの設定 詳細は、以下の記事もご参照ください。 blog.g-gen.co.jp 有効にすべき組織ポリシー Google Cloud の利用を始めたとき、どの制約を有効化すべきでしょうか。 本来は、組織のセキュリティ要件を検討し、適切な設計に基づいて有効化する制約と設定値を設計することが望ましいです。しかし、その内容に迷った場合は、いくつかの指針があります。 まず検討するのは、前掲の 組織のデフォルトの制約 です。2024年初頭以降に新しく作成された Google Cloud 組織では、明示的に設定しなくても、最初から前掲のデフォルトの制約が有効化されています。必要に応じて、それらの制約の設定値を修正してください。それ以前に作成された組織であれば、明示的に有効化することを検討しましょう。 参考 : デフォルトで安全な組織リソースの管理 また、Security Command Center から提供される Predefined posture for secure by default, essentials の設定値も参考になります。Predefined posture は Security Command Center の Enterprise ティアと Premium ティアで提供される機能で、Google Cloud 組織をセキュアに利用するための一通りの設定を提供する機能です。同機能を利用しなくても、ドキュメントで掲示されている組織ポリシーの設定値を参考にすることができます。 この Predefined posture で定義されている組織ポリシーは、組織のデフォルトの制約と重複しているものもありますが、 compute.requireOsLogin や compute.skipDefaultNetworkCreation のように独自のものもあります。内容は、以下の公式ドキュメントを参考にしてください。 参考 : Predefined posture for secure by default, essentials 関連記事 Google Cloud の「組織」機能については以下の記事で詳細に解説しています。 blog.g-gen.co.jp 組織のポリシーを含む、Google Cloud の推奨セキュリティ設定を提供する G-gen のサービスである「セキュリティスイート for Google Cloud」についても、以下の記事をぜひご参照ください。 blog.g-gen.co.jp Security Command Center の詳細については、以下の記事も参考にしてください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it