Autonomousを支える、自律型データベース「Oracle Database 18c」の進化

Oracle Databaseの最新バージョン「Oracle Database 18c」

日本オラクル株式会社：本日はまず、18cの全体概要のお話をした後に、マルチテナントの新機能のお話（をします）。デモがいっぱいあったので持ってきたかったんですけど、時間の関係上（持ってこられませんでした）。あとは、Autonomousっぽさが出てくるデータベース管理の機能のお話。そして、時間があれば最後に、Autonomous Data Warehouseの画面を少しお見せして終わる、という流れでがんばっていこうと思います。今日はよろしくお願いします。

では、一番最初に18cですね。18cが出てきたタイミングと同時に、Oracle、Autonomous、本日の前段の2つのセッションに紐づいて、けっこうメディアや外には出てきてると思います。なので、18cとAutonomousの位置付けについて、最初にご説明させてください。

「実はこれ、同じではないんですよ」ということが言いたかったんです。実はAutonomous Databaseは、18cやOracle Cloudを含み、それにAutonomousたらしめるCloud toolingすべてを合わせたものです。今日お話する18cはその中の技術要素であり、まさに今までのオンプレミスのOracle Databaseの最新バージョンです。それにさらにAutonomousの機能を付けたものが、Autonomous Databaseといったところです。

今日はこの18cのお話をさせていただきますが、18という数字が突如出てきまして、みなさん「18cとは？」と、けっこうびっくりされたかなと思います。

「これ、何？」というところなんですけど、まずは2018年の18です。この数字からわかるとおり、これから毎年出てくる年次リリースモデルの最初が18cです。

「なんでそうなったの？」というところなんですけども、年次という今までよりももっと早いサイクルで（リリースを）出していくことによって、より開発のスピードを上げて、品質を上げて、お客さまにご提供したい。

さらに、新機能を少しずつ少しずつ付けて、みなさんに使っていただくことで、早期に新機能を取り込んでいただいて、より良いものをご提供したいというところが、この18cになったそもそものきっかけです。

より詳しい情報はこのDocの番号がございます。みなさんのお手元の資料にもありますので、ぜひよろしければ見てみてください。

みなさんは「18になったんで、めちゃくちゃ変わっちゃうんじゃないの？」と思われるかもしれませんが、落ち着いてくださいというのがこのスライドです。

ライフタイム・サポートの考え方から申し上げると、これは今まで出ている12.2にポリシーを踏襲します。今決まっているのは、「19cまでは12.2のポリシーをサポートしていますので、大きく変わりませんよ」ということです。

データベース統合の新機能「マルチテナント・アーキテクチャ」

ではさっそく、今日の主題である新機能に入っていこうと思います。

本日お持ちした新機能は、カテゴリとしては大きく2種類です。マルチテナント・アーキテクチャとDatabaseのオペレーションの2つです。

「デモと共に」という、ちょっと料理名っぽい名前だったんですけど、それはマルチテナント・アーキテクチャのところで、少しみなさんにご覧いただこうと思います。若干地味めのデモではあるんですけども、がんばってお伝えしようと思ってます。

まず一番最初は、マルチテナント・アーキテクチャです。

ここにいらっしゃるみなさまは、かなりお詳しい方が多いと思うんですけど、マルチテナント・アーキテクチャってご存知ですかね？　けっこう現場では「まだちょっと手出してないよ」とか、「これからやろうと思ってるよ」という声をお聞きするので、みなさまはどうかなと。手を上げていただくことはないんですけど、雰囲気で（察します）。

（会場挙手）

ありがとうございます。半分（挙手をして）いただいて、ありがとうございます。「あんまり知らないよ」という方もけっこういらっしゃるようなので、この場を借りて、マルチテナント・アーキテクチャのエッセンスだけでも少しお伝えできればなと思います。

ちなみにこれ、12c標準アーキテクチャです。クラウドは必ずこれになりますので、ぜひこの場でどんなものかという雰囲気だけでも味わってもらえればと思いますし、今日の新機能もまさにこのお話になります。

まず「これ、なんでできたの？」という背景の話なんですけど、実は、金融グローバルのお客さまからのご相談によって生まれました。開発・テスト・本番などすべてを合わせると、数千におよぶくらいのデータベースをお持ちのお客様より、「もうすごい運用管理が大変、なんとかなんないの？」とご相談いただきました。

