テストレポート RadonDB 分散データベース: パブリック クラウド検証からエンタープライズ データ センター アプリケーションまで

ここ2年ほどで、AWSやAzureなど国内外のパブリッククラウド大手が相次いで自社開発のデータベースサービスを開始した。 QingCloud は分散データベース RadonDB をリリースしただけでなく、このパブリック クラウド検証済みデータベース製品をエンタープライズ データ センターに適用しました。分散テクノロジーとデータベースを組み合わせ、SSD のパフォーマンス ボーナスを追加することで、信じられないほどのパフォーマンスが実現します。例えば、中国銀聯は、昨年の「双十一」イベント中に、ピーク時の取引量が毎秒92,000件に達したと発表しました。 RadonDB が使用される場合、それをサポートするために必要なマシンはおそらく数台だけでしょう。

ヒント: この長いテスト記事を読むには約 10 分かかります。

企業のニーズに基づいて将来志向のデータセンターをどのように構築するかは、ほとんどの CIO が考えている問題です。

特にスマート端末の時代においては、データの急増によりこの問題はさらに複雑化しています。たとえば、モバイル バンキングはビジネス ホールの固定された営業窓口に対応し、モバイル アプリは固定数の販売チャネルに対応し、人工的な「カーニバル」はオンライン ショッピングから生まれました...

企業にとって、IT 負荷は予測不可能になりつつあります。同時に、エコシステム内外のデータフローはますます複雑かつ頻繁になっています。データの急増は、企業の IT のパフォーマンス、容量、管理に大きな課題をもたらしています。

IT の進化の過程において、クラウド コンピューティングはエンタープライズ IT にとって避けられない道であると考えられており、この数年間でそれが完全に確認されました。特に、パブリック クラウドの実践により、企業の IT ニーズとコストの矛盾がある程度解消され、ハイブリッド クラウドのトレンドもますます顕著になっています。

パブリック クラウドの成功体験は、企業のクラウドへの移行をよりスムーズにするために、社内の企業データ センターにますます適用されています。最も典型的な例は、インターネット分散ストレージから派生した SDS (Software Define Storage) であり、エンタープライズ ストレージ市場で最も主流のトレンドの 1 つとなっています。

RadonDB 分散データベース: パブリック クラウド検証からエンタープライズ データ センター アプリケーションまで

パブリック クラウド サービスをエンタープライズ データ センターに適用すると、ユーザーが実際の問題を解決できるだけでなく、パブリック クラウド ベンダーが企業のビジネス特性をより深く理解できるようになり、ユーザーのニーズを満たす製品やソリューションをその後にリリースするための条件が整います。代表的な例としてはデータベース製品が挙げられます。ここ2年ほどで、AWSやAzureなど国内外のパブリッククラウド大手が相次いで自社開発のデータベースサービスを開始した。 QingCloud は分散データベース RadonDB をリリースしただけでなく、このパブリック クラウド検証済みデータベース製品をエンタープライズ データ センターに適用しました。

パブリック クラウド環境と比較すると、エンタープライズ データ センターのビジネスはより複雑であり、IT インフラストラクチャに対する要件も高くなります。データベースは、データセンター内の物理サーバー、仮想マシン、コンテナなどのプライベートクラウド環境に展開するだけでなく、必要に応じてパブリッククラウドに拡張できる必要があります。

ソフトウェア定義ストレージと SSD の適用により、分散データベースがエンタープライズ データ センターに導入されるようになりました。実際、ストレージとデータベースの統合はより密接になっています (たとえば、サーバー SAN の主なシナリオの 1 つはデータベースです)。 SSD の高性能の利点により、データベースのパフォーマンスがある程度向上し、データベース アーキテクチャが簡素化され、分散が可能になり、理論的には最大限の容量拡張が実現され、パフォーマンスも直線的に向上します。

