データベース

ブックルックチーム代表の小山内です。
今日は私がIT未経験の新社会人としてテクニカルサポートから出発し、データベースエンジニアになるまでの道のりと、データベースエンジニアとしての経験を紹介したいと思います。

データベースエンジニアになるまで主に次の３つのステップがありました。

１つ目がクライアントPCの基本的な技術の獲得

２つ目がネットワークとサーバーサイドの知識と経験

３つ目がデータベースエンジニアの知識と経験

それぞれのステップとステップの間には「ツナギ」となる仕事がありました。必然的偶然のようなツナギの仕事です。
ツナギの仕事がデータベースエンジニアへと私を導きました。
突然データベースエンジニアになったわけではありません。自然と、本当に気付いたら、データベースエンジニアになっていたというのはそういうことだからです。
振り返れば、これら「ツナギ」の仕事がいかに重要だったかがわかります。

後半はデータベースエンジニアとしての失敗談や苦手なデータベース操作についてもお話しします。

悲鳴を上げるECサイト、１つしかないデータベース

2000年初期、米デル（現、デル・テクノロジーズ）の日本向けECサイトはいつも悲鳴を上げていました。
毎日何万の人がサイトに訪れ、何百ものパソコンがオーダーされます。
人手ではとうてい対応しきれないほどの注文が絶え間なく自動的に入ってきます。
そのため営業部門はサイトの24時間稼働は当然のことと考えていました。
それなのに、ちょっとした躓きでサービスダウンが発生する、という毎日でした。

ECサイトのWEBサーバーを増やし、いくら負荷分散したところで、サイトのパフォーマンスは改善されません。
なぜならば、データベースはたったの１台。
１台しかないデータベースは、フロント（ECサイト）を構成する複数のサーバーからのリクエスト処理がやってくるだけでなく、バックエンドで実行されているバッチ処理数だけでが毎日数千あり、リクエスト数は数えきれないほどありました。
そのため当時のデータベースサーバーは最高水準のスペックでしたが、常に高負荷になっていました。

この山に真正面から向かい、越えられたことが私のデータベースエンジニアとしてのスキルと経験を飛躍的に高める結果となりました。

ITエンジニアになったきっかけ

私がITエンジニアになったきっかけは、デルとの出会いが大いに関係しています。
その出会いに先駆けて、1995年、私は当時２部上場のトランス・コスモスに入社することとなり、入社前の２月頃から同期数十名と一緒に技術研修を受けました。
学生時代からパソコンに慣れ親しんでいる同期は当然のこととして話を聞いていました。
私はパソコンにほとんど触れたことがなく、見聞きすることが初めてのことばかりでした。
研修後も毎日、機械慣れしていない女子たちと一緒に、詳しい男子に教えてもらっていました。

そうこうしていると４月になり、同期のみんなは某プリンタメーカーのサポート業務部門に配属されていきました。
スタートから出遅れていた私だけが本社に取り残されました。
この先どうなるのかと心配しましたが、ゴールデンウイーク明けになってようやくデルでのパソコンのテクニカルサポートの仕事があてがわれました。

それは1995年、デルの日本進出2年目でした。当時の社名はデル・コンピュータ。
デルでは、「立ち止まって考えるな、走りながら考えろ」、「早くやれ、完璧は求めない、8割できれば成功だ」、「自分で判断しろ、人に聞くなら自分の答えを決めてからにしろ」という個人のパフォーマンスと成長を優先する合理的な行動をよく求められました。
私にとってはとても理解し易い、シンプルな考え方に思えました。しかも、多くのことを任せてもらえるし、やりがいもありました。

デルはハードウェアメーカーですが、仕事に必要な知識は非常に広範囲でした。
マザーボード、CPU、メモリ、ハードディスクに留まらず、OS、ネットワーク、サーバー、プリンター、ディスプレイアダプタ、サウンドカード、SCSI機器など。毎日毎日聞いたことのない単語がサポートを求めるお客様から出てきてその度に調べていました。
本で読んで実機で試すことを繰り返し行いました。ハードウェアとソフトウェアの関係性を学ぶことも多くありました。
一定の知識がなければ即刻退場となる厳しい環境でしたから必死で知識を身に付けました。

でもこれはまだステップ１。ハードウェアとソフトウェアの基本的な技術、つまり主にクライアントPCを使うために必要な知識の獲得に過ぎませんでした。

サーバーサイドのスキルアップ

データベースエンジニアにたどり着くまでにもう２段階あります。
ステップ２は、ネットワークとサーバーサイドの知識と経験の獲得です。

