リクエスト / レスポンス サービス

リクエスト / レスポンス サービスとは、ユーザーが特定の処理をサービスに明示的に要求し、そのタスクが正常に完了するまで待つというものです。このようなサービスの一般的な例は、次のとおりです。

  • ユーザーがブラウザを使用して直接操作するウェブ アプリケーション。
  • ユーザーのスマートフォン上のクライアント アプリケーションと、クライアントが操作する API バックエンドで構成されるモバイルアプリ。
  • 他のサービス(ユーザーではなく)によって使用される API バックエンド。

これらすべてのサービスで通常は、可用性(成功したリクエストの比率を測定)とレイテンシ(時間しきい値内に完了したリクエストの割合を測定)から SLI を使用します。可用性とレイテンシの SLI の詳細については、サービス モニタリングのコンセプトをご覧ください。

リクエスト ベースの可用性 SLI を表現するには、TimeSeriesRatio 構造体を使用して、合計リクエストに対する良好なリクエストの比率を設定します。「良い」または「有効」という好ましい判定に至るために利用可能なラベルを使用して指標をフィルタする方法を定めます。

リクエスト ベースのレイテンシ SLI を表現するには、DistributionCut 構造体を使用します。

Cloud Endpoints

Cloud Endpoints は API を管理するためのサービスです。既存の API を取得し、認証、割り当て、モニタリングで公開できます。

Endpoints は、gRPC アプリケーション サーバーの前面にプロキシとして実装されます。プロキシで指標を測定することで、すべてのバックエンドが使用できず、ユーザーにエラーが生じても、ケースを適切に処理できます。Endpoints は、serviceruntime.googleapis.com 接頭辞で始まる指標タイプにデータを書き込みます。

詳しくは以下をご覧ください。

可用性 SLI

Cloud Endpoints は、api モニタリング対象リソースタイプと service-runtime api/request_count 指標タイプを使用して Cloud Monitoring に指標データを書き込み、そのデータは、response_code 指標ラベルを使用してフィルタリングし、「良好」と「合計」のリクエストをカウントできます。

リクエスト ベースの可用性 SLI を表現する際は、次の例のようにリクエスト総数に対する良好なリクエストの TimeSeriesRatio 構造体を作成します。

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
    }
  }
}

レイテンシ SLI

Cloud Endpoints では、次の主要な指標タイプを使用してレイテンシを捉えます。

  • api/request_latencies: 非ストリーミング リクエストのレイテンシ(秒単位)の分布。全体的なユーザー エクスペリエンスが最も重要な場合に使用します。
  • api/request_latencies_backend: 非ストリーミング リクエストに対するバックエンド レイテンシ(秒単位)の分布。バックエンドのレイテンシを直接測定する場合に使用します。
  • api/request_latencies_overhead: バックエンドを除く、非ストリーミング リクエストのレイテンシ(秒単位)の分布。Endpoints プロキシによって発生するオーバーヘッドの測定に使用します。

リクエストの合計レイテンシは、バックエンドとオーバーヘッド レイテンシの合計値です。

request_latencies = request_latencies_backend + request_latencies_overhead

Endpoints は、api モニタリング対象リソースタイプと、リクエスト レイテンシ指標タイプの 1 つを使用して、指標データを Cloud Monitoring に書き込みます。これらの指標タイプには、response_coderesponse_code_class ラベルがありません。そのため、すべてのリクエストのレイテンシがレポートされます。

リクエスト ベースのレイテンシ SLI を表すには、次の例で示すように DistributionCut 構造体を使用します。

次の SLO の例では、プロジェクト内のすべてのリクエストの 99% が 1 時間の移動枠内で合計レイテンシが 0~100 ミリ秒未満であると想定しています。

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

次の SLO の例では、1 時間の移動枠内で、リクエストの 98% でバックエンド レイテンシが 0~100 ミリ秒となることを期待しています。

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Cloud Run

