サーバー自動復旧（インスタンス数の維持）のためのAuto Scalingの設定内容を知りたい

Rails初心者エンジニアです。
WebアプリのプロトタイプをAWS上にデプロイ・運用していく予定で、本番環境の構築を進めております。

###実現したいこと
EC2上のWebアプリの可用性を維持（インスタンス数１台を維持）するため、AWS EC2 Auto Scalingでサーバーを自動復旧する設定をしたい

###実施内容
0. EC2で立てたインスタンス（インスタンスタイプ：t2.micro, ストレージ：8G）からAMIを作成
0. 上記1で作成したAMIを使用し、起動設定を作成（インスタンスタイプ、ストレージ、セキュリティグループなどの設定は1と同じ。自動起動したインスタンスにも同じ鍵でSSHログインしたいため、既存のキーペアを選択。）
0. 上記2の起動設定を使用してAuto Scalingグループを作成

Auto Scalingグループの設定内容


・グループサイズ : 希望する容量1、最小キャパシティ1、最大キャパシティ1
・サブネット ： 既存のEC2インスタンスと同じものを選択
・ロードバランシング : チェックを入れ、ターゲットグループを選択
・ヘルスチェックのタイプ : EC2 & ELB
・ヘルスチェックの猶予期間 : 300
・インスタンスのスケールイン保護 : 保護なし スケールインから
・終了ポリシー : Default
・デフォルトのクールダウン : 300

###発生事象
EC2インスタンス（キャプチャのstart-aws-instance）に問題が無いにも関わらず、Auto Scallingによって、インスタンスの自動生成・終了が約8分毎に繰り返されてしまう。

インスタンス一覧

ELBのターゲット一覧（Auto Scalingのヘルスチェックがhealthyとならない）

Auto Scalingグループのアクティビティ履歴（約8分毎にインスタンスの起動・終了を繰り返している）

ポート状態の確認結果

unhealty
1Netid   State     Recv-Q    Send-Q                         Local Address:Port         Peer Address:Port     
2udp     UNCONN    0         0                                  127.0.0.1:323               0.0.0.0:*        
3udp     UNCONN    0         0                                    0.0.0.0:68                0.0.0.0:*        
4udp     UNCONN    0         0                                    0.0.0.0:111               0.0.0.0:*        
5udp     UNCONN    0         0                                    0.0.0.0:728               0.0.0.0:*        
6udp     UNCONN    0         0                                      [::1]:323                  [::]:*        
7udp     UNCONN    0         0             [fe80::89d:beff:fed1:a24]%eth0:546                  [::]:*        
8udp     UNCONN    0         0                                       [::]:111                  [::]:*        
9udp     UNCONN    0         0                                       [::]:728                  [::]:*        
10tcp     LISTEN    0         128                                  0.0.0.0:22                0.0.0.0:*        
11tcp     LISTEN    0         100                                127.0.0.1:25                0.0.0.0:*        
12tcp     LISTEN    0         128                                  0.0.0.0:111               0.0.0.0:*        
13tcp     ESTAB     0         36                             172.31.11.230:22          60.60.230.194:51511    
14tcp     LISTEN    0         128                                     [::]:22                   [::]:*        
15tcp     LISTEN    0         128                                     [::]:111                  [::]:*

healty
1Netid    State         Recv-Q     Send-Q                            Local Address:Port          Peer Address:Port     
2udp      UNCONN        0          0                                     127.0.0.1:323                0.0.0.0:*        
3udp      UNCONN        0          0                                       0.0.0.0:68                 0.0.0.0:*        
4udp      UNCONN        0          0                                       0.0.0.0:111                0.0.0.0:*        
5udp      UNCONN        0          0                                       0.0.0.0:727                0.0.0.0:*        
6udp      UNCONN        0          0                                         [::1]:323                   [::]:*        
7udp      UNCONN        0          0               [fe80::884:abff:fe94:f3e4]%eth0:546                   [::]:*        
8udp      UNCONN        0          0                                          [::]:111                   [::]:*        
9udp      UNCONN        0          0                                          [::]:727                   [::]:*        
10tcp      LISTEN        0          128                                     0.0.0.0:111                0.0.0.0:*        
11tcp      LISTEN        0          128                                     0.0.0.0:80                 0.0.0.0:*        
12tcp      LISTEN        0          128                                     0.0.0.0:22                 0.0.0.0:*        
13tcp      LISTEN        0          100                                   127.0.0.1:25                 0.0.0.0:*        
14tcp      TIME-WAIT     0          0                                  172.31.14.50:80           172.31.28.107:60516    
15tcp      ESTAB         0          36                                 172.31.14.50:22           60.60.230.194:51517    
16tcp      TIME-WAIT     0          0                                  172.31.14.50:80            172.31.6.186:34352    
17tcp      TIME-WAIT     0          0                                  172.31.14.50:80           172.31.28.107:60502    
18tcp      TIME-WAIT     0          0                                  172.31.14.50:80            172.31.6.186:34362    
19tcp      TIME-WAIT     0          0                                  172.31.14.50:80            172.31.6.186:34376    
20tcp      LISTEN        0          128                                        [::]:111                   [::]:*        
21tcp      LISTEN        0          128                                        [::]:80                    [::]:*        
22tcp      LISTEN        0          128                                        [::]:22                    [::]:*

