chigichan24のお気持ち表明

イケてるエンジニアになりたい.

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を改善したいとなったが,これをチューニングするのは死ぬほどつらそうと思った.次にわざわざメモリに展開してからソートするのは馬鹿らしいのでsqlORDER BYすればいいと思った.よく確認するとsqlですでにソートされているのに再度ソートを掛けていて :thinking_face: となったのでその処理を外した.また,わざわざハッシュにする意味もないので直接文字列生成してそれをrender するみたいな方針にした.

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

総括

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

最終スコア

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

リポジトリ

github.com

謝辞

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

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

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の話もたくさんしたけど,普通にAndroidiOSの話をしてそこそこ学びがあったのでよかった.

最後に

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

余談

mainframerで外部ビルド環境を作った話

最近

  • 購入して一年も経ったMacBook Pro(メモリ 8GB)でAndroid Studio × 3,XCode,RubyMine,PyCharm,Chrome(タブ50個 over)とかで開発を同時多発的にやっていると コンピュータが重くて重くて しかたなかった.

  • 特にAndroid Studioを触る機会が多いが,他人のコードをレビューする際にDatabindingやdaggerで生成された静的ファイルを一度消してビルドする必要があり(clean build & rebuild)それが重すぎて重すぎてコンパイルしている時は 虚無 になって Perfumeのことを考えるくらいしかやることがなく ,非常に時間がもったいないと感じていた.

そこで!!
  • せめてAndroidのビルドだけでも外の環境に投げてその間でも開発が続けられるようにーと思って,mainframerを導入してみました.

mainframerとは?

github.com

  • これのことで,要するに,gradleとsourceファイルをみて,remote buildする環境を提供してくれるやつです.

  • Android Studioにはこれを支援するPluginが入っているので,localの設定はそんなにしんどくありません.

  • remoteもDockerなどで,ビルド環境を再現してあげればもう簡単に,ヒョイとできます.

Remoteの設定

  • AWSなりなんなりに適当なインスタンスを建てる.
  • OracleJRE(openJREだとkapt + databinding あたりがバグった)を入れる.
  • SDKHandlerで,作りたい環境にあったバージョンのSDKを入れる.
  • licenseという概念があり,これが正しく認証されないとビルドができないので,きちんと指定します.

Localの設定

  • そもそも,普段./gradlewをあまり使わない人だと,gradle/wrapperの下にgradle-wrapper.jarがなかったりするので作っておく.
  • Plugin から,Mainframer Integrationを入れる.
  • 先に設定したRemoteを~/.ssh/configに書いて,それをAndroid Studioの Mainframer constructionで指定する.

ハマりポイント

  • 適当な権限でremoteのSDKやlicenseを指定すると書き込みや実行権限が振られずに正しくビルドできないのでディレクトリごと権限振る,ちゃんとユーザーを作るなどする必要があります.

  • 規模によりますが,私のやっていたコードの場合t2microで立てたらビルドが終わらずに途中で死んでました.多分CPU,メモリスペックともにそれなりなものを選択する必要があります.(私はt2-largeを選択しましたがそれでもCPU使用率が200%近い時がありました.)

結果

Before(普通にローカルでやる)

gifなのですが容量の問題でループできなかったのでリロードして確認してみると遅いことが分かるかと思います.

f:id:chigichan24:20180418202953g:plain

After(remote でビルドする)

f:id:chigichan24:20180418180652g:plain

お気持ち

  • localでやっていた時,フルビルドで最悪7-8[min] 早いときでも2[min]程掛かっていたビルドが,最悪でも 2[min] ,早い時は数秒でビルドが終わるので開発効率が上がりました.

  • ビルドしている時にコンピュータが重くならないので,なにか別の作業をすることもできます..コンピュータのファンが唸らない!!

  • これはまだやってませんがついでにCIもCircleCIやTravisに頼ることなく自前で回せます.

まとめ

  • これで作業が遅いことをPCのせいにする言い訳ができなくなった...