Professional Cloud Architect試験対策マニュアル

記事タイトルとURLをコピーする

G-gen の杉村です。 Professional Cloud Architect 試験 は、 Associate Cloud Engineer 試験の上位に位置する Google Cloud (旧称 GCP) の難関認定資格です。本投稿では試験の合格に役立つ、勉強方法や出題傾向などについて解説します。

はじめに

Professional Cloud Architect 試験 とは

Professional Cloud Architect 試験は Associate Cloud Engineer 試験の上位に位置する Google Cloud の難関認定資格です。

試験時間は 120 分、試験問題数は 50 問です。試験は日本語と英語で提供されています。

インフラ系、アプリ系の Google Cloud サービスの知識のみならず、データアナリティクス、セキュリティ、モニタリングなど幅広い知識が求められます。この試験に合格していることは、Google Cloud を幅広く理解しており、一人前の Google Cloud 技術者であることを示すといっても過言ではないでしょう。

可能であれば、当試験より先に Associate Cloud Engineer 試験に合格しておくことが望ましいですが、受験の必須要件ではありません。Associate Cloud Engineer 試験については以下の記事もご参照ください。

blog.g-gen.co.jp

Professional Cloud Architect 試験の難易度

当試験の難易度としては 中程度 だと言えます。

IPA の "応用情報技術者試験" 程度の基本的な IT 知識があり、かつ Google Cloud をある程度業務で使用した経験があるというのが前提知識として理想的です。試験ガイドでは「3年以上の業界での経験と、1年以上の Google Cloud における経験」が推奨だと記載されていますが、必ずしもこれを満たしていなくても十分合格が狙える資格です。

むしろ普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、Google の考えるクラウドらしいクラウドの使い方が何か、という一種の クラウド哲学 のようなものを頭にインプットしておくことが重要です。選択肢に迷った時に「最もクラウドらしい選択肢はどれか」という思考が助けになることがあります。

これらに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。

特に Amazon Web Services (AWS) の試験を受けたことがある人であれば気が付きますが、問題文の長さや複雑さは AWS Certified Solutions Architect - Professional 認定のそれと比較すると、短くてシンプルであると感じられます。体感的案難易度は AWS の Professional 試験より低いかもしれません。

推奨の勉強法

  1. Associate Cloud Engineer を先に取得する
  2. 試験ガイド を読み出題範囲を理解する
  3. 当記事を読み、出題傾向を理解する
  4. 把握した試験範囲・出題傾向をもとに勉強する
  5. 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする
  6. ケーススタディ を直前に確認する

ドキュメントを読むだけでは理解が進まないサービスも出てきます。こういったときは「書籍を読む」「ブログ記事を検索して読む」「コンソール画面や gcloud で実際に触ってみる」の3つを織り交ぜて学習を進めるのがおすすめです。

特に3つめの「触る」は大事です。コンソールやコマンドラインを触ると リソースの構成 が手にとるように分かり、理解が進むことが多いと言えます。リソース構成を把握してからドキュメントに戻ると、理解度が全く違うことがあります。

ケーススタディ

Professional 試験ではケーススタディと呼ばれる、架空の会社をテーマにしたクラウド導入事例が引用されます。

試験中は画面の右半分にケーススタディの内容が表示されるため覚える必要はありませんが、事前に目を通しておきましょう。どんな本番環境でも要求されるような基本的な要件も多いですが、そのケースで大事にしている(優先すべき)要件が書かれている点に注意しましょう。例えば コスト VS 全世界からのレイテンシが小さい というトレードオフになりえる選択肢からどちらかを選択しなくてはいけない場合、ケーススタディに書かれているビジネス要件・技術的要件がヒントになります。

ビジネス要件・技術要件に合わせて適切なサービスを選択する、などの問題が出題されます。全ての問題でケーススタディが引用されるわけではありませんが、この「要件にあわせて適切なサービスを選択」というテーマは Professional 試験の共通の傾向です。

