運用自動化のためにネットワーク機器に求めるもの

12月1日のNetOpsCoding Advent Calender 2015の記事です。

NetOpsCodingは、ネットワークインフラにおける運用を自動化した事例や システム開発の知見、有用なツールなどを共有する勉強会です。2015年10月30日に第一回目の勉強会「NetOpsCoding #1」を開催しました。

運用自動化のためにネットワーク機器に求めるもの

ネットワーク運用を自動化しなければならないということは、もはや言うまでもないことだと思います。自分たちのネットワークサービスをソフトウェア制御で提供しようと思った場合に大きな壁になるのが、ネットワーク機器を外部のソフトウェアから制御する方法です。

ネットワーク機器の制御には大きく分けて次のような項目があるかと思います。

• 情報取得 (show系コマンド)
• 設定投入 (conf t)
• アラート (syslog, SNMP trap)

これらの制御を外部のソフトウェアから行おうと思った場合に、どういう機能がネットワーク機器にあれば嬉しいのかを、ネットワーク運用者かつ自動化ソフトウェア開発者の立場から書いてみたいと思います。

運用自動化を目指すネットワーク運用者の目的は綺麗なコードを書くことではありません。一番大事なものはお客さまや自分たちのコンテンツのトラフィックです。そのため自動化にあたっては多少コードが汚くなったとしても 安全なソフトウェアを書くことが第一 です。

ちなみにここで言うネットワーク機器というのはCisco, Juniper, Brocade, Huawei, Alcatelなどのキャリア・DC向けのルータやスイッチを中心に考えていますが、あまり標準化が進んでいないPXCやWDMなどの機器も念頭に置いています。

全機能にアクセスできる統一的手段

APIとかNETCONFやSNMPとか対応していても、サービスに必要な全ての機能にアクセスできなければ意味がありません。 結局はtelnet/sshしてCLIから操作する羽目になりNet::Telnet最強説の暗黒面に足を踏み出すことになります。

例えば、インターフェイスの設定はNETCONFでできるけど、リンクアグリゲーションの設定はNETCONFだとできない。インターフェイスのUp/DownはSNMPで取得できるけど、LACP BlockedのステートはSNMPで取得できない。こういった状況にある場合は結局のところtelnet/sshしなくてはいけなくなります。

１つの種類の機器に対して複数の手段での操作を行う必要があると、それだけ検証の工数が倍増していくだけでなく、バグを踏むリスクが増えるので非常に辛いです。例えばSNMPでこのMIBを叩くとrebootするとかいうバグを見たことがある方は多いかと思います。逆に言えばメーカー間や機種間で共通したプロトコルやアクセス手段は必要ありません。実装が違うためどのみち検証工数はかかりますし、バグはそれぞれ存在するからです。

独自APIでも何でも構いません、その機器が提供している全ての機能に同じ方法でアクセスできる手段を提供してください。

さもなければ我々はtelnet/sshの闇から抜け出すことはできないでしょう。

コマンドの実行結果をJSON形式で必ず返す

残念ながらtelnetでCLIからコマンドを実行する必要が出てきた場合に、次に困ることが実行結果の解釈です。ただしこの項目に関してはAPIも含めて全ての制御方式に当てはまることです。

show系コマンド

show系のコマンドを打った時にその結果をパースして必要な箇所を抜き出す必要があります。そしてこの表示フォーマットは人間には読みやすいですが、機械処理しようとすると非常に厄介なフォーマットになっている場合がほとんどです。また、バージョンによって表示フォーマットが変わっている場合、バージョンごとに応じたパーサを用意する必要があります。さらに、特殊な条件で表示結果が変わる場合、例えば「この機能を有効にしていたら表示にこの行が追加される」みたいなケースで、知らずに機能を有効化してしまってパーサが死ぬみたいなことが起きると悲惨です。

人間用の表示フォーマットと機械処理用のJSONフォーマットの２つの表示フォーマットに対応してください。

JUNOSでは show ... | display xml でXML形式で出力できるため非常にありがたいです。

config系コマンド

