cloretsblackのテクニカルノート

言葉の意味はよくわからんがとにかくすごい自信だ

技術書典3で同人誌を販売しました。オンライン販売もあります。

先日ブログにて告知させていただいたとおり、10/22の技術書典3で「パケットキャプチャで見てみよう MySQLデッドロック編」を販売させていただきました。

今回のイベント参加でやったこと、感じたことなどを少し書き留めておきたいと思います。

f:id:cloretsblack:20171029145448j:plain

御礼

台風の中、足を運んでくださり、また本をご購入いただいた皆様、ありがとうございました。すばらしい運営をしてくださったイベント関係者の皆様、売り子をお願いした友人にも感謝致します。

技術書を書くということ

技術書を書くのは初めてだったのですが、参考書は色々読んできたので、どういうものを作ればよいかはある程度頭の中にありました。テーマが「パケットキャプチャ」なので、手元で色々できる環境が便利だと思い、クックブックとして作りこんでいくことに決めました。
実際の執筆期間は3ヶ月くらいでしょうか。勤務先の仕事もバタバタしていましたので、早めに仕上げてゆっくり修正するペース配分でした。今回は環境をそのままVMとしてダウンロードさせようかとも思ったのですが、容量の関係で現実的でなくなったため、Dockerを採用して環境を配布する事にしました。このあたりについては、かつてハンズオンセミナーを開催した際に学んだノウハウが非常に役に立ちました。
執筆ツールはGoogleDocsです。勤務先で昼休みとかにもちょっとずつ書きました。他の参加者の製作記録を読むと、表記ゆれなどを防ぐための仕組みがあったり、Gitを使ったりと、非常にカッコいい感じだったので次回は真似するかもしれないです。
今回最も苦労したのはMySQLデッドロックを意図的に発生させるWEBアプリケーションを作った所です。本の中ではほとんど一瞬で流されている箇所ですが、通常そのような目的を持った実装例があまりないこともあり、すこし試行錯誤を行った部分でもあります。

値決め

今回は一部1000円で販売しました。企業として参加していたこともあり、事前のサークルチェックなどでの数字を元に経済合理性を考慮したうえで設定させていただきました。直前のチェック数で30とかだったので、やっぱりマイナージャンルは厳しいよなぁと思いました。あと、経済的に余裕のない学生さんを対象に、「学生証を提示してくれれば半額キャンペーン」とかやっても喜ばれたかも。。?この辺は次回検討します。

配布形態

今回はダウンロード販売のみとし、A4のカラーコピーにQRコードを印刷し、100枚ほど用意しました。安いカラーコピー屋を探し、結局自宅近くのダイソーで一枚30円で刷りました。印刷屋さんに出さなかったのは滞留在庫のリスクと製本コストを許容できなかったためです。

売ってみた感想

A4カラーコピー一枚ッペラがそこそこのペースで1000円札と交換されていく様は結構気持ちがよかったです。売り子をしてくれた友人曰く、「えっ、これ売れんの?」と衝撃を受けていたみたいです。今回、友人がホワイトボードに絵を描いてくれました。技術書典3のイベントイラストに描かれている女性の顔がガイコツになっています。ひそかに黄金バットを思い出しましたw

https://techbookfest.org/assets/tbf03/images/top.png

当初見本誌を用意せず、目次だけ貼り出していた(すっかり忘れていた)のですが、実際にやってみて、見本誌の存在は重要だと思いました。特にダウンロード販売では、購入者の立場的にもあったほうが良いのは間違いないです。 ちなみに、販売ブースに見本誌がないことを知った知り合いの方が、当日コンビニで印刷してきてくださったので、後半からは見本誌をおいた状態で販売する事ができました。 前半と後半を比較すると、明らかに購入する人が増えました。セールストークもしやすいので、ノウハウとして見本誌は超重要だと分かりました。

具体的には、

  1. ブースの前で視線を送っている人に「見本誌、読んでってくださーい!」と声をかける。
  2. 本を手にとって、パラパラ見て本を戻す時に「パケットキャプチャとかお仕事で使われますか?」等と話しかける
  3. 具体的なユースケースが聞ければ、適宜参考になりそうなTipsやコメントをする