###質問
インスタンス乱立の要因は、Auto Scalingのヘルスチェックが上手くできてないことと想定しておりますが、詳細分かっておらず困っております。
EC2インスタンス（キャプチャのstart-aws-instance）に問題が生じた場合のみ、Auto Scalingで1台のサーバーを自動復旧するようにしたいのですが、発生事象の原因と対処法について、アドバイスいただきたく、よろしくお願いいたします。

行動規範の内容に同意します

回答2件

ベストアンサー

tanatさんの回答でほぼ確認すべきことは書かれているので自分はヘルスチェックについて書きます。

ヘルスチェックで何を行っているのかというところですが、ヘルスチェックはELBからEC2インスタンスのプライベートIPの指定されたパスに対してリクエストを送り、そのレスポンスコードが指定したものになっているかを確認しています。（デフォルトだと80番ポートにリクエストを送り、200 OKが返ってくるどうかを見ている）
これはターゲットグループの設定でカスタマイズできます。

なので、ELBがEC2インスタンスに対してリクエストを送った時に、想定したレスポンスコードを返すようにEC2側で設定していなければヘルスチェックは失敗します。
失敗の要因はEC2側でリクエストを受け付けられる状態になっていなかったり、セキュリティグループでELBからの通信を許可していなかったり、EC2側で８０番ポート宛のリクエストをリダイレクトしていたり（リダイレクトは300番台のコードなので）…等色々ありますが、調べてみてください。

あまりおすすめしない方法として、一時的にヘルスチェックをOKとみなすレスポンスコードを変えたり範囲を広げたりする、というのがありますが、これをやるのはあくまでもデバッグ中くらいで、実際に動かす時にこれをやってしまったらヘルスチェックの意味がなくなります。

投稿2020/11/17 09:09

yu_1985

総合スコア7588

maisumakun

2020/11/17 09:12

> EC2側で８０番ポート宛のリクエストをリダイレクトしていたり HTTPSに強制リダイレクトするようにしているのも、ヘルスチェックだけは外す必要がありますので要注意です。

yu_1985

2020/11/17 09:16

ここの回答の範疇から逸れそうなので割愛しましたが、ALBを噛ませている場合はEC2インスタンス側でリダイレクトするのではなくALB側でリダイレクトしたほうが簡単です。そうすればEC2側では80番ポートでListenしてればいいだけになりますし、逆にそうしなければALB配下のEC2インスタンス全てに証明書をわざわざ置かなければいけなくなります。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/elb-redirect-http-to-https-using-alb/ ALBからEC2インスタンスの間の通信まで暗号化する必要があるという要件があるのなら話は別ですけれど。

kuroine01690699

2020/11/18 02:18

連日ご回答いただき、恐れ入ります。まだHTTPS化できておりませんが、今後SSL証明書取得・HTTPS化する際に改めて参考にさせて頂きたいと思います。 tanatさんの回答にもコメントしましたが、サーバーがリスンしているポートの確認結果を、発生事象に追記させて頂きました。 unhealtyとなっているサーバーの方には、Local Address:Port`[::]:80`が無い（80番ポートがリスンしてない？？）ことが原因でしょうか？

yu_1985

2020/11/18 04:19

80番ポートがListenしてないならヘルスチェックはうまく行かないですよね…。念の為ですが、そもそもの元にしたEC2インスタンスはWEBサーバとして設定済みなんでしょうか？元にしたEC2インスタンスがどんなものについては書かれていないのでそのへんを書いてほしいです。あと、AMIから手動でインスタンス作成してみて、必要なプロセスが起動しているか確認してください。

kuroine01690699

2020/11/18 12:35 編集

unhealthyの原因は、Auto Scalingで作成したインスタンスのWebサーバー・アプリサーバーが起動していないことでした。。（手動で動かすとヘルスチェック通りました）今後の対応として、まずは元のEC2（Amazon Linux 2）でWebサーバー（Nginx）・アプリサーバー（Unicorn）の自動起動の設定を行いたいと思います。 Unicornの自動起動設定が難しそうなので、少し時間かかりそうですが、引き続き検証していきたいと思います！

kuroine01690699

2020/11/27 10:09