Cloud Run は、フルマネージド コンピューティング プラットフォームです。コンテナ化されたアプリケーションを迅速かつ安全にデプロイし、スケーリングすることを目的としています。トラフィックの変化に対応してほぼ瞬時にゼロから自動的にスケールアップ / スケールダウンし、使用した正確なリソースに対してのみ課金することで、インフラストラクチャ管理をすべて抽象化します。

Cloud Run のオブザーバビリティに関する詳細については、次のリンク先をご覧ください。

可用性 SLI

Cloud Run は、cloud_run_revision モニタリング対象リソースタイプと request_count 指標タイプを使用して、Cloud Monitoring に指標データを書き込みます。データは、response_coderesponse_code_class の指標ラベルを使用してフィルタリングし、「良好」なリクエストと「合計」リクエストをカウントできます。

リクエスト ベースの可用性 SLI を表現する際は、次の例のようにリクエスト総数に対する良好なリクエストの TimeSeriesRatio 構造体を作成します。

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
     }
  }
}

レイテンシ SLI

レイテンシを測定するため、Cloud Run では、cloud_run_revision モニタリング対象リソースタイプと request_latencies 指標タイプを使用して Cloud Monitoring に指標データを書き込みます。データは、リビジョンに到達するリクエスト レイテンシ(ミリ秒単位)の分布です。すべてのリクエストのレイテンシを明示的に測定する必要がある場合や、正常なリクエストのみに限定する必要がある場合は、response_coderesponse_code_class の指標ラベルを使用してデータをフィルタリングできます。

リクエスト ベースのレイテンシ SLI を表現するには、DistributionCut 構造体を使用します。次の SLO の例では、1 時間の移動枠内で、リクエストの 99% で合計レイテンシが 0~100 ミリ秒となることを期待しています。

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"run.googleapis.com/https/request_latencies\"
           resource.type=\"cloud_run_revision"",
        "range": {
           "min": 0,
           "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Cloud Functions

Cloud Functions はスケーラブルな従量課金制の Functions-as-a-Service で、インフラストラクチャを管理する必要がないコードの実行環境を提供します。Cloud Functions の関数は、イベント処理や自動化、HTTP/S リクエストの処理など、さまざまなアーキテクチャ パターンで利用されています。

Cloud Functions のオブザーバビリティの詳細については、次のリンク先をご覧ください。

可用性 SLI

Cloud Functions は、cloud_function モニタリング対象リソースタイプと function/execution_time 指標タイプを使用して、Cloud Monitoring に指標データを書き込みます。データは、status 指標ラベルを使用してフィルタリングし、「良好」と「合計」の実行回数をカウントできます。

リクエスト ベースの可用性 SLI を表現する際は、次の例のようにリクエスト総数に対する良好なリクエストの TimeSeriesRatio 構造体を作成します。

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\"",
      "goodServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\
         metric.label.\"status\"=\"ok\"",
     }
  }
}

レイテンシ SLI

レイテンシを測定するため、Cloud Functions では、cloud_function モニタリング対象リソースタイプと function/execution_times 指標タイプを使用して Cloud Monitoring に指標データを書き込みます。データは、関数の実行時間(ナノ秒単位)の分布です。すべての実行のレイテンシを明示的に測定する必要がある場合、または成功した実行のみを測定する必要がある場合は、status を使用してデータをフィルタリングできます。

リクエスト ベースのレイテンシ SLI を表現するには、DistributionCut 構造体を使用します。次の SLO の例では、すべての Cloud Functions の実行の 99% で、1 時間の移動枠内の合計レイテンシが 0~100 ミリ秒未満であることを期待しています。

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"cloudfunctions.googleapis.com/function/execution_times\"
           resource.type=\"cloud_function\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

App Engine

App Engine は、アプリケーションの構築と実行を行うフルマネージドのサーバーレス プラットフォームを提供します。スタンダード環境またはフレキシブル環境のいずれかを選択できます。詳細については、App Engine 環境の選択をご覧ください。

