退職エントリです(この文言を書いてみたかっただけ)．7ヶ月くらい長期インターンシップとしてお世話になった株式会社Moffを退職しました．
先に書いておくと，辞めた理由は，研究活動が本格的に忙しくなりそうというのと，任されていたタスクがある程度区切りが見えたからです．負の感情で退職したわけではないので，勘違いしないでよね[^1]．
問題のある事を書いていたら速攻で消すので連絡ください
今回の記事ではどれだけお世話になって，この半年でどれだけ強くなれたかを
の二本立てで書いていこうと思います．長いです．長いので以下の目次で興味のあるトピックを読むことを推奨します．当然ちぎちゃんのファンの方は全部読むと良いです(?)
ISUCON8予選に@k5342と @euglena1215 とでて惨敗しました．さようなら．
ふたりの記事は(特にk5342のほうには)詳細に書いてあるので，そちらを参考にするとムーブがよくわかります．ありがとうk5342メンバー！
なんか二人がいろいろ書いているので私はポエムを書こうと思います．
nginxとは，紛れもなくweb サーバであるが，単にエンドポイント振り分け係としての機能に加えて，同時にロードバランシングができたり，sessionを保存しているノードに振分けることができたりとそれなりに有能なのである．似たような機能を持つものとして，Apacheやh2oがある．これらのチューニングのうち，Apacheのみは経験したことはあったが，h2oはデフォルトではやい*1 らしくまともにチューニングしたことはなかった．なにより，デフォルトのh2oはデフォルトのnginxよりは当然性能はいいが，高度にチューニングされたnginxはh2oと同等もしくはそれ以上の性能を引き出せると未だに考えている．
ところで，今回のISUCONの初期実装ではh2oであった．/etc/nginx がないというのはかなりの衝撃であった．が，未だにh2oであったその真意はわかっていない．それでも上記の理由に加えて，不慣れなものはとっとと切り出すほうがそこに時間を食わなくて済むという経験に基づいて開始早々引き剥がす決断をした．
nginxの最適化というのはアプリケーションの実装によってどのパラメータを変更するのか，様々な使用率状況を把握しながらある程度は自動的に，それ以降は職人の勘で行っている．無闇矢鱈に様々なパラメータを on にすることは避けたほうがいいというのがここ数年 nginx調整係*2としての勘である．
それを踏まえて今回のISUCONを振り返ってみるとあまりにも勘に頼りすぎた可能性がある．例えば，今回の問題のアプリケーションやDBのCPU使用率はそれなりに高く，またそれ以上にメモリの使用率が半端なかったので，gzip周りで最適化することはこれ以上にサーバーに負荷を掛けてしまう恐れがあるため今回は見送った．また，最低限静的ファイルのキャッシュは終わらせたがそれ以上のチューニングは難しいと判断して早々に放置してしまった．いま考えるともっとチューニングバトルをしても良かったかなと思う．ということが複数個あって，「やらないで後悔するくらいならやって後悔したかった」という感じだ．去年のような画像がそれなりにある問題でCache-Control をつけると脳汁がドパとでるほどにスコアが跳ね上がる傾向にあるが，今回みたいなタイプはどうしてもスコアが上がりにくいし，しんどすぎという感じだった．
一方で，早々に切り上げる判断ができたのは良かったと思える面もある．それは明らかにnginxよりもmysqlの設定を更新したほうがスコアが上昇する状況だったので，小手先のスコアを伸ばすくらいならアプリケーションが大量のN+1問題やN*(N+1)問題(多重にN+1問題を起こしている)のようなDBへの負荷を爆上がりさせてくれるような問題を抱えていたのでnginxに時間割かなくてよかったとも言える．
mysqlのチューニングとなるとinnodb_buffer_pool_sizeをいじるだけでしょ（笑）みたいなことを言われるが(言われたことはない)，それ以外にもデフォルトだとそれなりに低く設定されているため改変するべきものは多くある．
しかし，今回の問題では上で書いたとおり，DBのCPU負荷，メモリ負荷が尋常ではない状況でメモリキャッシュさせるのはどう考えても悪手であるという感じだったので，max_connections を増やす程度の設定しかできなかった．
ただ，複数台構成が実現できそうになるとDB単体で一つのサーバが与えられ，それなりにメモリに余裕ができてきたのでそのような設定を入れることができたのは良かったと思う．
ここまで書いていて，今回のISUCONは昨年のISUCON本選同様に，最適設定ゲーではないというのがわかる．つまりアプリケーションをなんとかしないと話にならない．という話だ．
例のget_eventsクエリ潰し大会で三人でペアプロしたのが良かったのか悪かったのか問題はメンバーの間でも様々であるが，結果的には成功だったけど明らかに時間を掛けすぎた．あれに関してはてっぺーさんを信じるのと，値を見間違わないようにしないといけないという感じ．うーん．悲しい．
これは重い．おもすぎて60秒以内にレスポンスが入ればみたいなレギュレーション *3 である時点で明らかにやばいオーラを放っている．こいつがそれなりに重いためメモリ食ってんじゃないかという話になり私が担当した．sqlが3つのテーブルをinner joinするような形を取っていて，ほぼすべてのスキーマを参照してそれを一度ハッシュにぶち込んで，それをソートして渡して文字列を生成してcsvにするという形を取っていた．
この問題に当たる頃にはとにかくアプリケーションのCPU使用率とメモリ使用率を下げろ！という指示だった．
まず問題としてありえん巨大なsqlを改善したいとなったが，これをチューニングするのは死ぬほどつらそうと思った．次にわざわざメモリに展開してからソートするのは馬鹿らしいのでsqlでORDER BYすればいいと思った．よく確認するとsqlですでにソートされているのに再度ソートを掛けていて :thinking_face: となったのでその処理を外した．また，わざわざハッシュにする意味もないので直接文字列生成してそれをrender するみたいな方針にした．
この効果は不明だが微妙にスワップが減ったが微々たるもの(k5342談)だったので，うーん辛い．
多分，負の貢献をしてしまったのでつらい．お茶くみすればよかった．なによりRubyチームにのみ多く見られた例の問題は言語的な辛さなのかなぁと他のチームの話を聞く感じ思った．また，salesのところだけエンドポイントを切って別サーバに任せるという技がまじですごいなと感心した．すごい．
これでは顔採用は厳しいです．
WantedlyオフィスでISUCONに参加させていただきました．まじでありがとうございました．ディスプレイ借りれたり，ホワイトボードを借りれたり，テレビ借りれたり，椅子(いいやつ)を借りれたり，助かりました．あとオフィスが綺麗でした．
また，去年と同じメンバーで今年も参戦することができて非常によかったです．かなりバランスの取れたチームであったので本当に本選に駒を進めたかったです．来年も @euglena1215が電撃で留年か大学院に進学することで学生枠で出たいです(冗談です)
こんばんは．chigichan24です！先日 git challengeというものに参加したのでそのレポートをします！！！
この記事を斜め読みすると下のような文言が出てきました．
gitリポジトリに設けた難題をチームワークで解決していく競技型技術イベント
なるほど．個人的には，
Gitを使っていた時にやらかし太郎してしまった．けど，あなたならどうする？？？をコンテスト化したもの
というイメージです．
このイベントをやっているのはmixiさんだけ！ mixiさん大好き♥♥
お話させていただいて，大変光栄です． https://t.co/ulu7gCMmha
— プリキュア (@chigichan24) September 8, 2018
各チーム着実に解答が進んでいるようです。解答をリセットしてくれる「リセットセンター」には今回4つの異なる音の出るボタンをご用意しております。まだあまりリセットの依頼をされるチームは少ないようです。 #mixi_git pic.twitter.com/TDgdHwKtzM
— ミクシィグループ 新卒採用公式アカウント (@HR_mixi) September 8, 2018
コンテンツ力高めおもしろムーブ部門優勝じゃないですか？ #mixi_git
— プリキュア (@chigichan24) September 8, 2018
参加者の皆さん！運営の皆さん！誘ってくれた人事の方！皆さんありがとうございました🤩🤩 めちゃくちゃ楽しい競技でした💪💪💪 git力もっと上げます✍️✍️ #mixi_git
— プリキュア (@chigichan24) September 8, 2018
インターネット有名人の @raryosu に煽られたので、この先インターネットできないわ
— プリキュア (@chigichan24) September 8, 2018
