こんにちは。クラウドエース株式会社で Google Cloud 認定トレーナーをしている廣瀬隆博です。前回の記事で「絵文字がメロイックサイン（🤘）になっている人」と書きましたが、もちろん ヘヴィメタル が好きだからですね。誰も聞いてこなかったけどアピールしておきます。なお、にわかメタラー なのでお手柔らかにお願いします。

さて、ヘヴィメタルはにわかですが Google Cloud はそれなりに得意としているので、今回は Professional Cloud DevOps Engineer の認定試験範囲について解説いたします。同試験は サービスの信頼性と開発速度の向上を両立する ための考え方を学ぶことができます。受験される方はもちろん、受験はまだ考えていない方にも参考となりますので、最後までお付き合いいただけますと幸いです。

なお、同試験は 2023 年 8 月 21 日に 日本語化 されました。公式サイトではまだ英語のみ受験可能となっていますが、日本語で申し込み可能なことは確認しております。

本記事を読み始める前に

本記事は Professional Cloud DevOps Engineer の認定試験範囲について解説するものであり、システム開発に対してある程度の知識・経験を保有している方に向けた内容となっています。具体的には、Google Cloud における初級の認定試験である Cloud Digital Leader や、中級の認定試験である Associate Cloud Engineer の合格者、もしくは同等の知識・経験をお持ちの方を想定しています。どなたにも理解いただけるように、なるべく平易な表現を心がけておりますが、あらかじめご了承ください。

概要

はじめに、Professional Cloud DevOps Engineer 認定試験について整理しましょう。キーワードは DevOps と Site Reliability Engineering（以下、SRE） ですので、順に説明していきます。

DevOps とは

DevOps とは、Development（開発） と Operations（運用） を組み合わせた言葉で、「デブオプス」と読みます。
開発担当者と運用担当者が密に連携する開発手法であり、前述のようにサービスの信頼性を高めつつ開発速度を向上させる事を目的としています。

SRE とは

SRE は日本語にするとサイト信頼性エンジニアリングであり、Infrastructure as Code（以下、IaC）などの自動化手法を用いて サイトの信頼性を高めること を目的としています。

SRE に関する書籍紹介

SRE について解説する書籍が出版されており、オンラインであればなんと無償で購読することができます。英語のみでの提供ですが、興味がある方は以下の URL にアクセスしてみてください。なお、本記事では紹介にとどめており、内容を未確認でも問題ありません。

https://sre.google/books/

DevOps と SRE の違い

DevOps と SRE、同じような事が書かれていると感じますね。実際にその通りであり、DevOps を実現するためのエンジニアとしての考え方が SRE と思っていただければ試験範囲の理解には問題ありません。現時点ではあまり深く考えず、「DevOps の認定試験は信頼性と開発速度の向上に関するもの」という認識で本記事を読み進めていただければと思います。

SRE の原則

ではなぜ SRE について触れたのでしょうか。それは、初めに覚えていただきたいのが SRE の原則 だからです。DevOps の認定試験ガイドは以下の URL で公開されているのですが、最初のセクションが SRE の原則となっています。

なお、本記事は試験範囲の解説を目的としており、SRE の原則について細かく解説はしておりません。本記事を通じて興味を持たれた方は上記書籍などをご参照いただければと存じます。

サービスレベル

サービスレベルとは、文字通り ユーザーに提供されるサービスを測定して指標化したもの です。これを理解するには、いくつか似たような用語を知る必要があります。試験問題は略語で表記されるのでややこしいですが、是非覚えましょう。

サービスレベル目標

まずはサービスレベル目標、英語では Service Level Objectives（以下、SLO） です。SLO とは、システムの品質に設定された目標です。

サービスレベル指標

次にサービスレベル指標、英語では Service Level Indicators（以下、SLI） です。SLI とは、システムの品質を特定するための指標です。

サービスレベル契約

最後にサービスレベル契約、英語では Service Level Agreements（以下、SLA） です。SLA とは、利用者に保証する SLI の値と、目標に達しなかった場合の対応を説明した契約です。こう書くと非常に分かりづらいので、具体例を以下に記載します。

Cloud Storage における SLA から理解を深める

Cloud Storage の SLA は以下の URL にて定義されています。

https://cloud.google.com/storage/sla

