Gitaeを作ったきっかけは、何度も同じ実務的な疑問にぶつかったことでした。このWebサイトは本当に落ちているのか。それとも、問題は自分の環境だけにあるのか。
ブラウザでページが開かなかった、という事実だけでは原因は分かりません。origin serverが停止している可能性もあれば、DNS、HTTPS証明書、ルーティング、firewall、閉じた／filterされたポート、ISP、VPN経路、ブラウザの状態、ローカルキャッシュなどが原因のこともあります。見える症状は同じでも、取るべき対応はまったく異なります。
私がGitaeで解決したかったのはそこです。単に緑か赤かを表示するのではなく、次にどのレイヤーを調べるべきかを絞り込めるようにしたいと考えました。
本当に解決したかった問題
シンプルなwebsite checkerの多くが答えるのは、「ある時点で、ある場所から、そのURLが応答したか」という狭い問いです。それ自体は有用ですが、障害原因の診断とは別物です。
DNSが誤っていれば、applicationを再起動しても直りません。HTTPSが証明書の問題で失敗しているなら、ページ本文を変更しても意味がありません。TCP portに到達できなくても、serverそのものは稼働している場合があります。外部serverからは開くのに自分の回線からだけ開かないなら、application serverではなく、自分のnetworkから宛先までの途中に問題がある可能性もあります。
そこでGitaeでは、Webサイトは複数の依存関係からなるチェーンであり、各チェックはその一部分についての証拠を返す、という考え方を中心にしました。
外部からの視点は有用だが、絶対的な答えではない
Gitaeのチェックは、私が運用しているモスクワとヘルシンキのVDS serverから実行されます。最初に問題を見つけたPCやnetworkとは別の場所から確認できることに意味があります。
ローカルでは開かないのに両方のVDSから応答するなら、「originがインターネット全体から完全に到達不能」という可能性は低くなります。そういう場合は、ローカルDNS、ISPのroute、VPN、ブラウザ、firewallなど、経路や環境に依存する要因を優先して調べます。逆に、外部probeからも失敗するなら、server側、DNS、証明書、routing、あるいはより広いnetwork障害を疑う材料が増えます。
ただし、remote checkがlocal checkより自動的に「正確」になるわけではありません。2か所のVDSで正常でも、別の国、ISP、CDN edge、networkでは失敗することがあります。私にとってremote checkは追加の観測点であり、インターネット全体に対する判定ではありません。
Gitaeが現在確認するもの
現在のGitaeには、障害がどのレイヤーにあるかを切り分けるときに私が確認したいツールをまとめています。
- Website check — 外部serverからURLが応答するかを確認します。
- SSL check — HTTPS/TLS証明書の状態や証明書に関係する問題を確認します。
- DNS check、nslookup、dig — domainがどう名前解決され、どのDNS recordが返っているかを調べます。
- Reverse DNS と IP check — IP情報やPTR/reverse-DNSの情報を表示します。
- Domain info と domain age — domainに関する基本情報を確認します。
- Port check — probe地点から対象portへ到達できるかを確認します。
- Find your IP — service側から見えるpublic IPを表示します。
- Ping と traceroute — latency、packet loss、hostまでの経路についてnetwork-levelのシグナルを得ます。
- Hosting check と CMS detection — infrastructureやtechnologyを特定する手掛かりを表示します。
ここで重要なのは、これらをすべて「シグナル」として扱うことです。直接観測できるものもあれば、公開情報から推測しているものもあります。PTR recordだけでserverの所有者を証明することはできません。公開fingerprintに基づくCMS detectionも、正確なsoftware stackの証明ではありません。あるprobeからportへ到達できないからといって、そのportが世界中でclosedとは限らず、途中でfilterされている可能性もあります。
結果をどう読むか
単独の結果を見るより、複数の結果を組み合わせたときに価値が出ます。
たとえばDNSが期待したaddressを返し、HTTPS証明書もvalidで、2つの外部VDSからwebsiteが応答しているのに自分の環境だけ開かないなら、serverを変更する前にローカル経路を詳しく調べます。逆にDNSの応答が不整合だったり、remote website checkも失敗したりするなら、infrastructure側を調べる根拠が強くなります。
Pingやtracerouteにも注意が必要です。ICMPはfilterやrate limitされることがあります。tracerouteで途中のhopが表示されないからといって、そのnodeが故障しているとは限りません。またpingに応答しないhostでもHTTPSは正常に提供できる場合があります。これらは「合否判定」ではなく、追加のcontextを得るための道具です。
Gitaeで大切にしている考え方はシンプルです。1つの成功したcheckだけではsystem全体の正常性は証明できず、1つの失敗したcheckだけでは原因まで特定できません。
可用性とSEOを混同しない
SEOの観点でもavailabilityは重要ですが、ここでは因果関係を強く言い過ぎないようにしています。技術的なdowntimeとranking problemは同じではありません。Crawlingとindexingも同じではなく、indexingとtrafficも同じではありません。
安全に言えるのは、DNS、network、server errorによってcrawlerがsiteへ到達できなければ、その時点では対象contentを正常に取得できないということです。Googleは、crawl時のnetwork errorやDNS errorをserver-sideの5xx errorと同様に扱い、長時間のunavailabilityはcrawlや既にindexされているURLへ影響し得ると説明しています。ただし、短い障害が必ずSEO lossにつながるわけではありませんし、diagnostic toolだけでtraffic変化の原因がdowntimeだったと証明することもできません。
User側についてはもっと単純です。siteへ到達できなければ使えません。siteの性質によってはsession、lead、conversion、revenueの機会損失につながる可能性がありますが、diagnostic result自体がbusiness impactを計算してくれるわけではありません。
「サイトが落ちた」ときの実用的な確認順序
Gitaeのようなtoolに私が求めているworkflowは次のようなものです。
- 別networkから症状を確認する。 自分のbrowserだけをインターネット全体の状態だと考えず、外部probeからURLを確認します。
- DNSを確認する。 domainが解決できるか、期待するrecordが返っているかを見ます。
- HTTPS/TLSを確認する。 certificate validityやconnection errorを確認します。
- 必要なportを確認する。 少なくともprobe地点から到達可能かを見ます。
- network signalを比較する。 pingとtracerouteを補助情報として使い、単純なpass/fail判定にはしません。
- IP、reverse DNS、hosting、CMSのシグナルを見る。 想定しているinfrastructureへ到達しているかを確認する材料にします。
- その後で調査対象を絞る。 application、server、DNS、network path、local environmentのどこを優先すべきかを判断します。
これは万能なincident response手順ではありません。私が避けたかった「サイトが開かない」という一つの症状だけを見て、関係のないレイヤーを変更してしまうことを減らすための順序です。
まず実用性。収益化はその後
現在Gitaeは収益化していません。まず自分自身が使うために作りました。自分のPCの外からsiteを確認し、そのままDNS、certificate、port、networkの診断へ進める場所が欲しかったからです。
今の目標はdiagnosticsをもっと役立つものにし、SEOと実際の需要によってorganic trafficを得られるかを見ることです。もし少なくとも一定のtrafficが得られれば、instant messenger通知付きの自動website monitoringを追加したいと考えています。手動診断と同じ考え方を、障害の検知まで拡張するイメージです。まずunavailableになったことを知り、その後すぐ調査を始められる情報を出す。
最後までシンプルにしておきたいこと
中心の考え方は変わりません。「up」と「down」は症状であって、説明ではありません。
DNS、HTTPS/TLS、routing、port、hosting、application、そしてuser自身のnetworkまで、単純なavailability problemに見える現象へ影響します。Gitaeがすべてのroot causeを自動で特定できるわけではありませんし、それらの外部VDS地点だけでインターネット全体の状態を知ることもできません。それでも、独立した複数のシグナルを1か所で確認できます。
私が欲しかったのは、単に「サイトが開かない」と言うtoolではありません。そこから一歩進んで、「次にどのレイヤーを調べるべきか」を考えやすくするtoolです。