conf tしてからコンフィグ系のコマンドを実行した時、コマンドが成功た場合は結果は表示されず、コマンドが失敗した場合は何か文章が表示されることが多いかと思います。表示があったら失敗、なかったら成功、と判定しようとした時に厄介なのがwarningです。たとえば「rebootが必要です」みたいな警告が表示されるコマンドがあります。この場合設定の投入は成功していますが、表示はあります。こうしたものをいちいち場合分けして判断して対応する労力は大変です。

成功・失敗などのコマンド実行結果や、付随するwarningなどが構造化されたデータとして必ず返ってくるようにしてください。

階層移動系コマンド

Cisco系のCLIで設定する場合はinterface ...など階層を移動するようなコマンドを打つ必要があります。自動設定の時に怖いのが、例えば「誤ったインターフェイスに入ってshutdownしてしまう」といった階層移動ミスです。

GigabitEthernet 1/10 に入るつもりが、コマンドを流しこんだ際に最後の 0 がバッファ溢れで落ちて奇跡的に GigabitEthernet 1/1 に入ってしまって、そこでshutdownを打ってしまうと大惨事です。

１行程度のコマンドであればこのようなことは起きないとは思いますが、大量のコマンドを一度に流し込んだ場合にバッファが溢れる機器は実際にあるため、実装する側としては流し込まんだコマンドでバッファ溢れが起きていないか確認する必要があります。

階層移動のコマンドを打った場合も必ずその結果に移動先の階層の情報を含めて返して、対象の階層に確実に移動できたかどうかを確認できるようにしてください。

本当はJUNOSのset文のように階層はあるけれども階層に入らずに設定が行えるような仕組みになっていると嬉しいです。ターミナルのプロンプトに入ったインターフェイス名が表示される機器だとまだマシです。

トランザクション

先ほどの話は設定の際も安全性のために１つ１つコマンドを入れて結果を確認するという話でした。でもそれをやると時間がかかってしまうので、できれば設定をひとかたまりで投入できると嬉しいです。

このように複数の設定を同時に設定しようとした場合に怖いのが、途中のコマンドで失敗する場合です。失敗したコマンドの前に投入したコマンドが残っていても大丈夫な場合もありますが、できれば消しておきたいです。

ひとかたまりの設定を投入した時に途中で失敗したら、そもそも設定を投入する前の状態にロールバックできるような、トランザクションの機能を実装してください。

JUNOSやIOS-XRのcommitの機能がこれにあたります。IOSやIOSライクな機器ではできません。

おかしなコンフィグを通さずにエラーで返す

なるべくそのようなことは起きないように設計・実装するのですが、例えば「存在しないaccess-listを設定する」といったことが起きてしまった時に大惨事にならないようになっていると嬉しいです。この例の場合、機器の挙動は「全てpermit」「全て暗黙のdeny」などメーカによって異なりますが、自動設定の観点からはエラーを返すという挙動になっていると嬉しいです。

グラマーが正しくてもセマンティクスがおかしい設定が投入された時にはエラーを返すようにしてください。

コンフィグをテキストで渡してload

ネットワーク運用自動化の初期の段階として、データベースとテンプレートを用いてコンフィグを全文生成するという段階があります。このコンフィグ全文から１つ前の全文との差分を作成し、適切に機器に投入する機能を実装することは非常に難しいです。このような場合にコンフィグ全文を送って今の状態との差分をネットワーク機器側で適切に抽出して適用してくれると嬉しいです。

コンフィグ全文をファイルで送ってreloadすることで差分を適切に適用する機能を実装してください。

JUNOSではload overrideでできます。

またコンフィグの投入方式として、コマンドをscpなどでファイル転送して、ファイルから読み込みできるようにすると、telnetでのバッファ溢れなどの悲劇が防げるので嬉しいです。

投入するコマンドをファイルで送ってloadすることで設定投入できる機能を実装してください。

JUNOSではload setでできます。

デスクリプションの変更が他の設定に影響を与えないようにする

自動化を可能にするためにdescriptionの命名規則を制定して、descriptionを書き直す作業が発生することがあります。たとえばLAGのインターフェイス名にdescriptionが含まれているような機器の場合、descriptionを変更するためには一度LAGを解体する必要がある、つまりトラフィック影響があるわけです。本来description変更はトラフィック影響が無い作業であるべきですので、そのようになっていると嬉しいです。もしくはそのようになっていたとしても、名前部分のreplaceが効いたり、atomicにLAGの解体・構築ができてトラフィックに影響がないような仕組みになっていれば十分です。

