こんにちは。
社内開発のインフラ全般を担当している、N.Kです。
弊社は受託開発事業を行っており、その大半をWEBサービスの構築、運用が占めています。
運用している以上はトラブルが避けられませんが、アプリエンジニアに比べてインフラエンジニアの割合が低いため、インフラにおけるトラブル解決のスピードがネックとなっています。
そうした背景から、WEBサービスにおける簡単なトラブル切り分け方法を執筆するに至りました。
これさえ出来るようになれば原因解決の足掛かりになりますし、何よりインフラエンジニアへ調査を依頼する際にも、話がスムーズにいくことでしょう。
本稿の目的
WEBサービスのトラブル発生時における、インフラのなんちゃって切り分けができることを目的としています。
本腰を入れて調査するのはインフラエンジニアのお仕事ですので、大体の障害箇所が特定できていれば大変助かります。
ちなみに、以下のような構成を前提としてお話していきます。
- クライアント：Windows
- システム構成：Web-AP/DBの2層構造
WEBサービスにトラブルが発生！？ ～それってどういう状況？～
WEBサービスにトラブルが発生した際に、「WEBサービスがおかしいです」とだけ伝えてくる人、結構多いです。
自分で調べるにしても人に依頼するにしても、「こういう状態or動作でトラブルと判断した」という内容を伝えてくれるだけで、だいぶ変わってきます。
例えば以下のような感じです。
- WEBサービスの画面が表示されない
- WEBサービスの画面表示・画面遷移が遅い
- WEBサービス利用中にシステムエラーが発生した
などなど。
上記は「WEBサービスにトラブルが発生した」際によく目にする文章ではないでしょうか。
今回はこの3つを例にとって、切り分けを行っていきます。
1.WEBサービスの画面が表示されない
WEBサービスの画面が表示されない場合、多くはWEB-APサーバまで通信が届いていないことが考えられます。
クライアント～WEB-APサーバまでの通信の状態を確認しましょう。
■WEB-APサーバと疎通できるか
まずはクライアントからWEB-APサーバに対して、ping応答が返ってくることを確認しましょう。
※相手側の機種や設定によっては、ping応答を返さない場合もありますので、注意してください。
■確認方法
> ping <ドメイン名 または IPアドレス>
■確認観点
WEB-APサーバからの応答が返ってくれば、通信に問題はありません。
> ping casleyconsulting.co.jp
casleyconsulting.co.jp [49.212.207.13]に ping を送信しています 32 バイトのデータ:
49.212.207.13 からの応答: バイト数 =32 時間 =17ms TTL=47
49.212.207.13 からの応答: バイト数 =32 時間 =16ms TTL=47
49.212.207.13 からの応答: バイト数 =32 時間 =15ms TTL=47
49.212.207.13 からの応答: バイト数 =32 時間 =18ms TTL=47
49.212.207.13 の ping 統計:
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)、
ラウンド トリップの概算時間 (ミリ秒):
最小 = 15ms、最大 = 18ms、平均 = 16ms
WEB-APサーバからの応答が返ってこない場合、以下のことが考えられます。
-
- サーバ側のネットワークインタフェースの異常(サーバが起動していないなど)
→サーバの状態を確認しましょう。
-
- サーバまでの通信経路が異なる
→tracertでサーバまでの通信経路を確認しましょう。
-
- サーバもしくはファイアウォールに通信がブロックされている
→ファイアウォールの設定を確認しましょう。
> ping 49.212.207.13
49.212.207.13 に ping を送信しています 32 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
49.212.207.13 の ping 統計:
パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、
以下のような結果では、名前解決に失敗しています。
次項の「■ドメインの設定は正しいか」で深堀しましょう。
> ping casleyconsulting.co.jp ping 要求ではホスト casleyconsulting.co.jp が見つかりませんでした。ホスト名を確認してもう一度実行してください。
■ドメインの設定は正しいか
WEBサービスにおいてドメインを利用している場合、名前解決ができることを確認しましょう。
■確認方法
> nslookup <ドメイン名>
■確認観点
IPアドレスが返ってくれば、名前解決は問題ありません。
> nslookup casleyconsulting.co.jp サーバー: UnKnown Address: 192.168.10.1 権限のない回答: 名前: casleyconsulting.co.jp Address: 49.212.207.13
IPアドレスが返ってこない場合、ドメインまたはレコードの設定に問題があるか、
クライアント側で設定しているDNSサーバに問題があります。
> nslookup casleyconsulting.co.jp サーバー: UnKnown Address: 192.168.10.1 *** UnKnown が casleyconsulting.co.jp を見つけられません: Non-existent domain
名前解決するDNSサーバを別で指定することも可能です。
切り分け方法として、こちらも利用しましょう。
> nslookup casleyconsulting.co.jp 8.8.8.8 サーバー: dns.google Address: 8.8.8.8 権限のない回答: 名前: casleyconsulting.co.jp Address: 49.212.207.13
■WEBサービスは起動しているか
WEB-APサーバにて、 次のことを確認しましょう。
- サービスが起動していること
- サービスポートがListenしていること
■確認方法
$ sudo systemctl status <サービス名> $ sudo netstat -anpt | grep LISTEN
■確認観点
必要なサービスが起動しており、ポートがListenしていれば問題ありません。
ここではApache、80/tcpを確認します。
$ sudo systemctl status httpd # ←HTTPDサービスの状態確認 ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since 水 2020-01-08 06:00:00 JST; 6h ago # ←activeであることを確認する ~~~省略~~~ $ sudo netstat -anpt | grep LISTEN # ←LISTENしているポートを表示 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 15402/httpd
サービスが起動していない、もしくは必要なポートがListenしていない場合は、
サービスを起動したり、ポートの設定を確認しましょう。
$ sudo systemctl status httpd ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled) Active: inactive (dead) # ←inactiveなので、サービスが起動していない ~~~省略~~~ $ sudo netstat -anpt | grep LISTEN $
■ファイアウォールの設定は問題ないか
WEB-APサーバにおいてファイアウォールを利用している場合は、設定内容を確認してみましょう。
以下は、RHEL7/centos7標準のファイアウォールの確認方法です。
※別途ファイアウォール製品を利用している場合は、そちらの設定を確認します。
■確認方法
$ sudo firewall-cmd --list-services --permanent
■確認観点
httpが許可されていれば問題ありません。
$ sudo firewall-cmd --list-services --permanent dhcpv6-client http ssh
もしhttpdが許可されていない場合は、追加しましょう。
$ sudo firewall-cmd --list-services --permanent dhcpv6-client ssh # ←httpが許可されていない $ sudo firewall-cmd --add-service=http --permanent success $ sudo firewall-cmd --reload success $ sudo firewall-cmd --list-services --permanent dhcpv6-client http ssh # ←httpが許可された
2.WEBサービスの画面表示・画面遷移が遅い
WEBサービスの動作に遅延が発生する場合、サーバの負荷が高まっていることが考えられます。
サーバの負荷状況を確認しましょう。
■サーバの負荷状況を確認するには
サーバの負荷状況を確認する方法として、以下のコマンドがあります。
■vmstat
現在のメモリやスワップ、CPUの負荷が高くなっていないかを確認します。
取り急ぎ、サーバの負荷を確認するのにおススメです。
$ vmstat -t 2 # ←2秒間隔で表示 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- -----timestamp----- r b swpd free buff cache si so bi bo in cs us sy id wa st JST 1 0 0 5995596 4172 1768168 0 0 75 503 200 186 5 2 93 0 0 2020-01-08 13:41:50 0 0 0 5995612 4172 1768168 0 0 0 0 18 22 0 0 100 0 0 2020-01-08 13:41:53 0 0 0 5995612 4172 1768168 0 0 0 0 20 22 0 0 100 0 0 2020-01-08 13:41:55 0 0 0 5995612 4172 1768168 0 0 0 0 17 22 0 0 100 0 0 2020-01-08 13:41:57 0 0 0 5995612 4172 1768168 0 0 0 0 9 13 0 0 100 0 0 2020-01-08 13:41:59 0 0 0 5995612 4172 1768168 0 0 0 0 23 24 0 0 100 0 0 2020-01-08 13:42:01
■free
現在のメモリの状況を確認する場合に使用します。
$ free -m # -m:MB単位で表示
total used free shared buff/cache available
Mem: 7821 235 5855 8 1730 7303
Swap: 2047 0 2047
■top
実行中のプロセスをリアルタイムで表示します。
必要な項目でソートすることも可能です。
- CPU使用率(降順)：Shift + p
- メモリ使用率(降順)：Shift + m
- 実行時間(降順)：Shift + t
$ top
top - 13:51:34 up 49 min, 1 user, load average: 0.00, 0.01, 0.05
Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8009232 total, 5995240 free, 241400 used, 1772592 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 7478272 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20691 root 20 0 162020 2264 1548 R 0.3 0.0 0:00.04 top
1 root 20 0 128136 6684 4032 S 0.0 0.1 0:04.26 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:00.19 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
■sar
サーバの過去の負荷状況を確認する場合に使用します。
※sysstatパッケージが必要です。
$ sar -r -u -f /var/log/sa/saXX # -r:メモリ -u:CPU -f:sarファイルの指定 Linux 3.10.0-957.21.3.el7.x86_64 (terraform1) 2020年01月08日 _x86_64_ (2 CPU) 13時10分02秒 CPU %user %nice %system %iowait %steal %idle 13時20分01秒 all 0.30 0.00 0.12 0.05 0.00 99.52 13時30分01秒 all 0.54 0.00 0.11 0.00 0.00 99.34 13時40分01秒 all 0.16 0.00 0.05 0.00 0.00 99.79 13時50分01秒 all 0.01 0.00 0.03 0.00 0.00 99.97 14時00分01秒 all 0.08 0.00 0.07 0.00 0.00 99.85 平均値: all 0.22 0.00 0.08 0.01 0.00 99.69 13時10分02秒 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 13時20分01秒 6027548 1981684 24.74 4172 1643844 329128 3.26 574584 1121372 12 13時30分01秒 5995604 2013628 25.14 4172 1645244 365376 3.62 605836 1118976 0 13時40分01秒 5995224 2014008 25.15 4172 1645296 365376 3.62 606072 1118900 0 13時50分01秒 5995332 2013900 25.14 4172 1645300 365376 3.62 606112 1118864 0 14時00分01秒 5994424 2014808 25.16 4172 1645468 365376 3.62 606372 1118908 0 平均値: 6001626 2007606 25.07 4172 1645030 358126 3.54 599795 1119404 2
■サーバのログを確認するには
負荷状況の確認と合わせて、サーバで何が実行されているかを判断するために、ログを確認します。
※OSがデフォルトで出力するログは、大体が/var/log 配下に集約されています。
■システムログ
システムログは /var/log/messages に記録されます。
# リアルタイムで表示させる場合はtail $ sudo tail -f /var/log/messages # 過去のログを確認したい場合はless $ sudo less /var/log/messages
■cronログ
cronログは /var/log/cron に記録されます。
サーバ内で定期的に実行されるバッチなどが記録されます。
# リアルタイムで表示させる場合はtail $ sudo tail -f /var/log/cron # 過去のログを確認したい場合はless $ sudo less /var/log/cron
負荷状況やログを確認することで、負荷が高くなった原因を特定することができると思います。
3.WEBサービス利用中にシステムエラーが発生した
システムエラーが発生する場合は、アプリケーションやデータベース側に何らかの不具合が発生した可能性が高いです。
開発した人であれば、見るべきログを判断したり、事象から何となく原因を察することもできるでしょう。
■ログ確認
「2.2 サーバのログを確認するには」と同様に、必要なログを確認していきます。
事象発生時間帯に怪しげなメッセージや、ERRORなどの不穏なメッセージが出力されていないか確認しましょう。
# リアルタイムで表示させる場合はtail $ sudo tail -f <path/to/file> # 過去のログを確認したい場合はless $ sudo less <path/to/file> # 特定のメッセージで絞り込みたい場合(下記は"error"で検索) $ sudo grep -i error <path/to/file> # ← -i:大文字小文字を区別しない
怪しげなメッセージが発見されたら、Googleで調べるなり関係者にヒアリングするなりしましょう。
■ログの在りかを探す
ログの出力先が不明な場合は、ログ関連の設定ファイルを確認したり、パッケージインストール時の情報を確認したり、検索して特定しましょう。
# パッケージインストール時のファイル一覧からログファイルの在りかを探す $ sudo rpm -ql <パッケージ名> # ログファイルの名前でディレクトリ内を検索する $ find <検索ディレクトリ> <ファイル名>
番外編 WEBサービスが利用できないのは自分だけ？ と思った時に確認する項目
実は「自分のクライアントが原因でした」なんてことがないように、「おやっ？WEBサービスが利用できない」と思ったら、こっそりクライアントの状況を確認しましょう。
- URLにミスはないか
- IPアドレス、デフォルトゲートウェイ、DNSサーバが設定されているか
- ルーティングの設定が影響していないか
- 無線APの接続先は正しいか
■URLにミスはないか
そもそもアクセス先のURLを間違っていた、なんてことがよくあります。
落ち着いてURLを再確認するか、必要に応じて関係者にヒアリングしましょう。
■IPアドレスなどの設定値は正しいか
DHCPを利用していると、あまり意識が向かないかもしれませんが、
必要なネットワークの設定が足りていない可能性もあるので、確認しましょう。
特に★印は意識しておいてほしい項目です。
> ipconfig /all Wireless LAN adapter Wi-Fi: 接続固有の DNS サフィックス . . . . .: 説明. . . . . . . . . . . . . . . . .: Intel(R) Dual Band Wireless-AC 3168 物理アドレス. . . . . . . . . . . . .: XX-XX-XX-XX-XX-XX DHCP 有効 . . . . . . . . . . . . . .: はい 自動構成有効. . . . . . . . . . . . .: はい IPv4 アドレス . . . . . . . . . . . .: 192.168.10.10(優先) ---- ★ サブネット マスク . . . . . . . . . .: 255.255.255.0 リース取得. . . . . . . . . . . . . .: 2020年1月22日 10:00:00 リースの有効期限. . . . . . . . . . .: 2020年1月23日 10:00:00 デフォルト ゲートウェイ . . . . . . .: 192.168.10.1 ---- ★ DHCP サーバー . . . . . . . . . . . .: 192.168.10.1 DNS サーバー. . . . . . . . . . . . .: 192.168.10.1 ---- ★ NetBIOS over TCP/IP . . . . . . . . .: 有効
■カスタムルーティングの設定が影響している
手動で登録したルーティングが、実は通信に影響している場合があります。
こちらも確認し、不要であれば削除しましょう。
> route print
===========================================================================
固定ルート:
ネットワーク アドレス ネットマスク ゲートウェイ アドレス メトリック
10.1.1.0 255.255.255.0 192.168.10.254 1
172.16.1.0 255.255.255.0 192.168.10.254 1
===========================================================================
> route delete 10.1.1.0
OK!
> route print
===========================================================================
固定ルート:
ネットワーク アドレス ネットマスク ゲートウェイ アドレス メトリック
172.16.1.0 255.255.255.0 192.168.10.254 1
===========================================================================
■無線APの接続先が違う
無線LANを利用していると起きがちな事象です。
実は無線APの接続先がゲスト用だったり、デザリング中の社用携帯に繋がっていた、なんてこともあります。
意外と見落としがちなので、こちらもしっかり確認しましょう。
すべて確認し終えたら
クライアント側の状態が正常であることを確認して、無事にWEBサービスが利用できれば万々歳です。
よくある話ですが、こういった確認をせずに話を持って来られることもあります。
ちゃんと確認をした上で、サービス側の問題としてアラートを上げたり、話を持ってきていただいた方が、
当事者も恥ずかしい思いをしなくても良くなります。
まとめ
ここまで、WEBサービスのトラブルの切り分け方法を記載してきました。
トラブルの種類は千差万別で、すべてを洗い出すことはできませんが、
こうした手順を覚えておくことで、解決までのスピードを速めることができます。
本記事がトラブル解決の足掛かりになれば幸いです。
