G-gen の杉村です。 Google Cloud (旧称 GCP) の認定資格の一つである Professional Cloud DevOps Engineer 試験の対策や出題傾向について解説します。合格の助けになれば幸いです。

基本的な情報
- Professional Cloud DevOps Engineer とは
- Professional Cloud DevOps Engineer の難易度
試験対策方法
出題範囲・出題傾向
Site Reliability Engineering (SRE)
オブザーバビリティ
開発手法・CI/CD
- 構成管理
- CI/CD パイプライン
コスト管理
Google Kubernetes Engine (GKE)
Cloud Run
- Cloud Run の基本
- デプロイと運用

基本的な情報

Professional Cloud DevOps Engineer とは

Professional Cloud DevOps Engineer 試験は、主に Google Cloud で稼働するアプリケーションの運用に関する知見を問う試験です。

Google Kubernetes Engine (GKE) や Cloud Run、Compute Engine 等の監視、運用、インシデント管理、アプリケーションの CI/CD に関する知識を問うほか、特徴的な点として Google の提唱する Site Reliability Engineering (SRE) に関するベストプラクティスが数多く問われます。 Google の提唱する方法論について問われるわけですが、その内容は比較的一般的に適用可能な優れた方法論となっており、学習する価値は高いと言えるでしょう。

2023年8月現在、日本語版と英語版が提供されています。

試験費用は $200 で試験時間は 2 時間、問題数は 50 問です。

Professional Cloud DevOps Engineer の難易度

Professional Cloud DevOps Engineer の難易度は 中〜高程度 だと言えます。

Google Kubernetes Engine (GKE) や Cloud Run、Compute Engine 等、 Google Cloud のサービスに関する専門的な知識を問われるほか、 SRE に関するベストプラクティスを問われるため、ある程度、この試験専門の学習が不可欠です。

公式の要項には「業界経験が 3 年以上（Google Cloud でのソリューションの管理の経験 1 年以上を含む）。」という要件が記載されていますが、必ずしもここまでの経験は必要ありません。 Google Cloud に関する Professional Cloud Architect 程度の知見に加えて、一般的なアプリケーション監視・運用に関する知見がある人にとっては、追加学習を数十時間行えばキャッチアップできるものと考えられます。また IPA の "基本情報処理技術者試験" または "応用情報技術者試験" 程度の一般的なインフラ・アプリに関する知見もあるとベターです。

また、一部に Professional Cloud Developer 試験と重複する知識分野もありますので、こちらの試験を先に学習するのも有効です。

試験対策方法

以下のような方法が望ましいです。あくまで一例であり、各自が予め持っている知識や志向によって異なるものとご了承ください。

Professional Cloud Architect 試験を学習し、合格することで Google Cloud の基本的な知見を得る
オライリー発行の書籍『SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム』を読み SRE の原則を理解する
公式の試験ガイドで試験範囲を理解する
Cloud Monitoring、 Google Kubernetes Engine (GKE)、Cloud Run などよく問われるサービスを学習する
公式の模擬試験を受験し感覚を掴む
当記事の出題傾向を読み足りない知識領域をカバーする学習を行う

2 番はオライリーの SRE に関する有名な書籍です。これにより "SRE", "SLI/SLO", "トイル", "エラーバジェット", "ポストモーテム", "DevOps" といった SRE に関する基本的な考え方を把握することが重要です。これらが直接的に問題で問われることがあります。

また Google 公式で、なんとオンラインでその内容を読むことができます (英語版のみ。書籍の内容と全く一緒かは確認が取れていませんが、重要なポイントが網羅されています)。

参考 : Table of Contents

これに加え Cloud Monitoring や GKE、Cloud Run などのサービスの深い理解が必須と言えます。

特定の会社が提唱する特定の方法論を時間をかけて学ぶ、ということに抵抗がある方もいるかもしれませんが、 SRE についても各サービスについても、丸暗記というよりは、 原理原則を理解すれば答えられる ような問題がほとんどです。またその方法論は、学んだうえで普段の IT 運用に落とし込めるような比較的普遍的なものとも言えます。一度は学んでも損はない内容だと言えるかもしれません。

出題範囲・出題傾向

以下のような分野・サービスが出題範囲となっています。

Site Reliability Engineering (SRE)
Google Kubernetes Engine (GKE)
Cloud Run
Compute Engine
Identity and Access Management (IAM)
オブザーバビリティ
- OpenTelemetry
- Cloud Monitoring / Cloud Logging / Error Reporting
- Cloud Trace / Cloud Profiler
CI/CD
- Cloud Build
- Spinnaker
- Cloud Deploy
コスト管理

特に目立って出題が多い分野は SRE, GKE, Cloud Run, オブザーバビリティです。

当記事のこれ以降の見出しは、各分野での出題内容の傾向について解説しています。勉強方針を決めるために利用したり、受験前の最後の仕上げとしてご利用いただければ幸いです。

