$shibayu36->blog;

株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。

ISUCON8予選を突破した

id:hitode909id:takuya-aとチーム「ディメンジョナルハイソサイエティぬれねずみ」としてISUCON8に参加し、40867点で本戦に行けることになった。ISUCON初参加でいろいろ不慣れではあったが、なんとか本戦に行けて嬉しい!

サーバ複数台構成かつボトルネックになる箇所が結構面白いところが多く、非常に楽しめました。運営の皆様ありがとうございました。

振り返りとして、チームでやったこと・良かった進め方をまとめてみる。

チームでやったこと

開始直後は役割分担して作業していった。言語は勉強がてらgolangにしようと思ったこともあったが、せっかくなら勝ちたいし慣れてるperlにした。

  • shiba_yu36: 鍵置いたりコードのバックアップしたりなどといったオペレーション周り
  • 他二人: アプリケーションの挙動を確認し、作戦を立ててもらう


以下が最初のオペレーションでやっていたこと。


作戦会議の結果、まずはget_event周りのN+1クエリをなんとかする、またサーバ構成はDBがボトルネックっぽいし普通にapp二つとdb一つで良さそうということになった。

  • get_eventのN+1クエリ直す diff
  • サーバ構成を変える。DBボトルネック感あったので、app2台、DB1台に。isucon01をdb、isucon02をapp、isucon03をnginx + appにし、ベンチは03に向ける。
    • diff1
    • diff2
    • ここでGRANTの設定がおかしくて他サーバからDBにアクセス出来なかったので、init-user.shを参考にGRANTをした
    • /initializeがDBサーバと同居な前提だったため、これだけisucon01に固定で行くように。今から考えると、これはinit.sh周りを修正するだけで良さそうだった diff


さらにpt-query-digestsで集計して発見した遅いクエリを調整したり、sheetsのメモリキャッシュをしたりした。

  • N+1クエリ直した後のクエリにインデックス効かせるように diff
  • ORDER BY RANDやめる -> diff
  • reservationsのuser_idにインデックス -> diff
  • sheetsをメモリキャッシュ -> diff


このあたりでISEによって負荷レベルが上がらないという事態に遭遇する。エラーログを見ているとデッドロックが原因に見えた。そこで出来る限りロックを取らなくてすむようにFOR UPDATEいらないところは外してはと会話した。特に/api/events/{id}/sheets/{rank}/{num}/reservationでのロック範囲を最小限にするためにクエリを二回に分けてはどうかというid:hitode909のアイデアが良くて、これによってスコアが安定した気がする。


ただFOR UPDATEを外すというのをやったことにより、全体レポート生成(/admin/api/reports/sales)が同時に動くことが多くなり、その結果アプリケーションプロセスがOOM Killerで殺されるということが起こってしまった。これは辛いけどFOR UPDATEでロックは取りたくないねということでMySQLのGET_LOCKを使って並列度を下げてみることに( diff )。これによりOOM Killerに殺されることがなくなった。

/admin/api/reports/salesがメモリを異常に食ってしまう問題があったので、その修正に取り掛かる。アプリでソートをしているのをやめてみたり、オブジェクトを作らないようにしたり、文字列連結を少なくしたり、最初に領域確保してみたりということをしてみたが、あまりうまく行かなかった。


このあたりで残り30分くらいとなったので、ログ周りをoffにして、再起動試験をした。ここでfinish。うまくいくと40000ちょっとくらいになっていたので、行けるか行けないか微妙なところだなとなっていた。


終結果は40867点。両日3チームを除いた上位12チームに入っていたので本戦に行けることになった。

良かった進め方

  • 開始前に出前で寿司とったのが良かった。途中で寿司を食べながら一旦落ち着いて作戦会議できて、次の対策が思いつくなどの出来事があった
  • 開始後やることまとめておいたのが良かった。
    • f:id:shiba_yu36:20180917011739p:plain
  • rsyncデプロイにしたのはかなり良かった。git commitしなくてもデプロイ出来て素早さが増した
  • 1時間くらいアプリケーションを観察しながら、アイデアリストをホワイトボードに書いていき、いろいろ出揃った後に良さそうなものをピックアップして進められた。結果、最初に効果的な対策を打てた
  • ベンチマーク結果のログをちゃんと読み込むことで、負荷レベル上げられない理由から潰すことができた
  • 3並列でボトルネック解消ってそこまで出来ないと判断し、コード書くのは2並列にして、片方はペアプロするとした。ペアプロすると変なハマり方を減らせ、高速化していたので良かった
  • 15:00くらいに一回再起動試験をしてみたことが良かった。やってみるとisucon01以外のサーバでアプリケーションがenableされてなく、再起動するとプロセスが立ち上がらないということがわかった。もし終了直前だった慌てて原因が見つけられたか分からない。

最後に

改めて運営の方、非常に楽しい問題を作ってもらってありがとうございました。これまでISUCON出てなかったのもったいなかった、今後は絶対毎回出ようと思えるほど楽しかったです。本戦も頑張って優勝したい。

「OKR シリコンバレー式で大胆な目標を達成する方法」読んだ

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

