データベースを運用する仕事とは

Jul 30, 2025

はじめに

私は大学生の頃、将来はデータベースに関連した分野で仕事をしたいと考えていた。ほとんどの IT サービスではデータベースが必要であり、データベース技術者としてのキャリアは安定性の高いものであると考えたためである。(よく私は「食いっぱぐれなさそうだから」と言っている。) しかし当時は世間におけるデータベース分野の仕事についての具体的な情報があまりなく、実際にどのような業務を行うのかについて不安に感じていた。

現在はデータベースの運用を専門とする部署で業務を行っているが、データベース分野を明確に志望している人に出会うことは稀である。実際の現場では人材の需要に対して供給が追いついていないと感じている。

データベース運用の仕事について、実態を詳細に説明しているブログや記事は今でも多くはない。本記事は、かつての自分のようにこの分野に興味を持ちながらも、その中身が見えずに悩む人に向けて、私自身の業務内容を紹介することを目的としている。

以下に示すのは、私が日常的に関わっている主な業務の内容である。

DBaaS (Database as a Service) の構築・改善
大規模・特殊なデータベースの構築・運用
データベースが依存するハードウェアのライフサイクル対応
データベースの監視システムの構築
障害時の自動復旧システムの構築
障害発生時の対応体制の設計と実施
データベースのパフォーマンスチューニングや設備投資の計画
データベースの利用に関する利用者であるエンジニアからの相談対応

これらについて、簡単ではあるが紹介をしていく。

その前に: データベース管理者 (DBA) とデータベースリライアビリティエンジニア (DBRE) について

世の中にはデータベース管理者 (DBA) とデータベースリライアビリティエンジニア (DBRE) という職種名が存在する。前者はデータベースの安定運用に責任を持つ仕事であり、後者はSREの手法をデータベースに適用し運用の自動化に注力する仕事であると説明されることが多いようだ。しかし、私の実体験ではこれらの2つの業務を完全に分業化することは難しく、兼任することが実態のように思われる。

便宜上、本ポストでは私の仕事をデータベース管理者もしくは DBA と表記するが、DBA と DBRE の区別をしない。また、私が実際に行っている業務の多くはデータベースシステムの信頼性に関するものも多い。

筆者が所属する組織について

私が所属するのは、toC 向けに多数のサービスを展開する情報通信業を営む会社である。サービスのインフラとして社内プライベートクラウドを構築し、基本的に各サービスで使用するインフラはこの社内プライベートクラウドである。私は、このプライベートクラウドのデータベースサービスを提供する部署で業務を行っている。

社内で提供するデータベースサービスは複数存在しており、RDBMS やインメモリ DB、水平分散ができる KVS などを提供している。私は、この分散 KVS の提供を担当している。

社内ではマイクロサービスアーキテクチャに基づいて、機能が細かく分割されて開発・運用されている。その中で、データの管理を担当するコンポーネントが、データベースクラスタの作成をリクエストして、それに応じてデータベースクラスタが提供される。このデータベースクラスタの提供はよほど大規模なクラスタがリクエストされない限りは自動化されている。私が所属する部署では、このような DBaaS (Database as a Service) を開発・運用をしている。

DBaaS (Database as a Service) の構築・改善

社内の多数のユーザがいつでも新しいデータベースを構築することができるようにするため、社内プライベートクラウドの上に DBaaS を構築し運用している。社内のエンジニア向けの UI とバックエンドサーバーが必要だし、DBA が運用するための各種ツール (WebUI, CLI 問わず) の開発をする。

DB の異常を検知するための監視体制を整備したり、検知された異常のいくらかは自動で修復するツールの開発も行う。自動で修復できない異常については手動で対応する必要があるため、適切なエスカレーションのフローと手順をあらかじめ整備して、必要に応じて対応をしている。また、DB が載っているハードウェアは一般的には 5 年程度で交換する必要がある。サービスの利用者に影響が出ないようにするため、DB の機能を止めずにハードウェアを交換する計画を立て実行をする。

