ほぼ全員NOC未経験！学生チームがNaniwaNOG 3の会場ネットワークを支えてみた

はじめに

2025年8月29日、滋賀県大津市のピアザ淡海（ピアザホール）でNaniwaNOG 3ミーティングが開催されました。関西のネットワーク技術者が一堂に会するこのイベントで、前回に引き続き、学生を中心としたNOCチーム "Team Shirankedo" が会場ネットワークの構築・運用を担当しました。本記事では、キックオフから本番当日までの活動を、バックボーン（BB）・アクセスポイント（AP）・サーバー（SV）の各チームの取り組みを中心に、学生リーダーを務めた近畿大学の温井がご紹介します。各チームのパートは、実際に作業を担当したメンバー（BB：後藤、AP：岡野・好本、SV：上村）が執筆しました。

NaniwaNOGについて

NaniwaNOG（Naniwa Network Operators' Group）は、インターネットにおける技術的事項やそれにまつわるオペレーションに関する事項を議論・検討・紹介することで、関西エリア（近畿2府4県）を中心としたインターネット技術者および利用者に貢献することを目的としたグループです。年2回開催されているJANOG Meetingをベースに、開催地を特定地域に絞った「地域NOG」が近年各地で立ち上がっており、NaniwaNOGもそのひとつです。3回目の開催となる今回は、203名が参加しました。

Team Shirankedoについて

Team Shirankedoは「失敗してもOK。なんか上手く行ったわ、知らんけど。」を合言葉に、ネットワーク構築に興味を持つ初心者が気軽に取り組める環境を目指して発足したNOCチームです。前回のNaniwaNOG 2ミーティング（2024年10月・姫路）で初めて会場ネットワークの構築を経験し、今回が2回目のNOC活動となります（前回の活動は「NaniwaNOG 2ミーティングで会場ネットワークをゼロから構築してみた」をご覧ください）。

今回のNOCは、学生リーダー2名（丸岡・温井）を中心に、バックボーンを担当するBBチーム2名、Wi-Fiを担当するAPチーム2名、サーバー・監視を担当するSVチーム3名、そして全体をサポートしてくださる社会人メンバー2名という体制で活動しました。メンバーの大半はNOC未経験の学生です。

7月18日のキックオフMTGで顔合わせと役割分担を行い、さくらインターネット本社をお借りして開催した複数回のオフライン会、本番前日のホットステージを経て当日を迎えました。準備期間は約1か月半。オフラインで実機を触れたのは3日間、ホットステージと本番を合わせても計5日間という短期決戦でした。

ネットワーク全体構成

今回構築したネットワークは、ルーター1台、L2スイッチ1台、DNS/DHCPサーバー兼作業用のミニPC1台、AP6台という非常にシンプルな構成です。「来場者が確実にインターネットへアクセスできること」を最優先に、経験の浅いメンバーでも全体を把握できる無理のない設計を心がけました。

各チームの役割分担は次の通りです。

• BBチーム：ルーター・L2スイッチの設計とコンフィグ投入、ACLの設定・確認
• APチーム：Cisco Meraki MR44によるWi-Fi提供（eduroam・OpenRoamingを含む）と運用ツールの開発
• SVチーム：ミニPC上のDNS・DHCPサーバー構築と、さくらのクラウド上の監視基盤の構築

バックボーン（BBチーム）

（執筆：後藤）

オフライン会での準備

バックボーンの機材には、NOCをサポートしてくださった社会人メンバーの私物ルーター・スイッチをお借りしました。オフライン会では、まずネットワーク構成やIPアドレスの振り分け方を決めた後、実際に使用する機器にコンフィグを投入して動作確認を行いました。ネットワーク設計・構築の経験があるメンバーが少なかったため、基礎的な部分から一つずつ確認し、全員が理解できるように進めました。

ホットステージ・本番

ホットステージでは、事前に確認していたコンフィグをもとに、ACLの設定内容を確認しながら、学生リーダーの丸岡さんが用意したコンフィグと照らし合わせて作業を進めました。

当初の設計では、ミニPCをDHCPサーバーとして稼働させ、ルーターはDHCPリレーエージェントとして動作させる予定でした。しかしホットステージで、無線接続時にミニPCのDHCPサーバーからIPアドレスが割り当てられない事象が発生。切り分けの結果、最終的にはルーターをDHCPサーバーとして使用する構成に変更することで解決しました（後日の振り返りで、VLAN設定に起因する問題だったことが分かりました）。設計通りに動かないときに、その場で構成を判断して切り替える経験ができたのは大きな収穫でした。

Wi-Fi（APチーム）

（執筆：岡野・好本）

Cisco Meraki MR44によるクラウド管理

会場に設置するアクセスポイントには、京都大学様よりご提供いただいたCisco Meraki MR44を6台使用しました。この場をお借りして厚く御礼申し上げます。

Merakiはクラウド管理型のAPで、通常のネットワーク機器のように機器へ個別にログインして設定するのではなく、クラウド上のダッシュボードで一括設定し、全APへ自動反映できます。新しくAPを設置する際も、電源とインターネットにつなぐだけでAP自身がクラウドから設定を取得して適用してくれるため、構築の手間を大幅に削減できました。ダッシュボードからは各APの稼働状況やアクセスログの確認、接続状況を表すヒートマップの作成もでき、監視機能も充実しています。
会場では通常の無線LANに加えて、eduroamとOpenRoamingを提供しました。eduroamの認証には京都大学様のRADIUSサーバを利用させていただきました。こちらも厚く御礼申し上げます。

Meraki APIを使った運用ツールの開発