…というような感じで楽しく会話しつつ、最終的には執筆コストもまあまあ回収したので、初めてにしては上出来だったのではないかと思います。

宣伝

イベント前に勉強会でLTとかして宣伝しました。勉強会で知って来てくださった方もいらっしゃいましたので、そこそこ宣伝効果があったかもしれません。苦労の大部分を台風が吹き飛ばした気もしますが。。
宣伝といえば、イベント前に別件でTwitterがバズり、黒ブラのプロフィール画面と固定ツイートが非常に多くの方に閲覧されていたようです。しかし同人誌の告知をしていた固定ツイートのインプレッションが29700で、ふぁぼ(いいね)が衝撃の97、実に0.32%。バズる前に告知していた時点からほとんど増えていないという悲しい現実を見てしまいました。
なんか広告って難しいなぁ。(小並感)

オンライン販売について

以下のサイトでPaypal決済にてオンライン販売を行っております。 地方の方や台風で当日来られなかった方もいらっしゃるようなので、ぜひお買い求めください。

develup-japan.co.jp

決済やダウンロードに問題が発生した場合は上記サイトのコンタクトページかTwitterでご連絡ください。

NetOpsCoding#5 × ネットワークプログラマビリティ勉強会#13でLTしました。

以下に資料を公開しました。

www.slideshare.net

5分のLTだったので簡潔な内容ですが、黒ブラの職場で実際に起きたことをネタにしてみました。たぶん運用現場ではあるあるネタではないかと思います。

ぶっちゃけユーザー企業の情シスとしては、対応開始から原因究明+暫定対応まで、約1時間というタイムは悪くないと思っています。
この環境は障害対応時間をなるべく削減したいと願い、政治的にもかなり大ナタを振るった結果なので、いざ同様の環境を作ろうとすると、なかなか難しい部分もあると思います。

もしご興味があれば、コメントなどいただけると励みになります。
Twitterでもリプライやメンションいただければ反応しますのでよろしくお願いします。

同人誌出します

f:id:cloretsblack:20170930172608p:plain:w300
同人誌表紙

前回の投稿で、少し予告っぽく書いていたのですが、来る10/22(日)技術書典3 (会場:秋葉原UDX)において、パケットキャプチャの応用例とお手元で動作する環境を構築するためのクックブックを頒布します。

WEBシステムにおいて、データアクセスはアプリとインフラが入り混じる領域ではないかと思います。この領域におけるエラートラップと監視という課題に対し、データベースのコネクションをソケット経由にする事でパケットキャプチャというネットワークのデバッグ手法を応用する事ができます。
今回は例としてデータベースへのCRUDと内部エラー(デッドロック)をパケットキャプチャで解析してみました。また、エラーの検知から警告へ繋げる一連のシステムについても実装例を紹介しています。

ちなみに今回一番時間がかかったのはデッドロックを人為的に発生させるWEBアプリケーションの開発です(笑)

現時点でサークルチェック数が12と、非常に不安を掻き立てられていますが、何事も経験だと思いますので、とにかくやってみようと考えています。
配布はPDFですので、品切れはありません。
是非「い07企」ブースへお立ち寄りくださればありがたく思います。

techbookfest.org

JTF2017で発表しました

昨年に引き続き、今年もJTF2017で発表させていただきました。 当日は過去最高の参加人数だったとのことで、運営の皆様は非常に大変だったかと思いますが、おかげさまで気持ちよく発表や交流を行う事ができました。 このようなすばらしい機会を与えてくださった皆様に、心より感謝申し上げます。

今回のテーマは「情シスのひみつ」という事で、16年勤務した情報システム部門で得た様々な経験についてお話しました。
申し遅れましたが、黒ブラはこの8月に部署異動をしており、情報システム部門を離れ、ソフトウェア開発部門に配属されています。

www.slideshare.net

今回の発表は、個人的には「卒業研究」と位置づけています。 退職エントリとかではないのですが、すこし、自分の話をしてみたいと思います。

黒ブラは新卒でユーザー企業の情シス部門でインフラチームに配属され、パソコンのヘルプデスク業務からキャリアをスタートさせました。 たまたま、新システムの開発の手が足りないという事で、Oracleデータベースの夜間バッチ開発を手伝う事になり、割と早いうちからデータベースを覚えました。 その後、本格的にサーバ、ネットワークの管理を担当し、LinuxやDBA業務を覚えていく事になります。

