- Webサイトのダウンタイムについて
- 外形監視でダウンタイムを検出する方法
- ダウンタイムが発生したときの対処法
- サーバー構成を把握する
- ドメイン設定を把握する
- 問題の切り分け方
- nslookupコマンドでサーバーのIPアドレスを確認する
- pingコマンドでサーバー疎通確認をしてみる
- pingがtime outする場合
- SSL証明書を確認する
- サーバーコンソールに入って内部を確認する
- まとめ
Webサイトのダウンタイムについて
Webサイトのダウンタイムとは、Webサイトにアクセスできない状態のことを指します。
単純なWebサイトであっても、時間経過によってデータ量が増えデータベースに負荷がかかったり、アクセスごとにログファイルが出力されディスクを圧迫したり、SSL証明書の期限切れが発生したりといった人為的な設定ミスや管理不足があると、突然Webサイトにアクセスできなくなる場合があります。それらに起因して、Webサイトにダウンタイムが発生します。
ユーザーがお客様のサイトにアクセスする理由は何らかの情報を得ることであり、ユーザーにとって価値を提供しつづけるWebサイトは、常にオンラインでアクセス可能な状態を維持する必要があります。多くのインターネットビジネスにおいて、Webサイトのダウンタイムはサイト運営者とユーザー双方にとって良くない事です。URL監視は、そういった予期しない問題を検出するための解決策となりえます。
外形監視でダウンタイムを検出する方法
外形監視とは、Webサイトの特定のURLに対して定期的にアクセスを行い、Webサイトが正常に稼働しているかどうかを確認し、ダウンタイムが発生した場合にはほぼリアルタイムに運営者へ通知する仕組みのことを言います。これによりダウンタイムの発生に気づくことができ、即時対応することが可能です。
ダウンタイムが発生したときの対処法
ダウンタイムの要因はさまざまですが、問題は意外にも単純な設定ミスである可能性があります。まずは問題がどこにあるかを特定するために、問題の切り分けを行う必要があります。問題の切り分けができると、ピンポイントに問題特定が可能になります。以下ではダウンタイムが生じた場合に確認するべきポイントを解説いたします。
サーバー構成を把握する
お客様のWebサイトがどのようなサーバー構成で提供されているかを知っておく必要があります。例えば、レンタルサーバーを借りてウェブサイトをホストしている場合であったり、VPS（バーチャルプライベートサーバー）の上にWebサーバーが構築されていたり、GCPやAWSのようなIaaS（Infrastructure as a Service）の上でWebサーバーが構築されていたりします。お客様のウェブサイトの運用基盤がどのような形であるか把握しておきましょう。
ドメイン設定を把握する
また、ユーザーがどのドメイン（FQDN）でアクセスされるかも重要です。ユーザーは通常、Google等の検索エンジンからサイトを発見します。アクセスする際には特段気に留めるものではありませんが、ドメインの管理もまた重要な要素です。お客様のウェブサイトは、どのドメインで管理されているかや、AレコードがどのIP、サーバーに解決されるかなどを把握しておくことで、問題の特定に辿り着きやすくなります。
問題の切り分け方
以下では、問題切り分けの方法をご紹介いたします。
nslookupコマンドでサーバーのIPアドレスを確認する
このステップでは、ドメインの正常性を確認します。下記のコマンドを実行し、DNS名前解決ができるかを確認します。IPアドレスが正常に返ってくれば、ドメイン設定について正常な設定が行われていると考えられます。IPアドレスが返ってこない場合は、ドメインの設定を見直しましょう。
- ドメインのDNSサーバーの指定が間違えている可能性があります。ドメインを契約している会社のコントロールパネルで、どのネームサーバーに管理を委任しているか確認してください。
- DNSレコードのAレコードが設定されていない可能性があります。ドメインを契約している会社のコントロールパネルで、Aレコードがどのサーバーを指し示しているか確認してください。
- 社内ネットワークからの名前解決では、社内で管理しているDNSサーバーの設定が正しくない可能性があります。ネットワークの管理部署に問い合わせてください。
PS C:\Users\XXX> nslookup url-hawkeye.com Server: UnKnown Address: 2404:1a8:7f01:b::3 Non-authoritative answer: Name: url-hawkeye.com Address: 163.44.97.23
pingコマンドでサーバー疎通確認をしてみる
Webサイトをホストしているサーバー自体がオンライン状態であるかどうか、サーバーとの疎通確認をするとよいでしょう。これによりネットワークに起因する問題であるかどうかを特定できます。
ドメインのＡレコードに単一のIPアドレスが指定されている場合、そのIPアドレスでサーバーがホストされています。このIPアドレスに対してPINGを送信してみましょう。この時、あくまでもネットワークレベルの疎通確認を行いたいため、ドメインを指定した名前解決を行わないでください。生のグローバルIPアドレスを指定して、以下のコマンドを実行します。
ping xxx.xxx.xxx.xxx
Windowsであれば、コマンドプロンプトやWindowsTerminalなどのプリインストールされたアプリケーションをつかって上記のコマンドを実行できます。
Reply fromからはじまる出力があれば、ネットワーク的にサーバーにはアクセスできる状態であるため疎通確認は成功です。この時点で疎通が確認できない場合、サーバー側の問題である可能性があります。
- Webサーバーミドルウェア（ApacheやNginx）が起動していない。
- Webサーバーミドルウェア（ApacheやNginx）のエラーが出ているか確認してください。
- Webアプリケーションのエラーが出ていないか確認してください。
PS C:\Users\HG> ping 163.44.97.23
Pinging 163.44.97.23 with 32 bytes of data:
Reply from 163.44.97.23: bytes=32 time=10ms TTL=112
Reply from 163.44.97.23: bytes=32 time=5ms TTL=112
Reply from 163.44.97.23: bytes=32 time=6ms TTL=112
Reply from 163.44.97.23: bytes=32 time=5ms TTL=112
Ping statistics for 163.44.97.23:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 10ms, Average = 6ms
pingがtime outする場合
pingがタイムアウトする場合は、以下の要因が考えられます
- サーバーの電源が入っていない
- ネットワークの問題
- ICMPのポートが閉じられている
PS C:\Users\HG> ping 163.44.97.23
Pinging 163.44.97.23 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 163.44.97.23:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
SSL証明書を確認する
基本的にhttpsプロトコルでアクセスできるように構成されていると思います。SSL証明書が期限切れになっている場合、通信内容が傍受させる可能性があるためブラウザは警告を表示します。SSL証明書を契約している会社に問い合わせ、証明書の更新を行なっていないか確認してください。
サーバーコンソールに入って内部を確認する
レンタルサーバーの場合は、運営事業者に問い合わせを行って下さい。AmazonEC2やVPS、自社サーバー（いわゆるオンプレミス）の場合、サーバーコンソールにアクセスできる場合があり、詳細な問題特定が可能です。
Webサーバーにはいくつか種類があり、一般的には以下のようなものがあります。
- Apache
- Nginx
- ISS
これらのWebサーバーミドルウェアはアクセスログやエラーログを吐き出す設定になっているので、エラーログにエラーが出力されていないか確認してみましょう。また、Nginxなどの場合はプロキシしている場合があるため、アプリケーションサーバーのログも確認してみましょう。
まとめ
Webサイトが稼働状態であることを担保するために、URL監視は有用な手段です。ビジネス機会損失を最小化するために、URL監視を設定しておきましょう。問題解決にはさまざまな知識が必要ですが、問題の切り分けはできるようになると復旧までの時間を短縮することができます。