「Kuroko2の近況とクックパッドのバッチ周りの概況」というテーマで発表させて頂きました。(今回の記事ではクックパッドのバッチの概況については特に触れませんが下記資料を参照ください)。Kuroko2とは、Ruby製のWebベースのジョブスケジューラーです。2014年にクックパッド社内で開発され、2016年の秋にオープンソースとして公開しました。採用しているアーキテクチャの背景を知ることができます。コントリビュートする際にとても参考になる良い資料だと思います。カスタマイズする方法を紹介したいと思います。Kuroko2の方針ジョブ管理、ワークフロー管理への要求はトレンドや新たな技術の登場によって細かな要求が今後も変わってくることが予想されます。メンテナンスや拡張が行いやすいシンプルな設計を保つこと、様々な現場にあわせた拡張性を担保するために本体はシンプルに保っていくべきだと考えています。そのために以下を方針として意識しました。実際にクックパッドのバッチ運用を通して現実的な現場を意識して作られたものです。闇雲に最先端の技術を採用するのではなく、あえて管理のしやすさを優先して枯れたアーキテクチャを採用し、安定した運用ができるような設計を保っていくべきだと考えています。特徴として、煩雑になりがちなバッチ管理の方法をUIがフレームワーク的にアシストしていることが挙げられます。具体的には、ジョブ定義の際にジョブの説明を書くためのテンプレートが用意されていたり、ジョブのお気に入り機能、自分の管理するジョブが一覧で見れるダッシュボードなどクックパッドでの運用を通して必要とされたものが実装されています。良い点であり今後も重点的に改善を進めていくべき点だと思っています。当初よりフロントエンドのアーキテクチャが古くなっており、その改良は課題であると思っています。コアになる役割は、スケジューラーとワークフロー管理に限定し、新しい役割を定義はしないようにします。利用されているドメインに特化したものはカスタムタスクを利用することで柔軟性を確保するようにします。シェル経由でコマンドが実行されるのみです。この部分についても特定の機構に依存するものを本体にいれるべきではなく、うまく外の機構と連携できるように目指すべきだと考えています。利用することでそれぞれのドメインに合わせた連携を行っています。間の連携の抽象化をしてもう少し効率的な連携が行えるような改善の必要性があると認識しています。この方法を採用した理由は、Kuroko2本体の機能は常にアップデート可能なように管理できて、かつ必要に応じてカスタマイズしたかったためです。拡張という機能を想定しています。バッチを管理する上で生じるドメインに特化した細かなカスタマイズを行えるようにして、様々な現場に合わせるための拡張性を適切に提供できるようにしたいと考えています。拡張の具体的な方法のサンプルを紹介したいと思います。lib/kuroko2/workflow/task/次にカスタムタスク本体のコードを上記のディレクトリ以下に置きます。渡された任意のコードを実行できます。設定して、利用可能な状態にします。MyProject::Batch.runのようにKuroko2とは別のRailsアプリケーション内のバッチを実行するための専用のカスタムタスクを設定することができます。アプリケーションへのオプション定義のショートカットとして利用しています。本体にコントリビュートする際にも事前に検証などが行なえます。拡張する方法を紹介します。ここでなぜこのような拡張が必要なのかという理由を先に述べておきます。管理したいということがあったためです。それでは、実際に拡張する例を書いてみます。