Re: ICFP Prorgamming Contest のチーム戦テクニック集
「ICFP Prorgamming Contest のチーム戦テクニック集」を読んで、大半の内容はなるほど確かになぁという感じだったんだけど（それはそう）、一箇所この部分
大量に同時実行したAIの出力を POST リクエストでポータルサイトに投げるような設計をした場合はその負荷にも注意が必要です。ポータルサイトがボトルネックになって計算結果が失われるという悲しいながらも割と起こる事故があります。ISUCONするはめにならないよう。*4
*4:個人的にはこういう設計がそもそもダメなんじゃないかという気もします。json にメタデータを書くしょぼエンジニアリング最強なのでは？？
この主張には一理あり、ICFPCをやっているとそもそもの問題サイズが大きかったり、中間結果もビジュアライズのために取っておきたくなったり等の理由により、プログラムの出力が数MBから数十MBに膨れ上がることが稀によくあります。そういうとき、序盤で雑に書かれたFlask製サーバなんかがスケーリングされずにアップロードを待ち受けていたりすると一瞬で死んでしまうため、そんな辛い思いをするくらいなら最初からrsyncとファイルI/Oで頑張ればいいじゃんと考えるのは自然な発想ではあります。
しかしJSONメタデータ戦法は検索性が致命的に悪い。例を挙げると、何かしらの検索をしたければ、全てのデータを舐めながらマッチするデータだけ拾ってくる必要があるため自明に遅いという点が1つ。また、検索したい軸が1つしかないという状況もまずあり得ず、こういうカスタムクエリが欲しいという要望が無限に飛んできて、似たような検索ロジックをコピペで量産した挙句に全部バグって死ぬことになります（断言）。
……みたいなことを考えて、実際2016年はこの方針だったけど途中でスケールしなくなってMySQL建てたと記憶してるので、まあどうせみんなMySQL書けるし、大人なんだから自分の好きな言語でMySQLに繋ぐ方法くらい分かるでしょ（大嘘）という感じで思考停止でMySQL使う→MySQLの認証情報を配るのめんどいし、Webサーバを建てといてアップロードした解答を勝手にインデックスすると楽だよね、という感じで上記の記事に書いてあるようなシステムが出来上がったんだったと思います。そしていつの間にかISUCONが同時開催されます。勝手にコンテストの問題が増えるなんてお得ですね。
で、まあこうやって読んでるとなんとなく分かると思うんですが、上の理屈には飛躍があります。ICFPCのポータルサイトはデータ解析基盤なので厳しいリアルタイム性が要求されることはほぼなく、新しい結果が届いてから反映されるまで2、3分のラグがあってもまあええやろという雰囲気であることがほとんどです。ということは、アップロードを司る何かがインデックスを作る必要は特になく、各人が勝手にファイルをrsyncで所定の場所に置くようにして、それを適当なcronがMySQLなりElasticSearchなりに順次突っ込んでいけば良いのでは？
ということを思いついたので記事を書きました。誰か試してみてください。
