世界初の自律型データベースの実力は？　現役DBエンジニアがチューニング対決で検証

自律系データベースを検証する

関俊洋氏（以下、関）：みなさん、どうぞリラックスして聞いていただければと思います。内容は、先ほどYasinさんからお話いただいた自律型データベースを検証させていただいた結果を、みなさまにお伝えしたいなと思っております。ビジネス的な話はまったくなくて、「実際検証してどうだったのか？」という、正直なフィードバックが中心です。

検証結果の発表に先立って、今回、環境を提供してくださった日本オラクルのみなさまと、Yasinさんをはじめとするプロジェクトチームのみなさまに、お礼を申し上げたいと思います。どうもありがとうございます。

私は、データベースとクラウドを中心に仕事をしているエンジニアです。アシストという会社に所属をしております。2年前から、Oracle Cloudの仕事もするようになっていまして、我々アシストの社内で、Oracle Cloudを業務システムに活用する仕事もしています。

例えば、我々はサポートセンターを構えていますけれども、そこのFAQをOracle Cloudでつくったり、今年は基幹システムのDRサイトをOracle Cloudでつくろうとしています。なので、ユーザーとしてOracle Cloudを使って、みなさまにその情報をフィードバックするという仕事をしている人間です。

これから検証結果をご紹介するんですけれども、1点だけ先にご案内があります。リリース前の先行検証環境を使わせていただいているので、実際のサービス版とは少し動作が違う部分があるかと思います。その点は少し補足をしながら、ご案内していきたいと思います。

まず、今日はどうしてもみなさんに聞いてみたいことがあります。「ADWC（Autonomous Data Warehouse Cloud）、自律型DB（データベース）の第一印象をどうお考えですか？」。

だいたい2パターンあるかなと思っています。「すごいおもしろいね。やってみたいね」という方と、「ちょっとこれ、本当に大丈夫？」という方がいらっしゃると思うので、挙手をしていただきたいと思います。サテライトの方は「自分はこっちだな」と、その場で考えていただければと思います。

まず、Aの「積極的に使っていきたい」という方は、どれぐらいいらっしゃいますか？

（会場挙手）

関：いらっしゃいますね。ありがとうございます。10名様ぐらいですかね。オラクルさんも見ているので、ちょっと気を使っていただけるとありがたいなと思います（笑）。

（会場笑）

関：Bの「ちょっと大丈夫かな？　心配なところあるな」と思う方はいらっしゃいますかね？

（会場挙手）

関：ありがとうございます。8割ぐらいですね。私もこっち（Bの心配しているほう）です。

（会場笑）

自律型データベースへの意見は賛否両論

理由は、10年以上Oracleの製品（を使っていて）、現場でSEとしてやってますので、ちょっと心配というか、気になるところが多いなというところでした。主にそのあたりを検証でガッツリ調べてみたという、結果のフィードバックになります。

積極的にやっていこうかなと思ってる方も当然いらっしゃいますし、我々もその気持ちを理解できるところもあると思っています。私はデータベースを10年以上やってますけど、やっぱり、データベースエンジニアの守備範囲ってものすごく広いですよね。

要件定義の段階から、インフラのメンテナンス（とか）、運用が始まるまで、ものすごくたくさんのタスクがあります。データベースエンジニアと言われてる方々は、それをこなしていかなければなりません。

最近はデータベースだけではなくて、インフラ、ミドルまで幅広く全部面倒を見られてる方もいらっしゃるので、これらのタスクが少しでも減るところに期待をされてる方もいらっしゃると思います。工数が削減できて、浮いた工数で別のミッションに注力するといった考えにいたるのは、私はすごくすばらしいことだなと思っています。

一方で、たくさん手を上げていただいた慎重派のみなさまは、なんとなくこんなことを思ってるんじゃないかなと思います。本日はエンドユーザもいらっしゃれば、ベンダの方、SIerの方、あるいは開発をされてる方もたくさんいらっしゃると思います。

