Infomixの不具合の答えがオラクルのマニュアルに?―手探りの新人時代
亀山さんは1997年入社。最初は主にInfomixを使ったシステムの設計・テストからデータベースに携わった。当時を振り返り、亀山さんは「(技術的なことは)分からずに使っていました」と話す。
新人なら無理もない。しかし体当たりで技術を会得していく。当時β版の段階で不具合や改善要望が850件にも上り、自ら障害管理データベースを構築した。当時は現在ほど開発支援ツールが充実していなかったため、足りないものは作るしかなかったのだ。使ったのはAccessとSQL Server。この経験から一通りSQLの記述方法を理解したという。
あるときパフォーマンスの問題に行き当たった。ある実行ファイルをテストしていると、サーバーのサービスが落ちるほどの負荷がかかることが判明した。しかしテストするたびに結果が違う。何が原因でこのような現象が起きるのか、誰も分かる人はおらず頭を抱えてしまった。
結論としてはSQLの記載方法やデータベースの物理配置が適切ではなかったこと、またデータの断片化も起きていたのが原因だった。これをつきとめるのにどうしたか。
「答えはオラクルのマニュアルにあったのです。……おいおい、何を言っているんだ、と思うでしょう?」と亀山さんは笑う。
Infomixのシステムで発生した不具合の答えがオラクルのマニュアルにあったと言われれば確かに理解不能である。きょとんとしながら話を聞くと、亀山さんは「当時Infomixの資料が充実していなかったのです」と説明する。そこで比較的資料が充実していたオラクルのマニュアルから現象をつきとめようとした。それでも今のようにWebから検索できるような便利なマニュアルではなかった。紙の冊子である。しかし「基本的な機構は同じはず」と推測しながら不具合の究明と対策を探し当てたという。
厳密に言えばオラクルとInfomixでは内部機能は同じではない。しかしこうした不具合を通じてデータベースの設計やメンテナンスで性能が変わるということを理解し、データベースのアーキテクチャや設計について強い関心を持つようになった。
普段の業務でも性能問題にはよく直面した。亀山さんは「よくジュースについてるシールでプレゼントに応募するようなキャンペーンがあるでしょう?ああいうものは私たちのような印刷会社がやっているんですよ」と話す。1枚1枚違う数字やコードを印刷し、サイトでは同じコードは1度きりのみ入力を受け付けるなど、印刷とシステム開発の技術が必要になるからだ。
システムはテンプレートのようなものをベースに構築し、データベースは条件に応じてOSSや商用の製品を柔軟に選択した。いずれにしても、短期間のみ稼働するシステムなのでアクセスが一挙に伸びるのをうまく制御しなくてはならない。キャンペーン期間にシステムがダウンしたらビジネス的な痛手は大きい。性能には手を抜くわけにはいかず、性能にはおのずと詳しくなった。性能診断に関するコンサルタントの見積もりを聞いても「それなら自分でもできそうだ」と思えるほどになり、そのうちに社内のデータベース性能分析を任されるようになった。
実務経験だけではなく、受講した研修の量も半端ではない。「研修は相当受けましたよ。元がとれたのか分かりませんけどね」と亀山さんは苦笑いする。各種データベース製品の特徴や性能対策だけではなく、各社の研修コースの違いにも詳しくなったほどだ。
技術研修は自分のためというよりは「どうすれば後輩にスキルを渡せるか」という観点を意識していたという。開発しか経験がないと、なかなかサーバー側の性能に意識が向かない。そのため亀山さんは後輩や関係部門の方々ににデータベースの全体像を理解させることに力を入れてきた。ただしデータベースのアーキテクチャは口で言うだけでは伝わらない。実際に見せることにした。
後輩の前でサーバーの管理画面を開き、SQL文にかかる負荷や応答時間を見せる。例えば結果が帰ってくるまで100秒かかるSQL文があったとする。これをサーバーの負荷がかからないようなSQL文に書き換えて実行すると0.02秒になる。帰ってくる結果は同じになのに応答時間が劇的に違うため、後輩は目を丸くして「なぜ?!」と驚く。こうしたプレゼンテーションを通じて後輩にもサーバー内部で何が起きているのか、実行計画とは何か、性能を担保することとはどういうことかを説くようにしている。
はじめてPostgreSQLを触ったときに感じた「懐かしさ」
人並み外れた関心と情熱でデータベーススキルを究めた亀山さんではあるが、データベース業務を純粋に楽しめない時期があった。微妙なギャップが生じていたようだ。亀山さんはいわゆる“アーキテクト”や“コンサルタント”ほどのスキルを保有していたが、それが求められるようなソフトウェアベンダーやSIerの人間ではない。将来のキャリア方向性への迷いと周囲とのスキルの差などが漠然と絡み、迷いにつながったのかもしれない。
そこで一時的にデータベースから離れ、基盤システムの業務に携わることにした。当初数ヶ月は事務手続きばかりとなり、このままデータベースだけではなく技術的な業務からも離れ、企画や営業が中心になるのだろうかとも感じた。今だから言えることだが、一瞬転職も頭をよぎったという。
しかしそうした状況は長く続かなかった。大型案件の受注が立て続けに決まったことでデータベース設計の専門家が急きょ必要となり、亀山さんが割り当てられた。データベースから遠ざかったかと思いきや、強い力で引き戻されたようなものだ。これも運命だろうか。ここでデータベースの企画と開発を兼務しつつ、受注したシステムの移行や基盤フレームワークなどに携わった。
受注案件が一段落ついたころ、現行の職に就くことになった。社内業務の支援、顧客への提案、設計、構築、移行などの支援などを行う部署だ。特にデータベースの技術を強化するため、亀山さんが呼ばれた。
現状は商用データベースとOSSデータベースを扱う割合は半々ほど。しかし、新規は圧倒的にOSSデータベースが採用されることが多いという。社内だけではなく顧客にも変化が出てきた。
「これまでお客様は『(データベースは)なんでもいいから(システムを)作って』とデータベース製品には特に指定はありませんでした。しかし最近では『データベースは何にしますか?オープンソースのデータベースにしませんか?』と聞いてくるお客様もいます」(亀山さん)
これを聞いて筆者は患者が医者に「ジェネリック医薬品はありますか?」と尋ねる姿を想像した。必要な効果が変わらないなら、値段の安い後発医薬品のほうがいいという考えだ。OSSを医薬品にたとえるのは語弊があるが、当たらずとも遠からずなのか亀山さんは笑って聞いていた。
余談だが、PostgreSQLを最初に触ったときはちょっとした衝撃があったそうだ。初めて出会ったデータベースInfomixによく似ていたのだ。「すっごく似てる!」と旧友に再会するかのような懐かしさがあった。それもそのはず。InfomixもPostgreSQLも源流は同じ。きょうだいのような存在なのだ。
亀山さんがOSS-DB技術者認定試験を受験した理由
現在の部署に異動してから 亀山さんはLPI-Japanが運営している「オープンソースデータベース(OSS-DB)技術者認定試験」の受験を思いついた。実は亀山さんはこれまでもいくつかデータベースに関連する技術者試験に合格してきている。Oracle MasterのDBAは11g GoldにPerformance Tuning Expert、さらにDB2の技術者試験にも。オープンソースデータベースへの注目が高まっていることと、データベースに力を入れる担当となったことで、OSS-DB技術者認定試験も「とってみるか!」と挑戦することにした。
亀山さんほどの実力があると、受験対策はさほど必要としなかった。OSS-DB Silverは約2週間の準備でやすやす合格。ところがGoldではつまづいた。得意な性能に山をかけていたところ、障害対策の問題が多く出題されていたのだ。Gold試験だとまだ対策本やセミナーが少ないというのも不利だった。
そこであらためて試験対策に本腰を入れた。Let's PostgreSQLなどのWebサイトを参考にするほか、特に力を入れたのは実機での障害対策訓練だ。「自宅でサーバーを構築し、5000万レコードほど蓄積してから壊しました」と話す。データベース・クラスタを削除する、ファイルを壊す、WALのログを読めないようにするなどわざと障害を発生させ、復旧を試みた。そして2012年8月にGoldに合格。
「今ならPostgreSQLにどんな障害が起きても復旧させる自信がありますよ」と亀山さんは笑う。「OSS-DB技術者認定試験対策は実機に触らないとだめですね。後輩にもそうアドバイスしています」
これまでの経験が豊富なためOSS-DB Gold合格に特別な感慨は感じていないものの、「やはり知識を一通り整理できたことは良かったですし、顧客など周囲からの信頼がいっそう高まったと感じています」と亀山さんは話している。
今後もさらに「データベースのスキルを究めたい」と亀山さんは意欲満々。直近の目標はPostgreSQLで高可用性システムの構築に挑戦し、運用することだそうだ。根っからのエンジニアなのだろう。データベースの性能について話す亀山さんは表情が生き生きしている。
■■■ Profile ■■■
亀山潤一 KAMEYAMA,Junichi
大日本印刷株式会社
C&I事業部 ITサービスマネジメント部
DNP C&I事業部のデータベース技術担当です。
人種のるつぼといわれているDNPで社内外の方々との出会いを大切にしています。
DNP入社後、商品情報統合データベースシステムの設計・
データベースという技術は大切ですが、それだけで物事が成り立っているわけではありません。ちゃんとしたバックグランドをもってそれを基に懐の広い対応もでき、周囲の方々に頼りにされる技術者を目指したいです。
週末のお昼は二人の子供たちに童話を読み聞かせたり近所の公園で遊んでいます。夕方から夜は”妻のよろず相談役”としてひたすら話をきいています。