詳細記事 | UCloud データベース製品の進化

先日、「UCloud User Open Day」の最新イベントが無事に開催されました。 UCloud のリレーショナル ストレージ研究開発部門のマネージャーである Luo Cheng 氏は、UCloud のデータベース製品 UDB の開発履歴を体系的に整理し、製品ファミリーの紹介、アーキテクチャ設計、将来の計画、一般的なユーザー ケースなど、製品設計コンセプトを全体的に詳しく説明しました。

[[224776]]

UDB製品の過去と現在

UDB は、UCloud が 2013 年 1 月に正式にリリースした 3 番目の製品であり、当初は最も広く使用されている MySQL データベースをサポートしていました。 5年間の開発を経て、UDBの製品ラインはますます充実してきました。現在、MySQL、MongoDB、PostgreSQL、SQL Server など、業界で主流のデータベースを幅広くサポートしています。製品の機能には、マスタースレーブアーキテクチャ、高可用性、データベースゾーン、ゾーン間の高可用性、読み取り/書き込み分離、柔軟な拡張、バックアップとリカバリ、監視とアラームなどがあります。

UDB 製品は、高パフォーマンス、高可用性、高同時実行性の「3つの高」シナリオに非常に適しており、ゲーム、電子商取引、エンタープライズ サービス、O2O、オンライン教育など、さまざまな業界のビジネス ニーズを満たします。UDB とともに成長してきたお客様は、クラウド移行の開始以来、UDB を第一の選択肢として選択してきました。 2014年、Dota Legendは数か月連続でAppStoreランキングのトップを獲得しました。 UDB を導入した後、スレーブ ライブラリを除いて、ピーク時には 4,000 を超えるインスタンスを同時にオンラインでサポートできるようになりました。全体的な開発は非常に迅速で、UDB はビジネス開発をうまくサポートしました。

UDB製品設計コンセプト

UDB の開発以来貫かれている製品設計コンセプトは、次の 2 つの点に要約できます。

◆ ユーザーの需要主導

UDB の全体的な開発はユーザーのニーズに合わせて行われ、製品は継続的に更新および反復されます。

◆ 製品の自然な進化

クラウド データベースは文字通り「クラウド + データベース」を意味します。クラウド プラットフォーム上に展開されており、クラウド プラットフォームの開発とともに成長し続けます。

優れたインターネット製品の定義は、実現可能な技術的創造と持続可能な製品機能を通じてユーザーのニーズを満たすことです。

UCloud は常に、「ユーザーの需要が私たちの次の製品である」という信念を抱いています。ここでの需要には 2 つのレベルがあります。

◆ 機能要件

データベース製品の場合、対処すべき中核的な機能要件は、データ ストレージとデータ アクセス セキュリティです。私たちの理解では、データがここに置かれたら、それをどのように実装し、アクセスし、読み書きし、データが安全で信頼できることを確認するかが基本的な機能要件です。

◆ 追加要件

追加の要件には、安定性、災害復旧、容量、パフォーマンス、コスト効率、保守性などがあります。

クラウド データベース製品は、まずユーザーの機能的なニーズを満たし、その後徐々に追加のニーズを満たす必要があります。これがUDBの製品設計コンセプトです。

UDBの製品の進化

UDB は数年にわたって開発されてきました。需要レベルは単純なものから複雑なものへと進化し、製品全体も単純なものから複雑なものへと進化しました。この背後にある原動力は、次の 2 つの側面から見ることができます。

◆ 外部からの推進力

外部からの推進力とは、ユーザーがデータベースにアクセスして使用した後、ユーザー自身の成長によって UDB 製品が新しいニーズを満たすために進化し続けることを意味します。例えば、前述の「Dota Legend」は、UDB の使用後に爆発的な規模拡大を経験しました。一定のレベルに達すると、需要レベルも変化します。もはや一部の機能的なニーズに限定されず、追加の要求がますます増えています。

