実装と運用

可観測性と信頼性の運用

指標は Cloud Monitoring、ログは Cloud Logging、遅延の内訳は Cloud Trace で見ます。アラートは原因ではなくユーザーが受ける影響に付け、SLO とエラーバジェットでリリースの速さと信頼性の釣り合いを決めます。

指標、ログ、遅延の内訳、関数ごとの CPU は、それぞれ別のツールで見ます。そのうえで、ユーザーから見た良し悪しを SLO として数字で決め、SLO を割りそうなときだけ人を呼びます。設問に「アラートが多すぎて対応しきれない」「信頼性と新機能のどちらを優先するかでもめる」とあれば、SLO とエラーバジェットの話です。

4 つのツールは見るものが違う

VM のメモリ使用率とアプリのログは、Ops Agent を入れるまで届かない。遅いサービスを探すなら Trace、遅い関数を探すなら Profiler

Cloud Monitoring はダッシュボードとアラートと稼働時間チェックも受け持ちます。Cloud Trace は 1 つのリクエストがどのサービスで何ミリ秒かかったかを見せます。Cloud Profiler は本番で常時動かす前提の負荷の小さいプロファイラで、「性能への影響を最小にしてボトルネックの関数を特定したい」なら Profiler です。例外をスタックトレースごとに集約する Error Reporting もあります。

「VM のメモリ使用率でアラートを出したいが、指標が見当たらない」の答えは Ops Agent のインストールです。

ログはシンクで行き先を分ける

_Required の 400 日は変えられない。30 日を超えて残す、分析する、外へ流すなら、シンクで送り先を足す

_Required には管理アクティビティの監査ログなどが入ります。_Default の保持期間はプロジェクトで変えられます（保持期間の上限）。組織全体のログを 1 か所に集めるなら、組織かフォルダに集約シンクを作ります。プロジェクトごとのシンクは、新しいプロジェクトで作り忘れます。監査ログの種類はコンプライアンスとデータの所在で扱います。

アラートはユーザーが受ける影響に付ける

CPU 使用率 80% のような原因側の指標にアラートを付けると、ユーザーに影響がないのに夜中に人が起こされます。Google の SRE は、レイテンシ、トラフィック、エラー、飽和度の 4 つ（ゴールデンシグナル）を見て、人を呼ぶのはユーザーへの影響が出ているか出そうなときだけにするよう勧めています。CPU 使用率は調査のときにダッシュボードで見ます。すぐ手を打つべきものはオンコールの電話や PagerDuty へ、数日以内でよいものはチケットへ送ります。全部をメールに送ると、誰も読まなくなります。

SLO とエラーバジェットで、速さと信頼性の釣り合いを決める

SLO は SLA より厳しく置き、SLA を破る前に気付けるようにする。SLO と 100% の差が、失敗してよい量のエラーバジェット

SLI はユーザーから見た良し悪しの指標で、「500 ミリ秒以内に成功したリクエストの割合」のように、良いイベントの数を有効なイベントの数で割って書きます。SLO は SLI の目標値で、「30 日間で 99.9%」のように期間と一緒に決めます。SLA は顧客との契約です。

エラーバジェットは SLO が許す失敗の量です。30 日で 99.9% なら、30 日 × 24 時間 × 60 分 × 0.1% で約 43 分の全停止に当たります。99% なら約 7 時間 12 分、99.95% なら約 22 分、99.99% なら約 4 分です。

バジェットが残っているあいだは新機能を出してよく、使い切ったらセキュリティの修正などを除いてリリースを止め、信頼性の改善に人を回します。この取り決めをエラーバジェットポリシーとして開発と運用が事前に合意し、毎回の議論を数字に置き換えます。SLO を 100% にしないのも同じ理由です。ユーザーの端末やネットワークが先に失敗するので違いに気付かれないのに、リリースが一切できなくなります。

Cloud Monitoring では、SLO のバーンレート（エラーバジェットを消費する速さ）でアラートを出せます。バーンレート 1 は、期間の終わりにちょうど使い切る速さです。SRE ワークブックの Alerting on SLOs は、30 日の SLO で 1 時間にバジェットの 2%（バーンレート 14.4）を使ったら人を呼び、3 日で 10%（バーンレート 1）ならチケットにする組み合わせを勧めています（バーンレートのアラート）。

障害のあとは、責めないポストモーテムを書く

ポストモーテムは、障害の影響、時系列、根本原因、再発防止の作業をまとめた文書です。個人を責めない（blameless）ことが前提で、ミスをできてしまった仕組みのほうを直します。再発防止の作業には担当者と期限を付けます。「同じ障害が繰り返し起きている」とあれば、作業項目が実行されていないことを疑います。

Gemini Cloud Assist の調査（Investigations）機能は、ログ、指標、構成を読んで原因の仮説と次の手順を出します。アラートの発火で調査を始めさせることもできます（Gemini Cloud Assist の概要）。

本番の信頼性は、壊して確かめる

試験ガイドの 6.6 は、負荷試験、カオスエンジニアリング、ペネトレーションテストを挙げています。負荷試験は、セールなどの前に本番と同じ構成で想定のピークを超える負荷をかけ、オートスケールが間に合うかを見ます。カオスエンジニアリングは、VM の停止やゾーンの切り離しを意図的に起こし、設計どおりに切り替わるかを確かめます。フェイルオーバーを一度も試していないマルチゾーン構成は、動く保証がありません。

ペネトレーションテストは、自分のプロジェクトのリソースが対象なら Google への事前連絡は要りません。ただし利用規定に従い、ほかの顧客に影響を与えない範囲で行います（Cloud Security FAQ）。

試してみる

ログを書き、ログベースの指標でエラーの件数を数えます。無料枠に収まる規模です。

for i in 1 2 3; do
  gcloud logging write dojo-test "payment failed: order $i" --severity=ERROR
done
gcloud logging read 'logName:"dojo-test" AND severity=ERROR' --limit=5 \
  --format="value(timestamp,textPayload)"

ERROR の件数を数えるログベースの指標を作ります。

gcloud logging metrics create dojo_payment_errors \
  --description="payment errors" \
  --log-filter='logName:"dojo-test" AND severity=ERROR'

gcloud logging metrics list

Metrics Explorer で logging/user/dojo_payment_errors を選ぶと、指標を作った後のログの件数がグラフになります。これにアラートポリシーを付ければ、エラーの急増で通知できます。

後片付けです。書いたログは _Default の保持期間が過ぎると消えます。

gcloud logging metrics delete dojo_payment_errors --quiet

試験で問われる判断

このカリキュラムで作った例です。

「毎晩数十件のアラートが届き、ほとんどは対応不要だった」なら、ユーザーから見た SLI で SLO を定め、バーンレートのアラートに置き換えます。閾値を上げるだけでは本当の障害も見逃します。

「開発は週に何度もリリースしたいが、運用は障害を理由に止めたい」なら、エラーバジェットポリシーに合意します。リリースを月 1 回に減らす選択肢は、信頼性の基準を決めていません。

「全プロジェクトの監査ログを 7 年間保管したい」なら、組織レベルの集約シンクで Cloud Storage に送り、保持ポリシーを設定します。_Default の保持期間を延ばす選択肢は、プロジェクトごとの設定で組織全体を網羅できません。