デジタル庁クラウドチームの推すメッセージキュー（バッチ処理のイベントドリブン化）が有用になる場面

デジタル庁テックブログの「ガバメントクラウドにおけるモダン化の意味と定義」の説明がよろしくないので「それ何の役に立つの？」と言う反応が出てしまっているメッセージキュー（バッチ処理のイベントドリブン化）なのだが、困ったときに上手く使うと便利なので紹介しておきたい。

業務システムは、ウェブアプリなどのオンライントランザクション処理（OLTP）と、バッチ処理に大きく分かれる。OLTPでは入力してから3秒反応ないと利用者が困惑する（あばれだす）と言われ、30秒から60秒以内で処理を完了しないと、だいたいのミドルウェアの標準設定でリクエスト・タイム・アウトになってしまう。一方、バッチ処理は原則として時間制限がない。

困ったときと言うのは、OLTP、つまりウェブアプリで長時間処理を走らせたいときだ。メール配信、機械学習/統計解析、プリントサービス、配信コンテンツの置き換えなど色々とありえる。メッセージキューを使うとOLTPからバッチ処理を呼び出し、OLTPと長時間処理を非同期にすることができるので、時間制限の問題を解決できる。

また、タスクの管理/直列化/分散化も容易に実現できる。つまり、

• キューにたまったタスクを監視
• 複数のユーザーが十分な時間差なく同一の長時間処理を呼び出すような状況で、片方をキャンセル
• ウェブサーバーとバッチ処理サーバーを異なるハードウェアに
• 複数のウェブサーバーで受け付けた命令を直列化した上で、同一のサーバーでバッチ処理
• 大量に命令を、複数のサーバーに分散化してバッチ処理

することができる。並列化して時間制限をなくすことは、泥縄式の曲芸プログラミングでも不可能ではないが、柔軟なシステム構成をとることができ、タスク監視を充実できることから、メッセージキューを使う方が望ましい。

エンドユーザーから進捗が分からなくなりそうだと言う疑問が出されていたが、データベースなどにフラグを入れておき、polling/long pollingで処理が終わるまで処理開始…処理中…処理中…処理完了と30秒ごとにメッセージを出していくような事も難しくはない。

メッセージキューは1990年代に出てきた種類のミドルウェアだが、2000年代から大規模サイトでよく使われるようになっており、2010年頃からオープンソース製品が拡充してきた。RabbitMQは2007年に開発がはじまっており、Apache Kafkaは2011年にLinkedInで開発がはじまり、Apache Pulsarは米Yahoo!の社内で開発がはじまったものが2016年に公開された。ここ20年間で有用性が確認され、モダンなソリューションとして認識されるようになったと言える。今はホビーユーザーの自宅サーバーでも導入容易だ。

役所での使いどころは分からないが、機械学習/統計解析をシステムに組み込むのに向いている。データが入り次第、もしくは新しい分析モデルが設置され次第、統計解析をやり直せる。データが同時に多数入っても、重複や反復を抑制できる。計算サーバーとオンライン処理サーバーを分けることができるので、業務の邪魔にならない。オンライン処理で使っているプログラミング言語が統計解析に向かなくても、それにあわせる必要がない^*1。

ただし、デジタル庁クラウドチームは夜間バッチが古い方法でメッセージキューがモダンだという主張には疑念がある。メッセージキューで時間起動の夜間バッチを代替できるかは状況による。ノントランザクション処理にしてスループットを稼いでようやく間に合うような場合は、望みは薄い。できても、複雑なシステム構成になる。また、複雑怪奇な夜間バッチは複雑怪奇なイベント処理にかわるだけの可能性が高い。

*1ウェブアプリで使えるプログラミング言語の幅は技術的な理由で狭くなりがちだが、バッチ処理においてはそこまでではないので、利用可能なプログラミング言語の種類を広げることもできる。Rによる統計解析をシステムに組み込むのは無理だと言い出す人もいるが、メッセージキューを使えば問題なくできる。