◆ 内なる原動力

内部の原動力とは、インフラストラクチャが変化していることを意味します。 UCloud クラウド プラットフォームは、UDB のインフラストラクチャを提供します。インフラストラクチャはますます安価になり、クラウド プラットフォームの機能は継続的に向上しています。一方、より強力でコスト効率の高いコンピューティング/ストレージ ハードウェアの出現により、UDB はハードウェアの価値を吸収し、それを製品に転換するようになりました。

これらの内部および外部の推進力が共同して、クラウド データベースの急速な発展を促進します。 UDB 開発の全歴史を振り返ると、次の 3 つの段階を経てきたと言えます。

Cloud Database 1.0 は、データベースがクラウド上に展開される「クラウド + データベース」として簡単に理解できます。クラウドには、オンデマンド価格設定、迅速な配信、柔軟な拡張、高速ネットワーク、複数の可用性ゾーン、仮想化などの一連の特性があり、データベース自体は、データの構造化ストレージ、標準化されたアクセス、データセキュリティなどの問題を解決します。クラウドとデータベースの組み合わせは、ユーザーの機能的ニーズといくつかの追加ニーズをうまく満たすことができると言えます。

データベースの今後の発展について言えば、クラウドデータベースはもはや単なる「クラウド＋データベース」ではなく、「クラウド×データベース」となり、その機能はマトリックス進化に近いものになります。現在業界で大きな注目を集めているAWS Aurora DBはその代表例です。これは、RDS が一定の段階まで開発され、多くの課題を克服し、継続的に反復して、ユーザーのより高度なニーズをよりよく満たすように進化した新世代の製品です。現時点では、Aurora DB はデータベース 2.0 の段階を非常によく表していると個人的には思っています。

UDB ユーザーケース分析

前述したように、UDB は「3 つの高」シナリオに非常に適しています。以下では、実際のケースを使用して、UDB がこれらのビジネス シナリオにどのように適用されるかを説明します。

適用シナリオ: 事業継続

応用シナリオ: 高性能

応用シナリオ: 弾性拡張

応用シナリオ: 高いコストパフォーマンス

◆ 適用シナリオ: 事業継続

調査を実施したところ、顧客が最初にシングルポイント データベースを使用した場合、データベースがダウンすると、現場でハードウェアを交換するのに数分から数時間かかることがわかりました。さらに、ダウンタイムによる業務停止の影響は非常に深刻です。

UDB は、エージェント ノード、プライマリ データベース、スタンバイ データベースを含むシンプルで実用的かつ信頼性の高いインフラストラクチャを通じて上記の問題を解決します。

このアーキテクチャの利点は次のとおりです。

1) コンポーネントが比較的少ないため、非常にシンプルです。アーキテクチャ設計の面では、UDB は常に「シンプルであることは信頼できること」という原則を堅持してきました。

2) ノードを異なるアベイラビリティ ゾーンに分散して、アベイラビリティ ゾーン全体の災害復旧要件を満たすことができます。

アクティブ スタンバイ モードにより、どのコンポーネントもアクティブ スタンバイとホット スタンバイを持つため、DB 災害復旧とプロキシ災害復旧という 2 つの層の災害復旧を実現できます。次の図は、DB データの災害復旧を示しています。 DB 災害復旧用のオリジナルの VIP エージェントはプライマリ データベースであり、災害復旧を実行する際にはバックアップ データベースとして機能するため、非常にシンプルです。

もう 1 つは、VIP が可用性ゾーン間を移動できるようにするプロキシ災害復旧です。 VPC2.0 ネットワーク アーキテクチャでは、VIP はアベイラビリティー ゾーン 1 からアベイラビリティー ゾーン 2 に直接移動できます。