description変更がトラフィックに影響を与えないようにコンフィグを設計してください。

すべてのものに一意の型番をつける

モジュール型のネットワーク機器のラインカードモジュールやファブリックモジュール、ひいてはファンモジュールや電源モジュールなど、オブジェクトとして存在するものに対しては一意の型番を付与してください。メーカ側でそれらが決まっている場合、非常に楽になります。また、それらの型番と同じ文字列がshow系のコマンドで表示されるようにしてください。ただ、型番に括弧()を入れたりするのはやめてください…

ネットワーク機器を構成するすべてのものに一意の型番を付けてください。

ある機器のあるモジュールではシャーシサイズによって別のモジュールになっているにもかかわらず、機器の内部では同じ型番で扱われていたりします。こうなるとデータベース上でのモジュールの識別子を、メーカが決めた型番や機器内部で扱われている文字列とは別のものにする必要が発生します。こういったモジュールが１つ存在するだけで、全てのモジュールに対して「識別用の型番」と「設定用の型番」の２つの型番を管理する必要が生じます。これは避けたいです。

違うものに同じ型番を絶対につけないでください。

機械処理可能で十分な情報が含まれたプッシュ型通知

Link Down/UpやBGP Up/Downなどのイベントに自動で対応したり、集計・蓄積しようとしようと思うと、プッシュ型通知の機能が必要になります。この機能はsyslogやSNMP Trapとして存在します。

ネットワーク運用自動化の際にこれらのプッシュ型通知機能に求められるのは次の要件です。

• データが構造化されていること
• 対象を一意に特定するための情報が含まれていること

データが構造化された通知

syslogは人間に読みやすい文字列です。フォーマットがメーカでバラバラですし、同じ機器でもバージョンやログの種別によってフォーマットがバラバラになっています。syslogから情報を得るためには正規表現でマッチングすることが多いかと思います。この時に正規表現で上手くマッチングできないようなログがあると非常に厄介になります。JSONなどのデータ構造で送ることができれば機械処理は非常にやりやすくなります。

特定の宛先にはJSONフォーマットで送ることができるような機能があると嬉しいです。

Dec 01 00:00:00 INFO router01 GigabitEthernet0/1 Link Down (remote fault)

といったsyslogは人間には見やすいかもしれませんが、機械処理するのは面倒です。次のようなJSONフォーマットで出力できると非常に楽です。

{"hostname":"router01","hostaddr":"10.20.30.40","datetime":"2015-12-01 00:00:00 +0900","priorty":"info","event":"Link Down","detail":{"ifIndex":"1","ifDescr":"GigabitEthernet0/1","description":"AS65500","reason":"Remote Fault"}}

これはあくまでも例で、共通部分に関しては色々なメーカの機器でスキーマを揃えたほうが良いので、標準化してみたいと思います。

通知をJSONフォーマットで送ることができるような機能を実装してください。そして全てのアラートのスキーマを公開してください

SNMP Trapは構造化された通知です。MIBによりスキーマが定義されています。しかしバイナリフォーマットでありスキーマの解釈にはMIBファイルの読み込みが必要なので、スクリプトから扱うには敷居が高く、結局snmptrapdを使ってsyslogに変換して扱う状況が見られます。私はSNMP Trapをまだ上手く扱えていないので、SNMP Trapの可能性に言及することはできませんが、上手く使えば良い通知になるのではないでしょうか。

WDMなどの製品ではsyslogには対応しておらず、SNMP Trapのみに対応しているという場合が多いです。

対象を一意に特定するための情報が含まれた通知

アラートを使って何かを行いたいと思うと、その対象を一意に特定する情報が必要です。この時に単にID的な要素を含むよりかは、ユーザが決めることができるdescriptionなどの要素が含まれていると非常に運用が楽になります。

さきほどのsyslogの例だと

Dec 01 00:00:00 INFO router01 GigabitEthernet0/1 (AS65500) Link Down (remote fault)