ちなみに、経験ゼロで入ったヘルプデスク時代に、部署にあった、当時誰も触っていなかったSniffer Basic(商用のパケットキャプチャツール)を見よう見まねで弄り倒していた経験が入社4年目辺りから徐々に形になりだし、サーバ、DBなどの構築や操作は素人の癖に、何故かトラブルシューティングの精度だけ高いという不思議な覚え方をしました。

今にして思えば、分からない事に対し、分からないなりに取り組む時の姿勢として、

  • エビデンスを探し、Factを積み上げる
  • 正常と異常をI/Oレベルで見比べ、切り分ける

を習慣化していたことが、壁に突き当たってくじけたりする事もなく、長期間学習を継続できたポイントだったのかもしれません。

このスキルはその後、WEBプログラミング等、新しい技術を学ぶ際に幾度となく黒ブラを助けてくれ、 今ではデータベースのデバッグや監視すらもパケットキャプチャを応用する事ができるようになりました。

この辺りの事は以前ハンズオンセミナーをやったときに興味をもたれていた方がいらっしゃったので、少しノウハウとして書き残しておきたいと考えています。 今後何らかの形で皆様のお目に触れる事があるかも知れません。 そのときにはどうかよろしくお願いします。

IoTシステムのトポロジの話

ネットワークのトラブルシューティングのためのIoTを作っています。
先日発表した勉強会資料で、参加者から質問が出ていました。

www.slideshare.net

時間の関係でうまく説明できていなかったかもしれないと思いましたので、ブログ記事にします。

前置きとして、IoTシステムという文脈で語られる典型的な例として、デバイスによるセンシングとそれを集積するクラウドという構成があります。
このような構成はネットワークをはじめとするインフラの運用監視システムとしてはおなじみのもので、監視対象機器を設定し、トラフィック量、サーバのCPU使用率、DISK負荷、サービス応答時間、各種ログ等々を収集します。
勉強会ではインフラの運用管理システムがIoTシステムに、非常によく似ており、IoTデバイス=ネットワーク機器という図式が成り立ち、機器から集めたデータを可視化する運用管理システムは、すなわちIoTシステムではないかという所から話がスタートします。

頂いたご質問は、
「一般的なIoTシステムとして、デバイスで採取したデータをクラウドなどのサーバに集積して見せる形態が多く取られているが、今回の発表は同様のものではないのか?」
という趣旨のものでした。

両者の比較

一般的なトポロジ
f:id:cloretsblack:20170304095434p:plain

今回発表したトポロジ
f:id:cloretsblack:20170304095458p:plain

ご指摘の通り、IoTシステムの構成としては少し変わった形ではないかと思います。
トポロジが特徴的な理由としては色々あるのですが、黒ブラは普段システムを使う側の人間なので、ユーザー(黒ブラ)が本質的に何を望んでおり、どの様なシステムがマッチするのか、という問いに対する一つの結論だと思っています。
要点は以下の通りです。

・本来の目的
・やりたいこと
・データの解像度の問題
・最適なトポロジ

本来の目的

ネットワークやサーバの運用監視に用いられるシステムはOSS含め大量に存在し、日々しのぎを削っています。

これらの製品の目的は「継続的にサービスを提供すること」です。

安定してサービスを提供するためには
1.システムトラブルをいち早く発見すること
サービスの停止前に問題を発見できたらラッキーです。ユーザーが気づく前に修正できれば問題は起きていないのと同じです。

2.素早く復旧すること
不運にもサービスが停止してしまったら、素早く復旧することでビジネス損失を最小化できます。極端な話、利用ユーザーの少ない深夜に5分だけの停止で済めば、ビジネス上の問題は少ないケースがあり得るでしょう。

3.再発防止に取り組むこと
再発防止に取り組むことで問題そのものの発生頻度を減らすことができます。

サービスやプロダクトの安定性というものは、こうした問題解決のプロセスを数多く回し、それぞれの問題にきちんと対策が取られることにより向上するものです。
f:id:cloretsblack:20170304153043p:plain
集英社ジャンプコミックス 車田正美聖闘士星矢より引用

