1,000人を支えたネットワークインフラ

今年9月に開催されたPerl開発者のためのイベントYAPC::Asia Tokyo 2013⁠」⁠。過去最大となるのべ1,000名を超える参加者が集まりました。非常に高い品質のセッションが数多く見られ、gihyo.jp読者の皆さんの中にも会場まで足を運んだ方がいらっしゃるのではないでしょうか。会場では、快適なネットワーク環境が用意され、発表者から聴講者までインターネットを十分に活用できたかと思います。

ここでは、その来場者に向けたインターネット接続サービス提供を実現した専用の会場ネットワーク環境の構築について、準備から当日の模様までを紹介します。

リアルの熱気とネットの熱気の融合が最近のイベントのトレンド

昨今、さまざまなIT系のカンファレンスや勉強会が開催されていますが、参加者の共通的な特徴として、インターネット接続されたデバイスを使いながら参加することが挙げられます。

参加者が数十名程度であれば、各々のポータブルWi-Fi機器を使ってインターネットへ接続することが出来ますが、数百名となると話は違ってきます。ひとつの空間で、数百もの人が同時にポータブルWi-Fiを使用すると、あっという間に無線LANの周波数帯が枯渇してしまい、接続速度が低下するどころか、誰もが自分のポータブルWi-Fiへ無線LAN接続出来ないという事態に陥ってしまうでしょう。

YAPC::Asia Tokyo（以降YAPC）はIT系カンファレンスの中でも超大型のカンファレンスで、今回は参加者数が1,000人を超えています。しかも参加者の多くはギークと呼ばれるような人たち。みな普段からどっぷりインターネットを使っているインターネットのヘビーユーザなのです。

そんなヘビーユーザ1,000人のインターネット利用を支える会場ネットワーク構築において、どのように設計、構築、運用を行ったか、また新たな試みとして何を行ったかについて、まとめてみました。

YAPCネットワークチーム結成

YAPCの会場ネットワーク構想は、6月ごろから練り始めました。そこから会場の現況調査や交渉などを繰り返し、会場ネットワークを実現できる目処がついてGoを出せたのは、なんとYAPC開催日の2週間前でした。当初のチームの人数は2名。しかし、これだけの規模になると一緒にやってくれる協力者が必要になります。そこでIT系カンファレンスでネットワークサービスを提供しているJANOGミーティングのスタッフ経験者と、Lightweight Language カンファレンスのLLNOCチームに声をかけ最終的には13名からなるYAPCネットワークチーム（@yapcnwteam）が結成されました。

本番の2週間前にメンバー全員でのキックオフミーティングを行いそこから怒涛の勢いで方針の策定、ネットワーク自体や運用監視システムの設計機器調達、本番前のシステム構築と動作検証をするホットステージ、会場への搬入、会場での設営、本番前の最終確認を行っていきイベント当日を迎えました。

ネットワーク設計の方針

会場ネットワークを提供するにあたり、どこまで作り込むかの方針決定は重要です。ネットワークシステムというのは作り込もうとすれば、いくらでも情熱をかけられてしまいます。ゴールや優先順位を確定させておかないと、それぞれのネットワークチームメンバが趣味……じゃなくて得意な分野に没頭してしまい、全体の工程を見落としがちになってしまうからです。このため、どこまで手を広げるか、優先順位は何かの認識を徹底しました。

これを踏まえ、最優先事項としてネットワークがつながることから始め、次に円滑なネットワーク運用のための機器管理と運用情報の可視化、そして来場者を対象とした会場ネットワーク接続者のセキュリティチェック、余力があれば行うこととして、各種データの集計、ネットワーク機能のクラウド化など、実験的な取り組みを行うこととしました。

このネットワーク機能のクラウド化とは、DHCPサーバ、DNSサーバ、ルータ機能などを、さくらインターネット上のクラウドに構築し、すべての機能をさくらインターネット経由で行ってしまおうというものです。これが成功すれば、インターネット上のサーバにVPNによるトンネルを設定できれば、今後会場ネットワーク構築時に会場内へ物理サーバや、高価なルータが必要なくなるという実績を作ることができると考えたのです。

ネットワーク提供場所について

YAPCは4つの部屋を利用する形でプログラム構成されていました。実はYAPC運営側からは「メインの藤原洋記念ホールのみ、ネットワークがあれば良い。その他はなくてもよい」とのお話をいただいていました。

ネットワークの提供場所が少なければ、ネットワークチームの負荷は少ないと思われるかもしれませんが、ホールのみの提供の場合、来場者はホール以外の場所へ移動した際にポータブルWi-Fiの電源を入れて使用、そのまま電源を切らずにホールに戻ってくることになるでしょう。その際ホール内の無線LAN環境に悪影響が出てくるリスクを検討しなければなりません。