このようにdescriptionが入っていると、desciptionを使った分類や、イベントのトリガーが可能になります。そうでなければインターフェイス名やifIndex値からdescriptionなどを逆引きする仕組みを実装する必要に迫られます。例えばインターフェイスが変わったとしても、AS65500のためにアラートを蓄積するシステムの構築が容易になります。この例だとGigabitEthernet0/1で対象を一意に特定できますが、ifIndexのほうが一意性は高い場合もあります。また、コンフィグを行う際に使用するインターフェイス名と、ifDescrの内容が違う場合もあります。この場合syslogに記載されている内容が役に立たない場合もあります。SNMP TrapでifIndexしか含まれていないものがあり、それを人間が識別可能な文字列に直すために16進数演算を含む複雑な処理をようするようなものもあります。

通知には対象が容易に特定可能になる情報を含めてください。通知には1.一意のID、2.人間にとって可読性の高い識別子、3.ユーザ定義のdescriptionを含めさせてください

ちなみにUDPだとパケット長問題やパケロス問題が出てくるので、TCPにせざるを得ないかなぁと感じています。そういう点からも TCPでsyslogを送ることができる という機能もあると嬉しいです。できないネットワーク機器はそれなりに多いです。

API Firstな設計

なんだかんだいって、REST APIが欲しいです。でも人間のオペレーションにはネットワーク機器のCLIは最高です。Linuxサーバで?を押してがっかりしたことが何度合ったか。WDM機器に多く見られるNMSもネイティブGUIやWebGUIで良く出来ているものがあります。しかしそれらのCLIやGUIのインターフェイスは全てAPIのラッパーになっていて、そのAPIはユーザに対しても開かれている方が嬉しいです。そうすることで運用者が独自に運用に必要なシステムを作ることが可能になります。

全ての機能をAPIとして実装して、そのラッパーとしてCLIやGUIを提供してください。そしてそのAPIは運用者が利用できるようにしてください

まとめ

かなり長くなってしまいましたが、ネットワーク運用者視点で自動化のためにどのような機能があったら嬉しいかをまとめてみました。途中特定のメーカの賛美に思われる部分もありましたが、先進的な機能を実装しているので、やはり紹介しないわけにはいきません。

この記事が、少しでもネットワーク機器を開発されるメーカの皆様の助けになり、自動化しやすいネットワーク機器がたくさん世に送られることを願います。

CEDEC-Net 2015 で IPv6 の会場ネットワークを提供してきました

ゲーム開発者の祭典CEDEC

毎年８月末から９月頭頃に開催されるゲーム開発者のためのカンファレンスです。今年もパシフィコ横浜で３日間に渡って開催されました。昨年実績で１日あたり約5000名が来場します。

来場者のための無線ネットワーク「CEDEC-Net」

このCEDECではまともなインターネット環境が提供されていませんでした。5000名が来場するイベントに対して会場デフォルトのネットワークでは、無線アクセスポイントのスペックやDHCPのリース数、NAPTのセッション数などリソースが足りず、使えないネットワークになっていました。

これに危機感を覚えたコナミデジタルエンタテインメントの佐藤さんが日本ネットワークオペレーターズグループ（JANOG）に相談を持ちかけ、発足したのがCEDEC-Netです。JANOGでは年２回開催される数百人規模のカンファレンスで無線ネットワークを提供しています。蓄積されたノウハウもありますし、何より本職の人たちです。CEDEC-NetはJANOGからのメンバーに加え、ゲーム業界からネットワークに興味のあるエンジニアが集まって、CEDECでの安定かつ挑戦的な会場無線ネットワークの構築を目的として結成されました。

IPv6がテーマのCEDEC-Net 2015

昨年のCEDEC-Netのテーマは「CGN」でした。IPv4枯渇に立ち向かう技術の中で特にCGN(Carrier Grade NAT)に注目し、IPv4インターネットの変化を来場者にアピールしました。

今年は６月末に行った発足ミーティングで今年のCEDEC-Netのテーマを「IPv6」に決めました。６月のWWDC2015でApple社がiOSアプリの承認条件にIPv6対応を加えたからです。CEDEC-NetでAppleの推奨するIPv6オンリーかつNAT64+DNS64の環境を提供することで、ゲーム開発者にIPv6対応の必要性を訴えたいと考えました。一方で来場者に使えるネットワークを提供する必要があるので、IPv4のあるネットワークも提供することにしました。対外接続にはIPv6 IPoEの回線を利用し、その上でIPv4・IPv6移行共存技術を利用することも決めました。