金融・保険業界を例にとると、セキュリティ上の制約により、金融業界では「2拠点3センター」体制が求められています。 UCloud の 2 か所、3 つのセンターのソリューションでは、まず、可用性ゾーン全体にわたる高可用性製品を使用して、北京データセンターにメイン データベースを構築します。同時に上海にもバックアップデータベースがあり、UDPNネットワーク専用回線で接続されています。 UDTS データ伝送製品と組み合わせることで、信頼性が高く継続的なデータ伝送が可能になり、「2 拠点 3 センター」の要件を満たすことができます。

インターネットユーザーも「2つの拠点と3つのセンター」を必要としています。ネットワーク UDPN が接続されると、スレーブ データベースはマスター データベースと自然に同期できます。マスターとスレーブの関係が確立され、ネットワークが接続されている限り、これらの 3 つの可用性ゾーンに地域の災害復旧機能を自然に実装できます。 MongoDB の 2 サイトの災害復旧ソリューションはよりシンプルです。

◆ アプリケーションシナリオにおける高いパフォーマンス

データベースを使用する際の最も一般的なボトルネックは I/O です。通常の DB は、I/O を集中的に使用するアプリケーションに対しては非常に受動的であり、これは主に DB の応答が遅いという形で現れます。その結果、ネットワーク遅延の増加、クエリの低速化、接続の増加といった複雑な問題が発生します。雪崩効果により DB が簡単にダウンする可能性があります。

UCloud は、最下層に PCI-e と NVMe SSD を使用し、I/O 機能のスループットが非常に大きい高性能 SSD モデルというソリューションを提供します。パフォーマンス要件が高い場合は、他のマシンとの I/O 競合なしにマシン全体を使用できるように、専用インスタンスを使用することをお勧めします。要件がさらに高い場合は、容量を拡張できるだけでなく、パフォーマンスも弾力的に拡張できる分散データベース UDDB が推奨されます。典型的な顧客には、特に高い I/O 要件を持つインターネット、ゲーム、電子商取引、ソーシャル ネットワーキング業界のユーザーが含まれます。統計によると、高性能 SSD UDB は多くのユーザーの重要なビジネスにとって第一の選択肢となっています。

単一ノードのパフォーマンスがビジネスニーズを満たせない場合、UCloud はパフォーマンスを飛躍的に拡張できる読み取り/書き込み分離ソリューションを提供します。名前が示すように、読み取り書き込み分離とは、「読み取り」と「書き込み」が分離されていることを意味します。 「書き込み」は 1 つのノードに配置し、「読み取り」は他のスレーブに配置できます。基本的なアーキテクチャ図は次のとおりです。

UCloud には、オンライン カラオケ アプリを実行し、独自に構築したデータベースから UCloud クラウド プラットフォームに移行したユーザーがいます。当時、急速なビジネスの成長により、ユーザーのデータベースでパフォーマンスのボトルネックが発生していました。この読み取り/書き込み分離ソリューションを使用した後、パフォーマンスが飛躍的に向上しました。ユーザーは「1 つのマスターと 5 つのスレーブ」アーキテクチャを使用し、スループットを 6 倍に増加できました。スループットだけでなく接続数も増加できます。したがって、読み取りと書き込みの分離により、ビジネスは単一ポイント接続の数や単一ポイントの容量によって制限されなくなります。データベースのスループット容量は並行して拡張できます。接続数が増えるにつれて、同時実行能力はますます強力になります。

◆ アプリケーションシナリオの柔軟な拡張

インターネット アプリケーションには、「最初は小さくても急速に成長する」という特性があります。これらのアプリケーションでは、クラウド プラットフォームの柔軟な拡張機能に対する要件が非常に高く、まず、基盤となるインフラストラクチャに柔軟な拡張機能が必要です。アプリケーション層から見ると、バックエンドのステートレス サービスは弾力的に拡張するのが非常に簡単ですが、DB はステートフルです。 2 番目に、ホット アプリケーションがあります。つまり、DB 全体がこのアプリケーションを提供しているため、DB 全体のパフォーマンスが簡単に低下する可能性があります。

