こんにちは、@norryです。自分は九州は熊本からフルリモートで東京本社の株式会社G-genにジョインしています。 G-genはGoogle Cloudの専業ベンダーである事から、自らの実力向上の為Google Cloudの認定資格取得に取り組んでいます。 Googleの認定資格は KRYTERION で受験可能なのですが、国内ではあまり対応している試験会場がなく今回は福岡の試験会場で受験しました。 その際に受験会場周辺で少し迷ったので九州で唯一の会場ですので受験される人の参考になれば幸いです。ちなみに自宅からオンラインでの受験も可能なのですが気分転換も兼ねて今回は会場で受験しています。 Google Cloud認定資格とは 試験会場へのアクセス Google Cloud認定資格とは Google Cloudの認定資格とは Google Cloud の職務ベースの認定資格は、Google Cloud テクノロジーを使用した特定の職務の遂行能力を評価するものです。厳正に開発された業界標準の手法を使用して、各職務の知識、スキル、能力の評価が行われます。Google Cloud 認定資格は、個人のキャリア開発の促進と、高いスキルと実践力を備えたチームの構築に役立ちます。 とあります。 自分は今回は Professional Cloud Architect 試験を受験しました。AWSで言うところの Solutions Architect - Professionalにあたるでしょうか、Google Cloudのサービス全般的な内容が問われます。 Google Cloud 認定資格については、以下の当社記事もご参照ください。 blog.g-gen.co.jp 試験会場へのアクセス 電車で行く場合は地下鉄赤坂駅で下車してください。徒歩３分ほどになります。 試験会場へは15分前への入場になりますので余裕を持って試験会場の近くへ行きましょう。 幸いにも会場の近くにはカフェや喫茶店が多数ありますので試験勉強の仕上げに持ってこいです。 時間になりましたら会場へ向かうのですがこちらの建物が少し複雑で地図で書きますとこの場所になります。 自分は間違ってこの周辺をグルグルしてしまいました。 下の写真のラーメン屋さんから左折 ここが入り口です。 入り口入って「左側」のエレベーターで12Fまで上がってください、ここを間違って右側に乗ると12Fでぐるっと遠回りする事になります。 エレベーターをおりた右手に会場入口があります。 入って受付を済ませ試験です、出題数50問の制限時間120分でしたが60分ほどで終了し何とか合格しました。クラウド系資格全般そうなのですが「合格」「不合格」の表示が分かりにくくてドキドキします。 さて試験が終わったらご褒美に覚王山フルーツ大福を食べましょう〜 ※お店に撮影許可をいただいています 大福を食べた後は腹ごなしとお礼参りに福岡縣護国神社へ 以上福岡受験日記でした、皆さんも良い試験ライフを！ 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-genの杉村です。Google Cloud（旧称 GCP）のフルマネージドのデータウェアハウスである BigQuery には、パフォーマンス向上やコスト削減に当たり、 パーティション と クラスタリング という重要な概念があります。それぞれの仕組みや使い分けを解説していきます。 パフォーマンスのためのテーブル設計 パーティション パーティションとは 使用方法 パーティションフィルタ要件 メリット パーティションの分割基準 時間の列 取り込み時間 整数範囲の列 パーティションの管理 パーティションの上限と注意点 クラスタリング クラスタリングとは 使用方法 クラスタ化に指定する列 自動再クラスタリング パーティション vs クラスタリング パーティションとクラスタリングの違い パーティションとクラスタリングの使い分けと併用 パーティション・クラスターのレコメンデーション 参考情報 パフォーマンスのためのテーブル設計 BigQuery において、最適なパフォーマンスを出すためのテーブル設計として、最も重要なのが パーティショニング と クラスタリング です。 一般的な RDBMS（リレーショナルデータベースマネジメントシステム）では、テーブルに対してインデックスを作成することで、検索パフォーマンスを向上させます。BigQuery には検索インデックス（search index）機能があるものの、これは主に特定の文字列を特定のフィールドから高速に検索するために使用する機能であり、基本的には分析や可視化のパフォーマンス向上に寄与するものではありません。 blog.g-gen.co.jp 検索インデックスは、システムログの検索、セキュリティ監査などの文字列検索のパフォーマンスを向上させるために使います。一方で、当記事で紹介するパーティショニングやクラスタリングは、スキャン効率や速度、コストパフォーマンスを向上させるために有用です。そのため多くの機会で、パーティショニングやクラスタリングは、BigQuery のテーブル設計における基本的な考えであるといえます。 パーティション パーティションとは パーティション とは、 BigQuery の一つのテーブルを、特定の列の値を基準にして内部的に複数の部位に分割する機能です。これによりクエリ時にスキャンする範囲を狭め、パフォーマンス向上とスキャン料金の節約ができます。 参考 : パーティション分割テーブルの概要 分割基準として使う列をテーブル作成時に指定することで、パーティション分割されたテーブルを作成することができます。1つのテーブルには、パーティション列は1つしか指定できません。 パーティションで分割されたテーブル 使用方法 テーブル作成方法は以下のドキュメントの通りです。 参考 : パーティション分割テーブルの作成 例として、以下のような DDL で、パーティション分割されたテーブルを作成することができます。 CREATE TABLE mydataset.purchase_tran ( purchase_dt DATE , prod_id STRING, prod_name STRING, store_id INT64, store_name STRING ) PARTITION BY purchase_dt このように作成されたテーブルで以下のようにクエリを実行すると、 BigQuery は当該の値を含んだパーティションだけをスキャンします。 SELECT * FROM mydataset.purchase_tran WHERE purchase_dt = " 2025-04-01 " パーティションフィルタ要件 パーティション分割テーブルの作成時に、 パーティションフィルタ要件 （Partition filter requirements）を有効化することで、WHERE 句でパーティション列が指定されていないクエリを、エラーとして拒否することができます。 これを設定することで、テーブルの利用者は、パーティションによるスキャン範囲を指定したクエリしか投げられなくなりますので、テーブルに対する不用意なフルスキャンを予防することができます。 メリット パーティションが無い場合、BigQuery はテーブル全体をフルスキャンします。パーティションによる範囲スキャンは、フルスキャンに比べて大幅にスキャン範囲を節約でき、料金と時間の節約となります。 また前述のパーティションフィルタ要件を使えば、ユーザーが大規模なテーブル全体に対して誤ってクエリを実行する等の、費用の急増を防ぐ効果もあります。 パーティションの分割基準 時間の列 TIMESTAMP 型 、 DATE 型 、 DATETIME 型 のいずれかの列をパーティション列として指定可能です。 TIMESTAMP 列と DATETIME 列では、パーティションを時間単位、日単位、月単位、年単位のいずれかで作成できます。 DATE 列の場合、パーティションは日単位、月単位、年単位で作成できます。 いずれも、分割単位を指定しない場合、デフォルトは日単位となります。 以下は、DDL の例です。DATE 型の列をパーティション列に指定すると、デフォルトでは日単位での分割になりますが、以下の例のように DATE_TRUNC 関数を使って月単位で切り捨てることで、月単位の分割になります。 CREATE TABLE mydataset.newtable ( transaction_id INT64, transaction_date DATE ) PARTITION BY DATE_TRUNC(transaction_date, MONTH) OPTIONS ( require_partition_filter = TRUE ); 取り込み時間 取り込み時間をパーティション基準として選択すると、BigQuery がデータを取り込んだタイムスタンプに基づいてテーブルが分割されます。 分割粒度は、時間単位、日単位、月単位、年単位から選択できます。デフォルトは日単位です。 テーブル作成時には、 _PARTITIONTIME という疑似列（仮想列）をパーティション列として指定します。 以下は、DDL の例です。 CREATE TABLE mydataset.newtable ( transaction_id INT64 ) PARTITION BY _PARTITIONDATE 整数範囲の列 パーティション分割の基準列として、INTEGER 型の列を指定可能です。またこの場合、分割の開始値・終了値と分割の間隔を指定できます。 以下は、DDL の例です。 CREATE TABLE mydataset.newtable ( customer_id INT64, date1 DATE ) PARTITION BY RANGE_BUCKET( customer_id, GENERATE_ARRAY( 0 , 100 , 10 ) ); この例では customer_id 列でパーティショニングし、開始値 0、終了値 100、間隔 10 としています。 このように設定した場合、customer_id が 0 から 9 の行が最初の パーティションに入り、10 から 19 が次のパーティションに入ります。この処理が 99 まで続きます。この範囲外の値は、 __UNPARTITIONED__ という名前のパーティションに入ります。customer_id が NULL の行は、 __NULL__ という名前のパーティションに入ります。 テーブルにどんなパーティションが存在しているかは、テーブルのメタデータから確認できます。 参考 : パーティション分割テーブルの管理 - パーティション メタデータの取得 パーティションの管理 時間単位または取り込み時間で分割したテーブルの場合、パーティションの 有効期限 を設定できます。 指定した有効期限が過ぎたらデータは自動的に削除されます。このとき BigQuery のユーザーに割り当てれたリソースは消費されません。有効期限をうまく使うことで、ハウスキーピング用のジョブをユーザーが作成する必要がなくなります。 参考 : パーティション分割テーブルの管理 - パーティションの有効期限を設定する デフォルトのパーティション有効期限をデータセットで設定できるほか、テーブル単位で有効期限を設定することもできます。テーブルで有効期限が設定されている場合は、テーブルの有効期限が優先されます。 パーティションの有効期限はテーブル作成時に指定するほか、作成後にも変更できます。 パーティションの上限と注意点 1テーブルが持てるパーティション数には上限があり、 1テーブルにつき10,000パーティションまで です。従来は4,000が最大値でしたが、2024年5月29日のアップデートで10,000に変更されました。 これは、時間単位であれば 10,000 時間 = 約416日 = 約13ヶ月間であり、日単位での分割であれば 10,000日 = 約322ヶ月 = 約27年です。 パーティション数の上限に達すると、 ジョブがエラーとなります 。パーティションのデータのバックアップを取得する仕組みを用意したうえで、パーティションに有効期限を設けてデータが自動削除されるようにする等、運用上の考慮を検討する必要があります。 また「1 つのジョブで変更されるパーティションの数」や「1 日の取り込み時間パーティション分割テーブルあたりのパーティションの変更回数」「1 日の列パーティション分割テーブルあたりのパーティション変更数」などにも上限があります。バッチ処理がこれに抵触していないかは、十分注意する必要があります。 参考 : 割り当てと上限 - パーティション分割テーブル 以下は、10,001 個目のパーティションを追加しようとした場合のエラーメッセージです。 Resources exceeded during query execution: Table my-project:my_dataset.my_table will have 10001 partitions when the job finishes, exceeding limit 10000. If partitions were recently expired, it may take some time to be reflected unless explicitly deleted. パーティション上限を超えた際のエラーメッセージ また、1回のジョブで変更可能なパーティション数は4,000です。これを超えるようなクエリを発行した場合、以下のようなメッセージが表示されます。 Too many partitions produced by query, allowed 4000, query produces at least 10000 partitions クラスタリング クラスタリングとは クラスタリング とは、 BigQuery のテーブルの特定の列の値に基づいてテーブルのデータをソートし、内部的に近い位置に配置しすることで、フィルタや集計クエリを高速化する機能です。 テーブル作成時に、列をクラスタ化列として指定します。 クラスタリングを利用すると、指定した列の値に基づいて行がソートされるため、 WHERE 句でこの列に基づいてフィルタするクエリを投げた際、不要なデータのスキャンをスキップすることができます。また、クラスタ化した列で GROUP BY して集計するクエリの場合、行がソートされ近い位置に配置されているので、パフォーマンスが向上します。 参考 : クラスタ化テーブルの概要 クラスタは パーティションと併用する ことも可能です。クラスタリングとパーティショニングを併用すると、データはパーティション分割された後に、クラスタ化されます。 またクラスタ化列は、1つのテーブルで複数（最大 4 列まで）指定可能です。複数指定した場合、指定の順番が重要になります。まず最初に指定した列で行がソートされ、次にその中で2番めに指定した列でソート、次に3番目... というように、順番にソートされます。 クラスタ化されたテーブル 使用方法 クラスタリングされたテーブルを作成する方法は、以下のドキュメントのとおりです。 参考 : クラスタ化テーブルの作成と使用 例として以下のような DDL で、クラスタリングされたテーブルを作成できます。例では、パーティショニングも併用しています。 CREATE TABLE mydataset.purchase_tran_cls ( purchase_dt DATE , prod_id STRING, prod_name STRING, store_id INT64, store_name STRING ) PARTITION BY purchase_dt CLUSTER BY prod_id また、既存のテーブルをクラスタリングしたり、列の指定を変更することも可能です。 参考 : クラスタ化テーブルの作成と使用 - クラスタリング仕様を変更する クラスタ化に指定する列 クラスタ化に指定する列は、一意の値を多く含む（カーディナリティの高い）列が推奨されます。そのほうが、ソートによるスキャン範囲のスキップの効果が高く期待されるためです。 また、組み合わせて使われることの多い複数の列をクラスタ化すると効果が期待できます。先の記述の通り、順番に注意して、頻繁に WHERE で指定あるいは GROUP BY される複数列をクラスタ化列として指定すると、効果が大きくなります。 参考 : BigQuery 特集: ストレージの概要 参考 : BigQuery のクラスタリングで メンテナンスの手間を省いて クエリを高速化 自動再クラスタリング クラスタリングのメンテナンスは自動で行われます。データが新規で追加されたり、変更されたりした場合でも、自動で再クラスタリングが行われます。一般的なデータベース製品で必要とされる VACUUM といった処理は不要です。 再クラスタリングは、スロットなどのリソースが消費されることもなく、自動的かつ透過的に行われるため、ユーザーが意識する必要はありません。 パーティション vs クラスタリング パーティションとクラスタリングの違い パーティションとクラスタリングは併用できますが、どのようなケースでどちらを使えばいいのか、またどのような列を指定すればいいのか、使い分けに迷うときもあります。 パーティションとクラスタリングの違いは、以下のような点にあります。 パーティショニングでは実際のクエリ実行前に ドライラン でスキャン量の試算ができる（料金試算が可能）。一方のクラスタリングでは、試算はテーブル単位、パーティション単位で行われるためドライランに反映されず、実際のスキャン量は見積もりより小さくなる可能性がある 参考 : クエリの実行 - ドライラン パーティショニングでは有効期限の設定ができる パーティショニングでは分割粒度（時間・日・月・年・整数範囲）の選択ができる パーティショニングでは1つの列しか指定できない。クラスタリングでは4列まで指定できる パーティショニングでは特定の型の列しか指定できないが、クラスタリングには型の制限はない パーティションとクラスタリングの使い分けと併用 まずはパーティションを適用できる列があるかどうかを検討します。以下のような場合、パーティションの利用を検討します。 日付または時間 の型の列があり、 それらの列でフィルタ するクエリがある パーティションの 有効期限設定 を使ってテーブルのメンテナンスをしたい ドライラン でスキャン量（費用）の見積もりを行いたい 1個のパーティションあたりのデータ量が およそ 10 GB 以上 になる見込み（それ未満の場合はオーバーヘッドにより 逆に非効率 になる可能性があるためクラスタリングの使用を検討する） 上記の観点でパーティショニングを適用する列を検討をした後、以下のようにクラスタリングを適用する列を検討します。 よくフィルタ対象になる列だが、パーティショニングは既に別の列に適用している よくフィルタ対象になる列だが、データサイズが 10 GB 未満 になる見込み よくフィルタ対象になる列であり、値の カーディナリティが大きい （クラスタ化により速度改善の可能性あり） よくフィルタ対象になる列だが、パーティションを使うと分割粒度が小さくなりすぎ、1テーブルの 上限である 10,000 パーティション を超えてしまう テーブル内の大部分のパーティションが頻繁に（たとえば、数分ごとに）変更されるオペレーションがある。この場合、パーティションは避けてクラスタリングを利用する。1日あたりのパーティション変更数の上限があるため 結合に使われている列。クラスタ化によって 結合が高速化 する可能性がある（データが同じカラムナファイルに記録されスロット間のデータ移動が押さえられる） ただし 64 MB 未満のテーブルやパーティションではクラスタ化のメリットは小さい サイズがある程度大きいテーブルの場合は上記のように検討し、パーティションとクラスタリングを併用することで、スキャン料を節減してパフォーマンスとコスト効率を向上させられる可能性があります。 以下の公式ドキュメントも参照してください。 参考 : パーティション分割テーブルの概要 - クラスタ化テーブルとパーティション分割テーブルを組み合わせる 参考 : クラスタ化テーブルの概要 - クラスタリングを使用する場合 参考 : クラスタ化テーブルの概要 - クラスタ化テーブルとパーティション分割テーブルを組み合わせる パーティション・クラスターのレコメンデーション BigQuery には、過去のワークロードに基づいてテーブルの適切なパーティショニングやクラスタリングを推奨する機能があります。 Recommender API が過去30日間の実績を機械学習で分析し、テーブルの適切なパーティショニング・クラスタリング設定を提示します。対象テーブル、対象列、またどのくらいのスロット時間が節約できるかの見込みが表示されます。 推奨の対象となるテーブルは「パーティショニング無し・クラスタリング無し」「パーティショニング有り・クラスタリング無し」のテーブルです。 一方で 10 GB 以下のテーブルや既にパーティションとクラスターを両方設定済みのテーブル、また過去30日以内に読み取りされていないテーブルなどは対象外となります。 推奨はコンソール、gcloud、REST API で確認可能です。コンソールでは、画面右上の電球マークから確認できます。 参考 : パーティションとクラスタの推奨事項を管理する 参考情報 以下の公式記事では、パーティションやクラスタリングの仕組みが詳細に解説されていますので、是非参考にしてください。 参考 : BigQuery 特集: ストレージの概要 参考 : BigQuery のクラスタリングで メンテナンスの手間を省いて クエリを高速化 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさんこんにちは。G-genの鈴木ことすずたつです。 Google Workspaceにおいてオーナー権限というのをご存知でしょうか？ その名の通り、ファイルやフォルダのオーナー権限になるのですが、例えばそのオーナーがGoogle Workspaceから削除された場合など、オーナーが作成したドキュメントも一緒に削除されてしまいます。また、ファイルの変更履歴なども消えてしまうことがあるので、確実に実施する方法としては”オーナー権限を別のユーザーに移す”という作業が必要になります。 例えば 退職者が出た場合 等には必要になるので、ご活用ください。 それではその方法を簡単に説明していきます。 ユーザーが操作可能な場合(退職前など) 一括でオーナー権限を付け替える方法(退職後など) ユーザーが操作可能な場合(退職前など) まだユーザーが退職しておらず、またファイル数も少ない場合には以下の手順で簡単に実施可能です。 ファイルを右クリック＞共有のメニューから編集者のプルダウンにて オーナー権限の譲渡 にて操作可能です。 ファイル単位の譲渡方法 ただこちら、一個一個実施するのは相当めんどくさいですよね。退職者がでた。ということはおそらくファイルも多く存在すると思いますし。 では次項にて 一括で譲渡する方法 をお試しください。 一括でオーナー権限を付け替える方法(退職後など) こちらの方法は管理者のみが実行できる方法になるのですが、管理メニューから以下のように選択いたします。 「アプリ」＞「Google Workspace」＞「ドライブとドキュメント」＞「オーナー権限の譲渡」 オーナー権限の譲渡 ここで譲渡前のユーザー、及び譲渡後のユーザーを入力することで、簡単に一括でオーナー権限を譲渡することが可能です。 今回は佐藤さんから鈴木さんに譲渡してみましょう。 オーナー権限の譲渡操作(1) オーナー権限の譲渡操作(2) 上記操作を実施すると、以下の画面のように、佐藤さんが保持していたオーナー権限が、鈴木に譲渡されている。ということがわかるかと思います。 譲渡後のオーナー権限 ただしここで注意なのが本操作が可能なのは 同じ組織内で管理されているユーザーのみ になりますので、別組織等に共有しているものに関してはオーナー権限を一括で変更することはできません。 こちらに関しては引き続きGoogleサポートを利用しつつ調査していきたいと思います。 今回の記事はライトにここまでとさせていただこうと思います。 追伸：11月29日にGoogle Cloud - Professional Collaboration Engineerを取得させていただきました。この件に関してはまた何かの機会で。 Professional Collaboration Engineer 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-gen の杉村です。Google Cloud (旧称 GCP) のセキュリティサービスである Cloud IDS について解説していきます。 Cloud IDS とは アーキテクチャ 構成図 IDS エンドポイント Packet mirroring policy 脅威検知 Application-ID シグネチャーセット 重要度 シグネチャーの更新頻度 料金 上限 セットアップ セットアップ手順 動作確認 Cloud IDS Cloud IDS とは Cloud IDS とは Google Cloud (旧称 GCP) のセキュリティサービスであり、Google Cloud 上のネットワークにおける侵入、マルウェアによる通信、コマンド&コントロール通信等を検知する仕組みです。 IDS とは Intrusion Detection System の略語であり 侵入検知システム のことです。主にネットワークトラフィックを検査することで有害なアクセスを検知することを目的とした仕組みを指します。しばしば IPS/IDS のように侵入 防止 システムとセットで語られることが多いものです。 そのため Cloud IDS で提供されるのは侵入の 検知だけ であり侵入を 防ぐ機能はありません 。 Cloud IDS は、VPC からトラフィックをミラーリング (複製) し Palo Alto Networks の脅威検知技術 で検査します。 また、利用時間と処理データ量に応じて料金が発生します。全トラフィックを検査することも、サブネット単位なインスタンス単位で検査対象パケットを指定することも可能です。 参考 : Cloud IDS の概要 アーキテクチャ 構成図 Cloud IDS のアーキテクチャは、以下のように図示されます。 Cloud IDS のアーキテクチャ IDS エンドポイント Cloud IDS では IDS エンドポイント というリソースを作成します。 IDS エンドポイント自体はゾーンリソースですが、1つ作れば同じリージョン内の全ゾーンのトラフィックを検査できます。 IDS エンドポイントは Private services access の機能を使って、ユーザの VM と Google が管理する検査用 VM の間を接続します。 パラメータとして以下を持ちます。 最小のアラート (アラートとして扱う最小の重要度。 Critical > High > Medium > Low > Informational) トラフィックログ (ON or OFF) トラフィックログ は、検知された脅威とは別に、ミラーリングしたトラフィックのログを JSON で生成します。 大量のログが Cloud Logging へ送信され利用料金が大きくなることが想定されますので、特に必要な理由がある場合を除いて、オフとすることが望ましいでしょう。 Packet mirroring policy IDS エンドポイントを作成すると Packet mirroring policy をアタッチする必要があります。 このポリシーが、どのトラフィックを検査対象とするかを決定します。 Packet mirroring policy では以下のパラメータを持っています。 ポリシーの状態 (有効 or 無効) ミラーリングの対象 (サブネット単位 or ネットワークタグ単位 or インスタンス単位) ミラーリングのフィルタ (プロトコル / IP レンジ / トラフィックの方向) 脅威検知 Application-ID 検査されるネットワークトラフィックは Palo Alto Networks がメンテナンスする Application-ID (App-ID) という ID により、どのアプリのトラフィックであるかが判断されます。 脅威検知された際、そのトラフィックが何のアプリケーションにより生成されたものなのかが、この App-ID によって分類されます。 App-ID は週次程度の頻度で更新されていき、 Cloud IDS のユーザーが意識しなくとも、自動でアップデートされていきます。 シグネチャーセット Cloud IDS は シグネチャー によりトラフィックを検査します。 例として、以下のような挙動となります。 バッファオーバーフロー、コードの不正実行、その他の脆弱性を突いたアクセスなどを検知 スパイウェアからコマンド & コントロール (C&C) サーバへの通信を検知 重要度 検知された脅威は 5段階に分類 されます。 IDS エンドポイントの設定でどのレベルまでを検知対象とするかを指定できます。 重要度 説明 Critical 深刻。 サーバに深刻なダメージを与えるもの。またエクスプロイトコードが広く知られている、攻撃者が攻撃対象に関して認証情報や深い情報を必要としないなど、危険度が高い脅威 High 高。危険ではあるものの、エクスプロイトの難易度が高い、特権昇格に繋がらない、攻撃対象となり得る範囲が狭いなどの理由で "深刻" には分類されない脅威 Medium 中。インパクトは中程度で、攻撃者が同じローカルネットワークにいる必要があったり、標準的でない設定に対してのみ危険であったり、限定的な対象に対してのみ危険な脅威 Low 低。インパクトが小さく、ローカルネットワークもしくは物理的なアクセスが可能な場合のみ危険となりえるなどの理由で、警告レベルとされる脅威 Informational 情報レベル。直ちに脅威にはなり得ないが潜在的に危険な、疑わしい挙動など シグネチャーの更新頻度 App-ID やシグネチャーは、ユーザーが意識する必要なく、 自動的にアップデート されます。 Palo Alto Networks によるアップデートは、日次で Cloud IDS に反映されます。反映の遅れは、最大でも 48 時間とされています。 料金 Cloud IDS の料金は エンドポイントの存在する時間 単位の課金 + 処理したトラフィックの GB 単位の課金 の2軸となっています。 2021/11時点で料金は以下のようになっています。 エンドポイント時間あたり: $1.50 / hour 処理データ量あたり: $0.07 / GB 最新の料金は必ず以下のドキュメントを参照してください。 参考: Pricing 上限 Cloud IDS には以下の上限 (Quotas) が設定されています。 コンソールの 割り当て 画面から緩和リクエストを送信することが可能です。 ゾーンあたりの IDS エンドポイント数: デフォルト 10 分あたりの API リクエスト数: デフォルト 1,200 セットアップ セットアップ手順 セットアップ方法は以下のドキュメントを参考にしてください。 cloud.google.com 大まかな流れは以下のとおりです。 IDS エンドポイントの作成時に待ち時間が 10 分ほどありますが、全体としては 30 分程度で構築することができます。 Private service access を作成 (Cloud SQL などで既存のものがあれば利用可能) IDS エンドポイントを作成 Packet mirroring policy を作成 動作確認 Google Compute Engine (GCE) のコンソールで対象 VM を選択し オブザーバビリティ タブを選択すると対象 VM の Cloud Monitoring メトリクス (指標) を見ることができます。 その中に Packet Monitoring という項目があります。 ここを見ると、対象 VM からパケットが IDS エンドポイントを通じてミラーリングされていることが分かります。 パケットミラーリングが有効化されている また、脅威が確実に検知されることを確かめるため、以下のコマンドを VM 上で実行しましょう。 curl http://example.com/cgi-bin/../../../..//bin/cat%%20/etc/passwd しばらくすると Cloud IDS のコンソール画面で検知が High として脅威されていることが表示されます。 対象アラートをクリックすると、詳細を表示することができます。 テストで実行した curl が検知された 参考: Troubleshooting 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは株式会社G-genの渡邉（@norry）です。 Google Workspace (以下、GWS)を利用するにあたって組織の端末に対してセキュリティーをどう担保していくのか？気にされるのではないでしょうか、その時にGWSだけでどの程度管理可能なのかも気になる部分かと思います。 今回は利用人数1〜300名までのBusinessエディションの各プランで「これぐらいの管理がしたいからこのプランが必要」と判断する時にお役に立てれば幸いです。 各プランのおおまかな全体比較はこちらを参考にしてください blog.g-gen.co.jp どのプランがオススメか Business Starter及びBusiness Standardがオススメなケース Business Plusがオススメなケース 上記だけでは要件を満たさないケース 混同しがちなキーワード GWS上のデバイス管理のコンソールで良く目にするキーワード Businessエディション、デバイス管理の各プラン機能比較 機能比較の補足 基本のエンドポイント管理 セキュリティ設定 デバイスの管理 アプリの管理 デバイスの詳細 高度なエンドポイント管理 セキュリティ設定 デバイスの管理 アプリの管理 デバイスの詳細 Google Workspaceを導入するなら株式会社G-genにご相談ください。 どのプランがオススメか デバイス管理のBusinessエディションでの各プラン機能比較はこちらのようになります。 Business Starter Business Standard Business Plus 基本のエンドポイント管理 ✔ ✔ ✔ Android アプリの管理 ✔ 高度なエンドポイント管理 ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ デバイス監査ログ ✔ 使われていない会社所有デバイスに関するレポート ✔ 会社所有の Android デバイス ✔ 上記を参考にしながら最初にオススメのプランをご紹介いたします。 Business Starter 及び Business Standard がオススメなケース デバイス管理をしない、または最低限の管理だけを考えている方におすすめです。 後述しますがデバイス管理だけを考慮した場合、「Business Starter」「Business Standard」には差異がありません。 基本的なモバイルデバイス管理 が利用可能です 主な機能としてパスコード使用の必須化、デバイスの一覧取得、Google アカウントのリモート ワイプ、Android デバイスへのアプリケーションのリモート インストールが可能です。 基本的な管理のデバイス情報画面 また、ユーザーが Windows、Mac、Chrome、Linux デバイスのどのブラウザを使用して GWSにログインした場合でも、そのデバイスがエンドポイント管理に自動登録されます。 程度として、ユーザーに制限をかけたくない、どんなモバイルデバイスがアクセスしたのかな？あたりを知ることが出来ればOKでしたら、こちらを選択ください。 Business Plus がオススメなケース Andoroid、iOSのBYODデバイスに対してより細かく制御、Windows端末も管理対象にしたい場合にBusiness Plusプランがおすすめです。 Business Plusプランでは 高度なモバイルデバイス管理 が利用可能になります。 Android では仕事用プロファイルで個人データを仕事用データから分離して、プライバシーを守ることができます。iOS デバイスと Android デバイスで仕事用アプリの使用を許可、管理する事が可能です。 Windows デバイス管理ではGWSアカウントでのWindowsログインやデバイスからのデータのワイプ（消去）、デバイスの詳細情報を表示させる事が可能となっています。 上記だけでは要件を満たさないケース そもそも許可された端末以外はGWSにアクセスさせたくない場合は他の方法もご検討ください。 会社所有以外の端末からアクセスした時に管理者の承認を必須にする場合、Enterpriseエディションやその他のMDMツールをご検討ください。 基本的、高度なモバイルデバイスではユーザーは端末で一度はGWSにログインする事が出来てしまいますが、ログイン後に管理コンソールから状況の確認やワイプの操作は可能です。 混同しがちなキーワード GWS上のデバイス管理のコンソールで良く目にするキーワード GWS管理コンソール プランによってモバイルデバイスにはポリシー適用出来るがエンドポイントには出来ないみたいな事があります。検討しているうちにどの種類の端末なのか分からなくなってくるのでよく使うワードだけまとめておきます。 モバイルデバイス Android、iOS、Google sync デバイス（所謂携帯端末） エンドポイント 管理コンソール上ではパソコン(Windows、Mac、Linux)とスマートホームデバイス、プラン説明の時には端末全般を指す事が多い Chromeデバイス Chromebook とその他の Chrome OS 搭載デバイス 管理対象ブラウザ 各OS（Windows、Mac、Linux）から登録トークンを使用して登録された Chromeブラウザ のこと またGoogleエンドポイント管理のデバイス要件は こちら になります Businessエディション、デバイス管理の各プラン機能比較 機能比較の補足 先にオススメプランの結論はお伝えしましたが、もう少し機能について詳しく知りたい方向けに補足をさせていただきます。 再度になりますが、デバイス管理のBusinessエディションでの各プラン機能比較はこちらのようになります。 Business Starter Business Standard Business Plus 基本のエンドポイント管理 ✔ ✔ ✔ Android アプリの管理 ✔ 高度なエンドポイント管理 ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ デバイス監査ログ ✔ 使われていない会社所有デバイスに関するレポート ✔ 会社所有の Android デバイス ✔ 事項から補足していきます。 基本のエンドポイント管理 基本のエンドポイント管理 はGWSのBusiness StarterプランからBusiness Plusまで全てのプランで利用可能です。 また、基本のエンドポイント管理には以下の機能が含まれます。 セキュリティ設定 セキュリティ設定ではモバイルデバイスに対してパスコードの使用を必須化や、WindowsPCにエージェントをインストールする事によってGWSのアカウントでログインする事が可能になります。 基本的なパスコードの適用（モバイル） Windows 用 Google 認証情報プロバイダ デバイスの管理 デバイスの管理ではモバイル デバイスからユーザーのアカウントをワイプや、自組織のChromeを利用しているユーザーをリモートでログアウト、デバイス上のパソコン版ドライブに関する情報を確認などが可能です。 基本的なモバイル デバイス管理 パソコンの基本管理 エンドポイントの確認 パソコン版ドライブ デバイスのブロック アカウントのリモートワイプ（モバイル） リモート ログアウト（パソコン） アプリの管理 アプリの管理では管理者が設定したアプリをユーザーが見つけてインストールする事ができ、仕事用または学校用としてアプリ管理できます。 ただしBusiness Starterでは管理対象アプリを自動インストールしたりブロックしたりする機能はありません。 一般公開および限定公開の Android アプリの選択 デバイスの詳細 デバイスの詳細ではモバイルデバイス、エンドポイントの基本的な情報（種類、オペレーティングシステム、デバイスID）、管理対象デバイスの数の推移などが確認出来ます。 基本的な モバイル デバイス と エンドポイント の詳細 デバイス レポート 会社所有のパソコンのインベントリ 高度なエンドポイント管理 高度なエンドポイント管理 はBusiness Plus以上のプランで利用可能です。 高度なエンドポイント管理では端末の監視だけでなく制御をするMobile Device Management (MDM)の要素が加わってきます。 機能としては以下のようになります。 セキュリティ設定 セキュリティーポリシーによるカメラの使用許可の制御や、AndroidでBYODを実施する場合に会社利用のアプリケーションを別ける 仕事用プロファイル を利用可能です。 標準型と強化型のパスコードの適用 モバイル デバイスのセキュリティ ポリシー Android の仕事用プロファイル ネットワーク管理 （モバイル） デバイスの管理 詳細管理により、ロック画面通知などのモバイル デバイス機能の制限、デバイスの暗号化の強制、Android デバイス / iPhone / iPad 上のアプリの管理、デバイスからのデータワイプを行えます。 iPhone / iPadを詳細管理するには Apple プッシュ証明書 を設定しましょう。 モバイルの詳細管理 Windows デバイス管理 * デバイスの承認 デバイスのリモートワイプ アプリの管理 一部の Android アプリでは 管理対象アプリ として設定を保存する事が可能で、例えばWi-Fi に接続されているときにのみデータを同期するかどうかの制御が可能です。 iOS アプリの管理 限定公開の Android ウェブアプリ モバイルアプリを個別に配布する † Android アプリの設定 デバイスの詳細 デバイスのデバイスIDだけでなくシリアル番号などの取得などより細かい部分の情報も取得する事が可能です。 会社所有のモバイル デバイスのインベントリ モバイル デバイスの詳細レポート デバイス管理については機能も多くプランによっての違いが分かりにくい部分があるかもしれません そんな時は弊社にお気軽にお声がけくださいね。 Google Workspaceを導入するなら株式会社G-genにご相談ください。 株式会社G-genではGoogle Workspace / Google Cloud（GCP）を5%割引でご提供しております。 g-gen.co.jp また、Google Workspace / Google Cloud（GCP）/ Chrome book の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 お問い合わせはこちらから docs.google.com