Oracleとしての答えは、マルチテナントという機能を使って、こちらの問題を解決する。より統合しやすく、より運用管理しやすく、開発もしやすい。そんなアーキテクチャがマルチテナントです。

マルチテナントのポイントは「移行しやすさ」と「リソースの共有性」

そのポイントを詳しく話すと、おそらくこれだけで私のセッションが終わっちゃうので、簡単に（ご紹介します）。覚えていただきたいのは、この3つのポイントです。

1つ目は、（このスライドの一番上の）プラガブル・データベースという名前です。この赤いドラム缶がプラガブルデータベースのことを言っています。

ここはちょっと覚えていただきたいんですけども、挿し込んだり抜いたりできる、アンプラグ、プラグ。そんな可搬性の高い、今までになかったアーキテクチャがプラガブル・データベースです。略称がPDBといいます。

持っていきやすい、クローニングがしやすいという特徴があるので、そこだけお見知りおきください。

そのPDBがブスッと挿さっている下のものをコンテナデータベース、略称CDBといいます。ポイントは、このコンテナ単位で運用管理ができることです。

だから、バックアップを取ったり、パッチを当てたりというのは、この下で一括で取れます。中に入っている赤いデータベースがたくさんあっても1回で済み、運用管理性が上がっているというのがポイントです。

そして最後の3つ目、これはその下に書いてある絵のことを意味してるんですけども、メモリであったりCPUっていう、いわゆるリソースをこのCDB単位で共有しています。

何を言ってるかというと、上にいくつもの赤いPDBが載ってきても、このCPUとメモリというのは増えずに、もうその中で共有して使っていくので、リソースの効率がとても良いですよ、といったところがポイントになります。

アーキテクチャをスパッと縦に切った図がこちらなんですけども、かなりスキーマ統合に近いようなモデルに見えるかなと思います。スキーマ統合のいいところは、やっぱり集約性が高いというところです。とてもいい部分なんですけど、一方で統合する時すごい大変だったんですね。

例えば、スキーマ名がかぶっちゃったら統合できないので、すごい移行コストが高いです。やりきるお客さまもいらっしゃいますけれども、なかなか難しい。プラガブルデータベースはそこを解決しています。

アーキテクチャは似てるんですが、そのユーザ・データが入っているところは、物理的に全部分離されているので、スキーマ名がかぶっても大丈夫です。なので移行がすごくしやすく、リソースの共有性が高いです。そういったところがこのマルチテナントのポイントです。

ユーザ・データとメタデータの完全分離が可能

簡単と言いつつ、ちゃんと話しちゃってますけども（笑）。「なんでこんなことできるの？」という話の背景だけもう少しお話しますね。少し細かめですが、ビューの観点からお話します。

今まではDBAビューという一番大きいビューがあって、その中でユーザ・ビューなどがあったと思うんですけど、その上に、外側に、CDBという、つまりコンテナレベルのビューが増えた。これによって、中にPDBのビューが入ってきて、ネストをしたかたちになります。

逆にこれだけなんですよ。データ管理の仕方を変えることによって、先ほどのアーキテクチャを実現している。実はそんな大きく変わってないんです。

あともう1個ポイントがあります。メタデータの話ですが、左側にあるものは今までのアーキテクチャです。メタデータにはオブジェクトの情報などが入っています。

この赤いポイントが見えますか。ここにメタデータがあって、グレーのやつが基本的に管理情報だったりするんですけど、赤いラインはユーザ特有のデータです。

ユーザ・データとメタデータは基本的には分かれてるんですけど、今までは、一部メタデータの中にユーザ特有のデータが入ってたんですね。ちょっとアーキテクチャ上しょうがなかったと。

なので、「ユーザ・データを引っこ抜きたいよ」という場合は、このメタデータの中に入っているユーザ・データも出さなきゃいけなかったので、すごい大変だった。つまり、全部まるっとコピーしなきゃいけなかったんです。マルチテナント・アーキテクチャでは、それを完全に分離するということを実現しました。

これですね。PDBの中にユーザ・データを全部入れてしまいました。メタデータに入っていたユーザ・データもPDBの中に入れてしまったので、例えば「ユーザ・データを外に出したいよ」という場合には、このPDBごとスポッと抜けば（CDBやほかのPDBの）管理情報は一切ついてこない。だから、分離しやすくなりました。