出題傾向

出題範囲のサービスは Associate Cloud Engineer 試験対策記事 でご紹介したものと、大半が被っていますのでそちらの記事をご参照ください。

出題範囲は幅広く、多種多様なサービスを広く理解している必要があります。

当記事ではこれ以降、どのような試験問題が出るか、出題傾向とその内容を解説していきます。公式ドキュメントへのリンク等もできるだけ付記していますので、知らない用語や理解の浅い概念があれば、ドキュメントを読む・実際にサービスに触れる等の対策を行ってください。

組織 / IAM

組織のポリシー

組織のポリシーでは、さまざまな制約を組織全体に課すことができます。

ここでの設定は IAM での許可よりも優先されます。組織のポリシーでどんなことができるのか、もちろんすべて覚える必要はありませんが、組織に統制を効かせる際にどのようなポリシーが使われるだろうかと想像しながら以下のドキュメントを確認するとよいでしょう。

例えば以下のようなポリシーに注目して、使い方を事前に理解しておいてください。

  • 特定リージョンしか使えないようにする (constraints/gcp.resourceLocations)
  • External IP を持つことができる Compute Engine VM をホワイトリスト式で制限する (constraints/compute.vmExternalIpAccess)
  • 外部組織の Google アカウントが IAM 権限を持てないようにする (constraints/iam.allowedPolicyMemberDomains)

以下の記事も参照してください。

blog.g-gen.co.jp

IAM の基本概念

IAM は リソースに紐づく概念 であり、 継承 が起きるということを正しく理解していてください。IAM の概念については、以下の記事も参考にしてください。

blog.g-gen.co.jp

Associate 試験と同様に基本的な概念をしっかり理解しておけば解ける問題ばかりです。

また試験問題で「こういうシチュエーションを改善するにはどうするか」と問われるときは最小権限の原則を意識して改善策を考えてください。オーナーなどの強いロールは極力使わない方向にするべきですし、使う場合は組織全体に対して付与するのではなく、フォルダなどを使って適用範囲を制限します。

またサービスアカウントの使い方は理解しておいてください。サービスアカウントは 人ではなくプログラムや Google Cloud サービスが使うアカウント です。サービスアカウントに権限を与える際は、人のアカウントと同様に、最小権限の原則に従うべきです。

選択肢に安易に「組織の管理者を付与する」「オーナー権限を付与する」などがあれば、誤った選択肢である可能性が高いと言えます。

また個人のアカウントに個別に 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 を使って Cloud Logging に送信すれば、簡単に BigQuery や Cloud Storage へログを保存することができます。

また Cloud Logging からログをフィルタしたうえで Pub/Sub へ送信すれば、特定のログ発生をトリガにしてイベントドリブンで Cloud Functions 関数を起動することもできます。こういった文面を見て構成図が思い浮かぶくらいに理解しておきましょう。

Cloud Logging 全体の概要については以下の記事をご参照ください。

blog.g-gen.co.jp

セキュリティ・統制

Network Intelligence Center

Network Intelligence Center は Google Cloud のネットワーク関連の可視性を提供したり、モニタリングやトラブルシューティングに役立つサービスです。以下の記事を読んで、どのような機能があるのかを確認しておきましょう。

blog.g-gen.co.jp

ファイアウォールインサイト機能に注目です。これは、自動的に VPC のファイアウォールログをチェックしてルールの棚卸し等に役立つ機能です。

なお VPC のファイアウォールログは ルールごとに明示的に有効化 することが必要な点に注意しましょう。ファイアウォールのログを有効化しないと、ファイアウォールインサイト機能も動作しません(いつまで待っても検知事項がゼロのままです)。

Data Loss Prevention

Cloud Data Loss Prevention (Cloud DLP) で何ができるかを確認しておきましょう。また、スキャン結果はどこにどのように配置したり応用したりできるかが重要になってきます。

Cloud DLP の結果はデータに対するメタデータとして Data Catalog に保存されます。

