言語は Go、最終スコアは15532点、参考スコアを上から数えると45位だったようです。悔しい。
具体的な取り組みは下の方で述べますが、MySQL移行はバグなく完遂し、さてここからチューニングしていくぞ！という感じのところで終わりました。エンジンが掛かるまでの速度が足りなかった。

毎回、運営の皆様にはいくら感謝しても足りませんが、今回も取り組みがいのある問題で楽しかったです。ベンチマーカーも最後まで待ち時間がほぼなく、スコアも安定していたのでとてもストレスフリーでした。ありがとうございました。

マルチテナントで大量の SQLite3 データベースがあることが分かったとき、ISUCON本を読んだだけの人間には解かせないってことね!と思いながらニコニコしました。

ところで知り合いがたくさん著者に名を連ねているISUCON本ですが、予選の2週間前に購入し、予選開始1時間前に部屋から発掘されました。
30分ぐらいで流し読みしたのですが、大変実利的な内容に溢れているなあと感じました。nginx の upstream で keep-alive を有効にする方法は知らなかった……

9:00 起床

前日も早く寝るぞと自分に言い聞かせながら4時半まで起きてしまい、念には念で8時に掛けた目覚ましが1時間鳴っていました。すでにこの時点で心も体も終わっています。

部屋の隅にISUCON本が積まれているのを発見しました。ちいとぽも積まれています。
h-otterと合流するために移動しつつ、パラパラと眺めます。

10:00

まだ合流のため移動中ですが予選が始まっているようです

10:05

合流しました。 CloudFormation テンプレートを流します

10:22 初回スコア 2732

起動したのでベンチを回しました。この時点で分担も何も決まっていません。

とりあえず kataribe を入れたり pt-query-digest を入れたりします。
「そういえば先日の社内ISUCONで Cloud Profiler 便利だったな……」みたいなことを思いながら、入れ方を調べます。
GCPプロジェクトが必要らしいので作ったり、サービスアカウントキーを発行したりします。予選始まってからやることではない。

11:30ごろ

Cloud Profiler を入れたので眺めました

12:00

h-otter が MySQL 対応の実装を終わらせて、「Uber eatsでも呼ぶか〜」と言いながら、なぜか歩いてマクドナルドに飯を買いに行きます。なんで??

13:03 MySQL移行 3023点

MySQL移行が一段落します。今思うと速かった。

sqlite から SQL をダンプしてゴニョゴニョやり始めて十分程度経ったあと、 sqlite3-to-sql って名前のスクリプトあるけど?? と気付いて笑ってました。先に気付こうね。

とりあえず MySQL に流し込むこと数分、INSERT が一向に終わらないことに気が付きます。このままでは POST /initialize がタイムアウトしてしまうため、バルクインサートをするクエリに書き換えることにしました。

sed で気合でバルクインサートに書き換えましたが遅い。ここで1台目のインスタンスがメモリを食いつぶして死にます。160万件のINSERTを一発でやると死ぬことが分かる。
先日の社内ISUCONでもインスタンスのメモリを食いつぶしたんだよな……と思いながら1台目を捨てます。

これが答えです。

for i in `seq 1 100`; do echo $i; mv $i.sql $i.sql.bak; sed -z -e "s/);\n/);\n\n/" -e "s/NULL\n);/NULL\n);\n\n/g" -e "s/);\nINSERT INTO [a-z_]* VALUES/)\n,/g" $i.sql.bak > $i.sql; done

それなりに早くなりましたが、まだ遅いので tenant の player_score テーブルにおいて、 updated_at が一定以上のレコードを DELETE する作戦に切り替えます。これで10秒程度で POST /initialize が通るようになりました。

DELETE FROM tenant_X.player_score WHERE updated_at > 1654041599;
DROP TABLE tenant_X.competition;
DROP TABLE tenant_X.player;

他のチームの参加記を読んだら 「/var/lib/mysql をコピーする」「毎回 mysqldump を実行する」みたいな筋肉実装が多くて震えました……

確かここらへんで h-otter がなぜか flock を倒す実装を書くもベンチがコケました。
「そこはボトルネックじゃないっぽいし一旦revertしよ?」と、人の競技中の努力を無に帰すような心無い発言をしました。ごめんなさい。

