G-gen の武井です。当記事では Google が提供するクラウド型グループウェアサービスである Google Workspace の全体概要や、機能、料金などについて解説します。 Google Workspace とは Google Workspace のメリット 働き方の改善 コスト 生成 AI モデル「Gemini」の活用 管理と活用 セキュリティ コアサービス 概要 コアサービス一覧 バリエーション 個人事業者向け、教育機関向け Google Workspace と個人アカウントとの違い Google Workspace のエディション・プラン エディション・プラン一覧 Business と Enterprise の比較 Frontline エディション その他の Google Workspace エディション Google Workspace Individual Google Workspace for Education お得な利用方法 Google Workspace 請求代行サービス Google Workspace スターターパック Google Workspace とは Google Workspace とは、Google が提供する クラウド型グループウェアサービス です。Google Workspace には、「従業員のアカウント管理」「ファイルストレージ」「E メール」「カレンダー」「チャット」などのツールが付属しており、日本で一般的な IT ツールの分類としては「グループウェア」と呼ぶことができます。Google 自身は、Google Workspace を「ビジネスアプリとコラボレーションツール」であるとしています。 参考 : Google Workspace Google Workspace には、Gmail、Google カレンダー、Google ドライブ、Google Meet、Google チャットなど、多くのアプリケーションがパッケージングされています。 様々なサービスがパッケージングされたグループウェアサービス また Google Workspace には Gemini と呼ばれる生成 AI モデルがネイティブに統合されており、 追加料金なし で、Gemini アプリ、NotebookLM、また各種アプリに統合された生成 AI 機能を使用することができます。AI 機能は通常料金に含まれているため、アドオンライセンス等は不要です。 Gemini アプリ Google Workspace のメリット 働き方の改善 Google Workspace を使えば、セキュリティを維持しつつ、 どんな場所からでも会社のデータにアクセスすることができる ため、離れた場所同士の社員が共同で作業をしたり、ビデオ会議でミーティングを実施したりするなど、会社にいるときと同じように業務を遂行することができます。もちろん、適切な設定をすれば、特定の場所や特定の端末からしかアクセスできないように制限も可能です。 「各従業員の PC のローカルにファイルを保存する」という従来型の考え方とは違い、Google Workspace では すべてのファイルがクラウド（Google ドライブ）上で管理 されます。Google ドライブ上のドキュメントやスプレッドシートなどのファイルは、 同時に複数の人から編集可能 で、変更は リアルタイムに画面上に反映 されます。また、誰がいつファイルを編集したかの記録も残され、ファイルの 版管理も自動的 に行われます。 そのため、「誰かが共有ファイルサーバー上の Excel ファイルをロックしている」「バージョン違いのファイルがたくさんあり、どれが最新版か分からない」といった非効率やストレスがなくなります。 当社 G-gen でも Google Workspace を最大限活用し、 100% フルリモートワークでクラウドネイティブな働き方を実践しています。 以下の記事で、当社の働き方を紹介しています。ぜひ皆様の業務や働き方に置き換え、どのような変化や効果が現れるのかを想像しながらお読みください。 www.wantedly.com コスト コスト面でもメリットがあります。 前述のようにマルチベンダでグループウェアを導入した場合、それぞれのサービスにライセンス料を支払いますが、Google Workspace の場合、支払うのは 1 ユーザーあたりの月額料金のみです。 画像内の料金はあくまでイメージです 生成 AI モデル「Gemini」の活用 Google Workspace には、Google が開発する生成 AI モデルシリーズである Gemini が標準で統合されています。 ほとんどのエディションで生成 AI 関連機能が通常のライセンス料金に含まれており、追加料金は不要です。 Google Workspace に含まれる AI 機能の例として、以下のようなものがあります。 機能/サービス名 概要 Gemini アプリ AI とのチャットツール。質問、要約、画像生成、動画生成、レポート生成など NotebookLM 独自データを読み込ませて、独自データに基づいたタスクを AI に行わせるノートブックツール Gemini in Google Workspace Google ドキュメント、スプレッドシート、スライド、Gmail などに組み込まれた AI 機能 生成 AI 関連機能の業務活用については、以下の記事を参照してください。 blog.g-gen.co.jp また Google Workspace に含まれる AI 機能では一部例外を除いて、入出力データは保護されており、Google のサービス改善に使われたり、モデルの再学習（再トレーニング）に使われることはありません。Google はこれを エンタープレイズグレードのデータ保護 と呼んでいます。 参考 : Google Workspace Service Specific Terms 参考 : Google Workspace の生成 AI に関するプライバシー ハブ 管理と活用 Google Workspace を選択するメリットの1つに、IT ツールの統合管理があげられます。 例えば、チャットツールは Slack、ビデオチャットツールは Zoom、ストレージは box といった具合で様々なツールを利用している場合、個々のツールの管理が必要になるほか、ツールの活用ノウハウやツール間連携の面で課題が生じます。 一方で Google Workspace は、さまざまなアプリケーションを1つのサービスとしてパッケージングしていることから、例えば Google Meet で作成したビデオ会議を Google カレンダーに連携して関係するユーザーすべてに会議情報を即座に共有したり、AI に議事メモを取らせて Google ドライブで関係者に自動的に共有したりと、アプリケーション間の連携が柔軟で使い方もシンプルです。 セキュリティ クラウドを利用することで、企業 IT の セキュリティが向上する という理解が広まってきています。 Google Workspace は ISO/IEC 27001、SOC 2 / SOC 3、PCI DSS などの第三者認証に準拠しており、一般的な情報システムより厳格といえます。 参考 : Google Workspace - 認証、監査、評価 また Google Workspace では管理者やユーザーサイドで使用可能な多くのセキュリティ機能が備わっています。設定管理はすべてブラウザベースの管理コンソールから行います。 種別 設定名 効果 アクセスと認証 2 段階認証 不正アクセスのリスクを大幅に低減。物理的なセキュリティキーを適用してユーザーアカウントのセキュリティをさらに強化 不審なログインの監視 機械学習の機能を不審ログインの検出に活用。不審なログインが検出されると即座に管理者に通知 シングルサインオン (SSO) 他の 3rd パーティーアプリケーションへのアクセスを統合 高度なメールセキュリティ カスタムルールを設定して S/MIME を使ったメールの署名と暗号化を必須化可能 コンテキストアウェアアクセス ユーザー ID、アクセス元の地域、デバイスのセキュリティ状況、IP アドレスなどの属性に基づいて、アプリに対する詳細なアクセス制御ポリシーを定義可能 アセットの保護 データ損失防止 (DLP) ポリシーを設定してデータ漏えいを防ぐ (例 : Gmail の添付ファイルにクレジットカード情報が含まれている場合、メールの送信をブロックして送信者に通知) 迷惑メールの検出 機械学習の機能を迷惑メールの検出に活用し、 99.9% という高い精度でセキュリティの脅威となるメールをブロック コアサービス 概要 Google Workspace では多くのアプリケーションが提供されており、PC で利用する場合は専用のアプリケーションをインストールする必要がなく、すべてが Web ブラウザ上で完結します。 操作が軽快なため、ビデオ会議をしながらリアルタイムでドキュメントを共同編集したりと、チームのコミュニケーションとコラボレーションを促進してくれます。 スマートフォンやタブレット端末向けにも、専用のモバイルアプリが用意されています。 コアサービス一覧 Google Workspace に含まれる複数のアプリケーションのうち、中核をなすものは コアサービス として定義されています。以下は、一部抜粋です。 サービス名 概要 特徴 Gmail メールサービス 希望のドメインで利用可能 Google Meet ビデオ会議ツール ビジネス向けの機能が充実しており、ビデオ会議は通信時に暗号化される Google Chat チャットツール 1対1 やチャットルームによるグループチャット。スマホやタブレットからも利用可能 Google カレンダー 共有型カレンダー Google Driveやメールなど様々なサービスと連携が可能 Google ドライブ クラウドストレージ スマホやタブレットからも利用可能 Google サイト 簡易 Web サイト作成ツール 社内ポータルサイトなどに活用可能。ドライブなど、様々な機能と連携 Google フォーム アンケートフォーム スプレッドシートとも連携しているため、回答後即座に分析可能 Google ドキュメント ワープロ 複数のユーザーとリアルタイム同時編集が可能。 Microsoft Word との互換性有り Google スプレッドシート 表計算 複数のユーザーとリアルタイム同時編集が可能。 Microsoft Excel との互換性有り Google スライド プレゼンテーション 複数のユーザーとリアルタイム同時編集が可能。 Microsoft PowerPoint との互換性有り 管理コンソール 設定管理画面 設定を一元管理するための管理者向けコンソール画面 Gemini アプリ AI チャットツール 質問、要約、画像生成、動画生成、レポート生成など NotebookLM AI ノートブックツール 独自データを読み込ませて、独自データに基づいたタスクを AI に行わせるノートブック 参考 : Google Workspace Services Summary バリエーション 個人事業者向け、教育機関向け Google Workspace には、企業や官公庁向けのほか、個人事業者向けの Google Workspace Individual、教育機関向けの Google Workspace for Education といったバリエーションがあります。 サービス名 カテゴリ 特徴 Google Workspace 企業・官公庁向け ビジネスのユースケースに応じて多くのエディション・プランが用意 Google Workspace Individual 個人事業者向け 無料の Google アカウントでは利用できない Gmail、Google Meet、Google カレンダーの一部機能とサポートを提供 Google Workspace for Education 教育機関向け 学校内の連携やオンライン授業ツールなどが充実 Google Workspace と個人アカウントとの違い アカウント名が @gmail.com で終わる個人向け Google アカウントでも、Gmail、Google カレンダー、Google ドライブ、Google Meet、Google チャットなど、一部のコアサービスは無償で使用可能です。 しかし、無償の個人向けアカウントは、Google Workspace と比較して、利用できる機能に制限があったり、管理コンソールでのアカウント管理ができない、サポートへの問合せができないなど、ビジネスシーンでは必須な機能やサポート体制が提供されません。 ビジネスシーンで利用では、有償版の Google Workspace エディションの契約が必須です。 項目名 無償版 有償版 管理コンソール ✕ 利用不可 ◯ 利用可能 技術サポート なし 日本語による24時間365日サポート ストレージ容量 15 GB 30 GiB/人 から (プランに依存) SLA なし 99.9% Google Workspace のエディション・プラン エディション・プラン一覧 企業・官公庁向けの Google Workspace には Frontline 、 Business 、 Enterprise の3つのエディションがあります。また Business エディションと Enterprise エディションは、それぞれ3つのプランに分けられます。 エディション プラン 料金 (※) 最大利用人数 ストレージ容量 Frontline Starter 520円 無制限 2GB Business Starter 800円 1 ~ 300人未満 30GB Standard 1,600円 1 ~ 300人未満 2TB Plus 2,500円 1 ~ 300人未満 5TB Enterprise Essential 問合せ 無制限 1TB Standard 問合せ 無制限 必要に応じて拡張可 Plus 問合せ 無制限 必要に応じて拡張可 (※) 2025年3月現在の年契約の場合の定価料金 Business と Enterprise の比較 Business エディションと Enterprise エディションの選択基準はさまざまなものがありますが、特に重要な基準として、最大利用人数が挙げられます。 参考 : Google Workspace の各エディションの比較 Business エディションでは、最大ユーザー数が300人です。Enterprise エディションでは、ユーザー数に制限はありません。組織規模が300人以上であれば、Enterprise エディションを選択する必要があります。 その他にも、デバイス管理機能をはじめ、Enterprise エディションでないと利用できない機能は複数あります。 詳細は以下の記事を参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp Frontline エディション Frontline エディション は、専用のデスクや端末を持たない現場スタッフを対象としたエディションです。 参考 : Frontline エディション 一部の機能が制限されている代わりに、安価にライセンスを購入することができます。Frontline エディションのライセンスは単体での契約ができず、Business プランか Enterprise プランとの併用が必須です。また、契約の際には Google によりユースケース審査が実施されます。 詳細は以下の記事を参照してください。 https://blog.g-gen.co.jp/entry/2022/01/24/100229 blog.g-gen.co.jp その他の Google Workspace エディション Google Workspace Individual Google Workspace Individual は、小規模の個人事業主・フリーランスを対象としたサービスです。基本的にすべてのアプリケーションが利用できますが、管理コンソールはありません。 特に Google Meet では長時間通話や録画機能などの上位プラン同等の機能が利用できるだけでなく、Google カレンダーにおいてはオンライン予約システムとしても利用可能な スケジュール予約機能 が搭載されています。 スケジュール予約機能を使えるのは、Individual のみです。 参考 : Google Workspace Individual の詳細 Google Workspace for Education Google Workspace for Education とは、小学校、中学校、高等学校といった教育機関向けのサービスです。クラウドを活用して生徒の学習を支援することを目的としています。 サービス提供先は教育機関に限定され、購入にあたっては Google による審査が行われます。 Google チャットを除いたすべてのコアサービスが利用できる他、Google Classroom やアサインメントといった、教育の現場に有用なアプリケーションが備わっています。 アプリケーション 特徴 Google Classroom 「クラス」と呼ばれるオンライン形式のコミュニティで教師と生徒間のコミュニケーションを支援。コアサービスと連携し、課題を管理したり、ライブ配信型の授業、ディスカッションなどを提供 アサインメント 課題の出題や、生徒の提出物の分析と採点を行える学習管理向けのアドオンアプリケーション 参考 : Google Workspace for Education スタートガイド お得な利用方法 Google Workspace 請求代行サービス G-gen に代表される Google Workspace の代理店経由で Google Workspace を申し込むことで、通常より割引された価格でライセンスを購入できることがあります。 G-gen の場合、割引価格での提供に加え、無料の技術サポート窓口が付帯しています。G-gen の請求油代行サービスでは、日本円建て・請求書支払いとなっています。 新規に利用開始を検討しているケースはもちろん、既に Google Workspace を利用中でも、手続きを経て代理店を切替可能です。 g-gen.co.jp Google Workspace スターターパック Google Workspace の導入を検討しているものの初期設定や導入後の活用に不安がある場合、G-gen の Google Workspace スターターパック が利用可能です。 G-gen のエンジニアが、組織への Google Workspace 導入を支援したり、作業代行を行います。 g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2026 選出。 趣味はロードレースやサッカー観戦、ゴルフ、筋トレ。 Follow @ggenyutakei

