コラム

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

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

CTC 教育サービス

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

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

みなさんこんにちは。前回のコラムで擬似的に発生させたWEBサーバーの障害ですが、原因がわかりましたでしょうか。今回は、答えあわせと解説、再発防止策の検討を行いたいと思います。前回の宿題は次の通りでした。

どこに何のログがあるかを探してみよう
(ア) Nginx
(イ) PHP-FPM
(ウ) MySQL(MariaDB)
ログにはどんなエラーが書かれているかを確認してみよう
エラーメッセージから読み取った障害原因と、復旧方法、確認方法
再発防止策
(ア) そもそも同じ原因での障害を再発させないために、どうすればよいのか
(イ) どうすれば障害発生を早期に気づくことができるのか

どこに何のログがあるかを探してみよう

RHELやCentOSなどのrpm系Linuxでyumコマンドを使ってインストールしたパッケージは、標準の設定ファイルやログファイルなどをrpmコマンドで探すことができます。ただし、インクルードした設定ファイルなどはrpmパッケージの情報に表示されないため、設定ファイルの記述から辿ることでログファイルを探すことができます。

まず、rpmコマンドでnginxの設定ファイルを探してみます。引数に -ql <パッケージ名> を与えることで、rpmパッケージを構成するファイルを出力することができます。

[hamada@popotest ~]$ rpm -ql nginx | egrep '(conf$|conf.d\/)'
/etc/nginx/conf.d/default.conf
/etc/nginx/nginx.conf

上記コマンド例の出力2行目にある「nginx.conf」が、nginxが持つおおもとの設定ファイルです。1行目の「default.conf」は、nginx.confがインクルードしている設定ファイルですが、これはnginx.confファイルの記述から検索して確認します。

[hamada@popotest ~]$ cat /etc/nginx/nginx.conf | egrep include
    include       /etc/nginx/mime.types;
    include /etc/nginx/conf.d/*.conf;

上記コマンド例でおわかりいただけたかと思いますが、 /etc/nginx/conf.d ディレクトリの中にある、ファイル名が「.conf」で終わるファイルをインクルードしています。1台のサーバーで複数のバーチャルホストを収容する場合、設定ファイルを /etc/nginx/conf.d 以下にまとめることで管理を容易にすることができます(nginx.confに直接記述しても構いません)。

/etc/nginx/conf.d ディレクトリ以下の設定ファイルから、アクセスログとエラーログのパスを確認してみます。

[hamada@popotest ~]$ cat /etc/nginx/conf.d/www.example.com.conf | egrep '(^[[:space:]]{0,}(access|error)_log)'
    access_log  /home/vhosts/www.example.com/logs/NGINX/access.log main;
    error_log   /home/vhosts/www.example.com/logs/NGINX/error.log warn;

このように、バーチャルホストごとにログファイルを取得していることがわかりました。php-fpmやMariaDBも、同様に設定ファイルからログファイルを探すことができますので、ここでは省略しますが、あわせて確認してみるとよいでしょう。

ログにはどんなエラーが書かれているかを確認してみよう～エラーメッセージから読み取った障害原因と、復旧方法、確認方法

それでは、先ほどどこにあるか確認したエラーログを見てみましょう。するとこのような文字列を発見しました。

2018/01/18 16:49:10 [error] 892#892: *2945 FastCGI sent in stderr: "PHP message: WordPress database error Disk full (/tmp/#sql_39a_0.MAI); waiting for someone to free some space... (errno: 28 "No space left on device") for query SHOW FULL COLUMNS FROM `wp_usermeta` made by wp_signon, wp_set_auth_cookie, WP_Session_Tokens->create, WP_Session_Tokens->update, WP_User_Meta_Session_Tokens->update_session, WP_User_Meta_Session_Tokens->update_sessions, update_user_meta, update_metadata, add_metadata" while reading response header from upstream, client: 192.168.0.127, server: www.example.com, request: "POST /wp-login.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com", referrer: "https://www.example.com/wp-login.php?loggedout=true"

PHPプログラム(WordPress)がデータベースへ書き込もうとしてDisk fullのため書き込めない(ログインのセッションが確立できない)ということがわかりました。

それではdfコマンドでディスク使用率を確認してみましょう。

$ df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/vda3         16G   15G     0  100% /
devtmpfs         2.0G     0  2.0G    0% /dev
tmpfs            2.0G     0  2.0G    0% /dev/shm
tmpfs            2.0G   17M  2.0G    1% /run
tmpfs            2.0G     0  2.0G    0% /sys/fs/cgroup
tmpfs            396M     0  396M    0% /run/user/500

なんということでしょう。 / パーティションの使用率が100%ではないですか・・・。これで、当初申告のあった障害である「サイトの閲覧はできるが管理画面へログインができない」の説明がついたことになります。ディスク使用量を圧迫しているファイルを特定し、要否判断の上削除して障害は復旧しました。

障害報告と再発防止策

さて、障害原因を特定して対処も行い、お客様へ電話で報告したのですが、お客様にあまり納得いただけず、障害報告書を書いて欲しいと言われてしまいました。電話が終わったと同時に、客先訪問から上司が戻ってきたので相談したところ、次のアドバイスを貰いました。

障害発生から収束までの対応履歴を時系列で報告する
直接の障害原因と影響が何だったのかを明確にする
再発防止策および障害早期発見の施策実施を約束する

障害報告書には最低限これらの要素を盛り込みましょう。今回の障害は不要ファイルをサーバー内に放置し、ディスク使用率が100％になったことが直接の原因でした。技術的にはこれで説明がつきますが、本来不要なファイルがなぜサーバー内に置かれたのか、そしてしばらく気が付かなかった(気がつく仕組みがなかった)のか、は人為ミスであると言わざるを得ません。

データベース保守のためにクエリログを一時的に取得するなど、業務都合でファイルを生成することがあるでしょう。しかし、どれだけディスクを消費するのかを常に確認しながら実施しないと、今回のような障害をおこす原因となってしまいます。また、仮にサーバー内にファイルを置いたとしても、ディスク使用率などのリソースを常時監視し適切にしきい値を設定しておけば、ディスク使用率が100%になる前に気がつくことができ、サービス障害を防ぐことができた可能性もあります。

人は間違う生き物です。間違わない努力は当然に必要ですが、個人の頑張りや精神論に頼っていては疲弊してしまいかねません。WEBサーバーの運用監視については、いずれ回を追って取り上げてみたいと思います。