昨日は @icchy さんで 「whywaitaであいうえお作文する」でした。タイトルだけでだいたい想像できますね。

なるほど。

@icchy さんのおすすめインターネットコンテンツは飲酒日記です。

閑話休題。
アドベントカレンダー、書くネタはあれど頭を使うものばかりで泣きそうになったので、とりあえず過去の下書きを漁っていたらタイトルだけ書かれたこの記事の下書きを見つけました。
最近思うこともあったので、すでに忘れ去られ、誰もが忘れたままでいたいと思っていたICTSCのコンテストサイトの歴史を紐解いてみたいと思います。
whyawitaさんとの関わりもあるし、whywaita Advent Calendar的には100点満点のネタですね。よろしくお願いします。

ICTSCとは

早速本題に入りたいのですが、そのためにはICTSCに関する簡単な知識が必要です。
ICTSC (ICTトラブルシューティングコンテスト) は学生による学生のためのインフラ技術を競うコンテストで、最近は年1回開催されています。途中でナンバリングが回数から年号になるの、あるあるって感じですね。
予選もありますが、予選のことは一旦考えないこととして、本選の話をします。選ばれた本選の参加者は、当日の限られた制限時間内に与えられる問題へ挑むことになります。

問題は次のような形式で与えられます。

「A社の技術者であるXさんは、自社の端末からあるWebサイトを開こうとするといつも失敗することに気が付きました。A社の社内ネットワークのトポロジは下の図のようになっており(省略)、ルータの管理コンソールへアクセスするために必要な情報はXXです。あなたはXさんに変わってこの問題を解決してください」

管理コンソールのIP: xxx.yyy.zzz.www
ユーザ名: admin
パスワード: nyannyan

社内端末のIP, ユーザ名, パスワード: …

参加者はこれらの情報を元に、持てる限りの知識と経験を活かして挑み、気合で問題を解決することになります。
(大会インフラとしてはVMがいて、仮想ないし物理のルータがいて……となりますが、今回の本題からはそれるので割愛します)

そうして、問題に不明点があれば質問をし (競技界隈では clar(ification) と呼ばれたりするみたいですね)、解決に必要な情報をまとめて回答します。基本的に回答はテキストで自由な形式で行われます。
運営は提出された回答を読み、必要があれば実際にVMへアクセスして回答の検証をし、採点を行います。
採点を行った結果、正答であれば点数が加算され、不正答であれば改めて参加者が挑戦する、というのが一連の流れになります。

コンテストサイトの必要性

ICTSCでは、約15問の問題が2日間かけて出題され、参加チーム数も15チーム近くに上ります。賞金が出るということもあり、運営は限られた時間内に公平性をできるだけ保ちつつ採点や質問対応といったタスクをこなさなければなりません。
15チームというのは意外と少なく見えますが、人数でいうと60人から80人近くおり、1つのチームでも分担して複数の問題に取り組んでいたりします。そうなると、意外と想像を絶する数の質問や回答が来ます。15チーム×15問で単純に225回答ですし。

私がICTSCの運営にジョインしたのは、遠い昔のICTSC5でした。当時はプロジェクト管理ツールである Redmine を使って出題を行っていました。チームごとにプロジェクトを立て、問題ごとにIssueを立てて、そのコメントで質問や回答の管理をしていた気がします。
この構成で実際に開催を行ったところ、様々なトラブルが生じました。
質問や回答の状況が適切に把握できない(どの質問にまだ返答してないのか?採点は行われたか?)だけでなく、特定チームへの紙のトポロジ図の配布漏れ (これなんで紙で配ってたんでしたっけ?) などが生じました。

今思えばこれなんで起きたんだ?みたいなトラブルですね。Redmineを賢く使えば良かったのではないかと思ってきた……

さて、こういった課題に対処するために若者がやることは一つですね?
そう、「僕が考えた最強のコンテストサイトで解決しよう」です！

コンテストサイトの開発

さて、経緯はどうあれコンテストサイトの開発が始まります。正確にはすでに私の知らないところで一度頓挫していたのですが、忘れます。

今のコンテストサイトは様々あり(後述)、私が知らない構成になっているので、とりあえず私が知っている構成の最後の回のブランチへのリンクを貼ります。

GitHub: ictsc/ictsc-score-server at ictsc2018

さて、途中で採用技術が二転三転している(なぜ?)ので、老害らしく順を追っていくことにしましょう。

ICTSC6

輝かしいコンテストサイト初回導入のときです。当時関わっていた人からはICTSC6の文字列すら見たくないという話も聞きます。当時の振り返りはこちら。

https://github.com/ictsc/ictsc-score-server/tree/ictsc6

開発が始まりました、技術的には、特に面白みのない簡単な REST API + SPA 構成です。

私はフロントエンド技術には疎かったので、同じ運営学生のメンバーの方と、スポンサーの中の方々に協力して頂きました。
一体本業外のこんなことにどれだけの工数を割いていただいたのか、想像を絶する状況になっていたことだろうと思います。本当にありがとうございました。

特に、デザイナーの方にはふわっとしたユースケースから具体的な行動パターンの書き起こしから何から何までお世話になってばかりでした。特に、第6回は初めてコンテストサイトを導入するので何が起こるかわからない、というときに「じゃあ念の為に紙の解答用紙も作っておきますね!」とネタで解答用紙までデザインして渡していただいたときは笑いました。

