LIGのくま (@makaibito) です。
私はもともとITネットワークインフラの研究をしていたのが縁で、情報システム部門を2回作ったりしていました。情シスというのは昔は「社内で一番PCに詳しい人」が何となく就任していたのですが、今ではSaaSやらクラウドやら資産管理やらスマホやらと守備範囲が年々広がって大変な職種ですね。
そんな大変な業務範囲のなかでも社内のネットワーク(LAN)が安定して使えるかどうかというのは業務の中心になりがちです。デスクトップPCだけを見ていればよかった時代からノートPC、スマートフォン、タブレットと社内に移動を伴うデバイスが増えています。さまざまなソフトやSaaSが使われることからややこしさに拍車が掛かっています。
社内インフラって調子が良いと別に何も言ってもらえないのですが、調子が悪いと文句を言われがちですよね。私も何度も遭遇してきました。さて、弊社でもご多分に漏れず情報システム室室長の手塚さんが何やら困っているようです。
・
・
・
ある情報システム部の苦悩
VPNがね……今日も遅いって言われちゃって……。
リモートワークが中心の弊社ではオフィス環境では物理的にもネットワーク的にもスカスカなので問題になりにくいのですが、逆にルータ（VPNサーバ）の負荷が高いようです。たとえばファイル転送をしようとしてもオフィスでは数百Mbps出るのに対し、テレワークだと10Mbpsくらいしか出ない。それが今回のお悩みです。
もともとフィリピン開発拠点のメンバーも使っていたVPNサーバですし、そこに東京の社員も急に決まったリモートワークで乗っかることに……。
最終的には「VPNサーバかインターネット回線かどっちか変えてよ」って言われました。
出た。情シスの苦悩。
調子の良いときにはとくに何も言われないけど、調子が悪いとご意見が殺到するやつ。
社内からは普通に使えるんで、VPNサーバとして使っているルータを入れ替えようかなと思ってるんです。でも安いものでもないので稟議書を頑張って書かないと。
Sonarmanがやってきた！
そんな折、一件の記事広告のご依頼が。なんでも社内ネットワークに設置してパケット（データ通信においてネットワークでやり取りされるデータの最小単位）を収集し、問題があった場合にはコンサルタントが分析、改善提案してくれるというお話です。
LIGにそんな低レイヤ（コンピューターシステムの仕組みそのものに近い領域）のサービスについて、記事広告のご依頼があるんですね（……あれ？ いつの間にか記事も担当することになってる？）。
手塚さん、せっかくなので調子の悪いVPNサーバまわりに仕掛けて記事にしましょうよ。何か問題あったほうが記事にしやすいですし。
そうですね。問題が分かれば稟議書も書きやすいですし……。
そして株式会社デベルアップルジャパン代表の園山さんにお越しいただき、商品と設置方法についてご説明いただきました。
| 人物紹介：園山 淳也株式会社デベルアップジャパン代表。新卒で入社した商社の情報システム部門をへて、2014年を同社を設立。商社時代の経験を活かし、IoTパケットレコーダー「Sonarman」の開発、販売を手がける。 |
Sonarman、何するものぞ
第一印象としては、よくパケットキャプチャ（主にネットワークの障害を調査するためのパケット収集）を業者さんに依頼すると、設置するためのノートPCが出てくるのでそういうのかなと思いました。あれ、地味に邪魔なんですよね。設置のための掃除が一番面倒です。
しかし園山さんが取り出したのは小さな筐体。これならネットワーク機器の隙間にも入りますね。
今回はVPNが対象ということでVPNサーバを兼務するルータに接続しました。ルータとコアスイッチ（LAN内で中心となるネットワーク機器）の間に、Sonarmanと一緒に持ち込まれたミラーリング（流れている通信を別の接続口にコピーする）機能のあるスイッチングハブを接続します。
写真では黒い線がルーター（VPNサーバ兼務）、白い線が社内LANのコアスイッチ、青色がミラーリングされたパケットが流れるSonarmanに繋がります。接続はこれで終わりです。特に今回のケースで顕著ですが、社内ネットワークの設定変更が不要なのは情シスとしては嬉しいところです。一度インターネット接続できてしまえば、あとはお任せです。楽。
くま：Sonarmanをルータとコアスイッチに直接接続することはしないんですか？ その方が機材も少なくなりますよね。
園山さん：Sonarmanが故障した際に社内LAN全体が不通になるのは避けたかったんです。故障の可能性が低いこの接続方法を推奨しています。
くま：なるほど。そのスイッチングハブの信頼性はどうなんですか？ あまり良い思い出がないのですが……。
園山さん：（笑）。これはファームアップ（機器内のソフトウェア更新）をすれば問題なく動作しますよ。多くの現場で実績があるので心配しなくて良いです。
くま：……あ、ファームアップできるんですね。すいません、偏見でした……。
パケットキャプチャと聞いてあの質問をしてみた
くま：パケットキャプチャというと通信を覗き見る形なので、セキュリティ面で抵抗のある企業さんはありませんか？ 盗聴だ！ とか。
園山さん：そのような声はよくいただきます。それに対しては車におけるドライブレコーダーや、オフィスビルや街中の監視カメラのようなものだとお答えしています。それもとらえ方によっては「盗撮」に近くなるケースがあります。
くま：業種によっては執務室に監視カメラがあったり、持ち物検査をするくらいですしね。ドライブレコーダーというのはどういうイメージでしょうか？
園山さん：ドライブレコーダーの普及により、自動車事故の説明がしやすくなりましたよね。事故の原因究明に必要な時間が短縮されました。情シスも障害があった際にはトラブルシューティング、ベンダー交渉、経営層や社内への説明、予算取りといったような事故対応があるわけですが、それを少しでも時間短縮するために根拠となる情報を集めましょうというお話です。
くま：状況証拠で判断を迫られる機会は多いですし、予算確保の根拠が最後は「Trust me」とかになっちゃうので助かります。ただ、すべての情報を取るとなると、抵抗があるお客さんも居ますよね？
園山さん：すべての情報を取るかどうかは選択できます。問題が起きているところの情報だけを選択すれば回避できる場面もあるでしょう。たとえば今回の場合はLAN内の通信は取らないようにしています。
くま：なるほど。ネットワークにおけるドライブレコーダーなんですね。
園山さん：一点だけドライブレコーダーと違うところがあります。映像は誰が見ても理解できますが、Sonarmanは取得対象がパケットなので読み取るのに一定の修行が必要です。
くま：私もWireshark（パケットを収集するアプリケーション）はよく使っていましたが、そのまま取得すると情報が多すぎて鬱陶しいので自分の作ったアプリとPCで絞って見ていました。ちょっと目を離した瞬間に数GB溜まりますしね。もしかしてずっとあの大量のパケットをご自身で見続けているんですか？
園山さん：はい。修行です。そのときどきに導入される機材やアプリケーションのバージョンによってパケットのトレンドも変わっていくので、デバイスやアプリケーションが新旧混在していることも想定しながら紐解いていきますね。どこに着目すべきか、またどこは見なくて良いか、そのあたりをプロトコルの設計思想や実際の環境で見た経験をもとに判断する、高度な謎解きゲームのような感じです。
・
・
・
期せずして老師みたいな人が来られた気がする。そんな思いを胸に、LIG社を舞台にお手並み拝見といきましょう。
Sonarmanを仕掛けてみる
平日の午前。手塚さんが設置。その後疎通を確認して、園山さんがインターネット経由で設定を入れます。導入時にトラブルもなく、様子見の1週間が始まりました。
今回は帯域を計測する目的で、「オフィスから」と「VPNサーバ越しの手塚さんの自宅から」の2パターンで比較します。それぞれ、100MBのファイルをFTPでダウンロードしてみました。
この手の障害対応で困るのが、メーカーの人が入れ代わり立ち代わりやってきて、数ヶ月経過したうえで「何も分かりませんでした」とだけ言われるものです。私自身、2年に1回は何かしらのそういう経験をしていました。半年かけて「何も分かりませんでした」とかもありました。
そしてこれは記事。どうするかなぁ。何も起きなかったら困るなぁ。軽くVPNに繋いだ状態でping -fとかして自演しておくかなぁ……とか言っているうちに自演するのも忘れて検証期間が終わりました。
ヤバい。何も分からなかったらどうしよう。
そんなことを思いながら検証結果報告を待つこと3日。園山さんから「分析結果が出ました」と連絡があり、オンラインで報告会を開きました。
LIGのVPN環境はどうだった？？
園山さん：結論から言うとネットワーク機器もネットワークも問題ありません。
くま：何も問題なかったんですか？ （ヤバい。よくTwitterで見る進撃の巨人の一コマじゃないか。なんの成果も……とかいうやつ。）
園山さん：ただ、サーバとルータの間、それと手塚さんのネットワークが悪いですね。
手塚、くま：……？
園山さん：サーバとVPNサーバ（ルータ）の間はジャンボフレーム（一度の通信で送受信するデータの上限サイズを拡大し、効率的な通信を行う手法）で通信が行われていました。パケットの長さが平均5,015 byteで動作していました。
一方、手塚さんはmacOS標準のL2TPでVPN接続されているのでパケットサイズに上限が制限されており、VPNサーバと手塚さんの間は1,350 byteになっていました。そのこと自体は通信のパフォーマンスに与える影響は小さいのですが、途中の経路でパケットが失われたときの再送要求には不利に働くのではないかと思います。
くま：つまりサーバとルータの間は1パケットあたり5,015 byteのサイズで送られるものの、ルータと手塚さんの間は1,350 byteしか送られず、約4分割されていたためパフォーマンスが悪化していたということですね。
園山さん：正確に言うと、通信状態が悪くなった場合に通常よりも悪影響が出やすい状態だったということです。加えて手塚さんのご自宅のネットワーク。これは無線LANではないですか？
手塚、くま：……？
園山さん：traceroute（ネットワークの途中経路の状況を探るアプリケーション）の結果を見たところ、手塚さんのPCとご自宅のルータの間で、すでに20 msec（ミリ秒）ほどの伝送遅延時間（パケット通信時に消費される時間）がありました。20 msecというと東京-福岡間の伝送遅延時間に相当します。
手塚：そんなに……。ルーターの交換は必要でしょうか？
園山さん：ルータ自身に負荷はありませんので、交換の必要はないでしょう。ただルータの設定について見直しをオススメします。
ご自宅内の伝送遅延時間の件もありますが、サーバ〜VPNサーバ〜手塚さんの自宅のPCの伝送遅延時間が合計60 msecほどになってしまいました。これは問題です。私の経験上、60 msecというと東京-上海間の伝送遅延時間に相当します。
つまり無線LANが足をひっぱった結果、ネットワーク伝送遅延時間としては東京-上海間に匹敵するハンディを背負って通信していたということです。
くま：なるほど。会社のインターネット回線についても異常はなかったということでよいのでしょうか？
園山さん：流れているTCPから抽出した再送率から全体のパケットロス（通信の途中でパケットが失われること）は0.2%と推定されます。通常は数%出たりすることもありますが、非常に良いですね。
くま：ルータやネットワーク回線は、当面問題なさそうですかね？
園山さん：MSS（TCPにおける1セグメントで送受信可能なデータサイズ）、伝送遅延時間、パケットロスといったデータを計算していくと、手塚さんがテストした際のスループット14.95Mbpsと近しい値が算出されます。つまり故障とは言えません。
くま：なるほど。手塚さんはどうすると救われるのでしょうか？
園山さん：VDIなどで中継ポイントを設定して、実際のデータ伝送はそこから行うことで回避が可能です。工夫すればコストも抑えられると思います。
お手軽かつ、コストに配慮し即効性を求めるならば自宅を無線LAＮから有線LANにするのも有効でしょう。レイテンシをうまく削減することができれば、環境を変えずに速度を上げられるはずです。ほかにはVPNサーバを担当しているルータの設定を見直すといったところですね。
Sonarmanは「当てずっぽう」を無くす
くま：なるほど、ありがとうございます。たしかな定量結果に基づいた分析だと、説得力がありますね。
園山さん：情シスをしているとよくあることなのですが、複雑化した環境では知らず知らずのうちに勘に頼るようなケースが出てきます。もちろんログが確認できればするのですが、すべての機材で十分な精度のログが取れるわけではありません。
復旧を優先するために再起動を試した結果、障害発生時のログが残っていないこともありえます。結果的に推測で判断し、オペレーションするしかない状況は多々あります。
手塚：たしかに。憶測で判断してしてしまう方も少なくないと思います。
くま：これまでの経験、機材選定時の妥協した記憶、メーカーに対する思い出、関係者の性格などから「ここが怪しいのでは？」と偏見に近い推測が始まったりしますね。
園山さん：そうなんです。その推測はいつしか「ここが悪いに違いない」という思い込みを生むことがあります。勘が何度か当たった経験があればあるほど、この思い込みは強くなります。
くま：それは本当にまずいですよね。原因はまったく違うのにコストをかけて、製品導入・入れ替えをしたのにも関わらず、なにも改善されなかったみたいな悲しい事象も少なくなさそうです。
園山さん：少なくないですね。Sonarmanはログ収集とコンサルティングによって事象の裏付けをして情シスの力になってくれるサービスなんです。データを積み上げて分析をしてお話をすることで「コンピュータの話なので当てずっぽうで話すのは止めませんか？」とご提案しています。問題の発生メカニズムが分かって観測できていれば、修正したあとにそれが本当に直っているかもわかるんですよ。ITが専門でないユーザーさんは、基本フィードバックはくれないですからね（笑）
くま：さて、園山さんにはこういただきましたが、何から始めますか？
手塚：……とりあえず自宅を有線にします。
そう話していた手塚さんですが、今回の結果を元にルータの設定も見直したそうです。
QoS（通信の優先制御）の設定を改めたことで、途中経路で21 msecかかっていた伝送遅延時間が6 msecまで短縮することができました。今回の取材のおかげです！
こうしてLIG社は、徒労に終わったであろう対外ネットワークやVPNサーバのリプレイスを免れ、より適切な対応を無駄なコストを払わずに実施することができました。
Sonarmanはこうして作られた
最後になりますが、Sonarmanを作ったきっかけというのはどういったところなのでしょう。園山さんに聞いてみました。
園山さん：新卒で商社に勤めていたころ、駆け出しの情シスをしていました。そこで海外の会社を買収する話があり、海外拠点が5拠点から20拠点に増えたんです。
くま：4倍……！
園山さん：誰が20拠点の海外インフラの面倒を見るかとなったとき、いちばん下っ端だった私が担当したというわけです。海外拠点のインフラをトラブルシューティングするにあたり、フットワーク良く見に行けないもどかしさに加え、ネットワークに詳しくない現地スタッフと、慣れない英語でやり取りするときに「直接ネットワークの状況を見られるようにすれば、効率よく指示が出せるのでは？？」と思ったことがキッカケでSonarmanを作りました。
くま：……まさかそのころからずっと、パケットダンプをしつづけられているのですか？
園山さん：そのまさかですね。新人のとき、何もわからない素人情シスがチームに貢献するために見出したことが、「かならずパケットを取っておく」習慣でした。いつしかパケットにも見慣れ、その基本動作が技術に結実し、独立することになるとは、そのときには予想できませんでしたけどね。
Sonarmanは一日にしてならず。薄い筐体と、経験に基づいた手厚いコンサルティングによって、LIGのVPN環境もまた救われたのでした。
- Sonarmanの4つの特徴
-
- 顧客との詳細なヒアリングと綿密なフィードバック
- 既存のネットワークに最小限の構成変更で導入可能
- 勘ではなくログを根拠に積み上げることによる診断
- パケットのトレンドなども踏まえた専門性の高いコンサルタント