例えば、自律型という話を聞くと、「それはちょっと中身が見えないので、ブラックボックスじゃないの？」というようなご意見も、当然出てくるかなと思っています。「コントロールが効かないところでいろいろ変更されちゃうと、ちょっと困るな」という意見も、当然あると思っています。

あとは、先ほど基調講演で登壇されたYasinさんのセッションの中でも一部ありましたけれども、仕事がなくなることへの懸念ですね。まあ、そこで飯を食ってるところがなくなると、「じゃあ、次どうしよう。別のところに付加価値をと言われても、そんなのすぐに思い浮かばないよね」というご意見は、当然あってしかるべきかなと。

私がここに挙げた数多くの意見は、少なからずサービスを知っていただくことで、若干モヤモヤが解消されるんじゃないかなと思っています。なので、今回このイベントが終わったタイミングで振り返っていただいて、Autonomousに対する評価を一度、見直していただければなと思います。

3人のエンジニアをADWCの自動化機能と戦わせる

我々はこんなモヤモヤを抱えつつ、「こんな検証があったらどうか」と考えました。やる内容は、「エンジニアを3人用意して、ADWCの自動化なリ、自動〇〇という機能と戦わせてみよう」と思って、プランを立てました。

登場人物は、ほぼほぼチューニングとか運用管理のツールを使える若いエンジニアが1人。EM（Oracle Enterprise Manager）を使ったり、SQL Developerを使ったり。中堅は、ある程度の作業はなんでも手で動かせる。ベテランはなんでもござれです。チューニングも運用管理も全部できるベテランを用意しました。

検証環境は、ADWCの先行検証環境です。CPUは、2～8の間でちょっと動かしたりしています。比較対象はオンプレのエクサ（Exadata）です。ADWCがExadataの技術をベースに動いているので、これ以上ない格好の比較対象かなと思っています。あとは、Oracleではない別のエンジンを搭載しているデータベース・アズ・ア・サービス（DBaaS）です。

検証データは、Star Schema Benchmarkを使っています。これはADWCのインスタンスを立ち上げていただくと、あらかじめサンプルとして入っているデータです。今回はそれをちょっと増量して、1テラバイトのデータをつくりました。それで処理を実行して、データウェアハウスの検索系の処理を実行して、パフォーマンスを測っています。

まず、パフォーマンス系の検証結果のご紹介をいたします。

若手エンジニアが検証したんですが、自動チューニングというコンセプトがあります。「本当にそのとおり動くのか？」という話ですね。データをポンと入れたら、あとはいい感じのパフォーマンスを出してくれるのかという比較をしています。対象はオンプレミスのExadataですね。Star Schema BenchmarkのSQLで、大規模検索系のSQLが13個あるんですけど、それをポンと実行したらどうなったのか？

結論から申し上げると、ADWCのほうが早いというSQLが多かったです。6割～7割ぐらいがADWCのほうが早いという結果になりました。

オンプレエクサは若手のエンジニアが3日間ぐらいかけて、全部のSQLをがんばってチューニングしたんですけれども、残念ながらADWCにはかないませんでしたという結果です。ADWCはチューニングゼロです。データを入れて、SELECT文を実行するだけです。

オンプレのエクサを本気でチューニングしたらどうなるのか？

処理がいっぱいあるんですけど、SQL個別で見ると、最大で10倍ぐらいADWCのほうが早いという結果を得ることができました。ADWCは、当然クラウドですよね。オンプレミスのエクサは、実質物理を占有しているかたちです。

他は、なにも処理をしてない状況で実行してるので、クラウドと物理の差を考えても、この性能はけっこう驚きかなと思います。なによりもチューニング工数ゼロというのが、非常に印象的だったなと思っています。チューニングがまったくできない、というわけではないです。やれることもあります。例えばヒントを入れたり、やれることはありますが、実質なにもやってません。

