Making of RubyKaigi - Making of KaigiFreaks ネットワーク班

初稿：2011-09-26

はじめに

RubyKaigi2011 KaigiFreaks ネットワーク班番長の小岩です。今回は、RubyKaigi2011 のトラヒックを支えたネットワークについて説明する機会をいただきましたので、簡単ですが設計思想や要素技術などについて解説させていただきます。

RubyKaigi2011 ネットワークの目的

RubyKaigi2011 のネットワークは以下の目的のために、7/16-7/18 の 3 日間、練馬文化センターに臨時で敷設されたネットワークです。

大ホール及び小ホールのセッションの Ustream 中継
イベント運営業務のためのインターネットコネクティビティの提供
スピーカーへのインターネットコネクティビティの提供
参加者へのインターネットコネクティビティの提供

上記目的の順番は、そのまま重要度であります。つまり、本ネットワークの第一義の目的はセッションの Usteram 中継をおこなうためであり、特に一番最後の参加者へのインターネットコネクティビティの提供というのは、いわば、おまけに過ぎません。この目的の重要度付けはネットワークの設計及び運用指針に反映されてます。

RubyKaigi2011 ネットワークの懸念事項

RubyKaigi2011 のネットワークにおいては、過去の経緯及び検討より以下の懸念事項があるだろうと考えました。

多数の NAT セッション

ネットワークの利用者は全員一つのグローバル IP アドレスを持つ NAT 箱を通して、インターネットにアクセスしていきます。大量のユーザが同時にアクセスした場合、NAT セッションテーブルの数が枯渇するおそれがあり、その対策が必要になります。具体的には、NAT セッションの数を増やさないために、不要なパケットをインターネット側に流さないなどです。

無線 LAN デザイン

RubyKaigi2011 は 2 箇所の会場でセッションを聞くカンファレンスですので、多数の利用者が小ホール、大ホールに集中しそこからインターネットへのアクセスをおこないます。参加者へのインターネットコネクティビティは無線 LAN を通して提供しますので、AP の配置や設定が重要になります。

障害が発生した場合の対応

Ustream 中継も一般参加者のインターネットアクセスも同じ回線を通しておこなわれるため、なんらかの障害が起きてネットワークがダウンした場合、全てのサービスが停止します。特に、Ustream 中継の停止は避けねばなりません。障害が起きた場合、すみやかに原因を追求し重要度にしたがってサービスを回復する必要があります。また、その回復スピードもインターネットの向こうでセッションを見ている方のためにも分単位での対応が求められます。

RubyKaigi2011 ネットワークの設計指針

前項であげた懸念事項やその他の制限事項 (金銭的なもの、準備時間的なもの) を踏まえて、以下のような設計指針を考えました。

NAT セッション対策

キャッシュ DNS サーバの設置
- ネットワーク内にキャッシュ DNS サーバを設置し、クライアントの DNS クエリーをネットワーク内に閉じ込めました。最近の Web ブラウザは DNS のプリフェッチ検索をおこなうため DNS クエリーが多く発生します。そのため、このクエリーをネットワーク内に閉じ込めることで、NAT セッションの数を減らす努力をおこないました。
NAT ルータとして Vyatta を採用
- このネットワークでは大量の同時アクセスが発生すると考えられたため、この同時セッションをさばくスペックを持つアプライアンス製品を用意するのは、主に金銭的に困難だと考えました。そこで、最近、注目を浴びている Vyatta に着目し PC サーバに Vyatta をインストールしこれを NAT 箱としました。

無線 LAN AP の設置

エンタープライズ製品を用意できなかったため、一般に使われている民生品を使う必要がありました。そこで周波数帯やチャンネル割り当てを工夫し、できるだけ電波が干渉しないようにしました。

柔軟なネットワーク設計

ルータを設置し、サーバセグメントと大ホールセグメント、小ホールセグメントの 3 つにセグメントをわけました。これはブロードキャストストームをある程度の範囲で押さえ込む目的と、大きなトラヒックが発生してネットワークが輻輳した場合にセグメントを切り離すなどの対応をするためです。

ネットワーク図

以上の設計をもとに作成された本ネットワークの概念図は以下のとおりになります。

