Oracle Databaseの水平方向のスケーリング (2021/07/30)

Oracle Databaseの水平方向のスケーリング (2021/07/30)

https://blogs.oracle.com/exadata/horizontal-scaling-with-oracle-database

投稿者:Cristian Craft | Senior Director, Product Management




コンピュータシステムとそれに関連するデータベースが成長すると、より大きなサイズに「スケール」する必要があります。この成長には2つの側面があります。


  •     段階的に大きくなるデータベースへの対応
  •     段階的に大きくなるワークロードへの対応


より大量のデータに対応するためには、より多くのストレージが必要となりますが、サーバーとストレージの間でデータを移動させるために、関連するストレージネットワークの機能も必要となります。 より大きなワークロードに対応するには、より多くのコンピュートパワーが必要です。ワークロードが自動処理の場合もありますが、一般的にはオンラインユーザー数の増加がワークロードの拡大と考えられます。コンピューティングシステムでは、データベースとワークロードが同時に大きくなり、両方の次元でのスケーリングが必要になることも珍しくありません。


スケーリングソリューションには、大きく分けて2つの形態があります。垂直方向と水平方向です。垂直方向のスケーリング(「スケールアップ」とも呼ばれる)は、既存のアプリケーションやデータベースをより大きなシステムに移行する際に発生します。水平方向のスケーリング(「スケールアウト」とも呼ばれる)は、既存の構成にさらにシステムを追加し、データとワークロードをそれらのシステムに分散させる場合に発生します。垂直方向のスケーリングは、非常に破壊的なコストがかかり、最終的には規模が制限されますが、水平方向のスケーリングでは、基盤となるソフトウェアインフラが水平方向のスケーリング用に設計されていれば、これらの問題を回避することができます。


この記事では、Oracle Databaseを使用した水平方向のスケーリングと、Oracle Databaseソフトウェアが水平方向のスケーリングをサポートする独自の方法について説明します。その前に、どのようなアプリケーションやデータベースでも利用可能な垂直方向のスケーリングについてもう少し詳しく説明します。


垂直方向のスケーラビリティ


垂直方向のスケーリングとは、1台のサーバーでデータベースを稼働させた後、より大量のデータやワークロードを処理するために、徐々に大型のサーバーに移行することを意味します。Oracle Databaseは、最小の仮想マシン(またはクラウドの「インスタンス」)から最大の仮想マシンまで、また4ソケット、8ソケット、さらには16ソケットの巨大なベアメタルサーバーでも動作します。 垂直方向のスケーリングでは、データベースをより大きなマシンに移動させます。




垂直方向のスケーリングは、より大きなサーバーをデータセンターに移動させるのに、文字通りフォークリフトが必要になることから、「フォークリフトによるスケーリング」と呼ばれることもあります。


水平方向のスケーリング


水平方向のスケーリングは、仮想マシン(クラウド環境ではインスタンスタイプと呼ばれることもあります)のサイズを変更したり、仮想マシンに割り当てられるvCPUの数を増やしたり、フォークリフトを使ってより大きな物理サーバをデータセンターに持ち込んだりするのに比べて、より便利で破壊的でないスケーリング方法と言えます。水平方向のスケーラビリティとは、複数の小さなマシンを組み合わせて、より大きな構成を構築することです。水平方向のスケーラビリティを実現するには、一般的に以下の3つの方法があります。


  •     コンピュートクラスター
  •     データレプリケーション
  •     データベースシャーディング


これらの3つのアーキテクチャにはそれぞれ利点があり、必ずしもすべてのケースに対して「正しい」アプローチがあるわけではありません。また、これらの技術は(少なくともOracle Databaseでは)組み合わせることができるため、必ずしもどれか一つを選べばよいというわけではないことがわかります。


水平方向のスケーラビリティ - コンピュートクラスター


水平方向に拡張するという当初のコンセプトでは、小型コンピュータのクラスタを使用し、クラスタ内のすべてのコンピュートノードで実行されているプロセスが同時にアクセスする共有ストレージを組み合わせていました。拡張が必要な場合は、クラスタに別の計算ノードを追加し、共有ストレージプールを拡張するだけです。Oracle Real Application Clusters(RAC)は、このスケーリング・アーキテクチャをサポートするために開発され、Oracle Exadataプラットフォーム(Exadata)で究極の実装を実現しています。コンピュート・クラスターには、高帯域で低レイテンシーの相互接続ネットワークが必要ですが、Exadataには、業界で最高の帯域幅(100 Gbps)と低レイテンシー(~10 µsec)を実現する重要なイノベーションがあります。Exadataでは、業界最高水準の帯域幅(100 Gbps)と最低水準のレイテンシー(~10 µsec)を実現しています。これを実現する方法については、「Persistent Memory and RDMA inside of Exadata」のブログをご覧ください。