ビジネスが成長し続けるにつれ、特定のアプリケーション プラットフォームのバックエンドにある単一ポイント データベースは当初、大きな負担にさらされるようになりました。 UDB では、データベース アーキテクチャは、ビジネスの成長の圧力に耐えながら、単一の MongoDB プライマリ ポイントから高可用性レプリカ セット、そしてシャード クラスターへと段階的に進化してきました。データ量はシャードの数に応じて直線的に増加します。

たとえば、トップ 10 にランクインしたソーシャル アプリケーション APP のビジネスでは、年間 30 億のデータ項目の成長に達する可能性がありますが、これは比較的控えめな見積もりです。 APP は、弾力的な拡張性、優れたビジネス互換性、優れた費用対効果を備えたソリューションを望んでいます。当時、アプリケーションにはすでに毎日大量のデータがあり、クエリはすでにインデックスを通過していたため、単純な SQL 最適化では大きな改善は見られませんでした。

UCloud が推奨するソリューションは UDDB です。

このソリューションにはいくつかの利点があり、このソーシャル アプリケーション APP のニーズを非常によく満たしています。

弾力的な拡張: データの増加に対応するには、UDB ノードを追加し、新しく生成されたデータを新しいノードに書き込むだけです。

サイレント拡張: 拡張操作はビジネスに 100% 影響しません。

従量課金制: ビジネス開始の初期段階では、今後 3 か月間のデータ保存に 1 つのノードのみを購入すれば済みます。ビジネスが急速に成長した場合は、過剰な初期投資を避けるためにノードを追加できます。

高いビジネス互換性: 顧客のビジネス プログラムでは、2 つの SQL ステートメントを変更するだけで済みます。

◆ アプリケーションシナリオにおける高いコストパフォーマンス

顧客ビジネスによっては、膨大な量のデータの保存が必要になる場合があります。たとえば、IoT のシナリオでは、一部のスマート端末が 1 日に数億個のデータを収集します。収集されたデータは長期間（たとえば 3 か月）保存および保持する必要があります。このような高い同時実行性と継続的なデータ書き込みに直面した場合、UDDB ソリューションは顧客のニーズにも十分に対応できます。

同様のシナリオでは、物理マシンを使用して独自のデータベースを構築する場合、隠れた投資は非常に大きくなります。 UCloud では、データベース コストを効果的に削減できる高圧縮 UDB+ データベース ゾーン ソリューションを推奨しています。データベースゾーンが専用なので、マシン全体の利用率を向上できます。ゾーン内のマシンはより大きな保管スペースがあり、時間の経過とともにローリング方式で再利用できます。同時に、IoT アプリケーションには大量のコールド データが含まれているため、DB 圧縮後は、通常のデータ ディスクでも顧客のニーズを満たすことができます。 ***得られた効果は、データベース全体のサイズ圧縮率が約3.2倍、データ量が当初の150TBから現在の52TBに削減され、全体的なコストが26%節約されたことです。

UDBの将来展望

UDB 製品マネージャーの観点から見ると、UDB の将来に対する期待は、ユーザーがデータベースを入手して使用するための障壁を排除することです。現在では、取得の障壁が取り除かれ、ユーザーはクラウド データベースをオンラインで便利に購入できるようになりました。

UDB 製品が徐々に成熟し、改善されるにつれて、ユーザーはいくつかのオーケストレーション作業を行うだけでよくなり、バックエンドの技術的な詳細にあまり注意を払うことなく、バックエンド アプリケーションを直接使用できるようになります。しかし、これでは十分ではありません。クラウド データベースの入手障壁は基本的に解決されたため、使用障壁を下げるためにさらに多くの努力を払う必要があります。そのため、今後は、ユーザーのビジネスをサポートし、ユーザーをデータベースから完全に「解放」するために、より多くの製品機能と機能を実装する必要があります。