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 試験の難易度は 中程度 であるといえます。
IPA の「応用情報技術者試験」相当の IT ・開発に関する基礎知識に加えて Google Cloud の各種サービスに関する知見が求められます。

Google Cloud の知識のみならず、出題の中ではアプリケーション開発やコンテナに関する一般的な知識を求めるものもあります。
学習の際は Google Cloud に限ることなく「基本的な IT 知識」「基本的なアプリケーション開発に関する知識」も押さえるべきといえます。

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

Professional Cloud Developer 試験の勉強方法

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

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

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

blog.g-gen.co.jp

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

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

出題範囲と傾向

出題範囲と傾向について

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

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

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

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

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

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

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

IAM

Google Cloud 認定試験ではほぼすべての試験で共通ですが Cloud IAM に関する正しい理解が必須です。
以下の記事を読み、 IAM Policy が「 リソースに紐づく概念である 」ことを正しく理解してください。

blog.g-gen.co.jp

またそのうえで サービスアカウント に関する理解を正しくします。

例えば Compute Engine や Cloud Functions で稼働するプログラムが Google Cloud の他のサービスの API を叩く際には、インスタンス / 関数にアタッチされたサービスアカウントを使ってアクセスさせるのが最適です。
インスタンス / 関数にデフォルトでアタッチされるサービスアカウントは広い権限を持っています。
セキュリティの大原則は 最小権限の原則 ですので、個別のサービスアカウントを作成して最小の権限を与え、アタッチすることが望ましいです。

Google Kubernetes Engine (GKE)

Workload Identity

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

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 は現在では非推奨となり Anthos Service Mesh の利用が推奨されています。
試験 (2022 年 4 月現在) では Istio に関して問われますが、詳細な仕様まで問われるわけではなく、原則は同じです。

インターネットで検索すれば日本語情報が多数出てくるため当ページでは細かく解説しませんが、サービスメッシュの考え方や、 mTLS によるサービス間通信の暗号化 について概要だけでも理解しておきましょう。

デプロイ戦略

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

「それらがどのような方法なのか」「メリットとデメリット」「ロールバックの迅速さ」などに着目しましょう。
以下の公式ドキュメントも参照してください。

またこれらのデプロイ戦略は Google Cloud や GKE に特有のものではありません。
インターネットに多数の情報が落ちていますので、そういった情報も参考に、理解を深めてください。

サービス間通信

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

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

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

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

クラスタ外からの通信

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

Network Policy / Authorization Policy

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

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

Cloud Run

Cloud Run の基本は公式ドキュメントを読み理解しておきましょう。

Cloud Run はフルマネージドのサーバーレスサービスで、任意のコンテナを実行できるプラットフォームです。

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

一つ押さえておいたほうが良い知識として Knative という Google 製のツールがあります。
これはいわば「オンプレミス等のプラットフォームで動かす Cloud Run 」だと思えばよいでしょう。
このツールが存在すること程度を頭の片隅に入れる程度で OK です。

Cloud Functions

Cloud Functions はフルマネージドのサーバーレスサービスで、任意のコードを動かすことができるサービス (Function as a Service : FaaS) です。
Node.js 、 Python 、 Go 、 Java 、 .NET 、 Ruby 、 PHP などに対応しています。

Cloud Functions のユースケースは Cloud Run のユースケースとよく似ています。これらは Javascript 等で動くフロントエンドサービスのバックエンドプログラムのプラットフォームとして選択することも多いです。

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

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

例えば CORS (Cross-Origin Resource Sharing) という概念を押さえておきます。
CORS についての詳細は当ページでは解説しませんため、必ずお調べください。

例えばフロントエンドの Web サイトのドメイン名と Cloud Functions に設定するカスタムドメイン名が異なるドメイン名の場合はブラウザの CORS の実装に従い 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 など、運用上便利な機能をしっかりと押さえておいてください。

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

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

Firestore

Firestore に関する問題も多く出題されます。

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

旧称 Datastore から発展した Firestore (Datastore モード) と Web アプリ・モバイルアプリに最適な Firestore (ネイティブモード) の 2種類があり、ほぼ別製品といっていいものになっています。

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

