インフラエンジニアにおススメのシステムコール、参考記事とどう役に立つか

少し前の雑誌で恐縮ですが、今でもネットで手に入るWeb＋DB PressのVol.120の特集「Webページが表示されるまで　HTMLを運ぶプロトコルとシステムコールの裏側」がとてもいいので、紹介です。

WEB+DB PRESS Vol.120 https://www.amazon.co.jp/dp/B08Q764JKR/ref=cm_sw_r_tw_dp_0F5JA6ASV4K8YZTB3EJS

インフラ分野でエキスパートになりたい人は、システムコールを学ぶべきと私は思うのですが、そのきっかけとして良い記事だと思います。
なお、サンプルがC言語で書かれているので、そこは「ふーん」と読み飛ばしてもいいと思います。
システムコールそのものの話は記事を読んでもらうとして、この記事で書かれている内容が実際の現場でどう使えるのか、私の経験を基に紹介してみたいと思います。仕組みを学ぶと例えばこんなことがわかります。

strace：システムコールを追跡します。負荷が高いので本番環境ではとりずらいですが、実際インフラが何をしているのか調査するには一番のツールです。ストレージにI/Oしてるなとか、データを待っているな、とか分かります。
sendとrecvmsg：送ると受信待ちの関数です。多くのインフラソフトはソケットやファイルを使っているので、sendとrecv、writeとreadといった関数はよく見かけます。パフォーマンストラブルとか、ハングのときに、データを送っていないのか、パケットが届いていないのか、といった判断で使えます。
ソケット：ソケットの状態を確認して、ポートを開いているのか、listenなのか、establishedなのか、調べることがあります。つながらないなあというときに、通信初期フェーズをクリアしたかどうかの判断になります。
TCP/IPのチェックサム：昔、ドライバのバグでたまにチェックサムの値が変わるという不具合にあたったことがあります。チェックサムがチェックされ、パケットが捨てられます。再送の結果、今度は成功します。ただ、性能が大幅劣化して大問題になりました。パケットキャプチャして見つけました。
ＮＩＣ：昔、ＮＩＣの性能限界にあたったことがあります。帯域幅ではなくて、通信回数です。そんなときにNICのハードウエアや処理回数のような発想ができると役に立ちます。
ＮＩＣ：ＮＩＣに送受信データのキューがあると書いてありますが、ここにデータが溜まり、取り出しに時間がかかるようになるという性能劣化もありました。デバイスドライバでＣＰＵを喰うようになるので、ＳＹＳがあがります。
TCP listen（ハンドシェイク）：listenという状態で、ＳＹＮ要求を大量に送るというＤｏＳ攻撃があります。
ＴＣＰのシーケンス番号：シーケンス番号が前後して届くと、ドライバが「あれっ？」と思って、ＡＣＫを返すことがあります。そうすると通信の性能が変わったりします。順番が前後することはあります。パケットのキャプチャをとるとよくわかります。
ＴＣＰのシーケンス番号の抜け：なんらかの理由でパケットが届かないことがあります。そうすると、番号が抜けるので、再送が行なわれます。再送が行なわれると、その間、処理が進まないので性能トラブルになったりします。ネットワーク機器同士のオートネゴシエーションがうまくいかないときに、この状況になっているのを見たことがあります。
ＴＣＰのシーケンス番号のリセット：想定しない番号のシーケンスが届くと、TCP（ドライバ）はソケットをリセットします。これが実は障害状態からの回復において重要なステップとなります。インフラソフトはTCPの仕様をうまくつかっているなあと感じます。
Wireshark：ネットワークトラブルシューティングやソフトウエア解析のお友達です。いろんな通信プロトコルを分析してみるといいです。トラブルの際、Wiresharkを送信元のマシンと送信先のマシンにしかけて、ログを比較すると、送ったはずなのに届いていない、とか、こっちのマシンが応答を返していない、とか切り分けが進みます。

インフラエンジニアって、アプリエンジニアと違ってソースコードは見れないものの、こんなシューティングをする、システムコールを勉強するのがおススメ、という説明でした。