はじめに
リッチな機能を提供しているApplication Load Balancer(以下:ALB)ですが、Network Load Balancerと比較するとスパイクに弱く、予想されたトラフィックに対しては事前に暖機申請を行う必要があります。
ですがそもそもどの程度のリクエスト数までALBが耐えることができるのかが不明で、以前にサポートへ問合せした際も「普段のトラフィック量のピーク時と比較して短期間で5倍以上のリクエストが予想される場合には暖機申請をおすすめします。」という回答でした。
ALBは普段のトラフィック量に応じて自動的に拡張されるのですが、作成したばかりの小さいであろうALBがどの程度のスパイクに耐えられるのかを検証すれば暖機申請の目安が予想できるのではないかと考えて以前に以下の検証を行いました。
結果としては全然ALBからの5XXエラーが発生せず、大量のリクエストに対して全て正常に動作してしまったため検証が行えませんでした。
今回は検証方法を変更して、作成したばかりのALBがどの程度のリクエスト数を捌くことができるのかを再調査しました。
検証環境1
最初の検証環境はALBに1台の大きなEC2インスタンスWebサーバーをターゲットとしたものです。
これにJMeterを利用して毎分100万リクエストを送信します。
結論としてはELBのエラー数は0でした。
もちろんWebサーバー側もエラー数は0です。
仕方がないのでALBを作り直して、今度は毎分300万リクエストを送信してみることに。
結論としてはこれでもELBのエラー数は0でした。
ちなみに立てたばかりのALBはIPアドレスが一つしかなかったのですが・・・。
Non-authoritative answer:
Name: Access-Test-ALB-526809991.ap-northeast-1.elb.amazonaws.com
Address: 52.69.55.126
ターゲットを追加した時点でIPアドレスが追加されることを確認しました。
Non-authoritative answer:
Name: Access-Test-ALB-526809991.ap-northeast-1.elb.amazonaws.com
Address: 54.65.202.254
Name: Access-Test-ALB-526809991.ap-northeast-1.elb.amazonaws.com
Address: 52.68.8.246
さらに負荷試験開始から2~4分後にはDNSの逆引きIPアドレスが変わっていることが確認できました。
ALBがスケールアップしたということになりますね。
Non-authoritative answer:
Name: Access-Test-ALB-526809991.ap-northeast-1.elb.amazonaws.com
Address: 52.69.55.126
Name: Access-Test-ALB-526809991.ap-northeast-1.elb.amazonaws.com
Address: 52.199.14.96
検証環境2
前回の検証ではALBのターゲットが1台のインスタンスのみだったのでルーティングの振り分けに負荷がかかっていなかった節を提唱してみます。
そこで、新たにALBを作成後に2つのAZにまたがる3台のインスタンスをターゲットにしてみました。
先ほど耐えられた毎分300万リクエストを実行してみます。
ちなみにこの負荷試験は10台のSlaveを持つFargate上のJMeterを利用しています。
結果としては1分当たり150万リクエストを超えたあたりから5XXエラーが発生していることが確認できました。
念のためターゲット数を5台に増やしたり2台に減らした状態で同様の負荷試験を実施してみましたが、同じくらいのエラー率が確認できました。
ちなみにリクエスト数を毎分100万程度に落として5分程度負荷をかけてみたところこちらは耐えることができていました。
検証結果について
今回の検証結果からわかることについては、今回の検証ではターゲット数が2~5台程度なら毎分100万リクエスト程度は耐えられるが、条件によってこの数値は変動しそうということです。
というのも、ターゲット数が1台の時は耐えることができたトラフィック量に対してターゲット数が複数になると耐えられなくなったことから、構築環境の条件によって耐えられる値が変動することが予測できます。
この条件はターゲット数以外にも様々な要因が関係するのではないでしょうか。
以下はまだ検証していませんが、例えばこの辺りの要因も影響しそうだと思いました。
・Webサーバの設定でKeepAliveを有効にしているかどうか
・リスナールールの使用
・ALBのアクセスログの有効化
・WAFの有効化
今後の課題
今回は条件によってALBに暖機申請が必要な基準が変わることが確認できました。
ターゲット数もこの要因になっていそうですが、例えば同じ条件の構成でターゲット数を無数に増やした場合には耐えられるリクエスト数が変わるのかどうかの切り分けができていません。
また、その他にもALBの処理が詰まる要因になりそうな要素について検証ができていないので、この辺りについて後ほど検証したいですね。
しかし実行したばかりのALBも意外と大量のトラフィックを捌ける可能性が見えてきました。
案外、暖機申請が必要なケースは少ないのかもしれませんね！
今後、余裕があれば実用的な構成の時にどの程度まで耐えられるか再検証してみようと思います。
↑日別のコストエクスプローラー
ただ1番の課題は、負荷試験にお金がかかることなんですけどね・・・。
個人の検証アカウントなのでお金は自腹なので・・・（笑）
では、また！
コメントを残す