【ITニュース解説】How I side-stepped a 5-year migration with 40 lines of C and a Unix daemon trick.

今回の記事は、銀行の基幹システムを巡る興味深い技術的な挑戦と、それを少ない労力で解決した画期的なアプローチについて解説している。システムエンジニアを目指す皆さんにとって、既存の巨大なシステム（レガシーシステム）と最新技術をいかに結びつけるかという、実践的な視点が得られる内容だ。

まず、問題の背景から説明しよう。ある銀行の重要な送金処理は、COBOLという歴史の長いプログラミング言語で書かれた「バッチジョブ」として運用されている。バッチジョブとは、特定の時間にまとめて多くの処理を実行するプログラムのことで、記事では毎晩2時に起動し、メインフレーム上のファイルを読み込み、CICS（オンラインでのトランザクションを管理するシステム）を介して処理を行い、最終的にレポートを印刷していると書かれている。このCOBOLのシステムは長年にわたり銀行の中核業務を支えてきたものだが、現代のデジタル化の波によって新たな要件が生まれた。それは、この送金処理を外部から必要なときにいつでも呼び出せる「REST API」として提供することだ。REST APIは、ウェブサービス間で情報をやり取りするための現代的な標準的な方法である。

しかし、この新しい要要件を実現するにあたり、非常に厳しい制約があった。システムを一時的にも停止させることなく（ゼロ障害）、既存のCOBOLプログラムやその実行方法（JCLというメインフレームのジョブ制御言語）を一切変更せず（ゼロJCL変更）、さらには追加の予算もほとんどない（ゼロ予算）というものだった。これは、多くの企業が古いシステムを使い続けながら新しいサービスを開発する際に直面する典型的な課題である。

この困難な課題を解決するために著者が用いたのが、「Unixデーモン」という技術と、わずか40行のC言語コードだった。まず、Unixデーモンについて解説する。皆さんが普段コンピュータでプログラムを起動する際、コマンドライン（ターミナル）から実行すると、そのプログラムはターミナルという「親」のプロセスから起動された「子」のプロセスとして動作する。そのため、ターミナルを閉じると、多くの場合、その子プロセスも一緒に終了してしまう。これでは、銀行のサービスのように、常にバックグラウンドで稼働し続ける必要があるプログラムとしては不都合だ。

そこで「デーモン」の出番だ。デーモンとは、オペレーティングシステム（OS）上でバックグラウンドで動作し続けるプログラムのことである。ユーザーの操作やターミナルとは独立して動作するため、コンピュータが起動している間中、特定の処理を監視したり、サービスを提供したりできる。記事では、このデーモン化を実現するために「ダブルフォーク」というテクニックが使われている。これは、プログラムが自分自身をコピーする（フォークする）処理を2回繰り返すことで、親プロセスであるターミナルとの関係を完全に断ち切り、OSから直接管理される独立したプロセスとして動作させる方法だ。これにより、ターミナルを閉じたり、開発者がログアウトしたりしても、サービスが停止することなく永続的に稼働し続けることが可能になる。

次に、このデーモンの仕組みを応用して、COBOLのバッチジョブをREST APIから呼び出すための「橋渡し」の仕組みが構築された。著者は、既存のCOBOLコードやJCLを一切変更せずに、メインフレーム上のジョブを外部から実行する方法を探した。そこで見つけたのが、tsocmdというメインフレームのコマンドだ。これは、メインフレームの環境でコマンドを実行するためのもので、この記事ではsubmitコマンドを使って既存のJCLファイルを指定し、バッチジョブを起動している。

このtsocmdコマンドをC言語のプログラムから呼び出すために、popenという関数が利用された。popenは、C言語のプログラムの中から外部コマンドを実行し、そのコマンドの出力結果をC言語のプログラムで読み取ることができる便利な機能だ。これにより、たった40行のC言語コードで、外部からの指示を受け取ってメインフレームのCOBOLジョブを起動し、その結果を受け取る「ブリッジ」（橋渡し役）が完成した。このC言語のコードはlibpolycall-cobol.soというライブラリとしてコンパイルされ、システムに配置された。これは、メインフレームのコードに手を加えることなく、外部からメインフレームの機能を利用するための「外部関数インターフェース（FFI）」とも言える。

さらに、このC言語で書かれたブリッジは、Go、Python、Java、Node.jsなど、さまざまなプログラミング言語から利用できるように「ワン・メイクファイル」という統一されたビルドシステムでまとめられた。これにより、どの言語を使っている開発者でも、このCOBOLジョブを呼び出す機能を手軽に利用できるようになった。複数の言語に対応できることを「ポリグロット」と呼ぶ。

実際にデモンストレーションでは、ウェブブラウザからJCLファイルをドラッグ＆ドロップし、「Submit」ボタンをクリックするだけで、メインフレーム上のCOBOLプロダクションジョブが起動し、そのログ（JESMSGLG）がリアルタイムでブラウザに表示された。これは、既存のメインフレームシステムに一切変更を加えていないにもかかわらず、最新のウェブインターフェースから銀行の重要な処理を操作できるようになったことを意味する。上司が驚き、沈黙したという逸話は、このアプローチの革新性を物語っている。

この解決策の重要な点は、従来の「モダナイゼーション」と呼ばれる大規模なシステム改修とは一線を画していることだ。通常、古いシステムを最新の技術に置き換えるには、何年もかけて数百万ドルという巨額の費用を投じ、最終的にシステム停止のリスクを伴うことが珍しくない。しかし、このアプローチは既存のCOBOLシステムを「サイドカー」、つまり既存システムに寄り添う形で新しい機能を追加している。これにより、レガシーシステムはそのまま稼働し続け、新しい機能はGoやReactといった最新の技術で開発・提供できる。万が一問題が発生しても、新しい部分だけを停止すればよく、システム全体への影響が最小限に抑えられる。そして、デーモン化されているため、一度起動すれば、開発者が席を離れたり、SSHセッションが切断されたりしても、サービスは停止することなく安定して稼働し続ける。

この事例は、システムエンジニアにとって、既存のシステムを深く理解し、その制約の中でいかにクリエイティブな解決策を見つけるかが重要であるという教訓を与えている。古くからあるUnixの基本的な仕組みであるデーモン化を理解し、それを応用することで、大規模なシステムの課題を、わずかなコードと費用で解決できる可能性を示している。将来的に、この「libpolycall」という仕組みは、GraphQLといったより現代的なAPIの形式で提供されるようになり、古いメインフレームのシステムがまるでクラウド上のサーバーレス機能のように手軽に扱える未来が展望されている。これは、現代のシステムエンジニアが学ぶべき、レガシーシステムとの共存と発展の素晴らしい例と言えるだろう。