G-gen の佐々木です。今回は Google Cloud (旧称 GCP) の機械学習サービスである Vertex AI で、表形式データを用いた予測モデルの作成を試してみました。 私は機械学習についてはまだまだ勉強を始めたばかりなのですが、 Google の助けを借りて、高精度なモデル作りに挑戦してみようと思います。 Vertex AIとは AutoML モデル構築に使用するデータ 前処理 モデルのトレーニング 予測 予測結果 Vertex AIとは Vertex AI とは、 Google Cloud 上で機械学習モデルを開発・運用するための統合プラットフォームサービスです。 機械学習の学習用データセットを管理する DataSets 、学習用データの正解ラベル付けを自動で行う Data Labeling Service 、特徴量ストアを提供する Feature Store 、統合開発環境を提供する Workbench など、機械学習に関するサービスが統合されています。 今回はその統合されたサービス群から AutoML を使用していきます。 AutoML AutoML は、高度なデータサイエンスの知識を持っていなくても トレーニングデータをアップロードするだけで自動的に機械学習モデルを構築することができる サービスです。 Googleが目指している AIの民主化 を象徴するサービスの1つと言ってもよいでしょう。 AutoMLが自動化する範囲 現在 AutoML のトレーニングデータとしては、以下の 4 つがサポートされています ( 参考 ) 。 画像データ 表形式データ テキストデータ 動画データ モデル構築に使用するデータ 今回は表形式のデータ（CSVファイル）を使用してモデルをトレーニングしていきます。 モデルの作成に使用するトレーニングデータとして、パブリックドメインとなっている Adult Census Income を使用します。 このデータは米国の国勢調査局のデータベースから抽出されたものであり、ある個人に関する様々な情報（年齢、職業、結婚歴など）と「年収（income）が$50,000よりも高いか、$50,000以下か」が記録されています。 今回は AutoML を用いることで「各種パーソナリティ情報から年収（$50,000よりも高いかどうか）を予測する分類モデル」を作成していきます。 Adult Census Incomeのデータ 前処理 本データにNull値は含まれていないのですが、代わりに '?' が入力されているところがあるので、今回は '?' が含まれる行を欠損値ありとして全て取り除きました。 また、モデル学習後に予測精度を確認するため、予測に使うデータを一部を切り出して別々にCSVファイルに出力しています ( pred_data.csv と pred_answer.csv ) 。 以下のコードは、今回行った前処理の抜粋です。これ以外の前処理やモデルのトレーニングは出来る限り AutoML に任せていく方針です。 import pandas as pd from sklearn.model_selection import train_test_split # データ読み込み df = pd.read_csv( '/home/sasashun/notebook/blog/data/adult.csv' ) # ?を含む行を削除 drop_index = [] for column in [ 'workclass' , 'occupation' , 'native.country' ]: drop_index.extend(df.loc[df[column] == '?' ].index.values) drop_index = sorted ( set (drop_index)) df2 = df.drop(index=drop_index) # 学習に使用するデータ(train)とモデルに予測させるデータ(test)に分ける train, test = train_test_split(df2, test_size= 0.01 , random_state= 0 ) # testを使ってincomeを予測したときの正解率を見たいので、incomeは分離しておく pred_data = test.drop( 'income' , axis= 1 ) pred_answer = test[ 'income' ] # それぞれCSVファイルに出力 train.to_csv( '/home/sasashun/notebook/blog/train.csv' , index= False ) # トレーニング用のデータ pred_data.to_csv( '/home/sasashun/notebook/blog/pred_data.csv' , index= False ) # テストの際にモデルに与えるデータ pred_answer.to_csv( '/home/sasashun/notebook/blog/pred_answer.csv' , index= False ) # テストの正解データ（※後で不要になる） モデルのトレーニング モデルのトレーニング前に、トレーニングデータとなるデータセットを作成します。 今回はデータを「年収が$50,000より上」もしくは「年収が$50,000以下」のどちらかに分ける 分類 モデルを作成していきます。 データセットの作成① データソースとして、以下の3つの選択肢があります。 ローカルPCからアップロードしたCSVファイル GCSにあるCSVファイル BigQueryのテーブル/ビュー データセットの作成② 作成したデータセットについて、欠損値の数やユニークな値の数などをここで確認できます。 読み込んだデータセットの情報 データセットを作成したら、それをトレーニングデータとしてモデルの構築を行っていきます。 トレーニング方法として AutoML による Classification (分類) を選択します。 モデルのトレーニング① Target column には予測対象となる income を設定します。 トレーニングで使用される訓練データとテストデータの割合などもここで設定できます。 モデルのトレーニング② オプションではカラムごとのデータ型などが指定できますが、今回はデフォルトのまま Auto ML に全て任せます。 モデルのトレーニング③ 課金に影響する要素として、トレーニングに使用するノード時間を指定します ( 参考 ) 。 過学習 が起きる前にトレーニングを終了させる Early Stopping もここで設定できます。 以上の設定のみで、機械学習モデルの構築は AutoML が自動で行ってくれます。 モデルのトレーニング④ トレーニングが完了するとメールで通知されるようになっています。今回、トレーニングには2時間ほどかかりました。およそ 3,000 円の課金がされています (15 列×約 30,000 行のデータ、 1 ノード時間での学習) 。 トレーニング結果① トレーニングが終了すると、トレーニングによるモデルの予測精度の推移を確認することができます。 トレーニング結果② 構築されたモデルを確認すると、モデルの評価を一覧で確認することができます。0~1の値を取り、1に近ければ精度が高いとされる AUC や、0~∞の値を取り、0に近ければ精度が高いとされる LogLoss などの評価値を見ると、なかなか高精度なモデルになっているのではないかと思います。 構築したモデルの評価① 構築したモデルの評価② また、年収を予測する際に、各カラムがどれほど影響を及ぼしているのかが可視化されています。どうやら、以下のカラムの影響が特に大きいようです。 marital.status（結婚歴：独身・既婚・別居・離婚・死別など） education.num（教育年数） occupation（職業） age（年齢） 各カラムの重要度 予測 リアルタイムな予測が必要であればモデルをデプロイする必要がありますが、デプロイ後は削除するまで時間料金がかかってしまいます。 今回は数百行の予測用データ (pred_data.csv) で一度だけ予測を行いたいので、モデルをデプロイせずに バッチ予測ジョブ を作成して income を予測してみます。 バッチ予測に使用するデータのソースや、処理結果のエクスポート先には BigQuery と Cloud Storage が選択できます。 バッチ予測の作成 予測結果 今回、バッチ予測の結果を GCS に出力したのですが、予想に反して複数の CSV ファイルが出力されました。 それぞれのデータを繋ぎ合わせ、正解データと比較してみます。 予測結果のCSVファイル バッチ予測の出力は以下のようになっているので、前処理のときに用意した、正解のカラム (income) を含むデータフレームにマージします。 バッチ予測の結果 # 予測結果CSVファイルの読み込み pred_result = pd.read_csv( '/home/sasashun/notebook/blog/data/pred_result.csv' ) # 正解データが含まれるデータフレームにマージ test_result = pd.merge(test, pred_result) データフレームの income_>50K_scores カラムは予測によって出力されたものであり、年収が $50,000 を超える確率が入っています。 income_>50K_scoresカラムとincomeカラム 閾値を0.5として、値が0.5より大きければ '>50K' 、そうでなければ '<=50K' に変換し、新たなカラム pred_income として追加します。 sc_income[ 'pred_income' ] = sc_income[ 'income_>50K_scores' ].apply( lambda x: '>50K' if x > 0.5 else '<=50K' ) 予測結果であるpred_income列の追加 最後に、予測結果である pred_income と、正解である income がどれくらい一致しているかを確認します。 # pred_incomeとincomeの一致数 match_count = (sc_income[ 'pred_income' ] == sc_income[ 'income' ]).sum() # 一致した割合（一致数をデータ数で割る） print (match_count / sc_income.shape[ 0 ]) 今回構築したモデルでは、87%の確率で対象の年収が$50,000を超えているかどうかを予測できることがわかりました。 トレーニングデータに対する手動の処理をほぼ行っていない状態であっても、ここまでの精度を実現できるようです。 予測結果と正解データの一致割合 過去にKaggleで行われたコンペティションでは、 AutoML によって自動で構築されたモデルが2位にまで上り詰めた実績もあるようです ( 記事 ) 。 機械学習のモデルは、いかなる職人技によって構築されたものであっても、予測対象となる現実世界が時間の経過によって変化し、トレーニング時の状況から乖離してしまうことで、モデルの予測精度が下がってしまう問題があります。 そういった問題に対して、これからはAutoMLのようなサービスによる自動化を用いた MLOps の実践が極めて重要になってくるのではないかと思います。 私のように、これから機械学習のスキルを習得していくエンジニアは、このような自動化の仕組みと上手く付き合っていけるように、意識して学んでいく必要があるのかもしれません。 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア。 2022 年 6 月に G-gen にジョイン。Google Cloud All Certifications Engineer。 好きな Google Cloud プロダクトは Cloud Run。最近は Dataflow を勉強中。 Follow @sasashun0805

