ISUCON7予選で得た知見

きっちんゴリラ*1*2というチーム名で、id:tyage, id:nonyleneと出場しました。
結果は、max 113,846、score 95,352でした。

詳しい内容は

nonylene.hatenablog.jp

の通りです。

準備

去年の反省を活かしてデプロイスクリプトやベンチマーカーが混んだときのための負荷クライアントの雛形を準備していきました。
結果、提供されたベンチマーカーのスケーラビリティが素晴らしく後者は無用となりました。*3*4

作戦

結果的に、以下の作戦になりました。

  • app1サーバのnginxでロードバランサになる
  • app1サーバだけで/iconsに関わるすべての処理を受ける
  • app1, app2サーバで残りの処理をする
  • pumaのthreadsを増やしまくってCPUを使い切れる範囲でいい感じの値を二分探索する
  • ベンチマークガチャを引き続ける

役割分担

  • 全員
    • 初期の足場硬め
    • ログやメトリクスの収集環境構築
    • デプロイの仕組み
  • tyage
    • アプリのチューニング
    • /iconsの処理をDBから剥がす
    • N+1の解消
  • nonylene
    • インフラの設定とチューニング
    • HTTP Cache問題の解決
    • nginxやsystemdの設定

私はmackerelの設定といった細かい雑用やベンチマーク結果のエラーを眺めてボトルネックの指摘をしていたくらいで、特に実装上の貢献はありませんでした。
が、チームの皆様が優秀で/iconsのHTTP Cache設定およびimageテーブルの破棄(と、パラメータチューニング)がうまくいって10万点付近まで浮上することができました。

知見

戦略をちゃんと考える

戦略はありませんでした。しかし、今回のisuconは戦略を立てられたかどうかでHTTP Cacheの問題をクリアした後の点に大きく差がついたであろうことにあとで気づきました。

ISUCON7予選 当日マニュアル.md · GitHub

