Cookpad TechConf 2017 提供 Wi-Fi の裏側

2017/4/11 技術系

目次

インフラ部 id:sora_h です。

先週開催された Cookpad TechConf 2017 如何でしたでしょうか。わたしは TechConf において Wi-Fi を担当していて、こちらも好評いただいたようでなによりでした。

というわけで、この記事では TechConf 2017 における Wi-Fi についての詳細を紹介します。

– PR –

ネットワーク機器設定・サーバー mitamae レシピ等の公開

https://github.com/cookpad/techconf2017-network

今回の紹介する構成のうち、ネットワーク機器およびサーバ側の設定等、ほとんどを GitHub で公開しています。参考までにどうぞ。

TechConf 2017 NOC メンバー

実は外注などはしておらず、社内 IT と SRE グループのメンバーで構成されていました。

  • メイン (設計・運用・設営)
    • @sora_h (SRE)
    • 社内 IT ネットワーク担当 1 人
  • サポート (設営・調達等)

どのメンバーも特にカンファレンス Wi-Fi 運用に手慣れた訳ではありません。

Wi-Fi 運用に必要なこと

わたしとしては、最低でも以下が必要という認識です。

  • 人間 (設計・敷設/撤収・運用)
    • 敷設/撤収・運用… 特に敷設と撤収は会場の広さに必要な人数が比例します
  • 会場と仲良くする
    • 回線の調整、配線の調整…。
  • ちゃんとした AP を複数台
    • データレートのカスタマイズ、パワーレベル設定、ローミング対応など *1
  • そこそこの L2 スイッチとルータ
    • ルータは Linux ルータとかでも良いと思われる
    • AP が PoE 対応なら PoE 給電できるスイッチだと良い
  • ちゃんとした DHCP/DNS サーバ
    • Linux 入れたラップトップにセットアップすれば十分
  • 消耗品など
    • UTP ケーブル
    • 養生テープ *2
    • 電源タップ

ただ実際のところ、現実的に AP は Cisco Aironet (はんぺん) や YAMAHA の WLX シリーズを使わざるをえないと思います。*3

今回の規模と会場では有線な箇所にボトルネックはなく、とにかく Wi-Fi 環境の運用が重要でした。ただ、トラフィック的にはそこそこのルータは必要でしたね。

キャパシティ見積り

会場は 恵比寿 ザ・ガーデンルーム で、想定来場数は 350〜370 となっていたため、

  • 想定 600 クライアント
  • AP 計 8 台
    • 会場内 AP 6 台
    • ホワイエ AP 1 台
    • 控室 AP 1 台

で進めていました。

結論で言うと、あのスペースに AP 6 台って密度高いかな…と思っていましたが、まあなんとかなりましたね。それでも会場内の AP は多くて 1 台あたり 60-70 associations を要求する見積りとなりました。
1 台あたりの要求がかなり多いですが、密度的にはこれ以上 AP を増やすのが厳しいので、耐えてくれ…と願いながらこの台数で臨んだ形です。

(なお、当初 4 台で検討していましたが、思ったより想定の来場数が多かった事であわてて直前に増やしました。実はこの会場は社内イベントで定期的に利用していて、普段の人数でそこそこ一杯だったため、その程度の人数だろうと思い込んで確認を怠っていました…。)

機材

今回は社内で未使用だった機材 *4 でまかなうことができました。

  • ルータ
    • Cisco 2921/K9 ISR (gw)
  • L2 スイッチ
    • Cisco Catalyst 2960S-24PS-L PoE+ (2 台; sw, sw2)
  • WLC
    • Cisco 5508 Wireless Controller (wlc)
  • AP (計 8 台: 会場内 6 台、ホワイエ 1 台、控室 1 台; ap1 .. ap8)
    • Cisco Aironet LAP1142N
    • Cisco Aironet CAP3602i
  • サーバー
    • ThinkPad X240 (tp)
  • その他
    • AP スタンドとしての譜面台 7 つ *5
    • UTP ケーブル Cat6 単線 (AP用)
    • 養生テープ等々

荷物の量としてはネットワーク機器だけで 6U と結構な量になってしまいました。本当は最小限の荷物にしたいところですが、オフィスに WLC などを設置の上 VPN…とするには機材が足りず、ざんねん。
この機材を気軽に運搬する事ができたのはオフィスと会場が縦移動だけで済むからこそですね。 (弊社オフィスは会場隣の恵比寿ガーデンプレイスタワーにあります)

なお、AP は在庫の都合モデルが混在する構成となってしまっています。
ThinkPad はまあ DNS などで必要になるだろうと入れましたが実際は DNS サーバー以外に役割を持たせる事はありませんでした。

設計

下記が今回の構成図です。 *6

https://github.com/cookpad/techconf2017-network/blob/master/techconf2017-nw.pdf

