自分は大学院生活で、およそ2年間、学内システムインテグレータのようなことをした。NAISTの学生宿舎内のネットワークは、学生ボランティアの委員会により保守・管理されており、自分もその委員に属していた。その活動を何も残さないのは勿体無いので、その活動内容および得られたことを記事に綴る。
活動内容
学生宿舎のネットワークは学内ネットワークを利用するため、学内アカウントで認証を行い、不審な通信を発見ししだいその学生への対応も行う。このゲートウェイ・認証システムも委員会お手製アプリが動いている。エンジニアがトップに立つかどうかは賛否両論あるが、意思決定の迅速さから自ら委員長に立候補した。そして委員会の運営にいろいろと思うところがあったので、その改革を試みた。
認証システムの再構築
自分が委員会で行った一番の大仕事は、認証システムのリプレイスである。自分の入学時に使用されていた認証システムは、バグが放置されていたりと、お世辞にも褒められたものではなかった。しかしそれ以上に、その管理方法が最高にロックだった。まずデータベースにSQLiteを使用していた。更に、ユーザの管理をWebアプリのソースコード（Python）を手動で編集し、毎回Webアプリの再起動をした。宿舎に新たな学生が入る度にこの作業を行っていた。しかしこの惨鼻なシステムには、悲しい理由がある。自分が入学する半年前、宿舎ネットワークのゲートウェイが壊れた。そのときシステムのデータも飛び、しばらく宿舎内でネットワークが使用できない状態が続いた。その後当時の委員会のメンバが、突貫はあるが、数週間でシステムの再構築を行ったのであった。
この仮システム、結局メンテナンスされずに、自分の入学時にも引き続き使用されていた。そして委員会に入ってからその実態を知り戦慄した。SQLiteのDBが壊れてInternal Errorが発生したり、本番環境のソースコードを手動で編集することに耐えられなくなり、ついにシステムのリプレイスに踏み切った。
仕様変更とマシンの更新に伴い、スクラッチから作った。委員会のメンバと共に時間を見つけて開発を進め、11ヶ月かけてリリースできた。デプロイ後数週間はハラハラしながら見守り、その後浮上した細かなバグを潰し、今は安定稼働をしているようだ。なお開発時に得られたTipsなどは、Qiitaにでもまとめようかなと思う。
旧認証システムからも伺える通り、委員会内ではあまり先進的な技術を導入してない。それらを必要としている人も毎年1-2人程度である。しかしデプロイなども考えるとバージョン管理システムすらないのは不便だったので、学内のサーバを新たに借りてGitLabを導入した。またGitLabを学内のKerberos認証と関連付けるために、Kerberos認証の認証をしながらGitLabにパッチも当てたりした。
モダンなドキュメント管理
ユーザ向けにネットワークの設定方法や注意事項を記した資料を配布しているが、従来の資料はMS Wordで作成され、ファイルが更新される度に委員会内wikiにアップロードされていた。Web版ドキュメントが用意したかったのと、バージョン管理したかったため、HTMLベースのドキュメントに切り替えた。静的サイトジェネレータMiddlemanを利用して、Gitによるバージョン管理を行った。
ボランティア・インフラエンジニアの苦労
この2年間、常に事がうまく進んだわけではない。学生・そしてボランティアであるがために、至らないことや挫折したことも多かった。
運営体制の難しさ
メンバのほとんどは2年で卒業するため、長くメンバに属している人がいない。また職員からの干渉も少なく、委員会内で顔を合わせる機会は、月に一度の月例ミーティングのみだ。そのためメンバ間の繋がりも疎で、、必然的にノウハウや情報の教諭がうまくできず、引き継ぎも不十分となった。
また学生かつボランティアなので学業を優先すべきであり、自分も強制したくはなかった。忙しい時期には、学生たちも足が遠のいた。この支障は委員会に入って直後から感じていたため、運営体制をより良いものにしたかったが、方法がわからなかったため例年どおり何も変わらなかったのが心残りである。
若者のネットワーク離れ
「若者のネットワーク離れ」というのは自分の意見ではなく、学内の教員の意見である。下の学年の新メンバが少なくて学内の教員に相談すると、学生のネットワーク離れも深刻という。一昔前と比較するとネットワークの知識がなくともネットワークにつなげる時代になったためか、その教員の研究室も同じ状況だという。
ネットワーク離れが事実かどうかはサンプルが少ないため一概には言えないが、少なくとも過去の委員会のログを見るとIPv6移行プロっジェクトなどが存在を確認できたため、少なくとも今より昔のほうが活発だったと言える（IPv6移行はいまだされておらず、そのプロジェクトの存在も今は忘れ去られている）。これも引き継ぎの難しさの理由の一つであった。
ユーザとインフラエンジニア間のギャップ
インフラとは、ユーザからはインフラは常に動いて当然のもので、また障害発生時は異常事態である。しかしエンジニアからすると、常に動かすのも難しく、簡単に障害が発生しうる。正常に動作されている時は特に感謝はされず、障害発生時には怒りと苦情のメールが飛んでくる。このユーザとインフラエンジニア間のギャップを感じた。
幸い宿舎の学生は、ボランティアで活動しているのを理解しているためか、ネットワーク停止時にもそこまでの怒りのメールをもらったことはなかった。それでもシステム停止時やメンテナンス直後は、胃を痛める思いで作業をした。インフラエンジニアの苦労が若干理解できた気がするので、インフラの障害発生時にも穏便に対応するよう心がけるようにする。
おわりに
この2年間、家庭では体験できない規模のネットワークを扱えたのは良かったと思う。ある程度自由に活動できたのも嬉しかった。その反面苦労することもあり、エンジニアとして、人間としての未熟さも痛感した。これらの活動は将来の自分にとって良い経験となることを祈りたい。
