G-gen の杉村です。当記事では Google Cloud (旧称 GCP) の認定試験の中でも基本的なレベルの内容である Associate Cloud Engineer 試験 の合格に役立つ情報を記載します。
とはいえ、 試験の 利用規約 において、試験の内容を公開することは禁じられています。本投稿では試験問題そのものを書くこと等はせず、主にサービスカットで 合格するためには何を知っているべきか を中心に記載します。
なお当記事に記載されていることで試験範囲をすべてカバーできているわけではない点、ご了承ください。公式で発表されている 試験ガイド や 模擬試験 などもぜひ駆使して、学習を進めてください。
- はじめに
- 組織/リソース/ID系
- IAM
- Access Approval
- VPC / Cloud DNS / Cloud Load Balancing
- コマンドライン (gcloud / gsutil / bq)
- Google Compute Engine (GCE)
- AppEngine / Cloud Run / Google Kubernetes Engine 系
- Cloud Storage
- データベース / DWH
- オペレーションスイート
- 料金
- その他
はじめに
試験の概要
Associate Cloud Engineer 試験 は、 Google Cloud の認定試験の中でも基本的な試験です。
Google Cloud のインフラ系サービスを中心に、セキュリティ、アプリケーションホスティング、データベース、モニタリングなど、幅広い範囲が対象となります。
試験時間は 120 分、試験問題数は 50 問です。
試験は日本語、英語、スペイン語で提供されています。
なお、他の試験一覧は以下をご参照ください。
試験の難易度
当試験の難易度としては 比較的簡単 であると言えます。
"基本情報技術者試験" 程度の基本的な IT の知識があり、かつ Google Cloud に関する多少の業務経験がベースとして理想的です。
なお公式ガイドには「6ヶ月以上の Google Cloud における実務経験」が推奨であると記載されていますが、必ずしもこれを満たしていなくても、十分合格を狙えます。
また普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、 Google の考えるクラウドらしいクラウドの使い方が何か、という一種の「クラウド哲学」に慣れておくことが重要です。
これに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。
推奨の勉強法
- 書籍や公式のトレーニングを受け Google Cloud の基本を理解する
- 試験ガイド を読み出題範囲を理解する
- 当記事を読み、出題傾向を理解する
- 理解した試験範囲・出題傾向をもとに勉強する
- 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする
上記のうち 1. の基礎学習については、書籍が日本語でいくつか出版されているのに加え、 Google Cloud Japan 社が定期的にセミナーなどを開催しています。
ご参考まで Google Cloud Certification Jumpstart プログラム というプログラムを紹介します。
以下のサイトでは、過去のセッション内容を動画で閲覧することも可能です。
出題傾向
Associate Cloud Engineer 試験では以下のようなサービスが主題範囲です。
- 組織 / リソース
- アカウント (Cloud Identity / Google Workspace)
- Identity and Access Management (IAM)
- Virtual Private Cloud (VPC)
- Cloud DNS
- Google Cloud CLI (gcloud)
- Compute Engine
- App Engine
- Cloud Run
- Google Kubernetes Engine (GKE)
- Cloud Storage
- データベース系サービス (Cloud SQL / Cloud Spanner / Bigtable / BigQuery / Datastore)
- Cloud Monitoring / Cloud Logging
- 利用料金
当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきますので、参考にして各サービスの内容を押さえてください。
わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。
そのように勉強すれば、試験に合格できるのに加え、実践的な知識となるでしょう。
組織/リソース/ID系
リソース階層の概念
Google リソースが階層構造となっていることを押さえておきましょう。
最上位に 組織 があり、その下に フォルダ (入れ子構造も可能)、 プロジェクト 、 あとは個々のインスタンスや BigQuery テーブルといった個別リソースに降りていきます。
プロジェクトやフォルダもリソースの一種です。リソースには IAM を紐付けられること、またその IAM 権限は継承されることに留意しましょう (後述) 。 以下の記事も参照してください。
プロジェクト
Google Cloud を利用開始するには何が必要か、と考えたとき、少なくともプロジェクトを作成することは 必須 です。
プロジェクト作成 、課金の有効化、各サービスの API の有効化、などの流れを押さえておきましょう。
IAM
IAM の基本概念
Google Cloud の IAM は リソースに紐づけて設定する ものであり 継承の概念がある ということを正確に押さえましょう。
IAM の概念については、以下のブログ記事を参考にしてください。
これがわかれば、例えば VM にアタッチされたサービスアカウントが プロジェクトを跨いで別のプロジェクトのリソースにアクセスするにはどうすればいいか ということも自ずと答えが出るはずです。
gcloud による操作
コマンドラインで IAM を参照したり編集したりする操作も、ある程度押さえたほうが良いでしょう。
以下のドキュメントで gcloud コマンドによる組織・フォルダ・プロジェクトといった大枠リソースへの IAM 操作方法を理解しておきましょう。
大原則。 IAM ロールはアカウントではなくグループに付与すべし
複数のドキュメントで繰り返し述べられているベストプラクティスとして以下があります。
IAM ロールは、個別の Google アカウントではなく Google グループに付与すべし
個別のアカウントにロールを付与してしまうと、その人が退職したり異動になるたびに多くのリソースに対して細かい IAM のメンテナンスが必要になってしまいます。
グループにアカウントを所属させて、 IAM ロールはグループに対して付与するようにしましょう。
- 参考 : ポリシーの管理
基本ロールと事前定義ロール
基本ロールと事前定義ロールのいくつかを押さえておきましょう。
基本ロールはいわずもがな、以下の3つです。
- 閲覧者 (roles/viewer)
- 編集者 (roles/editor)
- オーナー (roles/owner)
基本ロールは権限が非常に大きいため、 できうるならば使うことを避けます 。 事前定義ロールや、カスタムロールを使ってきめ細かい権限制御をしましょう。
事前定義ロールは以下のドキュメントで確認できます。数が多すぎるので、もちろん 全て覚える必要はありません 。
- 参考 : ロールについて
とはいえ、いくつかの特徴的なロールは「ああ、そんなのあるんだ」と理解しておきましょう。
例えば プロジェクト閲覧用ロール や Resource Manager 用のロール などは押さえておきます。例えば roles/browser ロール (ドキュメントでは ブラウザ、コンソール上では 参照者 と翻訳) は、組織階層構造を閲覧できるようになるが、プロジェクト内のリソースまでは見られないという、特徴的なロールです。
Access Approval
何をするための機能 (サービス) なのか、 必要な IAM 権限は何か、を押さえておきましょう。
Access Approval は Google のテクニカルサポート等がユーザーのコンテンツにアクセスする必要がある場合に、明示的な承認を経ないとアクセスできないようにすることができるサービスです。
有効化すると、メールや Pub/Sub 通知で承認依頼が行われます。
- 参考 : Access Approval の概要
VPC / Cloud DNS / Cloud Load Balancing
VPC とサブネットの基本
VPC とサブネットの概念をきちんと理解します。以下の記事もご参考にお願いします。
前者の記事で VPC の全体概要を掴み、後者の記事で詳細を深堀りして理解いただければ役に立つかと思います。
VPC の特に重要な仕様として、以下が挙げられます。
- VPC の中に作ったサブネット間は自動的にルートが交換されるので、互いに通信できる
- サブネットはリージョンリソースである
- リージョンAに作ったサブネットAと、リージョンBに作ったサブネットBは互いに通信できる (ファイアウォールの穴が開いていれば)
また、 VPC 自体は IP アドレス帯を持たず、サブネットが持ちます。 VPC へのサブネット追加は容易にできますし、既存サブネットに IP アドレスレンジを追加することもできる、ということを押さえましょう。
セグメント分けとファイアウォール
Google Cloud では、よく比較される Amazon Web Services (AWS) と比べるとあまり細かく VPC やサブネットを分けない傾向にあります。
ファイアウォールとネットワークタグを駆使して、いわゆる DMZ と内部ネットワークを分けることが第一選択肢です。
とはいえ、全く通信させたくない環境同士は VPC を分けます。
まずは、ファイアウォールの仕組みを正確に理解しておきましょう。
上り (Ingress) ルールと下り (Egress) ルールはどっちがどっちなのか。
ネットワークタグを使ってインスタンスを指定するとはどういうことなのか。
ルールを全く書かない状態だとデフォルトではどのような挙動になるのか。
これらのことは答えられるようになっておきましょう。
限定公開の Google アクセス
限定公開のGoogleアクセス機能で何ができるかを押さえましょう。
特にハイブリッドネットワーク (オンプレとクラウドを併用したネットワーク) でのユースケースを押さえます。
Cloud DNS
基本的な機能を押さえます。
VPC の中から利用できる限定公開ゾーン (Private Zone) などの意味を 押さえましょう 。
Cloud DNS では一般公開ゾーン (Public Zone) や限定公開ゾーン (Private Zone) を使うことができ、前者はインターネットから名前解決ができるゾーンであり、後者は Google Cloud の VPC の中などプライベートネットワークからのみ名前解決できるゾーンです。
Cloud Load Balancing
どんなケースでどのロードバランサーを選択すべきかを押さえます。
- 参考 : ロードバランサの選択
ロードバランサーには「外部 vs 内部」「グローバル vs リージョナル」「HTTP(S) vs TCP/UDP」などにより適切なロードバランサーを選択します。
上記ドキュメントのディシジョン・ツリーの図が分かりやすいです。
コマンドライン (gcloud / gsutil / bq)
gcloud, gsutil, bq とそれぞれの用途を押さえます。
いずれのコマンドラインツールも、 まず gcloud コマンドで環境設定をしていることに注目しましょう。
Google Compute Engine (GCE)
基礎知識
Compute Engine の基礎的な知識は、以下の記事を参考に押さえておくと役に立ちます。
マシンタイプ
アプリケーションにとって最適なスペックを持つマシンタイプを選べるようにしておきましょう。
何タイプが何が得意なのか、押さえておきます。
ディスク・バックアップ・リストア
永続ディスクに関する理解を深めておきましょう。 永続ディスクからのインスタンス作成はどうすればよいのか、バックアップをスケジュールするにはどうすればよいか、などを公式ドキュメントから理解しておきます。
購入オプション
Compute Engine にはいくつかの購入方法があると思います。
以下を人に説明できるまで理解しておきます。
- オンデマンド
- プリエンプティブル
- 継続利用割引
- 確約利用割引
プリエンプティブル・インスタンス は非常にお得に見えますが、 強制終了 や 時間制限 があることに留意します。
確約利用割引や継続利用割引については、以下の記事も参考にしてください。
AppEngine / Cloud Run / Google Kubernetes Engine 系
App Engine
App Engine の強みが何かを押さえましょう。細かい仕様まで覚える必要はなく、どのようなサービスで、何を強みとしているかを理解してください。
リリースした複数のバージョン間でユーザトラフィックの割合を調整できるのも優れた機能の一つです。
- 参考 : トラフィックの分割
Google Kubernetes Engine (GKE)
Qwiklabs 等で GKE の基本的な概念と操作方法を理解するとベターです。
Pod, ReplicaSet, Deployment, Node, Cluster, Service...
使い分け
App Engine / Cloud Run / Google Kubernetes Engine はいずれもアプリケーションをホストするためのサービスです。コンピュート系 (コンピューティング系) サービスと総称されることもあります。どのようなときに、どのサービスを利用するのか を考えましょう。
特に利用が小規模で散発的なワークロードでは何を使うでしょうか？
バッチ処理では？
どのような Web アプリケーションだとどれを選択するでしょうか？
以下の記事を一読し、各サービスの特徴と使うべき場面を理解しておきましょう。
Cloud Storage
どのくらいの保存期間のデータならどのストレージクラスを選ぶべきか、しっかり押さえておきます。
- 普通: Standard
- 1か月に一度程度: Nearline
- 四半期に一度程度: Coldline
- 年に 1 回未満程度: Archive
以下のドキュメントが参考になります。
また Cloud Storage のユースケースも押さえます。
オブジェクトストレージですので、普通のファイルシステムとは違います。
安価でスケーラブルなので、フォーマットもサイズも異なる多様なデータをクラウドに保存するために適した選択でしょう。
以下の記事で Cloud Storage の詳細を解説していますので、是非参考にしてください。
データベース / DWH
Cloud SQL
以下の当社記事を読んで、Cloud SQL の基本的な機能を押さえます。
- インスタンスとは
- データのエクスポート
- バックアップ
BigQuery
以下の記事を参考にして、BigQuery の機能を一通り押さえておきます。
特に 外部テーブル定義 などで他サービスと連携する方法は重要です。
データベースのベストな選択
以下の問いに答えられるようにしておきます。 Google Cloud のデータベースサービスの特徴とユースケースを必ず押さえておきましょう。
- 超大量に押し寄せる IoT のセンサーデータを格納して低レイテンシで読み出しするのにベストなデータベースは？ (BigTable)
- 複数のリージョンにまたがるトランザクションワークロードに適したデータベースは？ (Cloud Spanner)
- Web アプリケーションから使う No SQL データベースは？ (Cloud Datastore ※現在は Firestore に統合)
- 一般的なアプリケーションからリレーショナルデータベースを使いたいときは？ (Cloud SQL)
- 大量のデータに対して SQL を使って分析を行いたいときは？ (BigQuery)
データパイプライン
データパイプラインを実現する以下のようなサービスの概要を理解しておきましょう。
オペレーションスイート
Cloud Monitoring
Cloud Monitoring の基本機能は以下の記事で押さえることができます。
メトリクスを監視し、しきい値を超えたらアクションを起こす、という基本的な使い方を押さえます。
アラートの通知先を "通知チャネル" として設定できます。
通知チャネルとして何を設定できるのかを押さえておきます。
- 参考 : 通知チャネルの管理
Pub/Subを通知先として設定できるので、アラートを契機にメッセージを Pub/Sub に送り、それをトリガに Cloud Functions を起動して... というようなことも実現できますね。
Cloud Logging
以下の記事で Cloud Logging の機能を把握する必要があります。
Cloud Audit Logs
証跡管理機能である Cloud Audit Logs の基本を、以下の記事で押さえておきましょう。
料金
請求先アカウント
請求先アカウントの概念は以下の記事で押さえておきましょう。
予算アラート
請求先アカウントに対し、予算アラートを仕掛けることができます。
- 参考 : 予算と予算アラートの作成、編集、削除
利用料金の見積もり
Google Cloud Pricing Calculator を使って料金を見積もることができます。
パブリッククラウドでは往々にして、 最適な利用料金となるよう考慮してアーキテクチャを設計するのも、エンジニア (アーキテクト) の仕事です 。
一つの目的を達成するためのアーキテクチャは無数にありますが、その中でも最もコスト効率良く (Cost-effective とよく言われます) 実現する方法を編み出すことが求められます。
原則的には「マネージドサービスが使えるときは、マネージドサービスを使う。次点で仮想サーバを選択する」と考えれば良いです。
Cloud Functions で実現すれば、 Compute Engine の VM を常時起動させなくてよいので、コスト効率が良くなる、などが一例です。
利用料金データの BigQuery へのエクスポート
請求先アカウントから BigQuery へ請求データを自動エクスポートすることができます。
無償で使える Looker Studio (旧称データポータルもしくは Data Studio) で可視化して分析することもセオリーの一つです。
その他
Google Cloud の哲学
全体を通して、選択肢の絞り込みに迷った際は Google Cloud の哲学ともいうべき共通認識に基づいて判断しましょう。
以下のようなキーワードを理解して判断に活かすことができれば、大きく外れることはないはずです。
「いやそうは言っても、実務ではこういうときはこうするだろう...」という気持ちをぐっと抑えて、Google の / クラウドの哲学に沿った回答を選ぶことが重要です。
- 責任共有モデル
- 最小権限の原則
- 組織全体でガバナンスを発揮する
- 権限の分譲
- ステートレスなアプリケーションとイミュータブルなインフラ
- 自動化によるトイルの削減
- スケーラブル・高可用性・堅牢性
- モニタリングと自動的な通知
受験環境
受験環境に関する当社メンバーの実体験が以下の記事で紹介されています。
ぜひご参照ください。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it