経緯
動かしているものは秒単位で変動する金融APIへ接続し発注するシステム。システムそのものの詳細はここでは省略させていただきます。
heroku scheduler の料金について調べた時にはここまで分からなかったので、具体的な事例として共有します。
スキルのバックグラウンド
- 僕は非エンジニアであるが、サービスを作りたくて触っていたら一通りコードが書けるようになった（Rails はじめて半年とか）
- Heroku も触っていたらそれなりに使えるようになった
まとめ
事前に分かっていたこと
- 24時間稼働のtaskは worker を使うこと
- schedular は短時間のバッチ処理に利用すること
事前に分かっていなかったこと
- schecular の料金体系
新たに分かったこと
- one-off dyno は起動単位で課金される
- 複数のスケジュールが立ち上がり、それぞれ長く起動すると起動ごとに課金が積み重なる
結論
- scheduler の長めの処理は、worker １つにまとめよう
- scheduler が使う one-off dyno の料金体系は見えにくいが、とにかく短時間で終了する設計が望ましい
詳細
動かしているアプリケーション
- 金融系の取引ツール（Railsで自作）
- API に接続しているバックエンドシステム
- 24時間常駐のWorkerを rake task で実行
- web は起動していない
schedulerを使っていた場所
- 注文残・ポジション残をチェックして、10分おき、1時間おき、1日起きの処理を入れる
- 1分以内に終了するタスクばかりだった
ここまでは良かった。
しかし scheduler の費用がほとんど見えないくらい安かったので、この後の処理を、 scheduler から動かしてしまったのが過ちだった。
scheduler に追加した処理
- より効率性を追い求めるために、秒単位で変動する値動きに対して、10秒ごとに統計的処理を加えて注文状況を変更する rake task を追加した
- 起動時間を長くするため、10分ごと起動のタスクの中で、10分経過するまで sleep を入れつつ繰り返し処理をした
worker は固定で費用がかかるが、scheduler はあまり費用がかかっていなかったので、 「待機時間が長いだけで、ひとつひとつは重い処理ではないから」 scheduler で動かせばいいや、と思ってしまった。
この時には 「worker で動かすこと」と、 heroku のドキュメントに書いてあることの意味が理解できていなかった。
かかった費用
scheduler
14日に気づいたので、応急処置でプログラムを触らない方法で起動数を減らしました。15日から減っているのはそのためです。19日で止めています。
worker (もともと動いている worker )
スケジューラーを止めて worker に移行した後の worker 2
金融系なので19日の月曜日から稼働。
費用抑制効果は一目瞭然ですね。
ちなみに
1ヶ月間チェックしていなかったので、この時点ですでに先月分が請求されていました。^^;
5月の scheduler
worker が $7 だとすると、約２０倍ですね。
dynos の数を見ての通り、並行起動は全て足し算されています。
前半は試行錯誤していたので、task が増えていた時期です。
並行起動する task が増えただけで、処理そのものは軽微なものです。
つまり、起動数を抑制するために worker1つに収めて、全てそのworker内で完結する方がコスト的に大変望ましい、ということになります。
費用比較時の留意点
6月に入ってscheduler の起動数は安定しました。（試行錯誤が終わりました。）
ですので、 schedulerの費用とworker移行後のコスト比較は6月で見るのが正しいです。（5月は参考程度）
スケジューラーを止めて移行した worker 2 では、それまでの処理内容は変えていません。同じ処理の起動方法が変わっただけです。（起動方法は１つのrake taskから呼び出すように変えています）
6月15日でdyno数が2になっている通り、プログラム以外の対処により起動数が減っています。厳密には 2 -> 1 に減ったことになります。
ただし、 worker に移行したことで、 14日以前の状態に戻しても 1 のままで済むと思われます（ここは推測）。そう考えると 6 -> 1 の削減です。
以上、heroku scheduler の料金について調べた時にはここまで分からなかったことと、安易に scheduler を立ち上げてしまうとこうなる事例、、ということで共有させていただきます。