無線 LAN の通信品質を見える化する話

これは DeNA Advent Calendar 2018 その2 の 7 日目の記事です。

こんにちは、IT 基盤部ネットワークグループの寺増です。

ネットワークグループでは、各サービスを提供している DC ネットワークの他、DeNA グループ全体のオフィスネットワークの管理・運用も行っています。

今回は、中でも日々重要性が増している無線 LAN の特徴と、それを安定的に運用するための通信品質観測の仕組みについて、本社ヒカリエを例に紹介します。

はじめに

1. 無線 LAN とは

無線 LAN とは、国際標準規格 IEEE802.11 で定義される無線技術を用いたローカルエリアネットワークの総称です。 1999 年策定の 802.11a/b に始まり、11g, 11n, 11ac と続き、来年からは 11ax (Wi-Fi 6) の普及も始まる予定です。

2. 有線 LAN との違い

無線 LAN は、有線 LAN と異なる以下の特徴があります。

通信の伝送媒体が電波である
利用には電波法による一定の制約がある
接続後のスループットが動的に変化する
ノイズの影響を非常に強く受ける
上りもしくは双方向の通信が半二重である (2018 年現在)

3. オフィスの無線 LAN と家庭の無線 LAN

オフィスの無線 LAN は、家庭の無線 LAN とは異なる以下のような特徴があります。

約 15 台のアクセスポイント (以下、AP) で一つのカバーエリアを構成している
1 台の AP に対して、40 - 80 台程度のステーション (端末) が同時に接続する
干渉源のデバイス (Bluetooth, デザリング端末等) が多く存在する
高層階では、外来波である各種レーダーの影響を受けやすい

4. オフィスの無線 LAN で発生する様々な事象

前述のような特徴から、オフィスの無線 LAN では次のような事象が発生し「遅延」や「断」に繋がります。

大容量通信による通信帯域の枯渇
スティッキークライアントによる帯域の浪費
隠れ端末・晒し端末による余分な通信待ちの発生
AP 同士の相互干渉による余分な通信待ちの発生
遮蔽物 (パーティション等) の構成によるカバレッジホールの発生
レーダーによる一時的な電波の停波、ひいてはカバレッジホールの発生
ノイズによる SN 比の低下、ひいては通信速度の低下
通信周波数の変更による一時的な通信断
BSS トランジション発生時の一時的な通信断
無線空間上でのフレーム消失によるパケットロス
その他、ステーション側のドライバに起因する様々な問題

ここに挙げた例の中には、ネットワーク機器側の情報だけでは実情の確認が難しいものも多く含まれています。

状況を正確に把握し、適切な措置を行う手段として、DeNA では icmp を用いた無線 LAN の通信品質観測を行っています。

無線 LAN の通信観測の仕組み

DeNA では、社内の ESSID に接続する全てのステーションの接続状態を計測・記録しています。

この仕組みは次のスタックで構成しています。

この仕組みにより、各ステーション・AP・フロア単位の通信品質を網羅的かつヒストリカルに可視化しています。更にこのデータを監視することで、大規模な通信遅延を能動的に検知し、続く改善措置までを一連の運用として行っています。

全体構成は以下のようになっています。

各処理について順に説明します。

1. リスト生成

AP に接続しているステーションの情報は、全て上位にある無線 LAN コントローラに記録されています。このフェーズでは、その情報を元にデータ収集の対象リストを Fluentd のコンフィグとして生成します。

無線 LAN のステーションは状態が動的に変化するため、このコンフィグも一定周期で再生成・リロードしています。

ここで生成している Fluentd のコンフィグは、以下のようなテンプレートを元にしています。

<source>
  @type       exec
  command     /bin/ping -i <%= ping_param[:interval] %> <%= client[:ipAddress] %>
  keys        rtt
  tag         foobar.<%= client[:ipAddress] %>
  time_key    time
  time_format %Y-%m-%d %H:%M:%S
</source>

