Amazon Web Services ブログ

ロードバランサーキャパシティユニット（LCU）予約を活用したトラフィック急増への備え

本記事は 2025年1月28日に公開された Using Load Balancer Capacity Unit Reservation to prepare for sharp increases in traffic を翻訳したものです。

はじめに

このポストでは、Application Load Balancer と Network Load Balancer ( ALB と NLB )の新機能である、ロードバランサーキャパシティユニット予約( LCU 予約)について説明します。この機能により、新製品のローンチ、セール、トラフィックの移行など、計画されたイベントによるトラフィックの急増に備えることができます。 Elastic Load Balancers ( ELB )は、あらゆるワークロードをサポートするために自動的にスケーリングします。スケーリングについて考えるとき、2つの要素を検討する必要があります。スケーリングの速度と全体的なスケーリング容量です。LCU 予約機能は速度に関するもので、全体的な容量については大規模ワークロード向けの ELB スケーリングに関する別の記事をご覧ください。この記事では、LCU 予約の内容と使用方法について説明し、利用を開始するための次のステップを共有します。
LCU 予約機能がローンチされる以前は、イベントに備えてロードバランサーを事前にスケーリングするために、ユーザーはサポートケースを起票する必要がありました。LCU 予約機能により、サポートケースを開くことなく、ユーザーが直接ロードバランサーの容量を予約できるようになりました。
LCU 予約をいつどのように使用すべきかをよりよく理解するために、ELB 製品が動的にスケーリングする方法について説明します。ELB 製品の基盤となるインフラストラクチャの設計とスケーリングには、ALB 用と NLB 用の2つの異なるスケーリングシステムが使用されています。ELB のスケーリングシステム戦略についてすでにご存知の方は、LCU 予約のセクションからお読み下さい。

ELB スケーリング

ALB と NLB はどちらも検出されたトラフィック量に基づいて自動的にスケールしますが、それぞれ異なる基準を使用します。ALB はトラフィック（帯域幅、接続レート、同時接続数）を基準としてスケールし、さらに AWS WAF や AWS Lambda など、使用している機能に必要な追加の処理負荷も考慮します。一方、NLBは帯域幅を基準としてスケールします。
ALB と NLB の両方において、LCU 予約は提供される最小容量にのみ影響します。要求した容量を超えた追加のスケーリングを防止したりブロックしたりすることはできません。そのため、容量を設定した後もロードバランサーが依然としてスケールしていたとしても、心配する必要はありません。これはスケーリングシステムがワークロードを適切に処理しているということです。
ALB と NLB は異なるテクノロジーで構築されているため、スケールできるレートが異なります。次のセクションでは、各製品の詳細について簡単に説明します。

ALB スケーリング

ALB は事実上あらゆるワークロードに対応できるように拡張可能ですが、場合によっては影響範囲を減らすために、複数のロードバランサーに負荷を分散することを推奨します。このプロセスは ELB シャーディングと呼ばれており、詳細については「Elastic Load Balancingのスケーリング戦略」で確認できます。

ALB は現在のワークロードに合わせて自動的にスケールしますが、スケールアップ/アウトは積極的に行われる一方、スケールダウン/インは慎重に行われます。小規模なワークロードの場合、ALB はより大容量のノードを使用してスケールし(スケールアップ)、大規模なワークロードの場合は並行して動作するノードを追加することでスケールします(スケールアウト)。

ALB は5分以内にワークロードを2倍にサポートするようにスケールアップすることが期待できます。例えば、1 Gbps のトラフィックを処理している ALB は、5分以内に2 Gbps まで増加し、次の5分で4 Gbps まで増加するといった具合です。これは、新規接続のレートや同時接続の総数など、トラフィックの他の基準にも適用されます。

NLB スケーリング

NLB はほとんどのワークロードに対応できるよう拡張可能です。ただし、まれに特定のワークロードを複数のロードバランサーに分散させる必要がある場合があります。これは前述のとおり、ELBシャーディングと呼ばれ、「Elastic Load Balancingのスケーリング戦略」で詳細を確認できます。

NLB のスケーリングシステムは ALB とは異なる方式で動作します。NLB は、選択された各サブネット / アベイラビリティーゾーン(AZ) に対して、Hyperplane 上でバックグラウンドでは複数の大容量ノードによってサポートながら、1つの独立した Elastic Network Interface (ENI) として構成されます。これにより ENI の IP アドレスを静的に保つことができ、ALB とは異なり、IP アドレスを変更することなくクライアントに対して透過的にスケーリングすることができます。

