低温調理肉0.1
以下の分量で作成
レシピ
- 豚塊肉 300g程度のモモか肩ロースで紐ついてたら外したほうがピタッとして良い
- 塩 適量 つまみなら強め
- しょうゆ 20ml程度 密封するために空気の隙間を埋める程度
お好みで追加
- 胡椒 適量 ビールと合わせるなら強めのほうがおいしい
やったこと
塊肉の全体に塩、お好みで胡椒を全体にかける
密閉できる袋（ziplockみたいなやつ）に塊肉を投入
しょうゆを空気の隙間をなくす程度に少量いれる。
水面器やバケツに水を貼り、空気を出しながら袋を密閉する。
低温調理が可能なもの（ヨーグルティアなど）で60℃10時間程度
時間になったら取り出し、ziplockを冷水で冷やす。
冷蔵庫に入れられるようになったらで1～2時間冷やしたら完成。
冷やしたほうが味が落ち着き、身も締まるので切りやすくなる。
感想
醤油が多いと角煮チャーシューぽくなるので、肉の味を楽しみたければ醤油は少なめがいい。
温度は錯誤中。あまり低温で長くかけすぎるのもよくないのではと思ってる。
次回
とくに予定なし。
ラーメン道具エントリ0.2
道具についてのエントリがなかったので更新していく ラーメンを作るのにこんなものがあるといいよっていうのがまとめられたらと思います。
道具
- 大きい鍋1 ベーススープ作成・保管用
- 大きい鍋2 麺茹で用
- 取って付鍋 スープ用
- 取って付ザル1 麺あげ用
- 取って付ザル2 スープのカス除き用
- ハンドブレンダー あると色々便利
- 計量カップ 5ml～50mlくらいまで測れるもの
- 密閉できる袋（ziplockなど） 耐熱だと漏れにくい
- ヨーグルティア（低温調理用）
- レードル（30㏄, 250cc）
それぞれについて、どのように使っているかなど書く。
大きい鍋1 ベーススープ作成・保管用
2人前くらいならスープとしては水1Lくらい、その他具材が入ればOK。 大きめの鍋なら何でもよい。
取手が外せるタイプだと冷蔵庫にもしまいやすいのでおすすめ。
大きい鍋2 麺茹で用
なるべく大き目の鍋で茹でた方が水も濁りにくく麺もほぐれやすい。
途中。
うずら味玉1.1
以下の分量で作成
レシピ
- うずらの水煮 8個～12個パックのもの
- みりん 100ml
- しょうゆ 50ml
お好みで追加 * にんにく ひとかけ またはチューブの1cm程度 * お酒 少々（日本酒か焼酎）
やったこと
- うずらのパックを切って中の水を捨てる
- 密閉できる袋（ziplockみたいなやつ）にうずらを投入
- みりん、しょうゆを1:1くらいいれる。
- 水面器やバケツに水を貼り、空気を出しながら袋を密閉する。
- 冷蔵庫で半日～1日
とても簡単でお手軽なツマミになる。
感想
醤油が多いとしょっぱくなるので注意。 みりん多めのほうが食べやすいかも。 にんにくやお酒はお好みで。
次回
とくに予定なし。 面白そうな味が思い浮かんだらやってみる。 ナンプラーとかどうだろう。
ISUCONに初参加した
初めてISUCONというものに参加した。
業務ではOSS系を全く触っていないし、一緒に興味を持って参加出来るような人が社内にいないし…とずっと参加できずにいたISUCON。 前々から興味があったので、試しに今回はどんなにぐだぐだでも揉めたりしない社外の友達を誘って2人で参加した。
参加した後の素直な感想
今まで参加しなかったのが悔やまれるほど得られるものが多く、何よりもチャレンジできるのが楽しかった。 仮説を立てて変更をかけ、どう変わったのか試していくことがとても新鮮だった。 手を動かすのは楽しい！
結果的にスコアは最初の6000くらいから11000と大きな改善は出来なかった。
しかし改善に向けての一歩を実現することが出来て良かった。 参加したことで、他の方のISUCON記事であー！ってなりとても勉強になる。 来年もあれば次は力をつけて是非参加したい。
当日何をしたか
やったことを覚えている範囲で記載。
- レギュレーションの読み合わせ
- sshでのログイン確認
- ベンチマークの実行
- 動いているサービスの確認
- 構成図を手書き
- gitによる変更対象の管理（bitbucketへの登録）
- kataribe導入
- netdata導入
- 気付いたことをアウトプット
当日の振り返り
イントロ
自分がインフラ担当・友人がアプリ担当として動くという方針で始まった。
まずは互いに当日のレギュレーションを読み合わせをし、各サーバへのsshログインを済ませた。 サポートチャットではログインできない！とか6台あります！とか交わされるのを横目に見ながらベンチマークに移る。
app1～app3まで3台構成であることを知る。 app1とapp2に対し、同時にベンチマークをかけたあと1台ずつかけていった。
ベンチマークを2台で実施した方がスコアが下がったため何これ？となった。 1台ずつかけた時も、app1が6000、app2は3000くらいと差があったため、スペックや設定が違う？何これ？？ となった。
後々ログインして確認したところ、サーバ毎にスペックの差異はなかった。おそらくベンチマークのブレっぽい。 netstatやpsでサービスを確認し、Webはnginx、DBはmysqlとミドルウェアを確認した。
gitの管理については友人に任せ、自分は構成図を書いて得られた情報を整理。
お互いのタスクが終わったところで認識と今後の方針を決める。
app1とapp2のベンチマーク差はわからなかったので、とりあえずシンプルにWebは1台でやって行こうということに。
アプリケーションについては友人に任せ、自分はapp3のDBをチューニングすることにした。
DB周りの調査
mysqlなら、まずはバッファプール！と聞いていたのでとりあえず積んでみようと思ったものの、サーバのメモリが1GBだったのでいきなり躓く。 slow-queryの設定とテーブル情報、件数、Indexの有無をまとめて一旦終了。
ベンチマークをかけながらslow-queryのログを眺めると大量に/imageの画像が出ていたので気づきとして挙げた。 DBに画像が入っているとこの時点で気付くものの、どうやって外に出すのかわからずmemcachedとかredisを調べてみたが理解が追い付かずお手上げ。
chromeの開発者ツールでもfetchが大量にリクエストされていることも気付きとして挙げた。
kataribe,netdataの導入
気付きは何点か出てきたが、細かくいじっても改善しないどころか悪化などして焦る。 誰かが言っていたボトルネックになっているところを解消しないとパフォーマンスは改善されないということを痛感。
思い付きで実行することに手詰まり感が出てきたため、まずはリソースを見える化してボトルネックを探そうということになった。
nginxのログ出力を変更してkataribeを導入してnginxのログを分析しやすくした。 netdataを導入し、サーバリソース、ネットワークリソースを可視化した。
netdataが素晴らしかった。
導入した状態でベンチマークを実行して各サーバを眺めるとWeb-DB間のNWが500Mbpsと枯渇していることに気付けた。
気付きからアクションを決めて対応。
アクションの実行
DBのimageテーブルの中に画像が入っていることが悪いことがnetdataのトラフィックを見て確信に変わったので、少なくともユーザ登録のアプリ箇所をDBに書き込まないようにアプリケーションを修正。
するとスコアが6000から9000ほどに上昇。DBへのIOが減ったためと思われる。
その後DBのインデックスを張ったり、my.cnfをconnection手さぐりで修正したところ、最高で15000を記録。脳汁が出た。 設定変更のcommitを忘れていて何をいじったのかわからなくなってしまったので反省。
その後は有効なアクションが打てずアプリケーションを眺めて終了。
反省点
- 初回必ず実行するものはスクリプト化しちゃったほうが良い
- kataribeとnetdataの導入
- ベンチ前にログローテのスクリプト
- 画像をキャッシュする実装方法
- 設定変更は後から何を変更したか追えるようにcommitする
- indexを効果的に張るようにする
振り返り
netdataを入れてからボトルネックがわかり、効果的なアクションが立てられるようになった。 他の方々の記事を見ても着眼点は間違っていなかったことは自信になった。 力不足で実現方法がわからず、何も出来なかったのが心残り。
今回のISUCONの復習を行うのと、ISUCONの過去問も遊んでみようと思う。
