まえがき
みなさまお疲れ様です。Gzockです。
ビットキー 情シス アドカレも終わりが見えてきました。
何を書くか迷ったのですが、私の一発目の記事でも予告していた通りMerakiのパフォーマンス向上の話をしようかな、と。
元々NWエンジニアだったので関連して多少なりともWi-Fiへの知見はありますが、まぁとはいえWi-Fiは専門ではないので間違ったことを言ってるかも？です。
しかしながら、今回のアプローチを用いて、弊社のNW環境は劇的に改善したのもまた事実です。
色んな会社で適用できるか？っていうとそうではないと思いますが、参考になる部分も多少なりともあると思います。そうならば私も大変嬉しく思います。
あ、ちなみに、私が好きなプロトコルはGREです。ていうかトンネリングプロトコルは大体好きです。
そもそもの話
- 私は情シス所属ではありません
- 普段はIoTの開発やってます
- 2023 AWS Summit Tokyoで弊社が登壇させてもらいましたが、その中で言及しているプラットフォームを担当しています
- その他、登壇資料を見てもらえるとどんなヤツか大体わかると思います
- なのになんで情シスアドベントカレンダーで割と記事書いてるのって？
- わかりません, ボス(@h_r_w_t_r)に聞いてください
- ちょっとした経緯は上述のOkta WFsの記事で言及しています
この記事は何？
- 弊社は創業からずっとシェアオフィスであったが、2021年夏に自社オフィスに移転した
- そこから自社管理のMerakiをベースとしたフルWi-Fi環境になった
- オフィス移転当時のNW設計および構築はベンダーにまるっとおまかせ
- 当時、私は入社していなかったので当然ながら全く関与していない
- 以降、NWがおそい！ネットが遅い！ Slackが見れない！ オンラインMTGで音声がめっちゃ途切れる！といった声が多発
- それを何とかした記事
- これらの内容は基本的にすべて自社で対応した内容になる
- 回線増強とAP増設はさすがにベンダーにお願いした
弊社オフィス環境の前提
- 全端末がWi-Fi環境であり有線接続している端末は一部の特殊用途を除き存在しない
- MerakiによるクラウドWi-Fi環境を構築
- 東京オフィスに20台超のアクセスポイント(AP)を敷設
- その配下にmacOS端末が150台程度は存在
- 基本的に大半の業務が何らかのSaaSに依存しており、ネットワークが生命線
- ちなみに開発や検証の関係でiPhoneやiPad, Android, 弊社IoTプロダクトなども存在するため、実際のクライアント台数は数百台になる
注意事項
- 大前提にまずは私が以前書いたこちらの記事を読んでおいてほしい
- 読んでる前提で本記事は話を進める
- 個々のNW技術について詳細は解説しない
- ある程度わかっているものとして本記事では話を進める
- CCNAぐらい持ってれば全然わかると思う, たぶん
- もしベンダーにお願いしてどうこうできるならそうしたほうがいい
- それこそAPどこ置く？みたいな基本的な施工部分についてはサーベイの必要もあるしベンダーおまかせのほうが絶対いい
Wi-Fi環境構成
- MX250 - MS250 - MS350 の三段構成
- MS350配下にPoEでMR57シリーズのAPが30台弱ほどぶらさがる
- 以下にMerakiのダッシュボードで表示されるトポロジーを貼っておく
- まぁあまり意味のある図ではないし、あとでこの構成の問題については言及する
弊社のNW構成におけるいくつかの問題点と解決策
- 詳細は割愛するが、私の1つ目の記事を用いて多くのサンプルを集めることができた
- その結果、以下の事実が見えてきた
ピークトラフィックにアップリンクが耐えられない
問題
- 当初、弊社のインターネット回線はベストエフォート2Gbpsだった
- 各種メトリクスを確認していると、朝10-11時, 13時過ぎ, 17時-18時などの皆がMTGをやりまくるような時間帯に輻輳を確認できた
- 同タイミングで多くの社員の平均RTTなども軒並み悪化することを確認
- 実際、社員の意見としても、そのタイミングのMTGで音声が途切れる / カメラ映像が見えない, などの問題が多発していた
対策
- 回線増強しかない
- ここは金で解決するしかない
- 各種メトリクスによって”明らかに足りていない”ことが確定的だったため、ここはお金を使って回線を増強しなければ根本対策にならないと判断できた
高密集AP環境であるにも関わらず隣接APでチャネルがぶつかっている
問題
- 平均RTTが悪くなりがちな社員とAP位置の関係を探っていて発見
- チャネルがぶつかると信号品質が下がる
- 各APがどこかしらのチャネルを持つわけだが、それが隣接APとぶつかっているケースがあった
- 恐らく最初はちゃんと設計していたのだと思うのだが、オートチャネルによる変更が何度か走った？元に戻らなかった？ のかもしれない
- そこまで強烈な影響なわけではないが、確実に悪い影響を与える状態であったのは間違いない
対策
- 愚直にチャネルを再設計
- 高密集AP環境において隣接AP同士でぶつからないようにするためには使えるチャネルの候補を増やす必要がある
- つまりチャネルボンディングをやめて、理論値の広い帯域幅は捨てて通信安定性に振ったチャネル設計にする
- オートチャネルはやめてマニュアル設定させる
- DFSが発動する可能性のある箇所は敢えてW52のチャネル帯を割り当てる
野良APが多くチャネルボンディングしているせいで既存APのチャネルに競合している
問題
- RTTが悪くなりがちな社員とAP位置の関係を探っていてSN比も比べたところ発見
- 上述の通り、NWに不満をかかえる社員が多かったがために、勝手にテザリングなどをするケースがちょいちょいあった
- そもそもはオフィスNWが悪いので社員を責めることはできない
- テザリングやポケットWi-Fiおよび類似品は、IEEE802.11acやaxで電波を吹くわけだが、このとき余裕でチャネルボンディングをしている
- つまり、20Mhzではなく、40Mhzや80Mhzで吹いている
- こうすると、ただでさえ高密集APでチャネルが詰まっているのに、おもいっきりぶつかることになる
対策
- 愚直に知らないSSIDを追いかけてそれっぽい存在を特定し止めてもらう
防音の会議室地帯のAPが少なすぎる
問題
- RTTが悪くなりがちな社員とそのタイミングでつながっているAPの位置関係を探っていて発見
- 弊社の会議室はすべて防音構成になっている
- それらの会議室が一帯に集まっているわけだが、そこにAPが2台しかなかった
- しかもそれが廊下にある
- 防音会議室は素材がしっかりしているので必然的に電波も通しづらい
- 結果、会議室の中でMTGをしているときに特にNW品質が下がることになった
- 昨今はオンラインも併用したハイブリッドMTGは盛んに行われていると思うが、当然そういうときに画面の向こう側にこちらの音声が届かない・・・という問題が多発
- オフィス移転時のベンダーのサーベイどうなってんねん！って思うけどまぁそこは我慢
対策
- APの出力を意図的に引き上げ部屋内に届きやすくなるようにして暫定対策
- その間にAP増設プロジェクトを推進
- 今までは2台しかなかったAPが今は4台に増え電波品質はかなり改善
- 同時に平均RTTの改善も観測
クライアント過多
問題
- RTTが悪くなりがちな社員をAP毎にgroupByしていると相関関係があり発見
- 前提の部分にも書いたが、とにかくクライアントの数が多すぎる
- Wi-Fiは昔からCSMA/CAプロトコルを採用しているため、上り下りの通信はぶつかる可能性がある
- つまりとにかくクライアント台数が多い環境に弱い
- 今でこそ、IEEE802.11axで採用されているOFDMA(Orthogonal Frequency Division Multiple Access/直交周波数分割多元接続)によって多くのクライアントがぶら下がる台数が多くなってもパフォーマンス維持しやすくなったが、それでもまだまだ
- そんな中、弊社はIoTプロダクトも提供していたり、あるいはスマホアプリ開発の必要性がある関係で、とにかくWi-Fiクライアントが多い
対策
- 個人スマホをつなげられるゲストSSIDを吹けるAPを限定化
- 執務室エリアでは個人スマホはAPに接続できない状態にする
- 開発スマホや開発IoTがつながるSSIDも分離 → 定期的にパスワードを変更させる
- 無造作にクライアントが増えすぎないような作戦
DFS発動による強制クライアント移動からくるNW切断
問題
- 不自然にWi-Fiに接続できないケースを見つけその理由を調べるためにイベントログを見まくっていたところ発見
- 5Ghzはチャネルによっては**DFS（Dynamic Frequency Selection）**の可能性がある
- 気象レーダーなどが用いる周波数とぶつかる可能性があり、それを避けるためにWi-Fi APたちは一時的にチャネル移動する必要がある
- 弊社オフィスは毎日何度か特定の方向からちょいちょいレーダーをくらいDFSが発動することがわかった
- この度にWi-Fi停波 → クライアントはすべて別APに移動が起こる
- この瞬間、クライアントたちは通信不安定な環境に一時的に陥ってしまっていることを意味する
対策
- Event logから
DFS event detectedで検索すれば、何時にどこのAPでDFS発動したのか？はわかる
- この統計をとることで、どこのAPでDFSが発動しやすいかがわかる
- わかったら、そこのAPに割り当てるチャネルをW52にし、DFS発動義務がないチャネルを意図的に使うようにする
- 弊社の場合、オフィスのとある一帯のAP3台程度が毎日DFS発動していたので、それらのAPに対して本施策を講じた
- これも踏まえて他項目で言及したチャネル設計を行う
各クライアントのローミングが遅く移動後のNW体験が悪い
問題
- 平均RTTのトレンドとその社員のスケジュールの相関関係を調べていて発見
- 会議室への移動などにより端末はローミングが発生する
- これが遅く、移動先のWi-Fiを正しくつかめていないケースが多発
- 結果的に例えばMTGのために会議室に移動してSlackを開こうとしても全然開けねぇ・・・！みたいなことが多発
- 弊社はすべてmacOS端末なのだが、M1以降でなければ、高速ローミングをするための規格であるIEEE802.11r / IEEE802.11k / IEEE802.11/vに対応していない
- Apple Sillicon搭載macへのリプレースはどんどん進んているが、それでもなおまだIntel macはいる
- これらは特に本件のローミングでの影響を受けやすい
対策
-
身も蓋もない話しだが、Intel macを買い替えてどんどんApple Sillicon系に変えていく
-
airportコマンドにローミング設定を変更する- JoinMode=strongestとすることで電波強度を優先的な条件としてローミングするようになる
- デフォ設定だとWi-Fi規格など他要素も多角的に組み合わせて切り替えが発生する
System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport prefs JoinMode=Strongest JoinModeFallback=KeepLooking
中間経路の輻輳
結果的にこれが一番効いた
問題
- SSIDおよび紐付けるVLANの設計の問題である
- 各APは1Gbpsで通信できる
- ということはワイヤースピード限界までトラフィックが流れるのであればアップリンク側は30Gbps流れる可能性がある
- しかし、MS250とアップリンクを持つMX250の中間経路は4本しかなかった
- さらにMXシリーズはLink Aggregationに対応していない
- 複数配線構成にするなら、必然的にRSTPになってしまう
- よって、配線的に2本だろうが4本だろうが8本だろうが、実質的に1Gbpsしか使えない
- 弊社の場合、従業員利用のためのSSIDは原則1つで運用していた
- これが30弱のAPたちで吹いているわけだが、AP単位でみれば1Gbpsで通信できる可能性があれど、上述の理由により確実に中間経路で詰まってしまっていた
対策
- LAGが使えない以上どうしようもない 😢
- まず従業員用SSIDを複数に分割
- 分割したそれぞれのSSIDにそれしか使わないような専用のVLANを切り出す
- それぞれのVLANのアクセスポートをMS250とMS350の中間経路として設定
- これにより各VLANが各ポートを独占利用でき、以前に比べれば明らかに中間経路のスループットを向上させられる
- ゲスト用や開発用SSIDは多少スループットが悪くても許されるので共用SSIDおよび共用VLANとしてトランクポートでタギングして流す
- 社員はロールごとにグルーピングしJamfによって利用可能なSSIDを切り替えるプロファイルを流す
- これで社員グループAはSSID_Aのみを使う・・・という形にする
- また別項目で説明している通り、一部のSSIDを一部のAPに限定させることにより、クライアントを削減 → トラフィック削減
- ただし、MSおよびMXシリーズは10G-SRやLRに対応しているため、それでつないだほうが帯域は稼ぎやすい
- 弊社の場合は諸々の事情により、そういう根本的な構成変更をとるだけの余裕がなかったため、今回のようなVLAN分離/ポート分離で近いことを実現した
その他の対策
トラフィックシェーピングしよう
- アップリンクの帯域は有限である
- 重要なVLAN = 守りたいVLANを定義し、それ以外のセグメントの通信は意図的にシェーピングして抑えるようなやり方もアリ
- 弊社の場合は以前はこれをやって負荷緩和策としていた
- 今はもうやめた
何らかプロキシさせるようなセキュリティツールを導入しているのなら重要な通信のみ バイパスさせよう
- 昨今のミドルボックスっぽく振る舞うセキュリティツールは大体プロキシ的に動く
- つまり、全通信が原則セキュリティツール → 昨今ではSaaSに通信が捻じ曲げられ、仲介され、インターネットに出ていく
- 通信経路が圧倒的に大回りになるため、セキュリティツール有効/無効で明らかにレイテンシは増えスループットは下がる
- 何かしら負荷がかかりやすい通信、あるいは重要な通信が明らかにわかっているのであれば、それはそのセキュリティツールの設定としてバイパスさせよう
- オンラインミーティングとかね
- やりすぎるとせっかくそういうツールを使っている意味がないので、この方法はご利用を計画的に
クライアントバランシングは気をつけよう
- Merakiはクライアントバランシングという独自機能がある
- クライアント台数が多く負荷が高いAPからクライアントが移動し、AP間でのクライアント台数が均一化される素敵な仕組み
- これを語ると時間がかかるので詳細は割愛するが、環境によってはかなり相性が悪いケースがある
- うちがそれ
- よって、弊社の場合はクライアントバランシングは無効化している
- とはいえ、これは有効化の一考の価値がある機能であるのは間違いないので、試してみたほうがいい
- ただし、その有効無効を正しく評価できるためにも、私の最初の記事のように何かしら定量的に判断できるような基準や方法を設けておくべき
- ただし、実はこのクライアントバランシングは昨年(2022夏)にアルゴリズムにアップデートが入った
- 参考: Updates to Meraki Client Balancing
- 最近試していないのだが、もしかしたら今試すと事情は違うかもしれないと思っている
MerakiのFWバージョンは横着せず引き上げよう
- アップデートによってMerakiの安定性が増したりする
- 意外と忘れがちなのでちょいちょい確認して対応しよう
- とはいえ以下の既知不具合報告のようにバージョンによっては逆に不安定になるケースもあるので注意
- 弊社の場合は、この不具合の関与が強く疑われるログを多数確認したため、FWをダウングレードした
- ダウングレード自体はMerakiのサポートに連絡すれば可能
- 以前、この話をXでポストしているので興味があればどうぞ
あとがき
- 結果的にNW品質を向上させ、今では社員からはほとんど不満が聞こえてこないようになった
- もちろんまだやれることはあるし、今後も継続的にメトリクスを確認し、改善できるところはしていきたい所存
- もう専業のNWエンジニアからは足を洗って数年になるのだが、CCIEを取得できていないのが自分の人生の心残り…