言語は 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 を今回なぜ見なかったのか……

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

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

情報科学若手の会という情報科学オールジャンル若手オンリーイベントに参加しました。でも最近は若手オンリーじゃないみたいです。
前回が初参加で、初参加なのに突然肩を叩かれて幹事になったので今回は幹事としての初参加になります。

ちなみに幹事ってなんだよみたいな話とか私が気になるお金とかの話とかもろもろは代表幹事のkurochanさんが書いていますので興味がある方はご参照ください。

発表のテーマとしては毎回様々あるのですが、なぜか近いテーマを複数人が発表するという事象があり、前回はブロックチェーンで今回は機械学習とかプログラミング言語といったテーマがそれに当てはまっていた気がします。

個人的に一番分かりが多かったのは Segment Routing の話で、なるほど経由地を含めた経路のルーティングとかができて便利そうみたいな気持ちになりました。OpenFlow とかでもできそうですが、ラベルスタックで表現するとハードウェア実装のスイッチとかで高速に実装できて良さそうだなって思いました。

コンテナデータセンターの話は個人的に一番聞きたかった話で、法的な側面でどういった解釈をしてどのように実現するのか、という話やコンテナの魅力が延々と伝わって来て面白いなと思って聞いていました。狭い部屋が好きなのでコンテナを自宅に改造して住みつつ隣のコンテナをデータセンターにしたいですね。

生物から学ぶ深層学習という話は深層学習概論みたいなところがあり、どういった歴史背景でどのように深層学習というものが生まれ、アカデミアとしてはその研究がどのように進んでいて、進んでいくのかというところの傾向が分かって面白かったです。
その次のPFNでの深層学習の話は色々なネットワークの紹介なんかがあり、例えばGANに関する説明なんかは腑に落ちるところがありました。
GANで作られた画像とかはTwitterとかで見ることがしばしばあったのでGはGenarativeのGかな〜ぐらいの認識をしていたのですが、あれは敵対的ネットワークというものでノイズを基になんらかの解釈ができるような(それらしさを持つよう)に延々と学習するんだな、みたいな説明があってとても納得しました。分かってきた。

どの発表も難易度がそこそこ高かったなと思いつつ割と個人的には適度な難しさだったなとは思うんですが、それはたまたま自分が知っている知識がそのあたりに偏在していたからだと思っていて、一般的にみるとそこそこ難易度が高めな発表が多かったのでは、と思っています。
前回は割とテーマ的に自分が知っているところと被らないテーマが多かった気がした(うろ覚え)ので、このあたりは難しいですね。

会場的な話としては、前回は伊東の山喜旅館だったのですが今回の会場は軽井沢の軽井沢研修所というところでした。軽井沢研修所、温泉がない以外は個人的には一万点みたいなところがあり、過ごしやすくて良かったです。ちなみに散歩したところ裏で温泉を掘っていたので来年も軽井沢だったら温泉に入れると良いなって思ってます。
温泉の問題は個人的にはあまり問題視していなくて、それはなぜなら帰りに温泉に行ったからです。軽井沢はそれ自体が温泉地で例えば星野リゾートの発祥地である星野温泉(トンボの湯)というのがありますが、そこから山を越えると草津温泉や万座温泉、鹿沢温泉などがあり、最強の温泉地帯が広がっているわけです。このエントリで書く内容ではないので割愛しますが万座温泉は青白色のにごり湯で最高でした。

幹事として何をしていたかというと概ね無なので来年はもう少しがんばります。 :innocent:

チーム「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の運営の皆様、お疲れ様でした、ありがとうございました!

以下は画像です

.+のインターンに(参加(し(まし)?た)|行った)シリーズも気が付いたら3本目です。タイトルに統一感がない。

インターンの正式名称は 「WINTER INTERNSHIP 2018 -ENGINEER-」です。

ちなみに過去のエンジニアインターン参加記事は以下にあります。よければご参照ください。

• Wantedly のインターンに参加した
• サイバーエージェントのインターンに行った

多分この記事を参照する人の7割ぐらいは、そもそもこのインターン (業務委託契約なので実際にはインターンではない) の概要に興味があると思います。これは探すと若干数ヒットするので、こちらの偉大なる先達の記事をご参照ください。

Recruit Summer Internshipに参加しました． – 未来永劫
http://shopetan.hatenablog.com/entry/2016/10/13/133031

cormoran’s note – Recruit Winter Internship 2017 参加記
https://blog.cormoran-web.com/blog/2017/03/rhd-winter-internship-2017/

DeNAのサマーインターンシップに参加してきました – たいむかぷせる2
http://studio-graph.hateblo.jp/entry/2017/09/16/211335
> リクルートホールディングスのインターンに参加していたので,それはまた書きます。

リクルートのエンジニアインターンはランチがすごいという前印象があり、それを印象づけた記事があったと記憶しているのですが、ググっても引っかからなかった。
ぜひご連絡ください。ちなみに、実際ランチは感動しました。記事の下の方をご確認ください。

インターンの感想にありがちな NDA (秘密保持契約)でほとんど書けない状況なので、それ以外のことを少しだけ書きます。

選考

記憶にありません。
というのは建前として、実際にはコードテストや人事面談、エンジニア面接等のステップからなります。(追記: 2019年ごろ?にコードテストのシステムが変わったとか変わってないとか)

事前面談でメンターから超魅力的な提案をされて、「それは最高ですね、やっていきましょう」みたいな雑な返しをした気がします。振り返ればこの時点で優勝(注: 別に優勝という概念はない)していましたね。

やったこと

配属は RTC (リクルートテクノロジーズ) で、あの事業の分析基盤をフルマネージドクラウドで作り直すようなことをしていました。

データ(分析)基盤や、パイプライン/ワークフローみたいなものに興味があったこと、クラウドに知見がなかったのでそのあたりも吸収できるみたいな感じで、最高のテーママッチングだったと思います。

メンターは、あのデータ基盤の分野では日本で第一人者といっても過言ではない @yuzutas0 大先生で、とにかく最高のやっていきがあるチームでやっていってました。とりあえずブログを見ると知見が一杯あって便利です。なんでもできるのかこの方は……?

インターン参加記によくある困難とそれを乗り越えた系の話

パイプライン、結構色々なツールが絡んでくることが多く、そのあたりをいかに上手く結合させるかみたいなところでアーキテクト力が養われたと思います。

また、インターン感想記事では、「○○を検証しました!」「こういうの作って便利にしました!」みたいなのは比較的よく見かけますが、実際にプロダクションに載るところまではいかないことが多いと思っていて、今回はそういうの無しでちゃんと載せるぞみたいな意志でやっていました。

ただ、スケジュール感は破滅していて、当初やるぞって言っていたことの下準備に日程の9割が費やされてしまいました。しかし本題は2日で終わりなんとか間に合った。流石に見積もりが甘すぎた。とはいえ単純作業は少なく、終始創造的なことをやっていた気がする。Toil (学びのない繰り返しタスク) じゃなくて最高。