このことから、会場全体にネットワークを提供するほうが、ネットワークチームに、また来場者の皆様に利点があるのです。この検討結果から、YAPC会場すべての部屋にて安定したネットワークを提供することを目標として設計を始めました。

ネットワークの物理構成

物理的な設計としてはすべての部屋にスイッチを置き、そのスイッチを起点として無線AP（アクセスポイント）機器を接続するという一般的な形を取りました。装置間の配線は、一般的なホール等を利用する場合は機器を設置するすべての場所へケーブルを敷設する必要があり、長いUTPもしくは光ケーブルの用意や、それらを養生するなどの作業が必要になりますが、今回は会場既設のUTPや光ケーブルの一部を借りることで[1]⁠、ケーブルを引き回す距離を大幅に削減することができました。

しかしそのかわり、配線の一部ではメディアコンバータの代わりとして光モジュールを搭載できるスイッチを利用していた箇所もありました。

ネットワークの論理構成

レイヤ2、3の設計は、参加者用のセグメントを4つ、サーバ用、管理用の最低でも6つのセグメントを作る必要があり、VLANを用いて設計を行いました。参加者向けのセグメントは1つで良いのではと思われる方もいるかもしれませんが、今回4つのセグメントに分けた理由は2つあります。

1つ目の理由として、最大で2,000ユニーク端末の接続を想定したためです。YAPCでは1,000人ほどの参加者を見込んでいました。PC＋スマホなど、1人で複数端末を利用するユーザも一般化してきているため、ユーザ数×2として算出した最大2,000ユニーク端末と想定しました。

しかし、2,000端末を1つのセグメントで同時に通信させることはあまり現実的ではありません。そのため、セグメントを分けてそれぞれのセグメントへ端末数を分散させたいと考えました。同じ部屋の中で違うセグメントに切り替わると通信が途切れる可能性があるため、距離的に近い3会場（藤原洋記念ホール多目的教室2と3）は同一のセグメントに収容し、離れているイベントホールを別セグメントに収容することとしました。

2つ目の理由は、無線AP機器の仕様によりSSIDごとに1つのVLANを割り当てる必要があったためです。yapc2013とyapc2013-gの2つのSSIDをブロードキャストするためには2つのVLANが必要でした。

その結果2つのVLAN×2つのセグメントで計4つの参加者向けセグメントとしました。

また、通常の利用では会場ネットワーク内で折り返す参加者間の通信は少ないと想定し、そのような通信はさせないように設計しました。そのため、管理用途以外のスイッチではisolation（アラクサラネットワークスの機能。Cisco機器でいうところのswitchport mode protectedに相当）を設定し、ルータではフィルタを設定し運用を行っていました。

今回のアクセス回線はNTT東日本のフレッツ光ネクストで、インターネット接続にはIIJのサービスを利用しました。グローバルIPv4アドレスは1つとなり、その1つのグローバルIPv4アドレスを全員で共有するためにはNAPTを利用する必要があります。

しかし、通信事業者が利用するような装置でなければNATテーブルのエントリ数上限は通常数千から数万しかありませんし、変換の際に利用できるTCPやUDPのポート番号にも限りがあります。そのため、多くのユーザを収容するにはNATセッションタイマ（NATテーブルからIPアドレスとポートの変換エントリが消える時間）を短くする必要がでてきます。

しかし、短くしすぎるとユーザのセッションを維持し続けるような通信が途切れる可能性や、スマートフォンでは接続維持などのためにバッテリの持ちが悪くなることを考慮する必要があり、慎重に値を決めなくてはなりません。

YAPCではNAPTセッションタイマを30秒と設計し、あとは運用状況次第でタイマ値を変更することにしました。NAPTセッション数は装置収容条件の上限付近となるような設定もできますが、装置収容条件の50％前後に抑えておくことで突発的な負荷に対応することとしました。

実際の利用状況は10,000～25,000セッションであり、結局NATセッションタイマは30秒のまま運用しました。これは通常からするとかなり短い運用ですが、YAPCに参加され、実際に会場ネットワークを利用された皆様いかがでしたでしょうか。

サーバの冗長化について

2013年8月24日に開催された「LLまつり」というイベントでも、YAPCネットワークチームに参加したLLNOCチームが会場ネットワークの構築を担当しています。

• LLまつり

LLまつりの会場ネットワークでは重要なVMをいくつも乗せたPCがハードウェア的に故障し、会場での設営時に起動することができず、サービスの提供が大幅に遅れてしまいました。

• 会場ネットワーク提供の憂鬱

その失敗を踏まえて、今回はサーバを会場とさくらのクラウド上の2拠点に用意し、どちらかが壊れても大丈夫なように設計しました。

結果的には今回はサーバは壊れなかったので（そうそう壊れてたまるか！⁠）⁠、クラウド上のサーバのみでサービス提供を行いました。

