G-gen の杉村です。 Google Cloud（旧称 GCP）におけるアプリケーション開発者向けの認定資格である Professional Cloud Developer 試験の勉強方法や出題傾向など、合格に向け役立つ情報をご紹介します。

試験情報

Professional Cloud Developer 試験とは

Professional Cloud Developer 試験は、クラウドネイティブなアプリケーション開発を行うための知識を問う Google Cloud 認定資格です。

Google Cloud 上でアプリケーションの高可用性、スケーラビリティ、セキュリティを確保し、マネージドサービスの活用やサーバーレスの活用により運用性の高いアーキテクチャを設計する知見が求めらます。CI/CD や開発ツールに関する知識や、認証・認可に関する知識も試験範囲に含まれます。

試験時間は120分、問題数は60問です。代表的な Google Cloud 認定資格である Associate Cloud Engineer 試験や Professional Cloud Architect 試験は「120分・50問」ですが、当試験では問題数が10問多く設定されています。ただし1問1問はそこまで問題文が長いわけではなく、また当記事をお読みのほとんどの方の第一言語であろう日本語で受験できるため、試験時間が足りなくて苦しい印象は持たないはずです。

試験は日本語と英語で提供されており、申し込み時に選択します。

参考 : Professional Cloud Developer

Professional Cloud Developer 試験の難易度

Professional Cloud Developer 試験の難易度は 中程度 であるといえます。

IPA の「応用情報技術者試験」相当の ITやシステム開発に関する基礎知識に加えて、Google Cloud の各種サービスに関する知見が求められます。試験では Google Cloud の知識のみならず、アプリケーション開発やコンテナに関する一般的な知識を求めるものもあります。そのため学習の際は Google Cloud に限ることなく「基本的な IT 知識」「基本的なアプリケーション開発に関する知識」も押さえるべきといえます。

公式ガイドでは「3年以上の業界経験」「1年以上の Google Cloud を使用したソリューションの設計と管理の経験」が求められるレベルであると記載されていますが、実際にはそこまでの経験がなくても、ポイントを押さえた学習をすれば、合格は難しくありません。

Professional Cloud Developer 試験の勉強方法

以下のような勉強方法が推奨です。しかしながら以下にこだわることなく、各自の現在の知識量や得意領域に応じた学習をすることが推奨されます。

モダンな開発手法に関する知識を別途、学習する
Associate Cloud Engineer 試験を学習し、取得することで Google Cloud の基本を理解
試験ガイドを確認して試験範囲を理解する
公式ドキュメントを中心に試験範囲を学習する
当記事を読み、試験範囲の詳細を把握し、知らない知識を補填する

Associate Cloud Engineer 試験についてはぜひ以下の記事を参考にしてください。

blog.g-gen.co.jp

前述の 1. は「モダンな開発手法」というあいまいなワードで表現されています。具体的には、以下のような用語の理解を深めると良いでしょう。これらは Google Cloud に限らず、開発に関する一般的な知識としても重要です。具体的にこれらの用語が試験で問われるわけではないかもしれせんが、これらの用語のエッセンスを理解することで回答を選択する際の判断基準になります。

CI/CD（継続的インテグレーション / 継続的デリバリ）
DevOps / DevSecOps
テスト駆動開発
オブザーバビリティ
イベントドリブンアーキテクチャ
サーバーレスアーキテクチャ
疎結合アーキテクチャ
マイクロサービスアーキテクチャ
ステートレスなアプリケーション、ステートフルなアプリケーション

出題範囲と傾向

出題範囲と傾向について

当記事では、主に Google Cloud のサービスカットで、出題範囲や傾向をご紹介します。また、知っているべき知識をできるだけ公式ドキュメント等へのリンク付きでご紹介します。ぜひ学習に役立てていただき、合格を目指してください。

この記事で全ての技術要素の解説をするわけではありません。記載があったりリンクが貼付されている場合は、そのあたりが試験における重要ポイントだとご認識ください。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャに関する知見が問われる問題が出題されます。

以下の公式ドキュメントは App Engine のドキュメントですが、マイクロサービスの RESTful API 設計における基本的な考え方を示しており、参考になります。