あと、やっぱりインフラをやった上での感想として、オンプレ系の知見はかなり活きました。その他に基礎的な知識はどこでも使えて便利。(例: シェル芸)

読み書きした言語は (J)Ruby, Python (2/3), Groovy, Java, SQL, Shell Script, node.js とかではちゃめちゃマルチスタックな感じです。無駄に手を広げておくと何かと役に立つことが分かりました。
特に個人的には Python はクソだと思っていて触りたくなかったんですが、逃れられずにやっていたらいつの間にかアレルギー症状が収まっていたので最後の2日に役に立ちました、でもクソだと思う。実用的だとは思いますが……

結果として、だいたい全部をゴリゴリやったらなんかだいたい全部できました。
惜しいことに実運用に乗せて切り替えまではいかなかったんですが、並行運用までいったので多分近いうちにいい感じになると思います。(よろしくお願いします。) (追記: 切り替わったらしい)

環境

最高の一言に尽きます。

これは面白イベントなのですが、インターン前日にメンターからメッセージが来て、メンター「MacBook ProがUS配列なんだけど」私「じゃあJISキーボード持ってきます」メンター「(本体とキーボードが分離しているのは)疎結合でいいですね????」みたいな会話がありました。既にこの時点でコミュニケーションが雑になっていて、疎結合は最高ということが分かる。(???)

そして、やはり有名なインターンに来る学生はやはり優秀な学生が多い。ここでもまた知り合いに会ってしまい、世界は狭いなと思いました。インターン生交流イベントもあって、特に参加を強制されて面倒、という感じではなく普通に楽しい。良かったですね。

ところで社員証のストラップをこれにしたらモチベーションが主観で3割ぐらい上がりました。ぜひblessing softwareの一員としての意識を持って仕事をしましょう。

[amazon_link asins=’B01NAIDKN5′ template=’ProductAdMonora’ store=’monora09-22′ marketplace=’JP’ link_id=’eef6befd-3348-11e8-b166-018151754d97′]

コミュニケーション

これは心理的安全性が確保されていました、の一言で済む話です。伝われ。

メンター (@yuzutas0) が最高なのは上にも書いたんですけど、上手く文脈の疎通ができて良い意味で雑なコミュニケーションが取れるというのはとてもいい環境です。
とくにオンボーディングはよく整理されていて、上司力の高い上司でした。多分僕も部下力を発揮したと思う。

インターン、コミュニケーションが最初から雑すぎて、「やっていってください」「やっていきます」みたいな感じになっている

— きょんたん (@sukukyon) February 16, 2018

ところで Slack のアイコンを普段使っているもの (凪のあすからの汐留美海)に変えたところ、メンターに「版権アイコンじゃん(笑)」と煽られたのはまだ根に持っています。

マジでほぼ1~2日に1回の頻度で1on1をして、予想される不安から取り除けるものは取り除いたり、設計についてアドバイスをもらったり、レビューで突っ込まれたりdisられたりしてとにかくコミュニケーションの密度は高かったです。

Slack は雑に #times_kyontan に延々と思考を書き連ねていたら割と色々な人が絡んでくれて議論もできて技術的雑談ができる環境最高だなって思いました。
流石RTC 、噂に聞く色々な人がいるなと……

やっていきがある環境って多分こういうことなんだなって思います。

生活

流石に最後に「もっと早く来られると良かったね」とか煽られるかなとドキドキしてたんですけど、特に何も言われませんでした……

(そういえば事前面談で「朝弱いんですけど、遅くてもいいですか」「日が昇っている時間に出社していれば」「なるほどね」みたいな会話をした気がする。)

結果的に、毎日座れる時間に通勤して、いい感じにやって、座って帰って寝る、みたいな最高の生活をしていました。
東京駅直結(ホーム→自席が5分)は最高でしたね。

ちなみに最終日はグリーン車で通勤しました。これはその様子です。

贅沢なインターン生なのでグリーン車で出社するぞ pic.twitter.com/GhtCaiPIpK

— きょんたん (@sukukyon) March 28, 2018

その他、なんかバランスボールが転がっていたので1週間ぐらいその上でふよふよしながら仕事してました。
さすがにふよふよしすぎて怒られるかなって思ったけど最後まで怒られは発生しませんでした。

夜に、疲れたのでルートビアを買ってきて飲んでいたらメンターに酒を飲んでると思われていが特に突っ込まれなかったというイベントもありました。それは流石に突っ込んで欲しかったですね。

あと、転がっていた Thunderbolt Display を使ったところ、遅延が少なくて割と最高なんですけど、グレアでかつ画面の位置が高く首が疲れたので、結局 MacBook Pro の解像度を 2560×1600 とかにしてやってました。

飯

飯の話が既存のブログ記事でされているからと言って飯の話をしないとは言っていない。

ランチは毎回色々な部署のすごい人と話すことができたのですが、私がインターンで一番上手く使えなかったのはこれに尽きると思います。人から話を引き出すのが下手すぎるので今後なんとかしたい。

画像を並べ立てても品がないのでもっと品がない感じで行きます。

I'm at 日本ばし すし鉄 in 千代田区, 東京都 https://t.co/J265C2nlY2

— きょんたん (@sukukyon) February 21, 2018

I'm at 日本橋 伊勢定 in 千代田区, 東京都 https://t.co/frpZC4f5lP

— きょんたん (@sukukyon) February 23, 2018

I'm at 天ぷら 新宿つな八 総本店 in Shinjuku, 東京都 https://t.co/hxZEazMsxq

— きょんたん (@sukukyon) February 26, 2018

I'm at 瓢喜 京橋店 in 中央区, 東京都 https://t.co/MUZUr61La0

— きょんたん (@sukukyon) February 27, 2018

I'm at 浅草今半 in 千代田区, 東京都 https://t.co/XtmRpED6DY

— きょんたん (@sukukyon) March 7, 2018

I'm at 焼肉トラジ 京橋店 in 中央区, 東京都 https://t.co/7XyyyZeXcL

— きょんたん (@sukukyon) March 8, 2018

I'm at 焼肉トラジ 京橋店 in 中央区, 東京都 https://t.co/p304kR2qVe

— きょんたん (@sukukyon) March 13, 2018

I'm at 叙々苑 游玄亭 in 千代田区, 東京都 https://t.co/GYV5p301tP

— きょんたん (@sukukyon) March 26, 2018

あとは最終成果発表スライドから1枚引用します。

最終成果発表で飯の自慢をする時間がなかったので、上のスライドみたく全部のスライドの背景に飯やらなんやらを積めたんですけどあまり気付いてもらえなかったらしい。

まとめ

最終成果発表ですが、あまりにも話したい内容が多すぎてスライドが163枚になりました。3分ぐらいオーバーしました。ダメです。
とりあえず一番ウケた(と主観的には認識している)ので良かったとします。

(注: 優勝という概念はない)

今回は全能感を持ってやっていくというのを意識して立ち振る舞っていて、とにかく現状の構造だったり、社内ドキュメントだったり、場合によってはソースコードまで片っ端から目を通すようにして1ヶ月を楽しみました。