クラウドを利用する利点は他にも色々あります。まずは前述のようなハードウェア障害にサービス提供が左右されませんし、そもそも物理サーバを用意する必要がありません。また、物理的なブツの移動が発生しませんので、本番直前まで設定をすることが可能ですし、撤収後にどこかのネットワークに接続し直さなくてもログなどを確認することが可能です。

しかし当日、クラウド事業者側での障害や、その事業者へのネットワーク経路に何らかの問題があった場合、そのサーバは使えなくなってしまいます。物理サーバであれば、そういった我々のコントロールできない部分での障害に巻き込まれる可能性は低くなります。

当初の計画では、トンネルを経由してIEEE802.1QのVLANタグを付けたまま、さくらのクラウド上のVMまで運び、VMでVLANをuntagするネットワークを実現したかったのですが、ホットステージの期間だけではうまく動かすことができず、YAPC当日までの時間もないため断念しました。そのため、今回は会場のVyattaとさくらのクラウド上のVyattaでトンネルを張り、サーバセグメントと管理セグメントをルーティングすることとしました。

また、今回NAPTは会場のルータで行いましたがNATテーブルのエントリ溢れ等が発生した場合はさくらのクラウド上のVMにコマンド1つで切り替えられるように用意をしていました。会場からさくらのクラウドまでの往復遅延時間は約20msのため、若干の遅延が発生する代わりにグローバルIPv4アドレスを複数利用することができるというメリットがありました。今回は先述の通りNATテーブルはまだ余裕があったため特に問題はなく、このコマンドを発動する事はありませんでしたが、NATタイマ長めで多くのユーザを収容する時には試してみたく考えています。

無線AP配置設計

藤原洋記念ホール

多目的教室2、3

無線APの配置は参加者の滞在する場所を予想して設計していきます。ここは後ろに立ち見が出そうだとか、昼休みに大勢の人が滞在しそうだとか、ノートPCを開いて休憩するに良さそうな場所だとか、自らが参加者になったつもりで参加者の流れを想像し、無線APごとの収容数を想定します。そこから、配線が実現可能であるか、危険性はないかなどを考慮して配置を決定していきます。よほど平坦な会場でない限り、下見なしで配置設計するのは困難です。

無線APのバンドあたり5GHz帯では最大収容数を50端末、厳しい条件となりそうな箇所でも70端末ほど、2.4GHz帯はチャネルのかぶりを避けられないため30～40端末程度を想定し配置していきます。

電波が遠くまで飛びすぎてしまうと条件の悪い通信が多く発生し電波状況が不安定になる原因となるため、いかにして遠くに飛ばし過ぎないか工夫する必要があります。家庭などでは、むしろ遠くに飛ばしたいことが多いですがカンファレンスなどで狭い場所にたくさんの端末が集まる場合はこのような工夫が必要になります。

5GHz帯は多くのチャネルが利用できますが、W53には気象レーダーとの干渉を防ぐためにレーダーの電波を検出すると通信を停止し回避動作を行うDFSがあり、悩ましいバンドです。窓際に近い場所に設置した無線APではこの回避動作による通信断が起こりやすいため、まず外からのレーダー電波が到達しにくいホールの奧の側からW53のチャネルを割り当てていき、窓際や入口が近い地点にはDFSのないW52のチャネルを優先して割り当てました。

無線LANのレート設定

無線LANは身近なEthernetと違い、限られた時間と空間を共有して通信が行われます。802.11a/b/gではそれぞれの端末ごとに1Mbps～54Mbps速度で変調されたデータがやりとりされます。54Mbps変調の端末であれば短時間でサクッとデータ転送が完了してすぐに空きになりますが、1Mbpsでチンタラとデータ送受信する端末が存在すると全体から見て時間のムダになります。非常に大ざっぱに言えば、54Mbps変調の端末であれば54台の通信が完了するのに1時間かかるとすると1Mbps変調では同じ1時間に1台しか通信できないのです。実際にはこのような単純計算のようにはいきませんが、遅い変調や条件の悪い通信があると収容できる台数が大幅に下がります。

そこで、遅いレートの通信は拒否し、少しでも通信条件が悪くなれば他の無線APへ積極的にローミングさせるようにします。ベーシックレートを54Mbpsとし、48Mbps、36Mbpsをサポートとしました。

また、一部の端末では54Mbpsのみでは接続できないケースがあるため、救済措置としてベーシックレートを36Mbpsくらいに遅く設定した無線APを少数用意します。遅い変調の無線APには接続が集中しやすいため、この無線APの設置場所は会場内で参加者の密度が低そうなところを選ぶべきでしょう。

この他、ローミング先がない無線AP（ホワイエなど）ではベーシックレートを11Mbpsほどまで下げ、本会場に支障が出ない範囲で送信出力を高めに設定してカバレッジを広くとります。

ベーシックレートを速く設定すると近くにある端末のみしか接続しなくなり、遅くすると遠くの端末も接続できるようになります。これにより、Autonomous無線APでも接続の偏りをある程度調整することが可能です。

