こんにちは。
社内開発のインフラ全般を担当している、のだです。

弊社は受託開発事業を行っており、その大半を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サービスのトラブルの切り分け方法を記載してきました。
トラブルの種類は千差万別で、すべてを洗い出すことはできませんが、
こうした手順を覚えておくことで、解決までのスピードを速めることができます。

本記事がトラブル解決の足掛かりになれば幸いです。

のだ
CSVIT事業部 のだ
DevOpsに興味津々