RDBMS と NoSQL にはそれぞれの得意不得意がありますが、YugabyteDB はそれぞれの不得意な部分を補い、RDBMS と NoSQL の両方の特長を融合して設計されたデータベース技術です。YugabyteDB を使用することで、データの厳密な一貫性を保ちながら、水平方向スケーラビリティ、高可用性を実現できます。

YugabyteDB を導入する前に、YugabyteDB が適したユースケースを理解することが重要ですので、今回の記事では、YugabyteDB のユースケース、従来のデータベースソリューションとの使い分けのポイントについて紹介します。

YugabyteDB に適したユースケース

以下のいずれかのユースケースにあてはまる場合に、YugabyteDB が有力な選択肢となると言えます。

• 強力な一貫性に加えて高い可用性と高い同時実行性が求められるアプリケーションの場合
• 大規模で、ビジネスの成長とともに処理するデータ量が増加するアプリケーションの場合
• 季節的なアクセス急増、あるいは今後のアクセス急増が予想される場合
• シンプルな構成で高可用性や災害対策、スケーラビリティを実現したい、運用を楽にしたい場合
• グローバルにサービスを展開したい場合
• 行単位でデータの地理的な配置場所を制御したい場合
• データベースのモダナイズしたい場合

強力な一貫性に加えて高い可用性と高い同時実行性が求められるアプリケーションの場合

強力な一貫性と高い可用性が求められるような、いわゆるミッションクリティカルなシステムの例としては、金融システムや決済システム、ECサイト、基幹系業務システムなどが挙げられます。

これらのアプリケーション、特に銀行システムにおいて、トランザクション管理はデータの一貫性を保つために非常に重要なものです。しかし、従来のデータベースでは分散したデータの一貫性を担保するのが大きな課題でした。YugabyteDB は分散トランザクションに対応しており、複数ノードにまたがってトランザクション処理しても強力なデータ一貫性を保証できます。

これらのシステムでは、ダウンタイムのない、24時間365日の安定稼働が求められます。

従来のオープンソースの RDBMS には可用性機能が提供されていないため、高可用性を実現するために、外部クラスタソフトウェアを導入するのが一般的です。稼働系に障害が発生した場合、自動的に待機系を昇格し、待機系へ切り替えることで、継続してサービスを提供することができます。ただし、このような構成では系統切り替え時に若干のダウンタイムが発生します。

YugabyteDB は高い可用性を持っています。従来の RDBMS のように障害時に系統切り替え処理は必要ないので、データベースノードに障害が起こったとしても、クライアントからの接続は切断されず、透過的に他のノードに切り替えることで、ダウンタイムなくデータベースの運用を続行できます。

障害時だけではなく、スケーリングやバージョンアップなどのメンテナンス時にも、ダウンタイムなくサービス継続を維持したままメンテナンスを行うことができます。

YugabyteDB を利用することで、非常に高い可用性要件を実現できます。

また、YugabyteDB は必要に応じて容易に拡張できるので、性能を維持したままアクセス数の急増にも対応できます。

大規模で、ビジネスの成長とともに処理するデータ量が増加するアプリケーションの場合

従来の RDBMS ではプライマリでしか書き込み処理を受け付けられないという特性があり、同時アクセス数が増加し、処理するデータ量が大規模になると、処理性能が落ちてしまいます。一方、YugabyteDB は水平方向の拡張性に優れており、RDBMS のプライマリでしか書き込み処理できないという制限に対して、YugabyteDB はどのノードでも書き込み処理を行えます。ノードを増やすことで書き込み処理負荷を分散できるので、大規模で同時書き込みが多いシステムでは、RDBMS と比べて高い性能を実現できます。

YugabyteDB は 1台のサーバではさばけないほど膨大なデータを扱い、今後もデータ量の増加が予想されるようなアプリケーションに適しています。

ただ、小規模なアプリケーションでも YugabyteDB のダウンタイムのない、高可用性のメリットを享受したいというケースもあるかと思いますので、RDBMS より多少レイテンシーが増えても、許容範囲内であれば、小規模なアプリケーションでも YugabyteDB を検討する余地があると言えるでしょう。YugabyteDB の導入を検討する際に、必ず事前検証を行い、アプリケーションの要件を満たすことができるかを確認してください。

季節的なアクセス急増、あるいは今後のアクセス急増が予想される場合