電波を遠くに飛ばしすぎないためのコントロール方法としては、下表のような手法があります。

5GHzという高い周波数では、伝搬特性が可視光に似てきます。見渡せる範囲では遠くまで届きますが、壁や人体などを貫通しづらく障害物があると遠くまで届きません。そのため、高い位置に設置すると遠くまで飛びすぎてしまうことがあります。高さや角度が簡単に調整できる譜面台などに無線APを設置すると、現場でこれを簡単に調整でき非常に便利です。

無線LANは変調レートによって電波強度の下限が決まっており、電波が弱ければ遅いレートでしか接続できなくなります。これを利用して、遅いレートの通信を拒否することで弱い電波の通信を拒否し、遠くまで飛ばないようにします。

電波の飛びを調整するには送信出力が真っ先に浮かぶ方が多いかもしれませんが、上記の2つと比較するとコントロールしづらい印象があります。近距離の端末も条件が悪化し、予測しにくくなります。

YAPCの会場は既設の無線APで2.4GHz帯が非常に混雑していたため（ビーコンなどのマネジメントフレームだけでチャネル利用率が常時50％を超えるような状況⁠）⁠、いっそのこと2.4GHzの提供をやめようかとも考えました。しかし、たとえ多数の端末を安定して収容できなくともポータブルルータが乱立するより良いだろうとのことで推奨の802.11a（5GHz）に加えて、802.11g（2.4GHz）も提供を行いました。802.11aと比較してかなり少ない接続数ではありましたが、予想したほど不安定にはならず802.11gも利用できていたようです。

無線APの使用機材

無線APの無線機材は Cisco Aironet AIR-AP1252AGを4台, AIR-AP1242AGを15台、すべてWLC（ワイヤレスLANコントローラ）を利用しないAutonomousで運用しました。19台もの無線APを管理するにはWLCが利用できるとよいのですが、今回の無線APはスタッフが私物を持ち寄ったためAutonomousでの運用となりました。

Aironetなどの高性能な無線APをたくさん用意するのは容易でないと思われがちですが、実は802.11nに対応していないちょっと旧世代の無線APは中古市場で安価に流通しています。会場ネットワーク構築のようなケースでは、802.11nはあまり重要ではありません。ちょっと旧世代の無線APでも前述のレート設定や送信出力設定、VLAN設定、各種監視などはまったく問題なく使用可能ですし、パフォーマンスも充分です。

大規模なカンファレンスの会場ネットワーク構築を家電量販店で手に入る無線APだけで構築するのは難しいかもしれませんが、今回使用した旧世代の無線APのように最新の高価な機材でなくても、工夫次第でなんとかできるものです。

DHCPサーバ

DHCPサーバは、会場に置く物理サーバとさくらのクラウド上に構築しました。さくらのクラウド側をプライマリサーバとし会場側をサブとしました。プライマリに障害が起きたときには会場のサーバに機能を切り替える運用としました。

今回、ネットワークのセグメント数が多く、それぞれにインターフェースを持つことも大変なので、DHCPサーバはサーバセグメントと管理セグメントのみに接続し、DHCPのクエリはDHCPサーバが接続されたセグメントにリレーしました。

DHCPサーバソフトウェアにはisc-dhcpを利用しました。failover機能の利用を検討しましたが、払い出したアドレスをプライマリ・セカンダリ間で同期しているのではなく、プールの前半・後半に分けてそれぞれのサーバがプールとして持ち、死活監視の結果によって動作するサーバが切り替わるため、プールアドレス不足による払い出しができなくなることが予想されました。そのため、fallover機能は利用しませんでした。とくにトラブルもなくIPアドレスは常にさくらのクラウド側から払い出せていました。設営時の設定では用意したアドレスプールを使い切ってしまう可能性を考慮し、IPアドレス払い出し期間を短く8時間としていました。木曜日の夜と金曜日の午前中のIPアドレス払い出し状況を確認したところ、十分に余裕がありリース時間を長くしても問題なさそうと判断したため、2日間に設定しなおし運用しました。

DNSサーバ

名前解決用のDNSサーバもDHCPサーバと同様に2拠点（さくらのクラウド、会場）に構築し、さくらのクラウド側のサーバを利用しました。

DNSサーバのソフトウェアとしてはBINDが有名ですが、今回はUnboundを利用しました。Unboundは、オランダNLnet Labsのキャッシュ DNS 機能に特化したサーバソフトウェアです。シンプルな構造をしており、軽い、速い、設定が簡単、BINDより脆弱性が少ない、と良いことづくめです。FreeBSD 10RではBINDの代替として採用され話題になりましたね。

• Unbound本家
• 日本Unboundユーザ会
• Unboundの紹介

