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

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

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

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

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

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

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

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

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

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

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

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

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

• マネージド インスタンス グループ
• GCE_VM_IP_PORT エンドポイントを使用するゾーン NEG
• ハイブリッド接続 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

  mem_utilization、cpu_utilization、application_utilization の各指標の値は 0.0 - 1.00 の範囲内ですが、リソース使用量が予算を超えるシナリオでは 1.00 を超えることがあります。

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

  orca.named_metrics.METRIC_NAME
  

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

  CUSTOM_METRICS バランシング モード用に定義された名前付き指標には、0 - 100 の範囲内の値が含まれます。WEIGHTED_ROUND_ROBIN ロード バランシング局所性ポリシーに定義された名前付き指標に、想定される範囲がありません。

必要な指標

ロードバランサでバックエンド VM インスタンス グループまたはネットワーク エンドポイント グループの選択にカスタム指標を使用するようにするには、ロードバランサに送信される ORCA 負荷レポートで、次の使用率指標の 1 つ以上を指定する必要があります。orca.named_metrics は、名前と値のペアの形式のユーザー定義指標のマップです。

• orca.cpu_utilization
• orca.application_utilization
• orca.mem_utilization
• orca.named_metrics

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

• orca.rps_fractional（1 秒あたりのリクエスト数）
• orca.eps（エラー数/秒）
• 使用率指標（優先順位は次のとおりです）。
  1. orca.application_utilization
  2. orca.cpu_utilization
  3. 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

  プロトコル バッファ対応コードの場合、これは 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_SERVICE_NAME: バックエンド サービスの名前
   • NEG_NAME: ゾーンまたはハイブリッド NEG の名前
   • NEG_ZONE: NEG が作成されたゾーン
   • REGION: リージョン ロードバランサの場合、ロードバランサが作成されたリージョン
   • 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 に設定しても、ロードバランサには影響しません。

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 フィールドを使用して、指標ファイルをバックエンド サービスに接続します。

次のステップ

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