1. 業務システムの増加で膨らむ、データベース運用の負担
一成長企業では、注文、決済、ユーザー管理、マーケティング、レポート作成という5つの業務システムを運用しています。各システムにMySQLインスタンスを用意し、独立して稼働させています。一見すると問題のない構成ですが、コストや運用の実態を見ると、ある課題が浮かび上がります。データベースインスタンスは増え続けているのに、リソースを十分に活用できていないのです。
-
5つのインスタンスに5台のサーバー
決済システムのデータベースがサーバーリソースの20%も使っていなくても、別のデータベースを同じサーバーに配置することには慎重になります。リソースの競合が本番環境の障害につながるおそれがあるためです。 -
5つのインスタンスに、インスタンスごとの運用手順
監視の仕組みを個別に構築し、バックアップをそれぞれ実行し、アップグレードの日程も個別に調整します。運用チームは、複数のツールや手順を使い分けなければなりません。 -
集約したくても踏み切れない
インスタンスを共有すると、マーケティングシステムのバッチ処理によって決済処理の性能が不安定になる可能性があります。一般的なクラウドデータベースを採用する場合も、分離の単位が粗く、アプリケーションごとの性能保証や責任範囲の明確化が難しいのではないかという懸念が残ります。
従来の選択肢には、それぞれトレードオフがあります。インスタンスを分けるとリソースが余り、管理も分散します。一方、共有するとリソースが競合し、業務同士が影響し合います。一般的なクラウドデータベースでも、重要業務のSLAや規制要件を満たすために必要な、きめ細かな分離ができるとは限りません。
コスト面から見ると、5つのインスタンスを運用するには、5台のサーバー、インスタンスごとの運用ツール、構成や契約によっては、商用ライセンスやサポートの費用も増加します。これは中小規模の企業を想定した例ですが、金融機関や官公庁、インターネットサービス事業者などが数百の業務システムを運用する場合、インスタンス数の増加に伴い、コスト、管理負荷、安定稼働を維持する負担も大きくなります。
独立したインスタンスと同じように業務を分離しながら、リソースをプール化して一元管理し、利用率を高めることはできないのでしょうか。
2. 複数の業務システムを管理する、3つの選択肢と課題
複数の業務システムを持つ多くの企業が、個別にデプロイするか、集約して共有するかを検討しています。しかし、実際に本番環境で運用すると、どの方法にも課題があります。
| 選択肢 | 構成の考え方 | 主な課題 |
|---|---|---|
| 独立したインスタンス | 業務システムごとに専用のデータベースを用意する | リソース利用率が低く、無駄なコストが発生する |
| インスタンスの共有 | 複数の業務システムで1つのデータベースを共有する | リソースの競合が性能に影響する |
| クラウドネイティブデータベース | クラウドデータベースのテナント機能を利用する | 分離の単位が粗く、SLAの達成が難しい |
独立したインスタンス：業務ごとに専用サーバーへ配置する構成を想定し、小さなデータベースにもサーバー1台が必要
独立したインスタンスは、最も多くの企業が採用する構成です。業務ごとにデータベースを分ければ、管理範囲が明確になり、障害の影響も切り離せるため、堅実な選択に見えます。しかし、実際のリソース使用量にかかわらず、小規模なデータベースにもサーバーを1台割り当てるという問題があります。
では、1台のサーバーにいくつのデータベースを配置すればよいのでしょうか。1つだけでは、リソースが長期間余ってしまいます。2つ配置すると、一方のバッチ処理がI/Oを使い切り、もう一方のオンライン取引に影響するかもしれません。従来の構成では、リソースの無駄を減らすことと、業務間の影響を防ぐことを両立しにくいのです。
結果として、$N$個の小規模なデータベースに$N$台のサーバーを用意することになり、ハードウェア、運用、ライセンスのコストがインスタンス数に比例して増加します。
さらに、$N$個のインスタンスそれぞれに、監視、バックアップポリシー、アップグレード手順が必要です。運用チームは、同じような管理作業を繰り返すことに時間を費やしてしまいます。
インスタンスの共有：コスト削減と引き換えに生じる性能への影響
コストを抑えるため、複数の業務システムを同じインスタンスに集約する企業もあります。直接的な費用は下がりますが、性能の安定性は保証できません。
マーケティングシステムでバッチ処理を実行した途端、決済処理の応答時間が急増する。レポートシステムで大規模なクエリを実行すると、基幹業務である注文データの書き込みが待たされる。こうした問題は、業務部門からの苦情やユーザー体験の悪化につながります。
最終的には、データベースを再び独立したインスタンスに分割し、元の構成に戻ってしまうこともあります。
クラウドネイティブデータベース：リソース分離とコンプライアンスの課題
クラウドデータベースには一定のマルチテナント機能がありますが、多くの構成では分離の単位がインスタンスやスキーマにとどまります。そのため、アプリケーション単位でCPU、メモリ、I/Oを細かく制御することは困難です。
金融などの業種では、基幹システムと周辺システムの分離や、操作履歴の監査・追跡が、規制対応と内部統制における重要な論点になります。大まかな単位でしか分離できない構成では、技術チームの懸念を十分に解消できません。
どの構成を選んでも、コストや運用、性能の面で課題が残ります。業務ごとの独立性を保ちながら、管理をまとめ、余っているリソースを有効に使えないでしょうか。
3. 業務ごとに建物を持つ構成から、オフィスビルを共用する構成へ
この違いを建物に例えてみましょう。
従来の構成は、5棟の独立した建物に相当します。それぞれに空調設備、警備、清掃が必要で、設備や人員を共用できません。建物ごとに管理する必要もあるため、5棟あれば5棟分の管理業務が発生し、棟数に比例して管理コストが増えていきます。
一方、マルチテナント構成は、複数の企業が入居する1棟のオフィスビルに相当します。空調、警備、清掃を一元管理し、必要に応じて設備や人員を配分することで、利用効率を高められます。
さらに重要なのは、ビル全体を管理する共通の管理センターがあることです。OceanBaseでは、OCP（OceanBase Control Platform）がこの役割を担います。ビルの防犯監視、設備保守、リソース配分をまとめて管理するように、1つの管理画面から全体の稼働状況を把握できます。
複数のデータベースを集約すると、リソースの無駄を減らせるだけでなく、個別に行っていた監視やバックアップなどの運用も一元化できます。
リソースのプール化：小規模なデータベースにサーバーを占有させない
OceanBaseのマルチテナントアーキテクチャでは、複数の小規模なデータベースを1つのクラスターに集約できます。これにより、小さなデータベースがサーバー1台を占有する無駄を減らせます。
リソースは、先に使い始めた業務がそのまま占有するのではなく、共通のリソースプールからテナントごとに割り当てます。決済システムには安定したリソース枠を確保し、マーケティングシステムには必要に応じてリソースを割り当てます。レポートシステムの大規模なクエリも、そのテナントに割り当てられたリソースの範囲内で実行できます。
同じクラスターに集約しても、業務同士が無制限にリソースを奪い合うわけではありません。 これを支えるのが、テナント単位のきめ細かなリソース分離です。
きめ細かなリソース分離：基幹業務への影響を防ぐ
OceanBaseでは、テナント単位でCPU、メモリ、I/Oを分離し、リソースクォータを設定できます。決済や会計などの基幹業務と、マーケティングやレポート作成などの非基幹業務を別々のテナントに配置し、基幹業務のテナントには必要なリソース枠を確保する一方、非基幹業務のテナントには使用量の上限を設定します。
非基幹業務でバッチ処理の負荷が増えても、基幹業務のリソースを無制限に消費することはありません。性能の確保は、物理的に分離する方法だけでなく、クォータによるリソース分離でも実現できます。
OCPによる一元管理：すべてのクラスターとテナントを1つの画面で管理
OCPを使えば、各クラスターやテナントの監視・運用を1つの管理画面にまとめられます。
- 監視：すべてのクラスターとテナントの稼働状況を把握し、基幹業務のテナントのアラートを最優先で扱います。
- 運用管理：リソースの拡張・縮小、構成変更、フェイルオーバーを、インスタンスごとに個別対応することなく一元的に実行できます。
- バックアップとアップグレード：ポリシーやスケジュールを統一し、インスタンスごとに調整する負担を減らします。
従来は、$N$個のインスタンスを管理するために、それぞれの監視ツール、バックアップの実行時間帯、アップグレード日程を管理していました。OCPでクラスターとテナントを一元管理すれば、運用チームはインスタンスごとの個別対応から、共通プラットフォームを使った集中管理へ移行できます。
4. コスト・性能・運用効率・コンプライアンスへの効果
コスト：余剰リソースと重複投資を減らす
マルチテナント構成では、複数の業務システムを少数のクラスターノードに集約し、テナントごとのクォータに基づいてCPU、メモリ、I/Oを割り当てます。小規模なデータベースごとにサーバーを専有する必要がなくなり、余っていたリソースを活用できます。
リソースの配分は、業務の重要度に応じて調整します。基幹取引のテナントには安定稼働に必要なリソース枠を確保し、マーケティングやレポート作成などの非基幹業務には、必要に応じて割り当てます。業務ごとにピーク負荷に備えた余力を過剰に確保せずに済むため、リソースの無駄を減らせます。
重要なのは、単にデータベースを詰め込むのではなく、プール化したリソースを業務の重要度に応じて再配分することです。基幹取引のテナントには安定したクォータを確保し、マーケティングやレポート作成などの非基幹業務には、必要に応じてリソースを割り当てます。これにより、未使用リソースを減らすとともに、各インスタンスにピーク時の負荷を見越した過剰な余力を持たせずに済みます。
インフラ面では、OceanBaseは汎用的なx86／ARMなどのアーキテクチャで稼働します。従来のメインフレーム、ミッドレンジサーバー、集中型ストレージを使う構成と比べて、明確なコスト優位性があります。また、データ圧縮により、ストレージ使用量を圧縮前の1/3〜1/9に削減できます。
性能：業務ごとのリソース配分で安定性を高める
テナント単位でリソースを分離することで、業務間の性能への影響を防げます。基幹業務と周辺業務、トランザクション処理とバッチ処理、オンライン業務とオフライン分析を別々のテナントに配置し、それぞれにCPU、メモリ、I/Oのクォータを設定できます。複数の業務で1つのデータベースを共有する場合に起こりがちな、1つのバッチ処理がすべての業務を遅くする問題を防ぐ仕組みです。
この構成では、物理的に環境を分ける代わりに、クォータで各業務が使用するリソースを管理します。基幹業務のテナントに安定したリソース枠を確保できるため、非基幹業務で大規模なクエリ、バッチ処理、レポート生成の負荷が増えても、基幹業務のリソースを無制限に消費することはありません。その結果、基幹業務でSLAを満たせるかどうか、見通しを立てやすくなります。
運用効率：分散した管理を1つのプラットフォームに集約する
運用効率は、管理を集約することで向上します。従来は、$N$個のインスタンスそれぞれについて、監視やバックアップポリシー、アップグレード日程を管理していました。
OCPを使えば、1つの管理画面でクラスターとテナントの状態を確認し、監視、運用管理、バックアップ、アップグレードを一元的に実施できます。
運用チームの仕事も、各インスタンスを順番に点検して対応する方法から、共通プラットフォームで全体を管理する方法へと変わります。また、SQL方言、監視、バックアップ、運用管理の仕組みを統一することで、開発・テスト・運用チーム間の連携にかかる負担も減らせます。
コンプライアンス：分離範囲と責任範囲を明確にする
コンプライアンス面では、業務間の分離範囲と管理上の責任範囲を明確にできます。業務システムを別々のテナントに配置することで、テナント間のリソースと権限を分離し、操作履歴を追跡できます。監査や規制当局の検査でも、「誰が何にアクセスしたか」「誰がどの操作を実行したか」「影響がどこまで及ぶか」を説明しやすくなります。
また、分離要件を満たすために、専用インスタンスを個別に構築するコストも抑えられます。従来は、基幹業務と周辺業務、本番処理と分析処理、異なる顧客の環境を分離するために、複数のデータベース環境を用意する必要がありました。
マルチテナント構成では、共通のクラスター内でテナントを分けることで、分離と監査を実現できます。管理上の要件を満たしながら、重複した環境構築を減らせます。
5. 業種ごとに見る活用例
複数の業務システムを管理する課題は、さまざまな業種に共通しています。ただし、重視する点は異なります。金融では規制に対応した分離と基幹処理の安定性、ECでは大型セール時のアクセス急増への対応、SaaSでは顧客数の増加に対応した環境提供の効率が重要です。
ここでは、代表的な3つのケースを取り上げます。
フィンテック：基幹業務と周辺業務を分離し、重要度に応じたSLAを設定
-
要件
会計、決済・清算などの基幹システムと、顧客チャネル、レポートなどの周辺システムを分離し、監査可能な状態で運用する必要があります。周辺システムのバッチ処理やクエリの負荷が増えても、基幹システムのオンライン処理を停止させてはなりません。また、データの分離と操作履歴の追跡には、規制上の明確な要件があります。 -
OceanBaseによる構成
基幹システムと周辺システムを別々のテナントに配置し、CPU、メモリ、I/Oのクォータによってリソースを分離します。OCPで全テナントを一元監視し、基幹業務のテナントには、より高いアラート優先度を設定します。 -
導入効果
監視、バックアップ、変更管理、権限モデルを統一することで、コンプライアンス対応や監査の手順が明確になります。基幹業務でSLAを満たせるかどうか、見通しを立てやすくなるほか、周辺システムは自らのテナント内で容量や処理タスクを管理でき、基幹処理に影響を与えません。
EC：大型セール時の負荷を分離し、必要に応じてリソースを拡張
-
要件
ECのトラフィックには、平常時と大型セール時で大きな差があります。通常は安定していても、セール時には短時間で急増する可能性があります。
取引や注文などの基幹処理ではSLAを守る必要がある一方、マーケティングやレコメンドなどの非基幹業務には、柔軟なリソースの拡張・縮小が求められます。また、セール時のマーケティングシステムのバッチ処理やデータ同期によって、取引処理が停止してはなりません。 -
OceanBaseによる構成
取引とマーケティングを別々のテナントに配置します。基幹取引のテナントには十分なリソースクォータを確保し、セール時のピーク負荷によって性能が不安定になるリスクを抑えます。
マーケティングのテナントでは、必要に応じてリソースを調整し、セールの前後に迅速な拡張・縮小を行います。OCPで全体を一元監視し、セール期間中は基幹業務のテナントの状態を優先的に確認します。 -
導入効果
大型セール中も、基幹取引の性能はマーケティングのバッチ処理の影響を受けず、安定します。非基幹業務のリソースを柔軟に調整できるため、平常時の無駄を抑えながら、セール時には必要な容量を確保できます。
運用チームは、OCPの1つの画面で業務全体を監視し、緊急時の対応を行えます。複数のインスタンスを切り替えながら作業する負担も減らせます。
SaaS：顧客ごとに必要な分離とリソースを提供
-
要件
SaaSプラットフォームでは、通常、顧客ごとに専用データベースを用意するのではなく、多数の中小規模の顧客でデータベースリソースを共有します。一方、大口顧客や重要顧客、より高いコンプライアンス要件を持つ顧客には、より強い分離を提供する必要があります。
顧客数が増え、顧客区分が多様になるにつれ、共有によるリソース効率と、重要顧客に必要な分離を両立することが課題になります。 -
OceanBaseによる構成
1つのOceanBaseクラスター内で、顧客区分や分離要件に応じてテナントを分けます。一般の顧客はテナントのリソースを共有し、重要顧客には専用テナントを割り当てます。
テナント間でCPU、メモリ、I/Oを分離し、ベーシック、プロフェッショナル、エンタープライズなどのサービスプランに応じて、異なるリソースクォータを設定します。顧客向けのテナントは、OCPで一元管理します。 -
導入効果
一般の顧客はリソースプールを共有するため、顧客ごとにインスタンスを占有する無駄を避けることができます。重要顧客には、データの分離範囲と性能への影響範囲が明確な環境を提供し、より高いデータセキュリティ、コンプライアンス、SLAの要件に対応できます。
新規顧客の利用開始に必要な作業も、「インスタンスの申請→デプロイ→設定」から「テナント構成の選択→クォータの割り当て」へと短縮できます。これにより、環境の提供にかかる時間と手間を大幅に削減できます。運用チームはOCPですべてのテナントを一元管理し、複数のインスタンスを個別に運用する負担を減らせます。
6. 自社に適した構成かを判断するポイント
次のような状況にある企業では、マルチテナントアーキテクチャを検討する価値があります。
-
業務システムが多い
複数システムの開発、テスト、運用、管理を統一する必要があり、インスタンス数の増加が管理上の負担になっている。 -
小規模なデータベースが多く、リソースの無駄が目立つ
小規模なデータベースが長期間サーバーを占有している一方で、利用率は低く、少数のクラスターノードに集約したい。 -
管理を一元化したい
OCPなどの共通管理プラットフォームを使い、1つの画面ですべてのクラスターとテナントを管理したい。インスタンス、ツール、手順の増加によって生じる運用の分散を解消したい。 -
業務ごとにきめ細かく分離する必要がある
業務ごとにSLAが異なり、基幹業務と非基幹業務が互いに影響しない構成が必要になっている。 -
コストの増加が続いている
ハードウェア、クラウドリソース、ストレージ、ライセンス、運用要員にかかるコストを最適化する必要がある。
7. 共通のデータベース基盤で、継続的な運用改善へ
システムごとに独立したデータベースを用意する構成は、業務を分離しやすく、導入時にも選びやすい方法です。ただし、業務の拡大に合わせてインスタンスを増やしていくと、使われないリソースや個別の管理作業が増え、運用コストも膨らんでいきます。
OceanBaseのマルチテナントアーキテクチャでは、複数の小規模なデータベースを少数のクラスターノードに集約し、テナントごとにリソースを割り当てます。サーバーを専有する無駄を減らしながら、基幹業務と非基幹業務を分離し、それぞれの性能への影響範囲を明確にできます。
OCPを使えば、すべてのクラスターとテナントを1つの画面で管理できます。個別に行っていた監視、バックアップ、アップグレードなどの運用をまとめることで、設備費に加えて、日々の管理にかかる手間も減らせます。
業務ごとの独立性を保ちながら、リソースと運用を一元管理する。マルチテナント化は、業務システムの増加に対応しつつ、データベース運用を効率化するための選択肢です。