AWS ALBの運用豆知識

たいした諸事情なわけでもないですが、だいぶ更新を空けてしまいましたので、ささやかなことからコツコツと書いていこうかと思います。

今回は、ALB(Application Load Balancer)の運用で得られた豆知識の記録です。



暖機運転の豆知識

申請の必要性

ALBはトラフィックが増加しても自動的に拡張して対応してくれますが、急激に増加すると拡張が間に合わずにキャパシティオーバーとなって、ALBがエラーを返してしまう可能性があります。そのため、事前にこのくらい跳ね上がりますので暖めて馴染ませておいてください。ってのが暖機運転（Pre-warming）です。

基本的には事前に申請して扱う仕組みですが、想定よりトラフィックが多くなり、エラーが多発し、数十分・数時間も解決しない場合もこの申請をすることがあります。この場合、ALBが自動拡張してくれない ＝ 何か他に問題がある 可能性が高いのですが、最も早く効果の高い Pre-warming を先に申請しつつ、並行して原因を探ることが、目先の問題の応急処置と恒久的解決のバランスのとれた対応となるでしょう。


申請目安

どのくらい急激な増加がよくないかというと、公式見解的には5分間で50%以下の増加に収めておけ、とされています（参考：Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services）。

もう少し具体的に考えるならば、Application Load Balancer の料金表 にある、LCUの詳細が参考になります。これはALB利用前だと、「あぁそういう料金体系なんだ」と思うだけの表記ですが、運用して少々トラブルに当たってみると、これらがALBのキャパシティオーバーになりうる項目群であり、
　最も高いディメンション = 請求用項目 = スケールアウト用目安
であろうことが想像できます。（※私見です。実際の条件は不明）

基本的にはリクエスト数に比例する項目群ですが、これらのうち、5分50% 以上増加する予定があれば申請すべし、ってのが正しい理解かなと。いうことでALBのグラフには、新規接続数／アクティブ接続数／トラフィック量（／使っていればルール評価数）を必ず残して注視すべきだと思います。


実戦の増加率

サービスによりけりで片付けては身もふたもないので、私の観測範囲におけるBtoC系の傾向をば。

トラフィックが増加する時間帯は、主に昼休みとなる 12:00～12:30 が、日中で最も増加率の傾きが急で 15～25%/5分 ずつ増加します。次に、朝と夜が二番手の傾斜となりますが、最大で5%/5分程度の増加と、昼に比べれば穏やかです。ただし、総トラフィックとしては昼休みよりも22時頃がピークとなります。



50%/5分 を超えるとしたら、例えば 12時にイベント開始 や、想定外の21時メンテ明け などです。日常的な急傾斜に、ユーザーのヨーイドンをカブせる結果になると、50%どころか500%になってもおかしくありません。

あとはサービスリリース時は、時間帯に加えて、瞬間的なアクティブユーザー数の増加が落ち着くまで増え続けるので、先読みと備えがモノをいう特殊事例となります。

……なので、ALB対応力的には、日常は大丈夫なレベルにしてくれてるので、それ以上はインフラエンジニアとアプリケーションエンジニアあたりが連携してちゃんと傾向と対策を練っておけよ、ということですね。

これらの増加率は、AutoScalingにおけるCPU条件とインスタンス起動時間による、安全確保にも利用する数値ですので、平時と有事、両方の傾向は把握してしかるべきです。


申請度合い

LCUにおける、とある項目の 50%/5分 増加によって、現状のALBキャパシティを貫くかどうかはCustomer側には把握する術はありません。また、多くの場合、何の項目が最大何%ずつ増加するかを把握することは、サービスは生き物なのでかなり難しいことがほとんどです。

サービスリリース直後に、数百req/s になるのか、数千req/s になるのか。もしかしたら一気に数万req/s になることもありうる業界だったりするので、悩みすぎるのは時間の無駄です。

ALBに限った話ではないですが、判断が難しかったり、不安な状況に遭遇したら、すぐにAWSサポートに問い合わせるとよいです。そう安くないサポート費用を払っているからバンバン問い合わせろ、というわけではないですが、AWSサポートは山のような過去事例などを利用したりして、非常に質の高い調査や応答をしてくれるので、これを使わない手はないです。

ただ、丁寧に情報を揃えてサポートリクエストを送ったつもりでも、さらなる情報提供などの往復で結構時間がかかったりすることはあるので、AWSに任せる部分と、自分達で解決していく部分の切り分けをし、両面から対応していくイメージが良いと感じています。


再申請は基本不要

当初、2週間の暖機運転で申請したとして、2週間後に再申請が必要かどうかは、その時のトラフィック状況によります。状況を切り分けるとこんな感じ。

  • 申請時よりトラフィックが下がっている場合
    • 現状に合わせたキャパシティに下げられる可能性有り
    • その後にトラフィック増があるなら再申請が必要
  • トラフィック傾向が変わらない場合
    • 暖機状態も継続しているので、再申請は不要
  • よりトラフィックが増加してきた場合
    • 再度、大きめの数値で申請が必要

不規則・短期的な必要性の場合はまた別ですが、リリース直後などの中期的対応としてはこんな感じになります。


サポートレベルと暖機状態の関連性