QingCloud の新世代分散データベース RadonDB は、オープンソースの MySQL テクノロジーに基づいて開発されています。 MySQL は世界で最も広く使用されているデータベースです。オープンソースであるため、ベンダーロックインを排除できます。オープンソース コミュニティの活発な発展により、MySQL に精通した多数の人材が育成され、企業が MySQL を導入、適用、管理する際の利便性が向上しました。 x86 サーバーと同様に、使いやすいだけでなく管理も簡単なので、企業のデータ センターのコスト削減に役立ちます。

しかし、膨大なデータの時代では、スタンドアロンの MySQL データベースではエンタープライズ アプリケーションのニーズを満たすことはほとんどできず、信頼性の目的で MySQL のクラスター バージョンを導入することになります。いくつかの企業は MySQL をベースにした分散展開バージョンを開発していますが、それらは特定のニーズを重視しており、成熟した製品にはまだまだ程遠いものです。 RadonDB は、パブリック クラウドに初めて改良を適用し、エンタープライズ アプリケーションの特性に合わせて最適化することで、エンタープライズ ユーザーの利便性を高める標準的な商用製品を形成しました。

具体的には、RadonDB には主に、ラドンとキセノンの 2 つのモジュールの改善と革新が含まれています。 Radon は、主にデータのルーティングとコンピューティングを担当する分散 SQL レイヤーです。 Xenon は、分散ストレージ層の構築に使用される MySQL クラスタの高可用性コンポーネントです。数秒でのマスター選出、マスター選出後の高速データ再生、マスタースレーブ切り替え後のデータ損失ゼロなどの機能を備えています。 RadonDB は、技術的な観点からシャーディングの概念をさらに拡張し、単なるシャーディング コンポーネントではなく、高可用性とスナップショット分離レベルを満たす分散トランザクションを備えたオープン ソースの分散データベースとなっています。

RadonDB 分散データベース アーキテクチャ図 (出典: QingCloud)

RadonDB パフォーマンス テスト環境のセットアップとコンポーネントの説明

一般的に言えば、データベースとストレージ（正確にはブロック ストレージ）の関係は非常に密接であり、データベースのパフォーマンスは通常、ストレージのパフォーマンスと密接に関連しています。分散ストレージのパフォーマンスは、一方ではハードウェアに依存し、他方では分散ストレージ ソフトウェア自体の最適化にも関係します。次の図は、RadonDB テスト アーキテクチャを示しています。

テスト環境全体は 6 台のサーバーと 25GbE スイッチで構成されており、主に分散ストレージ環境と RadonDB 分散データベース環境に分かれています。各サーバーには、2 つの Intel Xeon E5-2650 v4 プロセッサ (12 コア、2.2GHz) と 64 GB のメモリが搭載されています。

ストレージに関しては、RadonDB 分散データベースのパフォーマンスをより適切に反映するために、E Enterprise Research Institute は「オールフラッシュ」構成の分散ストレージを RadonDB データベース ストレージとして使用しています。分散ストレージは最低 3 つのノードで展開され、各ノードには 4 台の 4TB Intel DC P4510 SSD が搭載されています。これは、Intel の第 4 世代 U.2 インターフェース NVMe SSD です。パフォーマンスが向上し、容量も大きくなったため、RadonDB データベース パフォーマンスの上限をより簡単に監視できるようになります。

分散ストレージ ソリューションは、新世代の 25GbE ネットワークを使用して、内部データ循環の帯域幅を拡大します。これまでのテスト経験に基づくと、オールフラッシュ構成環境では、通常、10GbE ネットワークがストレージのボトルネックとなり、アプリケーションのパフォーマンスに影響を与えます。そのため、この RadonDB テストでは 25GbE ネットワークが使用され、分散ストレージは iSCSI 経由で RadonDB データに接続されました。 iSCSI は、エンタープライズ環境における標準かつ一般的なデータ転送テクノロジであり、既存のエンタープライズ環境への影響を最小限に抑えることができます。同時に、25GbE は、RDMA テクノロジー (リモート ダイレクト メモリ アクセス)、つまり RoCE または iWARP をより適切にサポートできます。 iSCSI 接続がアプリケーションに必要なストレージ パフォーマンスを提供できない場合は、iSER (iSCSI Extensions for RDMA) や NVMe over Fabric などの新しいデータ転送プロトコルに簡単にアップグレードできます。