「API コントラクト」「API バージョンを示す URL」「互換性を損なう変更と互換性を損なわない変更」などについて、用語の意味を押さえておきましょう。

参考 : マイクロサービスのコントラクト、アドレス指定、API

Cloud IAM（Identity and Access Management）

ほぼすべての Google Cloud 認定試験で共通して言えることとして、Cloud IAM に関する正しい理解が必須です。

以下の記事を読み、 IAM Policy がリソースに紐づく概念であることを正しく理解してください。

blog.g-gen.co.jp

また、そのうえでサービスアカウントを正しく理解してください。

例えば Compute Engine や Cloud Functions で稼働するプログラムが、Google Cloud の他のサービスの API を呼び出す際には、認証情報（サービスアカウントキー）をテキストとして保存しておき呼び出すのではなく、サービスアカウントをインスタンスや関数にアタッチして使うのが最適です。

Google Kubernetes Engine（GKE）

Workload Identity

Google Kubernetes Engine（GKE）で稼働するアプリケーションが Google Cloud の API へアクセスする際の認証・認可には Workload Identity を使うことが第一選択肢として推奨されています。

参考 : Authenticate to Google Cloud APIs from GKE workloads

Workload Identity を使うと Cloud IAM で作成した "Google Cloud の" サービスアカウントと、Kubernetes リソースとして作成した "Kubernetes の" サービスアカウントを紐づけすることができます。

これにより Kubernetes 上での権限管理と Google Cloud 上での権限管理を疎結合にすることができ、セキュリティや運用性が向上します。

この原則を問う問題が複数出題されますので、確実に押さえておきましょう。

認証情報の管理

Workload Identity を使い Google Cloud サービスへの認証を管理する方法は前述の通りですが、オンプレミスに存在するデータベースへの認証などのために ID・パスワードが必要とされる場面もあります。

コンテナ内やストレージにこういった認証情報を永続化するよりも、Google Cloud サービスである Secret Manager に認証情報を保管すれば、セキュアな保管やローテーションの管理などが容易になります。

認証情報自体は Secret Manager に保存しますが、GKE から Secret Manager にアクセスするにはやはり前述の通り Workload Identity が使われます。

参考 : Using Secret Manager with other products

サービスメッシュ

Istio on Google Kubernetes Engine は、2024年6月現在では非推奨となり Cloud Service Mesh の利用が推奨されています。2024年6月現在の当試験では Istio に関して問われますが、詳細な仕様まで問われるわけではありませんし、基本的な考え方は Cloud Service Mesh と同じです。

サービスメッシュの考え方や、mTLS によるサービス間通信の暗号化について、概要だけでも理解しておきましょう。重要なのは、Istio や Cloud Service Mesh を導入することにより、サービス間通信を少ない労力で暗号化することができます。

デプロイ戦略

Blue/Green デプロイ、ローリングアップデート、カナリアリリース、A/B テストといったデプロイ戦略を理解してください。

「それらがどのような方法なのか」「メリットとデメリット」「ロールバックの迅速さ」などに着目しましょう。これらのデプロイ戦略は Google Cloud や GKE に特有のものではなく、現代のデプロイ戦略の考え方として共通のものです。

以下の公式ドキュメントも参照してください。

参考 : アプリケーションのデプロイとテストの戦略
参考 : GKE でのデプロイとテストの戦略の実装

サービス間通信

Kubernetes リソースである Service には ClusterIP、NordPort、LoadBalancer などがあります。

これらのうちクラスタ "内" のサービス間通信を担うのは ClusterIP で、クラスタ "外" からの通信を受け付けるのが NodePort や LoadBalancer です。

また、GKE クラスタ内でマイクロサービス間の通信を実現するにはどのようなリソース構成とするべきか、理解しておきましょう。

これらについても当ページでは詳細に解説しません。参考として、以下の書籍で Kubernetes リソースの詳細な解説がされています。

参考 : ハンズオンで分かりやすく学べる Google Cloud実践活用術データ分析・システム基盤編

クラスタ外からの通信

Ingress に関する知見も問われます。たとえば External HTTPS Load Balancer に複数のホスト名用の SSl/TLS 証明書を設定する方法について押さえてきましょう。

参考 : Using multiple SSL certificates in HTTPS load balancing with Ingress