Internet
  |
 fennel (NAT箱)  nampla (管理サーバ)
  |　　　　　　　 |
 *-+-+-----+------+----------------*サーバセグメント
    |     |
    |   RTX1100 (ルータ)
    |     |
    |  *--+----+----+-----+-------*小ホールセグメント
    |          AP   AP    AP
    |
  RTX1100 (ルータ)
    |
 *---+----+----+-----+-------------*大ホールセグメント
         AP   AP    AP

詳細説明

本項では本ネットワークのいくつかの構成要素について、詳細に解説をおこないます。

NAT ルータ (fennel)

NAT ルータは、えにしテック提供の ML115G5 改に Vyatta をインストールして構築しました。

ホスト名は fennel です。

Vyatta は Debian GNU/Linux をベースとした、オープンソースソフトウェアを集めて作られたソフトウェアルータ (ディストリビューション) です。Vyatta社が開発しており、「Vyatta Core」と呼ばれる非商用版と、「Vyatta Subscription Edition」と呼ばれる商用版があります。本ネットワークでは、Vyatta Core を利用しました。

Vyatta を NAT ルータとして構築する方法は省略します。ここではおこなったチューニングと設定について説明します。

NATルータとして構築したvyattaに以下のチューニング及び設定をおこないました。

tcp の TIMEWAIT 値の調整
- TCP/IP の通信において、セッションは通信が終わってクローズされたのちも、同じシーケンス番号やポート番号を再利用しないように一定時間のタイムアウト待ち状態 (TIME_WAIT) になります。この TIME_WAIT の間のセッションは再利用できないため、本ネットワークでは少し時間を短くしました。具体的には、/etc/rc.local に以下の一行を追加しました。デフォルトでは 120 秒ですが、これを 60 秒に短縮してます。

echo 60 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_time_wait

munin の導入
- fennel の状態監視 (CPU、メモリ、トラヒックなど) のために munin を導入しました。最初は snmp を用いて監視しようとしたのですが、nampla に導入した mrtg との連携がうまくいなかったので munin でおこないました。Vyatta のリポジトリでは munin は提供されてませんが、fennel の apt-line に debian.org/squeeze を追加して munin をインストールしました。
http の透過プロキシの導入
- 会期中、アクセスされる Web サイトは Twitter や Google、GitHub、Flickr などいくつかの Web サイトに集中するであろうと判断し、プロキシのキャッシングが期待できると考え、透過プロキシを導入しました。これも NAT セッション削減対策の一環です。

管理サーバ (nampla)

管理サーバは、えにしテック提供の ML115G5 改に Debian GNU/Linux squeeze をインストールして構築しました。

ホスト名は nampla です。

このサーバには以下の機能を実装しました。

キャッシュ DNS サーバ
- bind をインストールし、構築しました。筆者のまったくの趣味で実は DNSSEC に対応してましたが、気づいた方はいらっしゃいましたでしょうか。DHCP の設定により各端末の resolver をこの DNS サーバに向けるようにしました。
DHCP サーバ
- dhcp3-server パッケージをインストールし、構築しました。default-lease-time と max-lease-time を 300 (5 分) というかなり短い時間に設定しています。dhcp のプールには十分な IP アドレスを用意したつもりですが、本ネットワークの性格上、各端末はスリープもしくはシャットダウンを頻繁に繰り返す (一日ずっと電源が入りっぱなしの端末は数が少ない) と考えられます。そのため、max-lease-time が長かった場合、未回収の IP アドレスが多数発生することが考えられるため短い時間にしました。
munin
- fennle と nampla の CPU 利用率などのマシンの状態監視をするために、munin を導入しました。
mrtg
- 各ルータのトラヒックを SNMP 経由で取得しグラフ化するため、mrtg をインストールしました。小ホールと大ホールのネットワーク利用状況の傾向を観察し、問題が発生しそうか

or　してるかの傾向をつかむためです。

nagios
- AP やルータなどを ping を用いた死活監視をおこなうために導入しました。

無線 LAN について

本来この規模であればエンタープライズクラスの無線 LAN AP を用意すべきですが、残念ながらかないませんでしたので、本ネットワークのユーザーサービス部分の無線 LAN については全て民生品の無線 LAN AP を利用しました。用意ができた Buffalo 社や Apple 社の製品を利用しています。無線 LAN のデザインについて重要なのが、各 AP 間の電波干渉を防ぐことです。本ネットワークでは、小ホール、大ホールに以下の設定の AP を用意しました。

