はじめに
Elastic Load Balancing(以下：ELB)の種類のひとつにApplication Load Balancer(以下:ALB)があるのはご存知だと思います。
このALBにはトラフィック量に応じて自動的にスケールされるという特徴があります。
しかし、スケールアップ、スケールアウトが行われるには時間がかかるため、突発的に大量のトラフィックがきた場合にはALB側の処理が詰まってしまうことがあります。
そのため、急激なトラフィックが予想される場合には1~2週間前にAWSのサポートへ暖気の申請をしなければなりません。
暖気申請を行うことで、事前にALBのサイズを大きくすることができます。
しかし暖気申請はどの程度のトラフィックが予想されるときに出せば良いのかいまいち判断が難しいです。
というのも、利用している環境に応じてALBのサイズは変わってきますし、今動いているALBがどのくらいのパフォーマンスを持っているか知ることはできません。
基本的には普段のトラフィックの3倍以上のトラフィックが予想される場合にはとりあえず暖気の申請を行い、AWSのサポート側に暖気が必要か判断してもらう流れになります。
(とは言っても３倍程度だと大体「暖気不要」という判断をされがちですが・・・。)
今回は作成直後のALBに対して負荷試験を行い、どの程度のアクセスまで耐えられるかの検証記事となります。
環境準備
ALBのターゲットグループに正常なサーバーが設定されていないと、CloudWatchのRequestなどのメトリクスが取得できません。
そのためt3.xlargeのEC2インスタンスに対してApacheを立てておきました。
◆以下のイメージを使ってBitnamiからLAMP環境を作成
https://aws.amazon.com/marketplace/pp/B07XJ2W2DF/
そして攻撃対象となるALBを作成して準備完了です。
ちなみにかつては負荷試験を行う場合にはAWSへの申請が必須でしたが、現在では負荷試験に対する申請は不要となっています。
Apache Benchで負荷をかける
単純な負荷試験なのでApache Benchを使って単純なリクエストを投げてみました。
abコマンドではあまり多くの負荷がかけられないため、毎分7,000リクエスト程度の負荷になります。
さて、皆さんに問題です。
立ち上げたばかりのALBは毎分7,000リクエストに耐えられると思いますか？
ではその結果がこちらです。
ALBが負荷で耐えられないと503エラーを返します。
ただし503エラーを返す場合はターゲットのサーバーが落ちているパターンもあり得ますので、ターゲットのエラー数とALBのエラー数のメトリクスも表示させています。
5XXエラーが発生していない事を見ると、どうやら立ち上げたばかりのALBは毎分7,000リクエスト程度では詰まらないようです。
ALBを立ち上げて放置してみる
もしかしたら立ち上げたばかりのALBはある程度の大きさが確保されているのかもしれませんね。
そこで、新たにALBを作成して20時間以上放置してみました。
さらにApache Benchでは負荷が足りない可能性もあったので、JMeterによる負荷をかけてみます。
ALBを立ち上げて20時間以上放置した後、毎分40,000リクエストを浴びせようと思うのですが、皆さんは耐えられると思いますか？
結果がこちら
5XXエラーがないことから耐えていることが分かりますね。
さらに追加で毎分100,000リクエストを与えてみましたが、
毎分10,0000リクエストでも耐えています。
1日放置&毎分10万リクエスト
先ほどの検証は、4万リクエストの後にスケールアップしてしまった可能性もあるため、新たにALBを作成して24時間以上放置してみました。
この状態で毎分100,000リクエストを与えてみます。
さて、新規に作成したALBを24時間以上放置してから、毎分100,000リクエストを数分間与え続けようと思いますが、皆さんはこの負荷が耐えられると思いますか？
なんとこれだけのリクエストでも5XXエラーは発生しませんでした。
続いてスケーリングが発生したかも確認してみます。
ALBがスケールアウトした場合には、DNSを逆引きしたときに割り当てられるIPアドレスの数が増えます。
単純にスケールアップ・スケールダウンした場合にはIPアドレス自体が変わります。
今回の負荷試験では、負荷の前後ではどうなっているのでしょうか。
↑こちらが負荷試験前の逆引きの情報です。
↑こちらが負荷試験後の逆引きの情報です。
十分な時間が経っているにもかかわらず、スケールアップもスケールアウトもしていません。
結果からの仮説
今回のケースではなぜALBが詰まることなくリクエストを処理できたのでしょうか。
いくつか仮説を考えたいと思います。
特に根拠のない仮説なので、あくまで参考程度にみていただければと思います。
1, ベンチマークの方法がダメ説
今回は単純にApacheのトップページへのリクエストを送るだけの負荷試験でした。
また、ALBと紐づいているサーバーは1台だけの構成です。
さらに単一IPアドレスからのリクエストだったため、ALBとアクセス元ユーザー、アクセス先サーバーへのルーティングに負荷がかからなかったのではないでしょうか。
2, 負荷の密度がダメ説
毎分100,000リクエストというのは毎秒1,666リクエストということになります。
1秒あたり1,666リクエスト程度であればALBは捌くことができるのではないでしょうか。
実際のサービス運用では、1分あたり50,000リクエストしかなくてもそのうちのある1秒に2万リクエストが集中してしまうなどあり得なくはないと思います。
そういったケースが暖気申請の必要になるパターンなのではないでしょうか。
3, 新規ALBはサイズがでかい&放置期間が足りない説
新規に立ち上げたALBはある程度の大きさが確保されている説です。
さらに、リクエスト数が少なければ徐々にスケールダウンされていくと思いますが、今回の検証のような２４時間程度ではほとんどスケールダウンが行われていなかった可能性もありそうです。
おわりに
「ALBがどの程度のリクエストに耐えられるか」という議題について、明確な答えが得られないまま検証終了となりました。
正解が得られないままの記事で申し訳がないのですが、AWS側が内部的な仕組みを秘密としている以上はこれ以上の追求は難しいと感じました。
これ以上の負荷をJMeterでかけようとしたところ、自宅のルーターがボトルネックとなってしまい、検証も難しいです。
(EC2を使ってJMeter立てれば良いが、そこまでやる気量がない)
ただし結果として、新規に立ち上げて24時間放置したALBに対してJMeterで毎分100,000リクエストの負荷をかけた結果、ALBではエラーが発生しなかったという事実は得られたので、何か参考になればと思います。
どなたかALBのボトルネックに対する検証を行った方や、知見がある方はコメントをいただけますと幸いです。
↓リベンジしてみました！
コメントを残す