NLB は帯域幅のあらゆる側面に基づいてスケーリングを行い、ワークロードに必要な容量を正確にプロビジョニングします。NLB は3 Gbps の帯域で起動し、1分あたり3 Gbps のペースで容量を増加させていきます。

LCU 予約とは？

前のセクションで説明したように、ELB のスケーリングシステムは、ワークロードの変化に素早く反応し、ほとんどのケースで増加に対応できる十分な容量を提供するように設計されています。しかし、大規模なトラフィックスパイクにより、想定される増加量よりも速くトラフィックが増加する状況が発生する可能性があります。LCU 予約機能は、このようなケースのために実装されました。

LCU予約は、季節性のイベント、イベントチケットの販売、新製品/機能のローンチ、人気番組の新エピソード公開などのイベントに備えて、事前に ELB をスケールするためのプロアクティブなメカニズムです。LCU 予約は、前のセクションで説明した ELB のリアクティブなスケーリングシステムと並行して動作し、ワークロードに十分な容量を提供します。

ALB および TCP や UDP リスナーを持つ NLB が、この新機能をサポートしています。

単一のイベントへの準備に加えて、LCU 予約は、トラフィックスパイクを予測できないユースケースに対して一定の最小容量を提供するためにも使用できます。推奨されるアプローチは、ELB シャーディングを使用することです。

どのように動作するか？

LCU 予約機能では、ロードバランサーの最小容量を設定し、予想されるトラフィックの急増に備えて、要求された容量を事前に確保することができます。最小容量が確保されると、スケーリングシステムは実際のトラフィックに基づいてロードバランサーの容量を増減し続けます。これらのスケーリング活動により、指定した最小容量を下回ることはありません。

図1: LCU 予約画面の使用状況グラフ

ALB の見積もりプロセスを合理化するため、AWS Management Console では PeakLCUs（図1）という新しいメトリクスを表示し、NLB については既存の ProcessedBytes メトリクスを1時間あたりの LCU 値に変換した LCU 使用量グラフを提供しています。PeakLCUs メトリクスは、ロードバランサーがワークロードをサポートするためにすべての基準でスケールする必要があるトラフィックパターンのピークを考慮します。これら2つのメトリクスは、特定期間におけるロードバランサーの使用状況を示します。同じワークロード / イベントが繰り返されると予想される場合、これらの値を LCU 予約フィールドへの直接的な入力として使用できます。

プロビジョニングする容量を判断する最も簡単な方法は、コンソールを通じて行うことです。すでに ALB またはNLBでワークロードを実行している場合、同様の負荷があった期間のメトリクスを使用し、予想されるトラフィックの増加に応じて乗数を適用することができます。

Amazon CloudWatch コンソールでメトリクスを使用することもできます。ALBの場合、可能であれば期間中のPeakLCUs の1分間の合計を確認して最高値を使用するか、1時間データポイントに対して以下の式を使用できます：PeakLCUs (最大) *（ PeakLCUs (サンプル数) * 60 / 期間( PeakLCUs )）。これに予想されるイベントの規模の増加を乗じます。例えば、5倍の負荷を予想する場合は、この値に5を掛けます。

NLB の場合、LCU 使用量メトリクスは2段階のプロセスで導出されます。最初のステップは、トラフィックをメガビット毎秒（Mbps）のレートに変換することです。これは ProcessedBytes メトリクスを次の式で変換することで可能です：ProcessedBytes (毎分) * 8/60/(10^6 )。2番目のステップは、得られた値を2.2で割ることです。2.2（Mbps）は1時間の間に転送される1GBに相当し、これは1 LCU に等しくなります。

必要な容量を計算する最良の方法は、ロードバランサーに対して負荷テストを実行し、その結果得られた PeakLCUs（ALB）または ProcessedBytes（NLB）メトリクスを前述の式と共に使用することです。

容量の計算には ConsumedLCUs メトリクスを使用しないことをお勧めします。これは請求目的のみを意図したものであり、容量の見積もりには前述のメトリクスのみを使用すべきです。

詳細については、ALB ドキュメントおよび NLB ドキュメントを参照してください。

LCU 予約をどう設定するか？

LCU 予約の設定は、コンソールまたは AWS Command Line Interface (AWS CLI) のいずれかを使用して行うことができます。

