1. はじめに
最終更新日: 2023 年 7 月 28 日
Google Cloud オペレーション スイートとは
Google Cloud オペレーション スイートは、Google Cloud 環境でアプリケーションのパフォーマンスをモニタリング、トラブルシューティング、改善できるプラットフォームです。Cloud オペレーション スイートの主要な柱には、Cloud Monitoring、Cloud Logging、Cloud Trace が含まれます。
こちらの動画で Google Cloud Operations の概要をご確認ください。
作成するアプリの概要
この Codelab では、Google Cloud にサンプル API をデプロイします。その後、Cloud Monitoring と API の複数の機能を確認し、構成します。
学習内容
- 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 を使用するのはご自身のみです。プロジェクトを削除しても、その ID を再び使用することはできません。
- 次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に課金されないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクト全体を削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Google Cloud Shell のセットアップ
Google Cloud と Google Cloud Trace はノートパソコンからリモートで操作できますが、この Codelab では Cloud 上で動作するコマンドライン環境である Google Cloud Shell を使用します。
Cloud コンソールから Cloud Shell を有効にするには、[Cloud Shell をアクティブにする] をクリックするだけです(環境のプロビジョニングと接続には少し時間がかかります)。
Cloud Shell を初めて起動する場合は、その内容を説明する中間画面(スクロールしなければ見えない範囲)が表示されます。その場合は、[続行] をクリックしてください(以後表示されなくなります)。この中間画面は次のようになります。
Cloud Shell のプロビジョニングと接続に少し時間がかかる程度です。
この仮想マシンには、必要な開発ツールがすべて含まれています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働するため、ネットワークのパフォーマンスと認証が大幅に向上しています。このコードラボでの作業のほとんどは、ブラウザまたは 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
- 地域を指定してください: 番号を入力して地域を選択してください。
- API [artifactregistry.googleapis.com] がプロジェクト [project-number] で有効になっていません。有効にして再試行しますか(数分かかる場合があります)(はい/いいえ)?Y
- ソースからデプロイするには、ビルドされたコンテナを保存するための Artifact Registry Docker リポジトリが必要です。リージョン [us-west1] に [cloud-run-source-deploy] という名前のリポジトリが作成されます。
Do you want to continue (Y/n)? Y
- [my-inventory-api] への未認証の呼び出しを許可する(はい/いいえ)?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 からサービスの詳細を取得する
サーバーレス コンピューティング環境である Cloud Run に API サービスをデプロイしました。Google Cloud コンソールからいつでも Cloud Run サービスにアクセスできます。
メインメニューから [Cloud Run] に移動します。Cloud Run で実行されているサービスのリストが表示されます。先ほどデプロイしたサービスが表示されます。選択した名前に応じて、次のように表示されます。
サービス名をクリックして詳細を表示します。サンプルの詳細は次のとおりです。
URL に注目してください。これはサービス URL だけです。ブラウザに入力して、先ほどデプロイした Inventory API にアクセスできます。指標やその他の詳細を自由に確認できます。
それでは早速、Google Cloud オペレーション スイートについて見ていきましょう。
4. ダッシュボードのセットアップ
Cloud Monitoring が提供する便利な機能の一つは、Google Cloud の複数のリソースにまたがるすぐに使用できる(OOTB)ダッシュボードです。これにより、標準指標を使用したダッシュボードの初期設定が迅速かつ簡単になります。
では、先ほど Cloud Run にデプロイした API サービスに対して、その方法を見てみましょう。
Service のカスタム ダッシュボード
API サービスを Cloud Run にデプロイしたので、サービス レイテンシを含むさまざまな指標の可視化に役立つダッシュボードの設定方法を確認しましょう。
まず、コンソールから、以下のように [Monitoring] → [概要] に移動します。
[概要] には、ダッシュボード、アラート、稼働時間チェックなど、Monitoring で構成した項目が複数表示されます。
ひとまず、サイド メインメニューで [ダッシュボード] をクリックします。すると、次のような画面が表示されます。
[SAMPLE LIBRARY] をクリックします。これにより、複数のリソースにわたって、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 サービスが公開する特定のエンドポイントです。
サンプル API サービスコードでは、文字列値「All Izz Well」を返すエンドポイント /healthy を公開しています。必要な作業は、https://<SERVICE_URL>/healthy のようなヒットとなる稼働時間チェックを定義し、https://<SERVICE_URL>/healthy という文字列が返されるかどうかを確認することだけです。
通知チャンネルを作成する
稼働時間チェックを作成する前に、まず通知チャネルを構成することが重要です。通知チャンネルは、Google の監視対象リソースにインシデントや問題がある場合にアラートを受け取るための手段です。通知チャンネルの例としてはメールがあり、アラートなどの場合にメールが届きます。
ここでは、メール通知チャンネルを構成し、メールアドレスを使用して構成します。これにより、システムによって発生するアラートがあった場合に通知を受け取ることができます。
通知チャンネルを作成する手順は次のとおりです。
以下に示すように、Google Cloud コンソールのメインメニューから [Monitoring] → [アラート] に移動します。
アラートやポリシーなどが記載されたページが表示されます。現時点では、[EDIT NOTIFICATION CHANNELS] というタイトルのリンクが表示されます。それをクリックします。
以下のように、さまざまな通知チャンネルのリストが表示されます。
[Email] セクションを見つけて、その行の [ADD NEW] をクリックします。これにより、以下のように [Email Configuration] の詳細が表示されます。
メールアドレスと表示名を以下のように入力します。[保存] をクリックします。
これで、メール通知チャンネルの作成は完了です。では、稼働時間チェックの構成に進みましょう。
稼働時間チェックの作成
Google Cloud コンソールのメインメニューから、[Monitoring] → [稼働時間チェック] に移動します。上部に [CREATE UPTIME CHECK] リンクが表示されます。それをクリックします。
稼働時間チェックを構成するための一連の手順が表示されます。
最初のステップは、ターゲットの詳細(デプロイした Cloud Run サービスに関する情報)を設定することです。記入済みのフォームは次のとおりです。
次のように異なる値を選択できます。
- プロトコル : HTTPS
- リソースタイプ : Cloud Run サービスを選択します。サポートされている他のリソースと、それらのリソースにも稼働時間チェックを設定できることに注意してください。
- Cloud Run サービス : my-inventory-api、または Cloud Run サービス用の特定の名前を選択します。
- パスは /healthy です。「All Izz Well」という文字列が返ってきて、それを確かめたいからです。
[続行] をクリックして次のステップに進みます。次のステップは、以下に示すようにレスポンスの検証ステップです。
[コンテンツの一致]のチェックが有効になっています次に、/healthy エンドポイントから返されるレスポンスが「All Izz Well」になるように設定します。[CONTINUE] をクリックして次のステップに進みます。このステップでは、アラートと、稼働時間チェックが失敗した場合にアラートを受け取る通知チャンネルを構成します。
このステップでは、アラートに名前を付けます。ここでは [Inventory API Uptime Check failure] を選択しましたが、自分でも名前を選ぶことができます。ここで重要なのは、前の手順で構成したリストから正しい通知チャンネルを選択することです。
最後のステップで [確認] をクリックし、構成した稼働時間チェックを確認します。
この最後のステップでは、稼働時間チェックに名前を付けます(例: Inventory API Uptime Check)。また、チェックが正しく構成されているかどうかをテストすることもできます。[TEST] ボタンをクリックします。
次に、プロセスを完了します(左側の [作成] ボタンをクリックします)。Google Cloud は、異なるリージョンに構成されている稼働時間チェック プローブに URL を ping するよう指示すると、これらのレスポンスが収集されます。数分後に [Monitoring] → [稼働時間チェック] セクションに移動します。異なるプローブから URL にアクセスできたことを示す緑色のシグナルがすべて表示されるのが理想的です。
いずれかのプローブが一定期間(構成可能)失敗すると、構成したメールチャネルにアラート通知が届きます。
これで、稼働時間チェックの設定に関するセクションは完了です。お疲れさまでした。
6. Metrics Explorer
Cloud Monitoring は、複数の Google Cloud プロダクトから数千の標準指標を公開します。これらの指標は、調査、クエリ、グラフへの変換、ダッシュボードへの追加、アラートの生成などに使用できます。
このセクションの目標は次のとおりです。
- さまざまな指標を確認する方法を理解したうえで、API サービスの特定の指標(レイテンシ)を調べます。
- その指標をグラフやカスタム ダッシュボードに変換すれば、いつでも指標を可視化できます。
Inventory API サービスのレイテンシ指標を確認する
Google Cloud コンソールのメインメニューから、[Monitoring] → [Metrics Explorer] に移動します。[Metrics Explorer] 画面が表示されます。[指標を選択] をクリックします。指標が生成されている複数のアクティブなリソースを操作できるようになりました。
ここでは Cloud Run サービスを扱うため、[Cloud Run のリビジョン] をクリックし、以下のように [Request Latency] というタイトルのカテゴリと特定の指標をクリックします。
[適用] をクリックします。リクエストのレイテンシがグラフに表示されます。以下に示すように、右側の [ディスプレイ] 設定から [ウィジェット タイプ] を [折れ線グラフ] に変更できます。
これにより、次のようなレイテンシ グラフが表示されます。
グラフとカスタム ダッシュボードを作成する
このグラフを保存しましょう[Save Chart] をクリックし、以下の詳細情報を使用します。
ここでは、既存のダッシュボードに保存するのではなく、新しいダッシュボードを作成します。[保存] ボタンをクリックします。これにより、以下のように、新しく作成されたダッシュボードがダッシュボードのリストに追加されます。
作成した特定のダッシュボードをクリックして、詳細を表示します。
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 を指定して、在庫サービスに対する無効なリクエストをシミュレートします。例:正しくないリクエストの例は次のとおりです。
https://<SERVICE_URL>/inventory/I-999
次に、クエリで間違ったプロダクト ID が指定された場合に、API によって生成されたすべての警告を検索します。
クエリボックスに、次のクエリ パラメータを挿入します。
resource.type="cloud_run_revision"
textPayload =~ "間違った productid の在庫リクエストを受信"
次のようになります。
[クエリを実行] をクリックします。受信したすべてのリクエストと、この問題が発生しているリクエストがすべて表示されます。
ログベースの指標
これらのエラーを追跡するためのカスタム指標を作成しましょう。間違ったプロダクト ID で呼び出しが大量に発生しているかどうかを確認したいと考えています。
上記をエラー指標に変換するには、ログ エクスプローラに表示されている [指標を作成] ボタンをクリックします。
これにより、指標定義を作成するためのフォームが表示されます。[カウンタ指標] に移動し、以下のように指標名((inventory_lookup_errors))と説明に詳細を入力し、[(inventory_lookup_errors)] をクリックします。
これによりカウンタ指標が作成され、次のようなメッセージが表示されます。
メインメニューから [ロギング] → [ログベースの指標] に移動すると、定義したユーザー定義の指標のリストに、定義したカスタム指標が以下のように表示されます。
このエントリの最後にある縦に 3 つ並んだ点をクリックすると、このカスタム指標に対して実行できるオペレーションが表示されます。以下のようなリストが表示されるはずです。[Metrics Explorer で表示する] オプションをクリックします。
前のセクションで学習した Metrics Explorer が表示されますが、今回は事前入力されています。
[グラフを保存] をクリックします。[グラフの保存] オプションでは、次の値を使用します。
これで、在庫検索のエラーを表示する新しいダッシュボードが作成され、ダッシュボードのリストで使用できるようになります。
これで準備が整いました。これで、ログからカスタム指標が作成され、カスタム ダッシュボードに表示されるグラフに変換されました。これにより、誤った商品 ID を使用している通話の数をトラッキングできます。
8. アラート ポリシー
このセクションでは、作成したカスタム指標を使用し、そのデータをしきい値でモニタリングします。つまり、エラーの数が特定のしきい値を超えると、アラートが発生します。つまり、アラート ポリシーを設定します。
アラート ポリシーを作成する
在庫検索ダッシュボードに移動します。すると、以下のように、在庫検索エラーを示すグラフが表示されます。
これにより、現在の指標データが表示されます。まず、次のように指標を編集します([編集] ボタンをクリックします)。
指標の詳細が表示されます。エラー率を示すグラフを、エラー数の合計値に変換します。変更するフィールドは次のとおりです。
右上の [適用] をクリックすると [指標] 画面に戻ります。ここでは、アライメント期間内のエラーの総数とエラー率を確認できます。
ここでは、エラーの数がしきい値を超えた場合に通知できるアラート ポリシーを作成します。グラフの右上にあるその他アイコンをクリックし、上に表示されているオプションのリストで [アラートのグラフに変換] をクリックします。
次のような画面が表示されます。
[Next] をクリックすると、しきい値が表示されます。この値を設定できます。ここで採用したサンプルしきい値は 5 ですが、お好みに応じて選択できます。
[次へ] をクリックして通知フォームを表示する
先ほど作成したメールチャネルとして、通知チャンネルを選択しました。その他の詳細(ドキュメント(発生したアラートの一部として提供されるドキュメント)など)を記入することもできます。[次へ] をクリックして概要を確認し、手順を完了します。
このアラート ポリシーを作成すると、以下のように、アラート ポリシーのリストに表示されます。アラート ポリシーのリストを表示するには、[Monitoring] → [アラート] に移動します。そのページの [Policies] セクションをスキャンして、これまでに構成したポリシーのリストを確認します。
これで準備が整いました。これで、Inventory API の検索中にエラー率が増加した場合に通知するカスタム アラート ポリシーを設定できました。
9. サービスのモニタリング(オプション)
このセクションでは、サイト信頼性エンジニアリング(SRE)の原則に従って、サービスの SLI/SLO を設定します。Cloud Monitoring では、Cloud Run にデプロイしたサービスを自動検出できるため、操作が簡単になることがわかります。また、エラー バジェットの計算とともに、可用性、レイテンシなどの主要な SLI を自動的に計算できます。
API サービスのレイテンシの SLO を設定してみましょう。
Inventory Service のレイテンシ SLO を設定する
Cloud コンソールのメインメニューで、[Monitoring] → [サービス] をクリックします。これにより、Service Monitoring 用に構成されているサービスのリストが表示されます。
現在、SLI/SLO モニタリング用に設定されたサービスがないため、リストは空です。最初に、上部にある [サービスを定義] リンクをクリックして、サービスを定義または特定します。
これにより、SLO モニタリングの候補となるサービスが自動検出されます。Cloud Run サービスを検出できるため、Cloud Run にデプロイされた Inventory API サービスがリストに表示されます。
表示される表示名は、サービスを Cloud Run にデプロイするときに選択した名前によって異なる場合があります。[送信] ボタンをクリックします。これにより、次のような画面が表示されます。
[SLO を作成] をクリックします。これにより、自動的に計算される SLI から選択できるようになります。
レイテンシ SLI を手始めに選択します。[続行] をクリックします。次に、このサービスの現在のパフォーマンスと一般的なレイテンシを示す画面が表示されます。
[Threshold] に値(300 ミリ秒)を入力します。必要に応じて別の値を選択できますが、定義したエラー バジェットに影響することに注意してください。[続行] をクリックします。
ここで、SLO(目標値と測定期間)を次のように設定します。
つまり、[測定期間] を [ローリング タイプ] として選択し、7 日間にわたって測定します。目標値についても同様に 90% を選択しました。ここで言いたいのは、API サービスへのリクエストの 90% が 300 ミリ秒以内に完了し、これを 7 日間で測定する必要があるということです。
[続行] をクリックします。概要画面が表示されます。この画面を確認するには、[SLO を更新] ボタンをクリックします。
これにより SLO 定義が保存され、エラー バジェットが自動的に計算されます。
次の方法をお試しください。
- 複数の呼び出しで API を実行し、サービスのパフォーマンスと残りのエラー バジェットに与える影響を確認します。
- ソースコードを変更して、一部の呼び出しで遅延(スリープ)をランダムに導入します。その結果、多くの呼び出しでレイテンシが上昇し、エラー バジェットに悪影響を及ぼすことになります。
10.完了
これで、サンプル アプリケーションを Google Cloud に正常にデプロイできました。また、Google Cloud オペレーション スイートを使用してアプリケーションの健全性をモニタリングする方法を学びました。
学習した内容
- Google Cloud Run にサービスをデプロイする。
- Google Cloud Run サービスのダッシュボードを設定する。
- 稼働時間チェック。
- カスタム ログ指標とそれに基づくダッシュボード/グラフを設定する。
- Metrics Explorer を探索し、ダッシュボード/グラフを設定する。
- アラート ポリシーの設定
- Google Cloud でサービス モニタリング用の SLI/SLO を設定する。
注: ご自身のアカウントと Google Cloud プロジェクトを使用して Codelab を実行した場合、割り当てられたリソースに対して引き続き課金が発生する場合があります。ラボが完了したら、プロジェクトとリソースを削除します。
次のステップ
Google Cloud オペレーション スイートの詳細については、この Cloud Skills Boost クエストをご確認ください。