アプリケーション ロードバランサのカスタム指標

Preview

This product or feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA products and features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

このページでは、アプリケーション ロードバランサでカスタム指標を使用する方法について説明します。カスタム指標を使用すると、 Google Cloudの標準の使用率またはレートベースの指標ではなく、アプリケーションまたはインフラストラクチャの要件に固有の指標に基づいて、ロードバランサのトラフィック分散動作を構成できます。ロードバランサにカスタム指標を定義すると、ワークロードに最適なバックエンド インスタンスとエンドポイントにアプリケーション リクエストを柔軟に転送できます。

ロードバランサは、カスタム指標の値を使用して次の決定を行います。

1. トラフィックを受信するバックエンド VM インスタンス グループまたはネットワーク エンドポイント グループを選択します。
2. トラフィックを受信する VM インスタンスまたはエンドポイントを選択します。

カスタム指標を使用したロード バランシング（クリックして拡大）

カスタム指標のユースケースの例を次に示します。

• リージョン アフィニティやネットワーク レイテンシなどのデフォルトの条件ではなく、アプリケーションに最も関連性の高いカスタム指標に基づいてロード バランシングを決定することで、グローバル コンピューティング容量を最大限に活用します。

  アプリケーションでバックエンドの処理レイテンシが秒単位で発生する場合は、ネットワーク レイテンシではなくカスタム指標に基づいてリクエストをロード バランシングすることで、グローバル コンピューティング容量をより効率的に使用できます。

• デプロイに固有の指標の組み合わせに基づいてロード バランシングを決定することで、コンピューティング効率を最大化します。たとえば、リクエストの処理時間とコンピューティング要件が大きく変動するシナリオについて考えてみましょう。このようなシナリオでは、1 秒あたりのリクエスト数に基づいてロード バランシングを行うと、負荷が不均等に分散されます。このような場合は、コンピューティング フリートを利用を最大限に効率化するために、リクエストのレートと CPU または GPU 使用率の両方の組み合わせに基づいて負荷を分散するカスタム指標を定義することをおすすめします。

• アプリケーションの要件に最も関連性のあるカスタム指標に基づいてバックエンドを自動スケーリングします。たとえば、構成したカスタム指標が 80% を超えたときにバックエンド インスタンスを自動スケーリングするように自動スケーリング ポリシーを定義できます。これは、トラフィック ベースの自動スケーリング指標（autoscaling.googleapis.com|gclb-capacity-fullness）を使用して実現されます。詳細については、ロードバランサのトラフィックに基づく自動スケーリングをご覧ください。

サポートされているロードバランサとバックエンド

カスタム指標は、次のアプリケーション ロードバランサでサポートされています。

• グローバル外部アプリケーション ロードバランサ
• リージョン外部アプリケーション ロードバランサ
• クロスリージョン内部アプリケーション ロードバランサ
• リージョン内部アプリケーション ロードバランサ

カスタム指標は、次のバックエンド タイプでサポートされています。

• マネージド インスタンス グループ
• ゾーン NEG（GCE_VM_IP_PORT エンドポイント）
• ハイブリッド接続 NEG

カスタム指標の仕組み

ロードバランサがカスタム指標に基づいてトラフィック分散の決定を行うようにするには、まず、特定のアプリケーションに最も関連性の高い指標を決定する必要があります。使用する指標が決まったら、これらの指標をロードバランサに安定して報告するようにバックエンドを構成します。 Google Cloud を使用すると、バックエンドからロードバランサに送信される各 HTTP レスポンスのヘッダーの一部として指標を報告できます。これらの指標はカスタム HTTP レスポンス ヘッダーにカプセル化され、Open Request Cost Aggregation（ORCA）標準に準拠する必要があります。

指標は次の 2 つのレベルで構成できます。

• バックエンド レベルで、バックエンド（MIG または NEG）の選択に影響する
• バックエンド サービス レベルで、VM インスタンスまたはエンドポイントの選択に影響する

以降のセクションでは、カスタム指標の仕組みについて説明します。

ロード バランシングの決定に影響を与えるカスタム指標を決定する

