この記事は、Techouse Advent Calendar 2024 24日目です。
昨日は Matsu-Nobu さんによる JavaScriptでテストしやすいコードを書く工夫 でした。24日目は、Techouse技術開発責任者の山崎 が担当します。
今回は、社内で利用しているWebブラウザベースのVoIPサービス「CallConnect (以下、コールコネクト)」における通信不安定の問題と、その解決に至る過程を共有します。
VoIP とは
TechouseではWebブラウザベースのコールコネクトを利用し、セールス担当者・カスタマーサクセス担当者・キャリアアドバイザー担当者とお客様との間の連絡にフル活用しています。Webブラウザからコールコネクトの画面を開いてボタンをポチるだけでお手軽に外線電話をかけられるので大変重宝しております。
こういうふうにインターネットやLANを介して内線電話・外線電話を実現する技術のことを「VoIP (Voice over IP)」といいます。VoIP自体は私の知る限り四半世紀以上前から存在しており、とくに目新しい技術ではありません。NTT東日本・NTT西日本の「ひかり電話」をはじめとして国内で多数の事業者がサービスを展開しています。かつては専用のハードウェア・専用のネットワークを利用していたものですが、だいぶ前から PC 上のアプリやブラウザ上でも手軽に利用できるようになりました。
そんなことから、私は「VoIPなど枯れきった技術であろう」と思っていました。
問題続出
社内でコールコネクトを利用しているユーザから「短時間(数秒間)、通話が途切れる」という事象が従来からたびたび報告されていました。ありがたいことに多くのお客様を担当させていただく会社となった結果、その事象も徐々に増加を続け、無視できない件数になってきました。そして解決に向けて調査をスタートすることとなったのです。
難易度の高いトラブルシュートだった
しかし原因特定は困難を極めました。
複数機種の複数端末で発生していることから、おそらくは個々の端末の問題ではなく回線やルータまわりで発生していることが想定されました。そのあたりから調べていきます。
が、利用推奨環境は当然満たしておりましたし、公式のネットワーク環境の確認の手順を踏んでも問題が検出されることはありませんでした。
回線帯域の空きもトラフィックグラフで十分に確保されていることを確認しました。
メイン回線はNURO Bizですが特に障害は発生しておらず、バックアップ回線として利用しているフレッツ光ネクスト プライオ + IIJ IPv6 FiberAccess/Fサービス タイプIPoEに切り替えても問題は解決しませんでした。
ルータにIIJ SEIL/X4を利用していますが、そのログを眺め回しても何も問題が見つからず、ルータ直下のスイッチに Cisco Catalyst シリーズや YAMAHA SWX シリーズを利用していますがそれらのログを見ても何もわかりませんでした。たいして複雑なネットワークではありませんので、とくにこれといったコンフィグの問題も見つかりませんでした。
無線LAN原因説
みなさんは Zoom や Google Meet や Slack のハドルミーティングなどで、このような症状を経験したことはありませんか?
- 数秒間だけ音声・映像が止まる
- 一時的に相手の声がロボットのような機械的な声になる
これらは一時的なパケットの到着遅れや、パケットの往復時間のゆらぎ(ジッタ)、パケットロスに起因して発生します。典型的には無線LANを利用しているとき、この問題が高頻度で発生します。
こちらのグラフをご覧ください。
これは2020年に旧オフィスにて無線LANアクセスポイントのリプレイスした際に、Google Public DNS (8.8.8.8) への ping の RTT (往復通信時間) を旧アクセスポイント・新アクセスポイント・有線LANの3パターンで1秒おきに計測したものです。縦軸は時間、横軸は回数です。
無線LANでは赤丸で示した箇所のように一時的に RTT が大きくなるのがわかります。
この瞬間に通話中の音声・映像が途切れたり、相手の声がロボ声になったりします。
これは何故かというと、無線LANが 「同じチャンネルを他の人が使っている間はパケット送信を止めて、待つ」 という方式だからです。外部・内部の通信による干渉によって「待つ」時間が発生するぶんだけ一時的に RTT が極端に増大したりします。 オフィス街の場合は平日より休日のほうが安定して通話でき、住宅街であれば昼間より深夜のほうが安定して通話できたりしますが、これは周囲で通信をしている人が少なくなることによって外部からの干渉が減るためです。
この問題は本質的に無線LANの通信方式によるもので、無線LANを利用している限り避けることができません。
理論上は干渉のほとんどない山間部や、電波暗室などの理想的な環境では解決できますが……わたしたちTechouseのオフィスの周囲には大中小さまざまなオフィスビルがあるため、外部からの干渉を避けることは不可能です。
無線LANにまつわる問題を回避するため、社内では 「通話時には有線LANを使う」 ことをルールとしています。ですが、ひょっとしたら「このルールが徹底されていないのでは? そのせいで通話が途切れたりしているのでは?」と思いました。これが問題の原因だとしたらどれだけラクだったことでしょう。しかし現地を確認したところ、たしかに有線LANを使っていることがすぐにわかりました。
……というところまでを調べてもらったところで、この続きは私の出番となりました。
技術開発責任者ですので、社内で発生している技術的な問題について何でも解決しようという意気込みをもっております。
颯爽と現場に乗り込みました。
ping RTT を実測する
ひとまずコールコネクトを使っている方みなさんに「ping RTT を測定し続けてもらって、問題が発生した瞬間のスクリーンショットを送ってもらう」ようにお願いをしました。
すると、問題が発生した瞬間の ping RTT をばっちり記録できました。
原因の尻尾がつかめました。
しかし何故にこのような問題が発生しているのかは全然わかりませんでした。
ビデオカメラで問題の瞬間をとらえる
オフィス内の各座席島ではバッファロー社製「LSW6-GT-8NS」を利用しています。非常に安価ながら電源内蔵タイプということで、重宝しています。(画像はメーカーサイトより引用)
しかしこのハブにはログを保存する機能がありません。まさかこのハブでログを必要とする問題が発生するとは思っていませんでした。いや、厳密にいうと、発生する可能性があるかもしれないとは思っていたのですが、ハブの予算をケチった私が悪いのです。
というわけで、この問題が発生している瞬間に何が起きているのかをとらえるために、ビデオカメラを引っ張り出してきて設置し機材一式を録画しました。
なんとも原始的な方法ですが、これで問題の瞬間を捉えることができました。
通常時はグリーンのランプ（1000Base-T接続）が点灯していますが、問題発生時には1〜2秒間だけオレンジ（100Base-TXまたは10Base-T接続）に変化していることが特定できました。
ビデオカメラでいっしょに録画している時計の時刻と問題発生の報告があったタイミングとも完全に一致しており、これが原因で間違いなさそうです。
このような一時的なリンク速度の低下の原因として考えられるのは、EEE (Energy Efficient Ethernet) です。
EEE とは本来、省電力のためにアイドル時にリンク速度を低下させる技術です。通常は通信がないタイミングでしか発動しないものですが、妙です。
ログがとれる機材に変える
そこで、おもむろにYAMAHA RTX1200を引っ張りだし、ハブの代わりに設置しました。
(配線が汚くてすいません。)
RTX1200 は EEE 非対応ですので、これで問題が解決するはずです。というわけで RTX1200 でしばらく運用していたところ、問題発生が少し減りました。ただし依然として問題発生件数はゼロにはなりませんでした。 RTX1200 のログを調べていくと、Buffalo LSW6-GT-8NS を利用していた時代は1〜2秒程度「リンク速度が落ちていただけ」だった問題が、RTX1200 では1〜2秒間の「リンクダウン」となっていることに気づきました。
「EEE が原因である」という仮説でここまで調べてきましたが、結果としては EEE 非対応の RTX1200 に交換しても問題は解消しませんでした。なので、仮説とは矛盾した事象が発生しています。もしかしたら EEE は原因ではないのかもしれません。
EEE が原因だった
というわけで奮発して Cisco Small Business 250の8ポートのモデルを購入しました。
これは EEE をオンにしたりオフにしたりできるモデルです。
EEE オンにしたりオフにしたりして実験を繰り返したところ EEE を強制的にオフにすることで問題発生回数が減少することがわかりました 。
USB まわりも原因だった
以前は「1日に数件発生していた」状態こそなくなったものの、「起きない日は全然起きない、起きる日は特定の人にだけ発生する」という状況になりました。発生回数は減ったので一応は進歩ですが、まだ根本解決にまでは至っていません。なので調査は続行です。
Techouse ではデスクトップPCのユーザは非常に少なく、ほとんどの人がノートPCで業務を行っています。
最近のノートPCは有線LANのコネクタが無いものばかりになりました。とくにコールコネクトを重点的に利用するチームの方は Chromebook を利用してもらっているのですが、Chromebook で有線LANのコネクタを持っているモデルは当社では保有しておらず、やむなく USB-LAN アダプタを使ってもらっています。
その Chromebook の同じモデルで同じ USB-LAN アダプタを使っていても問題が発生するケースと発生しないケースがありました。実際に利用している様子を見ると、その Chromebook の右側の USB ポートに LAN アダプタを挿すと問題が起き、左側の USB ポートに挿入すると問題が発生しなくなることがわかりました。
驚きましたが、おそらく内部での配線やチップの配置に起因しているのでしょう。これでまた発生件数が減少しました。
ここまでくると発生件数もだいぶ少なくなってきたのですが、さらに端末とUSB-LANアダプタの組み合わせを根気強く変えて試すを繰り返し、発生件数をさらに減少させることができました。
複数原因からなるトラブルの難しさ
結論としては
- Energy Efficient Ethernet (EEE) による問題
- USB ポートによる挙動差の問題
- USB-LAN アダプタ自体の問題
これらの3つのうちどれか1つに当てはまるだけで「通話が途切れる」という事象に至ることがわかりました。
本記事ではまるで一本道にこの結論にたどり着いたかのように書いていますが、実際にはああでもない、こうでもないというふうに試行錯誤が続き、とてつもなく時間がかかってしまいました。これは何故かというと、一般的なトラブルシュートにありがちなパターンとは外れたケースだからです。
トラブルシュートの際には仮説を立てて、その仮説が現実の事象のすべてを説明するものとなっているか否かを確認しながら調べていくと効率が良いです。闇雲に調べるのではなく，スマートかつ論理的に原因にたどり着くために「仮説を持つ」というのはとても需要なことです。私自身ふだんからそうしていますし、多くのエンジニアの方もトラブルシュートの際に同じような思考法をしていらっしゃるのではないかと思います。
しかし同時多発的に問題が発生している場合には仮説を立ててから調べるアプローチというのは逆に問題解決を難しくします。
仮説を立てたところで、その仮説が事象をすべてを説明するものとはならないからです。
(冒頭にて「複数機種の複数端末で発生していることから、おそらくは個々の端末の問題ではなく回線やルータまわりで発生しているものと想定された」と書きました。これがすべての問題を説明しうる「仮説」だったからですが、結果として原因ではありませんでした。)
というわけで、わけのわからないトラブルのときにはいっそ闇雲でも前に進んでみたほうが良いということもありうるのだというお話でした。この経験が、同じような問題に直面した方々のお役に立てれば幸いです。
明日のTechouse Advent Calendar 2024は代表取締役兼エンジニアの礒邉さんによる 10年間モノづくりを主戦場にしてきた代表が、今後10年もそうあり続けるために何をしているのか？ です。
では皆さま、Happy Holidays!!
Techouseでは、社会課題の解決に一緒に取り組むエンジニアを募集しております。 ご応募お待ちしております。