個人的には全能感があると、不安が減ったり精神的なハードルが下がってストレスも減ったりで良いことづくめなので、良い振舞いだったなと。

これは簡単なようでいて、そもそもそういったものが当たり前のように文書化されて構造化されている環境というのがそもそも恵まれていて、そういうところも含め最高でした。

統括

最高のインターンで最高にやっていきを発揮して最高の成果を出しました。でも色々惜しいのでやっていくことにします。

そういえば今回のインターンの報酬で Sublime Text 3 のライセンス買うわｗｗって開始時に言ったの思い出したので買いました。
日頃お世話になっているし今回も生産性が100倍ぐらいになりました。

お世話になったメンターやチームの皆様、関連部署の皆様、人事の皆様ありがとうございました!!

ところで、東京駅に前から行きたかった常陸野ブルーイング・ラボがあったので、インターンと関係なく行ったりしました。
これは勢い余ってバゲットを頼みすぎる図です。美味しかったなあ。

残していきたい/おきたいシリーズです。

Wantedly のサービス自体は比較的前(4年前?)から使っていましたが、まさかインターンに来ることになるとは当時は思ってもいませんでした。
やはり学部3年になると就活の時期ということになるわけで、スカウトを何件か頂いていたうちの1件で実際に人事の方と話させて頂いた上で決めました。

働き方、というよりはそのモチベーションを変えるというところで社会を変えようとしているというのが会社の考え(であると僕は認識しています)で、それは自分の考えとも一致するところがあり、技術的にもそこそこイケているのでは、というところが選択した理由になります。

参加したのは 9/5-22 の平日で、所用の休みを除いた12日でした。(業務委託契約なので実際にはインターンではない)

今夏はフロント/バックエンド/モバイル/機械学習みたいなコース分けがあり、とはいえ別に同じコースだからといって同じ日程であったり同じ人の下であるとは限らないという感じでした。日程も内容もある程度メンターと話し合って決めることができます。

面談で、最近のフロントエンド技術(React使ったSPAみたいなこと)には興味があるみたいな話をしたところ、なぜかバックエンドチームになり Rails を書いていた気がします。ずっとRubyばかり書いてますし、最近のアルバイトでは Rails でアプリケーションを書いていたので、そのあたりが考慮されたのでしょう。ちなみにこの話を当日したところ様々なアレがあり、最終的には最後の週にReact漬けになりました。React難しいね!

雑感

バックエンドというのはいわゆるサーバサイドのアプリケーションですが、私は Wantedly Visit という Wantedly の一番最初からある企業への訪問であったり、そのスカウトであったりというところの改善作業をしていました。
詳細は多分あまり書けないのですが、技術サイドでは BigQuery を初めて触ってクエリが実行されるごとに課金される様子を楽しんだり、そこから集計したデータを使ってごにょごにょしたりしていました。

ただ、やはり大規模 Rails というのはなかなか凄みがあって、様々な趣があり読んでいて面白いなと思いました。
そしてやはり社員の方の地力が強く、様々な点の技術判断というのはなかなかイケていると思っていました。僕が今回実装した部分についても、しっかりとデータに基づいた議論がありとても良かったです。あとは Ruby が好きなのが伝わってくるコードベースで個人的には良さみが深かったのも良かった。

最終週には前述したフロントエンドチームでも少しコードを書かせて頂き、本番へマージされたのはごく一部でしたがアイデアの PoC みたいなことをしていました。UX を良くするためにブラウザのレンダリングパフォーマンスと格闘する経験はなかったので、面白いなと思ったり。

その他

白金台MGビル、始めてきた時に強い既視感があり、Cookpad が昔ここにあったなあという気持ちになった。(フロアは違うらしい)
土地柄、やはり飯が高く1000円スタートみたいなところがあった。様々ある。

インターン期間中に上場があり、パーティーなどがありエモい雰囲気であった。

最近色々な記事がありましたが、残業しているインターンは確かに多いが別に定時に帰ろうが、それより早く帰っても何も言われない感じでした。そもそも業務委託契約なので業務時間も明記されていないし、ちゃんとやることをやればよい。そもそも残業しないと終わらないようなタスクを抱えるのはコミュニケーション/マネジメントの欠落では。
まあ、周りを見ているとこの内容でこの報酬かという気持ちにはなったりした。色々ありましたね。(ネガティブにもポジティブにも / 人事とも話した)

インターン生が多かったので色々話したりした。やはり2, 3社目としてこのインターンに来る人が多いのだなと再認識したりした。そしてやはり世界は狭い。

人事面談が毎週あったのも個人的に良かったポイントで、色々話したり聞いたりできたので、会社についてや、働くということについても色々聞けたのかな、と思う。

総括

新しい技術に触れるというよりは、どちらかというとアイデアで勝負したり、サービスを成長させるためにちゃんと数値を見ながらやる、みたいなところへ注力したインターンでした。
しかし、技術的にもある程度のレベルはしっかりと求められており、それに基づいたやっていきがありとても良かったなと言うのが感想です。
普段使っているサービスの裏側が見られるというのはやはり楽しいですね。

メンターの方との分かりややっていきもとてもあり、タイムリーなところではISUCON7 の予選も突破していたのを観測して、やはり強いなとあらためて思うなどした。

そんなこんなであっという間に過ぎた3週間でした。改めて、Visit のとある組織の皆様、メンターの方、人事の方、ありがとうございました!!!

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 が運営委員をしていることを観測しました。不義理を働いてしまった……)

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

さて、第50回 情報科学若手の会 (…) | 情報科学若手の会 というものがあります。
詳細はリンク先の説明に譲ります。

毎年この時期にやっていることは以前より知っていましたが、秋の花火を打ち上げる諸用と被っていたことが理由で参加できずにいました。
今年はかぶらないという事で、参加させて頂きました。

雑感

カジュアルではありながらも、少しでもアカデミックに若干寄ったイベントというのは初めてで、質疑応答の時間も長く、新鮮なイベントでした。

特に登壇者層は若手から若手(ではないが夢がある者)へと幅広く、話題もノンジャンルといって良いほどに幅広いものでした。ブロックチェーンやAIといった最近流行っているテーマから、人生戦略、ECMAScript, 研究支援, 地政学, 量子プログラミング, 考古学, オフィスを建てる, … 様々ありました。

交流の時間も非常に長く、また幹事の方々が考えられた交流イベント(QRコードへ付箋を貼りつつ戦っていく、往年のバーコードバトラーのような何か)もとても盛り上がりました。ありがとうございました!!

また、ナイトセッションでは酒とエモい話が並び、大変にNSFWな感じで良かったです。

登壇した