なぜかここからしばらく無の時間が続きます。なぜ……

15:20 3758点

h-otter が competitionRankingHandler の N+1 を潰したようです。

15:50 6336点

グッとクエリを睨んで indexを追加。playerAddHandler がかなり速くなりました。

ALTER TABLE visit_history ADD INDEX (competition_id, player_id, created_at);
ALTER TABLE visit_history ADD INDEX (created_at);
ALTER TABLE tenant_X.player_score ADD INDEX (competition_id, player_id, row_num DESC);

マルチテナントのDBをそのまま持ってきたので、tenant_id は無視するようにしました。

16:08 7923点

h-otter が playerHandler の N+1 を潰したようです。

そして player_score に index を追加。
ALTER TABLE player_score ADD INDEX (player_id, competition_id);

バルクインサートと、JSONシリアライザの変更(encoding/json → goccy/go-json)をした結果、スコアがやや増加しました。(8269点)

16:36 10253点

なんかヤバそうな実装の dispenseId を倒しました。1万点突破。
よくわからんけど順序保証されてたほうが良さそうな気がしたので、 time.Now().UnixNano() を文字列にしてそのまま突っ込みました。爆速。

たしかこのあたりで、 tenant の player_score は (tenant_id, competition_id, player_id) ごとに最新の1行だけあればいいことに h-otter が気付きましたが、あまり速くならず。
この時点で row_num に関する index を落とすべきでした。

既存の tenant_{1..100} に対してもそれを適用しましたが、スコアとしては特に変化なしでした。

このあたりでベンチマーカのログから、タイムアウトでユーザーが減ったという表示がなくなり、ようやくISUCON始まったな! という気持ちになります。すでに手遅れ。

17:03 12505点

h-otter が jwt のパース結果をキャッシュします。神

17:45 14363点

app + DB の2台構成にした気がします。

17:50 15962点

流石にやや諦めムード。ログを切ったりできることをしました。
忘れずDEBUGログを切ったりスロークエリーを切ったりしました。偉い。

「再起動試験はしなくていいでしょ！」で終了

感想

1. MySQL 移行をバグらせずに完遂できた俺達は偉い (本当に偉いと思っている)
2. 毎回意味不明なバグを仕込んで後半暗澹たる感じにあるので、今回はほぼ最後までノーバグで駆け抜けられたのは良かった。良くも悪くも我々は大人になった
3. プロファイラ / スロークエリ / アクセスログの3本柱をちゃんと見ながら走れたのは本当に良かった。常に事実は正しい。fact based / metrics-driven
4. 後半のスコアのブチ上がり方が楽しかった。というかここに来るまでを自分は第一関門を突破した段階だと思っている。やれる改善はたくさん残っていたし、あと1時間あれば更に2倍, 3倍のスコアは出ていたんだろうなと思うと悔しい

そのほか

1. 午前中からの競技は本当に心も体も終了していて何も捗らなかった。ISUCONに必要なのは健康な心と身体
2. デカいテレビで h-otter がリゼ・ヘルエスタと名取さなの原神ガチャ配信をずっと流していた。「縁起がいいと思ったんだけどなあ」って何?
3. その後はリゼがパワプロしてた。リゼ・ヘルエスタについて私が知っているのは第一第二第三皇女のいずれかであるということぐらいです。
4. 最後1時間ぐらいローテンションお嬢様 (壱百満天原サロメ)流したら集中力が0になった。何?

前回再起動試験で落ちたのでチーム「再起動非対応」で参加しました。ベストスコアは4410点でした。再起動試験までたどり着けなかった……悔しい……

チーム「再起動非対応」は同期3人 (自分 @kyontan, @hogashi, @h-otter) での参加でした。学生は2人いたはずですがエントリーをミスったので学生は1人ということになっています。

使用した言語

私はRubyが一番得意だと思っていますが、非同期処理が書きやすいとか型が着いていると嬉しい、みたいなことはあり今回もGo言語です。
でも今回はN+1潰すときの型マッピングで無駄に時間を溶かしてしまったので、Rubyの方が良かったかもしれない……つらい……