ロード バランシング決定に影響を与えるカスタム指標を決定することは、非常に主観的であり、アプリケーションのニーズに基づいています。たとえば、アプリケーションのバックエンド処理のレイテンシが数秒の場合、標準のネットワーク レイテンシではなく、他のカスタム指標に基づいてリクエストをロード バランシングすることをおすすめします。

使用する指標を決定したら、各指標の最大使用率しきい値も決定する必要があります。たとえば、メモリ使用率を指標として使用する場合は、各バックエンドの最大メモリ使用率のしきい値も決定する必要があります。

たとえば、example-custom-metric という指標を構成し、最大使用率しきい値を 0.8 に設定すると、ロードバランサはバックエンド間のトラフィック分散を動的に調整し、バックエンドから報告される example-custom-metric 指標を可能な限り 0.8 未満に保ちます。

使用できるカスタム指標には次の 2 種類があります。

• 予約済み指標。予約済みの指標名は 5 つあります。これらの名前は、ORCA API のトップレベルの事前定義フィールドに対応しているため予約されています。

  • orca.cpu_utilization
  • orca.mem_utilization
  • orca.application_utilization
  • orca.eps
  • orca.rps_fractional

• 名前付き指標 これらは、次の形式で ORCA named_metrics フィールドを使用して指定する、アプリケーションに固有の指標です。

  orca.named_metrics.METRIC_NAME
  

  ユーザー定義のカスタム指標はすべて、この named_metrics マップを使用して、名前と値のペアの形式で指定します。

必須の指標

ロードバランサでバックエンド VM インスタンス グループまたはネットワーク エンドポイント グループの選択にカスタム指標を使用するようにするには、ロードバランサに送信される ORCA ロードレポートで、次のリストから次の使用率指標の少なくとも 1 つを指定する必要があります。

• orca.cpu_utilization、または
• orca.application_utilization、または
• orca.mem_utilization、または
• orca.named_metrics: 名前と値のペアの形式でユーザー定義指標のマップ。

また、ロードバランサがカスタム指標を使用してバックエンド VM インスタンスまたはエンドポイントの選択にさらに影響を与えるようにするには、ロードバランサに送信される ORCA 負荷レポートで次の指標をすべて指定する必要があります。ロードバランサは、これらの報告された指標から計算された重みを使用して、個々のバックエンドに負荷を割り当てます。

• orca.rps_fractional（1 秒あたりのリクエスト数）
• orca.eps（1 秒あたりのエラー数）、
• 使用率指標（優先順位は次のとおりです）。
  • orca.application_utilization
  • orca.cpu_utilization
  • orca.named_metrics マップのユーザー定義の指標

追加情報:

• バックエンドごとに作成できるカスタム指標の上限は 2 つです。ただし、最大 3 つのカスタム指標を使用して dryRun テストを実行できます。

  2 つの指標が指定されている場合、ロードバランサはこれらを個別に処理します。たとえば、2 つのディメンション（custom-metric-util1 と custom-metric-util2）を定義すると、ロードバランサはこれらを個別に処理します。バックエンドが custom-metric-util1 の使用率が高い状態で実行されている場合、ロードバランサはバックエンドへのトラフィックの送信を回避します。通常、ロードバランサは、すべてのバックエンドをほぼ同じフルネスで実行しようとします。満腹度は currentUtilization ÷ maxUtilization として計算されます。この場合、ロードバランサは、2 つの指標によって報告された 2 つのフルネス値のうち大きい値を使用して、ロード バランシングを決定します。

• バックエンド サービスごとに 2 つのカスタム指標に制限されています。ただし、最大 3 つのカスタム指標を使用して dryRun テストを実行できます。この上限には、必須の orca.eps 指標と orca.rps_fractional 指標は含まれません。この上限は、バックエンド レベルで構成された指標とは関係ありません。

• 予約済み指標と名前付き指標の両方を一緒に使用できます。たとえば、orca.cpu_utilization = 0.5 と orca.named_metrics.queue_depth_util = 0.2 などのカスタム指標を 1 つの負荷レポートで指定できます。

• カスタム指標名には、規制対象、機密性の高い、個人を特定できる情報、または組織の外部の人が閲覧できないその他の機密情報を含めないでください。

カスタム指標の指定で使用できるエンコード

