データベースの同期処理（レプリケーション）に関する昔話

前回、SQLiteでのNULLのソート順について記事にしたところ、データベース熱（？）が再燃したので、今回はレプリケーションを自前で実装するお話

………………をしようと思ったのですが、前提となる昔話を書いていたらえらい長くなってしまったので、ひとまずおっさんの独り言として、この部分だけ先に投稿しておきます。

技術系の話というより懐古系寄りなので注意。

レプリケーションとはなんぞや

レプリケーションは英語だとReplicationと書き、「複製」や「複写」といった意味があります。

つまり、データベースのレプリケーションとはDBを（別サーバー間で）同期／複製すること。

SQLiteで言うならDBファイルをコピーするのと何が違うのか、MySQLやPostgreSQLならDUMPしてインポートするのと何が違うのか。

何も違いませんｗ

…あくまで結果としては。

データベースの同期処理をする目的は様々ですが、具体例を挙げると東京本社にあるDBの社員名簿テーブルを、大阪支社の社員名簿テーブルへ複写したい、といったケース。

は？そんなことせずとも大阪支社でブラウザ開いて東京本社のWebサーバーにアクセスすれば良いんじゃないの？と言われれば全くもってそのとおりとしか言えません。

なにせぼくがデータベースエンジニアとして現役バリバリ（たぶん死語）だったのは20年以上前の話で、当時はVPNもなかったし、本社と支社を結ぶ専用線の回線速度がべらぼうに遅く、64Kbpsとか128Kbpsとか、今の子たちは名称すら知らないであろうISDNくらいの速度しか出ませんでした。

そう、今回はそんな昔の話なのです。

なんでも屋は派遣社員を選ぶ

ちょうどWindows 95が出てインターネットが普及しはじめた1997年頃のこと。

当時ぼくは21～22歳くらいでしたが、働きはじめたのが早く、すでに業歴5年目で各種業務システムの設計／開発もこなし、DOSやNetwareはもちろんのこと、Windows 3.1/95でのプログラミング経験もあり、当時としては比較的新し目なVisual BasicやVisual C++も使え、更にはWinNTのセミナー受講経験があり、Windowsドメインの構築にも詳しい、ということで、ワイルドカードマンとして順調に育っていました。

そのためある意味当然の流れなのですが「炎上しているプロジェクトにほおりこんでおけばそのうち解決してくれるマン」としてあちこちのプロジェクトへたらい回しにされていたのでホトホト疲れ切っていました。

そんな限りなく黒に近い企業を勢いで辞めてしまうのも当然だし、個人的にはよくぞ体がもったものだと感心するくらいです。

とはいえ、働かなければ食べていけません。まずは派遣会社へ登録し、希望条件を聞かれたときに真っ先に口から出たのは「残業ができる限り少ないところ」だったのも致し方ないことでしょう。

派遣会社の営業マンは「？？？」とキョトンとしたお顔。「え、そんなに残業がいやですか？まったく残業したくないの？」みたいな、まるで残業を嫌うダメ人間を見る目でしたが、そこは譲れない。せめて、少しでも印象が良くなるようにと「私は高校中退で学歴がなく、いずれ大検^※を取りたいと思っています。そのための勉強時間が欲しいのです。」などとテキトーなそれらしい理由をつけて、頑なに残業がないところを希望。なにせ前職では毎日残業で終電に間に合わないことすら珍しくなかったのです。

そのような注文を付ける中、派遣会社から紹介されたのは今はなき日本DEC（Digital Equipment Corporation）への派遣でした。

SEとはふしぎな仕事だと知る

募集要項としてはSE（システムエンジニア）だったのですが、その内容を一言で表現するのはなんとも難しいです。SEというより、研究員とか調査員…といった表現のほうがしっくりくるかも知れません。

上司Aが業務システムのおおまかな仕組みを考え、上司Bがお客様にわかりやすい提案書を作成。そしてその提案書を成り立たせるための細かな技術が本当に実現可能かどうかをひとつひとつ調べる役割がぼくのお仕事。調査内容をレポートにして報告するのですが、技術的な部分はサンプルプログラムを作って開発チームへ提供する役目もありました。

21歳くらいのワカゾーが、歴戦のおっさんたちへサンプルプログラム提供して講釈する絵面はなんとも言えないモノがありましたが、上司たちは気にしていない模様。外資系ってホントに実力主義なんだなと感じた瞬間でもあります。

そしてその仕事の中には現在では廃れてしまったRISCコンピューターであるAlpha Serverの導入や、クラスタリング技術、貧弱な回線ごしのNTドメインの運用、そして、DBレプリケーションがありました。

主な環境としてはWindows NT4.0とSQL Server 6.5あたりがメインだったでしょうか。

パソコンの普及と低価格化により、オフコン（汎用機）からパソコンへ、分散コンピューティングという名目でシステム刷新が流行っていた時代でした。ですから、当然のように既存のオフコンが存在し、そのデータをSQL Serverへ移行する作業もありました。

