50代アプリエンジニアの積み上げ日記

50代からの学び直しブログ

ハンズオンで新たなエラーが発生。解決できず。。

今日の積み上げ

  • AWS Technical Essentials(日本語実写版)ハンズオン
    • EC2 Auto ScalingのELBヘルスチェックでエラー発生!
      • <発生事象>
        • An instance was taken out of service in response to an ELB system health check failure. (ELB システムのヘルスチェックの失敗に応じて、インスタンスがサービスを停止しました)
        • ただ、リソースを見ると、EC2インスタンスのステータスチェックには合格するのに、ELBのヘルスチェックに失敗する状態
      • AWS公式のユーザーガイドによると、原因と対処は以下の通り
      • <原因>
        • Auto Scaling グループが Elastic Load Balancing によって提供されるヘルスチェックに依存している場合、Amazon EC2 Auto Scaling は、EC2 ステータスチェックと Elastic Load Balancing ヘルスチェックの両方の結果をチェックして、インスタンスのヘルスステータスを判断します。 ロードバランサーは、各インスタンスにリクエストを送信して正しいレスポンスを待つか、インスタンスとの接続を確立することにより、ヘルスチェックを実行します。 インスタンスで実行されているアプリケーションに、ロードバランサーインスタンスをサービス停止と見なす原因となる問題があるため、インスタンスが Elastic Load Balancing ヘルスチェックに失敗する場合があります。

         

      • <対処1>ELBのヘルスチェックに合格する
        • ①ロード バランサーが予期する成功コードをメモし、アプリケーションが成功時にこれらのコードを返すように正しく構成されていることを確認する。
        • ②ロード バランサーと Auto Scaling グループのセキュリティ グループが正しく構成されていることを確認する。
        • ③ターゲット グループのヘルス チェック設定が正しく構成されていることを確認する。 ターゲット グループごとにロード バランサーのヘルス チェック設定を定義する。
        • インスタンス上のアプリケーションがライフサイクル フックの最後にロード バランサーに登録される前にトラフィックを受け入れる準備ができていることを確認するために、起動ライフサイクル フックを Auto Scaling グループに追加することを検討する。
        •  ⑤Auto Scaling グループのヘルスチェックの猶予期間を、Elastic Load Balancing が新しく起動されたインスタンスを正常と見なす前に必要なヘルスチェックの連続成功回数をサポートするのに十分な長さに設定する。
        •  ⑥Auto Scaling グループと同じアベイラビリティーゾーンでロードバランサーが設定されていることを確認する。

           

      • <対処2>Auto Scaling グループを更新して、Elastic Load Balancing ヘルスチェックを無効にする
      •  <試してみたいこと>
        • 対処2はすぐ出来そう。明日試してみよう
        • 対処1①はアプリケーションの中身に関することなので、よくわからない(たぶん、関係ない)
        • 対処1②③は「正しく構成されていること」の意味をきちんと理解しているか確認してみよう
        • 対処1④はちょっとハードルが高いので、保留
        • 対処1⑤はデフォルトの設定のままなので、たぶん問題なし
        • 対処1⑥も大丈夫

 

今日はハンズオン三昧の日。

このコンテンツの最後がEC2 Auto Scalingのハンズオンなんですが、最後の最後で詰まってしまいました。

あと、平均CPU使用率のしきい値を超えたらスケールアウトする、というシナリオなので、CloudWatchアラームを作成し、アプリ(コンテンツ内で提供されるものを利用)で負荷をかけてみたところ、思ったような結果が得られなかったのも気になりました。

 

何かがおかしい。。

 

今日のところは時間切れで解決できなかったんですが、明日引き続きTryしてみようと思います。

 

それでは、また。