https://speakerdeck.com/takai/the-design-philosophy-of-kuroko2
- kuroko2運用
- 複数サービス感の整合性の取り組みについて
agenda
- kuroko2の近況
- バッチ周りの概況
- 構成
- 運用
- デプロイ
kuroko2の近況
ジョブスケジューラー/ワークフローエンジン
アーキ
- console
- UI
- スケジュールを登録する
- 実行命令を投げる
- worker
- 実行(commandexecutorでシェル実行する)
- DB
- console/workerとで情報の受け渡しをする
沿革
- Takaiさんのスカンクワーク
- 大石さんが引き継ぐ
- OSSにしないつもりだったのがOSSになった
- サイレントリリース
- Takaiさんの資料をみてほしい
方針
- 現実的な運用を見据えた安定した設計
- kuroko rabbitmqを使っていたけど不安定だった
- DBでポーリングしたほうが安定するんじゃないかという発想
- UI/UXで管理の問題を解決する
- シンプリシティ
- スケジューラーと汎用性の高いワークフロー管理に徹する
- 外の機能と連携する(slack hipchat bricolage hako)
- 必要な部分にだけ開かれた拡張性
拡張性
- カスタムタスク(digdag/airflowでいうところのoperator)
- タスクの作成
- kuroko2.ymlへ宣言
- kuroko2 script
- env/env/runner
使いどころ
- ショートカットの作成
- 本体に手を入れなくても運用しているドメインに合わせたタスクが作れる
- 実験的タスクを試す
Kuroko2::ApplicationController拡張
- lib
- Raven::Transports::Fluentdへのコンテキスト通知などで利用
- ログなどのトレーシング
- ユーザーごとのアクセス制限
- Controller拡張だけでなく別の拡張ポイントも必要
課題
- ドキュメント
- 枯れさせたい
- ワークフローの機能強化
- Hako(Docker)との効率的な連携
バッチ周りの概況
- kuroko2の社内バージョンはない masterブランチのリリース直前のものを使う
- 700のバッチジョブ 1日あたり6000回 230worker
kuroko2の上ですべて管理
監視
- cpu/disk/network/死活監視
ジョブの状況を関し
APiをみてる
- v1/stats/waiting_execution(実行まちジョブ)
- v1/stats/instance
デプロイ
- capistrano
- console/scheduler/processor/comand-executerにわけている
- HUPシグナルによるgraceful shutdown
- バッチジョブは各部署が責任を持つ
− テンプレ通りに運用
