今回は長年インタースペースのアフィリエイトサービスのデータベース（以下DB）を構築・運用しているDBAの専門職である林田にインタビューを実施しました。このインタビューを通して、よりポジションについての理解を深めていただければと思います！

▼DBAが所属するシステムインフラグループの紹介記事はこちら

―アフィリエイトサービスのDBはOracleがベースになっているため、まずはOracle経験をお伺いしたいので、今までのご経歴を教えていただけますでしょうか。

キャリアのスタートは半導体をつくるための装置のエンジニアでした。そこに3～4年ほどいたのですが、業務内でソフトウェアも触っており興味があったため、ベンチャー企業に飛び込み、受託案件の対応をしていました。当時所属していた会社はOracleとの付き合いが深く、案件としてもほぼOracleに関連するものだったので、このときはじめてOracleに触れました。

その次は50～60人ほどの会社に転職し、大手の案件に参画していました。ひと月で400～1000人ほど関わるような規模感のシステムで、さまざまなトラブルを乗り越えるなどより深い経験が積めました。

その後、「自社サービスに関わることで課題に対してもっとコミットしたい」「トラブル解決後までしっかり追いたい」という想いがあり、自社サービスを展開しているインタースペースに入社しました。入社したのは2005年なのですが、ちょうど上場に向けて活動しているときで売上も倍々に成長していたので、ここならやれることがたくさんありそうだなと思い入社を決めました。

―たくさんの経験を積んでいると思うのですが、OracleDBの経験として特に自身の力になった経験はどういったものでしょうか？

前職で大規模な受託案件に参加しているときに、一度クラスターに不具合がありDBが消えた、つまりはデータがすべてなくなってしまったことがあります。

日曜夜10時半に電話がきてすぐに現場に向かい、バッチ管理の経験から外部に残っているデータを聞き、もらえるデータからの復元方法を30分くらいで考え、復旧方法を提案しました。なんとか朝の3時までに対応が終了し、朝7時に帰ったことがあります。

 大きなトラブルにぶつかったとしても、構造を一からたどっていき、どこでどのような分岐があるのか、どこからであれば問題解決につなげられるのか「ロジックツリー」のような思考で物事を整理していくと、「デジタルは嘘をつかない」ので、どこかに必ず答えがあります。身をもって大きなトラブルを体験できたのは今の考え方にも大きな影響を与えていますね。

―入社時のインタースペースのアフィリエイトサービスのDB周りの体制や状況はどういったものだったのでしょうか？

入社直後は自分以外DBAはおらず、システム開発エンジニアがテーブル管理をしていて、インストールなどは別のエンジニアがやっていました。そんな体制だったので、入社初日も夜間バッチが落ちていて業務ができなかったのも思い出です。当時は開発含めエンジニアが6人しかいなかったので、みんながなにかしらを兼務している状態でした。

現状は部署全体で40名ほどエンジニアがいます

―大体どのくらいの期間でDBの基盤が整えられたのでしょうか？ 

ある程度安定して稼働できるようになるまでには大体3か月くらいかかりましたね。

入社後まずはDB周りでの課題や困りごとをヒアリングしたうえで、自身の目で状態を確認しました。当時はDBの重さが課題として大きかったため、チューニングを行うことで多少改善したものの、データの移行をしないと理想状態にはたどり着かないと判断し、入社して1～2か月でDBの移行まで完了させました。当時は配信のDBが5～6台あったので、それぞれチューニングを実施してその結果を確認するため一晩1台だけで運用したりしました。 

―現在アクセストレードは月に大量のデータを取得していますが、DBとしてはどのくらいの処理を行っているのでしょうか？

メインのDBは1日で5TBのデータ更新と7千万回～1億回のSQLの処理をできるようにしています。 

―この規模のDBを安定稼働させるために工夫していることはありますか？

障害にいち早く気付くための工夫として、ユーザー側のエラーも含め、重要な処理をメールで通知がくるようにしています。自分の知りたい情報をすぐに取得できるように、ツールで通知設定をしているのではなく自身でSQLを書いてShellのなかで通知を飛ばしています。 

―SQLだけではなくShellも扱うんですね。

そうですね。ですので、WindowsよりもLinux環境の経験がある方のほうが適応しやすい環境になっています。

―障害対応以外に日々どのような業務を行っているのでしょうか？ 

基本的には監視を行っています。「Cacti」というツールを入れているので、そこで日々サーバーごとの状態を見ています。移行業務はハード側の保守対応に応じて5年に一度行っています。 

また、システムインフラグループとしても週次の定例ミーティングがあるので、そこでミドルウェア、NW、サーバーのメンバーと要望を伝えあって連携を取ることもあります。同じ部署には開発メンバーもいるため、「新しいテーブル設計や、カラムの持ち方はどうしたらいいのか」「性能が良くないのでSQLみてもらってほしい」などの質問や相談も日々受けています。DB関連の相談ごとはすべて受け答えできるようにしていますね。

―開発は開発でSQLを叩くこともあると思いますが、どのように切り分けしているのでしょうか？

DBの更新権限はマネージャー以上、サーバーにログインできるのはサーバーチームと自分だけになっています。開発メンバーはアプリケーション側でセレクトはできるので、そこから本番につないでもらい運用ミスを減らしています。なにかあってもリカバリーできる体制というのを前提に切り分けています。 

―入社者がいた場合、入社後はどのような業務からお任せする予定でしょうか？

なにが得意なのか、どのような経験をしてきたのかヒアリングしたうえで、適切な業務をお渡ししたいと思っています。日々の運用のなかでまずは開発環境でやれる部分を触っていき、慣れてきたら本番も任せたいです。意向次第ではあるのですが、DBに付随するアーキテクチャの選定提案もすることが可能です。ソフトウェアだけではなく、ハードウェアも扱えるのでその点はおもしろさも感じていただけるのではないかと思っています。 

―どのような人がマッチしていると思いますか？ 

DBAは組織内の間接的な立ち位置なので、周りの人をみて気になることや入ってきた情報に対して興味を持って調べてキャッチアップできる人は向いていると思います。 

DBの構造や関係性を理解するためには、物事を広く捉えて理解することが必要になるので、周辺知識含めどれだけ「知る」ことができるのかが重要だと考えているからです。また、情報収集をするためには人に聞くことも大事ですので、知的好奇心をもって自ら周囲にアプローチできるといいなと思います。 

林田さん、インタビューへのご協力ありがとうございました！  

インタースペースについて興味を持っていただいた方はぜひ採用HPもご確認ください！