id:sora_h です。最近は RubyKaigi の Organizer や Wi-Fi NOC をやっていましたが… 何屋なんだろう? 一応 Software Engineer (Site Reliability, Corporate Engineering) を名乗っていますが…。あっ RubyKaigi から戻ってからは学者をやってますね。落ち着いたら本業を思い出していこうと思います。
さて、Cookpad は 2010 年より RubyKaigi に協賛していますが、近年は Wi-Fi Sponsor など*1として携わっています。実体的には、 id:sora_h (筆者) が RubyKaigi 前にほぼフルタイムで Wi-Fi の準備に提供されたり、細々とした機材、一部の回線・ラックスペースの提供を行っています *2。
本稿では RubyKaigi 2023 Wi-Fi ネットワークの L1～L4 設計について解説します *3。Wi-Fi についてというより、Wi-Fi AP より先の足回り、会場のルータからインターネットまでの区間についてがメイントピックです。
実績
まずはじめに、RubyKaigi 2023 Wi-Fi の規模ってどういうものなの? というのを理解してもらうために実績から説明します。だいたいの実績は下記のようなところでした。
- IPv4/IPv6 dualstack
- Wi-Fi: 1,325 clients (peak)
- Traffic:
- Peak: 480 Mbps (in) 240 Mbps (out)
- 90%ile: 330 Mbps (in) 75 Mbps (out)
- IPv4 NAPT: 32,000 sessions (peak)
- DNS: 530 qps (peak), 370 qps (mean), うち ⅓ は DoH
事前に (後述するトンネル接続先との) フレッツ光 (NGN) 区間で測定した速度が 2 回線合わせても良い結果ではなかった*4ので昨年よりクライアント数は伸びつつもそこまでトラフィックは伸びなかったどころか減ったというのが印象です。ただQoSを特にせずとも問題ないくらいのクオリティで運用することができたのでまずまずという結果。
Association (Wi-Fi client 数) も参加者数に対してそこまで伸びてないなという感想です。みなさん最低でも 2 つは繋ぐでしょという前提で、2,400 assocs くらいは想定していたんですが (捌けるとは言っていない)、近年では参加者数に対して 1.1 倍くらいの Wi-Fi association 数の見積で良いのかもしれません。2 端末以上に設定されていて自動切断されていたのか、そもそも1端末にしか設定されていないのか、など理由はきになるところです。
概要
上記は RubyKaigi 2023 の L3 概要図です。本稿ではこれを上から順に解説します。
RubyKaigi のネットワークは参加者が会期中に呼吸をするために構築して提供しています。オペレーションや構成はシンプルにしつつ、イベントネットワークとして面白いことはやる、その上で冗長化可能なところは実装して耐障害性を高めたり、active/active 構成でパフォーマンス向上も目指したりします。
(現地で障害が起きて機材をリプレイスしているとカンファレンス本編に参加する時間を損ねてしまうので、なるべく現地かつ会期中でのオペレーションは最低限にしたい) 基本的にサービスレベルは高くなく *5、ある程度諦めても良いと思ってはいますが、それはそれとして高品質なネットワークを提供することに価値はあるし、できる範囲で高い品質を目指す気持ちで実装しています。
AWS VPC 上に構築される機能
はじめに前提として、RubyKaigi Wi-Fi では Linux サーバが必要になるような機能については可能な限り AWS VPC 上に構築しています。RubyKaigi 2023 では下記の機能を AWS 上に構築しました。
- 監視基盤 (Prometheus/Alertmanager/Grafana)
- Syslog (Fluentd, S3, CloudWatch Logs)
- DHCPv4 サーバ (kea4-dhcp)
- DNS リゾルバ (unbound, envoy)
- RADIUS サーバ (freeradius)
RubyKaigi 2022 に引き続いて、Amazon EKS を主に利用しています *6。Kubernetes 環境のお世話が必要になりますが、やはり 2023 年になって EC2 で Linux サーバをそのまま運用するのは面倒で、デプロイなどを含めてもコンテナベースのワークフローにしたいものです。
このあたりは https://github.com/ruby-no-kai/rubykaigi-nw で Terraform や Jsonnet ファイルが public になっているのと、ごくごくふつうのことをしているので本稿では省略します。
エクスターナル
会場側の設計解説に入る前に、まずはエクスターナル – 対外回線とインターネット接続について説明します。
対外回線
会場からの対外接続はフレッツ光 (NGN) の網内折り返しを利用しています。RubyKaigi 2022 までは 1 箇所に 2 回線を引いていたのですが、NTT 局側の同じ機材に収容されてしまったのか共倒れする障害が発生してしまいました。
この反省を受けて、RubyKaigi 2023 では 2 箇所に 1 回線ずつ手配しました。場所が分散することで運用は煩雑になりますが、少しでも同じ機材に収容されるような事態を回避するための取り組みです。しかしここばかりは会場周辺の光スプリッタ・芯の状況に依存するため、別の機材に収容されることを願うことしかできません *7。
今年はおそらく違う局舎側装置で終端されていそうでした。来年も 24 時間出張修理オプションに忘れずに加入し、お祈りしたいと思います。
中継拠点 (Point of Presence)
会場の回線からは直接インターネットに抜けていません。RubyKaigi では別途、中継地点を 2 拠点用意、そこへルータを設置して IPsec VPN や IP over IPv6 トンネルで *8 会場と接続しています。本稿でこの中継地点を以後 RubyKaigi PoP (point of presence) と呼びます。PoP の目的はインターネット や AWS VPC との接続を終端し会場側のルータにトンネルを提供するものです。
直接インターネットへ接続しない理由は会場側機材の接続設定をシンプルに保ちつつ冗長化と帯域のアグリゲーションを行うためです。中継拠点を設けることで自宅やオフィスでホットステージを行いやすく事前に dogfooding が可能になりますし、中継拠点の機材は RubyKaigi NOC チームでコントロールできるため、まとめて運用が可能です。会場から直接インターネットへ接続する場合は現地の回線に依存してしまい、同じ環境で検証を行いづらくなります。現地で確認してはじめて分かる情報が増えると設営時の作業が煩雑になるため、これを避けられる利点もあります。
RubyKaigi 2023 の PoP は Cookpad のラックスペースと筆者の自宅の 2 箇所に設置しました。前者を hnd, 後者を nrt と呼称します *9。
インターネット接続
PoP で終端する実際のインターネット接続は、筆者が構築/運営に携わっている AS59128 (KMC, 京大マイコンクラブ) からトランジットと IP アドレスを提供しました。これは RubyKaigi 2022 から *10 の変更で、マルチホーム接続など遊び要素、BGP による容易な冗長化のための取り組みです。
なおこの関係で、RubyKaigi NOC チームには多数の KMC 部員が Helper として参加しています。RubyKaigi 2023 NOC は幽霊部員の発見や現地での入部を経て最終的に 9 人中 7 人が KMC 部員 でした。したがって、RubyKaigi Wi-Fi は Cookpad がスポンサーしつつ KMC 部員が好き勝手するイベントネットワークになりつつあります。KMC 部員以外でも、何かしら面白いものをデプロイしてみたい人の参加は歓迎しているので、筆者や関係者まで Twitter などでお声がけくださいね。
また、Cookpad のラックスペースにある AWS Direct Connect Connection (dxcon) 上に RubyKaigi の AWS アカウント/VPC の private virtual interface (dxvif) を作成して、AWS VPC への接続も確立しています。バックアップとしてはもう片方の PoP で AWS Site-to-Site VPN (+ 適当なフレッツ光 PPPoE の ISP) を設定しました *11。
そして、実は同じ dxcon で Cookpad から AS59128 に public dxvif も提供していて、AS59128 は AWS とピアリング (直接接続) を行っています。そのため、RubyKaigi Wi-Fi と AWS の public IP prefixes の通信は AS59128 から直接 AWS に出て行き、その逆もしかり AWS から直接 AS59128 にパケットが送信されていました。AS59128 の対外接続 (RubyKaigi からみて上流の上流) はこれを除いて全て NGN などを通したトンネル接続ということもあり、AWS 宛の通信だけやたら低レイテンシ・広帯域が実現されています *12。AS16509 (Amazon), AS15169 (Google) ともにそれぞれ inbound traffic の 15% 程度を占めていたので、transit の帯域を他に譲れたので接続しておいて良かった印象です *13。
おまけ: NTT西日本エリアでの開催の場合
RubyKaigi PoP の配置場所は、AS59128 と物理的に接続できる場所という理由でも選定しています *14。
RubyKaigi 2023 は長野県松本市、NTT 東日本エリアでの開催だったため VNE (いわゆる IPv6 IPoE 接続)を利用しませんでした。RubyKaigi 2022 (三重県津市) のように NTT 西日本エリア側で開催する場合は、NTT 西の拠点として KMC 部室、NTT 東の拠点として Cookpad のラックスペースを利用します。この場合、NTT東西のNGNで互いに通信するために VNE の契約が必要です。
AS59128 の構成上、単一 IP prefix で東西をカバーしているため柔軟な traffic engineering ができない・その事情も含め東京の方がスループットのポテンシャルが (前述のAWS DXも含め) 高い・接続先コンテンツはだいたい関東側・関西で 2 箇所以上の拠点を確保しづらい…のような理由で、西日本で開催する場合は VNE を利用して東西 1 拠点ずつ PoP 開設・接続することにしています。
フレッツ光回線開通工事後、NTT 側の所定の作業が終わらないと VNE 事業者が回線と VNE を紐付けるサービスオーダーを行うことができません。この作業がいつ終わるかはケースバイケースのようで、回線オーダー時に早めに IPoE 開通がしたい旨を伝えつつ、回線開通工事から VNE のサービスオーダーまで 3 営業日程度余裕を持っておくことが無難だと思っています (筆者の個人の感覚です)。帯域の問題以外にも、VNE 開通失敗を見越して、NTT 西エリアに PoP を用意して VNE に依存しない網内折り返しができるように備えています。
L3-L4 設計
次は PoP〜会場間を担う L3-L4 の設計について解説します。図面については冒頭に掲載した L3 Diagram を参照してください。
構造
L3-L4 ではほぼ NEC の Univerge IX シリーズルータを採用しています。IPv4 は(ほぼ全て) BGP, IPv6 は OSPF を動作させています。経路冗長と帯域のアグリゲーションが主な目的です。RubyKaigi 2022, RubyKaigi 2023 ともに下記 4 レイヤの構成を取っていました:
- br (border router): PoPに設置する対外接続終端ルータ。PoP に 1 台ずつ設置
- tun (tunnel): 会場で NGN に直接接続するトンネル終端ルータ。
- gw (gateway): IPv4 については BGP/OSPF 間の redistribute 役とNAPT 装置. IPv6 はただのルータ。
- csw (core switch): ユーザ収容 VLAN の L2 スイッチングと L3 デフォルトゲートウェイ (これは Juniper EX スイッチ)。
br は PoP に 1 台ずつ、残りのルータは会場の回線終端場所に 1 台ずつ設置します。RubyKaigi 2023 では 2 回線工事したため tun, gw, csw はそれぞれ 2 台存在しました。
tun/gw 間、gw 同士, csw 同士を除いて L3 接続を行っています。RubyKaigi 2023 では前述の通り主・小ホールに回線とルータが分散したため、ホールを跨ぐ機器同士の link は L2 スイッチを通る構成になっていました。csw, gw 同士でパケット転送する必要はないため接続していません。
末端のユーザ収容 prefix については、private IPv4 prefix は csw から OSPF へ流し gw が BGP へ redistribute しています (v6 は gw から br まで全て OSPF *16, csw/gw 間は static)。IPv4 NAPT outer address は NAPT 装置である gw から BGP advertise しています。
会場→エクスターナル向き通信 (outbound)
まずは outbound の通信について。エクスターナル宛のパケットは csw に届いて、まず ECMP でいずれかの gw に振り分けられます。IPv4 インターネット宛のパケットはここで NAPT の対象となって outer address が決まります *17。
tun/gw 間の接続は冗長になっていません。IX シリーズの NAPT 機能は interface 単位で設定するため、まず NAPT を有効にして複数の interface で冗長化することが不可能です。NAPT 装置の IX ルータを別途用意している理由はこの制約と、CPU bound なトンネル処理を行う tun の負荷を減らすためです。
また、IX シリーズでは NAPT の制御も基本的に source address でしかできません。AWS VPC 宛の通信などで NAPT されては困るため、対インターネット向け通信でのみ対象にするために tun/gw 間の接続は VLAN tagged にして interface を 2 つに分割しています。IPv4 のみ BGP セッションを分けて、private IPv4 prefix 宛の通信は NAPT の設定がない interface を通って tun に向かうように設定されています。
gw から先はシンプルです。tun/br 間も ECMP になっていて、br からは AWS VPC *18 か default route の AS59128 にルーティングされ、インターネットへ到達します。
エクスターナル→会場向き通信 (inbound)
RubyKaigi Wi-Fi は eyeball network であり inbound heavy です。会場側の 2 回線の帯域を活かすため、戻りの経路でも ECMP で帯域のアグリゲーションがされるようにしています。その都合で装置ごとに異なる ASN で運用される br, gw と異なり tun に関しては 2 台とも同 ASN で運用、tun 同士は iBGP *19 で接続しました。
前述の通り NAPT outer address は gw からそれぞれ BGP advertise されていて、NAPT outer address に対応する gw 筐体へルーティングされていきます。具体的には、br からどちらかの tun にパケットが着信し、それが同じ場所の gw の持つ prefix であればそのままパケットを流し、そうでなければ tun 同士の link を通って、もう片方の (違う設置場所の) tun へ転送し適切な gw へルーティングされます。
光ネクストの NGN 2 回線で出せる帯域の合計が 1 Gbps になれば良い方だと思っていて、ルータ間の link は LAG により 2 Gbps 程度あるため tun 同士の link にはじゃんじゃかトラフィックを流すことにしていました。設置場所を跨ぐこれが最適な戦略なのかはいまいち良く分かってはいません。
gw から csw へは ECMP ではなく同じ設置場所の csw に渡るようになっています。これは csw から先は L2 になり、最寄りの csw からスイッチングしてもらうのが効率が良いためここは ECMP になっていません。設置場所を跨ぐ csw/gw の link (例: csw-02/gw-01) は前述 IPv4 NAPT outer address の振り分けのために設定されていて、inbound traffic が通ることはありません。
パケットフィルタ
RubyKaigi 2022 までは Stateful Firewall *20 を gw で実装していましたが、後述の NAPT セッション数の問題と同じ懸念があることと、RubyKaigi 2022 で観測されたパケットロスの原因の可能性も疑い RubyKaigi 2023 では Stateful Firewall を v4/v6 ともに実装しませんでした *21。TCP は ACK | RST の established filter を入れていますが、UDP は WebRTC/STUN での通信も見込んで全て通していました。
また、IPv6 についてはユーザ収容 prefix を csw で originate、以降 csw/gw, br/tun 区間で ECMP されており、行き戻りパケットで異なる gw 筐体を通過する可能性があるため、そもそもこの構成では stateful firewall を IX シリーズでは実装することができません。 IPv4 に関しては NAPT の都合で inbound は outer address にルーティングされ行き戻りパケットともに同じ gw 筐体を通過することから、NAPT/stateful firewall ともに実装可能です。
NAPT
経路の話を終えたところで IPv4 NAPT の設定についてです。RubyKaigi 2022 は RubyKaigi 2019 と同じパラメータで運用していましたが、 QUIC が 登場した ため 見直しが必要 でした。
結論としては下記のパラメータで運用していましたが、peak 32,000 sessions くらいで済んでいました。
ip napt translation max-entries 129020 ip napt translation max-entries per-address 350 ip napt translation tcp-timeout 120 ip napt translation udp-timeout 120 ip napt translation icmp-timeout 10 ip napt translation dns-timeout 10 ip napt translation gre-timeout 600 ip napt translation syn-timeout 300 ip napt translation finrst-timeout 15 ip napt translation other-timeout 600 ip napt translation port-range 1025-65535
(max-entries per-address は NAPT は 2 装置あるため実質的には 700 です)
udp-timeout を見直していなければ (600→120 へ変更) つらかったと思いますが、IPv6 dualstack だったため QUIC で繋がるような大部分は NAPT を必要としていなかったというのが大きいと思います。IPv4 single stack で 1装置のみの検証回線では max-entries per-address 350 でぎりぎりかなという印象。みなさん IPv6 対応しましょう…… といいつつ、非 BGP 回線で IPv6 の冗長が面倒で安価にすまないなあ…と思っている今日この頃です。ご家庭は簡単なんだけど、オフィスがね…。
いちおうセーフティで実は今回 NAPT outer address については装置ごとに 2 つ、合計で 4 つ用意していました。実際には NAPT 装置ごとに 1、合計 2 で十分だったと思います。NAPT outer address の使い分けについては csw→gw の ECMP で振り分けた上で gw 上で inner source address の上位 1 ビットで行っていました。なお、 採用している DHCPv4 サーバー kea4-dhcp はデフォルトでは sequential にアドレスを割り当てるため source address での振り分けを機能させるために random allocator が導入された kea をビルドする対応 が必要でした。
L1-L2 設計
続いて、会場側の L1-L2 設計です。とはいえ、L2 についてはユーザー収容 VLAN などいくつかありますが特に複雑なことをしていないため、L1 を中心に解説します。
原則としては対外回線のそばに L3 機能を担うルータ類を設置、そこから L2 スイッチを伸ばしていく形で設計します。会場から LAN のパッチパネルを借りれそうであれば借りますが、RubyKaigi 2022, 2023 では存在しなかったため全て自前配線となりました。
また、100m 前後を越える区間については光ファイバー (1000BASE-SX) で接続するしかないので光ファイバーを敷設しています。RubyKaigi 2022 より必要になって導入しましたが、はたしてどこまで雑に扱っていいのかというのは毎回首をかしげながら作業しています。
前述の通り RubyKaigi 2023 から対外回線を会場内の 2 箇所に設置するようにしたため、今回はルータ・回線が設置されている部屋同士の接続については最優先で敷設しました。
前述した L3 経路で設置場所を跨ぐものはシアターパーク (スポンサーブースエリア) にある L2 スイッチ 2 つを経由して link が構成されています (図面上の点線がその link)。また収容 VLAN の default gateway は csw-01 であること、全ての通信が wlc-01 を経由する *22 関係で、ワーストでこの経路を trb→wlc→csw-01→gw-02 のように 2 往復する可能性があります。
総ケーブル長を短く抑えるため、L2 スイッチは積極的に cascading をしますが、複数の部屋のトラフィックを担う接続は LAG を行うようにしています (そのため微妙に減ったり減らなかったり... 上記図面では省略)。今回は特に前述の往復が見込まれたため、csw-01/tpk/csw-02 間のリンクが最も重要でした。
この構成で帯域上の問題は生じませんでしたが、ルータ間の接続を保持してしまっていることから撤収の際に依存関係が生じ、シアターパークの機材だけ撤収作業が最後までブロックされてしまいました。これを回避するため、次回以降は同様の構成を取る場合独立した物理配線をすることになりそうです *23。長距離ケーブルが増えることによる敷設コストの増加よりも、撤収コストが安い方が勝ると考えているためです (みんなはやく打ち上げに行きたいというわけ)。
配線経路や cascading の接続といった設計は図面を元に考えて現地に 1～2 度下見にいって決定します。レーザー距離計や実際のケーブルを持ち込み、ケーブルを通せるかどうか、実際必要な長さはどうかという点を徹底的に確認します。
RubyKaigi 2023 では回線・ルータは主ホール楽屋と小ホール音響室に設置しました。そこから 3F のオープンスタジオ (#rubykaigiC), 4F の Hack Space が最も遠く、主・小ホール間は実験劇場 (主ホール舞台裏) とシアターパーク (スポンサーブース) を経由して接続していました。特に表に出る経路では3F, 4Fへ向かう光ファイバーが目立ったのではないでしょうか。たまたま綺麗に縦に通すことができたので、やっとるな〜と写真にでも収めたりしてもらえていればうれしいです (?)。
#rubykaigi むしろ誰か他の人が撮影してくれてたら嬉しい写真 (5フロア分の高さを垂直に上昇する光ファイバー) pic.twitter.com/A6tF3EMkEL
— osyoyu (@osyoyu) 2023年5月15日
Wi-Fi 区間
最初に書いたように本稿では深くは解説しませんが、
- 低データレートの拒否
- 基本は RRM に任せて power, channel は自動調整
- Dual 5 GHz radio の活用
- AP を適切にたくさん置く
- 2.4 GHz は client band steering に頼らずに SSID を分けたり切ったりする
である程度は…というところ。今年はあまり Wi-Fi 区間はリアルタイムにモニタリングしていなかったので、本当にこれでいいのかと思いつつも特に問題を感じないから良いのかなと思っています。client load balancing とかどれくらいちゃんと動いていたのかなあ。ここ数年は L3-L4 を主に見ていたので、来年は Wi-Fi またもう少し見てみても良いのかもしれません。会場で繋がりにくいなと感じた際にはTwitter #rubykaigiNOC ハッシュタグなどでご報告くださいね。
個人的にはスペクトラムアナライザを利用したサイトサーベイなどは全然できていないためこのへんに手を出したい気持ちがあります。いつも雰囲気で機材配置してる。
その他の取り組み
802.1X (WPA2/3 Enterprise)
Honeypot AP を防ぐため、また per-client encryption key のため、WPA2/3 Enterprise で 802.1X を実装していました。EAP-PEAP, EAP-TTLS によるパスワード認証で、全参加者で共有の資格情報でログインするという点ではこれまでの WPA2/3 Personal (PSK) での運用と変わりありません。
接続に際し手順がやや複雑になるのでどうなるかな、と思っていたものの、やってみたら 9 割程度は問題なく接続できていたようで良かったです。ただそのうちのどれくらいが盲目的に証明書を受け入れていたかどうかは分かりません。
証明書の CN を welcome.rubykaigi.org にして歓迎感を出してみていたんですが、これに気付いた人はいったいどれくらいいたんだろうか…
Public dashboard と timelapse
今回の Grafana はインターネットからログインせず public に見られるようにしていました *24。
あわせて、敷設撤収時の Grafana ダッシュボードのタイムラプスを録画していました。様子が見えてすこしおもしろい。
#rubykaigi #rubykaigiNOC Grafana time lapse Day 0 (Set up day) pic.twitter.com/41nZbag6XN
— そらは (@sora_h) 2023年5月14日
#rubykaigi #rubykaigiNOC Grafana time lapse Day 3 (Teardown day) pic.twitter.com/ydSmFgOC1S
— そらは (@sora_h) 2023年5月14日
DNS over HTTPS
DNS over HTTPS (DoH) をリゾルバで提供していました。詳細は下記の記事を参照してください。およそ ⅓ は DoH でクエリされていて、Apple デバイスの勢いを感じます。
今回は KMC の PI を利用して IP SAN を持った TLS 証明書を取得しましたが、DDR の現状の仕様だと IP SAN を持った valid な証明書が必要で、private IPv4 address 帯でデプロイするにはやや敷居が高いという印象です。
このデプロイメントについても https://github.com/ruby-no-kai/rubykaigi-nw にコードが存在しているので、眺めてみてください。
L3-L4 レイヤでの DNS リゾルバへの対応がいくつかありました。まず、IP SAN での証明書検証を正しく通すために SAN に入っている KMC の IP アドレスで DNS リゾルバの AWS NLB へ接続できる必要があります。AWS NLB に直接このアドレスを持たせることは困難 *25 です。そのため gw の downstream 側 interface で Static NAT を設定、outside (downstream側)にリゾルバのアドレス、inside に NLB のアドレスを指定していました (NAPT は internet 側, upstream で設定しているので、ここではユーザ側を外側ネットワークと認識させています)。
また、これは上記記事でも言及されている内容ですが、AWS VPC 内にデプロイした DNS リゾルバから権威サーバへのクエリは AS59128 のインターネット接続を経由させています。br で NAPT を有効にはしたくなかったため、Private IP address を持つ NAT Gateway を VPC で作成 *26 して専用のサブネットはこの NAT Gateway を default route にしています。NAT Gateway からは RubyKaigi PoP へ向くよう default route に vgw を指定、そして br のインターネット側 interface で Static NAT を実装していました。これは Terraform 上で onpremises サブネットとして定義されている内容です。
Acknowledgements
筆者 (id:sora_h) は主に L1-L4 の設計、L2-L4 の構築を担当していました。当日の L1 作業 (物理配線の敷設と撤収) の大部分は RubyKaigi 2023 NOC チームのみなさん に対応してもらいました *27。いつもありがとうございます。
加えて、冒頭の注釈で言及したように RubyKaigi の Wi-Fi 機材は殆どがスポンサーさまからの協賛費で購入したものです。最新機材やコンパクトな機材で揃え、機材の貸し借りで手配や返却が複雑・機材が不揃いになり運用が複雑になることを避けるために導入しましたが、これについては Wi-Fi Sponsor である弊社以外のスポンサーのみなさまのおかげです。RubyKaigi スポンサーのみなさま、いつもご支援ありがとうございます。
また AS59128 KMC へトランジットを提供していただいている AS59103, AS59105 のみなさまにも感謝します。
まとめ
RubyKaigi 2023 の Wi-Fi ネットワークにおける足まわりについて解説しました。
来年も id:sora_h は Wi-Fi NOC として活動する予定です。また同様の構成を取る見込みなため、この情報を踏まえて mtr や traceroute 結果を楽しむとよいでしょう。
また、この規模のネットワークに対して何かをデプロイして遊んでみたい、というような主体性のある NOC メンバーはいつでも歓迎です。興味があればお声がけくださいね。
あわせて読みたい
- RubyKaigi 2023の冷蔵庫は何だったのか - クックパッド開発者ブログ
- RubyKaigi 2023 では Rubyists on Rails 企画と Wi-Fi スポンサーに加えて実は冷蔵庫を提供していました。RubyKaigi 運営で松本ブルワリーさんにお願いしたビールを冷やすのどうしよう? と社内で相談したら Cookpad から冷蔵庫も提供することになりました。
- 実はこの冷蔵庫で動いている Linux box のネットワークや OS イメージのビルド・OTA まわりも id:sora_h が本業で製作したものです。バックエンドからエッジまで Ruby が動いている冷蔵庫になっています!
*1:Ruby Committers’ スポンサー (2017-2022) や Rubyists on Rails スポンサー (2023) も平行してやっています。Wi-Fi スポンサーは 2017 年から
*2:RubyKaigi の Wi-Fi 機材の大半はスポンサーのみなさまからの協賛金をもとにして RubyKaigi で購入所有しています。スポンサーのみなさま、ありがとうございます!
*3:RubyKaigi 2022 でもほぼ同様の構成を取っていました
*4:回線工事に立ち合って直後に計測した結果それぞれで inbound 100Mbps しかでず結構ひやひやしていた
*5:ただし、RubyKaigi 2022, 2023 ではバーチャル会場へのセッションのライブ配信を行っていたので、ここについては重要度が高いものになっていました
*6:Cookpad Japan では主に ECS が利用されていますが、たまには味変もいいよねというのと、Helm で雑に立てるのでいいか…という理由で EKS + Bottlerocket (Arm64 only) にしています
*7:RubyKaigi は地方開催を続けているためサービスエリアの都合選択肢に入ることはありませんが、サービスエリア内なのであればフレッツ光ネクスト, 光クロスを 1 本ずつ契約することで高い確度で別の機材に収容されることが期待できます。光ファイバについてはもしかしたら共用している部分があり、経路上の物理障害についてはどのみち運かもしれません
*8:private IPv4 prefix は IPsec VPN、それ以外は IPv4/v6 over IPv6 トンネル。ルータ負荷とMTUを考慮して IPsec の対象にするトラフィックを絞っていますが、IPsec だけでも今採用している機材なら十分性能が出るかもしれません (IX2215)。暗号化されないトンネルで利用するプロトコルについては IX シリーズだと IPv4/v6 over IPv6, EtherIP, GRE が候補になりますが、GRE はキープアライブなどやや複雑なので外し、EtherIP は RubyKaigi 2022 で採用していましたが、L3 ルーティングをするために Tunnel interface とは別に BVI interface を利用する必要があります。IX シリーズの IP over IP は 1 interface で v4/v6 dualstack にできないため、EtherIP でも IP over IP でも 2 interface 管理する必要があるのなら IP over IP の方がシンプルだなと思い直して今回はそのようになりました。
*9:traceroute して出てくる逆引き名にも出現していたと思いますが、気付いたひとはいるかな?
*10:正確にはキャンセルになった in-person の RubyKaigi 2020 の頃から AS59128 からのトランジットと番号資源の提供を予定していました
*11:はやく IPv6 outer の StS VPN をサポートしてほしい!
*12:余談: AWS re:Invent の会場 Wi-Fi も同じように public dxvif で Direct Connect してそうな雰囲気がありますね
*13:本当は RubyKaigi 2022 からそうなる予定でしたが、AWS 側の承認が間に合っていませんでした
*14:Cookpad の余剰ラックスペースや資源は RubyKaigi に加え、AS59128 にも貸し出しています
*15:設営時に余裕がなくてケーブルコスメが一切できてないまま運用に突入してしまったのが悔やましい。
*16:IX シリーズに IPv6 BGP のサポートが欲しい…
*17:5-tuple, per-flow ECMP であれば同じ flow は異なるパケットでも同じ宛先が選択されるため問題なく動きますが、障害などでルーティングテーブルに変動が起きたら TCP セッション等は普通に切れちゃいます
*18:ただし、VPC については AWS Direct Connect 経路を Site-to-Site VPN 経路より優先する経路制御をしているため、br-01.nrt に VPC 宛パケットが到着した場合は Direct Connect 接続をしている br-01.hnd にルーティングされます
*19:IGP は OSPF を起動。next hop self して IGP なしでも良いのかも…?
*20:ここではTCP/UDPなどflowを認識して外部からの新規着信を防ぐものを指します。NEC IX シリーズでは dynamic アクセスリストです。
*21:IPv4 インターネット宛通信は NAPT があるのである程度は落とされると思います
*22:FlexConnect を利用していないため、ただ制約と思っていた Peer-to-peer blocking が実は動きそうなので来年は変えるかもしれません
*23:冗長を組んでいるのでそれを信じるならばルータ同士の link は落としてしまっても問題は起こりづらいと思いつつも、Cisco WLC と AP を FlexConnect で運用してなかったりするので微妙なところ
*24:最近の Grafana には public dashboard 機能として一部だけ絞って公開することができるようになっていますが、Weathermap plugin などが未対応だったりするため Grafana 自体を公開、非公開にしたい data source は org を分けることで対応していました
*25:2 AZで利用することを考えると /28 ブロックを KMC の IP アドレスから追加で VPC cidr と subnet へ 2 つ追加する必要があり、番号資源を消費してしまう。もしくは何かしらで Static NAT を EC2 で実装。
*26:2021 年末頃から NAT Gateway は Internet gateway と EIP を必須とせず、private IP を outer address とすることができるようになっています
*27:id:sora_h は RubyKaigi 2021, 2022, 2023 で用意したバーチャル会場や配信の面倒を見ているので、そちらにも手を持っていかれがちのため…
