※本ページは、”Exadata Exascale – Why Database Cloning Needed Reimagining“の翻訳です。

あらゆるアプリケーションチームは、現実的なデータに迅速にアクセスしたいと考えています。

そして、あらゆるデータベースチームは、それを提供することが見た目以上に難しいことを知っています。

エンタープライズデータベースは、大規模でミッションクリティカルなシステムであり、厳格な運用管理の下で運用されています。開発やテストのためにコピーを作成するには、多くの場合、かなりの時間、ストレージ、および管理作業が必要です。データベース全体のコピーには大量の容量が必要になることがあります。テスト環境の更新には数時間から数日かかる場合があります。複数のコピーを最新の状態に維持することは、運用コストの増大につながります。そして、開発者やテスターが現実的なデータを迅速に入手できない場合、リリースサイクルは遅くなります。

これが、Exadata Exascaleのスナップショットおよびクローン機能が解決するために設計された課題です。

従来の課題：データベースのコピーは価値が高いが、コストも高い

データベースのコピーは、エンタープライズITの基盤となるものです。チームは、アプリケーション開発、機能テスト、性能テスト、パッチ検証、スキーマ変更、トラブルシューティング、レポーティング、ユーザー受け入れテスト、トレーニング、デモなど、さまざまな用途で利用しています。

その価値は明確です。現実的なデータベースコピーがあれば、チームは本番環境に近いデータを使ってテストを実施し、問題をより正確に再現し、本番環境に反映される前に変更内容を検証することができます。

課題は規模にあり

データベースの規模が大きくなるにつれて、従来のクローン作成手法はさまざまな面で課題を生み出します。

まず、フルコピーは大量のストレージを消費します。たとえば、50TBのソースデータベースの場合、フルクローンを1つ作成するだけで追加の50TBが必要になる可能性があります。これを開発、QA、ステージング、レポーティング、リリース検証環境などに展開すると、ストレージ使用量は急速に膨れ上がります。

次に、コピーの作成には時間がかかる場合があります。大量のデータを移動または複製する作業は瞬時には完了しません。自動化が導入されている場合でも、チームはプロビジョニング、リストア、リフレッシュ、検証、引き渡しといった工程を待つ必要があることがあります。

さらに、運用上の複雑さも蓄積していきます。DBAは、ソースコピー、クローンのライフサイクル、リフレッシュのタイミング、命名規則、アクセス制御、容量増加、クリーンアップ、リカバリ要件などを管理しなければなりません。

また、古いデータはテスト品質を低下させます。環境のリフレッシュにコストや時間がかかる場合、チームは古いコピーを使い続けることが少なくありません。その結果、最新のデータ、スキーマ、構成に対してテストが実施されず、不具合がリリースプロセスの後半で発見される可能性があります。

要するに、ビジネス部門はより多くのコピーを、より迅速に求めています。一方で、インフラチームはコスト、リスク、複雑さを抑制したいと考えています。従来のアプローチでは、その両立のために何らかのトレードオフを強いられることが少なくありません。

データベースのコピーが重要な理由

データベースコピーのワークフローに対する負荷は高まっています。

開発チームには、これまで以上に迅速な開発が求められています。リリースサイクルは短縮され、テストカバレッジの要件は高まり、セキュリティレビューはより厳格になっています。また、本番データベースは拡大を続けており、AIやアナリティクスの取り組みによって、現実的なデータ環境への需要はさらに増加しています。

同時に、組織はプロジェクトごとに異なる個別のプロセスではなく、標準化され、ガバナンスが効き、再現性のあるデータベースコピーのワークフローを求めています。

その結果、明確な要件が生まれています。データベースコピーは、迅速に作成でき、ストレージ効率に優れ、管理が容易でなければなりません。

容量効率に優れたスナップショットとクローン

スナップショットやクローンは、データベースコピーの経済性を大きく変えます。

コピー作成時にすべてのデータブロックの完全な物理複製を作成するのではなく、容量効率の高いコピーは、初期段階ではソースデータを参照し、変更が発生したときにのみ追加の領域を割り当てます。これがシンプロビジョニングの基本的な考え方です。

Exascaleスナップショットは、特定時点の読み取り専用コピーです。Exascaleクローンは、特定時点の読み取りおよび書き込みが可能なコピーです。Exascaleでは、これらのコピーを効率的に維持するために、Redirect-on-Write（RoW）技術を採用しています。