fetchにもN+1があり、POSTは3倍の点なのでfetchを遅くしてfetchで食うリソースを減らす。fetchでworkerが取られるのでthread数は思い切って増やすという戦略が有効だった。(もう遅い

2017/10/23 19:25
b.hatena.ne.jp

ということです。

isucon.net

にも書いてあるとおりです。
元の当日マニュアルにはちゃんとヒントが散りばめられています。太字になってすらいますね。
ドキュメントは落ち着いて隅から隅まで読まないければならないことがわかります。
実作業をして手を動かしてるとどんどん視野が狭くなっていくので、最初のうちに戦略を死ぬほど考えるとよいかもしれません。*5

CPUを早いうちに使い切る

Mackerelを導入してグラフが見えているのにも関わらず、CPUを使いきれてないことの問題をはっきりとは意識できてませんでした。
CPUが使い切れていないということは、ネットワークやディスク、メモリのいずれかがボトルネックになっているということであり、まず最初の目標はCPU使用率を100%になるよう設定を弄ることだったのかもしれません。
意識していても設定を弄ったりコードを読んでると忘れてしまいがちなので、ここを最初にクリアするのが重要です。*6

ベンチマーカーの気持ちになって考える

ユーザやjsのクライアント実装の気持ちになるとも言えます。
解説にもあるように、jsクライアントの実装は/fetchを起点としたmessageの取得になっています。
ブラウザでしっかりとアプリケーションの動作を確認して図にしておくと、当日マニュアルの読み込みが効いてきそうです。

感想

いいチームでおもしろい問題を解き、10万点の大台に乗れた点で概ね満足できました。
特にsleep(1)が一見不要に見えて本質的なパラメータになってるのは、とても面白かったです。インフラとアプリのバランスも良かったように思います。

運営および作問、インフラ設営、チームのみなさまありがとうございました。とても楽しく有意義な8時間でした。

*1:京都市左京区にある飲食店

*2:てきとうに決めた

*3:めでたいことです

*4:去年はfailしまくったので、外形監視テストでカバーできないかと考えていた

*5:実装をしない人をロールとして設定し考えさせてもよい

*6:仮にマルチコアでもtopを見ればわかるはず

プログラマのような知的労働者は、労働者自身が生産手段を半ば独占できているので、使用者に対して強気に出ても問題がないと思っている。*1
もちろん、チームで作って運用し続けられる規模のシステムだからこそ会社として業が成り立つのであり、自分ひとりの我儘で事態が大きく変わることは少ない(ように組織が設計されているべきだ)。
だが、「プログラマが辞めたあとに現場が混乱した」というイキり武勇伝は、話の真偽はともかく、労働者による生産手段の独占にそのような効用があることは間違いがないことを示している。
一人欠けただけで生産体制が崩壊するようなシステムはよくないのだが、組織労働の最大の敵はコミュニケーションなので、話をつけて調整する相手が少なければ少ないほど効率が上がることには違いがない。
なので、労働とくに知的労働と属人化がトレードオフになることは避けがたく、生産手段の独占され具合が強い業種ほど労働者が強くなれる。
このような前提のなかで、現代のプログラマはPCとインターネットさえあれば仕事ができるので、生産手段のうち大きな部分を専有しているといえる。*2*3*4*5 別にプログラマを称揚する意図は無いのだが、仕事のために必要な(一般人がアクセスできない)道具が少なければ少ないほど生産手段を独占しているといってよいだろう。

non117.hatenablog.com

追記

というか一般的に知識ってそういうもんでは?

*1:労働契約がすごい適当な文言だし……

*2:OSSによって、物理的ではない生産手段がパブリックアクセス可能なのも寄与している

*3:とはいえ銀行システムとかの超でかいやつの設計・開発・運用にそのまま理屈が適用できるとは思えない

*4:大規模プロジェクトは別の知識が必要になる説

*5:計算機科学ちゃんとやってきた人は何やっても強い気はしなくもない

自転車通勤の感想

健康

  • ジムと併用するとどんどん体脂肪率が落ちていく
  • 業務中眠くなりにくい
  • お腹が減りにくくなる
    • なんで

夜間の自転車と他の登場人物との関係

  • 自動車
    • 建前上は教育を受けて免許を持っており、減点制度もあるので無茶苦茶なことをしてこない印象
    • 前だけでなく後ろのライトあるいは反射板が大事
  • 歩行者
    • 車輌のほうが運動エネルギーがでかいので常に譲歩する
  • 予測困難な歩行者
    • 信号違反する人・突然振り返って道路を渡り始める人
      • 頑張って回避を試みるが怖い
      • 可能な限り歩行者に近づかない作戦
  • 自転車
    • 人によってはふらふらしてるので近づかないほうがよい
    • 常時点灯ではこちらに気づいてくれないことがある
  • 無灯火・車道逆走
    • 怖すぎる
    • 実は罰金刑らしいが運用されてなさそう

前のライトは常時点灯ではなく点滅のほうがよいのではないかという仮説

  • 目立たないとそのうち衝突しそう
  • 自転車の駆動音が小さい問題
  • ライトの明るさが自動車に比べて弱い問題
    • 反射板の方が常時点灯より目立つような気はするが、無灯火に対しては無力

問題について

人によって解決できる問題の複雑さ(大きさ?)には限界があると思っていて、それは忍耐強さとか問題を解決してきた経験に左右されてしまうとも思っている。問題解決の方法そのものは抽象的なメソッドとして言語化できるものではなく、暗黙知に属するが、しかし、知的労働者なら暗黙知のベールを破壊しないでどうするという葛藤もあり……。

そこでレビューというフローが便利で、これは暗黙知暗黙知モナドに包んだまま個別具体的な問題の解決方法を示唆していく教育手法だが、現状これ以上の指導方法が実践されてはいなさそう。*1

私が大学院生の頃の研究は散々なもので、難しい問題を前にすると1秒も考えずに思考停止していたし、当時の私が今の私の分解できる問題に対応できたとはとても思えない。なので、他人の問題解決能力をとやかく言うことはできないのだ。

実社会で解かれる問題に、アトムとしての分割された問題が難しすぎるケースはごく稀で、難しい問題は複雑であるだけだと思っている。*2*3なので、問題を諸問題へ分割するのが問題解決なのだけど、これもまた(これこそが)暗黙知ということでこの話はおしまいです。*4

*1:というか問題解決の手法が一般的に言語化(記号化)されたらあらゆる問題が機械によって解決可能になる

*2:難しい問題を解いたら残りすべてが作業になってしまうあれです

*3:しかし実際には作業でミスをする

*4:おなかがへりました

近況

業務

  • Railsサーバ屋さん かつ フロントエンド屋さんからインフラ屋さんへ
  • 業が何か変わったとかではなく、他のプロジェクトでは異なる役割をやってみようかくらいのあれ
  • chef鈍重で面倒なイメージがあったけど、ちゃんと構造化すれば便利
  • 業務水準で上から下まで作れるようになってよかった

引っ越した

  • 旧居が大通りに面しており自動車の騒音がひどかった
  • 利便性は奥まった場所でも確保できるので、車の多い環境に住むべきではなかった
  • 引っ越し
    • 物を捨てる労力が半分くらい
    • 読まない本を捨てられない問題
    • 壁の穴はティッシュを詰めてもごまかせない

自転車通勤

  • fitbitの安静時心拍数が有意に上がって調子が良い
  • 体脂肪率が単調減少し続けている
  • 可処分時間が50分くらい増えた
  • 京都駅が憎い

水耕栽培

f:id:non_117:20170905223413j:plain

  • 契機はわすれた
  • これは青梗菜
  • 毎日大きくなっていておもしろい
  • 日照が足りない場合は植物用LEDライトを買うとよい

家電買い替え

外食が苦手でコンビニも飽きるので、より自炊をしやすい環境を作っていっている

冷蔵庫

  • 毎日仕事が終わったあとに献立を決めてスーパーへ行くのは非効率
  • 肉や野菜をまとめ買いしてもある程度鮮度を保てる装備が必要

aqua-has.com

  • 選考基準
    • でかすぎない
    • フレッシュルームと野菜室がある

感想

  • 左開きのほうが良かったが、高級品(10万以上)にしかそのようなオプションはなかった
  • 概ね満足している
  • 肉をそこそこ長期保存しても問題ない
  • 用途別の扉に分かれていると、お茶などの取り出しで肉・野菜室の温度が下がりにくいメリットがありそう

オーブンレンジ

panasonic.jp

  • 選考基準
    • オーブンが欲しかった
    • 魚が焼けるとうれしい
    • 温度センサー分解能がミドルレンジモデルの8倍(すごそう)
    • 新製品が出た直後で型落ちモデルが安くなっていた

感想

  • コンビニの食品を温めただけなのに、なぜか以前より美味しい
  • あたためモードで食品の目標温度を1度単位で設定できる
    • いみがわからない
  • パンを焼いてもなぜか美味しい
  • あらゆる料理が作れる
  • 蒸気が出るので蒸し野菜作り放題

焼きそば

f:id:non_117:20170911195941j:plain f:id:non_117:20170911200046j:plain

出力

f:id:non_117:20170911202454j:plain

ふつうに美味しくて謎
最高の商品です

Cooking Hacks

cooking hacksで検索すると何故かIoT文脈の

www.cooking-hacks.com

が出てくるが食べられないRaspberry Piではなく料理のほうのお話。

 

最近我が家ではオレンジやパイナップル、グレープフルーツなどを食べるのが流行っているのだが、温州みかん以外の皮が厚い柑橘類は皮と身を包丁で分離するのが難しく、しかし手を果汁まみれにしてかぶりつきたくない問題があった。

 

www.youtube.com

解はこのようになっていて、たいへんエレガントである。

他にも、

www.youtube.com

www.youtube.com

www.youtube.com

このような有用なcooking hacksと呼ばれる叡智がYoutubeに集まっていることがわかった。

3つ目の櫛のような器具はスライスヘルパーとかオニオンホルダーと日本では呼ばれるもののようだ。

www.youtube.com

総集編的なやつがこれ。

フルーツの剥き方も様々な流派があるようだ。

ReactのViewとはどこか

  • ReactとVue, AngularはViewコンポーネントソースコードの構造に、JavaScriptが主かHTMLが主かという違いがある
    • ファイル単位としてのReact ComponentはViewだが、より詳細にみていくとrender()のなかのreturnのみがView(狭義)ともいえる
      • ReactはView(広義)までロジックが地続きになる
      • MVVMでのViewModel, ControllerがReact Component内のrender()以外と対応するのかもしれない
    • ロジックが地続きになっていると柔軟性は高そう
      • 柔軟性はコントロールが難しくてカオスになりやすい
      • React Componentの中にほとんどすべてのロジックが書かれたソースコードを我々はたくさん見てきた
    • この処理は間違いなくここ!という切り分けが常にできるとは限らず、現実世界に低い負荷で対応できる点で柔軟性は重要
      • ただし過剰な柔軟性ということもある
      • その他フォルダ問題
  • モジャッ
    • 難しくて思考が発散したので今日はここまで
    • やはりReactだけでフロントエンドGUIはいけるのでは
      • Reduxいらない派