ここではrootって書いてありますけども、共有情報だけ下のコンテナに残しておく。ここからは、こういう水平分離をすることによって、とてもメリットのあるアーキテクチャになったんですよという話です。

トランザクションを止めずにデータベースをコピーできる「ホット・クローン」

今日一番お伝えしたい話のポイントとして、このクローニング、プロビジョニングの話なんですけど、今のようにユーザ・データを分離したことによって、コピーもコマンド1発でできるようになったんです。

コンテナの中でプラガブルデータベースを複製したり、別のコンテナに引っこ抜いて持っていきやすくなったというのが、まず12cのマルチテナントのエッセンスです。

そして、今日お話する（18Cの）ひとつ前の12.2も、なかなか進化を続けています。ここで出てきた新機能として、ホット・クローンというものがありました。実は今まで、クローンというのは、コピーできたんですけど、コピー元を必ずREAD ONLYにしなきゃいけなくて、更新を止めなきゃいけない制約があったんですね。

それをしなくても大丈夫なんです。ユーザがトランザクションを実行したままコピーして、その先でまたコピーをすることが、トランザクションを止めずにできるようになりました。これがホット・クローンです。

12.2はひとつ前のバージョンなので、18cはさらに進化を続けていて、このマルチテナントだけでも、さまざまな新機能が入ってきています。

今日はその中でも、この赤い字のリフレッシュ可能PDBスイッチオーバーと、スナップショット・カルーセルの2つをご紹介します。

その前に、ユースケースの話をしますね。いつもDB触ってるよ、構築されてるよという方、多いですかね？

（会場挙手）

はい、ありがとうございます。例えばアプリケーションのテストのフェーズに入った時に、「過去のデータベース断面でテストしたい」と言われることってありませんかね？　けっこうありますよね。

やっぱりアプリを変えなくても、データがどんどん変わっていく。「なにかあった時に、その時のデータでテストをしないと意味がないよ」と、「だから戻したいんだけど」ということって、けっこうありませんか？

実際に開発者の声ということで（ご紹介します）。実在する東京都S.Nさんから実際にいただいた声です。「手動または定期的に自動取得されたデータベース断面があったら、めっちゃうれしいです」。

「なにかあった時とか監視してる時に再現をしたい。そういう時に、過去断面に戻って簡単にテストできたらありがてー」というお話であったり。

あとは最近けっこう、マイクロサービスとかも開発手法としてあると思います。そういう時は、アプリの機能ごとにデータベースがあったり。そういう細かいデータベースの運用方法の時に、「1機能のテストをする時に、他のDBに影響せずに対象のDBだけ戻せたらうれしい」というお話がありました。

データベースのスナップショットを定期的に取得

「18cはできるんです」という、若干の通販感がただよってますけれども。ここから少し、これらができる新機能のお話に入ります。まずは、PDBスナップショット・カルーセルという機能のご紹介をします。

PDBスナップショット・カルーセルは、新機能名にワードが2つ入ってきてますので、分けてお話します。まずは「PDBスナップショット」なんですけど、これは名前のとおり、PDBをある時点でコピーします。プラガブルデータベースをコピーをするので、これはいわゆるフル・クローン、クローニングのお話をしています。ある時点のデータをコピーする、ということですね。

もう1個、そのコピーをためる場所が、（この丸く描いてあるこの輪っかですね）カルーセルです。それで、PDBスナップショット・カルーセルといいます。一言でいえば、PDBスナップショットのリポジトリみたいなものですね。

カルーセルって日本語で言うと、芸能人の名前が出てきますけど、回転木馬ですね。この丸い円はそれを意味していています。今のバージョンだと最大8つまでなんですけども、自動的に順繰り順繰りにスナップショットを取り続けて、過去の断面から消していきます。勝手にどんどん肥大化していかないような、ちょっと便利なリポジトリなんですね。

もちろん8はマックスですけども、6とか、そういう数字にも変えることができます。これはパラメータで変えられます。スナップショットを取ると話しましたけど、もちろん取るタイミングも選べます。これが次のお話です。