コンソールでは、ロードバランサーを選択し、新しい「Capacity」タブを開くことができます。この新しいセクションでは、選択したロードバランサーとその LCU 予約に関連する情報を確認できます。その後、図2に示すように「Edit LCU Reservation」ボタンを選択します。

図2: 「Capacity」タブ内の「Edit LCU Reservation」ボタン

これにより「Edit LCU Reservation」メニュー(図3)に移動し、過去の実績に基づく見積もりか手動見積もりのいずれかを選択できます。この例では、過去の実績に基づく見積もりを使用しており、これにより前回のイベント中のピーク LCU を確認することができます。そして、この指標を次のイベントに向けた準備の参考にできます。

図3: 予約済み LCU (緑色で表示)と、PeakLCUs 使用量のグラフ(赤色で表示)

詳細については、ALB ドキュメントおよび NLB ドキュメントを参照してください。

AWS CLI
[ALB/NLB] aws elbv2 modify-capacity-reservation –load-balancer-arn <ALB/NLB ARN> –minimum-load-balancer-capacity CapacityUnits=267

Output ALB

{
    "CapacityReservationState": [
        {
            "AvailabilityZone": "us-east-1a",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "us-east-1b",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "us-east-1c",
            "State": {
                "Code": "pending"
            }
        }
    ],
    "DecreaseRequestsRemaining": 2,
    "LastModifiedTime": "2024-11-13T23:58:08.613000+00:00",
    "MinimumLoadBalancerCapacity": {
        "CapacityUnits": 267
    }
}

Output NLB

{
    "CapacityReservationState": [
        {
            "AvailabilityZone": "eu-north-1a",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "eu-north-1b",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "eu-north-1c",
            "State": {
                "Code": "pending"
            }
        }
    ],
    "DecreaseRequestsRemaining": 2,
    "LastModifiedTime": "2024-11-13T23:32:55.002000+00:00",
    "MinimumLoadBalancerCapacity": {
        "CapacityUnits": 9000
    }
}

予約済み容量がいつから使用可能になるかをどう知るか?

予約済み容量がいつから使用可能になるかは、コンソールまたはAWS CLI のいずれかを使用して確認できます。

コンソールでは、ロードバランサーを選択して「Capacity」タブを開ます。予約ステータスでは、図4に示すように、リクエストが正常に完了し、「Provisioned」ステータスになっていることが確認できます。

図4:「Capacity」タブに表示されるLCU予約状況

詳細は ALB ドキュメントおよび NLB ドキュメントを参照して下さい。

AWS CLI
[ALB/NLB] aws elbv2 describe-capacity-reservation –load-balancer-arn <ALB/NLB ARN>
Output ALB

{
    "CapacityReservationState": [
        {
            "AvailabilityZone": "us-east-1a",
            "EffectiveCapacityUnits": 89.0,
            "State": {
                "Code": "provisioned"
            }
        },
        {
            "AvailabilityZone": "us-east-1b",
            "EffectiveCapacityUnits": 89.0,
            "State": {
                "Code": "provisioned"
            }
        },
        {
            "AvailabilityZone": "us-east-1c",
            "EffectiveCapacityUnits": 89.0,
            "State": {
                "Code": "provisioned"
            }
        }
    ],
    "DecreaseRequestsRemaining": 2,
    "LastModifiedTime": "2024-11-13T23:53:04.690000+00:00",
    "MinimumLoadBalancerCapacity": {
        "CapacityUnits": 267
    }
}

Output NLB

{
    "CapacityReservationState": [
        {
            "AvailabilityZone": "eu-north-1a",
            "EffectiveCapacityUnits": 3000.0,
            "State": {
                "Code": "provisioned"
            }
        },
        {
            "AvailabilityZone": "eu-north-1b",
            "EffectiveCapacityUnits": 3000.0,
            "State": {
                "Code": "provisioned"
            }
        },
        {
            "AvailabilityZone": "eu-north-1c",
            "EffectiveCapacityUnits": 3000.0,
            "State": {
                "Code": "provisioned"
            }
        }
    ],
    "DecreaseRequestsRemaining": 2,
    "LastModifiedTime": "2024-11-13T23:32:55.002000+00:00",
    "MinimumLoadBalancerCapacity": {
        "CapacityUnits": 9000
    }
}

LCU 予約を削除するには？

LCU予約はコンソールまたは AWS CLI のいずれかを使用して削除できます。