開始前の準備

Prometheus/Grafana等のサーバの設定を @h-otter にお願いしました。前回のコードを読み返しつつ、何をしたかを思い出すなどした。

時間がなくて完全に忘れてしまいましたが、せめて練習はやっておくべきでしたね…

あと、 Alibaba Cloud の UI が色々不思議な感じで良かったですね。

本番

完全に正解していますが、今回はマイクロサービス問だということに気が付いたのは開始してからだいぶ経ってからでした。

開始30分前、チームメイトとの雑談「今日は何がでるかなー」「フリマアプリかオークションかそういうやつでしょ」「マイクロサービスとかね」「わかる〜」 #isucon

— kyontan@新刊はまだ (@sukukyon) September 8, 2019

今回できたことが異常に少ない気がする。kataribeのログを眺めつつ、チームでやったことは以下のことです。比較的時系列だけどそうでない部分もあるかも。

• 開始スコアは 2310
• 10:30 メモリ多いな〜って思っていたら2, 3台目のインスタンスタイプを間違えていたことに気がつく。インスタンス立て直し
  • コードは既にリポジトリへ追加していたのでチームメイトはルール/コードリーディングを進める
• 10:50ごろ: 作業開始
• 11:30ごろ?: MySQL 5.7 を 8.0 へ (@h-otter)
  • スコア変化なし
• 11:45 DBにインデックスを張る(@kyontan)
  • 多分間違えていて、これらにインデックスを貼りましたがあまり効いていなかったようにみえました
  • BigQuery の触りすぎでRDBのインデックスの挙動をほぼ忘れたのも敗北ポイント

config (name)
items (created_at, id)
items (id)
items (buyer_id)
items (seller_id)
shippings (transaction_evidence_id)
transaction_evidences (id)
transaction_evidences (item_id)
users (account_name)
users (id)

• 12:20: カテゴリをオンメモリへ (@hogas, @h-otter)
  • 2510点ぐらい
• 12:30: http2 対応, 静的ファイルをキャッシュ, アップロードされた画像を nginx で返すなど
  • スコア変化なし
• 13:30: config もキャッシュするように
• 14:00: 新着商品には発売中の商品だけを返すようにする (@hogas)
• 14:45  – 16:00: GET /users/transactions.json の N+1 を潰す (@kyontan)
  • 3500点ぐらい
  • なぜか色々ハマって2時間半ぐらい溶かしていた。これは敗北ポイント
  • 多分ここらへんでMySQLがサチらなくなっていた気がする
    • CPUがサチっていたことに気が付いていたが原因が分からず (pprofをなぜ見なかったのか……)
• 15:30: UserSimple が持つ情報は全てオンメモリでキャッシュする
  • ユーザの存在チェックだけするような部分 (権限チェック) も基本的にこれで対応できるのでそうした
  • 4210点
    • ここからスコア上がらず……
• 16:00: 同じクエリを何度か叩いているエンドポイントがあったので潰す (@hogas, @kyontan)
• 16:00ごろ: transactions 以外詰まってないしCPUに余裕があるので campaign (負荷レベル)を弄ったところ外部APIで 403エラー  {“error”:”IP address is not allowed”} が連発しだす
  • 主にGET /users/transactions.json での外部 shipment  サービスへのリクエストで連発
  • 外部APIへの403はアプリケーション的には500を返す仕様だったので、これが連発してベンチマーカが途中終了し完走しない
  • ここらへんで手詰まりに
• 17:00: 明らかに不要な SELECT FOR UPDATE を削除 (4箇所+ぐらい)
  • これかこれの次辺りで4410点。これがベストスコア
• 17:10: 外部APIを叩く部分で exponential backoff を実装 (@h-otter)
  • 変化なし / 403 が連発する
• 17:30: 外部APIをリクエストするエンドポイントだけ2台へ分散する
  • 403 の連発は解決せず、なぜ……
• 18:10: 最終スコア0点 (failed) で終了

