はじめに
こんにちは。TIG（Technology Innovation Group）の本田です。
フューチャー社内の有志メンバーでバッチ設計ガイドラインを作成し、公開しました。
本記事ではガイドラインの作成の経緯や想いなどを簡単に紹介します。
本ガイドラインの対象読者
本ガイドラインは、以下のような方を主な読者として想定しています。
- バッチ開発を行う初学者
- バッチ処理を含むシステム設計を行う人
- 自身のメイン領域はバッチ処理ではないがバッチ処理設計の勘所を知っておきたい人
特に初学者の方はジョブ設計の章だけでも読んでいただくことをオススメします。バッチ処理のプログラムを実装する上で留意するべき冪等性や性能といったポイントが紹介されています。
本ガイドラインの作成経緯
フューチャーでは様々な規模のシステムを構築しており、その中には多種多様なバッチ処理も含まれます。
cronのようなシンプルなスケジューラから特定の機能を定期的に呼び出すようなシンプルなものから、JP1やAirflowのようなワークフローエンジンを利用して複数の機能を制御するもの、ワークフローエンジンを自作するものまで要件に応じて実現方法は異なります。
ひとくちに「バッチ処理」と言っても、オンライン処理との使い分け、ワークフローエンジンの利用有無、同期/非同期の設計など、考慮すべきことは多岐にわたります。
こうした設計上の悩みどころに対して設計案の提示やレビュー観点のベースラインを提供することで、現場エンジニアをサポートしたい。そんな想いから、本ガイドラインは作成されました。
前提事項
本ガイドラインではバッチ処理を大量のデータを一括で処理するための手法と定義しています。バッチ処理と関連性が高いジョブスケジューラについても内容に含んでいます。
Web API設計ガイドライン、I/F設計ガイドラインといった他ガイドラインでカバーされる内容は対象外としています。
主にAWS、Google Cloud、Azureなどのクラウドサービスを用いた開発を想定しており、ガイドライン内の例としてはAWSのサービスを取り上げることが多いです。
内容紹介
ガイドラインに興味を持っていただくために一部内容を紹介します。
ワークフローエンジンの選定（AWS）
ワークフローエンジンに求められる要件を整理した上で、AWSでよく用いられるStep FunctionsとAirflowを例に挙げて製品比較を行なっています。
バッチの実行モデル
AWSでの構築を例に挙げ、バッチ処理をECSタスク、Lambda、常駐のWeb APIサーバ上で起動する場合の比較を行なっています。
オンライン処理との排他制御
ユーザーが画面を操作している裏でバッチを動かしたいといったケースで問題となる排他制御について、「バッチを常に優先する」「競合時はスキップする」といったパターンを解説しています。
業務日付の管理
夜間バッチなど、暦日とシステムの扱う日付が異なる場合に重要となる「業務日付」の考え方について解説しています。「オンラインとバッチで分離する」といった基本的なパターンから、「機能グループごとに日付を分離する」「タイムゾーン毎に分離するパターン」といった応用的なパターンまで解説しています。
ジョブ設計のポイント
冪等性の担保、性能を意識した実装（バルクインサート、並列化）、省メモリ設計など、個々のバッチプログラムを実装する上での具体的なベストプラクティスを紹介しています。
まとめ
今回公開したバッチ設計ガイドラインが、皆さまのプロジェクトにおける設計のベースラインや議論のたたき台として、少しでもお役に立てれば作成者の一人として嬉しい限りです。
本ガイドラインは初版の公開後も社内外のフィードバックを受けて少しずつアップデートされています。
内容に関するご意見やGitHub上でのPRもお待ちしています！