コンソールでは、ロードバランサーを選択し、「Capacity」タブを開きます。アクティブな LCU 予約がある場合は、図5に示すように「Cancel capacity」ボタンで予約をキャンセルすることができます。

図5: LCU 予約がセットされ、「Cancel capacity」が有効になっている

詳細は ALB ドキュメントおよび NLB ドキュメントを参照して下さい。

AWS CLI
[ALB/NLB] aws elbv2 modify-capacity-reservation –load-balancer-arn <ALB/NLB ARN> –reset-capacity-reservation
Output ALB

{
    "CapacityReservationState": [
        {
            "AvailabilityZone": "us-east-1a",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "us-east-1b",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "us-east-1c",
            "State": {
                "Code": "pending"
            }
        }
    ],
    "DecreaseRequestsRemaining": 1,
    "LastModifiedTime": "2024-11-13T23:58:08.613000+00:00",
    "MinimumLoadBalancerCapacity": {
        "CapacityUnits": 0
    }
}

Output NLB

{
    "CapacityReservationState": [
        {
            "AvailabilityZone": "eu-north-1a",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "eu-north-1b",
            "State": {
                "Code": "pending"
            }
        },
        {
            "AvailabilityZone": "eu-north-1c",
            "State": {
                "Code": "pending"
            }
        }
    ],
    "DecreaseRequestsRemaining": 1,
    "LastModifiedTime": "2024-11-13T23:58:08.613000+00:00",
    "MinimumLoadBalancerCapacity": {
        "CapacityUnits": 0
    }
}

考慮事項

  • LCU 予約機能は、トラフィックがスケーリングシステムの対応速度を上回って増加する可能性がある場合に、短時間使用することを想定しています。数時間程度の短期間、あるいは場合によっては数日間といった期間での設定を想定しています。
  • 予測不可能な使用量のスパイクがあるユースケースでは、シャーディングがより適切でコスト効率の良い長期的な戦略となる可能性があります。複数のロードバランサーを使用して受信ワークロードを分散させることで、各ロードバランサーに全体のトラフィックの一部を割り当てることができます。このアプローチは、複数のロードバランサーによる同時スケーリング機能の恩恵も受けられます。
  • LCU 予約は予約した容量に対して課金されます。例えば、1時間に100 LCU を予約し、その1時間常に120 LCU を使用した場合、20 LCU は標準の LCU 料金で、100 LCU は予約 LCU 料金で課金されます。
  • LCU 予約容量はリージョンレベルで予約され、AZ 間で均等に分散されます。各 AZ に同数のターゲットをプロビジョニングし、登録されたターゲットのない AZ がないようにすることを推奨します。
  • LCU 予約を使用する場合、常にロードバランサーレベルで設定を行い、ELB システムは希望する容量をすべてのアクティブな AZ 間で均等にプロビジョニングします。登録されたターゲットのない AZ はプロビジョニングプロセスに含まれません。ただし、ELB システムは残りの AZ で要求を完全に満たすのに十分な容量をプロビジョニングします。
  • ロードバランサーに LCU 予約を設定すると、ロードバランサー専用の追加容量がプロビジョニングされます。プロビジョニングされた容量は LCU 予約料金として課金されます。そのため、正確な容量見積もりが必要であり、イベント終了後や不要になった時点でプロビジョニングした容量を削除する必要があります。
  • LCU 予約は、契約上の義務/SLA/ポリシー要件により、常に最小容量を確保する必要があるユースケースにも使用できます。ただし、その容量の大部分が高頻度で使用されない場合は、事前にコストを見積もる必要があります。

結論

LCU 予約は、ロードバランサーの最小容量をユーザーがより柔軟にコントロールできる新機能です。季節性のイベント、セールスプロモーション、新製品・新機能のローンチなどに伴う突発的な大規模トラフィックに備えて、事前に容量を増やすことができます。
LCU 予約は、ELB のスケーリングシステムと並行して動作します。最適な利用のためには、動的スケーリングと LCU 予約を組み合わせて理解することをお勧めします。
ELB は、LCU 予約が設定されている間も必要に応じて容量を増加させ続けますが、予約された LCU よりも低い容量にはなりません。
シャーディングがより適切な選択肢となる可能性がある場合については、AWSの投稿「Elastic Load Balancingのスケーリング戦略」を確認することをお勧めします。

翻訳は Solutions Architect の山本 大貴が担当しました。原文はこちらです。