話してきた。スライドはこちら。
20分で話せるボリュームにまとめるにはちょっとスコープが広すぎて抽象的かつ割と普通な結論になってしまったなと題材選びに反省がある。 もう少し具体例について堀り下げられる時間がほしかったが、コンテキストなくそこだけ話してもやはり本質的には意味の薄いものになってしまっただろう。 問題を考えるときに、チームとして実際に考えてたことの本質的な部分についてなんとか言語化できたかなーという気がする。 逆に言えばそういう言葉を使って議論してたわけじゃなくて、自然とそういう目的や価値観を議論の中で共有できたからこそ、問題を良い方向にどんどんブラッシュアップできた。といえると思う。(ぼくが勝手にそう思っていただけでなければ…)
基本的にはまとめに書いたとおり、目的ドリブンで価値観を決めて、その価値観をもとに良し悪しを図り、やっていく。を実践した結果としてこういうのが出来たという話をした。 言ってることは当たり前のことになっちゃったけど、なんだかんだ一番重要かつ本質的に一番大事だったのはここで、これをそのまま伝えることにした。
プロポーザルに書いておいて語れなかったことにちょっと触れる。
どのようにしてブラックボックスとなっているアプリケーションが仕様を満たしているかをテストするとよいのか
これは id:sonots さんが主にやっていたことなので本当はインタビューしないといけないんだけど、 基本的には操作による状態の変化をエミュレートして、サービスが返すデータがそれと矛盾していないことをテストしていた。 簡単な具体例をだすと、S席が100席あるときに並列で5人同時に買ったら、残り95席になっているはず、それぞれ別の席が得られているはず、ということを確かめる。
実際はもっと複雑で、タイムアウトがありえる。すると何が難しいかというと、クライアント側からは操作が成功しているか失敗しているかが分からない。 つまり、並列で5人同時に買った操作のうち2件がタイムアウトした場合、残りの座席は95席とは限らないし97席とも限らない。 僕たちはどうしたかというと、許容誤差の範囲を動的に計算して、95席〜97席の範囲に収まっていれば正とするようなチェックをしていた。
また、座席のランダムチェックに関しては、全体でn件以上予約した結果として全体の座席の割り振られた順番が等差数列的になっていないことを確認していた。
こうすることで、単純な ORDER BY RAND()
を ORDER BY id
などに書き換えればFAILさせることができるし、一方でランダムにn個生成した数が等差数列になる確率は許容範囲になるだろうという目論見があった。
n件予約できない場合はもちろんこのチェックは走らないが、このようなことを試すモチベーションは仕様無視して予約処理の高速化を図るチート行為なので、件数が増えたときだけチェックすればよく何ら問題がなかった。
極限までチューニングする上でどのようにプロファイリングするとよいのか
普通にプロファイリングする。のだけど、以下のようなツールを組み合わせてボトルネックを解析してチューニングするのをひたすら繰り返していた。
- Linux
- dstat
- pidstat
- iostat
- netstat
- ss 使うべきなんだろうけどまだ慣れきってない…
- MySQL
- pt-query-digest
- SHOW ENGINE INNODB STATUS
- https://dev.mysql.com/doc/refman/5.6/ja/innodb-information-schema-transactions.html
- Redis
- SLOWLOG GET
- Perl
- Devel::NYTProf
- Devel::KYTProf
- log
- alp
ボトルネックとその原因を明確につかめるまでは多角的に情報を集めて矛盾の無い判断をするように気をつけていたと思う。 あと、PerlのNYTProfはかなり詳細に出せるので、読み方さえ理解すればすごく強力な武器になった。
あとは理屈上このほうが速いんじゃね?というのを適当にいろいろ試したりするのは予想外の結果になったりして面白く純粋に楽しかった。
そのほか
当たり前だけど、完璧な問題が作れたわけじゃない。課題はたくさん残ったまま予選当日を迎えてしまったし、いくつか初期実装の不備も出してしまった。 それらの点に関しては講評でも触れたとおりだけど反省しかないし申し訳ないと思っている。
その一方で、出題した問題そのものの本質的な問いかけに関しては、自分で言うのもなんだが高い評価をもらえたんじゃないかなと思っている。 おこがましいけど過去イチで面白くやりがいのある問題を作り上げてやろうと(勝手に)思っていて、そう思っていた反面ぜんぜん自信がなかったからずっと不安だったけど、良いフィードバックがたくさんもらえたのは本当に嬉しかったし、ひとに会うたびに無限に褒められが発生したので自信につながった。
あとは、ISUCONの作問は業務時間を使ってやっていたんだけど、仕事としてやる以上は成果を残さなきゃいけないというプレッシャーもあった。 ISUCONに関わる上での成果とはなにかって考えると、やはり良い問題を作るというのが本質的なコミュニティへの貢献だし、それこそが会社や自分自身のプレゼンスの向上への最大の近道だと思ってやっていた。逆にいえば、中途半端な成果にはしないという覚悟をしたからこそ「やります」という声を挙げられた。覚悟だいじ。
今年もいろいろ覚悟を決めて良い変化をちょっとずつ起こしていきたい。
追記
落穂拾いをずっと落ち葉拾いって読んでしまってた。おち"ぼ"ひろいなのかー。勉強になった
— かるぱねるら (@karupanerura) January 29, 2019
落ち穂拾い != 落ち葉拾い。覚えた。
ところでこれ送り仮名つけるのとつけないのどっちが正しいの?