手動で「この時点のスナップショットが取りたい」「バスンバスンって取りたい」。MANUALの設定ももちろんあれば、もうちょっとおもしろい定期取得ができます。「EVERY 〇〇（スナップショット間隔）」を入れると、分・時間が選べるんですけども、それで自動的にスナップショットを取り続ける、というような設定を入れ込むこともできます。

取っただけじゃなくて、おもしろいのは取ったものを戻せること。取ったら使いたいじゃないですか。それもちゃんとできるんです。

「CREATE PLUGGABLE DATABASE」というのが、基本的にデータベース、PDBをつくるコマンドです。それで、「USING SNAPSHOT いくつ」と書くと、このスナップショットを使って、トルンと持ってきます、なんてことが簡単にできるわけです。

ポイントは、フル・クローンと同じものがつくられるので、制限なく普通にREAD/WRITEできるかたちでつくれるようになりますよということ。これが、PDBスナップショット・カルーセルのエッセンスのお話でした。

コピー先も常に最新のデータを伝搬できる「PDBリフレッシュ」機能

もう1つ、今日はマルチテナントのお話をします。リフレッシュ可能なPDBスイッチオーバーという機能のお話なのですが、またちょっと12.2の時に進化したお話を、挟ませていただきますね。

この時、12.2ではPDBリフレッシュという機能が入ってきました。これは何かというと、先ほどはクローニングのお話をしました。データベースをコピーします、クローニングできますけど、例えばコピー元が更新されたら、コピーされた後のやつは古くなっちゃいますよね。

時間が経ったあとに、古くなっちゃうから、また新しくコピーを続けなきゃいけない。今まではそういう運用だったんですけど、「もうちょっとなんとかなんないかな」。それを実現するのがこのリフレッシュです。

簡単に言うと、更新されたデータだけをコピーして定期的に適用することで、常にコピー先も最新のデータを伝搬できる機能です。

この進化系の話の前に、少しユースケースの話をします。例えばアプリケーションのデプロイをする時に、今はけっこう2面でデプロイをする、ブルーグリーンデプロイメントというのがあると思います。

そうでもなくても今、上がプライマリ、下がスタンバイという時に、下のほうに新しいアプリをデプロイして、ユーザを切り替えて、逆のほうをスタンバイもしくは開発環境にして、次のバージョンの開発を上で行うなんてことはけっこうあるかなと思います。

「その時、DBどうなってるの？」というと、普通であればそのまま、上の方を見続けることになるかなと思うんですけど、DBのほうもPDB単位で無停止で切り替えられたら、うれしくないですか、というお話です。

この矢印には、あともう1個意味があります。先ほどのリフレッシュのことなんですけど、適宜データの同期を行えるから、切り替えの際のデータの追いかけ処理の時間を短縮できる。つまり早く切り替えられるし、トランザクションが無停止だったら、ちょっとうれしくないですかと。

18cにはトランザクションを守る新機能を搭載

まあお決まりなんですけど、18cではできるんです。それがこのリフレッシュ可能なPDBスイッチオーバーという機能です。

これはおもしろい機能なんですよ。今のリフレッシュの機能プラス、12.1から入ってきた可用性のなかなかいかつい機能がありまして、トランザクションを守る機能があるんです。12からApplication Continuityというものが入ったんですけど、みなさんご存知ですか？

「あんまり聞いたことない」という方も多いかもしれません。この組み合わせ技で、今のことを実現します。Application Continuityは何かという話を補足します。

これはもう名前のとおり、アプリケーションをコンティニューさせるものです。例えば、これはクラスタリングのものなんですけど、「ラックで障害が起きました」「上のノードで障害が起きました」「トランザクションかけ中でした」という時に落ちちゃったら、そのトランザクションは、未コミット状態になっちゃいますよね。

普通だったら、その時にエラーが返って、アプリケーションのほうでエラーハンドリングをして、再実行とかまた別の処理が必要になる。そういうつくり込みが必要になると思うんですけど、しないんですと。

まだコミットされてないDML文をちゃんと覚えておいて、「あ、こいつ、まだコミットされてないわ」と。そうしたら、生きてるほうに透過的に切り替えて、さらにリプレイまでかけちゃう。

アプリにエラーを返さないのって、すごく便利じゃないですか？　12.1を再実行してくれるんですよ。しかも、ちゃんと覚えているから、二重実行しないんです。実は12からそんな機能があったんですね。これを組み合わせて、さっきの話をちょっとやります。