ELB + EC2 Auto Scaling の構成で、スケール時に毎回ヘルスチェックエラーが発生します。原因と対処法を教えてください

Auto Scaling グループのライフサイクルフック機能で、新規起動した EC2 インスタンスの動作を制御できます。
2023.02.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

困っていた内容

ELB(Elastic Load Balancing)と EC2 Auto Scaling を組み合わせた構成で、毎回インスタンスの台数が増加するたびに ELB のヘルスチェックエラー(もしくは 502 や 504 エラー)が発生します。考えられる原因と対処法を教えてください。

考えられる原因

Auto Scaling グループによりスケールアウト(EC2 インスタンスの台数増加)が行われたあと、まだ新規インスタンスの内部的な準備が整っていない状態で ELB のターゲットグループに登録されてしまうため、ELB からのトラフィックに対してしばらく EC2 側が応答ができず、ヘルスチェックエラーとなっている可能性が考えられます。

どう対応すればいいの?

Auto Scaling グループのライフサイクルフック機能を利用して、新規起動した EC2 インスタンスの動作を制御できます。

例えば新規インスタンスが完全に利用可能になるまで5分かかる場合「インスタンスが起動してから5分間待機する」というライフサイクルフックを設定することで、インスタンス側の準備が整うまで ELB へのターゲット登録を遅らせられるため、ヘルスチェックエラーの回避が期待できます。

参考 AWS ドキュメント:
Amazon EC2 Auto Scaling のライフサイクルフック - Amazon EC2 Auto Scaling

やってみた

前準備として、ELB の配下に Auto Scaling グループで起動された EC2 インスタンスが 2 台稼働している環境を用意します。 (この手順は割愛します)

Auto Scaling グループのコンソールから「インスタンス管理 > ライフサイクルフックを作成する」をクリックします。
今回は「インスタンスが起動してから10分(600秒)待機してから ELB のターゲットグループに登録する」という動作を実現したいため、下記画像のように設定しました。

動作を確認するために Auto Scaling グループの容量を元の 2 台 から 3 台に増加させ、更新してみます。

すると新規インスタンスが起動して 3 台に増えましたが、ライフサイクルが「Pending:Wait」になったまま InService になりません。
アクティビティ履歴のステータスを見ると「MidLifeCycleAction」と表示され、ライフサイクルアクションの途中であることが分かります。

ELB 側のターゲットグループを確認すると、まだ 2 台のままで新しいインスタンスは登録されていません。

そのまま10分待つと、アクティビティ履歴のステータスが「Successful」に変わり、新しいインスタンスが ELB のターゲットにも登録されたことを確認できました。

補足

今回はライフサイクルフックで Auto Scaling のスケールアウト時(インスタンスの起動時)の動作を制御する方法をご紹介しましたが、逆にスケールイン時(インスタンスの終了時)の動作も制御できます。ユースケースとしては、障害が起きたインスタンスが終了される前にログを退避するなどが考えられます。
こちらについても、また機会があれば記事にしたいと思います。

この情報がどなたかのお役に立てば幸いです!

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。