即席チームでJANOG57 NOCを立ち上げる。GitHubバーンアップチャートと、管理用ネットワークアクセスが隠した盲点

公開日

はじめに

JANOG57 NOC Backboneチームでスクラムマスター的な動きをしていたhokkai7goです。

JANOGとはJApan Network Operators' Groupを意味し、インターネットに於ける技術的事項、および、それにまつわるオペレーションに関する事項を議論、検討、紹介することにより 日本のインターネット技術者、および、利用者に貢献することを目的としたグループです。

JANOG57は2026年2月11日（水・祝）～2月13日（金）の日程で大阪市で開催されました。5000人以上の来場がありました。

JANOG57 NOCは、JANOG57の会場で快適なネットワーク環境を提供するために結成されたボランティアベースのチームです。 NOCはBackboneやServer、Access Point、Cable、NOC Liveと複数のチームで構成されています。私はその中でもBackboneチーム所属でした。Backboneチームは各会場に数多く配置されたアクセスポイントやサーバーを動かすためのインターネットへの出口と、各拠点間を繋ぐL2/L3の基盤を提供することがミッションです。

個人的にはBackboneチームになったのがうれしかったです。というのも、縁の下の力持ち的なポジションが好きで、仕事ではWebインフラやSREが好きですし、音楽ではベースやドラムが好きです。なので今回Backboneチームかつ表に出るよりも支える側の立場だったことを、とても良いと感じていました。

JANOG57 NOCの活動については、以下で情報公開される予定です。

https://noc.janog57.ishikari-dc.jp/
https://noc.janog57.ishikari-dc.jp/noclive/

NOC LiveはNOC作業の様子や監視ダッシュボードの様子をYouTubeにて配信していました。興味のある方は見てみてください。

背景

JANOGのNOCは毎回同じメンバーや組織で編成される訳ではありません。JANOG57ではホストであるさくらインターネットのメンバーを中心としてNOCが編成されました。

https://www.janog.gr.jp/meeting/janog57/noc

全体リーダー、各チームのリーダーは先に決まっており、各メンバーは下記のタイミングで募集されて決定されました。

  • メンバー募集 2025/10/17
  • 採用の連絡 2025/11/3

NOCのメンバーとして採用された時点で3ヶ月程度の時間しか残されていない状況でした。プロジェクト管理においてこのスケジュール感は非常に大事なポイントでした。短時間でチームと会場ネットワークの設計・設定を立ち上げる必要がありました。

会場の制約と全体ネットワークの構成

下にNOC公式ページに記載されている会場の図を示します。

コングレコンベンションセンターと、JAMBASEと呼ばれる複数の会場がありました。それぞれ管理が違うため会場に引き込むことができる回線は別のものとなりました。これらをつなぐバックボーンとしてOCX(BBIX/BBSakura Networksが提供する「Open Connectivity eXchange」という閉域網クラウド接続サービス)が活躍しました。

また、会場の制約により既設のネットワーク設備を使わざるを得ない箇所がいくつかありました。特殊な構成が必要となった部分もありました。帯域制御をできるだけかけたくなかったのですが、JAMBASEに関しては既設のネットワーク設備の上限が1Gbpsであったことと、来場者のトラフィックと配信トラフィックが同じ回線に流れたことなどからDAY1終了時に帯域制御を入れることとなりました。

コングレコンベンションセンターに関しては会場の既設設備がVLANタグを通さないため、パケットを別のIPパケットにカプセル化（EtherIP）して転送する、というテクニックを使いました。

プロジェクト管理とタスクの進め方

他のチームのことは詳しくないのですが、Backboneチームの特徴としては以下のものがありました。

  • 即席チームで、期間限定かつ居住地も異なり、集まるのが難しい状況でした。
    • 仕事のチームなら数年一緒にいることもありますが、今回は11月に結成し2月には撤収する『解散前提の短距離走チーム』でした。
  • 会って話したことがなくスキルレベルのわからない人を巻き込んでタスクを進める必要がありました。