Network Policy / Authorization Policy

Network Policy や Authorization Policy を概要レベルでも構いませんので、押さえておきましょう。

これらはクラスタ内の Pod 間、サービス間の通信を制御する仕組みです。

参考 : Control communication between Pods and Services using network policies
参考 : Authorization policy overview

Pod のライフサイクル

Pod を停止させる際、データベースとのセッションを正しく切断してから終了するなど、Pod 終了前のアクションを設定したい場合、PreStop を利用します。

参考 : コンテナライフサイクルフック

Cloud Run

Cloud Run の基礎

Cloud Run の基本は、以下の記事を読んで理解しておきましょう。Cloud Run はフルマネージド・サーバーレスのコンテナ実行プラットフォームです。

blog.g-gen.co.jp

Cloud Load Balancing の背後に置いて Web アプリとして動作させることも、 Pub/Sub の push/pull サブスクリプションの背後に置いてイベントドリブンなプログラムを動作させることも、 Cloud Scheduler によって定期的なジョブとして呼び出すこともできます。

Cloud Run へのデプロイ

Cloud Run へのアプリケーションデプロイの基本的な流れを押さえてください。

ソースコードと Dockerfile が格納されているディレクトリで docker build を実行（コンテナイメージのビルド）
Docker イメージをコンテナイメージレポジトリへ Push（レポジトリへの格納）
イメージの URL を指定して gcloud run deploy（Cloud Run へのデプロイ）

また、上記のほかに、以下のように Cloud Build を利用した方法もあります。

ソースコードと Dockerfile が格納されているディレクトリで gcloud builds submit を実行（コンテナイメージのビルドとレポジトリへの格納）
イメージの URL を指定して gcloud run deploy（Cloud Run へのデプロイ）

このような基本的な流れを理解して、問いに答えられるようにしておいてください。

参考 : Cloud Run へのデプロイ
参考 : コンテナイメージをビルドします

Dockerfile なしでのデプロイ

Cloud Run へのアプリケーションのデプロイは、レポジトリに格納したコンテナイメージの URL を指定して行うことが基本ですが、ソースコードの存在するディレクトリからデプロイコマンドを実行することでも実現できます。この場合、自動的にコンテナイメージのビルド、イメージの Artifact Registry レポジトリへの格納、デプロイが行われ、Dockerfile の定義も必要ありません。

参考 : ソースコードからデプロイする

Cloud Functions

Cloud Functions はフルマネージドのサーバーレスサービスで、任意のコードを動かすことができるサービスです。Function as a Service（FaaS）と分類されることもあります。Cloud Functions は Node.js、Python、Go、Java、.NET、Ruby、PHP などのプログラミング言語に対応しています。

その際に押さえておいたほうが良い知識として、セキュアコーディングは必須です。セキュアなコーディングについては、以下のような書籍が役に立ちます。

参考 : 体系的に学ぶ安全なWebアプリケーションの作り方

例えば CORS (Cross-Origin Resource Sharing) という概念を押さえておきます。詳細は当記事では解説しないため、必ずご自身で調べ、理解してください。

例えばフロントエンドの Web サイトのドメイン名と、Cloud Functions に設定するカスタムドメイン名が異なる場合は、Access-Control-Allow-Origin: ${呼び出し元ドメイン名} をレスポンスヘッダに含ませる必要があります。

App Engine

App Engine はマネージドな Web アプリケーションプラットフォームであり、高度にスケーラブルな構成を簡単に構築できます。開発者は、インフラの構築・運用の工数を省き、アプリケーション開発に集中することができます。

App Engine に限らず様々なマネージドプラットフォームやコンテナアーキテクチャに共通して言えることですが、アプリケーションはステートレスである必要があります。そのためセッション管理には Redis や Memcached といったインメモリデータベースを利用するというアーキテクチャが、問題文の前提として設定されることが多くなっています。

そして Google Cloud では Redis / Memcached のマネージドサービスである Memorystore があり、これもセットで出題されます。

細かいところですが例えば Memorystore を App Engine から利用する場合のアクセス方法を理解しておきます。

App Engine（Standard）から Memorystore へ接続するには、サーバレス VPC アクセスが必要
App Engine（Flexible）から Memorystore へ接続するには、App Engine が authorized network 内にいる必要がある

