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

まず、Autonomous Databaseの代表的な三つの特長をご紹介します。

Autonomous Databaseでは、追加コストなく標準で利用できる様々なツールが提供されています。例えば、BIツール、WebアプリやグラフDBを開発するような開発系ツール、機械学習のプラットフォームとして使えるツールなど、Autonomous Databaseを作成すればすぐに使い始めることができます。

ご紹介したように、Autonomous Databaseは魅力的な機能が詰めこまれたクラウドサービスです。ここからは、魅力的であるがゆえに皆さんがぶつかる可能性のある「検討段階における二つの壁」について説明します。そして、これらの壁を越えるために何を知っておくべきかについて、順番に解説していきます。

（1-1）CPU・メモリのサイジング

従来、CPUやメモリは、将来に備え余裕をもったサイジングを行うことが基本です。Autonomous Databaseには「自動スケーリング」という機能が提供されています。この機能をフル活用することで、ある程度「ぎりぎり」の状態でCPUやメモリを使用することができ、無駄のない運用に変わります。

自動スケーリング機能では、データベースの負荷状況に応じてOCPU*が自動で増減されるため、インスタンスの停止やセッションの切断を行わなくてよいという大きなメリットがあります。
　*「OCPU」とは、Oracle Cloudにおけるコア数の単位（1OCPU = 1物理コア、2vCPU）

ただし、「OCPU数に比例して割り当てられるものの、自動スケーリング時には変化しないリソース」がある点には注意が必要です。

　・最大セッション数：300セッション / 1 OCPU
　・最大メモリサイズ：約15GB / 1 OCPU**

　　**メモリスペックは非公開のため、実測値をもとに記載

例えば、大量セッションが必要なシステムであれば、要件を満たすOCPUを割り当てておかなければなりません。メモリについては、裏側でExadataの高速化技術が働きます。このため、既存環境と比べて著しくサイズを小さくしても、ほとんどのケースで高速化されます。

また、検討段階では、「ピークに合わせてサイジングされた現行環境」と同じコア数でAutonomous Databaseの試算を行い、コスト的に見合わないという理由で採用が見送られるケースがあります。

先ほどご説明した通り、Autonomous Databaseではある程度ぎりぎりで運用することが基本方針となるため、試算条件を変えてコストを確認してみることもお勧めします。

（1-2）OS設定

従来は、バージョンごとに定義されている次のようなインストール要件を 一つ一つ設定する必要がありました。

　【例】
　・OSバージョンの選定
　・OSパッケージのインストール
　・カーネルパラメータの設定
　・OSユーザー／グループの作成
　・シェル制限の設定
　・その他推奨設定
　　・透過的HugePages無効化
　　・NUMA無効化
　など

Autonomous DatabaseではPDB（プラガブルデータベース）として提供されるため、OS設定だけでなく、OSの管理自体も不要です。

逆に言えば、「OSにアクセスしたくても、できない」という点については注意が必要です。現行環境でOSにアクセスしている処理があれば、移行前にその部分をどうするかについて検討する必要があります。例えば、データベースサーバ上で直接バッチ処理を稼働させている場合は、別途管理サーバを用意してリモートでバッチ処理を実行する、といったことを検討しなければなりません。

（1-3）データベース構成設計

従来はそのシステムにとって最適なデータベース構成になることを考え、以下のような観点で設計を行ってきました。アシストでもお客様のデータベース構成設計をご支援させていただく中で、普段から検討要素となる内容です。

　【例】
　・耐障害性（サーバ／ストレージ冗長化など）
　・リスナー構成
　・表領域、データファイル構成
　・ユーザー構成
　・初期化パラメータ構成
　・バックアップ構成

Autonomous Databaseでは、必要最小限の情報をコンソールから指定するだけで、オラクルのベストプラクティスに基づいたデータベースが自動で作成されます。これまで、データベース管理者の方が、データベース設計時に表領域やパラメータの設計から実装、運用管理を行っていましたが、Autonomous Databaseではほとんど考慮する必要がなくなります。

　【ベストプラクティスに基づいたデータベース】
　・RAC、ASMによる冗長構成が標準
　・ユーザー側でリスナー構成は不要、かつ、クライアントからウォレット接続が基本
　・表領域、データファイルは自動作成／管理
　　（ユーザーデータ表領域は「DATA」一択）
　・SYS/SYSTEMの代わりに「ADMIN」を使用
　・初期パラメータは自動構成
　・標準で60日分の自動バックアップを保持（追加ストレージ費用なし）

ちなみに、Autonomous Databaseの作成時間はリリース時よりも早くなり、最小構成の場合、1分半程度でプロビジョニングが完了するそうです。

さて、ここで表領域とパラメータ設定について少し補足します。Autonomous Databaseでは「DATA表領域」（BIG FILE）がデフォルトで一つ作成されます。データベース管理者の方が新たに表領域を作成することはできません。BIG FILEの最大サイズは一般的に32TBですが、これを越える場合は複数の「DATA表領域」が自動で作成されるため、インスタンスで使用可能なストレージ領域が実質の上限となります。表領域をデータの種類ごとに分けたり空き領域を細かく監視したり といった、従来必要だった手間がなくなります。

また、初期化パラメータは、従来は数百個もあるパラメータから主要なものに絞っても、数十個は管理されていたかと思います。Autonomous Databaseでは、OCPUの数に比例して値が決まるものや、事前にセットされているものなど、基本的にはお任せの運用に変わります。NLS関連、オプティマイザ関連など、ごく一部の例外を除いては、変更ができないようになっています。

次に、運用フェーズで大きく変わるポイントをご紹介します。

次に、更改・廃棄フェーズにおける違いについてご紹介します。

Autonomous Databaseは、データベース管理の仕組みを180度変えるクラウドサービスです。お客様がぶつかる一つ目の壁「何から始めればよいのかわからない」については、「Autonomous Databaseに置き換えたら、自社のデータベースやアプリケーションにどのような影響があるか」について、理解と整理を行うことが必要です。

これまでデータベース管理者の方が苦労されてきたところを、Autonomous Databaseへの移行により大きく負荷軽減できるという点は間違いありません。ただ、自動化されてしまうことで逆にデメリットになる場合もあります。

ここでご紹介したAutonomous Databaseに移行した場合の設計、構築、運用フェーズでの変化を参考に、将来的な自社のデータベースやアプリケーション像を描いていただければと思います。

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