※本ページは、”Exascale: Oracle Database Storage in the Age of the Cloud“の翻訳です。

Oracleは2024年、次世代のデータインテリジェント・ストレージプラットフォームとしてExadata Exascaleアーキテクチャを発表しました。これは、Oracle Databaseストレージの長年の標準であるAutomatic Storage Management（ASM）と並行して利用することが可能です。Oracleは、当初Exadata Database Machineのオンプレミス導入向けにExascaleを導入しました。Oracleは、同時にExascale技術をベースとした新しいクラウドサービスも市場投入しました。それが「Exadata Database Service on Exascale Infrastructure」です。Exadata Database Service on Exascale Infrastructureは、共有Exadataのコンピュートおよびストレージリソース上で稼働し、クラウド上のExadataでビジネスクリティカルなワークロードを実行するための低コストなエントリーポイントを提供します。

Oracleは、最近Exadata Database Service on Dedicated Infrastructure上でもExascaleストレージアーキテクチャをデプロイできるよう機能を拡張しました。これにより、お客様はASM上で稼働するデータベースと並行して、Exascaleストレージ上にデータベースをプロビジョニングできるようになりました。この共存オプションにより、既存のASMホスト型データベース環境を持つお客様は、同一Exadataシステム上で新規導入にExascale技術を活用でき、また都合のよいタイミングでASMからExascaleへ移行するための道筋も提供されます。

なぜ私たちはExascaleにこれほど情熱を注いでいるのでしょうか？

Exascaleがいかに変革的であるかを理解するには、過去数十年にわたってOracleがデータベースストレージ管理を、単一データベースの導入からクラウド規模へと発展させてきた道のりを振り返ることが有益です。

黎明期：ファイルシステムとRAWデバイス

Oracle Databaseの初期には、データベースは従来型のファイルシステム、またはRAWデバイス上でホストされていました。ファイルシステムは物理ディスクの上に作成され、通常はソフトウェアRAIDや論理ボリュームマネージャ（LVM）によって集約および／または保護されていました。このモデルは多くの手作業による管理を必要とし最適化も難しい一方で、馴染みのあるファイルシステム階層、アクセス方式、権限モデルを用いるという点で比較的分かりやすいものでした。これは、DBAが負荷分散、総合的な性能向上、特定ディスク群の飽和による性能低下の回避を目的として、「データ」表領域のデータファイルを、それに対応する「索引」データファイルとは別の物理ボリュームに分離して配置していた時代でもあります。当時のファイルシステムには、例えばext2ファイルシステムで最大16TiB、NTFSで最大ファイルサイズ2GiBといった、容量やファイルサイズの上限がありました。これらの制約は、管理者にとってファイルやボリューム管理のオーバーヘッド増大につながりました。さらに、オペレーティングシステム実装の違いや、OSとファイルシステムの相互作用の違いにより、予期しない停止が発生した際に書き込みが失われる可能性もありました。

高性能用途や、初期の共有アクセス型データベース導入では、一部の顧客がOracleのデータファイルを格納するためにRAWデバイスを選択していました。RAWデバイスはディスクパーティション上のデータにデータベースが直接アクセスできるため、I/Oコールを簡素化できます。しかし管理者は、各デバイスやパーティションを単一のデータファイルに割り当てる必要があり、ファイルを拡張するには基盤となるパーティションのリサイズが必要でした。その結果、作業ミスのリスクが高まり、管理負荷もさらに増大しました。また、ファイルシステム環境とRAWデバイス環境のいずれにおいても、Oracleデータベースの担当者は、ストレージやOSの担当チームに依存して、データベースストレージの高可用性・データ保護・性能面を管理せざるを得ない状況が一般的でした。

ASMがもたらしたパラダイムシフト