さて、当時の採用技術は次の通りです。

• REST API
  • Ruby
  • Sinatra (Ruby のシンプルなWebフレームワーク)
  • ActiveRecord (Rails で使われている O/Rマッパー)
  • (SQLite3)
• Web UI (SPA)
  • Angular 2.0
  • RxJS 5.0

REST API の方は私がRailsの経験がほとんどなかったので必然的にこうなりました。Web UIはおまかせしたらこうなりました。package.json 見るとわかるんですけど、Angular 2.0 って当時まだRCなんですよね。尖ってますね
RxJSが使われたコード、当時ちょっと弄ろうとしたら手も足も出なかったきおくがあります。今なら読めるかもしれない

ところで、当時のREST APIには致命的な設計ミスがあり、REST APIでN+1をしていました。例えば、参加者が問題文の書かれたページを開くと、次のようなアクセスが走ります。

• /problems/2
• /problems/2/comments
• /problems/2/issues
• /problems/2/issues/37/comments
• /problems/2/issues/39/comments
• …
• /problems/2/answers
• /problems/2/answers/27
• /problems/2/answers/27/comments
• …

うーんひどい、典型的なN+1ですね。

N+1 はデータ量が少ないと影響が見えにくいので、この問題は回答や質問量が増えてきた2日目に顕著になりました。
そして当時の私はDBにインデックスを貼るということを知らなかったらしい。いま schema.rb 見て吐き気が……

そして、運営は全ての参加者の回答や質問を見ることができる、つまりどうなるでしょうか? 大変なことになります。
10秒経っても帰ってこないAPIが乱舞して開発者ツールはさながらナイアガラの滝の様相を呈していました。同一IPに同時に張れるセッション数限界までリクエストが飛んでドーン、返ってきたら第2弾がドーン、もう見たくない……

当時は完全にテンパっていたのでAPI側の修正を入れる余裕はなく、フロントエンド側で急遽キャッシュ等の対応を入れてもらったものの、却って新しいリソースが見えなくなるなどして大変でした。

そんなこんながありつつも、なんとか(?)大会は閉幕。次回への課題を残しつつ、コンテストは第7回へ続きます。

ICTSC7

知り合いのOB、みんなICTSC7の話しかしたがらんがち。
https://github.com/ictsc/ictsc-score-server/tree/ictsc7

ICTSC6で辛酸を嘗めた私達[誰?]は、次こそは運営がトラブルシューティングしないコンテストにすべく様々な改善を行いました。

• REST API
  • Ruby
  • Sinatra (Ruby のシンプルなWebフレームワーク)
  • ActiveRecord (Rails で使われている O/Rマッパー)
  • MySQL (MariaDBだったかも?)
• Web UI (SPA)
  • Vue.JS 2.1
  • Vuex 2.0

API は N+1 問題を潰すべく、様々な対策が取られました。
その集大成が nested_entity.rb です。この100行に満たないコードがこのコンテストサイトの真価といっても過言ではないでしょう。私はそう思います。
これは要するに「僕の考えた最強のGraphQLっぽいやつ」で、指定した関連リソースをいい感じに取ってきてくれます。こうやって使います。 こんな読みづらい使い方だからだめなんだわ。

これを使うと、上記のICTSC6の例が次の1リクエストで完結します。

• /problems/2?with=comments,issues-comments,answers-comments

便利なのは分かりました。さて、ここで内部的には何をやっているのかというと、大きく次の2つのことを行っています。

• アクセスするユーザの権限によるRBAC (Role-Based Access Control) の適用
• N+1を避けるクエリの生成

コンテストサイトのユーザには、参加者や運営、スポンサーといったロールが割り当てられており、それぞれ見ることができる情報に差があります。例えば参加者が他チームの回答を見られては困りますね。

これ、すなわちRBACを実現するために、全てのロールに対してあらゆるモデルで読めるものを ActiveRecord の scope で定義しています。例えばこんな感じです。
scope とは何かというと、あらかじめ用意されたパラメータの指定可能なクエリといえばいいでしょうか。scope は ActiveRecord::Relation 型の値を返します。これは何かというと、ActiveRecord の抽象的なクエリ表現なので、これを更に合成したりできます。便利

クエリレベルでもN+1を避けるためにはどうしたら良いでしょうか? 気合でクエリを合成したらできそうです。
なんと ActiveRecord はクエリに include パラメータを渡すと勝手に合成してくれます。そうしましょう。
nested_entity.rb では、このあたりで与えられたクエリパラメータをいい感じに ActiveRecord が解釈できる形に変換しています。

全てが ActiveRecord の世界で簡潔するので、RBACもN+1もクエリレベルで表現されます。これはすごくて、あとは全てのロールがアクセスできるリソースをActiveRecordのクエリで表現できれば大丈夫です。つらい、二度とやりたくない。

ちゃんとDBもMySQLにしてインデックスも貼ったので、APIも水平スケールできるようになりました。こうしてコンテストサイトの Iikanji Speed-Up に成功した我々は、その後数回に渡って予選敗退を繰り返しました。何が足りないん?