やりたいこと

これらの製品を使う上でユーザーが知りたい情報は下記の二つに集約されます。

・監視対象機器に問題が起きていないか
・問題が起きていたらその原因は何か

監視チームとデバッグ担当者が分かれている場合には、監視チームが担当者に通知して終わり、というケースがあり得ますが問題の解決には不十分です。

最低でも問題解決の糸口になる、欲を言えば問題個所の切り分けと、再現条件が得られるレベルの情報を集めることが理想です。

データの解像度の問題

どのような情報を集めるべきかというのはアプリケーションの作りによっても違いますが、従来の運用監視システムにおいてサーバのログや稼働情報を集めたとしても、問題の解決につながらないケースがわりと存在します。
これはデータの解像度の問題です。

実例を挙げて考えてみましょう。
f:id:cloretsblack:20170304100856p:plain

「A」という業務WEBシステムでは、データの参照、登録、削除機能に加え、クライアントPCからのファイルアップロード機能を備えています。アップロードされたExcelファイルの内容を読み込み、データベースに反映し、後続処理を行います。

あるとき、Aシステムで夜間バッチのメールが飛んでいないという問題がありました。
調べてみると、アプリケーションサーバがハングアップしていました。
サーバ再起動によって問題は解消し、リカバリー処理も完了しましたが、原因が分かりません。
ログを調べると夜間バッチ処理が起動していないことが分かったので、おそらく夜間処理前にアプリケーションサーバに何らかの障害があったのだと推測されました。

たいていのシステム障害はログに残っていなければ何もわかりません。この例ではアプリケーションサーバに問題があることは明白なので、まだだいぶマシですが、サポートに問い合わせても対策できない可能性はかなり高いでしょう。

次の手としては、
・ログの詳細度をデバッグレベルまで高め、一時的な負荷と引き換えに、問題の再現条件を探す
・とりあえずベンダーから出ているパッチを全部当ててみる(スクラッチ開発の場合は難しい)
ということになり、完全に出たとこ勝負のトライアンドエラーになります。

この例では、あるユーザーが深夜にアップロードしたファイルのデータバグが原因でした。
ログの詳細度を上げていれば発見可能だったかもしれませんが、厳密にはプログラムは異なる分岐を通りますし、負荷の状態も異なりますので、解決までのリードタイムは確実に伸びていたと予想されます。

結果として、この障害はSonarmanで解決しました。
・パケットキャプチャでログに残った時刻より、問題の通信とユーザーを特定
・発生時のサーバレスポンスから、処理負荷によるタイムアウトである可能性を排除
・その場でユーザーに電話して、問題のファイルを取得し、検証用としてベンダーに引き渡し
・証跡としてパケットキャプチャを添えた上で、開発環境での検証と修正を依頼
復旧作業完了後に原因究明を始めて、一時間以内に対応できました。
あまりにもサクサク進んだためか、この一連のやり取りでベンダーの担当者がちょっと引いていましたが…。

Sonarmanは、サーバに一切の変更を加えることなく、最大の解像度で障害に関する情報を取得するというコンセプトで開発されました。 解像度の低いデータをクラウドに集積してざっくりと全体を把握するのではなく、一撃で解決につながる濃い情報を現地に持つというイメージです。
ちなみに高解像度情報をクラウドに持つのは容量の問題で現実的ではないです。(そういった間を取るソリューションがNetflowコレクタです)

最適なトポロジ

それでは、ネットワーク機器をIoTとしてとらえた時に、トラブルシューティングを目的としたIoTでは、どのようなトポロジが最適なのでしょうか。
誤解してほしくないのは、従来のSNMPをはじめとする運用監視ツールは依然として必要だということです。
私自身も運用監視ツールは使っていますし、どちらが優れているというというよりは、ケースによりどのような情報が見たいかというユーザー要求の問題だと思っています。
様々なレイヤの異なる解像度の情報を組み合わせて分散して持っておいて、困ったときはちゃんと調べられる状態にしておくのが良い、というのが私の結論です。

f:id:cloretsblack:20170304154203p:plain

この記事を読んで下さった方のご参考になればうれしく思います。
最後に、手前味噌で大変恐縮ですが、IoT パケットレコーダー「Sonarman-R」Amazonにて発売中です!
この手のパケットキャプチャ装置としては業界に激震が走るレベルのコストパフォーマンスです。