• JSON

  負荷レポートの JSON エンコードのサンプル:

  endpoint-load-metrics-json: JSON {"cpu_utilization": 0.3, "mem_utilization": 0.8, "rps_fractional": 10.0, "eps": 1, "named_metrics": {"custom-metric-util": 0.4}}.
  

• バイナリ Protobuf

  Protocol Buffers 対応コードの場合、これは endpoint-load-metrics-bin または endpoint-load-metrics: BIN のいずれかにある、バイナリ シリアル化された base64 エンコードの OrcaLoadReport protobuf です。

• ネイティブ HTTP

  endpoint-load-metrics 内の Key-Value ペアはカンマ区切りです。これは、OrcaLoadReport のフラット化されたテキスト表現です。

  endpoint-load-metrics: TEXT cpu_utilization=0.3, mem_utilization=0.8, rps_fractional=10.0, eps=1, named_metrics.custom_metric_util=0.4
  

• gRPC

  gRPC 仕様では、endpoint-load-metrics-bin キーを使用して末尾のメタデータを使用して指標を指定する必要があります。

カスタム指標をレポートするバックエンド構成

ロードバランサで使用する指標を決定したら、必要なカスタム指標を ORCA ロードレポートにコンパイルし、ロードバランサに送信される各 HTTP レスポンス ヘッダーでその値を報告するようにバックエンドを構成します。

たとえば、バックエンドのカスタム指標として orca.cpu_utilization を選択した場合、そのバックエンドは、ロードバランサに送信される各パケットで現在の CPU 使用率をロードバランサに報告する必要があります。手順については、このページのロードバランサに指標を報告するをご覧ください。

カスタム指標をサポートするロードバランサの構成

バックエンドから報告されたカスタム指標値を使用してロードバランサがトラフィック分散の決定を行うようにするには、各バックエンドのバランスモードを CUSTOM_METRICS に設定し、バックエンド サービスのロード バランシング ローカリティー ポリシーを WEIGHTED_ROUND_ROBIN に設定する必要があります。

カスタム指標がアプリケーション ロードバランサでどのように機能するか（クリックして拡大）

• CUSTOM_METRICS バランシング モード。バックエンド サービスの各バックエンドは、CUSTOM_METRICS 分散モードを使用するように構成する必要があります。バックエンドが CUSTOM_METRICS バランシング モードで構成されている場合、ロードバランサは、各カスタム指標に構成された最大使用率しきい値に従って、バックエンドにトラフィックを転送します。

  各バックエンドで、レポートする指標のセットを指定できます。バックエンドごとに複数のカスタム指標が構成されている場合、ロードバランサは、すべての指標が構成された最大使用率の上限を下回るようにトラフィックを分散しようとします。

  トラフィックは、選択したロード バランシング アルゴリズムに基づいてバックエンド間でロード バランシングされます。たとえば、デフォルトの WATERFALL_BY_REGION アルゴリズムは、すべてのバックエンドを同じフルネスで実行しようとします。

• WEIGHTED_ROUND_ROBIN ロード バランシングの局所性ポリシー。バックエンド サービスのロード バランシング局所性ポリシーは WEIGHTED_ROUND_ROBIN に設定する必要があります。この構成では、ロードバランサはカスタム指標を使用して、バックエンド内でリクエストを処理するための最適なインスタンスまたはエンドポイントも選択します。

カスタム指標を構成する

アプリケーション ロードバランサがカスタム指標に基づいてロード バランシングの決定を行うようにするには、次の操作を行います。

1. 使用するカスタム指標を決定します。
2. カスタム指標をロードバランサに報告するようにバックエンドを構成します。ロード バランシング決定に使用するために、ロードバランサに送信できるデータのストリームを確立する必要があります。これらの指標は、ORCA ロードレポートでコンパイルしてエンコードし、HTTP レスポンス ヘッダーを使用してロードバランサに報告する必要があります。
3. バックエンドから報告されるカスタム指標値を使用するようにロードバランサを構成します。

カスタム指標を決定する

このステップは、独自のアプリケーションのニーズに基づいて非常に主観的です。使用する指標を決定したら、各指標の最大使用率しきい値も決定する必要があります。たとえば、メモリ使用率を指標として使用する場合は、各バックエンドの最大メモリ使用率のしきい値も決定する必要があります。

