chigichan24のお気持ち表明

おきもちを表明している

退職しました😭😭😭

退職エントリです(この文言を書いてみたかっただけ)．7ヶ月くらい長期インターンシップとしてお世話になった株式会社Moffを退職しました．

先に書いておくと，辞めた理由は，研究活動が本格的に忙しくなりそうというのと，任されていたタスクがある程度区切りが見えたからです．負の感情で退職したわけではないので，勘違いしないでよね[^1]．

今回の記事ではどれだけお世話になって，この半年でどれだけ強くなれたかを

  • 技術的側面
  • 技術以外でいろいろ感じたこと

の二本立てで書いていこうと思います．長いです．長いので以下の目次で興味のあるトピックを読むことを推奨します．当然ちぎちゃんのファンの方は全部読むと良いです(?)

  • 馴れ初め
  • 技術的にやったこと
    • やったこと概要
    • 技術要素
    • SDK改良
    • データ蓄積・分析基盤構築
    • IoT機器接続基盤の設計・実験的実装
  • 技術以外に感じたこと
    • メンター編
    • 会社の雰囲気編
  • 今後
続きを読む

ISUCON8予選で負けました

ISUCON8予選に@k5342と @euglena1215 とでて惨敗しました．さようなら．

ふたりの記事は(特にk5342のほうには)詳細に書いてあるので，そちらを参考にするとムーブがよくわかります．ありがとうk5342メンバー！

k5342.hatenablog.com

euglena1215.hatenablog.jp

なんか二人がいろいろ書いているので私はポエムを書こうと思います．

ポエム

nginx 最適化設定編

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最適設定編

mysqlのチューニングとなるとinnodb_buffer_pool_sizeをいじるだけでしょ（笑）みたいなことを言われるが(言われたことはない)，それ以外にもデフォルトだとそれなりに低く設定されているため改変するべきものは多くある．

しかし，今回の問題では上で書いたとおり，DBのCPU負荷，メモリ負荷が尋常ではない状況でメモリキャッシュさせるのはどう考えても悪手であるという感じだったので，max_connections を増やす程度の設定しかできなかった． ただ，複数台構成が実現できそうになるとDB単体で一つのサーバが与えられ，それなりにメモリに余裕ができてきたのでそのような設定を入れることができたのは良かったと思う．

ここまで書いていて

ここまで書いていて，今回のISUCONは昨年のISUCON本選同様に，最適設定ゲーではないというのがわかる．つまりアプリケーションをなんとかしないと話にならない．という話だ．

ペアプロ編

例のget_eventsクエリ潰し大会で三人でペアプロしたのが良かったのか悪かったのか問題はメンバーの間でも様々であるが，結果的には成功だったけど明らかに時間を掛けすぎた．あれに関してはてっぺーさんを信じるのと，値を見間違わないようにしないといけないという感じ．うーん．悲しい．

report_for_sales重い問題編

これは重い．おもすぎて60秒以内にレスポンスが入ればみたいなレギュレーション *3 である時点で明らかにやばいオーラを放っている．こいつがそれなりに重いためメモリ食ってんじゃないかという話になり私が担当した．sqlが3つのテーブルをinner joinするような形を取っていて，ほぼすべてのスキーマを参照してそれを一度ハッシュにぶち込んで，それをソートして渡して文字列を生成してcsvにするという形を取っていた．

この問題に当たる頃にはとにかくアプリケーションのCPU使用率とメモリ使用率を下げろ！という指示だった．

まず問題としてありえん巨大なsqlを改善したいとなったが，これをチューニングするのは死ぬほどつらそうと思った．次にわざわざメモリに展開してからソートするのは馬鹿らしいのでsqlでORDER BYすればいいと思った．よく確認するとsqlですでにソートされているのに再度ソートを掛けていて :thinking_face: となったのでその処理を外した．また，わざわざハッシュにする意味もないので直接文字列生成してそれをrender するみたいな方針にした．

この効果は不明だが微妙にスワップが減ったが微々たるもの(k5342談)だったので，うーん辛い．

総括

多分，負の貢献をしてしまったのでつらい．お茶くみすればよかった．なによりRubyチームにのみ多く見られた例の問題は言語的な辛さなのかなぁと他のチームの話を聞く感じ思った．また，salesのところだけエンドポイントを切って別サーバに任せるという技がまじですごいなと感心した．すごい．

