MS-Accessとの戦い (接触編)
どこから書き始めたらいいのか分からない。いずれにしてもこの戦いはおよそ23年前にはじまり今まだ続いている。
私は新卒の会社を3年で辞めて初めて転職した。商用インターネットサービスが解禁され、まさに雨後の筍のように ISP が出てきたこのブームに乗っかるべしと、当時個人向けにサービスを始めたばかりの Dream Train Internet に転職したのは 1996年7月、25歳だった。
前職では主に SunOS や Solaris を使っていたので、当初私は技術部のサーバーチームに配属された。技術部はネットワークチームとサーバーチームに分かれており、簡単に言えば router や switch や access server (dial-up user を集約する Ascend MAX のような)以外全てをサーバーチームが受け持っていた。実際サーバー類はほとんどが Sun の Solaris だったのでそこは問題なかった。ただ残り全てということでどういうわけか「課金」を処理するサーバーもなぜか我々の管理範囲に入っていた。
当初課金を担当していたのは、三菱電機の関連会社から出向で来ていた (DTI は三菱電機の子会社だった) Aさんで仕事上は当初ほとんど関わりがなかった。ところが入社して1ヶ月くらいしたある日、社長が私のところにやってきて「高田君、今度 (課金を担当していた) A君が出向元に帰ることになったから課金処理のところ高田君が引き継いでくれ、よろしく」と言ってそのまま去っていき、結果突然その業務を引き継ぐことになってしまった。
出向元に帰るまで1ヶ月くらいしか無いということで、慌てて引き継ぎを行った。しかしそこで目撃したのは、Aさんがかなりの部分を手作業で MS-Accessを使って課金処理を行なっていたという衝撃の事実だ！
当時の DTI の課金体系というのはどうなっていたかと言うと、基本料金 1,500円 + 従量課金最大 2,000円。従量部分は分単位の接続時間で計算され 2,000円を超える部分はそれ以上課金されない。当時個人向けの ISPでそのような大胆な plan を出しているところはあまりなく、当時のヘビーユーザーには人気を得ていた。
ユーザーが1万人いれば平均 2,000円課金したとしても、一ヶ月で 2,000万円くらいの売り上げになる。そんな課金処理の部分はどうだったかというと結果的に MS-Accessで処理しているという始末。なぜそのようになっていたかと言うと、その後わかったことを時系列的に書くと：
- ISPを始めるにあたり当時 Santa Clara にあった AIMnet という会社にコンサルを頼んでいた。
- AIMnet は USですでに ISP 運用の実績があり、従量課金と課金のシステムを持っており、それも合わせて DTI が購入した。
- 課金処理システムは Oracleと integrateされたもので、ユーザーの顧客データベースとも一緒になっており。そこからカード請求などもできるはずだった。
- ところが RADIUS (ユーザが access pointから dial-up accessする時に認証を行うサーバー)が生成したログを Oracleに入れるところがうまくいってない、そもそもログの処理もうまくいってなかった。
- そもそも AIMnet は個人向けでもそんなに大きな会社ではなく DTI は当時毎月 10,000人会員が増えていたような ISPだ。そもそもシステムがそこまで scaleしなかった。
- 結局当初 4月に有料サービスを始める予定だったが、課金処理がうまくいかないために有料サービスを始めるのを 3ヶ月遅らせた (ユーザーにはサービス期間とアナウンスしていた)。
- Oracle からカード課金が処理できるようなデータを出力することができなかったので、Oracle にある顧客情報 (カード番号や住所、名前など)と、RADIUS の logから計算した使用料と課金体系に従ったその月のユーザー毎の料金。それらを合わせて MS-Access を使って処理していた。
- なぜ MS-Access なのか？それは担当していた Aさんが MS-Access しか知らなかったから。
普通に考えたら Oracle にデータ入ってんだから Oracleで処理すればいいんじゃないかと思うが、とにかく担当していた Aさんが MS-Access を得意だったので仕方がない。そのやり方を一通り step by step で教わった。
当時私は SQL やデータベースを使った開発を全く知らない若造だったし、MS-Access はおろか Windows の開発環境もよく知らなかった。それでも、すでにやっているプロセスを変えるのはリスクが高いと思ってそのままやることにした。
Aさんが出向元に帰ってから最初の課金処理の月末がやってきた。教わった通りにやってみるも、どうにも分からないことがあったので Aさんに電話した。Aさんは電話に出ると本当に迷惑そうな感じでもうこっちの仕事には関わりたくないようだった。正直その態度には腹が立った、しかし今考えてみればすでにそこの仕事を辞めてしまった人に何かを聞くのはそもそも間違いだったと思う。それでも聞きたいことは聞いてなんとか課金処理を終えた。といっても全ての処理に丸々 3日はかかった。
徹夜につぐ徹夜で心身ともに疲れ切っていたが、そうこうしているうちに毎月課金処理はやってくる。処理に時間がかかっているのはユーザー数に比例しているので毎月 10,000人ユーザーが増えているとどう考えてもスケールしない。このままでは体がもたないと思い、どうにも納得いかない MS-Access による処理を抹殺することを決意した。そもそも、課金の元になる顧客情報と使用量などの input はそこにあり、最終的にカード会社向けの CSVファイルを出すだけなら、途中にそんな難しいデータベースなんて必要ないんじゃないか？
まず最初に、RADIUS の log を処理する部分は月末にやるのではなく、１日一回 log を rotate するtiming でやればいいんじゃないか、その計算結果はユーザー単位でどっかに保存しておけばいいだろう。なんらかの SQLデータベースを使った方がいいとは思ったが、当時はまだ MySQL は存在せず (mSQL はあったが、今ひとつピンと来なかった) 他のデータベースソフトウェアを動かす overhead が面倒だったので、どうせ大したデータを保存するわけじゃないからと Berkeley DBに単純に User ID を key にして、いろんなデータを保存した。使用言語は当然 Perl。少なくともこれで RADIUS の log 処理に何日もかかるようなことは無くなった。
次に、Oracle から顧客情報をとってくるところ。実はこの顧客データベースも単純に Oracle とintegrate されてるわけではなく Remedy 社の Action Request Systemという middleware が間に挟まっていて基本的にそれ経由でのアクセスをしないといろいろ辻褄が合わない。探してみたら幸い ARSPerl という Perl module があったのでそれを使ってユーザー情報をデータベースから引っ張ってくることができるようになった。
これら2つが動けばあとはユーザー単位で課金額を計算して、CSV を生成するだけ。使い物にならない Oracle と MS-Access を抹殺して課金処理パイプラインを作ることに成功した。
余談だが、カード課金で DTI が直接カード会社にデータを送っていたわけではなく、途中に 3rd party の broker のような会社がいて、そこに一旦データを渡してカード会社用のデータを作ってもらっていた。カード課金用の CSV には住所や名前などのフィールドもあり、データベースには SJIS で保存されていたために SJIS の CSV で渡していたが、その 3rd partyの会社はカード会社にデータを渡す前に日本語コードを SJIS からメインフレームで使える日本語コード EBCDIC に変えるという話だった。EBCDIC という日本語コードの存在をその時初めて知った。
ことの顛末はだいたいこんな感じだった。しかし当時 DTI のサーバーチームにはプログラムを書けるまともな人がほとんどおらず (むしろネットワークチームの方には何人かいた) 控えめに言っても俺がエースのような働きだったと思う。今の実力を 10としたら当時は 1ぐらいだったと思うが、それにしてもだ。今考えるととんでもないが、サーバーの設定やモニターなんかもほとんどが手作業で何かを自動化しようとか合理化しようとか自分でコードを書かない限り良くならなかった。周りでそこまでコードを書いている人もいなかった。
かくして DTI から MS-Access は抹殺されたが、世の中にはまだまだ MS-Access がはびこっている。戦いはさらに続く。（発動編へ）