ASMは、2004年にOracle Database 10g Release 1で導入された際、Oracle Database実装におけるストレージ消費と管理に革命的な変化をもたらしました。ASMは、Oracle Databaseファイルの格納に特化して設計・最適化されたシステムとして、データベースストレージの管理責任（スチュワードシップ）をDBAに移し、管理を簡素化するとともに、データファイル配置の手作業を排除し、デバイスの集約、冗長性、負荷分散を自動的に処理しました。ASMはダイレクトI/Oおよび非同期I/Oコールをネイティブにサポートし、OSのI/OコールスタックおよびファイルシステムのバッファキャッシュをバイパスすることでI/O性能を向上させ、OracleがI/Oレイテンシを正確にレポートできるようにしました。

ASMは、SAME（Stripe And Mirror Everything）として知られる軽量なソフトウェアRAIDのようなモデルを提供し、ディスクグループ内のすべてのディスクに対して離散的なアロケーション・ユニットを分散配置することで、デバイスの利用率と性能を最大化します。これによりASMは、クエリを満たすために必要な関連ディスクに対してのみ、独立かつ並列に物理I/Oコールを発行できます。サブブロックの断片を組み立ててデータベースにとって意味のある形にする必要もありません。ASMはエクステントマッパーとして機能するため、新規デバイス追加後の再配置を含め、アロケーション・ユニットを容易に移動してデバイス間でデータを均等に分散できます。特に重要なのは、既存デバイスの削除前にそれを実施できる点です。これにより管理者は、ストレージを容易にスケールアップ／スケールダウンでき、オンラインでのストレージシステム移行ですら実現可能です。さらにASMは、デバイスのパーティショニングや割り当てをASM側に移すことで運用ミスの可能性を低減し、OSユーザーや管理者がアクセス可能な通常のファイルシステムからデバイスを切り離すことにも寄与します。

2008年にExadata Database Machineが初めて提供された際、ASMはストレージ管理の自然な選択肢でした。ASMは高性能、データ保護、管理の容易さを提供するだけでなく、データベースおよびExadataソフトウェアと共同設計され、Exadata Smart Scan、Storage Indexes、Exadata Smart Flash Cache、Exadata RDMA Memory（XRMEM）、Exadataストレージサーバ上のExadata Columnar Cachingなど、年月とともに進化してきた画期的な技術と統合することで、極限の性能を実現しました。ExadataとASMはまた、複数データベースを単一プラットフォームに統合することを可能にし、効率性と管理性を高めました。この組み合わせにより、多くの今日のパブリッククラウド環境の前身となるDatabase-as-a-Service提供も可能になりました。

Exascale：マルチクラウド時代のOracle Databaseストレージ

Oracle Database環境が大規模化し、多数がクラウドへ移行する中で、OracleはASMを再構想し、現在および将来のニーズに対応する真のクラウドスケール・ストレージシステムを提供できる機会を見出しました。Exascaleは、広大なストレージリソースを最小限の容量分割でプール化し、より簡素で効率的な管理を可能にするなど、高度な機能を導入しています。既存システムへ新しいストレージ（より新しく大容量なデバイスを含む）をシームレスに追加できます。高速なシンクローンをOracle Database環境内で直接作成・管理できるようになり、最小限の追加インフラで開発やQAの取り組みを支援しやすくなりました。またExascaleは、VMクラスタ間でストレージ容量を共有して利用率を高めることを可能にし、データベースクローンをVMクラスタ間でマウントできるようにします。これにより、異なるコンピュートリソース上でワークロードを実行しながら、Exadataの性能を最大限に活用できます。

Exascale技術は、クラウドにおけるOracle Databaseのデプロイメントを革新します。Exascaleは「ボールト（vault）」という概念を導入し、Exascaleストレージプールから割り当てられる単一でセキュアな論理ストレージ領域として提示します。ボールト内のすべてのオブジェクトには、透過的で高い冗長性が組み込みで提供されます。別個のディスクグループは不要となり、それらによって必要だった計画作業やストレージ容量の分割も不要になります。さらに、単一のボールトで単一VMクラスタ内の全データベースのストレージ要件を満たせるだけでなく、複数VMクラスタにも対応でき、クラスタ間でのデータ共有を容易にします。ボールトのストレージ容量管理は、総割り当てに対する総消費量を監視するだけで容易になりました。ボールトは自動スケールアップ構成も可能で、消費量が上限に近づいた場合、シームレスに自ら拡張します。また、Exascaleはボールトに保存されるファイルのコンテント・タイプを自動判別し、それぞれに適切な冗長性を適用するため、管理者による関連計画や作業は不要です。