Sonarman-R

Sonarman-R

Npstudy#11で発表しました。

発表内容

以下資料です。

www.slideshare.net

要約すると、パケットキャプチャを集積しておくことで、ビッグデータのように扱えるので、保守運用に必要な各種データが任意のタイミングで同じ手順で取り出せるようになりますよというお話です。

同じ手順とは言いましたが、簡単とは言ってません。
ある程度ネットワークの知識がないと難しいのではないかと思いますが、手法としてはそれなりに使えます。

本番稼働中のサーバに置いてあるデータ収集用のスクリプトを変更するなどの作業は現場の人間にとって非常にやりにくい作業の一つです。
その点、Sonarmanは一旦設置してしまえば、稼働中のサーバやネットワークに一切の変更を与えることなくデータを取得できるので、安心感があります。

情シスというポジション

情シスというポジションについても触れました。ITのエキスパートであるベンダと、業務のエキスパートであるユーザーの間に挟まれ、ある意味最も理解されづらいポジションではないかと思う時があります。

情シスにおけるインフラ担当者としての価値、すなわち自社での利用状況や課題を把握し、ユーザー価値を最大化するための施策を立案、実行する事ですが、そういった活動の元となる各種数値を効率よく正確に把握するためにはどうすれば良いかという問いに対する、私なりのアイデアと実行結果についてお話しました。

重要な事は2つ。
・何かを検討する際に正確な数字を持っている
・問題発生のときにエビデンスを持っている
これらの条件を満たす事は、話し合いの主導権を握るという事です。
このアドバンテージは非常に大きく、対人交渉や重要な判断の際に必ず役に立ちます。
事実、私自身過去に何度も助けられました。
私の経験が皆様のお役に立てばうれしく思います。

ご興味があれば、お気軽にTwitterでお声掛けください。

ジョジョの奇妙なケーススタディ【ネットワーク遅延】

きっかけ

ネットワーク遅延について書かれた資料を拝見し、インスパイアされてしまいました。
本記事とは異なり、大変真面目な内容です。

はじめに

一言にネットワーク遅延と言っても多くのケースが想定されます。 ネットワークを構成する様々な要素、例えば、サーバやクライアントPC、アプリケーションなどに原因が潜んでいる可能性があり、比較的難易度の高い障害ではないかと思います。
ただし、私の経験上、遅延の原因は解決してみればごく当たり前の現象であることがほとんどなので、ケーススタディを充実させるよりもネットワークの原理原則を理解したエンジニアに都度対応させるほうが理にかなっている一面もあり、遅延問題について具体的な事例と解説があまりインターネット上に存在しないように思います。

そのため、初心者がどれだけ検索しても問題事例に行き当たらないという現象が発生しており、ユーザー企業の情報システム部門などではユーザーとサポートベンダの板挟みにあい、苦しんでいる人々がいます。かくいう私もその一人でした。かつての私のような人々に少しでもご参考となればと思い、この記事を書きました。

f:id:cloretsblack:20170103113521p:plain
大体こんなテンションで進んでいきます
集英社ジャンプコミックス 荒木飛呂彦ジョジョの奇妙な冒険 より引用

注意
本記事ではネットワークのスループットが断続的に低下する事象を「遅延」と定義します。 具体的には理論値よりも明らかに速度が出ていない、以前よりも遅くなったなどの問題を扱います。
また、基本的にLANを中心に解説します。
パケットキャプチャを表示するソフトウェアにはWiresharkを使用しました。

私が今まで現場で見たことのあるネットワーク遅延とその検出方法、解決手法を具体的に書いてみたいと思います。

  • すべての「遅延」問題の調査に共通する基本
  • ネゴシエーション不一致
  • ケーブル不良
  • アプリケーションの問題
  • ネットワーク容量
  • サーバレスポンス遅延
  • ポート/セッション数枯渇
  • ジャンボフレームとフラグメント

すべての「遅延」問題の調査に共通する基本

もし、あなたの手元で問題が再現するなら、まずパケットキャプチャを取得するところから始めてください。

なぜパケットキャプチャを取らなければならないのですか?

