データベースの「Autonomous化＝自律化」をコンセプトとして、これまでの手間暇から解放してくれる。そんな「新たな選択肢」として提供されているのが、Autonomous Databaseです。
昨今、多くのお客様にとってシステムのクラウド化は共通のテーマとなっています。このような状況の中、Autonomous Databaseの採用においてはまだまだ慎重なお客様が多数派である印象を持ちます。
本記事では、前編、後編の2回に分け、Autonomous Databaseの検討段階でお客様がぶつかる「二つの壁」を乗り越えるためのヒント、そして、先行して採用を決断したお客様がどのように検討を進められたかをご紹介します。
Autonomous Databaseとは？
まず、Autonomous Databaseの代表的な三つの特長をご紹介します。
1. データベースの自律運転、自己保護、自己修復を支えるAIの仕組み
Autonomous Databaseは、日本語では「自律型データベース」と訳されます。自分自身でルールを決め、それに従って自ら判断を下し、さらに行動できるデータベースであり、これまで人手で管理してきた次のような業務を、Autonomous Database自身が管理してくれます。
・チューニング
・パッチ適用
・障害復旧
これらは「ある時間になれば、実行する」といった単純なものではなく、過去や現在の稼働状況を常にモニタリングし、状況に応じて最適なアクションが実行されます。負荷や工数を大きく削減できるだけでなくヒューマンエラー防止にも繋がり、リスク軽減にも貢献します。
2. データベース界における「スーパーカー」Exadata上で稼働
Autonomous Databaseは、Oracle Exadata Database Machine（以降Exadata）をインフラ基盤としており、Exadata特有の機能を利用した高速処理が大きな特長です。ただ速いだけではなく、乗り心地も良く、安心・安全という価値も含まれます。
自動車業界でも「自動運転」の技術が話題となっていますが、Autonomous Databaseも同様に、Exadataの機能を活かした「データベースの自動運転機能」を備えているというイメージです。ドライバー、すなわち皆さんが常に「ハンドル」を握っていなくても、一定のパフォーマンスを出し続けてくれるところが魅力です。
3. 標準で使える周辺のデータベース管理ツール
Autonomous Databaseでは、追加コストなく標準で利用できる様々なツールが提供されています。例えば、BIツール、WebアプリやグラフDBを開発するような開発系ツール、機械学習のプラットフォームとして使えるツールなど、Autonomous Databaseを作成すればすぐに使い始めることができます。
Autonomous Databaseリリース以降のアップデート情報
Autonomous Databaseは今から4年前の2018年にリリースされました。アシストではリリース前に、「
世界初の自律型データベースの実力は？ 現役DBエンジニアがチューニング対決で検証
」と題し、「若手からベテランまで3名のエンジニア vs Autonomous Database」という構図でSQLのチューニングに焦点を当てた性能検証を行いました。検証の結果、「Autonomous Databaseは、特に何もしなくても一定の品質を手に入れることができる点が大きな魅力である」ことを実証しました。一方で、課題として残りそうだと感じた部分は「今後のバージョンアップに期待」ということでメーカーである日本オラクル様にフィードバックさせていただいた過去があります。
Autonomous Databaseは、お客様の声を反映しながら多くの機能が追加実装されてきました。ここでは、その中からピックアップして五つのアップデート情報をご紹介します。
1. SQL Developer Webの改良版「Database Actions」のリリース
標準で提供される周辺ツールのアップデートです。筆者も実際に試してみたところ、手元にあるファイルを簡単にロードできたり、他にも様々な機能が詰め込まれ、ユーザーフレンドリーなところが魅力的なツールです。
2. コンソールからのインスタンスの自動起動・自動停止設定が可能に
つまりは「起動停止がジョブ化できるようになった」ということです。インスタンスを停止すればその分の利用料を節約できるため、特に開発環境などで重宝されるのではないかと思います。
3. クロス・リージョンでの高可用性構成（Data Gurad）のサポート
東京リージョン、大阪リージョン間でData Guardが利用できるようになり、災害対策が行えるようになりました。
4. SYSDATE、SYSTIMESTAMP関数の「日本時間」対応
5. UTF8以外の文字コードへの変換
上記4番と5番は2018年のリリース時にアシストから日本オラクル様に「今後のバージョンアップに期待」とフィードバックさせていただいた項目です。これまでタイムゾーンはデフォルトでUTCが返され、文字コードはUTF8以外の選択肢がなかったのですが、アップデートにより柔軟に対応できるようになりました。
今後も魅力的なアップデートにご期待いただければと思います。
Autonomous Database検討時の壁とその解決方法
ご紹介したように、Autonomous Databaseは魅力的な機能が詰めこまれたクラウドサービスです。ここからは、魅力的であるがゆえに皆さんがぶつかる可能性のある「検討段階における二つの壁」について説明します。そして、これらの壁を越えるために何を知っておくべきかについて、順番に解説していきます。
一つ目の壁「何から始めればいいか分からない」
Autonomous Databaseはリリース以降、事例が増えてきている状況ではありますが、お客様にお伺いしていると、「まだ遠い存在」と思われているようにも見受けられます。それはAutonomous Databaseが「できること」にフォーカスして語られることが多いことが原因かもしれません。「採用することで何が変わるのか」と逆に「（今のやり方から）変えなくてはいけないことは何か」を理解いただくことがその解決策になると思います。
すでに情報収集されている方も数多くいらっしゃると思いますが、Autonomous Databaseの採用は単純にインフラとしてのスペックやコストの話ではなく、データベース管理の仕組みが180度変わることを意味します。そのため、構築、開発、日々の運用だけでなく、将来的な対応がどう変わるのかまで、まずは「知る・想定する」ことが重要です。
オンプレミス環境では、「設計・構築」「運用」「更改・廃棄」という三つのサイクルを約5年単位で管理するのがよくあるケースです。
「Autonomous Databaseに移行した場合、これまでとどう変わるのか？」
この問いについて、システムのライフサイクルに沿って見ていくことで、「何から始めればいいか分からない」のヒントにしていただきたいと思います。
（1）設計・構築フェーズ
（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関連、オプティマイザ関連など、ごく一部の例外を除いては、変更ができないようになっています。
（2）運用フェーズ
次に、運用フェーズで大きく変わるポイントをご紹介します。
（2-1）サーバとデータベースの監視
運用中はデータベースの稼働状況を確認するために監視を行うのが基本です。これまでは以下のように、サーバとデータベースそれぞれに対し、多岐にわたる情報を監視していました。
【サーバの監視例】
・サーバの死活
・CPU、メモリ使用率
・ディスク使用率
・I/Oビジ―率
・ネットワーク帯域
【データベースの監視例】
・メモリのキャッシュヒット率
・プロセスの死活
・表領域使用率
・Oracle関連ログ
・SQLパフォーマンス
Autonomous Databaseでは、領域の使用率、セッションの接続数など、データベースにフォーカスして必要な部分だけを監視する運用に変わります。監視ツールはいくつか提供されており、例えばOCIのNotifications機能を使ってストレージの使用状況に応じて通知を飛ばすことができたり、使い慣れたEnterprise Managerを使ってデータベースのステータス、ワークロード、パフォーマンスといった情報を確認することができます。
【OCIのNotifications機能による監視例】
・adminユーザーのパスワード変更通知
・ストレージ容量の監視
（デフォルトで10%まで超過利用が許容される）
【Enterprise Managerのよる監視例】
・ステータス、ワークロードの監視
・パフォーマンスの監視、問題の診断
・オンプレミスDBからAutonomous Databaseへの移行テスト
・スキーマ管理タスクの実行
・データベース管理タスクの実行
Enterprise Managerは、オンプレミス環境のお客様にとっては使い慣れたツールであり、複数データベースの一元管理を行える点が大きなメリットです。Autonomous Databaseの初期リリースでは非対応だったものの、Enterprise Managerのアップデート（13.4.0.4以降）により、Autonomous Databaseを監視対象に指定できるようになりました。
（2-2）パッチ適用
パッチ適用は、必要性をこれまで感じながらも、現実には対応できていない状況がお客様企業で多く見受けられました。例えば、セキュリティパッチの定期適用が運用ルールになっているものの、実際にはできてない。このギャップがお客様にとって大きな負担や悩みになっていたのではないかと思います。
このパッチ適用がどうしても後回しにされがちな理由として、以下の三つが挙げられます。
1. パッチ適用の費用対効果が見えづらい
2. パッチと一言で言っても、OSからインフラ、データベースまで各レイヤーに対し
どこまで徹底してやればいいのか基準が判断しづらい
3. 手厚くやればやるほど人的コストがかかる
これに対し、Autonomous Databaseでは、データベースを停止することなく、全てのレイヤー（ファームウェア、ハイパーバイザ、クラスタウェア、OS、データベース）に自動でパッチが適用されます。
このようにお伝えするとお客様から「本当に無停止でパッチ適用できるの？」というご質問をよく頂きますが、Autonomous Databaseでは、RAC（サーバ冗長化）構成を生かしてローリングでパッチが 適用されるため、データベース自体の停止は必要ありません。
ただし、セッションの瞬断は発生するため、その際はアプリケーションの再接続が必要となります。もしも、これが許容できない場合は「Application Continuity」機能の利用をご検討ください。トランザクションの実行中にエラーが発生すると、通常はアプリケーション側にエラーが返されますが、この「Application Continuity」機能を利用すると、アプリケーション側にエラーを返さず透過的にトランザクションが再実行されます。
また、パッチバージョンが上がることでアプリケーションへの影響を心配されるお客様も少なくありません。デフォルトでオプティマイザーの修正はオフになっている点、また、そもそも標準で全ての SQLを対象にSPMという機能が有効化されているため、性能劣化への対策がなされた構成になっています。
（3）更改・廃棄フェーズ
次に、更改・廃棄フェーズにおける違いについてご紹介します。
（3-1）サーバの更改・廃棄
ここでは「サーバ」と「Oracle database」の二つの観点でご紹介します。まずサーバですが、保守期間は一般的に5年程度であることが多く、保守切れのタイミングでリプレースに向けた対応がなされてきたかと思います。システムごとに「新たな機器を手配し新規に構築する」、「既存サーバやネットワーク機器を廃棄処分する」というサイクルを繰り返していく必要があり、その分、データベース管理者の方には「コスト」「工数」「手間」がこれまで大きくのしかかっていました。
Autonomous Databaseでは、Oracle Databaseより下のインフラレイヤーはオラクル社の管理となるため、「更改」と「廃棄」という概念そのものがなくなります。
また、自社でサーバを管理する場合、利用している間は「資産」だったものが、更改時には「コスト」に姿を変えます。クラウドの場合は従量課金が前提ですが、検討フェーズでオンプレミス環境とコストを比較する場合は、初期費用だけでなく、このようなサーバのランニングコストも加えトータルで考慮するとよいでしょう。
（3-2）Oracle Databaseのバージョンアップ
Oracle Databaseをバージョンアップするタイミングは、従来はOracle Database自体のサポート期間に加え、ハードウェアの保守切れやリース期間の終了、OSの保守切れ、アプリケーションの更改といった外的要因も大きく影響してきました。またバージョンアップ時には、状況に応じて計画を策定し、それに沿ってプロジェクトを進めてこられたかと思います。
Autonomous Databaseでは、標準機能としてメジャーバージョンのアップグレードが自動的に行われます。そのため、外的要因が発生するたびに対応していたハードウェアの選定やデータ移行などの負荷がなくなるというメリットがあります。
逆に言えば、自動的にアップグレードされてしまうので、いわゆる「塩漬け」の状態にすることができなくなることを意味します。また、自動アップグレードを無効化することもできないため、将来的なアップグレードに備え、アプリケーションや Oracle Clientがそれに対応できるよう準備する必要があります。
お客様から「メジャーバージョンはいつ頃自動アップグレードされるんですか」というご質問もよく頂きますが、具体的なスケジュールはまだ非公開の状況です。現時点の情報として、次期ロングタームリリースが自動アップグレードのターゲットとなる見込みです。このため、19cから21cへ早々に自動アップグレードされる予定はなく、「19cをロングタームリリースとして当面は利用可能な状況である」と言ってよいでしょう。
「何からはじめればよいのか分からない」のまとめ
Autonomous Databaseは、データベース管理の仕組みを180度変えるクラウドサービスです。お客様がぶつかる一つ目の壁「何から始めればよいのかわからない」については、「Autonomous Databaseに置き換えたら、自社のデータベースやアプリケーションにどのような影響があるか」について、理解と整理を行うことが必要です。
これまでデータベース管理者の方が苦労されてきたところを、Autonomous Databaseへの移行により大きく負荷軽減できるという点は間違いありません。ただ、自動化されてしまうことで逆にデメリットになる場合もあります。
ここでご紹介したAutonomous Databaseに移行した場合の設計、構築、運用フェーズでの変化を参考に、将来的な自社のデータベースやアプリケーション像を描いていただければと思います。
執筆者のご紹介
本記事をご覧いただいている方へのご案内
最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。