あと、クラウドという関係で、物理的なExadataをまるっと占有しているわけではなく、1人のユーザが占有してるわけでもないので、I/O周りのところが若干ネックになりやすいのかなと感じてしまう部分もあります。

結果としてはなにもしなくてもいい。それで性能が得られるんだったら、工数削減（ができて）、手間がかからないところが魅力の1つだ、という結果が得られています。

ただ、これはあくまで若手がやった結果なので、「じゃあ、オンプレのエクサを本気でチューニングしたらどうなるのか？」というのが次です。ちょっと結果が変わってきます。

今回はベテランのエンジニアをアサインして、「オンプレのエクサをとにかくチューニングしてくれ」というような話で、比較してみました。そうすると今度は、6割ぐらいオンプレのほうが早くなっていきます。

これには少し理由があって、ADWCはリリースした段階なので、まだ現時点で設定できない機能があります。例えばパーティショニングとか、設定できない機能があります。今後そういうものが設定されてくると、たぶんどんどん変わってきますけど、現時点ではオンプレミスでパーティショニングを設定して、きちんとパフォーマンスが改善されるようにしてあげると、こういった差が出てきます。

ADWCは基本的にExadataの基本機能でカバーしていくかたちになるので、データを入れてすぐに処理を流すだけです。なので、ものすごく深いチューニングとかは、そもそもコンセプトから外れています。そういうことをする必要がないものとしてできているので、コンセプト外ということですね。

一定水準のチューニングを勝手にしてくれるのがADWCの魅力

ただ今回、ベテランのエンジニアが3日かけてチューニングしましたけど、実際のデータベースの運用では、スポットでチューニングをするケースもあれば、いつ何時チューニングしなきゃいけないような問題が起こるかわかりません。継続的に処理が速くなるように面倒を見てあげなきゃいけないという、その継続的というところがけっこうポイントだと思っています。

確かにスポットではDBエンジニアのほうが処理を上回りましたけど、運用中にそれを何回やっていくかという話ですよね。そういうことを考えると、深いチューニングはできないですけど、運用中に一定の水準のチューニングをずっと勝手にやってくれるところは、長い目で見るともしかしたら、ADWCのほうが魅力があるのかもしれない。そんなふうに感じた検証結果でした。

次にExadataをいったん置いておき、Oracle Databaseじゃないエンジンを持つデータベース・アズ・ア・サービス（DBaaS）との比較結果ですね。こちらも同じようにやってみましたけれども、これもだいたいADWCのほうが早いという結果になっています。

データ量やSQL、CPU数などは全部そろえています。他社のDBaaSは、チューニングはしておりません。同じようなコンセプトでチューニングはいらないはずなので、なにもしておりませんが、その時点でADWCのほうが上回っているという結果になりました。

今回は先行検証環境というところもあって、なかなか思いどおり動かないSQLもいくつかあったのは事実です。それでこの結果なので、もしかしたら製品版で検証すると、もう少し結果が変わるかもしれないです。

あともう1つ補足をすると、今回、日本オラクルさんとOracleのYasinさんをはじめとする製品担当の方とコミュニケーションを取らせていただいて、「ここはなんか動かない」とか、「意図した実行計画になってないんじゃないの？」というフィードバックをいくつかさせていただいたところ、数日の間にそれを解消していただいたことが何回かありました。

それぐらいADWCのアップデートのスピードはすごく早いですし、みなさんが今後もし検証して、うまくいかないことがあれば、ぜひフィードバックをしていただきたいと思っています。そうすると実は、裏でプロダクトの改修が行われて処理が改善することが実際にあるかなと思ってます。

ADWCのほうが処理が速い時の共通項

ADWCのほうが速い時に共通して言えることは、Exadataの機能がどれだけ効いてるかです。Exadataは、ストレージサーバとデータベースサーバで処理のレイヤーが分かれています。