詳細は省きますが、月間稼働率の割合が >= 99.95% と記載されていることに注目しましょう。これは、1か月の間に 99.95% は稼働していることを利用者と契約するものです。つまり、1か月の間に利用者がサービスを利用できる時間が 99.95% を下回ると契約違反となりますね。

では、SLO は SLA と同一でしょうか。サービス提供者の視点から考えると、目標値をわずかでも下回ってしまった場合にすぐ契約違反となる数値を設定するのはリスクではないでしょうか。つまり、SLO は SLA より厳しくすることが一般的です。SLO 違反に罰則はなく、SLA 違反には罰則がある と覚えておきましょう。

SLI については簡単ですね。SLO や SLA が達成されているのか判断するための指標です。稼働率の場合、システムが利用できた時間と利用できなかった時間を測定すれば計算することができます。

なお、稼働率 99.95% の場合は月間で 21.92分 停止するそうです。年間だと 4.38時間 なので、年1回は結構な長時間止まるような印象ですね。実際にそれほど長時間 Cloud Storage が止まった覚えはなく、SLO はもっと厳しい数値になっているんだと考えられますね。

リスクの許容

システムが 100% 稼働し続けるほどの信頼性は現実的ではありません。また、DevOps を実現するためには信頼性だけではなく開発速度の向上も重要であり、開発された新たなコードを反映することでトラブルの元となる場合もあります。そこで、どの程度のリスクを許容するのかを エラーバジェット として定義します。

エラーバジェット

許容するエラーの数量や停止時間をエラーバジェットとして定義します。定義したエラーバジェットを超過した場合、システムへの変更を停止して品質の向上に取り組むことになります。

具体例として、停止時間は 100% - SLO で計算することができます。前述した稼働率 99.95% の場合は月間で 21.92分 停止となり、これを上回る停止が発生した場合はシステム変更を停止することになります。これを自身が管理しているシステムと見比べて見るとどうでしょう？私は結構厳しい値ではないかと感じます。

リスクの受容とは、信頼性と開発速度向上のバランスを具体的に定義するものですので、うまく落としどころを設定してみてください。

自動化

IaC という言葉をよく聞くようになりましたが、SRE といえば自動化と言っても過言ではありません。なぜ自動化が必要なのでしょうか。

品質を高める

まだ IaC という言葉が無かった頃、インフラの構築は手動でコマンドを実行したり、GUI を操作していました。これはコードが書けない人でも対応可能というメリットはあるものの、設定内容を後から把握することが難しいという問題がありました。設定作業を画像やログで記録したり、設定結果を書類化することでなるべく情報を残すのですが、手動ということもあって完全ではありません。一方、IaC という言葉が無かった頃もアプリケーション開発ではこのような問題はありませんでした。開発したコードにアプリケーションの仕組みが書かれているからですね。

そこで、インフラの構築もコード化すれば品質を高めることができる と考えるようになりました。SRE に IaC が重視されるのも、設定内容がコードに載っている状態とすることで品質を高めるためですね。

繰り返し作業をなくす

DevOps の試験ガイドには 心身の疲労を防ぐ と記載されています。一見するとエンジニアリングの要素ではないと感じるのですが、DevOps の実現にはとても必要な要素となります。

インフラの運用には、単純であまり経験にならない作業がつきものです。たとえば、私が以前担当していたシステムでは、アプリケーションのリリースが手動でした。手動でロードバランサーの負荷分散対象からサーバーを切り離し、アプリケーションをリリースしてから組み込むといった作業手順ですね。リリースのたびに日程を調整し、システムの稼働していない時間帯に作業していました。

この作業はエンジニアの技術を磨くことに役立つでしょうか。最初はまだ良いかもしれませんが、慣れてくると 手間はかかるけど得るもののない繰り返し作業 となります。こういった作業を積極的に自動化することで手間を省くことができます。

また、リリース作業自体が本番環境での作業ということもあり、精神的な疲労を伴う作業ですね。これを自動化することで心身の疲労を防ぐことが出来ます。しかも手動ではなくなるので作業ミスを防ぐことができ、品質を高めることに繋がるので良いことづくめですね。

皆さまの業務において「手順書をダブルチェックしながら定期的に実施する運用作業」があれば、是非とも自動化を検討してください。

リリースエンジニアリング