そして、フロントエンド担当のエンジニアの方の異常な熱意により、唐突に ui2 ディレクトリが爆誕しました。突然のAngular引退宣言に人々は涙を禁じえませんでした。

そうして開催されたICTSC7は、少なくともコンテストサイトについては成功裏に終わったといっても過言ではないでしょう。

ユーザから見える部分としては、問題がこれまでの2日間の午前午後、計4パートでの固定出題から、問題を解くごとに次の問題が解けるようになったり、最初に問題を解いたチームに追加点数(first blood)を与えるようになったりという変化の方が大きかったかもしれませんが、これもコンテストサイトの貢献ということで。

ちなみにこの頃のスクリーンショットがこちら。

ICTSC8

ICTSC8の記憶があまりありません。

https://github.com/ictsc/ictsc-score-server/tree/ictsc8
コミットログを見ると、たしかに差分はあるけどあまり変わってないですね。確かプッシュ通知を実装しました。CyberAgentのFRESHチーム?が作った plasma を使っています。

ICTSC8では小さなバグフィックスやルール変更の対応等はあったものの、それよりはテストを書くことにご執心だったようです。RSpecの鬼になったkyontanの姿が垣間見えますね。増える緑の. (RSpecではテストケースが1つPASSするごとに.がプリントされた)にエクスタシーでも感じていたんでしょうか。
https://github.com/ictsc/ictsc-score-server/tree/ictsc8/spec/requests
相変わらずへんなヘルパー定義しててウケました。そんなんだからお前のコードは人に読まれない。

そうして満足したので運営委員を引退しました。それはそれとして、参加記を見ると毎回のように後悔が綴られていますね。

ICTSC9

関わっていないのでほとんど分かりません。

https://github.com/ictsc/ictsc-score-server/blob/3730cfaa8d62b14a573a1e3a5998f045993e2504/services/nested_entity.rb#L16

ほんまにすまんて

ICTSC2018

運営に出戻ったものの何したのか覚えてません。コンテストサイトには手を出していないはず。

このあたりで API 向けの CLI が生えたらしい。今までシードデータ投入をSQLでやってたのを、 REST API 経由でやるようにしたんですかね。

https://github.com/ictsc/ictsc-score-server/tree/ictsc2018/cli

あとはしれっと Kubernetes 化とかされている。モダンなインフラってやつ

私が知るのはここまでです

ICTSC2019

Big Bang! · ictsc/ictsc-score-server@5d5fd50

唐突に api2 と ui3 が爆誕する。担当者のキレ具合が垣間見えますね。僕も同情します。

• REST API
  • Ruby
  • Rails 6.0
  • GraphQL
  • PostgreSQL
• Web UI (SPA)
  • Nuxt.js 2.0
  • Apollo Client 2.6