過去のJANOG NOCではBackboneチームと別にL2/L3チームを編成することがあったようです。今回のJANOG57 NOCではBackboneチームがL2/L3も担当しました。当初はBackboneチーム内に主にOCXを扱うBackbone小チームと、L2/L3小チームを編成しました。ですが、年明けくらいからはこの小チームの分け方は意味のないものになったように感じました。スキルレベルの高いメンバーは複数タスクを抱えることになり、タスクアサインが小チームのメンバー構成と一致しない状況になったためです。タスクアサインについては常に悩みがありました。学生メンバーに経験を積んでもらいたい気持ちはありますが、仕事と違ってフォローの体制が整っていない状況かつ、スケジュールのプレッシャーがあるため経験を積んでもらうことを重視するのも難しかったからです。

上記の特徴は仕事では経験しにくいものと思います。プロジェクト管理の観点では下記の工夫をしました。

  • GitHub Projectsで作業を計画・追跡可能にしました。
  • Issue Templateを作成し、なぜやるのか、何をやるのか、（主にリーダーに）ゴールは何かを極力書いてもらうようにしました。その上で自分は個別Issueに着手せず全体を見るようにしました。
  • 最初にスケジュールを逆算して年内にあらかた設計を終わらせ、年始になったら作れるところから実装開始、直前2-3週間は調整と決めてリーダーと合意しました。
  • 時間がないので1週間を1Iteration(タスク処理単位の期間のこと)で回すことにしました。2週間のIterationにして進捗がなかった場合、短期間のプロジェクトのため、遅れに気がつくのが遅くなったり、遅れを取り戻すのが難しくなると考えたためです。
  • 数日更新がなく動いてないIssueについては自分が巡回して状況どうなっているかなど声掛けをしました。各メンバーそれぞれ本業の学業や仕事や生活があり、日々進捗を出すのが難しいときがあることは承知の上でした。そのため手厚く確認を行いました。
  • 設計議論はSlackやGitHub Issuesで非同期で行い、決定した内容をSharePoint上の設計ドキュメントに記載していく形となりました。議論が分散するため決定内容をまとめる必要や、未決のものを決めるために議論を促しました。
  • 各チームのオフライン作業会がさくらインターネット本社で不定期に開催されていました。他チームメンバーとの会話機会を作るためや、オンラインでは不足するチーム内での会話を補うために積極的に参加しました。

BackboneチームのProjectsでバーンアップチャートを出力してみました。最後に紫色のCompletedが緑色のOpenと合流しているのは、会期後に私が全てのIssueをクローズしたからです。紫色のCompletedは年末年始と会期直前に踊り場のように真横になっています。他の時点では大体急激な右肩上がりを表していて、非常に速いペースでIssueがクローズされていった様子が表れています。

2025/11/22に最初のIssueが作成されました。11月から12月は設計が盛り上がっていました。この時期が一番タスクを進めにくい状況にありました。各自の人間性やタスクの進め方や連絡の取りやすい時間帯がわからず、それぞれが探り探りで進めていたように見えたからです。

2025/12/17にケーブル講習会が行われました。実質これがBackboneチームとしての物理的な顔合わせになりました。紫色のCompletedが立ち上がったのも2025/12/17からというように読み取れます。

対面で手を動かすことや話し合うことで一気にIssue作成や設計議論が捗ったように感じられました。学生メンバーからは、どのようにタスクをもらうと良いかわからないとか、Slackでの会話に入りにくいという声を聞きました。結局のところこれらは解決することができず、Backboneチームができてから最後までコミュニケーションの課題は残り続けました。

実際のタスクの進め方は、学生リーダーが中心となり設計を進めていき、見えてきた課題やタスクをIssue化していき他のメンバーが拾っていくという形が多く見られました。搬入や撤収といったロジスティクスの計画や、監視や障害対応の計画は自分が中心となり逆算して早めにIssue化していたので、時間をかけて準備を進めることができました。とはいえ、撤収に関して検討に割いた時間が少なくバタバタしてしまったのは反省点でした。タスクアサインが学生リーダーに集中してしまったことも反省点です。