DNSサーバを会場ネットワーク内に提供する理由は大きく2つ挙げられます。1つは名前解決にかかるRTTを短縮できること、もう1つはNATテーブルエントリ数の節約のためです。

2つめの理由は地味に重要です。1枚のWebページを開くためにもDNS検索は多数発生しますので、これを全部NAPTしているとエントリ数を大量に消費します。DNS検索をNAPTせず折り返してやることで、NATテーブルのエントリ数消費を減らすことが可能です。

今回447万クエリの処理を行いましたが、ユニーククエリ数は16万でした。TTL値によって多少のズレはあるでしょうが、1/28程度の削減効果があったと言ってよいと思います。

ホットステージ

「ネットワークを提供します⁠」⁠ と宣言したからには、皆様の期待を裏切らない確実なインターネット接続の提供をするため、最大限の準備やテストを行います。YAPC開催当日に実際に用いるさまざまなネットワーク機器やサーバを本番同様に接続し、ひとつひとつ必要な確認を行います。サービス提供に必要な機能のチェックを人力でシステム的に行うので膨大なタスクが発生します。ですが、YAPCネットワークチーム（@yapcnwteam）スタッフは皆社会人であり、ましてやメインの業務としてYAPCネットワークチームをやっているわけでもなく、チームメンバの所属会社もバラバラ、勤務地はおろか、就業時間すら異なっています。この差を吸収するため、それぞれのメンバが自分の都合の良い時間帯に、都合の良い場所から作業できるような環境を整備する必要が出てきます。

そこで、YAPCネットワークチームの誰かの家に機材を集結させ、あらかじめ配線やマネージメントIPアドレス割り振りなどの最低限の設定だけ行っておき、あとは全員がリモートで設定を行っていくオンラインホットステージ[2]という試みを行いました。これにより、時間的拘束や移動コストを殆ど発生させずに、チームメンバの空いた時間を有効活用して構築やテストを実施することができました。

オンラインホットステージのデメリットとしては、有線の接続変更を行ったり、ファイアウォールのACL設定ミスや、ルーティング設定ミス時の設定戻しが発生した際や、rebootするつもりが間違ってshutdownしてしまったときなど、現地に人がいないと「＼お手上げ／」になってしまうことくらいです。

これまで、他のイベントで行ったホットステージでは、メンバ所属会社の会議室等を一週間ほど占有させていただき、そこへ機器を展開し、作業者はそこへ集まって設定を行っていましたので、この試みはとても有効であると実感しました。

メンバー間の情報共有にはGoogle DriveとSkype、Lingrを積極的に利用しました。Skypeのグループチャットではさまざまな議論や打ち合わせを行いました。Lingrとのゲートウェイを稼働させることで、スマホから画像をアップできるようにしたのが意外に便利でした。チャットは流れて行ってしまうので、夜中に議論が長引いたときなど後で追いかけるのが大変でもあり、やり取りの中で決まったことは別の場所に共有する仕組みが必要だと実感しました。

Google Driveではさまざまな図表を共有しました。Spreadsheetでチケット管理票、機材一覧表、ケーブル一覧表、各種認証情報、アドレス空間とVLAN ID、実アドレスの割当表（セグメントごと⁠）⁠、サーバ向け基本情報、NWチームのメンバリスト、下見チェックリスト、無線チェックリスト、諸費用計算と多岐にわたる重要な情報をやりとりしました。

その他、会場図面、物理配線イメージ、L2/L3設計図、Webへの掲載物、会場掲示ポスター、機材に貼ったシール素材、下見写真、など必要な図表を制作し共有しました。

この記事自体もGoogle DriveのDocument機能を利用し、共同で執筆し、共同で校正を行いました。画面上で他メンバーの校正する様子が見えるのが新鮮でした。

可視化ツールについて

YAPCでは会場ネットワークとそのトラフィックを可視化したページをインターネット公開していたのはご存知でしょうか？ このページは、会場に設置されたネットワーク機器（スイッチ、ルータ、無線AP）のネットワーク図上に、それぞれの機器間のトラフィックの向きと量をわかりやすく可視化したものです。以下の図が実際に公開していたネットワーク図となります。ここでは、このネットワーク図の導入について紹介します。

このネットワーク図は、Network Weathermapというツールで作成しています。Weathermapは、Cactiのプラグインとして（スタンドアロンでも動作します）PHP で実装されているツールで、SNMPで取得したトラフィック情報をノード（ネットワーク機器やサーバ）同士のリンクとして紐付けることでグラフィカルに表示する機能を持っています。YAPCでは、以下の手順でネットワーク図を作成しました。

1. Cacti に全ネットワーク機器を登録し、SNMP経由でそれぞれのトラフィックを取得する
2. Weathermapのエディタ機能（ネットワーク図を編集する機能）を利用して、ネットワーク図上に全ネットワーク機器とリンクを配置させる
3. ノード間リンクのデータソースとして、1で取得したトラフィック情報を指定する