読んだ。OKRのエッセンスについて短時間で学べたので良かった。前半にOKRを導入したら一回失敗して、その後やり方を変えたら成功したという小説仕立てのストーリーがあり、失敗する理由と成功する理由を実感を持って学ぶことができる。その後、後半ではOKRのフレームワークについての詳細の説明があるため、前半の具体例と紐付けて理解することができた。

印象に残ったのは、OKRと人事評価を密接に結びつけるなという話と、導入するときは必ず一度は失敗するから小さく始めろというところかな。

この本ではOKRでの目標設定と、人事評価を密接に結びつけるなと書いてあった。それ自体はある程度納得できるが、その場合評価制度の中のレーティングの役割はどこに持たせたら良いか悩むなーと思った。上司が部下の給与をある程度の裁量を持って決めるようにすると、OKRが評価に関わらなくてもうまくレーティングできそうかな?もしくは成果による評価割合を減らし、会社の行動指針やスキルでの評価を重めにするとかの方法も考えられるかもしれない。

導入ガイドも書いてあったけれど、もし導入するなら必ず一度は失敗するので、特定チームに適用するなど小さく始めると良いと書かれていた。どんな取り組みも小さく始めて早く失敗するのが大事だよなと再認識。

OKR勉強になりました。OKRすごくいいなーと思いつつ、MBOの制度が浸透している状況でOKRにシフトしていくのどうしたらいいかな〜と思ったのであった。

読書ノート

* OKRの基本 1347
	* Oは人を鼓舞するような定性的なもので、かつ期限付き(3ヶ月)、
	* KRは定量的な測れるものを3つ。ただし達成できるかどうか半々くらいに
* OKRは毎週の定例に組み込み、自信度を50%に調整し続ける 1431
* OKRの実行を習慣に 1519
	* 毎週月曜にOKRをチェックする。今週の優先事項3~4つ、OKR自信度状況確認、健康・健全性指標の確認
	* 金曜はウィンセッションで出来たものを褒め称え、モチベーションを上げる
* OKRを決めるときの問いかけ集 1604
* KRはポジティブになるようにする 1629
* チームOKRを作る際に、メンバーに先に自分が考えるチームOKRを考えてもらうと、自分ごと化される 1650
* OKRの本質は継続的な学びのサイクルなので、達成できなかったらその理由を学び、達成できすぎてしまったらもっと厳しいゴールは何かを考える 1668
* OKRの最初の挑戦は必ず失敗するので、失敗したときのリスクを少なくするアプローチを取る。例えば以下のものがある 1687
	* 全社のOKRを1つだけ決める
	* 全社の前に1チームでだけOKRを利用する
	* OKRを1プロジェクトで適用する
* OKRを使った週次情報共有フォーマット 1778, 1819
	* チームのOKRと自信度、優先タスクと達成されたか、来週の最優先事項3つ、リスクや障害、メモ
* よくある失敗 1820
	* 四半期のゴールが多すぎる -> ゴールは一つだけ、全従業員が覚えている明確なものに
	* Oに数字を入れてしまう -> Oは人々を鼓舞するような定性的な目標に。数字はKRで
	* 自信度レベルの設定を忘れる、追跡を忘れる -> 自信度を50%に保つことが大事。週次でも確認
	* 金曜日に厳しい話をしてしまう -> 金曜はあえて楽しくやったことを褒め合う。厳しいことは月曜に
* OKRを使ってゴールの持つ力を高めるには 1880
	* ゴールを達成したかが評価に密接に関わると、従業員は天井を低く見積もるようになる。なので評価とは切り離し、ゴールで可能性を最大化できるようにする
	* 成果の達成はリアルタイムで見ておく。さらにゴールは身近な存在にする。そうしなければみんなゴールを忘れ、方向がぶれたり、実行されなくなる。
* OKRの活用のヒントいろいろ 1927

builderscon tokyo 2018最高でした!

builderscon tokyo 2018に行ってきました。最高でした!トークも面白いネタが多かったのだけど、何より久しぶりに会う人と最近の困り事などについて雑談したり、ネット上でしか知らない人と新しく話せたりといったことが出来たのが本当に良かった。

YAPCから続くbuildersconは自分の中では一年に一回色んな人と話すことの出来る良い機会になっている。京都にいると、他の会社の人と話す機会も少ないので、自分の考えていることが本当にうまくいっているのか確信を持てないまま、悶々としながら仕事をしている。しかし、buildersconのような機会で色んな人と話すことで、それが一年に一回のベンチマークのようになっていて、この部分はうまくいってそうだけど、この部分はもう少しやれることがありそう、みたいなことが改めて考えられる。こういうところが最高だなーと思った。

buildersconは「コミュニケーションをする機会」というのを大事にしているように感じている。それがすごく良い。名札にアイコン画像とIDが書かれていることが、「あーネット上でよく見るあの人!」となって会話になるのが良い。HUBがある会場を使うことで、自然とHUBで会話が生まれるのが良い。懇親会/アフターパーティと、公式の懇親会が多いのが良い(しかも間に変に催しを用意していないので会話が途切れない)。とにかくこういう細かいところが非常に良いなと感じている。

こういう機会を提供してくれている運営のみなさん、本当にありがとうございます。また来年もあれば必ず参加したいと思います!

(最高の名札こういうやつ)
f:id:shiba_yu36:20180910093935p:plain:h300