#elasticloadbalancing

[ylastic]

EC2 resource page updates

EC2 resource page updates in Ylastic. Health check information for load balancer target groups readily available without accessing a separate tab. Sparklines now displayed for Requests, Healthy hosts and Unhealthy hosts.

Load balancers page displays sparklines for Requests, Healthy hosts and Unhealthy hosts. The displayed sparklines differ based on the load balancer type, as there are some differences in the metrics available for each type.

All resources that can be targeted by Cloudwatch alarms now display the active resource alarms in a sub-tab, making it easier to manage alarms for the resource.

[im-sei-blog]

大規模トラフィックを捌くための CloudFront 以外の選択肢

〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (ロードバランサー編) 〜

今回、ロードバランサーは全面的に AWS の Elastic Load Balancing (ELB) を使用しました。

Web API を提供するシステムにはもともと ELB を使う予定だったのですが、静的ファイルの配信などは ClouldFront + S3 という構成でいこうと思っていました。

が、最終的には静的ファイルを配信するシステムも ELB + EC2 という構成になりました。

そのへんの経緯とか、AWS を使うときのシステムのフロント周りの負荷分散にはどういう選択肢があるのかとか、軽くまとめてみようと思います。

静的ファイルの配信には CloudFront を使ったほうがいいのか

CloudFront は S3 と併用することで、静的なファイルの配信のことはほとんど考えなくていい、というくらい簡単にファイル配信の仕組みが構築できます。

しかし、想定するリクエスト数や転送量によっては、他の方法でファイル配信システムを構築したほうがよいことがあります。 とくに大規模なトラフィックが想定される場合には、一度 AWS のサポートセンターに相談してみることをおすすめします。

今回は、1.3 MB ほどのすこし大きめの単一のファイルに、秒間 10,000 リクエストが押し寄せてきても耐えられるシステムを構築する必要がありました。 転送量にして 104 Gbps です。

そこで、サポートセンターに相談したところ、CloudFront を使うのではなく以下の 2 つのいずれかの方法をとることを勧められました。

S3 に異なる名前の同一のファイルを複数置いてランダムアクセスさせる

EC2 インスタンスを複数台立ち上げておいて ELB でアクセスを分散させる

S3 に異なる名前の同一のファイルを複数置いてランダムアクセスさせる

これは、S3 に同じファイルを多数置いておき、クライアント側からアクセスが各ファイルに分散するようにしてあげるという方法です。 こうすることでファイル 1 つだけの場合よりも S3 のパフォーマンスをあげることができます。

パーティショニングをうまく使う

S3 バケット内のオブジェクト達は、負荷分散のため、オブジェクト名をもとに物理的に離れたサーバにパーティショニングされて配置されるようになっています。

このような仕組みの上では、たとえば 1 つのオブジェクトへのアクセスが急激に上昇した場合、そのオブジェクトが配置されている単一のパーティションのみがアクセスをうけることになります。

なので、異なる名前の同一のファイルを多数用意して S3 に置いておき、クライアントからランダムアクセスしてあげるようにすることで、各パーティションにアクセスを分散させることができ、パフォーマンスを上げることができます。 (より効果的なオブジェクト名のつけ方については、Amazon S3のパフォーマンスをあげるコツ が参考になります。)

どのくらいの数のファイルを用意すればいいのか

で、実際にどのくらいのファイル数を用意すればよいのかということについてですが、Amazon S3のパフォーマンスをあげるコツ を見たりするに、各ファイルへのリクエストが 50 ~ 100 req/s くらいに収まるくらいの数を用意するのがいいのかなと思います。

今回は、先ほども触れた 1.3 MB の単一のファイルを配信するシステムで、10,000 req/s を捌く必要がありました。

というわけで、サポートセンターからも各ファイル 50 req/s くらいになるように 200 ファイル程置いたらいいよ、というアドバイスをうけたりしました。

今回はクライアントサイドの都合でランダムアクセスが難しかったのでこの方法がとれませんでしたが、特定のファイルにアクセスが集中するような場合には有効な方法だと思います。

EC2 インスタンスを複数台立ち上げておいて ELB でアクセスを分散させる

こちらは静的ファイル配信用の EC2 インスタンスを多数立ち上げておいて、ELB でバランシングさせる方法で、今回はこっちでやりました。 Auto Scaling Group などを使うことでインスタンスの管理も比較的簡単です。

ELB の Pre-warming 申請

ただし、急激なトラフィック増加が想定される場合には、事前に ELB の Pre-warming 申請をしておく必要があります。

「急激なトラフィック増加」とはどのくらいの増加なのか、ということですが、「5 ~ 10 分で 20% 以上のトラフィック増加」というのが目安らしいです。 (Pre-warming 申請とは何ぞや？という人は、同時大量アクセスに備えて ELB を Pre-wariming 状態にしておく を参照)

なので、それと同程度かそれ以上の増加率が想定される場合には、Pre-warming 申請をしておくと安心できます。

Pre-warming 状態の ELB でも対応できない場合

ただし、想定するリクエスト数や転送量によっては、Pre-warming 状態でも 1 つの ELB で対応できるトラフィックを超えている場合があります。

その場合は、Pre-warming 状態の ELB を複数用意し、DNS ラウンドロビンを設定しておくという方法があります。 これも Route 53 を使うことで簡単に設定できます。 (設定手順は、Pre-warming した複数の ELB を Route 53 で DNS ラウンドロビンする にまとめました。)

今回は、1.3 MB 程度の単一のファイルを配信するためのシステムが ELB 1 つで対応できる転送量を超えているということで、この方法をとりました。