[[260997]]

データベースに関しては、RadonDB は最小 2 つのノード (最小可用性を満たすため) で導入でき、通常は 3 つのノードから開始されます。このテストでは、3 ノードのデプロイメントが使用され、2 ノードのデータベースのパフォーマンスが RadonDB データベースのスケーラビリティを検討するための基準として使用されます。 RadonDB の自動デプロイメントおよび運用・保守ツール Ansible を使用すると、ポートと変数を設定するだけでワンクリック インストールを実現でき、デプロイメント プロセス全体がシンプルで便利になります。

E エンタープライズ研究所は、実際のアプリケーション環境にできるだけ近づけ、テスト モデルを通じて実際のアプリケーション環境をできるだけリアルにシミュレートすることを目指しています。ただし、実際の環境では通常、予測できない状況が多く発生し、それらは特定のアプリケーションの負荷と密接に関連しています。このテストでは、E-Enterprise Research Institute は Sysbench ソフトウェアを使用して RadonDB データベースのパフォーマンスを評価し、ほとんどのアプリケーションの実行負荷に基づいてテスト データを構築し、できるだけ多くのユーザーに参考資料を提供しました。

同時に、RadonDB 分散データベースの限界をさらに調査するために、これは RadonDB データベースのアプリケーション シナリオに関係するため、E Enterprise Research Institute はテスト コンポーネントにいくつかの調整を加え、Intel DC P4800X SSD を RadonDB データベースのデータ キャッシュとして使用しました。 Intel DC P4800X SSD は Intel の Optane であり、SSD よりもバランスの取れた読み取りおよび書き込み機能と低いレイテンシを備えています。 Intel の研究所データによると、NAND SSD と比較して、Optane はデータベース キャッシュとして使用でき、データベースのパフォーマンスを数倍向上できます。

IntelはOptaneをデータベースキャッシュとして使用しており、パフォーマンスが3倍以上向上し、データベースの平均応答時間も約3分の1に短縮されており、Optaneの優れたパフォーマンスが示されています（Intelより）

人工知能やビッグデータ分析などのアプリケーションの出現により、エンタープライズ シナリオ ベースやパーソナライズされたサービスなどの革新的なビジネスは、モバイル インターネットにますます依存するようになっています。携帯電話やインターネットでの取引が主流の取引チャネルとなっています。プロモーション、急ぎの購入、その他の活動により、突然のビジネスピークが発生することがよくあります。ビジネス データとトランザクション量の急増により、エンタープライズ データベースに対する需要が高まっています。

このため、E Enterprise Research Institute のテストは「パフォーマンス」を中心に行われました。 1 つは、最小構成での RadonDB データベースのパフォーマンスであり、もう 1 つは、2 ノードから 3 ノードに拡張した後の RadonDB データベースのパフォーマンスの変化です。

RadonDB 初の試み: データベース分野における分散技術の検証

E Enterprise Research Institute は、Sysbench ソフトウェアを使用して、RadonDB および MySQL データベースに 16 個のテーブルを構築しました。このテーブルには合計 2 億行のデータが含まれており、約 80 GB のストレージ スペースを占有しています。読み取りおよび書き込みパフォーマンス テストでは、1 つのトランザクションは 1 つの SQL ステートメントです。読み取りと書き込みが混在する場合、1 つのトランザクションには 4 つの読み取り SQL ステートメントと 1 つの書き込み SQL ステートメントが含まれます。