驚いたことにオフコン用のODBCドライバーが存在したのですよ！それまで実際に触ったことはなかったのですが、上司の描いた絵に従って、技術検証する必要があったため、EBCDICなどの文字コード変換もそのときはじめて経験しました。そしてそれらのサンプルプログラムを作成。

そして、話は更に大きくなり、東京本社にあるオフコン→ODBC接続→本社のSQL Serverへ取り込み→レプリケーションで大阪支社のSQL Serverへコピー、とLANからWANへと広がっていきました。

レプリケーションを自分で実装しようと考えたきっかけ

遠隔地のデータ同期なんてフロッピーディスクを郵送することが当たり前だった時代、この計画は画期的といえました。

ところが、実際に調べてみるとSQL Server 6.5のレプリケーション機能は大変にお粗末だったのです。

まず、同期するタイミングがふわっとしていてわからないｗ　なーんかCPUがヒマになったときに同期してるっぽいなぁ、というのはわかるのですが、即座に反映されることもあれば何時間経っても同期されないこともある。挙句の果てに極稀にデータが壊れる。^※

こういうの一番困ります。

上司からはレプリケーションに変わる技術は何かないか、最悪、CSVでエクスポート／インポートする方向で業務設計しなおすけれど、それは本当に最悪なのでできる限りやりたくない、と相談されます。

現在の回線速度ならDBのエクスポート／インポートで済ませてしまうかも知れませんが、当時の回線速度でそれをやったら何時間かかるかわかりません。

更新されたデータだけCSVに出力するようにすれば回線速度の問題も解決するけれど、今度はテーブル設計を変えないといけない。それはつまり、既存の膨大な量の更新プログラムに手を加える必要があり、開発コストが上がることを意味します。

DCOMでのサーバー間通信を提案

解決策としてぼくが上司へ提案したのはDCOMの導入でした。

東京－大阪それぞれにFTPサーバーを導入するのはセキュリティ面で不安。かといってTCP/IPソケットプログラムを1から組むのもしんどい。というか、開発チームはVB専門プログラマーが大半なので、コア部分をVC++でぼくが書くというのは後のメンテナンス性に多大な問題を残すことになる。

しかしCOMサーバーならVBで簡単に作れる。しかもネットワーク越しでも呼び出し可とするDCOM化も設定画面をちょちょいといじるだけ。

更新キューの管理用にWindows Serverに常駐するサービスプログラムを作る必要があって、ここだけはVC++じゃないと作れないけれど、徹底的に簡素化すればほとんどメンテナンスフリーのプログラムになるはず。

ざっくりまとめるとこんな感じ。

• 業務プログラムはVBで開発中であり既に膨大な量のプログラムが完成済
• 開発チームの人数は多いけど、ほとんどがVB専門のプログラマー
• VBではCreateObjectでデータアクセス用のCOMオブジェクトを使いデータ更新している
• なら、そのCOMオブジェクトと同名のCOMオブジェクトをVBで作り、SQL文をぶっこ抜こう
• ぶっこ抜いたSQL文はまずは本来の（元の）COMオブジェクトにそのまま渡す
• その後、キュー用のテーブルにSQL文を一時保管
• COMオブジェクトとは別に作ったWindowsサービスで一定時間ごとにキュー用のテーブルからSQL文をひろって、大阪側のDCOMサーバーへ送信

というのがおおまかな流れ。

この自前のCOMオブジェクトとWindowsサービスを開発チームへ提供したところ大好評でした。なにしろCOMなので既存の更新プログラムに手を加える必要が全くといって良いほどなく、膨大な修正が必要なのではないかと身構えていた開発チームはホっと一安心。

また、渡されたSQL文はそのままODBCドライバーへ渡しているから動作は変わらないし、キュー用にいったん保存するだけで戻ってくるのでパフォーマンスにもほとんど影響しない。

更にはキューを読むタイミングは自前で作ったWindowsサービスで調整可能なので、想像よりもかなりリアルタイムに近い同期処理が可能となったわけです。

まとめ

正直思い出補正も多分にあるかと思いますがｗ　当時のお仕事はほんっとーに楽しかったなぁー。

死んだ目で仕様書どおりにコーディングするような作業はしなくて良いし、要件定義は上司がやるし、ぼくは大好きな新しい技術を学んで、要所要所のサンプルプログラムだけ書いて開発チームへ提供するだけで喜ばれる。

自分の席がない（派遣社員だったので）以外はまったくもって不満のない楽しいお仕事でございました。

その後、ここで培ったクラスタリング技術の知識を買われて、別の会社へ引き抜かれるのですが、これについては本当に関係ないのでまた何かの機会があれば。

ちなみに引き抜かれて5年後くらいだったか、久しぶりに当時の技術者の方と会う機会があり、「貴方が作ったキュー転送プログラム、今も元気に動いていますよ。びっくりするほどメンテナンスフリーです。」なんて言われたときは本当に嬉しかったなぁ。

…と、過去に自前でレプリケーションを実装したときの話を書いて、じゃあ今どきのPHPとSQLiteならどう書けば良いか、という記事にするつもりだったのですが、昔話が楽しすぎて長くなってしまったので、これはまた次回！