Weathermapを導入した目的はというと、実は死活監視やリソース監視系のツールほどの積極的な理由はありません。なぜなら、トラフィックの可視化は死活監視やリソース監視とは異なり、なかったとしてもネットワークサービスが提供できているかどうかがわからないような状況にはならないからです。しかし、これを利用することでチーム内でのネットワーク状況の共有がスムーズになり、トラフィックの流れや帯域の逼迫具合から、さまざまな予測が可能になったり、問題を発見するきっかけを見つけることができるようになったりします。そのため、ISPなど業務でネットワークサービスを提供している現場では、必須の機能となっています。

また、ネットワークインフラは普段利用者に意識されないものですが、これを見ていただくことでYAPCネットワークチームが提供しているネットワークサービスを参加者の方に少しでも意識してもらえたら、という外に向けてのアピールの目的もありました。

Weathermapを構築するポイントは、アプリケーションのインストールよりもむしろネットワーク図の調整にあります。「⁠ネットワーク状況の共有」が導入目的の1つである以上、誰が見ても直感的にわかりやすい図にしなくてはなりません。そこで YAPCでは、JANOG 32 Meeting のページで公開されているWeathermapの活用記事を参考に、主に「背景画像の指定」と「使用される帯域に合わせた表示調整」の2点の調整を実施しています。

1つ目の調整「背景画像の指定」では、背景画像として別途作成した会場のマップ図を指定することで、ネットワーク図に各部屋のネットワーク機器のレイアウト情報を加えています。上のネットワーク図から背景を抜いた図を想像していただくと、いかに背景図の存在が大きいかご理解していただけるかと思います。

2つ目の調整「使用される帯域に合わせた表示調整」では、ネットワーク帯域に応じた色分けの範囲を変更しています。デフォルトではリンク速度が1,000Mbits/secとして設定され、0～1％の使用量では白色、1～10％の使用量では紫色で描画されます。しかし、実環境ではリンク間速度が100Mbits/secを超えることはほぼないため、白、紫の2色でしか描画されないことになってしまいます。そこで使用量ごとの色分けをさらに細分化することで、デフォルトよりも多彩な図に仕上げました。

Weathermapからの気付き

会期中では、Weathermapを利用することでいくつかの問題に気付くことができました。たとえば、予想よりもアクセス回線の帯域使用量が逼迫していたことや、無線APのアクセスに偏りがあったことなどです。

このようにネットワークサービス運用時に気付くことができれば、何らかの対処を施したり次のアクションにつなげることができます。そして、何より運用して良かったことは、「⁠視覚的にトラフィックが見えて楽しい」とチームメンバーからフィードバックをもらったことです。ネットワークの運用は地味で根気のいる作業になることが多いのですが、そういった中で少しでも運用を楽しくできたことが Weathermap 導入の一番の効果だったと思います。

会場内ネットワークのセキュリティ監視について

安心して使用できるネットワークには、暗黙的にですが快適で安全なネットワークであることが求められています。たとえば通信が途切れたりしないネットワークの安定性や、同じネットワークにつながっている別の端末から不正にアクセスされないといった環境であることです。

今回の会場ネットワークにて、どのような構成で安定した無線通信を提供していたかという点についてはすでにご紹介しているので、ここではセキュリティの観点から会場ネットワークをご紹介します。

IDSによるセキュリティ監視

セキュリティ監視を実施するため、今回はネットワークIDS（Intrusion Detection System）のSnortを使用しました。IDSはシグネチャと呼ばれる、攻撃通信の特徴を示すネットワークトラフィック・パターンを用意しておき、そのシグネチャに一致する通信が検知した際にアラートを出します。

このアラートを常に監視し、攻撃通信の内容を見て対処することがセキュリティ監視であるといえます。重要な点はシグネチャがないと攻撃通信を発見することができないということと、たとえアラートが発生したとしてもそのアラートを見ていなければ対処ができないということです。

シグネチャの話

Snortは誰でも無料で使用することができるIDSです。またSnortのコミュニティが作成しているシグネチャも公開されています（ただし最新のシグネチャは有料。1ヵ月以上前に公開されたシグネチャから無料で使用可能⁠）⁠。今回の会場ネットワークでは機器の制約もありアプライアンス製品ではなく、Snort を使用しました。シグネチャに関してはSnortコミュニティが作成しているシグネチャとネットワークチームスタッフが作成したカスタムシグネチャを使用しました。

IDSによるセキュリティ監視は、①インターネットから守るべき内部ネットワークに対する攻撃通信を発見すること、②内部ネットワークからインターネットへ出て行く不審な通信を発見すること、の2つの方向性の違いがあります。

①にはSQLインジェクションによる情報漏えいを狙った攻撃や、ミドルウェアの脆弱性や設定不備を狙ったバックドアプログラムの設置などが挙げられます。一方、②については管理下にない端末に対する攻撃通信やマルウェアに感染した場合に発生する通信などが挙げられます。