E Enterprise Research Institute は、まず、RadonDB データベースのパフォーマンスをそれぞれ 2 ノードと 3 ノードでテストし、単一マシンの MySQL (Community Edition 5.7.22) のパフォーマンスを参照グループとして使用しました。両者のソフトウェアおよびハードウェア構成はまったく同じであり、どちらもデータストレージとして同じ容量の SSD を使用します。

書き込みシナリオでは、2 つのノードに展開された RadonDB データベースのパフォーマンスは、単一のマシンに展開された MySQL データベースのパフォーマンスとほぼ同等ですが、前者の方がわずかに高くなります。それは理解できます。分散環境では、通常、2 ノードの展開は可用性を考慮して設計されており、書き込みパフォーマンスは単一ノードの展開とそれほど変わりません。ただし、読み取りパフォーマンスの点では、2 つのノードに展開された RadonDB データベースのパフォーマンスは、単一のマシンに展開された MySQL データベースのパフォーマンスと比較して大幅に向上しています (これは、RAID 1 の読み取りおよび書き込みパフォーマンス特性に多少似ています)。

3 ノードで展開された RadonDB データベース環境では、2 ノードと比較してパフォーマンスが約 1 倍向上します。上図に示すように、3 ノードの RadonDB の書き込みパフォーマンスは、2 ノードの RadonDB の 35,000 TPS と比較して 80,000 TPS と 2 倍以上になり、読み取りパフォーマンスも約 50% 向上しています。混合シナリオ（読み取り/書き込み比率 8:2）では、パフォーマンスが約 80% 向上します。最小の 2 ノードのデプロイメント構成と比較すると、通常の 3 ノードのデプロイメントのパフォーマンスは、単一ノードの MySQL デプロイメントの約 2 倍になります。

レイテンシの面では、RadonDB データベースは「分散」テクノロジを活用しています。つまり、複数のノードの並列読み取りと書き込みを通じて、データベースのパフォーマンスが向上するだけでなく、トランザクション処理プロセスのボトルネック遅延も大幅に削減されます。上の図に示すように、読み取りパフォーマンスに関して、3 ノードの RadonDB データベースの平均レイテンシは MySQL の 60% にすぎません。書き込みパフォーマンスに関しては、RadonDB データベースの平均レイテンシは MySQL の約 3 分の 1 です。読み取りと書き込みの混合テストでは、MySQL データベースの平均レイテンシの約半分に短縮されます。

パフォーマンスの向上と平均レイテンシの低減により、RadonDB データベースはより多くのコアかつ重要なアプリケーション シナリオをサポートできるようになります。分散原則により可用性が向上するだけでなく、パフォーマンスとレイテンシも向上し、より厳しいアプリケーション要件を満たすことができます。さらに重要なことは、分散テクノロジがデータベース分野にも適用可能であり、アプリケーションのニーズに合わせて「弾力性」、つまりスケーラブルなパフォーマンスと容量を提供できることを証明したことです。

予測不可能性は現代の IT が直面している大きな課題です。分散とデータベースを組み合わせると、分散コンピューティングや分散ストレージ テクノロジと同様に、RadonDB を企業の既存のアプリケーション ニーズに応じて導入でき、アプリケーションのパフォーマンス要件の変化に応じてデータベース ノードを追加または削除することで、パフォーマンスや容量を柔軟に調整できます。

OLTP アプリケーション: パフォーマンスを拡張する方法

前回のテストは、極端な実験室環境での RadonDB データベースのパフォーマンスを検証し、環境が正しくインストールおよび構成されているかどうかを確認するために設計されました。パフォーマンス データは実稼働環境でのパフォーマンスを表すものではありません。ごくわずかな極端なケースを除いて、実際の環境におけるデータベースの読み取りおよび書き込み負荷モデルはより複雑で変化しやすく、特定のアプリケーションに直接関係しています。このテストでは、E Enterprise Research Institute は、現実に近いアプリケーション負荷をシミュレートすることで、パフォーマンス拡張の観点から QingCloud RadonDB データベースのパフォーマンスを評価することを目指しています。

