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

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

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

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

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

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

Cloud Endpoints

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

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

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

Cloud 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_code や response_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 のオブザーバビリティに関する詳細については、次のリンク先をご覧ください。

Cloud Run のドキュメント。
run.googleapis.com 指標タイプのリスト。

可用性 SLI

Cloud Run は、cloud_run_revision モニタリング対象リソースタイプと request_count 指標タイプを使用して、Cloud Monitoring に指標データを書き込みます。データは、response_code や response_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_code や response_code_class の指標ラベルを使用してデータをフィルタリングできます。

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

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"run.googleapis.com/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 のオブザーバビリティの詳細については、次のリンク先をご覧ください。

Cloud Functions のドキュメント。
run.googleapis.com 指標タイプのリスト。

可用性 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 の詳細については、次のリンク先をご覧ください。

App Engine のドキュメント。
appengine.googleapis.com 指標タイプのリスト。

可用性 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 は、アドオン（Anthos Service Mesh）として 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"
}

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

Cloud Endpoints

可用性 SLI

レイテンシ SLI

Cloud Run

可用性 SLI

レイテンシ SLI

Cloud Functions

可用性 SLI

レイテンシ SLI

App Engine

可用性 SLI

レイテンシ SLI

GKE と Istio

可用性 SLI

レイテンシ SLI

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