今回のような会場ネットワークではユーザセグメントから外部に対してWebサーバやFTPサーバなどを公開しないため、①の通信はほぼ発生しないと考えてよいです。しかしながら②には十分、注意する必要があります。YAPCは1,000人を超える一般参加者がいて、その他に発表者や運営スタッフがいます。皆、意識高い人たちばかりと考えられるので外部への攻撃通信は発生しないと推測されますが、マルウェア感染についてはマルウェア対策ソフトの導入等の対策をし、不審なメールの添付ファイルを開かない等の注意をしていても、場合によっては感染してしまう可能性があります。

そこで今回のセキュリティ監視ではこのマルウェアに関する通信に注目して、2種類のカスタムシグネチャを作成しました。

1つ目のカスタムシグネチャは、不審なIPアドレスにアクセスしていないかを発見するためのシグネチャです。マルウェアドメインリストと呼ばれるサイトで、マルウェアに感染した際に通信の宛先となる不審なIPアドレスのリストを公開しています。このアドレスのリストを元にカスタムシグネチャを作成しました。

2つ目のカスタムシグネチャは、マルウェアに感染した際に発生するネットワークトラフィック・パターンを発見するためのシグネチャです。マルウェアを解析しているWebサイトで、マルウェアに感染した際に発生する通信内容を公開しています。この公開されているネットワークトラフィック・パターンを元にカスタムシグネチャを作成しました。

まとめると次の3種類のシグネチャでセキュリティ監視を実施しました。

• Snortのコミュニティが公開しているシグネチャ
• 不審なIPアドレスに接続していないかを発見するカスタムシグネチャ
• マルウェアに感染したような不審な通信がないかを発見するカスタムシグネチャ

当日の監視の話

セキュリティ監視はシグネチャを用意するだけでは片手落ちです。用意したシグネチャを元に、発生したアラートを見ることも大切です。会期中、ネットワークを提供している間はこのアラートを見る必要がありました。しかしセキュリティ監視をするにあたり避けて通れないのが、シグネチャのチューニングです。シグネチャの検知精度によって、通常通信を誤検知することがあります。誤検知のアラートが多いと、見つけなければならないアラートを見逃すことになりかねません。そのため誤検知が多いシグネチャに関しては無効化するというチューニングが必要となります。そのためアラートを見て誤検知と判断した場合はその結果をフィードバックし、シグネチャチューニングをするというサイクルを回していました。

Snortはアラートをいろいろな形式で出力することができます。単純なテキスト形式からネットワークトラフィックを含むPCAP形式などです。数百、数千件のアラートが発生するため、これらのアラートを直接見ることは視覚的にも見落としやすく、現実的ではありません。そこでアラートを見るツールとしてSnorbyを使用しました。このツールにより、アラートの発生状況や検知したアラートの検索など、セキュリティ監視が格段にやりやすくなります。

まとめ：セキュリティ監視を通して

会期中のセキュリティ監視では特筆すべき危険なアラートは発生していませんでした。これは参加者の皆様が適切なセキュリティ対策をしていて、マルウェア感染のリスクを認知しているからではないでしょうか。しかしながらIDSによるセキュリティ監視は前述のとおり、シグネチャが無ければアラートは発生しません。シグネチャが無いような新手のマルウェアに感染していた場合は、当然ですが発見することはできません。もし新手のマルウェアに感染していた!という事実がわかった方がいれば是非、ネットワークトラフィック・パターンを採取させてください。次回のためにシグネチャを作成しますので。

運用中の注意事項について

YAPCのネットワークでは、さくらのクラウド上でなくてはならないサービスを動かしていたため、ネットワークの死活・疎通確認がとても重要でした。また、1,000人規模のイベントでどれくらいのトラフィックが発生するか想定できないため、トラフィックの監視もしなければいけませんでした。インターネット側からのトラフィックはピーク時には80～90Mbps以上ありましたが、ルータのインターフェースがFastEthernet（100Mbps）のため、ほぼ限界のラインに達していました。そのときはトンネルが落ちないかどうかとても心配でした。

トンネルがダウンするとアドレスの払い出しや名前の解決ができなくなる障害になります。ホットステージでの余裕がなかったためQoSなどの設定をしておらず、とても後悔しました。今回はトラブルには至りませんでしたが、このような構成を組むときは、それぞれの通信のToS値の確認やQoSの設定等をしたいところです。また、NATテーブルは別のページで述べたように、埋まってしまうとユーザが新しい通信を開始できなくなってしまうため、確認する必要があります。

無線APの監視はZabbix、Cactiで行いました。ポイントはトラフィックとアソシエーション数（端末接続数）です。負荷が偏り、問題が起こりそうであれば前述の方法で他の無線APへ移動させます。また、グラフ上で近くの無線APがすべて高負荷になってしまっている状態（たとえば想定以上の立ち見で満員電車状態であるなど）が観測されたときには、現地に行って状況を調査します。

