「自律型DB」は本当に使える？
本音で語るAutonomous Databaseの現在地（後編）

検討段階でぶつかる二つ目の壁「ブラックボックス感があってなんだか不安」について見ていきましょう。

Autonomous Databaseには「見える部分」と「見えない部分」がそれぞれ存在します。しかし、中身を見てみると、従来のOracle Databaseの技術や仕組みが踏襲されていることを確認でき、意外に「完全なブラックボックスではない」ということがお分かりいただけるかと思います。見えない部分については、見えないからといって不安に思う必要はなく、「わざわざ知らなくてもいい部分」と考えることもできます。

先に結論をお伝えしてしまうと、一番いいのは「試しに利用してみること」です。リリース以降の機能追加により、さらに便利になっている面もあります。どんな使い勝手になるのか、トライアルやPoCを通して実際に試していただくことをお勧めします。

例１：Oracle Databaseの高速化技術

Autonomous Databaseでは自動索引、自動パーティション機能が提供されていますが、必要に応じてデータベース管理者の方が索引、パーティション、MVIEW、ヒント句などを作成・追加できます。

例2：Exadata固有の高速化技術

Autonomous Databaseの基盤はExadataです。 Exadata特有のSmart Scan、Flash Cacheをはじめとした固有の機能が利用できるため、特別な設定を行わずに高速化が期待できます。

例３：SPM（SQL Plan Management）

SPMがデフォルトで有効化され、自動で動作します。パフォーマンスが優れた実行計画は自動的に「ベースライン」に追加されますが、状況に応じて「ベースライン」の実行計画から利用する実行計画を選択することもできます。

例４：Resouce Manager

リソースの割り当てに関しては、以前から存在するResouce Managerという機能がベースになっています。実行する処理の性質によって事前に定義された接続サービスを選択し、パラレル実行や同時実行セッション数、リソース割り当てなどの制御を行うこともできます。


このように、Autonomous Databaseではデータベース管理者の方がよく利用されていたり、聞き覚えのある機能で構成されていることがお分かりいただけたかと思います。これまでベースとなっていたOracle Databaseの機能が、Autonomous Databaseになっても安定したパフォーマンスを支えています。

Autonomous Databaseでは、自動チューニング機能によりかなりの高速化を期待できるのですが、さらにパフォーマンスを向上させたい場合は、OCPU数を増やすことを検討します。個々のオブジェクトやSQLの対応についても、Oracle Databaseの機能をベースにしているため、AWRから原因を分析・特定したり、CREATE文で索引などのオブジェクトを作成するといった対応は、これまでのチューニングスキルやナレッジを活用いただけます。

「リフト＆シフト」というキーワードは、クラウド移行の手法を表します。「リフト」はオンプレミスのサーバをIaaSサーバに置き換える単純なクラウド移行を表しますが、その次の段階であるクラウドネイティブな仕組みにするのが「シフト」です。

Autonomous Databaseへの移行は、このうち「シフト」に相当します。Autonomous Databaseのコンセプトは「従来データベースにかけてきた管理コストを極限まで減らし、その分、価値のある業務に充てること」であり、昨今叫ばれているDXや、IT人材の不足といった課題への切り札となります。ある意味、シフトの範疇を超えたPaaSサービスであると言うこともできます。

先行して採用を決められたユーザーの方々がどのようにAutonomous Databaseの検討を進めたのかをロードマップとして表したのが次の図です。

第1ステップ：オンプレミス環境からIaaSへのリフト

Autonomous Databaseを採用されるケースでは、「リフトまで進んだ状態」から始められることが多いと感じています。
　（1）まずはクラウドに慣れる
　（2）ハードウェアの管理から解放されインフラコストを削減する
といったクラウドの基本的なメリットの享受を主な目的として、何らかのシステムのリフトまでは経験値を積んだ状態です。

第２ステップ

本記事で紹介したポイントです。まずは机上で確認できる情報を整理し、何がどう変わるのか、どういったことを期待できるのかを確認します。

第３ステップ

多くのお客様が、実際に試してみることでその価値を確認しています。

既にオンプレミス環境でExadataを利用され、Exadata固有機能による性能面のメリットを理解されていたお客様の事例です。新しい移行先としてAutonomous Database、Exadata Database Service、オンプレミスのExadataを比較検討し、最終的にはAutonomous Databaseを採用されました。

その理由は以下の2点です。
　・Autonomous Databaseは、リソース追加（OCPU、ストレージ）に柔軟性があり、
　　フルマネージドサービスであることから運用コストの削減を期待できたため。
　・PoCにより、データベース設計や運用についての変更点を確認できたため。

オンプレミス環境でOracle Databaseを運用していると、限られたリソースの中でいくつものトラブルを乗り越えながらOSやOracle Databaseのパラメータを細かく調整してきた経験があるかと思います。そんな経験があると、「お世話をしないと、性能が引き出せないのではないか」といった不安を抱くのも無理はありません。また、「トラブル防止」「現行踏襲」「実績重視」といった現状が目の前にあると、誰でも変化に対して後ろ向きな気持ちになりがちです。

熟練のエンジニアの方が手間を惜しまなければ100％以上の性能が出せるかもしれませんが、Autonomous Databaseはこれとは真逆のコンセプトであり、特に手を掛けなくても一定の品質が手に入るサービスです。新技術とはいえ、Autonomous Databaseの中身はこれまでと同じOracle Databaseです。オンプレミス環境で培ってきたスキルは決して無駄になりません。

逆に、Autonomous Databaseという新しい技術を取り入れることで、エンジニアの方の時間や労力を、より生産的な分野であるデータ活用などへ振り分けたり、今まで以上のパフォーマンスや、安心・安全を得るといった大きなメリット（変化）が得られます。

Autonomous Databaseは、これまでの「データ管理の当たり前」を塗り替える、そんな可能性を秘めているサービスです。

Autonomous Databaseを活用したクラウド化のために何から始めればいいか迷っている皆さんは、サブシステムや検証環境といった比較的試しやすいシステムで、まずは一度Autonomous Databaseを試していただくことをお勧めします。

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。