CEDEC-Netは安定したネットワークを提供することだけを目的とするのではなく、ゲーム業界へのメッセージ性やNOCメンバーの技術向上を目的としています。そのために我々が決断したことはIPv6オンリーネットワークをデフォルトのネットワークとして、そして、IPv6オンリーであることをアピールせずに提供するということです。

私は過去のカンファレンス経験でIPv6オンリーネットワークの構築や利用を経験していますが、あくまでそのようにアナウンスした上で、利用する人もネットワーク業界のエンジニアでした。業界の人でない参加者に、何も説明せずにIPv6オンリーネットワークを使わせるという試みは初めてでした。つながらないという報告や相談が来ることは目に見えているのですが、それをアピールチャンスだと捉えました。

CEDEC会場のwifi、iPhone5は繋がるけど、NEXUS5では繋がらない。IPアドレス取得中のまま待てど暮らせど先に進まない。何故だ。

— oyapiro (@oyapiro) 2015, 8月 27

CEDEC-Net 2015からのメッセージ

SSID: cedec-netとして提供したIPv6オンリーネットワークは「この無線ネットワークで動作しないアプリはAppleの審査に通らないかもしれない」というインパクトでゲーム業界に伝わりました。

#cedec2015 iOS9アプリはDNS64+NAT64環境下で動くことが必須とAppleがアナウンスしています。そこで今年のcedec-netはDNS64+NAT64構成で提供しています。iOSを開発中/使用中の方はぜひいろいろなアプリをお試し下さい。

— cedecnet (@cedecnet) 2015, 8月 26

CEDEC会場のWiFiはIPv6らしく、各社のスマホゲームが試されている…

— うえした (@ueshita) 2015, 8月 28

CEDEC-Netでアプリが動かない事案が何件か起きてるな。動かないアプリがあるイベントWi-Fiというのもどうなの、という気がしなくもないけど、開発者イベントで「ここで動かないアプリはApple審査通らないよ」という警告を出すのもそれはそれで正しいと思う。#cedec2015

— ヤレヤレ君 (@yareyare_kun) 2015, 8月 28

 裏で色々聞いた話では大手ゲーム会社でもcedec-netを利用して自社アプリの動作確認を行う指令や翌週すぐにNAT64+DNS64の環境を構築するような指令が出たとか出なかったとか。

NOCチームで今回のネットワークについて講演する時間を頂きましたが、100人程度の部屋が満席になりました。この発表はなんとGAME Watchさんにも記事にしていただきました。GAME Watchというゲーム専門媒体にIPv6やNAT64などのネットワークの話が掲載されるというのも想像だにしなかった事態でした。

「CEDEC-Net 2015」がiOSアプリ開発者に警鐘を鳴らす！ - GAME Watch

これまで色々なネットワーク業界でIPv6に対する検証や啓蒙活動が行われてきましたが、これほど他の業界にダイレクトに伝わった瞬間を目撃するのは初めてです。我々がいきなり何か達成したわけではなく、今までのいろいろな人の地道な努力や積み重ねた知見があって今回我々がこのようなネットワークを提供できたので、ネットワーク業界の努力が実って繋がった思うととても感慨深いです。

IPv6 IPoEとDS-Liteの対外接続

対外接続の選定

対外接続にはIPv6 IPoEのサービスである、インターネットマルチフィード社のtransixサービスを利用しました。自社サービスなので無償提供がしやすかったというのがありますが、技術的にもテーマ的にも適しているということで選定しています。

IPv6 IPoEでは本来閉域網であったフレッツ回線に割り当てられるIPv6アドレスでそのままインターネットに抜けられることが特徴です。MTU1500でトンネルオーバーヘッドもNATもないので、ゲーム通信には最適な回線だと言えます。

ちなみにtransixですが、IIJmioのFiberAccess/NFというサービスを申し込むと利用できます。僕の自宅もこれです。Google(AS15169)までIPv6で4msと快適です（ステマ）。