そして、やはりイベントに出るからには登壇する必要があるようで、気がついたらショートセッションの枠へ登壇登録をしていました。しかも実際にはショートセッションを2つマージし @h-otter と合同で登壇するという暴挙にでていました。
内容としては、ICTトラブルシューティングコンテストの紹介と称してざっくり歴史をまとめつつ、自分たちが参加した会でのやったこと、辛かったこと、上手く行ったことなどを順に追っていく成長記録のような感じでした。2年間ですが、色々あったのかなあと思いつつ、やはりマネジメントは難しい。
ロングトークのマネジメントも難しいですね、精進します。

スライドはこちらです。HackMD (Reveal.js) なので一覧性が低く申し訳ないです :bow:

雑感その2

会場の Wi-Fi も非常に快適で、やはり Aironet は最高という気持ち。そのまま勢いで自宅の Aironet をギガビット対応させるべく電源を購入しました。

やはりこういう少し変わったイベントには少し変わった人が多く来るという(主観的な)偏見があり、実際そのように様々な人と話すことができました。しかしコミュニケーションは難しい、やっていきたい……

その他、次年度の幹事になるなどのイベントが発生しました。マネジメントつらいという話をするとマネジメントをする側になるのだなあとしみじみ思う次第です。どちらかというとオーガナイズよりな気がしますが、楽しんだもの勝ちなので全員で楽しんでいけるような会にしたい……!

やっていくぞ。

私信になりますが、もうすぐ就職か院進かというところで色々な悩みが発生したりしなかったりしています。
フィーリングでやっていきますが、もし何かお話等ありましたらご連絡いたしましたら幸いです。

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 のスポンサーの皆様、実行委員の皆様、そして支えて下さった運営委員の皆様へ感謝します。ありがとうございました。

MMA は大学のサークルですが、前回のチーム overflow +αみたいな感じでした。主要メンバーが運営にいるし、新たに入ってきた後輩はなぜか別チームでやっていたので、謎です。

僕は VoIP (Forensics 100), Memory Analysis(Forensics 100), PNG over Telegraph (Crypto 300) を解きました。とりあえずメモです。

VoIP (Forensics 100)

pcap が振ってくるので、WireShark で開いて VoIPツールで再生して終わり。これICTSCでやったやつや……
SECCON{9001IVR}

Memory Analysis(Forensics 100)

Volatility というツールを使えということだったのでその通り頑張ってみる。

strings forensic_100.raw | grep http をメモ
./volatility_2.5_mac -f forensic_100.raw dumpfiles --dump-dir dumpdir -S summary.txt
summary.txt を見るとプロセスの絶対パスが取れて、怪しい svchost が分かる (PID1776)

$ ./volatility_2.5_mac -f forensic_100.raw pstree
(snip)
.... 0x81f65da0:svchost.exe 1776 672 2 23 2016-12-06 05:27:10 UTC+0000
..... 0x8225bda0:IEXPLORE.EXE 380 1776 22 385 2016-12-06 05:27:19 UTC+0000
...... 0x8229f7e8:IEXPLORE.EXE 1080 380 19 397 2016-12-06 05:27:21 UTC+0000
(snip)

プロセスツリーが取れて、 PID 1776 の子プロセスが分かる

$ ./volatility_2.5_mac -f forensic_100.raw connscan
Offset(P) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ---
0x018c3cc8 192.168.88.131:1077 180.70.134.87:80 3676
0x0196f6a0 192.168.88.131:1122 175.126.170.70:80 3676
0x0233bbe8 192.168.88.131:1034 153.127.200.178:80 1080
0x02470238 192.168.88.131:1036 172.217.27.78:443 2776

PID 1080 がアクセスしてるのが `153.127.200.178` だと分かる

上の strings でアクセスしてた URL のドメイン部分を全部 `153.127.200.178` に変えて、curl

echo http://153.127.200.178/
curl -I http://153.127.200.178/ 2>/dev/null | head -1 | grep -v 404

こういうのを書き連ねて、 200 OK が返ってくるものを探す

(snip)
http://153.127.200.178/entry/Data-Science-import-pandas-as-pd
HTTP/1.1 200 OK
(snip)

後はアクセスして取ってきたファイルを開く

$ cat Data-Science-import-pandas-as-pd [/Users/kyontan/Code/ctf/2016online]
SECCON{_h3110_w3_h4ve_fun_w4rg4m3_}

PNG over Telegraph (Crypto 300)

待っていました YouTube 問題、と思ったんですが、50分を超える動画で最初から心が折れる。
とりあえずダウンロードして、ffmpeg で 1fps で連番画像へ変換。

mkdir tower; ffmpeg -i SECCON\ TOWER\ 2016\ -\ YouTube.mp4 -vf fps=1 tower/out%04d.png

これ、最近授業でやった気がするなーと思いつつググルも、一般的な手旗信号ではないようで少し戸惑っていたら、 @f_dita 先輩が最初のデモから対応表を作っていたようなので拝借。

そもそもパターン数が26+αあって、コマ数がトータルで3000を超えていたので人間技で分けるのは無理だと判断し、ImageMagick でごにょごにょするも、動画内の棒がブレるわ、次第に少しずつカメラがずれている? やらで全く精度が出ず、ここまで3-4時間近く。

最終的に心が折れ、手動分類アシストツールを書きやっていくこととなります。
そのようにして、160行のSinatraアプリケーションがここに爆誕しました。HTMLを文字列として扱って結合する簡単仕様。
そして去年のごとく、突然 @hogas を呼び出し、ひたすら朝まで単純作業。

それに伴い少しずつ分類器の機能が向上され、再分類(間違えた画像のやり直し)や大分類(軸となる棒の向き)→小分類 などの仕組みが整いスピードアップ。

これはSECCONではないと思いつつやるも、結局どのようにしてフラグを得たら良いのか分からず、更に混乱するなど。
問題文でPNGに戻せることが示唆されているので、何らかの方法で元に戻るはずですが、そもそも動画の冒頭で文字の対応が示されたのは20パターンほどに過ぎず、全部で何パターンあるのかも良く分からないままひたすら分類していきます。
最終的に32パターンになるのですが、途中で分類を誤ったりなんやかんやあった結果、36パターンの分類が完成し、Base36という誤った道を踏みそうに。答えは Base32 でした。

気合でバイナリに戻したら、馴染み深い IHDR の文字列が見えて感動しつつ、ここから更に間違えた分類画像100枚以上を探しつつ、気合でCRCを合わせて行きます。

最終的に、IHDR や PLTE, tRNS, pHYs, IEND 領域は CRC32 がマッチして、IDAT の inflate がチェックサムでコケるところまでは上手く戻せました。

