はじめまして！
テックブログ初投稿です。
初回は、20年間インフラエンジニアとして就業してきた中で、 役に立った「パケットキャプチャ」のご紹介。
まず、パケット、と聞くとパケット通信やデータ通信関連の事を想像されるかと思います。
その通り、パケットとはデータ通信時に最小化されたデータの事を言います。
ネットワーク系のエンジニアなら、パケットキャプチャ/パケットダンプ、 と言う響きに馴染みも多いかもしれません。
しかし、サーバエンジニアや昨今のクラウドエンジニアと呼ばれるエンジニアは、 あまり利用する機会も、耳にする機会も無いのではないでしょうか。
とは言え、この技術を習得すれば、 サーバ障害時の障害一次切り分けや、クラウドサービス上でのデータの流れを追う事が出来、 どこが原因で障害が発生しているのか、もしくは煮詰まっているシステム不具合の解消に役立ったりします。
ただしパケットを見る、と言う事は、もちろんネットワークの最低限の知見が必要になってきます。
このためTCP/IPの基礎知識は学習しておく事を、インフラ領域の分野問わずエンジニアにはおススメします。 ※TCP/IPの基礎については、また別の機会にブログを書きます。
サーバとサーバ、インスタンスとロードバランサ、等々、 インフラシステムのそれぞれの個体からは必ず別の個体へデータ通信が行われています。
このデータ通信の中身を見る事で、ログ調査だけの障害調査からの脱却が可能です。
確かにサーバやクラウド上で障害が発生した場合、 真っ先に確認するのはステータス、次にログだと思います。
しかしログだけでは切り分けが難しい上位機器、上位(ネットワーク的に)サービスとの間での障害の場合、 どちら側に原因があるのかを、ログだけで判断するのは正直困難です。
ここで登場するのがパケットキャプチャソフトウェアです。
LinuxOSではtcpdumpと言うパッケージがそれに当たり、WindowsだとWireSharkが有名です。
それぞれ見方は全然違いますが、流れている内容はデータ通信のパケットの順序なので、 その順序におかしい点が無いか、どこからおかしいパケットが届いているのか、 それともパケット自体が届いていないネットワーク間の障害なのか等を判断する事ができいます。
筆者は20年間サーバエンジニア→クラウドエンジニアの流れで現在の職務に就いていますが、 一番最初の会社でパケットキャプチャ技術とネットワークエンジニアを少し齧っていたおかげで、 インフラの部門に配置された際に、他のサーバエンジニア/クラウドエンジニアでは見付けられない問題個所や、 障害対応時の早急な問題解決ができた事もあります。
この年末年始に、パケットの見方を学習するのも、来年の新たなるエンジニアとしての飛躍に、 おススメですよ。