ネットワークでは様々な機器が連携して動いています。サーバ、クライアントPC、スイッチ、ルータ、それらを繋ぐケーブルなどです。
これら全てをしらみつぶしにチェックすることは手間がかかり、さらに必要な情報が必ずしも取得できるとは限りません。
一方、パケットキャプチャには解析に有用な情報が非常に多く含まれており、またパケットキャプチャにしか現れない情報も存在するからです。

パケットキャプチャは非常に読みづらいのですが、読まなければなりませんか?

パケットキャプチャの解析はネットワークのデバッグ行為に相当します。ソフトウェアと同様に、動作を理解し、原因を突き止めなければ問題を正しく修正することはできません。
しかし、必ずしも解析のスキルを身に着ける必要はありません。パケットキャプチャは問題の状況を伝える最も有効な手段の一つです。
つまり、原因究明のアウトソースが容易になるという利点もありますので積極的に活用していきましょう。

f:id:cloretsblack:20170103093234p:plain
思わず納得
集英社ジャンプコミックス 荒木飛呂彦ジョジョの奇妙な冒険 より引用

それでは具体的にネットワーク遅延のケーススタディをみていきましょう

ネゴシエーション不一致

ケーブルの両端にあるネットワークインタフェースでネゴシエーションの不一致が発生するとパケットのドロップが発生しスループットが著しく低下します。
パケットのドロップが発生するとTCPの再送が起きるので、パケットキャプチャの再送の数をカウントするのはネットワークの品質をチェックするのによい方法です。ただし、無線の場合は様々な条件で再送が発生するので、この方法は有線限定です。
Wiresharkで再送を検出するフィルタには以下のものを使います。
tcp.analysis.flags
f:id:cloretsblack:20170102175107p:plain
ちなみにもし様々な事情でWiresharkを使うことができない場合は、端末上で
netstat -s
コマンドにより再送数を簡易的に把握することができます。

再送が多い場合、まず疑うべきはネゴシエーションの不一致です。 GigabitEthernetの普及にともない、古い100Mのスイッチを使用している場合、ネゴシエーション不一致が起こりやすいです。現在では端末のインタフェースもほぼ全てGigabitEthernetになっているのでネットワーク上の100Mのスイッチには要注意です。
ネゴシエーションの状態を知るには接続しているスイッチのランプを確認するか、インテリジェントL2スイッチやルータなどで、インタフェース情報を見てください。

f:id:cloretsblack:20170102180719p:plain

Half-duplexなどになっていた場合はネゴシエーションに失敗している可能性が高いです。 このあたりの不一致にはインタフェース同士の相性も出ます。あまり深追いせずに古いスイッチは交換しましょう。

なお、ネゴシエーション不一致の場合、後述するケーブル不良と同様に runts, giants, CRCなどのカウンタが記録されていることがあります。 これらの項目は深刻なエラーです。必ずゼロにしなければなりません。

GigabitEthernetでは基本的に自動(オートネゴシエーション)で対抗のlinkを識別します。その際、対抗の設定が自動でない場合は半二重でリンクしてしまいます。
一般的にネットワークの管理ではLAN内の機器のスペックやlink状態を把握しておくことは非常に重要です。

f:id:cloretsblack:20170103115046p:plain
オートネゴはオートネゴでしか倒せない。それがイーサネットのルールッ!
集英社ジャンプコミックス 荒木飛呂彦ジョジョの奇妙な冒険 Part7 スティール・ボール・ランより引用

余談ですが、回線業者に依頼してルータのLAN側のインタフェースを10M固定に設定させた同僚がいました。理由を聞くとWANの帯域が10M以下だったので、10Mがふさわしいと思ったそうです。
その結果、周囲の機器が10Mというレガシー規格にうまく対応できず、パケットドロップが頻発するという事態が発生しました。 当該ルータは業者しか触れない契約だったため、最終的に全部のリンク設定をオートネゴシエーションに戻すのに結構なお金と時間がかかったというオチでしたが、 緊急の回避方法として、10Mのスタティックモードを設定できる、懐かしのNetscreen-5GTを5000円で仕入れ、ルータとスイッチの間に設置するという荒技を使ったことがあります。
というか、業者さんも止めてほしいです。そういうときは。