OLTP は、データベースの最も一般的かつ中核的なアプリケーション シナリオの 1 つです。これは通常、主要なエンタープライズ アプリケーションと同義です。通常、信頼性、可用性、高パフォーマンスなどの特性を意味します。大量データの時代においては、スケーラビリティ（パフォーマンスと容量）という要件も加わります。データベース レベルでは、データベースの管理と最適化を意味します。これは通常、長いプロセスであり、アプリケーションの負荷の変化と密接に関連しています。

データベースの最適化方法は、ストレージ システムの特性の変化と密接に関連しています。クラウド コンピューティング時代が深まるにつれ、特に分散テクノロジの普及と深化に伴い、コンピューティングおよびストレージ業界における分散技術革新など、エンタープライズ IT アーキテクチャがますます変化しています。パブリック クラウド プロバイダーによる分散テクノロジのデータベース分野への適用は、データベースの管理および最適化の方法にも影響を与え、変化をもたらすでしょう。

データベースの最適化は、ある程度、(SAN) ストレージに変更を加えることが難しいため、アプリケーションの特性に基づいて、データの処理方法と保存場所に対応する変更を加えることを意味します。しかし、分散テクノロジの導入後、クラウド コンピューティング時代のデータベースは、ストレージ業界から「スケールアウト水平拡張」と「スケールアップ垂直拡張」という 2 つの用語を借用して、データベース パフォーマンスを最適化する別のオプションを提供します。典型的な例は、分散原理によってノード数、パフォーマンス、容量を増やすことができる RadonDB データベースです。コンピューティング、ストレージ、ネットワークなどのハードウェア テクノロジの発展により、単一のデータベース ノードのパフォーマンスを向上させる条件が整いました。しかし、ユーザーにとって重要な前提があります。RadonDB などの新しいデータベースは標準の x86 ハードウェアに基づいているため、x86 とその周辺ハードウェアのアップデートによってもたらされるパフォーマンス上の利点をより早く享受できるということです。たとえば、U.2 インターフェイスをサポートする NVMe SSD や 25GbE ネットワークは、今日の主流の x86 サーバーのほぼ標準機能です。しかし、従来の SAN ストレージ分野では、RDMA をサポートする 25GbE ネットワークは言うまでもなく、より「エンタープライズ スタイル」の U.2 NVMe SSD のパフォーマンス特性を十分に活用するには時間がかかります。

したがって、次のテストは、これら 2 つの機能を中心に設計されています。一方では、スケールアウトの水平拡張後のパフォーマンスの変化を考慮するために、2 ノードと 3 ノードの RadonDB データベースのパフォーマンスをそれぞれテストします。一方、他の条件を変更せずに、よりパフォーマンスの高いストレージ メディア (キャッシュとしての Optane など) をデータベース ノードに追加することで、新しいハードウェアを使用した後の RadonDB データベースのパフォーマンスの変化が反映されます。テスト結果は次のとおりです。

RadonDB 分散データベースを 2 ノードから 3 ノードに拡張した後、データベースのパフォーマンスは 6824 TPS (Transactions Per Second、1 秒あたりに処理されるオンライン トランザクションの数、データベース パフォーマンスの測定単位) から 11285 TPS に約 1 倍増加しました。平均遅延は 2 ノードの場合の 75 ミリ秒から 3 ノードの場合の 45 ミリ秒に減少し、ほぼ半分の時間になりました。

オープンソースをベースとした商用データベース製品の場合、単一のデータベース システム内で TPS を数千から数万に増加させることは、大きな改善となります。たとえば、オンラインショッピングといえば、まず思い浮かぶのは「ダブルイレブン」かもしれません。政策によれば、現在のオンラインショッピングの支払いはすべて、中国銀聯決済公司（略称「中国銀聯」）の決済プラットフォームを経由する必要がある。中国銀聯が発表した2019年の「双十一」データによると、当日に処理された取引総数は11億7千万件だった。ピーク時には、1秒あたりに処理されるトランザクション数は約92,000件でした。実際の状況と同等とは言えませんが、おそらく 10 ノードの RadonDB データベースがこの負荷をサポートできるでしょうか?もちろん、信頼性のために、いくつかの追加バックアップが必要です。

