JANOG57 NOCに参加しました

2026年4月12日

JANOG57 NOCに参加させていただきました！！

京大マイコンクラブのほうにもブログ出ていますので、
こちらも合わせて見てください！
また、チームメートであるwuhu1slandさんの記事もぜひご覧ください！

https://github.com/janog57-noc/janog57-infra から公開されているコンフィグをご覧いただけます。

JANOGとは

Japan’s Network Operators’ Groupの略で、
ネットワーク界隈の人間たちが集まり、いっしょにわいわいする会です。
たくさんの企業さんがブースをやったり、ライトニングトークをやったり、講座をやったりします。

ブースたちの様子です：

booths

今回参加したのはJANOG57です。
場所は大阪だったので行きやすかったです。
（こういう系のイベント関東に開催されがちですよね（泣））

JANOG NOCとは

JANOG NOCというのは、
イベント会場のネットワークについて設計から構築、運用、撤収までを行い、 来場者にWi-Fiを提供する拠点のことです。
今回はServer、AP、Cable、Backboneの4チームに分かれており、
それぞれのチームにたくさんの学生や社会人が参加していました。

今回、僕はwuhu1slandさんとServerチームに入り、DHCPを担当させていただきました。

NOC部屋はこのような感じでした：

noc-room

DHCPとは

スマホがWi-Fiネットワークに繋がると、
ローカルIPアドレスが振ってきます。
繋がったクライアント（デバイス）はそれぞれのローカルIPアドレスを持っており、
これらのデバイスに通信するためにルータがローカルIPアドレスを使います。

こうしたローカルIPアドレスはどうやって振ってきたのかというと、
DHCPサーバが割り当てているのです。

ざっくり説明すると、ステップは4つです：

DHCPDISCOVER: クライアントがDHCPDISCOVERというパケットを送ります。「DHCPサーバさんいらっしゃいますか？IPアドレスほしいです！」と。
DHCPOFFER: DHCPサーバが送ります。「います！192.168.1.xxでいかかでしょうか？」と。
DHCPREQUEST: クライアントが送ります。「じゃあ192.168.1.xxでお願いします！」と。
DHCPACK: DHCPサーバが送ります。「了解です！192.168.1.xxですね！1時間お貸し出しします！」と。

DHCPについてふわっと理解いただけたのでしょうか？今回やったことを紹介していきます！

事前作業

2025年11月頃から作業を進めていきました。最初はDHCPについて調べ、仕組みを学びました。
チームリーダであるcrashRTさんからも、DHCPの仕組みを、パケットの中身まで詳しく丁寧に教えていただきました。

知識を入れるフェーズが終わってからは、チームリーダからタスクをもらい、作業を進めました。

実装にはプロトコル的な知識だけでなく、ソフトの使い方についても知らねばなりません。
JANOG57のホストであるさくらインターネットさんからのクラウド環境で試行錯誤などを行い学んできました。

別にすでに全部わかっていて詳しかったわけではなく、ネットで調べながらやるみたいな感じでした。

Kea

今回の構築においては、KeaというオープンソースのDHCPサーバのソフトを使いました。
まともなオープンソースのDHCPサーバはKeaぐらいしかないらしいです。

意外とサーバそのものを立てて動くまでの作業はそこまで難しくはなかったんですよね。
（サーバ作業あるあるなのかな。）
難しかったのは、configの調整でした。
必要に応じてサブネットの設定をしたり、細部を調整したりしていました。

負荷試験

何千人もネットにつながるという想定で、負荷試験を行いました。
perfdhcp で性能を計りました。

perfdhcp -r 100 -R 1000 -t 1 <IPアドレス>

などとして、性能計測をしました。
有線LANで繋いでいると余裕で秒にリクエスト1000個耐えられますが、
Wi-Fi越しだと1000個までは行けなかったですが100個ぐらいは耐えられていました。

性能計測をした時のStorkからみたリース状況のスクショです：

stork

これは、負荷試験でクライアント数の設定をミスって、
リースを枯渇させてしまったときのリースの円グラフです。
全部真っ赤でUsedになっていてなかなか珍しいですよね（笑）

ログ

ログの出力にも工夫をしました。
ログ班に渡せるようにsyslogにしながら、ローカルに控えのログも残すようにしました。
また、あまり重要ではないログ、
例えばStork（Kea DHCP専用のウェブのダッシュボード的なもの）から問い合わせが来たときに出るログなどは、
別のファイルにしました。

Ansible用の {% raw %} が入ってしまっていますが、/etc/kea/kea-dhcp4.confからの抜粋：

