これからのOracle Databaseの主流！マルチテナント・コンテナ・データベースに触れる

こんにちは。Airitechでトラブルシュート＆システム性能サービスに携わっているエンジニアの角（かく）です。

本稿ではOracle Databaseのマルチテナント・アーキテクチャについて、紹介していきたいと思います。非マルチテナント構成のデータベースは20cからサポート終了の予定となっていますので、Oracle Database エンジニアとしては今後、理解が必須の機能となりますね。

1. マルチテナント・アーキテクチャの概要

Oracle Databaseにおけるマルチテナント・アーキテクチャの概念は「データベースの中にデータベースを作る」という表現が手っ取り早いです。厳密にはマルチテナント管理用のメタデータが格納されているデータベース（CDB）の中に、実際のユーザーデータを管理する複数のデータベース（PDB）が格納されています。このユーザーデータの入っているデータベースはそれぞれ独立したデータベースとして利用できる、というものとなります。

　CDB=Docker Engine、 PDB=Dockerコンテナとイメージしてもらうと概要を理解しやすいかと思います。マルチテナント構成では、データベースインスタンスの中にCDBがあり、そこにいくつもPDBがぶら下がり、PDBそれぞれが1つのデータベースとして動作します。

図中の「マルチテナント構成」に記載されているCDB$ROOTはルート・コンテナと呼ばれるものでコンテナ・データベース（CDB）そのものです。マルチテナント・データベース全体のリソース管理を行ったり、共通スキーマ、共通スキーマオブジェクトが格納されています。ほかにもPDB$SEEDというPDBが突然登場していますが、これは各PDBのテンプレートとなります。新規にPDBを作成する場合は、PDBはPDB$SEEDのコピーとして作成されます。

2. マルチテナント・アーキテクチャのメリット

冒頭にも書きましたが、このマルチテナント・アーキテクチャを導入することで何が得られるのか。Oracle社からも各種の利点は提示されています。

・高密度の統合
・SQLによる迅速なプロビジョニングとクローニング
・高速のパッチ適用とアップグレードの新たなパラダイム
・多数のデータベースを一元管理
・プラガブル・データベースのリソース管理
引用元：Oracle Multitenant

しかしながら私が最も注目しているのは「データベースの独立性の担保」です。顧客ごとにPDBを割り当て、個別のデータベースとして管理することで、スキーマレベルでも物理ファイルレベルでもデータが分割管理されますので、顧客ごとにデータが論理的にも物理的にも隔離された環境となります。これにより、アプリケーションのバグやSQLインジェクションなどで、本来は表示されるべきではない無関係な顧客のデータが表示されてしまうようなインシデントを引き起こすことがなくなります。

3. マルチテナント・アーキテクチャが活きるシーン

ここからは私の過去の経験から、このマルチテナント・アーキテクチャが有効に機能すると思われるシーンを紹介していきます。

1) 組織統合による複数データベースの統合

一昔前のことでしたが、とあるお客様より「ある3つの組織A、組織B、組織Cの統合により、それぞれ個別に運用されてきた3つの同一アプリケーションのデータベース（DB-A、DB-B、DB-C）を、1つの筐体、できれば1つのインスタンスへ統合してほしい」というご相談をいただきました。

　その当時のOracle Databaseでのデータベース統合のセオリーは「スキーマ名を変え1つのインスタンスへデータインポートを行う」あるいは「1サーバに複数のインスタンスを起動させる」というもの。この案件では稼働させるためのサーバは既に購入されており、追加で2つのインスタンスを起動できる性能のサーバは用意できないということでしたので、当時の私はご多分に漏れず1インスタンスにスキーマ名を変えてデータを統合する方法でのデータ移行をお客様へご提案し、目的を達成しました。

ですが、このときにマルチテナント・アーキテクチャが存在していたら、CDBを利用することにより、それぞれの組織で運用されてきたデータベースをスキーマ名を変えることもなくPDBに移行することができ、容易にデータベースの統合ができたことでしょう。

2) Webサービスのデータベース水平分割

あるWebサービスの基幹となるデータベースは数年間のサービス運用に伴いデータが大量に蓄積され、極端にレスポンスが悪くなっていました。
当時、私はこのサービスの性能改善チームの一員として活動しており、性能改善チームでは「今後数年にわたりサービスを提供、運用していくうえで、如何に性能劣化を起こさない構成とするか」を検討していました。

　そのときに性能改善チーム内で至った結論は「すべてのユーザーのデータを1つのデータベースに投入するから、データサイズが肥大化し、パフォーマンス劣化が起きる」というものでした。そのため、次のバージョンアップの際には長期運用を行っても支障のないデータサイズに収まるよう1つのデータベースに収容するユーザー数上限を定め、それをたくさん横に並べて運用することでパフォーマンス劣化を防ごう、という、それ自体は水平パーティショニングと同じ発想です。

この場合、とにかくデータを小分けにするための器としてデータベースが存在していれば良いので、当時の状況であれば、マルチテナント・アーキテクチャのメリットを十分に活用できた、とは言えないでしょう。しかしながら、同一インスタンスの迅速な水平展開のために「PDB$SEEDを使用したPDBのプロビジョニング」を利用できますし、「リソースマネージャー」を使用して各PDBに均等にサーバリソース配分を行い、特定のPDBが他のPDBのパフォーマンスに悪影響を与えないよう予防措置を取ることもできます。

　ほかにも「PDBの接続・切断が容易に行える」ためデータ移行が簡単になりますので、極端にサーバリソースを消費する傾向のあるPDBを性能に余裕のある別の物理サーバに容易に移行できます。同様の理由でマルチテナント・アーキテクチャのOracle Databaseが稼働する物理サーバのスケールアップの作業工程もとてもシンプルなものになります。

　またOracle Database自体のパッチ適用やバージョンアップはCDBに対して実行するだけでよく、このようにOracle Databaseのマルチテナント・アーキテクチャは、長期のオンプレミスでのデータベース運用を踏まえた場合に、十二分なメリットを享受できるものと言えるでしょう。

3.終わりに

駆け足でマルチテナント・アーキテクチャと活用シーンの紹介をしてきましたが、いかがでしたか？今回取り上げたシーンのほかにも、Oracle Databaseのマルチテナント・アーキテクチャが活きる場面はたくさんあります。

本稿でOracle Databaseのマルチテナント・アーキテクチャの利点を少しでもお伝えできていたら幸いです。

次回はマルチテナント・アーキテクチャの中でも私自身も結構理解に苦しんだ「アプリケーション・コンテナ」について、ご紹介できればと思っております。

　Airitechでは、スキル向上の意欲がある方、新規プロダクトやサービスの開発に意欲のある方を募集しています。

Airitechの採用情報はこちら
https://www.airitech.co.jp/recruit/