下記の画像は各メンバーごとにIssueアサインがあった数を表しており、色については各IterationでIssueをこなした量を表しています。グラフの左にいくほど、会期直前のIterationになります。Iteration2か3あたりから各自がIssueの処理を受け持ち始めた様子が確認できます。突出しているグラフが上述の学生リーダーの処理量を表しています。

構築を支えた技術

NetBoxを中心とした構成管理とコンフィグ生成、コンフィグ回収自動化

  • NetBoxの情報をもとにJuniper EXスイッチのコンフィグを自動生成するソフトウェアconfig-generatorを開発し、コンフィグ適用を行いました。NetBoxを信頼できる唯一の情報源として構成管理を行いました。config-generatorはNetBoxから情報を取得して、ホスト名やインターフェイス設定等のコンフィグを自動的に生成します。作業ミスを減らすだけでなく、作業にかかる時間を減らすことができました。
  • 内製ツール configpush（NOC全体リーダーの江草陽太さん作）によるコンソール作業のコンフィグ回収自動化
    • ルータやスイッチはコンソールでのコンフィグ保存のたびに、自動的にGitHubの特定リポジトリの各機器ごとのフォルダにコンフィグを保存するソフトウェアがありました。GitHub Contents APIにより差分がある場合のみコミットが行われ、Slackに通知されていました。コンフィグのバックアップ忘れを防ぐことができますし、作業内容を即時チームメンバーに共有できるため非常に有用でした。

管理用ネットワークアクセス（命綱）

  • SmartCSとHeadscaleを組み合わせ、現地に行かなくてもセキュアに各機器のコンソールへアクセスできる仕組みを構築しました。これにより、どこからでも作業できる安心感が担保されました。
  • しかし、この「どこからでも快適に作業できる環境」が盲点を作りました。NOCメンバーの作業用PCが常にHeadscale経由で管理ネットワークに直結していたため、本来のデータプレーン（ユーザーが利用する経路）で発生していた「DNSサーバーへの疎通不可」という事象に自分たちで気がつくことができませんでした。

監視

監視はServerチームに用意していただいたGrafana + Prometheusと、Juniper Mistの両方を使って行いました。

ログの集約先にはSplunkを選定しました。通常はログサーバーを介しますが、今回は機器から直接SplunkへUDP (514 port)で送信する構成としました。これは、基盤となるサーバー環境の構築を待たずに、我々Backboneチーム側でネットワークの異常を即座に自律的に検知・追跡したかったからです。

Hot Stage（構築本番前の、機材を並べて検証する事前リハーサル期間のこと）で準備中に、Mist APが Cloud Unreachable というログを出し、スイッチのポートがフラップするという事象がありました。Mistでスイッチのポートを詳しくみてみると半二重通信となっていました。原因はまだわかっていませんが、Multi Gigabitのポートに当該ケーブルを接続しているとこの事象が起きていました。ケーブルの不調などがあった可能性があります。

ツール一覧

NW観点

プロジェクト管理

次回やるなら改善したいこと

  • プロジェクト開始から1ヶ月以内にオフラインで集まる機会を作る（作業会など）
  • ロジスティクスの見直し（機材の搬入・搬出、梱包、現地での作業スペース確保など）
  • ペア作業を推奨したタスクのアサイン
  • 雑談のためのSlackでのハドルミーティングを推奨
  • 他チームメンバーとの交流

コミュニケーションの課題は最後まで残りましたが、それでもGitHubを介してタスクが回り続けたのは、Issueを細かく分割し、ゴールを明確にする努力を続けた成果だと思っています。

最後に

初めてのJANOG NOC参加でしたが、私にとって非常に価値のある経験となりました。普段の業務ではここまでどっぷりとネットワーク技術だけに没頭できる環境はなかなかありません。また、学生と社会人が垣根を超えて一つの目標に向かうチーム編成も非常に刺激的でした。JANOG NOCにおいてもタスク管理等のスクラムマスターとしての動きができる人が必要だとわかりました。

今回、会場ネットワークというインフラを形にしたことはもちろんですが、NOCというコミュニティで得たつながりを今後も大切にしていきたいと思います。