input = "rfie3rynbinauaaaaagusscekiaaaaw5aaaafwqbamaaaabvebthaaaaaadfatcuiuaaaahzzzz5lwmz4uaaaaacorje3uzzzzellx1haaaaaclqjbmxgaaabmjaaaalcia2fxl1zqaaabwyjfcecvdyttw2uqms1i2ayrsrkvsqclbjlpxslmiavl5bus3zuqagz3xdt0oq15ci3kjuy0gjjknzzyjqobyha3dqobyha3dqobyhb3cpxdstrxdzt0zu1zzi5dwzc11jzvydx44gx2t0zfz3d4244rhdlcpir50u2mcaob1zrddyzj4bw11np1v02y5u1lcdrzjwouzjnzqobyb41geohcxsxdb3fdz3c0sejzsd2nbcye40jeapcdi3dt1g13gp2giw23z5jta0dfrt1ih55btxvmhxa3hqhzdpwdrl4whjsfrdqkzc2gljdeob0zdp1d55oe2uai1mnd4wxifhag344rpcm0rrbuha2pqr02i1dz2pd1bmbqobgzrhgrbqmzg00w12lpxgk1yn5c2obvnjwj4quha3pqjx2t2g1bmaq3rvpav5dmynuv2wlkuoppsrwidqodyl41hizwxhrl5lkz0ssvqdjwyzuvtev3k2dh05yha3d2zbdhljc1h4kj5ynk0100gw2xb5hz2jtuv2qobyg41gj2k3kl4jhftp2vfrr40fyme1l2vhc1dgzbpcnqgbyf41ewivxoh2pkn0qn5zpztpyllw33nzxoe2kqbhyda3cnzbepo3nylrfs0zjchnxcqyepu4krkupr1dqkbyh41evurfvlpar4ujdekpk34e1211lzzxacaob5zb5n5t0muzhmbs2urt2yr5524npkwukyot4z4xaiobyzbhtyzrj1okx5fv0g53voxfjfwqupsrj442n0ku0v4nyda3d2za4v0bvhnf5fpbv2lr3hvdndispkg5vi1byhatpyntgnwgusdvdnvh433x0rovk2r1lxzj0wi3dqohyi31nuunlupdqruvpo2gtp4lpzot4u2z053g3dqobg4qsfjvh1cz4jfy1kvg4u55givzw4acoobyzbdlyo21oo4wunlu5zmafr3tlqla0c0k4o5zwbihazpysw0wtz0feuyiyzznmxvk312gcpeyj4khmfy3dr1cwpvsvjt5mhl44404l4zuztj25ysxgf1vmmyldqohyl11yvxrlskky5fh02ncwlszjofoaffnleoiyha3d2zbzuvcoit5pxvqazyokxh1235ektpk3rd1tm4qibyh41cupelmkyzw40xl4t3omhlcvwmlwwq40zkf5klqodye4oekmt12pq5p2v3yh4dedtfui0pe5gu4fs1saeha2pqpc2u4gxeolww4j2lngsflw0xohl2byj1ayha4pymzf53hjbupoen5x4noc5beplaq4in2xb0ogq3dr1fz3o2ihvn0wxe34vlatswxkinpxmp5hxsomd55fqgbyf41g3kbgwk2ngbtfpupxwcndg3yzhkdaqdqpx3bmzgpntd4p0sfgwa441hppwmq2lsk2janbyhl3e1ptgpbdlnat2w21ukhm1kv4dpclpzp0p2vauob0zb4hsxvzi0gywexxzltim5ilmyvnrmwlk40hsly3q4xaadqpx3cvntfnn0ytnffkjc4x5trs44454sgucu4kx2m2byfa3d2zbshssd5wir0f13l14ln1xfcpe2w5j0d5rdnsda3dqjx3g3vdlk5xcjpcok1wypokpwgnlil4khjqkbyh41d5vruumwors0fu024zgkot100vjtrk34lx3ga3dv1cnlvhsmf1z5wutp0vkw2pwixvctl5j4iobypa4zrvkkch05giwwq4lmwqrf1ntwih21ly4fv1eiobyha4pylyyefx2tombpdl1lte5jlg3p0vilw5xmcla3dqnx3knm50tjlqnv12pwmz152ponnmafzs4iobyha4zrb4vtrlcxl20oqj54rxsuv5lrxcvdphm3dr1dgzqjp3otwo022qlrx0tlfiz3yfff4znfbyda3dp1eop2klbgoufqi2w3m5vqkyczlsjoagpxmuda3dqlx3dy020t0gde3vngk0d1u2vnkke1pnpf0a43kp3aha3dz1dwp2tvxklwknk55dlv2fbs135r0ix3pxbysdiob0zc44q1showz05sgn1moezliktgbku3lw55gmt3mo1ceobypaxlyx0mbl5ik1cl2oo4kdh40wwkxx5zoki1gbfyhb3fnxdmwqicfgdlzijcvkyvqz03h5yc31ev55ycxa3hqlx3n0qp5mxolk1nn4q1bwtkvmvtw22upeu5dqohys23m0lbxg04rx114zs3u31ehzki34jzihpotha3hpkbiha4pyu1xnmdt35ww31ht1f2epymzjf2x0phwwhamdqjx3ek1a54ufwoadzvikpo5iorjtplsm24eonyhb3dnzaef0m00jfmzvkatlu0xxdn0zpjueaaob5za4p23twus04k0ildq2nugd0dytpfsxgli22y1c33dr1cxpcgsax512lsmyq1h243s4kzmjmn3vtgayhazpyuj2yhgmv0nltaz01spccxf44kpn20mowlyodyh51h3kc2i43lddhvevviv1r4hqp5jkzkbtzvxqzlbi3dq1bg4yqr2gpw25vc4v3l4aan2xgx2zvxixhyobyg41eols0ong5koxbvretcf52ochl1nwbihazzqwpcif3ulfl3oixqvyulo5vky2ir45yag521jyha4pyplj3kmtoranly3wmn2mjoworm1wunnjcmx1adqobzzb4hvdqn3x5m1fzi3xnp4tm4y0ybhxfo5lfxyha3d2zbz15eaqobyha3dqobyha3dqobyhp3mz3apaujsxhmrfz0maaaaaacjivhejlscmcbaaaaaaaaaa"

s = "abcdefghijklmnopqrstuvwxy054321z"

x = [input.chars.map{|x| s.index(x) }.map{|x| ("00000" + x.to_s(2))[-5..-1] }.join].pack("B*")