X8M世代のOracle Exadata Cloud Service(Oracle CloudにおけるExadata)は、3,200vCPUの32台のデータベース・サーバーと3,162TBの64台のストレージ・サーバーに水平方向にスケールアップします。ここでは、大量のデータと膨大なワークロードを持つSINGLEデータベース、あるいは、より多くのデータベースが同じExadata Cloud Serviceシステム上にタフに統合されていることを明確にしておきます。 Exadata Cloud Serviceは、ハイエンドのエンタープライズ・ワークロード向けに設計されていますが、Oracle Database Cloud Service(Oracle Cloudのコモディティ・サーバー上のOracle Database)は、小規模なデプロイメント向けに2ウェイRACクラスタをサポートしています(最大192vCPU、40TBのストレージ)。


RACによる可用性とスケーラビリティ


Oracle Real Application Clusters(RAC)は、水平方向のスケーラビリティを提供すると同時に、可用性も高めます。RAC クラスタにコンピュートノードを追加して水平方向にスケーリングすると、クラスタ内の 1 つ以上のコンピュートノードが停止した場合でも RAC データベースの運用を継続できるという利点があります。生き残った計算ノードは停電の影響を受けず,故障したノードに接続していたユーザーは短い停電の後,生き残ったノードに再接続することができます.


継続的な可用性を実現するために、Oracle Application ContinuityとRACを組み合わせることで、接続が失われることなくアプリケーションの運用を継続することができます。アプリケーション・コンティニュイティでは、ロールバックやアプリケーションの特別なリトライ・ロジックなしに、トランザクションを継続することができます。RACとアプリケーション・コンティニュイティの組み合わせは、仮想マシンのライブマイグレーションを利用した一般的なアプローチと比較して、いくつかの利点があります。アプリケーション・コンティニュイティは、障害だけでなく、プロアクティブなメンテナンスにも対応します。RACクラスターのノードは、ハードウェア、O/Sソフトウェア、ドライバ、さらにはOracle DatabaseやOracle Grid Infrastructureソフトウェアのプロアクティブなメンテナンスのために、ローリング方式でシャットダウンすることができます。 仮想マシンのライブマイグレーションは、物理サーバーや仮想マシンのハイパーバイザーのプロアクティブなメンテナンスを行う前に、稼働中の仮想マシンをある物理ノードから別の物理ノードにプロアクティブに移動させる場合にのみ有効です。ライブマイグレーションは、障害時には役に立たず、O/Sやデータベースインスタンスの再起動を必要とするメンテナンスには対応していません。


Oracle Real Application Clusters(RAC)は、ERP(Enterprise Resource Planning)、OLTP(Online Transaction Processing)、データウェアハウス(Analytic)などの最も複雑なワークロードを含め、アプリケーションを変更することなく、アクティブ/アクティブなコンピュートクラスター間でワークロードをスケーリングすることができる明確なリーダーです。Oracle RACでワークロードをスケーリングしたPayPalの体験談は、最もドラマチックな例の一つです。


RAC とアプリケーションの互換性


大半のアプリケーションはRACと互換性があり、RAC構成で拡張することができます。Exadata Smart Storageや、RDMA over Converged Ethernet (RoCE)を用いた広帯域(100 Gbps)・低遅延のクラスタ相互接続などの革新的な技術により、ExadataはRACデータベースを拡張するための究極のプラットフォームであることが証明されています。2,000以上のISVアプリケーションがExadata上のアプリケーションの認証を受けています。 Exadata上のRACは、水平方向に拡張することでスケーラビリティを実現しているにもかかわらず、「垂直方向」のスケーラビリティと同じカテゴリーの透明性を持っていると広く考えられています。


水平方向のスケーラビリティ - データレプリケーション(読み取りレプリカ)