暖機申請をするには、ビジネス or エンタープライズ のサポートレベルが必要ですが、暖機申請完了後にレベルを下げても、暖機状態が解除される、ということはないようです。ただ、申請のためだけにレベルを上げ下げするのはナシなのと、そもそも異常状態の対応期間中に変更するのはトラブルシューティングとしてもなってないので、これこそ豆知識程度ですね。


パフォーマンスとチューニング

自動拡張しない問題

経験した１つのケースですが、ALBが 502 Bad Gateway を 0.1～1.0% の割合で返すようになり、影響範囲が十分に大きいため対応が急務となりました。ALBのログを残しても、WEBサーバーのHTTPステータス・レスポンスが記録されていなかったため、ALBがキャパオーバーしてエラーを返してしまっているのだろう、ALBの自動拡張を待とう……数時間経過しても改善しない、サポートに暖機申請だ！という流れです。

１度目の暖機申請の対応が完了したことで収まったため、やっぱALBが自動拡張してなかったのかALBクソだな！みたいな会話をしたりしなかったりしてると、また数時間後にエラーが増えて収まらなそうだったので２度めの暖機申請をしてその場は収まるも、さすがになんかおかしいぞとなって、サポートに情報提供と質問をしつつ、自分達でも深く調査し始めました。

結果的には、下記KeepAliveという基本が原因だったのですが、なんとなく値を調整したら治ったぜウィーー！で終わらず、サポートの丁寧な調査と回答によって、正しく原因を理解して今後に繋げられたと思っています。もしALBのエラー数が増加して収まらない場合、ALBがWEBが悪いとか変に先入観を持たずに、サクッと問い合わせから始めるのが最も無難で早い対応と言えそうです。


KeepAlive

今回はNginxの例ですが、keepalive_timeout がALBの ActiveConnections / NewConnections に大きな影響を与えます。

このグラフは、keepalive_timeout を調整した瞬間の変化で、調整前は値が 1 , 調整後は 10 にした状態です。それまで Active : New = 100 : 800 だった値が、Active : New = 200 : 200 程度に縮小されバランスが取れています。

keepalive_timeout が低すぎると NewConnections が大量発生する、というのは想像通りではあるのですが、それによってALBが処理不可能になったり自動拡張しなくなる、ということではなく、Nginxが接続を適切にさばききれなくなったことが原因でした。

調査の初期段階では、ALBのログにバックエンドのHTTPステータスコードが記録されず、Nginxのログにも同様のエラーコードがないことを確認していたため、バックエンドにまで来ずにALBで止まって返していると思いこんでしまいました。実際には、Nginxにまできているけども、Nginxがさばききれずに TCP RST もしくは TCP FIN によって接続を閉じた というサポートからの最終回答により、納得の上クローズすることになりました。

これにより、今後は問題切り分けの作業において、ログ保存と確認だけではなく、TCPの通信状況も確認すべし、という知見が追加されました。


ConsumedLCUs

なぜかELB CloudWatch Metricsの英語版にしか項目が存在しない ConsumedLCUs ですが、トラブル時に観測した所、この数値が拡張度合いを表すIPアドレスの数を超えてきたあたりでエラーが多く発生する傾向がありました（IPアドレスが 4 個なら、ConsumedLCUs が >= 4.0 あたり）

これについて問い合わせましたが、公式的には拡張度合いとConsumedLCUsは無関係なようです。ただ、この時、拡張度合い(=IPアドレス数)とConsumedLCUsの値はグラフ化していなかったので、グラフにしました。これによって、いつALBが拡張縮退したのかと、LCUの遷移を確認できるようになり、よりバランスの取れた運用ができるようになったと思います。


暖機運転の申請手順

他所のサイトでも掲載されているような内容ですが、せっかくなので自分で使った申請手順メモも置いておきます。

手順

  1. ビジネスサポート または エンタープライズサポート に変更します
  2. サポートセンターで新規ケースを作成します
  3. 各種内容を選択します
    1. 内容：技術サポート
    2. サービス：ElasticLoadBalancing (ELB)
    3. カテゴリ：ロードバランサー関連
    4. ELB FQDN(s)：ALBのFQDNをコピペ
    5. 緊急度：
      1. 前日以上に余裕があるなら ”通常の問い合わせ”
      2. 既にエラー出まくりの場合などは ”発生中の障害（ビジネスへの影響大）”
    6. 件名：（例）ALBの暖機運転依頼
  4. 説明に下記テンプレを貼り付けて編集します

説明テンプレ



おわりに

久々に記事を書いて見直してみると、ELBでのそれとたいして変わらん内容になってしまった気がしますがご愛嬌。

ALBに限らず、LoadBalancerってわりかし素直に動き続けてくれちゃうので、監視や理解をそこまで深めず運用しちゃったりするがゆえに、事故った時の対応がちと後手りがちです。それでも、最近のMackerel移行時の監視見直しによって後手感はかなり少なくなったと感じましたし、今回のケース対応によってサポートの頼りがい感も掴めました。

エラー出しちゃってる分はゴメンナサイではあるのですが、やはり本番運用こそ華といいますか、研究や準備を陰気にやってるよりもトラブルシューティング１発カマした方がシステムもエンジニアとしても格別にレベルアップして楽しいなと久々に感じた次第です。

まぁ、何やってても陰気な職種であることに変わりはないんですけどね:-)

Posted on 2017/07/19   カテゴリー: AWS タグ: , パーマリンク