# "\x89PNG\r\n\x1A\n\x00\x00\x00\rIHDR\x00\x00\x02\xDA\x00\x00\x02\xDA\x01\x03\x00\x00\x005 fp\x00\x00\x00\x06PLTE\x00\x00\x00\xFF\xFF\xFF\xA5\xD9\x9F\xDD\x00\x00\x00\x02tRNS\xFF\xFF\xC8\xB5\xDF\xC7\x00\x00\x00\tpHYs\x00\x00\v\x12\x00\x00\v\x12\x01\xD2\xDD~\xFC\x00\x00\x06\xD8IDATx\x9C\xED\xDAA\x92\xF2:\fFQUe\x01,)[\xEF%\xB1\x00\xAA\xF4\x1AK\x9F\xA4\x00o\xF2\xE3\x9E]\x0FhH\xE2\x93Ld\xC9J\x9B\xFF\xE10ppppppppppppp\xF0O\xB8\xE58\xDC\x7F\x9E\x7FO\x7F\xE8\xD0\xED\xF1{\xC9\xFDp;\xEFf\xBFg\x9F\x97\xFC\x1E\xFB\xBD\xC4\xE3X\x9E\x88\xEB4\xEB\x04\a\a\xDF\x88\xC7\x8F\xA7a\xB7\xBC\xD7\xFA\xB9\xEE5O,C\x8F\xD3gS\xE9o\xE0\xE0\xE0;\xF1\x88\xE3\x8A\xF2\xB8\xC3\xC2\x8F\xFC\x16dD\xFEC\xEBB,\x13yI\x00\xF1\r\x1C\x1C\xFCop\xCF\xE9\x91n\xF3\xFAL\xC1\x91\x963\xF2\x0F\xAD\x06w\xAB\x0Fpp\xF0?\xC6\xFB\x0E+\xDD\x8E\x99\x16#\x82\xBE.\x99i\x19\x1C\x1C\xFCo\xF0\xF5\xA7\x13\xB4\x02<\xC6\x8Fv\xBA\np\e\x9B\xDC^&f1\r\x0E\x0E\xBE\x11\xCFQ\xE1\xFF\xAF\x1F\x82\xC0\xC1\xC17\xE2sD0g\xCD\x9C\xDB\xDD[\xEEe{\r\xD0\xBA\xE0\xD5\xA9\xB2w\n\x1C\x1C|\x13~\xCF\xA6\xF0X\br5x+\xA1\xB3\r\xA5{e\xAA\x8E{\xE5\e pp\xF0\xBD\xF8\xE8\xFD\xAEx\xAFKW\xF3)V\x03M\xB1\xFAVd\xAF\x15\xD1\x9F:\xC1\xC1\xC1\xF7\xE1\x19\xD6\x91x\xFBRu\x86\xAB>\xCEMn\xDC:?\xFA\x99\xD2\xBD\x83\x83\x83o\xC6OU\xC5/i9f\xFE\xD4\xB1\x8E\xF2\\0\x9E_jqxf\xF8^&\xC0\xC1\xC1w\xE2Y\x15\xBB\x8F\xD7\xA9\xB9\x83u\xF7\xFEo\xC2\xD7nq\xBF\xBB\x89\xD5@'\xC0\xC1\xC17\xE1#\xDD\xC6\xE1q,\xB3\xF4\x88\xED\xB8\xA1\x82>\x9BTUG\xC7\xC3\x82\x83\x83\xEF\xC4\xAD\"Z\xAD\xE0\x8E\xE8\x91\x91OW6Ow\xDE_\xFFp\b\x0E\x0E\xBE\x1D7S\xCB)\xF3\xB02\xED#>\xE2:\xD7v\xD7\xAA\xD4V\x1D=\xFFw\x02\x1C\x1C|'\x9E?\x14\xF9\xCA\xBE\x8B\\\x9B\\\xAB\xAET\x96\xD0\xA3\xE5\x14\xEF}nUL\xD7m\xC0\xC1\xC1\xF7\xE0\xDDr\x1A\x9D\xA5\xD1^\x1A\xF5q\xE1\xEA6\x8D\x12z\x8D\xAA\xA3\xC1\xC1\xC17\xE1\xB33ljHu\ej}\xF3\x97\xCC]Uv>]\xFE\x9C\xD9\x1C\x1C\x1C|#\x9Em(\xD5\xD1\xE3\x84iW\xBB\xA6\x9B\xF6\xB7\xFD\xD3\xDD;\xFC\xEB\x86\xE0\xE0\xE0\x9Bp\x91SS\xF8_\xDAK\x8F*\xA6\xDD5\xA3\"\xBF\xB6\xC0'88\xF8F\xBC;\xBEs\xB7j5t\xD7\xD8\x02\xC7\x93\\\x16\f\x8B*\xDB\xB5\xFB\x05\a\a\xDF\x89[6\x9F\xF2RS\b\xC7\xFE\xD6^\xAA\xE7\xBAa<\x98N\xD4v\x17\x1C\x1C|+>\xB2\xAAg\xA6\x1D{\xDE\xF3\xB5\xEF\xF4\xFC\xD3\xDDbW1}V3\v\x1C\x1C|/\xDE\xC5o\x15\xC9J\xC6\x8A|\xF5\xA2\xB2\xE5\xF4\xB8\xAE\x01J\xD5\x91\xC8\xC1\xC1\xC1\xF7\xE1\xFD*'\"z}\xEB\x00\x7F\x0EU\xCF\xEE\xF3DT\xDE\xAED~\x9B7\x04\a\a\xDF\x85G\x91lV?m\xE6\xEB\xDC\xF8\xE6\x1Db\xAD\x98\xBBZ\e\xCF\xD4])pp\xF0M\xB8\x8Ad\xFD\xD7\xC3O\xEDy\x83\xECd\x1C\xCBDe\xE4\xD1\xA9\xB2\xCB\xD2\x01\x0E\x0E\xBE\x0F\x17i\xB3\\\x8E]\xAD\xB4\xF5m4\x8A\xBBf\xEE:\xFA\x1C'\xC0\xC1\xC1\xB7\xE1\x9F.\xB8t\x86\x8Fq\e\xAB\xED\xAE\x16\x82G\xAC\x10\xDA\e\xDB\x87.488\xF8\xBF\xE3\xBA\x83\xD5\xB9\xB5\xC9\xCD\xD5`\x9C\xADu!\xAF\xBB\x1F\xA3\xDEN`\xF5\xA2\xC0\xC1\xC1w\xE3qA5\x95\xD6\x983+\xE8\xFB\xD8M\x19\xB9\x8F\x9DC\x04\a\a\xDF\x81g\xCC\xF6\xCC{~dSX\e\xDF\x8E\xF7\xD9\x90\xEA\xE4\xAE\xA4\r\x0E\x0E\xBE\x13\xCF\x99\x9E\x11\xAD\xA0\x9Fm\xDFQGg\x95]\x8D\xE2[\xFE\xFC\xBF\xB5\x05\x1C\x1C\xFC;<\xAF_\xA3&\xC5\x89{\xFDsC4\x85\xB3\x15lYe\xABy<\x97\x8ECw\x00\a\a\xDF\x82\xABfV\xB78\x9BJU$[\xBE\xA7\x19o{\xD6\xE4j\n\x9BU\xFA\xCE\x87\x05\a\a\xDF\x86G\x94\x87\xAB\"9/\xB8\xBFmm\xF5\xCA'\x93\xB6\xD2r=Dm\x90\xC1\xC1\xC17\xE1\xB9Q\xADZ\xB8\x92\xF19^\xB6\x1E\xE5>\xC6j\xD0\xBD\xA8\xE9\x82\x83\x83\xEF\xC3\xD5cJ2\xCE\x8C\xB2Zg\xBB\xF9\x94\xE9\xFB9\xAAg\x15sk\xBF\f\x0E\x0E\xBE\x13WS\xC9\x85\xF7\xF5jM\xF9\xAA\xAD\xD7\xD9\x17\xA8\xA6\xBD'hpp\xF0o\xF1\xAA\x94#\xE7FE\xAD\r\xAD\x96\x84K\xE6\xCE\xC8?|\xBCl\xB5\xF1\x10\xE0\xE0\xE0\xDB\xF0\xBC`\x85\xBFf\xE6\x05\xE3_\x972i+7\x1F\x9A\xA1v\xD5\xD8%\x83\x83\x83o\xC55\x9A\xCC\xD2\xB86\xBE\xEB\xEC\xCF\xFB]{\x9A\xD6\x00\xBF\x96\xD0\xE0\xE0\xE0\xDF\xE2\x1D\xD6qX\xAE\xBE\xE5\xD0N\xB7\e\xCA\x95\xD2\xE3qTo;88\xF8f\xFC\x12\xFE:vv{\xD8.7\xCC\xD6T\x7F\x98)K\xBF\xB4\xA1\xC0\xC1\xC1\xBF\xC4s\xFA\xA5\x84\xCE\xA1`\x8E\xDB\x8C\xD5`\xAC\v\xEB\x92\\\x03>\xEC\xA0\xC1\xC1\xC1w\xE0\xF1\x9E\xE6y0\xC9\xCA\xB4\xCA\xC8\xFDN\xD5\xAAQ<\xF6\xBC\xB9\x06\xF8\xA7\xF0\a\a\a\xFF\x0E\xCF\xEC\xEBu.\xCAj\xB5\xA1\xAE\xBD(e\xEEj9E\xF8\xFB\x87\x12\x1A\x1C\x1C\xFC[\xDC=#\xBA\xDF\xCE\xA4f\xF9\x8E'\xD6\x85L\xC1U8\xBBkFd\xF8\xC7xDpp\xF0]x\xBEX\x15\xE9\n\xF0\x97\xD7;j\x19\xF7\x9BYW\xBE\xBE\xE5#\xC6\tpp\xF0\xAD\xB8\xD9h E0\xD7\xF4$UV+\x0F\xE7\x87\xD6\x05\xCF\x12\xBA\xD6\x05pp\xF0]\xF8\xDC\xC1\xFAe\xDC\xB5y\xAD\xDC<\eMUegn\xF6\x8F%488\xF8\x97x\xCC\xAC76w\e\xFB\xDB\xFC\xB9Nx\x87\xFA\x91\xCD\xA7\xE8;\xDD3\x83\x87z\x82\x83\x83o\xC5=v\xB0s\xE6\xADnx\xF3\xF1zG\xE1\x9FI{|\xBC\xF6\xB1\xC0\xC1\xC17\xE1\x15\xE0kt-\x9C\x01\xFE\xA8S\xDD\xA4:)\x9B\xD7&wdspp\xF0m\xF8\b\\\xB39IY\xFA\xA8\x13]3{\x8D\xB9\xFB\xD3B\x00\x0E\x0E\xBE\r\xBF\xBC\x9D\xA9,\xEDYB\xC7\x0E\xB6\x86\x1EG\x89\xBC\xB2\xB9\x96\x8E\xF7\x1E\x1788\xF8Wx\x8D _^\xEA\xE4\xCCC\xC7\xEE\xF9-\xAB\xECK\e\xCA\xCC\xC0\xC1\xC1\xF7\xE2\x89\xEE\x0EfW-\\\xC1\xFC\xFAO\x10\xAE]\xEDOor\xC7Yxp\xF0}x\xFCP\xBA\x8D\xF1c\x19\xEAJ\xD5\x15\xF4vx?IW\xD4\x19\xFE\xB7\x87\xD6\x14pp\xF0M\xBCB=3\xED\xDDT[\xAF\x17\xB0\x01\xBD\xB9\xAF\xDF\xD6\xE8\xB9\xF0\xE0\xE0\xDB\xF1\x1C\xB9e\xCD6\x94\xEB\x86\xB1$\xC4]u\xC2:\xFC\xDB\x05\a\a\xFF\v<H/(\xB2\xAF\x8EE\xE1\\Qn\xD5U\x8E\xA2;\xD6\x00mw\xC9\xC1\xC1\xB7\xE1\xEBO\x14\xC9\xBA j\xF1\xCB1\xBDb]gE\x9E\xB5\x1A\xD4\x89\x97\xF0\a\a\a\xFF\x0E\xCFQ\xC1\xBC\xBE\x99\xE2\xFD\x1C\xBB_\xB9\xB3x\xCE\x02{\x95\xDAYo\x83\x83\x83\xEF\xC3\xFFh\x80\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\xBF\x8C\xFF\x00\xF0Q2\xB9\xD9\x12\xFF,\x00\x00\x00\x00IEND\xAEB`\x82\x00\x00\x00\x00\x00\x00\x00"