yu_1985さん、[unicornの自動起動設定](https://teratail.com/questions/305360)について、大変お世話になりました。おかげさまで、こちらのインスタンス乱立問題も解消されたことを確認できました！ただ、元インスタンスと、AutoScalingで作成されたインスタンスの２台が「実行中」となっております。想定していた挙動は、元インスタンスのみ「実行中」となり、元インスタンスが障害などで停止してしまった際に、AutoScalingで新規にインスタンスが立ち上がることを想定しておりました。（インスタンス数1で維持）これが正しい挙動なのか、もしくは、グループサイズ（希望する容量1、最小キャパシティ1、最大キャパシティ1）などに問題あるのか、ご教授頂けますと幸いです。

yu_1985

2020/11/27 10:53 編集

ちょっと気になったんですけど、元インスタンス（恐らくstart-aws-instane）と称しているものはAutoScalingGroupで作成されたインスタンスですか？そうでないならAutoScalingGroupと関係ないのでAutoScalingGroupのインスタンス台数にはカウントされません。

kuroine01690699

2020/11/27 10:50

元インスタンス（start-aws-instance）は、手動で作成したもので、AutoScalingで作成したものではありません。いただいたコメントから類推すると、start-aws-instanceを削除すれば、インスタンス1台で維持する形が実現できそうな気がしました。

yu_1985

2020/11/27 10:54

それならAutoScalingGroupと関係のないインスタンスなのでAutoScalingによる制御はされないですね。当然といえば当然なのですが、対象のAutoScalingGroupで作成したインスタンスでないインスタンスはAutoScalingGroupによって制御されることはありません。必要があればAMIを取得後、元のインスタンスを停止するなり削除するなりすればよいでしょう。

kuroine01690699

2020/11/27 11:42

ありがとうございます！手動で作成した元インスタンスを停止し、インスタンス数1台で維持できることが確認できました！！

yu_1985

2020/11/27 11:50

本質問の回答としてはtanatさんのほうが的確で、自分がBAをもらうのはしのびないです…。

kuroine01690699

2020/11/27 12:05

お二方ともに助けられ、ここまでこれ、大変感謝しております。 BAについては「実現したいこと」に最後までお付き合い頂けた、ということで今回は選ばせて頂きました。

行動規範の内容に同意します

インスタンス乱立の要因は、Auto Scalingのヘルスチェックが上手くできてないことと想定しておりますが、詳細分かっておらず困っております。

まずは
Application Load Balancer のトラブルシューティングを行い、ヘルスチェックの失敗を修正する方法を教えてください。
等を参考に切り分けてみてください。

個人的には、いきなりWebアプリケーションの動いているAutoScalingGroupを作るのではなく、

最初に静的なHTMLを表示するだけのELBとEC2のセットを作り、ヘルスチェックをクリアできるようにする(Apacheやnginxがインストールされ、静的HTMLを表示するだけのwebサーバのインスタンスを用意する。ELBも今触っているのとは別に作る）
1のAMIとELBでAutoScaingGroupを作ってみる
2が出来たら、2と同じく静的なHTMLをヘルスチェック対象としたAutoScalingGroupを作ってみて、質問中で使用しているAMIで動く様にする
3が出来たら、動的なヘルスチェックを行う（質問中で目指しているであろう）環境を作る

というステップを踏んで、順に切り分け方法を把握するのが近道だと思います。

投稿2020/11/17 08:36

tanat

総合スコア18727

kuroine01690699

2020/11/18 02:18

環境作成のステップを具体的にご教授いただきありがとうございます。 しっかり段階を踏んで構築していくことが、とても大事だと改めて感じました。まずは、ご案内いただいたリンク（FailedHealthChecksのケース）を参考に、ssコマンドでサーバーがリスンしているポートを確認してみました。ポート状態の確認結果を発生事象に追記しておりますが、原因が掴めておりません。。 healthyインスタンス（もとのインスタンス）とunhealthyインスタンス（Auto Scalingで自動生成）を比較すると、unhealthyの方には、Local Address:Port`[::]:80`が無い（80番ポートがリスンしてない？？）ことが原因でしょうか？なお、両インスタンスには同じセキュリティグループを設定（ELBからのアクセスのみ許可）しております。

tanat

2020/11/18 04:27

そうですね。 TCP80が開いてないとヘルスチェックに成功しようが無いです。 webサーバの自動起動設定が出来ていないとか、起動時にこけているんじゃないでしょうか。 webサーバのエラーログを確認すると解決するかもしれません。

kuroine01690699

2020/11/18 12:34

Webサーバー（Nginx）を確認したところ、そもそも動いておりませんでした。。手動でインスタンスを再作成 => Webサーバー・アプリサーバー起動 => LBのターゲットに登録で、ヘルスチェックに成功したので、おっしゃる通り、Webサーバー・アプリサーバーの自動起動設定ができれば解決しそうです！ Nginxの自動起動設定は`sudo systemctl enable nginx`コマンドですぐ対応できたのですが、CentOS7上のUnicornの自動起動の設定が難しそうで時間かかりそうですが、、引き続き頑張ってみます！

kuroine01690699

2020/11/27 11:43 編集

tanatさん、おかげさまでインスタンス乱立問題は解消できました！改めてありがとうございます！（元インスタンスでNginx・Unicornの自動起動設定をした上で、AMI・起動設定・AutoScalingグループを作成しなおし、インスタンス乱立問題が解消されたことを確認できました）

tanat

2020/11/27 12:11

解決してよかったです。フィードバックありがとうございます

行動規範の内容に同意します

あなたの回答