1. はじめに
最終更新日: 2023 年 7 月 28 日
Google Cloud オペレーション スイートとは
Google Cloud オペレーション スイートは、Google Cloud 環境上のアプリケーションのパフォーマンスをモニタリングしてトラブルシューティングを行い、パフォーマンスを向上させるためのプラットフォームです。Cloud オペレーション スイートの主な柱には、Cloud Monitoring、Cloud Logging、Cloud Tracing があります。
Google Cloud Operations の概要については、こちらの動画をご覧ください。
作成するアプリの概要
この Codelab では、Google Cloud にサンプル API をデプロイします。次に、API を介して Cloud Monitoring の複数の機能を確認して構成します。
学習内容
- Google Cloud の Cloud Shell を使用して、サンプル アプリケーションを Cloud Run にデプロイします。
- ダッシュボード、アラート、稼働時間チェック、SLI/SLO モニタリングなどの Google Cloud Monitoring 機能の使用。
必要なもの
- Chrome の最新バージョン（74 以降）
- Google Cloud アカウントと Google Cloud プロジェクト
2. 設定と要件
セルフペース型の環境設定
Google アカウント（Gmail または Google Apps）をお持ちでない場合は、1 つ作成する必要があります。Google Cloud Platform のコンソール（console.cloud.google.com）にログインし、新しいプロジェクトを作成します。
- プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。この設定はいつでも変更できます。
- プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が気に入らない場合は、別のランダムな ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。
- なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
注意: プロジェクト ID はグローバルに一意である必要があります。また、ご自身が選択したプロジェクト ID を他のユーザーが使用することはできません。その ID を使用するのはご自身のみです。プロジェクトを削除しても、その ID を再使用することはできません。
- 次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクト全体を削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Google Cloud Shell の設定
Google Cloud と Google Cloud Trace はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。
Cloud Console から Cloud Shell を有効にするには、[Cloud Shell をアクティブにする] をクリックします（環境のプロビジョニングと接続に若干時間を要します）。
Cloud Shell を初めて起動した場合は、その内容を説明する画面が（スクロールしなければ見えない位置に）表示されます。その場合は、[続行] をクリックしてください（以後表示されなくなります）。この中間画面は次のようになります。
すぐにプロビジョニングが実行され、Cloud Shell に接続されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。仮想マシンは Google Cloud で稼働し、永続的なホーム ディレクトリが 5 GB 用意されているため、ネットワークのパフォーマンスと認証が大幅に向上しています。このコードラボでの作業のほとんどは、ブラウザまたは Chromebook から実行できます。
Cloud Shell に接続すると、すでに認証は完了しており、プロジェクトに各自のプロジェクト ID が設定されていることがわかります。
Cloud Shell で次のコマンドを実行して、認証されたことを確認します。
Cloud Shell に接続すると、すでに認証は完了しており、プロジェクトに各自の PROJECT_ID が設定されていることがわかります。
gcloud auth list
コマンド出力
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
コマンド出力
[core] project = <PROJECT_ID>
なんらかの理由でプロジェクトが設定されていない場合は、次のコマンドを実行します。
gcloud config set project <PROJECT_ID>
Cloud Shell では、デフォルトで環境変数もいくつか設定されます。これらの変数は、以降のコマンドを実行する際に有用なものです。
echo $GOOGLE_CLOUD_PROJECT
コマンド出力
<PROJECT_ID>
サンプル アプリケーション
このプロジェクトで必要となるすべてのものは Git リポジトリに用意されています。このリポジトリにはいくつかのサンプル アプリケーションが含まれており、この演習ではそのいずれかを使用できます。
Git リポジトリのリンク: https://github.com/rominirani/cloud-code-sample-repository
3. API アプリケーションをデプロイする
サンプル アプリケーションまたは API の概要
このアプリケーションは、在庫アイテムのリストと特定のアイテムの在庫数を取得する 2 つのオペレーションで REST API エンドポイントを公開するシンプルな Inventory API アプリケーションです。
API をデプロイし、https://<somehost> でホストされていると仮定すると、API エンドポイントに次のようにアクセスできます。
- https://<somehost>/inventory
これにより、在庫レベルがわかるすべての商品アイテムが一覧表示されます。
- https://<somehost>/inventory/{productid}
これにより、その商品の productid と手持ち在庫レベルを含む単一のレコードが提供されます。
返されるレスポンス データは JSON 形式です。
サンプルデータと API リクエスト/レスポンス
簡単にするため、このアプリはバックエンドのデータベースで動作していません。これには、3 つの商品 ID のサンプルと、その在庫レベルが含まれています。
商品 ID | On-Hand Inventory Level（手元在庫レベル） |
I-1 | 10 |
I-2 | 20 |
I-3 | 30 |
API リクエストとレスポンスの例を以下に示します。
API リクエスト | API レスポンス |
https://<somehost>/inventory | [ { "I-1": 10, "I-2": 20, "I-3": 30 }] |
https://<somehost>/inventory/I-1 | { "productid": "I-1", "qty": 10} |
https://<somehost>/inventory/I-2 | { "productid": "I-2", "qty": 20} |
https://<somehost>/inventory/I-200 | { "productid": I-200, "qty": -1} |
リポジトリのクローンを作成する
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。
gcloud を設定する
Cloud Shell でプロジェクト ID を設定し、PROJECT_ID 変数として保存します。
PROJECT_ID=[YOUR-PROJECT-ID]
gcloud config set project $PROJECT_ID
次のコマンドを実行します。
$ git clone https://github.com/rominirani/cloud-code-sample-repository.git
これにより、このフォルダに cloud-code-sample-repository というフォルダが作成されます。
（省略可）Cloud Shell でアプリケーションを実行する
次の手順に沿って、アプリケーションをローカルで実行します。
- ターミナルから、次のコマンドを使用して API の Python バージョンに移動します。
$ cd cloud-code-sample-repository
$ cd python-flask-api
- ターミナルで次のコマンドを入力します（このドキュメントの作成時点では、Cloud Shell に Python 3.9.x がインストールされており、デフォルト バージョンを使用します）。ノートパソコンでローカルに実行する場合は、Python 3.8 以上を使用できます。
$ python app.py
- 次のコマンドを実行して、Python サーバーをローカルで起動できます。
- これにより、ポート 8080 でサーバーが起動します。Cloud Shell のウェブ プレビュー機能を使用して、ローカルでテストできます。下の図に示すように、[ウェブでプレビュー] ボタンをクリックします。
[ポート 8080 でプレビュー] をクリックします。
- ブラウザ ウィンドウが開きます。404 エラーが表示されますが、問題ありません。URL を変更して、ホスト名の後に /inventory だけが含まれるようにします。
たとえば、私のマシンでは次のようになります。
https://8080-cs-557561579860-default.cs-asia-southeast1-yelo.cloudshell.dev/inventory
これにより、前述のように在庫アイテムのリストが表示されます。
- ターミナルに移動して Ctrl+C キーを押すと、サーバーを停止できます。
アプリケーションをデプロイする
この API アプリケーションを Cloud Run にデプロイします。このプロセスでは、glcoud コマンドライン クライアントを使用して、コードを Cloud Run にデプロイするコマンドを実行しました。
ターミナルから、次の gcloud コマンドを実行します。
$ gcloud run deploy --source .
複数の質問が表示されます（承認を求められた場合は、承認してください）。以下に、質問のいくつかを示します。構成と、Google Cloud プロジェクトで特定の API がすでに有効になっているかどうかによって、すべての質問が表示される場合とされない場合があります。
- サービス名（python-flask-api）: このデフォルトを使用するか、my-inventory-api などの名前を選択します。
- API [run.googleapis.com] not enabled on project [project-number]. 有効にして再試行しますか？（数分かかります）(y/N)? Y
- 地域を指定してください: 番号を入力して、任意の地域を選択します。
- API [artifactregistry.googleapis.com] not enabled on project [project-number]. 有効にして再試行しますか？（数分かかります）(y/N)? Y
- ソースからデプロイするには、ビルドされたコンテナを保存する Artifact Registry Docker リポジトリが必要です。リージョン [us-west1] に [cloud-run-source-deploy] という名前のリポジトリが作成されます。
Do you want to continue (Y/n)? Y
- Allow unauthenticated invocations to [my-inventory-api] (y/N)? Y
最終的に、このプロセスが開始され、ソースコードが取得されてコンテナ化され、Artifact Registry に push されてから、Cloud Run サービスとリビジョンがデプロイされます。このプロセスには 3 ～ 4 分かかることがあります。プロセスが完了すると、サービスの URL が表示されます。
実行例を以下に示します。
アプリケーションをテストする
アプリケーションを Cloud Run にデプロイしたので、次のように API アプリケーションにアクセスできます。
- 前の手順で取得したサービス URL をメモします。たとえば、私の設定では
https://my-inventory-api-bt2r5243dq-uw.a.run.appと表示されます。これを <SERVICE_URL> とします。 - ブラウザを開き、API エンドポイントの次の 3 つの URL にアクセスします。
- <SERVICE_URL>/inventory
- <SERVICE_URL>/inventory/I-1
- <SERVICE_URL>/inventory/I-100
これは、前のセクションで API リクエストとレスポンスのサンプルとともに提供した仕様に準拠している必要があります。
Cloud Run からサービスの詳細を取得する
API サービスをサーバーレス コンピューティング環境である Cloud Run にデプロイしました。Google Cloud コンソールから Cloud Run サービスにいつでもアクセスできます。
メインメニューから Cloud Run に移動します。これにより、Cloud Run で実行されているサービスのリストが表示されます。デプロイしたサービスが表示されます。選択した名前に応じて、次のような画面が表示されます。
サービス名をクリックして、詳細を表示します。サンプルの詳細は次のとおりです。
URL は、ブラウザに入力して、デプロイしたばかりの Inventory API にアクセスできるサービス URL です。指標などの詳細もご覧ください。
それでは、Google Cloud オペレーション スイートから始めましょう。
4. ダッシュボードを設定する
Cloud Monitoring の便利な機能の 1 つに、Google Cloud の複数のリソースにわたる Out-of-the-Box（OOTB）ダッシュボードがあります。これにより、標準指標を使用したダッシュボードの初期設定を迅速かつ簡単に行うことができます。
Cloud Run にデプロイした API サービスでこれを行う方法を見てみましょう。
本サービスのカスタム ダッシュボード
API サービスを Cloud Run にデプロイしたので、さまざまな指標（サービス レイテンシなど）を可視化するのに役立つダッシュボードを設定する方法を確認しましょう。
まず、コンソールから、次のように [モニタリング] → [概要] に移動します。
[概要] には、モニタリングで構成したダッシュボード、アラート、稼働時間チェックなど、複数の項目が表示されます。
ここでは、サイドのメインメニューから [ダッシュボード] をクリックします。次の画面が表示されます。
[サンプル ライブラリ] をクリックします。これにより、複数のリソースにわたって Google Cloud で使用可能な Out-Of-The-Box（OOTB）ダッシュボードのリストが表示されます。具体的には、リストを下にスクロールして、次のように [Google Cloud Run] を選択します。
Google Cloud Run で使用可能な標準ダッシュボードのリストが表示されます。Cloud Run にサービスをデプロイしているため、この点に関心があります。
Cloud Run Monitoring のダッシュボードが 1 つ表示されます。[プレビュー] リンクをクリックして、Cloud Run Monitoring で使用可能な標準グラフ（指標）のリストを表示します。[IMPORT SAMPLE DASHBOARD] をクリックするだけで、これらのグラフをすべてカスタム ダッシュボードにインポートできます。以下に示すように、同じ名前が事前入力されたダッシュボード画面が表示されます。
左上のダッシュボード名の左にある左矢印をクリックすると、前のページに戻ることができます。ダッシュボードのリストが表示されます。作成した新しいダッシュボードが表示されます。
そのダッシュボードのリンクをクリックすると、すぐに使用できる複数の指標をモニタリングできます。これらの指標には、レイテンシ、リクエスト数、コンテナ指標などがあります。
以下に示すように、スターアイコンを選択するだけで、ダッシュボードをお気に入りに登録することもできます。
これにより、ダッシュボードが Monitoring の [概要] 画面に追加され、よく使用するダッシュボードに簡単に移動できるようになります。
素晴らしいですね。これで、Cloud Run サービスをモニタリングするためのカスタム ダッシュボードが追加されました。よくできました。
5. 稼働時間チェック
このセクションでは、デプロイした API サービスの稼働時間チェックを設定します。公開稼働時間チェックでは、世界中の複数のロケーションから、一般公開されている URL または Google Cloud リソースにリクエストを発行して、リソースが応答するかどうかを確認できます。
この場合のリソースは、Cloud Run にデプロイした API サービスになります。この URL は、API サービスが公開する特定のエンドポイントで、サービスの健全性を示します。
サンプル API サービスコードでは、文字列値「All Izz Well」を返すエンドポイント /healthy を公開しています。したがって、https://<SERVICE_URL>/healthy
通知チャンネルを作成する
稼働時間チェックを作成する前に、まず通知チャンネルを構成することが重要です。通知チャンネルは、モニタリング対象リソースでインシデントや問題が発生した場合にアラートが送信される媒体です。通知チャネルの例としては、アラートが発生した場合などにメールを受信できるメールがあります。
ここでは、メール通知チャンネルを構成し、メールアドレスで構成して、システムが生成するアラートを通知できるようにします。
通知チャンネルを作成する手順は次のとおりです。
Google Cloud コンソールのメインメニューから、次のように [モニタリング → アラート] に移動します。
アラートやポリシーなどが表示されたページが表示されます。現時点では、上部に [通知チャンネルを編集] というリンクが表示されます。それをクリックします。
以下のように、さまざまな通知チャンネルのリストが表示されます。
[Email] セクションを見つけて、その行の [ADD NEW] をクリックします。これにより、次のようにメール構成の詳細が表示されます。
以下のように、メールアドレスと表示名を入力します。[保存] をクリックします。
これで、メール通知チャンネルの作成が完了しました。それでは、稼働時間チェックを構成しましょう。
稼働時間チェックの作成
Google Cloud コンソールのメインメニューから、[モニタリング] → [稼働時間チェック] に移動します。上部に [CREATE UPTIME CHECK] リンクが表示されます。それをクリックします。
稼働時間チェックを構成するために必要な一連の手順が表示されます。
最初の手順は、デプロイした Cloud Run サービスに関する情報であるターゲットの詳細を設定することです。入力済みのフォームを以下に示します。
異なる値は次のように選択できます。
- プロトコル : HTTPS
- リソースタイプ : Cloud Run サービスを選択します。サポートされている他のリソースと、それらに対して稼働時間チェックを設定できることも確認してください。
- Cloud Run サービス : my-inventory-api または Cloud Run サービスの特定の名前を選択します。
- パスは /healthy です。これは、文字列「All Izz Well」を返して、それを確認するためです。
[続行] をクリックして、次のステップに進みます。次のステップは、次の図に示すように、レスポンスの検証ステップです。
「コンテンツ マッチング」のチェックを有効にし、/healthy エンドポイントから返されるレスポンスを「All Izz Well」に設定していることがわかります。[続行] をクリックして次のステップに進み、稼働時間チェックが失敗した場合にアラートを構成し、アラートを送信する通知チャネルを設定します。
このステップでは、アラートに名前を付けます。ここでは [Inventory API Uptime Check failure] を選択しましたが、任意の名前を選択できます。ここで重要なのは、先ほど構成したリストから正しい通知チャンネルを選択することです。
[確認] をクリックして、構成した稼働時間チェックを確認します。
最後の手順では、稼働時間チェックに名前（例: Inventory API Uptime Check）を付けます。また、チェックが正しく構成されているかどうかをテストすることもできます。[テスト] ボタンをクリックします。
プロセスを完了します（左側の [作成] ボタンをクリックします）。Google Cloud は、異なるリージョンに構成された稼働時間チェック プローブに URL を ping するよう指示し、これらのレスポンスを収集します。数分後に [モニタリング → 稼働時間チェック] セクションにアクセスすると、さまざまなプローブから URL にアクセスできたことを示す緑色のシグナルがすべて表示されます。
プローブのいずれかが一定期間（構成可能）失敗すると、構成したメール チャンネルでアラート通知が届きます。
これで、稼働時間チェックの設定に関するセクションは終了です。よくできました。
6. Metrics Explorer
Cloud Monitoring は、複数の Google Cloud プロダクトから数千もの標準指標を公開します。これらの指標は、調査、クエリ、グラフへの変換、ダッシュボードへの追加、アラートの生成などに使用できます。
このセクションの目標は次のとおりです。
- さまざまな指標を確認する方法を理解し、API サービスの特定の指標（レイテンシ）を調べます。
- この指標をグラフとカスタム ダッシュボードに変換して、いつでも指標を可視化できるようにします。
Inventory API サービスのレイテンシ指標を確認する
Google Cloud コンソールのメインメニューから [モニタリング] → [Metrics Explorer] に移動します。[指標エクスプローラ] 画面が表示されます。[指標を選択] をクリックします。指標が生成された複数のアクティブなリソースをナビゲートできるようになりました。
Cloud Run サービスを扱うため、[Cloud Run のリビジョン]、カテゴリ、[リクエスト レイテンシ] という特定の指標をクリックします。
[適用] をクリックします。リクエスト レイテンシがグラフに表示されます。右側の [表示] 設定で、ウィジェットのタイプを折れ線グラフに変更できます（下図を参照）。
次のようにレイテンシ グラフが表示されます。
グラフとカスタム ダッシュボードを作成する
このグラフを保存しましょう。[グラフを保存] をクリックし、以下のように詳細を入力します。
既存のダッシュボードに保存するのではなく、新しいダッシュボードを作成していることに注意してください。[保存] をクリックします。これにより、以下に示すように、新しく作成したダッシュボードがダッシュボードのリストに追加されます。
作成した特定のダッシュボードをクリックして、詳細を表示します。
これで、Metrics Explorer を使用してさまざまな指標を調査する方法と、カスタム ダッシュボードを作成する方法に関するセクションは完了です。
7. Cloud Logging
このセクションでは、Cloud Logging について説明します。Cloud Logging には、さまざまな Google サービスと独自のアプリケーションによって生成されたログをナビゲートして詳細を確認できるログ エクスプローラ インターフェースが用意されています。
このセクションでは、ログ エクスプローラについて学習し、いくつかのログ メッセージをシミュレートします。これらのログ メッセージは、ログベースの指標という機能を使用して検索し、指標に変換できます。
ログ エクスプローラ
ログ エクスプローラには、次の図に示すように、メインの Google Cloud コンソールから [ロギング] → [ログ エクスプローラ] に移動してアクセスできます。
ログ インターフェースが表示されます。ここでは、必要に応じてログ メッセージをフィルタするために、さまざまなリソース（プロジェクト、Google Cloud リソース、サービス名など）とログレベルを個別に選択/選択解除できます。
上に表示されているのは、Cloud Run リビジョンのログのリストです。つまり、デプロイした Cloud Run サービスのログのリストです。構成した /healthy エンドポイントにアクセスするリクエストがいくつか表示されます。
警告を検索する
I-1、I-2、I-3 以外の商品 ID を指定して、Inventory Service への無効なリクエストをシミュレートします。たとえば、次のようなリクエストは正しくありません。
https://<SERVICE_URL>/inventory/I-999
これで、クエリで誤った商品 ID が指定されたときに API によって生成されたすべての WARNING が検索されるようになります。
クエリボックスに次のクエリ パラメータを挿入します。
resource.type="cloud_run_revision"
textPayload =~ "Received inventory request for incorrect productid"
次のようになります。
[クエリを実行] をクリックします。これにより、受信したリクエストと、この問題が発生しているリクエストがすべて表示されます。
ログベースの指標
これらのエラーを追跡するカスタムログ指標を作成しましょう。間違った商品 ID で大量の呼び出しが発生しているかどうかを把握したいと考えています。
上記をエラー指標に変換するには、ログ エクスプローラに表示される [指標を作成] ボタンをクリックします。
指標定義を作成するためのフォームが表示されます。カウンター指標を選択し、次の図に示すように指標名 （inventory_lookup_errors）と説明の詳細を入力して、[指標を作成] をクリックします。
これにより、カウンタ指標が作成され、次のようなメッセージが表示されます。
メインメニューから [ロギング] → [ログベースの指標] に移動すると、次のように、ユーザー定義の指標のリストに定義したカスタム指標が表示されます。
このエントリの末尾にある縦の 3 つの点をクリックすると、このカスタム指標で実行できるオペレーションが表示されます。リストは次のようになります。[Metrics Explorer で表示] オプションをクリックします。
これにより、前のセクションで学習した Metrics Explorer が表示されます。ただし、今回は事前入力されています。
[Save Chart] をクリックします。[Save Chart] オプションには次の値を使用します。
これで、在庫検索エラーを確認できる新しいダッシュボードが作成され、ダッシュボードのリストに表示されます。
これで準備が整いました。これで、ログからカスタム指標を作成し、カスタム ダッシュボードに表示されるグラフに変換しました。これにより、誤った商品 ID を使用している通話の数を追跡できます。
8. アラート ポリシー
このセクションでは、作成したカスタム指標を使用して、しきい値のデータをモニタリングします。つまり、エラーの数が特定のしきい値を超えた場合にアラートを生成します。つまり、アラート ポリシーを設定します。
アラート ポリシーを作成する
在庫検索ダッシュボードに移動しましょう。これにより、以下に示すように、在庫ルックアップ エラーを記録するために作成したグラフが表示されます。
現在の指標データが表示されます。まず、次のように指標を編集します（[編集] ボタンをクリックします）。
指標の詳細が表示されます。グラフをエラー率から合計（エラー数）に変換します。変更するフィールドは次のとおりです。
右上にある [適用] をクリックすると、指標画面に戻ります。今回は、調整期間のエラーの合計数とエラー率を確認できます。
エラー数がしきい値を超えた場合に通知するアラート ポリシーを作成します。グラフの右上にあるその他アイコンをクリックし、上記のオプション リストから [アラート グラフに変換] をクリックします。
次のような画面が表示されます。
[次へ] をクリックすると、設定可能なしきい値が表示されます。ここで使用したしきい値のサンプルは 5 ですが、必要に応じて選択できます。
[次へ] をクリックして、通知フォームを表示します。
通知チャンネルとして、先ほど作成したメールチャンネルを選択しました。[Documentation] などの他の詳細を入力します（これは、発生したアラートの一部として提供されます）。[次へ] をクリックして概要を表示し、プロセスを完了します。
このアラート ポリシーを作成すると、次の図のようにアラート ポリシーのリストに表示されます。アラート ポリシーのリストを表示するには、[モニタリング] → [アラート] に移動します。ページで [ポリシー] セクションを探して、これまでに構成したポリシーのリストを確認します。
これで準備が整いました。これで、Inventory API の検索中にエラー率が増加した場合に通知するカスタム アラート ポリシーが構成されました。
9. Service Monitoring（省略可）
このセクションでは、サイト信頼性エンジニアリング（SRE）の原則に従って、サービスの SLI/SLO を設定します。Cloud Monitoring では、Cloud Run にデプロイしたサービスが自動的に検出され、可用性やレイテンシなどの主要な SLI が自動的に計算されます。また、エラー バジェットの計算も自動的に行われるため、作業が容易になります。
API サービスのレイテンシ SLO を設定しましょう。
インベントリ サービスのレイテンシ SLO を設定する
Cloud Console のメインメニューで、[モニタリング] → [サービス] をクリックします。これにより、サービス モニタリング用に構成されたサービスのリストが表示されます。
現在、SLI/SLO モニタリング用に設定されたサービスがないため、リストは空です。上部の [DEFINE SERVICE] リンクをクリックして、最初にサービスを定義または特定します。
これにより、SLO モニタリングの候補となるサービスが自動的に検出されます。Cloud Run サービスを検出できるため、Cloud Run にデプロイされた Inventory API サービスがリストに表示されます。
表示される名前は、Cloud Run にサービスをデプロイしたときに選択した内容によって異なる場合があります。[送信] ボタンをクリックします。次の画面が表示されます。
[SLO を作成] をクリックします。これにより、自動的に計算された SLI から選択できるようになります。
まず、レイテンシ SLI を選択します。[続行] をクリックします。次の画面には、このサービスの現在のパフォーマンスと、一般的なレイテンシが表示されます。
しきい値（300 ミリ秒）を入力します。これが目標値になります。必要に応じて別の値を選択できますが、それに応じて定義するエラー バジェットに影響することに注意してください。[続行] をクリックします。
SLO（目標と測定期間）を次のように設定します。
つまり、測定期間をローリング タイプとして選択し、7 日間で測定します。同様に、目標値は 90% に設定しました。ここで言いたいのは、API サービスへのリクエストの 90% が 300 ミリ秒以内に完了する必要があり、これは 7 日間にわたって測定される必要があるということです。
[続行] をクリックします。概要画面が表示されます。この画面で [SLO を更新] ボタンをクリックして確定します。
これにより、SLO 定義が保存され、エラー バジェットが自動的に計算されます。
以下の方法をお試しください。
- 複数の呼び出しで API を実行し、サービスのパフォーマンスと、それが残りのエラー バジェットにどのように影響するかを確認します。
- ソースコードを変更して、一部の呼び出しで追加の遅延（スリープ）をランダムに導入します。これにより、多くの呼び出しのレイテンシが増加し、エラー バジェットに悪影響が及ぶはずです。
10. 完了
お疲れさまでした。サンプル アプリケーションを Google Cloud に正常にデプロイし、Google Cloud Operations Suite を使用してアプリケーションの健全性をモニタリングする方法を学習しました。
学習した内容
- Google Cloud Run へのサービスのデプロイ。
- Google Cloud Run サービスのダッシュボードを設定します。
- 稼働時間チェック。
- カスタムログ指標と、それに基づくダッシュボード/グラフを設定する。
- Metrics Explorer を調べて、ダッシュボードとグラフを設定します。
- アラート ポリシーの設定。
- Google Cloud でのサービス モニタリングの SLI/SLO の設定。
注: ご自身のアカウントと Google Cloud プロジェクトを使用して Codelab を実行した場合、割り当てられたリソースに対して引き続き課金が発生する可能性があります。ラボが終了したら、プロジェクトとリソースを削除してください。
次のステップ
Google Cloud Operations Suite の詳細については、こちらの Cloud Skills Boost クエストをご覧ください。