遠隔からの確認でも、たとえば無線APへログインしDHCPスヌーピングを確認し、アドレスが正しく振られてきていない端末が出てきている状況ですと、そろそろ限界かといった感触です。高負荷な状況が継続しそうな場合、無線APの増設を検討します。今回はイベントホールの用途が想定より多様であったこともあり、1台増設を行いました。

無線APごとのアソシエーション数を変調レートでグラフにしたもの（802.11a/g合算）から抜粋して掲載いたします。縦軸がアソシエーション数と変調速度、横軸が時間です。

アソシエーションが多くても、トラフィックが少なければ問題になりにくい傾向にあります。ライトニングトーク時のアソシエーション数がもっとも多くなりましたが、トラフィックは相対的に少なく感じました。楽しいLTが矢継ぎ早に繰り出されると、もう皆さんインターネットどころじゃなくなってしまうのでは？

各セッションが終了すると参加者がホールから出て行きます。アソシエーション数のグラフを監視していると、各セッションが終わった直後ホールの無線APがみるみる空き、ホワイエ（ロビー）に設置した無線APのアソシエーションが急上昇します。これも、10分から15分ほどで落ち着きます。お昼休みはもう少し長く賑わってますね。このホワイエに設置した無線APは、カバレッジを広くとるために遅いレートの接続も許可しています。

ライトニングトークが終了し懇親会が始まりますと、懇親会会場のアソシエーションが急上昇しました。懇親会は人口密度が高く、接続が不安定になりがちです。

同じ会場の中でも無線APごとの偏りがあり、トラフィックのグラフも割愛させていただいた関係で、各会場の状況を必ずしも正確に反映していないかもしれません。しかし、人の流れを予測してAP配置を設計することの大切さがおわかりいただけるかと思います。

運用結果

接続された端末について

YAPCでは、DHCPサーバから2,310個のIPアドレスを払い出し、1,098個のMACアドレスを観測しました。MACアドレスの上位24bitには製造元を表すコードが入っています。持ち込まれる機材の傾向がわかると面白いかと思い、データを集計してみました。

全体の約73％がAppleと偏っており、エンジニアの中でのApple人気の高さが伺えますね。会場を見渡したとき、確かにAppleのノートパソコンがよく見られましたが、これほどとは思いませんでした。

今回の会場ネットワークではIPv6もひっそりと提供していました。いまどきの端末であれば多くはIPv6を意識することなく使えるようになっているので、それと知らずに使っていた方がほとんどではないかと思います。

とはいってもトラフィックの大半はIPv4だろうと予想していましたがトラフィックデータをとってみたところIPv6もそこそこ使われていることに驚きました。図の赤線が総トラフィックで青い部分がIPv6です。

また、DNSのクエリ数トップ5は以下の通りでした。akamaiが多かったのはiOS7が発表された直後だったからかもしれません。端末の偏りがこちらでも如実に表れる結果となりました。

また、前述したとおり、会場ネットワークのトラフィックは、収容ルータ上限の100Mbpsにかなり近い値となってしまいました。JANOGやLLNOCでも最大60Mbps程度だったため、GigabitEthernetを搭載したルータは不要だと判断してしまいました。

しかし、よく考えてみるとJANOGやLLカンファレンスの来場者は300～500人で最大60Mbpsでしたから、その倍の人数が来るということを考慮すると、GigabitEthernetを搭載したルータは必要だったかもしれません。

まとめ

IT系のイベントやコミュニティは多くありますがそれぞれのコミュニティ同士の交流特に言語や開発系(YAPCやLL)とインフラおよびネットワーク系のコミュニティ（JANOG等）の交流は限られている印象です。実際今回のYAPCネットワークチームのメンバーの大半はYAPCに参加したことがありませんでした。

もっとエンジニア同士で交流していこうよとYAPCの事務局さんより声をかけていただき、JANOG＋LLコミュニティ横断のネットワークチームが結成され、今回の会場ネットワーク提供が実現しました。我々ネットワークチームのメンバーにはあまり馴染みのないコミュニティであるYAPCに飛び込むことで不安もありましたが、YAPCの熱気が感じられて大変有意義な機会でした。コミュニティの枠にとらわれるのはもったいないと思います。YAPCにご参加いただいた皆さまも、ぜひJANOGやLLに参加してみてください。

会場ネットワークを構築するにあたり、必要となるネットワーク機材はチームメンバーの持ち込みに加え、アラクサラネットワークス株式会社様、さくらインターネット株式会社様にご協力いただきました。またYAPCスタッフの皆さま、会場スタッフの皆さまや慶應義塾大学の加藤朗先生にも多大なるご協力をいただきました。この場を借りてすべての関係者の皆様に感謝を申し上げます。