ご覧の通り、ごく当たり前の設計となりました。余裕があれば遊びを入れたかったところですが、残念ながら時間に余裕がありませんでした。次回もし担当する事があれば遊びたいですね。

ポイントとしては、可能な限りサービスは AWS 側に置いて省力化しています。なので、前述した会場持ち込みの ThinkPad は DNS 以外の仕事がありませんでした。
Linux ディストリビューションは Arch Linux を採用しました。

回線

今回は会場既設の回線を利用しました。
既設の機材も存在したため、ONU から一旦こちらの L2 スイッチで受けて既設の機材に戻すという構成を取らせていただきました。

さらにこちらの機材でグローバル IPv4 アドレスを持つ事もできた上、帯域も特に問題を感じませんでした。そのため、今回は直接会場からインターネットに出ていく素朴な構成をとる事ができました。

有線側設計

L1

基本、会場図面や現地調査で配置を考えて UTP ケーブル発注等々をします。今回は最長 60m で、会場後方に別途スイッチを設置する事としました。 (配信ブースに有線接続を提供する都合もあり。)

60m のケーブルを敷設するのとか巻くのとか結構たいへんでした。貴重な体験。

L2, L3

ネットワーク全体の CIDR は 10.200.0.0/16 で会場側は下記のセグメントを持っていました。

  • クライアント (VLAN 100, client, 10.200.0.0/20)
    • DHCP プールは .1.0 – .15.250
  • 管理用 (VLAN 200, mgmt, 10.200.16.0/24)
  • サーバ (VLAN 210, srv, 10.200.17.0/24) *7

AWS 側は 10.200.128.0/17 が VPC 、中に AZ 2 つで public, private subnet をそれぞれ持たせる構成でした。

会場 NAPT

カンファレンスネットワーク等、たくさんのクライアントが NAT 配下にいて活発に利用される状況ではセッション数に気を配る必要が出てきます。
そのため、このようなネットワークでは NAT 最大セッション数が万単位でサポートされているルータを利用する事が重要です。

今回は gw (Cisco 2921/K9) が NAT を担当していて、下記のように設定しました。
ホストあたり最大セッション数は 200、タイムアウトは一部を除いて 10 分になっています。

ip nat translation timeout 600
ip nat translation tcp-timeout 600
ip nat translation udp-timeout 600
ip nat translation finrst-timeout 15
ip nat translation syn-timeout 30
ip nat translation dns-timeout 15
ip nat translation routemap-entry-timeout 15
ip nat translation icmp-timeout 10
ip nat translation arp-ping-timeout 10
ip nat translation max-entries 65000
ip nat translation max-entries all-host 200

残念ながらこちらは SNMP で監視する事ができず、実際の消費最大セッション数は把握できていません。会期途中で show ip nat statistics を確認した時は 15000 前後利用されていました。
だいたい 1 ホストあたり 50 セッションと見積れば良さそうですね。

L4

AWS への接続は VPC の VPN connection を利用していました。今回の会場はたまたま固定 IP だったから利用できたけれど、ほとんどのケースでは面倒な事になるので自前の EC2 インスタンスでルータを組んだほうが良さそうに思います。

L7

DNS

DNS は Linux サーバーでホスト、また Unbound を採用しました。これは AWS 側に 2 台 Multi AZ, t2.micro で設置しています。

Unbound のチューニングは 公式ドキュメント が参考になります。ここの書いてある以上のチューニングは特にしていません。

一応、会場側 ThinkPad でもキャッシュサーバーを用意しました。が、AWS 側に全て転送して、AWS 側に用意した 2 台でのみフルリゾルブを行う構成を取りました。
本来であれば、CDN 等に考慮しフルリゾルブは同じ回線、あるいは同じ AS から行いたいところです。しかし、今回はそれを実現するために public IP アドレスに余剰がない + NAT セッションを無駄に消費したくない + CDNにそこまで最適化する必要がないという状況だったため、AWS 側フルリゾルブを選択しました。

実際のところ、レイテンシを考慮しての会場側キャッシュでしたが、会期中はレイテンシ 5ms-10ms とかなり AWS への接続が安定していました。なので別に会場に無くても良いんじゃないかなぁ、と今は考えています。

ちなみに、気付いた方がちらほらいましたが、Route 53 private hosted zone で 200.10.in-addr.arpa. と nw.techconf.cookpad.com. ゾーンを持っていました。

DHCP

DHCP も Linux サーバーに担当させ、ISC Kea を採用しました。こちらも AWS 側に t2.micro で設置しています。
AWS に設置、つまり会場側のブロードキャストドメインを越えているため、gw に DHCP relay の設定を入れました。

DHCP で気をつけたのはリースタイムとプールサイズで、こちらはプールは大きめに取ってリースタイムは 45 分としました。
今思えばもっと短くても良かったかもしれないし、セグメントサイズも小さくても良かったですね。思考停止して /20 とかにしていた。

