夜間バッチという見えない労働
要点
- 夜間バッチは、日中の負荷を避けて重い処理をまとめて走らせる古典的な手法で、いまも金融や物流の基盤を支えている。
- Googleはこうした繰り返し作業を「トイル（toil）」と呼び、自動化すべき対象として定義した。
- ただしバッチを廃してリアルタイム化すれば良いとは限らず、まとめて処理する効率には固有の合理性がある。
- 見えない労働ほど、止まったときの影響範囲を事前に把握しておく価値が高い。
午前2時、オフィスに人はいない。だが計算機は最も忙しい時間帯を迎えている。日中に蓄積された取引や注文を、夜のあいだにまとめて集計し、翌朝の数字をつくる。この「夜間バッチ」と呼ばれる処理は、デジタル化が進んだいまもなお、銀行の勘定系や物流の在庫管理を静かに動かしている。表に出ないが、止まれば翌朝の業務が止まる種類の労働だ。
なぜ夜にまとめるのか
バッチ処理の発想は単純である。一件ずつ即座に処理するより、ある程度ためてから一括で処理したほうが、計算機資源を効率よく使える場面が多い。日中はオンライン取引にCPUとデータベースを譲り、利用の少ない夜間に重い集計を回す。この時間的なすみ分けが、限られた資源を分け合う現実的な解だった。いまでも「日締め」「月締め」という言葉に、その名残がある。
もっとも、効率の裏には硬さがある。夜間バッチは決まった時刻に、決まった順序で走ることを前提に組まれる。前段の処理が遅れると後段がずれ込み、朝までに終わらなければ業務開始に間に合わない。処理時間のばらつきが、そのまま朝の遅延に直結する構造である。
「トイル」という命名
Googleが公開した『Site Reliability Engineering』は、こうした繰り返しの運用作業を「トイル」と名づけた。手作業で、繰り返し可能で、自動化できるのに人が担い続けている作業——それがトイルである。同書の主張は明快だ。トイルは価値を生まないわけではないが、増え続ければ運用担当者の時間を食いつぶし、改善のための余白を奪う。だから測定し、上限を設け、自動化で削るべき対象として扱う。
夜間バッチの監視は、しばしばこのトイルの典型になる。毎朝、担当者がログを開いて正常終了を確認する。問題がなければ何も起きない。だが「何も起きないことを確認する作業」そのものが、人の時間を静かに消費していく。
リアルタイム化すれば解決か
では、すべてを即時処理に置き換えればバッチの硬さから逃れられるのか。一見もっともらしいが、ここには見落としがある。一件ずつ処理する方式は応答が速い反面、全体を俯瞰した整合性チェックや、大量データの一括突合には向かない。月次の締め処理のように「ある時点でのスナップショットを確定させる」種類の仕事は、まとめて処理する前提があってこそ成立する。
一方で、利用者が結果を待てない領域——たとえば残高の即時反映——では即時処理が要る。現実の設計は、即時に返す層とまとめて確定させる層を分け、両者を整合させる方向へ進んでいる。これは結果整合性の議論と深く結びつく。バッチかリアルタイムかではなく、どこを即時にし、どこを夜に回すかという配分の問題だ。
見えない労働を見えるようにする
夜間バッチが厄介なのは、平時にはその存在を誰も意識しない点にある。十年前に書かれた処理が、担当者が代替わりしても走り続け、なぜその順序なのかを説明できる人がいなくなる。属人性が抜けたのではなく、属人性ごと背景に沈んでいる。
自動化が進むほど、人の仕事は実行から監視と理解へ移る。夜のあいだ静かに動く処理に対して、止まったとき何が止まるのかを言語化しておくこと。見えない労働を完全に消すことはできないとしても、見えるようにしておくことはできる。バッチが古いか新しいかではなく、その振る舞いを誰かが説明できる状態にあるかどうかが、運用の健全さを分けている。
出典
- Google『Site Reliability Engineering』（トイルの定義と運用負荷の議論）
- 同書におけるバッチ処理・運用自動化に関する章