1. はじめに
最終更新日: 2023 年 7 月 28 日
Google Cloud オペレーション スイートとは
Google Cloud オペレーション スイートは、Google Cloud 環境上のアプリケーションのパフォーマンスをモニタリングしてトラブルシューティングを行い、パフォーマンスを向上させるためのプラットフォームです。Cloud オペレーション スイートの主要な柱には、Cloud Monitoring、Cloud Logging、Cloud Trace が含まれます。
こちらの動画で 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 をランダムに生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップを終えた後は変更できず、プロジェクト期間中は維持されます。
- なお、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 の概要
このアプリケーションは、在庫アイテムを一覧表示し、特定のアイテムの在庫数を取得するいくつかのオペレーションを備えた REST API エンドポイントを公開する、シンプルな Inventory API アプリケーションです。
API をデプロイし、https://<somehost> でホストされていると仮定すると、次のように API エンドポイントにアクセスできます。
- https://<somehost>/inventory
これにより、すべての商品アイテムが手持ちの在庫レベルとともに一覧表示されます。
- https://<somehost>/inventory/{productid}
これにより、productid とその商品の在庫レベルを含む単一のレコードが返されます。
返されるレスポンス データは JSON 形式です。
サンプルデータと API リクエスト/レスポンス
シンプルにするため、このアプリケーションはバックエンドのデータベースを使用していません。3 つのサンプル商品 ID とその在庫レベルが含まれています。
商品 ID | 在庫レベル |
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] がプロジェクト [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 アプリケーションにアクセスできます。
- 前の手順で取得した Service 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 Service をサーバーレス コンピューティング環境である Cloud Run にデプロイしました。Google Cloud コンソールからいつでも Cloud Run サービスにアクセスできます。
メインメニューから [Cloud Run] に移動します。Cloud Run で実行されているサービスのリストが表示されます。デプロイしたサービスが表示されます。選択した名前に応じて、次のような画面が表示されます。
サービス名をクリックして詳細を表示します。サンプルの詳細は次のとおりです。
URL に注目してください。これは、ブラウザに入力して、デプロイした Inventory API にアクセスできるサービス URL です。指標やその他の詳細を自由に確認できます。
それでは、Google Cloud オペレーション スイートについて説明しましょう。
4. ダッシュボードを設定する
Cloud Monitoring の便利な機能の 1 つは、Google Cloud 内の複数のリソースにわたるすぐに使用できる（OOTB）ダッシュボードです。これにより、標準指標を使用したダッシュボードの初期設定が、迅速かつ便利なプロセスになります。
Cloud Run にデプロイした API サービスで、この方法を試してみましょう。
サービス用のカスタム ダッシュボード
API サービスを Cloud Run にデプロイしたので、さまざまな指標（サービス レイテンシなど）を可視化できるダッシュボードを設定する方法を確認しましょう。
まず、コンソールから、以下の手順で [Monitoring → Overview] に移動します。
[概要] には、Monitoring で構成したダッシュボード、アラート、稼働時間チェックなど、複数の項目が表示されます。
サイドのメインメニューから [ダッシュボード] をクリックします。次の画面が表示されます。
[サンプル ライブラリ] をクリックします。これにより、複数のリソースにわたって、Google Cloud で使用可能なすぐに使用できる（OOTB）ダッシュボードのリストが表示されます。具体的には、リストを下にスクロールして、次のように [Google Cloud Run] を選択します。
Google Cloud Run で使用可能な標準ダッシュボードのリストが表示されます。サービスを Cloud Run にデプロイしているため、この点に興味があります。
Cloud Run Monitoring のダッシュボードが 1 つ表示されます。[プレビュー] リンクをクリックして、Cloud Run Monitoring で使用可能な標準グラフ（指標）のリストを表示します。[サンプル ダッシュボードをインポート] をクリックするだけで、これらのグラフをすべてカスタム ダッシュボードにインポートできます。次に示すように、ダッシュボード画面が表示され、名前が事前に入力されます。
左に移動するには、左上のダッシュボード名の左側にある左矢印をクリックします。ダッシュボードのリストが表示されます。このリストに、作成したばかりの新しいダッシュボードが表示されます。
ダッシュボードのリンクをクリックすると、すぐに使用できる複数の指標をモニタリングできます。これらの指標には、レイテンシ、リクエスト数、コンテナ指標などがあります。
ダッシュボードをお気に入りとしてマークすることもできます。以下に示すように、スターアイコンを選択するだけです。
これにより、ダッシュボードが Monitoring の [概要] 画面に追加され、よく使用するダッシュボードに簡単に移動できるようになります。
ありがとうございます。Cloud Run サービスをモニタリングするためのカスタム ダッシュボードが追加されました。よくできました。
5. 稼働時間チェック
このセクションでは、デプロイした API サービスの稼働時間チェックを設定します。公開稼働時間チェックでは、世界中の複数のロケーションから一般公開されている URL や Google Cloud リソースにリクエストを発行し、リソースが応答するかどうかを確認できます。
この場合のリソースは、Cloud Run にデプロイした API サービスになります。URL は、API Service が公開してサービスの状態を示す特定のエンドポイントになります。
API サービス コードのサンプルでは、文字列値「All Izz Well」を返すエンドポイント /healthy を公開しています。したがって、https://<SERVICE_URL>/healthy のような URL にアクセスし、"All Izz Well" という文字列が返されるかどうかを確認する稼働時間チェックを定義するだけで済みます。
通知チャンネルを作成する
稼働時間チェックを作成する前に、まず通知チャネルを構成することが重要です。通知チャンネルは、Google の監視対象リソースにインシデントや問題がある場合にアラートを受け取るための手段です。通知チャネルの例としては、アラートが発生したときにメールが届くメールがあります。
ここでは、メール通知チャンネルを構成し、メールアドレスを使用して構成します。これにより、システムによって発生するアラートがあった場合に通知を受け取ることができます。
通知チャンネルを作成する手順は次のとおりです。
以下に示すように、Google Cloud コンソールのメインメニューから [Monitoring] → [アラート] に移動します。
アラートやポリシーなどが表示されます。現時点では、[EDIT NOTIFICATION CHANNELS] というタイトルのリンクが表示されます。それをクリックします。
次のように、さまざまな通知チャンネルのリストが表示されます。
[メール] セクションを見つけて、その行の [ADD NEW] をクリックします。これにより、以下のように [Email Configuration] の詳細が表示されます。
メールアドレスと表示名を以下のように入力します。[保存] をクリックします。
これで、メール通知チャンネルの作成が完了します。稼働時間チェックを構成しましょう。
稼働時間チェックの作成
Google Cloud コンソールのメインメニューで、[Monitoring] > [Uptime checks] に移動します。上部に [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 稼働時間チェック）。チェックが正しく構成されているかどうかをテストすることもできます。テストするには、[TEST] ボタンをクリックします。
手順を完了します（左側の [作成] ボタンをクリックします）。Google Cloud は、さまざまなリージョンに構成された稼働時間チェック プローブに URL への ping を命令し、これらのレスポンスを収集します。数分後に [Monitoring] → [稼働時間チェック] セクションに移動します。異なるプローブから URL にアクセスできたことを示す緑色のシグナルがすべて表示されるのが理想的です。
プローブのいずれかが一定期間（構成可能）にわたって失敗した場合は、構成したメール チャンネルでアラート通知が届きます。
これで、稼働時間チェックの設定に関するセクションは完了です。お疲れさまでした。
6. Metrics Explorer
Cloud Monitoring は、複数の Google Cloud プロダクトの何千もの標準指標を公開します。これらの指標は、調査、クエリ、グラフへの変換、ダッシュボードへの追加、アラートの発生など、さまざまな用途に使用できます。
このセクションの目標は次のとおりです。
- さまざまな指標を確認する方法を確認してから、API サービスの特定の指標（レイテンシ）を調べます。
- その指標をグラフとカスタム ダッシュボードに変換し、いつでも指標を可視化できるようにします。
Inventory API サービスのレイテンシ指標を確認する
Google Cloud コンソールのメインメニューから、[Monitoring] > [Metrics Explorer] に移動します。これで、指標エクスプローラの画面が表示されます。[指標を選択] をクリックします。指標が生成されている複数のアクティブなリソースを移動できるようになりました。
Cloud Run サービスを使用するため、[Cloud Run のリビジョン]、カテゴリ、[リクエスト レイテンシ] の順にクリックします。
[適用] をクリックします。リクエストのレイテンシがグラフに表示されます。右側の [表示] 設定で、ウィジェットの種類を折れ線グラフに変更できます。
次のようなレイテンシ グラフが表示されます。
グラフとカスタム ダッシュボードを作成する
このグラフを保存しましょう[Save Chart] をクリックし、以下の詳細を使用します。
ここでは、既存のダッシュボードに保存するのではなく、新しいダッシュボードを作成します。[保存] ボタンをクリックします。これにより、以下のように、新しく作成されたダッシュボードがダッシュボードのリストに追加されます。
作成した特定のダッシュボードをクリックして詳細を表示します。
これで、Metrics Explorer でさまざまな指標を調査し、カスタム ダッシュボードを作成する方法に関するセクションは終了です。
7. Cloud Logging
このセクションでは、Cloud Logging について説明します。Cloud Logging には、さまざまな Google サービスと独自のアプリケーションによって生成されたログを移動して詳細を確認できるログ エクスプローラ インターフェースが用意されています。
このセクションでは、ログ エクスプローラについて学習し、いくつかのログメッセージをシミュレートします。ログメッセージを検索して、ログベースの指標という機能を使用して指標に変換できます。
ログ エクスプローラ
ログ エクスプローラには、次の手順でメインの Google Cloud コンソールから [Logging → ログ エクスプローラ] を選択してアクセスできます。
ログ インターフェースが表示されます。ここで、さまざまなリソース（プロジェクト、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) と説明に詳細を入力し、[指標を作成] をクリックします。
これにより、カウンタ指標が作成され、次のようなメッセージが表示されます。
メインメニューから [Logging → ログベースの指標] に移動すると、次のように、定義したカスタム指標がユーザー定義の指標のリストに表示されます。
このエントリの末尾にはその他アイコンがあります。これをクリックすると、このカスタム指標に対して実行できるオペレーションが表示されます。リストは以下のようになります。[Metrics Explorer で表示する] オプションをクリックします。
前のセクションで説明した Metrics Explorer が表示されます。ただし、データが事前に入力されています。
[Save Chart] をクリックします。[グラフの保存] オプションでは、次の値を使用します。
これで、在庫検索のエラーを表示する新しいダッシュボードが作成され、ダッシュボードのリストで使用できるようになります。
これで準備が整いました。これで、ログからカスタム指標を作成し、それをカスタム ダッシュボードのグラフに変換しました。これにより、間違った商品 ID を使用している通話の数をトラッキングできます。
8. アラート ポリシー
このセクションでは、作成したカスタム指標を使用して、しきい値に基づいてデータをモニタリングします。つまり、エラー数が特定のしきい値を超えると、アラートを発生させます。つまり、アラート ポリシーを設定します。
アラート ポリシーを作成する
広告枠検索ダッシュボードに移動します。作成したグラフが表示され、インベントリ検索エラーが記録されます（以下を参照）。
これにより、現在の指標データが表示されます。まず、次のように指標を編集します（[編集] ボタンをクリックします）。
これにより、指標の詳細が表示されます。エラー率を示すグラフを、エラー数の合計値に変換します。変更するフィールドは次のとおりです。
右上にある [適用] をクリックすると [指標] 画面に戻ります。今回は、アライメント期間内のエラーの総数とエラー率を確認できます。
エラー数がしきい値を超えた場合に通知するアラート ポリシーを作成します。グラフの右上にあるその他アイコンをクリックし、上記のようにオプションのリストから [アラートグラフに変換] をクリックします。
次のような画面が表示されます。
[次へ] をクリックすると、設定できるしきい値が表示されます。ここで採用したサンプルしきい値は 5 ですが、お好みに応じて選択できます。
[次へ] をクリックして通知フォームを表示する
先ほど作成したメール チャンネルとして通知チャンネルを選択しました。ドキュメントなどのその他の詳細情報を入力できます（これは、生成されるアラートの一部として提供されます）。[次へ] をクリックして概要を確認し、手順を完了します。
このアラート ポリシーを作成すると、次のようにアラート ポリシーのリストに表示されます。アラート ポリシーのリストにアクセスするには、[モニタリング] > [アラート] に移動します。ページで [ポリシー] セクションを探して、これまでに構成したポリシーのリストを表示します。
これで準備が整いました。これで、Inventory API の検索中にエラー率が増加した場合に通知するカスタム アラート ポリシーが構成されました。
9. Service Monitoring（省略可）
このセクションでは、サイト信頼性エンジニアリング（SRE）の原則に従って、サービスの SLI/SLO を設定します。Cloud Monitoring では、Cloud Run にデプロイしたサービスを自動検出できるため、操作が簡単になることがわかります。また、エラー バジェットの計算とともに、可用性、レイテンシなどの主要な SLI を自動的に計算できます。
次に、API サービスのレイテンシ SLO を設定します。
インベントリ サービスのレイテンシ SLO を設定する
Cloud コンソールのメインメニューで、[Monitoring] > [Services] をクリックします。Service Monitoring 用に構成されたサービスのリストが表示されます。
現在、SLI/SLO モニタリング用に設定されたサービスがないため、リストは空です。上部にある [サービスを定義] リンクをクリックして、まずサービスを定義 / 識別します。
これにより、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 のオペレーション スイートについて詳しくは、こちらの Cloud Skills Boost クエストをご覧ください。