G-gen の杉村です。 Google Cloud（旧称 GCP）には Cloud Workflows という簡易的なワークフローツールがあります。今回の記事は Cloud Workflows を使った簡易的なデータパイプラインの構築方法をご紹介します。 はじめに Cloud Workflows とは 関連記事 この記事で作るもの 概要 SQL 実行方法 1 - BigQuery API Connector SQL 実行方法 2 - Scheduled Query Scheduled Query の呼び出し方 ワークフローの作成 フロー図 Cloud Run functions 関数 yaml ファイル 実行の流れ ワークフローのデプロイ ワークフローの実行 留意事項 はじめに Cloud Workflows とは Cloud Workflows （単に Workflows とも呼ばれる）は、Google Cloud で提供されるワークフローツールです。事前に定義したワークフロー（いわゆるジョブネット）に沿って、自動化ジョブを実行できます。ワークフローからは HTTP リクエストを実行したり、各種 Google Cloud API を呼び出すことができます。 フルマネージドサービスなのでインフラの管理・運用は一切不要であり、安価で無料枠も大きいのが特徴です。 ワークフローではジョブを「順次」「分岐」「繰り返し」を利用して実行可能です。ただし、簡易的な可視化機能はあるものの、ワークフローを GUI で編集することはできず、フローを YAML または JSON 形式で記述します。 またワークフローは、Cloud Scheduler と組み合わせて、定期的な自動実行が可能です。 参考 : ワークフローの概要 参考 : ワークフローの料金 関連記事 Cloud Workflows と Cloud Scheduler については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp この記事で作るもの 概要 当記事では Cloud Workflows を使って、BigQuery のデータに対して SQL を実行し、ELT 処理を行うワークフローを構築してみます。 当記事で紹介する手法では、BigQuery Data Transfer API を利用するため、少し改修すれば「Amazon S3 からデータを BigQuery に取り込み。その後、 ELT 処理を実行」というパイプラインも実現可能です。 イメージ SQL 実行方法 1 - BigQuery API Connector Cloud Workflows には Google Cloud の API を簡単に呼び出すための各種コネクタが存在します。BigQuery API Connector はその1つであり、簡単に BigQuery に対して SQL を実行できます。 参考 : BigQuery API Connector Overview ただし、このコネクタを使うとワークフローの yaml に直接 SQL を記述する必要があり、保守性が悪いため、今回はこの方法は採用しません。 SQL 実行方法 2 - Scheduled Query BigQuery の Scheduled query（スケジュールされたクエリ）機能では、BigQuery に保存した SQL を任意のタイミングで呼び出すことができます。 参考 : クエリのスケジューリング Scheduled query は本来、定期的に SQL を自動実行するための BigQuery 備え付けの機能です。しかし呼び出されたときだけ SQL を実行する「オンデマンド」としての保存もできます。今回のワークフローでは、Scheduled query を呼び出す方法を採用します。 保存されたオンデマンドの Scheduled Query を呼び出し Scheduled Query の呼び出し方 Scheduled Query は BigQuery Data Transfer API 経由で呼び出すことができます。 Cloud Workflows には BigQuery Data Transfer API をノーコードで呼び出せる BigQuery Data Transfer API Connector も存在しますが、記事を執筆した2022年6月現在で Preview 段階でした。 参考 : BigQuery Data Transfer API Connector Overview 当記事では本番利用を想定して、ワークフローから Cloud Run functions の関数を呼び出し、その関数から BigQuery Data Transfer API へリクエストする形でデータパイプラインを実現していきます。 なお BigQuery Data Transfer API では、他にも Amazon S3 から BigQuery へデータを転送するジョブ等も呼び出せるため、当記事のワークフローで「 Amazon S3 からデータを BigQuery に取り込み。その後、 ELT 処理を実行 」といった処理も可能です。 ワークフローの作成 フロー図 この記事では、以下の図のようなワークフローを構築します。 以下の図では実行されるジョブが query_01 の一つだけですが、数珠つなぎにジョブを繋げることで、クエリの完了を待って次のクエリを実行することが可能です。 ワークフローの例 Cloud Run functions 関数 今回作成する Cloud Run functions 関数については、当記事では詳細は紹介しませんが、以下のような関数を想定しています。 No 関数名 処理内容 戻り値 1 execute-sql BigQuery Data Transfer API 経由で、与えられたリソース名の Scheduled Query を実行する 実行したジョブ名 例: projects/1234567890/locations/asia-northeast1/transferConfigs/11111111-0000-1111-1111-111111111111/runs/99999999-0000-9999-9999-999999999999 2 check-status BigQuery Data Transfer API 経由で、与えられたジョブ名のジョブのステータスを確認する ジョブのステータス 例: SUCEEDED / RUNNING / PENDING / FAILED 等 当記事ではこれらの関数が HTTP トリガ関数としてデプロイ済みである前提で解説します。 以下の資料も参考にしてください。 参考 : Cloud Run functionsを徹底解説！ - G-gen Tech Blog 参考 : Python Client for BigQuery Data Transfer yaml ファイル 以下のような yaml ファイルを作成します。 main : steps : - initialize : assign : - query_01_name : "projects/1234567890/locations/asia-northeast1/transferConfigs/11111111-0000-1111-1111-111111111111" - query_01_timeout : 300 next : query_01 - query_01 : steps : - execute_01 : call : http.post args : url : https://asia-northeast1-your-project-name.cloudfunctions.net/execute-sql body : scheduled_query_name : ${query_01_name} auth : type : OIDC result : run_name - check_01 : steps : - setup_01 : assign : - elapsed_time : 0 - timeout : ${query_01_timeout} - check_status_01 : call : http.post args : url : https://asia-northeast1-your-project-name.cloudfunctions.net/check-status body : run_name : ${run_name.body} auth : type : OIDC result : status - check_if_complete_01 : switch : - condition : ${status.body == "SUCCEEDED" } next : finalize - condition : ${elapsed_time >= timeout} raise : "Job timed out" - condition : ${status.body == "RUNNING" OR status.body == "PENDING" } assign : - elapsed_time : ${elapsed_time+10} next : wait_01 - condition : True raise : "Job error" - wait_01 : call : sys.sleep args : seconds : 10 next : check_status_01 - finalize : return : "SUCEEDED" 7 行目の以下の行は、実際の Scheduled Query として保存されたオンデマンドクエリのリソース名で置き換えてください。 query_01_name: "projects/1234567890/locations/asia-northeast1/transferConfigs/11111111-0000-1111-1111-111111111111" 15 行目および 31 行目の以下の 2 行は Cloud Fucntions 関数 (HTTP トリガ) の呼び出し URL ですので、実際に構築した Cloud Run functions のものに置き換えてください。 url: https://asia-northeast1-your-project-name.cloudfunctions.net/execute-sql url: https://asia-northeast1-your-project-name.cloudfunctions.net/check-status 実行の流れ 冒頭のフロー図に示したとおり、これにより以下のワークフローが定義されます。 execute-sql 関数が実行されジョブが投入される check-status 関数が実行されジョブのステータスが確認される ステータスにより分岐 (以下の順で評価) ステータスが SUCEEDED であればジョブが正常終了 設定したタイムアウト秒数を超えていればワークフローが異常終了 ステータスが PENDING や RUNNING であれば 10 秒待機 10 秒間待機 check-status 関数の実行まで戻る ワークフローのデプロイ yaml ファイルができたら、以下のコマンドを実行します。 gcloud workflows deploy example-workflow \ --location = asia-northeast1 \ --source = example-workflow.yaml \ --service-account = hogehoge@hogehoge.gserviceaccount.com 4 行目の --service-account=hogehoge@hogehoge.gserviceaccount.com は、Cloud Run functions を起動する権限のあるサービスアカウントに置き換えてください。 ワークフローの実行 以下のコマンドにより、デプロイしたワークフローが実行可能です。 gcloud workflows run example-workflow --location = asia-northeast1 --call-log-level = log-errors-only ログレベルの設定など詳細は、以下のドキュメントをご確認ください。このコマンドでは、各ステップの実行履歴はログ出力されず、エラーが起きた場合のみログが Cloud Logging に出力されます。 参考 : ワークフローを実行する - gcloud なお、Cloud Workflows のコンソール画面からもワークフローのデプロイや実行が可能なほか、実行状態を確認することができます。 gcloud コマンドで実行した場合は、ワークフロー全体が完了するまでプロンプトが戻らないので、適宜コンソールで状態を確認したり、別ターミナルからステータスを確認するコマンドを実行してください。 参考 : ワークフローを実行する - 実行のステータスを確認する 留意事項 データパイプラインをはじめとする自動化ジョブでは、エラー時の検知やリトライを検討する必要があります。 当記事でご紹介したワークフローはあくまで簡易的なものです。実際の業務では以下を考慮してください。 冪等性（リトライ性） エラーの検知 ワークフローが失敗した際に、シンプルにワークフローを再実行すれば良いように、冪等性（何度実行しても同じ結果になる性質）が担保されるように変換処理を設計することが望ましいといえます。 また、エラー検知に関しては、ワークフローのエラーを Cloud Logging に出力させて、Cloud Monitoring で検知してメールや Slack へ通知する等が考えられます。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - ログ監視 当記事のワークフローでは、関数のエラーや例外をワークフロー内でハンドリングしていません。つまり、関数が失敗しても、戻り値が返ると次のステップが実行されてしまいます。Cloud Workflows にはエラーや例外をハンドリングする仕組みもありますので、これの利用を検討してください。 参考 : Workflow errors 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは、又吉です。今回は、 Google Workspace の全エディションにおいて無償で利用可能な コネクテッドシート （Connected Sheets）をご紹介します。 はじめに コネクテッドシートとは 前提条件 料金 アクセス制御 セットアップ 操作方法 概要 グラフ ピボットテーブル 関数 データの抽出 計算された列 列の統計情報 データの更新 VPC Service Controls とコネクテッドシート 実践 はじめに コネクテッドシートとは コネクテッドシート （Connected Sheets）とは、BigQuery に保存されているデータの可視化や分析を、Google スプレッドシート上で実現可能な機能です。Google スプレッドシートから BigQuery にアクセスし、BigQuery 上のデータをスプレッドシートに簡単に取り込むことができます。 Google スプレッドシートには、シート当たり最大 1,000 万セルまたは 18,278 列（列 ZZZ）までしか持てないという制限があるため、本来は 1,000 万セルを超えるビックデータの分析には適していません。一方で、BigQuery を使ってビックデータを分析するには、SQL の知識が必要になってしまいます。 参考 : Google ドライブに保管可能なファイル そこで、 SQL を使わずエクセルライクにビックデータを分析 したい方や、 簡単な集計はスプレッドシート上で済ませたい 方などにオススメなのがコネクテッドシートです。 参考 : コネクテッド シートを使用して Google スプレッドシートで BigQuery データを分析、更新する 参考 : コネクテッド シートの使用 前提条件 コネクテッドシートを利用するためには、Google アカウントが必要です。 また、BigQuery API が有効化された Google Cloud プロジェクトが必要です。 料金 コネクテッドシートの利用自体は 無料 です。 従来は Google Workspace の Enterprise エディションでのみコネクテッドシートが利用可能でしたが、2022年6月から、個人用の無償 Gmail アカウントを含む 全エディション で利用可能になりました。 コネクテッドシート自体は無料であるものの、BigQuery へのクエリ料金等は、通常どおり発生することにご留意ください。BigQueryの料金については、以下の Google Cloud 公式ページを参照ください。 参考 : BigQuery の料金 アクセス制御 コネクテッドシートで表示するデータは参照元の BigQuery データセットに存在するため、コネクテッドシートから BigQuery へのアクセスを実行する利用者の Google アカウントは、 対象の BigQuery テーブルに対してアクセス権限を持っている 必要があります。 また、 アクセス権の委任 という選択肢もあります。アクセス権の委任を行うと、最初に設定を行う人の Google アカウントの権限で BigQuery テーブルに接続し、後から利用する人もその人の権限を利用して、コネクテッドシートを利用することができます。ただしアクセス権の委任機能は、Google Workspace Enterprise / Education Standard / Education Plus / Enterprise Essentials / Enterprise Essentials Plus のいずれかのエディションでのみ利用可能です。 詳細は、以下の公式ページを参照ください。 参考 : 組織でコネクテッド シートを使用する セットアップ 今回扱うデータは、BigQuery の一般公開データセットにある「アイオワ州の酒類購入情報」（アイオワ州の 公式資料 より）から取得したいと思います。 まずは、新規のスプレッドシートから、[データ]→[データコネクタ]→[BigQueryに接続]をします。 接続先の情報を入力します。 [対象のGoogle Cloudブロジェクト]→[公開データセット]→ [iowa_liquor_sales]→[sales]→[接続] 今回接続したデータは2,399万行24列（約5.8億セル）のビックデータになりますが、ほんの10秒程度で一部データがプレビュー表示されました。 操作方法 概要 スプレッドシートでデータを分析するように、列データをもとに昇順/降順での並び替え、条件でフィルタをかけたりすることができます。 また、赤枠にある各種項目でグラフを作ったり、ピボットテーブルでデータを形成したり、より柔軟な分析ができます。 一つずつ簡潔に説明していきます。 グラフ グラフを用いるとデータを容易に可視化できます。グラフの種類も折れ線、縦棒、円、散布図、地図などから選択できます。 以下は都市別の売上をグラフ化してます。 ピボットテーブル ピボットテーブルは柔軟に分析ができるので、中でもよく使う分析項目かと思います。 こちらの例では月別の売上を表示させてます。右側のエディタから表示させたい行、列、値を選択し、グループ化やフィルタなどの条件もスプレッドシートの操作感で行えます。 実際に裏ではこのような感じのSQLに変換され、BigQuery 側で処理されています。コネクテッドシートを用いることで、SQL を打たずにビックデータの分析ができるのは魅力的です。 関数 関数はスプレッドシートで普段使うような集計関数などが利用できます。 データの抽出 データの抽出は、BigQuery からデータをスプレッドシート上に取り出しておける機能です。最大 500,000 行（ただし10MBまで）の BigQuery データを抽出できます。 コネクテッドシートのデータをグラフ化したり、あるいはスプレッドシート関数でコネクテッドシートのデータを参照すると、 都度 BigQuery にクエリが発行 されてしまいます。参照先テーブルが大規模だと、クエリに時間がかかったり、料金の増大に繋がります。 データの抽出機能を使ってシートにデータを取り出しておけば、 Google スプレッドシートの中でデータの扱いが完結する ので、パフォーマンス向上や料金節約に繋がります。 計算された列 計算された列は、任意の列に対し関数を組み込んで新しい列を作成できる機能です。 以下は、sale_dollars列に対し130を掛けて、japanise_enという新しい列を作成しました。 列の統計情報 列の統計情報は、任意の列情報を表示してくれます。 以下は、city列の統計情報を表示してます。一意の値がどれくらいあるのか、出現回数が最も多いのは何なのかなど、ぱっと調べたい時に有用ですね。 データの更新 BigQuery データとコネクテッドシートの同期は、 手動更新 または 自動更新 から選択できます。 手動更新は、コネクテッドシートの画面左下から選択できます。 プレビュー内容の手動更新 また、自動更新の単位は1時間・1日・1週間・1ヶ月から選ぶことができます。 自動更新を設定するには、コネクテッドシート上部の更新オプションを押下します。 自動更新の更新オプション その後、画面右側の更新スケジュールより、「繰り返す間隔」「開始日」を選択し保存します。 更新スケジュールの設定 注意点としては、更新するたびに裏で BigQuery に対してクエリが投入されるので、更新頻度が高いとその分、クエリ料金が高くなる可能性があります。 必要最小限の頻度でのデータ更新をオススメします。 VPC Service Controls とコネクテッドシート VPC Service Controls は、Google Cloud 環境に境界（perimeter）を構成して、API やデータを保護する機能です。 VPC Service Controls によって保護されているプロジェクトの BigQuery に対して、コネクテッドシートからアクセスするには、VPC Service Controls の 内向きルール と 外向きルール に適切な設定をする必要があります。 内向きルールには、コネクテッドシート利用者の環境からアクセス可能なよう、IP アドレス（アクセスレベル）や、アカウント単位、またはグループ単位の許可を設定します。 外向きルールには、Google によって管理されている専用プロジェクトへの API リクエスト実行許可を設定します。 詳細は、以下の公式ドキュメントを参照してください。 参考 : BigQuery - コネクテッド シートの使用 - VPC Service Controls また、VPC Service Controls の詳細については、以下を参照してください。 blog.g-gen.co.jp 実践 G-gen 社内で、実際にコネクテッドシートを使って分析を行っている事例は、以下の記事で紹介されています。ぜひ、ご参照ください。 blog.g-gen.co.jp 又吉 佑樹 (記事一覧) クラウドソリューション部 はいさい、沖縄出身のクラウドエンジニア！ セールスからエンジニアへ転身。Google Cloud 全 11 資格保有。Google Cloud Champion Innovator (AI/ML)。Google Cloud Partner Top Engineer 2024。Google Cloud 公式ユーザー会 Jagu'e'r でエバンジェリスト。好きな分野は生成 AI。 Follow @matayuuuu