まとめ
  • 有線ネットワークの品質は再送数でチェック
  • リンクの状態を確認し、ネゴシエーションの設定をチェック
  • 解決策:すべてのスイッチをGigabitEthernetのオートネゴシエーションに統一する
  • 打ち合わせ中に業者さんが変な顔をしたら、自分が間違っているかもしれないので聞いてみる

ケーブル不良

メーカー製のケーブルを使用する限り、日本ではほとんど起きないのですが、海外や自作のケーブルを使用していたり、UTPのカテゴリが合っていないなどの場合でまれに発生します。
このケースも前項と同様に再送数のチェック、確実には機器のインタフェース統計で判別します。
大前提として、ローカルエリア内の有線ネットワークにおけるTCP再送はゼロにできます。
少量の再送はスループットに大きな影響を与えないのですが、がんばってゼロにしておくと、異常時に気が付きやすくなるのでおススメです。

f:id:cloretsblack:20170103082337p:plain
伝われ、このスッキリ感
集英社ジャンプコミックス 荒木飛呂彦ジョジョの奇妙な冒険 より引用

ケーブル不良のうち、銅線の「より」が少ないことが原因でノイズが乗りやすい状態になっている場合があります。不定期に通信品質が悪化する現象が発生しますので、インタフェース統計の runts, giants, CRCのカウンタは最低でも敷設時、理想的には定期的にチェックするとよいでしょう。
f:id:cloretsblack:20170102180907p:plain

ちなみにCRCエラーが出ると、スイッチによってはCRCチェックの負荷によりpingのRTTに数ミリ秒の遅延が出る場合があります。同一拠点内でのpingに遅延がみられる場合には上記のカウンタを確認すべきです。

まとめ
  • ケーブル不良はインタフェース統計でチェック
  • runts, giants, CRCのカウンタがゼロでない場合は要注意
  • 解決策:ケーブル交換

アプリケーションの問題

アプリケーションの使い方によって、以下の例のように非効率的な通信が発生してしまうケースがあります。

  1. ネットワーク上の共有フォルダにインストーラーを置いて、端末から直接実行する

  2. 巨大なパワーポイントを共有フォルダに置いて直接開く

1.のケースではファイルの読み込みだけでなく圧縮ファイルの展開、解凍などで共有フォルダに大量の読み書きが発生しがちです。 インストール作業を自動化するためにパスを固定したい場合もありますが、一旦ローカルへファイルをコピーしてから実行するよう変更するべきです。

2.のケースではMS Officeがカレントディレクトリにキャッシュを作るという動作を行うために、非効率な読み書きが発生する場合があります。 参照用途で、かつ容量の大きい場合にはWEBなどから配布するなどの工夫をすると幸せになれるかもしれません。

ネットワークにおけるアプリケーションの挙動を詳細に解析するのは比較的難しいので、ネットワークの存在を意識した上でアプリケーションの使い方をトライアンドエラーするのがいいかもしれません。その際パケットキャプチャはトラフィックを定量化したり、レスポンスを正確に計測する用途にも使えますので、積極的に活用してみてください。

まとめ
  • ネットワーク特性を意識したアプリケーションの使い方をすることが大切
  • トライアンドエラーの効果測定にパケットキャプチャを使うと便利

ネットワーク容量

単純にネットワークに大きなデータが流れているために他の通信が送れないという現象です。
解決策としてはスイッチやルータの流量を収集してトラフィックを可視化するのが良いと思います。
具体的にはSNMPを使って流量のカウンタを収集するZabbixやCactiMRTG、またはSNMPよりも多くの情報が得られるCiscoのNetFlowコレクタなどの可視化ツールの導入を検討してください。
手前味噌で大変恐縮ですが弊社のSonarmanもおススメです。

私の個人的な観測ですが、ユーザー企業の現場では意外なほどトラフィック可視化が行われていません。
トラブルシューティングにおいては、障害が起きた時のために普段から準備をしておくことがとても大切です。

問題の具体例として、WindowsUpdateやiPhoneの更新が集中するケースの他に、WSUS等の分散配布システムを使用する場合に、多人数の出張などで予期しないトラフィックパターンが生じるケース、クラウド等への大容量バックアップ、P2Pアプリケーションによる巨大ファイルのダウンロードなどが挙げられます。

