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

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

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

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

こんにちは、G-genの荒井（@arapote）です。みなさん、パブリッククラウドはご利用でしょうか？！既に利用されている企業様も多いかと思いますが、全国的にはまだまだオンプレミスを運用している企業も多くいらっしゃると思います。今回はそんな方々でも、かんたんにクラウドを体験していただけるよう、無料で Google Cloud（旧称 GCP）をご利用いただける方法をご紹介いたします。 Google Cloud って無料で使えるの？ 「無料枠」と「無料トライアル」 無料枠とは 無料枠の適用範囲 無料トライアルとは 利用イメージ 利用料金の例 Google Cloud 利用開始準備 手順の概要 必要なもの Googleアカウントの準備 無料 Google アカウントの作成 後編へ ※本記事に記載の情報は2024年11月時点のものです。 Google Cloud って無料で使えるの？ 早速本題の「 Google Cloud を無料で使えるか？ 」ですが、結論からお伝えしますと Yes です。とはいえ、もちろん完全に無料というわけではありません。いくつか条件がありますのでご紹介いたします。 Google Cloud には、 無料枠 と 無料トライアル があります。これらを利用することで、Google Cloud を無料で利用することができます。それでは、それぞれの内容を確認していきましょう。 無料枠と無料クレジットの詳細は、以下の公式ドキュメントをご確認ください。 参考 : Google Cloud の無料プログラム 「無料枠」と「無料トライアル」 無料枠とは 無料枠 とは、Google Cloud のプロダクトごとに設けられた、 一定量まで毎月無料 で利用することができる仕組みです。 この無料枠は後述の無料トライアル期間とは関係なく設けられており、毎月、定められた量を無料で利用できます。この無料枠を超えた分については、通常どおり課金されます。人気のプロダクトにも無料枠が設定されていますので、Google Cloud を無料で、あるいは安価に利用することができます。無料枠の例は、以下の通りです。 プロダクト名 無料枠 BigQuery ・1TB のクエリ ・10GB のストレージ Cloud Storage ・5 GB の保管料金（ us-west1 、 us-central1 、 us-east1 のみ。Standard Storage） Compute Engine ・e2-micro タイプの VM 1台（ us-west1 、 us-central1 、 us-east1 のみ。Standard Storage）ほか 適用リージョンの指定など、制限については以下のドキュメントをご確認ください。 参考 : 無料枠の使用量上限 無料枠の適用範囲 Google Cloud の無料枠は、特記がない場合は「請求先アカウント」の単位でカウントされます。Google Cloud プロジェクトが複数あっても、 同じ請求先アカウントに紐づいていれば、1つの無料枠を共有する ことになります。 参考 : 無料枠 請求先アカウントについては、以下の記事も参照してください。 blog.g-gen.co.jp 無料トライアルとは 無料トライアル は、Google Cloud を初めて利用される方向けに $300のクレジット が付与される仕組みです。こちらのクレジットには、 90日間 という有効期間があります。90日経過後、クレジットは消滅してしまいます。 このクレジットを使うことで、$300 分までは無料で Google Cloud を試用できます。 無料トライアルの対象となる条件などについて、以下のドキュメントに記載がありますのでご確認ください。 参考 : 90 日間 $300 分無料トライアル 利用イメージ 無料枠 と 無料トライアル をご紹介しましたが、文字だけだと少しわかりにくいと思うので利用例を図にしてみましょう。わかりやすくするために、1ヵ月を30日としています。 課金が発生するケースは、以下のどちらか（もしくは両方）を満たした場合となります。 $300のクレジットを超過した 90日経過後も利用を継続している しかし重要なポイントとして、 $300を超えた 、あるいは 90日間が経過した からといって勝手に課金が開始されるわけではありません。サービス利用開始時にクレジットカードの情報登録作業があるものの、自動課金にはなりません。（これ、良心的ですよね！） コンソール画面上にこのような親切な表示があり、利用者が自身で課金を有効にしない限り、クレジットカードを登録しても課金は始まりません。 なお、無料クレジットを使い切ってもGoogle Cloud を継続的に使いたいという方向けに、G-genではGoogle Cloud を3%OFF〜でお得にご利用いただけるサービスがあります。詳細は以下の記事を参照してください。 g-gen.co.jp 利用料金の例 無料クレジットが$300付与されるとご紹介しましたが、これって多いの？少ないの？そんな疑問が出てきた方がいらっしゃるのではないでしょうか。 一例ですが、Google Cloud で仮想サーバーを運用した場合の利用料金の例を記載します。 マシンタイプ : e2-standard-4（vCPU 4、RAM 16 GiB） ストレージ : 100 GiB OS : Windows Server または Ubuntu 上記のようなスペックの場合、Windows Server では $272.83 、Ubuntu（あるいはライセンス料のかからない OS）の場合は $138.51 / 月 です（いずれも2024年11月現在、東京リージョン）。 1ヵ月間、仮想サーバーを起動し続けてもこの料金です。Compute Engine は従量課金制（マシンが起動している間のみ料金が発生）なので、利用していないときはマシンを停止するなど工夫すると、さらに効率的に利用できるのではないでしょうか。 Google Cloud 利用開始準備 手順の概要 Google Cloud は使い方次第で無料で利用できることがわかりましたので、利用の準備を進めましょう。利用開始までの大きな流れは、以下の通りです。 Google アカウントの準備 Google Cloud 利用情報登録 Google Cloud 初期設定 必要なもの Google Cloud を利用するために必要な環境を事前に準備しておきましょう。 インターネットに接続できる PC Google アカウント SMS が受信できる電話番号 クレジットカード（登録は必須ですが、課金は任意） Googleアカウントの準備 Google Cloud を利用するためには、Google アカウントが必要です。Google アカウントは大きく分けて、3つの準備方法があります。 Cloud Identity で Google アカウントを管理する（自社ドメインが必要、無償または有償） Google Workspace で Google アカウントを管理する（自社ドメインが必要、有償） 無料 Gmail アカウント を利用する Google アカウントに関する詳細は、以下の記事もご参照ください。 blog.g-gen.co.jp 無料 Google アカウントの作成 すでに Gmail などを利用されている方は、そのアカウントでも利用が開始できます。Gmail も Google アカウントも持っていない方は、 Google アカウントのログインページ で「アカウントを作成」をクリックし、指示に従って入力を進めることで無料の Google アカウント（Gmail アカウント）を作成できます。 ただし、企業や官公庁などの組織で Google Cloud を使う場合は、Cloud Identity や Google Workspace で Google アカウントを管理することが強く推奨されます。無料で Cloud Identity 組織を作成する方法は、以下をご参照ください。 blog.g-gen.co.jp 後編へ ここまで準備ができたら、あとは Google Cloud にアクセスして利用開始手順を進めることができます。利用開始手順は、後編でご紹介いたします。 blog.g-gen.co.jp また、以下のリンク集では各プロダクトをわかりやすく解説した当社記事がまとまっています。ブックマーク必須です！！ blog.g-gen.co.jp 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

