前回の記事では、分散データベース YugabyteDB の概要や特長、アーキテクチャについて紹介しました。
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 の地理的パーティショニング機能はこのようなユースケースには最適です。
例えば、1つのテーブルの中で世界中のユーザ情報を管理しているケースで、国を表す列でパーティション分割して、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 のスケーラビリティのメリットを活かしたユースケースでの利用実績があり、今後も利用する企業は増えてくると思います。