G-gen の杉村です。Google Cloud (旧称 GCP) のマネージドな DNS サービスである Cloud DNS で、先日困ったことが発生しました。同じことが起きたときに誰かの助けになるよう、顛末と解決法を記載します。 やりたかったこと エラーメッセージ 解決方法 注意点 やりたかったこと Google Cloud (旧称 GCP) のフルマネージドな DNS サービスである Cloud DNS で、あるドメインを管理しています。これを仮に example.com とします。 ある日、とある理由からパブリックゾーンである example.com を別の Google Cloud プロジェクトの Cloud DNS に移動する必要性が出てきました。 当初考えた移行方法は、以下の通りです。 移行先プロジェクトにパブリックゾーン example.com を作成する 移行元ゾーンから gcloud コマンドによりレコードの内容を エクスポート し、移行先ゾーンに インポート する お名前ドットコム側に、移行先ゾーンの新しい NS レコードを登録する エラーメッセージ しかしながら、先ほどの手順 1. で移行先プロジェクトにパブリックゾーンを作成しようとしたところ、以下のようなエラーメッセージが出てしまいました。 http://www.google.com/webmasters/verification/ で「(ドメイン名)」ドメイン（または親）の所有権を確認してから、もう一度お試しください エラーメッセージ このエラーですが、以下のような条件のときに出てしまうようです。 既に Cloud DNS あるいは Google Domains でドメイン名の DNS を管理している この状態で Cloud DNS に同じドメイン名のパブリックゾーンを作成する うっかり英語版のエラーメッセージを取ることを失念していたのですが、 この公式ドキュメント に記載されている Verify ownership of the example.com domain (or a parent), and then try again. に該当しているようです。 解決方法 このエラーメッセージは、ドメイン名の悪用を防止するために Google の DNS で既に管理中のドメイン名について、パブリックゾーンが作成されたときに Google 側がドメインの所有権を確認するために出すメッセージです。 エラーメッセージにある http://www.google.com/webmasters/verification/ にアクセスし Google の ウェブマスター セントラル にてドメイン名を登録します。 ウェブマスター セントラル は Google 検索結果の順位の監視、管理、改善などのために Google によって提供されている Google Search Console の一部です。 ウェブマスターセントラル プロパティを追加 を押下してドメイン名の登録を進めます。 ドメインの所有権の確認には、 Google の指定する HTML ファイルを同ドメインを持つウェブサイトにアップロードするなどの方法もありますが、ドメインのゾーンに TXT レコードや CNAME レコードを追加する方法が選択できます。 ドメイン名の所有権の確認 指示された TXT レコードを移行元ゾーンに登録して所有権を確認したところ、それ以降は移行先プロジェクトに同じドメイン名でパブリックゾーンを作成することが可能になり、無事 DNS ゾーンを移行することができました。 注意点 一連の作業は、同じ作業者の Google アカウントで実施する必要があります。 ドメイン名の所有権の確認は Google アカウントに紐付いているようですので、所有権を確認された Google アカウントでゾーンの作成等を行う必要があります。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