Firestore ネイティブモードはドキュメント志向データベースであることから、テーブル、カラム、レコードといった概念ではなく、「 ドキュメント 」「 コレクション 」という概念となっています。
このデータモデルをきちんと理解することを推奨いたします。

また Firestore ネイティブモードはモバイルアプリを想定しており、モバイル機器のローカル側と Firestore の通信が切れても、ローカル側でデータを保持してアクセスできるようにしておき、 通信が回復した際に同期 を取るようにすることができます。

また開発担当者の PC のローカル上で稼働するエミュレーターも用意されています。

Compute Engine

基本

仮想サーバーのサービスである Compute Engine も出題範囲です。

Compute Engine のインフラ寄りの内容よりも、アプリケーションのデプロイに関わる点が重視されます。

たとえば VM メタデータ (インスタンスごとに Key/Value で情報を持たせられる) に、アプリの展開に必要な環境ごとの情報を入れておき、デプロイ処理時 (初期化処理時) にメタデータから情報を読み取って展開に利用する、などのユースケースが出題されます。

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

さらにトラブルシュートの方法としてシリアルコンソールを使用したトラブルシューティングについてのドキュメントも目を通しておいてください。

モニタリングとロギング

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

この Agent は fluentd が元となっており、試験問題では過去の経緯から「 Google 版の fluentd エージェント」などと呼ばれているかもしれません。

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

blog.g-gen.co.jp

データベース選定

Cloud SQL / Bigtable / Cloud Spanner のデータベースの違いを把握しておきましょう。

整合性やトランザクションの有無 (ACID の有無) などをデータのアクセスパターンと照らして選定するはずです。

Pub/Sub

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

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

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

Cloud Logging のシンク機能と組み合わせて、ログを収集しリアルタイムに別のプログラムに Push するような動かし方も可能です。

またローカルで動作するエミュレータも存在しており、これが問題で問われることもあります (存在を知っていれば良い程度です) 。

開発環境

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

VSCode 、 IntelliJ などの IDE のためのツールであり、 Google Cloud における開発を便利にしてくれます。

また Cloud Shell は Google Cloud を実際に利用・運用している人はほぼ使ったことがあるはずです。
もし使ったことがない場合は、多少は触っておきましょう。
組み込みのコードエディタである Cloud Shell エディタが付属しており、その気になればこれらだけで開発を完結することもできなくはありません。

Cloud Build (CI/CD)

CI/CD

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

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

なお Cloud Build には ステップ (step) という概念があります。
ステップはその名の通りビルドの各ステップを処理する単位ですが、ステップごとにマネージドなコンテナが起動して処理を行います。

YAML または JSON で記述した構成ファイルに、一つ以上のステップを定義し、実行することでビルドやデプロイを実行するイメージです。
各ビルドステップは別々のコンテナで実行されますが /workspace 以下に残したファイルは ステップ間で引き継がれます 。

こうした基本概念を押さえておきます。

脆弱性の管理

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

Google Cloud ではこれを実現する仕組みも存在します。

例えば脆弱性があるバージョンのミドルウェアを含んだコンテナがデプロイされないようにしたい場合、Cloud Build でビルド → コンテナイメージは Artifact Registry (試験では前身である Container Registry が選択肢として提示) に格納しますが、ここに対するコンテナイメージの自動スキャンを有効化することで、自動的なセキュリティ施策とすることができます。

またスキャンで問題がなかったコンテナイメージにのみ署名を付与し 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 Debug といったいわゆる Operation Suite を押さえておきます。

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

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

Cloud Debugger はアプリケーション実行環境にデバッガライブラリをインストールすることでコードごとの デバッグに活用 できる機能です。

似ているように見える 3 サービスですが、それぞれが何を目的とした仕組みなのかを押さえておけば、問題に回答することは難しくありません。

Cloud Endpoints

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

Cloud Endpoints では Nginx ベースの Extensible Service Proxy (ESP) と呼ばれるプロキシ機能により機能提供がされます。 ESP は「 Cloud Load Balancing の後ろ」「 VM / GKE などバックエンドアプリケーションの手前」に配置されます。

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