最終スコア

これでは顔採用は厳しいです． f:id:chigichan24:20180917153420p:plain

リポジトリ

github.com

謝辞

WantedlyオフィスでISUCONに参加させていただきました．まじでありがとうございました．ディスプレイ借りれたり，ホワイトボードを借りれたり，テレビ借りれたり，椅子(いいやつ)を借りれたり，助かりました．あとオフィスが綺麗でした．

また，去年と同じメンバーで今年も参戦することができて非常によかったです．かなりバランスの取れたチームであったので本当に本選に駒を進めたかったです．来年も @euglena1215が電撃で留年か大学院に進学することで学生枠で出たいです(冗談です)

*1:https://w3techs.com/technologies/comparison/ws-h20,ws-nginx

*2:他にできる仕事がなくてこれしか任せられない

*3:https://gist.github.com/rkmathi/1d08e17671d3952e8d2e873e686b7ea6#%E5%88%B6%E7%B4%84%E4%BA%8B%E9%A0%85

git challengeに参加しました！

こんばんは．chigichan24です！先日 git challengeというものに参加したのでそのレポートをします！！！

Git Challengeとは？

現代っ子なのでNAVERまとめを参照します．

matome.naver.jp

この記事を斜め読みすると下のような文言が出てきました．

gitリポジトリに設けた難題をチームワークで解決していく競技型技術イベント

なるほど．個人的には，

Gitを使っていた時にやらかし太郎してしまった．けど，あなたならどうする？？？をコンテスト化したもの

というイメージです．

このイベントをやっているのはmixiさんだけ！ mixiさん大好き♥♥

参加する前に

  • このイベントは一度しか出ることができない！ということもあり，数年前から出たかったが†Git力†に自信がなかったので躊躇してた．
  • が，いつ学生という身分から迫害されるかわからなかったので(?)出ることにした．
  • 参加する前には，応募要項として，過去の開発経験とか，あなたのGitエピソードみたいなのを書いて応募すると，抽選された．
    • これはオフレコなのですが，熱い想いを書き殴っていたら文字上限を超えてしまいそれに気が付かず提出ボタンをおしたら書いた内容が消えて，1度萎えたという事件がありました．
    • なので，皆さんは一度どこかにファイルとして保存しておいてそれをコピペするのをおすすめします．
  • 抽選に見事に当たり，参加が確定する．わーい．

当日

  • 迷子になる(安定の)．

  • mixiさんに初めて行った．競技が行われた会場めちゃくちゃ綺麗だった．オシャ (≡ﾟ♀ﾟ≡) f:id:chigichan24:20180910195658j:plain

  • インターネット有名人の @raryosu くんと会ったりした．

競技前

  • チュートリアルをやったりして，なるほどこれがgit challengeか〜ってなったりしてた．
  • ごはんが美味しかった．
  • 社員さんとエモい話と，高専関係者って結構世界に転がっている話をした．

競技開始！

  • 難易度が★ ~ ★×5 まであって，チーム戦だったのにペアの人に雑に問題を振ってしまい(申し訳ねぇ)，自分は得点が高めなものから見始めてました．
  • 適当にやったら得点にならなかったので焦って前からちゃんと解き始めました．
  • 問題は現実でも { 遭遇したことある | 遭遇しそう }なものから，こんなことできるんだ！みたいな気付きが多い問題まで多種多様で問題を解きながらもかなり学びが多かったです．

  • このボタンを4つ同時に押して運営を煽るなど(????)，場を和ませるムーブをしました．
  • ほかにも，場を和ませるムーブをしていました．楽しかったです???

結果発表 & 解説

  • 結果的には4位くらいで，成績的にはかなり，やらかし太郎だったけど，面白かったので良しとします．

懇親会

  • ごはんが美味しかった(デジャブ)
  • git challengeの話もたくさんしたけど，普通にAndroid・ iOSの話をしてそこそこ学びがあったのでよかった．

最後に

  • こんな楽しいイベントを作るmixiさんすごい．
    • 問題を思いつくのも天才的だし．競技を支えるインフラ，テスターを書くことなどを考慮するとかなり時間がかかるはず．．．
  • 特に，私の害悪度高いムーブを受け止めて，淡々と問題を解いてくれたペアの chocoboくんありがとう！

余談