よくあるアプリの構成でサービスがダウンしているとき（Webブラウザを介してサービスを利用できないこと）、の原因をまとめてみました。
今回は特にWebアプリのインフラで遭遇しがちなものを想定しています。
自分が遭遇してきたケースです
Webアプリ構成
| 使用するもの | |
|---|---|
| フレームワーク | Rails |
| Webサーバー | Nginx |
| その他サーバー | Unicorn |
| ロードバランサー | ELB |
| インフラ | EC2 |
という構成でサービス運営しているとします。
この構成はRails + クラウドの構成でサービス作るときにありがちな構成かと思います。
原因その1: Unicornの停止
この状況かどうかの確認方法
web
sshログインしてunicornが動いているか確かめてみよう
EC2にログイン後
$ ps aux | grep unicorn
で確認してみましょう。
解決方法
unicornを起動しなおす。
参考)http://qiita.com/moonsubaru/items/09df180736f09c995954
原因その2: Nginxの停止
この状況かどうかの確認方法
また、sshログインしてnginxが動いているか確かめてみましょう。
EC2にsshログイン後
$ ps aux | grep nginx
を打ってみましょう。
解決方法
Nginxを再起動する
EC2にsshログイン後
$ nginx
としましょう。場合によっては sudo をつける必要があります。。
原因その3: EC2がELBから切り離されている
状況
WebサーバーがELBのヘルスチェックに応答できておらず、OutOfServiceになってしまった可能性が高いです。
この状況かどうかの確認方法
IPアドレスにWebブラウザからアクセスしてみて、画面が正常に表示される場合はこの状況です。
解決方法
ELBの応答に対して正しく応答するようにしましょう。
今回は応答できないということなので、
「サーバ側で重い処理が走っててレスポンスが遅い」
という場合なので2通りの対応をします。
重いプロセスをkillする
その処理が大事な場合どうするんだ、というのは置いておいて
$ kill <プロセスid>
で処理を停止できます。
ヘルスチェックの設定を変更する
AWSのマネジメントコンソールでEC2を選択した後、
サイドバーからロードバランサーを選びます。
その後、「ヘルスチェック」のタブを選択し、「ヘルスチェックの編集」を押しましょう。
高度な詳細という項目を変更します。
「応答タイムアウト」を長くすれば、レスポンスの遅さに寛容になります。
「非正常のしきい値」、「正常のしきい値」も変えて調整するのもいいでしょう。
この編集はELBに紐付いたサーバーをInServiceにするための緊急対応なので、
正常稼働できる状態にサービスを戻したら、数値も元に戻しましょう。
最後に
Webブラウザでアクセスするとなんとなくわかったりします。