Cloud Storage

Cloud Storage は堅牢で安価なオブジェクトストレージです。Cloud Storage については当社記事で詳細に解説していますので、以下を参照してください。

blog.g-gen.co.jp

ライフサイクルマネジメント機能、署名付き URL など、便利な機能をしっかりと押さえておいてください。「署名付き URL で制限時間付きの専用 URL を発行し、認証済みの利用者だけが Cloud Storage 上のオブジェクトをダウンロード可能にする」などのユースケースが頻出です。

参考 : 署名付き URL

また記事でも説明されている静的ウェブサイトホスティング機能により Cloud Load Balancing と組み合わせて、ウェブサイトのホスティングに使うことができます。

マルチリージョンの Cloud Storage + 外部 HTTP ロードバランサー + Cloud CDN 有効化 のようなアーキテクチャにすることで、安価かつフルマネージドな形で、世界中の利用者をターゲットとしたウェブサイトを簡単に構築することができます。このような構成を、頭の中で描けるようにしておいてください。

Firestore

Firestore は、モバイルアプリや Web アプリのバックエンドデータベースとして利用できる、フルマネージドな NoSQL データベースです。

旧称 Datastore から発展した「Firestore（Datastore モード）」と、Web アプリ・モバイルアプリに最適な「Firestore（ネイティブモード）」が存在し、これらはほとんど別々の製品であると考えることができます。

参考 : Feature comparison

試験に向けては、特にネイティブモードの Firestore について重点的に理解したほうが良いでしょう。

Firestore ネイティブモードはドキュメント志向データベースであることから、テーブル、カラム、レコードといった概念はありません。その代わりに「ドキュメント」「コレクション」という概念が存在します。

参考 : Cloud Firestore データモデル

また Firestore ネイティブモードはモバイルアプリを想定しており、モバイル機器のローカル側と Firestore の通信が切れても、ローカル側でデータを保持してアクセスできるようにしておき、通信が回復した際に同期するようにできます。また開発担当者の PC のローカル上で稼働するエミュレーターも用意されています。

Compute Engine

基本

仮想サーバーのサービスである Compute Engine も出題範囲です。Compute Engine のインフラ寄りの内容よりも、アプリケーションのデプロイに関わる点が重視されます。

たとえば「VM メタデータ」（インスタンスごとに Key/Value で情報を持たせられる機能）に、デプロイ先の環境ごとに異なる情報を格納しておき、デプロイの際の初期化処理時に利用する、といったユースケースが出題されます。

参考 : About VM metadata

またメタデータには「プロジェクトレベルのメタデータ」と「インスタンスレベルのメタデータ」があります。プロジェクトレベルで設定したメタデータは全てのインスタンスから取得でき、インスタンスレベルのメタデータはそのインスタンスからのみ取得できます。

モニタリングとロギング

アプリケーションのログを Cloud Logging へリアルタイムに送付したい場合、Ops Agent をインストールすることで任意のログを Cloud Logging へ送出できます。以下の記事を参考にしてください。

blog.g-gen.co.jp

データベース選定

Cloud SQL、Bigtable、Cloud Spanner、Firestore といった Google Cloud のデータベースの違いを、しっかり把握しておきましょう。以下の記事の「その他のデータベース」の項を参照してください。

blog.g-gen.co.jp

整合性の強弱、トランザクションの有無、SQL の利用可否などを、データのアクセスパターンと照らして選定する必要があります。

Pub/Sub

Pub/Sub はフルマネージドなメッセージキューイングサービスです。

システムコンポーネント同士を疎結合にするために重要なサービスであり、クラウドらしいアーキテクチャの要となります。

Pull サブスクリプションと Push サブスクリプションの2種類がある点、またストリーミングデータの受け口としても使われる点などから、Amazon Web Services (AWS) でいう Amazon SQS、Amazon SNS、Amazon Kinesis Streams を組み合わせたような位置付けのサービスです。

またローカルで動作するも存在しており、これが問題で問われることもあります。

参考 : Testing apps locally with the emulator

開発環境

Cloud Code というツールの存在を押さえておきましょう。