ザ・モダン・Webアプリケーション大全。僕の心境としては「GraphQLもどきを作って公園で砂遊びしてたらいつのまにか本物のGraphQLで置き換えられていた、何が起きているのか(ry」って感じです。
DB が Postgres に変わったのはなんでなんでしょうね? 僕は理由を知らないので知っている人がいたら教えて下さい。

増えた機能が多すぎて良くわかりませんが、Webでだいたいのリソースが編集できるようになってたり、問題VMへのアクセスに必要な情報を専用のテーブルで管理できるようになったりしたようです。憶測ですが、VMをプロビジョニングするいい感じのツールと連携していい感じにできるんじゃないですかね。

こうして生み出したプロダクトが自分の手を離れて育っていく様子をまだ学生の身にして実感することができました。ハッピー。

万物は流転する

私事になりますが、先日JANOG47？っていう日本最大級のネットワークエンジニアの集まり？ってやつでNETCONっていうあいしーてぃーえすしー？みたいなのをやるって言われてあれやそれやで運営委員になりました。

どうやらコンテストサイトが必要らしいんですよね。

………というわけで最近forkしました。これどうしたらいいんですか?

そんなこんなで、泣きながら Ruby の GraphQL実装を調べています。ドキュメントの大切さが目に染みる。

明日は同期だったはずのくるとんさんです。ワンワールドサファイアステータスを求めて飛び回りたいという発言を最近目にしましたがお元気ですか?

• 第6回 ICTトラブルシューティングコンテストの運営委員をしていました
• ICTSC7 の運営委員を務めました

に引き続きのエントリになります。ちなみに記事はないですが第5回でも運営委員を努めさせて頂いていたので、これで4回目になります。
後述しますが5回目はないので運営委員シリーズはこれで最後です。(そもそもシリーズものではないですが……)

偉そうになんやかんや語っているところだらけですが、あくまで主観だし間違いも色々あると思います。ただの記録や雑感として受け取って頂ければ幸いです。

表題の ICTSC8 とは、正式名称を「スカイアーチネットワークス杯 第8回ICTトラブルシューティングコンテスト」と呼びますが、学生主体の学生による学生のためのインフラ技術中心のトラブルシューティング大会です。
インフラ技術といっても色々ありますが、ここで指しているのは主に OSI参照モデルの L2-L7 あたりを指します。運営委員はL1もやってますが、問題としては出題されていないはず。

今回は電気通信大学で開催され、数回ぶりの学校での開催となりました。ちなみに前回, 前々回はNTT東西の研修センタで、その前は Cisco 東京本社でした。

前回、前々回となんらかのマネジメント的な役職についていましたが、今回はそうではなく、単なる平の運営委員としての参加でした。
特に今回は何をしたということを主張することもしづらいような立場でしたが、問題を1問作り、あとはひたすらコンテストサイトに手を入れていた気がします。

作った問題はこれ (問題解説: ホビットの国 第二のトラブル | ICTSC tech-blog) で、ICTSC7 における運営側のトラブルを再現したものになりました。
Keystone API のバージョン差異によるトラブルであったことまではわかっているのですが、未だに原因が究明できていない問題の一つです。
OpenStack を理解している方には是非運営委員に来ていただきたいところ……

(実はもう一問作っていた問題があったのですが、自分の力不足により出題できず仕舞いとなりました……)

コンテストサイトについては、3回を通して色々とやってきたこともあるので、近日中に別の記事にまとめたいと思っています。
引き継ぎは失敗したので、次回はないかもしれません。心残りのうちの1つです。

きっかけ

そもそものきっかけは、ふわっとしたサーバー/ネットワーク技術への興味があった自分を @whywaita 先輩が運営に引き込んできたところから始まりました。

スイッチとルーターって何が違うんだっけ、というような右も左も分かっていなかったアホの自分でしたが、実際の機器の操作やDCでの作業など、様々な経験をさせて頂けてとても学びになりました。en, conf t, do show run, ...

そこに自分も何らかの貢献ができたり、その次の世代へ、というように流れを作ることができていたならよかったのかなと思います。

技術面では、いかに面白いことをするかということで Linux のカーネルモジュールを書いている人がいたり、OpenFlow をやったり、家が立つような価格の機材でなんやかんやしている人がいたりした一方で、目に見えるところではシナリオを導入したりも運営も満足できるコンテストにできるのかということを考えながら進めた運営でした。

至らぬところも数多くあり、人間関係が破滅しチームとして動くことの難しさを感じました。やっぱり自分はマネジメントに向いていない……
一方で、チームでしかできないこと、チームでやることの楽しさを感じた回もありました。

特に、次の世代への引き継ぎという点では至らないところが多かったと思っていて、自分が運営委員を努めていた4回の中で新しく入ってきて、僕がやめることになった第8回の時点で次もやると言っていた方は5, 6名程度だったのかなという気持ちです。巻き込んで楽しいと思ってもらうというのは難しいですね。オーガナイズやマネジメントをする立場としては、やはりこういった巻き込み力が大切なのかなと思いました。

暴論

また、私はIPAの情報処理技術者試験でネットワークスペシャリストやらなんやらを取っていましたが、結局そういったものを得ることに大した意味はないのかな、などと思っています。百聞は一見にしかず。もちろん体系的な知識を得る機会になることそのものは良いと思っていますが、結局業務独占できない資格に大した意味は無いんや……!
(しかし単に話のネタになるので、残る最後のテクニカルなスペシャリストであるところのデータベーススペシャリストぐらいは取っておくかぐらいの気持ちがあります。)

特にリーダー/副リーダーは20人規模のグループのマネジメント(ができていたかどうかはともかく)をすることになるわけで、こういったことに挑戦できる機会というのは学生ではなかなか得られないと思います。人やマネジメントということに興味を持つようになったのもこのあたりなのかなと。

もちろん社会人になってからもこういったことを経験する機会は多いでしょうし、学生しか失敗できないということはないでしょうが、それでもこういった機会があることは素晴らしいことだと思いますし、若いうちに積んでおいて損をするわけではないのかなと思います。
(もちろん、そんなことをしている暇/隙があったら個人の技術を磨け、という論調もありますし、同意します。)

最後に

実際にそういったものに触れられる環境へ繋がる機会を下さった実行委員の皆様や、そこへ自分を引き入れてくれた運営委員の @whywaita を始め、一緒にICTSCの運営をした運営委員の皆に感謝します。ありがとうございました。

(しかし、僕が運営委員をやめたあとにも @whywaita が運営委員をしていることを観測しました。不義理を働いてしまった……)

次回はどうなるんでしょうね、楽しみです。

ICTトラブルシューティングコンテスト という学生が主体となってインフラやサーバに関するトラブルを起こして、学生が解決する(雑) な大会がありまして、その第7回、通称 ICTSC7 の運営側として参加してきました。

ちなみに、この前説は以前書いた記事からコピーしたものを数字だけ変えただけです。

実際に大会の本選が行われたのが 2017/3/4, 5 (土日) でしたから、もう2週間が経ったわけです。忘れないうちに書き残して置こうと思います。

今回もフォトレポートを始め、参加者や運営委員の方々がレポートを上げてくださっているので、そちらもご参照ください。

NTT東日本杯 ICTSC7 レポートまとめ

さて、改善点が多かったかと思えば最終的には反省点の山になり、上でリンクした記事を読み返したところ陰鬱な気持ちになった前回という大会がありました。それを元にして、今回はどうやって動いたんだお前という話です。

ちなみに活動期間ですが、2016/10/1 に運営委員結成開始, 2016/10/29, 30 にキックオフ合宿, 2017/2/18 より HotStage開始, 2017/3/4, 5 が本選でした。キックオフから数えて、4ヶ月に渡り活動していたことになります。

役割

今回、私はインフラリーダーとして、リーダー, 副リーダーの下にいる3つのリーダー職 (インフラリーダー, 問題リーダー, イベントサポート) の1つを勤めさせて頂きました。
改めてこれらの役割をまとめてみます。

リーダー, 副リーダー: 全運営委員 (今回は22名, ちなみに前回は16名) の指揮をする。また、機材折衝であったりイベント全体に関わる様々な部分において、実行委員(大人側)と調整を行う。
問題リーダー: 運営委員によって作問された問題の品質を保証するのが目的。スケジュール管理や問題のバランス調整が主な役割ですが、今回はシナリオ作成も行ってくれました。
イベントサポート: おそらく機能したのは今回が初。リーダーが今まで全てを担っていた機材折衝や管理の大部分を受け持ち、その他会場側との調整や、当日の段取りなど、実行委員側にお任せしていた内容を学生側でできる限り受け持つという目的のもと、それを主導する立場。
インフラリーダー: 問題を出題する基盤となる、会場ネットワークの L1 ~ L7 を設計/実装し運営委員および参加者に提供する、インフラ担当の運営委員のトップ。

各役割は確か運営委員が結成して1, 2週間ぐらいで立候補形式で決定した記憶があります。
あと、副リーダーが役職上しか存在していなかったという噂を聞きました。そういうこともあります。
忙しさの順序で言うと、問題リーダー>イベントサポート>=リーダー>=インフラリーダー ぐらいになるんじゃないでしょうか。あくまで今回の僕からみた主観的な感想です。ピーク値で言うと本選直前のイベントサポートが一番忙しそう。

やったこと

そんな中、自分が今回何をしたかを書いていきいます。
端的にいうと、前回は副リーダーとして色々やり、やらかしましたが、それでも僕は前回の基本的な方針は間違えていないという信念を持ち、できる限り近い方針で運用をしつつ、それでいて自分でほとんどタスクを持たないようにしました。

情報のやりとり

インフラリーダーがやることなのか分からないですが、やりました。
前回は Slack, Crowi (Wiki), Trello (ToDo管理), Google Drive (ドキュメント管理) の4つを主に使用していたはずですが、Trello を結局うまく使えず最新の情報が抜けまくってたのでやめました。
つまり、Slack, Crowi (Wiki), Google Drive の 3つで運用しました。

例のごとく Slack は最高のチャットツールですが、ちゃんとチャンネル戦略を練らないと一瞬で破綻するのでちゃんとやります。
具体的には左にあるはずの画像のような感じです。プレフィックスを良い感じにつけて、適度にサブチャンネルを付けると良い感じになります。(例: #infra 単体にしてしまうとサーバやネットワークといった異なる話題がごちゃ混ぜになってしまうので、 #infra-server, #infra-network を作るなど)
今回は問題のチャンネル #problem-xxx を作り、その中で各自が検証の進捗を書くようにしたのが新しかったでしょうか。あと、前回は HotStage (本選2週間から東京へ運営委員が集まり、インフラやらなんやらの直前準備を行う機関) に #hotstage-XXX チャンネルを色々作っていたのですが、既存のチャンネルとの差別化ができなくて混乱したのでやめました。
最終的なチャンネル数は 73チャンネル (うち分報15チャンネル, 問題個別21チャンネル) でした。メッセージ数は約47100メッセージ, うち59%が Public Channel でした。(前回は約48900メッセージ, 67%)

Crowi は最高の Wiki だと思います。ちょうど ICTSC7 が始まる前に 階層化 or 非階層化論争が再び起こり、Scrapbox も最近流行っているのかな、という感じはします。ただ、前回運用した知見があることに加え、前回の100ページを超える知見が溜まっていることは大きな利点だと感じ、前回の Wiki を継続して使用しました。
Wiki 自体は前回の運営委員がアクセスするものとは異なるものを同じデータをクローンして作り、 /ictsc7 という階層を切っただけです。
今回だけで新たに 144ページが作成されました。これは個人的にはとても驚いていて、前回は全体の147ページの半分以上を自分が書いていたはずですが、今回は自分が書いたのはたかが10ページ程度だったので、そこまでページがあったとは思わなかったからで。
今回は大人も含め積極的に Wiki にまとめるということをしてくれていた気がします。
ただ、まだまだこの運用, Wikiには改善すべき点があると思っているので、どうにか模索したいところです。
(例えば各ディレクトリ以下の情報をうまく収集して表にできたりすると、一々2つのページを手で更新しなくてよくて便利、など)

Google Drive は言わずもがなですね。基本的に Docs, Slides は使用しないので、 Sheets ばかりを乱用します。
IPアドレス一覧であったりネットワークの管理はやはりスキーマがある方が圧倒的に便利ですし、Markdown の表はめっちゃ使いづらいので、やはりリアルタイム同期ができて実質 Excel な Sheets は最高です。Conditional Format を使うと割りと楽に綺麗にできるのも評価すべきところ。
今回は1つのドキュメントにIPアドレスからVLAN設計からなにまで全部を詰め込みました。(今回は使っていませんが)シート間参照ができることと、別の内容を開きたい時にドキュメントを開き直さなくて良いのがメリットですね。ドキュメントを開き直さなくていいの、自明でしょという感じはしますが、Google Sheets の読み込みは結構重くてなんだかんだ10秒ぐらい奪われるのでシート切り替え1秒なんかで済むのは結構大きい気がします。逆にまとめることによるデメリットも今回だとないのかなと。

あとは、恒常的には使っていませんが HackMD はそこそこ使っていました。ミーティングの議事録なんかはこれで取るとリアルタイム同期されるのもあって便利です。

ちなみに、情報のやりとりがスムーズにできるとだいたいのことは良い感じに行く気がします。でもモチベーションの維持が大変ですが……

インフラ

インフラリーダーとして何をやったかというと、基本的になにもしていません。
インフラリーダーがそれでいいのか良く分からないんですが、今回の運営委員はインフラに強そうな人がたくさん居たので、多分任せたら良い感じにいくんだろうなって思いました。
おそらく僕がすべきだったのは進捗確認だったので、進捗確認と次にやるタスクの明確化だけは常に行いました。ミーティングについても、全体でのミーティングが月1程度だったのに対し、インフラ担当の中ではその倍の頻度である2週に1度の頻度で行いました。(週1開催という目標は達成できませんでしたが……)
あとは一部機材折衝をしましたが、実際僕がやったのはここまでなので、実際にどういうことを運営委員全体としてしたのかをつらつら書きます。

ちなみに大会ネットワークというのは結構自由なもので、スター型であろうがフルメッシュであろうがリング型であろうが、気合さえあればやることができます。コンテストのルールすら自由に変えられますからね。

ちなみに前回 (ICTSC6) の HotStage 末期には、テンションが壊れた運営委員が「次回はオールSDN, オールIPv6, オールBGPでやるぞ」などと叫びこんなホワイトボードを書き残していましたが、知られていません。消したら消えました。当たり前ですね。

さて、今回は SDN やってみようぜ! というテンションの元、いくつかの SDN 技術の検証なんかを最初の2ヶ月ほどを使ってやっていました。具体的には Midonet, OpenFlow, QinQ (これはSDNではない) なんかを検証し、どうにか取り入れられないかと試していました。結局色々な制約があってだいたいなくなったんですが、実は OpenFlow は競技ネットワークの片隅で動いていたりしました。参加者の皆さん、ご存知でしたか?
ラックの上部にハードウェア OpenFlow スイッチがマウントされていたことに気が付いた方は何名いたのでしょうか。でも実際に OpenFlow が動いていたのはそれではなく、下から3番目にマウントされていたラックサーバです。すみません。

競技ネットワークには、プロビジョニングを簡単にするという目的のため、各チームのVMがそれぞれ同じIPアドレス, ネットワークアドレスを持つ設計になっていました。つまり、同じネットワークアドレスを持つネットワークが15個 (=チーム数) 存在していました。運営ネットワークからこれらのVMを区別してアクセスするため、VLAN ID を利用してIPアドレスを書き換える不思議なNATが前回に引き続き今回も存在しました。前回はこのNATの実装として、Linux の netfilter に適用するカーネルモジュールが書かれていましたが、今回はこれを OpenFlow を使った Open vSwitch での実装に置き換えました。コントローラーは Python の ryu でした。

話が飛びましたが、ネットワークの設計について、最終的には ICTSC6 の基本設計を踏襲しつつ、実装する技術の選定からはゼロベースで行う方針になりました。基本設計は基本的に毎回ゼロベースでやっても同じ結論に帰結することが多いので、そこの手間を省き実装に時間を割いたということになります。

実装がどう違うかというと、例えば前回使っていた Apache CloudStack が OpenStack Newton に変わる程度の変化がありました。これは大きな変化で、途中 Horizon というコンポーネントがなかったことにされる程度の些事はありましたが、期間全体を通して安定動作し、再構築も容易な OpenStack はやはり良かった気がします。(前々回も OpenStack でしたね。ちなみに前々回使ったときは諸事情あり Neutron が使えませんでしたが、今回は使えました。時代の進化を感じます)
その他、過去2回に渡りインフラの都合で出題できていなかった IPv6 にまつわる問題を出題するため、コアネットワークに IPv6 を割り当てました。OpenStack の VM には必要性がなかった(+やはり不安があった)ため割り当てませんでしたが、Ocata では IPv6 Full Support らしいので、次回こそはあるかもしれませんね。また、これに伴い、対外接続を提供頂いた Home NOC Operator 様には グローバルIPv6 アドレスの割当を頂きました。ありがとうございました。

また、会場で提供している無線LANから問題VMの提供されているネットワークへの疎通性を持たせたりもしました。少なくとも僕の知るICTSCである限りの直近3回でこれができたのは今回だけです。それに伴い、802.1X で良い感じに認証してそれぞれのチーム, 運営のVLANへ繋がるようになっていました。
802.1X にすることで、参加者がLinux マシンを持ってきたら繋がらないのでは? という懸念がありましたが、幸い Linux マシンを持ち込んだ参加者は Network Manager で無事接続できたようです。ちなみに FreeBSD なノートPCでも繋がったらしいです。
ただ、残念ながら、Network Manager の入っていない Arch Linux を使っているとある運営委員の ThinkPad では繋がらなかったらしいです。

そういえば DNS の構築は僕がやりました。今回は NSD をコンテンツサーバとして、Unbound をキャッシュサーバにしてやったみたいです。ゾーンファイルなんかは自動生成で適当にやるようにしたりもしました。ドメインがあるのは結構便利で、作業効率が若干上がった気がしますし早めに導入しておくと良さそうですね。
え、Unbound + NSD は TAB問題だって? そりゃ DNS構築したときにハマったものを問題にしたんだからそりゃそうです。HotStage にねじ込んだらどこかの会社の1問目になっていてびっくりしました。
ちなみに解答としては、SELinux を無効にする (or 有効にした状態で 10053/UDP を NSD が Listen できるようにする)、iptables で 53/TCP, UDP を許可する、 unbound.conf へ insecure-domain を追加する、nsd.conf の 172.16.0.0/16 がミスタイプであることに気が付き、 172.16.0.0/12 に直すで満点です。文脈がわからないと何も分からないですね。
ちなみに半分ぐらいのチームが解いたみたいで、半分のチームは2問目以降へ進めなかったということになりますが、上の通り初歩的なミスを連続でやらかしているだけなので、頑張りましょう。

問題といえば、KYF問題は面白かったですね。これは僕がキックオフで酒を飲んでした発言を本当に実現されたもので、WoLパケットを送るとVMが起動するっていう、何が起きてるのか分からない問題です。実際にはネットワーク上に隠しVMが居てパケットをキャプチャしていて、WoLパケットを拾うと OpenStack Nova API を叩いて VM を起動しているんですが、ここまで説明しても凄いのか良くわからないですね。でもその実装力はすごいと思います。

また話が逸れましたが、競技用ネットワーク全体でBGPルーティングされたりもしたみたいですよ。

ところで、ここまでを振り返ってみて、何かに気が付かないでしょうか。
今回のネットワークにおいて、IPv6 はコアネットワークと参加者の手元に到達性があり、OpenFlow が組み込まれ、BGPが周り、そしてRadius認証のある無線LANが提供されました。つまり、夢はだいたい叶ったということです。
実際、前回こんなことを言っていたときには、こんなの叶うわけがないというニュアンスで笑いながら言っていましたし、そもそもこの話は今回の運営ではしていないので、本当に偶然なのですが。

結局、大会のインフラというのは合理性を取ると本当に何もなくなってしまうので、できる限り参加者に楽しんでもらえるように面白い要素を詰め込みつつ、いかに無駄な作業を省き、いかに面白い技術を取り入れ、そして安定したネットワークを参加者へ提供するかというところに向かっていくのが理想だと思います。そういった意味で、今回のコンテストはルールの面を始めとして参加者へ面白いものを提供し、インフラは結構面白いことができ、そこそこ自動化され、ちゃんと安定していたので良かったのではないかと。

次回はどうなるのか楽しみですね

コンテストサイト

今回もやりました。

アンケートを見る限り概ね好評だったようで、良かったです。初日の朝のミスは頭が真っ白になりましたが、git push してなかっただけでした。
基本的に前回起きたパフォーマンス系の問題 (真面目にRESTしすぎてDoSになった問題) を解決しつつ、今回のルール変更へ対応し……というのを真面目にやりました。具体的にはスコアボードを実装したり、問題の公開条件を変更(時間による条件を廃止し、問題を解く度に次の問題が公開されるようになった)、みたいなところを修正しています。
その他、真面目に SQL を勉強して ActiveRecord に泣かされたり、前回参加者に怒られたのがトラウマになったのでパフォーマンスチューニングをそこそこ真面目にやって5台の物理サーバを使い60物理コア, 120スレッドの環境で分散させたりした結果、Sinatra アプリケーションにもかかわらずエンドポイントによっては 1000req/s を優に超えたり (30~10000req/s) しましたが、実際には20req/s を超えることはほとんどありませんでした。ちゃんと負荷を見据えてエンドポイントを設計しなおしたのが功を奏したので、良かったです。
あとちゃんとリクエストやら負荷やらを Zabbix + Grafana 可視化したりしてくれてました。

懺悔になりますが、前回に引き続いてデザインとフロントエンドを実行委員の方へ丸投げお願いする形になりました。また直前で負荷を掛けさせてしまい、すみませんでした……。フロントエンドが Angular2 から Vue2 に変わったのは何かの陰謀です。

ドキュメンテーションとリファクタリングとテストコードはこれからやります……。

まとめ

こんな感じで、僕は前回と同じでコンテストサイトの開発に没頭していたICTSCでした。
全体としてもトラブルなく終わったと思っていますし、成功に終わったと言って良いでしょう。

まだまだやるべきこと、改善すべきことはありますが、ひとまずここまで。

ここに来るまでご尽力くださった、ICTSC7 のスポンサーの皆様、実行委員の皆様、そして支えて下さった運営委員の皆様へ感謝します。ありがとうございました。

大会自体は8/27, 28 (土日) が本番でしたが、運営委員は 4/24 のキックオフMTGから活動が始まっていて、実に4ヶ月近くの期間があったことになります。

写真とかは公式のレポートにたくさんあるのでご参照下さい。

NTT西日本杯 ICTSC6 準備期間 レポート – ICTSC | ICT トラブルシューティングコンテスト

NTT西日本杯 ICTSC6 DAY1 レポート – ICTSC | ICT トラブルシューティングコンテスト

NTT西日本杯 ICTSC6 DAY2 レポート – ICTSC | ICT トラブルシューティングコンテスト

 

ICTSC には運営委員として、第5回 (ICTSC5) から関わっていて、ICTSC6 では運営委員の副リーダーなるものを務めさせて頂きました。
(ICTSC6 は16人の運営委員と大人の方々による実行委員とスポンサーの方々によって成り立っており、その学生側ということです。)

ICTSC5 の反省を活かして、ICTSC6 のために自分が行ったことはとにかく1つに集約されていて、「とにかく見える化、情報の集約化を徹底して、何かをしたいときにすぐに行動できるようにする」というもの。

結局この記事は僕の自己満足ですし完全に主観で書いていて、最終的にはここに書いていない範囲、色々とよくないこともあったし、そもそも未だ僕が把握してない範囲で色々揉めたというのもあるのですが、結果としてそれを全部汲み取って解決できなかったのは本当に自分が悪いと思っています。未だももやもやとする気持ちもあります。
責任転嫁するつもりはないし、頼むから直接言ってくれという気持ちです。

以下、雑多に何をしたのか書いていきます。

ICTSC5 は、自分が初参加で周りが見えていなかったということもあるのだけれど、とにかく情報がブラックボックス化されていて誰が知っているのかすら良く分からないみたいな情報でつらかったという印象があった。

そのためにやったことは大きく2つあって、以下をしました。

• Wiki を作る
• Slack で Public チャンネルを大量に立てて話題を分ける / 見える化する (Private チャンネルを減らす)

Wiki は色々と模索した結果、 Crowi という国産の WIki が一番イケている印象があったので選択しました。半年間運用しましたけど本当に安定していて、ちゃんと動いて階層化ができて MarkDown がシュッと書けて良かったと思っています。
開発も精力的に行われていて、大会運営の後半では Elasticsearch と連携して検索機能も実装されて更に便利になった。開発者の人とも Gitter でコミュニケーションが取れて良いプロダクト。

とにかくありとあらゆる情報はこの Wiki から参照できるようにして、他サービスとして利用していた Google Drive やら Trello やらも全部参照できる情報をここに載っけるようにした。
合宿みたいなほぼ全員で集まる機会もあったので、Wikiの使い方をレクチャーしたり、みたいなこともした気がする。(あまりうまく行かなかったな、とは思っています)

結果としては、4ヶ月間で 147ページ ものページが作成されて Wiki で常に参照できる状態になった。
僕は文書化をほぼほぼ機械的にしていて、Slack で議論された事柄を片っ端から Wiki にまとめるみたいなことをした。
懸念していたのは、情報が錯綜することと古くなって参照されなくなることだったので、とにかくそこに気を使って更新を止めないようにした。

Crowi には Slack 連携機能があったので、#wiki-update みたいなチャンネルを作って通知を飛ばすようにした。
基本的に人が寝ている時間に作業する人間なので、4時とか5時とかにバンバン通知を飛ばしていた気がする。

Slack については完全に議論と雑談をするためのフリースペースでいいという認識で、1万件問題についてはログを取って参照できるようにすればいいし、そもそも確定した重要事項については Wiki に書くのが大前提なんだから、いくら流れてもいいのでとにかく書いてくれというスタンスで運用した(つもり)。

分報 (#times_{username})を導入したのもそういう意図があるし、運営委員そのものが日本中に散らばっているので、そのコミュニケーションの要となる Slack はとにかくコミュニケーションでツーでカーな感じにしたかった。

とにかく議論が混乱しないよう、分野ごとにチャンネルを大量に作成して、分けて議論がそれたらすぐに該当するチャンネルへ誘導するといったスタンス。
具体的には、 #infra やそのサブチャンネルとなる #infra-dc, #infra-network, #infra-server 問題作成に関連する #problem, 大会運営に関する #event-support などなど。times 含め59チャンネルが作成された (うち分報13チャンネル)

概ねこの方針は正しかったと思っていて、一部分けすぎて混乱したみたいなのはあったのですが、それでも全部が #random に書き込まれる世界よりはよっぽど健全だったと思っています……

そんな感じでやっていきました。

最後に、副リーダーとしてはリーダーの仕事を常に奪い続けるスタンスで行動していて、リーダーは常に手が空いてる状態を維持するように善処したつもりです。結局どうだったのかは人により意見が別れると思いますが、どうだったんだろう……

その他にも、無限に人にタスクを投げ続けるように立ち回ったつもりではあるのですが、結果としては僕がタスクを抱えすぎたり口を滑らせたりで本番直前で周りに大迷惑を掛けてしまったということが一番の反省点です。

結局、大会の運営というのは最終的にはどうやって人をマネジメントするかということに帰結していて、していますということです。

改めまして、この大会にご尽力くださった運営委員、実行委員、スポンサーの皆様、そして参加して頂いた皆様には厚く御礼申し上げます。ありがとうございました。