冗長化は特にせず、memfile backend でディスクにファイルを書かせる形でリース情報の永続化を構成しました。裏を RDB にして構成しても良かったかなあ、と今は思いますが、AWS 側で failover の実装がやや面倒なので見送りました。

なお、relay agent を通して Kea 付属の perfdhcp で測定しましたが、300 4-way exchanges / second を記録できたため、特にそれ以上のチューニングはしませんでした。

有線その他

  • 配信は同じクライアントの VLAN に収容して特に QoS 等も設定しませんでした。これは上流が 200Mbps ほどあり余裕が確実に出るという予測 (配信は上り 4Mbps 程度しか使用しない) ためです。
    • 一応、会場内では TechConf 自体のライブ映像を見ないように協力のお願いをさせていただきました。ご協力ありがとうございました。

Wi-Fi 設計

有線ネットワークの数倍めんどうくさいのが Wi-Fi です。

基本的には、

  • データレートに気をつける
    • 遅いデータレートで通信されると他のクライアントも巻き込んで遅くなってしまうため (1台がチャンネルを占有する時間が長くなってしまう)。
    • なので、遅いデータレートを Disable するのは必須です。これが安定性にかなり寄与します。
  • チャンネル被りに気をつける
    • 敷設後イベント開始前に手動で調整しました。Automatic にすると離れてはいるが何台か被ってしまっていたので、結局 Manual で。
    • 2.4 GHz はもう無理なので諦め。どちらにせよ密度高く 6 台設置する環境だと被るので…。
  • パワーレベルに気をつける
    • クライアントは基本的に見えている一番電波強度が強い AP に接続しにいくため、遠い AP へ接続されないように気をつける
    • AP 間の距離が短めなので最弱に設定した上で、真ん中あたりが弱くならないように微調整。
  • セキュリティ面
    • クライアント間折り返し無効化、またスイッチ側で AP のポートに保護ポートを設定する (Cisco では switchport protected)
    • DHCP および DHCP 付与アドレスを強制

とすれば問題ない…と思いたいところです。

なお、データレートは今回下記を無効にしました。 (MCS index)

  • 5 GHz: 11a 6,9,12,18 / 11n 0,1,2,3,8,9,16
  • 2.4 GHz: 1,2,5.5,11,6,9,12,18

AP の配置

AP ごとに収容するクライアントの数をバランスよくできそうな間隔で配置していきます。

TechConf 2017 では会場内に計 6 つ、左右に 3 つずつ配置しました。また、ホワイエにも 1 つ、スタッフ向け控室にも 1 つ設置していました。

今回の会場であるガーデンルームはフラットでコンパクトですが、フラットじゃなかったり、広かったりすると真ん中にも配置したりと考える事が増えて大変になりそうです。

運用

Wi-Fi 運用は比較的筋肉運用の世界です。

たとえば定期的に AP ごとのクライアント数を確認して、明らかに接続数が偏っていたらその AP のパワーレベル・譜面台の角度や高さを調整してクライアントを散らす必要があります。

特に休憩・休憩終了時には入口付近の AP に接続したまま会場内に着席して、偏る、という事が発生しがちです。

トラブル

幸いにして目立ったトラブルはありませんでしたが、終盤 (17時前後) ある AP が定期的に association を全て落としたり、全然 association を持たないという現象が発生していて対処していました。最終的に一旦 AP を余剰機材に入れ替えたりしました。

その前後で全体的にクライアント数調整で不安定になっていたと思います。ご迷惑おかけしました。

設定漏れ

上のトラブルに関しても今思えば、ログは取っていたが各種トラップを有効にしてない事にまとめを書いていて思いました。これは DFS 発生などのログが残らなそうに思う設定ですね…。

その他も Client Band Select が有効になっていない状態でイベントがスタートしてしまい、一部 2.4GHz がなぜか盛り上がってしまうみたいな状況にも悩まされてしまった。 *9

監視

監視には Zabbix を採用しました。これは慣れてるのと SNMP 対応がやはり理由としては大きいです。環境は完全に普段のものから分離していたため、0 から zabbix-server を構築しました。
アイテムに関しても、基本的なメトリクスはトラブル発生時に供えて各種取得できるように整えました。kea, Unbound に関しては社内にもテンプレートがなかったので新規に作成しています。

構成は DB に PostgreSQL を使用し、Web frontend は php-fpm + nginx でホストする形をとりました。会場側に zabbix-proxy を設置するかどうかは検討しましたが無駄に管理対象増えるなと思って見送りました。

Grafana ダッシュボード

また、ダッシュボードの作成には Grafana + grafana-zabbix を使ってみました。個人的に最近 Grafana は便利な Zabbix フロントエンドという認識です。特に discovery で作成されたアイテムをまとめたグラフが簡単に作って自動で追加削除を反映させられるのが良い。