"loggers": [
    {
        "name": "kea-dhcp4",
        "output-options": [
            {
                "output": "kea.log",
                "pattern": {% raw %}"%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i.%t] %m\n"{% endraw %}
            },
            // 出力先を複数指定します！！
            {
                "output": "syslog",
                "pattern": "%-5p [%c.%t] %m\n"
            }
        ],
        "severity": "INFO"
    },
    {
        // Stork から command がやってきたときなどに使われます。
        // あまり重要ではないので別の log file にします。
        "name": "kea-dhcp4.commands",
        "output-options": [
            {
                "output": "kea-dhcp4.commands.log",
                "pattern": {% raw %}"%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i.%t] %m\n"{% endraw %}
            }
        ],
        "severity": "INFO"
    },
    {
        // あまり重要ではないので別の log file にします。
        "name": "kea-dhcp4.host-cmds-hooks",
        "output-options": [
            {
                "output": "kea-dhcp4.host-cmds-hooks.log",
                "pattern": {% raw %}"%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i.%t] %m\n"{% endraw %}
            }
        ],
        "severity": "INFO"
    },
    {
        // 別の log file にします。
        "name": "kea-dhcp4.subnet-cmds-hooks",
        "output-options": [
            {
                "output": "kea-dhcp4.subnet-cmds-hooks.log",
                "pattern": {% raw %}"%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i.%t] %m\n"{% endraw %}
            }
        ],
        "severity": "INFO"
    }
]

出力先を複数指定する方法はドキュメントに記載がなかったので、試行錯誤でこのような書きかたするとできると知れました。

いよいよ本番

いよいよ本番になりました！

✨ やらかし話をします！

初日の朝10時にさっそくやらかしました！
dhcp-1とdhcp-2のそれぞれのリース数を監視していたら、
「dhcp-1と-2のリース数がすごく傾いてんな。リースをリセットしてみよっか」と思い、
isc-kea-dhcp4-server.service を停止し、リースファイルを削除し、再び立ち上げてしまいました。
（サーバの再起動はしていません。）

systemctl stop isc-kea-dhcp4-server && \
rm /var/lib/kea/kea-leases4.csv /var/lib/kea/kea-leases4-2.csv && \
systemctl start isc-kea-dhcp4-server

そう、本番でもサービスを止めちゃってもいいと勘違いしてしまいました。

別に来客に支障は出ていなかったのですが、下手したら出た可能性がありましたよね。
1時間後「リースのグラフはここに急に0になっちゃったのなぜ？」のような質問が来たので
正直に答えたらproductionではサービス中断が起こりうる事は勝手にやったらマズいと知りました。
「やる前には相談を」と。
Productionではあまり触らない方が吉だと、なんとなく思ってはいましたが、
「リースファイルを削除するのって一瞬だけだし、
DHCPの仕様上ではこのようなことに対しても対策はされているしまぁいっか」と
思い込んでしまってこのようなことをやってしまいました。
※ DHCPサーバの仕様上は対策はされていますが
　もちろん負担がかかったり渋滞したり何十秒間は重くなったりするのでよくはないです。

fuckup

※ 左、中、右のグラフは会場それぞれのサブネットのリース数を示しています。

今度からはサービス提供中はサービスを止めるなどを行う前にチームリーダに相談するように心がけます｡ﾟ(ﾟ´ㅅ`ﾟ)ﾟ｡

リース数が傾く

先ほども述べたように、dhcp-1とdhcp-2のリース数の比率が傾いていました。
dhcp-1とdhcp-2どちらもクライアントにDHCPOFFERを送りますが、
クライアントは一番早く来たほうを選ぶような実装が一般的です。
何かよくわからない原因でdhcp-1のほうの返信が早いという状況になっているので、
割合を均一にすることは難しいらしいです。

感想

このような大きなイベントの裏側をまわることは初めてで、いろいろ学ばせていただきました。
最初は「ド素人で貢献できるのかな」のような懸念を抱いていましたが、
ちゃんと貢献できて良かったです！

今回の経験で自分の不足に気づきました。
まだ分からないことがたくさんあると。
これからもサーバを詳しくなっていきたいと思いました。
サーバ力を磨いていきます。
もっと貢献できるようになりたい。
もっと自発的に作業を進められるようになりたい。
という感情を忘れずに学習していきたいと思います。

もう一つの収穫がありました！日本語力が伸びたかもしれないことです！
もう少し自信を持って話せるようになりました！
新しく学んだ言葉もかなりありました！
思い出して箇条書きにするのはやっぱり難しいのですが
「静観」「ふんわり仕様」「まとも」「冗長」
などを知りました。

感謝のひとこと

今回のサーバチームリーダである、京大マイコンクラブの先輩でもあるcrashRTさんに感謝です！
手厚くサポートしていただきました！ありがとうございます！
crashRTさんなしには僕はNOCはおぼつかなかったです。
DHCP班のチームメートのwuhu1slandさんにも感謝です！
いつも作業を進めていてくれてありがとう！