これは、データベース ストレージに NAND SSD を使用する場合にのみ当てはまります。より優れたパフォーマンスを備えた新しいハードウェアを使用して 1 秒あたり 100,000 件のトランザクションをサポートする場合、RadonDB データベース ノードの数は 1 桁にまで削減される可能性があります。別のテストでは、E Enterprise Research Institute が各 RadonDB データベース ノードに 375GB Intel Optane SSD DC P4800X (略して Optane) を 2 つ追加しました。これらは冗長化されており、データベース キャッシュとして使用され、主に Optane の高い書き込みパフォーマンスを利用してデータベース書き込み IO を高速化します。同じテストを 2 ノードと 3 ノードの RadonDB データベース環境で実行したところ、パフォーマンスの変化は次のようになりました。

Optane をキャッシュとして使用した後、2 ノードの RadonDB データベースのパフォーマンスは 26,900 TPS に向上し、これは Optane を使用しない場合の約 4 倍です。 3 ノードの RadonDB データベースのパフォーマンスは 11,285 から 60,996 に向上しました。 RadonDB データベースのパフォーマンスは少なくとも 5 倍向上しました。

さらに、データベースの応答時間も大幅に改善されました。上記の表に記載されているように、Optane を使用しない場合、2 ノードと 3 ノードの RadonDB データベースの応答時間はそれぞれ 75 ミリ秒と 19 ミリ秒です。 Optane を使用した後、同じテスト条件下では、応答時間はそれぞれ 45 ミリ秒と 8 ミリ秒に短縮され、Optane を使用する前の約 4 分の 1 の時間になりました。

データベースに関して言えば、「Double Eleven」の膨大なトランザクション量をサポートするには、おそらく数個の RadonDB データベースだけが必要です。一方では、これは分散技術の応用によるものです。一方、これは巨大な x86 エコシステムによるものでもあります。 RadonDB データベースは、より新しく、より優れたパフォーマンスを発揮するハードウェア テクノロジや製品を可能な限り短時間で検証して適用できるため、データベース自体のパフォーマンスがさらに向上します。

もちろん、これはあくまでも実験室のデータであり、実際の環境で検証する必要があります。しかし、E 企業研究所のこれまでのテスト データに基づくと、RadonDB 分散データベースは、企業にとって重要なアプリケーション データベースになるための条件を当初から満たしていました。優れたパフォーマンス、可用性、保守性を備え、分散技術によってもたらされる「弾力性」とデータベースを非常にうまく組み合わせています。

テスト結果は主にパフォーマンス数値で示されていますが、その背後には従来のデータベースとは異なる RadonDB データベースの特性があります。たとえば、RadonDB データベースのパフォーマンスと容量のスケーラビリティは、一方では実績のある分散テクノロジから、他方では新しいハードウェアの採用から得られます。その背後には強力な x86 エコシステムがあります。もう 1 つの強力なエコシステムは、MySQL オープン ソース コミュニティにあります。理論的には、RadonDB データベースは、オープンソース コミュニティから最新のデータベース改善テクノロジを取得できるだけでなく、貴重な学習経験とデータベース管理の才能も取得できるため、企業ユーザーがアップグレードするために必要な学習コストを最小限に抑えることができます。 QingCloud パブリック クラウド プロバイダーの遺伝子は、RadonDB の製品化プロセスを促進し、企業ユーザーのアプリケーション特性を理解できるだけでなく、研究開発を加速し、RadonDB が大量データ時代のデータベースのパフォーマンスと容量の要件をより具体的に満たすことを可能にしました。 2018 年初頭、RadonDB は GitHub でオープンソース化されました。 radondb.io でさらに詳しい情報や詳しい体験をすることができます。