pingを使わずcurlをマスターしよう【バックエンドエンジニア】
はじめに
入社半年の頃、先輩から 「ping通ってる？」 と言われました。
どんなシチュエーションかすっかり忘れてしまいましたが、経験の浅かった私は「そうか、pingってやつで確認すればいいんだな！！！」と素直に刷り込まれました。
当時「ping コマンド」と検索し読んだ記事でも「ネットワークの疎通確認に役立つコマンドです」とのあり、とりあえずping使えばいいんだ！と認識は強化されるばかりでした。
しかしこれは間違いでした。
少なくとも、アプリケーションレイヤーを主戦場とするフロントエンド・バックエンドエンジニアにとっては、pingで確認するのはむしろ有害であると思えます。
私だけかと思いきやよくある勘違いらしいので、今回記事にして解説したいと思います。
tl,DR
- pingはレイヤー3のICMPプロトコル。AWSリソースなら明示的に許可しない限りセキュリティグループで弾くので基本通らないよ
- 逆にpingが通ってもアプリケーションの障害には気づけないよ（プロセスが落ちてる等）
- アプリケーションの疎通と生死判断はcurlで判断しよう
- 迷ったら
curl -Iv https://example.comでOK
前提知識
OSI参照モデル
OSI参照モデルは、コンピュータのネットワーク通信を7つの階層に分けて考えるためのモデルです。
Webアプリケーションが動くのは「アプリケーション層（レイヤー7）」、pingが動作するのは「ネットワーク層（レイヤー3）」と別の階層です。
プロトコル
プロトコルは、コンピュータ同士が通信を行うための共通のルールや方法のことです。
「人の意思伝達」で例えると、以下のような方法がありますね。
- 話して伝える
- 対面
- 電話
- ビデオ
- テキストで伝える
- 手紙
- オンライン
- LINE
- Slack
- 表現で伝える
- 絵画
- 音楽
それぞれ特性が違い、相手との関係や距離によって使い分けています。
これらは「人間の意思疎通のプロトコル」と言えます。
コンピュータも、目的や方法によって様々なデータの送り合い（リクエスト・レスポンス）をしている、と言えます。
pingとは
pingは、ICMP（インターネット・コントロール・メッセージ・プロトコル）というプロトコルを利用して、サーバーとネットワークの疎通確認を行うためのコマンドです。
前述の通りレイヤー３で動作します。
pingによって、ネットワーク機器とOSのレベルで通信が可能か調べることができるためネットワークエンジニアは重宝するそうです。しかし、それ以上の情報は得られません。
つまり、 サーバーが生きているか死んでいるかは分かっても、そこで動いているアプリケーションが正常に動作しているかは全く別問題であるということです、、！
明示しない限りセキュリティグループで弾かれる
例として、EC2へローカルからアクセスしたいと思ったとします。
（「普通にブラウザアクセスすりゃいい」と言えばそうなのですが、、一旦進めます）
AWSリソースは基本的にセキュリティグループで通信を制御します。Webサーバーとしては通常、HTTPやHTTPSの通信（ポート80, 443）のみを許可して、ICMPの通信（ping）はデフォルトで拒否していることが多いです。
そのため、pingを試しても応答がないことがほとんどです。この場合、サーバーが動いているかの判断も当然できません。
pingによる誤った判断
-
「pingが通らないのでアプリケーション落ちてます！」
→ 🙅♂️
pingが拒否されているだけかもしれません。アプリケーションの方は正常に動いている可能性があります。 -
「障害の原因調査中です、pingは通っているのでアプリケーションは動いていると思います」
→ 🙅♂️
ping自体は通っても、アプリケーションのプロセスが落ちていたり、内部でエラーを起こしている可能性があります。OSレベルでICMPの応答パケットがあるからと安心しても、アプリケーションが正常とは限らないです、、、😭
このため、「判断を誤るからアプリケーションエンジニアはpingを使わない方がいいよね」、というのが本記事で伝えたいことの一つ目となります。
解決策
ではどのようにアプリケーションが正常かを判断するか？というと、レイヤー7、つまりアプリケーション層のプロトコルで判断しましょう。
HTTPやHTTPS、telnetあたりが候補になります。(telnetはポートが開いてるか確認できます）
その中でも一番使い勝手もよいcurlコマンドをぜひマスターしましょう！！
curlを使いこなす
curl(カール)とは
URLを指定してデータを送受信するためのCLIツールです。HTTP以外にもFTPやSMTPなどのプロトコルをサポートしており用途は広いです。
基本系は以下です。
curl https://example.com
オプション
curlにはオプションがたくさんあります。全て覚える必要はなく、いくつか使えるだけでもデバッグや疎通確認に便利に使えます。
| オプション | 意味 |
|---|---|
| -I | ヘッダー情報のみを表示 |
| -v | 通信の詳細（ヘッダー情報、リダイレクトなど）を詳細に表示 |
| -X | リクエストメソッド（GET, POSTなど）を指定 |
| -d | POSTリクエストのデータを指定し |
| -o | レスポンスをファイルに保存 |
| -s | プログレスメーターなどを非表示 |
迷ったらこれ
Webアプリケーションの稼働状況を確認したいだけなら、迷わず次のコマンドを使いましょう。
curl -Iv https://example.com
-
-I（大文字のI）でヘッダー情報だけを取得するため、レスポンスボディが膨大なデータ量の時でも素早く結果を得られます。
-
-vで詳細なログ（リクエスト及びレスポンスヘッダー、SSL/TLS通信の詳細など）を確認できるため、何が原因でエラーが起きているのかを判断することができます
HTTPステータスコードの確認と、リダイレクトやタイムアウトといった詳細な状況も把握できるので重宝します。覚えておいて損はないはず、、、!
pingではなくcurlに慣れていきましょう。
まとめ
- アプリケーションの生死判断には、pingを使わないこと
-
curl -Iv https://example.comで確認したり、オプションを使いこなしたりしましょう
実際にはcurlだけで終わることはなく、サーバー内部に入ってプロセスやメモリの確認もします。何より今は障害検知・特定はモニタリングツールで分かるように仕組み化していることも多いかなと思います。その方が圧倒的に早いので。
だからこそ基礎知識を理解しコマンドで解決できる力を身につけ、その上で便利なツールを使っていきたいですね！
おまけ
ここからはAIに聞いてみた回答となります。
Q. pingによる誤った判断を５つ挙げてください。
A.
「pingが通るからWebサーバーは問題ないはず。原因はデータベース側だ。」
❌ Webサーバーのプロセスが落ちていても、OSレベルのネットワークスタックが応答する限り、pingは通ります。Webサーバープロセスとデータベースの間の通信障害や、データベースの応答が遅いなどの問題はpingでは分かりません。
「pingで応答が遅いから、ネットワーク帯域が狭い。」
❌ pingの応答速度は、単にネットワーク帯域だけでなく、サーバー側の処理負荷（CPUやメモリ）や、ネットワーク機器（ルーターやファイアウォール）の処理遅延など、様々な要因で変動します。遅延の原因をpingだけで特定することはできません。
「pingが通らないから、サーバーのOSがクラッシュしている。」
❌ pingが通らないのは、単にファイアウォールやセキュリティグループでICMPが拒否されているだけの可能性があります。OS自体は正常に稼働しており、SSHなどでログインできることもあります。
「pingは通っているのに、ブラウザからアクセスできないからDNSがおかしい。」
❌ pingがIPアドレスで通る場合でも、DNSレコードの設定ミス、ブラウザのキャッシュ、プロキシ設定など、様々な要因で名前解決が失敗し、ブラウザからのアクセスができないことがあります。pingはIPアドレスレベルの疎通しか確認しないため、DNSの問題を特定することはできません。
「pingでサーバーが応答しているから、サービスは高負荷に耐えられている。」
❌ pingは非常に軽量なパケットであり、サーバーにほとんど負荷をかけません。pingの応答が早くても、アプリケーションが高負荷状態になると応答不能になったり、エラーを返したりする可能性があります。サービスの健全性を判断するには、アプリケーション層のレスポンスタイムや、CPU・メモリ使用率などのメトリクスを確認する必要があります。
まとめると
pingが通る／通らない ＝ OSレベルでICMPが応答するかどうかを確認しているだけ
pingでは分からないこと
アプリケーションの死活状態
データベースや他サービスとの接続状態
帯域の十分さ（スループット測定ではない）
DNSの正常性
サービスの高負荷耐性
pingの用途は限定的なため、診断には多層的なチェックが必要です。
多様な視点を提供してもらえました。
本記事は以上です、お読みいただきありがとうございました。
Discussion