システム開発において、新しい機能のリリースはつきものです。昨今、特に Web で一般公開されており誰でもアクセスできるシステムでは、毎日といっても過言ではない頻度で新しいコードがリリースされています。これを支えるのが リリースエンジニアリング であり、品質を高めつつ開発速度を向上させる DevOps において重要な要素ですね。

デプロイ戦略

DevOps におけるデプロイとは、日本語で「配置する・配備する」といった意味で使用されます。新しい機能を利用できる状態にすることですね。戦略なく新しい機能をリリースしていくと、不具合が発生した際に全利用者へ影響が発生することになります。そこで、不具合発生時の影響をコントロールしつつ、迅速に新しいバージョンをリリースするためにいくつかの戦略が用いられます。

Google Cloud の公式ドキュメントから試験に関する箇所を抜粋してご紹介しますので、詳しく知りたい方は以下の URL をご参照いただければと存じます。

インプレースアップデート
- 特にコントロールせずにアプリケーションをデプロイする
- デプロイ時にシステム停止が発生する
- バージョンを戻す際には旧バージョンの再デプロイとなるため、時間を要する
ローリングアップデート
- アプリケーションを複数のコンピューティングリソースで稼働させ、1つずつデプロイする
- デプロイ作業中は新旧バージョンが混在する
- バージョンを戻す際にはデプロイ済みリソースへのアクセスを抑止して再デプロイする
ブルーグリーンデプロイ
- コンピューティングリソースを2倍用意し、新旧のバージョンを稼働させる
- デプロイ完了後に利用者を新バージョンへ誘導することで瞬時に切り替える
- 新旧バージョンは混在しない
- バージョンを戻す際には旧バージョンへ再誘導するため、瞬時に戻すことができる
- 多くのリソースを使用するため、高コストとなる
カナリアテスト

試験では特に カナリアテスト が出題されるので、他との差異も含めて覚えておきましょう。なぜカナリアなのかは本記事では省略しますが、調べてみると由来もセットで記憶に残るかもしれませんね。

CI/CD

デプロイ戦略が決まったら、次はデプロイの手法ですね。SRE としては、自動化を用いた品質の高い方式を設計する必要があります。継続的インテグレーション と 継続的デリバリー がキーワードですね。

継続的インテグレーション

継続的インテグレーションとは、英語では Continuous Integration（以下、CI） です。複数の異なるものを組み合わせることがインテグレーションであり、ここではシステム開発のことだと思ってください。つまり、継続的にシステムを開発していくことが継続的インテグレーションですね。

継続的デリバリー

継続的デリバリーとは、英語では Continuous Delivery（以下、CD） です。開発したソフトウェアを継続的にデプロイすることであり、特にデプロイを自動化することを表します。

なぜ CI/CD なのか

私の経験として例示した「手動でのリリース作業」では手間も時間もかかるので、開発速度を向上させるには限度があります。また、手動作業のためミスなどが発生する恐れもありますね。そこで、開発したアプリケーションが自動的にデプロイすれば素早く品質も高いと考え出されたのが CI/CD です。DevOps に欠かせない要素ですね。

環境間の設定を揃える

ここまでに説明した要素と重複する部分もありますが、環境間の設定を揃える為にも CI/CD は必要となります。

システムは一般的に本番・検証・開発の3環境で構成されます。それぞれ以下の目的で使用します。

本番環境
- 利用者へサービスを提供する環境
検証環境
- 各種リリースを本番より先に適用して動作を確認する環境
開発環境
- サービスを開発・テストするための環境

これらの環境を手動で維持することも不可能ではないのですが、作業順序を誤ることで設定が異なってしまう可能性があります。CI/CD であれば 環境ごとの設定がコード化されて自動適用されます ので、容易に環境間の設定を揃えることができます。

特に検証環境は本番リリース前の動作確認が目的ですので、本番環境と同じ設定になっていなければなりません。CI/CD を活用して品質の高い環境を構築・維持しましょう。

性能と監視

SRE の原則ではモニタリング、つまり監視について語られることが多くあります。その内容は性能監視も含まれていますので、ここでは両方まとめて取り扱うことにします。

性能

システムが止まらないことはもちろん必要ですが、同じくらい必要なのは 快適な応答速度である ことです。例えシステムが動作していたとしても、操作するたびに長時間待たされると利用者は不満ですよね。そういった観点から、応答が遅延していないことや現在のリソース消費率が上限に近づいていないことといった指標で性能を維持する必要があります。