Pre-warming 状態の 1 つの ELB に対するトラフィックが、HTTP リクエスト数にして 200,000 req/s、転送量にして 40 Gbps 程度に収まるようにということで、ヴァージニア、オレゴン、アイルランドの各リージョンに分散させて配置しました。

ちなみに、Web API を提供するシステムは、HTTP リクエスト 30,000 req/s、転送量 120 Mbps の想定だったので、Pre-warming 状態の ELB 1 つで問題ありませんでした。

とここまで書いといてなんですが、実際にどの方法をとるかを決める際には、AWS のサポートセンターに相談してみるのがいいかと思います。

自分も AWS のサポートセンターにいろいろ助けてもらったおかげで、お正月は笑って過ごすことができました。

以上

[im-sei-blog]

Pre-warming した複数の ELB を Route 53 で DNS ラウンドロビンする

Pre-warming 状態の ELB でも、想定するトラフィック等によっては 1 つでは対応しきれないことがあります！ (Pre-warming については 大量同時アクセスに備えて ELB を Pre-warming 状態にしておく を参照)

そういう場合は、Route 53 で DNS ラウンドロビンを設定して、複数の ELB にトラフィックを分散させるようにしておきます。

手順はそれほど難しくないのですが、忘れそうなので公開メモっておきます。

rr-sample.uniba.jp というホストに 2 つ ELB をもたせたいという気持ちでいきます！

まずは、ELB を作ります。

つぎに、Route 53 にうつり、ELB の数だけ A レコードを作成します。

Alias の Yes を選択することで、ターゲットが入力できるようになります。 フォーカスをあわせると、S3 のバケットや ELB などの候補がいくつか表示されるので、先ほど作成した ELB を選択します。

Routing Policy は Weighted を選択します。

Weight に入力する数値は、各 ELB + バックエンド EC2 のセットの性能が同じであれば、同じ数値を入力しておけば問題ないでしょう。 今回は、適当に 100 と入力しておきます。

Set ID は、Name と Type の組み合わせ内でユニークになっていればいいそうなので、ELB の名前とか入力しておけばいいでしょう。

そこから下の設定は DNS フェイルオーバーとかを設定するための項目だった気がするのですが、忘れちゃいました...

作成し終わったら、以下のような見た目になります。

dig ってみましょ〜

$ dig rr-sample.uniba.jp @ns-612.awsdns-12.net ;; ANSWER SECTION: rr-sample.uniba.jp. 60 IN A 176.34.31.155 $ dig rr-sample.uniba.jp @ns-612.awsdns-12.net ;; ANSWER SECTION: rr-sample.uniba.jp. 60 IN A 54.248.124.27

何度かやってみて違う IP が返ってきていたらたぶん成功です！

[im-sei-blog]

大量同時アクセスに備えて ELB を Pre-warming 状態にしておく

普段 EC2 を使っていると、ロードバランサーは導入の手間的にほぼ ELB 一択になっちゃいます。

ヘルスチェックはもちろん、高負荷時には自動でスケールしてくれるし、最近やっとコンソールから使えるようになった Auto Scaling とも連携してくれるので、たいへん重宝しています。

ただ、スケールすることを前提としているため、初期状態ではそこまで性能が良くありません。

自分が試した限りでは、HTTPリクエストは 2000 req/s くらいしか捌けませんでした。 また、転送量も 800 Mbps (100 MB/sec) くらいしか稼げませんでした。 (HTTPS の使用や Keep-Alive の設定によっても変わるので一概には言えませんが、ざっくりこのくらいということで。)

また、公式のドキュメントによると、スケールするのに 1 ~ 7 分はかかるらしいです。

したがって、徐々にアクセスが伸びてくることを想定したシステムでは問題なく使用できますが、あるタイミングでアクセスがドカンとくることを想定したシステムには向いていません。

しかし！

AWS のビジネス以上のサポートプランに入ることで、ELB を Pre-warming (暖機) 状態にしておくサポートが受けられるようになります。 このサポートを利用すると、想定のリクエスト数やスループットにあわせて、ELB をあらかじめスケールされた状態にしておくことができます。

要するに、コードを一行も書かずに最強のロードバランサーが手に入るということです。

Pre-warming (暖機) の申請はコンソールからではなく、以下のフォームから申請する必要があります。 https://aws.amazon.com/support/createCase

ビジネスもしくはエンタープライズのサポートプランに加入すると、フォームの「お問い合わせの種類」から「技術サポート」という項目が選択できるようになるので、そこから申請をおこないます。

申請の際には以下の項目について聞かれるので、あらかじめ想定を作っておきます。

対象の ELB 名

予測されるピーク時のリクエスト数 (req/s)

予想されるピーク時のスループット (bit/s)

Pre-warming が必要となる期間

HTTPS の利用有無、利用する場合には HTTP と HTTPS の割合

利用するAZ (アベイラビリティゾーン)

バックエンド EC2 インスタンスの Keep-alive の設定可否

バックエンド EC2 インスタンスの台数

今回はリクエスト数 5 万 req/s、スループット 160 Mbps で申請しましたが、上限がどのくらいなのかはわかりません...

ちなみに、通常の ELB と同様、Pre-warming (暖機) 状態でも想定よりアクセスが増えてきた場合は、そこからさらにスケールするようになっているので安心です。

サポートプランを一度ビジネスに変更した後に、フリープランに戻すこともできるようなので、検証のために一度ビジネスプランに加入してみるのもいいかもしれません。

各サポートプランの料金はこちら。 他の AWS のサービスと同様、料金の計算がちょっとたいへんです...