こちらは最も YugabyteDB のスケールの柔軟性の恩恵を受けられるユースケースと言えます。

何らかのビジネスの施策によって、サイトへのアクセス数が一気に増えて、レスポンスが悪くなったり、最悪の場合はサーバダウンが起こってしまう可能性があります。もしサーバがダウンしてしまうと、ビジネスチャンスを逃してしまう恐れがあります。

このようなアプリケーションの例としては、ECサイトやオンラインゲームのプラットフォームなどが挙げられます。

例えば、ECサイトでキャンペーンやタイムセールなどを行う場合は、一次的なアクセス急増が予測されます。増加する負荷にも耐えられるように、事前にスケールアウトしておくことで、アクセス集中による影響を防ぐことが可能です。キャンペーンが終了後にアクセスが落ち着いたら、スケールインして、コストを抑えることも可能です。

また、ゲーム制作会社は新しいゲームの発売に伴って、ユーザが急増する状況も想定されます。YugabyteDB は簡単にスケールアウトできるので、ユーザが急増する状況にも容易に対応できます。

シンプルな構成で高可用性や災害対策、スケーラビリティを実現したい、運用を楽にしたい

従来のデータベースでは可用性や水平方向スケーラビリティを実現するために、構成が複雑になってしまい、運用の手間がかかります。

YugabyteDB には高可用性と自動シャーディング機能がビルトインされており、外部コンポーネントを導入する必要がなく、シンプルな構成でスケーラビリティや継続的な可用性を実現できます。

また、従来の災害対策としては、複数のサイトを用意して、サイト間で非同期レプリケーション、あるいは、カスケードレプリケーションを使って、データの同期を行う構成がよく使われています。この構成では、サイトの障害を自動的に検知できなく、メインサイトに障害が発生した場合には、手動でDRサイトを昇格する必要があるので、復旧に多くの時間がかかり、運用がやや複雑という欠点があります。

YugabyteDB はマルチ AZ、マルチリージョン、マルチクラウド、ハイブリッドクラウドなど、構成パターンが多様で、可用性要件に応じて柔軟に構成パターンを選択でき、データセンター、リージョン、クラウドサービスまで、あらゆる規模の障害や災害に対してダウンタイムなしで回復できます。

さらに、フルマネージドサービスである YugabyteDB Managed も提供されています。管理コンソールで数回クリックするだけで指定したクラウド上にデータベースクラスタを迅速に構築できます。従来のように、サーバの構築、OS やミドルウェアのインストール・設定などのインフラ作業を行わなくて済むので、ビジネスを支えるアプリケーションの開発に集中でき、俊敏性の向上やコスト削減を実現できます。

グローバルにサービスを展開したい場合

YugabyteDB はグローバルに広がったアプリケーションの場合にも活用できます。

例えば、グローバルに広がった複数の拠点にまたがって YugabyteDB をデプロイし、利用ユーザの近いところにデータを配置することで、よりレイテンシーを抑えることが可能になります。

行単位でデータの地理的な配置場所を制御したい場合

最近、個人情報保護意識が高まっており、個人情報を国内や特定の地域のデータセンターに保管しなければならないケースが増えています。YugabyteDB の地理的パーティショニング機能はこのようなユースケースには最適です。

例えば、１つのテーブルの中で世界中のユーザ情報を管理しているケースで、国を表す列でパーティション分割して、tablespace 機能を使って特定のパーティションテーブルを特定の地域に紐づけて、行単位でデータの地理的な配置場所を制御することが可能です。

データベースのモダナイズしたい場合

クラウドネイティブの登場で、アプリケーションのアーキテクチャが変化しつつあります。従来のモノリシックなデータベースは、アプリケーションの俊敏性、スケーラビリティ、柔軟性を損なってしまうので、データベースの革新も求められるようになっています。

YugabyteDB は一貫性、スケーラビリティ、高可用性を兼ね備えたクラウドネイティブな分散型 SQL データベースであり、YugabyteDB を利用することで、従来のモノリシックなデータベースの課題を解決できます。

また、YugabyteDB はクラウドネイティブプラットフォーム Kubernetes にも対応しており、アプリケーションや Web サーバ、データベースを含むシステム全体を Kubernetes 移行を検討している場合は、YugabyteDB が有力な選択肢と言えます。

類似製品の使い分け

