1,000人超の大規模開発者イベント「YAPC::Asia Tokyo 2013」を支えたネットワークインフラ構築の舞台裏~プロフェッショナルのボランタリーが生み出したチカラ

この記事を読むのに必要な時間:およそ 11 分

ネットワークの論理構成

レイヤ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つの参加者向けセグメントとしました。

レイヤ3の設計図

レイヤ3の設計図

また,通常の利用では会場ネットワーク内で折り返す参加者間の通信は少ないと想定し,そのような通信はさせないように設計しました。そのため,管理用途以外のスイッチでは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まつりの会場ネットワークでは重要なVMをいくつも乗せたPCがハードウェア的に故障し,会場での設営時に起動することができず,サービスの提供が大幅に遅れてしまいました。

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

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

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

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

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

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

著者プロフィール

YAPCネットワークチーム

YAPC会場ネットワーク設営,運用のために集められたプロフェッショナル集団。

@yapcnwteam

東松裕道(とうまつひろみち)

アラクサラネットワークス株式会社 製品開発本部

高田美紀(たかたみき)

NTTコミュニケーションズ株式会社 先端IPアーキテクチャセンタ

高橋祐也(たかはしゆうや)

国内電気通信事業者

津山訓司(つやまさとし)

NECビッグローブ株式会社

森久和昭(もりひさかずあき)

セキュリティベンダ

熊谷暁(くまがいあきら)

個人

田島弘隆(たじまひろたか)

Genie Networks

バックナンバー

ネットワーク

  • 1,000人超の大規模開発者イベント「YAPC::Asia Tokyo 2013」を支えたネットワークインフラ構築の舞台裏~プロフェッショナルのボランタリーが生み出したチカラ

コメント

コメントの記入