ロードバランサの構成に進む前に、カスタム指標の仕組みのセクションで、使用可能なカスタム指標のタイプ（予約済みと名前付き）と指標の選択要件を確認してください。

ロードバランサに指標を報告するようにバックエンドを構成する

カスタム指標は、ORCA 標準を使用して、アプリケーション バックエンドからの各 HTTP レスポンスの一部としてロードバランサに報告されます。このセクションでは、ORCA ロードレポートでカスタム指標をコンパイルし、ロードバランサに送信される各 HTTP レスポンス ヘッダーでこれらの指標をレポートする方法について説明します。

たとえば、HTTP テキスト エンコードを使用している場合、ヘッダーは次の形式で指標を報告する必要があります。

endpoint-load-metrics: TEXT BACKEND_METRIC_NAME_1=BACKEND_METRIC_VALUE_1,BACKEND_METRIC_NAME_2=BACKEND_METRIC_VALUE_2

使用するエンコード形式に関係なく、負荷レポートを作成するときに指標名から orca. 接頭辞を削除してください。

次のコード スニペットは、2 つのカスタム指標（customUtilA と customUtilB）を HTTP ヘッダーに追加する方法を示しています。このコード スニペットは、ネイティブ HTTP テキスト エンコードと base64 エンコードの両方を示しています。この例では、わかりやすくするために customUtilA と customUtilB の値をハードコードしています。ロードバランサは、ロード バランシングに影響を与えると判断した指標の値を受信する必要があります。

...
type OrcaReportType int

const (
        OrcaText OrcaReportType = iota
        OrcaBin
)

type HttpHeader struct {
        key   string
        value string
}

const (
        customUtilA = 0.2
        customUtilB = 0.4
)

func GetBinOrcaReport() HttpHeader {
        report := &pb.OrcaLoadReport{
                NamedMetrics: map[string]float64{"customUtilA": customUtilA, "customUtilB": customUtilB}}
        out, err := proto.Marshal(report)
        if err != nil {
                log.Fatalf("failed to serialize the ORCA proto: %v", err)
        }
        return HttpHeader{"endpoint-load-metrics-bin", base64.StdEncoding.EncodeToString(out)}
}

func GetHttpOrcaReport() HttpHeader {
        return HttpHeader{
                "endpoint-load-metrics",
                fmt.Sprintf("TEXT named_metrics.customUtilA=%.2f,named_metrics.customUtilB=%.2f",
                        customUtilA, customUtilB)}
}

func GetOrcaReport(t OrcaReportType) HttpHeader {
        switch t {
        case OrcaText:
                return GetHttpOrcaReport()
        case OrcaBin:
                return GetBinOrcaReport()
        default:
                return HttpHeader{"", ""}
        }
}
...

カスタム指標を使用するようにロードバランサを構成する

ロードバランサがバックエンドの選択時にこれらのカスタム指標を使用するようにするには、各バックエンドのバランシング モードを CUSTOM_METRICS に設定する必要があります。また、カスタム指標をエンドポイントの選択にも反映させる場合は、ロード バランシング ローカリティー ポリシーを WEIGHTED_ROUND_ROBIN に設定します。

このセクションで説明する手順は、ゾーン NEG バックエンドを使用するロードバランサがすでにデプロイされていることを前提としています。ただし、ここで説明した --custom-metrics フラグを使用して、gcloud compute backend-services update コマンドを使用して既存のバックエンドを更新できます。

