先日、コマーシャルペーパーディーリングサービスというサービス開始についてお話を伺ってきた。コンピュータネタ、目次へ
ようするに株式のホームトレードを借用証書でもやろうというアイディアである。専用線でもサービスを行うらしいが、目玉はやはりインターネット。本気か？
黙っていては私らしくない。非常に回りくどい言い回しの質問をした。「回線などの障害で、取引ができなかった場合の免責事項について、専用線を経由した場合と、インターネットを経由した場合では差があるのでしょうか。」回答は「バックアップもあるし、オフサイトもあるのでダウンすることはない。だからこちらに責任が生ずることはない。」凄い自信だ。ベンチャーキャピタルからよくぞそれだけの資金を集めることができたと感心しているのではない。いや、やっぱり感心するな。バックアップもあるということは同じ建物の中にサーバーが２台。オフサイトがあるということは、別の建物にサーバーが少なくとも１台。これが信頼性抜群の大型汎用機ならよくぞ資金を集めた。しかし、クライアントソフトはＪａｖａだったなあ。
個人のゲーム用プラットフォームとして誕生したＵＮＩＸは、その生い立ち忘れさせるほどの発展を遂げ、耐障害性を高めてきたというのは認める。２台のマシンを立ち上げておいて、通常はそのうちの一台が動作しているが、その場合でも相互に相手の状態を監視し、何かあればＩＰアドレスと、共有されたディスク内のデータを引き継ぎ、バックアップ機が立ち上がるといった仕組みはよくぞまあ作ったと感心する。だからといって「落ちない」というわけではない。
とりわけインターネットにつながっている場合はいろいろと落とし方が定型化されている。私なら「しまった！売りそこなった」と気が付いたら、そのサイトを攻撃して落とし「お宅のサイトが落ちていたから売るに売れなかった」と文句を言うくらいのことは考える。なかでも良くわからないのはDDoS攻撃という奴である。これって「大量のパケットをターゲットのサイトに送りつけて他のサービスを受け付けられなくする」とか説明されるけどほんとかなあ。そのサイトはインターネットと接続している専用線の回線容量以上にパケットを受け付けられないはずですよ。その容量分のパケットがくるとサイトがダウンするというのなら、それはシステム管理者の回線容量の見積もりがおかしいのですよ。実際に攻撃を受けたCNET、ZDNet、CNNといった有名サイトの管理者がみんなそんな感じであれば逆にそっちのほうが怖いです。とはいえ私もオフサイトが必要となった実例は一つしか聞いておりません。ニューヨーク世界貿易センタービルが爆破されたときです。特に問題はなかったようですが(^^;、強制退去命令が出たときに手動でオフサイト切り替えするのを忘れていたら大変なことになっていたという話を聞きました。無人のビル内でコンピュータがひたすら注文データを受け付けている。でも、こちらからは何もできない。もしそういう場合になったときのために、（去年はやった）コンテンジェンシープランの作成者は対策をマニュアル化しておいてください。自分の使用しているフロアを放棄しなくてはならない場合ではあるが、コンピュータも自社フロアも傷ついていないわけですから、ついつい忘れてしまうかもしれません。万が一忘れてしまった場合は、ゴルゴ１３に頼んでコンピュータにつながっている回線を銃弾で切断してもらうというのをお勧めします。でもマニュアルには書けないよね。もしゴルゴ１３への連絡方法をマニュアルに書くと逆に命を狙われるかもしれません。
オフサイトのデータがどの程度信用できるかも疑問です。データベースレプリケーション？どの時点までレプリケーションで同期が取れているかを任意の時点で保証してくれるならそれでもいいです。できないでしょう。
そんなものだから、逆にオフサイトのデータベースをチェックして、どこまでレプリケーションが終わっているか確認しなければなりません。ダンプを取ってユーザーに渡しますか？ダンプの中身は「正規化」ということでユーザーの入力データを切り裂いたものになっているでしょう。それとも、データベースから入力データを再作成するプログラムを組んでおきますか？いずれにしてもユーザーは確認のために常日頃から入力内容をメモしておかねばなりませんが。それとも、ユーザーのところに検証用プログラムを作っておいておきますかねえ。で、本システムと検証用システムに二重入力するの。ストレートスループロセッシングの発想には思い切り逆行しますが、やっておかねばならないのはこういうことです。でもそれだったらオンサイトの端末とオフサイトの端末を並べてユーザーフロアにおき二重入力したほうがいいですね。もちろんそれをするくらいなら、端末が（というかフロントエンドが）オンサイトとオフサイト双方にデータを投げて同期を取って更新してくれるほうがましであります。つまり同一のシステムが二つ走っているわけです。これならシステムのデータ整合性はとれる。双方のサイトにデータが飛ぶので回線への負担は倍になるけども、むしろレプリケーションより回線への負担は少ないんじゃないかなあ。
でも、そんなアーキテクチャーは聞いたことがない。なぜできないか分かりますか？知っていたら教えてください。あ、オラクルのライセンス料の問題というのは私も気がついてますから。（オラクルは、バックアップ用システムであればライセンス料を値引きしてくれる。しかし、オンサイト、オフサイトとも同一アプリケーションで更新する場合は、値引きしてくれないかもしれない。）
調べましたところホットバックアップ、つまり《通常でも、バックアップシステム上のOracleは活動状態にあり、バックアップデータベースと本番データベースの整合性は常に保たれているが、オンラインによるクライアントからのアクセスはない場合を指します》の場合、オラクルはライセンス料および保守料を１／４にまけてくれるそうです。上の文には私のレプリケーションに対する厳しい見方を反映しています。昔、レプリケーションができるどうかを大データベース専業会社に質問して、「できない」と言われたことを根に持っているのです。９３年でしたかね。
当時、私は海外拠点の情報を一元管理するデータベースのお守りをしていました。データベースエンジンはＤＢ２。結構な腕でしたよ。製造元の日本法人よりもよく分かっていた（部分もある）と強弁できます。そのころ、各海外拠点でも情報システムを入れようという話が持ち上がりました。そのとき思いつきました。だったら国内と海外のデータベース設計を共通にして、同期をとって更新すればいいじゃないか。
更新データの到着管理と、更新時間の長さに閉口していた私はもう一歩踏み込んで考えました。海外拠点でできたフォーワードリカバリー用のログ（ジャーナルファイル）を送ってもらって、国内ではそれを使ってフォーワードリカバリーをかければ速いし、更新プログラムを作らなくて済むぞう。
そんなわけで、海外拠点が使うというデータベースの日本法人に電話をかけたのです。そんなことできるか？その会社の名誉のために言っておきますが、電話にでてきた担当者はとても丁寧に答えてくれました。ジャーナルファイルは同期点を時刻で持っているので、そこを書き換えない限り無理なんだそうです。
オラクルとサイベースがデータベースレプリケーションを発表したのは、それから一年もたたないころでした。サイベースはレプリケーション先のデータベースが止まっていても何とかしてくれるようでしたが、オラクルは動いていないと駄目だという話でした。なんとなく、なるほどね、と納得したのを覚えています。そんなわけで、データベースレプリケーションに対しては複雑な気持ちを持っているのですが（即座に立ち上げることができないオフサイトなら、日中回線料払ってレプリケーション電文飛ばすより、夜間バックアップテープを転送した方が単純だろう、とか）その分人の考えつかない使い方を発案するものです。
おととし考えたのはこんな感じです。サーバー１台、クライアント数台という小さなシステムでした。クライアントで照会をする度にサーバーにいちいちアクセスにゆくというとてもわかりやすいアーキテクチャーのものを作っていました。で、クライアントプログラムのテストまでは、ローカルに同じアーキテクチャーのＤＢＭＳを入れてスタンドアロンでやっていたそうです。だったら・・・。
クライアントのプログラムはそのままでサーバー上のデータベースをマスターにして、クライアント側のローカルデータベースについてレプリケーションで同期をとる。サーバーがダウンしたときは、マスターを特定の１台のクライアントのローカルデータベースをマスターに切り替えて他のクライアントはそれからレプリケーションをかける。
だったら、サーバーでバッチしているときもクライアントだけで照会できるぞ。ユーザーがオンライン延長を言ってきても対応できるし。バックアップサーバーの価格けちれるし。
こんな使い方できないかと、もちろんメールしましたが、マスターを動的に変更するのは無理みたいです。でも、そろそろ製品化されませんかねえ。