#appkoyomi 開発メモ

00-index.md

https://github.com/key-amb/perl5-App-Koyomi

主に私自身のための開発メモです。

• Milestone
• Spec
• Issues

10-milestone.md

Milestone

Upcoming

v1

• シグナルハンドリング
• logger 対応
  • logger モジュール化
• ジョブのタイムアウト処理
• ジョブの重複実行制御
• テストコード
• File ジョブデータソース。たぶん JSON 形式
• Memcached セマフォデータソース(ミューテックス)
• 実行中のジョブ数を取得する仕組み
• 実行中のジョブ数が少ないワーカーがジョブを優先的に実行できるようにする
• ロゴ作成 - 誰かに頼むのもアリ

v2

• schedule datastore plugin 対応
• logger plugin 対応
• notify plugin 対応

Done

v0.5

• job スキーマ for SQLite
• semaphore を使わないオプション("None" データソース module)

v0.4

• CLI 作成 (koyomi-cli)
  • job 登録・一覧表示・編集・削除

v0.3

• ジョブ実行ユーザ指定

v0.2

• jobs, job_schedules テーブル分割

v0.1

• job を mysql から読み出して実行
  • job のスキーマ決める
  • job を mysql から読み出す
  • 設定された日付時刻で job 実行
• 設定した間隔でスケジュール更新
• semaphore 取得
  • 排他制御はするが重複制御しない
    • いま ジョブの実行終了後に何もしてません
    • こうすることでかなり実装をサボることができました。v1までにちゃんとやる予定。
• 1分ごとに job 実行
• config 対応
  • 環境変数で読み込む config 変えたり
• logger 対応
  • debug log
  • job 実行記録
• ドキュメント書く
• CPAN に上げる

30-spec.md

Spec

Overview

• bin/koyomi
  • メインプロセス
  • ジョブスケジューラワーカー
  • スケジュールデータストアからスケジュールを読み出し、実行する
  • 複数サーバで稼働する前提で、協調動作する
    • とりあえずは、同じジョブがどれか1台で動く
• スケジュールデータストア
  • とりあえず MySQL にする
• スキーマ
  • ジョブのスケジュール
    • cron 的な拡張記法(ex:*/5 = 5分ごと, 15-45 = 15〜45分の間, “,” 区切り)はサポートしない
    • 複数のタイミングで実行したい場合、複数レコード登録してもらう
    • 正規化して jobs テーブルと job_schedules テーブルに分ける
    • ‘*’ は OK.
    • 設定されたスケジュールの内、いずれかにマッチしたタイミングでジョブ実行される
• 排他制御
  • 任意のジョブが複数のサーバで同時に実行されないように
  • MySQL に排他制御用のテーブルを用意
  • ジョブIDを主キーとするレコードを作る
  • レコード更新に成功したときのみジョブ実行

Schema

jobs:
  - id: job id ★PK
  - user: 実行ユーザ。指定しないときは worker の実行ユーザになる
  - command: シェルコマンド
  - memo: メモ用
  - created_on: 登録日時
  - updated_at: 更新日時
job_times:
  - id: ★PK
  - job_id: job id
  - year:
  - month:
  - day:
  - hour:
  - minute:
  - weekday:
  - created_on: 登録日時
  - updated_at: 更新日時

semaphores:
  - job_id: job id ★PK
  - number: セマフォ数。初期値1。0のときはジョブ実行不可。未使用
  - run_host: 実行ホスト
  - run_pid: 実行プロセスID
  - run_date: 最新ジョブ実行日時
  - created_on: レコード作成日時
  - updated_at: 更新日時

90-issues.md

Issues

明らかにヤバい系はふつうに GitHub Issues に書く。

DS::Semaphore::Teng::Data

App::Koyomi::Semaphore で利用されるので、TengべったりのインタフェースをパブリックAPIにしない。row とか。

X::Teng::Data の基底クラスを作る

上にも絡むが、インタフェース揃えた方が堅牢。その内。

CLI で Job 登録・編集時のバリデーション

いま何もやってないのでやる。