鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

Cookpad Tech Kitchen #8 に行ってきた

cookpad.connpass.com

非同期ジョブと仲良くする / 小林 秀和さん

非同期ジョブと仲良くする // Speaker Deck

  • barbeque (https://github.com/cookpad/barbeque) の話
  • Docker ベースのジョブキューシステム
  • アプリ（マスター）とワーカーは同じDockerイメージから起動（起動時引数が違うだけ）
  • Hako (Dockerコンテナ管理ツール) を利用してる
  • キューは SQS なので、AWS におまかせ
    • cf. sidekiq + redis を増やしたら、スケールするように redis cluster の面倒見が必要
  • アプリからの実行は ActiveJob 準拠なので barbeque 特有のコード書かなくてよい
  • 開発用にローカルでの実行もできる
  • AWS SNS 契機でのジョブ実行もできる
  • アプリのデプロイはなく、ビルドした Docker イメージを上げればよい。

AWSのサービスやHakoと連携してそれらの機能をうまく活用することで、非常にシンプルな構成で、スケールする仕組みを実現できているのがよいなと感じました。

kuroko2の近況とクックパッドのバッチ周りの概況 / 大石 英介さん

kuroko2の近況とクックパッドのバッチ周りの概況 // Speaker Deck

  • kuroko2 (https://github.com/cookpad/kuroko2)の話
  • 高井さんのスカンクワークで開発され、社内導入
  • 大石さんがメンテを引き継ぐ
  • 元々OSS化の予定はなかったが、2016/10 OSS化、諸般の事情によりサイレントリリース
  • 現実的な運用を見すえた設計方針。
  • カスタムタスクによる拡張性
    • kuroko2 本体に手を入れなくてもドメインに合わせたタスクを作れる
  • バッチまわりの近況
    • 社内では OSS のkuroko2 のmaster のヘッドを使ってる
    • 700個のバッチジョブ
    • 一日あたり6000実行
    • 230 worker
    • 監視用のAPIをたたいて監視 (zabbix)
    • capistrano でデプロイ. worker は HUPシグナルでgraceful shutdown
    • ほぼすべてのジョブを1つのkuroko2アプリで管理

バッチ実行基盤なのでその上で個々のバッチが確実に実行され、それぞれの価値を生むのを継続して支えつづけることに価値があり、安定的に運用できることに価値を置いて技術選択、設計をされたという点が一番印象に残りました。自分も開発対象のそれぞれの特性によって何に重点を置くべきかはしっかり考えて行きたいと思いました。

美しいバッチの壊し方 / 青木 峰郎さん

Cookpad TechKitchen #8: Breaking BatchJobs Beautifully // Speaker Deck

  • ジョブ数が多くフローが複雑。とはいえ1000ジョブ強なので小規模もいいとこ
  • Kuroko2 でスケジュール。中身をBricolage で実行してる。
  • Bricolage
    • SQLバッチ専用フレームワーク
    • 1ジョブ = 1SQL分の強固な思想に基く → よいバッチのために必要だから
  • 運用しやすいバッチはよいバッチ
    • 落ちたときに簡単に対処できる = 障害を直しやすい = 美しく壊れる
  • 美しく壊れるバッチの3つのポイント
    • どこで壊れたかすぐわかる
    • 続きから実行できる (9割までいってたらせめて8割5分くらいから実行できる)
    • リトライで直せる (ちょこっと直してリトライ)
  • どうやったら美しく壊れる？
    • 処理をひたすら細かく分割し、小さい job を繋いで全体を構成する
      • Bricolage は 1SQLなので、もう分割できないところまで分割できてる。
    • I/O対象ごとにジョブ分割
      • 中間テーブルに書いたらそこで無条件に切る
    • ジョブ管理システムで結合
      • →今のところ Kuroko2 で繋いでる。
      • グラフで正常終了、実行中、落ちてるが見えて区別できるとよいなぁ… (Kuroko2への要望)
  • 羃等バッチの記述
    • いっこいっこがリトライ可能じゃないと意味がない
    • トランザクションなど。
    • 更新 (UPDATE) しない→あたらしいテーブルつくるか、DELETE&INSERTするか

どこで壊れたかすぐわかること、続きから実行できること、ちょこっと直してリトライで直せることというのはSQLにかぎらず一般的に大きなバッチをどう美しく（壊れた時に早く対処できるように）していくべきかの指針になると思うが、単位を1SQL文にするという明確なルールでそれを実現したというのは興味深かった。

懇親会

成田さんとヨシオリさんに、自前で作ってOSS化することに関して聞かせていただきました。最初から自分たちで作ることを考えるわけではなく、まずはその領域のありものをしっかり調査して、その結果はまるものがない場合に覚悟を決めて自分たちで作るという判断をしてること、一方で開発するときはOSS化することを前提に設計することで、業務依存な部分(OSS化しない)とそうでない基盤部分(OSS化する)をうまく分離していることなど、自分が最近悩んでいたことに対する他での取り組み方を聞けてとても参考になりました。