Site Reliability Engineering (SRE)

原理・原則

まず前述のように "SRE", "SLI/SLO", "トイル", "エラーバジェット", "ポストモーテム", "DevOps" といった用語を理解することが重要です。

試験問題ではこれらの用語を理解しているか、また SRE の提唱するベストプラクティスを理解しているか、を問われます。

インシデント対応

大規模障害が発生した際の SRE の原則を問われます。これは SRE 本の Chapter 9 - Incident Response に記載があります。

まずインシデント対応の司令塔となる Incident Commander (IC) が任命されます。 IC の最初の仕事は、オペレーションのリーダーである Operations Lead (Ops Lead, OL) と関係者コミュニケーションのリーダーとなる Communications Lead (Comms Lead, CL) を経験あるメンバーの中から選任することです (この3つの役職名は覚えたほうが良いかもしれません) 。

インシデント対応チームには、 IC が適切にタスクを委任したり、メンバー間で効果的にコミュニケーションすることが重視されます。またユーザーや経営陣などステークホルダーへの情報公開も重要な要素の一つです。一人のヒーロー的存在が活躍するのではなく、組織としてインシデント対応が管理されている状態が理想的とされます。

なお MTTD (Mean time to detect) 、 MTTR (Mean time to recover) 、 MTBF (Mean time between failure) といった Google 専門でない一般用語についても、意味はしっかり理解しておく必要があります。

SLI / SLO / Error Budget

Error Budget (エラーバジェット) は消費しすぎても、しなさすぎてもいけないというのが SRE の考え方です。

消費しすぎているということは安定性も問題があるということであり、消費しなさすぎているというのは、リリースのスピードがビジネスニーズに対応しきれていない、もしくは SLO の設定が不適切であるということを意味しています。健全な消費具合にすることが重要であり、そのためには開発がビジネスニーズに追随するか、あるいは SLO を適切に設定しなおすということが必要になってくるでしょう。

また、そもそもの適切な SLO/SLI の設定が大事です。 SLO の制定にはステークホルダーの同意が必須です( Chapter 2 - Implementing SLOs )。

SLI の設定が間違っていれば、それを満たして SLO を達成しても意味がなくなってしまいます。ユーザー体験を適切に反映するような SLI を設定するには、ときにはネットワークなど技術的な考慮が必要になってきます。例えば、サービス自体の利用可能状態に関する SLO を設定したいのに、サーバー側のエラーログの数を SLI として監視してしまうと、サードパーティの CDN の障害や大規模ネットワーク障害を反映することが できません 。クライアントからのリクエストを模したような 外形監視 (Synthetic monitoring) が必要になるでしょう。

ポストモーテム

Postmortem (ポストモーテム) の原則は SRE 本の Chapter 15 - Postmortem Culture: Learning from Failure に記載のとおりです。

Blameless (批判しない) という原則が重要であり Postmortem に「この問題は誰の責任なのか」といったことを書くことは NG です ("Avoid Blame and Keep It Constructive")。

またせっかくの良い Postmortem も知見として共有されなければ意味がありません。組織内で広く共有されるべきである、という点も原則の一つです。

トイルの削減

手動であり、繰り返し行われ、自動化の余地があるもの、 interrupt-driven で reactive であり、価値を生み出さず、しかもサービス成長に応じて線形に増加していくようなタスクは トイル と呼ばれ、 SRE の背景で数多く言及されます。

Google Cloud は API で操作できることが強みであり、これはプログラムによる自動化の可能性を広げるものです。

あえて人が夜中に起きてやらなくてもいいような、単純なインスタンスの再起動・再構築などは、自動化を検討することができます。

オブザーバビリティ

Cloud Monitoring

Cloud Monitoring の基本機能は、ぜひ以下の記事を参照してください。

blog.g-gen.co.jp

Ops Agent による メトリクスやログの収集 、複数のプロジェクトの指標を まとめて可視化 する方法、アラート機能による Slack や SMS 、 Pub/Sub への通知 などは把握しておいてください。

なお上記記事にあるように、複数プロジェクトのメトリクスをまとめてダッシュボード化等する方法としてスコーピングプロジェクト (Scoping Project) という用語がありましたが、これはかつて Cloud Monitoring Workspace と呼ばれていました。試験でもこの名称で出題されることがありますので、お気をつけください。

また、カスタムメトリクスについては、使ったことがない場合は一通りの仕様は抑えておくべきでしょう。値の型 ( BOOL / INT64 / DOUBLE / STRING ) や指標の種類 ( GAUGE / DELTA / CUMULATIVE ) などを問題で問われて面食らうことのないようにしておきましょう。それぞれがどのような場面で使われるかは、公式ドキュメントを確認することで押さえられます。

Cloud Logging

Cloud Logging の基本機能は以下の記事でご確認ください。