1. バックエンド サービスにバックエンドを追加するときに、バックエンドの分散モードを CUSTOM_METRICS に設定できます。--custom-metrics フラグを使用して、カスタム指標とロード バランシング決定に使用するしきい値を指定します。

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --network-endpoint-group=NEG_NAME \
     --network-endpoint-group-zone=NEG_ZONE \
     [--global | region=REGION] \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics='name="BACKEND_METRIC_NAME_1",maxUtilization=MAX_UTILIZATION_FOR_METRIC_1' \
     --custom-metrics='name="BACKEND_METRIC_NAME_2",maxUtilization=MAX_UTILIZATION_FOR_METRIC_2'
   

   次のように置き換えます。

   • BACKEND_METRIC_NAME: ここで使用するカスタム指標名は、バックエンドの ORCA レポートで報告されるカスタム指標名と一致している必要があります。
   • MAX_UTILIZATION_FOR_METRIC: ロード バランシング アルゴリズムが各指標でターゲットに設定する最大使用率。

   たとえば、バックエンドが 2 つのカスタム指標（customUtilA と customUtilB）を報告している場合（ロードバランサに指標を報告するようにバックエンドを構成するで説明されているように）、次のコマンドを使用して、これらの指標を使用するようにロードバランサを構成します。

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --network-endpoint-group=NEG_NAME \
     --network-endpoint-group-zone=NEG_ZONE \
     [--global | region=REGION] \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics='name="customUtilA",maxUtilization=0.8' \
     --custom-metrics='name="customUtilB",maxUtilization=0.9'
   

   または、構造化 JSON ファイルでカスタム指標のリストを指定することもできます。

   {
   "name": "METRIC_NAME_1",
   "maxUtilization": MAX_UTILIZATION_FOR_METRIC_1,
   "dryRun": true
   }
   {
   "name": "METRIC_NAME_2",
   "maxUtilization": MAX_UTILIZATION_FOR_METRIC_2,
   "dryRun": false
   }

   次のように、JSON 形式の指標ファイルをバックエンドに接続します。

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --network-endpoint-group=NEG_NAME \
     --network-endpoint-group-zone=NEG_ZONE \
     [--global | region=REGION] \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics-file='BACKEND_METRIC_FILE_NAME'
   

   ロードバランサに実際に影響を与えることなく指標が報告されているかどうかをテストするには、指標を構成するときに dryRun フラグを true に設定します。

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --network-endpoint-group=NEG_NAME \
     --network-endpoint-group-zone=NEG_ZONE \
     [--global | region=REGION] \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics 'name="BACKEND_METRIC_NAME",maxUtilization=MAX_UTILIZATION_FOR_METRIC,dryRun=true'
   

   dryRun が true に設定された指標が構成されている場合、その指標は Monitoring に報告されますが、ロードバランサで実際に使用されることはありません。

   この設定を元に戻すには、dryRun フラグを false に設定してバックエンド サービスを更新します。

   gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
     --network-endpoint-group=NEG_NAME \
     --network-endpoint-group-zone=NEG_ZONE \
     [--global | region=REGION] \
     --balancing-mode=CUSTOM_METRICS \
     --custom-metrics 'name="BACKEND_METRIC_NAME",maxUtilization=MAX_UTILIZATION_FOR_METRIC_,dryRun=false'
   

   すべてのカスタム指標が dryRun が true に設定されている状態で構成されている場合、バランシング モードを CUSTOM_METRICS に設定したり、ロード バランシング局所性ポリシーを WEIGHTED_ROUND_ROBIN に設定したりしても、ロードバランサには影響しません。

   注: --clear-custom-metrics など、gcloud compute backend-services update-backend コマンドでサポートされている他のフラグについては、gcloud compute backend-services update-backend リファレンス ページをご覧ください。

2. カスタム指標を使用してエンドポイントの選択に影響を与えるようにロードバランサを構成するには、バックエンド サービスのロード バランシング局所性ポリシーを WEIGHTED_ROUND_ROBIN に設定します。

   たとえば、適切なバックエンドですでに構成されているバックエンド サービスがある場合は、次のようにロード バランシング局所性ポリシーを構成します。

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
     [--global | region=REGION] \
     --custom-metrics='name=BACKEND_SERVICE_METRIC_NAME,dryRun=false' \
     --locality-lb-policy=WEIGHTED_ROUND_ROBIN
   

   バックエンド レベルの指標で示したように、バックエンド サービス レベルで構造化された JSON ファイルにカスタム指標のリストを指定することもできます。--custom-metrics-file フィールドを使用して、指標ファイルをバックエンド サービスに接続します。

次のステップ

• 外部アプリケーション ロードバランサのトラブルシューティング
• 内部アプリケーション ロードバランサのトラブルシューティング