監視

上記のように快適な応答速度を維持するために、性能に関する指標を監視する必要があります。また、性能だけではなく、システムが安定して提供されるようさまざまな監視が必要です。

ゴールデンシグナル

監視には欠かせない4つの指標が ゴールデンシグナル と呼ばれており、これらはシステム設計の際に盛り込むようにしましょう。

レイテンシー
- リクエストの応答速度であり、ユーザーが快適に使用できている ことを監視する
トラフィック
- システムに対するリクエストの負荷であり、システムの需要の変化 を監視する
エラー
- リクエストの失敗率であり、特に想定外のエラーは監視が必須である
- エラー監視は重要度を定義し、エラーごとのリスクを把握 できるよう設計する
サチュレーション
- システムの使用率であり、どの程度 性能に余力がある か監視する
- 他の要素と組み合わせて今後の予測を立てる際に役立つ

もちろん上記が全てではなく、システムの特性に応じて監視を設計していく必要があります。

インシデント分析

インシデントが発生した場合、事後分析が必要となります。ここで最も重要なのは、責任を追及するのではなく事象を改善するための分析であるということです。誰が悪かったのかを決めるのではなく、何が悪かったのかを突き止める 意識を持ちましょう。

事後分析のステップ

ポストモーテム分析とも表記されますが、事後分析は以下のステップで進めます。

事象の記述
- 何が、いつ、どこで、どのように起きたのか 事実を時系列で整理 する
影響の評価
- どれくらい停止したのか、どれくらいの ユーザーに影響があったのか を評価する
原因の特定
- 技術だけではなく、リリースフローやコミュニケーションなども含めて 根本原因 を特定する
改善案の提案
- 特定した 根本原因に対する改善案 を提案する
効果測定
- 改善案が実施されるまで追跡し、改善案の効果を測定 し、問題の再発を防ぐ

繰り返しになりますが、分析工程で犯人を決めて責めることのないよう注意しましょう。仮に特定の作業者によるミスであったとしても、それを 検知できないフローとなっていたことが問題 であり、そうならないよう工程を改善するといった対策をしていくべきですね。

チーム間のコミュニケーション

冒頭に記載したように、DevOps では開発担当者と運用担当者のコミュニケーションが重要です。コミュニケーション方法を明確とし、定期的にミーティングを設けることで緊密な関係を構築しましょう。

コミュニケーションが取れている場合、お互いの情報が共有されており、相互に理解しあって協力する ことが可能となります。その結果、チームを超えて新しいアイデアが生まれるようになり、お互いにフィードバックを交換することで継続的な改善に繋がります。

試験範囲の解説

さて、ここまでの内容で SRE の概要が理解できたかと思いますので、これを踏まえて試験範囲を解説していきます。なお、これまでの解説で説明済みの要素もありますので、対象項目に偏りはありますがご了承ください。

Google Kubernetes Engine

Google Kubernetes Engine（以下、GKE）とは、コンテナを稼働させるためのプロダクトです。

コンテナについて少しだけ説明すると、仮想マシンがサーバー機器を仮想化するのに対して、コンテナでは OS を仮想化 します。仮想マシンより軽量であり、OS のセットアップが不要であることから、最近のアプリケーションでは採用されることが増えてきています。コンテナに関する詳細は Google Cloud の公式サイトにも記載がありますので、もしよろしければご参照ください。

コンテナは IaC とも相性が良く、DevOps を実現するために採用されることが多くなっています。そのコンテナを実行するための環境として GKE があり、DevOps の試験では割とよく登場することので、DevOps に関する項目は押さえておきましょう。

基本的な用語

GKE について記載し始めるとブログどころか本が一冊書けてしまうので、試験解説としては最低限にとどめたいと思います。しかし、ある程度の用語は知っておく必要がありますので、以下に解説します。

クラスタ
- GKE の 最も大きな管理単位 であり、下記のコントロールプレーンとノードで構成される
コントロールプレーン
- マスターノードとも呼ばれる、GKE 全体を管理する機能
ノード
- コンテナが動作するリソース であり、実態は仮想マシン
ノードプール
- 同じ設定のノードをグループ化したもの
Pod
- コンテナをグループ化したものであり、GKE では最小のデプロイ単位 となる
Replica Set
- Podの複製を保持する数量 であり、3 に設定すれば同じ Pod が 3 つ動作している状態を維持する
Deployment
- Pod を管理するものであり、Replica Set などを定義する
  - Google Cloud の公式ドキュメントに Deployment マニフェストファイル例が掲載されている