色々施策を打つもスコアの変化要因が今ひとつ分からず頭が回っていなかったですね。
特に外部API が undocumented な 403 を返す (しかもメッセージは 「許可されていないIPアドレス」) というのは全然分かりませんでした。
マイクロサービス問題なら単一IPから連続でアクセスすると弾くようになっているのかな、などと思い、後半で外部APIへリクエストをするエンドポイントだけ複数台へ分散するなどしていましたが全く解決せず泥沼へ。

これベンチマーカと外部API側に問題あるのでは? みたいな気持ちになりつつ、マイクロサービス問だしちゃんとbackoffとか実行すればいけるでしょ! と思っていましたが、意図したエラーだったのかは未だに分からず……

他の方の感想を見た限りでは、ポータルサイトへ登録されていないIPからのアクセスは弾かれるみたいですが、これについてはUI上で正しく登録されていることを確認したので問題なさそうでした。
11:00 ごろにインスタンスを立ち上げ直してIPを再登録したのがポータルサイトの何らかのエッジケースを踏んだのでは? などと勝手に邪推しています。謎ですね。

そのほか、 campaign の値を変えると何が変わるのか (POST系アクセスが増える?)、みたいなことも終了後にログを分析してようやくなんとなく傾向がわかり悔しい気持ちに。

感想

終わってみれば途中重大な気付き (「外部APIのレスポンスキャッシュできるじゃん」「ユーザの嗜好に合わせて商品出し分けたら?」など) があり、見逃しの多い回でした。
bcrypt の件は全く気づいておらず。前回は初手でやった(があまり意味がなかった) pprof を今回なぜ見なかったのか……

短い時間で追い詰められている環境の中でどれだけ集中できる / 気付けるか、というのが重要になると改めて感じました。

コンテストとしては今回も設定が面白く、運営の手の込みようが分かり、かつ短期間で取り組みがいのあるとても良い問題でした。
運営の皆様、大変お疲れさまでした。

チーム「hhkb」で同期3人 (自分 @kyontan, @hogashi, @h-otter) 2回目の参加で2日目で Go 実装でした。学生枠突破ならずでした、悔しい。というよりは 55,982点で全体4位の点数で落ちました。ちなみに hhkb は h-otter, hogashi, kyontan, :boom: ???? の略です。
スキルセット的には、 @h-otter がインフラ(ミドルウェア含)なんでもできる+Goの経験が一番あるマンで、 @hogashi がアプリケーションなんでもできるマンで、 @kyontan はアプリとインフラとDBを一通り見られるマンみたいな感じでした。

今回の参加に向けて、取り組んだことをつらつらと書きます。

今回は真面目に本戦に行きたかったので前々日に ConoHa で ISUCON7 の予選を解き直して練習しました。具体的には ConoHa の練習用イメージを使って 1GBプラン x3台で予選環境を再現しました。結果、10時間程度で 5,204点から509,190点まで持っていけることが分かり、計測と試行の反復を効率的に行えば ISUCON の予選は突破できるという確信を深めていました。
また、前回は最後の最後でベンチマーカを走行させた結果点数が下がって落ちたので、前回の直後に「泣きの1回はやらない」というスローガンを掲げ、1年越しでそれを達成しました。

事前に準備したのは Prometheus のサーバ (@h-otter がいい感じにやってくれた)と、やること/できることチェックリストぐらいでしょうか。だいたい大会では開始した瞬間にテンパってそのまま撃沈するのが常なので、思考停止状態でもコピペで動くようなコード片とかを用意しておくと便利ですね。あとは思考が無になったときに確認するべき事項とかを作っておくと良いのではないでしょうか? 頻繁に無になって帰りたくなりました。メンタルは大事。

例えば下のような感じです。

当日は3人がローカルで開発し、本番環境のVMへバイナリを転送して検証する、という進め方でやっていました。Go はクロスプラットフォームでのビルドがしやすいのが便利ですね。

具体的にやったことを羅列します。というか @h-otter が書いていたのを未承諾引用します。順番は適当

• SELECT * する系のクエリを必要な列しか取らないようにした
• /api/users は user_id で reservations を全部とってきて、アプリ側で処理してやったらめっちゃ速くなった
  • ここでベンチマーカが重いと言ってくるエンドポイントが /users/:id から /api/events/:id/actions/reserve になった
