データ集約型アプリケーションの設計 (Japanese Edition), 2nd Edition

第11章 バッチ 処理

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

システムは、一人の人物の影響が強すぎると成功しない。初期設計が完了し、ある程度堅牢性が確保されたら、 様々な視点を持つ人々が独自の実験を始める段階で、真のテストが始まるのだ。

ドナルド・クヌース『TeXのエラー』（1989年）

これまで本書では、リクエストや クエリ、それに応じたレスポンスや 結果について多く述べてきた。このデータ処理スタイルは、多くの現代のデータシステムで前提とされている。つまり、何かを要求したり指示を送ったりすると、システムは可能な限り迅速に答えを返そうとするのだ。

ウェブブラウザがWebページを要求するとき、サービス呼び出しでリモートAPIを呼び出すとき、データベース、キャッシュ、検索インデックス、その他多くのシステムがこのように動作する。これらをオンラインシステムと呼ぶ。応答時間は通常、その性能評価の主要な指標であり、高可用性を確保するために耐障害性が求められることが多い。

しかし、インタラクティブなリクエストでは処理しきれない大規模な計算や大量データの処理が必要な場合もある。AIモデルのトレーニング、大量データの形式変換、大規模データセットの分析計算などがそれだ。こうしたタスクをバッチ処理ジョブと呼び、これを扱うシステムはオフラインシステムと呼ばれることもある。

バッチ処理ジョブは入力データ（読み取り専用）を受け取り、出力データ（ジョブ実行の度に新規生成される）を生成する。通常、読み書きトランザクションのようにデータを変更することはない。したがって出力は入力から導出される（「記録システムと派生データ」で説明した通り）。 出力結果が気に入らなければ、それを削除し、 ジョブのロジックを調整して、再度ジョブを実行できる。

入力を不変性で扱い、外部データベースへの書き込みなどの副作用を避けることで、バッチジョブは優れたパフォーマンスと以下の利点を実現する：

• コードにバグが混入して出力が間違ったり破損したりした場合、単に以前のバージョンのコードにロールバックしてジョブを再実行すれば、出力は再び正しくなる。あるいは、もっと簡単に、古い出力を別のディレクトリに保存しておき、そちらに切り替えることもできる。 ほとんどのオブジェクトストアやオープンテーブル形式（「クラウドデータウェアハウス」参照）は、 この機能を「タイムトラベル」と呼んでサポートしている。読み書きトランザクションを持つほとんどのデータベースにはこの特性がない： バグのあるコードをデプロイしてデータベースに不正なデータを書き込んだ場合、コードをロールバックしてもそのデータは修正されない。バグのあるコードから回復できるという考え方は、人間のフォールトトレランスと呼ばれてきた[1]。

• このロールバックの容易さゆえに、機能開発はミスが取り返しのつかない損害を意味する環境よりも迅速に進められる。この不可逆性を最小化する原則はAgileソフトウェア開発に有益である[2]。

• 同一のファイルセットを、様々な種類のジョブ入力として利用できる。これには監視ジョブも含まれ、 監視ジョブはメトリックを計算し、ジョブ出力が期待される特性を持つかどうかを評価する（例えば、 前回の実行結果と比較し差異を測定することで）。

• バッチ処理フレームワークはコンピューティングリソースを効率的に使用する。OLTPデータベースやアプリケーションサーバなどのオンラインデータシステムを介してデータをバッチ処理することは可能だが、必要なリソースの観点でははるかにコストがかかる場合がある。 ...