今回は皆さんご存知Google Workspace(旧G Suite)のオススメプラン比較になります。 個人でGmailは使ってるけど会社やチームで利用した事は無い、検討しているけどどのプランを選べばいいのかな？BusinessやEnterpriseってあるけど各エディションの違いって何だろう？そういう方へご参考になれば幸いです。 Google Workspace 概要 エディション Business と Enterprise の比較 アカウント数上限 主要な機能比較 Business エディション内の比較 比較表 Businessプランの選び方 Business Starter を選択するケース Business Standard を選択する場合 Business Plus を選択する場合 Google Workspace の導入 概要 Google Workspace の 公式サイト には「あらゆる働き方に対応する生産性向上とコラボレーションのツール。」とあり、また従業員の生産性 = チーム x 会社の文化 = コミュニケーション + コラボレーションと言い換える事が出来ます。 その組織のコミュニケーションとコラボレーションを下支えし促進するツールが Google Workspace です。 Google Workspace の特徴として各ツールが独立して存在するのでは無く、チームの力を最大化する為に各々のツールが密に連携している事にあります。 例えば通常はチャットとドキュメント作成は別々の会社のツールを利用している場合があるでしょう、Google Workspaceではチャットやビデオ会議などでコミュニケーションを取りながらシームレスに資料作成をする事が可能です。 G-gen 社は、全員フルリモートで勤務しています。PC 端末は Chromebook、ツールとして Google Workspace を使って仕事をしています。リクルートの面においてもこういった働き方がアピール出来るというのは企業にとって大きなアドバンテージになるのではないでしょうか。 Google Workspace の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp エディション 以下は、公式のプラン・料金ページです。 workspace.google.co.jp エディションを大きく分けると Business と Enterprise に分かれます。Enterprise エディションは Business エディションの上位エディションです。 Business と Enterprise の比較 アカウント数上限 まずは Businessの最上位エディションである Business Plus と Enterprise を比較してみます。まずは一番分かりやすい点として、アカウント数の上限があります。 　 Business Plus Enterprise 利用可能人数 300人まで 無制限 上記では Enterprise エディションはひと括りになっていますが、実際には Enterprise Essentials 、 Enterprise Standard 、Enterprise Plus** に分かれています。 Google Workspace を利用する人数が 300名以上でしたらEnterpriseを利用 することになります。 また300名以下の場合でも、PC 端末やスマートフォンを管理下に置いて監視や制限をかけたい場合にも Enterprise が検討対象になります。 主要な機能比較 参考として Business エディションの最上位プランである Business Plus と Enterprise の各プランでの、主な機能比較を記載します。 2011年11月現在の情報ですので、最新情報は以下の公式ドキュメントをご参照ください。 参考 : Google Workspace の各エディションの比較 Business Plus Enterprise Essentials Enterprise Standard Enterprise Plus 基本情報 月額料金（1ユーザーあたり※税別） 2,040円 お問い合わせ お問い合わせ お問い合わせ ユーザー上限数 300人 指定なし 指定なし 指定なし ストレージの容量 5 TB *5人以上のユーザーが必要 （4人以下の場合は１TB） 1TB 必要に応じて拡張可能 必要に応じて拡張可能 メール Gmail ✔ ✔ ✔ IMAP クライアントと POP クライアント ✔ ✔ ✔ Google Meet 会議あたりの参加者数の上限 250 150 250 250 ドメイン内および信頼できるドメインのライブ ストリーミング 1万人 10万人 Google Chat Chat でのファイルの共有を管理する ✔ ✔ ✔ Chat とサードパーティ製アーカイブ ソリューションとの連携 ✔ ✔ Google グループ グループ メンバーを精査する ✔ ✔ グループ メンバーを制限する ✔ ✔ 動的グループ（メンバーシップを自動的に管理） ✔ ✔ ネストしたグループのメンバーを確認（間接的なメンバー） ✔ ✔ セキュリティと データ保護 信頼できる外部ドメインとの連携 ✔ ✔ ✔ データ損失防止（DLP） ✔ ✔ ユーザーとデバイスの状況に基づくアクセス制御 ✔ ✔ Google サービスのセッション継続時間を設定する ✔ ✔ ✔ Cloud Identity Premium ✔ ✔ セキュリティ センター: セキュリティ ダッシュボード ✔ ✔ セキュリティ センター: セキュリティ調査ツール ✔ ✔ セキュリティ センター: セキュリティの状況ページ ✔ ✔ Fundamental データ リージョン ✔ ✔ Enterprise データ リージョン ✔ クライアントサイド暗号化（ベータ版） ✔ 移行プロダクト HCL Notes から移行する ✔ ✔ ✔ レポートと監査ログ ドライブの詳細な監査とレポート ✔ ✔ ✔ BigQuery へのレポートのエクスポート ✔ ✔ 管理アクティビティのアクセスの透明性ログ ✔ ユーザーに関するワーク インサイト レポート ✔ サードパーティ製 アプリとの連携 セキュア LDAP: LDAP ベースのアプリやサービスを接続する ✔ ✔ ✔ パスワードが保管されたアプリへのアクセスを管理する ✔ ✔ デバイス管理 モバイルアプリを個別に配布する ✔ ✔ ✔ デバイス監査ログ ✔ ✔ ✔ 使われていない会社所有デバイスに関するレポート ✔ ✔ ✔ 会社所有の Android デバイス ✔ ✔ ✔ 会社所有の iOS デバイス ✔ ✔ Windows デバイス管理 ✔ ✔ iOS データの保護 ✔ ✔ デバイスのリモートワイプ（Windows） ✔ ✔ モバイル デバイスの証明書 ✔ ✔ 管理ルール ✔ ✔ ドライブ ドキュメントエディタ コネクテッド シート ✔ ✔ ✔ 組織のブランディング（カスタム テンプレート） ✔ ✔ ✔ Chrome ブラウザでドライブのファイル候補の使用を許可する ✔ 前述のとおり Business Plus でも主要な機能はサポートされていますが、ライブストリーミングやデバイス制御や管理、レポーティングと言った機能は利用出来ません。 また Enterprise Essentials は「300名以上で Google Workspace を利用したいが、メールシステムは他に持っているため直ちに移行することは難しい」「まずはコミュニケーション（Google Chat）やコラボレーション（ドライブ、ドキュメントエディタ）だけ利用したい」といったユースケースでおすすめです。HCL Notes からの移行が含まれているのも Enterprise ならではと言えるでしょう。 Enterprise のエディションに関しては検討すべき要件も多いため、ぜひ当社までご相談ください。 g-gen.co.jp Business エディション内の比較 比較表 次に Business に分類される3つのエディション Business Starter 、 Business Standard 、 Business Plus を比較します。 Business Starter Business Standard Business Plus 基本情報 月額料金（1ユーザーあたり※税別） 680円 1,360円 2,040円 利用可能人数 1〜300名 1〜300名 1〜300名 ストレージ容量 30GB 2TB 5TB 24時間365日の電話サポート ✔ ✔ ✔ コアサービス Gmailとカレンダー ✔ ✔ ✔ Cloud Searchによるドメイン内検索 ✔ ✔ Google Vault ✔ Google Chat ✔ ✔ ✔ ドライブと ドキュメント ドキュメントの作成 ✔ ✔ ✔ チーム向け共有ドライブ ✔ ✔ ✔ Google Meet 会議あたりの参加者数の上限 100名 150名 250名 会議の録画とドライブへの保存 ✔ ✔ ノイズ キャンセル ✔ ✔ ブレイクアウト ルーム ✔ ✔ セキュリティと データ保護 信頼できる外部ドメインとの連携 ✔ ✔ データリージョンの選択 ✔ ✔ デバイス管理 基本のエンドポイント管理 ✔ ✔ ✔ 高度なエンドポイント管理 ✔ モバイルアプリの個別配布 ✔ Businessプランの選び方 Business Starter を選択するケース まずは少人数（10名以下）でコストを抑えて Google Workspace を使った働き方にチャレンジしたい場合にオススメします。 主要な機能であるドキュメント作成、メール、カレンダー、ビデオ会議、チャットなどを利用する事が出来ます。 例えば全社に導入する前に少人数でテスト的に利用してみるのも良いでしょう。 Business Standard を選択する場合 より共同作業（コラボレーション）を促進し、生産性向上をはかりたい場合にオススメします。 Business Standard からはストレージの容量が一気に1ユーザーあたり２TBまで増えます。 またビデオ会議では「会議の録画」「ノイズキャンセル」「ブレイクアウトルーム」など、オンライン会議だからこそのコラボレーション機能が強化されます。 また同一ドメイン内の Gmail、ドライブ、ドキュメント、カレンダーなどに含まれるデータを包括的に検索し提案する「Cloud Search」を利用する事が可能となります。 Business Plus を選択する場合 大容量のストレージと更にセキュリティを高めたい場合にオススメします。 Business Plus ではストレージの容量が1ユーザーあたり５TBになります。 さらに Business Standard の機能に加えて Google Workspace のあらゆるデータの保持、検索、書き出しを行うことができる情報開示・ガバナンスの為の「Google Vault」、エンドポイント管理などよりセキュリティに重点を置いた機能が強化されます。 安全に Google サービスを活用したい場合にはぜひ活用ください。 Google Workspace の導入 Google Workspace を導入するなら株式会社G-genにご相談ください。Google Workspace を使った働き方に変えると本当に組織のコミュニケーションとコラボレーションのあり方が変わって、驚くはずです。 この感動をより多くの人に体感してもらいたいですね。 株式会社 G-gen では Google Workspace / Google Cloud (旧称 GCP) を5%割引でご提供しております。 g-gen.co.jp また Google Workspace / Google Cloud / Chromebook の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-genの杉村です。 Cloud Logging は Google Cloud（旧称 GCP）上のシステム等が生成したログを収集・保管・管理する仕組みです。基本的な概念や仕組みを解説していきます。 Cloud Logging 概要 Cloud Logging とは 対象のログ ログの保存先 Cloud Logging が扱うログ プラットフォーム ログ、コンポーネント ログ 監査ログ ユーザー作成のログ マルチクラウドとハイブリッド クラウドのログ 料金 Cloud Logging の料金 最初から存在するログバケットの料金 取り込み料金の節約 ログの閲覧 閲覧方法 クエリ言語 インデックス ログの閲覧可能範囲を定義する ログビュー ログスコープ ログルーティングとログの保存 ログルーティングとは シンクとは 初期設定で存在するシンクとログバケット 書き込み ID プロジェクトをまたいだログの集約 別プロジェクトのストレージにログを送る 組織全体でログを集約する 集約シンクの種類 ログ監視 ログベースの指標 ログベースのアラート Log Analytics Log Analytics とは 利用方法 BigQuery データセットとのリンク ユースケース 制限 Log Analytics の料金 サービス間連携 Cloud Run functions のログ Compute Engine VM（Windows）のログ Tips Cloud Logging 概要 Cloud Logging とは Cloud Logging （旧称 Stackdriver Logging）は Google Cloud 上のシステム等が生成したログを収集・保管・管理する仕組みです。 各 Google Cloud サービスが出力するログは自動的に Cloud Logging に集約されます。また、Cloud Logging の Web API やエージェントソフトウェアを通じて、任意のログを収集することもできます。 収集されたログは ログバケット と呼ばれるストレージで保管され、期限が過ぎたら廃棄する等の設定を簡単に行うことができます。ログバケットの他にも、Cloud Logging や BigQuery など他のストレージにログを転送することも容易です。 ログは Web コンソールである ログエクスプローラ で閲覧・クエリすることができます。さらに、指定の文字列がログに出力された際にアラートを発報する設定も可能です。 対象のログ Cloud Logging で収集・管理可能なログには、以下の種類があります。 参考 : Cloud Logging の概要 - ログのカテゴリ 種別名 説明 プラットフォームログ BigQuery や Cloud Run 等、ほとんどの Google Cloud サービスのログ コンポーネントログ Google が提供するソフトウェア コンポーネントが生成するログ。Google Kubernetes Engine（GKE）の管理機構が出力するログなど 監査ログ Cloud Audit Logs やアクセスの透明性ログ（Google サポート等がユーザのコンテンツにアクセスした際に出るログ） ユーザー作成のログ ユーザーのアプリケーションなどによって出力したログ。エージェントや API 経由で収集 マルチクラウドとハイブリッド クラウドのログ Microsoft Azure や Amazon Web Services（AWS）から取り込んだログやオンプレミスから取り込んだログ ログの保存先 Cloud Logging の保存先ストレージは以下から選択できます。 ログバケット Cloud Storage バケット BigQuery データセット Pub/Sub トピック Splunk 他の Google Cloud プロジェクト ログバケット は Cloud Logging 独自の専用ストレージです。Cloud Storage バケットと名称が似ていますが、 全く別のもの です。ログバケットに保管されているログだけが、 Cloud Logging コンソールのログエクスプローラから閲覧できます。 ログバケットへのログ保管料金は、以下の公式ドキュメント「Google Cloud Observability の料金」の「Cloud Logging の料金概要」部分に記載されている「ロギング保持」がそれにあたり、$0.01/GiB（2025年2月現在）であり、Cloud Storage バケットの Standard Storage や Nearline Storage よりも少し安い価格設定です。 参考 : Google Cloud Observability の料金 - Cloud Logging の料金概要 参考 : Cloud Storage の料金 - 料金表 Cloud Logging が扱うログ プラットフォーム ログ、コンポーネント ログ ユーザーが意識しなくとも、様々な Google Cloud サービスが Cloud Logging にログを出力しています。 これにより、利用者は Web コンソール画面でいちいち各 Google Cloud サービスの画面へ遷移しなくても、Cloud Logging で集中的にログを管理・閲覧することができます。 Cloud Run や Cloud Run functions 等の Google Cloud サービスで稼働するプログラムは、何も設定しなくても、標準出力が Cloud Logging にログエントリとして連携されます。ただし、適切なフォーマットで出力することで Severity（重要度）などの属性値を、閲覧しやすい形で出力できます。以下の記事も参考にしてください。 blog.g-gen.co.jp 監査ログ Cloud Audit Logs サービスによって生成されるログです。 Cloud Audit Logs については以下の投稿で解説していますので、そちらを参照してください。 blog.g-gen.co.jp ユーザー作成のログ ユーザーが明示的に Cloud Logging に投入したログです。 Google Compute Engine（GCE）の VM 等から Ops エージェント などを通して投入することができます。 Cloud Logging にログを投入することで以下のようなメリットを享受できます。 ログ閲覧の際にサーバにログインする必要がない サーバ障害やスケールインした際にもログが失われない 分析目的でログを BigQuery に投入できる ログの保管と保管期限の管理（ハウスキーピング）が容易に実装できる VM に Ops エージェントをインストールするとデフォルトで、Linux では /var/log/messages や /var/log/syslog が、 Windows では System 、 Application 、 Security のイベントログが収集されます。 デフォルトで収集されるログ以外にも、設定ファイルを変更することで、任意のアプリケーションのログを収集することができます。 詳細は公式 ドキュメント を参照ください。 Compute Engine の VM から Cloud Logging にログを送出する方法については、以下の記事もご参照ください。 blog.g-gen.co.jp マルチクラウドとハイブリッド クラウドのログ Microsoft Azure や Amazon Web Services（AWS）から取り込んだログやオンプレミスから取り込んだログです。 Ops エージェント等を通じて、Google Cloud 以外のプラットフォームからもログを収集し、管理することができます。 料金 Cloud Logging の料金 Cloud Logging の料金はログの 取り込み処理量 と ストレージ保管量 の2軸での従量課金です。 「取り込み処理量」への課金は、Cloud Logging ログバケットに取り込むログのサイズに応じて、ワンショットの料金が発生します。 「ストレージ保管量」への課金は、ログバケットで保管しているログのサイズに応じて、継続的に発生する料金です。 2025年2月現在の料金単価は、以下のとおりです。 料金名 単価 説明 取り込み処理量 $0.50 / GiB ・Cloud Logging ログバケットに投入されたログのデータサイズに応じて一度だけ課金 ・毎月、プロジェクトごとに最初の 50 GiB は無料 ストレージ保管量 $0.01 / GiB ・ログバケット上に30日間以上保管されたログにのみ適用（30日間以内は無料） ・ログを BigQuery や Cloud Storage 等、他サービスに転送する場合はそちらの料金が発生 最新の料金単価は以下のページを参照してください。なお以下のドキュメントでは、前者の「取り込み処理量」は「Logging ストレージ」、後者の「ストレージ保管量」は「ロギング保持」と表現されています。 参考 : Google Cloud Observability の料金 - Cloud Logging の料金概要 最初から存在するログバケットの料金 Google Cloud プロジェクトを作成すると、デフォルトで _Required と _Default という2つのログバケットが存在しています。 _Required は、Google Cloud が必須で取得する監査系のログが投入される特殊なログバケットです。ここに保存されるログは、取り込み料金もストレージ料金も発生しません。 _Default は、 _Required に保存されるログ 以外のログ がすべて保存されるログバケットです。このログバケットは、初期設定で保持期限が30日ですので、保持期限を変更しなければストレージ料金は発生しません。ただし、取り込み処理料金は発生することに注意してください。 取り込み料金には、プロジェクトごとに最初の50GiBまでが無料枠として用意されていますので、相当のサイズまでは無料で取り込むことができます。 取り込み料金の節約 ログのボリュームが大きくなると、$0.50 / GiB の取り込み料金はコストとして重くのしかかってきます。 この取り込み料金は Cloud Logging ログバケットに対して取り込むログサイズに対してのみ 発生します。つまり、以下のログに対しては料金が発生しません。 シンク（後述）により Cloud Storage バケット、BigQuery データセット、Pub/Sub トピック等にルーティングされたログ シンクの除外フィルタで除外したログ ログ量が莫大になり、取り込み料金が多く発生している場合、除外フィルタで取り込むログをフィルタリングしたり、Cloud Storage や BigQuery に逃がすことで、取り込み料金を節約できます。ただし、ルーティング先の取り込み料金は発生しますので、そちらを確認する必要はあります。 参考 : クラウド管理者向けの Cloud Logging の料金: そのアプローチと費用を削減する方法 例として Cloud Logging ログバケットへの取り込みと BigQuery へのエクスポートで料金を比較すると、以下の通りです。 Cloud Logging ( 取り込み料金 ) : $0.5 /GB (2023年5月時点) BigQuery ( Streaming inserts 料金 ) : $0.06 /GB ($0.012 per 200 MBと表記。東京リージョン、2023年5月時点) BigQuery へログをエクスポートすると Streaming inserts 料金が発生しますが、Cloud Logging ログバケットへの取り込み料金と比較して、10分の1近くの料金設定となっています。 ログの閲覧 閲覧方法 Cloud Logging のログバケットに保存されたログは、Google Cloud の Web コンソール内に存在する ログエクスプローラ と呼ばれる画面で閲覧することができます。 ログエクスプローラ また他にも、gcloud コマンドラインツール等を用いてログを取得することも可能です。 参考 : ログ エクスプローラを使用してログを表示する 参考 : gcloud CLI を使用してログエントリをリスト表示する クエリ言語 ログエクスプローラや gcloud コマンドでは、独自のクエリ言語である Logging query language を用いて、ログをフィルタして表示させることができます。 Logging query language は、ログエクスプローラから直感的に生成することもできますので、ゼロから時間をかけて学習する必要性はありません。公式のリファレンスは以下のリンクから参照できます。 参考 : Logging のクエリ言語 以下は、クエリの例です。 my-project というプロジェクトにおける Cloud KMS 関連のログだけを抽出しています。 protoPayload.serviceName="cloudkms.googleapis.com" resource.labels.project_id="my-project" 以下の当社記事では、Logging query language について詳細に解説しています。 blog.g-gen.co.jp インデックス Cloud Logging には インデックス の概念があります。 以下のフィールドにはデフォルトでインデックスが作成されており、クエリに含めることで、ログ抽出を高速化できます。 resource.type resource.labels.* logName severity timestamp insertId operation.id trace httpRequest.status labels.* split.uid またログバケットごとに、フィールドに対して カスタムインデックス を明示的に指定することができます。 参考 : Configure custom indexing ログの閲覧可能範囲を定義する ログビュー ログビュー とは、ログバケットに保存されているログの一部のみ（ログのサブセット、と表現します）を利用者に閲覧させたい場合に、事前に定義したログ範囲のみの閲覧権限を付与できる機能です。 ログビューでは、対象のログバケットと、Logging query language で記述するフィルタを定義します。管理者はログ閲覧者のために、このログビューに対する閲覧権限を付与します。これにより、閲覧者は定義されたログバケット内のフィルタされたログだけを閲覧できるようになります。 詳細と具体的な手順は以下のドキュメントを参照してください。 参考 : ログバケットのログビューを構成する ログスコープ ログスコープ とは、複数の Google Cloud プロジェクトの Cloud Logging ログを、横断して閲覧するための機能です。 通常、ログエクスプローラでは、単一のプロジェクトのログバケットを対象としたログのクエリ・閲覧しかできません。 ログスコープを使うと、複数のプロジェクトやログビューをグルーピングすることができます。ログエクスプローラ上でログスコープを対象にしてクエリを投入すると、複数のプロジェクトやログビューを横断してログが検索されます。 ログスコープ自体は、プロジェクトレベルのリソースとしてプロジェクト内に作成します。 当機能を使って各プロジェクトのログを閲覧するには、閲覧者が対象のプロジェクトにログの閲覧権限を持っている必要があります。 参考 : Create and manage log scopes ログスコープ機能は2025年2月現在、Preview 段階です。 ログルーティングとログの保存 ログルーティングとは Cloud Logging で特に重要な概念が ログルーティング および シンク （sink）です。おおまかな概念を以下に図示します。 参考 : 転送とストレージの概要 参考 : サポートされている宛先にログをルーティングする ログルーティングの概念 図の最上部は、ログの発生元を表しています。ここからログが Cloud Logging API に向けて投入されます。 投入されたログは ログルーター という Cloud Logging の内部機構により、振り分け先を決定されます。ログルーターは シンク という個別設定を持っており、ログはシンクに定義された設定に応じて保存先に振り分けられます。 ログの振り分け先としてログバケット 、Cloud Storage バケット、BigQuery データセット、Pub/Sub トピック、他の Google Cloud プロジェクト、Splunk を指定することができます。 シンクとは シンク は Cloud Logging に入ってきたログの振り分けをするコンポーネントです。 API を通じて Cloud Logging に入ってきたログは、シンクによって宛先であるログバケットや BigQuery などに振り分けられます。 シンクは設定値として 1. ログの保存先 、2. 包含フィルタ 、3. 除外フィルタ を持ちます。 まず 1. ログの保存先 は前述の通り「ログバケット」、「Cloud Storage バケット」、「BigQuery データセット」、「Pub/Sub トピック」等からいずれかを指定します。 そして 2. 包含フィルタ と 3. 除外フィルタ は、そのシンクがどのログを ログの保存先 に振り分けるかを決定するためのフィルタであり、 Logging query language で定義します。以下のようなものです。 resource.type="bigquery_dataset" AND LOG_ID("cloudaudit.googleapis.com/activity") AND protoPayload.methodName="google.cloud.bigquery.v2.DatasetService.UpdateDataset" 上記は「BigQuery データセットが UpdateDataset により更新されたときに発生したアクティビティログをキャッチせよ」という意味です。 参考 : フィルタの例 なお、複数のシンクでフィルタの設定が重複していて、同じログをキャッチするようになっている場合、それら全てのシンクにログが 複製されて振り分けられ ます。 たとえばシンク A はあるログをあるログバケットに転送する設定になっており、シンク B は同じログを BigQuery に投入する設定になっているとします。この場合は、ログバケットと BigQuery の両方に、同じログが投入されます。 初期設定で存在するシンクとログバケット 初期設定で _Required と _Default というシンクが存在しています。それぞれのシンクは _Required と _Default というログバケットにログをルーティングする設定になっています。 _Required ログバケットには「管理アクティビティ監査ログ」「システム イベント監査ログ」「アクセスの透明性ログ」が保存され、400日間保存されます。なお「管理アクティビティ監査ログ」「システム イベント監査ログ」は Cloud Audit Logs という監査ログの仕組みによって取得されるログです。 _Default ログバケットには、 _Required に入らない全てのログが入るように初期設定されています。この設定は変更可能です。 これらのバケットに発生する料金は前述の 最初から存在するログバケットの料金 をご参照ください。 参考 : ログバケット 書き込み ID シンクを作成した際、ログの振り分け先が「そのシンクが所属するプロジェクトのログバケット 以外 」である場合、 書き込み ID （Writer Identity）と呼ばれるサービスアカウントが生成されます。 ログをルーティングするには、この書き込み ID に対して、書き込み先への権限を付与する必要があります。 書き込み ID の名称はコンソールでログシンクを選択し「シンクの詳細を表示する」を押下したり、gcloud で gcloud logging sinks describe ${SINK_NAME} を実行することで確認できます。 書き込み ID の確認 例えば書き込み先が BigQuery データセットの場合、当該のプロジェクトや BigQuery データセットにおいて、書き込み ID に BigQuery データ編集者 権限を付与する必要があります。 参考 : エクスポート先の権限を設定する なおシンクと同じプロジェクト内のログバケットへログを送る際は、書き込み ID は不要であり、作成されません。 書き込み ID はシンクを作成するごとに一意に生成されます。後述する集約シンクを作成する際には組織レベルやフォルダレベルでシンクを作成しますが、シンクが作成されるレベルによって書き込み ID の命名規則が異なります。 No シンクのレベル 書き込み ID の名称 1 プロジェクトに作成されたシンクの書き込み ID p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com 2 フォルダレベルで作成されたシンクの書き込み ID f(フォルダ番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com 3 組織レベルで作成されたシンクの書き込み ID o(組織番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com プロジェクトをまたいだログの集約 別プロジェクトのストレージにログを送る Cloud Logging のシンクを使い、別のプロジェクトのログバケットや BigQuery データセットにログをルーティングすることができます。 この場合、シンクの書き込み ID が宛先のストレージに対して書き込み権限を持っている必要があります。 またシンクの宛先を「他の Google Cloud プロジェクト」にした場合、宛先プロジェクト内のログシンクに処理を委任することができます。次の項で説明するような組織構成を使わない場合でも、この方法でログの処理を1プロジェクトに集約することが可能です。 組織全体でログを集約する 以下のような理由で、組織全体でログを一つのプロジェクトのログバケットや BigQuery に集約したい要件が出てくるかもしれません。 複数プロジェクトのログを集約して SIEM 等で分析したい 監査などの理由で監査ログを第三者に提出する必要がある 複数プロジェクトでアプリケーションが稼働しておりログを横断して確認したい その際は、シンクを組織やフォルダのレベルで作成し、配下の全てのプロジェクトのログを収集することが可能です。このように複数プロジェクトのログを集約するためのシンクを 集約シンク （Aggregated sinks）といいます。 参考 : 組織レベルとフォルダレベルのログをサポートされている宛先に照合して転送する シンクを作成する際に「 このリソースとすべての子リソースによって取り込まれたログを含める 」オプションを有効化することで、その組織/フォルダ配下の全てのプロジェクトに対してシンクが有効になり、ログ集約用のプロジェクトにログを収集できます。 詳細な手順は、以下を参考にしてください。 参考 : 組織のログをログバケットに保存する シンクによるログの集約 なお、単純に複数のプロジェクトを横断してログを確認したい場合、前述のログスコープ機能を使うこともできます。 集約シンクの種類 集約シンクの作成時、 非インターセプト型集約シンク （non-intercepting aggregated sink）と インターセプト型集約シンク （intercepting aggregated sink）の2種類から選択可能です。 前述の通り、組織の上流（組織のルートやフォルダ）で集約シンクを使用すれば、下流の子リソース（プロジェクト等）で発生するログを集約することが可能ですが、非インターセプト型集約シンクの場合は、親リソースの非傍受型集約シンクで収集したログは、子リソースでも収集することができます。一方のインターセプト型集約シンクの場合、上流のシンクで収集したログはそれより下流の子リソースでは収集できません。 インターセプト型シンクを使えば、子リソースでログを重複して収集し、ログ収集コストが肥大化することを避けることができます。逆に、子リソースでもログを自由に収集できるようにしたい場合は、非インターセプト型のシンクを利用します。 なおインターセプト型シンクは子リソース（プロジェクト）からも閲覧できます（コンソールのログルーター画面に表示されます）。 参考 : Overview ログ監視 ログベースの指標 Cloud Logging でログの特定文字列を正規表現で検知し、その検知数を Cloud Monitoring に指標（メトリクス）として送信することができます。これを ログベースの指標 と呼びます。 この指標を Cloud Monitoring のアラートポリシー機能により検知・発報することで「XXログで Error という文字列を5分間で3個以上検知したらメール通知する」のようなログ監視が可能になります。 手順は以下をご参照ください。 参考 : ログベースの指標の概要 参考 : 指標ベースのアラート ポリシーを作成する アラートポリシーについては、以下の記事もご参照ください。 blog.g-gen.co.jp ログベースのアラート ログベースのアラート は、Cloud Logging に出力されたログエントリの文字列を検知して、E メールや Slack 等に対して通知を発報する機能です。 検知対象の文字列を指定してログベースのアラートを設定することで、アプリケーションや Google Cloud サービスのエラー等を検知して、運用者や管理者に対してアラートを発報することができます。 前述のログベースの指標による発報方法は、いったんログ文字列の検知数を Cloud Monitoring の指標としてカウントしますが、この「ログベースのアラート」では特定の文字列を検知すると直接、アラートを発報できます。 この「ログベースのアラート」は前述の「ログベースの指標 + アラートポリシー」とほとんど同じことが可能ではありますが、「ログベースのアラート」では文字列検知数を指標化しないため、数値として後から統計が取れない代わりに、より少ないステップで設定可能であり、後から見ても設定がわかりやすいという違いがあります。 参考 : ログベースのアラートを構成する Log Analytics Log Analytics とは Log Analytics （ログ分析）は、Cloud Logging ログバケットに格納されているログに対して SQL でクエリすることができる機能です。 当機能リリース以前は、ログに対して SQL でクエリをかけるにはログルーター (シンク) を使って BigQuery へログをエクスポートする必要がありました。2023年1月に当機能が GA されて以降は、当機能により Cloud Logging ログバケットに直接 SQL を実行することが可能になりました。 またもう一つの機能としてログバケットを BigQuery データセットとリンク することができます。 BigQuery データセットとリンクされたログバケットは BigQuery 側からビューとして使うことができます。これにより BigQuery の他のデータと結合しての分析も可能になります。 参考 : ログ分析 利用方法 ログに SQL を実行するには、ログバケットごとに Log Analytics を 有効化 する必要があります。 有効化されたログバケットに対して Google Cloud コンソールの Log Analytics ページから BigQuery 標準 SQL を実行することができます。 コンソール画面 BigQuery データセットとのリンク ログバケットごとに BigQuery データセットとのリンク を行うことができます。 リンクすると BigQuery に新規データセットが作成され、その中に _AllLogs というビューが生成されます。このビューに対してクエリを実行することでログを抽出できます。 BigQuery を使って _AllLogs ビューに対してクエリを実行すると、スキャンしたデータ量に応じて BigQuery のクエリ料金が発生します。一方で Log Analytics 画面からのクエリは無料です。 ユースケース Log Analytic は、アプリケーションのトラブルシューティングや、アプリログを BigQuery の自社データやパブリックデータセット等と結合する等の用途が想定されます。 従来、こういった分析をするためにログルーター（シンク）を使って BigQuery にログをエクスポートして長期保存することもありました。しかし Log Analytics 登場後は、事情が変わります。 Cloud Logging のログバケットの保存料金は、 BigQuery のストレージ料金（アクティブ/長期保存）と同等あるいは安価なためです。最終的に Cloud Logging ログバケットに保存したほうが安価になるのか、あるいは BigQuery の方が安価になるのか、については後述します。 参考 : Cloud Logging pricing summary 参考 : BigQuery - Storage pricing 制限 代表的な制限のみを記載します。 クエリできるのは Log Analytics 有効化後に発生したログのみ ログバケットが CMEK 暗号化されていない ログバケットがロックされていない その他の制限や最新情報は以下の公式ドキュメントをご参照ください。 参考 : 制限事項 Log Analytics の料金 Log Analytics では通常の Cloud Logging 以外に発生する追加料金はありません。Log Analytics 画面からクエリした場合、クエリ料金も無料です。 一方でログバケットを BigQuery データセットとリンクして BigQuery からクエリした場合 BigQuery のクエリ料金が発生します。 ログをログバケットに保存するのと、BigQuery にエクスポートするのでは、最終的にどちらが安価になるのでしょうか。それには、以下の要素が関わってきます。 ログ取り込み時の料金 Cloud Logging ( 取り込み料金 ) : $0.5 /GB (2023年5月時点) BigQuery ( Streaming inserts 料金 ) : $0.06 /GB ($0.012 per 200 MBと表記。東京リージョン、2023年5月時点) クエリ時の料金 Cloud Logging (Log Analytics 画面) でのクエリ : 無料 BigQuery でのクエリ ( オンデマンド料金 ) : $6 /TB (最初の 1TB は無料) (東京リージョン、2023年5月時点) つまり、ログ取り込みの料金は BigQuery の方が安価ですが、クエリ時の料金は Cloud Logging（Log Analytics 画面）のほうが安価（無料）ということで、一長一短です。利用実績を確認し、どちらのほうが安価になるかを判断してから決定することになります。 サービス間連携 Cloud Run functions のログ 以下は、Cloud Run functions から Cloud Logging へログを投入する方法について解説した記事です。Cloud Run functions では、標準出力に文字列を出力するだけで Cloud Logging へログとして投入されますが、特定の設定をすることで 重要度（Severity）等を設定することができます。 blog.g-gen.co.jp Compute Engine VM（Windows）のログ 以下の記事では、Compute Engine VM から Cloud Logging へ任意のログファイルを取り込むための方法を紹介しています。Ops Agent という Cloud Monitoring のエージェントソフトウェアをインストールすることで実現できます。 blog.g-gen.co.jp Tips 以下の記事では、Cloud Logging の運用上の Tips が紹介されています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさんこんにちは。G-genの鈴木ことすずたつです。 みなさまの会社や、コミュニティではタスク管理をどのように行っていますでしょうか？ 前回は 共同タスクを利用したタスク管理 を紹介しました。 共同タスクの利用は、主に お客様とのやり取りが必要な場合 、つまりGoogle Workspaceを利用していない、もしくは 別の組織の方々とのやり取りが必要な場合 に本領を発揮します。 では、組織内の方々とタスク管理する場合はなにかないものでしょうか？ そこで今回はGoogle Keepを利用したタスク管理について説明していきたいと思います。 Google Keepとは Google Keepの基本操作 ラベルの作成 色の変更とリマインダーの設定 担当者の割り当て Googleカレンダーとの連携 Google Keepとは Google Keep Google Keepとは、Google Workspace(旧 G Suite)に無料で含まれている 多機能メモアプリケーション になります。携帯用のアプリケーションも提供されていますので、外出先からなにか忘れてはいけないことをメモしたりすることができます。 では今回はそんなGoogle Keepを利用して 組織のメンバーとタスク管理 する方法を紹介いたします。しかも、はやりの 看板管理 で。 Google Keepの基本操作 はじめに、Google Keepの基本操作をみていきましょう。初期画面は、以下のような画面になります。 Google Keepの初期画面 画面中央の左から以下のようなイメージなります。 ・単純なリスト ・ホワイトボードのような描画入り ・写真入り Google Keepの基本的な使い方 それでは次の項目より以下を説明いたします。 ・タスクを識別するラベルの作成 ・色の変更とリマインダーの設定 ・担当者の割り当て ・Google カレンダーとの連携 ラベルの作成 でははじめに準備として、タスクをわかりやすく識別するために、左側のペインの ラベルの編集 よりラベルを作成していきましょう。 今回は「新規開発プロジェクト」というラベルを作成してみます。 ラベルの作成 すると、上記画像のようにいままであったタスクがなくなりました。これは最初に作成した3つのタスクに「新規開発プロジェクト」といラベルが貼られていないためです。 このように、ラベルを使ってプロジェクトごと、業務種別ごと。など、さまざまな角度からタスクをグルーピングすることができます。 色の変更とリマインダーの設定 すべてのタスクが白だと、わかりにくいですよね。そんなときは各看板の パレット の絵をクリックして、以下のように色を変えてみましょう。 色の変更 また、各タスクに対してリマインダーを設定することも可能です。以下のように、ベルのマークからリマインドを設定してみましょう。 リマインダーの設定 このように設定することで、各タスクを一覧でみることができ。かつ、納期管理もできるようになりました。 担当者の割り当て 実際のプロジェクトとなると、一人で進めることはあまりないかと思います。他のメンバーとタスクを共有しながら進めることが一般的です。 その場合には各タスクに担当者を割り当ててみましょう。 以下のように 人のマーク から組織内の別のメンバーを割り当てることが可能です。 担当者の割り当て(1) 担当者の割り当て(2) これで他のメンバーとタスクを共有することができました。 Googleカレンダーとの連携 Google Workspaceは様々な機能が自動的に連携しています。そのため何もせずとも他のアプリケーションで状況を確認することが可能です。 では実際に Googleカレンダーからタスクを見る方法 を説明いたします。 それは簡単。以下のようにGoogleカレンダーのマイカレンダーより「リマインダー」を選択することでタスクで設定したリマインドの日に表示することが可能です。 Google カレンダーとの連携 とっても簡単ですね。全体的に管理すると以下のようなイメージになります。 Google Keep利用イメージ このように、Google Keepをうまく利用することでタスクを看板管理することが可能になります。ぜひ、ご利用ください！ Google Cloud(旧GCP) / Google Workspace導入に関するお問い合わせ Google Workspace 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-gen の杉村です。Google Cloud のリソースモニタリングのためのプロダクトである、 Cloud Monitoring を解説します。 Cloud Monitoring の概要 Cloud Monitoring とは Cloud Monitoring の料金 リソースモニタリング Google Cloud の指標 カスタム指標 複数のプロジェクトの指標を表示する Ops エージェント Ops エージェントの指標 Ops エージェントのセットアップ VM の要件 トラブルシューティング ダッシュボード アラート 概要 通知チャネル 設定方法 稼働時間チェック 稼働時間チェックとは 公開の稼働時間チェック 非公開の稼働時間チェック Prometheus Query Language（PromQL） Cloud Monitoring の概要 Cloud Monitoring とは Cloud Monitoring は Google Cloud（旧称 GCP）の Google Cloud Observability と呼ばれるサービス群の1つで、各種 Google Cloud サービスからパフォーマンスデータ等を収集して保存・閲覧可能にするサービスです。データ収集元として、Google Cloud の各種サービスのほか、オンプレミスや Amazon Web Services （AWS）上の仮想サーバなども対象にすることができます。 参考 : Cloud Monitoring の概要 Cloud Monitoring では、デフォルトで収集するデータ（後述の「Google Cloud の指標」など）に対しては課金されず、基本機能は無料で使用することができます。 なお Google Cloud Observability はかつてはオペレーションスイート、その前は Google Stackdriver と呼称されていましたが、改称されました。 参考 : Google Cloud のオブザーバビリティ Cloud Monitoring の料金 Cloud Monitoring は、多くの場合で無料で利用することができます。 Google Cloud がデフォルトで収集する指標（メトリクス）については、課金は発生しません。ユーザーが Ops Agent で収集する追加指標やカスタム指標は、収集したバイト数あるいはサンプル数に応じて課金されます。 課金対象メトリクスも、最初の 150 MB は毎月無料ですが、それ移行は $0.2580/MB が発生します（2025年4月現在の単価）。数台〜十数台の VM の Ops Agent 追加指標程度であれば、無料範囲内に収まる可能性があります。 また、Cloud Monitoring API にリクエストした階数や、稼働時間チェック機能などにも、料金が設定されています。 最新の料金は、以下のドキュメントを参照してください。 参考 : Google Cloud Observability の料金 リソースモニタリング Google Cloud の指標 Cloud Moniitoring は、Compute Engine や Cloud SQL、 Cloud Storage のバケットなど、あらゆる Google Cloud リソースから 指標 （メトリクス）を収集します。 取得できる指標は、Compute Engine や Cloud SQL の場合、CPU 使用率やネットワーク I/O、Cloud Storage ならば API リクエスト数や総使用バイト数などです。 標準的な指標は、利用者が何も設定しなくても、 自動的に収集 されます。自動的に収集される指標については、課金は発生しません。このような自動的に収集される指標を、 Google Cloud の指標 といいます。 収集された指標は、Cloud Monitoring コンソール画面の Metrics Explorer 画面や、各サービス側のリソースの画面等で閲覧することができます。 参考 : Metrics Explorer でグラフを作成する Metrics Explorer 画面 Google Cloud の指標の一覧は、以下の公式ドキュメントを参照してください。 参考 : Google Cloud metrics カスタム指標 ユーザー独自の指標として カスタム指標 を収集して、Cloud Monitoring API に送信することができます。 Google Cloudの指標や Ops エージェントの指標は画一的なものであり、アプリケーションの負荷やユーザー体験の状況を正確に反映していない可能性があります。 CPU 使用率やメモリ使用率が上がっているからといって、ユーザーが処理を待たされていることを確実に示しているわけではないですし、逆に CPU 使用率やメモリ使用率に余裕があっても逆のことがありえます。システムのパフォーマンス実態を示す独自の指標があれば、正確に状況を反映し、スケールアクションなどに繋げることができます。 カスタム指標を収集するには、Cloud Monitoring の Web API に直接データを送信する方法と、オープンソースのライブラリである OpenCensus を使って Cloud Monitoring に送信する方法があります。詳細は以下のドキュメントをご参照ください。 参考 : ユーザー定義指標の概要 複数のプロジェクトの指標を表示する 指標スコープ を構成することで、複数のプロジェクトの指標を単一の画面で表示することができます。 ある Google Cloud プロジェクトを、複数プロジェクトの Cloud Monitoring 指標を横断して表示するためのハブとして決めて、そのプロジェクトの指標スコープに、監視対象のプロジェクトを追加することで、複数プロジェクトの指標を横断して閲覧できます。このとき、ハブとなるプロジェクトを スコーピングプロジェクト と呼びます。また、監視対象となる個々のプロジェクトを リソースコンテナ と呼びます。 参考 : 指標スコープの概要 指標を閲覧する Google アカウント（グループ）は、スコーピングプロジェクトに対してのみ、モニタリング閲覧者（ roles/monitoring.viewer ）ロール等の IAM ロールを持つことで、監視対象となるすべてのプロジェクトの指標を閲覧できるようになります。個々の監視対象プロジェクトに対する IAM 権限は必要ありません。 参考 : 指標スコープの概要 - Cloud Monitoring へのアクセス権を付与する スコーピングプロジェクトと権限 公式ドキュメントでは、スコーピングプロジェクトとして専用のプロジェクトを作成し、そこにはリソースを何も作成しないことを推奨しています。そのほうが権限管理上もシンプルですし、スコーピングプロジェクト自体で指標が生成されないため、管理が容易になるためです。 参考 : 指標スコープの概要 - ベスト プラクティス Ops エージェント Ops エージェントの指標 Compute Engine VM に、 Ops エージェント をインストールすると、Google Cloud の指標の他に、追加の指標を収集できます。 参考 : Ops エージェントの概要 Compute Engine の場合、Google Cloud の指標では、メモリ使用率、ディスク使用率、スワップ利用率などの重要な指標は収集されません。これは、Google Cloud の指標は、 VM のハイパーバイザから取得できる情報 をもとに構成されているからだと考えられます。 Ops エージェントは、VM のゲスト OS 上で稼働し、情報を収集して、Cloud Monitoring の API エンドポイントに対してその情報を送信します。これにより、 メモリ使用率 、 ディスク使用率 、 スワップ利用率 などの指標が取得できます。 Ops エージェントによって収集される指標の一覧は、以下の公式ドキュメントを参照してください。 参考 : Ops エージェントの指標 なお、Ops エージェントの指標は取り込みボリュームに応じて料金が発生します。インスタンス数が数台〜十数台といったレベルでは無料枠に収まるか、安価になる可能性が高いですが、数百台のインスタンスを管理する場合は、コストに関する試算も重要になります。 Ops エージェントのセットアップ エージェントのインストール手順は、以下の公式ドキュメントを参照してください。 参考 : Ops エージェントをインストールする VM の要件 Ops エージェントが稼働する VM では、以下の条件1〜3をすべて満たしている必要があることに注意してください。どれか1つでも満たせていない状態だと、Ops エージェントは指標の送信に失敗します。エージェントが稼働してから数分が経つと、Memory Utilization（ agent.googleapis.com/memory/percent_used ）といった Ops エージェントの指標が VM の詳細画面等で確認できます。エージェントのインストール後には、正しく指標が収集できているかを確認しましょう。 条件1 : VM が Cloud Monitoring の API エンドポイントに到達できる 例1 ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている VM が外部 IP アドレスを持っている 例2 ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている VM が Cloud NAT でインターネットへアクセスできる 例3 サブネットで限定公開の Google アクセスが有効になっている VM が限定公開の Google アクセス経由で Google Cloud API にアクセスできる設定ができている 限定公開の Google アクセスについては、以下の記事も参照してください。 参考 : 限定公開の Google アクセスの仕組みと手順をきっちり解説 - G-gen Tech Blog 条件2 : VM にアタッチされているサービスアカウントがプロジェクトレベルで以下のロールを付与されている モニタリング指標の書き込み（ roles/monitoring.metricWriter ）ロール 条件3 : VM のアクセススコープ設定で Cloud Monitoring への書き込みが許可されている "デフォルト" もしくは "全て許可" になっていれば問題ない アクセススコープについては、以下の公式ドキュメントや、当社記事も参照してください。 参考 : サービス アカウント - アクセス スコープ 参考 : 改めてサービスアカウントとVMのアクセススコープを理解する - G-gen Tech Blog トラブルシューティング 指標が表示されない場合は、何らかのエラーが出力されている可能性があります。Linux インスタンスであれば、以下のようなパスにエージェントのログが出力されているので、ログを確認して原因を調査します。 /var/log/google-cloud-ops-agent/subagents/logging-module.log 以下はエラーの例です。この例では、VPC ファイアウォールルールでインターネットへのアウトバウンドの 443/TCP 通信が拒否されていたため、エージェントは API エンドポイントにリーチできず、エラーになっていました。 [2021/10/14 10:07:46] [error] [upstream] connection #272 to logging.googleapis.com:443 timed out after 10 seconds なお上記のエラーメッセージで logging.googleapis.com と出ていることからもわかるように、Ops エージェントは Cloud Logging にログを送信するエージェントの役割も兼務しています。かつては Monitoring エージェントと Logging エージェントの2つの異なる役割のエージェントソフトウェアがありましたが、現在では Ops エージェントに統合されています。 ダッシュボード Cloud Monitoring 指標を閲覧するには、Metrics Explorer の他、 ダッシュボード 機能を使うこともできます。ダッシュボードはカスタマイズ可能で、さまざまなチャート（グラフ）を配置して、運用上必要なリソースの指標を閲覧することができます。 ダッシュボードは運用の要件に合わせて自在に作成が可能であることに加えて、Google Cloud プロダクトごとにプリセットで用意されているダッシュボードをそのまま利用したり、複製してカスタマイズして利用することもできます。また、ダッシュボード定義は JSON 形式でエクスポートしたり、インポートすることができます。 参考 : ダッシュボードの概要 参考 : カスタム ダッシュボードの作成と管理 プリセットのVM用ダッシュボード アラート 概要 Cloud Monitoring では、指標にしきい値を設定して、しきい値を超過した際にメールを発信するなど、 アラート の設定が可能です。アラート機能で作成された個々の設定を、 アラートポリシー と呼びます。 参考 : アラートの概要 例えば、以下のようなアラートポリシーが作成可能です。 指標 : CPU使用率 対象 : あるインスタンスグループ全体 期間 : 5分間 しきい値 : 80%を超過 アクション : E メールを送信 アラートの設定画面 通知チャネル Cloud Monitoring のアラートでは、以下の通知先への通知が可能です。これらのような通知先のことを 通知チャンネル （notification channels）と呼びます。 Eメール Google Cloud のモバイルアプリ Google チャット PagerDuty Services PagerDuty Sync Slack Webhook（HTTP エンドポイント） SMS Pub/Sub 通知先チャンネルを使った運用の例として、指標のしきい値超過をトリガーにして Pub/Sub にメッセージを送信し、Pub/Sub トリガの Cloud Run functions を起動して、対処アクションを自動実行するといったことが実現可能です。 参考 : 通知チャンネルを作成して管理する 設定方法 アラートポリシーは、しきい値超過時の発報のほか、指標が収集できなくなった時や、指標がある数値に到達されると予測される際に発報させることもできます。アラートポリシーの設定方法は、以下の公式ドキュメントを参照してください。 参考 : 指標しきい値のアラート ポリシーを作成する 参考 : 指標なしのアラート ポリシーを作成する 参考 : 予測指標値のアラート ポリシーを作成する また、以下の記事もご参照ください。 blog.g-gen.co.jp 稼働時間チェック 稼働時間チェックとは 稼働時間チェック （uptime checks）とは、一般的に URL 監視、あるいは外形監視等と呼ばれる監視を設定できる機能です。 HTTP、HTTPS、TCP（任意のポート）のいずれかのトラフィックを Google から対象リソースに送信し、そのレスポンスが想定状態と異なっていればアラートを発報することができます。 インターネットからアクセス可能なエンドポイントを対象とする 公開の稼働時間チェック （Public uptime checks）と、VPC ネットワーク内のプライベートなエンドポイントを対象とする 非公開の稼働時間チェック （Private uptime checks）の2種類があります。 チェックが失敗した際の通知先として、Cloud Monitoring の通知チャンネルが選択できます。 参考 : 公開の稼働時間チェックを作成する 参考 : 非公開稼働時間チェックを作成する 稼働時間チェックには、チェック実行回数あたりの料金が発生します。料金単価は、1,000 回の実行ごとに $0.30 です（2025年4月現在）。また、Google Cloud プロジェクトあたり、月に100万回までが無料です。 参考 : Google Cloud Observability の料金 公開の稼働時間チェック 公開の稼働時間チェック （Public uptime checks）は、インターネットからアクセスできるエンドポイントを対象とする稼働時間チェックです。 以下を監視対象として設定できます。 URL Compute Engine VM App Engine アプリケーション Kubernetes サービス Amazon EC2 インスタンス Amazon Elastic Load Balancers Cloud Run リビジョン 監視対象が Google Cloud の VPC ネットワーク内のリソースの場合、稼働時間チェックが正しくエンドポイントに到達できるようにするためには、VPC ネットワークのファイアウォール等を適切に設定する必要があります。 0.0.0.0/0 からのトラフィックが許可されていれば問題ありませんが、稼働時間チェックが利用する接続元 IP アドレスだけを許可することもできます。IP アドレスのリストは、Google Cloud コンソールからダウンロードしたり、API 経由で取得することができます。 参考 : 稼働時間チェック サーバーの IP アドレスを一覧表示する 上記で取得した接続元 IP アドレスの範囲だけを VPC ファイアウォールルールで許可することも可能ですが、クラウドサービスの IP アドレス範囲は変更される可能性もあるため、変更を定期的に検知してファイアウォールルールに反映するような仕組みを用意することが望ましいでしょう。 公開の稼働時間チェックの設定手順の詳細は、以下の公式ドキュメントを参照してください。 参考 : 公開の稼働時間チェックを作成する 非公開の稼働時間チェック 非公開の稼働時間チェック （Private uptime checks）は、インターネットに公開されていない、 VPC ネットワーク内部のリソースのエンドポイントを対象とする 稼働時間チェックです。 社内向けシステムをホストする Compute Engine VM や、自組織の内部ネットワーク向けの API エンドポイント等を監視する目的で利用できます。 非公開稼働時間チェックでは、ターゲットとして Service Directory リソース と呼ばれるリソースを作成する必要があります。Service Directory リソースには、エンドポイント、サービス、名前空間といったリソースが含まれます。これらのリソースにより、Compute Engine VM や、Cloud Load Balancing の IP アドレスを抽象化し、稼働時間チェックはそれに対してチェックを行います。 詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : 非公開稼働時間チェックを作成する Prometheus Query Language（PromQL） Cloud Monitoring では、 Prometheus Query Language （PromQL）という言語で、指標をクエリしたり、グラフを作成することができます。 PromQL は、主に Kubernetes 向けのオープンソースの監視ツールである Prometheus で用いられる、時系列データに対するクエリ言語です。 Prometheus を利用しており、運用を共通化したい場合は、Cloud Monitoring でも PromQL を使うことができます。Metrics Explorer や、カスタムダッシュボードへのグラフ追加時に、PromQL を利用できます。 参考 : Cloud Monitoring の PromQL 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。2021年10月26日、デジタル庁が公募していた デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供 の公募結果が公開されました。 結果として Amazon Web Services (AWS) と Google Cloud (旧称 GCP) が対象として 発表 されました。 これに関連して本投稿では、 Google が公開している海外の政府・自治体による Google Cloud 利用事例を簡単にご紹介します。 日本でも行政によるクラウド利用が進み、国民がより便利に、効率的に行政サービスを受けられるようになることを願います。 デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供 政府および行政機関向け Google Cloud 概要 Google Cloud のコンプライアンス情報 行政向けの事例 1. アメリカ国立老化研究所: パーキンソン病対策を加速 2. NYC Cyber Command: ニューヨーク市の大規模デジタル サービスの安全を守る 3. ロサンゼルス市: Google Map で市民への情報公開と利便性の向上を実現 4. イタリア・ベネト州: 500万人向けの地方自治体サービスの変革 5. チリ: 医療ケアのモダナイゼーション 6. アリゾナ州: クラウドコラボレーションで生産性とセキュリティを向上 デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供 2021年10月4日、日本のデジタル庁は デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和3年度地方公共団体による先行事業及びデジタル庁WEBサイト構築業務－ と題した公募を発出した。 デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和3年度地方公共団体による先行事業及びデジタル庁WEBサイト構築業務－ (デジタル庁) 公募の目的は以下のように記載されている。 本公告はクラウドサービスの適正かつ確実な提供を確保するため、公募参加者に対し、 その確実なサービスの提供を証明する書類等の提出を求めるものであり、デジタル庁が 当該提出された書類等の審査においてクラウドサービスの提供が可能と判断した者すべ てと契約の締結を行うものである。 また応募要項の事業概要の項に記載されているように、今後デジタル庁の Web サービス基盤はこれらのパブリッククラウド上に構築され、他省庁や自治体のシステムもこれに続くことが想定される。 (1) 地方公共団体による先行事業に向けたクラウドサービスの整備 (中略) (2) デジタル庁 WEB サイトに向けたクラウドサービスの整備 (中略) 本件は、上記（1）、（2）を実施するために、その基盤となるクラウドサービスの提 供を公募するものである。 2021年10月26日には、 Amazon Web Services (AWS) と Google Cloud (旧称 GCP) が選定されたことが発表された。 公募結果について (デジタル庁) 政府および行政機関向け Google Cloud 概要 Google Cloud の公式 Web サイトには、政府・行政機関による Google Cloud 利用事例が公開されている。 政府および行政機関向け Google Cloud (Google) 同ページではGoogle Cloud の IaaS 系ソリューションの他、 AI/ML (人工知能・機械学習) 系ソリューションや Google Workspace による業務効率化がソリューションとして紹介され、またいくつかの事例が公開されている。 ただし2021年10月末現在のところ、同ページで紹介されている事例はいずれもアメリカ合衆国や南米など、海外の事例に留まっている。 同ページで紹介される海外事例は一部が日本語訳されているものの、英語版しか公開されていない事例もあることから、これらを抄訳してごく簡単に紹介したい。 Google Cloud のコンプライアンス情報 事例を紹介する前に、同ページで紹介されている Google Cloud のコンプライアンス情報に関しての記述に触れたい。 行政・自治体に限らず一般企業でも注目すべきポイントは、 Google Cloud が受けている第三者認証だ。 以下のページでは、 Google Cloud が受けた認証に関する資料に加え、各国の公的認証やガイドラインへの準拠に向けた補助資料が配置されている。 コンプライアンス リソース センター 日本でも知名度が高い ISO/IEC 27001 や SOC 、PCIDSS はもちろん、日本の通称「3省2ガイドライン (厚生労働省、経済産業省、総務省の3省が発行する医療機関向けの情報システムガイドラインの総称)」に準拠するためのホワイトペーパー等も公開されている点が興味深い。 さてここからは、同ページで紹介されている海外での行政・自治体における Google Cloud や Google Workspace の活用事例を紹介する。 行政向けの事例 1. アメリカ国立老化研究所: パーキンソン病対策を加速 cloud.google.com アメリカ国立老化研究所 (National Institute on Aging) において Google Cloud が利用された事例が紹介されている。 Cloud Life Sciences (旧 Google Genomics: 生物医学データ処理のためのコンピューティングリソース管理プラットフォーム) の利用 オンプレ基盤では数ヶ月かかる200 TB のエクソームデータの処理を 3.5 週間で実現 世界中の50を超える機関の研究者にデータを共有 (アクセスコントロールによりセキュリティを担保) Cloud Life Sciences (旧 Google Genomics) を使うことで大量のコンピューティングリソースを効率的に管理して膨大な遺伝子解析を実現した事例だ。 また Google Cloud のきめ細やかなアクセス制御の特性を利用して、米国内や欧州の各機関に散らばる研究者たちにデータを速やかに共有できたことを紹介している。 2. NYC Cyber Command: ニューヨーク市の大規模デジタル サービスの安全を守る cloud.google.com NYC Cyber Command は米国・ニューヨーク市の公的機関で、市のサイバーディフェンスを任務とする機関だ。 Google はこの事例を以下のように要約している。 高パフォーマンスのクラウド サービスでより迅速に脅威を検知 100 以上のすべての都市機関のオンボーディングにかかる時間を短縮 小規模なチームでクラウド インフラストラクチャを安全に管理 ペタバイト規模のデータを分析できる、ほぼ無限のスケーラビリティ 都市機関や市民に最大の価値を提供 本事例では、市の職員が BeyondCorp セキュリティモデルによるシステム利用をしていることが述べられている。 Google Workspace により ID 管理をベースに Cloud IAM による認可制御をし、 Cloud Identity-Aware Proxy (IAP) を利用して非 VPN による Google Cloud アクセスを実現したようだ。 また各行政システムからデータ収集を行うデータパイプラインを以下のようなアーキテクチャで構築したことが記載されている。 データの受け口として Cloud Pub/Sub を利用 Cloud Dataflow または Cloud Functions がそのデータを処理する BigQuery 等のダウンストリームでデータを分析 これらのサービスを利用した理由として、サーバレスゆえに高い処理能力が容易に調達・実装できることが理由として挙げられている。 またアプリケーション基盤としては Google Kubernetes Engine (GKE) を採用しモニタリングに オペレーション スイート (旧称 Stackdriver) を利用していることを明らかにしている。 3. ロサンゼルス市: Google Map で市民への情報公開と利便性の向上を実現 workspace.google.com 同事例では Google Cloud による以下の成果が記載されている。 緊急時に重要となる情報を使い慣れた Google Map のインターフェイスで提供 Google Map での情報提供を1時間以内に セキュリティよりも機能開発へ注力できるように ロサンゼルス市情報技術局 (ITA, Information Technology Agency) は 2016 年まで、緊急情報提供をウェブサイト上でのテキストにより行われ、地図情報が必要な際には手動で作られた地図がPDF配布されていた。 2016 年前半、エル・ニーニョ現象によって引き起こされた異常気象の際、 Google Map を使った新システムが活用された。 Google Map を活用して市の地図と気象情報をレイヤで重ねたエル・ニーニョ・ウォッチ・ページが公開された。 このページでは警報情報、浸水した市街地、地滑り、停電、渋滞情報、避難シェルターなどの情報が提供されたという。 このエル・ニーニョ・ウォッチ・ページでは Google Map の提供する地理情報の他、地域のホームセンター等の情報も活用した。住民がその情報を活かして、大雨に備えた準備ができるようにしたのだ。 また ITA はカリフォルニア州で頻発する山火事の対応にも Google Map を活用している。 火事の発生場所や避難場所等を表示するようにしたのだ。 またロサンゼルス市は Google Workspace (旧 GSuite) も利用している。 2009 年から Gmail とカレンダーを使っており、これは米国内の自治体でも最も早い部類だったという。 現在では Google Drive や Google Meet の利用を含め 30,000 ユーザーが利用している。 ロサンゼルス市は東京23区のおよそ2倍の面積 (1214.7 平方 km) であるため、点在する職員のコミュニケーションに Google Drive 等が利用されている。 ロサンゼルス市では 2028 年のオリンピック開催に向け、さらにバーチャルアシスタント (Google Assistant) の活用や 5G 活用などを模索している。 4. イタリア・ベネト州: 500万人向けの地方自治体サービスの変革 cloud.google.com ヴェネチア市を擁するイタリア・ベネト州の地方公共サービスでは以下の成果が報告されている。 85,000 人の従業員を Google Workspace で管理。人の移動の必要性を 60% 削減 オンプレソリューションに比べ保健医療当局の運用コストを 90% 削減 地方自治体を跨いだ統合デジタルエコシステムを構築。機械学習を活用した革新的な管理ツールを利用 同州ではデジタル戦略の一環として、ヘルスケアシステムのICTインフラの更改を決定した。 同州には 13 の地方医療当局が存在し、それぞれにデータセンターやEメールプロバイダーを持っていた。 入札を経て、構築パートナーの力を借りたうえで、 50 を超える医療機関の 70,000 人の従業員を Google Workspace に移行した。 Google Workspace のサービスである Drive, Document, Spreadsheet, Meet の利用により、職員の地域間の移動が半分以下に削減できたという。 また同市は Vertex AI (旧 Cloud Machine Learning Engine), Cloud Natural Language および Cloud Storage を活用し、機械学習向けライブラリである TensorFlow を使った機械学習も活用している。なお TensorFlow も Google が開発したオープンソースだ。 医療機関の診断書の管理のために機械学習が活用されており、解析により正確な診断に活用するとされている。 また Apigee API Management Platform も利用されており、これにより各地の 4,000 人以上の開業医の診察予約情報が収集されている。 Google Cloud と Google Workspace の活用により、データセンターの管理運用に比べて 90% の運用コスト削減になったことを当局 CIO が明らかにしている。 5. チリ: 医療ケアのモダナイゼーション www.youtube.com チリ厚生省のヘルスケアシステムに関する事例が動画で紹介されている。 同省では、患者の医療情報の統合に課題があったという。 法的レギュレーションのもと、パブリックな情報とプライベートな情報を API ガバナンスのもとで統合し、臨床現場で利用できるようにするため Apigee を利用した。 同省が Apigee を採択した理由として「シンプルなアーキテクチャ」「ステークホルダに情報を共有する際のセキュリティ」の2つを上げている。 Apigee により 2017 年、住民票と患者情報の照合や、ワクチン情報の共有、パブリックとプライベートなセクターを跨いだ医療情報の共有などに役立てたという。 こういった情報の相互運用を、公的な基準に準拠したうえで実現するために Apigee を活用した。 今後、テクノロジーをベースとして、国民が自ら予防的な健康維持をできるような施策を実施することが今後の課題だとしている。 6. アリゾナ州: クラウドコラボレーションで生産性とセキュリティを向上 workspace.google.com 米国アリゾナ州でも Google Workspace を使って生産性向上を図った事例が公開されている。 リアルタイムなコラボレーションで生産性を向上 月あたり10万7千件あった有害なメールを排除し、セキュリティを向上 3年で数百万ドルのストレージ、ライセンス、管理コストを節約 アリゾナ州のクラウドファーストポリシーを実現 米国の州の中で IT 技術のリーダー的ポジションに位置するアリゾナ州は、 2018 年にクラウドファースト方針を決定。 セキュリティの観点から Google Workspace を選択した。 同州は既に Microsoft 365 を利用していたが、当時は同州が求めていたリアルタイムのコラボレーションやビデオ通話の要件を満たさず、代わりに Google Workspace の採用を決定した。 Okta により Active Directory と Google Workspace を統合してシングルサインオン (SSO) を実現したことが紹介されている。 ブラウザとして Chrome を採用しているほか、 Vault の機能を使って電子情報開示 (eDiscovery) に対応している。 Vault とは、 Google Workspace の Business / Enterprise プランに組み込まれている機能で、 Gmail や Drive といった各サービスのデータを保持、検索、書き出しを行うことができる機能だ。 同州では1年以内に 22,000 人の職員が Google Workspace へ移行し、最終的には 36,000 の職員や関係者が利用することになるという。 導入にはパートナーの他、 Google のプロフェッショナルサービスが協力した。 Gmail ではプロアクティブな保護により、毎月1千万を超えるスパムメールを排除している。同州の従来型のオンプレミスの仕組みでは検知できなかった10万件以上の有害メールを、 Gmail は自動検知して排除したという。 同州ではほとんどのファイルサーバを廃止して Google Drive に移行した。また Google Meet や各種サービスを使った遠隔・リアルタイムの働き方にも慣れ、強い嵐によってデータセンターが機能停止に陥った際も、職員は自宅から働くことができたという。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。BigQuery への認証・認可は Cloud IAM によって制御されますが、その仕組みは複雑です。当記事では、仕組みを詳細に解説します。 はじめに BigQuery と認証・認可 IAM の基本概念 BigQuery 関連の IAM 権限の理解 ジョブ実行とデータアクセス ジョブ実行権限 データへのアクセス権限 読み取り権限 読み取り権限の検証 書き込み権限 メタデータへのアクセス権限 ロールが持つ IAM 権限 ユースケース別 IAM 設定 プロジェクトのすべてのデータセットに対する閲覧権限を与えたい 設定 説明 特定のデータセットにだけ閲覧・編集権限を与えたい 設定 説明 特定のプロジェクトの BigQuery 全体管理者 設定 説明 BigQuery のデータを含むプロジェクト内の全リソースの閲覧権限を与えたい 設定 説明 閲覧者ロールに関する考察 その他のユースケース はじめに BigQuery と認証・認可 Google Cloud（旧称 GCP）のデータウェアハウスサービスである BigQuery では、認証・認可が Identity and Access Management（IAM）によって制御されます。 Google Cloud の IAM の仕組み自体が難しいことに加えて、BigQuery では ジョブ実行権限 と データ取得・編集権限 が別れていたり、「基本ロール」には 特殊な仕組みで 権限が与えられていたり、と難解です。 当記事では、実環境での検証結果も交えて解説します。 IAM の基本概念 まずは Google Cloud の IAM の基本的な仕組みを理解する必要があります。本投稿では以下の記事の内容が理解されている前提で記載しておりますので、先にご参照ください。 特に「リソースの持つ許可ポリシー」「ロール」「継承」などの用語理解が必須です。 blog.g-gen.co.jp BigQuery 関連の IAM 権限の理解 ジョブ実行とデータアクセス BigQuery の ジョブ とは、BigQuery のコンピューティングリソースを使って行われる以下のような操作を指します。 クエリ（テーブルの読み取り、書き込み） ロード（テーブルへのデータ投入） エクスポート（Cloud Storage バケットなどにデータを出力） コピー（テーブルを複製する） これらの操作がユーザーやプログラムにより行われると、ジョブが作成され、バックグラウンドで処理が行われます。例として、コンソールに SQL を入力して実行したり、bq コマンドによって Cloud Storage からのデータロードなどを行う際に、ジョブが実行されます。 参考 : ジョブを管理する BigQuery では、この「 ジョブを実行する権限 」と「 テーブルのデータにアクセスする権限 」が区別されています。 普段仕事で使うパソコンに例えると、パソコンにログインをする権限と、ファイルサーバへのアクセス権限とは別になっている、というようなイメージです。 ジョブ実行権限とデータへのアクセス権限 別れている理由は、以下の例を考えると理解しやすくなります。 Google が公開しているパブリックデータセットを使って分析を行うケースを考えます。データセットへのアクセス権限は全世界に公開されており、データの保管料金は、データを保持している会社（プロジェクト）に課金されています。しかしクエリジョブはデータ利用者側の Google Cloud プロジェクトに投入する必要があり、コンピュート料金もデータを利用する側が負担します。 他プロジェクトのデータを使う場合 このようにデータを保管するユーザーと、クエリを実行するユーザーがわかれているとき、IAM 権限が別々に管理されているために、責任範囲や費用負担を分割することができます。 ジョブ実行権限 ジョブ実行関連の IAM 権限には bigquery.jobs.create 、 bigquery.jobs.get 、 bigquery.jobs.list といったものがあります。 ジョブを実行するには bigquery.jobs.create の権限が必要です。この権限は、以下のような事前定義ロールに含まれています。 BigQuery 管理者 （ roles/bigquery.admin ） BigQuery ジョブユーザー （ roles/bigquery.jobUser ） BigQuery ユーザー （ roles/bigquery.user ） BigQuery Studio ユーザー （ roles/bigquery.studioUser ） これらのロールは、 プロジェクト レベル以上（組織、フォルダ、プロジェクト）で付与する必要があります。ジョブはプロジェクトの API に対して投入するものなので、これらのロールをデータセットのレベルに付与しても効果がないか、ロールによっては付与できない仕様になっています。 ただし、ジョブの実行権限だけを持っていても、データにアクセスすることはできません。次に記載するデータへのアクセス権限が必要です。 データへのアクセス権限 読み取り権限 BigQuery のテーブルへクエリ等を行うには、ジョブ実行権限に加えて、 データへのアクセス権限 が必要です。先ほどの仕事用パソコンの例えを使うと、こちらはファイルサーバへのアクセス権限です。 テーブル内のデータに読み取りアクセスするには、 bigquery.tables.getData の権限が必要です。この権限は、以下のような事前定義ロールに含まれています。 BigQuery 管理者 （ roles/bigquery.admin ） BigQuery データオーナー （ roles/bigquery.dataOwner ） BigQuery データ編集者 （ roles/bigquery.dataEditor ） BigQuery データ閲覧者 （ roles/bigquery.dataViewer ） これらのロールは プロジェクト レベル、 データセット レベル、あるいは テーブル レベルで付与することができます。親リソースにロールを付与すれば、その配下にある子リソースすべてに権限が継承されます。 例えばあるデータセット内のデータに読み取りクエリを実行したい場合、そのユーザーのアカウントに、 プロジェクト レベルで BigQuery ジョブユーザー （ roles/bigquery.jobUser ）を付与するのに加えて、該当のデータセットレベルで BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）を付与します。これにより、このユーザーはプロジェクトレベルでのジョブ実行権限と、データセットレベルでのデータ読み取り権限を得ることになり、SELECT 文等を実行することができます。 読み取り権限の検証 「ジョブ実行権限はプロジェクトレベルで付与する必要がある」そして「データへのアクセス権限はデータセットレベルもしくはテーブルレベルで付与する」と記載したことについて、検証します。 BigQueryの権限のディシジョンテーブル BigQuery ジョブユーザー（ roles/bigquery.jobUser ）ロールはデータセット単位では付与できない仕様のため、上記の表では N/A となっています。 表のとおり、プロジェクトレベルにジョブ実行権限がない場合にはクエリが実行不可（N）という結果になりました。 またジョブ実行権限さえあれば、データ読み取り権限はデータセットレベルで付与することでデータが読み取れる、という結果が確かめられました。なお、データセットレベルでなく、テーブルレベルで権限を付与することでも、データを読み取ることができます。 書き込み権限 書き込み権限について、基本的な考え方は読み取り権限と同様です。 書き込みアクセスに必要な権限は bigquery.tables.updateData です。この権限は、以下のような事前定義ロールに含まれています。 BigQuery 管理者 （ roles/bigquery.admin ） BigQuery データオーナー （ roles/bigquery.dataOwner ） BigQuery データ編集者 （ roles/bigquery.dataEditor ） メタデータへのアクセス権限 メタデータはデータセットやテーブルの持つ付随的な属性情報です。テーブルのスキーマ情報などがこれに当たります。 仕事場のパソコンの例えを使うと、ファイルサーバのデータ容量の使用状況やディスクのドライブ名、またファイルシステムの設定値などが当たります。 データセットのメタデータに対する権限として bigquery.datasets.get 、 bigquery.datasets.update があり、テーブルのメタデータに対する権限として bigquery.tables.get 、 bigquery.tables.update などがあります。 メタデータの閲覧・編集権限があれば、テーブル名やカラム情報を得ることができますが、テーブル内のデータ（レコード）を閲覧したり、編集することはできません。 事前定義ロールである BigQuery データ編集者 （ roles/bigquery.dataEditor ）や BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）などは、データに対する権限に加えて、メタデータに対する権限も持っています。 一方で、 BigQuery メタデータ閲覧者 （ roles/bigquery.metadataViewer ）ロールはメタデータに対する読み取り権限を持っていますがデータ自体への権限はないので、 BigQuery 基盤の管理者・運用者などが使うことが想定されます。 ロールが持つ IAM 権限 どの IAM ロールがどのような権限を持っているかを確認したい場合、以下のドキュメントを参照します。 テキストボックスに権限名を入力して検索することで、ある権限を持つロールの一覧が確認できます。また逆に、ロール名を検索することで、そのロールが持つ権限の一覧を確認できます。 参考 : IAM roles and permissions index ユースケース別 IAM 設定 プロジェクトのすべてのデータセットに対する閲覧権限を与えたい 設定 付与対象リソース プロジェクト 付与する IAM ロール BigQuery Studio ユーザー （ roles/bigquery.studioUser ） BigQuery データ閲覧者 （ roles/bigquery.dataViewer ） 説明 プロジェクトレベルで、Google アカウントに対して上記の2つのロールを付与することで、そのアカウントはプロジェクト内のすべてのデータセット・テーブルに対して読み取りクエリを実行することができるようになります。 BigQuery Studio ユーザー（ roles/bigquery.studioUser ）ロールをプロジェクトレベルで設定することにより、アカウントは BigQuery ジョブを実行する権限を得ます。 BigQuery Studio ユーザーロールの代わりに BigQuery ジョブユーザー（ roles/bigquery.jobUser ）ロールでも構いませんが、BigQuery Studio ユーザーロールを付与することで Gemini in BigQuery を含む、BigQuery Studio（BigQuery の Web コンソール）のほとんどすべての機能を利用することができます。Gemini in BigQuery は生成 AI が SQL コーディングの補助等をしてくれる機能であり、制限付きながら無償で利用できます。 もしロールの付与対象が人間のユーザーではなくサービスアカウントである場合、BigQuery Studio ユーザーロールよりも BigQuery ジョブユーザーロールの方が適しています。 上記に加え、BigQuery データ閲覧者（ roles/bigquery.dataViewer ）をプロジェクトレベルに設定することで、アカウントはプロジェクト内の全てのデータセットとテーブルに対して閲覧権限を持ちます。 特定のデータセットにだけ閲覧・編集権限を与えたい 設定 IAM 設定 1 付与対象リソース プロジェクト 付与する IAM ロール BigQuery Studio ユーザー （ roles/bigquery.studioUser ） IAM 設定 2 付与対象リソース データセット 付与する IAM ロール BigQuery データ編集者 （ roles/bigquery.dataEditor ） 説明 上記の IAM 設定 1 と 2 の両方、すなわちプロジェクトレベルとデータセットレベルの両方で、アカウントに対してロールを付与することで、特定のデータセットに対してのみ、INSERT や UPDATE、SELECT の実行などデータの読み取り・編集権限を得ることができます。 BigQuery Studio ユーザー（ roles/bigquery.studioUser ）ロールなどをプロジェクトレベルで付与することで、アカウントはジョブを実行できるようになります。なお同ロールはデータセットレベルには付与できない仕様であり、必ずプロジェクトレベル以上にしか付与できません。 また BigQuery データ編集者（ roles/bigquery.dataEditor ）をデータセットレベルで付与することで、そのデータセットに対してのみ、データの編集権限を持つことができます。一方でプロジェクトレベルに設定すると、プロジェクト内の全てのデータセットとテーブルに対して編集権限を持つことができます。 特定のプロジェクトの BigQuery 全体管理者 設定 付与対象リソース プロジェクト 付与する IAM ロール BigQuery 管理者 （ roles/bigquery.admin ） 説明 プロジェクトレベルで BigQuery 管理者（ roles/bigquery.admin ）ロールを付与すれば、そのアカウントはジョブの実行、データへのアクセス、データセットやテーブルの作成、など BigQuery に関する全ての操作を行うことができます。 BigQuery のデータを含むプロジェクト内の全リソースの閲覧権限を与えたい 設定 付与対象リソース プロジェクト 付与する IAM ロール 閲覧者 （ roles/viewer ） 説明 ある Google アカウントが 閲覧者 （ roles/viewer ）ロールをプロジェクトレベルで持っていると、BigQuery の全データセット・テーブルのデータとメタデータを閲覧することができます。 閲覧者は、BigQuery 以外のほとんどすべての情報に対する閲覧権限も持つため、注意が必要です。 閲覧者ロールに関する考察 閲覧者（ roles/viewer ）ロールと BigQuery の関係性について、詳細に解説します。 閲覧者（ roles/viewer ）ロールの持つ BigQuery 関係の権限を一覧化すると、以下のようになります。 sugimura@cloudshell:~ ( gcp-dev-yuma-sugimura ) $ gcloud iam roles describe roles/viewer | grep bigquery - bigquery.bireservations.get - bigquery.capacityCommitments.get - bigquery.capacityCommitments.list - bigquery.config.get - bigquery.connections.get - bigquery.connections.getIamPolicy - bigquery.connections.list - bigquery.connections.use - bigquery.datasets.get - bigquery.datasets.getIamPolicy - bigquery. jobs .create - bigquery. jobs .get - bigquery. jobs .list - bigquery.models. export - bigquery.models.getData - bigquery.models.getMetadata - bigquery.models.list - bigquery.readsessions.create - bigquery.readsessions.getData - bigquery.readsessions.update - bigquery.reservationAssignments.list - bigquery.reservationAssignments.search - bigquery.reservations.get - bigquery.reservations.list - bigquery.routines.get - bigquery.routines.list - bigquery.rowAccessPolicies.getIamPolicy - bigquery.rowAccessPolicies.list - bigquery.savedqueries.get - bigquery.savedqueries.list - bigquery.tables.createSnapshot - bigquery.tables.getIamPolicy - bigquery.transfers.get 上記から抜粋すると、BigQuery のテーブルに関する権限は以下の2つだけです。 - bigquery.tables.createSnapshot - bigquery.tables.getIamPolicy これでは、閲覧者ロールはテーブルのメタデータやデータに対するアクセス権限は持たないはずです。前述の通り、データにアクセスするには bigquery.tables.getData の権限が必要です。 bigquery.jobs.create 権限はあるのでジョブ実行はできますが、テーブルのデータは読み取れず、Access Denied エラーになるはずです。 しかし実際には、テーブルのデータを取得することができます。これは、BigQuery が新規データセットに対してデフォルトで付与する、以下の設定が関係しています。 閲覧者ロールを持つことは BigQuery データ閲覧者ロールを持つことと同義 上のスクリーンショットの通り、プロジェクトレベルで閲覧者（ roles/viewer ）ロールが付与されている人は、データセットに対して BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）相当の権限を持つように設定されています。これは IAM の仕組みとは異なる、レガシーなアクセス権限の仕組みに起因しています。 これは、データセットを新規作成するときに自動で設定される、BigQuery 特有の設定です。これにより、閲覧者（ roles/viewer ）ロール自体は bigquery.tables.getData 権限を持っていないため、本来はデータにアクセスできないはずですが、データセット側の個別設定で BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）相当の権限を与えられていたためアクセスができるようになっています。 参考 : Basic roles and permissions 同様にプロジェクトレベルの オーナー （ roles/owner ）には BigQuery データオーナー （ roles/bigquery.dataOwner ）相当の権限が、プロジェクトレベルの 編集者 （ roles/editor ）には BigQuery データ編集者 （ roles/bigquery.dataEditor ）権限が割り当てられます。 これらの自動で割り当てられる権限は、削除することも可能です。 その他のユースケース 以下の公式ドキュメントに、BigQuery 関連の事前定義ロールがどのような権限を持っていて、どのリソースに付与可能なのかが一覧化されています。 当記事の内容を理解したあとは、以下のページを参照し、きめ細かい権限設定を検討してください。 参考 : BigQuery の IAM ロールと権限 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud（旧称 GCP）の証跡管理の仕組みである Cloud Audit Logs （Cloud Audit Logging）について解説します。 Cloud Audit Logs の基本 Cloud Audit Logs とは API リクエストとは Cloud Audit Logs で記録できるログ ログの出力先 料金 考え方 監査ログの料金 監査ログの種類 4 つの監査ログ No 1. 管理アクティビティ監査ログ No 2. データアクセス監査ログ No 3. システム イベント監査ログ No 4. ポリシー拒否監査ログ ログの保存期間 データアクセス監査ログの有効化 有効化手順 3つの種類 除外するプリンシパル 監査ログの集約 集約の必要性 設定手順 データアクセス監査ログと Cloud Storage の認証済み URL Cloud Audit Logs の基本 Cloud Audit Logs とは Cloud Audit Logs とは、Google Cloud（旧称 GCP）の API リクエスト履歴を記録する仕組みです。 監査対応やトラブルシューティングに活用することができます。この仕組みにより Google Cloud で「いつ、誰が、どこから、何をしたか」が自動的に記録されます。 一部の記録はデフォルトでオンになっており、設定変更によってさらに広い範囲のログが記録されるようになります。 参考 : Cloud Audit Logs overview API リクエストとは まず、必要な前提知識を確認します。Cloud Audit Logs は、 Google Cloud に対する API リクエストを証跡管理の目的で記録するサービスです。では、ここでいう「API リクエスト」とは何でしょうか？ Amazon Web Services（AWS）を始め、多くのパブリッククラウドは、インターネットに公開された Web API で操作されます。Google Cloud もほぼ全てのリソースが Web API 経由で操作 （閲覧、作成、更新、削除）されます。例えば、以下のような操作は全て Web API リクエストで行われます。 VM の閲覧、作成、起動、停止 Cloud Storage へのオブジェクトのList、Get、Put、Delete BigQuery へのクエリ、メタデータの閲覧、更新 API リクエストと履歴の記録 AWS や Google Cloud を Web コンソール画面で操作したとしても、その Web 画面のバックエンドでは、 Web API リクエストが発行されている と考えてください。 パブリッククラウドの Web API はインターネットに公開されていますが、誰でも API を実行できるわけではなく、IAM の仕組み等で認証・認可されていますので、セキュリティが保たれます。 Google Cloud では、各サービスごとに Web API のエンドポイントが用意されています。なおこれらの API を総称して Google Cloud APIs と呼びます。 一方で、以下のようなアクセスは Web API リクエストとは別です。 VM への SSH アクセス VM でホストされた Web サイトへの HTTP（S）リクエスト これらは Virtual Private Cloud（VPC）という仮想ネットワーク内の VM に対して、TCP/IP 的にリーチするアクセスですので、クラウドの Web API とは別の経路でアクセスすることになります。 Google Cloud APIs の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp Cloud Audit Logs で記録できるログ Cloud Audit Logs により、いつ誰が Google Cloud サービスに対して Web API リクエストを行い、リソースの閲覧、作成、編集、削除等を行ったかが記録されます。 これらの記録は「監査証跡として」「オペレーションミスやセキュリティインシデントの事後調査」「内部的の抑止」「利用状況の分析」などに用いられます。 Cloud Audit Logs に記録されるのは、 Google Cloud APIs に対するリクエスト です。一方で、前の小見出しで最後に示した、 VPC への TCP/IP 的なアクセスは記録されません 。 後者の履歴を記録するのは、VPC の機能である VPC Flow Logs やファイアウォールログ、もしくはアプリケーション側のロギングの役割です。 なお、Cloud Audit Logs に対応している Google Cloud サービスの一覧は、以下のドキュメントに示されています。 参考 : 監査ログを使用する Google Cloud サービス ほとんどすべての Google Cloud サービスが Cloud Audit Logs でカバーされている一方、Google AI Studio（ generativelanguage.googleapis.com ）など、Google Cloud ではないサービスは対象になっていません。 ログの出力先 Cloud Audit Logs により記録されたログは、 Google Cloud のログ管理サービスである Cloud Logging に保存されます。 Cloud Logging については以下の記事で詳細に解説していますので、ご参照ください。 blog.g-gen.co.jp 料金 考え方 Cloud Audit Logs 自体に料金は発生しません。しかし、ログの 保存先である Cloud Logging の料金 が発生します。 Cloud Logging の料金は、「ログの取り込み量」「ログの保管量」のそれぞれに対する従量課金です。前者は、月に 50 GiB まで無料で、それを超える量に対して料金が発生します。後者は、デフォルトの保管期間であれば無料であり、ログの保管期間を長くした場合に発生します。 参考 : Google Cloud Observability の料金 - Cloud Logging の料金概要 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - 料金 監査ログの料金 デフォルトで出力される監査ログ（管理アクティビティ監査ログなど）については、デフォルトで Cloud Logging ログバケットである _Required ログバケットに保管されます。特に設定を変更しなければ「ログの保管量」に対する課金は発生せず、無料で保管できます。また、プロジェクト全体のログの取り込みボリュームの合計が無料枠である 50 GiB を超えないうちは、「ログの取り込み量」に対する料金も発生しません。 参考 : 転送とストレージの概要 - _Required ログバケット データアクセス監査ログを明示的に有効化した場合や VPC Service Controls を有効化してポリシー拒否監査ログが発生した場合、特に設定を変更しなければこれらのログは _Default ログバケットに出力され、デフォルトの保管期間である「30日間」を変更しない限り、「ログの保管量」に対する課金は発生しません。また、プロジェクト全体のログの取り込みボリュームの合計が 50 GiB を超えなければ、「ログの取り込み量」に対する料金も発生しません。ただし、使用状況や設定内容にもよりますが、データアクセス監査ログは大量に発生する傾向があります。ログの発生量には注意が必要です。 参考 : 転送とストレージの概要 - _Default ログバケット 監査ログの種類 4 つの監査ログ Cloud Audit Logs では前述の通り、 Google Cloud サービスに対する Web API リクエストの履歴が記録されますが、記録されるログにはいくつかの種類があります。それらのうちには、デフォルトで有効化されているログもあれば、任意で利用者が有効化する必要があるものもあります。 No 名称 説明 料金 デフォルト 1 管理アクティビティ監査ログ (Admin Activity audit logs) リソースに対する管理的な更新系の API リクエストが記録される 無料 有効 (無効化できない) 2 データアクセス監査ログ (Data Access audit logs) リソースやデータに対する更新系・読み取り系の API リクエストが記録される。有効化するとログ容量が大きくなる可能性があるため注意 有料 無効 (BigQueryのみデフォルト有効) 3 システム イベント監査ログ (System Event audit logs) ユーザではなくGoogle Cloudサービスによって行われたリソース構成変更が記録される 無料 有効 (無効化できない) 4 ポリシー拒否監査ログ (Policy Denied audit logs) VPC Service Controls 機能で拒否された API リクエストが記録される 有料 有効 (除外フィルタ設定可能) 参考: 監査ログの種類 No 1. 管理アクティビティ監査ログ 管理アクティビティ監査ログ は、 更新系 の API リクエストのことです。組織やプロジェクトで、デフォルトで有効化されています。 Compute Engine VM が作成されたり、Cloud Storage のバケットが作成・削除されたりする際に、このログが出力されます。 更新系操作は証跡管理上の重要度が高いため、デフォルトで有効となっており、400日間保存されます。無効化はできませんが、料金も発生しません。 No 2. データアクセス監査ログ データアクセス監査ログ は、 データに対する読み取り系および更新系のログ が記録されます。BigQuery を除き、デフォルトではオフになっています。一般的に、データの更新・読み取りアクセスは書き込みに比べて頻度が多いことから、データ量が大きくなり、利用ボリュームによっては料金が高額になる可能性があります。 BigQuery のみ、デフォルトでデータアクセス監査ログが有効化されており、無効化はできません。 データアクセス監査ログとして記録されるオペレーションの例として、Cloud Storage のオブジェクトの作成、削除、オブジェクトの一覧表示、オブジェクトの取得などがあります。どのオペレーションがデータアクセス監査ログに当たるかは、サービスごとのドキュメントに記載されています。 参考 : Cloud Storage での Cloud Audit Logs データアクセス監査ログは Google Cloud サービス単位で有効化することができます。有効化すると、ログの取り込み量、保存量、保存期間に応じて Cloud Logging の料金が発生します。 データの読み取りや更新の頻度が多いと、データアクセス監査ログに対して多額の利用料金が発生する可能性があるため、特に重要なデータを扱う可能性があるサービスを選定し、必要性とコストのトレードオフを検討してから有効化してください。 例として、個人情報を格納している Cloud Storage バケットが存在するプロジェクトなどで、データアクセス監査ログを有効化することを検討します。 また、Cloud Logging の除外フィルタ設定により、記録されるログをフィルタすることで料金を節約することができます。 参考 : 除外フィルタ No 3. システム イベント監査ログ システム イベント監査ログ は、人間のユーザーによる API リクエストではなく、 Google Cloud サービス側のリクエストによりリソースに変更があった際に記録されます。 システム イベント監査ログはデフォルトで有効化されており、無効化はできません。また、料金も発生しません。 No 4. ポリシー拒否監査ログ ポリシー拒否監査ログ は、VPC Service Controls のポリシーが違反されたときに記録されるログです。 ポリシー拒否監査ログの記録と保存には Cloud Logging 料金が発生します。料金を節約したい場合、Cloud Logging の除外フィルタ設定によるフィルタを検討してください。 VPC Service Controls については、以下をご参照ください。 blog.g-gen.co.jp ログの保存期間 デフォルトで有効化されている監査ログは、組織、各フォルダ、各プロジェクトにデフォルトで存在するログバケット _Required に保存され、 400日間 保持されます。 ログバケット とは、ログを保存するための Cloud Logging 専用ストレージであり、Cloud Storage バケットとは名前が似ていますが、別物です。 _Required ログバケットの保存期間は変更することができないため、400日間以上ログを保持したい場合、Cloud Logging でシンク（ログを選別して保存先へルーティングするための仕組み）を作成して、より長い保存期間を設定した別のログバケットや Cloud Storage バケット、BigQuery 等にログを保存します。 また、データアクセス監査ログを有効化すると _Default ログバケットに保存されます。 _Default ログバケットの保持期間は 30日間 です。 _Default ログバケットの保存期間は変更できるため、より長い保存期間が求められる場合は保存期間を変更するか、シンクを作成して別のストレージにログを保存します。 データアクセス監査ログの有効化 有効化手順 データアクセス監査ログを有効化するには、Google Cloud の Web コンソール、gcloud コマンドライン、REST API などを利用します。詳細な手順は以下の記事を参照してください。 参考 : データアクセス監査ログを有効にする 3つの種類 データアクセス監査ログには、3種類の有効化オプションがあります。 名称 説明 ADMIN_READ メタデータや構成情報に対する読み取りオペレーションを記録 DATA_READ ユーザー提供のデータに対する読み取るオペレーションを記録 DATA_WRITE ユーザー提供のデータに対する書き込みオペレーションを記録 Cloud Storage を例に取ると、オブジェクトのメタデータ（保存日時、データサイズ、名称の取得等）を取得するリクエストは ADMIN_READ に分類されます。データ自体をダウンロードするリクエストは DATA_READ に分類されます。 Google Cloud プロジェクトにおいて、各 Google Cloud サービスごとに、上記のうち有効化するログを選択して有効化します。すべて有効化することもできますし、一部のみを有効化することもできます。また、全サービスのすべてのログを取得するように設定することもできます。 参考 : 構成の概要 除外するプリンシパル 特定の プリンシパル （Google アカウントやサービスアカウントなど）を指定して、そのプリンシパルだけはデータアクセス監査ログを生成しないように設定できます。 例えば、イベントドリブンで頻繁に起動する Cloud Run functions があるとします。この関数は、数秒に1度、オブジェクトがバケットにアップロードされるたびに起動して、サービスアカウントの権限を使ってオブジェクトを取得し、短い処理を行ってから終了する、とします。この関数は頻繁に起動して Cloud Storage オブジェクトにアクセスするため、データアクセス監査ログが膨大になることが想定されます。このような場合に、関数が使うサービスアカウントを Cloud Storage のデータアクセス監査ログの除外プリンシパルとして設定すれば、関数からのアクセスはログに記録されません。 除外するプリンシパルは、Google Cloud サービスごとに指定できます。 参考 : 除外を設定する 監査ログの集約 集約の必要性 前述の通り、デフォルトでは監査ログは組織、各フォルダ、各プロジェクトのログバケット _Required に保存されます。 しかし、以下のような要件がある場合、 ログ集約用のプロジェクト を作成し、その中にログ集約用ログバケットを作成したあと、組織レベルで 集約シンク を作成することで、組織配下の全ての監査ログを1か所に集約することができます。 複数プロジェクトのログを集約して SIEM で分析したい 監査のために監査ログをエクスポートして第3者に提出する必要がある 複数プロジェクトを横断して監査ログをクエリしたい 集約シンクを使ってログを集約する場合、ログバケットへのデータ取り込みに対して、ログの取り込み量、保存量、保存期間に応じて料金が発生する点に留意しましょう。 シンクによるログの集約 なお、単純に複数プロジェクトを横断して監査ログをクエリしたいだけであれば、Cloud Logging のログスコープ機能を使うことで実現できますが、この機能を使ってログを閲覧するにはログを保持する各プロジェクトに対してログの閲覧権限が必要です。ログをログ集約プロジェクトに集約することで、ログの閲覧者が各プロジェクト側に権限を持つ必要がなくなります。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログスコープ 設定手順 組織で監査ログを集約するには、以下のような流れで設定作業を行います。 ログ集約用の Google Cloud プロジェクトを用意 ログを保存するためのログバケットまたは BigQuery テーブル等を用意 組織レベル（フォルダレベル）で集約シンクを作成 シンクのサービスアカウントに、ログ保存先に書き込むための IAM 権限を付与 場合によってはログのボリュームが膨大になり利用料金がかさむため、必要に応じて最小限のログが収集されるよう、除外フィルタ設定を検討してください。 手順の詳細は、以下の公式ドキュメントを参照してください。 参考 : 組織のログをログバケットに保存する データアクセス監査ログと Cloud Storage の認証済み URL プロジェクトで Cloud Storage に対してデータアクセス監査ログを有効化すると、Cloud Storage オブジェクトの認証済み URL が使用できなくなります。 この事象を回避するには、Cloud Storage のデータアクセス監査ログのうち「データ読み取り」ログを無効化するか、URL を利用するアカウントを除外プリンシパルとして設定します。 参考 : 認証によるブラウザでのダウンロード 参考 : トラブルシューティング - 403: Forbidden トラブルシューティングの事例として、以下もご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。 限定公開の Google アクセス （Private Google Access）機能を使うと、External IP アドレスを持っていない VM から、Google Cloud サービスの API にアクセスできるようになります。 限定公開の Google アクセスとは 仕様 利用するドメイン名 前提知識 デフォルトのドメイン名を利用する 特殊なドメインを利用する private と restricted の違い 2つのドメイン名の違い private.googleapis.com restricted.googleapis.com 選択フローチャート 有効化の手順 概要 デフォルトのドメインの場合 private.googleapis.com restricted.googleapis.com オンプレミスから利用する 限定公開の Google アクセス vs Private Service Connect 限定公開の Google アクセスとは 限定公開の Google アクセス （Private Google Access）とは、Google Cloud（旧称GCP）の API に対して、External IP（Public IP）アドレスを持たない VM や、オンプレミスのクライアントから、プライベートネットワークのみでアクセスできるようにする仕組みです。 Google Cloud の API は、通常はインターネット経由でアクセスされることを想定しています。しかし、インターネットを介さず、プライベートネットワークでのアクセスを可能にするのが当機能です。 参考 : 限定公開の Google アクセス なお、類似の機能として Private Service Connect があります。どちらの機能を利用したら良いのかについては、Private Service Connect について解説した以下の記事で説明していますので、ご参照ください。 blog.g-gen.co.jp 仕様 イメージ 限定公開の Google アクセスの仕様と特徴は、以下のとおりです。 サブネット単位で有効化 する 有効化すると、 External IP を持たない VM やオンプレミスのノードが Google の API へアクセスできるように なる Cloud Storage や BigQuery などの Google Cloud サービスに加え、Google Map、Google 広告なども対象 利用するドメイン名の選択肢 として以下の3つがある。アクセス可能な API、必要なファイアウォール設定、DNS 設定などが異なる デフォルトのドメイン名を利用する private.googleapis.com を利用する restricted.googleapis.com を利用する 利用するドメイン名 前提知識 限定公開の Google アクセスを理解するには、前提として、 Google Cloud サービスは API によって操作され るものである、ということの理解が必要です。 これは、Amazon Web Services（AWS）などの他のパブリッククラウドでも同様です。VM の起動・停止や、 BigQuery のテーブルへのクエリなどは、 Web API を通じて行われます。Web ブラウザで Google Cloud コンソール画面を操作する際や、gcloud コマンドラインを実行する際も、内部的には HTTPS プロトコルにより Web API へのリクエストが実行されています。 Google Cloud API とクライアント これについては、以下の記事で詳細に解説しています。 参考 : Google Cloudの根幹を成すGoogle Cloud APIsとは何か - G-gen Tech Blog 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - G-gen Tech Blog - API リクエストとは 例えば、Cloud Storage API のエンドポイントは https://storage.googleapis.com/ であり、BigQuery API のエンドポイントは https://bigquery.googleapis.com/ です。これらの API エンドポイントは、インターネットに公開されています。そのため、Compute Engine VM から Cloud Storage や BigQuery を利用する場合、本来は External IP アドレスを使って、インターネット経由でアクセスする必要があります。 デフォルトのドメイン名を利用する 限定公開の Google アクセスで利用するドメイン名として、以下の3種類から選択できます。 デフォルトのドメイン名を利用する private.googleapis.com を利用する restricted.googleapis.com を利用する 選択肢 1. デフォルトのドメイン名を利用する は、もともとの Web API エンドポイントをそのまま利用する選択肢です。サブネットで限定公開の Google アクセスを有効化した場合、この状態になり、すぐに利用することができます。 この方法で VM から Google Cloud APIs へアクセスするには、VPC ルートで 0.0.0.0/0 をデフォルトインターネットゲートウェイに向ける必要があり ます。さらに、 ファイアウォールの下り（Egress）ルールで 0.0.0.0/0 に対する HTTPS（443/TCP）を許可する必要があり ます。 上記のような設定をすると、トラフィックがインターネットに出ていくようにも思えますが、この設定により External IP アドレスを持っていない VM でも、Google Cloud APIs へのアクセスができるようになります。また、通信は Google のネットワーク内に閉じたものになります。 参考 : 限定公開の Google アクセスを構成する - 構成オプションの概要 この設定では、VPC ネットワーク単位でデフォルトルートを 0.0.0.0/0 に向ける必要がありますし、ファイアウォール設定も空ける必要があります。設定ミス等により、意図せず VM が External IP アドレスを持ってしまった際などに、VM からはインターネットへのアウトバウンド通信が可能な環境になってしまいます。 これを防ぎたい場合は、他の選択肢が検討されます。 特殊なドメインを利用する 選択肢 2. private.googleapis.com を利用する と、 3. restricted.googleapis.com を利用する は、これらのドメイン名を、 デフォルトのドメイン名の CNAME として登録することでこれらを Web API エンドポイントとして利用 し、アクセス先 IP アドレスを変える方法です。 これらの選択肢では、VPC ネットワークに、 199.36.153.8/30 や 199.36.153.4/30 といったIP アドレス帯に対しての通信を許可するファイアウォールやルートを設定します。 理解しやすくするため、 restricted.googleapis.com の場合を例にとって、設定の流れを以下に記載します。 サブネットで 限定公開の Google アクセスを有効化 199.36.153.4/30 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（デフォルトでは 0.0.0.0/0 のネクストホップがインターネットゲートウェイになっているため、条件を満たしている） VPC ファイアウォールで、 199.36.153.4/30 への 443/TCP の 下り（Egress）通信が拒否されていないことを確認（デフォルトでは許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : restricted.googleapis.com タイプ : A IPv4アドレス : 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : restricted.googleapis.com 上記の手順で Cloud DNS が設定された状態 上記を設定すると挙動がどう変わるのでしょうか。例として、Compute Engine VM 内から gcloud storage コマンドを実行して、Cloud Storage へのアクセスが発生するときの内部的な動作を考えます。gcloud storage コマンドは、Cloud Storage API へリクエストするために、 storage.googleapis.com へ HTTPS でアクセスしようとします。すると VM は Cloud DNS を参照しますので、限定公開ゾーンを優先的に使って名前解決します。内部的には、以下のような処理が行われます。 VM が storage.googleapis.com を名前解決するため、Cloud DNS へクエリする クエリは *.googleapis.com に一致しているので、CNAME で restricted.googleapis.com へ解決される restricted.googleapis.com は A レコードにより 199.36.153.4 、 199.36.153.5 、 199.36.153.6 、 199.36.153.7 のどれかへ解決される VM がクエリへのレスポンスを受け取る gcloud コマンドは、 199.36.153.4 、 199.36.153.5 、 199.36.153.6 、 199.36.153.7 のいずれかへアクセス VPC ネットワークの設定で、これらの IP アドレスへのルートがデフォルトインターネットゲートウェイへ向いており、かつファイアウォールで 443/TCP が許可されていれば、上記の処理の結果として、Google の内部ネットワークを通って API リクエストができます。 解決先の IP アドレスとして、 private.googleapis.com では 199.36.153.8/30 を（上記の4つの IP アドレス）、 restricted.googleapis.com では 199.36.153.4/30 を使う必要があります。 これらの IP アドレスは、インターネットに広報されていない、限定公開の Google アクセス専用の IP アドレスです。 参考 : 名前解決の結果 private と restricted の違い 2つのドメイン名の違い 限定公開の Google アクセスでデフォルトのドメイン名を使わないパターンには、 private.googleapis.com を利用するパターンと、 restricted.googleapis.com を利用するパターンの2種類があります。いずれの場合も、基本的な仕組みは同様です。相違点は、 アクセスできる API の種類 と、 利用する IP アドレス です。 この相違点については、Google Cloud 認定資格である Professional Cloud Network Engineer 試験や Professional Cloud Security Engineer試験でも問われますので、受験予定がある方は restricted.googleapis.com と private.googleapis.com の違いについて、正しく理解することが推奨されます。 参考 : Professional Cloud Network Engineer試験対策マニュアル - G-gen Tech Blog 参考 : Professional Cloud Security Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog private.googleapis.com private.googleapis.com を使うパターンでは、ほとんどの Google API へのアクセスが可能です。 次に説明する restricted.googleapis.com では、 VPC Service Controls でサポートされている API にだけしかアクセスできませんが、 private.googleapis.com では、VPC Service Controls のサポート有無は関係ありません。 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog private.googleapis.com を使うと、多くの API にアクセス可能な一方で、VPC Service Controls で VM からの API アクセスを厳密にコントロールしたい場合には適していません。 VPC Service Controls を使用ておらず、使用する予定もない場合や、VPC Service Controls を使用するものの、サポート対象でない API へのアクセスを許可する場合に、 private.googleapis.com を選択することになります。 サポートされているアクセス先の一覧は、以下のドキュメントを参照してください。 参考 : 限定公開の Google アクセスを構成する - ドメイン オプション DNS に登録する専用 IP アドレスは、 199.36.153.8/30 です（ 199.36.153.8 、 199.36.153.9 、 199.36.153.10 、 199.36.153.11 ）。 restricted.googleapis.com restricted.googleapis.com を使うパターンでは、VPC Service Controls でサポートされている Google API に のみ 、アクセスできるようになります。それ以外の API へのアクセスは拒否されます。 VPC Service Controls を利用している、または利用する予定があり、かつ VM からは VPC Service Controls でサポートされていない API へのアクセスを禁止したい場合は、こちらを選択します。 サポートされているアクセス先の一覧は、以下のドキュメントを参照してください。 参考 : VPC Service Controls - サポートされているプロダクトと制限事項 DNS に登録する専用 IP アドレスは 199.36.153.4/30 （ 199.36.153.4 、 199.36.153.5 、 199.36.153.6 、 199.36.153.7 ）です。 選択フローチャート どのドメインを選択すればいいか、簡単なフローチャートで見てみましょう。 ドメイン名決定フローチャート 一番左の、デフォルトのドメイン名を選択すると、図中にあるように VM が External IP アドレス持っていると、インターネットへアクセスできてしまう などのリスクがあります。これを十分理解して選択しましょう。 有効化の手順 概要 当記事では、設定手順の概要だけを記載しています。詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : 限定公開の Google アクセスを構成する デフォルトのドメインの場合 対象のサブネットで 限定公開の Google アクセスを有効化 VPC ネットワークのルート設定で、 0.0.0.0/0 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（デフォルトでは設定済み） VPC ファイアウォールで、 0.0.0.0/0 への 443/TCP の下り（Egress）通信が拒否されていない ことを確認（デフォルトでは暗黙的に許可） private.googleapis.com 対象のサブネットで 限定公開の Google アクセスを有効化 VPC ネットワークのルート設定で、 199.36.153.8/30 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（ 0.0.0.0/0 がデフォルトインターネットゲートウェイに向いている設定でも問題ない） VPC ファイアウォールで、 199.36.153.8/30 への 443/TCP の 下り（Egress）通信が拒否されていない ことを確認（デフォルトでは暗黙的に許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : private.googleapis.com タイプ : A IPv4アドレス : 199.36.153.8 199.36.153.9 199.36.153.10 199.36.153.11 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : private.googleapis.com restricted.googleapis.com 対象のサブネットで 限定公開の Google アクセスを有効化 VPC ネットワークのルート設定で、 199.36.153.4/30 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（ 0.0.0.0/0 がデフォルトインターネットゲートウェイに向いている設定でも問題ない） VPC ファイアウォールで、 199.36.153.4/30 への 443/TCP の 下り（Egress）通信が拒否されていない ことを確認（デフォルトでは暗黙的に許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : restricted.googleapis.com タイプ : A IPv4アドレス : 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : restricted.googleapis.com オンプレミスから利用する Cloud Interconnect や Cloud DNS で Google Cloud に接続されたオンプレミス環境から、限定公開の Google アクセスを利用するには、以下の設定が必要です。 限定公開の Google アクセスの IP アドレス（ 199.36.153.8/30 等）を Cloud Router からオンプレミス側に広報する オンプレミスノードが参照する DNS に、フォワーダー設定を追加して、 Google Cloud APIs の名前解決を Cloud DNS の限定公開ゾーンに転送する 1つ目は、Cloud Router の カスタムルートアドバタイズ を使うことで実現可能です。2つ目は、Cloud DNS の 受信サーバーポリシー で実現可能です。 2つ目については、オンプレミスのクライアントが、限定公開の Google アクセスの IP アドレス（ 199.36.153.8/30 や 199.36.153.4/30 ）を向きさえすれば良いので、オンプレミスの DNS に Cloud DNS と同じレコードを追加しても構いません。 より詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : オンプレミス ホストの限定公開の Google アクセスを構成する 限定公開の Google アクセス vs Private Service Connect 類似の機能として、 Private Service Connect があります。 どちらの機能を利用したら良いのかについて以下の記事で説明していますので、ご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。当記事では Google Cloud APIs にプライベートネットワーク経由でアクセスするための機能である Private Service Connect について解説します。 概要 Private Service Connect とは Google Cloud APIs とは Private Service Connect のユースケース 必要性 機能のポイント Private Service Connect でマネージドサービスを公開する Private Service Connect vs 限定公開の Google アクセス 機能の違い どちらを使えばよいのか？ 設計のポイント エンドポイントの種類 エンドポイントの IP アドレス DNS 設定 設定手順 はじめに 設定手順の概要 DNS 設定の意味 オンプレミスから利用する 概要 Private Service Connect とは Private Service Connect とは、 External IP（Public IP）アドレスを持たない VM や、オンプレミスのクライアントから、プライベートネットワーク経由で Google Cloud の API 群や、ユーザーの独自サービスへアクセスできるようにするための仕組みです。 この機能では、VPC ネットワーク内に Internal IP（Private IP）アドレスを持つエンドポイントが作成され、このエンドポイント経由で Google Cloud APIs や独自サービスにアクセスできるようになります。 参考 : Private Service Connect 参考 : エンドポイントを介した Google API へのアクセスについて 当記事では、Private Service Connect で Google Cloud API にアクセスする方法について紹介します。 Google Cloud ドキュメント より引用 Google Cloud APIs とは 前提知識として、Google Cloud APIs とは何かについておさらいします。 ほとんどの Google Cloud リソースに対する閲覧、作成、更新、削除などは、すべて Web API によって操作され ます。これは、Amazon Web Services（AWS）などの他のパブリッククラウドでも同様です。 これについては、以下の記事で詳細に解説しています。 参考 : Google Cloudの根幹を成すGoogle Cloud APIsとは何か - G-gen Tech Blog 参考 : Cloud Audit Logsを解説。Google Cloud(GCP)の証跡管理 - G-gen Tech Blog - API リクエストとは Private Service Connect のユースケース セキュリティ上の理由から、Google Cloud APIs へのアクセスを、インターネット経由でなくプライベートネットワーク内で行いたいというケースがあります。 限定公開の Google アクセス 機能を使うことで、External IP アドレスを持たない VM やオンプレミスのノードから、Google Cloud APIs にアクセスできるようになります。 参考 : 限定公開の Google アクセスの仕組みと手順をきっちり解説 しかし、限定公開の Google アクセスでは、 199.36.153.4/30 や 199.36.153.8/30 といった、RFC 1918 範囲（※）ではない IP アドレスを使う必要があるため、 Cloud Interconnect や Cloud VPN 経由でオンプレミス環境から利用する際などに、ルーティングが複雑化するなどの弊害が出る可能性があります。 ※ 10.0.0.0/8 、 172.16.0.0/12 、 192.168.0.0/16 一方で当記事で解説する Private Service Connect を利用すれば、 VPC ネットワーク内に Internal IP アドレスを持つエンドポイントを作成し、このエンドポイント経由で Google Cloud APIs にアクセスできます。 このエンドポイントには任意の IP アドレスを割り当てることができ、RFC 1918 で定義された IP アドレスでも、そうでなくても構いません。 必要性 Google Cloud APIs はインターネット経由でアクセスする必要があるため、これをセキュアでないと考える方もいるかもしれません。しかし、API リクエストは HTTPS（SSL/TLS）で暗号化 されます。そのため、鍵情報の漏洩がなければ、パケットが盗聴されても内容は解読されません。Google から SSL/TLS 証明書の鍵情報が漏洩し、さらにパケットが盗聴・復号されて情報が漏洩する可能性は、一般的には低いと考えられます。 そのため、Private Service Connect や限定公開の Google アクセスを用いる主たる理由は「インターネットへのルーティングができないクライアントを、Google Cloud APIs へアクセスできるようにするため」あるいは「会社（組織）のセキュリティポリシーに準拠するため」であるともいえます。 機能のポイント Private Service Connect 機能のポイントは以下の通りです。 Private Service Connect エンドポイント（Internal IP アドレスが割り当てられる）を作成し、オンプレミスのノードや VPC ネットワーク内の VM は、そのエンドポイント経由で Google Cloud APIs へアクセスできる エンドポイント作成時に、以下の種類のいずれかを選択 all-apis vpc-sc エンドポイントは時間ごとに料金が発生（$7.44/月程度） イメージ Private Service Connect エンドポイントの料金は、以下の公式の単価表を参照してください。 参考 : Virtual Private Cloud の料金 - Private Service Connect Private Service Connect でマネージドサービスを公開する 当記事では詳しく紹介しませんが、もう1つの Private Service Connect の機能として、自環境でホストするサービスを他の Google Cloud ユーザー向けに公開する機能があります。これは、 マネージドサービスの公開 と呼ばれます。なお、Amazon Web Services（AWS）の AWS PrivateLink でも類似のことが実現可能です。 以下の記事でご紹介していますので、ご参照ください。 blog.g-gen.co.jp Private Service Connect vs 限定公開の Google アクセス 機能の違い Private Service Connect に似た機能として、 限定公開の Google アクセス があります。 これら2つの機能は、以下のような違いがあります。 限定公開の Google アクセス機能では API エンドポイントとして利用する仮想 IP アドレスとして 199.36.153.4/30 や 199.36.153.8/30 といった RFC 1918 定義外の IP アドレスを使う必要がある 限定公開の Google アクセス機能では、デフォルトのドメイン名を使う場合に限り、DNS の追加設定が不要で手軽に利用できる しかしこのパターンでは 0.0.0.0/0 へのデフォルトルートと、ファイアウォール許可設定を追加する必要がある 限定公開の Google アクセス機能では料金が発生しない なお、Private Service Connect を設定する際には、限定公開の Google アクセスを有効化する必要がありますので、Private Service Connect 機能は限定公開の Google アクセスの拡張版と考えることもできます。 どちらを使えばよいのか？ Private Service Connect vs 限定公開の Google アクセス を考える時、どのように判断したらよいでしょうか。以下のような観点で検討します。 以下の全てに当てはまる場合は、 Private Service Connect を選択する オンプレミスからのプライベートネットワーク経由での Google Cloud APIs 利用がある 限定公開の Google アクセスで使われる 199.36.153.4/30 または 199.36.153.8/30 を使うにあたり、経路交換や経路制御で不都合がある 例: オンプレミス側のクライアントによって異なる通信先 VPC ネットワークや使用する回線を変えるため、複数のエンドポイントを使用したい 例: RFC 1918 以外の IP アドレスが広報されてくることが望ましくない それ以外の場合、無料で使える 限定公開の Google アクセス を選択する 利用する IP アドレスとして、 199.36.153.4/30 または 199.36.153.8/30 が許容できる場合は、無償で利用できる限定公開の Google アクセスを選択するのがよいでしょう。 限定公開の Google アクセス機能については、以下の解説記事で紹介していますので、ぜひご参照ください。 blog.g-gen.co.jp 設計のポイント エンドポイントの種類 エンドポイントの種類によって、アクセス可能な API が異なります。 all-apis の場合、 Google Cloud のほとんどのサービスや、Google Map、Google 広告など、多くのサービスへ接続することができます。 vpc-sc の場合、接続できるのは VPC Service Controls でサポートされているサービスだけです。 VPC Service Controls を使用しておらず、将来的に使用する予定も全く無い場合は前者を選択します。一方で VPC Service Controls を使用している、または使用する予定がある場合で、かつ VPC Service Controls がサポートしていないサービスへのアクセスが不要な場合は、後者を利用するとよいでしょう。 エンドポイントがサポートしている接続先の API については、以下の公式ドキュメントを参照してください。 参考 : エンドポイントを介した Google API へのアクセスについて - サポートされている API エンドポイントの IP アドレス Private Service Connect エンドポイント作成時には、1つの Internal IP アドレスを割り当てます。IP アドレスは、RFC 1918 アドレス（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）でもそうでなくても構いませんが、 IPv6 アドレスは使えません。 エンドポイントの IP アドレスは、 サブネットの IP アドレスとは重複できません 。また、VPC ネットワークと、ネットワークピアリングや Cloud Interconnect、Cloud VPN 等で接続されているネットワークと重複してもいけません。 将来的な VPC ネットワークやサブネットの拡張などを考慮して、 重複が起きない、かつ IP リソースの無駄使いにならない ような IP アドレスを指定しましょう。 また、もしオンプレミス環境から Cloud Interconnect や Cloud VPN 経由で Private Service Connect エンドポイントを利用したい場合、Google Cloud から広報するルートの集約性を考慮して、VPC サブネットの IP アドレス帯と隣り合った IP アドレスにするのが望ましいでしょう。 参考 : エンドポイントを介した Google API へのアクセスについて - IP アドレスの要件 DNS 設定 例として、Cloud Storage API のエンドポイントは https://storage.googleapis.com/ であり、BigQuery API のエンドポイントは https://bigquery.googleapis.com/ です。これらのドメイン名の IP アドレスを名前解決すると、パブリック IP が返ります。 storage.googleapis.comの名前解決の結果 Private Service Connect エンドポイントを作成しても、このままでは、gcloud コマンドなどのクライアントは、これらのパブリック IP アドレスを目指してパケットを発送してしまいます。 そこで、以下のいずれかの方法で、クライアントが Private Service Connect エンドポイントのプライベート IP アドレスを向くようにする必要があります。 クライアント（SDK）側の設定で、Private Service Connect エンドポイントを参照するよう明示的に設定する プライベートな DNS 名前解決により、クライアントが Private Service Connect エンドポイントを向くように設定する 1.は、クライアントへの明示的な設定により、向き先を変える方法です。Private Service Connect エンドポイントを作成すると、プロジェクトの Cloud DNS に <サービス名>.<エンドポイント名>.p.googleapis.com という DNS ゾーンが自動的に作成されます。gcloud や Python SDK など、クライアント側では、向き先の API エンドポイント URL を明示的に指定することができます。この方法では、DNS 設定を変更することなく Private Service Connect エンドポイントを使うことができます。 参考 : p.googleapis.com DNS 名を使用する 2.は、VM やオンプレミスのクライアント PC 等が参照する DNS サーバー、あるいは Cloud DNS のプライベートゾーンで、 *.googleapis.com に対する CNAME レコードを作成し、それを Private Service Connect エンドポイントの IP アドレスへ解決させる方法です。この方法では、クライアント側の設定やプログラムのソースコードを変更することなく、Private Service Connect エンドポイントを使うことができます。 参考 : デフォルトの DNS 名を使用して DNS レコードを作成する 当記事では続けて、2. の設定手順を紹介します。 設定手順 はじめに 当記事では、設定手順の概要のみを記載しています。より詳細な設定手順は、以下の公式ドキュメントをご参照ください。 参考 : エンドポイントから Google API にアクセスする 設定手順の概要 Private Service Connect の設定手順のおおまかな流れを以下に記載します。 必要な API を有効化 Compute Engine API Service Directory API Cloud DNS API Private Service Connect エンドポイントを作成 対象のサブネットで限定公開の Google アクセスを有効化 VPC ファイアウォールで、エンドポイント IP アドレスへの 443/TCP の 下り（Egress）通信が拒否されていないことを確認（デフォルトでは許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : googleapis.com タイプ : A IPv4アドレス : (エンドポイントの IP アドレス) 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : googleapis.com DNS 設定の意味 上記のうち、5. 以降の DNS 設定について解説します。 例えば、VM の中で gcloud storage コマンドを実行して、Cloud Storage へのアクセスが発生したとします。gcloud コマンドは Cloud Storage API へリクエストをするために、 storage.googleapis.com へ HTTPS プロトコルでアクセスしようとします。VM はデフォルトでは Cloud DNS を参照するので、限定公開ゾーンを優先的に使って名前解決をします。 クライアントの動作の流れは、以下のとおりです。 VM が storage.googleapis.com を名前解決するため Cloud DNS へクエリする クエリは *.googleapis.com に一致しているので、CNAME で googleapis.com へ解決される googleapis.com は A レコードにより Private Service Connect エンドポイントの IP アドレスに解決される VM は 名前解決の結果を受け取る gcloud コマンドは Private Service Connect エンドポイントの IP アドレスへ API リクエストを実行する 参考として、Cloud DNS でのレコード追加済みの画面のスクリーンショットと、実際に VM の中から名前解決を試みた結果を以下に貼付します。 Cloud DNSでレコードが設定されている VMからCloud Storageを名前解決するとエンドポイントURLが返る オンプレミスから利用する ここまで、Compute Engine VM から Private Service Connect エンドポイントを利用するための設定手順を説明しました。 一方、Cloud Interconnect や Cloud DNS で接続されたオンプレミスネットワークから Private Service Connect エンドポイントを利用するには、以下の設定が追加で必要です。 Private Service Connect エンドポイントの IP アドレスを、Cloud Router からオンプレミス側に広報する オンプレミスノードが参照する DNS にフォワーダー設定を追加して、Google Cloud APIs の名前解決を Cloud DNS プライベートゾーンに転送する 1つ目は、Cloud Router の カスタムルート アドバタイズ で実現可能です。2つ目は、Cloud DNS の 受信サーバー ポリシー で実現可能です。 2つ目については、オンプレミスのクライアントが Private Service Connect エンドポイントに向けば良いので、オンプレミスノードが参照する DNS に直接 Cloud DNS と同じレコードを追加しても構いません。 詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : エンドポイントから Google API にアクセスする - オンプレミス ホストからエンドポイントにアクセスする 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Cloud（旧称 GCP）の 請求やの仕組み や 請求先アカウント について解説します。 基本的な概念 概念と用語 請求先アカウントとは お支払いプロファイル 複数のプロジェクトと請求 無料枠 プロジェクトとの紐づけ 紐づけの基本 必要な IAM 権限 Google Cloud パートナーによる請求代行（請求代行） 請求代行の仕組み Marketplace に関する注意点 課金レポート 課金レポートとは レポートのコツ Tips 管理機能 予算アラート 異常検知（Anomaly Detection） 課金データの BigQuery エクスポート プロジェクトと請求先アカウントのリンクを保護 AWS との違い 基本的な概念 概念と用語 当記事では Google Cloud（旧称 GCP）の 請求の仕組み 、また 請求先アカウント という言葉を、Amazon Web Services（以下、AWS）と比較しつつ解説します。 まずは請求先アカウントの仕組み、概念を図示します。 請求の概念 図の中にある、3つの用語を簡単に説明すると、以下のとおりです。 用語 説明 請求先アカウント 請求先情報を定義する設定オブジェクト。プロジェクトと紐づける お支払いプロファイル クレジットカード番号など、支払い情報を定義する設定オブジェクト。請求先アカウントと紐づける プロジェクト Google Cloud のリソースを収容する、いわゆる「テナント」 参考 : Cloud Billing について 請求先アカウントとは Google Cloud を利用するためには プロジェクト の作成が必要ですが、プロジェクトごとに請求先を設定する必要があります。その請求先を定義する設定オブジェクトが、 請求先アカウント です。請求先アカウントでは、以下のような情報を設定したり、情報を閲覧したりできます。 請求先（お支払いプロファイル） 請求書の表示、ダウンロード 課金の分析 予算アラート（利用料金が一定値を超えると警告メールを発信する） 一度、請求先アカウントを作ると、その請求先アカウントは再利用ができ、複数のプロジェクトと紐づけることができます。つまり、請求先アカウントとプロジェクトは 1:n の関係です。 お支払いプロファイル お支払いプロファイル には、クレジットカード情報や請求書送付先など、具体的な支払い情報が含まれています。 なお、お支払いプロファイルを表示したり編集したりする権限は、請求先アカウントの権限とは独立して設定可能です。お支払いプロファイルは一度設定すると、編集したり閲覧したりする頻度は低いはずですので、権限を持つべき人は請求先アカウントよりもごく少なくなるはずです。クレジットカード番号などの情報が入っていますので、より厳密に権限管理しましょう。 複数のプロジェクトと請求 以下のように、Google Cloud 組織の中には複数の請求先アカウントを作成することができます。 また、プロジェクトごとに違う請求先アカウントを設定できます。 請求の概念 (複数請求先アカウント) 請求先アカウントを複数作成すると、管理が煩雑になります。「利用内訳が分かるだけではダメで、請求書を完全に分割したい」「プロジェクトごとにクレジットカードを分けたい」など、特別な理由がなければ複数の請求先アカウントを作成する必要はありません。 1つの請求先アカウントに複数のプロジェクトが紐づいていても、コンソールの費用内訳画面で「プロジェクトごと」「サービスごと」「フォルダごと」など 詳細に課金の内訳を閲覧することが可能 です。 部署ごとやシステムごとの課金内訳を知りたいときは、まずはその方法を検討します。 無料枠 Google Cloud には、サービスごとに無料枠が存在しています。例えば BigQuery は、1ヶ月あたり「10 GiB のデータ保存」「1 TiB のスキャン」までが無料で利用できます。 ただし、これらの Google Cloud 無料枠は、特記がない場合は「請求先アカウント」の単位でカウントされます。Google Cloud プロジェクトが複数あっても、それらのプロジェクトが 同じ請求先アカウントに紐づいていれば、1つの無料枠を共有する ことになります。 参考 : 無料枠 プロジェクトとの紐づけ 紐づけの基本 Google Cloud プロジェクトを請求先アカウントと紐づけると、そのプロジェクトのクラウド利用料は、その請求先アカウントに対して課金されます。 後述する Google Cloud パートナーによる請求代行サービスを利用する等の理由で、すでに利用中の Google Cloud 環境において、ある請求先アカウントから別の請求先アカウントに紐づけを変更することも可能です。 その場合、紐づけ変更の 実施以降 に発生したクラウド利用料金だけが、新しく紐づけた請求先アカウントに課金されるようになります。つまり、紐づけを行った翌月の請求は、2つの請求先アカウントに分かれて発生することに留意してください。 必要な IAM 権限 Google Cloud プロジェクトと請求先アカウントとの紐づけ操作を行うには、操作者の Google アカウントに、以下の 両方の権限 が必要です。 プロジェクトに対する resourcemanager.projects.createBillingAssignment 権限 請求先アカウントに対する billing.resourceAssociations.create 権限 上記のうち 1. を満たすには、プロジェクトに対して以下のいずれかのロールが必要です（例示であり、他にも必要な権限を含んだロールは存在します）。 オーナー（ roles/owner ） プロジェクト請求管理者（ roles/billing.projectManager ） また、上記のうち2. を満たすには、請求先アカウントに対して以下のいずれかのロールが必要です（同様に、例示です）。｀ 請求先アカウント管理者 （ roles/billing.admin ） 請求先アカウント ユーザー （ roles/billing.user ） アクセス制御に関する詳細や請求先アカウントに対して IAM ロールを付与する方法については、以下の公式ドキュメントもご参照ください。｀ 参考 : Cloud Billing のアクセス制御と権限  |  Google Cloud Documentation 参考 : Cloud 請求先アカウントへのアクセスを管理する  |  Cloud Billing  |  Google Cloud Documentation Google Cloud パートナーによる請求代行（請求代行） 請求代行の仕組み Google Cloud パートナーによる請求代行サービス（課金代行サービス）を利用することで、 Google Cloud を割引料金で利用できるなどのメリットがあります。 パートナー経由で Google Cloud を利用する場合の請求の仕組みはパートナーごとに様々ですが、ここでは Google Cloud 専業パートナーである G-gen （ジージェン）社のケースをご紹介します。 参考 : 株式会社G-gen - Google Cloud 請求代行 G-gen 請求代行サービスの仕組み G-gen の請求代行サービスに申し込むと、 G-gen から利用者に対して 請求先アカウントが払い出され ます。利用者は、この請求先アカウントを自由にプロジェクトに紐づけて使用することができます。 この請求先アカウントをプロジェクトに紐づけた時点から、Google Cloud の利用料金は Google から G-gen に請求されます。G-gen は利用者の代わりに Google に料金を支払い、その後で、G-gen から利用者に対して割引料金で請求をします。 このような仕組みですから、すでに Google Cloud を自社のクレジットカード等で利用していても、プロジェクトの紐づけ先を G-gen の請求先アカウントに切り替えるだけで、請求代行サービスを利用することができます。このとき、原則的に システムの中断や利用可能な機能差などはなく 、G-gen 経由の支払いに切り替えて、 割引の恩恵を受ける ことができます。 また G-gen の請求代行サービスでは、当記事で紹介する課金レポートや予算アラートなど、請求先アカウントの管理機能も、制限なく利用できます。 当記事では G-gen 社のケースを紹介しましたが、パートナーによって仕組みが異なりますので、詳細はパートナーの営業担当者にお問い合わせください。 G-gen 社の請求代行サービスの詳細は、以下をご参照ください。 g-gen.co.jp Marketplace に関する注意点 Google Cloud Marketplace 経由で購入するサードパーティ製品は、再販の規定の関係でパートナー経由での販売ができない場合があります。 また Google 製品の中でも Google Maps Platform や Firebase など再販規定が少し特殊なサービスもあります。これらのサービスを利用している場合は、パートナーの営業担当者にお問い合わせください。 一方で、株式会社 G-gen の場合は MCPO（Marketplace Channel Private Offer）という仕組みにより、サードパーティ製品を Google Cloud Marketplace 経由で購入する際に割引の恩恵を得られる場合もあります。以下の記事も参照してください。 blog.g-gen.co.jp 課金レポート 課金レポートとは Google Cloud の課金情報を閲覧できる 課金レポート 機能があります。Google Cloud コンソールで お支払い > レポート へ遷移することで、請求先アカウントごとに詳細に課金内容を可視化できます。なお、G-gen の請求代行サービスでは、お客様は自由に課金レポートを閲覧できます。 参考 : Cloud Billing レポート 課金レポート このレポート画面では、以下のような切り口で課金額をグラフィカルに表示できます。 プロジェクトごと サービスごと SKU（課金単位）ごと リソースに付与したラベルごと リージョンごと 上記の掛け合わせ レポートのコツ Google Cloud コンソール画面で お支払い > レポート に遷移して課金レポートを表示した際、初期状態ではグラフ上部の「グループ条件」フィルタで「サービス」が選択されている場合があります。 「サービス」でグルーピングされている この状態では、課金額がサービスごと（Vertex AI、BigQuery、Compute Engine など）に表示されます。この表示方法だと、それぞれのサービスで「なぜ」課金が発生しているのか、理解することができません。BigQuery の料金を節約したいと考えた時、スキャン量に対する課金が発生しているのか、ストレージ料金に対する課金が発生しているのかを確認しなければ、適切な対処を打つことができません。 「グループ条件」フィルタ で「SKU」を選択することで、より細かい軸で課金額を表示できます。 「グループ条件」フィルタ SKU とは、Google Cloud の最小の課金単位です。例えば BigQuery であれば、 Analysis (asia-northeast1) という SKU は東京リージョンにおけるオンデマンド課金モードでのスキャン料金を示しており、一方で Active Logical Storage (asia-northeast1) は東京リージョンにおけるストレージ料金を示しています。 参考 : SKU Groups - BigQuery 参考 : SKU Groups 「SKU」でグルーピングした表示 レポートを SKU 単位で表示することで、コスト削減などにおける適切な打ち手を検討することができます。 また、グループ条件では他にも「プロジェクト」「プロジェクト階層（組織、フォルダ等）「ロケーション（リージョン）」の単位でのグルーピングを指定できるようになっています。また表示対象の SKU やプロジェクトを指定して表示対象を絞ることもできるなど、詳細に表示をコントロールできます。 課金レポートをうまく使うと、以下のような流れで、Google Cloud のコスト削減施策を検討することができます。 グループ条件を「SKU」にして課金レポートを表示 特に料金のかかっている SKU を特定 SKU フィルタで、特定した SKU だけに料金表示を絞る グループ条件を「プロジェクト」にして課金レポートを再表示 これにより、その SKU での課金が特に多く発生しているプロジェクトを特定 プロジェクトの担当者に対策を指示 Tips 課金レポートに関する Tips として、以下の記事も参考にしてください。 blog.g-gen.co.jp 管理機能 予算アラート 請求先アカウントに対して 予算 を設定し、その金額の n % に達したらメール通知する、などのアラート設定が可能です。 予算の粒度も、月ごと、四半期ごと、年間など任意の期間にできますし、予算の適用範囲プロジェクトやサービスも細かく選択できます。 例えば 「1ヶ月でXXXプロジェクトとYYYプロジェクトの合計予算を ￥2,000,000 とする。この予算に対し 50% に達したときと 75% に達したときにメールを発報する」 などの設定が可能です。 参考 : 予算と予算アラートを作成、編集、削除する 予算アラートの設定方法については、以下の記事もご参照ください。 blog.g-gen.co.jp 異常検知（Anomaly Detection） 請求先アカウントには、 異常検知 （Anomaly Detection）機能があります。 異常検知は、Google Cloud の突発課金を検知できる機能です。請求先アカウント単位で、過去の使用傾向が機械学習により学習され、通常パターンと異なる課金が発生すると異常（anomaly）として検知されます。 参考 : View and manage cost anomalies 当機能の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 課金データの BigQuery エクスポート 請求先アカウントの課金履歴を、 BigQuery へ自動エクスポート することができます。BigQuery により課金データの詳細な分析を行いたいときに活用できます。 エクスポートする内容は以下の3つから選択でき、それぞれ出力されるデータの粒度が違います。 標準の使用料金（Standard usage cost data） 詳細な使用料金（Detailed usage cost data） 料金（Pricing data） 「標準の使用料金（Standard usage cost data）」には、請求月、サービス、 SKU 、プロジェクト、ラベル、リージョン、費用、使用量、クレジット（割引）などの情報が含まれます。 「詳細な使用料金（Detailed usage cost data）」には「標準の使用料金」に含まれる情報に加えて、その料金を発生させたリソース名など個別リソースの情報が含まれます。リソースレベルでの分析が必要な場合に利用できます。 「料金（Pricing data）」をエクスポートすると、Google Cloud の最新の料金単価がエクスポートされます。Google Cloud の利用料金単価は変更されることがあるので、ここから最新の料金単価を取得することで、分析に活用できます。 詳細な仕様については、以下のドキュメントをご参照ください。 参考 : Cloud Billing データを BigQuery にエクスポートする 参考 : BigQuery 内の Cloud Billing データテーブルについて なお、これらの機能によって生成されたテーブルは自動的に「取り込み日付によるパーティション」が設定されます。BigQuery ではテーブルあたりのパーティションの最大数は 10,000 であり、これは日単位でのパーティションでは およそ27年で枯渇 することを意味しています。これを超えた場合、エクスポートがエラーとなることが考えられますので、長期利用が想定される場合はパーティションに27年程度の期限を設定し、データが自動削除されるように設定することが望ましいでしょう。その場合は、データのバックアップなどは別途、検討する必要があります。 プロジェクトと請求先アカウントのリンクを保護 プロジェクトと請求先アカウント間のリンクが誤って解除されないよう、ロックすることができます。 プロジェクトと請求先アカウントの紐づけが解除され、プロジェクトに請求先アカウントが紐づけられていない状態になると、一部の Google Cloud リソースが削除され、復元不能になる可能性があります。これに伴い、プロジェクト内のデータが消失するおそれがあります。 参考 : プロジェクトの課金を無効にする 誤操作等で紐づけが解除されてしまったり、異なる請求先アカウントに紐づけが変わることを防ぐため、リンクをロックすることが可能です。ロックするには Google Cloud コンソールの「課金」画面で「マイプロジェクト」タブへ遷移し、対象プロジェクトの三点リーダーから「請求をロック」を選択します。 参考 : プロジェクトと請求先アカウント間のリンクを保護する 請求先アカウントのロック AWS との違い Google Cloud と Amazon Web Services（AWS）の請求の仕組みとの違いも、簡単にご紹介します。 AWS では、クレジットカード等の請求先情報は AWS アカウントごとに定義 します。「AWS アカウント」とはいわゆる「テナント」と言い換えることができ、 Google Cloud でこれに最も近い概念は「プロジェクト」です。 AWS では AWS アカウントごと に請求情報を設定するのが基本です。複数の AWS アカウントの請求をまとめるには Consolidated Billing という機能を利用します。ある AWS アカウントを 管理アカウント （旧称マスターアカウント）とすることで、管理アカウントに請求をまとめることができます。 AWSの請求の概念 一方で、Google Cloud は請求先情報の設定が 請求先アカウント として独立していて再利用可能です。 Google Cloudの請求の概念 まとめると、AWS では「請求先情報の設定は AWS アカウントの持つ属性」であり、Google Cloud では「請求先情報の設定はプロジェクトとは独立している」ということができます。これが、これら2つのクラウドの請求の仕組みにおける、大きな違いです。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさんこんにちは。G-genの鈴木ことすずたつです。 みなさまの会社や、コミュニティではタスク管理をどのように行っていますでしょうか？ 人によってはなにか独自のソフトウェア/クラウドサービスを導入して管理してる人もいるかと思います。 しかし！ Google Workspaceにはすでにその機能がある ので、今回はそちらを解説してゆきましょう。 この機能を利用することで、例えばお客様サポートであったり、社内のプロジェクトのタスク管理など、忘れやすいタスクを管理可能！ 共同タスクとは？ 共同タスクの利用方法 共同タスクの実際の利用 作業を割り当てる 作業をラベルで管理する 作業を完了させる 共同タスクとは？ まずはじめに、共同タスクに関して簡単に説明しますと、以下のようにメーリングリストで受信したメールを、メールとして処理するのではなく、 一つのタスクとして受信 する機能です。 受信したタスクは、メンバーによって各個人に割り当てることが可能で、そのタスクの進捗管理することでぬけもれを防止することができる機能です。 本機能はGoogle Groupの機能を応用したものになります。Google Groupというのは以下のように一言でいうと メーリングリストのようなもの です。 Google Groupとは 共同タスクの利用方法 実際に共同タスクを利用する場合、初期設定が必要になります。以下のグループ設定から「追加の Google グループの機能を有効にする」で 共同トレイを有効に しましょう。 ついでにそのすぐ下にある 共有ラベル も有効にしておくと便利ですので、このタイミングでONにしてしまいましょう。 共同タスクの設定方法(1) 共同タスクの設定方法(2) たったこれだけで共同タスクの設定方法は終わりです。 共同タスクの実際の利用 それでは早速利用していきましょう！ 大まかな作業としては以下になります。 ・作業を割り当てる ・作業をラベルで管理する ・作業を完了させる その前に、ではどうやったらこのグループに作業として追加できるのか？ それは簡単！この グループにメールを送信するだけ です。今回の場合はtask-mgmt@suzutatsu.onlineをメールアドレスに指定してますので、ここにメールを送信することで新しいタスクが追加されます。 これを応用することで例えばお客様からのご質問やサポートなど、きっちりとタスクとして管理可能なため、 ぬけもれ防止に繋がり、ひいてはお客様の信頼獲得へ！ 作業を割り当てる まずはじめに受信したタスクに関して担当を割り当ててみましょう。 以下のようにタスクをクリックし、右上のアイコンより担当者を指名することが可能です。 これでタスクが個人に割り当てられました。 タスクの割り当て 作業をラベルで管理する タスクが多くなってきたときに、 重要度で管理 したり、どの 部門で対応すべき事項 かなど、様々なラベルが必要になる場合があるかと思います。 その場合に役に立つのが最初に有効化しておいた共有ラベルになります。こちらを利用することで各タスクが一目瞭然！ 今回は緊急対応が必要という想定で設定してみましょう。 共有ラベルの設定(1) 共有ラベルの設定(2) 以下のように 緊急対応が必要 だということが一目瞭然ですね。 共有ラベルの設定(3) 作業を完了させる 受領したタスクの実施事項を完了したときにタスクの状態を完了にし、もう何もすることがないことを明らかにしましょう。 また、このときに共有ラベルを対応済み。などにしておくとよりわかりやすいですね。 タスクの完了(1) タスクの完了(2) これで共同タスクの一連の利用方法の解説は終わりになります。思ったよりも簡単だったのではないでしょうか？ Google Workspaceにはこのように実は簡単に使えるのだけども知られてない機能が沢山あります。 弊社ではGoogle Workspaceの使い方からサポートさせていただきますので、お気軽にお声がけください！ Google Cloud(旧GCP) / Google Workspace導入に関するお問い合わせ Google Workspace 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-genの杉村です。管理対象の Compute Engine インスタンス（VM）が多いと、課題になるのがログインユーザーの管理です。Google Cloud（旧称 GCP）のサービス Google Compute Engine（GCE）には OS Login 機能 があり、SSH ログインユーザーを効率的に管理できます。 OS Login について OS Login とは ポイント メリット 設定手順 Step 1. OS Login 有効化（メタデータ設定） Step 2. IAM ロールの付与 ログイン手順 OS Login について OS Login とは OS Login は Compute Engine の SSH ログイン時の認証を IAM で管理するための仕組みです。 OS Login 機能では、 VM へ SSH ログインするユーザを Google アカウントと連動して管理 できます。なお、当機能で管理できるのは SSH ログインであるため、対象は Linux VM のみであり、Windows Server は対象外です。 OS Login 機能をプロジェクトごとに、またはインスタンスごとに有効化すると、SSH ユーザーを Google アカウントやグループと紐づけて管理できます。Google アカウント（グループ）に付与する IAM ロールによって、 VM へのログイン可否 と、 sudo 可否 を指定できます。 なお OS Login は、無料で使用できます。 参考 : OS Login の概要 OS Login機能の概念 ポイント 有効化 / 無効化は Compute Engine のメタデータ（インスタンス単位 / プロジェクト単位）で指定する 公開鍵 / 秘密鍵は自動生成されインスタンスの中に連携される OS Login では OS ユーザーが <アカウント名>_<ドメイン名> という名称で自動作成される 例: john@g-gen.co.jp → john_g_gen_co_jp 2段階認証が設定可能 メリット VM にログインできる利用者を Google アカウント（グループ）で管理できるため、 OS ユーザー統制の改善 や 管理・運用の工数削減 が期待できます。 ログイン時の2段階認証も簡単に設定できるので、セキュリティレベルの向上も見込めます。 反対に OS Login 機能を利用しないで SSH ユーザーを管理する方法には、 メタデータマネージド SSH 接続 があります。こちらの場合、例えば gcloud compute ssh でログインが行われると、操作した PC 環境のローカルユーザーの名称で、OS ユーザーが VM 上に自動作成されます。この方法では、VM に OS ユーザーが乱立してしまうおそれがあります。 参考 : メタデータ マネージド SSH 接続 設定手順 参考 : OS Login を設定する Step 1. OS Login 有効化（メタデータ設定） まず、OS Login 機能を プロジェクト単位 で有効化するのか、あるいは インスタンス単位 で有効化するのかを決定します。 OS Login を有効化するには、指定のキー・バリューをメタデータに設定する必要があります。Compute Engine メタデータは、プロジェクト単位のメタデータとインスタンス単位のメタデータあります。 プロジェクト全体で有効化するには、プロジェクトの Compute Engine メタデータに enable-oslogin = TRUE を設定します。 プロジェクトレベルのメタデータ 一方でインスタンス単位で有効化するには、個々のインスタンスの 編集 画面から、メタデータに enable-oslogin = TRUE を設定します。 インスタンスレベルのメタデータ 2段階認証を有効化したい場合は、この時点でメタデータに enable-oslogin-2fa = TRUE も併せて設定してください。 OS Login 機能の2段階認証は、 Google アカウントに設定された二段階認証の要素を利用します。たとえば、Google Authenticator の OTP 入力を促されたり、スマホの Google アプリの承認ボタンを押すことを促されたりするなどです。 Step 2. IAM ロールの付与 OS にログインさせたい Google アカウントまたは Google グループに、IAM ロールを付与します。 なお IAM のベストプラクティスとして、IAM ロールはアカウントに直接付与するのではなく、グループに付与することが推奨されています。 OS Login を使うには、以下の いずれか の IAM ロールを付与します。 sudo 権限なしの場合 roles/compute.osLogin （日本語名: Compute OS ログイン ） sudo 権限ありの場合 roles/compute.osAdminLogin （日本語名: Compute OS 管理者ログイン ） IAM ロールは 組織レベル プロジェクトレベル 個別インスタンスレベル のいずれかで付与することで、その Google アカウント（グループ）がどのインスタンスにログインできるか、が決まります。 組織レベルで付与すれば組織配下の全てのインスタンスに、プロジェクトレベルで付与すればプロジェクト内の全てのインスタンスに、インスタンスレベルで付与すればそのインスタンスだけに、SSH ログインできるようになります。 IAM の基本的な仕組みについては、以下の記事も参照してください。 blog.g-gen.co.jp ログイン手順 OS Login を有効化すると、コンソールから SSH ボタンを押下したり、gcloud コマンドを使って VM にログインする際に、自動的に OS Login による認証が行われ、ログインできるようになります。 コンソールからのSSHログイン gcloud コマンドであれば、通常の SSH ログイン時と同じように、以下のように実行するだけです。 gcloud compute ssh --project=${PROJECT_ID} --zone=${ZONE} ${VM_NAME} もしメタデータに enable-oslogin-2fa = TRUE が設定されていれば、このタイミングで2段階認証が求められます。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは！G-genの小林です。みなさんGoogle Cloudはご利用されてますでしょうか？お客様とお話ししている中でGoogle Cloudを使ってみているけど、最初に何を設定しておくべきなのか分からなくて困っている、という声をよく伺います。当記事では、Google Cloudをセキュアに使うためにはどうするべきなのかについて説明します。 はじめに 最初に対応すべきチェックリストの確認方法 組織と ID ユーザーとグループ 管理者アクセス お支払い リソース階層 リソースのアクセス ネットワーキング モニタリングとロギング セキュリティ サポート（カスタマーケア） はじめに 当記事では、Google Cloudを利用開始したばかりの方が、セキュアに利用するために必要なことを説明します。 「Google Cloudを社内で使ってみようとしているけど、必要最低限の設定をした状態でユーザーに使わせたい」「本番利用する場合のこれだけは設定しておくべき項目を把握しておきたい」と考えているクラウド管理者の方向けの内容です。 なお、当記事で紹介する Google Cloud コンソール画面は2021年10月現在のものです。最新の状態とは異なる場合がある点にご留意ください。 最初に対応すべきチェックリストの確認方法 Web ブラウザで Google Cloud にログインし、[IAMと管理] -> [IDと組織] にアクセスします。画面上部のプロジェクトセレクタで組織を選択すると、以下の表示になります。 この画面では、Google Cloudを利用する際の推奨設定が案内されます。[チェックリストに移動] をクリックすると、以下の画面になります。 ここに記載されている項目を1つずつ対応することで、Google が推奨する本番ワークロードに適した環境設定を行うことができます。 なお、見ていただくと分かる通り非常に多くの対応項目があります。Google Cloudを初めて利用する人にとっては分からない用語や理解に時間がかかる項目がちらほら...。 そのため、以降の本投稿では具体的にどのような設定が必要か簡単かつわかりやすく解説したいと思います。 組織と ID Google Cloud を管理したり、Google Cloud 上で開発したりする人のアカウントは、Cloud Identity もしくは Google Workspace で管理されます。 Google Workspace をすでに利用している組織の方は、そのアカウントを使って Google Cloud を利用することが可能です。Google Workspace を利用していない組織の方は、Cloud Identity の新しい組織（テナント）を開設する必要があります。Cloud Identity Free edition は、50アカウントまで無料で利用することができます。 実施内容 Cloud Identity もしくは Google Workspace を利用している場合 ドメインの所有権の証明が完了しているかチェック Cloud Identity もしくは Google Workspace をまだ利用していない場合 Cloud Identity の新規登録 ドメインの所有権の証明が完了しているかチェック 組織についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp ユーザーとグループ ユーザーやグループを作成します。 Google Cloud で使用するユーザーアカウントやグループは、Google Cloud コンソールで作成するのではありません。前述のとおり、Cloud Identity もしくは Google Workspace の管理コンソールで作成します。Google Workspace で作成したユーザーアカウントやグループを、そのままGoogle Cloud でも使用するイメージです。 実施内容 ユーザーの追加 グループの作成 ユーザーをグループに追加 このとき、Google Cloud の組織管理者、請求管理者、プロジェクトごとの管理者など、役割ごとにグループを作ることが推奨されます。 管理者アクセス この項目では、1つ前の項目で作成したグループに対して IAM ロールを割り当てます。 なお、この作業は Cloud Identity または Google Workspace の特権管理者が行う必要があります。Cloud Identity または Google Workspace アカウントの特権管理者は、最初から Google Cloud の「組織の管理者」ロールの権限を持っています。 実施内容 グループへの IAM ロールの割り当て IAM の仕組みについては、以下の記事も参照してください。特に、クラウドを管理する役割の方は IAM の仕組みを正確に理解することが強く推奨されます。 blog.g-gen.co.jp お支払い この項目では Google Cloud の支払いを行う請求先アカウントの作成をします。Google Cloud は支払いの設定がなくても一部の機能を利用できますが、すべての機能を利用するには Google Cloud プロジェクトに対して 請求先アカウント の紐付けが必須になります。 実施内容 請求先アカウントの作成 請求先アカウントをユーザーが自ら作成すると、Google と直接契約することになります。G-gen のようなリセラー（代理店）と契約し、請求先アカウントを発行してもらうことも可能です。リセラー経由で請求先アカウントを発行してもらうと、 割引 や 無料の技術サポート窓口 、日本円・請求書払いができるなど、リセラー独自のサービスを受けることができます。 請求先アカウントについては、以下の記事も参照してください。 blog.g-gen.co.jp リソース階層 Google Cloudは以下のようなリソース階層で成り立っています。 この項目では、フォルダとプロジェクトを作成します。 Google Cloud プロジェクト は最下層の管理単位であり、Compute Engine VM や BigQuery テーブルなど個々のリソースを配置する管理オブジェクトです。Amazon Web Services（AWS）でいうところの「AWS アカウント」といえます。 フォルダ は、プロジェクトをグループピングするための管理オブジェクトです。 Google Cloud のフォルダやプロジェクトの詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 実施内容 リソース階層の計画 フォルダの作成 プロジェクトの作成 プロジェクト作成時に、紐づける請求先アカウントを選択します。そのプロジェクトで発生した課金は、紐づけた請求先アカウントに対して発生します。1つの請求先アカウントには複数のプロジェクトを紐づけることができます。どのプロジェクトでどのような課金が発生したかは、請求先アカウントの課金レポートで詳細に確認できます。 リソースのアクセス Google Cloud では、個々のリソースが持つ IAM 設定値（このリソースに対して、誰がどのような権限を持っているか）のことを IAM ポリシー と呼びます。例えば、ある Compute Engine VM の IAM ポリシーには「 user01@example.com が管理者権限を持つ」のように定義できます。 この項目では上記のような IAM ポリシーの設定を実施します。IAM ポリシーなどの概念については、以下の記事をご参照ください。 blog.g-gen.co.jp 実施内容 組織レベルの IAM ポリシー設定 フォルダレベルの IAM ポリシー設定 プロジェクトレベルの IAM ポリシー設定 ネットワーキング VPC ネットワーク、Cloud VPN、Cloud NAT、VPC ファイアウォール等、主にネットワークに関連する初期設定を行う項目です。 すぐには設定が不要な項目もあるはずですので、必要に応じて作業を行ってください。 実施内容 VPC 設定 共有 VPC 設定 IPSec VPN 設定 Cloud NAT 設定 ファイアウォール設定 Cloud Load Balancing 設定 Google Cloud のネットワークの基本的な知識については、以下の記事も参照してください。 blog.g-gen.co.jp モニタリングとロギング この項目ではモニタリングとロギングの設定を行います。モニタリングは Cloud Monitoring、ロギングには Cloud Logging を利用します。 Cloud Monitoring は Google Cloud サービスからパフォーマンス指標を取得、保管、閲覧するサービスです。この項目では、モニタリング用のプロジェクトを作成し、そのプロジェクトでパフォーマンス指標を一括管理するために、他のプロジェクトを登録するための設定を行います。 Cloud Logging は Google Cloud サービスからログを収集、保管、閲覧するサービスです。この項目では、ログ集約用のプロジェクトを作成し、複数のプロジェクトから取得されたログをロギング用プロジェクトの BigQuery に一括収集する設定を行います。 実施内容 モニタリングの設定 ロギングの設定 Cloud Monitoring や Cloud Logging については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp セキュリティ プロジェクトの保護に役立つセキュリティ設定を行います。 Security Command Center とは、Google Cloud サービスの構成ミスや脆弱な設定がないかチェックする脅威検出サービスです。スタンダードティアは無料で利用できます。 組織ポリシー は、組織内で利用可能なサービスや実施可能な操作、適用可能な設定などを制限する強制的なルールを定義できる仕組みです。例えば、特定のリージョン以外の使用を制限することや、利用可能な Google Cloud APIs を制限することが可能です。 実施内容 Security Command Center の設定 組織ポリシーの設定 Security Command Center や組織ポリシーについての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp サポート（カスタマーケア） 障害時等に備えて、公式の技術サポートを利用したいと思うことがあるはずです。Google Cloud には カスタマーケア と呼ばれるサポートサービスがあり、無償のプランと有償のプランがあります。 無償プラン（ベーシック）の場合、課金に関する質問のみを問い合わせることができます。技術的な質問が可能な有償プランには複数あり、プランによって日本語対応の有無や、回答時間の差異があります。 実施内容 カスタマーケアの申し込み このときカスタマーケアを申し込む操作者は、組織レベルで「組織の管理者（ roles/resourcemanager.organizationAdmin ）ロール」と「サポート アカウント管理者（ roles/cloudsupport.admin ）ロール」が必要です。さらに、請求先アカウントに対する「請求先アカウント管理者（ roles/billing.admin ）ロール」などが必要です。 カスタマーケアのプランについては、以下の公式ページを参照してください。 参考 : Google Cloud カスタマーケア 小林 あゆみ (記事一覧) クラウドソリューション部 営業チーム AWSエンジニアからGoogle Cloud営業に転向 福井からリモートワーク中 趣味はMonkey125でツーリング、Netflix鑑賞、旅行

G-gen の杉村です。 Google Cloud Next '21 の What's new with BigQuery セッションで発表された新機能を、速報としてご紹介します。 BigQuery はじめに BigQuery Omni (GA) BigQuery Security & Governance for Data Lakes (Coming soon) BigQuery External Functions Analytics Hub (Preview) BigQuery Migration Service (Preview) BigQuery 管理系機能 Admin hub & Resource charts (GA) Slot estimator (Preview) BigQuery Slots Autoscaling (Coming soon) Table Snaphosts and Clones BigQuery Storage Write API (GA) Search Indexes with BigQuery (Preview) BigQuery ML 関連 Explainable AI Integration with Vertex (Coming soon) Advanced Models & Techniques BigQuery BI Engine (GA) はじめに 2021年10月12日〜から14日の日程で Google Cloud Next '21 が開催されています。 What's new with BigQuery というセッションの中で、 Google Cloud のデータウェアハウスサービスである BigQuery の新機能の数々が発表されました。 特に BigQuery Migration Service という移行に活用できる機能や、 Table Snaphosts and Clones , Search Indexes with BigQuery といった BigQuery のユースケースを変えてしまう可能性すらある機能は注目です。 本投稿では、当該セッションで発表された新機能をご紹介します。なお記載の内容は セッションの発表があった 2021年10月13日現在の内容となっております 。 リリース状態や機能の内容は常に変化しておりますので、本投稿はあくまで速報記事であることをご理解ください。 BigQuery Omni (GA) AWS, Azure, Google に分散されているデータをSQLで横断クエリできる機能。 Google Cloud (GCP) 上のこれまでと同じ BigQuery のインターフェースで、Google Cloud や AWS、Azure に保存したデータを、クラウド間を移動したりコピーしたりすることなくクエリが可能となる。 Anthos の技術をバックエンドとして使い、例えば AWS 上で BigQuery のクエリエンジンが稼働し、 Amazon S3 等に保存されているデータにクエリを実行する。 参考: BigQuery Omni - マルチクラウド の分析でデータを活用 BigQuery Security & Governance for Data Lakes (Coming soon) BigQuery では Cloud Storage や Spanner など BigQuery の外部に存在するデータを外部テーブルとして定義することができるが、この外部テーブルに対する権限設定をきめ細かくできるようになる模様。 データレイクのセキュリティ向上が見込めるはずだ。 ※同機能は BigLake として 2022/01/25 に GA となりました。 BigQuery External Functions UDF (ユーザ定義の関数) を BigQuery の外部で定義できるようになった。 これまでも BigQuery では UDF を定義することはできたが、標準 SQL か Javascript で記述する必要があり、関数は BigQuery の内部に定義された。 今回のアップデートでは UDF が BigQuery の外部に定義できるようになり、そのランタイムにはご存知 Cloud Functions を利用しているので node.js / Python / Go / Java / .net / PHP などで記述できる。 参考 : リモート関数の操作 Analytics Hub (Preview) 組織 (Organization) をまたいでデータをやりとりできる仕組み。 Publisher (データ公開側) は Analytics Hub を通じてデータセットを公開でき、 Subscriber (データ利用者側) がこれを利用できる。 公開データをキュレーションしたり検索する仕組みが提供される模様。 Publisher がデータの利用状況を分析できるような仕組みも存在しているようだ。 参考 : Analytics Hub のご紹介 -- 簡単、安全、スケーラブルにデータ分析を共有 ※ Analytics Hub は 2022/10/11 にGA となりました。 BigQuery Migration Service (Preview) 他のデータウェアハウス製品から BigQuery への移行を支援するツールであるの Preview が発表された。 ソース DB へのアセスメント、 SQL (DDL, DML, BTEQ で書かれた PL) の変換、 移行先 BigQuery へのバリデーションを行う。 Walmart や Mercado Libre などで既に SQL 変換にこれを利用した実績があるという。 現在のところ、 Teradata がサポート対象となることが判明しているが、他の移行元も Coming soon としている。 参考 : BigQuery Migration Service の概要 BigQuery 管理系機能 Admin hub & Resource charts (GA) BigQuery 環境の詳細なモニタリング、管理、トラブルシュート、ボトルネック特定などに活用できる新しい管理コンソールが使えるようになった。 Slot Reservation (コンピューティング容量の事前購入。定額・大容量で BigQuery を利用できるようになる) を使用してワークロード管理を行っているユーザーにとって、強力な機能となるだろう。 Slot estimator (Preview) こちらも Slot Reservation を使っているユーザー向けの機能だ。 組織内でプロジェクトを横断してスロットの利用状況を確認できる他、スロットを追加購入すべきかどうかの判断の助けになる情報を提供する。 ※ Slot estimator は 2022/11/14 にGA となりました。 BigQuery Slots Autoscaling (Coming soon) 事前に定義した予算に基づいてスロットを自動でスケーリングする機能だ。 従来のオンデマンドモードだと、基本的にスロットは 2,000 が上限であり、ベストエフォートでのバーストを期待することができた。 当該機能がリリースされれば、ある程度の予測が難しいワークロードでもコストの無駄ナシで高いパフォーマンスを維持できるだろう。 ※当機能は BigQuery Editions の一機能として 2023/03/29 にGA となりました。 Table Snaphosts and Clones BigQuery でのデータの持ち方が大きく変わるかもしれない機能も発表された。 Snapshots (スナップショット) は読み取り専用のデータコピーであり、論理バックアップ目的やタイムトラベル機能 (7日間しか保持されない) 以上の保持期間で特定時刻のテーブル状態を保持したい場合に利用できる。しかもデータは、オリジナルテーブルから即座にコピーするのではなく、基本的にはオリジナルテーブルを参照したまま、変更や削除された場合のみデータが複製される (いわゆるコピー・オン・ライト) のためコストを抑えることが可能だ。 ※ Snapshot 機能は 2021/10/28 に GA となりました。 Clone (クローン) は Snapshots のデータ変更が可能なバージョンと考えればいいだろう。同じくコピー・オン・ライトでテーブルのクローンを作成する。発表ではアプリケーションに対する変更をテストする環境として利用するユースケースが挙げられた。 ※ Clone 機能は 2022/02/15 に Preview 公開 され、その後 2023/05/03 に GA となりました。 BigQuery Storage Write API (GA) BigQuery のストレージに直接 API を発行し、高スループットでのデータの書き込み等が可能になる。 費用も通常の INSERT より低く押さえられるため、大量データの投入では検討すべき選択肢だ。 参考 : BigQuery Storage Write API の使用 Search Indexes with BigQuery (Preview) なんと、 BigQuery でインデックスが使えるようになった ( Preview 公開の予定の発表であり 2022 年 1 月現在でまだ利用可能になっていない → 2022/04/07 に Preview 公開され 2022/10/27 に GA となった) 。 2022/04/11 更新 : 以下の当ブログ記事にて詳細を解説している。 blog.g-gen.co.jp 従来では BigQuery においてはインデックスは使えなかった。これが BigQuery のメンテナンス工数を減らす利点でもあった。 とはいえこれは BigQuery がテーブル単位・パーティション単位でのフルスキャンを行うことを意味しており、数ペタバイトにおよぶデータの中から特定のキーでデータを抜き出すようなワークロードに対して大量のスキャンが発生してしまうため、金銭的・時間的コストがかかってしまうことも意味していた。 本機能ではテーブルにテキストインデックスを作成し、特定の文字列を検索する性能を向上させることができる。 インデックスは自動的に更新されるため、いわゆる VACUUM のようなメンテナンスは依然として不要だ。 同じくプレビュー発表されたネイティブJSONタイプにも使用できる。 以下のようなユースケースが挙げられた。 選択範囲が非常に狭いフィルタを使ったダッシュボード (スライシング/ダイシングが必要) 目的となるデータのサブセットを大きなデータセットから見つけ出す (特定の情報を持った患者群を抜き出す) GDPR準拠のため特定ユーザのデータだけを抜き出して削除する ログから特定 IP アドレスを抜き出す BigQuery ML 関連 Explainable AI AI/ML 関連でよく話題になる「説明可能なAI」を実現するための機能だ。 学習データのうちどのような要素が結果に影響したのかを理解することを助ける。 Integration with Vertex (Coming soon) BigQuery ML が Vertex AI と連携する。 Vertex AI のパイプラインと連携することで BigQuery ML のモデルの学習やデプロイが強化される模様だ。 Advanced Models & Techniques XGBoost, Wide & Deep DNN (ディープニューラルネットワーク), AutoML Tables などがサポートされ、強化される。 BigQuery BI Engine (GA) プレビュー版で用意されていた機能が GA となった。 データポータル等の BI ツールから利用可能なキャッシュ機構で、利用には追加料金が発生する。 インメモリキャッシュ機構であり、有効化するだけで効果を発揮する。 参考 : BI Engine とは 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it