sgykfjsm.github.com

起動に失敗したインスタンスを調査する例

先日、とあるサービスで利用しているBeanstalk環境でインスタンスが起動に失敗した。ログを見ると、S3からリソースの取得に失敗していたようだ。
ネットワーク接続の状態としては、AWS内のネットワークでは疎通可能だが、インターネットを経由した通信は不可、という状況。具体的には、例えばAWSのインスタンスからはsshログイン可能だが、グローバルからのsshログインはできないといったような感じ。色々調べたけど、不意に調査対象のインスタンスがTerminateしてしまい、結局原因がわからないままになってしまった。

調査はAWS Supportとやりとりしながら行ったのだけれども、色々と情報収集を都度指示されて捗らなかった。
なので、ここには次また事象が再発した場合に備えて、障害発生時に取得しておきべきこと、確認すべきことを整理する。

確認すべきこと

  • 対象インスタンスに設定されているSecurityGroup
    • どこからのアクセスを許可しているか
    • 許可しているプロトコルは何か
    • どのポートを開けているか
  • 通信状態に問題がある場合
    • AWS内ネットワークからアクセス可能か(例えばsshログインなど)
    • インターネットからアクセス可能か(例えばcurlでのHTTPアクセスなど)
  • 対象インスタンスにログイン可能な場合
  • 対象インスタンスにログインできない場合
    • Management ConsoleのEC2の画面から対象インスタンスを選択 > Actions > Instance Settings > Get System Logで起動時のログを参照できるかを確認する。
    • 確認できた場合はそれをテキストファイルなどにコピーしてSupportへ提供する。

収拾すべき情報

起動に成功したインスタンスと起動に失敗したインスタンスのそれぞれで収拾を行なうこと。

  • 各種設定ファイル
    • /etc/ssh/sshd_config
    • /etc/resolv.conf
  • 各種コマンドの結果
    • ps -ef
    • traceroute, nslookup, dig
      • これらのコマンドはsshログインできた端末(例えば踏み台に使ったEC2インスタンス)と、sshログインできなかった端末(例えば対象インスタンスへインターネット経由でsshログインを行った作業者の端末)の両方で行うこと。
      • www.google.co.jpやrepo.ap-northeast-1.amazonaws.comなど、いくつかのパターンを試すと良い。
    • tcpdump
      • .cap形式でコマンドの結果を保存してSupportへ提供する。
      • tcpdump port 80 -w filename.cap
    • netstat -rn, netstat -an
    • ssh -vvv
    • iptablesの起動有無
      • sudo /etc/init.d/iptables status
      • sudo /etc/init.d/ip6tables status
      • 起動している場合は設定をテキストファイルなどにコピーしてSupportへ提供する。

注意すること

今回、油断して障害発生した端末が不意にTerminateしてしまい、原因を究明することができなかった。このような障害インスタンスはStanby状態にすることで稼働を維持することができる。具体的にはマニュアルのAuto Scaling グループのインスタンスのトラブルシューティングを参照すること。Auto ScalingやBeanstalkなどを利用していなければ、勝手にTerminateされることは無いと思うので、Terminate Protectionを設定しておけば大丈夫だと思う。