小ホール
　202APa01 (802.11a、チャンネル自動)
　202APa02 (802.11a、チャンネル自動)
　202APa03 (802.11a、チャンネル自動）
　202APb01 (802.11b、チャンネル1)
　202APb02 (802.11b、チャンネル6)
　202APb03 (802.11b、チャンネル11）
大ホール
　203APa01 (802.11a、チャンネル自動)
　203APa02 (802.11a、チャンネル自動)
　203APa03 (802.11a、チャンネル自動）
　203APb01 (802.11b、チャンネル1)
　203APb02 (802.11b、チャンネル6)
　203APb03 (802.11b、チャンネル11）

802.11a と b の各周波数帯において 3 台の AP を用意し、これに対して電波干渉がおきないようチャンネルを設定、各ホール 6 台ずつ合計 12 台の AP を用意しました。11a の AP についてはチャンネル固定の設定がありませんでしたので、自動としています。

実際の運用について

発生した障害

ustreamの配信障害

1 日目の午後、Ustream の配信がプチプチ切れるという障害が発生しました。切り分けの結果、セグメントルータの RTX1100 の CPU 使用率が高負荷 (80% 超える) になる場合があるということがわかりましたので、セッションの間の休憩時間において Ustream 配信端末の収容セグメントを、大ホールセグメントからサーバセグメントに変更しました。

この変更後、Ustream の配信がプチプチ切れるという事象は発生しなくなりましたので、小ホールのネットワーク構成も同じように変更しました。

スタッフ用無線 LAN セグメントの増設

各ホールではスタッフも参加者と同じ無線 LAN を利用していましたが、ホールの中の人数が増えてくるとファイルの転送に時間がかかるなどの問題が発生しました。そのため、スタッフ用の無線 LAN AP を別に立てサーバセグメントに収容しました。

毎朝のネットワーク起動

一日のイベントが終わった後、ホールの電源が落とされるため、毎朝ネットワークの立ち上げをおこなう必要があります。朝の準備時間は多く時間がとれないため、ネットワークの起動及び確認は素早くおこなう必要があります。そこで、以下の項目をクリアーすればネットワークが正常に起動している、ということにしました

nagios の全ての項目がグリーンになっている
小ホールからインターネットアクセスができる
大ホールからインターネットアクセスができる

これらのテストをクリアーすることでネットワークの正常起動を確認し、その後の Usteram 配信のテストなどにスムーズに引き継げるようにしました。

数値で見る RubyKaigi2011 ネットワーク

http 転送量
- 7/16　21.0GB
- 7/17　18.6GB
- 7/18　17.6GB
会期中の http アクセス先　トップ 5
1. www.gravatar.com
2. api.twitter.com
3. rubykaigi.org
4. search.twitter.com
5. a2.twimg.com
TCP 同時セッション数
- 最大　約 23,000 セッション
- 平均　約 11,000 セッション
DHCP リリース数 (ほぼ同時接続者数と考えてください)
- 大ホール
  - 最大　376 個
  - 平均　115 個
- 小ホール
  - 最大　170 個
  - 平均　34 個

終りに

RubyKaigi2011 のネットワークを支えた要素技術や設計などについて、簡単ではありますが説明してみました。ネットワーク構築に魔法はなく、ひたすらセオリーを積み重ねていくことで、スタッフやスピーカー、参加者の皆様を支えるインフラを構築していきます。

勉強会やイベントでのネットワーク構築はあまり日が当たらない分野ではありますが、この記事がみなさまの興味をひくきっかけになれば幸いです

著者について

小岩秀和 (@koiwa)

北海道でサーバやネットワークのコンサル、提案、構築、運用などをおこなってます。フリーソフトウェアを用いたシステム構築が得意技。ごくたまに、Ruby でスクリプトを書きます。妻と娘と BOYCOMBAT とホッピーとバーボンを愛する、どこにでもいる男です。

株式会社エストコスモ所属、一般社団法人 LOCAL 理事、KaigiFreaks、88nite、奥野一門

バックナンバー