圧縮の展開に失敗するため、普通の Preview.app などでは見ることができませんでしたが、とりあえず Chrome に投げたらある程度の断片が拾えて、QRコードだったので、なるほど〜といいつつ画像をチームチャットに投げたところ誰かのアプリが良い感じに読んでくれました。

SECCON{SEMAPHORE_LINE_IS_THE_1ST_TELEGRAPH_SYSTEM_IN_THE_WORLD}

7番目ぐらいに解けた気がします。これ、多分うまくやると自動分類できるんですが、それでもそこそこしんどい気がしますね。結局PNGは最後まで戻せるのかどうか……

普段 Web 系の人間なはずなのに全く分からなくてしんどいし困りますね。でもバイナリにも強くなりたいですね。やっていきましょう。

2018年新卒ではないですが、 2016/9/6 〜 2016/9/26 まで、2018年新卒向けの CyberAgent の夏季長期インターンであるところの WORKインターン (インフラ) に参加して、アドテク本部というところでなんやかんやしていました。

2018年新卒向けとはいっても、特に制約があるわけでもなく普通に応募できます。まあ、インターンに行くのは普通は学部3年 or 院生なので、必然的にそうなるんでしょうか。

ICTSC 関連の知り合いの方に誘われて、大規模なインフラに触れてみたいという気持ちもあり応募したことから始まったインターンでしたが、今までに無い濃密な日々でした。

まず、面接が2回ある。これは本当に驚きで、まず人事面接があって、その後に部門面接がありました。
ただの職業体験的なインターンだと思っていたそれまでの観念が書き換えられて、1ヶ月間共に仕事をする人という扱いをされているんだなあという気持ちになりました。

人事面接の後、人事の方から「kyontan君のやってみたいことからすると、ここ(アドテク本部)のインフラとかどうかな〜」といったサジェストを頂き、インフラができればどこでも! ということでレスポンスをしたところ、そこの方と部門面接をすることになりました。
CyberAgent のインターンは内部的には100箇所以上の配属先があるらしくて、それぞれの学生に一番マッチするところへ、ということでマッチングにとても気を遣われている印象がありました。

部門面接で興味のある技術やなんやかんやという話をしていましたが、やはりそこでも印象的だったのは、「もしやりたいことが変わったり気が変わったらいつでも連絡してね!」と言われたことでした。なるほどなるほど……