blog.g-gen.co.jp

特に Agent でのログ収集 や シンクでの BigQuery や Pub/Sub へのエクスポート 、また ログベースの指標 などは重要です。

細かい所として Cloud Logging のエクスポート設定など設定の書き換えに必要な IAM ロール logging.configWriter などは念のため、確認しておきましょう。

また Google Kubernetes Engine (GKE) のローカルログファイルに出力されるログファイルを、どうやって Cloud Logging にエクスポートするか、なども問われます。 Cloud Operations for GKE のデフォルトのエージェントが収集できます (公式ドキュメント) 。

OpenTelemetry / Cloud Trace / Cloud Profiler

OpenTelemetry / Cloud Trace / Cloud Profiler あたりの用途を理解しておきましょう。

これらの概要は以下の記事の 監視 (オブザーバビリティ) の項にまとめてありますので、参考にしていただければと思います。

参考 : Professional Cloud Developer試験対策マニュアル - 監視 (オブザーバビリティ)

開発手法・CI/CD

構成管理

「ファイルサーバーでずさんなコード管理をしているチームに対して Git の使用を検討させる」といった状況の問題文がいくつか提示されます。 Git の main / ブランチ / プルリクエスト / diff 機能などベーシックな知識があれば答えられる問題です。

もちろん、コードを「ファイルサーバーで管理する」「 Cloud Storage で管理する」「 Google Drive で管理する」などの選択肢は排除することができます。

CI/CD パイプライン

Cloud Build でコンテナイメージをビルドして Spinnaker でデプロイする、といったシチュエーションが多く出題されます。

例えば Cloud Build でコンテナイメージをビルド → Artifact Registry に Push → これを Pub/Sub で検知 (ドキュメント) → Spinnaker のデプロイプロセスをキックといった大きな流れが分かっていれば答えられる問題があります。

比較的新しいフルマネージド CD サービスである Cloud Deploy を用いたデプロイ手法も出題されるので、こちらもチェックしておきましょう。

また Binary Authorization による attestation などの流れも理解しておきましょう。これは Professional Cloud Developer試験対策マニュアルや Professional Cloud Security Engineer試験対策マニュアルなどの記事で紹介している通りです。

ほかに Cloud Build ではビルド完了時等に Pub/Sub 通知ができることから Pub/Sub の Push Subscription を用いて Webhook 通知ができることなどを押さえておきましょう。これによりビルド完了を契機にサードパーティ製品に通知を送り後続処理を実行することができます。

コスト管理

コスト管理はクラウド運用上、重要なテーマです。 確約利用割引 (Commited Use Discounts) や プリエンプティブルインスタンス の基本を押さえておいてください。

確約利用割引については、以下の記事も参考にしてください。

参考 : 確約利用割引(Compute Engine)を解説。AWSとの違いも確認

プリエンプティブルインスタンスは、 Google 側の都合で中断されることがあるため「キューイングされたジョブを次々に処理するワーカー」などの ステートレスで一時的な処理基盤 としての利用が適切です。長時間に渡り保持が必要な「データベース」「Web サイト」などには適しません。

またネットワークコストの低減にはデフォルトである プレミアムティア の代わりに スタンダードティア を使うなどネットワークサービスティアの選択を検討してください。

Google Kubernetes Engine (GKE)

GKE の基本

Google Kubernetes Engine (GKE) の基本概念は把握しておく必要があります。

Pod / ReplicaSet / Deployment など Kubernetes リソースの意味や、 Horizontal Pod Autoscaling / Vertical Pod Autoscaling / Cluster Autoscaling の意味の違いなど、基本的な事項は押さえておきます。

GKE や Kubernetes の基本は、以下の記事で押さえます。

参考 : Kubernetes の基本を解説
参考 : Google Kubernetes Engine（GKE）を徹底解説

デプロイ戦略

Kubernetes におけるアプリケーションのデプロイ戦略に関する問題が多く出題されます。

「サービスへの影響を可能な限り抑えてロールアウトし、問題があれば素早くロールバックする」ために Blue/Green デプロイを採用するなど、デプロイ戦略ごとのメリット / デメリットを把握し、要件に応じて適切なものを選択できるようにしましょう。

セキュリティ

GKE で機密情報を扱う際の方法も重要です。Cloud KMS に関する基本的な事項も押さえておきましょう。以下の記事も参考にしてください。

参考 : Cloud KMSを徹底解説

GKE クラスタ内のワークロードから他の Google Cloud サービスを利用する場合の認証方法についても問われます。

GKE では、Google Cloud APIs の認証には Workload Identity の使用が推奨されています。Kubernetes の ServiceAccount リソースと Google Cloud の IAM サービスアカウントを紐付けることで、クラスタ内のワークロードから IAM サービスアカウントを使用して Google Cloud APIs にアクセスすることができます。