Professional Cloud DevOps Engineer試験対策マニュアル

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

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

Professional Cloud DevOps Engineer

基本的な情報

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 の提唱する方法論について問われるわけですが、その内容は比較的一般的に適用可能な優れた方法論となっており、学習する価値は高いと言えるでしょう。

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

試験費用は $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 試験と重複する知識分野もありますので、こちらの試験を先に学習するのも有効です。

試験対策方法

試験対策の流れ

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

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

「SRE 本」について

書籍『SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム』は、SRE に関する有名な書籍です。この本を読むことで、SRE、SLI/SLO、トイル、エラーバジェット、ポストモーテム、DevOps といった SRE に関する基本的な考え方を把握することができます。これらの用語が、直接的に問題で問われることがあります。

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

ただし、それなりにボリュームがあるので、すべてを読むことができない場合は、重要な用語について記載された章に限って読むことも可能です。どの単語が重要かは、当記事を参考にしてください。

特定の会社が提唱する特定の方法論を学ぶ、ということに抵抗がある方もいるかもしれませんが、 SRE についても Cloud Run などの各サービスについても、丸暗記というよりは、原理原則を理解すれば答えられる問題がほとんどです。

またこれらの方法論を学ぶことで、全部を導入しなくとも、部分的に普段の IT 運用に落とし込めるような比較的普遍的なノウハウも得られます。一度は学んでも損はない内容だと言えるでしょう。

出題範囲・出題傾向

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

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

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

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

Site Reliability Engineering(SRE)

原理・原則

まず前述のように SRESLI/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) という用語があります。意味を理解しておいてください。

また、カスタムメトリクスについては、使ったことがない場合は一通りの仕様は抑えておくべきでしょう。値の型 ( 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 などは念のため、確認しておきましょう。

OpenTelemetry / Cloud Trace / Cloud Profiler

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

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

開発手法・CI/CD

構成管理

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

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

CI/CD パイプライン

Binary Authorization による attestation(コンテナイメージへの署名) などの流れも理解しておきましょう。これは Professional Cloud Developer試験対策マニュアルProfessional Cloud Security Engineer試験対策マニュアル などの記事で紹介している通りです。

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

従来は、開発終了後の試験フェイズにおいて脆弱性診断を行うなど、セキュリティの担保は開発の後工程に行われていました。セキュリティの向上施策を、より開発の前工程に移していく動きをセキュリティのシフトレフトといいます。

コスト管理

コスト管理はクラウド運用上、重要なテーマです。 確約利用割引 (Commited Use Discounts) や スポット VM の基本を押さえておいてください。

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

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

ネットワーク

ネットワークのログ

Google Cloud の VPC で採取できるログとしては「VPC フローログ」「ファイアウォールルールのログ」が代表的です。以下の記事で、それぞれの特徴を確認してください。

これらを使うことで、検査の実装の手間がかかる「パケットミラーリング機能」などを使わなくても、ある程度のパケットの情報と傾向を得ることができます。

Network Connectivity Center

Network Intelligence Center には接続テスト(Connectivity Test)機能があります。Compute Engine や GKE のノード間のネットワーク到達性をテストでき、トラブルシューテイングにも役立ちます。

ネットワークのコスト

ネットワークコストの低減のため、デフォルトであるプレミアムティアの代わりにスタンダードティアを使うなど、適切なネットワークサービスティアを選択できるようにしておきましょう。

Google Kubernetes Engine (GKE)

GKE の基本

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

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

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

スケーリング

最低限、以下のスケーリング手法は理解しておく必要があります。

  • クラスタ自動スケーリング(cluster autoscaling)
  • 水平 Pod 自動スケーリング(horizontal Pod autoscaling)
  • 垂直 Pod 自動スケーリング(vertical Pod autoscaling)
  • 多次元 Pod 自動スケーリング(multidimensional Pod autoscaling)

クラスタ自動スケーリングによって、GKE のノードプールのサイズが自動で変更され、Pod が稼働するノード数が増減します。そのノードに載る Pod は、水平 Pod 自動スケーリングにより数量が増減します。個々の Pod へ割り当てられるリソースは、垂直 Pod 自動スケーリングによって調整されます。水平と垂直の Pod 自動スケーリングを併せて使うのが多次元 Pod 自動スケーリングです。どのような状態でどのスケーリングが使われるべきか、イメージできるようになっておく必要があります。

例えば、問題文で、GKE によるバッチ処理のパフォーマンス改善が求められるシチュエーションが出題されたとします。ノードの CPU 使用率やメモリ使用率が大幅に余っているのであれば、それ以上ノード数を増やしてもパフォーマンス改善は見込めません。Pod 数を増やして一度に処理できるワークロードを増やして方がよいでしょう。

デプロイ戦略

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

GKE に固有のものではありませんが、Blue/Green デプロイ、カナリアリリース、バージョン間のトラフィック移行、などのデプロイ手法は理解をしておきましょう。

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

例えば、Kubernetes において Blue/Green デプロイを行った際に切り戻しを行うには、Service の Selector が Blue(切り替え前)のバージョンを向くように変更することになります。これがマニフェストファイルでどのように表現されるかを確認しておきましょう。

セキュリティ

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

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

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

Helm

深くは問われませんが、Kubernetes のパッケージ マネージャーである Helm が出題される場合があります。

Google Cloud のフルマネージドの成果物レジストリである Artifact Registry では、OCI 形式で Helm のチャートを保存することができ、クローズドな環境下で活用することができます。

Cloud Run

Cloud Run の基本

Cloud Run の基本は、以下の記事で押さえます。

blog.g-gen.co.jp

デプロイと運用

Cloud Run services のリビジョン (バージョン) 管理 に関する問題が多く出題されます。

リビジョン間の トラフィック分割機能 を活用した段階的なロールアウト手法や、タグ付きリビジョン を使用した新しいリビジョンのテストなど、Cloud Run 特有の機能を理解しておきましょう。

Cloud Run から機密情報を利用する

Cloud Run 上のアプリケーションからサードパーティの API にアクセスする際などに、API キーなどの機密情報を利用したいときがあります。このような機密情報は Secret Manager に保存し、Cloud Run の環境変数経由でアクセスすることができます。

杉村 勇馬 (記事一覧)

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

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