こんにちは、G-genの渡邉@norry です。 皆さんCloud Logging は活用されていますか？ Cloud Logging は Google Cloud (GCP) 上のシステム等が生成したログを収集・保管・管理する仕組みです。 まずはCloud Logging とは何か？ をしっかり理解したい方は以下の記事をおすすめします。 blog.g-gen.co.jp 本項では GCP 上の Windows VM より Google Cloud オペレーションスイートのエージェント ( Ops Agent ) を利用して Cloud Logging にログファイルを収集する方法をご案内します。 Ops エージェント概要 Ops エージェントとは サポートされるOS Ops エージェントの機能 標準対応しているサードパーティアプリ Ops エージェントのインストールと起動確認 インストール方法 起動確認 任意のログの取得方法 Ops エージェントの構成 Windows VM での設定手順実例 Ops エージェント概要 Ops エージェントとは Ops エージェントは、Compute Engine インスタンスから テレメトリー (稼働データ) を収集して Cloud Monitoring や Cloud Logging に送信するエージェントソフトウェアです。 公式ガイドは コチラ を参照くだい。 Ops エージェントではログの取得と指標 を 一つのエージェント に統合している部分がポイントです。以前は指標の収集送信に "Cloud Monitoring エージェント" を、ログの収集には "Cloud Logging エージェント" を、というように別々のエージェントが存在していました。現在ではこれらが Ops エージェントとして統合されています。 また、ここで言う ログ はシステムから出力される何らかのイベントログやアプリケーションから出力されるテキスト形式のログのこと、 指標 は例えば1秒間あたりにどのくらいのCPUやメモリの使用率があったかと言うような 稼働状況 と捉えていただいても問題ないかと思います。 Ops エージェントはログに Fluent Bit を使用しており、高スループット ロギングと指標の OpenTelemetry Collector がサポートされています。 サポートされるOS エージェントは標準的な Linux 及び Windows ディストリビューションで稼働します。 サポート対象 OS の一覧は コチラ です。 Ops エージェントの機能 ロギング関連の主要な機能は次のとおりです。 設定なしで標準のシステムログ（Linux の /var/log/syslog と /var/log/messages、Windows のイベントログ）を収集 カスタム ログファイル JSON ログ。 書式なしテキストのログ 正規表現を使用した解析。 JSON ベースの解析 任意の形式のログを取得する際に、正規表現でログを抽出しJSON 形式に変換し Cloud Logging に送信する事が可能です。 標準対応しているサードパーティアプリ Ops エージェントではサポートされているサードパーティ アプリケーションの自動ログ解析が可能となっています。その場合にはファイル解析をする為に Ops エージェントを構成します。この構成については後述します。 2022年2月時点での対応サードパーティアプリは次のとおりです。 Apache Tomcat Cassandra Elasticsearch IIS (WIndows のみ) JVM MariaDB Memcached MS SQL Server (WIndows のみ) MySQL Nginx PostgreSQL Redis なお、ここにリストされているソフトウェア以外の収集も、カスタム構成を行うことで 実現できます のでご安心ください (後述) 。 さらに参考として、モニタリング機能は次のとおりです (当記事では詳しく扱いません) 。 CPU 指標 ディスク指標 iis 指標（Windows のみ） インターフェース指標 メモリ指標 mssql 指標（Windows のみ） pagefile 指標（Windows のみ） スワップ指標 ネットワーク指標 プロセス指標 内部エージェント指標の選択: api_request_count memory_usage monitoring/point_count 稼働時間 Ops エージェントのインストールと起動確認 インストール方法 インストール方法については大きく下記 3つの方法 があります。 gcloud / エージェント ポリシーを使用して VM フリートにエージェントをインストール 自動化ツール (Ansible、Chef、Puppet、Terraform ) を使用して VM フリートにエージェントをインストールする 個々の VM に Ops エージェントをインストールする 今回は Windows VM で任意のログを取得する事を目的としていますので、さくっと 個々のVM に Ops エージェントをインストールする 方法で、インストールを行います。 Compute Engine ＞ 該当のWindows インスタンス ＞ インスタンスの編集 よりメタデータに以下の内容を記載します。 Ops エージェントインストール キー1 : windows-startup-script-ps1 値1: (New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1") Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall" 上記を記述し WIndows VM を起動すると自動的にインストールが開始されます、インストールは初回のみで良いのでインストールが終了したらメタデータの記述は消去しても大丈夫です。 起動確認 VM 起動後にOps エージェントが正常起動すると、 Google Cloud Ops Agent 、 Google Cloud Ops Agent - Logging Agent 、 Google Cloud Ops Agent - Metrics Agent のサービスが実行されている事が確認できます。 サービス起動確認 またGCP 管理コンソール ＞ ロギング ＞ ログエクスプローラー で RESOURCE TYPE にVM Instance が表示されWindows のイベントログが取得出来ている事が確認出来ます。 Cloud Logging 任意のログの取得方法 Ops エージェントの構成 前項で表記したデフォルトで取得するログ以外を取得する場合にはOps エージェントの構成の変更が必要になります。それ以外にも下記のような目的の時に変更が必要になります。 デフォルトのロギングや指標の取り込みをオフにする ログ収集元のファイルパスをカスタマイズする ログをJSON や正規表現で解析し構造を変更する 指標のサンプリングレートの変更 (60秒周期から30秒など) Ops エージェントはデフォルトの構成があり、その構成は直接操作する事は出来ません。そのかわりにユーザー側で追加・変更の構成ファイルを作成しデフォルトの構成にマージ・上書きします。適用にはOps エージェントのサービス再起動が必要になります。 把握しておくべき構成要素は次の通りです。 receivers: この要素はエージェントによって収集される内容を表します。(ログの場所の指定など) processors: この要素は、エージェントが収集した情報を変更する方法を記述します。(ログを正規表現で抽出、JSON形式で格納など) service: この要素は、レシーバーとプロセッサをリンクして、パイプラインというデータフローを作成します。service 要素には、複数のパイプラインを含めることができる pipelines 要素が含まれます。 Windows のOps エージェントではデフォルトの構成では次の通りです。デフォルトの内容を変更したい場合にはユーザー側で新たに設定ファイルを作成します。 logging: receivers: windows_event_log: type: windows_event_log channels: [System, Application, Security] service: pipelines: default_pipeline: receivers: [windows_event_log] metrics: receivers: hostmetrics: type: hostmetrics collection_interval: 60s iis: type: iis collection_interval: 60s mssql: type: mssql collection_interval: 60s processors: metrics_filter: type: exclude_metrics metrics_pattern: [] service: pipelines: default_pipeline: receivers: [hostmetrics, iis, mssql] processors: [metrics_filter] 詳しくは コチラ を参照ください。 Windows VM での設定手順実例 ユーザーがデフォルトで収集されないログ、例えばベンダーのパッケージ製品のテキストログを Cloud Loggingに集約する場合を想定して設定確認をしてみます。 今回は コチラ の簡易的なWeb サーバーを利用してそのログを Ops エージェントを通じて Cloud Logging へ送信します。 Webサーバーの構成は次の通りです、実行ファイルと同一フォルダにHTTDir.log というログファイルが出力されました。 log Web サーバー起動時のログはこのような内容です。 [2/17/2022 12:22:51 AM] awdss_1 [2/17/2022 12:22:51 AM] awdss_2 [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\Get.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\HTT.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\HTTDir.exe [2/17/2022 12:22:51 AM] awdss_self_noop [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\MimeType.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_3 [2/17/2022 12:22:51 AM] awdss_4 Windows では以下のパスにある yaml ファイルをメモ帳などで編集します。 C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml 今回は次のように設定しました。 logging: receivers: HTTDir_general: type: files include_paths: [C:\HTTDir\*.log] service: pipelines: HTTDir_general: receivers: - HTTDir_general 内容について詳述します。 logging: ログを収集して送信します、指標を取得する場合は metrics: で記述します。 receivers: どのデータを収集するかの指定 HTTDir_general: RECEIVER_ID と呼ばれるIDです、任意のIDを設定します。 type: どの形式で取得するかを指定します、 files syslog windows_event_log などが指定可能です。 include_paths: type が files の場合、取得するログが保存されている場所を指定します。 service: receivers: と processors: を紐づけて Cloud Logging へ送信します。重要度に応じてレベル分けも可能となっています。 pipelines: パイブライン名を HTTDir_general: としています。 receivers: レシーバー名 HTTDir_general の内容を Cloud Logging へ出力します。 Cloud Logging ＞ [VM Instance] ＞ [Log Name] で確認すると次のようになります。 IDで設定した名前でログが登録されている事が分かります。 Cloud Logging への出力 また、ログの中はこのようになりました。 jsonPayload 内にログが、まるっと格納されている事が確認できます。 jsonPayLoad の内容 jsonPayload の中にそのままメッセージ内容を入れるだけであればこのままで良いですが、フィールドとして表記したい場合やタイムスタンプとしてjsonPayload 外に値として取り入れたい事もあるかもしれません その場合は config.yaml に processors: を追記、正規表現を用いてフィールドに格納します。 今回は単純なログですので簡単に time フィールドと msg フィールドに分けてみました。 logging: receivers: HTTDir_general: type: files include_paths: [C:\HTTDir\*.log] + processors: + HTTDir_general: + type: parse_regex + regex: "\[(?<time>[^\]]+)]\s+(?<msg>.*)$" service: pipelines: HTTDir_general: receivers: - HTTDir_general + processors: + - HTTDir_general 追記部分の補足をします。 processors: レシーバーで得たデータを操作します。 HTTDir_general: PROCESSOR_ID を指定します。今回はRECEIVER_ID と同一名にしています。 type: ログの内容を解析・変換方法を指定します。 parse_regex では正規表現を使って解析し、JSON形式に変換します。元々のログ形式がJSON の場合は parse_json を利用します。 regex: type に parse_regex を指定した場合必須、正規表現で内容を解析し各キーにあてます。今回は正規表現を用いて 時間とメッセージで抽出しています。 service: processors: のPROCESSOR_IDを追記しています。 上記内容にconfig.yaml を変更しOps Agent サービスを再起動した後の jsonPayload の内容は次の通りになりました。 jsonPayload 内でtime キー と msg キーでログの値が抽出されている事が分かります。 key:value に分割 サポートされているサードパーティアプリであれば正規表現等は使わずとも良い感じにCloud Loggingへ収集してくれますので興味がある方は 公式ドキュメント を読んでみてください。 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-gen の杉村です。当記事では、Google Cloud の認定資格である Professional Cloud Security Engineer 試験 の出題傾向や対策、知っておくべき技術領域などについて紹介します。 概要 Professional Cloud Security Engineer とは 難易度 推奨の勉強法 出題傾向 責任共有モデル 組織のポリシー 基本的な知識 把握しておくべき制約 Cloud Identity と ID 連携 アカウントとグループの管理 アカウント連携（プロビジョニング） Workload Identity Identity and Access Management（IAM） 基本的な知識 基本ロールと事前定義ロール コンピュートリソースと IAM ネットワークセキュリティ Virtual Private Cloud（VPC） VPC に関する参考記事 ハイブリッドネットワーク Cloud Armor、Cloud IDS Cloud Logging と Cloud Audit Logs 暗号化 Cloud KMS（Key Management Service） エンベロープ暗号化 デフォルトの暗号化と CMEK 暗号化 Sensitive Data Protection Sensitive Data Protection とは PII の発見と保護 DevSecOps（CI/CD） VPC Service Controls Security Command Center Compute Engine Confidential Computing Shielded VM その他のプロダクト Network Intelligence Center Secret Manager Google Cloud セキュリティの全体像把握 概要 Professional Cloud Security Engineer とは Professional Cloud Security Engineer は、Google Cloud（旧称 GCP）のセキュリティ関連の知識と実務能力を問う認定資格です。 試験時間は120分、出題は50問〜60問の多肢選択式です。問題文はそこまで長くないため、落ち着いて解ければ十分な余裕があります。 なお、当試験は2022年2月までは英語版のみの提供でしたが、2022年3月より日本語での提供が開始されました。 参考 : Professional Cloud Security Engineer 当記事では、Professional Cloud Security Engineer 試験の出題傾向について紹介します。当記事で学習の方向性を決定し、実務にも応用可能な知識を習得してください。 難易度 当試験の難易度は、 中程度〜比較的高い と言えます。「応用情報技術者試験」程度の IT 基礎知識があり、かつ Google Cloud をある程度業務で使用した経験がベースとしてあることが望ましいです。 これに加えて、ネットワークセキュリティや Web アプリケーションセキュリティに関する基本知識を持っていることが望ましいです。IPA のネットワークスペシャリストや、情報処理安全確保支援士（旧セキュリティスペシャリスト）の知識も役立ちます。 なお Associate Cloud Engineer や Professional Cloud Architect 試験を先に取得しておくと、Google Cloud の基本知識が事前に習得できるため、学習コストが下がります。逆にいうと、これらの資格を既に取得済みの方であれば、あとは当記事を参考にして知識をアドオンしていけば、合格は難しくありません。 参考 : Associate Cloud Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog 参考 : Professional Cloud Architect試験対策マニュアル - G-gen Tech Blog 推奨の勉強法 Associate Cloud Engineer を取得する ただし Professional Cloud Security Engineer の受験手続きにあたっての必須要件ではありません 書籍、各社のブログ記事、公式ドキュメント等で Google Cloud のセキュリティ関係サービスの概要を理解する。特に以下のサービスに着目する IAM、組織（Organization）、組織のポリシー、VPC、Cloud Identity、Cloud KMS、Cloud DLP 試験ガイド を読み、出題範囲を理解 当記事を読み、出題傾向を把握 把握した試験範囲・出題傾向をもとに勉強 Google Cloud に限らない一般的なセキュリティ系知識（暗号化、ネットワーク、 Web アプリセキュリティ等）もこれを機に勉強し、理解する 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする 出題傾向 当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきます。わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。そのように勉強すれば、試験に合格できるだけでなく、実践的な知識となるでしょう。 また、責任共有モデルや最小権限の原則をはじめ、多くのセキュリティの概念は、 Google Cloud に限らず情報セキュリティにおける一般的な知識です。この試験勉強を機に、セキュリティの基本的な知識を身につけ、実践できるようにしていくことが重要です。 なお、当記事の内容は2026年1月時点の、G-gen 従業員の受験体験に基づいています。 責任共有モデル クラウドユーザーが意識しておくべき最も重要なセキュリティの考え方として、 責任共有モデル があります。 どこまでがクラウド提供事業者（Google）の責任で、どこからが私たちクラウド利用者の責任なのか、自分の言葉で人に説明できるまで理解している必要があります。以下に、参考となるドキュメントへのリンクを記載します。 参考 : Google Cloud における責任と運命の共有 参考 : AWS クラウドセキュリティ - 責任共有モデル 責任共有モデルを理解しておけば、例えば Web アプリを Google Kubernetes Engine（GKE）などにホストした際に、私たちクラウド利用者が どの部分のセキュリティに責任を持つべきか 、という問いに答えられるようになります。 簡単に言うと、「データセンターの物理機器の管理は Google の責任」「マネージドサービスであれば概ね OS レイヤまでが Google の責任」であり、それ以外は私たちユーザーの責任です。つまり、Web アプリケーションのセキュリティ、すなわちセキュアコーディングであったり、 WAF（Web Application Firewall）がカバーすべきL7レイヤの脅威への対処は、私たち ユーザーの責任 です。 一方で、App Engine や Cloud Run のようなマネージドサービスでは、OS レイヤ以下は、 Google の責任 となります。 組織のポリシー 基本的な知識 当試験では、 組織のポリシー についての問題が頻繁に出題されます。 blog.g-gen.co.jp 以下のようなキーワードで、理解を深めてください。 制約 、 ブール型とリスト型 継承 （API パラメータとしては inheritFromParent : true または false ） 代表的な組織ポリシー（制約）の使い方 把握しておくべき制約 以下のような代表的な制約について、概要を把握してください。 参考 : ドメイン別の ID の制限 参考 : サービス アカウントの使用の制限 参考 : リソース ロケーションの制限 参考 : 公開アクセス防止を使用する Cloud Identity と ID 連携 アカウントとグループの管理 Cloud Identity（または Google Workspace）によるアカウントやグループの管理手法に関する質問に答えられるようにしてください。 あまり知られていない事実として、Cloud Identity のグループメンバーは、Cloud Identity の管理コンソールだけでなく、Google Cloud コンソールの「IAM と管理 > グループ」画面でも編集できます。操作者がグループ内で「マネージャー」や「オーナー」のロールを持っていれば、Cloud Identity 管理コンソールにアクセスすることなく、Google Cloud コンソール上でグループメンバーの追加や削除が可能です。セキュリティ維持のため、 組織外部のユーザー をグループに追加できないようにするには、Cloud Identity 管理コンソールで「 グループ オーナーは外部メンバーを許可できる 」のチェックボックスを外しておくことで禁止できます。また、グループごとに設定を変更することも可能です。 参考 : グループを使用するための組織全体のポリシーを設定する またアカウントのログインパスワードのポリシーに関する理解も必要です。Cloud Identity（または Google Workspace）では、脆弱なパスワードを使用できないようにパスワード要件を設定できます。「次回ログイン時にパスワードポリシーを適用する」のチェックボックスをオンにすることで、安全にポリシーを適用できます。 参考 : ユーザーのパスワード要件を適用、モニタリングする アカウント連携（プロビジョニング） 当試験では、Active Directory や Microsoft Entra ID と、Cloud Identity（または Google Workspace）の間でアカウントを同期する（プロビジョニングする）方法について、十分に理解しておく必要があります。 オンプレミスやクラウドの VM 上の Active Directory（AD）から Cloud Identity へアカウントをプロビジョニングするには、 Google Cloud Directory Sync （略称 GCDS）が使用できます。GCDS はサーバーにインストールするタイプのソフトウェアで、AD のアカウントを Cloud Identity に自動プロビジョニングできます。 参考 : Google Cloud Directory Sync について またクラウド型の Directory Sync 機能を使うと、GDCS と同様に、AD から Cloud Identity へアカウントをプロビジョニングできます。Directory Sync は、Entra ID にも対応しています。 参考 : Directory Sync のスタートガイド Entra ID の場合は、上記の Directory Sync を使う方法のほか、Entra ID に備わっている自動プロビジョニング機能を用いることができます。 参考 : Microsoft Entra ID（旧 Azure AD）のユーザー プロビジョニングとシングル サインオン Workload Identity Active Directory や Entra ID を始めとする外部の Identity Provider（IdP）から Google Cloud へシングルサインオン（SSO）する方法を、十分に理解してください。SAML や OAuth 2.0（OIDC）といった仕組みを使ったシングルサインオンについての一般的な知識が無い方は、まずはそちらを調べて、概要を理解したほうが良いでしょう。 そのうえで、SAML や OAuth 2.0（OIDC）に準拠した権限連携の仕組みである Workload Identity を理解してください。Workload Identity は、外部 IdP のアカウントを Cloud Identity にプロビジョニング することなく 、外部 IdP のアカウントに Google Cloud の IAM 権限を付与できる仕組みです。 Workload Identity を使うことで、例えば Entra ID（Active Directory）などの外部 IdP のユーザーに、Google Cloud 上で開発を行う権限を付与できます。こうしておけば、アカウントの管理自体は外部 IdP で行われるため、退職者等の権限は 外部 IdP 側でアカウントが削除された時点で消失 します。これで Google Cloud 側で権限を変更する必要がなく、運用が簡素になります。 参考 : Workload Identity 連携 Identity and Access Management（IAM） 基本的な知識 Identity and Access Management （IAM）の概念と仕組みを正しく理解しておく必要があります。以下の記事を参照して、IAM の仕組みを詳細に理解してください。 blog.g-gen.co.jp 以下の問いに、自分の言葉で答えられるようになっていれば、IAM の基礎知識が身についているといえます。 IAM 許可ポリシーとは何か IAM の継承とは何か プリンシパルにロールを紐づける、とはどういうことか 基本ロールと事前定義ロール 以下の基本ロールや事前定義ロールの仕様は、特に注意して把握しておくべきです。 基本ロール（閲覧者、編集者、オーナー） Resource Manager（組織、フォルダ関係） Cloud Logging Cloud Billing Cloud Storage 以下の公式ドキュメントを確認したり、あるいは Google Cloud プロダクトごとの IAM 関連のガイドを確認し、事前定義ロールを理解しておきます。 参考 : IAM roles and permissions index 参考 : IAM を使用したプロジェクトのアクセス制御 - Resource Manager 参考 : IAM によるアクセス制御 - Cloud Logging 参考 : Cloud Billing のアクセス制御と権限 - Cloud Billing 参考 : Cloud Storage に適用される IAM のロール - Cloud Storage コンピュートリソースと IAM Compute Engine、Cloud Run、Google Kubernetes Engine（GKE）などのコンピュートリソース上のプログラムから、Google Cloud APIs にアクセスするには、サービスアカウントの IAM 権限を使用します。これらの実行環境にサービスアカウントをアタッチすることで、プログラム上から権限を使用できます。サービスアカウント キー を発行することは、ほとんどの場合でベストプラクティスに反しているため、 選択肢になりません 。 Google Kubernetes Engine（GKE）の Pod からサービスアカウントの権限を使うには、 Workload Identity Federation for GKE という仕組みを使い、Kubernetes の世界のサービスアカウントと、Google Cloud の IAM の世界のサービスアカウントをマッピングする手法が一般的に行われます。 参考 : Workload Identity Federation for GKE について 最小権限を維持し、かつ権限を持つ時間を最短にするためには、サービスアカウントの 権限借用 （impersonation）という手法が使われることもあります。 参考 : サービス アカウントの権限借用 参考 : サービスアカウントの権限を借用して Terraform を実行する方法 - G-gen Tech Blog ネットワークセキュリティ Virtual Private Cloud（VPC） 基本的な Virtual Private Cloud（VPC）の仕組みはもちろん、応用レベルの仕様も理解しておきましょう。例えば、以下のような概念です。 VPC Flow Logs VPC Peering 共有 VPC VPC のルーティング（ 参考 ） 同一 VPC 内のサブネット同士のルート交換の仕様 VPC ネットワークピアリングを接続した際の VPC 同士のルート交換 VPC ファイアウォール Cloud NAT 上記の用語の意味を理解したうえで、以下のような少し複雑な VPC の仕様が具体的にイメージでき、設計に活かせるくらいの知識があると、問題にも回答できます。 VPC ネットワーク内に複数サブネットを作成すると、 全てのサブネット同士は通信できる （サブネット同士の通信のためのルートは、編集したり削除したりできない） VPC ネットワーク同士をピアリングすると、 VPC ネットワーク内の 全サブネットのルートが自動的に交換される （ルートは編集したり削除したりできない） VM は複数の VPC ネットワークの 複数のサブネットに足を伸ばせる （NIC を作ることができる） ファイアウォールにおいて、あるパケットが複数のルールに該当する場合、どのルールが適用されるか、 優先度 を理解する VPC に関する参考記事 VPC の詳細な仕様については、以下の記事も参照してください。 参考 : Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い - G-gen Tech Blog 参考 : Google CloudのVPCを徹底解説！(基本編) - G-gen Tech Blog 参考 : Google CloudのVPCを徹底解説！(応用編) - G-gen Tech Blog 参考 : Professional Cloud Network Engineer試験対策マニュアル - G-gen Tech Blog ハイブリッドネットワーク ハイブリッドネットワーク とは、オンプレミスと Google Cloud の VPC ネットワークを接続して、相互運用を行うようなアーキテクチャのネットワークのことです。 Cloud Interconnect 、 Cloud VPN 、 限定公開の Google アクセス などがキーワードとなります。 以下の公式ドキュメントを確認して、オンプレミスと VPC ネットワークを接続する際には、適切なプロダクトを選択できるようにしておきます。 参考 : Network Connectivity プロダクトの選択 これに関連して、 限定公開の Google アクセス （Private Google Access）機能を使い、オンプレミスからプライベートネットワーク経由で Google Cloud APIs を利用する方法も理解してください。以下の記事も参考にしてください。 blog.g-gen.co.jp Cloud Armor、Cloud IDS Google Cloud が提供するフルマネージドな WAF（Web Application Firewall）である Cloud Armor については、概要を理解してください。 blog.g-gen.co.jp Cloud IDS は、VPC ネットワーク内のパケットを検査し、マルウェアによる通信、コマンド&コントロール通信等を検知する仕組みです。VM に出入りするパケットの中身を検査することができます。 blog.g-gen.co.jp もしも「WAF が保護できる対象の脅威（攻撃手法）は何か」「IDS や IPS が保護できる対象の脅威（攻撃手法）は何か」「WAF、IDS、ファイアウォールの守備範囲の違いは何で、それぞれ目的は何か」といった一般的な問いに答えられない場合は、これを機に知識を再確認しておきましょう。 上記は Google Cloud に限定されない一般的な IT セキュリティの知識ですが、これが分かっていれば回答できる問題が、当試験では出題されます。 Cloud Logging と Cloud Audit Logs Cloud Logging と Cloud Audit Logs の仕組みも頻出です。監査ログを適切に出力し、保存する方法に関係しているためです。 blog.g-gen.co.jp blog.g-gen.co.jp 上記の記事を読み、以下の概念を正確に把握してください。 Cloud Logging のログシンクとログバケット、包含フィルター Cloud Audit Logs 管理アクティビティ監査ログと、データアクセス監査ログ 暗号化 Cloud KMS（Key Management Service） 当試験でも最も重要なのが、暗号化や鍵情報の扱いです。その中核にあるのが Cloud KMS です。Cloud KMS は FIPS 140-2 と呼ばれる、米国政府により規定されたセキュリティ要件仕様の規格に準拠した Google Cloud サービスです。 参考 : Cloud Key Management Service の概要 Cloud KMS のサービス詳細については以下の記事を参照してください。 blog.g-gen.co.jp さらに Cloud KMS 関連の以下の単語については、それぞれの違い、役割、仕組みを理解する必要があります。 顧客管理の暗号鍵（CMEK、Customer-Managed Encryption Key） 顧客指定の暗号鍵（CSEK、Customer-Supplied Encryption Key） Cloud EKM（External Key Manager） Cloud HSM（Hardware Security Module） エンベロープ暗号化 エンベロープ暗号化 （Envelope Encryption）という仕組みの理解が重要です。エンベロープ暗号化は Google Cloud の KMS に独自の技術というわけではなく、暗号化の世界ではしばしば用いられます。 Envelope Encryption という言葉で検索して解説を読んだり、以下のドキュメントを参考にするなどしてください。 参考 : エンベロープ暗号化 - Google Cloud 参考 : Concepts in the AWS Encryption SDK - Amazon Web Services デフォルトの暗号化と CMEK 暗号化 Google Cloud ではストレージ上のデータは、 デフォルト で 透過的に暗号化されている という点も重要です。 データの暗号化の基本的な考え方として at-rest （保存時）の暗号化 と in-transit （転送中。in-flight とも）の暗号化に分けることができます。それぞれについて Google Cloud の物理基盤ではどのような実装がされているか、以下のドキュメントを確認してください。 参考 : デフォルトの保存データの暗号化 参考 : Google Cloud の転送中データの暗号化 Google Cloud のデータはデフォルトで暗号化されているのにも関わらず、CMEK（顧客管理鍵での暗号化）が必要になる理由は、鍵の管理に関する要件への対応です。デフォルトの暗号化では、鍵の管理やローテーションは Google によって管理されています。暗号鍵を自組織で管理する要件や、ローテーション日数の厳密な指定がある場合は、Cloud KMS を利用して、CMEK を用います。 Sensitive Data Protection Sensitive Data Protection とは Sensitive Data Protection （旧称 Cloud DLP）の問題は頻出です。Sensitive Data Protection は PII（個人識別情報）等のセンシティブなデータを発見、分類、保護するためのフルマネージドサービスです。 参考 : Sensitive Data Protection の概要 PII の発見と保護 Sensitive Data Protection の主要な機能は、センシティブなデータの 「 発見 」と「 保護 （de-identification = 匿名化、redaction = 削除）」に大きく分けられます。 前者の「発見」については、 Cloud Storage や BigQuery 内のテキストや画像データの中に PII が含まれていないかどうかをスキャンできます。また、API 経由で Sensitive Data Protection に検査を指示することもできるため、例えば生成 AI の入出力テキストを検査して、PII の入力や出力を防止することもできます（現在では、この機能は Model Armor に統合されています）。 参考 : Google Cloud のストレージとデータベースに含まれる機密データの検査 参考 : テキストに含まれる機密データの検査 後者の「保護」については、特に匿名化（de-identification）機能の一種である 仮名化 （pseudonymization）を理解してください。仮名化とは、情報流出を防ぐため、PII を違う文字列に置き換える機能のことです。 参考 : 仮名化 仮名化には AES-SIV を使用した確定的暗号化 、 フォーマット保持暗号化 、 暗号ハッシュ という3つの手法があります。それぞれの違いと、ユースケースを把握しておいてください。 方式名 AES-SIV を使用した確定的暗号化 フォーマット保持暗号化 暗号ハッシュ サロゲートアノテーション 使用可 使用可 非対応 フォーマット保持 いいえ はい いいえ 復元可能 はい はい いいえ 参照整合性 はい はい はい AES-SIV を使用した確定的暗号化は、特定のアルゴリズムに準じて文字列を変換します。暗号鍵への適切な権限をもっていれば、暗号化後の文字列を復号して元の文字列を得ることもできます。「従業員の個人情報を、人事部署のみが参照できるようにする」などに適しています。 フォーマット保持暗号化は、復号が可能であることに加え、変換後の文字列を、元の文字列と同じ文字セットや長さで出力します。「開発部署がテストのためにユーザーデータを欲しがっている。クレジットカード番号や E メールアドレスは、本物と同じフォーマットにして欲しい。しかし、これらは個人情報であるため、本当の値を渡したくはない」といったユースケースで使用できます。 「暗号ハッシュ」はハッシュ化であるため、一度 PII を変換したら、元に戻すことはできません。ただし、入力が同じであれば出力も一意に決まるため、参照整合性はあります。つまり、仮名化した文字列と他のカラムのデータの関係性が保持されるため、分析用途で使用できます。 DevSecOps（CI/CD） Google Cloud で CI/CD パイプライン を実装し、パイプライン内にセキュリティを組み込む方法についても把握することが望ましいです。 参考 : Google Cloud 上での DevOps と CI / CD について フルマネージドのコンテナリポジトリサービスである Artifact Registry には、 コンテナスキャン 機能があります。コンテナスキャンを有効化すると、サポートされているベースイメージの OS やプログラミング言語のパッケージの依存関係をスキャンして、脆弱性を検知してくれます。 参考 : コンテナ スキャンの概要 また Binary Authorization を用いると、Google Kubernetes Engine（GKE）や Cloud Run といったコンテナ実行基盤に、 証明書 （attestations、署名とも訳される）のついた安全なコンテナイメージだけがデプロイされるように制限することができます。 参考 : Binary Authorization の概要 VPC Service Controls VPC Service Controls の基本については、以下の記事を参照して把握してください。 blog.g-gen.co.jp 境界 （perimeter）の考えや、境界の保護下に VPC ネットワーク内の VM インスタンスを組み入れるにはどうすればよいか、などを回答できるようにしてください。 境界内のリソースと、境界外のリソースが通信する方法も理解してください。 境界ブリッジ （perimeter bridges）を使うことで、異なる境界内のリソース同士でデータのやり取りが可能になります。 ただ、一方のリソースが VPC Service Controls の境界を使用していない場合は、境界ブリッジではなく、 内向きルール や 外向きルール を適切に設定する必要があります。それぞれをどういったときに、どのように設定すべきなのかについて、以下の記事を読み込んで把握してください。 blog.g-gen.co.jp Security Command Center Security Command Center （SCC）は、Google Cloud 環境の脆弱性や構成ミス、不審な挙動などを検知してリストアップしたり、通知するサービスです。SCC は複数の機能を擁していますので、どのような機能があるのか、どのように使うべきなのかを、公式ドキュメントや以下の記事を参考に把握してください。 blog.g-gen.co.jp SCC のどの機能がどのレイヤの脆弱性を検知できるのか、適切に答えられるようにしましょう。 Security Health Analytics は Compute Engine や VPC ファイアウォール、Cloud Storage などの不適切な設定や設定ミスを検知することができます。 Web Security Scanner は Web アプリに対する L7 レベルの脆弱性スキャンを定期的に実行することが可能です。 Virtual Machine Threat Detection は、VM をスキャンして クリプトマイニング （暗号通貨採掘）、カーネルモードルートキット、マルウェアなどを検出します。VM のゲストメモリからメタデータを読み取って検査するので、エージェントソフトウェアは不要です。 Compute Engine Confidential Computing 近年では at-rest / in-transit のデータ暗号化に加えて、 メモリ上のデータ暗号化 も加える場合があります。Google Cloud の Confidential Computing の考え方では、ストレージ上や通信経路上のデータだけでなく、メモリ上のデータも暗号化します。これを実現する VM を、Confidential VM と呼びます。 参考 : Confidential Computing のご紹介 参考 : Confidential Computing の概要 Shielded VM Shielded VM は、VM がセキュアに起動することを担保するために高度な設定を有効化した Compute Engine VM のことです。 セキュアブート 、 vTPM 、 整合性モニタリング といったオプションを有効化して VM を起動することで、ブートレベルやカーネルレベルなど低レイヤで動作するマルウェアやルートキットなどに対処できます。この3つのキーワードを覚えてください。以下のドキュメントや記事も参照してください。 参考 : Compute Engineを徹底解説！（応用編） - G-gen Tech Blog - Shielded VM 参考 : Shielded VM の概要 その他のプロダクト Network Intelligence Center Network Intelligence Center の概要を把握しておいてください。 参考 : Network Intelligence Centerを徹底解説！ - G-gen Tech Blog Firewall Insights 機能など、ネットワークセキュリティとガバナンスの維持に有用な機能が利用できます。Firewall Insights ではその Firewall ルールが何回ヒットした（実際に使われた）か、また最後に使われたのはいつか、などを確認することができます。また優先度のせいで別のルールの影に隠れて使われていない Shadowed rules を見つけることもできます。増えすぎたファイアウォールルールを棚卸しするときに便利な機能です。 Secret Manager Secret Manager はアプリケーションが利用するパスワード、証明書、 API キーなどの機密情報を格納するためのセキュアなストレージサービスです。 参考 : Secret Manager の概要 API 呼び出しでシークレット（機密情報）を格納したり、取り出したりできるほか、バージョニングやローテーションといった管理機能があります。Secret Manager に格納されたシークレットはデフォルトで暗号化されており、オプションで前述の Cloud KMS の CMEK を利用することもできます。 試験の傾向として、サービスアカウントのシークレットキーを発行して Secret Manager に格納するような選択肢は、 ほぼ誤り であると考えてください。なぜなら、Secret Manager にアクセスすること自体に権限が必要になるため、ではその権限はどう管理するのか、という話になるからです。試験の世界においては、サービスアカウントは VM や Cloud Run などの実行環境にアタッチして使うものであり、キーを発行するという選択肢が正答になることはほとんどないといえます。また、それが Google Cloud のベストプラクティスであることを示しています。 Google Cloud セキュリティの全体像把握 以下の記事は、Google Cloud におけるセキュリティ施策を網羅的に解説した記事です。 個々のプロダクトの学習と併せて、それらをどう組み合わせて網羅的な対策としていくかを、以下の記事を使って把握してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは G-gen の渡邉@norry です。 Goole Workspace を運用する際に管理者が特に気になる事の一つとして、セキュリティー関連のレポートや監査ログがあるかと思います。 常日頃のガバナンス管理、有事の際での証跡として...今回は Google Workspace でどういったログが取れるのかのご案内と、プランによっては取得出来ないログもありますのでその点にも触れます。 Google Workspace の機能比較やプラン一覧はこちらをご覧ください。 blog.g-gen.co.jp レポート レポートの表示方法 レポートの種類 監査ログ 監査ログの表示 Google Workspace で利用可能な監査ログ プラン別の違い Google Workspace プラン別項目一覧 ログ出力のタイムラグ 保持期限 ログのエクスポート エクスポートについて スプレッドシート、CSV へエクスポート BigQuery へのエクスポート Reports API を利用したログ取得 アラート レポート レポートの表示方法 Google Workspace 管理コンソールにて「 レポート ＞ レポート 」を選択することで各種レポートを表示することができます。 レポートではグラフやチャート、表を用いてアプレケーションやアカウント情報などを閲覧者に対し、どういう状況にあるかを視覚的に分かりやすく表示します。 アカウントのレポート レポートの種類 管理コンソールから確認可能なレポートの種類は以下のようなものがあります。 レポート 内容 重要ポイント レポート 組織の主な指標と傾向の概要を確認できます。サービスの使用状況、ドキュメント公開設定、保存容量、ファイル共有アクティビティ、基本的なセキュリティ指標などが含まれます。 組織全体のアプリレポート ドメイン内のすべてのユーザーと管理者に関するチャートとグラフを閲覧できます。組織全体の傾向と管理情報の概要も含まれます。 ユーザー レポート: アカウント セキュリティとアプリの使用状況に関するアクティビティ情報の重要ポイントがマスター レポートとして示されます。 ユーザー レポート: アプリの使用状況 組織での Gmail とドライブの使用状況が示されます。メール アクティビティの種類、作成および共有されたドキュメントの数、各チームメンバーによるドライブ ストレージの使用容量などが含まれます。 ユーザー レポート: セキュリティ ドメイン全体でのデータ漏洩リスクを評価できます。また、チームの 2 段階認証プロセスの使用状況、モバイル デバイスにサードパーティ製アプリをインストールしているユーザー、ドメイン外のユーザーとのドキュメント共有状況などを確認できます。 監査ログ 管理者のアクティビティ、モバイル アクティビティなど、特定のイベントに関する情報を入手できます。 監査ログ 監査ログの表示 Google Workspace 管理コンソールにて「 レポート ＞ 監査 」を選択することで各種レポートを表示することができます。 監査ログには 「誰が」 「いつ」 「何に対して」 「どのような操作」 を行ったかが記録されます。 例えば 管理者の監査ログ では、Google 管理コンソールで行われた操作の記録を確認できます。管理者がユーザーを追加した日時や Google Workspace サービスを有効にした日時などですね。 また、Google Drive であれば下図のようにどの種類のファイルをいつ誰が操作したのか分かるようになっています。 先のレポートの項目ではビジュアル的にどの程度かを把握するのに適しており、監査ログではより詳細な内容について把握する事が可能です。 ドライブの監査ログ Google Workspace で利用可能な監査ログ Google Workspace で利用可能な監査ログは こちら になります。代表的な物として以下のようなものがあります。 管理者の監査ログ ログインの監査ログ デバイス監査ログ メールログ検索 Google Chat の監査ログ Google Meet の監査ログ プラン別の違い Google Workspace プラン別項目一覧 どのプランでどういったレポートや監査ログが取得出来るのかを一覧にしてみました。 Frontline Business Starter Business Standard Business Plus Enterprise Essentials Enterprise Standard Enterprise Plus アプリとユーザーのレポート ✔ ✔ ✔ ✔ ✔ ✔ ✔ 監査ログ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ドライブ監査 ✔ ✔ ✔ ✔ ✔ Meet の出席レポート ✔ ✔ ✔ ✔ BigQuery へのエクスポート ✔ ✔ アクセス透明性ログ ✔ インサイト レポート ✔ 大きな違いとしてプランの中に ドライブ が含まれるか？がポイントになります。 Business Starter 及び Enterprise Essentials にはドライブ (共有ドライブ) が含まれていません。 従って監査ログにもドライブの項目が存在せず、レポートとしては表示が可能ですが詳細な操作ログを閲覧するには適していない為、ドライブの操作ログを取得したい場合には Business Standard 、Enterprise Standard 以上のプランをおすすめします。 アクセス透明性のログは社内のデータに Google のスタッフがアクセスしたときの操作情報を把握することができるとあり、インサイトレポートではダッシュボードを作成し組織での Google Workspace の使用に関する詳細な指標を得ることができます。 特に Enterprise 環境において必要になる場合があるでしょう。 ログ出力のタイムラグ Google Workspace のログには保持期間とレポートやログに反映されるまでのタイムラグがあります。 詳しくは こちら を見ていただければと思いますが、大まかに下記のようになります。 項目 期間 備考 レポート 1～3 日 監査ログ ほぼリアルタイム（数分以内） 項目によっては1～3 日 データの保持期間 6ヶ月 項目によっては12 か月 アカウントログやドライブの操作ログなど一般的に即時性が求められるようなログに関してはほぼリアルタイムに反映されます。 保持期限 データの保持期間が 6ヶ月の為、特に監査ログなど6ヶ月以上保持する必要がある場合にはエクスポートする等の対応が必要になります。 後述しますが、ログを参照するための API をGoogle では提供していますので、リアルタイムにログを検知、通知を行う機能を利用者側で実装も可能となっています。 ログのエクスポート エクスポートについて 前項でデータの保持期間が6ヶ月 (項目によっては12ヶ月) と述べました。 ではそれ以上の期間のログを取得したい場合にどうするか？大きく別けて以下の3パターンになります。 スプレッドシート、CSV へエクスポート BigQuery へエクスポート Reports API を利用したログ取得 スプレッドシート、CSV へエクスポート Google Workspace 管理コンソール ＞ レポート ＞ レポート ＞ アプリレポート の各項目より、スプレッドシートまたは CSV でダウンロードする事が可能です。 例としてアプリレポート ＞ アカウント の「2 段階認証プロセスの登録と適用」に遷移し画面右上にあるダウンロードアイコンを押下します。 2 段階認証プロセスの登録と適用 スプレッドシートまたは CSV でのダウンロードが確認できます。 ダウンロード 実際にダウンロードしたスプレッドシートは以下のようになります。 スプレッドシートへのエクスポート 注意点として、一度にダウンロード可能なレコード数は 100,000行 という制限が存在するため、制限を超えて取得する為には BigQuery Export を利用するといった対応も必要になります。 BigQuery へのエクスポート Google Workspace 管理コンソール ＞ レポート ＞ BigQuery Export から Google Cloud (GCP) の BigQuery へ出力する事が可能です。分析用データベースに出力する事により SQL を利用した抽出が行えます。 BigQuery Export BigQuery へのエクスポートでは次のようなデータを利用可能です。 使用状況レポート - ライセンスの有無にかかわらずドメイン内のすべてのユーザー（使用状況テーブル）。 監査ログ - Google Workspace Enterprise を利用している組織は、ドライブとモバイルの監査ログを書き出すことができます。管理者、Google カレンダー、Google グループなどのその他のログについては、すべてのユーザー（全エディション）のデータが BigQuery に書き出されます。 ただし BigQuery のエクスポートを利用する為には Google Workspace の Enterpriseエディション、もしくはEducation Standard / Plusエディション の契約が必要になりますのでご注意ください。 Google Workspace の管理者ヘルプには SQL の抽出クエリの例、例えば以下のように「Gmail の 30 日間のアクティブ ユーザー数に対する 1 日あたりのアクティブ ユーザー数の割合」の取得方法等も示されています。 BigQuery にエクスポートされる内容は多岐にわたる為、一度目を通してどのような抽出が出来るのかを把握しておくことをおすすめいたします。 #1 日あたりのアクティブ ユーザー SELECT date, gmail.num_1day_active_users FROM api_project_name.dataset_name.usage WHERE gmail.num_1day_active_users > 0 ORDER BY 1 DESC; # 7 日間のアクティブ ユーザー SELECT date, gmail.num_7day_active_users FROM api_project_name.dataset_name.usage WHERE gmail.num_7day_active_users > 0 ORDER BY 1 DESC; # 30 日間のアクティブ ユーザー SELECT date, gmail.num_30day_active_users FROM api_project_name.dataset_name.usage WHERE gmail.num_30day_active_users > 0 ORDER BY 1 DESC; 抽出例について知りたい方は コチラ を参考にしてみてください。 Reports API を利用したログ取得 Google Workspace には Google Workspace Admin SDK (ソフトウェア開発キット) が用意されています。 Google Workspace の Reports API を利用して手組みで実装する事も可能ですが、監査ログの仕様は幅が広く少し敷居が高いと言えます。ご興味があられる方は Reports API に関するドキュメント コチラ をご参照ください。 アラート アラートの設定は Google Workspace 管理コンソールの「 ルール 」から行えます。 Google Workspace の管理者は「ルール」作成する事により、特定の条件下においてユーザーにメール通知が可能です。 ルール 作成可能なルールの主な種類は以下になります。 アクティビティ - ドメイン内のアクティビティに応じた操作 データの保護 - ドメイン内のドライブ ファイルの使用に関連する特定のアクティビティが発生したときに通知 レポート - 組織の監査ログに基づいてカスタム アラートを作成、管理 例えば監査ログのイベントに基づいてアラート設定する場合には、 管理コンソール ＞ ルール ＞ ルールを作成 を押下し レポート を選択します。 ルールを作成 監査ログに遷移しますので +フィルタを追加 ＞ 「イベント」 を選択し、検索欄に通知を行いたいイベントを入力し、適用します。今回は ドライブの設定の変更 を適用しました。 イベントを検索 画面右上のベルのマークを押下します。 ルールの名前、受信者 (アラートセンター、特権管理者、追加の宛先)を選択、作成して完了となります。 レポートルールを作成 作成したルールは、 管理コンソール ＞ ルール の一覧の中に表示されます。 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-gen の杉村です。Google Cloud (旧称 GCP) 認定資格である Looker LookML Developer 試験 は、他の Google Cloud 認定試験とは一線を画し、かつては Google Cloud とは別プロダクトであった Looker の開発者向け認定資格です。 本投稿では試験の合格に役立つ情報を記載します。 ※ 当試験は 2022/04/01 をもって 廃止 となりました。しかしながら当記事は Looker の製品知識の取得に役立ててもらう意味を込めて、公開のままとさせていただきます。 はじめに 本投稿の想定読者 Looker LookML Developer 試験の難易度 推奨の勉強法 出題傾向 フィルタとアクセス制御 フィルタを強制する アクセス制御 Dimension & Measure フィールドタイプ 持続可能な LookML Explore / View Derived Table (派生テーブル) ユーザーの利便性向上 開発と Git トラブルシューティング ベストプラクティス その他 日本語版試験と英語版試験 受験環境 Looker LookML Developer はじめに 本投稿の想定読者 本投稿は以下のような方向けです。 Looker LookML Developer 試験を受けるために勉強をしており出題傾向を知りたい Looker の基本的な知識は習得済み、もしくはある程度実務で使ったことがある 近日中に試験を受けようと思っているので、最後の勉強をしている Looker LookML Developer 試験の難易度 当試験の難易度としては、中程度だと言えます。 Looker を通常業務で用いており、 LookML を日常的に扱っている人にとっては、当記事を参考にポイントを押さえた追加学習を行うことで十分合格できます。 ただし LookML の初心者であったり、 Looker をあまり扱った経験のない人にとっては、まずはトレーニング等で基本を押さえてからでないと当試験の合格は難しいでしょう。 推奨の勉強法 Google (Looker チーム) の実施している公式トレーニングなどを受けて、基礎的なスキルを習得する (ここが最も重要であり取っ掛かりになります) 試験ガイド を読み出題範囲を理解する 当記事を読み、出題傾向を理解する 理解を深めたいパラメータについては公式ドキュメントを読んだり、インターネット検索して各社の公開する技術ブログを読む。実際に Looker 環境で使ってみることも重要 最後にまた、当記事で復習する なお当試験は 2022 年 1 月現在、 英語でのみ提供 されています。 他の Google Cloud 試験と比べても 1 問の問題文が長い傾向があるため、英語ドキュメントを読むことに慣れていないと、まず問題文を理解することに脳のリソースを使ってしまうことになりかねません。 Looker ドキュメントは普段から英語で読む ように癖づけましょう。 また試験時間は 100 分であり、先述の通り問題文が長いため、他の Google Cloud 試験に比べて時間的余裕がありません。 筆者も、当試験の受験時点で 4 つの Google Cloud 試験を合格済みでしたが、もっとも時間的に焦りを感じた試験となりました。 時間配分は、普段以上に気をつける必要がありそうです。 出題傾向 当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきます。 わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。 そのように勉強すれば、試験に合格できるのに加え、実践的な知識となるでしょう。 フィルタとアクセス制御 フィルタを強制する ソースデータベースから取得するデータを適切に絞ることは、とても重要です。 BigQuery を始め、多くのカラムナ (列志向) のデータウェアハウス製品では、適切なクエリを書かなければ テーブルにフルスキャンがかかってしまう 可能性があります。 これは不要な負荷をデータベースにかけることになるだけでなく、製品によってはスキャン量に応じた課金となるため、コスト的なデメリットもあります。 Looker では以下のようなパラメータが用意されており、 LookML の工夫次第でユーザーが不用意に巨大なクエリを投げてしまうことを防ぐことができます。 ※ (凡例) [利用箇所] パラメータ名 [Explore] sql_always_where [Explore] always_filter [Explore] conditionally_filter これらのパラメータについては、サブパラメータの書き方も含めてしっかり押さえておく必要があります。 ただドキュメントを眺めるのではなく「実業務ではどういうときにこのパラメータを使うのか？」「似たパラメータ名だが、違いは何なのか？」を理解すると良いでしょう。 アクセス制御 Looker のユーザーには User Attribute という属性を持たせることができます。 例えば department という Attribute を持たせ、ユーザーごとに executive, sales, store-manager のように役職・部署名を持たせます。 Looker ではこの User Attribute ごとに、見せるデータを変えることができます。 Explore ごと、 Join/View ごと、フィールドごとに見せ方を変えることができますし、行単位で制御することも可能です。 以下のパラメータを用います。 [Explore] access_filter [Model] access_grant [ Explore / Join / View / Field ] required_access_grants これらのパラメータについても、やはりサブパラメータの書き方も含めてしっかり押さえておく必要があります。 繰り返しになりますが「実業務ではどういうときにこのパラメータを使うのか？」「似たパラメータ名だが、違いは何なのか？」を考えつつ勉強します。 access_filter は User Attribute の値をもとに行をフィルタします。強制的に SQL の WHERE 句が追加されます。 access_grant と required_access_grants はセットです。 User Attribute の値に応じて Explore / Join / View / Field の閲覧を許可するかどうかを設定できます。 Dimension & Measure フィールドタイプ Dimension や Measure の各タイプやその特徴を押さえておきます。 Measure では sum や number といった頻繁に使われるタイプはもちろん、 sum_distinct や percent_of_total など、様々なタイプの用法、サブパラメータも押さえておきましょう。 持続可能な LookML 持続可能な LookML (運用を崩壊させず、継続でき、かつスケールできるような LookML の書き方) に関する問題は多く出てきます。 例えばフィールドを set でまとめて Explore 側の fields パラメータで指定できるようにしておく、であったり、万一フィールド名を変えたときのために alias を使ったり、などというテクニックです。 これは後述する ベストプラクティス にも記載があります。 Extends の利用などもこれに含まれるでしょう。 Explore / View Explore の各パラメータを把握しておきます。 特に重要になるのが、 View 同士の 結合 に関する知識です。 Looker では 対称集計 (Symmetric Aggregates) が可能であり、これを適切に働かせるには join において relationship パラメータを適切に設定する必要があります。 なお対称集計に関連して Explore には symmetric_aggregates というパラメータがありますが通常は省略され、デフォルトは yes です。 そもそも対称集計とは何か、そしてそれが集計結果にどう影響を及ぼすのか、についてまずはキャッチアップしましょう。 Derived Table (派生テーブル) 試験にあたり Looker の Derived Table (派生テーブル) 機能を使いこなせるようになっている必要があります。 Looker における View を一般的なデータベース用語における「テーブル」に見立てると、 Derived Table は「ビュー」に当たります。 日単位→月単位のように粒度を変えたり、 Measure を Dimension 化したり、複雑なロジックを事前に入れ込んだりするために用います。 Derived Table の種類は "Persistent / Temporary" の軸と "Native / SQL" の軸があり、都合 4 種類あるといえます。 試験では、特に Persistent Derived Table (PDT) の扱いが注目されます。 そもそも、 PDT を使いたいときはどんなときなのかを把握しましょう。 一般的なデータベース用語における「ビュー」が Temporary Derived Table だとすると、 Persistent Derived Table は「マテリアライズド・ビュー」に当たります。 指定したデータベースに物理テーブルとしてデータを事前に永続化するので、パフォーマンスの向上が見込めます。 また PDT はデータベースに物理テーブルとして永続化されるので、リフレッシュのタイミングの指定方法が重要です。 datagroup の使い方をしっかり説明できるようにしておきましょう。 「 sql_trigger と max_cache_age の違いや使い方」「ソーステーブルの ETL プロセスと PDT リフレッシュのタイミングを合わせるにはどうするか」などの理解は必須です。 sql_trigger の書き方はドキュメントの「 Examples 」が参考になります。 またキャッシュ周りは似たようなパラメータが多いのでドキュメント Persistence strategies を読んでおきましょう。 ユーザーの利便性向上 LookML Developer 試験は開発者向けの試験ですが、ユーザー目線を意識させる問題が多いです。 どのように実装すれば利用者にとって嬉しいか、を考えさせます。 以下のようなベストプラクティスを覚えておきましょう。 必要最小限のフィールドだけが見えるようにする 不要なフィールドは Explore/Join の fields パラメータで除外 見せる必要のないフィールドは hidden パラメータで隠す 似たフィールドは group_label パラメータでグルーピングする group_label は explore にもある 分かりやすい名前を付けるため view_label パラメータを使う view_label は explore / view / join にもある 開発と Git Looker は Git と統合 できます。 GitHub などの外部レポジトリを用いるのが推奨です。 Bare Git repository と呼ばれる Looker サーバに配置するレポジトリのみを利用するモードもあり、これを利用すれば外部の Git を用意しなくてよいのですが、これだと開発者は Looker のブラウザベース IDE からローカルレポジトリのみを編集するような形になり、推奨されていません。 外部レポジトリを使う場合 HTTPS と SSH の 2 通りの接続方法が利用できますが、認証方法に違いがあるため、ドキュメントをそれぞれ確認しておきましょう。 例えば HTTPS 接続にした場合でも Single account HTTPS authentication と Multiple account HTTPS authentication の 2 種類があり、前者だと Git ログインに使われる認証情報を一つだけ設定する、など違いがあります。 トラブルシューティング 試験ガイドにあるように Content Validator で何ができるのかはよく確認しておきましょう。 壊れた参照などを検知する機能に加え、これを修正する機能も備わっています。 また LookML を開発していると様々なエラーメッセージに直面します。 Looker error catalog というドキュメントには、エラーメッセージと考えられる原因がまとめられています。 この一覧はチェックしておきましょう。もちろん、すべて覚える必要などありませんが [IDE] のマークが付いているメッセージは要確認です。 ベストプラクティス 公式の Looker Help Center に掲載されている、以下のベストプラクティスは読んでおきましょう。 試験問題だけでなく、業務に直結する知見が得られるかもしれません。 Best Practice: LookML Dos and Don'ts Best Practice: Optimize Looker Performance Best Practice: Create a Positive Experience for Looker Users Best Practice: Writing Sustainable, Maintainable LookML その他 日本語版試験と英語版試験 Google Cloud 認定資格の試験を申込みする際は KRYTERION の Webassessor の Web サイトでアカウントを作成して申し込みます。 しかし、アカウント作成時に言語を 日本語 として作成すると、日本語版の Google Cloud 認定資格しか申し込むことができません。 英語版しか提供されていない Looker 試験を申し込むには 2022 年 2 月現在、 言語を英語とした新しいアカウントを作成 する必要があります。 Webassessor のログイン画面が以下のように日本語表記の場合、英語版に切り替えてから新しいアカウントを作成し、そのアカウントで申し込みます。 別言語でアカウントを作成 受験環境 当社メンバーの Google Cloud 認定試験の受験環境に関する実体験が以下の記事で紹介されています。 ぜひご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の渡邉@norry です。Compute Engine VM にアタッチする サービスアカウント と、VM の アクセススコープ の概念について整理しました。 はじめに 前提知識 サービスアカウントとアクセススコープ IAM 検証 「デフォルトのアクセス権を許可」の場合 「すべての Cloud API に完全アクセス権を許可」の場合 まとめと補足 IAM の権限とアクセススコープ 最小権限の原則を意識する はじめに Google Cloud（旧称 GCP）の Compute Engine では、VM を作成する時にデフォルトで Compute Engine のデフォルトサービスアカウントがアタッチされます。 参考 : サービス アカウント - Compute Engine のデフォルトのサービス アカウント このサービスアカウントの権限とアクセススコープの範囲によっては、意図しないセキュリティホールが生まれる可能性があります。例えば、悪意を持った第三者が仮想マシンから gcloud コマンドを操作して新たな仮想マシンを起動し、暗号通貨の採掘（クリプトマイニング）を行うなどの事故が考えられます。 今回の記事では、改めて Compute Engine における サービスアカウント と アクセススコープ の概念を整理します。 前提知識 サービスアカウントとアクセススコープ Compute Engine における サービスアカウント と アクセススコープ の基礎知識については、以下の記事の サービスアカウントとアクセススコープ の項をご参照ください。 参考 : Compute Engineを徹底解説！（応用編） - G-gen Tech Blog - サービスアカウントとアクセススコープ アクセススコープは、サービスアカウントの権限に「フタをする」ような挙動をすると考えれば分かりやすくなります。 当記事では、上記の点について検証します。 IAM Google Cloud のリソースと IAM の関係性については、以下の記事を参照してください。 blog.g-gen.co.jp 検証 「デフォルトのアクセス権を許可」の場合 VM を新規作成します。アタッチするサービスアカウントとして、 Compute Engine default service account を選択します。アクセススコープ設定は デフォルトのアクセス権を許可 を選択します。 アクセス スコープ デフォルトのアクセス権を許可 VM 作成後に、詳細画面の セキュリティとアクセス のブロックの下にある、 API と ID の管理 の項目で、VM にアタッチされているサービスアカウントと、設定されているアクセススコープが確認できます。さらに、Show detials を押下すると、アクセススコープの詳細が確認できます。 サービスアカウントとアクセススコープ デフォルトのアクセス権を許可 だと、Compute Engine API や BigQuery API へのアクセス許可は無効となっている事が分かります。反対に、許可されているのは Cloud Logging（旧称 Stackdriver Logging）や、Cloud Monitoring（旧称 Stackdriver Monitoring）への書き込みです。これは、Cloud Logging へログを送信したり、Cloud Monitoring へメトリクスを送信できることを意味しています。また、Cloud Storage（画面上は「ストレージ」と記載）への読み取りも許可されています。 この状態で VM に SSH 接続し、gcloud コマンドで VM を作成することを試みます。 norry@instance-1:~$ gcloud compute instances create instance-2 Did you mean zone [ asia-northeast2 -a] for instance: [ instance -2] ( Y/n ) ? Y ERROR: ( gcloud.compute.instances.create ) Could not fetch resource: - Request had insufficient authentication scopes. リクエストの認証スコープが不足している（ Request had insufficient authentication scopes. ）と表示され、VM が作成出来ませんでした。アクセススコープで制限されているため、このようなエラーとなります。 「すべての Cloud API に完全アクセス権を許可」の場合 次にアクセススコープを すべての Cloud API に完全アクセス権を許可 にします。この設定では、アクセススコープではアクセス先 API を制限しない状態になります。この設定にした場合、サービスアカウントが権限を持ってさえいれば、すべての操作が実行できます。 VM のアクセススコープを変更するには一度 VM を停止する必要があります。 サービスアカウントとアクセススコープ 設定変更が完了したら、再度 VM に SSH 接続し、gcloud コマンドで VM を作成してみます。 norry@instance-1:~$ gcloud compute instances create instance-2 Did you mean zone [ asia-northeast2 -a] for instance: [ instance -2] ( Y/n ) ? Y Created [ https://www.googleapis.com/compute/v1/projects/xxxxxx/zones/asia-northeast2 -a /instances/instance -2] . NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS instance -2 asia-northeast2 -a n1-standard -1 RUNNING 上記のように、VM の作成が成功しました。アクセススコープではアクセス先 API が絞られていないためです。サービスアカウントが VM 作成権限を持っているので、操作が成功しました。 次に、アクセススコープが すべての Cloud API に完全アクセス権を許可 であっても、サービスアカウントが権限を持っていない操作は行えないことを、念のために確認します。 VM のアクセススコープは すべての Cloud API に完全アクセス権を許可 のままで、サービスアカウントの IAM ロールを編集者から閲覧者へ変更します。 編集権限から閲覧権限へ 再度 VM に SSH 接続し、gcloud コマンドにて VM を作成してみます。 norry@instance-1:~$ gcloud compute instances create instance-3 Did you mean zone [ asia-northeast2 -a] for instance: [ instance -3] ( Y/n ) ? ERROR: ( gcloud.compute.instances.create ) Could not fetch resource: 上記のように、サービスアカウントが権限を持っていない操作が拒否されることが確認できました。 まとめと補足 IAM の権限とアクセススコープ サービスアカウントの持つ権限と、VM のアクセススコープ設定の状態ごとの、操作実行可否を表に表すと以下のとおりです。 アクセススコープ : デフォルト アクセススコープ : すべての Cloud API サービスアカウント : 編集者 ✕ (アクセススコープで拒否) ◯ (両方で許可) サービスアカウント : 閲覧者 ✕ (アクセススコープで拒否) ✕ (IAM で拒否) VM のアクセススコープ設定が デフォルトのアクセス権を許可 では Compute Engine API への操作が無効なので、サービスアカウントに十分な権限があっても新たに VM を作成する事が出来ませんでした。 反対に、VM のアクセススコープ設定が すべての Cloud API に完全アクセス権を許可 であっても、サービスアカウントに権限がなければ VM を作ることはできません。 VM のアクセススコープ設定は、サービスアカウントの権限に「 フタをする 」ような挙動をすると考えればよいでしょう。 最小権限の原則を意識する 情報システムの権限管理においては、アカウントに対しては必要最小限の権限だけ与えるべきだという「 最小権限の原則 」が基本となります。 しかしながら、Compute Engine デフォルトのサービスアカウントが自動的に作成される際には、プロジェクトレベルで 編集者 （roles/editor）ロールが付与されてしまいます。 編集者は、強力なロールです。何も意識しなければ、VM のアクセススコープは デフォルトのアクセス権を許可 のはずなので、操作可能範囲はある程度制限されていますが、意図せずアクセススコープを すべての Cloud API に完全アクセス権を許可 などに設定してしまうと、かなり広い範囲の操作が可能になってしまいますため、十分注意が必要です。 この仕様への対処として、 組織のポリシー で以下を設定することができます。 制約名 ID 説明 デフォルトのサービス アカウントに対する IAM ロールの自動付与の無効化 constraints/iam.automaticIamGrantsForDefaultServiceAccounts 有効化することでデフォルト Compute Engine サービスアカウント作成時に編集者権限が付与されなくなる なお上記の制約は、2024年初頭以降に新しく作成された Google Cloud 組織では、はじめから有効化されている場合があります。 組織のポリシーについては、以下の記事も参照してください。 blog.g-gen.co.jp 渡邉 宣之 (記事一覧) クラウドソリューション部 AI/ML、アプリケーションモダナイゼーション、データ分析基盤の構築、クラウド管理運用やネットワークなどインフラ系は何でも、Google Workspace 活用も推進中 週末フォトグラファーで、観葉植物や塊根植物にハマっていて種から育ててます。

G-genの荒井です。当記事では Google Cloud 認定資格 の一覧や、各試験の概要をご紹介します。Google Cloud を仕事で取り扱う方や、興味があって調べている方向けに資格の概要をご紹介しますので、どんな資格が自分に必要か見定めて資格取得を目指していただければと思います。 はじめに Google Cloud 認定資格とは 資格の種類 認定資格のメリット ルール・受験方法 言語・試験時間・料金 受験場所 有効期限と再認定 資格取得の順番 不合格時の再試験 Google Cloud 認定資格の詳細 Foundational レベル Cloud Digital Leader Generative AI Leader Associate レベル Associate Cloud Engineer Associate Google Workspace Administrator Associate Data Practitioner Professional レベル Professional Cloud Architect Professional Cloud Database Engineer Professional Cloud Developer Professional Data Engineer Professional Cloud DevOps Engineer Professional Cloud Security Engineer Professional Cloud Network Engineer Professional Machine Learning Engineer Professional Security Operations Engineer 番外編 Professional ChromeOS Administrator 廃止された試験 Looker LookML Developer Looker Business Analyst Professional Google Workspace Administrator はじめに Google Cloud 認定資格とは Google Cloud 認定資格とは、Google Cloud に関する公式の認定資格です。Google Cloud に関する知識やスキルが評価されます。 2026年7月現在、Google Cloud 認定資格は 14個 あります。テクノロジー分野ごとに資格が用意されているため、資格を取得することでその分野における知識・スキルを保持していることが証明できます。 以下は、Google Cloud 認定資格の公式案内ページと、詳細なヘルプドキュメントです。日本語のページは最新情報に更新されていない場合がありますので、最新情報を得るためには、ページ最下部右側のセレクタで英語版に切り替えてください。 参考 : 認定資格 | Google Cloud 参考 : Google Cloud 認定資格 ヘルプ 資格の種類 Google Cloud 認定資格には、どのようなものがあるか確認してみましょう。 Google Cloud 認定資格は、Foundational（基礎）、Associate（アソシエイト）、Professional（プロフェッショナル）の3段階に別れています。 Foundational レベル Associate レベル Professional レベル Foundational レベル Cloud Digital Leader Generative AI Leader Associate レベル Associate Cloud Engineer Associate Google Workspace Administrator Associate Data Practitioner Professional レベル Professional Cloud Architect Professional Cloud Database Engineer Professional Cloud Developer Professional Data Engineer Professional Cloud DevOps Engineer Professional Cloud Security Engineer Professional Cloud Network Engineer Professional Machine Learning Engineer Professional Security Operations Engineer 認定資格のメリット Google Cloud 認定資格を取得すると、以下のようなメリットがあります。もちろん一番は自身の知識・スキル向上ですが、その他にもたくさんの特典があります！ 学習の きっかけ になる 知識の 客観的 な証明になる Google Cloud Next などのイベントで 有資格者特典 が得られる Google の 限定グッズ が手に入る ルール・受験方法 言語・試験時間・料金 ※ 受験料の記載は税別です 資格名 試験時間 受験料 言語 Cloud Digital Leader 90分 $99 日本語/英語/スペイン語/ポルトガル語/フランス語 Generative AI Leader 90分 $99 日本語/英語 Associate Cloud Engineer 2時間 $125 日本語/英語/スペイン語/ポルトガル語 Associate Google Workspace Administrator 2時間 $125 日本語/英語 Associate Data Practitioner 2時間 $125 日本語/英語 Professional Cloud Architect 2時間 $200 日本語/英語 Professional Cloud Database Engineer 2時間 $200 日本語/英語 Professional Cloud Developer 2時間 $200 日本語/英語 Professional Data Engineer 2時間 $200 日本語/英語 Professional Cloud DevOps Engineer 2時間 $200 日本語/英語 Professional Cloud Security Engineer 2時間 $200 日本語/英語 Professional Cloud Network Engineer 2時間 $200 日本語/英語 Professional Machine Learning Engineer 2時間 $200 日本語/英語 Professional Security Operations Engineer 2時間 $200 日本語/英語 受験場所 Google Cloud 認定資格は、テストセンターでの現地受験のほか、オンラインでの受験が可能です。 テストセンターでの現地受験の場合、日本全国に提携試験会場（テストセンター）があり、会場に設置されたパソコンを使って受験します。 福岡県近辺の方向けですが、テストセンターへの行き方についての記事も参考にしてください。 参考 : 「Google Cloud認定試験」福岡会場への行き方 - G-gen Tech Blog オンラインでの受験については、当社のメンバーによる記事も参考にしてください。 参考 : Google Cloud 認定資格オンライン受験の準備と注意点 - G-gen Tech Blog 参考 : 3ヶ月前までGoogle Cloud(旧GCP)の素人だった私がGoogle Cloudの試験を遠隔(オンライン)で受験する話 - G-gen Tech Blog 有効期限と再認定 Google Cloud 認定資格には、有効期限が設定されています。 Foundational レベルと Associate レベルの試験の有効期限は 3年間 、Professional レベルの試験の有効期限は 2年間 です。 再認定を受け資格を更新するには、以下の方法があります。 1. 再度、試験を受験する 再試験の受講可能期限内に再度、通常試験に合格することで、資格を更新する（再認定される）ことができます。受講可能期限は、Foundational レベルと Associate レベルの試験では「有効期限日の 180 日前以降」、Professional レベルの試験では「有効期限日の 60 日前以降」です。 2. 短縮版の更新試験を受験する Cloud Digital Leader、Associate Cloud Engineer、Professional Cloud Architect、および Professional Data Engineer のみ、通常試験より問題数が少ない 更新試験 が用意されています。更新試験は標準試験より問題数、受験費用、試験時間などが低く設定されており、小さい負担で資格を更新することができます。 3. Google Skills の受講 Google Skills と呼ばれる、Google が提供するオンラインラボの所定のコースを受講することでも、再認定を受けることができます。この場合、資格の期限は 1 年間のみ延長されます。この方法に対応しているのは Cloud Digital Leader、Associate Cloud Engineer、Professional Cloud Architect、および Professional Data Engineer のみです。 参考 : 認定資格の更新 資格取得の順番 Google Cloud 認定資格では「A の資格を取得しないと、B の資格を取得できない」といったような資格取得の順番指定はありません。いきなり Professional レベルの試験を受験しても構いません。 とはいえ、 Google Cloud の知識を順当に身につけていくためには、おすすめの順番があります。 エンジニアであれば、 Cloud Digital Leader もしくは Associate Cloud Engineer から始めるのが推奨されます。Cloud Digital Leader → Associate Cloud Engineer → Professional Cloud Architect → その他の Professional 試験、という順番で受験することで、順を追って Google Cloud 活用の知見が身につけられます。 一方、エンジニアとしてではなく、 経営目線やバックオフィス目線 で Google Cloud を捉える必要のある方は、 Cloud Digital Leader に挑戦 することが望ましいでしょう。 不合格時の再試験 もしGoogle Cloud 認定試験に不合格となってしまったら、再試験ポリシーに則って再度受験することができます。 Cloud Digital Leader 試験は、1年間に10回まで受験できます。もし試験に不合格となった場合、再受験まで14日のインターバルを空ける必要があります。 Associate レベルと Professional レベルの試験には、以下のようにインターバルが設定されています。 受験回数 再受験までのインターバル 1回 2回目の再試験までに14日間のインターバルが必要 2回 3回目の再試験までに60日間のインターバルが必要 3回 4回目の再試験までに365日間のインターバルが必要 Associate レベルと Professional レベルの試験の場合、受験回数は2年間で最大4回まで、という制限があります。受験がオンサイトかオンラインかにかかわらず、受験回数にカウントされます。 参考 : 再受験ポリシー 参考 : Google Cloud 認定資格試験のポリシーと試験の利用規約 Google Cloud 認定資格の詳細 Foundational レベル Cloud Digital Leader Cloud Digital Leader 試験は、Google Cloud に関する最も基礎的な資格です。推奨の実務経験期間などはありません。 Google Cloud を理解するための最初のステップとして最適な資格であり、 エンジニアでない方も取得を目指せ ます。 以下の記事で、難易度や試験対策方法について詳細に解説していますので、ぜひご参照ください。 blog.g-gen.co.jp また、以下は G-gen 社のセールスメンバーが当試験を受験した体験記です。非エンジニアが当試験を勉強するためのヒントにしてください。 blog.g-gen.co.jp G-gen のエンジニアが執筆した書籍「合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題」は、Cloud Digital Leader 試験の参考書です。こちらも、参考にしてください。 合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題 作者: 杉村 勇馬 , 又吉 佑樹 リックテレコム Amazon Generative AI Leader Generative AI Leader 試験は、 生成 AI に関する基礎的な知識 や、 Google Cloud や Google Workspace の生成 AI 関連サービス・機能の知識 が問われます。非技術系のビジネスパーソンも対象としている試験です。当試験は、2025年5月14日（米国時間）に一般公開されました。 この試験取得に向けて、Google は無料のオンライントレーニングコースを提供しています。当試験の合格に向けて有用なほか、ビジネスにおける生成 AI 活用のために重要な知識を学ぶことができます。 試験対策方法については、以下の記事をご参照ください。 blog.g-gen.co.jp Associate レベル Associate Cloud Engineer Associate Cloud Engineer 試験では、Google Cloud の基礎スキルが評価されます。 クラウドエンジニアの出発点 となる資格です。 公式ガイドには「Google Cloud での構築経験 6 か月以上を推奨」と記載されていますが、必ずしもそれを満たしていなくてもチャレンジできる資格です。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp G-gen のエンジニアが、試験対策書籍である「合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題 」を執筆しています。こちらも学習にあたりご参照ください。 合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題 作者: 杉村 勇馬 , 佐々木 駿太 , 藤岡 里美 リックテレコム Amazon Associate Google Workspace Administrator Associate Google Workspace Administrator 試験は、Google Workspace の基礎的な管理業務に関するスキルが評価されます。企業の情報システム部員などにおすすめの資格です。2024年10月末に Beta 版として公開され、2025年1月に GA（一般公開）されました。 基本情報技術者試験レベルの IT 基礎知識（DNS、E メール基盤、特権管理など）に加えて、Google Workspace の管理画面に日常的に触れている方であれば、追加の学習を数日〜1ヶ月程度行うことで十分に合格を狙えます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Associate Data Practitioner Associate Data Practitioner 試験は、Google Cloud 上のデータの保護や管理のためのスキルが評価される試験です。データパイプラインの管理、分析、可視化、機械学習などのタスクを Google Cloud 上で行った経験が問われます。2024年10月末に Beta 版として公開され、2025年1月に GA（一般公開）されました。 Google Cloud 上でのデータ取り込み、変換、パイプライン管理、分析、機械学習、および可視化等に関する知識や技能が問われます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional レベル Professional Cloud Architect Professional Cloud Architect 試験は、Google Cloud や関連テクノロジーに関する、設計、実装、管理に必要な高度なスキルを保持していることを示す資格です。 IT インフラとアプリケーション開発に対する、バランスの取れた知識 が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Database Engineer Professional Cloud Database Engineer 試験は、Google Cloud における データベース系サービスの知見 を問う試験です。Professional Data Engineer 試験がデータエンジニアリングに関する知識を問う試験であるのに対し、当試験は運用データベースに関する知識を問います。 アプリケーションからのデータへのアクセスユースケースに応じて適切なデータベースサービスを選定・設計し、管理・トラブルシューティングなどを行うことができることを示す資格です。 Cloud SQL、Firestore、Bigtable、Spanner 等に関する知見が求められます。反対に BigQuery など分析系データベースに関する出題はありません。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Developer Professional Cloud Developer 試験は、Google 推奨の手法を理解して、スケーラブルで高可用な アプリケーションを開発 できるエンジニアであることを示す資格です。 クラウドネイティブなアプリ、開発者ツール、マネージドサービス、次世代データベースの使用経験が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Data Engineer Professional Data Engineer 試験は、データの収集、変換、可視化など、 データエンジニアリングに関する技能 を持つエンジニアであることを示す資格です。 データ処理システムの設計、構築、運用、セキュリティ保護、監視に加え、機械学習に関する問題も出題範囲です。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud DevOps Engineer Professional Cloud DevOps Engineer 試験は、Google Cloud でアプリ開発を行ったり、 CI/CD パイプラインを構築したり、サービス監視・インシデント管理など、 IT サービスを安定稼働 させるためにはどうすればよいかといった知見が求められます。 Google の提唱する SRE （サイト・リライアビリティ・エンジニアリング）がその根底にあります。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Security Engineer Professional Cloud Security Engineer 試験は、Google Cloud 上で安全なインフラを設計、実装するできるエンジニアであることを示す、 セキュリティに特化 した認定資格です。 ネットワークセキュリティ、アプリケーションセキュリティ、認証認可、監査証跡等に関する知識が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Network Engineer Professional Cloud Network Engineer 試験は、Google Cloud の ネットワークアーキテクチャに関する深い知見 が求められる資格です。 Google Cloud のネットワーク系サービス、コンテナ（GKE）に関するネットワークキング、ハイブリッドクラウド等に関する知見が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Machine Learning Engineer Professional Machine Learning Engineer 試験は、 Google Cloud の AI/ML 系サービス を活用して、ビジネス課題を解決するための機械学習モデルの設計、構築、利用を推進できる 機械学習エンジニア であることを示す資格です。 機械学習モデルのアーキテクチャ、データパイプラインの相互作用、およびメトリックの解釈に熟達している必要があります。 Google Cloud の試験ではありますが、Google Cloud の知識に加えて、機械学習に関する知見が深く求められる試験です。机上の理論だけでなく比較的実践的な知識も求められるため、難易度は高いものとなっています。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Security Operations Engineer Professional Security Operations Engineer 試験は、Google Cloud プロダクトを中心とした セキュリティオペレーション担当者向け の認定資格です。 攻撃の検知や防衛・対応に関する技術的な知識からインシデント管理の体制に関するものまで、包括的に問われます。 特に、Google Security Operations（略称 Google SecOps）と Security Command Center が中心となります。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp 番外編 Professional ChromeOS Administrator Professional ChromeOS Administrator 試験は、Google の提供するコラボレーションツールである Google Workspace や ChromeOS デバイスの運用、管理に関する知識を問う試験です。 Google Cloud の公式ブログ で紹介されているものの、 Google Cloud 認定試験一覧 の公式ページには記載されておらず、Google 関連試験ではあるが Google Cloud 認定試験の扱いにはなっていません。 以下の記事で詳細に解説していますので、ご参照ください。 blog.g-gen.co.jp 廃止された試験 Looker LookML Developer Google の提供するデータプラットフォームツールである Looker における開発 (LookML) に関する知見 を問う認定資格です。 当試験は2022年4月1日をもって終了しました。参考までに、以下の記事で、どんな試験だったのかを確認することができます。 blog.g-gen.co.jp Looker Business Analyst Google の提供するデータプラットフォームツールである Looker のビジネスユースに関する知見 を問う認定資格です。 当試験は2021年12月31日で廃止となりました。 Professional Google Workspace Administrator Professional Google Workspace Administrator 試験は、 Google Workspace （旧称 GSuite） の導入や運用に関する知見 を求められる認定資格です。Active Directory と連携した認証・認可やシングルサインオンなど、企業 IT の周辺知識も求められます。 当試験は、2022年4月29日より以前は Professional Collaboration Engineer 試験 と呼称されていましたが、名称変更されました。また、2025年1月に後継の認定資格である Associate Google Workspace Administrator 試験が GA（一般公開）になり、当試験は廃止されました。参考までに、以下の記事で、試験の内容を確認することができます。 blog.g-gen.co.jp 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 / 2026 ・Google Cloud 認定資格 7冠 ・Jagu'e'r エバンジェリスト Follow @arapote_tweet

G-gen の杉村です。 BigQuery の Scheduled Query (スケジュールされたクエリ) で自動実行するクエリの、ジョブ失敗通知を行う方法について解説します。 はじめに 3つの方法 1. メール通知機能 2. Pub/Sub 3. ログベースの指標 ログベースの指標とアラートの作成手順 ログベースの指標とは 手順 1: ログベースの指標作成 手順 2: アラートの作成 メール通知の例と課題 Scheduled Query の限界 Cloud Monitoring と Cloud Logging はじめに Google Cloud (旧称 GCP) のデータウェアハウスサービスである BigQuery には Scheduled Query という機能が存在します。別名をスケジュールされたクエリ、あるいはクエリのスケジューリングと言います。この機能では定期的に BigQuery 上で SQL を実行することができ、この機能の利用自体に料金は発生しません (通常通りの BigQuery 料金のみが発生します)。 この機能では、前後関係や分岐のある複雑なジョブ管理はできないものの、日時を指定して定期的に SQL が実行できるため、簡易的な ELT 処理やデータマートテーブル作成などを行わせることができます。 しかしこの機能を使うに当たって課題となるのが、ジョブが失敗したときの通知です。当記事では、 Scheduled Query を使った際の失敗通知について解説します。 参考 : クエリのスケジューリング 3つの方法 1. メール通知機能 Scheduled Query には、ジョブが失敗した際にメールを送信する機能が備わっています。 デフォルトのメール通知機能 多くの方が、これを第一の選択肢として考えるはずです。 しかしながら、この機能は ジョブ作成者の Google アカウントのメールにしかメールが送信できない という仕様があります。 ドキュメントではワークアラウンドとしてメールを自動転送する方法が記載されていますが、これだとジョブ作成者のアカウントが退職等で削除されたときに通知ができなくなってしまいます。 メール通知 (このリンクは BigQuery Data Transfer Service のドキュメントですが、 Scheduled Query は同サービスの一部です) ジョブの失敗通知は、監視チームのメーリングリストであったり、インシデント管理ツールやチャットツールへの通知が必要になってくるでしょう。 そのようなニーズに、このデフォルト通知機能では答えることができません。 2. Pub/Sub もう一つの方法として、 Pub/Sub への通知が挙げられます。 前掲のスクリーンショットにあるように、ジョブの成功/失敗通知は Cloud Pub/Sub に通知することができます。 しかしながら Pub/Sub からメッセージを読み出すには、 Cloud SDK 等を用いる必要があり、基本的にはノーコードで実現できません。 Pub/Sub から Push 型で直接メール通知を発出する方法は 2022 年 1 月現在では存在しないため、例えば Pub/Sub トリガの Cloud Functions を作成してメール/チャットへ連携するなど、通知の仕組みを別途作成する必要があります。 Scheduled Query をそもそも、手軽にデータ変換を行うために利用しているのだとすれば、このような手間のかかる実装は選択肢としては選びづらいかもしれません。 その場合は次に挙げる代替案を検討します。 3. ログベースの指標 次の方法は、ログベースの指標とアラートを用いることです。 Scheduled Query (BigQuery Data Transfer Service) はジョブ実行の結果を Cloud Logging へ出力しています。 成功時・失敗時ともにログを出力します。エラー時のログは以下のようなものです。 Scheduled Queryのエラーログ このエラーログを検知して通知することが一つのワークアラウンドになりそうです。 この方法は簡単に実装できるため、以降当記事では、ログベースの指標とアラートを用いた通知の実装方法を紹介していきます。 ※なお特定ログを検知してアラートを発報する方法としては、今回ご紹介する「ログベースの指標 + アラート」よりもさらに簡単に実装できる ログベースのアラート 機能があります。こちらは執筆当時の 2021 年 12 月現在ではプレビュー機能だったため採用しませんでしたが、現在は GA されています。 ログベースのアラートを構成する ログベースの指標とアラートの作成手順 ログベースの指標とは ログベースの指標とは、 Cloud Logging に出力されたログにフィルタをかけて、その検出数を Cloud Monitoring の指標 (メトリクス) として利用する機能です。 今回は Cloud Logging に出力されたエラーログを、以下のようなフィルタで検知してみます。 resource.type="bigquery_dts_config" AND severity = "ERROR" 上記のフィルタは重要度が ERROR である Scheduled Query (BigQuery Data Transfer Service) ログを抽出するものです。 このフィルタを使ってログベースの指標を作成すると、 該当するログレコードの数を Cloud Monitoring に数値メトリクスとして送る ことができます。 そのメトリクスがしきい値を超えたときにアラートを発報するよう設定すれば、エラーログ出力を契機にメール通知や Slack 通知などを行うことができます。 ここからは、ログベースの指標と、それを元に通知を発報するアラートを Google Cloud コンソールで作成する手順をご紹介します。 手順 1: ログベースの指標作成 Google Cloud コンソールで ロギング > ログベースの指標 画面へ遷移します。 ボタン 指標を作成 を押下します。 指標を作成を押下 指標の設定値は以下のようにします。 指標タイプ: Counter ログ指標の名前: (任意) 説明: (任意) 単位: 空白 フィルタの作成: 以下の通り resource.type="bigquery_dts_config" AND severity = "ERROR" 指標の情報を入力 入力後、ボタン 指標の作成 を押下すると指標が作成されます。 以後は Cloud Monitoring の Metrics Explorer で、検出数をメトリクス (指標) として確認できます。 メトリクス名は logging/user/(指定した指標名) となります。 手順 2: アラートの作成 指標作成後に現れる以下の画面から「指標に基づくアラートを作成する」を押下します。 指標作成後の画面 この画面を閉じてしまっている場合は、 Google Cloud コンソールで Monitoring > アラート 画面へ遷移してボタン + CREATE POLICY を押下します。 次の画面で ADD CONDITION を押下し、 Target として logging/user/(指定した指標名) を指定します。 (指標作成後の画面から遷移した場合は、ここまでは自動で入力されます) アラート作成画面 Period として、メトリクスを集計する時間単位を指定します。 Configuration のブロックで、発報の条件を指定します。 Configurationブロック 例えば Period が 10 minutes で Aggregator が Sum 、 Configuration にて is above 10 for most recent value のように設定した場合、 10 分間で検知されたログ数の合計が 10 を超えた場合に発報がトリガーされます。 is above 0 としておけば、 1 個でもエラーが出れば発報されるようになります。 ボタン ADD を押下してしきい値設定画面を閉じたら 次へ を押下して、通知先設定へ遷移します。 通知先設定 通知先は Cloud Monitoring の Notification Channel という設定値として管理することができます。 メールや Slack の他、 Webhook で外部 API を呼び出したり、 Pub/Sub へメッセージを Publish することもできます。 Notification Channel を事前に作っていない場合、この画面で新規作成が可能です。 なおアラートが発生すると Cloud Monitoring 内で「インシデント」が起票されますが、インシデントの自動クローズ期限などもここで設定できます。 ボタン NEXT を押下して、最後にアラート名を設定し、ボタン SAVE を押下します。 アラート名の設定 ここまで設定すると、しきい値を超えた際に Notification Channel へ通知が行われます。 メール通知の例と課題 通知先をメールとした場合、以下のようなメールが届きます。 メールの例 課題として、メール本文からは 「どのジョブがコケたか」「どのようにコケたか」は分からない 点があります。 その代わりメール内の VIEW LOGS ボタンを押下して Google Cloud コンソールへログインして該当するログを閲覧すれば、エラー本文や該当する Scheduled Query ジョブの ID が確認できます。 しかしこれでは、 Google Cloud コンソールへログインする権限を持たないメンバーがメールを受け取る場合、対処が取れません。 メール本文からどのジョブがこけたかを把握するには、例えばフィルタを以下のようにして、ジョブごとにログベース指標とアラートを作成する方法が挙げられます。 resource.type="bigquery_dts_config" AND severity = "ERROR" AND resource.labels.config_id="xxxxxxxx-0000-0xxx-0000-xxxxxxxxxxxx" resource.labels.config_id として指定している xxxxxxxx-0000-0xxx-0000-xxxxxxxxxxxx の部分は、各 Scheduled Query の詳細画面の 構成 タブで確認できる「リソース名」の末尾部分の英数字です。 config_id こうしてジョブごとにログベース指標とアラートを作成すれば、メール本文にはアラート名や指標名が記載されるため、メール本文から「どのジョブがコケたか」までは把握することができます。 ただし、依然として「どのようにコケたか」までは分からないうえ、ジョブ数 (Scheduled Query 数) が多くなると、ジョブごとに指標とアラートを作成しなければならず、現実的ではありません。 メールによる通知はあくまで簡易的な通知に留め 、実際の対処はコンソールにログインしてログを確認する、というオペレーションが現実的でしょう。 Scheduled Query の限界 Scheduled Query では、前述の通知の課題に加えて、前後関係や分岐のあるジョブネットを組むことに限界があります。 ジョブ失敗時のリトライ処理なども、うまく管理することが難しいでしょう。 一定以上複雑なジョブの場合は Scheduled Query だけでジョブを構成することを諦めて、 ワークフロー管理ツールを導入することを検討 しましょう。 3rd party 製品の検討はもちろん、 Google Cloud サービスであれば Cloud Composer などが該当します。 また Cloud Data Fusion や Dataprep といったツールも検討対象です。 Cloud Monitoring と Cloud Logging 当記事でご紹介した Cloud Logging の使い方や、 Cloud Monitoring の指標やアラートの概念については以下の記事で紹介していますので、ご参考にお願いいたします。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは株式会社G-genの渡邉@norryです。 皆さんコラボレーションツールのGoogle Workspaceは利用されていますか？ 今現在企業で利用されているGoogle WorkspaceのエディションとしてはGoogle Workspace BusinessやEnterpriseエディションを利用されている方も多いのでは無いかと思います。 全社でGmailを全員利用したいけど、現場スタッフ全員にライセンスを割り当てるには料金が...利用する端末どうしよう...どうやって契約すればいいの...などといった事はありませんか？ そういった方に向けてGoogle Workspace Frontline のご紹介になります。 Google Workspaceとは？ Frontlineエディションについて Frontlineエディションとは 現場スタッフの定義 利用可能なサービス 仕様についての注意点 契約に際しての注意点 ユースケース審査 エディション混在のみで利用可能 契約期間と支払い 申込み方法 最後に Google Workspaceとは？ Google Workspaceの 公式サイト には「あらゆる働き方に対応する生産性向上とコラボレーションのツール。」とあり、また従業員の生産性＝チームx会社の文化＝コミュニケーション＋コラボレーションと言い換える事が出来ます。 その組織のコミュニケーションとコラボレーションを下支えし促進するツールがGoogle Workspaceとなります。 Google Workspace には費用の異なる複数のエディションが存在します。詳しくはこちらの記事を参照ください。 blog.g-gen.co.jp Frontlineエディションについて Frontlineエディションとは Google Workspace の Frontline エディションとは、 第一線で活躍する現場スタッフ向け のエディションです。 統制が取れた上でと表現したのは、現場スタッフは業務を遂行する上で知りたい情報を得るのに自分たちの個人デバイスやアプリを使うほかない状況が推測されるからです。 そういった状況はシャドーITとも繋がり企業にとっては望ましくない状況でしょう、きちんと管理下に置いた上で適切な情報を素早く得られる状態が望ましいはずです。 現場スタッフの定義 Google Workspace Frontlineを利用可能な現場スタッフの定義は以下になります。 不特定多数の人に直接対応して、サービスやサポート、商品販売を行う 製品やサービスの製造、配送に直接携わる 戦力の大部分を構成し、業務遂行にはスピードと共同作業が重要である 該当する具体的な現場スタッフの例: 製造業の組み立て作業員 レストラン、接客業、小売業のスタッフ 農業、漁業、林業の従事者 建設作業員 主に屋外で作業するスタッフ コールセンターや交通機関のオペレーター 利用可能なサービス 価格や利用人数の制限などは下記のようになっています。 Frontline Business Starter Business Standard Business Plus 基本情報 月額料金（1ユーザーあたり※税別） 520円 680円 1,360円 2,040円 利用可能人数 無制限 1〜300名 1〜300名 1〜300名 ストレージ容量 2G 30GB 2TB 5TB 24時間365日の電話サポート ✔ ✔ ✔ ✔ 利用可能なコアサービスは下記の通りです。 Frontline Business Starter Business Standard Business Plus コアサービス Gmailとカレンダー ✔ ✔ ✔ ✔ ビジネス向け Google グループ ✔ ✔ ✔ ✔ ChatとChatスペース ✔ ✔ ✔ ✔ ドライブ ストレージとドキュメント エディタ ✔ ✔ ✔ ✔ Meet によるビデオ会議 ✔ ✔ ✔ ✔ ディレクトリ管理 ✔ ✔ ✔ ✔ Cloud Searchによるドメイン内検索 ✔ ✔ Google Vault ✔* ✔ 基本的な機能はほぼ利用出来ると言って良いでしょう、また上記に加えてFrontlineではデバイス管理において「基本のエンドポイント管理」「高度なエンドポイント管理」が利用可能となっており、現場スタッフが利用するにあたって企業のガバナンスを効かせる事が可能です。 ※ Vault は Frontline では有料アドオンとしてご利用いただけます。 仕様についての注意点 「共有ドライブ」の作成機能は無いが、すでに作成されている共有ドライブに参加する事は可能 Frontline ユーザーは「共有ドライブ」のフォルダは 「閲覧」 しかできない ただしファイル単位で権限を付与すれば編集可能（フォルダ単位・ドライブ単位では編集権限を付与できない。 参考 ） 1ユーザーあたりのメール、ドキュメント、写真の保存容量を含めて2GBとなっている Cloud Searchを使った横断的な検索ができない と言った事が上げられます。特に「共有ドライブ」のドライブのルートやフォルダには 閲覧権限 しか与えられない事に注意してください (ファイル単位で編集権限を付与することはできます) 。この事からも現場スタッフに特化したプランと言えます。 契約に際しての注意点 ユースケース審査 その特性上、Frontlineを契約する場合には Google 社の要件に沿っているか？ が Google によって審査されます。 Google Cloud 社と直接契約の場合には Google Cloud 社が直接審査を実施します。 パートナー経由で利用している場合にはパートナーが Google Cloud 社と協議いたします。 Frontline のユースケースに合致していると判断された場合のみ、契約が可能となります。 エディション混在のみで利用可能 Frontline エディション 単体での契約は不可 であり Frontline + 別エディション のように混在した形でのみ契約が可能です。 例えば Business Standard + Frontline などです。 ただし Frontline 以外のプランに関しては、例えば Business StandardとBusiness Starter 等のように複数のエディションやプランを混在させて契約する事は 出来ません のでご注意ください。 契約期間と支払い Frontline を契約するにあたって、契約期間と支払いは以下の通りです。 混在して契約する Frontline 以外のエディションもあわせて以下になりますのでご注意ください。 ライセンス数を定めた年間契約 (12ヶ月間) 契約締結翌月の月初に請求書発行・翌月末に 12 ヶ月分をまとめて支払 年途中でユーザーを追加する場合は、残月分を前払い 現在の契約次第では手続きに 2〜3 週間かかる場合がある 申込み方法 上記の注意点を見ても分かります通り、現在の環境や契約形態によって検討する部分が多い為、弊社株式会社G-genにお気軽にご相談ください。 docs.google.com 最後に Frontlineを上手く組み合わせる事で全社一丸となった働き方変革、コミュニケーション、コラボレーションの促進にお役立ち出来る事かと思います。 弊社株式会社G-genではGoogle Workspace / Google Cloud（GCP）/ Chrome book の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 また Google Workspace / Google Cloud (GCP) を5%割引でご提供しております。 既に Google Cloud をご利用中の方も、新規にご利用開始を検討されている方も、お気軽にご連絡ください。 g-gen.co.jp 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-genの渡邉@norryです。当記事では、現場スタッフにリーズナブルな価格で Google Workspace ライセンスを割り当てるための Google Workspace Frontline エディションを紹介します。 概要 Frontline エディションとは 現場スタッフの定義と審査 仕様 利用可能な機能 機能の制限 人数や容量の上限 Starter、Standard、Plus の比較 注意点 主な機能制限 エディション混在のみで利用可能 契約期間と支払い 購入にあたり 概要 Frontline エディションとは Google Workspace の Frontline エディション とは、第一線で活躍する 現場スタッフ向けのエディション です。なお Frontline（フロントライン）とは、「前線」を意味する英単語です。 Frontline エディションは、他のエディションと比較して機能制限はあるものの、比較的安価にライセンスを購入することができます。 Frontline エディションには Frontline Starter 、 Frontline Standard 、 Frontline Plus の3種類が存在します。上位エディションになるほど、セキュリティ管理機能が強化されます。 参考 : Frontline エディション 現場スタッフの定義と審査 Frontline エディションを利用可能な「現場スタッフ」の定義は、以下のとおりです。 不特定多数の人に直接対応して、サービスやサポート、商品販売を行う 製品やサービスの製造、配送に直接携わる 戦力の大部分を構成し、業務遂行にはスピードと共同作業が重要である 具体的には、以下のような従業員が該当します。 製造業の組み立て作業員 レストラン、接客業、小売業のスタッフ 農業、漁業、林業の従事者 建設作業員 主に屋外で作業するスタッフ コールセンターや交通機関のオペレーター Frontline エディションのライセンスを購入するには、利用する従業員が上記の要件に沿っているか、 Google によって審査 が行われます。 Google Cloud と直接契約をする場合には、Google Cloud 社が直接、審査を実施します。G-gen のような販売パートナー経由で契約する場合、パートナーが Google Cloud 社と協議することが可能です。 Frontline のユースケースに合致していると判断され、審査をクリアした場合のみ、購入が可能となります。 仕様 利用可能な機能 Frontline エディションでは、以下のような機能が利用可能です。Business エディション以上で使える Google Workspace のほとんどの機能が、Frontline エディションでも利用できることがわかります。 Gmail とカレンダー ビジネス向け Google グループ Chat とチャットルーム ドライブ ストレージとドキュメント エディタ（Google ドキュメント、スプレッドシート、スライド、フォーム、サイトを含む） Meet によるビデオ会議 ディレクトリ管理 サイト その他の Google サービス Colab: データ サイエンスと機械学習モデルを共同で開発できます（その他の Google サービスとして、ユーザー ライセンスは不要）。 Colab Pro と Colab Pro+（アドオン） エンタープライズ級のデータ保護を備えた Gemini アプリ AppSheet Core Gemini Notebook（旧 NotebookLM） Cloud Search（Frontline Plus のみ） AppSheet Core 上記は、一部抜粋です。利用可能な機能の一覧や詳細は、以下の公式ドキュメントを参照してください。 参考 : Frontline エディションの比較 機能の制限 Frontline エディションでは、Business 以上のエディションと比較して、以下のような機能制限があります。 Google ドライブの共有ドライブには、 閲覧者権限 しか付与できない（ファイルに直接権限を付与する場合は、編集も可能） Google Vids は視聴のみ（編集ができない） Gemini ウェブアプリは利用可能だが、Gemini Advanced ではない（高度な機能が利用できない） 人数や容量の上限 Google Workspace の各エディションには、ライセンス数の上限や、ストレージ容量に上限が設けられています。以下の表では、3種類の Frontline エディションと、比較のために Business Starter および Plus エディションの上限を記載しています。 エディション ユーザー数 ストレージ容量 Frontline Starter 無制限 5 GB/ユーザー Frontline Standard 無制限 5 GB/ユーザー Frontline Plus 無制限 5 GB/ユーザー Business Starter 300 30 GB/ユーザー Business Standard 300 2 TB/ユーザー Business Plus 300 5 TB/ユーザー Starter、Standard、Plus の比較 Frontline Starter では、デバイス管理において「基本のエンドポイント管理」「高度なエンドポイント管理」が利用できます。一方、Frontline Standard や Plus では、「 エンタープライズエンドポイント管理 」が利用可能となっており、現場スタッフが利用するにあたって、より高度な統制とセキュリティを発揮する事が可能です。 最上位の Plus エディションでは、高度なデータエクスポートや、クライアントサイト暗号化、データリージョンの指定、監査情報の BigQuery へのエクスポート、ログイベントの Google SecOps へのエクスポートなど、より高度なセキュリティ機能が利用できます。 詳細な一覧は、以下のドキュメントを参照してください。 参考 : Frontline エディションの比較 注意点 主な機能制限 Frontline エディションでは、以下の制限に特に注意が必要です。 「共有ドライブ」の作成機能は無いが、すでに作成されている共有ドライブに参加する事は可能 Frontline ユーザーは組織内の共有ドライブに、 閲覧者 権限のみを付与可能 フォルダ単位・ドライブ単位では編集者権限を付与できない ただしファイル単位では、編集者権限を付与できる 参考 : 共有ドライブを作成する 組織外の共有ドライブのメンバーとして追加される場合は、 管理者 などの任意のアクセスレベルを付与できる 参考 : 組織の共有ドライブを設定する 1ユーザーあたりのメール、ドキュメント、写真の保存容量は 5 GB 特に、組織内の共有ドライブには閲覧権限しか付与できない点には注意が必要です。Frontline エディションは、あくまで現場スタッフに特化したライセンスのため、ドライブ上のファイルの主要な管理者としては想定されていないと考えられます。 エディション混在のみで利用可能 Frontline エディションは、単体での契約は不可であり、 Business 以上の別のエディションとの組み合わせる 形でのみ、購入が可能です。例えば、 Business Standard + Frontline Starter のように、エディションを混在させる場合で購入ができます。 ただし、Frontline 以外のプランに関しては、例えば Business Standard + Business Starter のように、複数のエディションやプランを混在させて契約する事はできない点に注意してください。 契約期間と支払い Frontline を契約するにあたって、契約期間と支払いは以下のとおりです。混在して契約する Frontline 以外のエディションも、あわせて以下が適用されますのでご注意ください。 ライセンス数を定めた年間契約（12ヶ月間） 契約締結翌月の月初に請求書発行・翌月末に 12 ヶ月分をまとめて支払 年途中でユーザーを追加する場合は、残月分を前払い 現在の契約次第では手続きに 2〜3 週間かかる場合がある なお、この情報は G-gen 社の過去実績に基づいています。最新情報は、Google Cloud 社や販売パートナーにご確認ください。 購入にあたり 上記の注意点を見てもわかるとおり、現在の環境や契約形態によって考慮すべき要素が多いため、Frontline エディションの購入は、経験ある販売パートナーに相談することが推奨されます。 当記事を執筆した株式会社 G-gen のお問い合わせフォームより、お気軽にご相談ください。 参考 : ご相談・お問い合わせフォーム - 株式会社G-gen G-gen では Google Workspace や Google Cloud（旧称 GCP）を割引価格で提供しています。既に Google Cloud や Google Workspace をご利用中の方も、新規に利用開始を検討している方も、お気軽にご連絡ください。 参考 : Google Cloud 請求代行 - 株式会社G-gen 渡邉 宣之 (記事一覧) クラウドソリューション部 AI/ML、アプリケーションモダナイゼーション、データ分析基盤の構築、クラウド管理運用やネットワークなどインフラ系は何でも、Google Workspace 活用も推進中 週末フォトグラファーで、観葉植物や塊根植物にハマっていて種から育ててます。

Google が提供するゼロトラスト・ソリューションである Chrome Enterprise Premium （旧称 BeyondCorp Enterprise）を紹介します。 Chrome Enterprise Premium の概要 Chrome Enterprise Premium とは 実現できること ゼロトラストセキュリティとは 構成要素 運用 ID（ユーザーアカウント） 外部 ID 連携 監査ログ 料金 Chrome Enterprise Premium の料金 その他の課金 無料範囲 技術的な詳細 01. Identity-Aware Proxy（IAP） Identity-Aware Proxy（IAP） とは 他のプラットフォームへの中継 02. Identity and Access Management（IAM） 03. Access Context Manager Access Context Manager とは [A] IP アドレスレンジ [B] 地域 [C] プリンシパル（主体） [D] デバイスポリシー 04. Endpoint Verification その他の機能 Threat and Data Protection Cloud Console / Google Cloud API へのアクセス制御 Chrome Enterprise Premium の概要 Chrome Enterprise Premium とは Chrome Enterprise Premium （旧称 BeyondCorp Enterprise）は、エージェントレス・VPN レスで社内 IT サービスへのアクセスを実現する、 Google のゼロトラスト・セキュリティサービスです。Chrome ブラウザの利用を前提としており、特に Google Workspace や Chromebook を社内 IT の中心に置いている組織にとって、有効なセキュリティソリューションといえます。 Chrome Enterprise Premium を用いると、インターネット VPN を使うことなく、インターネット経由で安全に社内システムや SaaS などへアクセスすることができます。また、データ損失防止（DLP）機能やフィッシング対策など、多くのセキュリティ機能を具備しています。 重要なキーワードとして、 コンテキストアウェア アクセス があります。例として「会社承認のデバイスであること」「会社の Google アカウントでログインしていること」という条件を満たしていれば社内の顧客情報システムへのアクセスを許可する、といった設定が可能です。なおかつ、 IT 管理者は VPN ルーターやゲートウェイ（プロキシ）の管理をする必要がありません。 なお旧称である BeyondCorp Enterprise の BeyondCorp は、後述のゼロトラストセキュリティを実現するために Google が開発した実装モデルを指しています。BeyondCorp を一般の組織向けに販売するプロダクトが Chrome Enterprise Premium です。 参考 : Chrome Enterprise Premium 参考 : Chrome Enterprise Premium overview 実現できること Chrome Enterprise Premium では、以下のようなことが実現できます。 VPN なしで Google Cloud 他のプラットフォーム上の Web アプリケーションにアクセスできるようにする 社内システムにアクセスできる端末を、社用端末だけに制限する モバイル デバイスから社内データにアクセスできるようにする 従業員が機密データをコピーして持ち出せないようにする Chrome Enterprise Premium を利用すると、以下のような情報をもとにしたアクセス制御が可能になります。 接続元 IP アドレス デバイス情報 Google アカウントや Google グループ サポートされているサードパーティ製品（CrowdStrike 等）からの情報 ゼロトラストセキュリティとは 前述のようにユーザーのリクエストのコンテキスト（デバイス状態、アクセス状況等、 ID とパスワードだけに頼らない各種背景情報）を判断に使ってアクセス制御を行う方式は ゼロトラストセキュリティ と呼ばれます。Google 社では実際に、BeyondCorp の仕組みを社内で利用し、 VPN レスなゼロトラストセキュリティを実現しているといわれています。 ゼロトラストセキュリティは、従来型の「社内と社外を境界線のファイアウォールや UTM で区切る」「社内ネットワークからのアクセスであれば安全とみなして、全て許可する」という 境界型ネットワーク とは、考え方が異なります。 境界型セキュリティ vs ゼロトラスト 2010 年代以降に一般的になった標的型攻撃等により、社内ネットワークにマルウェアが入り込んだり、あるいは侵入者にひとたび社内ネットワークに入り込まれると、境界型セキュリティは意味をなしません。これが、近年ゼロトラスト・セキュリティが注目されている理由です。 Chrome Enterprise Premium は Google が自社で実現したゼロトラストをサービス化したものであり、多数の実績のあるソリューションだといえます。 構成要素 Chrome Enterprise Premium は次の 4 つのコンポーネントで構成されます。 No 名称 概要 説明 01 Identity-Aware Proxy（IAP） マネージドのリバースプロキシ 社内サーバなどへの接続を中継してくれる Google Cloud 上の仕組み 02 Identity and Access Management（IAM） Google Cloud の権限管理機構 Google アカウントと権限を紐づける仕組み 03 Access Context Manager ルールエンジン デバイス情報、アカウント情報、接続状況など各種背景情報からアクセス可否を判断する仕組み 04 Endpoint Verification エンドポイント エージェント ユーザーのデバイス情報を収集する Google Chrome 拡張機能 各コンポーネントの機能を図で表すと、以下のようになります。 各コンポーネントの機能 この図では IAP が単一障害点（SPOF）に見えてしまうかもしれませんが、IAP は Google の高度にスケーラブルなインフラで稼働しているため、物理的には単一障害点にはならず、高い可用性を持っています。IAP の物理的な構成要素の一つである Cloud Load Balancing は月単位で 99.99% の SLA が定義されています。 参考 : Compute Engine Service Level Agreement (SLA) また、その他の機能として Threat and Data Protection があります。Threat and Data Protection は、Chrome ブラウザの追加機能として提供され、マルウェアやソーシャルエンジニアリングなどのウェブ上の脅威に対する保護や、Data Loss Prevention（DLP）ルール、セキュリティアラート、レポートツールを提供します。 運用 ID（ユーザーアカウント） 認証に用いられる ID（ユーザーアカウント）は、原則 Google アカウントです。 Google アカウントは Google Workspace または Cloud Identity で管理されます。1人の個人に対して、1つの Google アカウントが発行されます。詳細は、以下の記事も参照してください。 blog.g-gen.co.jp 外部 ID 連携 外部 ID 連携 を用いることで、以下のような外部 ID を Google アカウントと連携して認証することもできます。 メールアドレスとパスワード OAuth（Facebook、X、GitHub、Microsoft など） SAML OIDC 電話番号 カスタム 匿名 参考 : External identities 監査ログ デフォルトでは、アクセスポリシー違反をしたログは、全て Cloud Audit Logs により記録されます。 追加の手順を実行することで、違反ログだけでなく、すべてのリクエストを詳細にログに出力することも可能です。 参考 : Identity-Aware Proxy audit logging ログは、Cloud Logging の Log Explorer を使うことなどによって閲覧できます。ログを Cloud Logging から BigQuery へエクスポートすることで、より深い分析も可能です。Cloud Audit Logs や Cloud Logging の詳細については、以下の記事をご確認ください。 blog.g-gen.co.jp blog.g-gen.co.jp 料金 Chrome Enterprise Premium の料金 Chrome Enterprise Premium の料金は、1ユーザーあたり月額 $6 です。 Chrome Enterprise Premium の購入は、Web コンソール等からは行うことはできません。Google もしくは販売パートナーの担当営業へお問い合わせください。その際に利用人数を申請しますが、その申請アカウント数ベースで課金が行われます。 参考 : Chrome Enterprise Premium その他の課金 利用人数ベースの課金のほか、Chrome Enterprise Premium の使用に伴いデプロイされた Cloud Load Balancing などに料金が発生します。 また ID 管理のための Google Workspace や Cloud Identity（Premium の場合）のアカウント料金も、別途発生することに注意が必要です。 無料範囲 Google Cloud では Cloud IAP が無料で利用できます。 Chrome Enterprise Premium を購入しなくとも、Cloud IAP を活用することで、Google Cloud 上で稼働する Web アプリケーションへのアクセス制御や、踏み台サーバ無しでの VM へのログインなどが実現できます。以下の記事も参照してください。 blog.g-gen.co.jp 技術的な詳細 ここまでは、Chrome Enterprise Premium の基本的な概念を解説しました。ここからは技術的な観点で、 Chrome Enterprise Premium の構成要素を解説します。 01. Identity-Aware Proxy（IAP） Identity-Aware Proxy（IAP） とは Identity-Aware Proxy（IAP） は、 フルマネージドのリバースプロキシ です。簡単に言うと、社内システムへの接続を中継してくれる、 Google Cloud 上の仕組みです。 「フルマネージド」というのは、 この仕組みが Google の管理するインフラの上で動いているため、 インフラ管理・運用をする必要がない ということを意味しています。 IAP が中継するのは基本的には HTTP（S）トラフィックですので、 Web アプリケーションが利用対象となります。IAP が中継を許可するかどうかは、後述の IAM や Access Context Manager で定義したルールに基づいて判断されます。つまりインターネットから社内システムへアクセスする際、ユーザー情報やデバイス情報に基づいてアクセス可否が判断されるため、社内システムを安全に利用することができます。 この仕組みにより、インターネット VPN に頼らない、セキュアなアクセスを構築できます。 参考 : Securing resources with IAP 他のプラットフォームへの中継 Cloud IAP は、Google Cloud 上に Google Compute Engine（GCE）や Google Kubernetes Engine（GKE）で構築された Web アプリケーションに加え、Amazon Web Services（AWS）や Microsoft Azure、オンプレミスなど、他のプラットフォーム上で稼働する Web アプリケーションにも対応しています。 参考: Securing resources with IAP 参考: オンプレミス アプリの IAP の概要 他のプラットフォーム上の Web アプリを中継する場合、 コネクタ をデプロイする必要があります。コネクタの実体は、Cloud Load Balancing の外部アプリケーションロードバランサーと、Google Kubernetes Engine（GKE）でホストされたアプリケーションです。 IAP経由でオンプレミスアプリへアクセスする コネクタから Web アプリケーションへの通信は、HTTPS などの暗号化プロトコルであればインターネット経由でもリスクは低いといえます。 HTTP などの非暗号化プロトコルの場合は、Google Cloud の VPC とオンプレミス環境が Cloud Interconnect（専用線）やインターネット VPN で接続されているべきです。 02. Identity and Access Management（IAM） Identity and Access Management は略称を IAM といい、Google Cloud の認証・認可の管理機構です。特にクラウドサービスでは一般的な用語です。 参考: Applying IAM conditions IAM は「 誰 （プリンシパル、主体）が、どういった 条件 （コンディション）のもとで、 何に対して （対象リソース）、 何をできる （ロール、権限）か」というルールセットを管理します。 Google Cloud の IAM の特徴として「誰（プリンシパル、主体）が」「どういう条件（コンディション）のもとで」「何をできる（ロール、権限）」という情報を、 操作対象のリソースに設定する 形になっている点が挙げられます。この紐付けを バインディング（binding） と呼びます。バインディングは IAM policy と呼ばれる、各リソースの属性として保持されます。 Chrome Enterprise Premium では、アクセス制御対象の Web アプリケーションに対して Cloud IAP 上で IAM policy を設定し、「誰（プリンシパル、主体）が」「どういう条件（コンディション）のもとで」「何をできる（ロール、権限）= どのサービスに対して接続できる」という細かいアクセス制御が実現可能です。 Google Cloud の IAM の仕組みについては、以下の記事で詳細に紹介しています。さらに深堀りして理解したい方はご参照ください。 blog.g-gen.co.jp 03. Access Context Manager Access Context Manager とは Access Context Manager は、デバイス情報、アカウント情報、接続状況など、リクエストの背景情報からアクセス可否を判断する仕組みです。 参考 : Limiting access Access Context Manager は IAM とセットで使われます。 IAM の「条件（コンディション）」として Access Context Manager が使われるイメージです。 個々の条件設定オブジェクトを アクセスレベル と呼びます。アクセスレベルでは、以下の要素を条件として利用できます。 [A] IP アドレスレンジ [B] 地域 [C] プリンシパル (主体) [D] デバイスポリシー 参考 : Access level attributes [A] IP アドレスレンジ 許可する接続元 IP アドレスを、CIDR 形式（ x.x.x.x/x ）で指定できます。 IPv4 と IPv6 の両方に対応しており、パブリック IP のみを指定できます。 [B] 地域 アクセス元 IP アドレスから地理情報が判断され、指定した地域からのアクセスのみが許可されます。 条件に複数地域を指定すると、OR で判定されます。 なおパブリック IP アドレスから判定されるため、地域を条件に指定すると、Private Google Access（限定公開の Google アクセス）等を使ったプライベート IP アドレスからのアクセスは拒否されます。 [C] プリンシパル（主体） アクセスに使われるプリンシパル（Google アカウントやサービスアカウント）です。 そもそも IAM policy は Google アカウントや Google グループ、サービスアカウントと紐付けられて作成されるので、条件の中でプリンシパルを指定することは限定的かもしれません。同じグループに紐付いている IAM policy で、プリンシパルによって条件を少し変えたい、というときに利用します。 [例] Google グループ ops-grp@example.com に対して、システム A への IAP アクセスを許可する IAM policy がある その IAM policy の条件として以下を設定 tom@example.com は 9:00-18:00 の時間帯でアクセスを許可 mary@example.com は 18:00-09:00 の時間帯でアクセスを許可 [D] デバイスポリシー 後述の Endpoint Verification で取得されたデバイスポリシーと合致しているかどうかを条件として設定できます。これにより、会社指定の端末以外がサービスに接続することを防いだり、セキュアでない設定の端末が、Web サービスに接続することを防ぐ事ができます。 以下の要素を条件としてチェックできます。 スクリーンロックの強制 ストレージ暗号化 デバイスが管理者に承認されていること 会社指定のデバイスであること 会社指定の OS であること 04. Endpoint Verification Endpoint Verification （エンドポイント・ベリフィケーション）は Chrome ブラウザの拡張機能（Chrome Extention）を使い、ユーザー情報や端末の情報を収集します。 つまり各 PC の Chrome ブラウザに拡張機能をインストールする必要があります。Google Workspace を利用している場合は Endpoint Verification Chrome extension を管理コンソールから一斉配布・自動展開が可能です。 参考 : Endpoint Verification overview 参考 : Gathering device information その他の機能 Threat and Data Protection 前述の主要な4つの構成要素に加えて、 Threat and Data Protection 機能を利用できます。 これは Chrome ブラウザの追加機能として提供され、マルウェアやソーシャルエンジニアリングなどのウェブ上の脅威に対する保護や、 Data Loss Prevention（DLP、データ損失防止）ルール 、 セキュリティアラート 、 レポートツール を利用できるようになります。 DLP 機能 では、 Chrome 上で機密データの共有に関して警告を出したりブロックしたりします。 ファイルのアップロード・ダウンロードや、コピー&ペーストの中に、クレジットカード番号や大量のメールアドレスが含まれている場合などに当機能が働き、ブロックやアラート発報などを行うことができます。ただしこの機能は Windows、Mac、Linux、Chrome OS の Chrome ブラウザでのみ機能する ことに注意が必要です。 また、 監査ログ 、 セキュリティ ダッシュボード 、 レポーティング 機能も充実しています。 「Chrome の脅威対策に関する概要」「Chrome のデータ保護に関する概要」「リスクの高い Chrome ユーザー」「リスクの高い Chrome ドメイン」などのレポートを表示することができ、マルウェアの転送、危険なサイトへのアクセス、パスワードの再利用、機微なデータの転送などのアクティビティを可視化できます。 従業員の活動を Chrome ブラウザに集約・制限したうえで Threat and Data Protection をうまく活用することで、情報漏洩のリスクを下げる事が可能です。 参考 : Chrome Enterprise Premium で Chrome ユーザーを保護する Cloud Console / Google Cloud API へのアクセス制御 Google Cloud の Web コンソールや、gcloud コマンドライン、SDK を使った Google Cloud API へのアクセス制御を行うことができます。 この機能を使って、Google Cloud 環境の運用者や開発者に対し、接続元 IP アドレスやデバイスポリシーに基づいたアクセス制御をかけることができます。 アクセスレベルの定義に違反する運用者は、コンソール画面にアクセスできないほか、CLI や SDK を使った環境操作もできなくなります。 blog.g-gen.co.jp 参考 : Secure the Google Cloud console and the Google Cloud APIs 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。 Google は The Google Cloud Adoption Framework というフレームワーク (考え方や施策の枠組み) を公表しています。 このフレームワークでは、組織がクラウドを導入するときにどのように考え、施策に取り組むべきかについての指針を示しています。 技術的な視点にとどまらず、 組織づくりや経営層の関わり方も含めた、包括的なフレームワーク となっています。 以下のページから無料でホワイトペーパーを閲覧することができます。 cloud.google.com ただし、ドキュメントは残念ながら英語でしか公開されていません。 当記事では The Google Cloud Adoption Framework を抄訳 (逐語訳ではなく要約しつつ翻訳) し、紹介したいと思います。 当記事の内容は、図を含め、前述の The Google Cloud Adoption Framework ホワイトペーパーから抜粋・翻訳したものとなりますが、一部に翻訳者 (杉村) の解釈や解説を含むことをご了承ください。 また (※) で挿入された注釈は翻訳者によるものです。 第一部: エグゼクティブ・サマリー 1-1. 四つのテーマ、三つのフェイズ 1-2. クラウド成熟度 1-3. エピック 1-4. The Google Cloud Adoption Framework とは 1-5. はじめかた 1-5-1. クラウド成熟度の測定 1-5-2. ゴールを決める 1-5-3. クラウド導入プログラムを計画する 1-5-4. ちょうどよいワークロードを見つける 第二部: テクニカル・ディープダイブ 2-1. クラウド成熟度の各段階について 2-1-1. Tactical (戦術) 段階 2-1-2. Strategic (戦略) 段階 2-1-3. Transformational (柔軟) 段階 2-2. 各テーマごとのクラウド成熟度 2-2-1. Learn (学習) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-2-2. Lead (リード) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-2-3. Scale (スケール) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-2-4. Secure (セキュア) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-3. エピック 2-3-1. アクセス管理 2-3-2. アーキテクチャ 2-3-3. 振る舞い 2-3-4. CI/CD (Continuous integration and delivery) 2-3-5. コストコントロール 2-3-6. コミュニケーション 2-3-7. データマネジメント 2-3-8. 外部の知見 2-3-9. ID (アイデンティティ) 管理 2-3-10. インシデント管理 2-3-11. Infrastructure as Code (IaC, インフラのコード化) 2-3-12. 計測 2-3-13. ネットワーキング 2-3-14. 人的オペレーション 2-3-15. リソース管理 2-3-16. スポンサーシップ 2-3-17. チームワーク 2-3-18. スキル向上 付録: クラウド成熟度アセスメント 第一部: エグゼクティブ・サマリー 1-1. 四つのテーマ、三つのフェイズ The Google Cloud Adoption Framework には4つのテーマと、3つのフェイズがあります。 4つのテーマは以下です。 The Google Cloud Adoption Framework より引用した図を翻訳したもの Learn (学習) Lead (リード) Scale (スケール) Secure (セキュア) Learn (学習) は、技術部門のメンバーをスキルアップさせたり、あるいは技術のあるパートナー企業との連携を行うことを扱うテーマです。 Lead (リード) は、クラウド移行にあたり経営層やリーダー層の支援を得られているか、それにより部署間連携が取れているか、モチベーションは十分か、どのようなチーム編成となっているか、といった内容を扱うテーマです。 Scale (スケール ※) は、適切なクラウドサービスの利用や自動化を駆使することで、インフラに関わる運用負荷を減らしたり、アプリケーションのアップデートの負荷を減らしたりするためのテーマです。 ※スケール = コンピューティングリソースやストレージを、使用状況に応じて拡張したり縮小したりすることをスケーリングと言い、動詞的に「スケールする」のように用いる Secure (セキュア) は、セキュリティに関するテーマです。多層セキュリティ、IDベースのセキュリティを基本とします。 これら4つのテーマごとに、それぞれ3つのフェイズ (進捗度) があります。 The Google Cloud Adoption Framework より引用した図を翻訳したもの Tactical (「戦術」段階) Strategic (「戦略」段階) Transformational (「柔軟」段階) Tactical (「戦術」段階) は、個別の取り組みが存在しているものの、組織として一貫した状態にはない、という状態です。この状態での関心は、個々のシステムのコスト削減や、波風の少ない移行などに留まっており、将来の拡張などにはまだ関心がありません。ここが短期的なゴールになります。 Strategic (「戦略」段階) は、将来に渡る観点が存在し、個々の取り組みが管理されている状態です。また必要な関係者の巻き込みはできており IT チームは成果を出し始めています。ここが中期的なゴールとして捉えられます。 Transformational (「柔軟」段階) は、クラウド運用がスムーズに実現しており、関心はクラウド上にあるデータやそこから得られる洞察にある、という状態です。 IT 部門、もしくは相当するチームがイノベーションのエンジンになっており、これが長期的なゴールといえます。 1-2. クラウド成熟度 前述の4テーマ、3フェイズのうち、組織が現段階でどこにいるかを確かめる際は、 クラウド成熟度 をチェックします。 以下の図のように、組織は各テーマごとに、上から下へ成熟していきます。 The Cloud Maturity Scale - The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-3. エピック クラウド成熟度スケールを使って自組織の現在地が分かったら、次は前へ進むための方法を考えます。 クラウド導入のためのそれぞれの取組みのことを、ここでは エピック (※叙事詩のこと) と呼びます。 各エピックはお互いに重複しないよう定義されています。また、各個人のストーリーにブレイクダウンできます。 下の図は、エピックを People (人) 、 Technology (技術) 、 Process (プロセス) に分類したものです。 色がついた部分は、各テーマに対応しています。Learn (学習) = 緑、 Lead (リード) = 黄、 Scale (スケール) = 青、 Secure (セキュア) = 赤です。 全てのエピックを実施できない場合は 色付きの部分にまず取り組む ことが、成功への近道です。 Fine-tuning your direction with epics - The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-4. The Google Cloud Adoption Framework とは 先に紹介した「クラウド成熟度測定」で自組織の現在位置を確認したあと、エピックを使ってゴールへの施策を決めます。 なお The Google Cloud Adoption Framework は Google Cloud (旧称 GCP) だけでなく どのクラウドに対しても適用できる 方法論です。 Google Cloud の Technical Account Manager (TAM) の支援を仰ぐことで、超上流のアセスメントを行うことができます。 これによりクラウド成熟度を測定したり、それに伴うトレーニングの優先度決定や、チェンジ・マネジメント (※) の仕組みの策定、パートナーとの関わり方、クラウド運用体制、アカウント管理手法などを検討できます。 ※ チェンジ・マネジメント = 経営学用語。経営戦略や組織の変革がスムーズに行われるようにマネジメントすること、またその手法 TAM は、クラウド化の最初のプロジェクトから、その組織がクラウドファーストな組織になるまで、伴走することができます。 The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-5. はじめかた 1-5-1. クラウド成熟度の測定 ステイクホルダー (関係者) に4つのテーマ、すなわち Learn (学習) 、 Lead (リード) 、 Scale (スケール) 、 Secure (セキュア) を説明し、アセスしてもらいます。 後述のテクニカル・ディープダイブで、各テーマごとのサマリー表が示されるので、それを元に議論を勧めます。 1-5-2. ゴールを決める クラウド成熟度のうち、どの段階をゴールとするかを決めます。 この段階で、 IT 組織の中でも意見が合わないことが多いでしょう。 その人が組織の中のどの階層にいるかによって、クラウド化によって得られる利益 vs リスクに対する考え方が異なるからです。 まずは足がかりとして、短期戦術的な目標にフォーカスして議論することも検討しましょう。 1-5-3. クラウド導入プログラムを計画する ゴールとのギャップがあるエピックについて、施策を実施します。 いずれの施策も、最終的に以下の4つのいずれかに行き着くようにしてください。 トレーニングプログラムの策定 チェンジ・マネジメントプログラムの策定 クラウド運用モデルの設計 クラウドアカウントのセットアップ Getting Started - The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-5-4. ちょうどよいワークロードを見つける ※ワークロード = 元は仕事量、処理量という意味。ここではシステムが処理する業務やその性質、あるいはシステム自体を指す 初めにクラウド化するのは「 シンプルでビジネスクリティカルではないシステム 」が最適です。 こういったシステムを最初にクラウド化することで、組織のクラウド能力を鍛え、自信をつけることに繋がります。 能力が高まってくれば、将来はより複雑でクリティカルなシステムのクラウド化にも対応できます。 最初のプロジェクトはワークロード主体で考えるべきか、あるいは運用方法主体で考えるべきか、悩むこともあるでしょう。 スタートアップ企業では、迅速に商用環境へデプロイすることを優先し、運用負荷は甘んじて受けることもあるでしょう。 トップダウンでクラウド導入を進める大企業であれば、クラウドを本番導入する前にまずは運用体制をしっかり確立することもあると思われます。 これらの検討に正解は無く、組織ごとに異なるものです。 第二部: テクニカル・ディープダイブ ※ディープダイブ = 技術要素などに対して、深堀りして紹介したり考察すること。 IT 界隈でしばしば使われる言葉 2-1. クラウド成熟度の各段階について 2-1-1. Tactical (戦術) 段階 Tactical (戦術) 段階は、既存 IT の コスト最適化 という短期的な目標ともいえます。 クラウド化によってあまり使われていないコンピュートリソース (※主に CPU ) やストレージを最適化したり、運用負荷を下げたり、調達やセットアップの工数を下げたりすることが該当します。 この段階では、 IT チーム (人的) 、アプリケーションやツール (技術的) 、運用体制 (プロセス的) に大きな変更は起こさないことが多いでしょう。 とはいえ、これもクラウド導入において重要なフェイズです。 Tactical (戦術) 段階では、期待する成果は TCO (※) 分析への影響度合いで判断します。 分析の結果として得られる利益が少ない場合、すぐに Strategic (戦略) 段階へ行きたいと考えるかも知れませんが、商用環境でクラウドを使った経験がない場合は十分に気をつけてください。この段階で得られる経験がチームに成功体験として残れば、その経験自体がのちのフェイズのための重要な基礎となるでしょう。 ※ TCO = Total Cost of Ownership, 総所有コスト。資産を調達してから廃棄するまでに発生する、金銭的・人的等のコストの総額 2-1-2. Strategic (戦略) 段階 Strategic (戦略) 段階は IT組織がもたらす価値の増大 という中期的な目標です。 この段階を達成するには、 IT チームの開発・運用に関する効果や効率が飛躍的に向上しなければなりません。 それには、アーキテクチャのモダナイゼーション (近代化) によりクラウドネイティブ (※) なサービスを活用することも含まれます。 ※クラウドネイティブ = 「クラウドありき」だったり、クラウドのメリットを存分に活用している状態を指す。サービスやシステムに対して使うこともあれば、組織や個人に対して使う言葉でもある この段階では、 IT チーム (人的) 、アプリケーションやツール (技術的) 、運用体制 (プロセス的) な変化が、一定の範囲で必要です。 変化は IT 組織の一部に留まるかもしれませんが、組織の将来像 (青写真) を示したり、成功体験として残るという意味で、最終段階である Transformational (柔軟) 段階への布石として重要です。 2-1-3. Transformational (柔軟) 段階 Transformational (柔軟) 段階は、 ITがイノベーションのエンジンである状態 を目指すという長期的な目標に当たります。 この段階では IT がビジネス変革を推し進める原動力となっており、もはやコストセンターではなくビジネスに不可欠な存在です。 以下のような要素がキーとなります。 既存データから洞察を得ること 新しいデータを収集・分析すること (感情、画像、音声など) 機械学習で Predictive Analytics (予測的分析 ※) や Prescriptive Analytics (処方的分析 ※) を行うこと ※ Predictive Analytics = 予測的分析。機械学習により、将来起こり得る事象や数値を予測すること ※ Prescriptive Analytics = 処方的分析。機械学習により、意思決定の自動化、もしくはサポートを行うこと また IT 組織自体もスピード感を持ってイノベーションを提供できるよう、上記のようなデータドリブンな (データ起因の) アプローチを取る必要があります。 組織として、 SLO の合意・計測を適切に行い、知見の横展開や、個人やチームが主体的に意思決定できることを促進するようにします。 またクラウドサービスやクラウド流のベストプラクティスが、組織の新しい常識になる必要があります。 組織は、失敗や障害を含めて実験的な取り組みを正しく評価し、成果とコストを適切に算定することで、この新しい常識を下支えできるでしょう。 2-2. 各テーマごとのクラウド成熟度 関連エピック: スキル向上 、 外部の知見 2-2-1. Learn (学習) Tactical (戦術段階) 自己動機づけに頼った、個人単位でのスキル向上 オンラインドキュメントや YouTube パートナーが全体的な知見をカバー パートナーがクラウド環境への admin 権限を持つ スキル向上は個人のベストエフォートに任されており、オンラインドキュメントや YouTube といった無料の教材を使っています。 この段階ではサードパーティのパートナーが完全に頼られており、クラウド資産への特権アクセスが可能です。 技術的な質問や、有事の際のエスカレーションもパートナーが一手に引き受けている状態です。 この段階に至るために、クラウド要員を雇う必要はなく、既存のメンバーで到達できるでしょう。 Strategic (戦略段階) トレーニング開催あり 資格試験への支援あり クラウド関連業務での人材募集あり パートナーが緊急時のみ発動するクラウド環境への admin 権限を持つ (Break-glass admin access ※) ※ Break-glass 〜 = 緊急時に稼働するものを意味する。火災報知器のアラームを鳴らすためにガラスを割ることから 定期的なスキル向上プログラムが IT 要員に対して提供されている状態です。 資格試験取得が推奨され、予算も確保されています。 サードパーティのパートナーは、社内の IT 要員がまだ持っていないスキルや、内製で到達するには狭く深すぎる領域の知見をカバーします。 技術的な質問や有事の際のエスカレーションについては、一次受けは内部の IT メンバーが受けます。 そこで解決できない場合の第2層として、サードパーティのパートナーがエスカレーションを受けます。 そのため、パートナーは普段は制限付きのアクセス権限しか持っておらず、有事の際に必要な権限へ昇格する仕組みとなります。 この段階ではクラウド用の新しいポジションが用意され、採用施策が始まっています。 また各 IT メンバーにはテスト用のクラウド環境 (サンドボックス) が用意され、検証作業や新しいアイデアのテストを行うことができます。 Transformational (柔軟段階) 個人同士が相互に学びあう文化あり wiki, テックトーク(※), ハッカソン IT 要員の役割や責任範囲が刷新されている パートナーは補強的な役割のみであり、特権を持たない ※テックトーク = 技術に関する意見交換会、知見共有会など この段階では、スキル向上は継続的で、相互的に行われます。 定期的なトレーニングに加えて、 IT チームや個々の従業員は、定期的にハッカソンやテックトークを開き、知見を共有します。 IT メンバーはブログ記事や講演を通じて、業界をリードする立ち振舞いをすることが推奨されます。 これは IT メンバーの成長の意味もありますが、新たな採用に繋がるという点で一石二鳥です。 クラウドファーストな IT 組織として、 IT 部門の役割と職責は、必要な再定義が完了している状態です。 サードパーティのパートナーは、補助的な役割のみを担います。 特権管理権限は持ちません。ほとんどのエスカレーションは内部で解決し、全てのインシデント対応手順が内部で完結します。 2-2-2. Lead (リード) 関連エピック: スポンサーシップ 、 チームワーク Tactical (戦術段階) ある特定プロジェクトの特定個人によりクラウド導入が行われる IT 部門内の別部署との連携は難しい 上長からの承認はあるものの、予算は限られている この段階では、スポンサーシップ (上長・幹部からの支援) は単一部門の上級管理職からのものに限られている状態です。 といっても、この上長はクラウド導入を承認し、進捗が芳しくないときのエスカレーション先であるに過ぎません。 クラウド導入は個人的なクラウドへの興味を持っている一部のメンバーによってのみ、行われます。 他の IT メンバーとの連携は、既存組織の構造次第で制限されてしまいます。なぜなら、 IT 部門員の職責の範囲は、割り当てられたプロジェクトやビジネス部門の管轄内・予算内に限られてしまっているからです。 また彼らの成果は末端で利用される IT だけに現れており、組織の中央の IT に還元されることはありません。 結果として「かろうじて生存しているクラウド」や「クラウド・シャドーIT (※)」のようになってしまいます。 ※シャドー IT : 中央の IT 部門によって承認されていない IT ツール等を事業部門やメンバーが勝手に使っていることを指す。一般的にセキュリティリスクである Strategic (戦略段階) プロジェクト横断で集まった少数のクラウド推進派グループによりクラウド導入が進む このグループ外との連携は難しい CxO レベルの幹部からの承認があり、予算もついている この段階では C レベルの幹部 (※) からのスポンサーシップを受けられるようになっています。 レポートライン上の各マネージャは、クラウド導入にあたり目標や KPI を明確に定められています。 上長からの支援により、他の IT 部門やビジネス部門との水平連携が可能になっています。 ※ Cレベル = CIO, CTO など C から始まる幹部職 いまだ従来型の SLO (Service Level Objectives, サービスレベル目標) が、検証のスピードやイノベーション、障害からの回復よりも優先されています。 この段階では、クラウド導入は少数精鋭の機能横断・プロジェクト横断のチーム (Center of Excellence, CoE) により進められています。 この CoE チームにはアプリケーションアーキテクト、ソフトウェアエンジニア、データエンジニア、ネットワークエンジニア、 ID / ディレクトリ管理者、運用担当者、セキュリティ担当者、財務担当者など、コアとなる役職が揃っている状態です。 チームのメンバーは、専務の場合も兼務の場合もありますが、役職名や評価軸は新しい役割に応じて刷新されています。 IT 組織などの関係者と技術業界知識に明るい、専任の技術マネージャーがいることが望ましいでしょう。 Transformational (柔軟段階) 自主的なプロダクト開発チームが複数ある エラーバジェット (※) と "批判なし" のポストモーテム (※) が CxO レベル幹部に認識されている 組織全体で定期的に進捗が更新される ※エラーバジェット = 事前に定める障害に対する予算であり SLO に基づき算出される。これが残っているうちは新しいリリースが可能、などのように使われる ※ポストモーテム = 語源は「検死」。インシデントとその対応が完了した後に、事象・対応・原因・根本対策などをまとめる再発防止目的のドキュメント。障害報告書と似ているが報告ではなく改善が目的である点でニュアンスが異なる ※いずれの用語もオライリー社による出版の『SRE サイトリライアビリティエンジニアリング』に詳しい。同書は Google のメンバーにより執筆され SRE という用語を広く普及させた スポンサーシップは、マーケティング、財務、オペレーション、人事などをも含む CxO レベル幹部全体から受けられるようになっており、その下位のマネージャ陣にも行き渡っている状態です。 そのおかげで、実験とイノベーションが大事であるという文化が全体に行き渡っています。 エラーバジェットの概念が CEO まで理解されており、批判を伴わないポストモーテムの文化が IT 組織に浸透しています。 チームは、透明性がありオープンな情報共有が可能な環境で働くことができており、各種決定権限を持っています。 アドホックな検証を行うために、承認を得たりリソースの準備を待つ必要はありません。 データガバナンスやコストコントロールは自動化されています。 障害すら、後進のための貴重な教訓として歓迎されます。個人による失敗は個人に帰すことはせず、組織としての欠陥と解釈され、叱責はありません。 2-2-3. Scale (スケール) 関連エピック: アーキテクチャ 、 CI/CD (※) 、 IaC (※) ※ CI/CD = Continuous Integration / Continuous Delivery 。継続的インテグレーション・継続的デリバリーと訳される。前者は自動化によりソフトウェアのビルド・テストのスピード・効率を向上させる手法。後者は自動化を駆使してサービスのリリースのスピード・効率を向上させる手法 ※ IaC = Infrastructure as Code 。IT インフラをコードないし定義ファイルで定義して再現性確保・自動化・バージョン管理を可能にする手法 Tactical (戦術段階) クラウドリソースは手動で展開される アプリは長期運用の VM に展開。 OS の保守が必要 環境変更のレビューは手作業 環境変更のリスクは高く、頻度は低く、手作業 この段階では、マネージドサービス (※) やサーバレス (※) の利用は限定的です。 自ら運用する必要がある 仮想マシン (VM ※) に頼っています。 しかしこれは、管理対象が増えるに連れ、対象ごとに意図しない設定のズレが起きるなどの原因となり、管理運用の工数が増え続けます。 サーバの数が増えれば増えるほど、管理・運用の対象は増え、監視対象も増え、パフォーマンス情報の収集対象も増えていきます。 ※マネージドサービス = クラウドサービス側でインフラが管理されるサービス。物理層や OS 層を意識せずソフトウェアレベルで利用することができる。例として Google Cloud (GCP) の Cloud SQL や Amazon Web Services (AWS) の Amazon RDS はリレーショナルデータベースのマネージドサービスである ※サーバレス = マネージドサービスのうち、サーバの概念がない (ユーザから見て隠蔽されている) サービスのこと。利用前にインスタンスの展開等が必要なく、即座に利用できる。 Google Cloud (GCP) の BigQuery や Amazon Web Services (AWS) の AWS Lambda などが該当 ※仮想マシン (VM) = Google Cloud (GCP) であれば Google Compute Engine (GCE) であり、 Amazon Web Services (AWS) でいえば Amazon EC2 である アプリケーションのコードやインフラ設定の変更は人の目によりレビューされ、手動で実施されます。 環境に対する変更は高リスクとみなされ、数週間に一度、もしくは数ヶ月に一度の頻度です。 この段階では、クラウドリソースの展開は手動で行われます。 Google Cloud (GCP) の Deployment Manager や Hashicorp 社の Terraform といったインフラ自動化ツールは用いられません (※) 。 ※ Amazon Web Services (AWS) の場合は Terraform や AWS CloudFormation が該当する Strategic (戦略段階) クラウドリソースはテンプレートから展開する アプリはイミュータブル (※) な VM やコンテナに展開。 OS への接続は不可 (不要) 環境変更のテストは自動 環境変更のリスクは中程度 環境変更は手動 ※イミュータブル = 「不変の」を意味する英単語。コード定義の仮想サーバまたはコンテナの利用により、インフラ (サーバ) が不変である代わりにいつでも捨てられることを意味している。従来はサーバを構築すると、内部に配置された設定ファイルにより設定が管理され、アプリケーションのデータを内部に持つため、サーバの中身は「可変」であった。それゆえ、サーバのバックアップを取り、障害の際は中身の復旧が必要となる。対してイミュータブルなインフラでは、サーバの中身は変わらない。データは外部のデータストアに永続化され、設定値はコードでバージョン管理されるからである。障害の際は、障害が起きたサーバ/コンテナは廃棄し、新しいサーバ/コンテナをイメージから復旧する。このイミュータブルなインフラにより管理工数は大幅に減り、水平スケールが容易になる この段階では VM はイミュータブルな設計になっています。そのためシステム変更におけるスコープを小さくすることに成功しています。 環境設定はファイルではなく、 VM イメージとして保持され (イメージを "焼いておく" と表現することもあります) バージョン管理されています。 ステートフル (※) なワークロードとスケートレス (※) なワークロードは区別されており、そのため柔軟な水平スケール (※) ができるようになっています。 ※ ステートフル = アプリケーションやサーバが状態を保持することが前提のアーキテクチャ。「データ腹に持つ」ものが該当。例えばあるアプリケーションサーバがローカルディスクにセッションファイルを保存する仕組みの場合、そのアーキテクチャはステートフルである ※ ステートレス = アプリケーションやサーバが状態を保持 "しない" ことが前提のアーキテクチャ。「データを腹に持たない」ものが該当。保存するべきデータは全てサーバ/コンテナ外部のデータベース等のストレージに保存する ※ 水平スケール = スケールアウトとスケールイン。1つのサーバのスペックを上げたり下げたりするスケールアップやスケールダウンとは対象的に、サーバやコンテナの数を増やしたり減らしたりしてパフォーマンスを調整する方法。アプリケーションがステートレスであれば、データを複製したり整合性を取る必要がないため、水平スケールが容易である 環境変更のリスクは中程度であると認識されている状態です。 本番環境へのデプロイはプログラムにより行われますが、その処理は人手によって起動されます。 必要な場合、すぐにロールバックして元の状態に戻すことができます。 アプリケーションチームは基礎的なモニタリングから卒業し、 Application Performance Monitoring (APM) を実現しています。 24 時間・ 365 日 でアプリケーションのパフォーマンスに関する洞察を、ニアリアルタイムで得ることができています。 Google Cloud (GCP) プロジェクト (あるいは AWS でいう "AWS アカウント" 等) や VPC ・ ID など関連リソースの展開は Deployment Manager (Google Cloud), Terraform (Hashicorp) などを用いてプログラムで行われます。 コスト明細タグやデータ機密レベル、保有チームなどインプットすべき変数を入力すれば、自動的に展開できるようになっている状態です。 Transformational (柔軟段階) 全クラウドリソースはボタン一つで、数分内に再構築可能 アプリはサーバレスなクラウドサービスに展開 環境変更は定常的で低リスク 環境変更はプログラマブルに行われる 本番環境 VM には緊急時のデバッグ目的以外ではアクセスできないようになります。 セルフマネージドなサービス (IaaS) は全て、マネージドサービス、サーバレス、 SaaS などに置き換わっており、運用負荷は最小化されています。 環境変更のリスクは小さいとみなされ、本番環境へのデプロイはプログラムにより自動的に行われます。 カナリアリリース (※) やブルーグリーンデプロイ (※) などのフェイズ別デプロイ戦略が実施されています。 ※カナリアリリース, ブルーグリーンデプロイ = いずれもアプリケーションのデプロイ戦略の名称で、新バージョンへの切り替えと問題があった際の旧バージョンへの切り戻しを効果的に行うための戦略。 Amazon Web Services Japan 公開の AWS Black Belt Online Seminar AWS CodeDeploy の資料に詳しい ロギングとモニタリングは包括的であり各 SLO のもとになる全ての SLI をカバーしています。 全てのクラウドリソースは Deployment Manager (Google Cloud), Terraform (Hashicorp) などを用いてプログラムで行われます。 本番環境全体が、数分以内で別ゾーンや別リージョンに再構築できるようになっています。 2-2-4. Secure (セキュア) 関連エピック: アクセス管理 , データマネジメント , ID (アイデンティティ) 管理 Tactical (戦術段階) ID は Google によってのみ発行 Owner, Editor, Viewer といった基本ロールのみ利用 (Google Cloud の場合) 境界型セキュリティに依存し、プライベートネットワーク内を暗黙的に信用してる この段階では、利用者の ID は Cloud Identity (※) によって管理されており、それが Google Analytics や Adwords, YouTube などの他の Google サービスのアカウントにもなります。 アカウントが企業によって管理されている状態です。 しかしながら、まだ Microsoft Active Directory などの企業の中央ディレクトリとは同期されていません。 ※ Cloud Identity = Google Cloud (GCP) の ID を管理するための仕組み。 Amazon Web Services (AWS) の場合は、これを IAM User と読み替えて差し支えない。 Cloud IAM では Owner, Editor, Viewer (※) といった、非常に強い権限を持った基本ロールの利用がほとんどです。 これは、最小権限の原則を守っていない状態といえます。 権限設定がデフォルトのままなので、 Google Cloud (GCP) ユーザーは好きにプロジェクトや請求先アカウントを作成できてしまう状態です。 IAM 権限は Forseti Security のようなツールを使ってモニタリングされていません。 Cloud Audit Logs (※) の管理アクティビティ監査ログやデータアクセス監査ログはシステマティックにチェックされていません。 サービスアカウント (※) の作成も制限なしで自由に作成でき、秘密鍵も自動ローテーションされません。 ※ Owner, Editor, Viewer = 管理者用、編集者用、閲覧者用の強い権限を持つロールで、プロジェクト内の全てのリソースに対して強い操作権限を持つ。 AWS であれば Administrator や ReadOnlyAccess といった AWS 定義の IAM ポリシーが該当 ※ Cloud Audit Logs = 監査ログを保存する仕組み。 当社ブログ に詳しい。 AWS であれば AWS CloudTrail が該当 ※ サービスアカウント = アプリケーションなど人間以外が Google Cloud API 等をコールするときに用いるアカウント。当文の記述は AWS であれば Amazon EC2 用の IAM Role であったりプログラム用の IAM User から発行される Credentials を自由に発行できる状態を意味している ネットワークセキュリティ (境界型セキュリティ) が過信されており、ファイアウォールが重要なセキュリティコンポーネントです。 IP アドレスやポート番号といった情報に基づいてアクセスが制限されます。 クラウドとオンプレミス間の通信は VPN トンネルなどによる暗号化はなされているものの TLS によるエンドツーエンドの暗号化にはあまり関心が払われていません。 VPC Service Controls (※) は Cloud Storage や BigQuery といったフルマネージドサービスに対して適用されていますが、データの機密性に応じてルールが設計されている状態には達していません。 ※ VPC Service Controls = Google Cloud (GCP) の API をコンテキスト情報に応じて保護するための仕組み。 当社ブログ に詳しい。 Strategic (戦略段階) ID は企業のディレクトリから同期される 最小権限の原則に基づいて定義済み IAM Role が利用される (Google Cloud の場合) ネットワークレイヤとアプリケーションレイヤのハイブリッドセキュリティモデル クラウドユーザーの ID は Active Directory や OpenLDAP といった企業のディレクトリサービスから Google Cloud Identity に同期されているため、整合性があり、運用もシンプルです。 ユーザーは同期されたパスワードで認証するか、あるいはサードパーティの SSO (Single-Sign On) サービスで認証されます。 100% のユーザーは SMS (ショートメッセージ) やワンタイムコード生成アプリを使った二段階認証を使っており、フィッシング攻撃などの対策となっています。 Cloud IAM ポリシーにおいては、おおざっぱな基本ロールの利用はやめて、より細かく権限定義されている事前定義ロール (※) を利用しています。 Google Cloud (GCP) でデフォルトで付与されている プロジェクト作成者 ( Project Creator ) ロールと 請求先アカウント作成者 ( Billing Account Creator ) ロールは Google Cloud 組織レベルからは削除されており基本的なクラウドリソースのガバナンスが確保されています。 ※事前定義ロール = 基本ロール以外のプリセットの IAM ロール。例として「 BigQuery 管理者」のように用途別に権限が予め定義されているので利用者は細かく権限を設定する必要がない。 AWS では AWS IAM の「AWS 管理ポリシー」が該当 VPC の境界セキュリティはファイアウォールだけでなく Cloud Load Balancing (TLS 有効化) や Cloud Identity-Aware Proxy (IAP) 、 Cloud Armor などで強化されています。 これらはパブリックなインターネットにサービスを晒すことにおけるリスクを低減化するものです。 Transformational (柔軟段階) 全てのアプリ間アクセスに対して認証・認可が行われる IAM ポリシーが継続的にモニタリングされ修正される インターネットから VPC に至るまでの多層ネットワークセキュリティ 全てのサービス間通信は認証・認可されます。同一 VPC や同じプライベートネットワークにいるノード同士でも、信頼はしません。 VPC のファイアウォールルールも、 IP アドレスレンジによってではなく、サービスアカウントによって許可されます (※) 。 ※サービスアカウントによるファイアウォールルール = Google Cloud (GCP) のファイアウォールルールでは、 IP アドレスやポート番号による許可 / ブロックという一般的なルールを使うことができるが、 VM に付与したネットワークタグによるルールや、 VM に付与するサービスアカウントによるルールを利用することもできる どのデータストアにどのようなデータが入っているか、ということが全体的に理解されており、それゆえに認証をすり抜けたアクセスや不適切なアクセスに対応するセキュリティモデル・データガバナンスモデルを適切に設計することができます。 100% のクラウド利用者がハードウェアセキュリティキーを二段階認証に使っているため、フィッシング攻撃への対策は十分です。 SMS (ショートメッセージ) やワンタイムコード生成アプリが十分に安全ではないと認識されています。 Cloud Audit Logs の管理アクティビティ監査ログやデータアクセス監査ログは定期的に監査され、事前に定義した脅威パターンに一致した場合はアラートが自動発報されるように設定されています。 Cloud IAM の権限やファイアウォールのルールは継続的にモニターされ、 Forseti Security のようなツールで修正されます。 2-3. エピック クラウド成熟度が測定できたら、次は具体的なアクションです。ここでエピックを使います。 エピックは「人 (People) 」「プロセス (Process) 」「技術 (Technology) 」に分類されています。 Fine-tuning your direction with epics - The Google Cloud Adoption Framework より引用した図を翻訳したもの ※原文では以降、各エピックはアルファベット順で記載されている。当記事では日本語に翻訳しているが、そのままの順番で記載する。 2-3-1. アクセス管理 目的: 適切な人/サービスだけが認証・認可され適切なリソースに対する適切な操作を行えるようにすること 適切なアクセス管理ができていれば、不便さを感じさせることなく、最小権限の原則で、人/サービスが業務に必要なリソースへアクセスできます。 Google Cloud (GCP) では Cloud Identity と Resource Manager の組み合わせでこれを実現できます。 2-3-2. アーキテクチャ 目的: ベストプラクティスを適切に推奨したり、将来を視野に入れたクラウドコンピューティングやストレージの選択に役立つ視野を提供すること アプリケーションがクラウドプラットフォームをフル活用できるためにはコンピュートやストレージの適切な選択が必要であり、これに寄与するのがクラウドアーキテクチャです。 例として「柔軟なスケーラビリティを得るためには、アプリケーションはステートレスなマイクロサービス構成とし、永続ストレージとは分離する」「再現性とセキュリティを確保するために、手作業でのパッチ当てやメンテナンスを排除する。そのためインフラはコード定義とし、イミュータブルなものにする」といったものです。 アプリケーションやデータウェアハウス、パイプラインなどのスケーラビリティ・可用性・費用負担を段階的に変えていくこと、また開発スピードを向上させていくことは、どのようなビジネスでも必須だと考えられます。 2-3-3. 振る舞い 目的: よりチームとして働きやすくしたり、受け手の気持ちを考えるコミュニケーションを取れるようにしたり、スキル向上プログラムからより多くを得たりするための「振る舞い」を助長する、システマティックな方法を開発すること 人の振る舞いの 90% 以上は無意識のモチベーション、価値観、信念、習慣から起こるのだといいます。 成功するクラウド導入には、意識的な行動だけでなく、マインドセットや価値観にも着目する必要があります。 Learn (学習) や Lead (リード) がうまくいくかどうかは、人々が次のような新しい振る舞いを受け入れられるかどうかにかかっています。 例: コラボレーション、批判しない文化、心理的安全性、プロトタイピング、データドリブンな意思決定 組織の「現在の振る舞い」と「目指すべき振る舞い」の両方を理解して、「目指すべき振る舞い」に行き着くための行程を設計することが最終ゴールです。 2-3-4. CI/CD (Continuous integration and delivery) 目的: CI/CD パイプラインによりシステムへの変更を自動化し、最小の中断時間で全ての変更がテストされ、監査され、デプロイされるようにすること 巨大な分散システムでは不明点や依存関係、部分によって責任部署が違うなど、コードへの変更が意図通りに動かない可能性に繋がる不確定要素が多くなりがちです。 ビジネスにとって、不確定要素はリスクやソフトウェアデリバリーの遅延に繋がります。 CI/CD (Continuous integration and delivery) によって継続的にリリースプロセスを検証することで、どんなコード変更でも意図通りに動くという自信に繋がります。 2-3-5. コストコントロール 目的: コストをニアリアルタイムで可視化することで、開発者やアーキテクトにコスト意識を持たせること クラウドでは前払いが必要な調達がなく、資産化による減価償却に基づく複数年のキャパシティ計画もありません。そのため、コストコントロールは一人のソフトウェアエンジニアから始まることもあります。 オンプレでは物理的な制約がありましたが、クラウドでは代わりにリソースクォータ (ソフトウェア的な上限) やオートスケーリングの設定があるのみです。 適切なダッシュボード・アラート設定・プロセスの確立がなければ、複数プロジェクト・複数チーム・複数事業部門によるクラウド支出を管理することは、難易度が高く時間もかかるものとなってしまいます。 物理的制約がないため、アプリケーションの所有部門は、次の3つの戦略のうちどれかを選び、実行する必要があります。 無制限のスケーリング (例: E コマースサイト) 徐々に削減する (例: 社内のデータ分析) 上限を設ける (例: 開発用サンドボックス) 2-3-6. コミュニケーション 目的: 「失敗をオープンに共有することを推奨」「ミスは改善の機会として歓迎される」といった風潮の土台となるように、批判をしない文化やオープンコミュニケーションの文化を理解して、醸成すること こんにちではソフトウェアのデリバリーは速度も速く、複雑です。そのような中で組織は、失敗や障害は不可避であり、ミスは改善の良い機会である、ということを理解する必要があります。 心理的安全性を作り出し、批判のない職場を醸成し、リスク取ることが奨励され、ミスの責任は個人ではなく仕組みやプロセスにあるとする文化であることは、もはや必須です。 またポストモーテム (前述) は、批判しない文化・学び続ける文化・仕組みの改善の文化を醸成する大事なツールとなります。 2-3-7. データマネジメント 目的: どんなデータが保管されており、出自はどこで、どれくらい機密性があり、誰がアクセス可能なのか、といったことを理解して管理することで、データの安全を守り、検索可能で、利用可能にすること データマネジメントが弱いと、データ漏洩やそれによる信頼失墜、規制当局による制裁などの結果に繋がります。 暗号化、分類、漏洩対策、コンプライアンス規格の順守などはもちろんのこと、データマネジメントでは他にも多くの事項を検討する必要があります。 2-3-8. 外部の知見 目的: エキスパートの支援により、ベストプラクティスを適用し、他組織のクラウド導入期の教訓を学ぶことで、クラウド導入を加速すること 知識はトレーニングなどから得ることができます。しかし経験はそうもいきません。 そういった経験があれば、問題を早急に解決したり、予測不可能なリスクに対処したり、特定のビジネスニーズにフィットするソリューションを効率的に開発することができます。 クラウド導入の初期段階では、組織の外部に支援を求めることが有効な策となり得ます。 Google のパートナー、プロフェッショナルサービス (※) 、 Office of the CTO (※) 、ソリューションアーキテクト (※) などが支援可能です。 ※プロフェッショナルサービス、 Office of the CTO = いずれも Google Cloud のコンサルタントサービス ※ソリューションアーキテクト = クラウドでのアーキテクチャ設計に精通したエンジニア 2-3-9. ID (アイデンティティ) 管理 目的: 人もしくはサービスへの信頼ある認証を提供すること、および認証情報の漏洩やなりすましに対策すること 人やデバイスのアイデンティティ管理に信頼がおけることは、現代的なセキュリティモデルでは必須です。 現代的なセキュリティモデルにおいては、単一要素だけを信頼することはありません。 パスワード、証明書、 IP アドレスといった要素は単一では信頼の対象にはなり得ません。 代わりに複数要素を組み合わせることで、どんなネットワークからのアクセスも可能にします。 2-3-10. インシデント管理 目的: 内製および Google のサポートのもとで、予定外のサービス低下を、秩序正しく迅速に、アラート発報・トリアージ・整理すること システム運用では効率的で効果的なサポート提供や、迅速なサービス復旧が求められます。 クラウド導入においては、スキルのギャップや運用プロセスのギャップが発生し得ます。 ソリューションの最適化や稼働率向上、ビジネス価値を確保するためには、これらのギャップは正す必要があります。 適切なサポート体制を構築することで、サービス中断のリスクを下げたり、中断が起こったときでも影響範囲を最小化したりすることができます。 ツールやサービス構築に使っているプラットフォームを最大限利用することが重要です。 2-3-11. Infrastructure as Code (IaC, インフラのコード化) 目的: 設定値や構築をコード化することで自動化し、人的ミスを撲滅し、時間を節約し、全ステップをドキュメント化すること インフラをプログラム化することにより設定値とリソースの展開を自動化すれば、水平スケール・自動スケールが可能になります。 またサーバへの admin/root 権限アクセスを禁止したり、開発環境を数分で展開したり、本番環境すら安定バージョンと新バージョンの間をダウンタイムなしで切り替えることも可能になります。 2-3-12. 計測 目的: リソースの稼働状況やログイベントを計測し、アプリケーションをトレース・プロファイリング・デバッグすることで、様々な状況下でのシステムの挙動を監視し、 SLO を定量化すること 包括的な計測を行うことは、クラウドでは一層重要になります。 計測されたメトリクス (指標) によって、クラウドリソースをいつ、どのようにスケールするかが決まりますし、障害時やパフォーマンス低下時には、原因がクラウドサービス側なのかアプリケーション側なのかを判断する重要な要素になります。 また、クラウドにおける全ての操作は API コールなので、誰が、どのリソースに対して、どのような操作を行ったかという監査ログを包括的かつ変更不可能な形で残すことで、クラウド運用を本質的にセキュアにすることができます。 2-3-13. ネットワーキング 目的: 認証・認可の有無とは別軸で、サービスやデータの流れを論理的境界により接続・保護すること ネットワークはどのようなビジネスにとっても重要なインフラです。ネットワークは顧客とサービスを繋ぎ、エンドユーザーとビジネスを繋ぎ、従業員の仕事を可能にします。 こんにちのビジネスは、接続性なしには成り立ちません。そして接続性は、組織 (会社) の境界内だけにとどまらず、顧客、パートナー企業、インターネットにも広げる必要があります。 これはどのような規模・形式のビジネスでも同様であり、オンプレミス・クラウド・ハイブリッドの別を問いません。 2-3-14. 人的オペレーション 目的: 必要な組織構成を定義し、クラウド導入担当者たちを適切な役職・スキル・勤務評定手法に当てはめ、クラウド導入の円滑を図ること 組織構成・人員配置・勤務評定手法を調整することで、チームが変更を受け入れて新しい役割をこなすことを促進できます。 逆に、 IT 部門や運用部門、関連ビジネス部門がどのように動くべきかを理解せず、期待されていることが分からない状態だと混乱が発生し、せっかくのクラウド移行のための投資への悪影響となってしまいます。 また、クラウド導入担当者たちが新しい役割や新しい振る舞い (コラボレーション、透明性、失敗の許容、信頼) を受け入れることへの動機付けも重要です。 そのための勤務評定手法やインセンティブ構成が必要となってきます。 最後に、測定可能でありかつクラウド導入行程と連携した「組織としてのゴール」を定義することが非常に重要です。 ゴールや方向付けがブレると、クラウド導入の成功は遠のきます。 2-3-15. リソース管理 目的: クラウド環境の整頓・一貫性確保・制御のため、クラウドリソースのクォータ (割当て上限) を整理・明示・設定すること クラウドでは誰でも仮想的にリソースを生成することができますが、代わりに見通しが悪くなったり、勝手な行動をされるおそれも出てきます。 有用で分かりやすいルールを作り、組織の階層構造と合わせてフォルダー・プロジェクトの階層構造 (※) を構築すれば、ガバナンスを維持し、無秩序状態を回避することができます。 ※フォルダー・プロジェクトの階層構造 = Google Cloud (GCP) ではクラウド環境の1テナントを "プロジェクト" と呼び、複数プロジェクトをグルーピングして整理する単位を "フォルダー" と呼ぶ。フォルダーやプロジェクトは階層構造にして管理ポリシーや IAM 権限を適用できる 2-3-16. スポンサーシップ 目的: 幹部層からの熱心かつ継続的な支援により、クラウド導入担当者が変革を委任されていることを広く認識させること スポンサーシップとは、幹部やリーダーがクラウド導入チームやプロジェクトに対して、能動的で目に見える形の支援を行うことをいいます。 組織でのクラウド導入は複雑です。ビジネス価値の増大やコラボレーション推進、速度向上のために、組織規模でクラウド利用を決断するにあたって、 強力なスポンサーシップは必要不可欠です。 幹部層は組織で最も影響力がある立ち位置だけに、クラウド導入戦略に対して熱心かつ継続的な支援を行うことで、クラウド導入担当者たちが変革を委任されているのだということを広く認識させる必要があります。 2-3-17. チームワーク 目的: クラウド技術が最高効率で活用されるよう、コラボレーションと信頼に基づく振る舞い・文化を体現するチームを構築すること チームワークは、個々人の担当者によるボトムアップの理念リーダーシップ (Thought leadership) から始まります。 理念リーダーシップは Center of Excellence (CoE ※) や専任エバンジェリスト、非公式のクラウド派など様々な形を取り、また多くの知見共有の取り組みとなっている場合があります。 ※ Center of Excellence (CoE) = 組織の中で特定技術や分野において、研究・開発・導入などのリーダーシップを取るチームのこと。特にクラウドにおいては Cloud Center of Excellence (CCoE) と呼ばれ近年話題になっている こういった主導者たちが、セキュリティやアーキテクチャ、ネットワーク、運用、データベース管理などの規律を形作っていきます。 彼らに共通しているのは、前向きであることと、クラウド導入のベストプラクティスに自発的に関心を持っていることです。 こういった主導者がいない場合、クラウド導入は幹部層のスポンサーシップに依存してしまいます (スポンサーシップの項を参照)。しかしこのような一方的かつトップダウンの方策はスケールが遅く、またクラウドの利点である IT リソースの本質的な民主化という利点を活用できない結果にお話ある可能性があります。 2-3-18. スキル向上 目的: 現職メンバーが持つ業務知識や既存 IT 資産に関する知見と、新規に学んだベストプラクティスを融合するため、学習に対して投資をすること クラウドコンピューティングは、仮想化の出現以来、類を見ないパラダイムシフトとなっています。 これらの新しい考え方やベストプラクティスは、チームの個々人のスタイルにあうように、様々な方法で学習することができます。先生が教えるタイプの研修や、 coursera.com や qwiklabs.com のようにインタラクティブな自己学習タイプのものでもよいでしょう。 スキル向上とは、技術的な理論を学ぶことだけを指すのではありません。学んだことを業務に活かしたり、自分で問題解決ができるようにしたり、 Google サポートを利用したり、同僚と教訓を共有したりすることで、継続的に学ぶ文化を醸成し、それにより組織全体の知見を育てることこそが重要です。 付録: クラウド成熟度アセスメント ホワイトペーパーの抄訳は、以上で終了です。 ここからは Google により無償公開されている、クラウド成熟度アセスメントツールをご紹介します。 以下のサイトで公開されている Web ツールを用いると、ホワイトペーパー内でも紹介されていたクラウド成熟度を測定することができます。 digitalmaturitybenchmark.withgoogle.com 画面に表示される質問に順に答えていくと、組織の現在のクラウド成熟度を4つのテーマに沿って測定することができます。 質問の内用を吟味すると、今の組織に足りないものが何か、見えてくるはずです。 質問は英語ですので、苦手な方は Chrome ブラウザの翻訳機能などを駆使してご活用ください。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud 認定資格の1つである Professional Data Engineer 認定資格は、Google Cloud でのデータエンジニアリングやデータ分析に関する難関資格です。当記事では、試験の学習に役立つ情報を記載します。 はじめに 当記事の内容 想定読者 試験の難易度 推奨の勉強法 更新試験 出題傾向 セキュリティとガバナンス 組織、IAM 個人情報の扱い VPC Service Controls BigQuery 基本的な知識 関連記事 外部テーブルと BigLake テーブル データの共有 Cloud Storage 基本的な知識 複数リージョンとターボレプリケーション Bigtable 基本的な知識 テーブル設計 運用 適切なデータベースの選択 Dataplex Dataplex による権限管理 Dataplex Universal Catalog Dataflow 概要 ウインドウ exactly-once 融合（fusion） ネットワークとファイアウォール データパイプライン Dataform Pub/Sub Cloud Composer Dataproc Dataprep、Cloud Data Fusion データ移行 オンプレミスからのデータ移行 データベース間のデータ移行 機械学習（AI/ML） オペレーションスイート 基本 注目すべきメトリクス その他 受験環境 はじめに 当記事の内容 当記事では、Google Cloud（旧称 GCP）認定資格の1つである Professional Data Engineer 認定資格の学習に役立つ情報を紹介します。Professional Data Engineer 認定資格は、Google Cloud でのデータエンジニアリングやデータ分析に関する難関資格です。 参考 : Professional Data Engineer 認定資格 試験の利用規約において、試験の内容を公開することは禁じられています。そのため当記事では試験問題そのものを書くこと等はせず、主にサービスカットで、 合格するためには何を知っているべきか という観点で情報をご提供します。 なお、当記事で試験範囲を全てカバーできているわけではありません。公式の試験ガイドや模擬試験なども駆使して、学習を進めてください。 想定読者 当記事は以下のような方向けです。 Professional Data Engineer 試験の出題傾向を知りたい Google Cloud サービスやデータエンジニアリングの基本的な知識は把握済みである 近日中に試験を受けようと思っているので、知識の確認をしたい また前提知識として Google Cloud の基礎知識が必要です。 Associate Cloud Engineer 試験 相当の知見は持っておくことが推奨されます。以下の記事も参考にしてください。 blog.g-gen.co.jp 試験の難易度 Professional Data Engineer 試験の難易度は、 比較的高い と言えます。 IPA の「応用情報技術者試験」程度の基本的な IT の知識があり、かつ Google Cloud をある程度業務で使用した経験があることが望ましいです。これに加えて、データモデリングや ETL / ELT 、分散アーキテクチャのデータ処理基盤や RDBMS、NoSQL データベースなどのデータ関連技術要素に関する基礎知識が必要です。 これらの情報技術に関する基礎知識のうえに、Google Cloud のデータベースやデータ処理に関するサービスや、サービスの組み合わせなどについて、書籍や公式ドキュメントで理解しておくこと必要があります。 また、普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、Google の考える「クラウドらしいクラウドの使い方」という一種の哲学を、頭にインプットしておくことが重要です。 これらに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。 推奨の勉強法 Associate Cloud Engineer を先に取得する 書籍や各社のブログ等で Google Cloud のデータ関係サービスの概要を理解する。特に以下のサービスに着目する BigQuery、Dataplex、Dataplex Universal Catalog、Cloud Storage、Dataflow、Pub/Sub、Cloud Composer、Bigtable、Dataproc、BigQuery ML 試験ガイドを読み、出題範囲を理解する 当記事を読み、出題傾向を理解する 把握した試験範囲・出題傾向をもとに勉強する 模擬試験を受け、足りない知識を認識して、ギャップを埋める勉強をする 試験ガイドや模擬試験へのリンクは、以下の公式ページから確認できます。 参考 : Professional Data Engineer 認定資格 更新試験 Professional Data Engineer には、有効期限が切れる前に資格を更新するための 更新試験 があります。更新試験は、資格の有効期限の 60 日前から受験可能です。更新試験では、問題数、試験時間、受験費用が、通常試験に比べて小さく設定されています。 項目 初回試験 更新試験 問題数 40～50問 20問 試験時間 120分 60分 受験費用 $200（税別） $100（税別） 更新試験は英語と日本語で受験することが可能です。 出題傾向 当記事ではこれ以降、出題傾向や必要な知識を解説します。分からない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。 そのように勉強すれば、試験に合格できるのに加え、実践的な知識となるでしょう。 セキュリティとガバナンス 組織、IAM Identity and Access Management （IAM）の 継承 の概念や、リソースとの紐づけ、またリソース階層（組織、フォルダ、プロジェクト、各リソース...）の概念については確実に理解してください。以下の記事を参照してください。 blog.g-gen.co.jp また IAM と BigQuery の組み合わせの応用として、 承認されたビュー の使用方法も問われます。この機能については、以下の記事を参照してください。 blog.g-gen.co.jp 個人情報の扱い 個人識別情報 （PII）の扱いについては、頻出です。 PII を保存して必要なときには参照できるようにしておきたいが、適切な権限を持っている人以外は閲覧できないようにしたい、という場合、 Sensitive Data Protection （旧称 Cloud Data Loss Prevention、 Cloud DLP ）が活躍します。 元データに対して「削除」や「マスキング」を行って上書きすると当然、元のデータが失われてしまいます。一方で 暗号ベースのトークン化変換 という手法のうち フォーマット保持暗号化 や 確定的暗号化 を使うと、暗号鍵への権限さえあれば再度、元の値を復元できます。反対に 暗号ハッシュ化 をしてしまうと元の値に戻せない（不可逆）である点に注意してください。 参考 : 暗号ベースのトークン化変換 VPC Service Controls VPC Service Controls は、Google Cloud の API とデータを保護するための仕組みです。以下の記事を読んで、概要を把握してください。 blog.g-gen.co.jp VPC Service Controls の境界（perimeter）には、プロジェクトまたは VPC ネットワークを追加することができます。VPC ネットワークだけを追加しても、プロジェクトの API は保護されない点に注意してください。 BigQuery 基本的な知識 Google Cloud の誇るフルマネージドなデータウェアハウスである BigQuery は、当試験で最も出題されるプロダクトです。まずは以下の記事で、BigQuery の機能や用語を一通り理解してください。 blog.g-gen.co.jp blog.g-gen.co.jp BigQuery 以下のような概念を理解していれば、多くの問題に答えることができます。用語やドキュメントの暗記ではなく、概念として腹落ちするまで理解するようにしてください。 BigQuery の特質 列志向ストレージ 分散アーキテクチャ スロットと予約（Reservation） パーティショニングとクラスタリング 権限管理 IAM 承認済みビュー、承認済みデータセット BigQuery Sharing（旧称 Analytics Hub） 列レベルのアクセス制御、行レベルのセキュリティ バックアップとタイムトラベル ロケーション選択にてマルチリージョンを選択する意味 ストリーミングインサート（メリットとデメリット） 関連記事 上記の学習にあたっては、以下の記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 外部テーブルと BigLake テーブル BigQuery では、 外部テーブル を定義することで、Cloud Storage 上の CSV や Parquet といった形式のファイルに対して、リアルタイムにクエリを実行することができます。また、外部テーブルの発展版である BigLake テーブル への理解も必要です。 参考 : BigQueryを徹底解説！(応用編) - BigLake BigLake テーブルには メタデータキャッシュ 機能があり、パフォーマンス向上につながります。 参考 : 外部テーブルのメタデータのキャッシュ保存 データの共有 BigQuery Sharing（旧称 Analytics Hub）を使うと、少ない労力で他の組織に BigQuery データセットを安全に共有できます。アクセス制御を適切に行なったうえで共有でき、データのコピーは必要ありません。 参考 : BigQuery Sharing の概要 BigQuery Sharing（Analytics Hub）は、 限定公開リスティング を使うことで同じ組織内での共有に利用することもできます。 Cloud Storage 基本的な知識 Cloud Storage に関する問題も頻出です。以下の記事で、一通りの機能を把握してください。 blog.g-gen.co.jp 複数リージョンとターボレプリケーション Cloud Storage バケットの作成時に、バケットを配置するリージョンを単一リージョン、デュアルリージョン、マルチリージョンの3種類の中から選択可能です。これにより、データの可用性や堅牢性が向上します。ただし、リージョン間のデータレプリケーションは非同期で行われ、60分以上の遅延が発生する場合もあります。 データの RTO を短縮するには、 ターボレプリケーション の有効化が効果的です。有効化すると、追加料金と引き換えに15分以内でデータの複製が完了します。 参考 : データの可用性と耐久性 - ターボ レプリケーション Bigtable 基本的な知識 Bigtable は、Google Cloud のフルマネージドの NoSQL データベースです。どのようなアクセスユースケースで Bigtable を利用するのが望ましいのか、ユースケースを押さえておいてください。 以下の記事も参考にして下さい。 blog.g-gen.co.jp テーブル設計 スキーマ設計についてはドキュメントをよく読み込んでおき、特に大事な行キーの設計はよく理解しておきます。テーブル、列ファミリー、列、行、セル、行キーといった概念を理解してください。 基本的に、行キーにタイムスタンプを使うのはバッドプラクティスです。タイムスタンプは連続した値になってしまうので、データ格納先のストレージ位置が集中してしまい、 ホットスポット の原因となります。 machine_4223421#1425330757685 のように先頭にカーディナリティの高い ID などと組み合わせてキーとする手法が使われます。 参考 : スキーマ設計のベスト プラクティス 参考 : 時系列データ用のスキーマ設計 運用 モニタリング、本番用ワークロードと分析用ワークロードの分離（ アプリプロファイル ）、クラスタ拡張、 Key Visualizer など、管理運用面も把握しておきましょう。 参考 : アプリ プロファイルの概要 適切なデータベースの選択 Cloud SQL、Firestore（旧 Datastore）、Spanner、Bigtable、BigQuery など、Google Cloud には多用なデータベースサービスが存在しています。それぞれのユースケースや、できること、できないことを把握しておきましょう。どういったユースケースでどのデータベースを選ぶのかを回答できるようにする必要があります。 以下の表を参考にしてください。 名称 Cloud SQL Firestore Spanner Bigtable BigQuery 概要 マネージドRDB。MySQL / PostgreSQL / SQL Server が利用可能 NoSQL データベース。モバイルアプリからもよく利用される 無制限のスケーリング、グローバル利用が可能なリレーショナルデータベース NoSQL データベース。高スループット、高スケーラビリティ データウェアハウス。分析目的の列指向 DB ユースケース 一般的なアプリ。RDB Web、モバイル、ゲーム等で KVS がマッチする場合 金融、ヘルスケア、ゲーム等でグローバルなトランザクション 時系列データ、購入履歴、IoT 等。高スループット、高スケーラビリティが求められる SQL での分析や ELT 種類 RDB NoSQL（ドキュメント DB） RDB かつ分散アーキ NoSQL（ワイドカラム） データウェアハウス（表形式・列指向） クエリ方法 SQL API もしくは SQL ライク言語 SQL API SQL トランザクション ○ △ (※) ○ ✕ (1行のみ可) ✕ (※) Firestore と Datastore で仕様が違う Dataplex Dataplex による権限管理 Dataplex は、分散されたデータの統合・管理を自動化するためのサービスです。データの権限管理を簡素化し、 データメッシュ の構築を後押しします。プロダクトの詳細は、以下の記事で把握してください。 blog.g-gen.co.jp Dataplex では、BigQuery や Cloud Storage のデータへのアクセス権限の管理を行うことができます。具体的なアーキテクチャ等については、以下の記事も参考にしてください。 blog.g-gen.co.jp Dataplex Universal Catalog Dataplex Universal Catalog は、メタデータ管理のためのフルマネージドサービスです。BigQuery や Cloud Storage のデータのためのメタデータを管理し、データカタログを構築できます。かつて存在していた Data Catalog というプロダクトの後継プロダクトです。 以下の記事を参考にして、概要を把握してください。 blog.g-gen.co.jp Dataflow 概要 Dataflow は Apache Beam のマネージドサービスです。リアルタイム処理とバッチ処理の 両方を 扱うことができる点が特徴です。Dataflow はマネージドサービスであるため、自動的なスケールイン・スケールアウトなどにより、小さい運用負荷でデータ変換処理を実現できます。当試験においては、Dataflow は BigQuery に次いで最も出題数が多いプロダクトといえます。 以下の記事を読んで、Dataflow の概要を理解してください。 blog.g-gen.co.jp また以下のドキュメントを確認し、Apache Beam のプログラミングモデルについて概要を把握してください。 参考 : Programming model for Apache Beam ウインドウ Dataflow がストリーミングデータを扱う際に、データを分割してグルーピングする粒度として、 ウインドウ という設定を使用できます。 タンブリングウインドウ 、 ホッピングウインドウ （= スライディングウインドウ）、 セッションウインドウ の用語は押さえておきましょう。 参考 : Streaming pipelines - Windows and windowing functions exactly-once 例えば Pub/Sub から BigQuery へのデータ連携などでは、少なくとも1回（ at-least-once ）が原則である Pub/Sub からデータを受け取って、1回限り（ exactly-once ）の処理を実現できることも特徴です。 参考 : Exactly-once in Dataflow 融合（fusion） Dataflow は複数のワーカーを使って並列処理を行いますが、オペレーションの内容によっては自動的にジョブが最適化されて 融合 （fusion）が発生し、ジョブが少ないノードで実行されることがあります。場合によってはこれが非効率であり、実行時間が延びてしまうことがあります。 reshuffle を使うことで、融合を回避するようなテクニックもあります。 参考 : Dataflow pipeline best practices - Identify performance issues caused by fused steps ネットワークとファイアウォール Dataflow の VM ノード同士が通信するには、VPC ファイアウォールルールでノード同士の通信を許可する必要があります。 許可するポートはストリーミングジョブの場合は 12345/tcp 、バッチジョブの場合は 12346/tcp Dataflow VM ノード に付与されたネットワークタグでファイアウォールルールを作成する ネットワークタグはデフォルトで dataflow が付与される。カスタムネットワークタグの付与も可能 Dataflow の学習においては、上記のような、ネットワークとファイアウォールに関する知識も把握しておいてください。詳細は以下のドキュメントに記載されています。 参考 : Configure internet access and firewall rules データパイプライン Dataform Dataform は、BigQuery 用のフルマネージドのデータパイプラインサービスです。BigQuery に実行する SQL をワークフロー管理でき、スケジュール実行や、Git リポジトリとの連携も可能です。ワークフローは SQLX と呼ばれる SQL ベースの言語で記述するため、SQL の知識があれば学習コストが小さく済みます。 以下の記事も参考にして下さい。 blog.g-gen.co.jp なお Dataform では アサーション と呼ばれるテストコードを記述することで、データ品質を検証できます。アサーションでは、null 値のチェック、一意制約のチェックなどが可能です。 参考 : データ品質のテスト Pub/Sub 多くの問題文、または選択肢において、Dataflow とセットで Pub/Sub が扱われます。Apache Kafka を Pub/Sub で置き換えるという定番パターンも出題されます。 Pub/Sub の基本概念（トピックとサブスクリプション）、 デッドレタートピック 、Push サブスクリプションの 再試行ポリシー などについて理解を深めてください。 参考 : Pub/Sub サービスの概要 参考 : デッドレター トピック 参考 : サブスクリプション プロパティ - 再試行ポリシー Cloud Composer Google Cloud のサービスを活用してジョブオーケストレーションを行うには Cloud Composer が有用な選択肢です。 ジョブ実行ツールとしては他に、 Cloud Scheduler とサーバーレスサービスを組み合わせる方法などがありますが、Cloud Composer は DAG （有向非巡回グラフ）によるジョブの前後関係の管理や、モニタリング等の面で強みがあります。以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp Dataproc Hadoop/Spark のマネージドサービスである Dataproc も頻出です。公式ドキュメントを確認し、クラスタ構成や管理運用方法について把握しておきましょう。 参考 : Dataproc の概要 Dataproc では基盤として Compute Engine VM が使われます。そのためパフォーマンス向上やコスト削減にあたっては、Compute Engine と同じ知識が使えます。例えば「ローカル SSD は永続ディスク（=ネットワークストレージ）よりもレイテンシが低い」であったり、「コスト効率を良くするために、セカンダリワーカーとして Spot VM（プリエンプティブル VM）が使用できる」などです。 また、オンプレミスの Spark / Hive 環境をクラウドに移行する際の移行先として、Dataproc が第1選択肢になります。 参考 : Apache Spark ジョブの Dataproc への移行 参考 : Dataproc での Apache Hive の使用 Dataprep、Cloud Data Fusion Dataprep と Cloud Data Fusion は、いずれもデータ抽出・変換パイプラインをノーコードで実装できるマネージドサービスです。GUI 上でワークフローを構築し、スケジュール実行できます。BigQuery などへのデータ挿入や、データ変換が可能です。ソースコードを書かずにデータパイプラインを実装したい場合のユースケースに適しています。 参考 : Google Cloud Dataprep by Trifacta クイック リファレンス 参考 : Cloud Data Fusion の概要 データ移行 オンプレミスからのデータ移行 データ移行というテーマも扱われます。オンプレミスから Google Cloud への大規模なデータ移行には、 Transfer Appliance という選択肢があります。Transfer Appliance は物理的なストレージデバイスです。Transfer Appliance にデータを転送して、Google に返送すれば、Google Cloud の Cloud Storage に速やかにデータを移行することができます。どのようなシチュエーションやどのくらいの規模のデータにこのサービスが適しているのかは頭の片隅に入れておきます。 参考 : Transfer Appliance また gcloud storage rsync （ gsutil rsync ）コマンドを使って手作業で Cloud Storage にデータ移行を行うこともありますし、Storage Transfer Service を使えば Cloud Storage へのデータ移行をジョブ化・自動化できます。 参考 : Cloud Storage とビッグデータの使用 参考 : Storage Transfer Service とは BigQuery Data Transfer Service と Storage Transfer Service の違いには注意してください。前者は外部から BigQuery へ データを転送する仕組みであり、後者は Cloud Storage へ データを転送する仕組みです。 データベース間のデータ移行 Datastream は、フルマネージドのデータ転送サービスです。データソースとして MySQL、PostgreSQL、Oracle などの RDBMS に対応しており、宛先としては BigQuery、Cloud Storage に対応しています。CDC（Change data capture）により、データの更新をリアルタイムにキャッチしてデータ転送を行うことができます。 参考 : Datastream の概要 Datastream を使い、オンプレミスのデータベースから専用線経由で BigQuery にデータを転送することもできます。データソースは Compute Engine VM でもよく、例えば VM にインストールされている Oracle Database から CDC でリアルタイムに BigQuery にデータを転送することが可能です。 機械学習（AI/ML） 当試験では、機械学習系の出題もあります。また Google Cloud 特有の知識というよりも、機械学習の一般的な用語や基礎知識について、ある程度の理解が必要です。 ラベリング、トレーニング、モデル、推論、回帰、分類（Classification）、クラスタリング、リコメンデーション、教師あり学習、教師なし学習、混同行列、過学習とのその対策、など基礎的な用語を押さえます。これらの用語の意味がわからない場合は、Web 検索や Gemini を活用して、浅くでもいいので理解しておきましょう。 また BigQuery ML も出題範囲です。使い方やある程度の仕組みは理解している必要があります。 参考 : BigQuery の AI と ML の概要 オペレーションスイート 基本 Cloud Monitoring の基本機能をしっかり理解しておきましょう。 blog.g-gen.co.jp 「Google の指標」のリファレンスページで、Compute Engine や Pub/Sub、Cloud Storage など、データエンジニアリングにおいて重要なサービス群のメトリクスは、簡単でいいので眺めておくことが望ましいです。 参考 : Google Cloud metrics overview 注目すべきメトリクス 「Pub/Sub からデータを読み取って、Cloud Storage にデータを書き込むデータパイプライン」があるとして、これを Cloud Monitoring で監視するときにどうするか、などのシチュエーションを想像してください。 Pub/Sub のメトリクスのうち subscription/num_undelivered_messages が上昇していると「処理の遅延等が起きている」とみなせるはずです。 また BigQuery には slots/allocated_for_project といったメトリクスがあります。プロジェクトごとに割り当てられたスロット数が確認できるため、複数の部署で BigQuery を使っているときにどの部署がスロットを多く消費しているのか、などが確認できます。 その他 受験環境 当社メンバーの受験環境に関する実体験が以下の記事で紹介されています。ぜひご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさんこんにちは。G-genの鈴木ことすずたつです。 私はG-genに9月にJoinして、日々優秀な技術者とともに学ばせていただいて、11月2日にProfessional Cloud Architectの試験に合格させていただきました。 ※Associate Cloud Engineerに関しては10月の頭に合格させていただいたので、その話はまた別の機会にでもブログ書いてみたいと思います。 今回は、受験記ではなくいまこのコロナの時期だからこそ有効活用したい遠隔試験に関して少し話してみようと思います。 Google Cloudの遠隔試験とは？ 遠隔試験の要件と実際の環境 最初に受験しようとしていた環境 実際の受験環境 事前の予約 当日の流れ その他 眼鏡 外付けのWebカメラ 後日、Professional Collaboration Engineerを受験しました。 Google Cloudの遠隔試験とは？ Google Cloudでは以下にありますように、様々な試験を提供しています。 Google Cloud 認定資格 そして、その試験がなんと 家から受験できてしまう のです！ 現時点(2021年11月4日時点)では、日本語対応している以下のすべての試験が 遠隔での受験が可能 です。 Google Cloud Certified - Cloud Digital Leader (Japanese) Google Cloud Certified - Associate Cloud Engineer (Japanese) Google Cloud Certified - Professional Cloud Architect (Japanese) Google Cloud Certified - Professional Cloud Developer (Japanese) Google Cloud Certified - Professional Collaboration Engineer (Japanese) Google Cloud Certified - Professional Data Engineer (Japanese) コロナが落ち着いてきたとはいえ、リモートで受験できるのはとても便利ですので、ぜひ活用しましょう。 遠隔試験の要件と実際の環境 実際に公式にアナウンスされている要件は以下の通りになります。 Exam Procedures 私の場合は、あまり家も大きくないので、、、どこで受験しようかと、実は試験開始30分前まで悩み、最後の最後で変更しました(汗) 最初に受験しようとしていた環境 最初は、机の上に何も無ければよいだろう！と考え、リビングのテーブルで受けようと考えておりました。 ※簡単な環境は以下の絵を参考にしてください。 家の間取りと受験しようとしていた場所 ただ、キッチンにはものがあったり、近くにテレビがあったりと、これはつっこまれるか？？と思い、試験30分前に子供部屋を利用することを決意。(実はこの時夜の23時30分) 実際の受験環境 結果として以下の環境で受験を決意！ 最終的に受験した場所 結果からいうとこの場所で子供のおもちゃたちに見守られながら受験して事なきを得ました。それでは次より、事前準備(予約)や当日の流れを説明してゆきます。 ちなみにPCは普通のWindowsのプライベート端末に外付けカメラをセットしたものになります。 事前の予約 基本的に、予約は通常の方法と何ら代わりありません。以下のKryterionのサイトから通常通り申込みしましょう。 準備ができたら ただ、注意なのが日時と時間です。Professional Cloud Architectは人気の試験なのか、結構受けたい日の枠が空いておらず、悩みに悩んだ末に 11月2日00:00AM での受験を決意。 みなさま、00:00AMって、真っ昼間なのか、夜中なのかすぐにわかりますか？ 鈴木は実は昨年、子供の運動会が終わったあとの、お昼にマクドナルドが来るように予約してたら、夜中に来てしまった。という体験があるため一瞬で判別可能でした。(どこでどういう経験が活きるかわかりませんね)。 そう。11月2日00:00AMというのは11月1日のお仕事が終わって、夕飯食べおわって、お風呂に入ったあとの夜中です！お間違えないよう！ 他にも、海外から監視だからなのか3:00AMとか、日本だと普通は 寝ている時間でも受験が可能 なので、予約時間は間違わないように注意しましょう。 予約が完了しましたら、以下の画面の右側にSentinelのインストール、というボタンと、生体認証用の顔写真登録。というボタンがでますので、2つとも試験前までに済ませておきましょう。 Kryterionの画面 当日の流れ 当日は10分前になった時点で、予約画面の？の印が”受験する”というボタンに変わります。ボタンをクリックするとSentinelが自動的に立ち上がります。 ただこの時、どうやらチェックする側の方が混雑してたっぽく、数分間待つことに。 画面は「この画面を切らないでくださいね。混雑してるので最大15分待ってもらうかもしれません。」のようなメッセージが画面に表示されていました。 やっとのことで接続されると。はじめは簡単な説明があった上で、パスポート等をカメラに近づけてよく見えるように映してください。という指示があり、OKだとチャットボックスが立ち上がります。 どきどきしながら英語のゴリゴリの外人の方がへろー！とか言ってくるのかと思ったら、画面左にチャット、右側にカメラ。というウィンドウが立ち上がり、チャットボックスに「ではチェックを開始します。まずは壁四面、天井、床をカメラで映してください。各部分5秒程度静止してください」のような メッセージが日本語で表示 され、それに従って映すような形になります。 ただ、ここで注意なのが、 リアルタイムですぐになにかリアクションしてくれるわけではなく 、全部確認してOKだったら次の指示。のような形なので、何もリアクションが無いままで「右の壁5秒、左の壁5秒、前、後ろ、天井、足元、、、最後に自分。。。これであってるのかな？」という状況で、数秒たつと。「では次に、机の上を映してください」、「次は携帯のカメラ、もしくは手鏡をつかって、PCのディスプレイを映してください。」、「ありがとうございます！パスポート、携帯をどこかにおいてください！」と来て、(どこにおけば・・・)、と思いつつも部屋の隅っこのおもちゃたちの中へぽいっ。と。 こういった一連の流れが終わると「これでOKです！それでは試験を開始します！この時間は試験時間に含まれませんのでご安心ください！」というメッセージが表示され、試験が開始されます。 ただ、数十秒(体感的には1分くらい？)のあいだ試験開始ボタンが表示されなかったため、「え？？どうやって試験開始するの？？？」と思ってしまいましたが、無事にボタンが出現し試験開始となりました。 あとはいつもの試験と同じで、合意の画面があって、試験があり、アンケートあり、結果。という流れで進みます。 (試験終了した時点で夜中の1時30分すぎでした・・・) 合格もそうですが、実は始めての遠隔体験だったため、30分前に場所を変えたり、バタバタしたりでなんだか日程さえ合えば行った方が良かったんじゃないかとも少し思ってしまいましたが、、、 今後のためにもいい経験ができました。 その他 眼鏡 生体認証(自分の顔写真を撮って送付)のときも、実際のときも自分の顔を送付。というのはあることはわかってたのですが、このときのインストラクションで メガネも外してください という説明があり、メガネを外すと0.01レベルの鈴木は 撮影ボタンが見えない！ という状況だったので、眼鏡くらいは許してほしいな。。。と思いました。 外付けのWebカメラ 私は幸いにもUSBの外付けのWebカメラを持っていたため、そちらを当日は利用しました。チェックリスト的には内蔵のカメラでもOKなのですが、机の下を映したり、あちこち映したりするので、内蔵だと正直厳しいのではないか。。。と思っております。 後日、Professional Collaboration Engineerを受験しました。 後日談ですが、Professional Collaboration Engineerを受験しました。(結果は別のブログで・・・) 2度目のリモート受験なので、落ち着いて、ある意味チャレンジを。と思い、以下のような環境で受験しました。 結論からいうと問題なく、試験監にいくつか指摘されましたが、 手の届くところにものがない というのが条件のようです。手の届くところにいろいろあるじゃないか！というツッコミはご容赦ください。 ※試験に必要なパスポートを「そこに置いてある赤いノートを片付けなさい！と突っ込まれたときは・・・と思いましたが。。。」 デスクまわりの写真 これから寒い時期にもなりますし、遠隔受験をうまく活用して、いいGoogle Cloudライフを送りましょう！ Professional Cloud Architect 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-gen の杉村です。 Professional Cloud Architect 試験 は、 Associate Cloud Engineer 試験の上位に位置する Google Cloud (旧称 GCP) の難関認定資格です。本投稿では試験の合格に役立つ、勉強方法や出題傾向などについて解説します。 はじめに Professional Cloud Architect 試験 とは 難易度 推奨の勉強法 ケーススタディ 出題傾向 更新試験 組織と IAM 組織のポリシー IAM の基本概念 オペレーションスイート Cloud Monitoring Cloud Logging セキュリティ・統制 Network Intelligence Center Sensitive Data Protection Google Kubernetes Engine（GKE） 基本概念 モニタリング 安全なデプロイ GKE からの Google API への認証 データベース・分析 データ分析プラットフォームの選択 Cloud SQL Cloud Storage コンピュートサービス 概要 App Engine CI/CD 概要 コンテナセキュリティ VPC / ネットワーク VPC の基本 ネットワークセキュリティ 接続性 概要 VPC 間の推移的通信 ハイブリッドネットワーク 可用性 SLA Compute Engine Compute Engine の基本 マネージドインスタンスグループ リージョン永続ディスクを利用した可用性向上 ライセンスの持ち込み その他 その他のプロダクト はじめに Professional Cloud Architect 試験 とは Professional Cloud Architect は、Associate Cloud Engineer 試験の上位に位置する Google Cloud の認定資格です。 IT インフラやアプリケーション開発に関係する Google Cloud サービスの知識のみならず、データ分析、セキュリティ、モニタリングなど幅広い知識が求められます。この試験に合格していることは、Google Cloud を幅広く理解しており、一人前の Google Cloud 技術者である証左だといっても過言ではないでしょう。 試験時間は 120 分、試験問題数は 50〜60 問です。試験は日本語と英語で提供されています。 参考 : Professional Cloud Architect ‐ Google Cloud 可能であれば、当試験より先に Associate Cloud Engineer 試験に合格しておくことが望ましいですが、受験にあたり必須要件ではありません。Associate Cloud Engineer 試験については以下の記事もご参照ください。 blog.g-gen.co.jp 難易度 当試験の難易度としては 中程度 だと言えます。 IPA の「応用情報技術者試験」程度の基本的な IT 知識があり、かつ Google Cloud をある程度業務で使用した経験があるというのが前提知識として理想的です。試験ガイドでは「3年以上の業界での経験と、1年以上の Google Cloud における経験」が推奨だと記載されていますが、必ずしもこれを満たしていなくても十分合格が狙える資格です。 むしろ普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、Google の考えるクラウドらしいクラウドの使い方が何か、という一種の クラウドの哲学 を頭にインプットしておくことが重要です。選択肢に迷った時に、 最もクラウドらしい選択肢はどれか という思考が助けになります。 これらに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。 特に Amazon Web Services（AWS）の試験を受けたことがある人であれば気が付きますが、問題文の長さや複雑さは AWS Certified Solutions Architect - Professional 認定のそれと比較すると、短くてシンプルであると感じられます。体感的案難易度は AWS の Professional 試験より低いかもしれません。 推奨の勉強法 Associate Cloud Engineer を先に取得する 試験ガイド を読んで出題範囲を理解する 当記事を読み、出題傾向を理解する 把握した試験範囲・出題傾向をもとに勉強する 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする ケーススタディ を直前に確認する ドキュメントを読むだけでは理解が進まないサービスも出てきます。こういったときは「書籍を読む」「ブログ記事を検索して読む」「コンソール画面や gcloud で実際に触ってみる」の3つを織り交ぜて学習を進めるのがおすすめです。 特に3つめの「 実際に触れる 」は重要です。コンソールやコマンドラインを触ると、Google Cloud プロダクトの リソース構成 が手にとるように分かり、理解が進みます。リソース構成を把握してからドキュメントに戻ると、理解度が全く違うことがあります。 ケーススタディ Professional 試験では ケーススタディ と呼ばれる、架空の会社をテーマにしたクラウド導入事例が引用されます。 参考 : Professional Cloud Architect Exam Guide | Japanese 試験中は画面の右半分にケーススタディの内容が表示されるため、内容を覚えておく必要はありませんが、事前に目を通しておきましょう。どんな本番環境でも要求されるような基本的な要件も多く書かれていますが、そのケースで大事にしている（優先すべき）要件に注意しましょう。例えば「コスト vs 全世界からのレイテンシ」というトレードオフからどちらかを選択しなくてはいけない場合、ケーススタディに書かれているビジネス要件や技術要件がヒントになります。 出題傾向 出題範囲のサービスは、Associate Cloud Engineer 試験対策記事に記載されているものと、大半が重複していますので、そちらの記事をご参照ください。 参考 : Associate Cloud Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog 出題範囲は幅広く、多様なサービスを広く理解している必要があります。 当記事ではこれ以降、どのような試験問題が出るか、出題傾向とその内容を解説していきます。公式ドキュメントへのリンク等もできるだけ付記していますので、知らない用語や理解の浅い概念があれば、ドキュメントを読んだり、実際にサービスに触れる等の対策を行ってください。 更新試験 Professional Cloud Architect 試験には、一度合格して更新時期を迎えた人向けの 更新試験 も用意されています。 更新試験は英語と日本語で提供されており、問題数は通常試験の約半分の25問、試験時間は半分の1時間です。また受験費用は、通常料金の半額の $100 です。 更新試験は通常試験とは出題範囲が異なっており、ケーススタディの内容も、生成 AI ソリューションをテーマとしたものになっています。ケーススタディに関する問題が全体の90%〜100%を占めているとされており、ほとんどが生成 AI 関連の問題と考えられます。最新情報は、公式の更新認定試験ガイドを参照してください。 参考 : Professional Cloud Architect 更新認定試験ガイド 組織と IAM 組織のポリシー 組織のポリシーでは、さまざまな制約を組織全体に課すことができます。 ここでの設定は IAM での許可よりも優先されます。組織のポリシーでどんなことができるのか、もちろんすべて覚える必要はありませんが、組織に統制を効かせる際にどのようなポリシーが使われるだろうかと想像しながら以下のドキュメントを確認するとよいでしょう。 参考 : 組織のポリシーの制約 例えば以下のようなポリシーに注目して、意義や使い方（パラメータに何を設定するか）を事前に理解しておいてください。 特定リージョンしか使えないようにする ( constraints/gcp.resourceLocations ) 外部 IP アドレスを持つことができる Compute Engine VM をホワイトリスト式で制限する ( constraints/compute.vmExternalIpAccess ) 外部組織の Google アカウントが IAM 権限を持てないようにする ( constraints/iam.allowedPolicyMemberDomains ) 以下の記事も参照してください。 blog.g-gen.co.jp IAM の基本概念 Google Cloud の Identity and Access Management （IAM）は、 リソースが持つポリシーが中心 の概念であること、また 継承 が起きるということを正しく理解してください。IAM の概念については、以下の記事も参考にしてください。 blog.g-gen.co.jp Associate 試験と同様に基本的な概念をしっかり理解しておけば解ける問題ばかりです。 また試験問題で「こういうシチュエーションを改善するにはどうするか」と問われるとき、 最小権限の原則 を意識して改善策を考えてください。オーナーなどの強いロールは極力使わない方向にするべきですし、使う場合は組織全体に対して付与するのではなく、フォルダなどを使って適用範囲を制限します。 また、 サービスアカウント の使い方は理解しておいてください。サービスアカウントは、人間ではなく プログラムや Google Cloud サービスが使うアカウント です。サービスアカウントに権限を与える際は、人のアカウントと同様に、最小権限の原則に従うべきです。 選択肢に安易に「組織の管理者を付与する」「オーナー権限を付与する」などがあれば、誤った選択肢である可能性が高いと言えます。 また個人のアカウントに個別に IAM 権限を付与することなく、グループに対して付与することで、運用工数を削減することができます。 参考 : IAM を安全に使用する オペレーションスイート Cloud Monitoring Cloud Monitoring の基本機能（Google Cloud の指標、 Ops エージェントの指標、カスタム指標、ダッシュボード等）を理解してください。 blog.g-gen.co.jp Cloud Monitoring にはリソースのモニタリングやアラートの発報などの機能のほか、簡易的なインシデント管理の機能もあります。ドキュメント中心で構わないので、理解をしておく必要があります。 また Google Kubernetes Engine（GKE）でも Cloud Monitoring を使ったモニタリングが活躍します。こちらも確認しておくとよいでしょう。 Cloud Logging Cloud Logging の シンク （ログルーター）の仕様や用途をしっかり押さえておきましょう。シンクからどのサービスにログをエクスポートできるのか、どんなアクションに繋げられるのか、という点が重要です。また 集約シンク を使うことで、組織配下の全プロジェクトや、特定フォルダ配下の複数のプロジェクトのログを容易に集約し、監査用プロジェクトに保存することもできます。 参考 : ログエントリを転送する Compute Engine VM に Ops Agent をインストールすれば、VM 上のアプリケーションログを簡単に Cloud Logging に送信し、ログシンクを使って BigQuery や Cloud Storage へログを転送、保存することができます。 参考 : Ops エージェントの概要 また Cloud Logging からログをフィルタしたうえで Pub/Sub へ送信すれば、特定のログ発生をトリガにしてイベントドリブンで Cloud Run functions を起動することもできます。こういった文面を読んだ時に、構成図が思い浮かぶくらいに理解しておきましょう。 Cloud Logging 全体の概要については以下の記事をご参照ください。 blog.g-gen.co.jp セキュリティ・統制 Network Intelligence Center Network Intelligence Center は Google Cloud のネットワーク関連の可視性を提供したり、モニタリングやトラブルシューティングに役立つサービスです。以下の記事を読んで、どのような機能があるのかを確認しておきましょう。 blog.g-gen.co.jp ファイアウォールインサイト機能に注目です。これは、自動的に VPC のファイアウォールログをチェックしてルールの棚卸し等に役立つ機能です。 なお VPC のファイアウォールログは、 ファイアウォールルールごとに明示的に有効化 する必要がある点に注意しましょう。ファイアウォールのログを有効化しないと、ファイアウォールインサイト機能も動作せず、いつまで待っても検知事項がゼロのままです。 Sensitive Data Protection Sensitive Data Protection （旧称 Cloud Data Loss Prevention、Cloud DLP）で何ができるかを確認しておきましょう。また、スキャン結果はどこにどのように配置したり応用したりできるかが重要になってきます。 参考 : Sensitive Data Protection overview データ処理パイプライン中で Sensitive Data Protection を使って PII（個人識別情報）を検知することで、PII を削除してからデータを保存するユースケースなどが挙げられます。 また、Sensitive Data Protection の検査結果はデータに対するメタデータとして、Dataplex Universal Data Catalog に保存できます。 Google Kubernetes Engine（GKE） 基本概念 Professional Cloud Architect 試験では Google Kubernetes Engine（GKE）だけでなく Kubernetes の全般知識が求められる問題もあります。 Pod、Deployment、Service、Ingress、Namespace、Cluster、Istio、サーキットブレイク、マイクロサービスなどの単語や概念の理解を進めましょう。 GKE や Kubernetes については以下の記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp モニタリング GKE はネイティブに Cloud Monitoring や Cloud Logging と統合されています。この統合機能は Cloud Operations for GKE と呼ばれています。 参考 : GKE のオブザーバビリティ GKE クラスタで Managed Service for Prometheus を有効化することもできます。新規クラスタのみならず、既存クラスタでも有効化が可能です。 参考 : Google Cloud Managed Service for Prometheus 安全なデプロイ readiness probe と liveness probe を設定しておくと、Pod が更新された際などに、正常でない Pod にトラフィックがルーティングされてしまい、サービスに影響が出ることを防ぐことができます。 参考 : コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス - アプリケーションに有用な readiness probe と liveness probe を設定する GKE からの Google API への認証 GKE で実行されているアプリケーションから Google Cloud サービスへアクセスする際の推奨事項を確認しておきましょう。 GKE から Google Cloud API への認証方法の最初の選択肢は Workload Identity 機能です。これは Kubernetes のサービスアカウントと Google Cloud のサービスアカウントを紐づける機能です。GKE コンテナからすると Kubernetes サービスアカウントのみを意識すれば良いため Kubernetes リソースと Google Cloud リソースが疎結合になり、保守性が向上します。 参考 : GKE ワークロードから Google Cloud API に対する認証を行う データベース・分析 データ分析プラットフォームの選択 Google Cloud のデータ分析系サービスは多数ありますが、それぞれをどんなユースケースのときに選択するのか、押さえておきましょう。Cloud SQL、Datastore（Firestore）、Bigtable、Spanner、BigQuery の特性を、それぞれ自分の言葉で説明できるでしょうか？ 運用管理の知識を問われたときの備えて、それぞれのデータベースのバックアップ方法なども抑えておきましょう。 以下の記事の「その他のデータベース・移行」の項にて、データベースごとのユースケースを書いていますのでご参照ください。 参考 : Professional Data Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog - データベースの選択 例えば Bigtable は高スループットが出るデータベースです。IoT やアプリケーションのトラッキングのような秒間数万の書き込みリクエストがあるような場合に適しています。一方で標準的な SQL には対応していないため、 SQL での操作が必要な場合や、トランザクション処理が必要な場合には Cloud SQL や Spanner を検討することになります。 Firebase はサーバーレスでリクエスト数に応じた従量課金であるため、あまりワークロードが多くないシステムにおいてコストを重視する場合などに選択できます。 各種データベースサービスについて、以下の記事も参考にしてください。 参考 : Cloud SQLを徹底解説！ - G-gen Tech Blog 参考 : Cloud Spanner を徹底解説！ - G-gen Tech Blog 参考 : BigQueryを徹底解説！(基本編) - G-gen Tech Blog 参考 : Bigtableを徹底解説！ - G-gen Tech Blog 参考 : Firebaseを徹底解説！ - G-gen Tech Blog 参考 : AlloyDB for PostgreSQLを徹底解説！ - G-gen Tech Blog Cloud SQL オンプレミスからのデータベース（RDB）の移行先としては Cloud SQL が選択されることが多いはずです。どのような手法で移行ができるかを理解しておきましょう。 また、バックアップとリストアの方法や冗長化の方法など、可用性に関する内容は自信をもって設計・実装できるくらいに把握しておきます。 自動バックアップ機能に加え、トランザクションログの保存日数指定などが行える点を押さえておきます。また「ポイントインタイムリカバリ（PITR）機能」を用いるには、自動バックアップとポイントインタイムリカバリを 両方有効にする 必要があります。 PITR により、データベースを特定時刻の状態で復旧することができます。ただし、元のインスタンスとは別インスタンスとして構築されることになります。 以下の記事を参考にして、Cloud SQL の仕様を一通り理解しましょう。 blog.g-gen.co.jp Cloud Storage Cloud Storageの基本的な仕様や概念は Associate 試験で押さえているはずです。さらに以下のようなポイントを押さえて、応用的な使い方を理解しましょう。 IAM によるアクセス制御 オブジェクトのバージョニング 保持ポリシーと保持ポリシーのロック ストレージクラス（Standard、Nearline、Coldline、Archive） 以下の記事で Cloud Storage の一通りの仕様を解説していますので、ご参照ください。 blog.g-gen.co.jp コンピュートサービス 概要 Google Cloud のコンピュートサービスである Compute Engine、Cloud Run、Cloud Run functions、App Engine について、各プロダクトのアーキテクチャ、用法、運用管理、デプロイ、スケーリングなどの特徴を理解する必要があります。 どのようなときにどのプロダクトを選択するのか？それぞれのプロダクトの強みは何か？ や可用性を高める方法は？ コストを最適化するには？ 安全にアプリケーションの新バージョンをデプロイして移行する方法は？ 例えば Cloud Run では、 新旧バージョン間でトラフィックを徐々に移行 することができます。割合を指定することで、「新バージョンに10%、旧バージョンに90%のトラフィックをルーティング」「問題ないことがわかったら、徐々に%を変えていく」といった運用が可能です。 参考 : ロールバック、段階的なロールアウト、トラフィックの移行 また「静的ファイルは Cloud Storage に配置。軽量なバックエンド API は Cloud Run functions で実装。フロントには Cloud Load Balancing を置く」といった クラウドネイティブなアーキテクチャ は可用性・コスト効率が高いことも理解しましょう。 このように、プロダクトの特性を活かしたアーキテクチャやデプロイ方法などが問われます。 以下の記事も参考にしてください。 blog.g-gen.co.jp App Engine App Engine では、運用工数が低い スタンダード 環境と、より詳細なカスタマイズができる フレキシブル 環境が選択できます。 デプロイの容易さや運用性を優先する場合で、開発言語が Java、Node.js、Go など、スタンダード環境に対応しているプログラミング言語である場合は、スタンダードが選択肢になります。 参考 : App Engine 環境を選択する また、App Engine には新バージョンをデプロイする際、まずは別の URL へ新バージョンをデプロイして、テスト完了後に任意のタイミングで本番昇格する機能もあります。 参考 : アプリケーションをテストしてデプロイする - トラフィック移行前の App Engine でのテスト また、App Engine のフレキシブル環境は VPC ネットワーク上の Compute Engine VM で実行される一方、スタンダード環境は VPC 外 で実行されている点に注意が必要です。スタンダード環境の App Engine アプリケーションから VPC リソースや、VPC ネットワークと VPN や専用線で接続されているオンプレミス環境のリソースにアクセスするには、 サーバーレス VPC アクセス を設定する必要があります。 参考 : App Engine 環境を選択する 参考 : VPC ネットワークへの接続 CI/CD 概要 Google Cloud サービスを使って CI/CD パイプラインを構築するにはどのサービスを使うか、理解しておきます。また、各コンピューティングサービスへのアプリケーションデプロイの方法を押さえます。Google Cloud プロダクトで実装する CI/CD では、 Cloud Build が重要です。 Cloud Build はそのサービス名称からするとビルド専用のサービスにも思えますが、実際には GKE、Cloud Run、App Engine、Cloud Run functions などへのデプロイ自動化にも使われます。 Git などのソースコードレポジトリの特定のブランチに、ソースコードがコミットされたことを検知して Cloud Build が動き出し、アプリケーションやコンテナのビルドやテストが実行され、その後 GKE などにデプロイする、という一連の流れが基本です。 参考 : Google Cloud 上での DevOps と CI / CD について コンテナセキュリティ Binary Authorization というサービスでは、Google Kubernetes Engine（GKE）や Cloud Run で「署名済みのコンテナイメージ」以外はデプロイできないようにする機能があります。これにより、検査されたセキュアなイメージ以外のデプロイを防ぐことができます。 参考 : Binary Authorization の概要 VPC / ネットワーク VPC の基本 以下の2記事を参考に、 Virtual Private Cloud （VPC）の基本は改めておさらいしておきましょう。 Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い - G-gen Tech Blog Google CloudのVPCを徹底解説！(基本編) - G-gen Tech Blog VPC に対して、Associate Cloud Engineer 試験と同等以上のレベルの理解は必要です。Associate Cloud Engineer 試験対策記事の VPC に関する記述も、改めて参考にしてください。 参考 : Associate Cloud Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog ‐ VPC ネットワークセキュリティ VPC ファイアウォールの基本的な仕様は、Associate 試験と同様に必須です。 また Cloud Armor の基本概念や、実装方法（Google Cloud コンソールおよび gcloud コマンドライン）も押さえておきましょう。 参考 : Cloud Armor セキュリティ ポリシーを構成する Cloud Armor はフルマネージドの WAF サービスです。L7 レベルの攻撃を防ぐ機能に加え、接続元 IP アドレスを制限することもできます。Fastly などの CDN からのトラフィックは許可できるよう、名前付き IP アドレスリストも用意されています。Fastly で言えば sourceiplist-fastly というようなリスト名です。 Cloud Armor の基本は以下の記事で把握することができます。 blog.g-gen.co.jp 接続性 概要 異なる VPC ネットワークに存在する VM 同士で通信するにはどうすればいいか、といった応用的な方法を理解しておきます。以下のそれぞれの特徴を理解してください。 VPC 間で VPC ネットワークピアリングを接続する VPC 間で Cloud VPN を使って接続する 複数の VPC の NIC を VM に追加する VPC ネットワークピアリング を使うと、異なる VPC ネットワーク間を接続できます。利用料金がかからず、最もコスト効率の良い方法です。VPC ネットワーク同士が異なるプロジェクトや 異なる組織 に所属していても、VPC ネットワークピアリングを使うことができます。 参考 : VPC ネットワーク ピアリング VPC 間の推移的通信 VPC ネットワークピアリングで2つの VPC ネットワークを接続すると、自動的にルートが交換され、相互に通信できるようになります。ただし以下のような場合、 VPC A と VPC C 同士は通信できません。 VPC A ===(Peering)=== VPC B ===(Peering)=== VPC C VPC A と C は直接繋がっていないので、お互いに通信できません。この特性を「VPC ネットワークピアリングでは、推移的な接続はできない」と表現します。俗にこれを「2ホップ制限」と呼ぶこともあります。 ただし、この構成を VPC ネットワークピアリングではなく Cloud VPN で構成すれば、適切なルート交換を設定する前提で、推移的な通信が可能です。 ハイブリッドネットワーク オンプレミスネットワークと VPC ネットワークを接続するための様々な方法を理解しておきましょう。 Google Cloud には、 Dedicated Interconnect 、 Partner Interconnect 、 ダイレクトピアリング 、 キャリアピアリング と呼ばれる4つのライベート接続方法があり、それぞれユースケースが異なります。 細かい設定までは理解する必要はありませんが、 どのようなときにどれを選ぶか を理解しておきましょう。 オンプレミスから Google Cloud の VPC ネットワークへプライベート接続を確立するためには、Dedicated Interconnect（専有型専用線）または Partner Interconnect（共有型専用線）を選択します。これらの専用線サービスを使うことで、Cloud VPN に比べて、安定した帯域とレイテンシを確保できます。 一方で、Google Workspace 等の Google サービスに接続したいときに ダイレクト ピアリング（専有型専用線）やキャリアピアリング（共有型専用線）を選択します。 専有型か共有型かという観点では、自社・データセンター等から Google の PoP（Point of Presence）に直接接続できる場合であり、かつ安定的で広い帯域が求められる場合に、専有型である Dedicated Interconnect / ダイレクトピアリングを選択します。一方でコストが重視される場合は、共有型である Partner Interconnect / キャリアピアリングを選択します。 参考 : Network Connectivity プロダクトの選択 可用性 SLA Cloud VPN や Cloud Interconnect の可用性についても理解しておきます。 Cloud VPN で言えば、99.99% の可用性 SLA が適用されるには、以下の構成である必要があります。 1台の HA VPN ゲートウェイを、2台のピアデバイスに接続（トンネル数は2） 1台の HA VPN ゲートウェイを、外部 IP アドレスを2つ持つ1台のピアデバイスに接続（トンネル数は2） 1台の HA VPN ゲートウェイを、1つの外部 IP アドレスを持つ1台のピアデバイスに接続（トンネル数は2） つまり、トンネルが2つ確立されていれば、オンプレ側のルータが1台でも、99.99%の 可用性 SLA の対象になります 。ただし HA VPN ゲートウェイ側は、2つのインターフェイスを使用する必要があります。 以下のドキュメントを参照し、構成を理解しておいてください。 参考 : HA VPN トポロジ - 99.99% の可用性 SLA 用に構成する 参考 : Dedicated Interconnect で 99.99% の可用性を実現する Compute Engine Compute Engine の基本 Compute Engine の基本的な仕様は、Associate 試験と同様です。さらに、運用にあたり重要となる応用的な概念を加えて理解しておきましょう。 blog.g-gen.co.jp マネージドインスタンスグループ マネージドインスタンスグループ（MIG）におけるインスタンスのアップデートの仕様が問われることがあります。 MIG でインスタンスを更新するとき、方法が「自動更新（Automatic または proactive）」「選択（selective または opportunistic）」の二種類があります。前者はインスタンスの更新が自動的にされます。後者は手動で命令したときや新インスタンスが作成されたときにのみ更新されます。日中の稼働が激しいシステムなどでは、自動更新（proactive 更新）はリスクが大きいため、避けることを検討します。 参考 : MIG で VM 構成の更新を自動的に適用する ‐ タイプの更新 リージョン永続ディスクを利用した可用性向上 リージョン永続ディスク は、Compute Engine VM にアタッチ可能な永続ディスクです。通常の永続ディスクがゾーンリソースなのに対して、リージョン永続ディスクはリージョンリソースです。ある片方のゾーンで障害が発生しても、データは別のゾーンに複製されます。 Compute Engine VM を複数のゾーンにデプロイし、現用系と待機系のアクティブ/スタンバイ構成を取っている場合、現用系のゾーンが停止しても、リージョン永続ディスクであれば待機系の VM に 強制アタッチ できます。これにより、可用性の高い構成を実現できます。 参考 : ディスクの同期レプリケーションについて 参考 : 同期的に複製されたディスクを使用して HA サービスを構築する ライセンスの持ち込み Windows Server のライセンスは、一定条件下で Google Cloud に持ち込む（BYOL）ことができます。以下のドキュメントを参考に、一連の流れを把握してください。 参考 : お客様所有ライセンスの使 ライセンスの持ち込みには、オンプレミスの仮想マシンの、仮想ディスクファイルを Compute Engine にインポートし、イメージを作成します。また、デプロイ先の Compute Engine は、物理的に専有された 単一テナントノード である必要があります。 その他 以下のような細かい仕様を押さえておいてください。 Cloud IAP Linux VM での起動スクリプトの使用 オーバープロビジョニング（CPU やメモリが過剰にアサインされている VM）に対して推奨事項を表示する方法 Spot VM その他のプロダクト 以下のようなサービスも出題範囲となっています。細かい使い方まで分かれば理想的ですが、業務で使ったことがなければ、最低でも「どのようなサービスか」「どのようなときに、どのように利用されるのか」などを押さえておきましょう。 Migrate for Compute Engine ランブック という言葉を把握しておく Cloud Memorystore Cloud Filestore Fire store ではなく File store 選択可能な Service Tier を把握し、ユースケースやスループット上の限界値を確認しておく Cloud Scheduler Anthos Service Mesh / Anthos Config Management Dataproc 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは株式会社G-genの渡邉@norryです。 前回はBusinessエディションでの端末管理をお話しました、今回はそのEnterpriseエディション編になります。 blog.g-gen.co.jp 今回は主に利用人数300名以上のEnterpriseエディションで端末管理を利用したい場合に、Google Workspace Business Plusと何が違うのかを知りたい方のご参考になればと思います。 補足になりますがEnterpriseエディションは300名以下の組織でも利用可能となっていますので、ご利用されたい機能がある場合には選択肢としてご覧ください。 BusinessエディションとEnterpriseエディションの全体比較記事はこちらになります。 blog.g-gen.co.jp 端末管理を考えた時にどのGoogle Workspace Enterpriseプランを選ぶべきか Enterprise Standard及びPlusを選択した方が良いケース 端末管理においてのBusiness Premiumとの違い Business Premiumも一定の管理機能は備わっている Google Workspaceを導入するなら株式会社G-genにご相談ください。 端末管理 を考えた時にどのGoogle Workspace Enterpriseプランを選ぶべきか Google Workspace Enterpriseエディションには「Enterprise Essentials」「Enterprise Standard」「Enterprise Plus」の3つのプランがあります そしてこのプランのうち端末管理を考慮した場合にプランの選択肢としては下記の２つになります。Enterprise Essentialsは端末管理のエンタープライズ エンドポイント管理機能を備えていませんので省略しています。 Enterprise Standard Enterprise Plus ただしEnterprise Essentialsも基本のエンドポイント管理と高度なエンドポイント管理の機能は備えていますので、300名以上で Gmail以外 の機能を利用し端末管理は別のサードパーティー製品でカバーするケースには良いかと思います。 Enterprise Standard及びPlusを選択した方が良いケース Google Workspaceを300名以上での利用と様々なOS（Chrome OS、Android 、iOS、Windows）を統合的に管理したい場合にEnterprise Standard及びEnterprise Plusをおすすめします。 このプランではMDM (Mobile Device Management)の領域をカバーしています。サードパーティーのMDMを利用せずにGoogle Workspaceのみで管理する場合にはこちらを選択ください。 ただし、Enterprise Standard及びPlusのプランにおいて 端末管理 で使える機能について差異はありません。 以下がGoogle Workspace Enterpriseの各プランの端末管理における機能比較表になります。 Enterprise Essentials Enterprise Standard Enterprise Plus 基本のエンドポイント管理（多数の機能） ✔ ✔ ✔ 高度なエンドポイント管理（多数の機能） ✔ ✔ ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ ✔ デバイス監査ログ ✔ ✔ 使われていない会社所有デバイスに関するレポート ✔ ✔ 会社所有の Android デバイス ✔ ✔ 会社所有の iOS デバイス ✔ ✔ Windows デバイス管理 ✔ ✔ iOS データの保護 ✔ ✔ デバイスのリモートワイプ（Windows） ✔ ✔ モバイル デバイスの証明書 ✔ ✔ 管理ルール ✔ ✔ 端末管理においてのBusiness Premiumとの違い Google Workspace Business Premiumにも端末管理の機能は備わっていました、ではBusiness PremiumとEnterprise Standard及びPlusでの機能面での違いは何でしょうか Business Premiumも一定の管理機能は備わっている 下記が比較表になります。Business Premiumの場合Chrome OSやAndroid OSのみ対象とするとライセンスの範囲内で管理が可能です。Enterprise Standard及びPlusでは、iOSデバイスの管理やWindowsデバイスのリモートワイプ（消去）、モバイルデバイスの証明書など、エンタープライズな環境で複数のOSを管理する場合に必須な機能が備わっている事が分かります。 Business Plus Enterprise Standard Enterprise Plus 基本のエンドポイント管理（多数の機能） ✔ ✔ ✔ 高度なエンドポイント管理（多数の機能） ✔ ✔ ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ ✔ ✔ デバイス監査ログ ✔ ✔ ✔ 使われていない会社所有デバイスに関するレポート ✔ ✔ ✔ 会社所有の Android デバイス ✔ ✔ ✔ 会社所有の iOS デバイス ✔ ✔ Windows デバイス管理 ✔ ✔ iOS データの保護 ✔ ✔ デバイスのリモートワイプ（Windows） ✔ ✔ モバイル デバイスの証明書 ✔ ✔ 管理ルール ✔ ✔ 以上から、どの種類（OS）の端末をどの程度管理したい（ログインさせない、ブロックする、紛失時のワイプなど）かによってプランをご検討ください。 Google Workspaceを導入するなら株式会社G-genにご相談ください。 Google Workspaceを使った働き方に変えると本当に組織のコミュニケーションとコラボレーションのあり方が変わってびっくりすると思います。 この感動をより多くの人に体感してもらいたいですね。 株式会社G-genではGoogle Workspace / Google Cloud（GCP）を5%割引でご提供しております。 g-gen.co.jp また、Google Workspace / Google Cloud（GCP）/ Chrome book の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 お問い合わせはこちらから docs.google.com 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。