• getEvent を getEventWithoutDetail と分けた
• getEvent と getEvents を2クエリに
• sheets へのクエリを消す
  • 効果があったのかは良くわからない
• MariaDB のチューニング
• Prometheus と Grafana で可視化
• ログインのクエリを1つに
• パスワードを平文で突っ込むようにした
• DB にインデックス張った (けどあまり良い結果がでなくてもんにょりした)
  • 最初に mysql コマンドでインデックス張ったけど結果が全く変わらなくて、なぜ? と思ったら毎回 /initialize でテーブルを作り直していることに気がついた。
• IN句を使いたかったので DBにアクセスするライブラリを sqlx に切り替えた
• トランザクションの開始がおかしいところがあったので直したり デッドロック時にエラーを返さずリトライするようにした

最後は予約時のシート決定を高速化するコードが安定化しなくて入らなかったり、Redisでいい感じにやろうぜみたいなことを思うだけ思ってやらなかったりしました。多分ここができると数万点上がったはず。

あとはスコアに関係ないけど作業便利になる系として、 エラーログでソースコードの行番号を吐くようにしたり、 Makefile 弄って1コマンドでデプロイできるようにしました。
開発は3台のサーバでバラバラにやっていましたがDBは1台だけを参照するようにしました。これはDBのチューニングとかがあって、1台でやった変更を他に反映したりするのが面倒くさかったので。こうすると、やりたい人間が適当にベンチマーク対象のサーバを変更して実行してやればいいので楽でした。

ソースコードは GitHub で管理し、いい感じにやりました。コミットログは下の通りです。

数字がタグに付いていることがありますが、これはいいスコアが出た時にバイナリごとコミットしてタグつけておこうぜ、みたいな感じにした結果でした。

今回の僕の活躍はよく分からなくて、いい感じデバッグ担当だった気がします。PRを見るなりとりあえずマージしてベンチマーカを落としたりバグ探しをしていたりしました。とにかく @h-otter がぶち壊しつつ @hogashi がいい感じに安定化するコードを書いてくれてよかった感がある。

Webサーバはh2oで十分高速だし、画像のトラフィック詰まりもないしで、とにかくアプリケーションコードの改善に注力した/するしかなかった8時間でした。

最終的に残り30分でベンチマーカを叩いたところ3万点前後のスコアが5万点に若干跳ねてそこで打ち止め。一度再起動をしてブラウザからアクセスできることを確認し天命を待ったところ、無事再起動試験で落ち失格となりました。天命……

(追記: スコアが跳ねたのは、最後に実行先サーバを変えた時に インデックスを張る処理を init.sh に書いたサーバで実行したからかもしれないことを思い出した。)

なぜ失格になったのかは分かっていなくて、おそらく /admin/api/reports/events/:id/sales の処理が遅くて不整合が起きて落ちたのかなあなどと思っていますが、2回連続で落ちるのは運が悪かったなと……

なんやかんやでやることがなくならない8時間で、やることが見つからない8時間よりは良かったのではないかと思います。

ISUCONの予選に向けて昨日は練習をしていたわけだけど、知っていることをちゃんと愚直にできれば比較的現実的な時間で予選突破ラインには十分立てることが分かったので良かった

— kyontan@新刊はまだ (@sukukyon) September 14, 2018

イキっているなどと言われてもこれは事実だと信じていて、典型的な N+1 を潰すなどすれば予選は通過できるはずなことは分かりましたね。くぅ〜〜

来年はちゃんと本選に行けたらいいですね。頑張りましょう。

そして、参加会場を提供していただいた mixi 様、惜敗の悔しさを教えてくれる最高のコンテストを運営をしていただいたISUCONの運営の皆様、お疲れ様でした、ありがとうございました!

以下は画像です

Ruby実装で挑み、最終スコア 38605点@2017-10-22 20:59:30, ベストスコア: 67792点@2017-10-22 20:44:59 でした。
ベストスコアでは予選ラインは超えていたんだなあと思いますが、最終的には伸び悩んだチームも多いようで、結局落ち着くところに落ち着いたのかなと思います。