VSCode、IntelliJ などの IDE 向けのプラグインであり、Google Cloud における開発を便利にしてくれます。

参考 : Cloud Code and Gemini Code Assist IDE Plugins

また Cloud Shell は Google Cloud を実際に利用・運用している人はほぼ使ったことがあるはずです。もし一度も使ったことがない場合、多少は触っておきましょう。Cloud Shell には 5 GB の永続ディスクが割り当てられますが、120日間アクセスがない場合、中身が削除されます。

参考 : Cloud Shell: アクティビティのない状態

CI/CD

Cloud Build

Google Cloud で CI/CD パイプラインを構築する際に要になるのは Cloud Build です。

Cloud Build はその名の通り、ソフトウェアのビルドのためのサービスですが、 Google Cloud 上の各プラットフォームへのデプロイにも用いることが可能です。ソースコードレポジトリへの Push を検知して Code Build が動き、ビルド・テスト・デプロイを実施させることができます。

フルマネージドの Git レポジトリサービスである Cloud Source Repositories と、Cloud Build を連携させて上記のような CI/CD パイプラインを実現することができます（ただし、2024年6月以降、Cloud Source Repositories の新規利用受け付けは終了しました）。

参考 : Cloud Build を使用したビルドの自動化

なお Cloud Build にはビルドステップ（または単にステップ）という概念があります。ステップはその名の通りビルドの各ステップを処理する単位です。ステップごとにマネージドなコンテナが起動して処理を行います。YAML または JSON で記述した構成ファイルに、一つ以上のステップを定義し、実行することでビルドやデプロイを実行するイメージです。

各ビルドステップは別々のコンテナで実行されますが、/workspace ディレクトリ配下に配置したファイルはステップ間で引き継がれます。

参考 : ビルドステップ

脆弱性の管理

CI/CD にセキュリティの概念を取り込み、開発・運用にセキュリティ担保の仕組みを継続的に取り込む体制は、DevSecOps とも呼ばれます。

コンテナイメージの格納レジストリである Artifact Registry では、脆弱性スキャンを有効化することができます。

参考 : Artifact Analysis と脆弱性スキャン

またスキャンで問題がなかったコンテナイメージにのみ署名（attestation）を付与し、Binary Authorization により署名がないイメージのデプロイを禁止することで、セキュリティを向上することができます。Binary Authorization の設定時はポリシー（コンテナイメージのデプロイを規定するルール）と認証者（）という2つのオブジェクトの作成が必須です。

署名と Binary Authorization を使ったコンテナイメージのセキュア化は、Professional Cloud Security Engineer 試験でも問われる、一種の定石です。以下の記事もご参照ください。

blog.g-gen.co.jp

監視、オブザーバビリティ

Google Cloud における監視・運用といえば Cloud Monitoring です。

blog.g-gen.co.jp

上記の基本は押さえつつ、Cloud Trace、Cloud Profiler を押さえておきます。

Cloud Trace は、アプリケーションの分散トレースを実現する仕組みです。アプリケーションがユーザのリクエストを処理するのにかかる時間を計測したり、マイクロサービス間のレイテンシを継続できるので、SLI/SLO の計測にも利用できます。アプリケーションに必要なクライアントライブラリを追加し、必要なコードを追加することで利用可能になります。

Cloud Profiler はアプリケーションの CPU やメモリなどリソース使用状況を継続収集するための仕組みです。アプリケーションにおいて、ソースコードのどの部分が最もリソースを消費しているのか、などを特定できるので、非効率なアプリケーションのオーバーヘッドの特定に利用できます。

Cloud Endpoints

Cloud Endpoints は公開 API を実装するためのサービスです。Cloud Endpoints を介して API を公開することでモニタリング、セキュア化、分析、クォータの設定などが実現できます。

Cloud Endpoints では Nginx ベースの Extensible Service Proxy（ESP）と呼ばれるプロキシ機能により、さまざまな機能を実現します。ESP は「Cloud Load Balancing の後」「VM / GKE などバックエンドアプリケーションの前」に配置されます。

以下のドキュメントの構成図をよく覚えておいてください。この構成図の中で ESP がどこに配置されているか = Cloud Endpoints の配置場所を分かっているだけでも回答に役立ちます。