大規模・特殊なデータベースの構築・運用

非常に大規模であったり、きわめて高い可用性が求められたり、通常のものとは異なる要件が求められるデータベースについては、手動で構築する場合がある。このときには、専用の監視や運用フローを構築する場合があり、利用しているエンジニアと密なコミュニケーションを取る必要がある。

データベースが依存するハードウェアのライフサイクル対応

ハードウェアが一般的には 5 年程度で交換の時期がやってくる。基本的には DB の機能を止めずにハードウェアの交換を行うことが求められるため、効率的かつ安全に交換作業を進めるための準備と事前検証を行い、最終的には交換対応を実施していく。

データベースの監視システムの構築

ハードウェアは壊れるし、利用者が誤った使い方をした場合などには DB の機能に深刻な影響が出ることがある。中には提供しているデータベース自体に致命的なバグがある場合もある。そのような障害が発生したことを検知し、適切にハンドリングをする必要がある。

具体的な障害パターンを列挙し、それらを拾えるように監視ツールの開発や改善を行っていく。このとき、監視ツールは検証と配布をしやすい形式で開発をしている。例えば、DB サーバーにインストールする rpm パッケージとして開発をすることで検証環境で開発中のパッケージに差し替えたり、本番サーバーにインストールされるバージョンを明示的に指定したりする。

他には DB サーバー自体がダウンしたことを検知することはサーバーの外から観察する必要があるため、外部からの監視を行うツールを作成したりする。また、DB や OS が出力するレイテンシや Disk Usage などのメトリクスを保管し、メトリクスの異常値が見られた場合にはアラートを発火させる仕組みを構築したりもする。

これらは、具体的にどのような事象や状況が DB の安定運用に支障を来たすかを予測しながら、それらの脅威に対処できるように構築する必要がある。

障害時の自動復旧システムの構築

上述した監視システムによって異常な状態を検知したときに、自動対応を行うシステムの構築を行っている。例えば、DB が動作しているマシンがダウンした際にフェールオーバーを自動で行ったり、マシンの置き換えによって DB の機能の維持を行ったりする。

障害発生時の対応体制の設計と実施

自動対応で解消できない問題が生じた際には、手動での対応が必要になる。障害は24時間いつでも発生する可能性があり、またそのような障害は DB の可用性に影響が出ている可能性もある。そのため、短時間で誰でも解決ができるように、既知の障害については対応手順を事前に整備・検証を行い、トレーニングをしている。

また、一部の障害については対応を外部に委託するケースもある。そのようなものについて、外部も含めた対応体制を設計し、構築を行っている。

データベースのパフォーマンスチューニングや設備投資の計画

企業にとって、インフラに対するコストというのは非常に重要である。マシンのリソースを十分に利用するため、適切なパフォーマンスチューニングを行い、より少ないハードウェアリソースで要件を満たすように DB の機能を提供することが求められる。また、社内における DB の需要変動を予測し、大きな過不足なくハードウェアの購入を行う。

データベースの利用に関する利用者であるエンジニアからの相談対応

社内には多数のエンジニアが所属しており、その多くはすべての DB に精通しているわけではない。新規サービスの設計時などには、サービス開発エンジニアのリクエストに応じて各 DB の DBA が集まり、要件に応じた適切な DB を選定する支援を行っている。

また、新規 DB の利用開始時だけでなく、既存 DB の利用に際しての利用者からの相談に対して担当する DBA が回答を行う。

総括

私が所属している DBA の組織では以上に代表されるような業務を実施している。担当する DB によっても具体的な業務内容は異なるが、基本的には提供されたハードウェア上に DB を構築するところから始まり、異常状態への対応や、利用者からの相談対応などを各部署で実施している。

私が学生のときに想像をしていたよりも、より広範でより技術的に深い内容の業務をしていると感じる。 DB はサービスの重要な要素であるため、これを安定的に運用することは非常に責任が重いが、貢献度の大きい仕事であるように思う。学生のときに思っていた、「食いっぱぐれなさそう」な仕事であることは間違いなさそうである。