2023/7/5 - 7/7に、長崎市の出島メッセにてJANOG52 Meeting in NAGASAKIが開催された。私はNOCチームメンバーの一人として、会場ネットワークの設計構築、運用、撤収に参加。貴重な経験を積んだ。
JANOGをはじめとする大規模イベントのNOCに参加したのは、2年前のJANOG49が初めて。今回のJANOG52は、私にとって2度目のNOC経験となった。
経験したことを忘れないうちにまとめたいと思う。
参考資料
この記事はあくまで個人の日記として残しているものなので、前提情報を知らない人が読んでも、何を言っているかさっぱりだと思う。
JANOG52の会場ネットワークについては、プログラム発表のプレゼン資料や、佐々木氏のnote記事を読んでもらうと全体がつかみやすいと思うので紹介する。
参加日程とか
NOCに応募して採用通知が来たのが4/14。それから本番までの間、何度か全体ミーティングやったり、チームでミーティングやったり。ホットステージが近づくと、チームでのミーティングの頻度も増えたり。
私のいたL2L3チームは、ホットステージ前に週2でミーティングしていたけど、他のチームに比べても結構高頻度だったみたい。他のチームを見渡せばアクティブにどしどしコミュニケーションを取っているチームもいたけれど、うちは大人しいメンバーが多いチームだった？ような印象があるので、高頻度でミーティング取る戦略は正しかったかも。非同期でSlackでメッセージ打ってると中々聞けないようなことも、ミーティングだとさらっと質問できたりするからねぇ。
現地参加の日程はちょっと厳しかった。
・ホットステージ: Day1 - Day3
・土日 - 現地滞在者同士で交流会+長県大見学会
・機材搬入日: Day -1
・設営日: Day0
・JANOG本番: Day1 - Day3
という全体スケジュールの中で、参加できたのがホットステージのDay2と、設営日のDay0、JANOG本番の3日間。合計5日間しか参加できなかった。
講義を色々取ってたので、講義になるべく穴を開けずに、現地参加もなるべく多く...とバランスを取るとこうなった、という感じ。でも結局、Day3の日もDay-1の日も学校休んじゃったし(大寝坊した)、本番までのスケジュールはきつかったなぁ...。
現地では、L2スイッチ周り触ったり、人がトラブル対応してる所にお邪魔して検証手伝ったり、カメラ持って行っていたので写真撮りまくったり。Day3の後は(私にしては珍しくw)飲み会に参加したり。
「JANOGを全力で楽しむぞ！」という目標で参加したけど、ネットワークチームの立場としては一通り、最初から最後まで通して参加できたので良かったんじゃないだろうか。
なぜL2L3チームに参加したのか
L2L3チームに参加した動機は単純で、「JANOG49ではサーバー触ったので他のことをやりたかった」という動機が7割。隣の芝生は青く見えるというやつで、サーバー以外の作業に興味があった。
プログラム書いたり、面白いもの考えて作ったりするような創造性の高いことは他の人に任せた方が楽しいものができそうだなぁ、という思いも3割くらいを占めていた。やっぱり、裏方的なことをやるのがどうしても好きなんだ。
そんなこんなでL2L3チームに手を挙げたのだが、結果的には自分にピッタリ合っていたといえるのではないだろうか。
時系列まとめ
もう覚えてない...。あまりに激動の2週間すぎて全く記憶に残らなかった。
備忘録として、覚えている部分だけ書き出してみる。
HotStage Day2
怒涛の日帰りスケジュール。朝8時台に長崎について、朝マック食べて会場に駆け込んだ。
現地ではすでに上流側開通済み。L3SWキッティング中、L2SWとりあえず1台コンフィグがざっくりできつつあった。
私の作業としては、L2SWの2台目以降を一通りさわり、既存のコンフィグがどうなってるのかザックリ理解し、まず2台目をキッティング。他のスイッチも他のメンバーが作ってくれたりした。
出来上がったNW機器をMDFとかEPSに置きに行ったり。
1日の作業の終わり際、チームのみんなが駄弁っているあいだにもう1台のスイッチのコンフィグを流し込みながら、キッティングに使うコンフィグの流し込み用雛形を作っちゃった。勢いだけで作っちゃったこの雛形だが、翌日私が居ない間に、コンフィグの流し込みに有効活用されたみたい。かなり嬉しい。
そのあと集合写真撮って解散。
列車予約の勝手がわからず、切符をネット予約だけして受け取らずにおいたら「間に合わないぞ急げ！！」ってめっちゃ焦らせてしまった。切符の受け取りは早い方がよい(当たり前だ)
Day0 (会期前日)
この日も朝から長崎着。
設営日。この日はL2L3チームとしてはあまりやることがなかった。ネットワーク自体は完成形にほぼ近い状態で動いていた。他のチームの手伝いをしたり、会場の養生だったり配線だったり、チーム外の仕事の配分が高かった記憶。
EPS室にスイッチを置きまくったり、足元注意の虎テープを貼ったり。大人メンバーの方が無限にドーナツの差し入れをしてくれたりｗ。
この日は忙しいメンバーが多かったのか、作業中の写真を撮った人が少なかったので、写真をたくさん撮っておいてよかった。
Day1 - Day3（会期中）
この日から記憶がだいぶ薄い。
初日は、無事に動き出したネットワークを眺めていたくらいで、あまり出番はなかったようなそんな記憶がある。私たちとは別のサーバーチームは、この日のハッカソンで監視まわりを一気に仕上げたりしていて、無事にハッカソンに優勝したけど、別の発表があるからといって優勝者プレゼンを辞退しただとか、そんな話を聞いたり。それで1日が終わったようなそんな記憶がある。
2日目は展示ブースとか見に行ったり、JANOGの夕べに参加したり。JANOGの夕べは人があまりに多すぎてちゃんと楽しみ切れなかったなー...。
3日目は会場NWに異変が起こった。来場者Wi-Fiがつながりにくいという話が入って、調べてみるとNATテーブルが溢れていたらしい。余計な所に影響を与えないよう、昼休みにNAT関連の再設定が行われた。
ここまでノートラブルでネットワークが運用できていたので、トラブルに見舞われたのはとても惜しかった。最も重要性の高いストリーミング配信には影響がなかったのが不幸中の幸い。トラブル対応風景は勉強になった。
午後にはネットワークチームのプログラム発表があった。一番楽しみにしていたプログラムの一つでもあった。
登壇風景の写真を取るつもりでカメラを持ってきたけど、思いの外キレイには取れなかった...。
3日目の後は大急ぎで撤収。スイッチやルーターを開梱したときの物品管理が甘く、梱包作業にえらく戸惑った。結果、梱包は無事に終わったけど、物品管理は私もリモートで後方支援してあげるべきだったかなぁと反省。
3日目の後は飲み会に参加して、ホテルで後泊して、翌朝無事に寝坊して、あわててホテルをチェックアウト。
雨も降っていたし、お財布がカツカツだったし、疲れていて人と会うエネルギーもなかったので、3日目の翌日は本当に何もできなかった。新幹線を夕方の予約にしていたけど、お土産を買う以外はただひたすらに暇つぶしするばかりだったのが勿体なかった。
反省とか
個人的な反省としては、JANOGというイベントを本当に楽しめたのか？という点では疑問が残る。きちんとセッションを見たりすべきだった。展示ブースも回ったけど、名刺を準備していなかったので出展社さんの名刺をもらうばかりだった。
あとはスケジュールというか個人の能力の問題でもあるんだけど、大学の授業に追われていて事前に自分なりにネットワークのこと勉強したり、設計に関与したりといったことは十分には出来なかった。マルチタスクが上手な人はちゃんと授業と両立できると思うが、あくまで個人差。次の機会があれば、余裕あるときに勉強や質問、意見交換など頑張っていきたい。
今後の展望
今回得られた経験をこの場限りにすることなく、他のイベントNOCなどにも生かしたいと考えている。できればさっき書いたとおり、設計にもガンガン首突っ込めると良いよなぁ、と。
興味のあるイベントに参加して、肩書きも技術経験も増やしていくことで、自分にとっても企業さんにとっても「強み、弱み、興味」がはっきりするようになれば、就活にもつなげていけるかなぁ、なんて考えている。
個人的に感動した技術
今回、実験ネットワークのひとつとして「IPv6-mostly Access Network」が運用された。
「IPv6-mostly...(略) 」なんだか聞きなれないワードだが、日本語に訳すなら「主としてIPv6を用いるアクセスネットワーク」とかそんなところだろうか。ChatGPTに聞いたら「IPv6主体のアクセスネットワーク」という、イケてる訳を考えてくれた。さすが。
このネットワークは、IPv4/IPv6デュアルスタックネットワークの一種である。ただし、
・IPv6対応
・NAT64対応（なおかつCLAT対応？）
・DHCP Option 108 (RFC8925) を通知する
の3つの条件を満たす端末には、IPv4アドレスが払い出されない。代わりに、NAT64を経由してIPv4インターネットに出てもらう。
端末からみると、IPv6アドレスしか割り当てられていないにもかかわらず、Twitterのような、IPv4のみに対応するコンテンツにもアクセスができるという不思議な状況を実現できる。
今までのIPv4/IPv6デュアルスタックネットワークは、IPv4シングルスタックネットワークを構築・運用するのと比べて負担が増大するという面が大きかった。
IPv6対応コンテンツへのアクセス時には、トラフィックをIPv6にオフロードできるため、IPv4シングルスタック構成と比較してNATの負担が減るというメリットは挙げられる。かといって、DHCPプールの払出しが減るわけでもない。
今回の手法では、対応端末に対してIPv4アドレスを払い出さずに済むようになるため、DHCPプールの払出し数を削減できる。また、IPv4コンテンツへのアクセス時に、従来は必ずIPv4 NATを経由していたが、今回の手法では、対応端末からIPv4コンテンツへアクセスする際はNAT64を経由することになる。IPv4 NATへのアクセス集中を緩和できる点も、単純なIPv4/IPv6デュアルスタック構成と比較した長所だろう。
会場で構築されたIPv6-mostly Networkは安定動作しなかったが、新しい技術ゆえに安定運用のためのノウハウが蓄積されておらず、不安定要素が残るものと捉えている。したがって、私はあまりこの点を気にしていない。
IPv6アドレスの割り当てのみでIPv4コンテンツにアクセスできるという体験が非常に新鮮であった点と、IPv4の運用を徐々にフェードアウトさせていく道筋が見えたという2つの面で、インターネットの未来を垣間見られたように思う。個人的に、とてもよい刺激をもらった。
私の環境でも、IPv6-mostlyに限らず、IPv6まわりを沢山実験したい。どのようなテーマがあるか色々考えている。