YugabyteDB の他に、Pacemaker や Pgpool-II による PostgreSQL 冗長化構成、マネージドサービス Amazon Aurora もよく使われています。

いくつかのソリューションの中から目的や課題にあった最適なソリューションを選択するには、それぞれの違いを理解しておくことが大事です。ここでは、それぞれのソリューションの使い分けのポイント、考慮すべきことを紹介します。

可用性、水平方向スケーラビリティの観点で比較した結果は以下の表のようになります。

	YugabyteDB	Amazon Aurora	PostgreSQL HA (Pgpool-II)	PostgreSQL HA (Pacemaker)
オープンソース		✘
マネージドサービス			✘	✘
ゼロダウンタイム		✘	✘	✘
参照負荷分散				✘
更新負荷分散		✘	✘	✘
地理分散		✘	✘	✘

YugabyteDB は PostgreSQL/Cassandra との互換インターフェイスを持っているとしても、中身はまったく異なるアーキテクチャになりますので、分散データベースアーキテクチャにあったデータベースの設計が重要です。

小規模で、アプリケーションの改修やスキーマ変更は極力避けたい、十数秒～数分程度のダウンタイムがあったとしても許容されるようなアプリケーションの場合は、Pacemaker/Pgpool-II を使った冗長化構成の方が良いのではないかと思います。

極めてダウンタイムをなくしたい場合や、PostgreSQL ではさばけないほどの書き込み量に対応したい場合には YugabyteDB の利用が適切でしょう。

終わりに

今回の記事では、YugabyteDB のユースケースや従来のソリューションとの使い分けのポイントについて紹介します。

多くのアプリケーションには PostgreSQL は十分に耐えられていますが、PostgreSQL では実現できないこと、(例えば、ゼロダウンタイムの可用性やスケーラビリティ) が求められるようなユースケースには、YugabyteDB は有力な選択肢と言えるでしょう。

国内でも YugabyteDB のスケーラビリティのメリットを活かしたユースケースでの利用実績があり、今後も利用する企業は増えてくると思います。

RDBMS と NoSQL にはそれぞれの得意不得意がありますが、分散 SQL データベースはこのような拡張性と一貫性のトレードオフをなくし、RDBMS と NoSQL の両方の特長を融合して設計されたデータベース技術です。

現在様々な分散 SQL データベース製品が開発されていますが、その中で PostgreSQL および Cassandra との互換性を持つ、代表的なものとして YugabyteDB という製品があります。本記事では、YugabyteDB の概要、特長、アーキテクチャについて紹介します。

YugabyteDB とは

YugabyteDB は、Google Spanner の設計からインスピレーションを得て開発されたオープンソースの分散 SQL データベースです。米国に本社を置く Yugabyte 社によって開発されています。

PostgreSQL および Cassandra と互換性を持ち、一貫性、拡張性、高可用性を兼ね備えたクラウドネイティブな分散型 SQL データベースです。

YugabyteDBの特長

YugabyteDB には次のような特長があります。

PostgreSQL/Cassandra 互換

YugabyteDB は RDBMS の PostgreSQL および NoSQL の Cassandra と高い互換性を持ち、PostgreSQL や Cassandra から YugabyteDB への移行に伴うアプリケーションの修正は少なくて済みます。

一貫性と拡張性の両立

従来の RDBMS では、SQL を使って複雑な集計や検索などの操作が可能です。また、トランザクションに対応しており、厳密なデータの一貫性が保証されるのが特長です。RDBMS は一貫性を保つためにもともとは 1台のサーバで実行するよう設計されているので、拡張しにくいというデメリットがあります。同じ状態を持つ複数サーバを用意して、読み取り処理を分散させることは可能ですが、書き込み処理は一貫性を保つために複数のサーバで並行して処理できません。データが大規模になると、処理速度が低下してしまうというのが RDBMS の大きな課題の1つとなります。

RDBMS のこういった性能課題に対して、NoSQL はデータの一貫性を犠牲にしているので、水平方向拡張性や可用性に優れています。必要に応じて自由に拡張できるので、大規模なデータであっても高速に処理できます。

YugabyteDB はこのような性能と一貫性のトレードオフをなくした、「一貫性」、「拡張性」、「高可用性」を兼ね備えたクラウドネイティブな分散データベースです。

読み取り・書き込み負荷分散

