コラム

CTC教育サービス・ホーム　＞　コラム　＞　クラウド時代のサーバー運用入門　＞　第6回　クラウド時代の障害対応術 (5) WEBサイトが落ちた？ (2)(前編)

クラウド時代のサーバー運用入門

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第6回　クラウド時代の障害対応術 (5) WEBサイトが落ちた？ (2)(前編) (濱田康貴) 2018年3月

みなさんこんにちは。本コラムも先月から実践編ということで、実際のサーバー障害を例に対処方法をご紹介しています。前回はリモートホストの障害切り分けに役立つコマンドを紹介し、WEBサーバーの外形監視、ステータスコードの取得や名前解決の方法をご紹介しましたが、今回は実際に障害が発生しているWEBサーバーへログインし、原因特定を行ってみたいと思います。

今回、疑似障害を発生させるサーバーは次のスペックです。

OS : CentOS7.4
WEBサーバー : Nginx + PHP-FPM
- » Nginx : 1.13.8
- » PHP : 7.1.13
DBサーバー : MariaDB 10.2.12
CMS : WordPress4.9.4

今回は実際に、壊してもよいWEBサーバーを構築してハンズオンっぽくやってみたいと思います。ですので、社内に余ったサーバーかクラウド環境をご用意いただき実践してみることをおすすめします。

WordPressへログインできない

ある日、お客様から電話があり「御社で管理いただいているサイト(WordPress)にログインできない」と申告がありました。幸い、サイトの表示ができているのでいつものようにWordPressの管理画面へログインを試みたところ、確かにログインできません。いつも自分で覚えているIDとパスワードでログインを試みるのですが、管理画面へ遷移する気配がありません。

そもそもサイトが見えているのですが、念のためにSSHでサーバーにログインし、psコマンドでプロセスの確認をします。

[hamada@popotest ~]$ ps -aef | egrep '([p]hp|[n]ginx)'
root       863     1  0  1月18 ?      00:03:09 php-fpm: master process (/etc/php-fpm.conf)
root       886     1  0  1月18 ?      00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx      891   886  0  1月18 ?      00:00:00 nginx: worker process
nginx      892   886  0  1月18 ?      00:00:01 nginx: worker process
nginx      893   886  0  1月18 ?      00:00:00 nginx: worker process
nginx      894   886  0  1月18 ?      00:00:00 nginx: worker process
nginx      895   886  0  1月18 ?      00:00:18 nginx: cache manager process
nginx     1010   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1011   863  0  1月18 ?      00:00:06 php-fpm: pool www
nginx     1012   863  0  1月18 ?      00:00:06 php-fpm: pool www
nginx     1013   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1014   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1072   863  0  1月18 ?      00:00:05 php-fpm: pool www
nginx     1114   863  0  1月18 ?      00:00:04 php-fpm: pool www

NginxもPHP-FPMも動いています。MySQL(MariaDB)も動いているか確認します。

[hamada@popotest ~]$ ps -aef | egrep -i [m]ysqld
mysql      922     1  0  1月18 ?      00:41:00 /usr/sbin/mysqld

手詰まりか？トラブルシュート

少なくとも、サーバー上で動いているプロセスには問題がなさそうです。アプリケーションを開発しているメンバーにも相談してみましたが、特に設定を変えたりはしていないとのことでした。(順番が違うような気もしますが)上司に相談すると、「ログは見たのかね？」と。そう言えばログを見ていなかった・・・これではいけません。

今の状況を整理してみると

WordPressのサイトそのものは表示されている
ordPressの管理画面へログインできない
WordPressを実行しているサーバーへSSHログインできる
Nginx PHP-FPM MySQL(MariaDB)のプロセスは動いている

という状況になります。

再現環境構築

さて、今回は障害実践編ということもありますので、実際に環境を作ってみたいと思います。
本稿の再現環境として、拙作のサーバープロビジョニングコマンド「ICHIGEKI」を使い、さくらのクラウドでWordPress実行環境を構築しています。

https://github.com/nullpopopo/ichigeki/blob/master/ICHIGEKI

そして、今回は以下のコマンドで擬似障害を発生させています。

$(echo L3Vzci9iaW4vZGQK | openssl enc -d -base64) bs=1048576k count=$(df -h | egrep /$ | awk '{print $2}' | sed -e "s/[[:alpha:]]//g") if=/dev/zero of=DEVZERO

※ このコマンドは、本稿での障害を擬似的に発生させるものです。絶対に本番環境で実行しないようお願いします。

上記「ICHIGEKI」を少しカスタマイズすることで、すぐにWordPressの実行環境を構築することができます。最初の変数指定部分を以下のようにし、構築対象のサーバーへアップロードし、rootユーザーで実行します。

ADMINUSER_MAIL=＜メールアドレス＞
ADMINUSER_ID=＜sshおよびWordPressログインユーザー名＞
ADMINUSER_PW=＜sshおよびWordPressログインユーザーのパスワード＞
ADMINUSER_PUBKEY="公開鍵の文字列"
WORDPRESS_TITLE="WordPressのタイトル"


FQDN=＜DNSで名前解決のできるホスト名＞
CMSINSTALL_CHOICE=WorsPress

ICHIGEKIでのサーバー構築が困難な場合、KUSANAGIでサーバーを構築しても構いません。ICHIGEKIおよびKUSANAGIでのサーバー構築方法の詳細は割愛いたしますが、サーバー構築後の疑似障害発生コマンドを実行してみてください(繰り返しになりますが、くれぐれも本番環境で実行しないよう、お願いします)。