この記事は
Develop fun!を体現する Works Human Intelligence Advent Calendar 2020
Develop fun!を体現する Works Human Intelligence #2 Advent Calendar 2020
Works Human Intelligence アドベントカレンダー 12/5 の記事です。
今年も本家 本番環境でやらかしちゃった人は大賑わいですね！ 当記事はワークスHI版やらかしちゃった話のひとつだったりしたりしなかったり（略）ですがさておいて。どうぞ少しだけ、日本の名だたる有名法人をお客様に据える「大手法人向けERP」っぽさを感じていただけたらなと思います。
大手法人向け統合人事システム「COMPANY」の「リモートジョブ」
いわゆる「ERP」パッケージソフト「COMPANY」を開発している我々ですが、オンライン処理・バッチ処理で分けた場合のバッチ処理を行う基盤をおよそ弊プロダクトではそう呼んでいます。まず一般論としてのバッチ処理は バッチ処理について考える がわかりやすいです。今日は我々の若きトラブル談を中心に書きます。
まずざっくりと中身は
- クライアント：フロントエンド
アプリケーションサーバ（以下AP）：フロントエンドからの依頼をどうのこうの処理して画面に即返したり、主に人間の待てる範囲の非同期処理をしたりする。 - キュー管理サービス：アプリケーションサーバの行っていた処理のうち、主に人間が待てない範囲の非同期処理依頼の、順番、実行、実行履歴を管理する。
- Kicker：サービスに依頼された処理を、依頼されたとおりに実行する。
- 業務処理：処理そのもの。従業員を雇用したり、異動させたりからお給料を計算したり明細を発行したり。
という感じ。以上登場人物。
担う業務で分けると
業務と言っていますが「ドメイン」の概念に近いかもしれません。
- 新入社員の個人情報を登録する
- 異動する従業員の属性を変更する
- 入社予定の社員の情報を一括登録する
- 社員の給与計算業務を夜間に行う
- 勤怠時間の計算情報を受けとる
- 計算結果を帳票として他所に送るために出力する
等等々なことをしたい場合に使われるバッチ。調べると1000本以上種類があります。
本題
弊社の旗艦プロダクトCOMPANYは現在Ver.8を絶賛提供中。なのですが時代はVer.5, Ver.6に遡ると20余年をゆうに超えるご長寿プロダクトです。私は2003年新卒で入社したのでそこそこ自らの時代を共にしています。
「リモートジョブ」のトラブルを語りたい
弊社へのお問い合わせトップ5には軽く入ると思われる
- バッチが異常終了する
- バッチが処理中のままいつまでも終わらない
- バッチが処理待ちのままいつまでも始まらない
というのがバッチ3大トラブルです。始まらない&終わらない、アベンドするってまともに動いてないじゃないかと思われそうですがごにょごにょ
シーケンス図
細かく見ていきましょう。おしゃれに描くとこういう感じ。
なのですがちょっと待って下さい
最初の図に少し偽りがあったので訂正します。そうです。キュー管理サービスはAP（アプリケーションサーバ）内のただの1インスタンスだったのです。と思って見るとなんだかいっぱいお仕事名が書いてありますね。
(中略)
うわっ、APの役割多すぎ。。。？
さて何が起こるか見ていきましょう。
異常終了
どストレートに。バッチが異常終了します。図では一番右の線上で起こります。原因はバッチ自身であることが多いと信じて、今回は割愛。
処理中
ぱっと思いつく事案として、ほぼ、業務処理が走ったまま息絶えているケース。
- ファイルが見つからなかった（ファイル転送などなどはうまく行ったはずなのに別の階層を見てるとか
- Exeが見つからなかった（何かの作業中リネームされてたとかいうこともあった
- Javaの実行環境のなにがしかのトラブル。他のアプリ様と同居しているせいでバージョンがよろしくないとか
- 途中でDBやAPに異常が起こって処理は落ちてるがいわゆるKickerさんの方でそれを検知できてない
- 複数ジョブを並列利用する式の処理で親ジョブが子ジョブを蹴ったがそれを見失って親ジョブずっと処理中
等など。例えば処理中になったときでも
- キャンセル
- 一時停止と再開
がせめてできたら怒られないんじゃないかな。（客観視）
処理待ち
もっとも語りたいのがこれ。まずそのジョブがファイル転送を伴うジョブかそうでないかが関わります。ファイル転送を伴い特にファイルを取り込むジョブは
- キューに投入
- ファイルを転送
- ジョブをスタートさせる
3段階で命令を出す必要があるのですが処理待ちはつまり1,あるいは2までの状態。
特に2がコケて開始命令を遅れていないがよくあるパターンです。その場合は各サブシステム担当にもっかい確認をお願いしたりサブシステム側に潔白を主張されたときにはExe名を聞いてDelphi ソース落としてきてはじめましてながらそのサブシステムから読み始めるとかもやります。そこまでやるのが「リモートジョブ担当」、と思うほどまでは責任感はないですがたまにそのくらいしないと判明しないトラブルが起こります。
それでも判明しないことがたまにあってクライアントからFTPつながってますかとかたまにコケるという話のときは酷いとWiresharkとってみてください とか言ったこともある気がします。
だけじゃない。
というかこれも「APでキュー管理サービスが動いている」話の伏線回収！
とりわけAPが複数台ある場合。さあ盛り上がってきそうですね。
APが複数台ある場合でも、キューの制御を行うのはお一つで良いわけなので「主」APを決めないといけません。でもジョブが走り出した後で主が変わってしまったらどうしよう？例えばちょっとした「取込インターフェース」が走りだそうとするまさにそのタイミング別のプロセスがまあ大概かの「帳票出力システム」でExcel形式ででかい帳票を出してしまうなど。
両者は全く別のサブの別のものですがOutOfMemory で主サーバが倒れます→キュー管理サービスが別サーバに移る。実はDBのテーブルでAPの主・副は決まっていたんですが切り替え作動後、発行されたトークン的な情報は代替サーバに引き継がれていない。よって走ろうとしたジョブがバッチサーバ内で「ログイン」できない、というかせっかく発行してもらったトークンの持って行き先がない。。→走り出せず処理待ち
密です
意図しないところがBlockerになるものなのです。冒頭に書いたオンライン処理とバッチ処理、弊プロダクトには「アイコン」ベースでこれも3800を超える数の機能があります。本当はそれぞれがそれぞれ、動けばよいはず。
しかしいわゆる「3層構造」へ変更を行ったのがはや20年近く前。当時の設計資料を紐解くとJavaを書くことが楽しかったようで今でもそんなソースに出会うとコメントに書かれている紆余曲折の端々がルンルンしています。
アプリケーションサーバが複数台あったときにどれがそれを行うか、負荷分散オッケー、クラスタサイコー、という「横つながり」（と表現するのは少し語弊があるかもしれないが）概念ができた一方、バッチ処理とオンライン処理の役割分担の切り離し方。キュー管理システムをAPに置いてしまったため結局バッチがAP無しでは動けなくなったというのが僕たちの過ちです。
例えば人事帳票１つを出力するにExcelフォーマットで全従業員数千人分なんてワンパクをしてしまいうっかりOOMErrorでも起こればバッチも止まる、APごと再起動してくださーいとなる。
そんな本番環境でやらかしちゃった話の種がここにもひとつ...
「というお話だったのサ」
ではなくて、トラブル談だけ書いているとそのうち怒られる心配があるので、以下、それが既にどう解決されているかについて書いておきます。
時は変わりVer.7
あれ？APがいつの間にかいらっしゃらない。そうなんです。やっとここで「キュー管理サービス」はめでたく独り立ちできました。
だいぶスッキリしましたね！キュー管理サービス間は独自にソケット通信を行い起動停止、バッチ実行の交通整理を行います。
Ver.8から、今後
Fargateとかもやってます
各業務がFargate内で独立すれば、より処理中、処理待ちにまつわる懸念点が解消される目論見です。
より独立した未来が見えそうです。ということで安心いただけたらと思います。
バッチサーバーをFargate化しました - Qiita
バッチサーバーFargate化プロジェクトのまとめ - Qiita
参考文献
バッチ処理について考える
Markdownテキストでシーケンス図とフローチャートを描く
Visual Studio Code で UML を描こう！