Written by はじめに
Serverチームの大黒響です。今回、「NOCに挑戦してみたい」という思いから応募いたしました。JANOGへの参加、ならびにNOCメンバーとしての活動は今回が初めてとなります。Serverチームの一員として、日々楽しく準備を進めています。
1. チームテーマと事前準備の目的
JANOG58 NOC Serverチームの事前準備期間における活動レポートをお届けします。
今回のServerチームでは、始動時に「知らないを放置しない、得意を活かして支え合う」というテーマを掲げました。学生からベテランまでが揃う環境の中、お互いの技術的な強みを活かし、疑問点を曖昧にしないまま本番環境へ繋げることを目的としています。
本記事では、7月上旬のホットステージに向け、リモート環境下でどのように各サーバーの仮想検証およびネットワーク連携を進めてきたかをご紹介します。
2. これまでの歩み
4月の始動から現在（7月上旬）に至るまで、チームミーティングを重ねながら段階的に設計と検証を進めてきました。
- 4月22日（MTG #1）: 各サーバーの担当選定、必要なCPU・メモリ・ディスク容量の要件定義、および機材リストの作成。
- 5月20日（MTG #2）: 各サーバーの必要スペックの確定。先行して立ち上げた共通基盤（Wiki、NetBox、Hermes Agent）の状況共有。
- 6月17日（MTG #3）: 各サーバーの具体的な進捗報告と、本番環境を見据えた冗長化構成についての議論。
- 6月25日（MTG #4）最終ミーティング: 「最終ミーティングまでに最低限稼働する状態を作る」という目標に向けた、現在の進捗確認とラストスパート。
現在は、本番期間中に必要となるコア機能の動作を仮想環境上で担保すべく、各担当が順次構成コードや設定ファイルの作成・検証を進めている段階です。
3. 仮想検証環境における各サーバーの構築状況
ホットステージ前でまだ本番用の物理機材に直接触れることができない期間、1台のProxmox VE環境に加え、提供いただいたさくらのクラウドの環境や、一部貸し出していただいたAristaの検証機へネットワーク越しにアクセスし、検証を進めてきました。各メンバーはcloud-initを用いて自身の検証環境を迅速にデプロイし、各種設定ファイルや連携動作の確認を行っています。
① 基礎インフラ（DNS / DHCP / NTP）
L2/L3のネットワーク班との連携が必要なインフラサーバーに関しては、検証用スイッチを接続してもらい、実際のセグメントやVLANを跨いだ状態でのIP分配や名前解決、時刻同期の動作検証を実施しています。
- DNS（Unbound）: 今回のDNS環境は、AristaのAWE上でUnboundをコンテナで動作させる構成を採用し、検証を進めています。
- DHCP（Kea DHCP）: デーモンとして動作させる構成です。最終的にはAnsible Playbookを活用して構築する形に着地し、NetBoxと連携して各種コンフィグやIPアドレスの情報を自動的に取得・反映する仕組みを整えました。これらはすべて、Web UIからプレイブックを実行できるSemaphore UI上で制御しています。
- NTP（chrony）: こちらの環境はすでにDockerを用いて構築を完了しています。正確な時刻同期の担保を行い、現在はIPv6対応に向けた設定作業を進行しています。
私の所属しているDHCP班では毎回深夜までハドルで構築・検証しています。私はこのお祭り感が大好きです。本当に新たな知見が身につくので、成長を実感しています。ネットワーク系のサーバーを立てる機会などDNSサーバー以外あまりないので、本当にいい経験だと思います。
またサーバーの知識だけでなくネットワークの知識も必要になってくるので、レイヤーを意識して動くという経験もでき、考え方が変わったなと感じます。
② 監視・ログ・可視化サーバー
監視サーバーにおいては、VictoriaMetricsとGrafanaを中心とした構成がDocker Compose上で構築されており、現在はFlow周り以外のコンポーネントが概ね立ち上がっています。
- アーキテクチャ: 各ホストから Grafana Alloy でメトリクスやログを収集し、ネットワーク機器からはSNMPで取得しています。これらの情報を集約してVictoriaMetrics へ流し込み、Grafana で一元的に可視化する構成です。
可視化サーバーに関しては、Shumoku の稼働を開始しており、NetBoxや監視サーバーとの接続テストを完了しています。
③ 共通基盤（さくらのクラウド）
プロジェクトの知識ベースとして機能するWiki.js、資産管理を行うNetBox、および認証基盤であるauthentikはさくらのクラウド上に集約して運用しています。さくらのDNSアプライアンスを用い、これら共通基盤へのドメイン割り当てをコントロールしています。この認証基盤を活用し、検証環境であるProxmox VEをOAuth2認証に対応させているほか、Proxmox VE本体および各VMにおいてもLDAP認証を有効化しています。ドキュメント管理においては、当初Googleドキュメントで管理されていた設計書やナレッジのデータをWiki.jsへと一斉に移行する作業が発生し、このデータ整理と移行作業は私が担当しました。Wiki.jsは個人で構築したことがあったので、初回MTGのときに「Wikiサーバーを構築したいです」と提案し、受け入れてもらいました。自分ひとりでセキュアな環境が構築できるか心配でしたが、いつでも相談できる環境があり、安心して構築できました。
4. 自動化（IaC）への取り組みとAnsibleとTerraformの実行環境
手動構築による設定のブレやデプロイコストを抑えるため、ServerチームではSlackハドル上で自動化分科会を開催し、自動化およびIaC（Infrastructure as Code）の対象範囲や技術選定について議論を重ねました。
今回の自動化においては、さくらのクラウド上にWikiやNetBoxなどの共通基盤を先行して安定稼働させている背景もあり、Proxmox VE上のVM初期構築をメインターゲットに設定しています。具体的な役割分担と技術スタックは以下の通りです。
- cloud-init: Serverチーム全員が共通で使用しています。テンプレートからVMを立ち上げる際、短時間で起動し初期セットアップまでを自動で完了してくれるため、非常に重宝しています。
- Ansible / Terraform: 主にVMへの設定流し込みと構成管理に活用しています。
- Semaphore UI: 環境差分を排除し、手順書の作成を簡略化するため、Ansibleの実行環境としてこのWeb UIを採用し制御する形に着地しました。
私自身、今回のJANOG58 NOCの活動で初めてAnsibleに触れました。これまでは手動で行っていたパッケージのインストールや設定ファイルの流し込みが、プレイブックを実行するだけで一瞬で完了するため、インフラ構築における圧倒的な爽快感を味わうことができました。 また、すべての構成やコードをGitHubでバージョン管理できるため、リモート環境主体のチーム開発において変更履歴の追跡や共有が容易になり、その利便性を実感しています。現在は各担当が運用のデザインまでを見据えながら、実装と検証を進めています。
5. AIエージェント「Hermes Agent」の活用
さくらインターネットのAI Engineをバックエンドに、Hermes AgentをSlack上で運用し、チームメンバーと対話するAIアシスタントとして私たちのリモート構築を支えています。
単なる雑談用ではなく、Wiki.jsやNetBox、さくらのクラウドのAPIと連携しており、Slackの専用チャンネルで「NetBoxのデータ見せて」「Wikiのこのページを更新して」と指示を出すだけで、実際に裏でAPIを叩き、データの取得・確認・更新を行える状態になっています。AIモデルはKimi2.6を採用しています。
構築中に出たエラーログを投げてトラブルシューティングの参考にしたり、息抜きに開催地である松山の情報を尋ねるなど、日常のコミュニケーションにも活用されています。
私はHermesにチーム全体の進捗を確認したり、技術について教えてもらったりしています。Hermes君はみんなから愛されています。
6. まとめと今後に向けて
リモート環境下での検証という制約はありつつも、Slackのハドルを活用して活発に意見を交わし合うことで、不明点をその都度解消しながら本番に近い構成を組むことができています。
「最終ミーティングまでに最低限動くものを作る」という目標に対し、自動化やツールの導入を進めながら、着実に各サーバーの構築が形になりつつあります。 ここで蓄積したコンフィグや知見を、7月上旬から始まるホットステージでの本番機への落とし込み、そして松山での本番運用へとしっかりと繋げていきたいと思います。