データレプリケーションソフトウェアは、ネットワーク上の1つまたは複数のシステムにデータベースのコピーを維持します。レプリケーションの最も一般的な形態は、クエリやレポートをサポートする読み取り専用のレプリカです。更新情報は、データベースの中央コピーに適用され、読み取り専用のコピー(リード・レプリカ)に複製されます。リード・レプリカの使用は、ワークロード(ユーザー)のスケーラビリティには役立ちますが、データのスケーラビリティには役立ちません。つまり、データの読み取りを可能にするために、より多くのvCPUをプロビジョニングできますが、データベースの読み取り/書き込みコピーは1つしか存在できません。データベースのコピーはすべて同じサイズなので、リードレプリカは確かにデータ量の面でスケールするためのソリューションではありません。





Oracle Active Data Guardは、Oracle Database用のデータレプリケーションソフトウェアで、1つのプライマリデータベースから最大30個のリードレプリカを作成できるほか、1つのレプリカが他のレプリカに供給できるカスケードレプリカも可能です。もちろん、リードレプリカはリードオンリーなので、アプリケーションの観点からは必ずしも「透過的」とは言えません。他のデータベースとは異なり、Active Data Guardを搭載したOracle Databaseでは、DMLリダイレクション(変更内容が更新可能なコピーに透過的にリダイレクトされる)が可能ですが、大量の変更を想定したものではありません。DMLリダイレクションは、実際には読み取りが中心のアプリケーションを対象としています。リード・モストリーのアプリケーションで少量の変更を可能にすることは、アプリケーションにとって十分に透過的である場合があります。


Oracle Active Data Guardは、パフォーマンスと可用性のバランスをとるための複数のオプションを含む、プライマリコピーからレプリカへの変更の同期および非同期の伝搬を提供します。Active Data Guardのパフォーマンスは、変更がREDOログを介して伝搬されるため、ストレージ層ですべての変更を伝搬する他のソリューションに比べて、サイト間の距離やネットワークインフラに大きく依存します(変更伝搬の量ははるかに多い)。


水平方向のスケーラビリティ - マルチマスターレプリケーション


マルチマスターレプリケーションは、各レプリカ・データベースが読み取り/書き込みモードで開かれているという、読み取りレプリケーションを超えるものです。マルチマスターレプリケーションでは、データ同期の競合が発生した場合、アプリケーションが定義した検出と解決のロジックに依存しています。競合の検出と解決のロジックは、アプリケーションの不可欠な部分として扱われ、(全く別のコンポーネントではなく)アプリケーションの一部として設計されるべきです。マルチマスターレプリケーションは、その名の通り、同じサイズの2つ以上のデータベースを使用するため、データベース内のデータ量を拡張する機能はありません。





マルチマスターレプリケーションは、複数のデータベース(多くの場合、複数のサイトにある)を独立して動作させることができます。レプリケーションの競合検出および解決ロジックは、独立したサイトで別々に発生するデータベースへの更新を処理します。 Oracle GoldenGateは、クロスプラットフォーム、クロスデータベース、クロスバージョンの異種データレプリケーションを含む、マルチマスター・レプリケーションの業界をリードするテクノロジーです。Oracle GoldenGateは、1つまたは複数のトランザクション・データベースからデータ・ウェアハウスやレポーティング・データベースにデータを投入するなど、他の展開モデルでも使用されているため、GoldenGateはマルチマスターレプリケーション専用のソリューションではありません。


水平方向のスケーラビリティ - データベースシャーディング


シャーディングとは、1つの論理データベースを分解して複数の物理データベースにデータを分散させることですが、概念的にはその逆で、複数の独立した物理データベースを1つの大きな論理データベースにまとめることもできます。シャーディングはもともとアプリケーションコード内で行われていましたが(私もいくつか手がけました)、Oracleのようなデータベースベンダーは、シャーディングされたデータベース上でのアプリケーション構築を容易にするために、データベースに直接シャーディング機能を組み込んでいます。シャーディングは、データとワークロードの両方にスケーラビリティをもたらしますが、アプリケーションの開発と実装の段階では、慎重な検討が必要です。アプリケーションコードやデータ構造への変更は最小限で済むことが多いのですが、シャーディングは、サードパーティのパッケージアプリケーションがシャーディングを特別にサポートしていない限り、一般的に使用することができません。