ストレージサーバ側でデータを絞り込んで、サーバ側に返すデータを極力減らして処理するのがExadataのやり方です。その機能がいかに効くかが、性能の分かれ目のポイントだと思ってます。実行計画で言うと、Smart Scanが効くかどうかですね。

Oracle Database独自の実行計画、Smart Scanが効くかどうかというところで、他のデータベースとの差が出てくるんじゃないかなと思っています。

こういうふうに性能系の検証を3つやってきましたけども、結果は非常に良かったなと思います。ADWCは本当にまったくチューニングしてないので。まあ、（チューニング）しようがないというのが正しいですね。インデックスも貼れないですし、マテビューをつくって、ちょっとズルなチューニングをしたりもできないようになっていますので、公平な比較ができたんじゃないかなと思っています。

続いてスケールアップです。先ほど基調講演でYasinさんがやったデモの中で、ブラウザを使ってスケールアップの操作をしていただいたと思いますが、私たちもあの動作の確認はしていて、実際、無停止でスケールすることは確認しています。

その時の動きをちょっと見てみると、このグラフは最初4コアでスタートして、途中から8コアに上げているというグラフなんですけども、このY軸はデータベースの処理のI/Oの量ですね。全部で250ギガぐらいの処理をSELECTで動かしてるんですけど、途中で4から8というふうにスケールアップをしたところ、きちんとI/Oの量も比例して上がっていることが確認できています。

SELECTも途中でスケールアップしても、パラレルのSELECTの数は増えないので、SQLのパラレルとしては変わらないですけども、I/O Resource ManagerのI/O帯域が上がるので、I/O量も一緒に増えていくという結果が出ています。

これがおもしろいなと。Oracle で、しかもExadataじゃないと、こういう動きはできないので、スケールアップをして、その時にI/Oの量が瞬間的にきちんと上がっていくのは、他のデータベースにはないおもしろい動きだなと思っております。

無停止でスケールアップできるデータベースサービスは、他社さんにもありますけれども、よくよく見ると「読取専用にしてください」といった話もあったり。でも、そういった影響も受けずにできるのはおもしろいかなと思います。

ADWCと他社のDBaaSのコスパの差は最大で10倍

あと、自動スケールに関しては、先行検証の時点では実装されていなかったので、今後に期待かなと（思います）。自動スケールは、例えばあるCPUの負荷までデータベースサーバの負荷が上がってきたらスケールしましょうとか、そういうなにかをトリガーとして動くことを「自動スケール」というふうにここでは表現してます。

今後そういうものが実装されてくると、もっと柔軟に、ユーザが介在しなくても、ユーザ様のシステムの負荷状況を見て、自動でCPUを増やしたり減らしたり。減らすというところまでいくとおもしろいですね。（そういったことが）今後できるようになってくると思うので、そこに期待をしたいと思っています。

続いてコスパですね。「性能がいいのはわかったけど、いくらするのよ？」というお話です。ADWCと他社のDBaaSの価格性能比を出してみました。全部で13本のSQLがあるんですけど、Star Schema Benchmark、それ全部実行中に、終わるまででいくらかかるのかというお金の計算をしています。

コスパ的には、ADWCのほうが安いという結果になっていますし、処理によっては先行検証なのであんまり動かないものもあったんですけど、処理を見ていくと最大で、10倍ぐらいコスパが違ったりします。Oracle Open Worldで、Oracleさんでも某データベースとの比較結果をされてたと思いますけども、それに近しい処理が一部で確認できているという結果になっております。

赤字でも書いてますけども、このコスパはあくまでもクラウドの料金のお話です。クラウドに対して支払う料金のお話で、この性能を出すためにどれぐらいの人的リソースを使ったかが、人的コストとして別にあるわけですよね。

ADWCはまったくその「お作法」というものがないです。「データを入れてください。データを入れたら、SELECTしてください」、それだけですね。他のDBaaSは、やっぱりちょっと「お作法」があるんですよね。