IIJmio:FiberAccess/NF概要

IPv4の接続性には同社で提供しているDS-Liteを利用しています。DS-Lite(Dual-Stack Lite)は家庭側機器(CPE)であるB4とISP側機器であるAFTRの間で、IPv4 over IPv6トンネルを張ってIPv4パケットを運び、AFTRでNAPTを行い、複数の家庭でグローバルIPv4アドレスを共有する技術です。CPEでNAPTを行うMAP-Eなどに比べると、ISP側機器の負荷が高くスケールしにくいのですが、IPv4アドレスを柔軟に使えたり、CPEの実装負荷が軽いという利点があります。あと名前が某社の携帯端末みたいなのでゲーム業界のネットワークに使うのにピッタリです。

B4にはYAMAHAの新製品であるRTX1210とCiscoのASR1001を日を分けて使いました。RTX1210は配下のYAMAHAのスイッチも一括管理できるルータです。

DS-Liteの設計

DS-Liteは1IPアドレス＝65536ポートを複数の家庭で共有する技術のため、本来こういった数百数千のクライアントを収容するネットワークに用いる技術ではありませんが、同社に特別な回線を用意してもらい65536ポートをフルで使えるようにして頂きました。1端末あたり64ポートを見込んでいたので1024端末まではこれでサーポートできます。昨年は1200端末が同時接続していたので、この設計では足りません。しかしポートが枯渇して通信できなくなる事自体がIPv4をこのまま使い続けるとまずいというアピールになるのではと考えました。とはいえ読みが外れて本当に使えないレベルでポート足りなくなると問題なので、もう１回線用意しておいて、緊急時はトラフィックを分散できるように設計してありました。

２日目の午後４時頃に1400端末が接続しているタイミングで、予定通りNAPTのプール数が枯渇しました。上のグラフが16時過ぎに65kあたりに達しているのが分かるかと思います。プールの枯渇なのでプール内でのポートの使い回しがありますが、一部の通信がポート枯渇で通信できていなかったものと思われます。17時頃に別回線にトラフィックを分散した後は70k近くまでポートを使っているのがわかります。1端末あたり約50ポート程度を見積もっておくと良いという知見が得られました。

NAT64+DNS64の構築

今回NAT64に用いたのはA10 NetworksのvThunderという仮想アプライアンスです。CEDEC-Netには無償でお貸し出しいただきました。コンフィグ例はWebの記事に動作含めてまとまっていますのでこの通りにやれば動くものができます。

NAT64でIPv6端末をIPv4サーバにつなげよう（1/2） - ＠IT

DNS64は同じvThunderでもできるのですが、今回はBINDを使いました。Cisco ASR1001でもNAT64をやってみようという計画があったのですが、ASRではDNS64ができないので、DNS64は切り離しておこうという計画によるものです。

NAT64についてはググればLinuxやBSDの実装やコンフィグ例が出てくると思います。

CEDECで使ったコンフィグについてはいずれ機会と需要があればどこかにまとめてみたいと思います。

IPv6オンリーネットワークへの接続

今年の同時最大接続数は1695でした。この結果は５分間隔のポーリングですが、リアルタイムの無線管理のツールの結果では1713端末の同時接続が確認されたようです。

#cedec2015 14:54:13 に 1713端末の同時接続を確認しました! pic.twitter.com/javpt8k0Ec

— cedecnet (@cedecnet) 2015, 8月 28

 昨年の1200端末からすると1.5倍の端末に接続していただきました。今年はA0版のポスターまで作って頂くほどの広報の努力もあり、そしてCEDECのWiFiは使えるという認識が徐々に参加者の間に広まってきたのだと思います。

パシフィコ横浜 #CEDEC2015 初日に到着しました。テザリング禁止令が発令中なう pic.twitter.com/xWqsfcnRVm

— Yoshinori (y0sh1) (@takesako) 2015, 8月 26

 同時接続数より重要なことがこのグラフから分かります。それは実に60%の端末がIPv6オンリーネットワークであるSSID:cedec-netに接続していたということです。