オラクルはDatabase 12cでシャーディングを導入しましたが、その後のバージョンでOracle Shardingの機能は非常に洗練されてきました。Oracle Shardingは、アプリケーションコードによってシャーディングを行う従来の方法と比較して、実装を大幅に簡素化する一連のサービスを提供します。また、Oracle Shardingは、イントラ・シャードやインター・シャードの並列処理など、アプリケーション・コードで実装するには非現実的な機能を提供します。


市場に出回っている他のソリューションとは異なり、Oracle Shardingは、シャーディングの持つスケーラビリティの利点と、Oracle converged databaseのフル機能を組み合わせて提供するように設計されています。シャーディングの実装は、NoSQLデータベースでも利用可能ですが、それらのデータベースには、オラクルが持つ豊富なデータモデリングとワークロードのサポートがありません。


RACとシャーディングおよびレプリケーションの組み合わせ


Oracle Real Application Clustersは、Oracle Shardingと組み合わせることで、シャードの数を減らし(各シャードを大きくして)、各シャードの可用性を高めることができます。最も印象的な例として、Cassandraデータベースの9万個のシャードを、Oracleのわずか400個のシャードに置き換えたお客様がいます。


水平方向のスケーラビリティとして、Oracle Active Data Guardを使用して1つのプライマリデータベースに最大30個のリードレプリカを関連付けることができますが、Real Application Clusters(RAC)を使用することで、プライマリとレプリカの規模を拡大し、それぞれの可用性を高めることができます。





マルチマスターレプリケーションは、同じデータの複数の分散コピーを展開し、各サイトが独立して動作することを可能にします。各サイトの同期には、レプリケーションの競合検出と解決ロジックに基づいた「最終的な一貫性」モデルが使用されます。各サイトは、Oracle Real Application Clustersを使用して高可用性を構成する必要があります。





Oracle Shardingは、Real Application Clustersと組み合わせることで、各シャードの規模を拡大すると同時に、各シャードの可用性を高めることができます。これは、シャードのサイズと重要性が増すにつれ、特に重要になります。より大きなシャードを持つことができるということは、数百のシャードではなく数十のシャードを管理するといったように、より少ない数のシャードを管理することになります。1つのシャードのダウンタイムが他のシャードに影響を与えることはありませんが、そのシャード内のデータは利用できず、そのシャードに依存しているユーザーには影響が及びます。





高可用性のためのRAC + ディザスタリカバリのためのActive Data Guard


一般的な構成は、Oracle Real Application Clusters (RAC) for High Availabilityとディザスタリカバリ (DR) 用のActive Data Guardです。Active Data Guardを使用すると、DRコピーをレポート用にオープンにすることができるため、企業はDRソリューションへの投資を災害時のみに限定するのではなく、日々の価値を確認することができます。Oracle Cloudではこの種の導入が自動化されていますが、より高度な実装はOracle CloudでData Guardを直接構成して導入することができます。災害復旧コピーは、複数のADを含むOracle Cloudリージョンでは、別のAvailability Domain(AD)に配置されます。高度な実装では、必要に応じてDRコピーを別のOracle Cloudリージョンに配置することもできます。


まとめ


Oracle Real Application Clustersは、オラクルが長年培ってきた独自の水平方向のスケーリングソリューションであり、データベースの可用性の面でもメリットがあります。Oracle Real Application Clusters は、長年にわたりオラクル独自の水平方向のスケーリングソリューションであり、データベースの可用性の面でもメリットがあります。また、オラクルは Active Data Guard で複数のリードレプリカを使用して水平方向のスケーリングを行うことができます。Oracle Shardingは、1つの論理データベースを複数の独立した物理データベースに分割することで、水平方向に拡張する機能を提供します。Oracle GoldenGateは、異種データベース間のリアルタイムのデータ統合を実現します。これには、競合の自動検出と解決機能を備えたマルチマスター・レプリケーションのサポートが含まれ、最終的なグローバル一貫性を実現します。つまり、オラクルは、垂直方向と水平方向の両方のスケーリングを含むスケーラビリティの点で、明らかに業界のリーダーです。


コメント

このブログの人気の投稿

Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01)

Oracle Cloud Infrastructure Secure Desktopsを発表: デスクトップ仮想化のためのOracleのクラウドネイティブ・サービス (2023/06/28)

新しいOracle Container Engine for Kubernetesの機能強化により、大規模なKubernetesがさらに簡単になりました (2023/03/20)