例えば、「ソートするキーを決めてください」とか。それを1回決めたら、データを入れ直さないと二度と変えられないですからね。いろんな「お作法」があって、性能を出すためにはきちんとした前提をそろえなければいけない。そういうこともないので、クラウドの料金と人的コストをひっくるめて考えると、コストパフォーマンスがすごくいいと思います。

まだまだ職人技が必要な部分がある

そもそもOracle Cloudのコンセプトって、Universal Creditになったことによって、1つの資金のプールの中で、「IaaSもPaaSもすべて使えます」というコンセプトになっているので、その時点でトータルコストはきっと圧縮できるはずです。

データベースの周辺にはアプリケーションがいますね。例えばBIなどもいますし、データベースにデータを連携するものもどこかで必要です。それもひっくるめてトータルコストを比較していくと、もう少し差が出てくるかもしれないですね。これは、今後どういった構成がADWCでいいのかで始めて、もう一度比較してみたいなと思っています。

パフォーマンス検証をまとめていくと、やっぱり手作業には手作業の良さもあると思っています。まだまだ職人技は必要だなと思うところがあります。

例えば、もう本当に特定の処理、バッチなりなんなりが困っていて、「どうしてもこれ、早くしてください」と言われる場合は、その環境を知りつくして、ありとあらゆる手をつくすことができるのは、人手を介す作業のいいところです。深くチューニングをしていくところですね。

一方、ADWCはお任せです。なにもする必要はありませんし、一部を除いてチューニングの機能はできない、しなくていいようになっています。

手作業は「だいたいここぐらいまで性能が上がればいいよ」というチューニングの目標を決めて、それに挑んでいく場合に向いていると思っています。例えば「5分の処理を1分にしてください」とか、そういうことです。

ADWCは、そういう目標を決めてチューニングをするというアプローチじゃなくて、ワークロード全体を常に見渡してチューニングしてくれるという。まあ、稼働範囲の違いかなと思っています。

それからスケールアップに関しては、CPU、ストレージの増強というのが可能です。もちろんメモリも増えますね。スケールダウンも可能というところが、オンプレミス手作業と違うところです。あと、Oracleのライセンスに引っ張られることがあまりないのも、クラウドのいいところだと思っています。

ADWCでバックアップの設計が楽になる

以上、パフォーマンス系が終わりで、次が運用系です。運用の中で必要になるデータベースのオペレーションがいくつかあると思っているので、そこの検証結果をお見せいたします。

まず1つ目がバックアップです。データベースの運用の中で欠かせないバックアップに関しては、ADWCでインスタンスをつくると、バックアップの設定が自動でされます。なにか細かい設定を入れ込むことは、基本的には必要ないですね。週次フルバックアップが取られていて、日次でバックアップも取られています。かつ、FLASHBACKも有効になっています。

これだけバックアップの対策を自動で施してくれれば、障害が起きた時、あるいはオペレーションミスをした時、どちらでも対応できるような設計があらかじめされていると、今回の検証では感じました。

これを自力でやるというのが、その左です。我々エンジニアが実際やっている作業としては、「バックアップ、どういう方針にしましょう？」という検討をしなきゃいけないです。「物理バックアップにするのか、論理バックアップにするのか？」「どんなツールを使うのか？」「いつ取るのか？」。そんなことをやっていきます。

実際に設計に入って、細かいパラメータを決めていきます。「バックアップの並列をどうするの？」とか「それで管理どうするの？」といったことを決めていきます。

テストの計画をつくって、お客さんのアプリケーションと同じ、実際のデータを生成して、テストをして、実装をして、運用引継ぎの手順書をつくって。こういったことをやっていくと、どれだけ早くても2週間～3週間ぐらいはかかると思います。

それをADWCの場合は、設定項目が実質なにもないので、「インスタンスをつくりました。その設定を確認します」だけで終わりです。バックアップ設計、テストという概念は必要ないですし、バックアップの戻しの作業もブラウザからできるので、なにか難しい運用手順書をつくること必要ないです。バックアップの設計は、これでものすごく楽になると思います。