ここで無線ネットワークの端末のベンダーコードの統計を見ていただきたいのですが、65%をAppleの端末が占めています。我々の検証の結果、MacもiPhoneも、Apple端末自身はIPv6オンリーネットワーク上でも完璧に動作することがわかっています。残念ながらSSIDごとのベンダーコードを記録していなかったので確証はないのですが、この60%がIPv6オンリーネットワークを使い続けたという結果は、Appleの端末によるものではないかと推測されます。iOSの審査要件にIPv6対応を入れるだけのことはあります。

IPv6トラフィックの割合

NAT64の外側で取得したフローにもとづくデータです。Download, UploadともにIPv6トラフィック(bps)の割合が25%程度になっています。

無線ネットワークの運用

アクセスポイントの配置設計

CEDECの無線ネットワーク設計で特徴的なのがアクセスポイントの配置計画です。通常のIT系カンファレンスであれば来場者がPCを開くホール内や部屋内にアクセスポイントを集中的に配置し、廊下はコネクションが切れない程度の密度で配置します。CEDECでは真逆の傾向にあります。

これは２日目のトラフィックの様子ですが、このピークが立っている時間帯というのは、各セッションの開始直前の時間帯に合致します。

CEDECでは講演開始前に講演部屋の前に入場のための行列を形成します。この入場待ちの時間に廊下のアクセスポイントを通して多くのトラフィックが流れます。みなさん待ち時間は暇なようです。一方でみなさんまじめに講演を聞いているからなのか、講演時間中はあまりトラフィックは流れません。そのため部屋の中のアクセスポイントの負荷はそれほど高くありません。たまに小部屋に超人気セッションが押し込まれることがありますが、その時は非常にヤバイです。特に今年は竹迫さんのSECCONセッションがヤバかったです。

この独特の傾向からCEDEC-Netでは通常のカンファレンスとは異なり廊下やロビーのアクセスポイントを多めに配置しています。特に１階のホール前については通常であれば２、３個のアクセスポイントで十分ですが、非常に長い待ち行列が形成されるため、６個のアクセスポイントを配置してアクセスポイントあたりの接続端末数を抑えています。これは昨年の経験を活かした設計です。

無線APへの給電にはPoEスイッチを使いました。壁から出ているLANジャックはパシフィコ横浜の普通のスイッチと接続されているため、部屋の中でPoEスイッチを噛ませる必要がありました。そのため結構な数のスイッチが必要でしたがYAMAHA様にSWX2200-8PoEというゲートウェイルータのRTX1210から一括管理できる８ポートのPoEスイッチをお貸し出しいただきました。

無線ネットワークの監視

昨年のCEDECでcisco-wlc-monitorというCLIツールを作成したのですが、今年はNOCに展示ブースに何かを出したい、しかもFirefoxのタブ切り替えで見せるものを切り替えていく、という話になったので、Webブラウザから監視できるツールを作りました。10秒ごとにアクセスポイントの状態やトラフィックなどの統計情報が更新されていきます。Rubyで書いたsinatraのAPIと、websocketのデーモンがバックエンドで動いています。

動かすことを目標に前日に１晩で作ったものなのでコードが非常に汚いのですが、時間があれば整理して他のカンファレンスネットワークの皆様にも使っていただける形で公表したいと思います。

総評

書きたいことはやまほどあるのですが、そろそろまとめます。今年のCEDEC-Netは非常にチャレンジングかつインパクトのある取り組みができたと思います。昨年から引き続きNOCをやってくれたメンバーや、今年から新しくNOCに入ってくれたメンバー、それぞれの活躍おかげです。ありがとうございました。

これからもネットワーク業界とゲーム業界の実践交流の場として盛り上がっていくと思いますので、NOCチームに興味のある方は遠慮なく連絡ください。

関連資料

私がNOCチームの講演で使用したスライドはこちらです。

CEDEC-Net 2015 テクニカルレビュー from Yuya Rin

www.slideshare.net

CEDEC-Netに対するみなさんの反応はこちらにまとまっているのでぜひご覧ください。

https://twitter.com/cedecnet/favorites

CEDEC公式サイトに掲載されたネットワークの案内にもまとまった情報があります。

cedec.cesa.or.jp

iOS9で必要な対応はこちらの記事を参照ください。

qiita.com