Exascaleにおけるスナップショットとクローンの違いを理解することは重要です。

  • スナップショットは、特定時点のデータを参照する必要がある場合に主に利用されます。
  • クローンは、ソースから独立して変更可能な、書き込み可能なコピーが必要な場合に利用されます。

Exascaleのスナップショットとクローンにより、Exadataリソースをはるかに効率的に活用できます。チームはデータベースコピーをより迅速に作成でき、作成時に必要となる追加ストレージを削減しながら、コピーごとにフルストレージ容量を増やすことなく、より多くの開発・テスト環境を同時に運用できるようになります。

汎用的なクローン技術がOracleデータベースに十分ではない理由

多くのインフラストラクチャプラットフォームは、コピー、スナップショット、レプリケーション、または仮想クローンといった機能を提供しています。これらの技術は、汎用ストレージ、仮想マシン、ファイルシステム、および一部のアプリケーション環境において有用です。しかし、Oracleデータベースは異なります。

Oracleデータベースは、単に独立してコピーできるファイルの集合ではありません。データファイル、制御ファイル、REDO、UNDO、アーカイブログ、リカバリセマンティクス、RAC、そして最新の環境ではCDBと複数のPDB（その数は数百から数千に及ぶこともあります）を含む、稼働中のトランザクションシステムです。ストレージ層でファイルを高速にコピーしただけでは、自動的にデータベースクローンが作成されるわけではありません。

汎用的なクローン機能では、データベースの整合性を確立するために、REDOの適用、識別子や名称の競合解決、サービスの処理、そしてコピーが安全に利用できることの検証といった追加のDBA作業が必要になる場合があります。RAC環境では、クラスター、インスタンス、サービス、ストレージの連携もワークフローに含まれることがあります。マルチテナント環境では、コピー対象がCDBなのかPDBなのかを理解し、それに関連するデータディクショナリのメタデータを適切に管理できる必要があります。

性能も重要です。クローンは、ユーザーが利用を開始した際に本番環境と同等の動作をしてこそ価値があります。Exadataユーザーにとっては、それはExadataプラットフォームの性能特性と運用モデルを維持することを意味します。汎用的なコピー機能でも利用可能なコピーを作成することはできますが、統合、管理、性能、あるいはリカバリの面でギャップが生じる可能性があります。

目標は、単にデータベースファイルの別コピーを作成することではありません。Oracle AI DatabaseとExadataのあらゆる機能を活用できるデータベースクローンを作成することです。

Exascaleが変えるもの

Exadataは以前からスナップショットおよびクローン機能をサポートしていましたが、Exascaleはこれらの機能をExascaleストレージアーキテクチャにネイティブに組み込み、Oracle AI Database 26aiと統合することで、その利用体験を大きく変えています。

Oracle AI Database 26aiがExascaleストレージを利用している場合、PDBスナップショットコピー操作では、Exascaleのネイティブなクローン機能を自動的に利用し、基盤となるデータベースファイルをシンプロビジョニングできます。さらに、PDBを含むCDB全体のクローン作成も、gDBCloneユーティリティを使用することで非常に簡単になります。このユーティリティは、データベースファイルのシンクローンを作成するだけでなく、インスタンスの管理および起動まで行うため、単一のコマンドで完全に機能するデータベースクローンを作成できます。

実際のメリットはシンプルです。ユーザーは従来から使い慣れたOracle Databaseの操作やユーティリティをそのまま利用でき、その裏側でExascaleが容量効率の高いコピー処理を透過的に実行します。

Exascaleこそが、機能を価値へと変える

DBAは、データベースコピーを作成するために、脆弱で分離されたストレージ固有のワークフローを必要とすべきではありません。開発者も、テスト環境を利用するためにストレージ実装のあらゆる層を理解する必要はありません。プラットフォームチームは、標準化され、再現性があり、Oracle Databaseと整合したデータベースコピーのワークフローを提供できるべきです。

開発環境とテスト環境における価値

最も分かりやすいユースケースは、開発環境およびテスト環境での利用です。

たとえば、大規模なアプリケーションリリースを準備しているチームを考えてみましょう。そのチームには、アクティブな開発用、QA用、性能検証用、ユーザー受け入れテスト（UAT）用、不具合解析用、さらに他システムとの統合テスト用など、複数の環境が必要になる場合があります。

従来のフルコピー方式では、それぞれの環境に対して相当なプロビジョニング作業とストレージ容量が必要になりました。