しかも、これが共通設計にされると、ADWCに入れたインスタンス、複数インスタンスを立てた時に、すべてバックアップの設計なり戻しの手順は共通化できるので、そういった意味でも運用上のメリットはあるんじゃないかな、と思っています。

ADWCのモニタリング機能の守備範囲

続いて、モニタリングですね。監視に関してですけども、ADWCには、モニタリングするための専用ツールが付いています。ブラウザから、この「モニタリングツールにアクセスする」というボタンを押せば、その画面が出てきます。

Enterprise ManagerのDatabase Expressをもうちょっとシンプルにしたようなイメージです。モニタリングなので、なにか操作をするものもなくて、見るだけです。

例えばCPU使用率を見たり、「ストレージ、あとどのぐらい残ってますよ」というのを見たりとか。あとは、今流れてるSQLと過去に実行されたSQLのリストを見て、実行計画を深掘りしていって、どうなってるのかを見るようなモニタリングツールが用意されています。

よくDBaaSとしてクラウドで使われる他社さんのものと比べると、入れる項目はだいたい同じぐらいかなと思っています。実行計画の深いところまで見えるので、パフォーマンスが出ないSQLを特定したり、そういったところにも十分使っていけます。

守備範囲の外に出ている機能は、例えばしきい値を監視して、メールで通知をするとか、警告を出すものはないです。「CPUが90パーセントに上がったらメールしてください」といったものはないですね。

これはこのモニタリングツールの守備範囲外なので、これまでどおりSQLを、例えばデータベースに対して監視ツールから発行して、統合監視と連携していくとか、そんな実装も必要ですし。

OracleにはManagement Cloudというサービスがあるので、そこから将来的に連携をして見られるようになったらおもしろいのかなと。パーツ同士の連携でサービスの価値が高まっていくんじゃないかなと思います。

トラブルの時の対応。基本的にクラウドになった時点で、そもそもオンプレミスとトラブル時の動きが変わってきます。

クラウドになると、ハードウェアやネットワーク層が、基本的には我々から見えないので、「内部でどうなってるの？」という切り分けは実質できなくなるわけです。

SRへの依存度が高くても解決時間が伸びるとは限らない

今回いくつかADWCの検証をしていて、サービスリクエストを上げてお問い合わせをすることが何回かありました。その時に我々が遭遇した事象としては、例えばオンプレミスだと、アラートログとかトレースログとかありますよね。あとは、データベースにログインして、（データ・）ディクショナリ・ビューを見たり。

いろんなトラブルシュートをして、原因を絞って、そこから自分なりの結論をある程度見出してからサービスリクエストに上げるということをやっていると思います。ADWCは、そういう操作が必要なくなります。というか、できなくなります。

例えばアラートログとかトレースファイルのような、いわゆる生ログを見ることができません。ちなみに、「アラートログが見れないんだったら、データベースにある内部情報を見よう」と思いましても、それも見れなくなってます。これは「見れない」というよりも、「しなくてもいいサービスである」という表現が正しいかもしれないですね。

例えば「問題が発生しました」となったら、まずは今その瞬間的に見える情報を取得する必要があります。例えばSQLがエラーになったのであれば、「発行したSQLの文はこれです」と、「出力されたORAエラーのコードはこれです」と、「いつそれを実行しましたか？」とか「再現性はありますか？」とか。そういったことを確認してすぐSR登録です。

アラート、トレースを分析するとか、1次切り分けをするというステップは必要ない、というかできないので、SRに登録するというフェーズになります。そのため、私は少しオンプレミスよりもSRに依存する割合が増えるんじゃないかなという印象を持っています。