Google Cloud の公式ドキュメントにはアーキテクチャの解説がありますので、より深く知りたい方はご参照ください。

オートスケール

DevOps には信頼性が求められており、性能低下を避けるために リソースの自動拡張 は有効な対策です。弊社が別途 GKE の自動スケーリングに関する記事を公開しておりますので、詳細はそちらをご参照ください。

限定公開クラスタ

プライベートクラスタとも表記される限定公開クラスタですが、一言でいうと パブリック IP アドレスを持たないクラスタ です。既定値でクラスタを作成するとノードに外部へ直接アクセス可能なパブリック IP アドレスが付与されるので、これを避けてセキュアな構成とする目的で限定公開クラスタが選択されます。

具体的なアーキテクチャを記載するとかなりの量になってしまうので割愛しますが、Google Cloud の公式ドキュメントを参照しながら一度限定公開クラスタを作成してみると理解が深まって良いでしょう。

CI/CD パイプラインの設計・実装

パイプラインとは、データが入力されて結果が出力されるまでの一覧の流れを表します。CI/CD パイプラインの場合、ソースコードをデプロイするまでの処理 ですね。CI/CD パイプライン周りでは、プロダクトの選定やパイプラインの保護、認証情報の取り扱いなどが問われます。

コード管理

コードを管理するにはバージョン管理システムを用いることがほとんどであり、最近は Git がよく使われます。Google Cloud のプロダクトでは Cloud Source Repositories が該当します。他には GitHub も知っておいて損はないですね。

https://github.com/

ビルド・テスト・デプロイ

コンテナイメージやプログラム等をビルドしたり、ビルドされた成果物をデプロイ・テストする環境が必要となります。これは Cloud Build が適しています。ビルド以外にも IaC の実行環境としても採用される、CI/CD の主要なプロダクトです。

https://cloud.google.com/build?hl=ja

Artifact Registry

Artifact Registory とは、コンテナやプログラムなど、ビルドした結果の成果物を格納するプロダクト です。CI/CD パイプラインでは、Cloud Build の結果を格納するために用いられます。

Terraform

Google Cloud のプロダクトではありませんが、Terraform は Google Cloud 環境を IaC で構築・管理する際によく採用されます。 Google Cloud の公式ドキュメントでも Terraform での記述例を掲載していることが多く、覚えておくべきソフトウェアですね。他にも VMware や Kubernetes なども対応しており、クラウドだけではなくオンプレミスにおいても活用することができます。

認証情報管理

CI/CD において、さまざまな認証情報を取り扱うことがあります。たとえばデータベースの接続パスワードですが、これを CI/CD のプログラムに直接記入したり、コンテナ内のテキストファイルに記述することは望ましくありません。適切なプロダクトに格納し、必要になったタイミングで随時参照するようにしましょう。

Secret Manager

機密データを管理するためのプロダクトが Secret Manager であり、APIキー、パスワード、証明書などを保存して適宜アクセスすることができます。Google Cloud のさまざまなプロダクトで 認証情報を共有 することができます。

Cloud Key Management

Cloud Key Management Service（以下、KMS）の頭文字から KMS と表記されることの多いサービスですが、現在の公式サイトでは末尾の Service が記載されていないようです。どちらにせよ役割は変わらず、暗号鍵の作成、アクセスを管理するプロダクトです。

暗号鍵に関して説明を始めると単独でブログを書けるくらいの文章量になってしまうので詳細は割愛しますが、データを暗号化したり復号するためのものです。

Secrets

GKE において認証情報を取り扱う機能です。GKE で稼働するアプリケーション間で共有することができるので、GKE に閉じた範囲内で認証情報を取り扱う 際に使用します。

認証情報格納場所設計のポイント

各プロダクト、機能は排他ではありません。取り扱う認証情報や使用範囲によって選択したり、組み合わせて使用することもできます。

たとえば、Secret Manager 自体の暗号化に KMS を使用することができます。これは、Secret Manager が保持するデータの暗号鍵の管理には KMS が適切だからですね。

パイプラインの保護

