検索たいした諸事情なわけでもないですが、だいぶ更新を空けてしまいましたので、ささやかなことからコツコツと書いていこうかと思います。Balancer)の運用で得られた豆知識の記録です。申請の必要性ALBはトラフィックが増加しても自動的に拡張して対応してくれますが、急激に増加すると拡張が間に合わずにキャパシティオーバーとなって、ALBがエラーを返してしまう可能性があります。そのため、事前にこのくらい跳ね上がりますので暖めて馴染ませておいてください。暖機運転(Pre-warming)です。基本的には事前に申請して扱う仕組みですが、想定よりトラフィックが多くなり、エラーが多発し、数十分・数時間も解決しない場合もこの申請をすることがあります。先に申請しつつ、並行して原因を探ることが、目先の問題の応急処置と恒久的解決のバランスのとれた対応となるでしょう。ある、LCUの詳細が参考になります。スケールアウト用目安であろうことが想像できます。以上増加する予定があれば申請すべし、ってのが正しい理解かなと。いうことでALBのグラフには、新規接続数/アクティブ接続数/トラフィック量(/使っていればルール評価数)を必ず残して注視すべきだと思います。実戦の増加率サービスによりけりで片付けては身もふたもないので、私の観測範囲におけるBtoC系の傾向をば。次に、朝と夜が二番手の傾斜となりますが、最大で5%/5分程度の増加と、昼に比べれば穏やかです。総トラフィックとしては昼休みよりも22時頃がピークとなります。日常的な急傾斜に、ユーザーのヨーイドンをカブせる結果になると、50%どころか500%になってもおかしくありません。あとはサービスリリース時は、時間帯に加えて、瞬間的なアクティブユーザー数の増加が落ち着くまで増え続けるので、先読みと備えがモノをいう特殊事例となります。......なので、ALB対応力的には、日常は大丈夫なレベルにしてくれてるので、それ以上はインフラエンジニアとアプリケーションエンジニアあたりが連携してちゃんと傾向と対策を練っておけよ、ということですね。これらの増加率は、AutoScalingにおけるCPU条件とインスタンス起動時間による、安全確保にも利用する数値ですので、平時と有事、両方の傾向は把握してしかるべきです。増加によって、現状のALBキャパシティを貫くかどうかはCustomer側には把握する術はありません。多くの場合、何の項目が最大何%ずつ増加するかを把握することは、サービスは生き物なのでかなり難しいことがほとんどです。なることもありうる業界だったりするので、悩みすぎるのは時間の無駄です。ALBに限った話ではないですが、判断が難しかったり、不安な状況に遭遇したら、すぐにAWSサポートに問い合わせるとよいです。安くないサポート費用を払っているからバンバン問い合わせろ、というわけではないですが、AWSサポートは山のような過去事例などを利用したりして、非常に質の高い調査や応答をしてくれるので、これを使わない手はないです。丁寧に情報を揃えてサポートリクエストを送ったつもりでも、さらなる情報提供などの往復で結構時間がかかったりすることはあるので、AWSに任せる部分と、自分達で解決していく部分の切り分けをし、両面から対応していくイメージが良いと感じています。当初、2週間の暖機運転で申請したとして、2週間後に再申請が必要かどうかは、その時のトラフィック状況によります。状況を切り分けるとこんな感じ。必要性の場合はまた別ですが、リリース直後などの中期的対応としてはこんな感じになります。サポートレベルが必要ですが、暖機申請完了後にレベルを下げても、暖機状態が解除される、ということはないようです。申請のためだけにレベルを上げ下げするのはナシなのと、そもそも異常状態の対応期間中に変更するのはトラブルシューティングとしてもなってないので、これこそ豆知識程度ですね。割合で返すようになり、影響範囲が十分に大きいため対応が急務となりました。ALBのログを残しても、WEBサーバーのHTTPステータス・レスポンスが記録されていなかったため、ALBがキャパオーバーしてエラーを返してしまっているのだろう、ALBの自動拡張を待とう......数時間経過しても改善しない、サポートに暖機申請だ!という流れです。1度目の暖機申請の対応が完了したことで収まったため、やっぱALBが自動拡張してなかったのかALBクソだな!みたいな会話をしたりしなかったりしてると、また数時間後にエラーが増えて収まらなそうだったので2度めの暖機申請をしてその場は収まるも、さすがになんかおかしいぞとなって、サポートに情報提供と質問をしつつ、自分達でも深く調査し始めました。結果的には、下記KeepAliveという基本が原因だったのですが、なんとなく値を調整したら治ったぜウィーー!で終わらず、サポートの丁寧な調査と回答によって、正しく原因を理解して今後に繋げられたと思っています。ALBのエラー数が増加して収まらない場合、ALBがWEBが悪いとか変に先入観を持たずに、サクッと問い合わせから始めるのが最も無難で早い対応と言えそうです。大きな影響を与えます。程度に縮小されバランスが取れています。大量発生する、というのは想像通りではあるのですが、それによってALBが処理不可能になったり自動拡張しなくなる、ということではなく、Nginxが接続を適切にさばききれなくなったことが原因でした。調査の初期段階では、ALBのログにバックエンドのHTTPステータスコードが記録されず、Nginxのログにも同様のエラーコードがないことを確認していたため、バックエンドにまで来ずにALBで止まって返していると思いこんでしまいました。いうサポートからの最終回答により、納得の上クローズすることになりました。これにより、今後は問題切り分けの作業において、ログ保存と確認だけではなく、TCPの通信状況も確認すべし、という知見が追加されました。あたり)これについて問い合わせましたが、公式的には拡張度合いとConsumedLCUsは無関係なようです。この時、拡張度合い(=IPアドレス数)とConsumedLCUsの値はグラフ化していなかったので、グラフにしました。これによって、いつALBが拡張縮退したのかと、LCUの遷移を確認できるようになり、よりバランスの取れた運用ができるようになったと思います。他所のサイトでも掲載されているような内容ですが、せっかくなので自分で使った申請手順メモも置いておきます。(トラフィックは継続的に発生するため、とりあえず期間を2週間にしてます。・イベント日までにバックエンドEC2インスタンス数を増やしますか。トラフィックパターンをお知らせください。2018/01/14(トラフィックは継続的に発生するため、とりあえず期間を2週間にしてます。・イベント日までにバックエンドEC2インスタンス数を増やしますか。トラフィックパターンをお知らせください。以下となりますおわりに久々に記事を書いて見直してみると、ELBでのそれとたいして変わらん内容になってしまった気がしますがご愛嬌。ALBに限らず、LoadBalancerってわりかし素直に動き続けてくれちゃうので、監視や理解をそこまで深めず運用しちゃったりするがゆえに、事故った時の対応がちと後手りがちです。それでも、最近のMackerel移行時の監視見直しによって後手感はかなり少なくなったと感じましたし、今回のケース対応によってサポートの頼りがい感も掴めました。エラー出しちゃってる分はゴメンナサイではあるのですが、やはり本番運用こそ華といいますか、研究や準備を陰気にやってるよりもトラブルシューティング1発カマした方がシステムもエンジニアとしても格別にレベルアップして楽しいなと久々に感じた次第です。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。