システム開発には、アプリケーション、AP基盤、システム基盤・クラウド、ネットワーク、データベースなど、異なる専門性を持つエンジニアが関わります。
本記事では、その中からデータベースエンジニアを取り上げます。
SEの職種全体と、それぞれの役割の違いについては、次の記事で整理しています。
データベースエンジニアとは
データベースエンジニアは、システムが扱うデータを安全に保存し、必要なときに正しく、十分な速度で利用できるデータベースを設計、構築、運用する職種です。
「データベースエンジニア」という言葉から、テーブル設計やデータモデリングを想像する人もいると思います。私が関わってきたSIerのプロジェクトでは、データベースの構築、性能管理、権限管理、監視、バックアップ、障害対応を担うDBA（データベース管理者）を指すことが一般的でした。
ここからは、長く担当してきたOracle DBAの実務を軸に、物理設計、構築、性能管理、セキュリティと監査、運用、復旧を見ていきます。製品ごとにアーキテクチャや実装方法は異なりますが、DBAに求められる基本的な役割と考え方には共通する部分があります。
DBAの中心的な役割は、論理的に整理されたデータモデルを、安定して稼働できる物理構成へ落とし込むことです。データベース製品をインストールして初期設定するだけではありません。アプリケーションが扱うデータ量、処理量、同時実行数、更新頻度、障害時の復旧要件を踏まえ、業務特性に合った物理構成と運用方式を設計します。
ここでいうデータモデルは、顧客、契約、申請、承認など、業務で扱う情報を整理し、どのような単位で管理するのかを定めたものです。この構造を設計する作業をデータモデリングと呼びます。業務要件やアプリケーションの処理と密接に関わるため、概念モデルや論理モデルの作成は、アプリケーション側が中心になることが多い領域です。
DBAも、完成したデータモデルを受け取るだけではありません。正規化の妥当性、テーブルや列の構成、主キーや外部キー、インデックス、データ量、検索や更新の特性を確認し、性能や運用の観点からレビューや助言を行います。
テーブル設計は、稼働後に変更すると、SQL、画面、バッチ、外部システムとの連携、データ移行、テストまで広い範囲へ影響します。将来のデータ増加や機能追加も見据え、物理設計へ進む前の段階からDBAが関わることが重要です。
主な担当領域は、大きく次のように分けられます。
構築と物理設計
データベース製品と構成の選定
インストールと初期設定
表領域、データファイル、ログ領域の設計
各種初期化パラメータの設計
性能と容量管理
SQLと実行計画の分析
インデックスや統計情報の管理
性能チューニング
データ容量と増加量の見積もり
セキュリティと運用
ユーザー、権限、ロールの設計
監査要件への対応
監視とログ管理
可用性とデータ保護
冗長化と障害時の切り替え
バックアップとリカバリの設計
移行と製品管理
データ移行
バージョンアップや製品更改
ライセンスと保守契約の管理
製品ごとに仕組みや用語は異なりますが、アプリケーションの特性を踏まえて構成を決め、稼働後も性能、セキュリティ、可用性、復旧を管理するという役割は共通しています。
アプリケーションの特性から物理構成を設計する
データベースの構築は、アプリケーションの処理内容を理解しなければ始められません。
どの程度のデータを登録し、どの時間帯に更新が集中するのか。長時間の検索、大量更新、夜間バッチなどがあるのか。アプリケーションの処理特性によって、必要なデータベース構成は変わります。
Oracleでは、REDOログのグループ数やサイズ、UNDO表領域の容量と保持期間、各表領域の初期容量や自動拡張の可否などを決めます。これらは、製品の標準値をそのまま採用すればよいものではありません。
更新量に対してREDOログが小さすぎれば、ログスイッチが頻発し、チェックポイント処理の負荷も高まります。次に使用するロググループのチェックポイントやアーカイブが完了していなければ、更新処理に待機が発生することもあります。
長時間の検索や大量更新に対してUNDO領域の容量や保持期間が不足すると、読み取り一貫性に必要な過去のデータを保持できません。ORA-01555（スナップショットが古すぎます）などによって、検索処理が失敗することもあります。
表領域の容量や拡張方法が不適切であれば、データの増加によって業務処理が停止する可能性があります。
容量の見積もりは、初期構築時だけの作業ではありません。どの表が月次や年次でどれだけ増えるのかをアプリケーションチームから引き出し、拡張の余地とストレージの追加時期まで計画に落とします。
データ移行は本番と同じ規模で確認する
旧システムからのデータ移行も、データベースエンジニアが中心となる作業です。
移行対象の件数、許容される停止時間、移行方式、データ変換の方法、移行後の統計情報の再取得まで設計します。
移行プログラムが正しく動くだけでは不十分です。本番と同等のデータ量を使ってリハーサルを実施し、移行処理が許容時間内に完了することを確認します。
移行後に統計情報を取得していなければ、データは正しく移行できても、適切な実行計画が選択されず、業務開始後に性能問題が発生する可能性があります。
移行作業には、データベースの知識だけでなく、業務停止時間、アプリケーションの停止と起動の順序、移行後のデータ確認方法、さらには切り戻し手順まで含めたデータ移行にかかる全体設計が求められます。
マネージドサービスでも設計は残る
マネージドサービスを利用する場合も、この考え方は変わりません。
RDSではパラメータグループを通じて設定を変更し、変更できる範囲は製品そのものより狭くなります。
標準値のまま構築してよいという意味ではありません。決められる範囲が限られた中で、業務特性に合う値を選ぶ作業が残ります。
クラウドサービスが引き受けるのは、データベース運用の一部です。どのような性能が必要なのか、障害時にどこまで業務を継続するのか、どの時点までデータを戻すのかといった判断まで、クラウド側が決めてくれるわけではありません。
RDS for Oracleへ移行すると、SYSDBA権限やOSへのアクセス、ストレージ管理、監査ログの扱いなど、オンプレミスで前提としていた運用をそのまま持ち込めない場面があります。具体的な設計ギャップと代替方法は、次の記事で詳しく整理しています。
データベースは構築後も変化し続ける
システム基盤との大きな違いの一つは、構築後も継続的な調整が必要になることです。
サーバーやOSは、構築時に適切な構成を決めれば、稼働後に設定を大きく変えずに運用できるケースもあります。
データベースでは、データ量や分布、利用者数、業務処理の内容が日々変化します。昨日まで高速だったSQLが、データの増加や統計情報、実行計画の変化によって突然遅くなることもあります。
一つのSQLを改善して終わりとは限りません。業務機能の追加やデータ量の増加によって別の処理が遅くなり、新たな実行計画の変化が発生します。
稼働後も監視、分析、改善を繰り返すのが、データベース運用の実態です。
性能問題はデータベースだけでは解決できない
性能問題が発生した場合、CPUやメモリの使用率を見るだけでは原因を特定できません。
遅いSQLを特定し、実行計画や待機状況を確認しながら、検索対象となるデータ量、結合順序、アクセスパス、統計情報、キャッシュの状態、I/O、ロック競合などを横断的に調べます。
同じSQLでも、必要なデータがメモリ上にあるか、ストレージから読み込むかによって処理時間は変わります。過去に生成された実行計画が再利用されるか、新しい実行計画が選ばれるかによっても、性能は大きく変化します。
性能問題をデータベースの設定だけで解決できるケースは、実際にはそれほど多くありません。
SQLや業務ロジックそのものに原因があれば、データベース側のパラメータを変更しても根本的な改善にはなりません。
改善策は、インデックスの追加や変更、統計情報の更新、必要に応じたSQLヒントの付与といったデータベース側の対応に限りません。SQLの書き換え、処理の分割、検索条件の見直し、データの持ち方の変更が必要になることもあります。
接続数やトランザクション管理に問題があれば、AP基盤チームへコネクションプールや共通処理の修正を依頼します。
CPUやストレージI/Oが不足していれば、システム基盤チームとリソース増強や構成変更を検討します。業務ルールを実装した共通部品が非効率であれば、アプリケーションチームの改修が欠かせません。
私がOracle DBAを担当していたときも、性能問題が起きると、まずデータベースが疑われることが少なくありませんでした。
調査を進めると、原因がSQL、業務ロジック、接続方式、共通部品、ストレージなど、別の領域にあるケースも多くありました。
データベースは多くのアプリケーションから共通して利用されます。問題が起きれば複数の業務機能へ同時に影響し、データベースエンジニアは調査と調整の中心に立つことになります。
権限とロールはアプリケーションと切り離せない
権限とロールの設計も、アプリケーションとの調整が避けられない領域です。
既存システムを引き継いだとき、アプリケーションのスキーマにDBA相当のロールがそのまま付与されていたことがありました。
セキュリティ要件の観点で認められる状態ではなく、必要な権限だけを個別に付与する形へ絞り込むことになりました。
権限を外した結果、これまで動いていた処理が動かなくなりました。どの処理がどのオブジェクトへどう触れているのかを整理した資料はアプリケーションチームにも残っておらず、発生したエラーと処理を突き合わせながら、必要な権限を一つずつ特定していく作業になりました。
権限を細かく制限するほど、影響確認と試験にも相応の工数がかかります。
マネージドサービスでは、この制約がさらに強くなります。
RDS for OracleではSYSDBA権限そのものが提供されず、管理操作は用意されたパッケージ経由に限定されます。オンプレミスで当たり前に実行していた手順が使えない前提で、権限の設計と運用手順を組み立て直す必要があります。
監査ログは出せばよいわけではない
監査も、要件を満たす設定を入れれば終わりという作業ではありません。
とりあえず監査ログを出力する設定にしたところ、膨大な量のログが出力され、何を監査対象とするのかを決める作業の方が大変でした。
すべてのSQLを記録すれば、性能とストレージへ影響します。絞りすぎれば、問題が起きたときに誰が何をしたのか説明できません。
特定のテーブルへのアクセスだけを対象にするのか、更新だけでなく参照まで含めるのか、保持期間をどれだけにするのかを、業務要件と法令要件の両面から決めます。
個人情報や決済に関わるデータでは、誰がいつどのデータへ触れたのかを後から説明できることが求められます。
共通のアプリケーションユーザーで接続していれば、データベース側の記録だけでは実際の利用者までたどれません。
アプリケーションのログと突き合わせて追跡できる設計にするのか、クライアント識別情報をデータベースへ渡してもらうのかを、アプリケーションチームと事前に決めておく必要があります。
監視も、稼働状況を眺めるためのものではありません。
表領域の使用率と増加傾向、権限の変更、想定外の接続元、監査ログが想定どおり出力・保管されているかなど、業務が止まる前に気づくべき事象と、後から説明を求められる事象の両方を対象にします。
冗長化しても業務を継続できるとは限らない
データベースの可用性を高めるには、障害が発生してからデータを復旧するだけでなく、待機系へ切り替えて業務を継続できる構成も設計します。
オンプレミスではRACやData Guard、クラウドではRDSのMulti-AZなど、障害の範囲、許容停止時間、許容できるデータ損失、費用に応じて方式を選びます。
冗長化構成を用意しても、データベースが待機系へ切り替わるだけで業務を継続できるとは限りません。
アプリケーションの再接続、接続プールの回復、DNSキャッシュ、切り替え中に失敗した処理の扱いまで含め、システム全体の復旧動作を設計します。
私が担当したシステムでは、正常時の通信遅延を抑えるため、WebサーバーとAPサーバーをRDSのプライマリと同じAZ側へ寄せて稼働させていました。正常時の性能を優先しつつ、障害時にはRDSが別のAZへ切り替わることを前提とした構成です。
RDSが別のAZへフェイルオーバーすると、Web／APサーバーとデータベースの通信がAZをまたぐ場合があります。通信経路が変わればレイテンシーも変化し、データベースアクセスの多い業務では性能へ影響する可能性があります。
確認すべきなのは、フェイルオーバーが成功したかどうかだけではありません。RDSが反対側のAZへ切り替わった状態でも、オンライン処理の応答時間やバッチ処理時間が要件内に収まるのかを試験します。
通常時と同じ性能を維持できない場合には、あらかじめ定めた縮退運転の条件で業務を継続できることまで確認します。Web／APサーバーを別AZ側へ切り替える構成であれば、アプリケーションとデータベースを同じAZ側で動かせるかも検証対象です。
RDS Multi-AZで自動化されるのは、データベース側の待機系への切り替えです。その後にアプリケーションが正常に再接続し、性能要件や縮退要件を満たして業務を再開できるかは、利用者側で設計し、試験しなければなりません。
バックアップがあっても復旧できるとは限らない
データベースに障害が発生すれば、システム全体が停止したり、複数の業務が同時に利用できなくなったりする可能性があります。データの破損や消失が起きれば、サーバーを再起動するだけでは復旧できません。
重要なのは、どの時点まで戻すのかという要件を、事前にアプリケーションチームと合意しておくことです。
前日の夜間バックアップまで戻してよいのか、障害の直前まで戻す必要があるのか。直前まで戻す要件があるなら、アーカイブログモードで運用し、アーカイブログの出力先、退避方法、保持期間まで設計に含めます。
判断が難しいのは、夜間バッチの途中で障害が発生した場合です。
どのジョブまで完了していたのか、どこまで戻せば再実行できるのか、中途半端な状態で残ったデータをどう扱うのかは、データベース側だけでは決められません。
復旧の目標時間と、戻した後に業務をどの順番で再開するのかを含めて、アプリケーションチームと一緒に決めます。バックアップを取得しているだけでは不十分です。
データファイルが壊れた場合、誤って大量のデータを削除した場合、バッチの途中で停止した場合では、手順も所要時間も変わります。
ユースケースごとに、実際にリストアとリカバリを実施します。本当に戻るのか、目標時間内に終わるのか、戻した後にアプリケーションが正しく動くのかを、アプリケーションチームと合同で確認しておきます。
RDSの復元は元のインスタンスを巻き戻す処理ではない
マネージドサービスを利用する場合も、復旧方法を事前に決めておく必要があります。
RDSのポイントインタイムリカバリでは、バックアップ保持期間内の任意の時点へ復元できます。ただし、トランザクションログは通常5分間隔でAmazon S3へアップロードされるため、指定できる最新の復元時点は現在時刻より数分前になることがあります。実際に復元可能な最新時点は、LatestRestorableTimeで確認します。
注意が必要なのは、指定した時点の状態が新しいDBインスタンスとして作成され、元のインスタンスが巻き戻るわけではないことです。
復旧時間には、新しいインスタンスの作成だけでなく、利用中の接続先を復元後のインスタンスへ切り替える時間も含まれます。
アプリケーションがRDSのエンドポイントを直接参照するのか、DNS名で接続先を抽象化するのかを含め、切り替え方式を事前に設計しておかなければ、復旧目標時間には収まりません。
旧インスタンスをいつ削除するのか、切り戻す余地をどこまで残すのかも決めておきます。戻す単位にも制約があります。
この復元方式では、DBインスタンス全体が新しいインスタンスとして作成されます。既存のDBインスタンスを過去の状態へ戻したり、特定のテーブルだけを1時間前の状態へ戻したりする機能ではありません。
誤更新への対応では、復元した別インスタンスから対象データを抽出して取り込むなど、別の方式を組み合わせる必要があります。
データベース製品によって、アーキテクチャと設計上の判断は変わる
以上、Oracleを主な例として説明しました。
近年は、一つのシステムでも、業務データにはリレーショナルデータベース、ログや非定型データには別のデータストアを利用するなど、用途に応じて複数の製品を組み合わせる構成も増えています。
データベースエンジニアが、特定の製品だけを理解していればよい場面は少なくなりつつあります。求められる製品や要件に合わせ、知識を更新しながら、新たな仕組みへ対応しなければなりません。
同じリレーショナルデータベースでも、Oracle、PostgreSQL、MySQLでは、運用機能、可用性構成、拡張方式、チューニングの考え方に違いがあります。
OSはAmazon LinuxからRed Hat Enterprise Linuxへ変わっても、プロセス、メモリ、ファイルシステム、権限管理など、基本的な仕組みや設計の考え方には共通する部分があります。
データベースは、製品の種類が変わると設計思想そのものが大きく変わることがあります。
OracleのようなリレーショナルデータベースとMongoDBのようなドキュメント指向データベースでは、データの持ち方、整合性の考え方、検索方法、拡張方式まで異なります。
製品が変われば、操作方法だけでなく、データモデルやトランザクション、可用性、性能設計の前提から学び直さなければならないこともあります。ここにも、データベースエンジニアという職種の難しさがあります。
まとめ
データベースエンジニアは、データベース製品を構築するだけの担当者ではありません。
アプリケーションの処理を理解して性能問題の原因を横断的に分析し、権限や監査の要件を業務と擦り合わせ、障害が起きてもデータを失わずに業務を再開できる状態を維持し続ける役割です。
データベースは多くのアプリケーションから共通して利用され、データ量や処理内容も稼働後に変化し続けます。
構築が終わっても仕事は終わらず、性能問題や障害が起きれば、データベースエンジニアが原因分析と関係チームの調整の中心に立ちます。
データ量が増えても必要な性能を保ち、稼働後もデータの安全性と業務継続を支える。その責任を担いながら、採用する製品や要件の変化に応じて知識を更新し、新しい設計思想へ適応し続けるところに、データベースエンジニアの専門性があります。
関連記事
SEは一つの職種ではありません。アプリケーション、AP基盤、システム基盤・クラウド、ネットワーク、プロジェクト管理など、ほかの職種との違いは次の記事で整理しています。
システムエンジニアの種類と仕事内容｜SIerのSEはどこまで担当するのか
各職種についても、今後個別の記事で詳しく解説していきます。
コメント