CI/CD パイプラインは適切に保護する必要があります。もし 脆弱性のあるコンテナ がデプロイされてしまった場合はどうなるでしょうか。攻撃者にとって格好の標的となり、コンテンツの改ざんや不正アクセスといった被害を被ってしまうことになります。そのような自体を避けるために、さまざまな手法でパイプラインを保護します。

脆弱性スキャナ

Artifact Registory には脆弱性スキャン機能が搭載されています。コンテナの脆弱性をスキャンすることができる ので、CI/CD パイプラインに組み込むことで安全なコンテナのデプロイを助けます。

Binary Authorization

Binary Authorization とは、コンテナに署名する機能です。CI/CD パイプラインに組み込むことで、パイプラインを通さず作成されたコンテナはデプロイできないように制御する ことができます。

CI/CD 関連ミドルウェア

CI/CD パイプラインでは、Google Cloud のプロダクト以外にも著名なソフトウェアが用いられます。

Jenkins

Jenkins とは、オープンソースの CI ソフトウェア です。ビルドとテストの自動化に強く、マルチプラットフォームに対応しているため、要件によっては Cloud Build ではなく Jenkins を採用する場合もあります。

https://www.jenkins.io/

Spinnaker

Spinnaker とは、オープンソースの CD ソフトウェア です。デプロイの自動化に強く、前述のデプロイ戦略を実現することができます。Jenkins と組み合わせて CI/CD パイプラインの構築に用いられます。

https://spinnaker.io/

監視プロダクト

SRE の原則にも記載した監視ですが、ここでは具体的なプロダクトについて解説していきます。なお、ログ監視については別項目にまとめてあります。

メトリクス監視

Cloud Monitoring では、さまざまな 指標を監視 することができます。例えばトラフィックの量やシステムの利用率など、数値に対してしきい値を設定することで超過時にアラートを送ることもできます。Google Cloud 監視の必須プロダクトですので、是非覚えましょう。

なお、指標の英語表記である metric を複数形したものが metrics であり、メトリクス監視と記載されている場合は指標の監視のことですね。

アプリケーション監視

開発したアプリケーションを監視するためのプロダクトがいくつか提供されています。どれも コードに処理を追加する必要のあるもの ですが、Google Cloud の基盤だけでは判断できない情報が取得できますので、要件に応じて使用しましょう。

Error Reporting

Error Reporting では、アプリケーションエラーを管理 し、アラートを通知することができます。Python における処理の追加例が公式ドキュメントに掲載されていますので、イメージを掴むためにも是非確認してみてください。以降で紹介するプロダクトにおいても、おおよそ似たような形となります。

Cloud Trace

アプリケーションの パフォーマンスを管理・分析 する際には Cloud Trace を使用します。

https://cloud.google.com/trace?hl=ja

Cloud Profiler

アプリケーションが使用している CPU やメモリの使用率を管理・分析 する際には Cloud Profiler を使用します。

監視関連ミドルウェア

ここまでは Google Cloud のプロダクトを用いた監視について記載してきました。しかし、CI/CD と同様に、監視についても著名なソフトウェアを用いることがあります。Google Cloud のマネージドなサービスより複雑な要件がある場合は選択することになります。

Prometheus

Prometheus とは、Cloud Monitoring のように メトリクス監視 を実現するためのソフトウェアです。

https://prometheus.io/

Grafana

Grafana とは、ログやデータを可視化 するためのソフトウェアです。データソースとして Prometheus を使用することができるので、両者を組み合わせて監視ダッシュボードを構築することができます。

https://grafana.com/

OpenTelemetry

OpenTelemetry とは、Cloud Trace のように アプリケーションのパフォーマンスを管理・分析 するために使用します。Cloud Trace トレーシング、Cloud Monitoring はメトリクス監視をそれぞれ担当して連携しますが、OpenTelemetry は単独でトレーシングと収集を両方担当することができます。

https://opentelemetry.io/

ログ管理・監視

Cloud Logging によって ログを管理・監視 することが可能です。Google Cloud で稼働するプロダクトやコンピューティングリソース、アプリケーションなどはもちろんのこと、AWS など他のクラウドについても公式に対応 しています。

https://cloud.google.com/logging?hl=ja

仮想マシンログ

仮想マシンが出力するログは、Ops エージェント によって収集されます。Cloud Logging への書き込み権限や Firewall の通信が許可されていない場合はログが収集されないことに注意しましょう。詳しくは公式ドキュメントにトラブルシューティングが掲載されています。