Data Catalog は Google Cloud サービスで、いわゆるメタデータを管理するためのサービスです。BigQuery 等に入っているデータに対してラベル付けをしたり説明を付記するなどして、データの管理・維持運用に用いられます。特にデータ活用基盤では重要になるサービスです。

Cloud DLP + Data Catalog によりどこにどのような個人情報 (PII) が保管されているかが適切に管理されます。

Kubernetes / 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 クラスタで Managed Service for Prometheus を有効化することもできます。新規クラスタのみならず、既存クラスタでも有効化が可能です。

GKE からの Google API への認証

GKE で実行されているアプリケーションから Google Cloud サービスへアクセスする際の推奨事項を確認しておきましょう。

GKE から Google Cloud API への認証方法の最初の選択肢は Workload Identity 機能です。これは Kubernetes のサービスアカウントと Google Cloud のサービスアカウントを紐づける機能です。GKE コンテナからすると Kubernetes サービスアカウントのみを意識すれば良いため Kubernetes リソースと Google Cloud リソースが疎結合になり、管理上都合が良くなります。

データベース・分析

データ分析プラットフォームの選択

Google Cloud のデータ分析系サービスは多数ありますが、それぞれをどんなユースケースのときに選択するのか、押さえておきましょう。Cloud SQL、Datastore(Firestore)、Bigtable、Spanner、BigQuery の特性を、それぞれ自分の言葉で説明できるでしょうか?

運用管理の知識を問われたときの備えて、それぞれのデータベースのバックアップ方法なども抑えておきましょう。

以下の記事の「その他のデータベース・移行」の項にて、データベースごとのユースケースを書いていますのでご参照ください。

blog.g-gen.co.jp

例えば Bigtable は高スループットが出るデータベースです。IoT やアプリケーションのトラッキングのような秒間数万の書き込みリクエストがあるような場合に適しています。

一方で標準的な SQL には対応していないため、 SQL での操作が必要な場合や、トランザクション処理が必要な場合には Cloud SQL や Spanner を検討することになります。

Cloud SQL

オンプレミスからのデータベース(RDB)の移行先としては Cloud SQL が選択されることが多いはずです。どのような手法で移行ができるかを理解しておきましょう。

また、バックアップとリストアの方法や冗長化の方法など、可用性に関する内容は自信をもって設計・実装できるくらいに把握しておきます。

自動バックアップ機能に加え、トランザクションログの保存日数指定などが行える点を押さえておきます。また「ポイントインタイムリカバリ (PITR) 機能」を用いるには、 自動バックアップとポイントインタイムリカバリを両方有効にする 必要があります。

PITR により、データベースを特定時刻の状態で復旧することができます (ただし、元のインスタンスとは別インスタンスとして構築されることになります) 。

以下の記事を参考にして、Cloud SQL の仕様を一通り理解しましょう。

blog.g-gen.co.jp

Cloud Storage

Cloud Storageの基本的な仕様や概念は Associate 試験で押さえていると思います。
以下のようなポイントを押さえて、応用的な使い方を理解しましょう。

  • アクセス制御
  • オブジェクトのバージョニング
  • 保持ポリシーと保持ポリシーのロック
  • Cloud Storage のパフォーマンス最適化 (資料)

最後のリンクにある「アップロード時のパフォーマンス最適化」については、マルチスレッドアップロードの方法の記述を中心に一通り目を通しておきましょう。

また以下の記事で Cloud Storage の詳細を解説していますので、ご参照ください。

blog.g-gen.co.jp

Cloud Run / Cloud Functions / App Engine (コンピューティング系サービス)

概要

各サービスのアーキテクチャ、用法、運用管理、デプロイ、スケーリングなどの特徴を理解する必要があります。

  • どのようなときにどのサービスを選択するのか? (それぞれのサービスの強みは何か)
  • 冗長性を確保するには?
  • コストを最適化するには?
  • 安全に新バージョンに移行するためのデプロイ方法は?