App Engine フレキシブル環境では、可用性またはレイテンシの SLI として簡単に使用できる指標がありません。SLI には、Cloud Load Balancing またはログベースの指標の使用をおすすめします。詳細については、次の SLI ドキュメントをご覧ください。

App Engine の詳細については、次のリンク先をご覧ください。

可用性 SLI

App Engine スタンダード環境は、gae_app モニタリング対象リソースタイプと http/server/response_count 指標タイプを使用して Cloud Monitoring に指標データを書き込みます。データは、response_code 指標ラベルを使用してフィルタリングし、「良好」と「合計」のレスポンス数をカウントできます。

App Engine スタンダード環境のリクエスト ベースの可用性 SLI を表現する際は、次の例のようにリクエストの総数に対する良好なリクエストの TimeSeriesRatio 構造体を作成します。

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\">\"499\"
         metric.label.\"response_code\"<\"399\"",
      "goodServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\"<\"299\"",
     }
  }
}

レイテンシ SLI

レイテンシを測定するため、App Engine スタンダード環境では、gae_app モニタリング対象リソースタイプと http/server/response_latencies 指標タイプを使用して、指標データを Cloud Monitoring に書き込みます。データは、response_code 指標ラベルを使用してフィルタリングし、「良好」と「合計」の実行回数をカウントできます。

App Engine スタンダード環境のリクエスト ベースのレイテンシ SLI は、DistributionCut 構造体を使用して表現します。次の SLO の例では、1 時間の移動枠内で、全リクエストの 99% で合計レイテンシが 0~100 ミリ秒となることを期待しています。

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"appengine.googleapis.com/http/server/response_latencies\"
           resource.type=\"gae_app\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

GKE と Istio

Google Kubernetes Engine(GKE)は、Google が管理する安全な Kubernetes Service です。4 方向の自動スケーリングとマルチクラスタをサポートします。Istio は、サービスの接続、保護、制御、監視を可能にするオープンソースのサービス メッシュです。Istio は、アドオン(Istio on GKE)として GKE にインストールすることも、オープンソース プロジェクトからインストールすることもできます。いずれの場合も、Istio はメッシュで管理される各サービスのトラフィック、エラー、レイテンシに関する情報など、優れたテレメトリーを提供します。

Istio 指標の一覧については、istio.io 指標タイプをご覧ください。

可用性 SLI

Istio は、service/server/request_count 指標タイプと、次のモニタリング対象リソースタイプのいずれかを使用して、Cloud Monitoring に指標データを書き込みます。

データは、response_code 指標ラベルを使用してフィルタリングし、「良好」なリクエストと「合計」リクエストをカウントできます。また、destination_service_name 指標ラベルを使用して、特定の指標のリクエストをカウントすることもできます。

Istio サービス メッシュが管理する GKE 上で実行されているサービスに対してリクエスト ベースの可用性 SLI を表現する際は、次の例のようにリクエストの総数に対する良好なリクエストの TimeSeriesRatio 構造体を作成します。

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"istio.io/service/server/request_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"",
      "goodServiceFilter":
        "metric.type=\istio.io/server/response_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"
         metric.label.\"response_code\"<\"299\"",
    }
  }
}

レイテンシ SLI

レイテンシを測定するため、Istio では、service/server/response_latencies 指標タイプと次のいずれかのモニタリング対象リソースタイプを使用して、Cloud Monitoring に指標データを書き込みます。

データは、response_code 指標ラベルを使用してフィルタリングし、"good" and "total" requests. You can also use the destination_service_name| 指標ラベルを使用して特定のサービスのリクエスト数をカウントできます。

Istio サービス メッシュが管理する GKE で実行されているサービスに対してリクエスト ベースのレイテンシ SLI を表現する際は、DistributionCut 構造体を使用します。次の SLO の例では、frontend サービスに対するすべてのリクエストの 99% が 1 時間の移動枠内で合計レイテンシが 0~100 ミリ秒未満であることを期待しています。

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"istio.io/server/response_latencies\"
           resource.type=\"k8s_container\"
           metric.label.\"destination_service_name\"=\"frontend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}