Grafana 自体もバイナリパッケージ入れて起動するだけで動くから手軽だなぁ、流行るわけだわーという好印象です。バイナリ置くだけで済んで便利じゃんみたいな奴、くぅ〜便利〜分かる〜とも思うのだけど、いろいろ複雑な心境を抱きますね。

ログ

起きてほしくはないですが、後で問題が起きた時のために DNS/DHCP/NAT ログを取得していました。

NAT ログに関しては Cisco から syslog での出力となるので、rsyslog を入れた EC2 インスタンスを AWS に設置して、WLC や L2 スイッチ含めてログ転送先としました。

敷設・撤収

前述の通り、今回は運搬がオフィスから会場で、かつオフィスと会場間は縦の移動のみで済ませられました。そのため、特に工夫はせず台車 3 台 + ダンボールで運搬をしていました。

他に確認するべき事項としては、会場やイベント運営スタッフと入り時刻・撤収時刻を確認しておきましょう。また、会場側でケーブルをどう配線しても問題がないか (養生テープ使用の可否など) を確認しましょう。

今回はほぼ 1 部屋というシンプルな配置だったため、特に深く考えず頑張ってケーブルを敷設・撤収する以上はありませんでした。

実績値

  • DL: 平均 48Mbps、最大 120Mbps
  • UL: 平均 16Mbps、最大 68Mbps
  • 最大同時クライアント数 330
  • DNS ヒットレート平均 45% (計測1分単位、会場側キャッシュのみの集計)
  • DNS 最大 49qps (会場DNSサーバのみ)

接続数は思ったより伸びず、上流回線も余裕がある状態で運用できていました。この伸びの悪さは張り紙などの周知不足かなぁと考えています。

接続先に関しては上から Google, Amazon (AS16509), Twitter, Apple, Amazon (AS14618), さくらインターネット, Akamai (AS20940), EdgeCast, Fastly, Facebook, Microsoft (AS8075), GitHub といった具合でした。AWS や Google はアテにならないとしても、それ以外から参加者の層がなんとなく掴める気がしています。

その他

今回助かった所

  • 手持ちの機材でまかなえた事
  • まともな回線が来ていた。会場にお願いして ONU 直収させてもらえたのは大変助かりました。
  • ガーデンルームを利用する社内イベントが開催の 2 週間ほど前にあった事
    • 実際の会場でホットステージを行えて、敷設や実際の問題点が早期に洗い出せたのだった。 特に敷設および撤退で気をつける点はおおよそ分かったため、当日の敷設・撤退の高速化に繋がりました。

今回困った所

  • IPv6 アクセスが無い。HE Tunnel Broker 使っても良かったんだけど…。
  • 弊社はオンプレ環境がなく、完全に AWS のみのためグローバル IPv4 アドレスも IPv6 アドレスも余らせておらず、構成の工夫に限度があった。
    • たとえば会場のインターネット接続性が微妙だった時に、EC2 経由でしか通信させられないよなとか。
    • 従量課金だし。あと EC2 ブロックしてるサービス実は結構あるので避けたいところ。
    • (ちなみに v6 アクセスはそもそもオフィスにも無い…)
  • AWS VPC の VPN connection、というか CGW は IP アドレス固定を想定している事
    • 今回はたまたま事前に確認できたし当日も変化がなかったけれど、AWS とくっつけるとしたら普通は自前の EC2 インスタンスと strongSwan でルータ組むのがよさそう。

反省点

  • 張り紙等の告知不足。おそらく告知不足から想定より接続数がだいぶ少なかったと見られるため。

やりたい所

まとめ

TechConf 2017 Wi-Fi の裏側についてご紹介しました。

参考

他にもカンファレンス Wi-Fi 運用について下記リンクが参考になると思います / 参考にさせて頂きました。

*1:VLAN は使えなくてもいいと思うけれど、まあこれができるAPはだいたい 802.1q 対応している

*2:会場によっては養生不可なので注意

*3:DD-WRT とかでも出来る…のだろうか。やったことない。

*4:正確に言うと、白金台オフィス時代の機材の残り

*5:スタンドとしても便利ですが、AP の電波出力の傾向を微調整するのにも便利。

*6:次の機会があるか分からないけれど、あった時に思い出すの困るのでちゃんと描いた。

*7:結局 DNS しか使わなかったけれど

*8:なお、public IP を付与していました。NAPT 配下に置かず直接再帰クエリをさせるのは DNS spoofing 防止につながるためです。

*9:なお、Client Load Balancing は過去に社内でトラブルが発生したため利用していませんでした。

投稿日：January 26th 2017

元記事：http://techlife.cookpad.com/entry/2017/01/26/120222

– PR –