Infomixの不具合の答えがオラクルのマニュアルに？―手探りの新人時代
亀山さんは1997年入社。最初は主にInfomixを使ったシステムの設計・テストからデータベースに携わった。当時を振り返り、亀山さんは「（技術的なことは）分からずに使っていました」と話す。
新人なら無理もない。しかし体当たりで技術を会得していく。当時β版の段階で不具合や改善要望が850件にも上り、自ら障害管理データベースを構築した。当時は現在ほど開発支援ツールが充実していなかったため、足りないものは作るしかなかったのだ。使ったのはAccessとSQL Server。この経験から一通りSQLの記述方法を理解したという。
あるときパフォーマンスの問題に行き当たった。ある実行ファイルをテストしていると、サーバーのサービスが落ちるほどの負荷がかかることが判明した。しかしテストするたびに結果が違う。何が原因でこのような現象が起きるのか、誰も分かる人はおらず頭を抱えてしまった。
結論としてはSQLの記載方法やデータベースの物理配置が適切ではなかったこと、またデータの断片化も起きていたのが原因だった。これをつきとめるのにどうしたか。
「答えはオラクルのマニュアルにあったのです。……おいおい、何を言っているんだ、と思うでしょう？」と亀山さんは笑う。
Infomixのシステムで発生した不具合の答えがオラクルのマニュアルにあったと言われれば確かに理解不能である。きょとんとしながら話を聞くと、亀山さんは「当時Infomixの資料が充実していなかったのです」と説明する。そこで比較的資料が充実していたオラクルのマニュアルから現象をつきとめようとした。それでも今のようにWebから検索できるような便利なマニュアルではなかった。紙の冊子である。しかし「基本的な機構は同じはず」と推測しながら不具合の究明と対策を探し当てたという。
厳密に言えばオラクルとInfomixでは内部機能は同じではない。しかしこうした不具合を通じてデータベースの設計やメンテナンスで性能が変わるということを理解し、データベースのアーキテクチャや設計について強い関心を持つようになった。
普段の業務でも性能問題にはよく直面した。亀山さんは「よくジュースについてるシールでプレゼントに応募するようなキャンペーンがあるでしょう？ああいうものは私たちのような印刷会社がやっているんですよ」と話す。1枚1枚違う数字やコードを印刷し、サイトでは同じコードは1度きりのみ入力を受け付けるなど、印刷とシステム開発の技術が必要になるからだ。
システムはテンプレートのようなものをベースに構築し、データベースは条件に応じてOSSや商用の製品を柔軟に選択した。いずれにしても、短期間のみ稼働するシステムなのでアクセスが一挙に伸びるのをうまく制御しなくてはならない。キャンペーン期間にシステムがダウンしたらビジネス的な痛手は大きい。性能には手を抜くわけにはいかず、性能にはおのずと詳しくなった。性能診断に関するコンサルタントの見積もりを聞いても「それなら自分でもできそうだ」と思えるほどになり、そのうちに社内のデータベース性能分析を任されるようになった。
実務経験だけではなく、受講した研修の量も半端ではない。「研修は相当受けましたよ。元がとれたのか分かりませんけどね」と亀山さんは苦笑いする。各種データベース製品の特徴や性能対策だけではなく、各社の研修コースの違いにも詳しくなったほどだ。
技術研修は自分のためというよりは「どうすれば後輩にスキルを渡せるか」という観点を意識していたという。開発しか経験がないと、なかなかサーバー側の性能に意識が向かない。そのため亀山さんは後輩や関係部門の方々ににデータベースの全体像を理解させることに力を入れてきた。ただしデータベースのアーキテクチャは口で言うだけでは伝わらない。実際に見せることにした。
後輩の前でサーバーの管理画面を開き、SQL文にかかる負荷や応答時間を見せる。例えば結果が帰ってくるまで100秒かかるSQL文があったとする。これをサーバーの負荷がかからないようなSQL文に書き換えて実行すると0.02秒になる。帰ってくる結果は同じになのに応答時間が劇的に違うため、後輩は目を丸くして「なぜ？！」と驚く。こうしたプレゼンテーションを通じて後輩にもサーバー内部で何が起きているのか、実行計画とは何か、性能を担保することとはどういうことかを説くようにしている。