G-gen の杉村です。 Google Cloud (旧称 GCP) では新機能やプロダクトが「Preview (プレビュー)」版などとしてリリースされることがあります。Preview が何を意味しているのか解説します。 プロダクトのリリースステージ プレビュー版は何が問題なのか 規約の違い Pre-GA Offerings Terms GA を待つ Google Workspace の場合 プロダクトのリリースステージ Google Cloud プロダクトには以下の2つのリリース段階があります。 Preview (プレビュー) Generally Available (一般提供、 GA) プレビューは、機能のテストや評価 をするためのリリース段階です。一方で一般提供 (GA とも呼ばれる) は、 Google Cloud の正式なプロダクトとしてリリースされたことを意味します。 一般的に、プレビュー段階のサービスは 本番環境で利用するべきではない とされています。当記事ではこれについて、もう少し深堀りしてみます。 なお余談ですが、以前は Google Cloud では早期アクセス、アルファ版、ベータ版、一般提供の 4 つのリリース段階がありましたが、 2020 年 10 月に 2 つに統合されました。 参考: And then there were two: Simplifying our product launch stages また Preview 段階の機能には "Private Preview" (プライベートプレビュー) というものもあります。この機能を使うには Google Cloud の担当者に連絡し、制限解除をしてもらう必要があります。 プレビュー版は何が問題なのか 規約の違い プレビュー版は何が問題で、なぜ本番環境での利用が非推奨なのでしょうか。 その答えはサービス利用規約に記載があります。 これ以降、当記事では 2022 年 6 月時点での利用規約類について概要を解説しています。最新版の正確な規約文は、 必ず原本をご参照ください 。当記事で得られた情報によって不利益を被ったとしても、当社では一切の責任を負いません。 Pre-GA Offerings Terms Google Cloud の利用規約群の一つである Service Specific Terms (サービス別利用規約) の General Service Terms の項にある 5. Pre-GA Offerings Terms を確認してみます。 抄訳すると、以下のようなことが書いてあります。 サービスは事前通知なしにいつでも変更、停止、中止されることがある SLA の対象とならない 技術サポートの対象とならない場合がある Data Processing and Security Terms (データ処理とセキュリティについて書いた規約) の対象とならないため機密情報処理に使うべきではない 規約に定められたデータのロケーションに関する規定から外れることがある このことから、サービスは Preview 公開されたものの GA せず終了となる こともありえますし、 仕様が突然変更 になることもあります。 また SLA の対象となりません 。 これらの理由から、 Preview 公開された機能は本番環境で使うべきではないとされているのです。 GA を待つ プロダクトが GA されると Google Cloud release notes や 公式ブログ で発表されます。 G-gen ではこれらの公式サイトの RSS をサブスクライブし、社内 Slack に新着情報が通知されるようにしています。 最新情報をチェックして、新サービスが Preview 公開されたり、 GA されるのを楽しみに待ちましょう。 Google Workspace の場合 ここまで Google Cloud のリリースステージについて述べました。一方、Google Workspace の場合はどうでしょうか。 Google Workspace の機能には、以下のフェイズがあります。 アルファ版テスト ベータ版テスト 一般提供（GA） アルファ版は、限定的なテスト版であり、通常は招待制です。サポートや SLA の対象にはなりません。 ベータ版は、通常では一般ユーザーも利用可能です。SLA は通常適用されませんが、限定的なサポートは提供される場合があります。 一般提供（GA）のフェイズになると、SLA やサポートの対象となります。 参考 : ソフトウェア テストのフェーズと GA について 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の武井です。当記事では Google Cloud の仮想マシンサービスである Compute Engine を徹底解説します。当記事は、Compute Engine の基本的な知識の解説に絞った 基本編 です。この記事を読んだ後は、 応用編 もご参照ください。 概要 Compute Engine とは Compute Engine とネットワーク 操作 VM のステート（状態） VM の停止・起動 一時停止・再開 修復状態 ネットワーク IP アドレスとネットワークインターフェイス インターネットとの接続 高度なネットワーキング マシンファミリー、マシンシリーズ、マシンタイプ 概要 マシンファミリー マシンシリーズ マシンタイプ 性能 リージョンとゾーン 概要 リージョン ゾーン リージョンとゾーンの設計 ストレージ VM のストレージ Persistent Disk Hyperdisk ローカル SSD リージョン間データ同期 ゾーン間データ同期 ディスクの暗号化（CMEK/CSEK） 複数 VM からのマウント 接続（ログイン） Linux VM の場合 Windows VM の場合 Cloud IAP を利用した接続 ユーザー管理と OS Login 機能 メンテナンスと障害対応 概要 ライブマイグレーション ホストエラー ホストメンテナンスポリシー ホストイベント以外の障害 バックアップとリストア バックアップ方法 スナップショット スナップショットとは 定期的なバックアップ リストア マシンイメージ バックアップ リストア スナップショット、マシンイメージ、カスタムイメージ Compute Engine の料金 料金の基本 vCPU・メモリ料金 有償の OS ライセンス料金 ディスク料金 スナップショット・イメージ料金 ネットワーク料金 課金対象 VM 同士の通信 プレミアムティアとスタンダードティア 外部 IP アドレス 割引制度 スポット VM 継続利用割引（SUD） 確約利用割引（CUD） 応用編の記事 概要 Compute Engine とは Compute Engine とは、Google Cloud（旧称 GCP）が提供する仮想サーバーのサービスです。Amazon Web Services（AWS）でいう Amazon EC2、Microsoft Azure でいうVirtual Machines にあたります。Google Compute Engine を省略して、GCE と呼ばれることもあります。 オンプレミスのようにハードウェアの調達や設置場所の確保等の準備は必要ありません。仮想サーバーを 必要なときに、必要な分だけ 利用することができます。もちろん、必要がなくなればマシンを削除したり、システムの規模に応じてあとから拡張したりすることも容易です。 Compute Engine で作成した仮想マシンは VM あるいは インスタンス と呼ばれます。 参考 : Compute Engine の概要 Compute Engine とネットワーク Compute Engine の VM は、Google Cloud の仮想ネットワークである Virtual Private Cloud （VPC）ネットワークの中に構築します。 VM には、VPC ネットワーク内の内部 IP アドレス（プライベート IP アドレス）や、インターネットからアクセスできる外部 IP アドレス（パブリック IP アドレス）を持たせることができます。 また VPC ネットワークを、専用線や VPN でオンプレミス環境と接続することで、Compute Engine VM に社内利用向けの業務システムをホストさせることも可能です。 VPC についての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 操作 Compute Engine VM の構築、起動、停止等の操作は、Web API 経由で行います。 API を呼び出すインターフェイスとして、 Google Cloud コンソール や Google Cloud CLI （gcloud コマンド）等があります。これらのインターフェイスから操作することで、VM を起動したり、停止したり、あるいは削除したり、設定を変更したりすることができます。 VM のステート（状態） VM の停止・起動 VM が作成されてから削除されるまでに取りうる状態を総称して、 ステート （状態）と呼びます。VM のステートには以下があります。 ステート名 意味 コンピュート料金 PROVISIONING VM が構築中 (初回起動時) 発生しない STAGING 起動状態 (RUNNING) へ移行中 発生しない RUNNING VM が実行中 発生 STOPPING VM が停止状態 (TERMINATED) へ移行中 発生 TERMINATED VM が停止済み。削除されたわけではなく再び起動できる 発生しない (※1) (※1) Persistent Disk や静的 IP アドレスなどは VM を停止していても課金が発生する VM を初めて 起動 （start）すると、PROVISIONING → STAGING 状態を経由して RUNNING 状態に至ります。この状態になると VM が利用可能です。また、課金も開始されます。 RUNNING 状態の VM を 停止 （stop）すると、STOPPING 状態を経由して TERMINATED 状態になります。TERMINATED になると課金も停止します。TERMINATED 状態の VM は、再度起動することで、STAGING 状態を経由して RUNNING に戻ります。 TERMINATED 状態の VM には CPU 料金やメモリ料金は発生しません。ただし Persistent Disk や静的 IP アドレスなどの周辺リソースの課金は引き続き発生します。 参考 : VM インスタンスのライフサイクル 参考 : VM を停止して起動する 一時停止・再開 VM には停止・起動というアクションの他に、 一時停止 （suspend）・ 再開 （resume）というアクションもあります。一時停止（suspend）は、停止（stop）とは異なり、デバイスの状態やメモリの内容を Google が管理するストレージに一時的に退避して、VM のコンピュートリソース（CPU やメモリ）を開放します。これは、一般的なノートパソコンなどで利用できる「ハイバネーション」と同じ仕組みです。 そのため次に再開する際は、一時停止前の状態に戻ります。一時停止した VM の再開は、停止した VM の起動よりも素早く完了します。 一時停止中の VM には CPU やメモリ料金は発生しませんが、デバイス状態・メモリ状態をストレージに保持するため、その分のストレージ料金が発生します。 一時停止と再開に関連して、以下のステートが存在します。 ステート名 意味 コンピュート料金 SUSPENDING VM が一時停止状態 (SUSPENDED) へ移行中 発生 SUSPENDED VM が一時停止済み 発生しない (※2) (※2) デバイス状態およびメモリの内容が保管されるため容量に応じて課金 参考 : VM を一時停止して再開する 修復状態 Compute Engine サービスの内部的なエラーが発生した場合や、基盤となっている物理マシンで障害が起きた場合、VM のステートが REPAIRING になることがあります。この状態の VM は使用不能です。 基本的には、Google Cloud 側が自動修復するため、復旧を待つ他ありません。復旧すると、VM は RUNNING 状態に戻ります。 ステート名 意味 コンピュート料金 REPAIRING VM が修復中 (物理ホストの障害等) 発生しない ネットワーク IP アドレスとネットワークインターフェイス VM は 内部 IP アドレス を持ちます。内部 IP アドレスは、同じ VPC ネットワーク内で一意のプライベート IP アドレスです。 また、VM には任意で 外部 IP アドレス を持たせることができます。これはインターネットに広報されるパブリック IP アドレスであり、セキュリティ向上のため、付与しないという選択も可能です。 後述の通り、外部 IP アドレスには料金が発生します（2025年3月時点の東京リージョンで $0.005/時間）。 また、VM は複数のネットワークインターフェースを持つことも可能です。 参考 : 複数のネットワーク インターフェース インターネットとの接続 VM は外部 IP アドレスを持たせることでインターネットへ出ていく通信をしたり、逆にインターネットから接続されることが可能になります。ただし、VM がインターネットと通信するには、VPC ネットワークで適切にルートやファイアウォールが設定されている必要があります。 また、 Cloud NAT を使うことで、VM に外部 IP を持たせずにインターネットへのアウトバウンド通信（外向き通信）だけを許可することも可能です。 参考 : Google CloudのVPCを徹底解説！(基本編) - ルート 参考 : Google CloudのVPCを徹底解説！(基本編) - ファイアウォール（Cloud NGFW） 参考 : Google CloudのVPCを徹底解説！(基本編) - Cloud NAT なお VM が外部 IP アドレスを使って Google API や Google Cloud API へアクセスする際は、トラフィックは公共のインターネットを通らず、Google のネットワーク内にとどまることが、以下のドキュメントに明記されています。 参考 : 外部 IP アドレスを持つ VM から API にアクセスする 接続は VM の外部 IP アドレスから行われますが、トラフィックは Google Cloud 内にとどまり、公共のインターネットを介して送信されません。 高度なネットワーキング Google Cloud と Compute Engine では、VPC の機能により高度なネットワーキングを行うことができます。 VPC に対する理解とセットとなるため、詳細は以下の記事もあわせてご確認ください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp マシンファミリー、マシンシリーズ、マシンタイプ 概要 マシンファミリー 、 マシンシリーズ 、 マシンタイプ とは、 VM の CPU やメモリなどのリソースに関連する概念です。 参考 : マシン ファミリーのリソースと比較ガイド Compute Engine には、以下のようなマシンファミリー・マシンシリーズが存在しています。なお以下の表は一部抜粋のため、完全なリストは上述の公式ドキュメントを参照ください。 マシンファミリー マシンシリーズ 用途 汎用 E2 汎用的で、最も安価 N4 Web アプリ、中規模データベース、メディアなど。Intel 製 CPU N4D N4 と同用途。CPU が AMD 製であり時間単価が安い N4A N4 と同用途。Google 製の Axion プロセッサ（Arm ベース）で費用対効果が高い C4 高性能と信頼性が求められるアプリに。Intel 製 CPU Tau T2A スケールアウトするワークロード向け。Arm プロセッサ搭載 Tau T2D スケールアウトするワークロード向け。AMD プロセッサ搭載 コンピューティング最適化 C2 CPU 重視のワークロード。ゲーム、広告、 HPC 、 メディアトランスコード、 AI/ML 等 C2D C2 と同用途だが CPU が AMD 製であり時間単価が安い メモリ最適化 M3 メモリ重視のワークロード。大規模データベース、インメモリデータベース、 SAP HANA 等 M4 メモリ重視のインスタンスタイプ。M3 よりも最大 vCPU が大きく、より新しい Intel Emerald Rapids CPU を搭載 アクセラレータ最適化 A3 GPU 搭載。機械学習、HPC、並列コンピューティング等 A4 GPU 搭載。A3 より搭載可能な最大メモリが大きく、より新しい NVIDIA B200 GPU を搭載 G4 GPU 搭載。NVIDIA RTX PRO 6000 Blackwell。グラフィックやビデオエンコーディングに マシンファミリー マシンファミリー とは、複数のマシンシリーズをグルーピングした概念です。「汎用マシンファミリー」「コンピューティング最適化マシンファミリー」「メモリ最適化マシンファミリー」などがあり、それぞれの得意分野を表しています。 マシンシリーズ マシンシリーズ とは、VM がホストされる物理マシンの特性を示しています。 例えば汎用マシンファミリーの一つである E2 マシンシリーズ は、 Intel もしくは AMD（Intel 互換）の CPU を搭載した、汎用的な用途に対応したマシンです。 「メモリ最適化マシンファミリー」に分類される M2 マシンシリーズ は Intel Skylake CPU を搭載しており、他のシリーズより vCPU あたりに割り当てることができるメモリの量が多くなっているため、高稼働なデータベースを搭載する VM に適しています。 マシンシリーズ名の最初のアルファベットはシリーズの種類を示しており、それに続く数字は世代を表しています。例えば N2 シリーズには、より古いバージョンの N1 シリーズが存在します。通常は、より新しいバージョンを利用することが推奨されますが、最新のマシンシリーズは一部のリージョンでしか使えない場合もあるため、対応リージョンは以下のドキュメントで確認が必要です。 参考 : Available regions and zones マシンタイプ マシンタイプ とは、Google Cloud によって事前定義された VM のリソース割り当てのプリセットです。例えば e2-standard-2 マシンタイプは E2 シリーズの物理マシンを利用し、 2 コアの vCPU と 8 GiB の RAM を搭載した VM です。 VM の構築時にマシンタイプを指定しますが、あとから変更することが可能です。ただしマシンタイプの変更には、VM を一度停止する必要があります。 ここまでの内容を総合すると、マシンタイプ名である e2-standard-2 の表記の意味を分解できます。 先頭の e2 はマシンシリーズを指しています。中央の standard はマシンタイプの特徴を表しており、他に highmem や highcpu などが存在します。最後の 2 は vCPU コア数を示しています。 参考 : マシン ファミリーのリソースと比較ガイド - 事前定義されたマシンタイプ マシンタイプの表記の意味 なお、ユーザー独自のに カスタムマシンタイプ を定義することも可能です。例えば、 e2-standard-2 は 2 vCPU / 8 GiB RAM を搭載していますが、メモリがそこまで必要ないため「2 vCPU / 6 GiB RAM に落としたカスタムマシンタイプで VM を起動する」ということも可能です。利用料金は、割り当てた vCPU とメモリの量に応じてのみ発生します。これにより、 必要最小限の利用料金で VM を起動 することができます。 ただし、マシンシリーズごとに vCPU あたりに最低限割り当てなければいけないメモリ量と、上限のメモリ量が決まっており、その範囲内での調整が可能です。 参考 : マシン ファミリーのリソースと比較ガイド - カスタム マシンタイプ 性能 マシンシリーズごとに搭載 CPU 等のハードウェア仕様が異なるため、同じ vCPU 数、同じメモリ数の VM を構成しても、マシンシリーズごとに性能が異なる場合があります。 以下の公式ドキュメントでは、PerfKitBenchmarker というオープンソースツールを使って計測したマシン性能が、参考情報として公開されています。 参考 : CoreMark scores of VMs by family リージョンとゾーン 概要 Google Cloud には、 リージョン と ゾーン の概念があります。 Google Cloud は 200 以上の国と地域に専用のインフラ設備を展開しており、2025年7月現在、42のリージョンと127のゾーンが存在します。Google Cloud は設備を順次拡大しており、例えば2022年6月時点ではリージョン数が33、ゾーン数が100でした。3年間で10近くの新規リージョンを開設したことになります。 参考 : リージョンとゾーン 参考 : Cloud locations リージョン リージョン とは、地域ごとに設立された Google Cloud のデータセンターの集合体です。 「東京（asia-northeast1）」「大阪（asia-northeast2）」「ロサンゼルス（us-west2）」「ロンドン（europe-west2）」などのリージョンが存在します。リージョンは、複数のゾーンで構成されます。 ゾーン ゾーン とは、1つまたは複数のデータセンターで構成されており、電源、空調、物理機器といった設備をある程度共有する「単一障害ドメイン」です。 例として東京（asia-northeast1）リージョンの中には asia-northeast1a 、 asia-northeast1b 、 asia-northeast1c の3つのゾーンが存在します。 異なるゾーンでは、電源や空調は別のものが使われていますので、複数のゾーンに VM を展開することで、システムの可用性を向上させることができます。 リージョンとゾーンの設計 VM を構築する際、どのリージョンのどのゾーンに設置するかを指定します。 例えば、世界中のユーザにサービスを提供するアプリケーションをホストする VM マシンを設計する場合、複数のリージョンに VM を配置するマルチリージョン構成とすることで レイテンシ （通信遅延）を抑えることができます。 また障害発生時の可用性を担保するために、同一リージョン内の複数ゾーンに VM を配置して冗長性を確保するといったマルチゾーン構成は、ごく一般的です。 なお VM マシンの利用料金や利用可能なマシンタイプはリージョンやゾーンによって異なります。どのゾーンでどのマシンタイプが利用可能かは、以下の公式ドキュメントを参照してください。 参考 : 使用可能なリージョンとゾーン ストレージ VM のストレージ Compute Engine VM で利用可能なストレージ（ディスク）は、大きく分けて以下の種類があります。 Persistent Disk Hyperdisk ローカル SSD いずれもブロックストレージと呼ばれる種類のストレージです。ローカル SSD は VM をホストしている物理サーバーに物理的にアタッチされていますが、Persistent Disk と Hyperdisk はネットワークストレージです（とはいえ OS から見ると、物理的にアタッチされている場合と同様に使用できます）。それぞれの種類に応じて、性質や性能、料金が異なります。 参考 : ディスクタイプを選択してください Persistent Disk Persistent Disk （日本語では永続ディスクとも呼称）は、Compute Engine VM で最も一般的に利用されるストレージです。 Persistent Disk は不揮発性のストレージです。不揮発性とは、「VM を停止しても保存されたデータが削除されない性質」を意味します。一方で、後述するローカル SSD は揮発性のディスクであり、VM を停止すると内容が失われる、一時保存領域です。 Persistent Disk は VM にアタッチ（取り付け）したり、デタッチ（取り外し）することが可能であり、ある VM にアタッチされていた Persistent Disk をデタッチして、再度別の VM にアタッチすることも可能です。 Persistent Disk には複数のタイプがあり、性能や費用が異なります。 No タイプ名 性質 1 Standard Persistent Disk HDD。コストは最も低い。シーケンシャルアクセスではスループットが出るが、ランダムアクセスには適さない 2 Balanced Persistent Disk SSD。標準 Persistent Disk と SSD Persistent Disk の中間。コストとパフォーマンスのバランスに優れており、最も一般的に利用される 3 SSD（Performance）Persistent Disk SSD。IOPS とレイテンシに優れ、高速なランダムアクセスを実現する 4 Extreme Persistent Disk SSD。高いパフォーマンスが求められるワークロード向け。IOPS の事前プロビジョニングが可能。対応するマシンタイプが限られる なお上記のディスク名は、英語版ドキュメントの表記を採用しています。2025年7月現在の日本語版公式ドキュメントの表記は、「永続ディスク」と「Persistent Disk」 が混在していてわかりにくいものとなっています。公式の日本語表記は、上から、標準 Persistent Disk、バランス永続ディスク、SSD（パフォーマンス）永続ディスク、エクストリーム Persistent Disk です。しかしながら日本語版 Google Cloud コンソール上は「永続ディスク」の表記に統一されているなど、一貫性のない和訳となっています。 参考 : Persistent Disk について Hyperdisk Hyperdisk は、特に高性能なストレージが必要とされるワークロードに最適な Compute Engine VM 用の不揮発性ストレージです。 Persistent Disk と比較して、高い IOPS やスループットを出すことができます。 Hyperdisk には以下の種類があります。 No タイプ名 性質 1 Hyperdisk Balanced Hyperdisk の中でも費用対効果のバランスがよく幅広い用途に対応 2 Hyperdisk Balanced High Availability 同一リージョン内の複数ゾーンにデータを同期的に複製 3 Hyperdisk ML 最も高いスループットを実現。機械学習ワークロードに適している。読み取り専用で複数 VM にアタッチ可能 4 Hyperdisk Extreme IOPS とスループット、レイテンシで高い性能を発揮する。データベースなど要求の厳しいワークロードに適している 5 Hyperdisk Throughput 容量とスループットを柔軟に設定できる。分析ワークロードやコールドストレージ向け。Hadoop や Kafka など 参考 : Google Cloud Hyperdisk について ローカル SSD ローカル SSD は、VM の物理ホストに直接アタッチされたストレージであり、高性能ではありますが VM を停止すると内容が消失する、揮発性のストレージです。Persistent Disk や Hyperdisk は、物理ホストとネットワーク経由で接続されたネットワークストレージですが、ローカル SSD は VM が稼働する物理マシンに直接接続されています。ローカル SSD は エフェメラルディスク とも呼ばれます。 ローカル SSD は、 高速な入出力（I/O） と 低いレイテンシ で利用できます。ただし揮発性のディスクであるため、VM を停止すると ディスクに保存された内容は失われ ます。それゆえ、 ブートディスクとしては利用できません 。また、E2 シリーズや Tau T2D シリーズ等、一部のマシンタイプでは利用できません。 これらの性質から、ローカル SSD はデータの保存（永続化）用途ではなく、 キャッシュ用途 や 一時ファイルの保存用途 で利用するものです。 参考 : ローカル SSD ディスクについて なお、2025年3月時点でプレビュー版の機能として、ローカル SSD を利用する VM を停止または一時停止する際に、データを Persistent Disk に一時退避して、VM が再開されるときに復帰することができます。この機能を用いると、VM を停止（一時停止）している間、退避したデータサイズに応じた標準 Persistent Disk の料金が発生します。 参考 : VM の停止または一時停止時にローカル SSD データを保持する リージョン間データ同期 Persistent Disk 非同期レプリケーション （PD 非同期レプリケーション）を用いると、Persistent Disk のデータを 別のリージョン に非同期で転送し、災害対策等に役立てることができます。 転送元のディスクをプライマリディスク、転送先のディスクをセカンダリディスクといいます。また、転送元のリージョンをプライマリリージョン、転送先のリージョンをセカンダリリージョンといいます。 PD 非同期レプリケーションを利用できるのは、Balanced Persistent Disk と、SSD（Performance）Persistent Disk のみです。 参考 : Persistent Disk の非同期レプリケーションについて ゾーン間データ同期 Persistent Disk と Hyperdisk Balanced High Availability では、ゾーン間で ディスクの同期レプリケーション が利用可能です。この機能を用いると、異なるゾーン間でデータが同期的に転送され、ゾーン障害に備えることができます。 転送元のゾーンをプライマリゾーン、転送先のゾーンをセカンダリゾーンといいます。 ゾーン間転送を有効化した Persistent Disk は、 リージョン Persistent Disk （Regional Persistent Disk） と呼ばれます。 リージョン Persistent Disk や Hyperdisk Balanced High Availability では、プライマリゾーンで障害は発生して VM が利用不可になっても、セカンダリゾーンの VM にディスクを 強制アタッチ （強制接続）することでデータを引き続き利用できます。 参考 : ディスクの同期レプリケーションについて 参考 : リージョン Persistent Disk ディスクの暗号化（CMEK/CSEK） Google Cloud の全てのサービスにおいて、保存されるデータは、 デフォルトで透過的に暗号化 されています。つまり、何もしなくてもストレージ上のデータは暗号化されており、ストレージ機器の盗難や紛失、Google の内部犯行によるストレージへのアクセスなどへは対策がされます。 このデフォルトの暗号化では、Google によって暗号鍵が管理されています。非常に高いセキュリティが求められたり、情報セキュリティ監査や社内のセキュリティポリシーにおいて、鍵の管理を自組織で完結できるように求められている場合などには、デフォルトの暗号化ではなく、ユーザーが指定する暗号鍵でディスクを暗号化することもできます。 フルマネージドの鍵管理サービスである Cloud KMS を利用することで、ユーザー管理の鍵を用いて暗号化を実現できます。Cloud KMS に鍵管理を委託する場合は Customer-managed Encryption Key 暗号化 （CMEK 暗号化）、ユーザ側で鍵の作成や管理まで行う場合は、 Customer-Supplied Encryption Keys 暗号化 （CSEK 暗号化）と呼ばれます。通常、後者は非常に運用オーバヘッドも大きく、難易度が高いものになります。 参考 : 顧客指定の暗号鍵でディスクを暗号化する 参考 : Cloud KMS 鍵を使用してリソースを保護する Cloud KMS については以下の記事も参照してください。 参考 : Cloud KMSを徹底解説 複数 VM からのマウント 一部の種類の Persistent Disk や Hyperdisk は、複数の VM から 読み取り専用モード もしくは読み書きが可能な マルチライターモード でマウントすることができます。 これにより、高可用性を担保したいときや、フェイルオーバークラスタの構成に役立てることができます。 読み取り専用モードに対応しているディスク Standard Persistent Disk Balanced Persistent Disk SSD（Performance）Persistent Disk Hyperdisk ML マルチライターモードに対応しているディスク SSD（Performance）Persistent Disk Hyperdisk Balanced Hyperdisk Balanced High Availability Hyperdisk Extreme その他の制限や仕様などの詳細は以下のドキュメントを参照してください。 参考 : インスタンス間でディスクを共有する 接続（ログイン） Linux VM の場合 Linux VM には SSH プロトコルを使ってログインします。事前に VPC ファイアウォールで、接続元 IP アドレスからの SSH ポート（22/tcp）を許可したうえで、以下のいずれかの方法で SSH ログインできます。 Google Cloud コンソールからブラウザのターミナルで SSH ローカル PC の SSH ターミナル gcloud コマンドライン 以下のスクリーンショットは、 1. のブラウザのターミナルを利用した例です。Web ブラウザのウインドウが SSH ターミナルとなります。ファイルのアップロードやダウンロードも可能です。Cloud IAP という仕組みを使えば、VM が外部 IP アドレスを持っていなくともログインできますし、踏み台サーバーも不要です。 SSH ボタンをクリックするだけ ファイルのアップロード / ダウンロードも可能 参考 : Google ツールを使用して Linux VM に接続する 参考 : サードパーティ ツールを使用して Linux VM に接続する 以下の記事では、VM への SSH ログインの方法を整理して解説していますので参考にしてください。 参考 : Compute Engine の SSH 接続方法についてのまとめ Windows VM の場合 Windows VM へは、RDP（リモートデスクトップ）を使ってログインします。Windows VM を構築後、初回ログイン時のみ、まず認証情報の生成（OS ユーザーの作成とパスワード取得）をする必要があります。 この認証情報を用いて RDP クライアントツールから、Windows VM の外部 IP に対して接続することでログインできます。外部 IP がアタッチされていないマシンに対しては、踏み台サーバーを利用したり、Cloud IAP を利用することでログインできます。 参考 : Windows VM の認証情報を生成する 参考 : RDP を使用して Windows VM に接続する Cloud IAP を利用した接続 Google Cloud には Cloud Identity-Aware Proxy （Cloud IAP）とよばれるフルマネージドのリバースプロキシサービスがあります。 こちらのサービスを利用することで、踏み台サーバを用意することなく、外部 IP アドレスを持たない VM に対しても、セキュアな接続を実現できます。 接続イメージは以下の図の通りで、利用者はまずインターネット経由（HTTPS プロトコル）で IAP へアクセスして、トンネルを作成します。このとき、利用者は Google アカウントで認証します。また IAP を利用できるのは、 Cloud IAM で適切なロールを付与された人だけですので、適切な認可も可能です。 Cloud IAP の使い方については、以下の記事で詳しく解説していますので、ご参照ください。 参考 : 踏み台サーバはもういらない。IAP(Identity-Aware Proxy)の便利な使い方 ユーザー管理と OS Login 機能 OS ユーザーの管理は、Linux でも Windows Server でも、オンプレミスのサーバと同様に行う必要があります。 Linux VM の場合は OS Login 機能を活用することで、ユーザー管理を Google アカウントと連携させて、管理工数を節減することができます。 参考 : OS Login の概要 OS Login の詳細については、以下の記事をご参照ください。 参考 : Google Compute EngineのOS Login機能でSSHユーザを楽に管理しよう メンテナンスと障害対応 概要 Compute Engine の実行基盤となる物理ホストにおけるメンテナンスや障害など、VM の実行に支障となりえるイベントのことを、 ホストイベント といいます。 これらが発生した際は、事前に設定した ホストメンテナンスポリシー に応じて、VM のライブマイグレーションや再起動などが行われます。 ホストイベント 説明 メンテナンスイベント ハードウェアまたはソフトウェアの更新を行うイベント ホストエラー VM をホストしている物理基盤上で稼働中の VM がクラッシュするようなハードウェアまたはソフトウェアの問題 参考 : ホストイベントについて ライブマイグレーション ホストシステム（Compute Engine の実行基盤である物理ホスト）でメンテナンスイベントが発生しても、多くの場合、 ライブマイグレーション 機能によって VM は停止することなく、同じゾーン内の別の物理ホストに移動します。 ライブマイグレーションに伴う中断時間は、 通常は1秒未満 とされています。また、ユーザーの介入は必要ありません。 ただし、C3 ベアメタルインスタンスや X4 ベアメタルインスタンス、Z3 VM、多くの Confidential VM インスタンス、Cloud TPU など、一部の VM ではライブマイグレーションがサポートされないことに注意する必要があります。 参考 : メンテナンス イベント中のライブ マイグレーション プロセス ホストエラー ホストエラー とは、Compute Engine のサービス基盤における障害のことです。ホストエラーが発生すると、ライブマイグレーションが失敗することがあります。 その場合は、デフォルトでは、通常は180秒、最大でも330秒待機してから、VM が自動的に再起動されます。ホストエラーが発生する可能性は一般的には低いといえますが、そのような場合に備え、マネージドインスタンスグループなどを利用して可用性の高い設計にすることが重要です。 参考 : ホストエラー ホストメンテナンスポリシー ホストメンテナンスポリシー とは、メンテナンスイベントやホストエラーが発生した際の VM の挙動を定義するためのポリシーです。以下の設定値を持たせることができます。 No 項目名 意味 デフォルト 1 メンテナンスの動作 メンテナンスイベント発生時に VM をライブマイグレーションするか停止するか 移行する 2 再起動の動作 VM がクラッシュした場合やホストエラーが発生した場合、 VM を再起動するか停止するか 再起動 3 ホストエラーの検出時間 VM が応答していないことを検出してから VM の再起動または終了を行うまで待機する最大時間 330秒 4 ローカル SSD のリカバリタイムアウト ホストのエラー後にローカル SSD データの復元を待機する時間 1時間 ホストメンテナンスポリシーは VM を作成する際に設定可能なほか、作成後にあとから変更することもできます。設定しない場合は、デフォルトの挙動が適用されます。 参考: インスタンスのホスト メンテナンス ポリシーを設定する ホストイベント以外の障害 ここまでに示したように、物理基盤におけるメンテナンスや障害には、Compute Engine によって柔軟で自動的な対応が行われます。 しかし、これらの機能だけでは、OS レイヤやソフトウェアの障害、 CPU やメモリリソースの逼迫によるパフォーマンス劣化などには対応できません。 Cloud Monitoring によるリソース監視やサービス URL の外形監視などは、 他のクラウドサービスやオンプレミスと同様に重要である ことに留意しましょう。Cloud Monitoring については、以下の記事も参照してください。 参考 : Google Cloud(GCP)のCloud Monitoring解説 (基本編) バックアップとリストア バックアップ方法 VM のバックアップには、複数の方法があります。 ストレージの スナップショット VM の マシンイメージ 前者はストレージ（Persistent Disk 等）のスナップショットを取る機能であり、ディスク単位でのバックアップとリストアを実現します。 後者は後発の仕組みであり、2022年1月に GA（一般公開）されました。マシンイメージは、1台の VM をまるごとバックアップする機能です。 スナップショット スナップショットとは スナップショット は、Persistent Disk や Hyperdisk 等のストレージに格納されているデータをバックアップする仕組みです。 スナップショットを複数回実行すると、前回に取得したときからの増加分データのみがバックアップされます（ 増分バックアップ ）。またデータは自動的に圧縮されるため、ディスクの完全なコピーをバックアップとして作成するよりも高速かつ低コストでバックアップを実現できます。 スナップショットは VM が起動している状態でも取得することができます。 スナップショットには、 スタンダード （標準）、 アーカイブ 、 インスタント （即時）の3種類があり、以下のような性質を持っています。 比較観点 - - - - - - - リストア速度 [速い] インスタント > スタンダード > アーカイブ [遅い] コスト [高い] インスタント > スタンダード > アーカイブ [安い] 冗長性 [高い] アーカイブ = スタンダード > インスタント [低い] 参考 : アーカイブ ディスクと標準ディスクのスナップショットについて 参考 : インスタント スナップショットについて 定期的なバックアップ スナップショットスケジュール 機能を使用することで、定期的にスナップショットを自動取得することができます。スナップショットスケジュールは Google Cloud コンソール画面から設定できるため、cron や自動化スクリプトを作成する必要はありません。 参考 : ディスク スナップショットのスケジュールを作成する リストア スナップショットからリストアを行うと、 新しいディスクが作成 されます。元のディスクの中身をある時点に巻き戻す、といったことはできません。 スナップショットから特定のデータのみを取り出したい場合は、スナップショットからディスクを作成し、そのディスクを VM にアタッチしてマウントすることで、取り出すことができます。 あるいは元の VM を一度停止して、復元したディスクをアタッチし、元のディスクは取り外してから VM を起動することで、マシンのリストアを行うこともできます。もしくは、復元されたディスクから新規に VM を作成することも可能です。 参考: スナップショットから復元する マシンイメージ バックアップ マシンイメージ は、1台の VM の情報をすべてバックアップする手法です。マシンイメージは、VM のプロパティ、メタデータ、権限、接続されている全てのディスクのデータを持ちます。 スナップショットが個々のディスクのバックアップであるのに対し、マシンイメージは VM をまるごとバックアップ するような仕組みと理解すればよいでしょう。 なお、マシンイメージもスナップショット同様、増分バックアップです。またスナップショット同様、 VM が起動している状態で取得することができます。 参考 : マシンイメージ 2025年7月現在では、スナップショットスケジュールのような自動取得の仕組みは存在しておらず、取得を自動化したい場合は、Cloud Run functions などを用いて自動化スクリプトを作成する必要があります。 以下の記事では、 API を用いた自動化の一例を紹介しています。 参考 : Cloud Run functionsを使用してCompute Engineのマシンイメージを自動で取得する リストア マシンイメージからのリストアを行う場合は、マシンイメージから VM を新たに作成 することになります。スナップショットと同様、ある VM の中身をある時点に巻き戻す、といったことはできません。 外部 IP アドレスを維持したい場合、リストア元の VM にアタッチしていた固定 IP アドレスを、新規 VM に付け替えるといった対応が必要です。また内部 IP アドレスについては、アドレスを解放するためにリストア元の VM を先に削除する必要があります。 参考: マシンイメージから VM インスタンスを作成する スナップショット、マシンイメージ、カスタムイメージ Compute Engine には、スナップショット、マシンイメージの他に、カスタムイメージ（または単にイメージ）という機能も存在します。 これらの違いは、以下の記事で詳細に整理しています。 参考 : Compute Engineのスナップショット、マシンイメージ、カスタムイメージの違い Compute Engine の料金 料金の基本 Compute Engine の利用料金は、以下の要素に対する 従量課金 です。 vCPU メモリ (RAM) ストレージ GPU 有償の OS ライセンス (プレミアムイメージ) スナップショット (バックアップ) ネットワーク (データ通信量) IP アドレス 詳細は以下の公式ドキュメントに記載されています。当記事では、重要な要素のみを解説します。 参考 : Compute Engine の料金 参考 : VM インスタンスの料金 vCPU・メモリ料金 vCPU には コア数あたり 、メモリには GB あたり の単価が設定されており、利用料金は単価 × 稼働時間で計算されます。 稼働時間とは、 VM インスタンスが起動している時間 のことです。また VM を短時間起動すると、最低でも1分の課金が発生し、その後は 1秒単位 で課金されます。 有償の OS ライセンス料金 Compute Engine では、Windows Server や Red Hat Enterprise Linux（RHEL）など、有償のソフトウェアライセンスを含んだマシンイメージから VM を起動することができます。このような有償イメージは プレミアムイメージ と呼ばれています。 これらを選択して VM を構築した場合、マシンの稼働時間に応じてライセンス料金が課金されます。 参考 : プレミアム イメージ ディスク料金 Persistent Disk 、Hyperdisk、ローカル SSD は、いずれも 割り当てサイズ （GiB）に対して月額費用が発生します。 また、エクストリーム Persistent Disk や Hyperdisk Extreme、Hyperdisk Throughput など、IOPS やスループットを事前プロビジョンできるストレージタイプでは、これらの容量に対しても課金が発生します。 性能とコストは トレードオフ の関係にあります。コスト重視の場合は低性能なディスクを選択することで月額費用は抑えられますが、ディスクパフォーマンスは劣ります。 スナップショット・イメージ料金 ディスクのバックアップ機能を利用してスナップショットやマシンイメージを取得した場合も、サイズ（GiB）に応じた課金が発生します。 参考 : ディスク スナップショットの料金 参考 : マシンイメージ ネットワーク料金 課金対象 ネットワーク料金については、原則的に、 下り通信 （VM から出ていく通信）のデータ量に対して課金されます。 例として、VM で Web アプリケーションがホストされているケースを考えます。 ユーザーから Web アプリへの HTTP リクエストは、上り通信（VM の外から中へ入ってくる通信）であるため、課金されません。その反対に、Web アプリからユーザーへ返すレスポンスは、下り通信（VM の中から外へ出ていく通信）であるため、課金対象となります。 同様に、ユーザーからサーバーへのデータのアップロードは課金対象ではありませんが、逆にサーバーからユーザーがデータをダウンロードする場合は、課金対象となります。 下り通信は「外向き通信（Egress 通信）」、上り通信は「内向き通信（Ingress 通信）」と呼ばれることもあります。 参考 : ネットワーキングのすべての料金体系 VM 同士の通信 Google Cloud 内部の VM 間通信でも、VM 同士が異なるリージョンやゾーンに存在する場合は、 リージョン間・ゾーン間通信料金 が発生します。 一方で、同一ゾーン内の VM 同士の通信には料金は発生しません。 プレミアムティアとスタンダードティア VM を構築する際、使用するネットワークを、 プレミアムティア と スタンダードティア から選択することができます。 これらは VM が Google Cloud の外と通信する際に使用するネットワークの品質を示しています。前者のプレミアムティアがデフォルトであり、後者のスタンダードティアより若干料金が高くなりますが、 Google のバックボーンネットワークを利用するため、高品質で安定した通信が可能です。 参考 : Network Service Tiers の概要 外部 IP アドレス VM の内部 IP アドレスには料金は発生しませんが、外部 IP アドレスには料金が発生します。以下はいずれも2025年7月現在の、東京リージョンの料金単価です。 種類 料金 通常の VM にアタッチした外部 IP アドレス（静的/エフェメラル） $0.005 / 時間 Spot VM にアタッチした外部 IP アドレス（静的/エフェメラル） $0.0025 / 時間 アタッチされていないが予約された静的外部 IP アドレス $0.015 / 時間 参考 : VM から Google サービス 割引制度 スポット VM スポット VM （Spot VM）とは、Google Cloud のデータセンターで余剰の（売れ残っている）コンピュートリソースを割引価格で利用できる利用形態です。割引額は、マシンタイプごとに異なりますが、60～91%です。 スポット VM は安価である代わりに、Google Cloud 側の都合で処理がインタラプトされ、VM が プリエンプト 、すなわち停止されてしまう可能性があります。プリエンプト発生時は、 VM は停止または削除（事前指定の設定値に従う）されます。 スポット VM は永続的に稼働する VM ではなく、一時的に起動して並列処理を行うワーカーとしての利用や、オンデマンドに VM を起動するバッチ処理に適しています。 参考 : Spot VM スポット VM の料金は、需給状態に応じて30日に1回、変更される可能性があります。ただし、通常価格の60～91%の範囲で調整されます。現在の料金は、以下のページから確認可能なほか、Cloud Billing Catalog API 等から取得することができます。 参考 : Spot VM の料金 なお、スポット VM の前身機能として「プリエンプティブル VM」が存在していましたが、現在では利用は推奨されていません。 参考 : プリエンプティブル VM インスタンス 継続利用割引（SUD） 継続利用割引 （SUD、sustained use discounts）とは、VM の1ヶ月あたりの稼働時間が一定以上になりい、条件を満たした場合に適用される割引制度です。 ユーザーが何もしなくても、 VM の月の稼働時間が一定時間を超えると、自動で割引が発生します。 参考 : 継続利用割引 詳細は、以下の記事をご参照ください。 blog.g-gen.co.jp 確約利用割引（CUD） 確約利用割引 （CUD、committed use discounts）とは、1年間または3年間の継続利用をコミット（確約）することで割引が受けられる仕組みです。 前払いはできませんが、継続的な利用をコミットをしたうえで安価な月額で VM を利用できます。 参考 : Compute Engine の確約利用割引（CUD） 詳細は、以下の記事をご参照ください。 blog.g-gen.co.jp 応用編の記事 応用編の記事では、以下のトピックを扱っています。Compute Engine の全てを知るためには、応用編もご参照ください。 サービスアカウントとアクセススコープ Compute Engine へのサーバー移行 ロードバランシングと SSL/TLS インスタンスグループ オートスケーリング（Autoscaling） メタデータ スタートアップスクリプト、シャットダウンスクリプト Persistent Disk のパフォーマンス ログ管理 ライセンス 単一テナントノード GPU 高度なセキュリティ（Shielded VM、Confidential VM） 運用の自動化（VM Manager） blog.g-gen.co.jp 武井 祐介 (記事一覧) クラウドソリューション部クラウドエンジニアリング課。 Google Cloud Partner Top Engineer 2025 選出。 趣味はロードレースやサッカー観戦、ゴルフ、筋トレ。 Follow @ggenyutakei

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

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

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

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

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

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

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

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

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

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

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

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

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

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