例えば Cloud Run では 新旧バージョン間でトラフィックを徐々に移行 することができます。

また「静的ファイルは Cloud Storage に配置。動的バックエンドは Cloud Functions で実装。フロントには Cloud Load Balancing を置く」といったクラウドネイティブなアーキテクチャは可用性・コスト効率が高いため、クラウド系試験ではこういった選択肢を選ばされることが多いと言えます。

このように、サービスの特性を活かしたアーキテクチャやデプロイ方法などが問われます。

以下の記事も参考にしてください。

blog.g-gen.co.jp

App Engine

App Engine には運用工数が低いスタンダード環境と、より詳細なカスタマイズができるフレキシブル環境があります。

運用性を優先する場合で、開発言語が Java・Node.js・Go など対応言語である場合はスタンダードを選ぶことになります。

また App Engine には新バージョンをデプロイする際、別 URL でデプロイしてテスト後に任意のタイミングで本番昇格させる機能もあります。

CI/CD

概要

Google Cloud サービスを使って CI/CD パイプラインを構築するにはどのサービスを使うか、理解しておきます。また、各コンピューティングサービスへのアプリケーションデプロイの方法を押さえます。

Google Cloud サービスで実装する CI/CD では Cloud Source RepositoryCloud Build といったサービスが重要になってきます。

Cloud Build はそのサービス名称からするとビルド専用のサービスにも思えますが、実際には GKE, Cloud Run, App Engine, Cloud Functions などへのデプロイ機能が備わっています。

Git や Cloud Source Repository (Google Cloud の提供するマネージドな Git リポジトリ) などの コードレポジトリにソースがコミットされたことを検知して Cloud Build が動き出し、アプリケーションやコンテナのビルドが走り、 Cloud Build がそれらを GKE などにデプロイする、という一連の流れが基本です。

コンテナセキュリティ

Binary Authorization というサービスでは、Google Kubernetes Engine(GKE)や Cloud Run で「署名済みのコンテナイメージ」以外はデプロイできないようにする機能があります。これにより、検査されたセキュアなイメージ以外のデプロイを防ぐことができます。

VPC / ネットワーク

VPC の基本

以下の2記事を参考に、 VPC の基本は改めておさらいしておきましょう。

  1. Google Cloud(旧GCP)のVPC基本機能を学ぶ!VPC・サブネット・NAT・ピアリング・AWSとの違い
  2. Google CloudのVPCを徹底解説!(基本編)

Associate Cloud Engineer 試験と同等以上のレベルの理解は必要です。当社の Associate Cloud Engineer 試験対策記事の VPC の箇所 も、改めて参考にしていただければと思います。

ネットワークセキュリティ

VPC ファイアウォールの基本的な仕様は Associate 試験の際に理解したと思います。

Cloud Armor の基本概念やその 実装方法 (コンソール / gcloud) も押さえておきましょう。

Cloud Armor はフルマネージドの WAF サービスです。L7 レベルの攻撃を防ぐ機能に加え、接続元 IP アドレスを制限することもできます。Fastly などの CDN からのトラフィックは許可できるよう、名前付き IP アドレスリストも用意されています。Fastly で言えば sourceiplist-fastly というようなリスト名です。

Cloud Armor の基本は以下の記事で把握することができます。

blog.g-gen.co.jp

接続性

概要

異なる VPC に存在する VM 同士で通信するにはどうすればいいか、といった応用的な方法を理解しておきます。

"VPC 間で Peering を繋ぐ" , "VPC 間で VPN を繋ぐ" , "VPC を跨いだ NIC を VM に追加する" といった方法が思いつくと思います。それぞれの特徴を理解する必要があります。

VPC 間の推移的通信

例えば "VPC 間で Peering を繋ぐ" だと、自動的にルートが交換され、 VPC 間で通信ができるようになります。ただし以下のような場合、 VPC AVPC C 同士は通信できません。

