皆さん、こんにちは。ITサービス＆エンジニアリング事業本部（以下、ITS＆E）クラウドプラットフォーム事業部の五味 なぎさです。私が所属する部署はクラウドサービス事業の拡大をミッションとしており、当社が提供するマネージドクラウドサービスabsonne（アブソンヌ）の企画・運営・提案・導入や、Amazon Web Services（以下、AWS）、Microsoft Azure（以下、Azure）、Google Cloud、Oracle Cloud Infrastructure（以下、OCI）等のパブリッククラウドサービスを利用したシステムの提案・設計・導入を推進しています。前回はAWSの最新情報を入手すべく現地まで赴いたre:Invent 2024の参加レポートブログを公開していますので、まだご覧になっていない方はぜひこちらも併せて読んでみてください。
さてre:Invent 2024の開催直前に発表されたApplication Load Balancer（ALB）と Network Load Balancer（NLB）のキャパシティユニット予約機能について今回は取り上げたいと思います。re:Invent2024のイベントセッションでも何度か言及されましたね。ネット上での購買が当たり前になって久しい昨今、チケットのオンライン販売やデジタルキャンペーン開催時にWEBサイトが落ちてしまったというニュースをよく耳にします。こうした、予測されるトラフィックの急増に対して、ALB/NLBを利用する際にできる対策を今回のブログでは解説します。具体的には、トラフィック急増に備えるための事前準備と、ALB/NLBのキャパシティユニット予約機能の利用方法についてお伝えしますので、デジタルサービスの品質向上に向けて、ご参考になれば幸いです。
※今回はALB/NLBのキャパシティユニット予約機能に関連した話になるため、サーバレス構成ではなく、VPC内にリソースを作成しサービス提供する構成を前提とします。
緩やかにトラフィックが増加する場合、通常はあまり意識することなくトラフィック処理が出来てしまいます。なぜなら、コンピュートリソース（Amazon EC2、AWS Fargate等）についてはAuto Scale機能が利用でき、ALBやNLBは内部的にスケールされるためです。一方で、オンラインチケット販売やデジタルキャンペーン等で特定の時間に急激にトラフィックが増加する場合、リソースの増加がトラフィックの流入に間に合わずリソース増加が完了するまでエラーが発生する、もしくは最悪の場合、処理の滞留により復旧までに時間がかかる事態が発生します。そういった事態を回避するためにも、事前準備は必要不可欠です。事前準備内容は、コンポーネント種別に応じて大きく3種類に分けられます。
横にスクロールできます
リソース系について、時間指定でのNodeのScalingや、RDS、Amazon Auroraであればリードレプリカの増台、DBのWrite性能の向上が必要であればスケールアップなどの対応が挙げられます。パラメータ系については、予め利用サービスのService Quotasを確認し、処理能力に影響するパラメータがあれば必要に応じて緩和申請を行います。
そして、申請系についてが、今回のアップデートに関連する内容です。ALB/NLBでは、基本的には負荷に応じて内部でスケールアップ/アウトが余裕をもって行われています。re:Invent 2024のセッションで語られた話によると、CPU使用率が35％以上、Targetあたりのリクエスト数が50を超えるとスケールアップ/アウトされる仕組みになっているそうです。セッションの詳細は下記リンクから確認してください。
しかし、そのペースを超えるトラフィックの流入が予想される場合、予めALB/NLBのリソースを増やしておく必要があります。これまではALBについてはPre-warming（暖機）申請を行い、AWSサポートの方とやり取りしながら暖機に必要な対応を行う必要がありました（NLBは仕組み上ALBよりも突発負荷に強いアーキテクチャのため、暖機申請を行う仕組み自体が無かった）。しかし、re:Invent 2024期間に発表されたアップデートにより、キャパシティユニット予約が可能になったことで、ユーザ側での対応が容易になりました。
ALB/NLBキャパシティユニット予約の流れは以下の通りです。
※ALB/NLBで特定のリクエスト数やトラフィック量を処理できる単位
以下に、手順の概要を説明していきます。
必要なLCUの見積方法としては、負荷テストや実際の過去のワークロードを元に試算する方法が挙げられます。今回LCU予約機能の追加と合わせてAWS Managed ConsoleのALB/NLBの画面から、ALBの場合はPeakLCUsというメトリクス値が、NLBの場合は既存のProcessedBytesメトリクスを1時間あたりのLCU値に変換したLCU使用量グラフが、それぞれ表示可能になり、見積が容易になりました。
初めてLCU予約を行う場合、Service Quotasの緩和が必要になります。LCU予約を実施するALB/NLBと同じリージョンを指定し、Service Quotasを緩和します。Service Quotasの申請画面に直接アクセスも可能ですが、ALB/NLBのキャパシティ予約画面から遷移することも可能です。
ALBの場合は「Reserved Application Load Balancer Capacity Units (LCU) per Region」の引き上げを、NLBの場合は「Reserved Network Load Balancer Capacity Units (LCU) per Region」の引き上げを申請します。なお、Gateway Load Balancerについては現状LCU予約に対応していませんが、re:Invent 2024のセッション※内でロードマップとして予定されている話がありました。
※Optimizing ELB traffic distribution for high availability (NET401)
実際にLCU予約を行います。
1.で負荷テストや実際の過去のワークロードを元に試算済みの場合は、推奨されるLCUレベルが表示されるため、その値を利用することが可能です（図5参照）。
負荷テストなどの実施が難しく、参考とするワークロードがAWS上で把握できていない場合は、図6のようにManual estimateを選択し、手動でLCUの値を入力します。
双方のケースにおいて、LCU数が入力されるとSummary画面に図7のようにAZ毎のLCU数が表示されます。また、Redundancy（冗長）設定を有効にしていると、耐障害性を考慮したLCU数が確保されます。
最後に図7の画面下部右側の“保存”ボタンを押下することで、LCU予約手順は完了です。予約が完了すると、ALB/NLBのキャパシティタブの“Reservation Status”が“provisioned”になります。なお、ピーク負荷が落ち着き、リソースが不要になったタイミングでLCU予約をキャンセルする必要がありますので忘れず対応するようにしてください。
今回の記事では、ALB/NLBのキャパシティユニット予約機能について詳しく解説しました。これにより、予測されるトラフィックの急増に対する事前準備が容易になり、サービスの安定性が向上します。今回の記事が皆様の何らかのお力になると嬉しいです。今後もAWSに関する最新の技術情報をお届けしていきますのでぜひご期待ください。
なお、当社ではAWS包括的技術支援サービスを提供しています。AWSへの移行でお悩み等ございましたら、ぜひ本サービスもご活用ください。その他、AWSをはじめマルチクラウド化に関するご相談全般はこちらからお気軽にお声がけください！
加えて、お客様のクラウドネイティブ化を包括的に支援する新サービス「CloudHarbor（クラウド・ハーバー）」も提供しております。クラウド移行に留まらず、クラウドネイティブ化にもご興味ある方はぜひCloudHarborカタログも併せてご覧ください！それでは、また次回もお楽しみにお待ちください！