２年目になると私はテクニカルサポートに必要な知識を身に付け、チーム内で常にナンバーワンの業績を出すようになりました。
一方で、鳴りやまないお客様からの電話対応に疲れ果てていました。
私の仕事量を減らすにはどうしたらよいか考えました。それは私以外のメンバーがもっとたくさんの電話を取ってくれることです。

私がナンバーワンを維持する秘訣である自作のＱ＆Ａ集を社内に公開することにしました。
私は電話で問い合わせを受けたらFAXで回答を送ることで、１件あたりの対応時間の短縮を図っていました。
１度作成したドキュメントは保存しておき、同じ問い合わせが来たらFAXで送信するだけ、ということを繰り返していました。

社内の情報共有はNotesで行われていましたが、大小100以上あるドキュメントの更新や検索のし易さの点で、HTMLで作成して共有することとしました。

これがツナギの仕事です。ステップ１とステップ２をつなぐきっかけになったのです。
クライアントPCからネットワークやサーバーサイドへ行かざるを得なくなったのです。

当時の米Yahooを真似てディレクトリ型のページを作成しました。複数カテゴリへの登録、ドキュメント間のリンクなど今では当たり前ですが、当時は画期的でした。
それでも目的のドキュメントが見つからない、とメンバーから何度も言われ、私が検索して見つけて渡すということが度々ありました。

そんなこんなでデルでの２年半の仕事の後、ソニーのＶＡＩＯのコールセンターの立ち上げを行うこととなりました。
ＶＡＩＯのコールセンターはデルの何倍もの人数の部隊でした。
私はデルでの業績を買われ、メンバーを支援する後方部隊の仕事を任されました。
同じように「こういうお問い合わせにはこう答えましょう」というＱ＆Ａ集「chaco」を提供しました。
chacoは私が小学生のときに飼っていたメスの三毛猫の名前です。

chacoはＶＡＩＯのお客様の特性に合わせ発展させていきました。
BIOSのシミュレーション画面や、パソコンに同梱される物やソフトウェアの情報なども追加し、実機が手元に無くても電話でサポートできるようにしました。
間もなくHTMLでは対応しきれなくなり、WEBサーバーを構築し、サーバーサイドのコーディングが必要になりました。
プログラミングもしたことがなかったので、社内の誰か出来る人がいないかと本社にお願いしましたが、そこまでできないということで、最初のやり方だけ教えてもらいました。
あとは本を片手に試行錯誤でとりあえず構築しました。

しかし、見様見真似だけではわからないことが多く、一から本を読んで勉強する必要性を実感し、ネットワークの基礎、Windows Server、TCP/IP、IISなど手近なところからやりました。

ここまでで、ステップ１（パソコンの基本スキル）、ステップ２（ネットワーク／サーバーの知識と経験）と来たわけですが、これが次のステップ３（データベースエンジニア）へと進む大きな自信になりました。

WEBサイト管理のコアはデータベース

ソニーＶＡＩＯコールセンターでサポートシステムchacoが軌道に乗ったところで転職活動をしたらたまたまデルに入社することとなりました。2000年1月のことです。
chacoのことは後輩に任せましたが、その後10年ほど進化しながら利用され続けたと聞きました。

デルではカスタマーサポート部に配属され、サポートサイトで公開するコンテンツ開発を行いました。
よくあるお問い合わせをコールセンターから仕入れドキュメント化し、WEBで公開する仕事です。サーバーも触らないし、コーディングもしません。

しかしこれがステップ３へのツナギの仕事になったのです。

サポートサイトではどれほどコンテンツを追加しても、コールセンターへの電話の数は減ることはありませんでした。その原因を追究していくとサイトのユーザビリティに行きつきました。
欲しい情報がすぐ見つかる、使い易いサイトを目指し改善を重ねました。

一方で、私は社内用のコールセンター向けのコンテンツサーバーを立上げ、検索エンジンを導入し、社内イントラサーバーの開発を行っていました。

しばらくすると同じ部署でサーバーを管理していたエンジニアが退職することになりました。
そのため私が外部向けのサポートサイトを構成する複数のサーバーを管理することになりました。

やがて私はカスタマーサポート部から、それらサーバーと一緒にＩＴ部門に異動することになり、ECサイトも面倒を見ることとなりました。
ＩＴ部門に異動した当初はWEBサイト管理ということで、サーバー単位で管理していました。
当時はまだクラウドのサービスは一般的ではなく、データセンターに物理サーバーを置いていた時代です。
サーバー単位なので、ハードウェア、OS、ミドルウェア（WEBサーバーとデータベースサーバー）が責任範囲でした。データベースはMicrosoftのSQL Server。
その時のECサイトは先ほど述べた通りで、ほぼ毎日事件（システム障害）続きでした。