VPC A ===(Peering)=== VPC B ===(Peering)=== VPC C

VPC AC は直接繋がっていないので、お互いに通信できません。これは "推移的な通信" と呼ばれます。 VPC Peering では 推移的な通信はできない という仕様です (2 hop 制限と呼ぶこともあります) 。

ただし、これが Peering ではなく Cloud VPN であれば、適切なルート交換がされてさえいれば、推移的な通信は可能です。

ルート交換

IP アドレスが重複した VPC / サブネット同士の通信はやっかいです。VPC 同士を VPC ネットワークピアリングで接続してしまうと、VPC 内のすべてのサブネットのルートが交換されてしまうので、通信に支障が出ます (そもそも、重複した IP アドレスレンジを持つ VPC 同士はピアリングできません)。

一方で Cloud VPN であれば任意のルートのみを交換させることが可能です。IP アドレスが重複しているサブネットへのルートだけは除外してルート交換させることもできます。

ハイブリッドネットワーク

オンプレミスネットワークと VPC / Google サービスを接続するための様々な方法を理解しておきましょう。

Dedicated InterconnectPartner Interconnectダイレクト ピアリングキャリア ピアリング といったプライベート接続方法があり、これら4つの接続方法はユースケースが異なります。 細かい設定までは理解する必要はありませんが、どのようなときにどれを選ぶか、は理解しておきましょう。

Google Cloud の VPC へのプライベートネットワーク接続のためには Dedicated Interconnect (専有型) または Partner Interconnect (共有型) を選択します。

Google Workspace 等の Google サービスに接続したいときに ダイレクト ピアリング (専有型) や キャリア ピアリング (共有型) を選択します。

専有型か共有型かという観点では、自社・データセンター等から Google の PoP (Point of Presence) に直接接続できる場合で、かつ安定的で広い帯域が求められる場合に専有型である Dedicated Interconnect / ダイレクト ピアリング を選択します。そうでない場合は共有型である Partner Interconnect / キャリア ピアリング です。

可用性 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つのインターフェイスを使用)。

以下のドキュメントを参照し、構成を理解しておいてください。

Compute Engine (GCE)

Compute Engine の基本

Compute Engine の基本的な仕様は Associate 試験の際に理解したと思います。運用の際に重要となる応用的な概念を加えて理解しておきましょう。

blog.g-gen.co.jp

マネージドインスタンスグループ

マネージドインスタンスグループ(MIG)におけるインスタンスのアップデートの仕様が問われることがあります。

MIG でインスタンスを更新するとき、方法が「自動更新(Automatic または proactive)」「選択(selective または opportunistic)」の二種類があります。前者はインスタンスの更新が自動的にされます。後者は手動で命令したときや新インスタンスが作成されたときにのみ更新されます。日中の稼働が激しいシステムなどでは、自動更新(proactive 更新)はリスクが大きいため、避けたいこともあるでしょう。

その他の細かい仕様

以下のような細かい仕様を押さえておいてください。

その他

以下のようなサービスも出題範囲となっています。細かい使い方まで分かれば理想的ですが、業務で使ったことがなければ最低でも概要 (どのようなサービスか、どのようなときにどのように利用されるのか) を押さえておきましょう。

  • Migrate for Compute Engine
    • ランブック という言葉を把握しておく (参考)
    • ランブックは、Wave (移行対象の VM グループ) に含める VM と、ターゲット VM の構成を指定する CSV ファイル。ソース VM についての記述、ターゲット VM とネットワークのプロパティの定義、その他のメタデータも含まれます。
  • Cloud Memorystore
    • Redis をクラウドに移行する際の選択肢として認識しておく
  • Cloud Filestore
  • Cloud Scheduler
  • Anthos Service Mesh / Anthos Config Management
  • Dataproc
    • オンプレミスの Hadoop クラスタの移行先として選択肢になる
    • コスト効率を求める場合、Spot VM を基盤として使うことも可能

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。