はじめに

先日Google Cloud Professional Cloud DevOps Engineerを更新(再度受験)しましたので、勉強方法や傾向などを記載します

概要

試験時間・問題数は多くのGoogle Cloud Professional資格と同様に120分・50~60問です
受験料は$200です
前回この資格を取得した2年前は英語のみでしたが日本語でも受験可能となっています
GKE(kubernets)やCloud Monitoring(監視関連)とSREの基礎知識が主に問われる資格となっています
詳細な出題範囲は以下参照

おさえておきたいポイント

SREのプラクティスに関するもの

以下に出てくるユースケースをおさえておくとよい

量が多いので時間がなければインシデント系だけでも理解しておくといい

インシデント識者(Incident Commander:IC)/オペレーションリード(Operation Lead:OL)/コミュニケーションリード(Communication Lead:CL)の役割など

ポイント

ポストモーテム(事後分析)

ポストモーテムにはいかが含まれている必要があり、できるだけ広く共有することが大事
- 重大度
- 根本原因
- 解決策
- 今後、同様なインシデント発生を防ぐ対策
- 教訓(インシデントによる学び)
- 優先順位を付けたアクション項目
個人の責任ではなくインシデントの原因に重点を置く
上位層にも参加してもらう
いいポストモーテムを書くことが評価されるようにする(書くことをためらう文化をつくらない)
次に同じインシデントを発生させないためにとる対策を記載する
- 例：ソフトウェアの変更によってエラーが発生したケースであれば同様のエラーをキャッチできるかをテストする
ポストモーテムの作成をするシーン
- インシデントによってデータが失われたり、リリースに失敗した場合などユーザに影響を与えた場合
- 上記ではない場合に上席や関係者に要求された場合やユーザ影響がなく想定通りに回復した場合(2つあるマシンの1つがダウンして戻ったなど)は事後分析不要
  - 想定通りに再起動する場合はアラートを停止することによってSREの燃え尽き症候群を防ぐことができる
アクションアイテム
- 種類・オーナー・バグを記載する
- 1人のオーナーと必要に応じて共同作業者を割り当てる

SLI/SLO/SLA/エラーバジェット関連

まずは上記を参考にSLI/SLO/SLA/エラーバジェットの意味を理解する
- 例：SLIはサービスの動作を測定し成功した頻度を示すため、該当業務のすべてのリスエストに対する成功応答の割合
SLOの運用
- SLOを過剰に満たしている(エラーバジェットに余裕がある)場合は以下の対応をするといい
  - リリースを頻繁にリスクを取ったものにすることができる
  - 計画的にダウンタイムを発生させ、エラーバジェットを消費させることもできる
  - 上記を実施することでユーザが暗黙的に高いSLOを期待することを減らせる
  - SREが複数のサービスを担当している場合は他のサービスに割り当てる時間を増やすことも可能
- ビジネスニーズがないのにエラーバジェットに余裕があるからと言ってSLOを高く再設定してしまうこと過剰品質となってしまうため望ましくない
  - 投資対効果の目安の計算方法
    - 収益10億円のアプリのSLAを99.9%→99.99%にした場合
      - 0.09%の可用性工場であるため1000万円✕0.09%で90万円の増益が期待できるため90万円以内の投資でSLAを向上できるのであれば投資価値がある
エラーバジェット
- エラーバジェットを監視しアラートを出すためには select_slo_burn_rate を用いる
  - 参考：https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring/api/create-policy-api?hl=ja
- エラーバジェットが枯渇した場合はリリースの凍結もしくはUX(ユーザ体験)の悪化を許容する
トイル
- 反復的なタスクを自動化することで、トイルを特定、測定、排除することで運用コストを最小限に抑えながら、技術的負債を削減するSREのプラクティスの1つ

Cloud Monirotingで実装する方法
- ウィンドウベースとリクエストベースのSLOの違いを理解しておく

リリース・CI/CDに関するもの

用語と使い道を覚える
- Blue/Green
  - 稼働中の本番と同じものを用意し、リリース完了時に本番の向き先を切り替える
  - 作業の複雑さを取り除くことができることと即座にロールバックが可能であり停止時間を減らせることが特徴
- カナリア
  - 一部ユーザに対して新機能にリスエストを流し様子を見ながら徐々に割合を増やしていく
  - 影響を与えるユーザを少なくすることができる
- A/Bテスト
  - 画面等のレイアウトや機能を同時にリリースし、ユーザによって表示を切り替える方法
  - コンバージョン等の結果を利用してどちらの機能がいいのかをテストする手法
- スモークテスト
  - 品質保証の初期段階に行われるテストでありシステムへの影響を判断するために使う
Google CloudのCI/CD
- 以下のリンク先を参照しつつ、単体テスト・統合テスト・受け入れテストなどのタイミングを含めて使うサービスを一連の流れで理解しておくといいでしょう