<filter foobar.<%= client[:ipAddress] %>>
  @type       record_modifier
  <record>
    mac          <%= client[:macAddress] %>    // ステーションの MAC アドレス
    vendor       <%= client[:vendor] %>        // MAC アドレスを保有しているベンダー名
    ip           <%= client[:ipAddress] %>     // ステーションの IP アドレス
    ssid         <%= client[:ssid] %>          // 接続している SSID 名
    ap           <%= client[:apName] %>        // 接続している AP 名
    loc          <%= client[:location] %>      // その AP を設置しているフロア名
    rssi         <%= client[:rssi] %>          // ステーションで感知している信号の減衰量 (信号強度)
    snr          <%= client[:snr] %>           // S/N 比 (信号強度と雑音強度に基づく電波品質の指針値)
    proto        <%= client[:protocol] %>      // 接続周波数帯
    user         <%= client[:userName] %>      // 接続時に利用した証明書の CN
  </record>
</filter>

2. データ収集

データ収集には Linux 標準の ping コマンドを利用しています。前項テンプレートの <source> 部分が該当箇所です。この結果を Fluentd の exec Input Plugin でパースし、RTT のみを抽出して結果値に採用しています。

Linux の ping コマンドはタイムアウトを出力しませんが、タイムアウト自体を見る必要がないため意識はしていません。これは、ping のインターバル、応答数とそれぞれの RTT が判ればタイムアウト回数も逆算出来ることが背景にあります。

3. データ集計

ソースデータが常時止めどなく流れるストリーミング系であるため、この集計処理には Norikra を採用しています。このフェーズで、ステーション毎の 1 分間のデータ件数、平均 RTT、最大 RTT を算出して、元データに付与します。

無線 LAN は移動等で RTT が変動するため、平均の算出時には Norikra::UDF::Percentile によるパーセンタイルも行っています。

本社ヒカリエには日々 2000 以上のステーション (スマホ、タブレットを含めると更に倍以上) が存在しています。それらのデータを個別に集計する仕様から、ここには多めの RAM を充当して並列で処理を行うようにしています。

ここで生成される最終的なデータは、以下のようにモデルになっています。

{
  "mac": "11:22:33:44:55:ab",                // ステーションの MAC アドレス
  "vendor": "Unknown",                       // MAC アドレスを保有しているベンダー名
  "ip": "192.168.0.1",                       // ステーションの IP アドレス
  "ssid": "ssidName",                        // 接続している SSID 名
  "ap": "AP01",                              // 接続している AP 名
  "loc": "System Campus > HIKARIE > 20F",    // その AP を設置しているフロア名
  "rssi": -43,                               // ステーションで感知している信号の減衰量 (信号強度)
  "snr": 51,                                 // S/N 比 (信号強度と雑音強度に基づく電波品質の指針値)
  "proto": "5GHz",                           // 接続周波数帯
  "user": "foo@bar.baz"                      // 接続時に利用した証明書の CN
  "count": 4,                                // 1 分間に記録されていたデータの件数
  "max_rtt": 105,                            // 1 分間に記録されていた RTT の最大値
  "min_rtt": 18.4,                           // 1 分間に記録されていた RTT の最小値
  "percentiled_rtt": 89.7,                   // パーセンタイル・カットした RTT の基準
  "avg_rtt": 45.32500000000012               // 1 分間に記録されていた RTT の平均値 (パーセンタイル後)
}

4. データ蓄積／可視化

このフェーズで、Norikra によって生成されたデータを Fluentd によって引き戻し、そこから Elasticsearch にポストしています。Fluentd から Elasticsearch へのデータの引き渡しには、 Elasticsearch Output Plugin を利用しています。

これを Kibana から参照することで、各ステーション・AP・フロア単位、それぞれの通信品質を可視化を実現しています。

以下は DeNA で実際に利用している Dashboard のサンプルです。アクセシビリティ向上のため、フロントエンドは別途用意しています。