社内Wi-Fi大全～見えないものとの戦いに挑んだ技術者たち～
こちらはMoney Forward CorporateIT Advent Calendar 2022 ⧉13日目の記事です。
前回はmochicoさんの「サーバーサイドエンジニアからコーポレートエンジニアに転職してみた⧉」でした。
自己紹介
マネーフォワードでコーポレートインフラ担当しておりますnikokenと申します。普段は社内システムの導入/改善/運用のお仕事をしており、最近は自身の英語力と会社から求められている英語力とのgapを埋める日々です。
はじめに
社内ネットワークは当たり前のように無線化されている現状ですが、私が入社して以来、不具合改善や品質向上を行ってきたことを振り返っていきたいと思います。
※これ以降、文章の体裁が変わります。
困難の前触れ
私が入社当初、本社は森永プラザビル本館17階にあり、すでに無線LANはFortiAPで構築されていた。当時はUTMがFortigateでその機能をフル活用しようとアクセスポイント機能も同機種で設定していた。その製品の採用根拠はコストパフォーマンス重視だったかもしれない。
APの管理を任させた私はここからいくつもの試練が待ち受けていようとは思いも寄らなかった。
不具合が発生
「ブツブツ切れる」、、、無線LANに対する社員からのご相談だ。右も左も分からない私は社員にPCの再起動を要求するしかなかった。入社間もない私は、分からないだけで終えるわけにはいかないと、無線LANについてひたすら調べていく日々。少しずつ知見が溜まっていった。
当時の私が出した答えは「チャネル番号の固定化」だった。APが電波干渉や外来波影響によりチャネル番号が変わるタイミングでそのAPに接続しているノードが一度ネットワークが切断されてしまっていることを確認。その番号変更をさせない施策として番号を指定することにした。
効果はあった。社内設置のAP全台をそれぞれ固定化したため、それまでチャネル番号変更の影響で隣接するAP同士が同じ番号になってしまっていることが原因でのチャネル使用率を抑えることができ、結果無線LANの品質向上ができた。
ただし、そもそもAPの台数と配置がフロアレイアウト変更に追随できておらず、壁や間仕切りのせいで電波強度が極端に低いエリアがあったりと、設定変更では対応できない部分も多かった。
反撃の狼煙をあげよ（本社移転）
2018年7月本社移転。事前に移転に関して関係者限定で情報が開示され、私は社内ネットワーク部分の検討担当となった。そこで私は機器リプレースに打って出た。総取り替えである。収容想定人数などのキャパシティプランニングの結果、以下の要件を満たすスペックを検討することになった。
機器選定を1から行えるプロジェクトに「根本的に改善できる！逆転できるぞ！」とWi-Fiに対して巻き返しを図る絶好のチャンスと、導入に関して総力戦となるベンダーさん3社との検討および相見積の結果、ネットワークバリューコンポーネンツ様と導入を進めることを決めた。
移転当時の戦いの様子はこちらをご覧いただきたい。
なお、後になって分かるのだが入社者の増加数が想像以上のものとなり、数々の困難がやってくることを当時知る由もなかった。。
いくつもの試練が待ち受けていた
2018年7月当初、移転作業は無事完了した。社内Wi-Fiはというと、APを35台以上設置してフロア全体で電波が届くように配置、ClientMatch機能を最大限に活用するために自動設定を積極的に採用し、管理者の手を煩わせること無く利用者も運用者も快適利用が可能になったと思われた。
「たまに切れる」、、、盤石のハードウェア環境にも関わらず、移転後しばらくするとこんな声が聞こえてくるようになった。
調査すればするほどぬかるみにはまる感覚の中、私は神経を擦り減らしていった。ストレスで暴飲暴食を繰り返し、体重もみるみるうちに増加していった。
構成変更（前期）
まずは全体のネットワーク通信量の多さに着目し、LBOの活用を検討。WindowsUpdateなどの回線ひっ迫を促す通信を逃がすことにした。WANに近い部分の通信の最適化は進んだのだが、顕著な効果が見えず、LAN側への対策へとシフトしていった。
「台数を減らす」、英断だった。ぶら下がるノード数が社員数増加により増える一方でAP同士の干渉に悩まされていたことに対処する策だった。「アクセスポイントは多いほど快適」の誤解を解くのに十分な効果を発揮、知見をためることができた。その後、この知見はチャンネル番号の重複や出力電波調整に活かすことになり、5GHz帯を軸にしたWi-Fi構成の基礎となった。
利用用途の変化
2020年4月の東京、神奈川、埼玉、千葉、大阪、兵庫、福岡の７都府県に発令された緊急事態宣言前後からzoom等のweb会議が多くなり、当初の想定とは異なるトラフィック量や種類を取り扱うことになったので、無線LAN設定にも利用用途に追随する形で変更を加えていった。
構成変更（後期）
ClientMatch機能の全自動化から当社の利用シーンにあった一時手動設定を併用する形にシフトし、以下設定値に関しての調整を実施。こちらも効果が出た。
【変更した設定箇所】
送信レート：特定のAPに弱い送信レートをつかんだままのノードがいることによる、他ノードへの悪影響を減らすため実施。
arm変更（good-snr/bad-snr/snr-thresh）：Sticky Client 対策のため、最適なAPを常に利用できるノードの挙動を促すために数値の調整を実施。
CM変更（CM calculating interval/CM neighbor matching %）：arm設定と同様、ノードが常に最適なAPに接続され続ける状況を促すため数値の調整を実施。
帯域幅制限：特定のノードのトラフィック量でその接続しているAPに対する通信の占有率を平準化させるために実施。
WMM、DSCP：QoSの1つ、トラフィックを4つのカテゴリに分けて優先制御させる設定を実施。
また、利用用途をAPごとに分けることにより、オフィスのメイン通信をほかのBYOD/ゲスト利用用通信の影響から逃れるため、zone設定を活用して周波帯含めた「棲み分け」を実施した。
次世代へのバトン
現在も一進一退の攻防が続いている状況だが、いよいよ社員数増加による「そもそもすべてが足らない」状況に至った今、次なる手を打つべく新たな仲間も加わり、スペシャリストの彼らに我々の未来を託そう。
この記事が気に入ったらサポートをしてみませんか？