Cloud Buildで利用できるもの
- https://cloud.google.com/build/docs/develop?hl=ja
- Java/Python/Go/Packerを利用したビルドができる
- アーティファクトはArtifact RegistryとCloudStorage(GCS)に配置できる
  - Artifact Registryが推奨(利点：コンテナの脆弱性診断ができる・BinaryAuthorizationが利用できる・GKEのイメージストリーミングが使えるなど)
  - Artifact RegistryはDockerイメージ他にOCI形式のHelmチャートやJava/Node.js/Pythonのライブラリ管理、Goのモジュール管理ができる
- GKE/CloudRunのデプロイにはCloudDeployが利用できることもあわせて覚えておきましょう
- Cloud BuildをVPCServiceControlsの境界内で使用したい場合やトラフィックをVPC内にとどめたい(APIアクセス等をパブリックにしたくない)要件がある場合はプライベートプールを利用する
Terraform
- terraformを利用して環境を構築するケースの問題も出てきます
- terraformの基本的な使い方を確認しておくといいです
  - 複数人やCI/CDで利用する際はGCSにtfstateを配置するようにバックエンド構成をするなど

GitOps
- 概要を理解しておく

GKE/Kubernetesに関するもの

Anthosについて
- Anthosとはハイブリッド・マルチクラウド環境に対応したアプリケーション管理プラットフォームのこと
- 詳細：https://cloud.google.com/anthos/docs/concepts/overview?hl=ja
  - Anthos GKE on-prem/ on AWS
    - AnthosをオンプレミスやAWSで稼働させることのできる機能
  - Anthos Config Management
    - Policy Controllerを利用し、Kubernetesクラスタのポリシー管理を行うことができる
    - Config Syncを用いることでGitと連動させてポリシーの適用ができる
  - Anthos Service Mesh
    - サービスメッシュを実現することができるマネージドされたistio
    - カナリアリリース・トラフィック分割が利用できる
スケーリングに関して
- GKEのスケーリングはpodとノードをスケーリングする方法がある(詳細は以下リンクを参照)
  - podのスケーリングのHPA(水平Pod自動スケーリング)とVPA(垂直Pod自動スケーリング)を併用するとMPA(多次元Pod自動スケーリング)になる
  - それぞれのスケーリングにはCloud Monitoringのカスタム指標や外部指標を利用することができる
  - 現状VPAはJVMでは利用できない

セキュリティ
- セキュリティの試験ほど詳しくは出ないですが特に以下の用語と目的は理解しておきましょう
- 特にBinary Authorization

kubernetes manifestについて
- (使い慣れていない場合は)基本的な構文やdeployment/service/ingressなどがどのように定義されるか確認しておくといい
権限関連
- kubernetes上のpodに対してGoogle Cloudリソースへのアクセス権限を付与する際にはWorkload Identity を使用して、Googleサービスアカウントとして認証する

Prometheusを利用したい場合はGoogle Cloud Managed Service for Prometheusを利用すると運用コストを減らしつつPromQL(Prometheusのクエリ)

Cloud Runに関するもの

基本的な機能を抑えつつ、特に以下のトラフィック管理関連は読み込んでおくといい
- 新しいリビイジョンへの移行やトラフィック分割方法
- CLIで実行する場合に指定する必要のあるパラメータ

試験問題にはしばらく出てこないと思いますが新機能
も発表されています

オブザーバビリティに関するもの

OpsAgent

ログにはFluentBitを使用し、メトリクスとトレースにはOpentelemetry collectorを利用する
- ロギングレシーバー・指標レシーバー・OpenTelemetryレシーバーなどの使いどころ

インストール方法
- https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent/install-index?hl=ja
- OSポリシー：VMにエージェントがインストールされているかチェックし、インストールされていない場合は最新バージョンがインストールされる。バージョンの自動更新はしない
- エージェントポリシー：指定した条件に一致するVM全体でエージェントの自動インストールと自動アップグレードを実行することができる(CLIで実行)
アプリケーション解析
- Cloud Monitoring
  - アプリケーションやコンテナのCPU使用率などのメトリクスを確認することができる
- Open TelemetryやCloud Trace
  - 複雑なマイクロサービスアーキテクチャでのリクエスト処理の方法や調査ログの特定に役立つ

* 指標スコープ
    * Cloud Monitoringではスコープを指定することで該当プロジェクトないだけではなくフォルダ単位でグラフ化するなどのことができます

Profiler
- コード内の遅い箇所を特定するためにアプリケーションを継続的に監視するために利用する
- パフォーマンスへの影響と管理オーバーヘッドが小さい

ログ
- ログシンク・集約シンク
  - 以下ドキュメントで基本的な機能を理解する
    - 集約シンクを用いることでフォルダ・組織単位でまとめて宛先にログを転送できる

勉強方法

試験ガイドを確認する

上記「確認しておくべきサービス・機能」で紹介したドキュメントを中心に試験ガイドの範囲のドキュメントを確認する
模擬試験を解く

試験範囲で苦手なところをドキュメント等で確認しつつ、必要に応じてUdemy等の問題を解いてみる

おわりに

GoogleCloud試験全体に該当しますが試験問題および選択肢は比較的短文(問題文：3行程度、選択肢1行)の問題が多いため、時間が足りなくなるということはない印象です
SREに関する知識を確認するためにも良い試験だと思いました