もちろん、ADWCとかOracle Cloud自体が、世界中で同じ構成が動いてるはずです。Exadataの技術を標準にすえているなら品質はいいはずですし、なにか起きたら、「世界中で同じ構成がいるんだから、他の事例があるはず。なので修正も早いはず」という発想にいたるので、SRへの依存度が高いからといって、必ずしも解決時間も伸びると言えるものではないかなと思っています。

手作業とADWCのそれぞれの良さ

このあたりは実運用で、サポートからの回答の時間などを比較してみる、実際に見てみる必要があるかなと思ってます。今回の検証に関しては、トラブルの対応と解決まで、非常にフレキシブルに導いていただけたなと思っています。

運用管理、保守系の考察ですね。手作業の良さとADWCの良さについてまた話をすると、手作業は設計の幅が広いことが、1つの売りです。例えば、ADWCの場合は「FLASHBACKがONですよ」と申し上げましたけども、「じゃあ、それをOFFにしてみよう」とか、そんな設計の自由もなんでもできます。

見られる範囲も広いです。ありとあらゆるログを全部見て、トラブルシュートして、普段からメンテナンスの情報として使うとか、なんでもできます。みなさんが今持ってる経験をそのまま引継いで、運用として固めていくことができるんです。

それはトラブルの時にも言える話で、「こういう問題が起きたら、きっとこうだろう」という、経験に基づいたトラブルの初動対応、切り分け、それから速やかな火消しができるのが、手作業のいいところです。

一方でADWCは、はじめバックアップで申し上げたとおり、設計や実装の手間は基本的にいらなくなります。工数はほぼゼロになります。共通の設計が各ユーザーに施される、というかたちですね。

情報に関しては、「トレース、アラートが見れません」という話をしましたが、現時点では見る必要がない設計になっています。トラブルの時の複雑なログ解析も必要なくなりますが、SRに依存する比率が高くなるので、実際のトラブル対応の時の動きは、評価のフェーズできちんと試していただければなと思っています。

その他、おまけ程度にやった検証がいくつかあるので、ご紹介をします。Redshiftからの移行に関しては、SQL DeveloperにMigration Assistantというものが用意されています。

その接続の情報とS3にいったんファイルを置いて、それをロードするというステップを踏むので、S3の情報を渡してあげるだけで簡単に移行できます。

データの圧縮率についても検証

試しにやってみたんですけど、まずSQL Developerで移行スクリプトを生成するという処理が行われます。移行スクリプトを生成すると、その中身としては、データをアンロードする処理が1個、いわゆるエクスポートが1個と、ADWCに表定義を移すためのDDL文が1個。もう1つがデータをロードするSQL。

この3つがMigration Assistantから生成されます。その場で実行をポチッと押すと、もうそれだけでADWCにデータが流し込まれるところまで、全部完結で行えます。

もちろんSQLそれぞれが単発で実行することもできて、データのアンロード、エクスポートをすると、Amazon S3にデータがたまっていきます。それをデータロードのSQLで叩けば、ADWCのデータの移行はこれで終わりです。

非常に簡単なので、例えば検証や評価をしてみる時に、このMigration Assistantを使ってやってみると、「今RedshiftにあるデータをADWCに持っていったらどうなのか？」という検証はできます。

チューニングがいらないので、データを入れたらコードの次はもうSELECTでいいです。統計情報を取ったり、なにかインデックスをつくったりする必要がないので、データをロードしてすぐSELECTです。

あと、検証としてやったんですけど、ちょっと結果は出たんですけれども、そんなに大きく取り上げるまでもないかなと思ったやつが2つあります。

1つがデータの圧縮率です。ADWCはExadataのテクノロジーをベースにしてるので、Hybrid Columnar Compression、HCCが効きます。HCCが必ず適用されますので、圧縮率は非常に高い結果が出ています。今回1テラのデータを入れましたけれども、だいたい4分の1ぐらいまで圧縮されています。

これはオンプレミスと比較して同じ数字だったので、オンプレのエクサのHybrid Columnar Compressionと同等のものが使われてる、と判断をしていいと思います。