毎日起こるシステム障害。『これは何とかしなければならない』と半ば強引に対策を施しました。
対策のメインはデータベース。チューニング、一極集中する状況の打破、システムの見える化、キャパシティプランニングなど、できることはないか、すべきことはないかとデータベースの勉強をしながら行いました。

データベースのマニュアルや教科書を読みながら、効果がありそうなことを見つけたら実際に試してみることを繰り返すことで、データベースエンジニア、データベース管理者としてのスキルと経験を身に着けていきました。

当然この私のデータベースエンジニアとしての仕事だけではありませんが、事件続きのECサイトを安定稼働させることができるようになりました。安心できるようになるまで1～2年はかかったと思います。

いよいよデータベースエンジニア

ECサイトが安定稼働したことで、社内のその他のデータベースも面倒を見ることになりました。
MicrosoftのSQL Serverだけでなく、Oracleも含まれ、またもやチャレンジングな状況になってしまいました。

サーバー30台、データベース300以上あったと思います。
その中にまさにビッグデータがありました。世間でその単語が取り上げられるよりも先に取り扱っていました。
社内ではこのビッグデータを使ってガリガリ、ガリガリと分析をする人たちが大勢いて、頻繁に「遅い」、「時間がかかる」、「処理が終わらない」、「結果が返ってこない」、「どうやってデータを結合したらいいのか」、「欲しいデータがない」などなど私のところへ要望、質問、文句が山ほど寄せられました。

システム障害は起こらないものの、社内ユーザーからの同じことの繰り返しの問い合わせに、またもや『これは何とかしなければならない』と立ち上がるに至りました。
ビッグデータのデータベースはOracle。手法は異なるものの原理はSQL Serverと同じ。
データベースファイルの配置、インデックスの管理、バッチの管理などを見直しました。

全社のデータ分析、レポーティング業務をほぼ１日止めてしまったこともあります。
パフォーマンスチューニングのためにインデックスの再作成したのですが、データ量が多すぎて一晩経っても終わらなかったのです。
朝になり、皆が出勤してくるとどんどんリクエストがやってきてCPUを消費され、インデックスの作成が滞り、さらに時間がかかるという状況になりました。
ユーザーに謝罪しつつ、ひたすら手動でリクエストを切断し続け、ようやく午後３時ころに完了したのを覚えています。

データベースにまつわる人為的ミスといえば、データベースエンジニアなら１度は経験したことがあるのではないでしょうか。それはデータ削除です。
データ削除は、データの完全性を担保すべきデータベースエンジニアとして最悪なミスです。
データ削除とは、データを間違って削除したり上書きしたり、中にはデータベースを丸ごと削除したり、バックアップで本番データベースを上書きしてしまったりすることです。
バックアップから復元できればまだましです。利用頻度が高いデータベースでは、バックアップからだけでは復元できないことがあります。
実は私も１度だけあります。レコード８行を間違って削除してしまい、慌ててバックアップから復元を試みたものの、２行はどんなデータだったかもわからず永久に失われてしまいました。
間違って削除したことに気付いた瞬間、血の気が全部引きました。体温が低下し、緊張のあまり手を震わせながらデータベース操作をしました。

データベースエンジニアとして最も重要な仕事は何かと聞かれれば、私はバックアップとリカバリだと思います。
必要なバックアップを取り、万が一の時に迅速にリカバリすることができれば怖いものはだいぶ減ります。
しかし、個人的にOracleデータベースのリカバリは何度やっても慣れませんでした。
SQL ServerとOracleを管理していたのですが、前者はほぼ目をつむっていてもリカバリできます。しかし後者は確認事項が多くうまくいかないこともありました。
まず、バックアップ対象が複数あり、漏れなくバックアップをしておくことから始まります。
人が管理していたものだとそれが不十分なことがしばしばありました。SWITCH LOGを実行してからバックアップをしていないとか、初期化パラメータファイルがないとか。。。
そのためリカバリは気を使います。すべてのデータファイルが同じSCNを持っているかとか、REDOログどうするかとか。
ビッグデータを保管するデータベースの場合、試しに他のサーバーでバックアップからリカバリできるか確認するということができなかったので、リカバリしなければならないような事態にならないことを祈るだけでした。