ソースコードは kyontan/isucon7_qual です。踏み台でやっていた影響でコミッタが僕に見えますが、だいたい僕ではない。

次回も参加したいなという気持ちになってきたので、ひとまずはやったことを記していきます。

実は僕と @hogas は ISUCON6 の夏期講習に出たことがありましたが、そのときには日程等もあり参加しておらずということで、今回が初参加に。
@h-otter というインフラにとても強い同期がいたことや、周囲でも参加する人間が何故か多く、とにかくやっていくしかないという流れに。

チーム名を決めるところで消耗/摩耗し、本番前日までSlackはほとんど流れておらず。前日夜になって僕とか @h-otter がぽちぽち参加記やチューニングできそうなところを貼っていく感じに。

最近、正午より前に起きると早起きしたと言い出す僕が時間に間に合っていたあたりで色々とミスっていたんですが、東京都内の某所で3人で集まってやっていました。

事前にやった

とりあえずグローバルIPを持つ作業用サーバを用意しておいた。Rubyは事前に入れておいて、開始後に MySQL  も入れてスタンドアロンで動くようにした。あとあと @hogas はここでずっと作業してたり、 @h-otter が Prometheus のサーバを立てたりしていた。便利

コードについては GitHub リポジトリを立てて、普通にブランチ切ってやっていた。便利

情報共有は対面だったので、コードスニペット貼れるしリアルタイムで最高な HackMD を例のごとく使っていた。ベンチマーカの結果を全部ペタペタ貼っていたら容量制限に引っかかり、2スレ目、3スレ目が誕生した。HackMDのタイトルは「ISUCON7 まだチーム名で消耗してるの? 2スレ目」でした。

やったこと

ミドルウェアより下は正直 @h-otter に丸投げしていたので、アプリケーションより上をぽちぽち見ていました。
インフラについては正直何をしたのかは全容を把握していないですが、初手で nginx や MySQL に基本のチューニングを突っ込み、Prometheus で延々と監視しながらPDCAを回していたっぽい。正しいインフラチューニングや……

言語は僕と @hogas が使い慣れている Ruby を選択しました。正直クエリ弄るぐらいでいいなら Go でもいいよねーって言っていましたが、慣れてるほうが便利でした。Sinatra の文字列には幼馴染のような安心感がある。

僕と @hogas はよしなにアプリケーションコードを読みながら色々した。以下は色々

erb を haml に置き換える / hamlit gem の導入

気持ち+2000点ぐらい

初期実装が erb で、erubis に置き換えるというのも一案ありましたが、行きの車内で「erubis hamlit 速度」などで検索した結果やっぱり hamlit かとなっており、ノータイムで haml に書き換えることを決断しました。
erb2haml とかあったね〜と @hogas と話しながらやってもらった。

以下様子です

. @hogextend 「erb2hamlどうやって使うの?」ぼく「とりあえず rails new して突っ込んでみたら?」 #isucon

— きょんたん (@sukukyon) October 22, 2017

僕「ﾖｯｼｬ(gem install rails)」

— hogas (@hogextend) October 22, 2017

(erb2haml はコマンドラインツールとかではなく、Rails に追加する rake タスク群ということに気が付いた様子)

nginx <-> Puma を UNIXドメインソケットに

気持ち +2000点

定番です。HTTP 5000/tcp から UNIXドメインに変えた。

SQL のクエリ改善

気持ち+10000点ぐらい

これは定番ですね。SELECT のカラムを絞ったり (@hogas)、 LIMIT を付けたり (@hogas)、インデックスを張ったりした。N+1 は手を付けていましたが、コード変更に集中できなくて最終的に投げてしまった。悔しい

終了直前にソースコード眺めてたら statement.close を意図的に忘れていそうなコードが見つかり慌てて修正した。スコア上の変化は分からず。

 画像を静的ファイルに書き出す

気持ち+15000点ぐらい

ユーザーのアバター画像が DB に blob で入っていたので、雑に Ruby のワンライナーで書き出して (ここまで @kyontan)、 nginx に try_files で食わせる (@h-otter) みたいなことをした。
既に話題になっていますが、最終的には Cache-control 的な問題でキャッシュヒット率が悪かったらしい。むむむ。

