7. データベースのマネージドサービス化
2026/04/22 公開
クラウド環境ではデータベースのマネージドサービスが提供されており、ハードウェア・OS・データベースソフトウェアの管理はCSPの責任範囲となる。さらに、HA構成・自動バックアップ・リードレプリカ・リージョン間レプリケーションがサービス設定のみで実現できるため、データベース運用の自動化と高可用性を低コストで達成できる。
ただし、オンプレミス環境でデータベースサーバーのOS上で動作させていたバッチ処理や運用スクリプト、最上位特権を必要とする操作については、マネージドサービスへの移行に伴い実行環境や操作方式の変更が必要となる点に留意が必要である。特にバッチ処理については、データベースサーバー外への移動に伴うネットワークレイテンシーの影響で処理が長時間化するケースが多いため、早期に性能検証を実施し、問題がある場合に備えてプロジェクトスケジュールに余裕を持たせることを推奨する。具体的な対策については7.3節を参照。
7.1 オンプレミスデータベース方式のクラウド移行
以下に、オンプレミス環境で一般的に実施されているデータベース方式ごとの移行方針を示す。
表7-1 データベース方式別クラウド移行方針
| データベース検討ポイント | クラウド移行時の対応 | 説明 |
|---|---|---|
| RDBのマネージドサービス化（マネージドサービス対応エンジン） | 追加作業あり | MySQL・PostgreSQL・SQL Server・Oracle等、主要なRDBエンジンはCSPによってマネージドサービスとして提供されている。ハードウェア・OS・データベースソフトウェアの管理はCSPの責任範囲となる。移行前後での動作検証（ノンデグレーションテスト）の実施が必要。 |
| RDBの仮想マシン構成（マネージドサービス非対応エンジン） | 設計変更が必要 | データベースエンジンとCSPの組み合わせによってはマネージドサービスが提供されていない場合がある。その場合は仮想マシン上へのインストール構成となるが、可能な限りマネージドサービスに対応したエンジンへの移行を検討することを推奨する。 |
| データベースサーバー上のバッチ処理・運用スクリプト | 設計変更が必要 | マネージドサービスではOS領域が利用システムの管理対象外となるため、データベースサーバーのOS上で動作していたバッチ処理や運用スクリプトは別環境での実行に変更が必要。バッチサーバーの準備や、クラウドが提供するサーバーレス実行環境の活用を検討すること。 なお、バッチ処理の移行に伴うネットワークレイテンシーの影響については本章冒頭を参照。 |
| 最上位特権を必要とする操作（sysdba・SUPER等） | 設計変更が必要 | マネージドサービスでは最上位特権は利用できない。該当する操作はデータベースサービスのパラメータ設定機能等を利用する方式に見直す必要がある。 |
| HA構成（冗長化・自動フェイルオーバー） | 設定のみで対応可能 | データベースのマネージドサービスではHA構成オプションが提供されており、サービス設定のみでスタンバイ環境の構築と自動フェイルオーバーを実現できる。個別に冗長構成を構築する必要はない。 |
| データベースのバックアップ | 設定のみで対応可能 | データベースのマネージドサービスでは自動バックアップ機能が標準で提供されており、保管期間の設定のみで自動的にバックアップが取得される。バックアップサーバーの構築は不要。 |
| リードレプリカ（読み取り性能の拡張） | 設定のみで対応可能 | データベースのマネージドサービスではリードレプリカの追加がサービス設定のみで実現できる。導入時は必要最低限の台数から始め、負荷に応じて追加することを推奨する。 |
| リージョン間レプリケーション（災害対策） | 設定のみで対応可能 | データベースのマネージドサービスではリージョンを跨いだレプリケーション機能が提供されており、サービス設定のみで遠隔地への災害対策を実現できる。物理的な媒体搬送は不要となる。 |
7.2 クラウド環境で新たに必要なデータベース設計
クラウド環境への移行にあたっては、オンプレミス環境にはなかった以下のデータベース設計を新たに検討する必要がある。
表7-2 クラウド環境で新たに必要なデータベース設計
| 項目 | 説明 |
|---|---|
| データベースエンジンバージョンの管理 | マネージドサービスではCSPがデータベースソフトウェアのパッチ適用・バージョンアップを管理するため、利用システム側でパッチ適用タイミングやバージョンを任意に制御できない場合がある点に留意が必要である。サポート終了バージョンの利用継続リスクを把握した上で、バージョンアップ計画を事前に策定する。 |
| 接続数・リソースの設計 | マネージドサービスでは選択するインスタンスサイズに応じて最大接続数やリソース上限が定まる。アプリケーションからの接続数設計とインスタンスサイズの選定を合わせて検討する。 |
| NoSQLデータベースの活用検討 | クラウドではRDBに加え、拡張性・可用性に優れるNoSQLデータベースのマネージドサービスも提供されている。システムの特性（大量データの読み書き・柔軟なスキーマ設計等）に応じてNoSQLの活用を検討する。 なお、R1（Replatform）ではアプリケーション改修を伴うためNoSQLへの移行は難しいことが想定されるが、R2（Rebuild）ではクラウドのより有効な活用の観点から検討を行うことを推奨する。 |
| コスト最適化（インスタンスサイズの適正化） | クラウドのデータベースサービスはインスタンスサイズに応じた従量課金となる。導入時は必要最低限のサイズから始め、運用の過程で負荷状況に応じてサイズを見直すことでコストを最適化する。詳細は9章を参照。 |
7.3 バッチ処理のネットワークレイテンシー対策
データベースのマネージドサービス化に伴いバッチ処理をデータベースサーバー外に移動した場合、ネットワークレイテンシーの影響で処理が長時間化するケースが多い。性能検証の結果、問題が確認された場合、表7-3に示す代表的な対策例を参考に対策を検討すること。
表7-3 バッチ処理のネットワークレイテンシー対策
| 対策 | 内容 | 効果・留意事項 |
|---|---|---|
| SQL発行回数の削減 | ループ内での1件ずつのSQL発行を、一括UPDATE/INSERT等の単一SQL発行に変更する | ネットワーク往復回数をN回から1回に削減できる。 |
| ストアドプロシージャの活用 | 複数のSQL処理をストアドプロシージャとしてデータベース内部で完結させる | ネットワーク往復をほぼゼロにできる。ただしDBエンジン変更を伴う場合は書き直しが必要となる点に留意する。 |
| バッチ処理の抜本的見直し | 上記の対策でも解決しない場合は、夜間一括処理のイベントドリブン化・データ処理のDB内完結化・処理の並列化等を検討する | 処理方式の根本的な改善によりレイテンシーの影響を排除できる。 |
| 同一耐障害性ゾーン（※1）への配置 | バッチサーバーをデータベースと同一耐障害性ゾーンに配置する | 異なる耐障害性ゾーンをまたぐ通信と比較してレイテンシーを低減できる ただし、同一耐障害性ゾーンへの配置は耐障害性ゾーン単位での冗長化が難しくなるため、他の対策で解決できない場合の最終手段として検討すること。 |
7.4 参考資料
7.4.1 CSP別 技術ガイド
オンプレミス環境からクラウドのマネージドサービスのデータベースへの移行の際の考慮事項をまとめている。検討の際の参考としていただきたい。