GKE ログ

GKE についても仮想マシンと同じくエージェントを導入してのロギングですが、GKE 専用のエージェント が導入されます。その際にデフォルトで収集されるログ、設定することで取得できるログがそれぞれ存在しますので、公式ドキュメントを確認しておきましょう。

VPC フローログ

VPC フローログとは、トラフィックのサンプルを記録 するものです。送信元、送信先、時刻、パケットサイズなどは記録されますが、パケット自体が記録されるわけではありません。また、保存する情報の割合が指定できるため、通信量が多すぎてログの保管料金が増大する場合は半分だけ記録するといったことが可能です。

では、取得したログはどのように活用するのでしょうか。以下に例示します。

トラフィックの特徴を分析
- Google Cloud に入ってくる通信が多いのか、出ていく通信が多いのか
- どの時間帯に通信が多いのか
- どれくらいの量を通信しているのか
今後のトラフィック予測
- 時系列にトラフィック量を整理することで予測を立てる
セキュリティの分析
- 通信の許可・拒否が記録されている
- 不正なトラフィックやセキュリティの脅威が含まれていないか

これらの例を参考にしていただくと特徴が見えてくるのですが、1つ1つのログを解析する用途ではあまり使用しません。多くのデータを分析することで傾向を見出す 目的のため、前述のように保存する割合を指定することができます。ログ量が非常に多い場合、総数が半分になっても傾向は現れるためですね。

なお、分析には BigQuery や Looker Studio などが用いられます。他にも、正規化されたデータを分析するツールであれば問題ありませんので、知見をお持ちのツールで分析してみてください。

ログシンク

ログシンクとは、指定した宛先にログを転送 するものです。たとえば、古いログを Cloud Storage の安価なクラスに転送してから長期保管することで費用を削減する設計が可能となります。

ログベースの指標

ログの内容から指標を取得することができます。たとえば、ERROR を含むカウント型のログベースの指標を作成した場合、条件に合致するログがカウントされるようになります。これを用いることで利用者へのアラートを作成します。例えば、ERROR を含むログが1件以上発生した場合は管理者へアラートを通知するような使い方ですね。

少しわかりにくい名前ですが、ログから指標を作成するのがログベース指標であり、Cloud Monitoring はログベース指標を元にアラートするといった分担になっています。

インシデント管理

監視システムから重要なアラートが通知された場合、インシデント対応が始まります。ここでは、SRE の原則より具体的なインシデント管理のポイントをお伝えします。

影響を把握する

インシデントが発生した場合、まずは影響を把握 しましょう。特に利用者への影響ですね。

体制を組む

利用者への影響が大きなインシデントであった場合、チームで対応にあたります。各担当者の役割は以下の通りです。

インシデントコマンダー

インシデントコマンダーとは インシデント対応の責任者 であり、対応計画を立案してチームを編成します。チームを率いて問題解決を主導し、技術的な判断も必要な事から、技術力のあるプロジェクトリーダーが適任 です。責任者ということでマネージャーから選出したくなりますが、適切ではありませんのでご注意ください。

なお、インシデントコマンダーは経験者から選出するべきです。今後インシデントコマンダーを担って欲しい人材は、一度インシデントコマンダーの振る舞いを学ぶ目的でインシデント対応チームに参加しておくべきですね。学習が目的ですので、役割は与えないように配慮しましょう。

オペレーションリード

インシデント対応における 技術面でのリード役 がオペレーションリードです。インシデントコマンダーは技術的な判断をしますが、対応方針を立案したりシステムを操作するのがオペレーションリードの役割です。色んな人がインシデント発生中のシステムを操作すると更にトラブルを生みかねないので、誰が操作するか決めておくべきですね。

コミュニケーションリード

インシデントにおけるコミュニケーションを管理 する役割がコミュニケーションリードです。チーム外とのコミュニケーションを引き受けることで、チームがインシデント対応に専念できるようにします。システムの利用者や社内外のステークホルダーなど、相手に応じた適切な情報発信が求められます。マネージャーはインシデントコマンダーではなく、コミュニケーションリードに選出するのが適切ですね。

サービスの復元を優先する

まずは利用者への影響を抑えるために サービスの復元を優先 しましょう。事後分析に備えて情報を収集したくなる気持ちもありますが、何よりも利用者への影響を低減・解消させることを優先させるべきです。