SHA1 を殺す (パスワード, アバター画像)

気持ち+2000点

パスワードのソルトを生成している random_string を見たときに、これは要らないのではと思ってしまったのが始まり。初期データのパスワードはハッシュ化されていたので、 id が1000より大きい user は全て平文パスワードを DB に突っ込んだりした。 (by @hogas)
アバター画像は、ファイルの内容を SHA1 したものをファイル名に使用する実装になっていましたが、もしかしていけるのではと言いながらユーザIDをそのままファイル名にしたら通ってしまったのでそのままに。

Redis (最終的に入れず)

気持ち+2000点ぐらい(?)

画像をバイナリで入れるのはまあそうだね〜〜と言いながら、Redis に載せようとしていた。正直コードの変更は大したことがないのは分かっていたので実装はシュッとできたけれど、実際に動かしてみると意外とスコアに有意な差が出なかった。その後も永続化周りで少し足踏みしていたり、他の変更を見ていたために最終的に入れられなかった。残念

アプリケーションサーバ3台化

気持ち +3000点ぐらい

@h-otter がラスト30分でイケると言い出してやってた。ここで Puma (アプリケーションサーバ) のスレッド数を調整していた (10 -> 18スレッド)時に出したのがベストスコアです。

その他

• 再起動試験は何の問題もなかった????
  • 過去の参加記なんかを見てるとここが関門かなというのはあったので絶対やっておきたかった (やりました)
  • Redis に手を出してなかったのでここで不安はあまりなかった
• MySQL の Too Many Connections が割りと頻発した
  • ここは statement.close 忘れも影響してるかなと思うけれど、500が途中で出たり安定しないことがあった。最終的には安定しました
• 日ごろは頭痛の頭の字もないのに、とにかく頭痛が酷かった。緊張にはやはり弱い。
• JSONシリアライザが遅いのは分かっていて、 Oj を入れるぞと言いながら入れるのを忘れた。あれを入れただけでシリアライズについては数倍速くなるというのは分かっていたので、ただただつらい。
• ICTトラブルシューティングコンテストでスコアサーバを延々とやっていたことが知見として生きたとは思う。DB設計なりアプリケーション設計なりチューニングなり。
  • 当時のオーバーキルなチューニングしたときの操作が生きることになるとは思ってなかった
• 最後のベンチマークの結果を見て全員で嘘やんって言ってた
  • ルールを読んでなかった。次回は読みます
  • にゃーん

そういえば30分ほどですがスコアボードの上位に乗っていました。学生トップなのは分かっていたので、これは予選突破できるんじゃない? とか言いながら笑っていたのを覚えています。このあたりが後々ボーダーになるんだろうな〜という話をしていて、実際そうなったのである程度読みは正しかったのかなと思いつつ。

総括/最高

監視に強い人(@h-otter)強い。常に横で IOバウンドかネットワークバウンドか、みたいなことを見ながらアドバイスしてもらえる環境は最高。

限られた時間の大会という環境でもくもくとコードいじれる人(@hogas)強い。とにかく僕が頭が回ってなくてコードをまともに書けない状況にあったので、そんな中でちゃんと改善する変更を入れ続けてくれて最高。

基本的にどこに手を入れればいいか、この変更はコスパ的にどうかみたいなことを常に考えながら立ち振る舞えてはいたと思うので、そういった点ではなかなか善戦はできたかなと思いつつ。
しかし、できたことは山のように残っているなという感想。、途中で集中力が切れてしまったこともあり、こういう結果になったのは悔しいなと思う。

ただ、これだけ言えるというのはつまりバランスが最高だということに他ならなくて、こういった駆け引きができるバランスのゲームを作るのはとにかく難しいなと思っているだけに最高だな！！！という気持ちです。
こんな最高のコンテストを生み出してくれた運営の皆様、ありがとうございました。そしてお疲れ様でした！

本選に行かれる皆様はぜひとも頑張ってほしいなと思うところです。

次回は最高の♨️から最高の心構えでやっていきたい。

• 第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 に書き込まれる世界よりはよっぽど健全だったと思っています……

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

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

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

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

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