AP自体の設定は最初のオフライン会でほぼ完了したため、2回目以降のオフライン会では、Meraki APIを活用した運用ツールを学生2人で手分けして開発しました。

• APごとの接続台数をリアルタイムに通知するSlackBot（Pythonで実装し、さくらのクラウド上のVMで稼働）
• APごとの稼働状況や接続台数をブラウザ上で可視化するWebアプリケーション

Meraki APIとSlack APIの両方に触れることになり、大変よい勉強になりました。

ケーブル作成と設置作業

最後のオフライン会では、スイッチからAPまでを接続するLANケーブルの成端作業も行いました。初めての成端で、被覆を剥いて撚り線をほどき、RJ45に差し込んでかしめるまでかなり時間がかかりました。中には45mというかなり長いケーブルもあり、経験したことのない8の字巻きに大苦戦。いったんすべてほどいてから巻き直すという地獄の作業も経験しました。

前日の設営では、学生リーダーが考案した設置表に従い、譜面台の上に養生テープで固定する方式でAPを配置し、会場中を行き来してケーブルを這わせました。MR44はPoE対応のため電源ケーブルが不要で、設置がとても楽でした。会場の外に設置する1台が扉の開閉と干渉する問題が発生し、その場で短いケーブルを作り直すなどの現場対応も行いました。途中、APがMerakiクラウドに到達できないトラブルもありましたが、最終的にはすべてのAPから会場用Wi-Fiを提供できました。

当日

本番当日は、Wi-Fiが落ちないことを祈りながら講演を聞いていました。作成したSlackBotやWebアプリもしっかり稼働し、休憩時間には廊下のAPへの接続台数が増える様子がヒートマップで見えるなど、人の流れが分かって面白かったです。イベント終了後はすぐにAPとケーブルを回収し、お借りした機材がすべて揃っていることを確認して返却しました。

サーバー・監視（SVチーム）

（執筆：上村）

SVチームは、現地に設置したミニPCと、さくらインターネット様にご提供いただいた「さくらのクラウド」の2か所にサービスを構築しました。現地のミニPCにDNS・DHCPサーバー、さくらのクラウド上に監視基盤を置く構成です。

DNS

ミニPC上にDockerエンジンを用意し、Unboundのコンテナを構築しました。コンテナで構築しておくことで、いざというときはコンテナを破棄すれば初期状態に戻せるため、準備期間中に高速でトライアンドエラーを回すことができました。

DHCP

DHCPサーバーにはKea DHCPを採用しました。リース情報の管理にデータベースを導入し、サーバーを再起動してもリース状態が失われない構成にしています。Ubuntu上で稼働させる際にAppArmorとケンカするなど一悶着ありましたが、無事に動作させきりました。

監視基盤（PLGスタック）

監視には比較的モダンな監視スタックであるPLGスタック（Prometheus / Loki / Grafana）を採用しました。ネットワーク監視ではZabbixやNetFlowがよく使われますが、PLGスタックを使うことでログとメトリクスの相関分析が簡単に行えます。

• Prometheus：ネットワーク機器のSNMPメトリクスをsnmp_exporterで、ミニPCやクラウド上のVMのメトリクスをNode Exporter・Container Exporterで収集・蓄積
• Loki：UnboundやKea DHCPのログを収集し、日時やサービス名でラベル付けして保存
• Grafana：メトリクスとログをまとめて可視化

さらに、監視基盤自体が不調に陥った場合に備えて、UptimeKuma（クラウド上のVMからミニPCを外形監視）とMackerel（外部サービスによるクラウドVMの監視）の予備系統も用意しました。

振り返り（KPT）

本番終了後、チーム全体でKPT形式の振り返りを行いました。その一部を紹介します。

Keep（良かったこと）

• 提供したネットワークがきちんと使えるものになり、大きなクレームもなかった
• ケーブルの断線など物理面の大きなトラブルが発生しなかった（前回は多くのケーブルが断線していたので、大きな進歩！）
• さくらのクラウドを自由に使えたため、テスト環境をすぐに用意できた
• 参考資料や手引書が共有されていて、一人でも作業を進めやすかった

Problem（課題）

• さくらのクラウドと会場との接続設定が遅れ、監視を十分に活かしきれなかった
• 無線接続時にIPアドレスが割り当てられない問題の切り分けに時間がかかった（原因はVLAN設定だった）
• 必要な情報がSlackやGoogle Driveに分散していて、探すのに時間がかかった

Try（次回に向けて）

• 本番前にできるだけ事前の結合試験を行う
• 定期的にオフラインで集まり、実機に触れて知識の定着を図る
• リンク集を整備して情報を見つけやすくする

まとめ

ほぼ全員がNOC未経験の学生というチームでしたが、それでも会場の皆さまにご満足いただけるネットワーク環境を提供できたことは、大きな自信になりました。ネットワーク機器に直接触れて設定や操作を行う中で、理論として学んだ知識が現実の環境でどう活かされるのかを実感でき、ネットワークへの興味がより深まった準備期間・本番でした。

最後になりましたが、AP（Meraki MR44）とeduroam用RADIUSサーバをご提供くださった京都大学様、さくらのクラウドとオフライン会の会場をご提供くださったさくらインターネット様、NaniwaNOG 3運営の皆さま、共に学生リーダーとしてチームを引っ張ってくれた丸岡さん、そして当日会場でWi-Fiをご利用くださった皆さま、本当にありがとうございました。この経験を糧に、次回のNaniwaNOGではさらに良いネットワークをお届けできるよう精進していきます。それでは、また次のミーティングでお会いしましょう！