Exascaleは、リダイレクト・オン・ライト（redirect-on-write）アルゴリズムを活用して再設計されたデータベースクローン機構を導入し、変更をより効率的に取り込むためにアウト・オブ・プレース書き込みを行います。さらにExascaleは、書き込み可能なシンクローンを構成する変更ブロックのような、シンプロビジョニングされたオブジェクトを同一のボールト内にまとめて格納できる機能も提供します。これらの変更により、Exascaleはリードオンリーのテスト用マスターコピーを必要とせず、ソースデータベースまたはデータベーススナップショットから、実質的に無制限の書き込みが可能なシンクローンを効率的に保存・管理できます。実際、Exascaleストレージ上のほとんどあらゆるデータベースはシンクローン可能です。リードライト、リードオンリー、プライマリ、スタンバイ、プラガブルデータベース（PDB）も対象です。さらに、シンクローンを別のシンクローンとして複製することもできます。これは従来のシンクローン技術に比べて使い勝手が大きく向上しており、ストレージ層でボリュームを複製して同一または別ホストに提示し、マッピングやマウントを行ってデータベース操作を可能にする方式と比べても大幅な改善です。Exascaleでは、新しいクローンデータベースを単純に作成でき、それは他のどのデータベースとも同様に見え、同様に振る舞います。新しくクローンされたデータベースは、ソースと同じVMクラスタ上で稼働させることも、ソースデータベースのボールトを共有する別のVMクラスタ上で稼働させることも可能です。これにより、データベースはコンピュートとストレージリソースを共有することも、必要に応じてワークロードを分離することもでき、いずれの場合もExadataの性能機能のすべての恩恵を双方で得られます。

Exascaleは、ストレージエクステント管理をデータベースサーバからストレージ層へ移し、DBAの関与なしにスケール可能です。データベースサーバからASMインスタンスを排除することで、サーバ側のリソースが解放され、管理者にとってメモリ管理も簡素化されます。さらに重要なのは、Exadataのストレージ管理をストレージ層へ移すことで、ディスク障害や計画メンテナンスからプラットフォームが自動復旧する際の、データリバランスや冗長性復旧といった操作の性能が向上します。最も大きな利点として、Exascaleボールトのサイズ変更はリバランス操作を必要とせずに実行でき、ASMでの同様のスケーリング作業と比べて時間とリソースを節約できます。

Exascaleテクノロジーは、シームレスな集中型VMストレージを提供し、VM向けに実質的に無制限のファイルシステム領域を実現します。これにより、データベースサーバ上の限られたストレージに保存できる範囲を超えて、より多く、より大きなVMイメージをサポートできます。VMイメージを共有ストレージに保存することで、計画的なデータベースサーバ保守の影響を軽減するためのVM移動（モビリティ）も容易になります。VMモビリティは、現在Exadata Database Machine上のExascaleで利用可能です。

最後に、ExascaleはExadataエンジニアリングチームによって開発され、Oracle Databaseと共同設計されています。これにより、アプリケーションや運用モデルを変更することなく、Exadataシステムに期待される極限のパフォーマンス、セキュリティ、可用性、スケーラビリティ、運用性をデータベースワークロードで利用可能になります。

まとめ

今回ご紹介した数々の機能により、私たちはExadata Exascaleに非常に大きな期待を寄せています！Exadata Database Service on Exascale Infrastructureは低コストの従量課金で利用できるため、ぜひExascale技術を今すぐお試しください。

詳細については、開始に役立つ以下の重要リンクを参照してください。