ローカルのディスクへアクセスしてデータを処理する RDBMS は複数のノードにまたがってデータを処理する YugabyteDB より処理速度は速いですが、大規模データになると、処理性能が落ちてしまいます。サーバのスペックを増やすことで性能が改善されますが、限界があります。同じ状態を持つ複数サーバを用意して、読み取りは分散して処理することはできますが、書き込みは一貫性を保つために、分散して処理できません。そのため、RDBMS は大規模データの書き込み処理能力が求められるアプリケーションには適していません。

YugabyteDB は水平方向拡張性や柔軟性に優れているため、処理するデータ量の増減に応じて、柔軟にスケールアウト/スケールインできます。また、RDBMS の書き込み処理が分散できないという弱点に対して、YugabyteDB はどのノードでも書き込み処理を行え、複数のサーバで分散して処理できるので、大規模で同時接続数が多いシステムでは、RDBMS と比べて高い性能を実現できます。

YugabyteDB は 1台のサーバではさばけないほど膨大なデータを扱い、今後もデータ量の増加が予想されるようなアプリケーションに適しています。

高可用性・耐障害性

従来のデータベースでは高可用性を実現するには、外部クラスタリングソフトウェアを利用するのが一般的です。クラスタリングソフトウェアは、常にデータベースサーバを監視し、プライマリに障害が発生した場合、レプリカを昇格し、レプリカへ切り替えることで、サービスを継続します。ただし、このような構成では系統切り替え時に若干のダウンタイムが発生するというデメリットがあります。

YugabyteDB には高可用性機能がビルトインされており、追加クラスタリングソフトウェアを導入する必要がなく、シンプルな構成で継続的な可用性を実現できます。また、系統切り替え処理は必要ないので、データベースノードに障害が起きたとしても、ダウンタイムなくデータベースの運用を続行できます。従来のデータベースの HA 構成より可用性に優れています。

また、YugabyteDB はマルチ AZ、マルチリージョン、マルチクラウド、ハイブリッドクラウド構成にも対応しているため、クラウドサービス、リージョン、データセンターなど、あらゆる規模での耐障害性を提供しています。

企業競争力を高める俊敏性

クラウドネイティブ時代に、企業の競争力を高める、俊敏性が強く求められています。従来のデータベースでは可用性や拡張性を実現するために、構成が複雑になってしまい、俊敏性が失われてしまいます。YugabyteDB は可用性と拡張性を併せ持ったオールインワンのソリューションなので、より迅速にデータベースクラスタを構築でき、リリースサイクルを短縮することができます。

さらに、フルマネージドサービスである YugabyteDB Managed も提供されています。管理コンソールで数回クリックするだけで指定したクラウド上にデータベースクラスタを迅速に構築できます。従来のように、サーバの構築、OS やミドルウェアのインストール・設定などのインフラ作業を行わなくて済むので、ビジネスを支えるアプリケーションの開発に集中でき、より俊敏性を高め、TCO 削減を実現できます。

地理分散

地理分散というのは、地理的に離れた複数の場所にまたがったデータベースクラスタのことで、デプロイメントパターンの1つです。

近年、データセンター障害や自然災害が発生した際に、早期復旧または事業継続を図るための対策の重要性が高まっています。地理分散デプロイメントを利用することで、データセンターの障害や自然災害が起こったとしても、サービスを中断することなく、継続して利用可能です。特定のリージョンで障害が起こっても、別のリージョンにあるノードが処理を継続するため、リージョン障害に対する回復力を持たせることが可能になります。

また、地理的に分散した場所にまたがるアプリケーションの場合にも活用できます。例えば、グローバルに広がった複数の拠点にまたがって YugabyteDB をデプロイし、利用ユーザの近いところにデータを配置することで、よりレイテンシーを抑えることが可能になります。

また、個人情報など機密性の高い情報を国内や特定の地域のデータセンターに保管する、といったユースケースに最適です。

様々な稼働環境に対応

YugabyteDB はオンプレミスやクラウド、仮想環境はもちろん、Kubernetes などのコンテナプラットフォームも含め、様々な環境に対応しており、マルチクラウドやハイブリッドクラウドでも利用できます。

また、YugabyteDB ではデプロイメントパターンや構成オプションが多く用意されており、アプリケーション要件に応じて、柔軟に環境や構成を選ぶことができます。

YugabyteDB の製品ラインナップ