そんなこんなでインターンでは、OpenStack Mitaka と Midonet という SDN のプロダクトの運用検証や、ストレージ(SAN)の性能検証みたいなことをしていました。
「とにかく今までやったことがないことがやりたくて、やりたい、SDNとか興味あります!」みたいな意味合いのとにかく具体性のないことをメンターの方に伝えたのですが、実際にそんな感じになってとにかく感動しました。
ICTSC6 では CloudStack を使用していて、ICTSC5 では OpenStack を使っていた、みたいなことはあったのですが、自分で構築したことは一度もなかったし、この機会に1からやってみるのも良いな、というのもありました。
ついでにプロビジョニングも1からやってみたいという感じで、Ruby で書ける Itamae を使って、OpenStack Mitaka と Midonet を一発構築するレシピを書いた。

kyontan/itamae-recipe-openstack-with-midonet: Itamae recipe for installing Openstack Mitaka + Midonet

ちょっと最近私用で使ってみたら壊れてたので直します、ゆるしてください。

Midonet 、セールスポイントとしては ovs のカーネルモジュールを使っていて信頼性があって SPOF のない SDN オーバレイネットワークを構築できて OpenStack Neutron と密接に連携してくれるというところなんだけれど、結構イケてるプロダクトだと思う。
アーキテクチャの筋はめっちゃ良いと思っていて、おもしろプロダクトなので、これからも詳しく見ていきたい気持ちがあります。

で、主にそのあたりの検証をしたりした。

ストレージの検証は難しくてあまり成果が出せなかったのでしんどいという気持ち。

実質15日しかなくて、その中でいかにして結果を出すかみたいなことをメンターの方とも相談して方向性を決めたりした。
結果として、15日で目に見える成果物も出せて、濃密な感じにできたのは良かったと思っています。

最終的にできたのは以下のようなもの。(公開の許可は頂いています / 検証環境です)

Midonet はトラフィックを可視化する機能が Enterprise (有償) にしかなくて、標準だと CLI で謎UUIDと紐付けられた値が取得できるだけなのだけれど、それを色々してちゃんとVMやらホスト間のトラフィックを可視化して Zabbix で表示するようにした。
これは結構イケていると思っていて、実際動くのでイケています。よかったですね。
技術系のネタはまた別の記事で書きたい気持ちもあるので端的にこんな感じで。

とにかくインターンを通して、メンターの方や社員の方々には良くしてもらって、気にかけて頂いていた気持ちが強い。本当に一言で表せないぐらいなのですが、お世話になりました、ありがとうございました。
配属された組織がとにかく強い人の集まりで、僕のふわっとした要領を得ない質問に対して簡潔で的確で正確な応えが返ってくるのは学びになりました。

他にも、インターン同士の交流会があってどこぞの大会でお会いした人に再会したり、インターネットの有名人(と個人的に認識している人)にお会いしたり、社内の施設も社員と同様に使えたりして感動した。(使う機会がなかったのが残念)
社内のリラクゼーションスペースがちょうど工事中で、インターン期間に行けなかったのが悔やまれる。

他にも、椅子がエンボディチェアで、これがハーマンミラーか……! と感動したり、無限に甘ったるいドリンクが出てくるベンディングマシン(普通のコーヒーやコーラももちろん出てくる) があって、無限にアイスチョコバナナとかいう不健康飲料を摂取したりしていた。アイスチョコバナナは最高。

(2016/10/25 22:12 補足: 記事の公開時にアーロンチェアと表記していましたが、エンボディチェアだという指摘を頂きました。調べてみたら最上位……なるほど……)

他のインターンの方の話を聞いていると、やはり配属される部署でこの辺りは結構差があって、営業と同一フロアでノイジーな環境だったりすることもあるみたいですが、とにかくありとあらゆる手法で解決することが可能なのでやっていきましょう。
ちなみに僕の環境はオールエンジニアのフロアで静かでした。キラキラしてる印象はそんなになかったです。(他のフロアに行ったらキラキラしてたので驚いた)

そんなこんなであっという間に過ぎた3週間でした。改めて、アドテク本部のとある組織の皆様、メンターの方、人事の方、ありがとうございました!!!

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

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

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

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

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

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

既に年も明け、とても遅くなってしまいましたが、先日の 2015/12/19, 20 と2日連続で高専カンファレンスに行ってきました。

http://kosenconf.jp/?100tokyo

何故かタイムテーブルに僕の名前が乗ってます。
はい、LTしました。工業高校卒の僕が、高専カンファで。何故か。

5分の発表時間に対し、150枚のスライドを用意していたので、都合2枚/秒のペースで話す必要があったのですが無理でした。そりゃそうだ。
それどころか、しどろもどろになってしまって内容の1割もまともに喋れなかったので、あの場を用意してくださった方々に申し訳ないという気持ちでいっぱいです……

そもそもどうして高専卒でない僕が高専カンファで話すことになったのか? ということですね。

物事の発端は Dentoo.LT #11 で とある方 が高専カンファの宣伝LT をしていたことに依ります。
その とある方 こそが 100カンファの運営委員長の なっちゃんさん な訳ですが。
その後も、すれ違えば LT出てよ! と背中を押され、気が付いたら申し込んでいて通っていて…… みたいな感じでした。

そんな広告戦略については、なっちゃんさん の100カンファ後のブログ記事を見て納得するなど。

http://marin72.hatenablog.com/entry/2015/12/23/202842

僕は私用により1日目の夢これ、アイスブレーク等に参加できず (とても悔しい!!) 、懇親会の途中からの参加となったのですが、会場について驚いたのが、高専生ってこんなにたくさんいるんだ!! ということ。
身の回りに高専に行った人もいなく (神奈川県には高専がない) 、高専生ってどのくらいいるんだろうなあという実感もないままに参加したイベントだったがために、余計に感動しました。
しかも、会場が東京だというのに、北海道から沖縄まで、全国津津浦浦からの参加者がいるのには本当に驚くばかり。

発表者といい参加者といい、自分より若い方もいれば、卒業生の方もいてなんだなんだこの巡るめく高専ワールドは…… とただひたすらに。

特に感動したのは、でなりさん (@denari01) 率いるデザインチームの力でした。
会場の案内から、チラシから名札からなんやら、果てはスライドのテンプレートまで、一貫したデザインがあるということはここまで強いことなのだなと実感せざるを得ない場所でした。
デザインは趣味程度にかじる人間でしかないですが、ここまで一貫したブランドイメージを感じる機会というのはなかなか記憶にないところで、最初から最後まで感動が止まらず。あと、でなりさん本当にイケメンだったのでイケメンしか言えなくてとても残念だった。ぐぬぬ

会場ではたくさんの人と話しましたが、本当にいろんな人がいて、高専というのは不思議な場所であるなあと。
こんな(いい意味で)変な人がたくさんいる場所は高校以来だったので、不思議な感覚でした。あの工業高校にも変な人がたくさんいた……

LTについては精進しますとしか言えない……!

参加者、運営の皆様、本当にありがとうございました! 最高のイベントでした!!