Cookpad tech kitchen#8に参加してみた
Cookpad tech kitchen #8に当選できたので初参加して来ました 色々と経験出来たのでメモ
tech kitchenについて
まず、ガッツリ料理が出てきたのにびっくり。。 野菜もふんだんに使われていて、見た目も味もステキな料理が食べられてこれだけでも来た価値が・・とちょっと思ってしまった笑 飲み物も提供されていて、セッション始まるまでは何しに来たのかちょっとわからなくなるほどのおもてなし感
セッションについて
非同期なジョブ
ワーカーがスケーラブルではない → キューをトリガーにdockerでワーカーが必要な分だけ起動する → activejobとAWS（SNS,SQSなど）を活用
Barbeque → ジョブキュー管理システム
- Hako → コンテナ管理ツール
アプリとワーカーで同じイメージから起動しているため環境差分が無くスケールしやすい
kuroko2
クックパッドのジョブ管理システム
美しいバッチの壊し方
- Bricolarge
- 1ジョブ = 1SQL → よいバッチ（運用しやすいバッチ=障害の対応がしやすい）を作るため
美しいバッチとは！？
- I/Oの対象ごと（DB、テーブル、ファイルなど）にジョブ分割
- ジョブ管理システムで結合
Others
Hakoとは
dockerで賄えないDNSやDB接続情報なども設定ファイルで管理できる（？）ツール
DWHについて
DBA的な仕事もしつつアプリ（バッチ）もガッツリ書く ブリコラージでジョブ管理をしているのでバッチはほとんどRuby製（ただし、中にはシェルなどを呼び出している部分も・・） DWH（Amazon redshift）のキャパ的にはバッチ処理自体では全然余裕があるが、DEVやビジネスサイドで呼ばれるクエリ処理がガンガン来るため大変・・（グルーバル展開もしているため、それこそ一日中来てしまう。。）
Cookpadの開発環境について
本番と開発環境のDBのレプリケーションについて
本番DBと開発DBの間にもう１個DBがかまされている（※わかりやすさのため準本番とする） 本番DBから準本番DBへのレプリケーションはステートメントベース 準本番から開発DBへのレプリケーションはレコードベース（IDが変わってしまうなどの問題があるため） 準本番から開発DBへのレプリは開発用のデータはID１から、レプリは必ず6万以上から、といったような感じでMySQLのAUTO INCREMENT(?)機能などを活用して運用している どうしてもレプリ時にエラーとなってしまうデータ（重複エラーなど）は無視する 詳しくはブログにも書いてあるとのこと
開発チーム、体制について
リリース（？）、システムははリクエストごとにdockerイメージがスケールしていくような構成になっている → スケーラブルな仕組み 開発チームはビジネスサイドのディレクターさんなども含めた2〜3人とかの小規模なチーム プロジェクトにチーム（人）が紐付いているような感じで体制は流動的
セッションはRubyもAWSも使っているわけではないため概念的な部分とかしか理解できず、持ち帰れたものが少なかったかも・・ ただ、やっぱりバッチがどうあるべき、どういう問題を抱えていてこうした、みたいな話が聞けて良かったし、個別にお話させて頂いて色々聞けたのも良い機会でした！