Exascaleのシンクローンを利用すれば、チームは書き込み可能なポイントインタイムのデータベースコピーを、より効率的に作成できます。これにより、開発・テストチームは、通常であれば大規模なデータベースコピーの作成に伴うコストや待ち時間を抑えながら、より現実的な環境で作業できるようになります。

これは単にインフラ利用効率を向上させるだけではありません。エンジニアリングの生産性向上にもつながります。

チームが環境の準備を待つ時間が短くなれば、より早い段階でテストを開始できます。より現実的なデータを使ってテストを行えば、問題を早期に発見できます。環境のリフレッシュが容易になれば、古い環境に依存する可能性も低くなります。また、DBAが繰り返し発生するコピー作業に費やす時間が減れば、より付加価値の高い業務に集中できるようになります。

運用における価値

スナップショットとクローンは、開発者の生産性向上だけを目的としたものではありません。運用チームにも大きなメリットをもたらします。

高速かつ容量効率に優れたクローンを利用することで、本番環境で発生した問題を、本番環境上で直接検証することなく再現できます。また、ポイントインタイムコピーは、アプリケーションの挙動、スキーマ変更、データ関連の不具合などの調査にも役立ちます。さらに、複数のチームが同じ時点のデータを基準として並行して作業を進めることができます。たとえば、QAチームが修正内容を検証している間も、開発チームは継続して新しい機能開発を進めることができます。

データベース運用の観点で最も重要なメリットは、コントロール性です。Exascaleのスナップショットおよびクローンは、データベースコピーの管理を容易にし、より安全に利用できるようにします。これにより、チームは可視性、ガバナンス、一貫性を維持したまま、より迅速に業務を進めることができます。

現代のデータベースプラットフォームにより適したアプローチ

現代のプラットフォームには、スピードとガバナンスの両立が求められています。

ライフサイクル管理を伴わない高速なコピーは、環境の乱立を招く可能性があります。一方で、効率的なプロビジョニングを欠いた厳格な管理は、開発やリリースのスピードを低下させます。目指すべきは、その両方を実現することです。すなわち、現実的なデータベース環境への迅速なアクセスと、運用上の可視性、セキュリティ、そして適切なクリーンアップ運用を両立させることです。

Exascaleのスナップショットとクローンは、まさにこのモデルに適しています。なぜなら、これらは後付けの機能ではなく、Exadataプラットフォームの一部として設計されているからです。容量効率の高いコピー機能を、ユーザーがすでに利用しているデータベースワークフローにより近い形で提供します。

これは特にOracle Multitenant環境において重要です。プラガブル・データベース（PDB）は、本来、分離とライフサイクル管理の自然な単位として設計されています。PDBレベルでのシンクローンにより、チームは必要以上に大きな単位をクローンすることなく、特定のアプリケーション、プロジェクト、またはテストサイクル向けのコピーを効率的にプロビジョニングできるようになります。

このシリーズで取り上げる内容

本記事では、データベースコピーに関する課題を紹介しました。データベースコピーは不可欠なものですが、従来のクローン手法は時間がかかり、ストレージ消費が大きく、運用も複雑になりがちです。

このシリーズの残りの記事では、その課題を解決するExascaleの機能について、さらに詳しく解説していきます。

  • データベースのクローン作成を再考する必要がある理由（本記事）
  • Exascaleスナップショットとクローン：基本概念
  • PDBシンクローン：開発・テスト向けの高速コピー
  • PDBスナップショット・カルーセル
  • CDB間のクローン作成
  • gDBCloneを使用したCDB全体のクローン作成
  • スタンバイデータベースをクローン元として利用する方法
  • Exascaleクローンのベストプラクティスとリファレンスアーキテクチャ

データベースのクローン作成は、ボトルネックであってはなりません。

それは、迅速で、効率的で、ガバナンスが効いており、容易に利用できるプラットフォーム機能であるべきです。Exascaleのスナップショットとクローンは、容量効率の高いデータベースコピーをアーキテクチャのネイティブ機能として提供することで、Exadataをその方向へと進化させています。

本番環境に近い環境を必要としながらも、コピーごとに本番環境並みの準備期間やストレージ容量を確保したくないチームにとって、これは大きな変化と言えるでしょう。

次回の記事では、その基盤となるテーマを取り上げます。Exascaleのスナップショットとクローンとは何か、それぞれがどのように異なるのか、そしてなぜそのアーキテクチャが重要なのかを詳しく見ていきます。