ELBのスケーリングとsurge queue

aws

バックエンドだけではなくELB自体もスケーリングし、内部node数はdigで調べることができる。 このnode数は自分ではコントロールできず、基本的に意識することはない。

$ dig ****.ap-northeast-1.elb.amazonaws.com

;; ANSWER SECTION:
*****.elb.amazonaws.com. 60 IN A xxx.xxx.xxx.xxx
*****.elb.amazonaws.com. 60 IN A yyy.yyy.yyy.yyy

nodeが増えるのにはある程度時間がかかるので、 アクセスが急増(5分間で50%以上のトラフィック増加が目安) したら捌ききれず、503を返すことがある。 前もって多量のアクセスが来ることが分かっていて、 AWSサポートがBusiness以上なら pre-warming申請することでnodeが増えた状態で待ち構えられる。

バックエンドのアプリケーションがリクエストを処理できない場合、ELBのsurge queueに溜まっていく。 この数はCloudWatchのSurgeQueueLength(キュー長の急増)メトリクスで確認できる。 また、SurgeQueueLengthの最大値1024を超えるとリクエストは拒否され、その数はSpoiloverCount(過剰数)メトリクスに出る。

参考

ELBの挙動とCloudWatchメトリクスの読み方を徹底的に理解する | Developers.IO

Elastic Load Balancing でのレイテンシーのトラブルシューティング