まとめ
  • トラフィックの可視化を検討する
  • 人為的ミスが多い
  • 発生状況をヒアリングし個別に検討が必要

サーバレスポンス遅延

サーバそのものの反応が遅い場合があります。WiresharkではSMB2やDNSLDAPなどのレスポンスタイムを可視化する機能がありますので、そういった機能を使ってもよいですし、WEBサーバであればブラウザの開発ツールがダウンロードに要した時間や処理のレスポンスを可視化してくれます。
注意点として、ファイル共有等でDISKのI/Oタイムアウトがエラーとして返される場合があります。パケットキャプチャでしか見つけられませんが、もし見つけたら絶対に無視してはいけません。DISKが壊れかけています。

まとめ
  • ブラウザの開発ツールやパケットキャプチャで遅延を計測できる
  • 解決策:サーバ増強

ポート/セッション数枯渇

ルータやプロキシサーバを長期間入れ替えていない、利用者が急激に増えたなどの場合にはセッション数やポートの枯渇を疑ってみるとよいかもしれません。
まずnetstatで機器のコネクション数を確認してください。
さらにパケットキャプチャで不自然な待ち時間やコネクションの切断が発生していないか、ルータのログにNATのセッションテーブルの枯渇が記録されていないか等もチェックポイントです。

最近のブラウザでは表示速度の向上を目的とした分散ダウンロードが一般的になっています。CSSや画像、スクリプトなどは異なるTCPコネクションを利用して並列にダウンロードすることで速度を出しており、それらは一つずつ異なるコネクションを使ってルータやファイアーウォールを通過します。
また、ブラウザの動きに合わせて、サイズの小さな部品をたくさん配置するデザインのWEBサイトも増えています。トップページの表示だけで数百のコネクションを使用するWEBサイトも存在しますので、注意が必要です。
ダウンロードが完了したコネクションは破棄され、ソケットは再利用されますが再利用の際に発生する負荷や、純粋なNATセッション数が上限に達してしまうことが原因で、待ち時間が生じてしまうことがあります。ネットワーク上でコネクションが集中する箇所は常時監視や定期的に点検してみることが大切です。
大量のセッションを消費するアプリケーションの具体例として、Bittorrent等のP2Pアプリケーションのフラッディングや、Bitcoinのマイニングツールなど、特殊なものも存在します。

f:id:cloretsblack:20170103095748p:plain
間違いない
集英社ジャンプコミックス 荒木飛呂彦ジョジョの奇妙な冒険 より引用

まとめ
  • ルータやプロキシサーバなどトラフィックが集中する箇所はコネクション数を監視する
  • 解決策:機器のアップグレードや分散配置

ジャンボフレームとフラグメント

通常のイーサネットフレームは1500バイト程度ですが、ジャンボフレームの普及により、LAN内で高速にデータ通信ができる環境が整いつつあります。しかしVPN等でWANに流れる通信の場合、パケットの分割すなわちフラグメントが問題になるケースがあります。問題の把握にはパケットキャプチャを取得する必要があります。
ジャンボフレームの分割に際し再送が発生していないか、PathMTUで発生するICMPのDestination Host Unreachable メッセージが端末まできちんと返っているかなどがチェックポイントです。

パケットキャプチャではTCPのシーケンスナンバーを条件にフィルタすることで再送が発生する元のパケット(到達しなかったパケット)がどのような状態であったかがわかります。元のパケットがジャンボフレームだった場合には設定を変更してパケットのサイズを小さくしてみると状況が変化する可能性があります。
f:id:cloretsblack:20170102175120p:plain
(5446バイトのジャンボフレームが分割して再送されている)

f:id:cloretsblack:20170103111351p:plain
ちょっと違いますが

集英社ジャンプコミックス 荒木飛呂彦ジョジョの奇妙な冒険 より引用

まとめ
  • パケットキャプチャで再送やICMP、フレームの長さをチェックする
  • 解決策:ジャンボフレームの設定解除

最後に

非常にダラダラと読みにくい記事だったと思います。お疲れ様でした。

黒ブラとしてはコラを貼りたかっただけなので、説明はだいぶ端折っています。もしご質問などがあればTwitterでリプください。