他のDBaaSの圧縮機能とかだと、1テラのデータが700ギガぐらいに減ったり500ぐらいに減ったりはしますけど、こんなに減ったりはしないです。圧縮率はかなりいい数字が出ると思っています。

工数ゼロで80～90点のチューニングが可能

あとは、本来やっちゃいけないんですけど、データウェアハウス専用のDBなんで、DMLを実行したくなるタイミングがもしかしたらあるかもしれないので、その時の検証もやってみましたけれども、Exadataを基盤にしてるとはいえ、さすがにオンプレのエクサよりはDMLの処理は当然遅かったですね。

ただ、一般的なデータウェアハウスのDBと比べると、DMLの性能はそんなに悪くなかったので、やむをえず実行するぐらいはいいかなと思いますが、HCC圧縮が必ず効いてますので、基本的にダイレクトパスロードをしていただかないと圧縮がされなくなる、という注意（点）はあるかなと思ってます。

あとは、OLTP（Online Transaction Processing）、ミックスドワークロード版のAutonomousのDBサービスがそもそも後から出てくるので、それはそっちに任せましょうという話になると思っています。

検証、チューニング、運用というふうにやってきましたけども、最後に我々がその中で評価をして、これが自律型DBの強みだなと思ったポイントをご紹介します。

まずチューニングに関しては、すべての自動チューニングが100点だったかというと、そうではないです。一部「人力でやったほうが速いよ」という結果も得られましたけれども、そこにいたるまでの工数はゼロですし、それでここに書いてあるとおり80点とか90点のチューニングが得られるんだったら、すごくいいことだと思っています。

瞬間的に80点、90点になるだけじゃなくて、それが運用を続けてる間、ずっと継続してチューニングされるわけなので、長い目で見た時のメリットは出やすいはずですし。

本当の自律型かどうかは今後試されると思いますけれども、Oracle自身がいろんなユーザのワークロードなりを学習して、チューニングの最適なパスをどんどんどんどんきめ細かに整備していくと、将来的に100点に近づいていくはずです。これはクラウドのいいところだと思っているので、そこに期待をしたいと思っています。

それからバックアップに代表されるように、設計とか設定の手間が大きく減っていくことが、今回検証ではっきりわかっています。

何もしなくても一定の品質のものが手に入る「手軽さ」

トータルで私がこういうふうに評価をしたのは、パフォーマンスがけっこう市場的なメッセージとして強く出てると思っています。自動チューニングするとか、Exadataを使っていることももちろんいいんですけど、私は、工数が減るところとか、なにもしなくても一定の品質のものが手に入るという「手軽さ」のほうに魅力を感じています。とにかく手軽に始められるところですね。

もうすでにADWCは、みなさんも使っていただけるサービスなので、ぜひトライアル、試使用をしていただきたいと思っています。みなさまが持っているアプリケーションなりデータなりをADWCに突っ込んでみて、SELECTをポンと実行していただくとか。

そういうことをやっていただくと、どれぐらい手軽かがわかりますし、チューニングが本当にいらないとか、バックアップ設計がいらないというのも、実際に触ってみればすぐに伝わると思います。

なので、冒頭で懸念として挙げた、「ちょっとADWC心配だよね」という方に関しては、ぜひ触ってみることをおすすめします。私も触っていく中で、いくつか気になったポイントなどが解消されたりもしています。

もちろん一部にちょっと「これはもう少し宿題として残るね」というのはあったんで、それは今後、Oracleさんにバージョンアップを期待したいと思っています。みなさんからも検証の時にもし気になったポイントがあれば、Oracleさんにどんどんフィードバックしていただきたいと思います。

そうすることによって品質も上がっていくし、みなさんの望むものに自律型として近づいていくと思うので、そういった使い方をしていくと、より運用上、業務にメリットが出やすくなるんじゃないかな、と思っています。私のセッションは以上です。ご清聴ありがとうございました。

（会場拍手）