YugabyteDB のコアとなる機能はオープンソースとして公開されており、無償で利用できます。

有償製品として、YugabyteDB Aeon があり、Self-Managed、Bring Your Own Cloud (BYOC) および Full-Managed の3つのオプションが提供されています。

YugabyteDB のアーキテクチャ

従来の RDBMS との違い

従来の RDBMS ではプライマリしか書き込み処理を受け付けられないという特性があり、冗長構成する場合は、書き込み処理をプライマリに送って、ストリーミングレプリケーションを使ってプライマリとレプリカの同期を行うのが一般的です。

一方、YugabyteDB ではプライマリとレプリカといった役割がなく、すべてのノードがプライマリとして振る舞い、書き込み処理を受け付けます。

YugabyteDB の内部構造

YugabyteDB は YB-Master と YB-TServer の2つコンポーネントから構成されています。

YB-Master と YB-TServer の役割は以下の通りです。

• YB-Master: クラスタ全体のメタデータの管理、構成管理
• YB-TServer: アプリケーションからのクエリを処理して、データとして保持

YB-Master は Raft という分散合意アルゴリズムを使って、冗長化しています。YugabyteDB のノードをデプロイすると、YB-Master と YB-TServer が自動的に作成されますが、YB-Master は最大 replication factor の数までしか作成されません。

replication factor とはデータのコピーの数のことです。つまり、同一データを保持する tablet peer における tablet の数のことです。(tablet については後述します。)

例えば、replication factor = 3 で 5ノードのクラスタを作成すると、以下のような構成になります。

 YB-TServerの内部構造

ここでは、YB-TServer の内部構造について紹介します。

YB-TServer はクエリを処理するクエリレイヤとデータを処理するストレージレイヤの2つのレイヤに分かれています。

クエリレイヤは PostgreSQL 互換の API および Cassandra 互換の API をサポートしています。クエリレイヤは PostgreSQL のクエリ処理部分を再利用しているので、PostgreSQL との高い互換性を実現しています。クエリレイヤがクライアントリクエストを受け付けて、クエリを処理して、下位ストレージレイヤに送ります。

下位のストレージレイヤでは、テーブルとインデックスのデータは、自動的に複数のシャード(YugabyteDB では tablet と呼ばれる。以降、tablet) に分割され、各ノードの DocDB に分散配置されます。ノード間でデータの複製は tablet 単位で行われ、同じデータを持っている、複数の tablet 群が tablet peer と呼ばれます。各 tablet peer は1つの leader と複数の follower から構成され、内部的に Raft という合意アルゴリズムを使っています。基本的にはユーザからの書き込み・読み取り処理は leader に対して実行されます。

障害時にもサービスが継続

YugabyteDB では、書き込み・読み取り処理は基本的には leader tablet に対して実行されますが、leader tablet がダウンしたら、どうのようにサービスを継続させるのか。ここでは、障害が発生した場合の挙動について説明します。

leader がダウンしたら、YugabyteDB が自動的に障害の発生を検出でき、3秒以内にいずれかの follower を leader に昇格させ、処理を継続します。table peer 単位で一定の値の tablet 数(=replication factor) を維持しないといけないため、別のノードに follower がリバランスされます。

クライアントからの接続は透過的に新しいリーダーに継続し、ユーザにデータベースノードがダウンしたことを意識させることなく継続使用が可能となります。また、leader と follower 間では、同期レプリケーションのため、ノード障害が発生しても、データの損失はありません。

スケールアウト

YugabyteDB では、簡単にノード数を増やすことができるので、アクセス数が増えた場合にも、容易に対応できるというメリットがあります。ノードを追加すると、leader と follower がノード間で均等に配置されるように自動的にリバランスされます。

終わりに

今回は、PostgreSQL/Cassandra 互換の分散 SQL データベース YugabyteDB の概要や特長、アーキテクチャについて紹介しました。

YugabyteDB を使うことによって、サービスのダウンタイムの短縮、高い可用性、大容量データに対する高い処理性能など多くのメリットを得られます。PostgreSQL と高い互換性を持ち、アプリケーションの修正は少なくて済むので、比較的容易に移行できます。既存の PostgreSQL では解決できない書き込み性能問題や障害によるダウンタイムを改善したい場合は、YugabyteDB の使用を検討してみてはいかがでしょうか。

次回は、YugabyteDBのユースケースや構成について詳しく紹介します。