インシデント管理手順を事前に文章化する

インシデント管理手順とは、インシデント発生からサービスを復元するまでの手順だけではありません。

インシデントの内容に応じてオペレーションリードを選出するチームも変わりますし、コミュニケーションルールも事前に決めておくことができますね。インシデント対応の後は事後分析があるので適切な記録を取る必要がありますし、事後分析の終了を判断するタイミングも定義しておきたいところです。

とはいえ、プロジェクトや会社によって求められるものは異なります。過去のインシデント対応を思い出し、SRE の原則を適用し、ここまでに記載した内容を踏まえてインシデント管理手順を作成しましょう。

コスト管理

最後は世知辛いお金のお話です。多くのシステムはビジネスのために作成されますが、予算や収益の観点から無制限にお金をかけられることはほとんどありません。そこで、さまざまな条件を満たすことで Google Cloud の利用料を削減 する方法をご紹介します。

プリエンプティブル VM と Spot VM

プリエンプティブル VM と Spot VM、どちらも仮想マシンに条件を付けることで 料金を半額以下に押さえることができる方法 です。条件とは、Google Cloud のリソースひっ迫など、Google が必要だと判断したタイミングで仮想マシン が停止されることです。

勝手に止められるなんて使い物にならないと思いますよね。ところが、使いどころによってはとても有益なんです。例えば、個人的に使っている作業用仮想マシンはどうでしょう。不意に停止される懸念はあっても、金額は半額以下になるのであれば一考の余地はあるのではないでしょうか。

私の場合、社内で技術検証をする場合に設定しています。長時間稼働させるものではないですし、もし停止されてもちょっとやり直せば良いだけで半額以下なので、とてもありがたいですね。その分スペックを倍にして短時間で終えるようにするといった工夫もできるので、皆さんも 突然停止しても困らない用途 があれば導入を検討してみてください。

なお、プリエンプティブル VM はサポートが終了したもので、現在は Spot VM が最新です。それぞれ特徴はありますが、DevOps の試験という観点ではどちらも「突然の停止を許容する代わりに仮想マシンの費用を半額以下にできる」という点を覚えておきましょう。興味のある方は公式ドキュメントを参照してみてください。

確約利用割引

確約利用割引とは、1 年または 3 年の契約期間に利用し続けることを条件に料金が割引される 制度です。最近流行りのサブスクリプション方式でのサービスにも多い仕組みですが、毎月課金より1年分まとめて課金したほうが安くなるというものですね。全てのプロダクトで使用できるわけではありませんので、詳細は公式ドキュメントをご参照ください。

継続利用割引

確約利用割引と勘違いしやすい継続利用割引ですが、対応しているプロダクトを使用し続けた際に適用 されます。いっぱい使ってくれるから割引してあげる、といったお得意様割引みたいな感じですね。

例えば Compute Engine であれば、「請求月の 25% を超えて使用され、他の割引が適用されていないリソースに対して継続利用割引（SUD）が適用されます。」とのことです。要点としては 他の割引が適用されていないリソース ですね。試験で引っかからないように注意しましょう。

Cloud Storage ストレージクラス

Cloud Storage における ストレージクラス とは、データの利用頻度に応じて利用料金の削減が可能な機能です。最近はある程度自動的に最適なクラスを適用してくれる Autoclass という便利な機能も追加されましたが、試験という観点では各クラスの特徴を理解しておきましょう。ポイントは 利用頻度 ですが、詳細は公式ドキュメントをご参照ください。

Standard
- 頻繁にアクセスする
Nearline
- 30 日に1回程度の頻度でアクセスする
Coldline
- 90 日に1回程度の頻度でアクセスする
Archive
- 365 日に1回程度の頻度でアクセスする

おわりに

Professional Cloud DevOps Engineer 認定試験ガイドから私の主観でまとめた本記事は以上となります。他の Google Cloud 認定試験とは異なり、IT 技術ではない要素が比較的多い と感じる内容になっていました。SRE の原則から始まり、インシデント発生時の振る舞いなど、エンジニアのみならずシステムに携わる方には知ってもらいたい内容だと思っています。ここまで読んでくださった方は是非とも周りの皆様に本記事をご紹介いただき、多くの方に読んでいただけますと幸いです。

それでは、また次の記事でお会いしましょう🤘

Discussion