YugabyteDB はオンプレミスやクラウドはもちろん、マルチクラウドやハイブリッドクラウドも含め、様々な環境に対応しております。また、YugabyteDB では構成パターンや構成オプションが多く用意されており、アプリケーション要件に応じて、柔軟に環境や構成を選ぶことができます。

本記事では、これから YugabyteDB を使ってみたい、または構成を検討している方向けに、次の5つの YugabyteDB の構成パターンについて紹介します。

1. シングルリージョンマルチAZ
2. マルチリージョン
3. xCluster
4. 地理的パーティショニング
5. リードレプリカ

構成パターン1：シングルリージョンマルチAZ

YugabyteDB をデプロイするときに、まず最初にシングルリージョンを利用するのか、マルチリージョンを利用するのかを決めておく必要があります。こちらは主にアプリケーションの可用性要件に依存します。シングルリージョンとマルチリージョンは可用性と性能のトレードオフがあります。マルチリージョンの場合は、リージョン障害に対する回復力を持たせることが可能ですが、リージョン通信のレイテンシが増加するという代償が伴います。シングルリージョン構成でアプリケーションの可用性要件を十分に満たせるのであれば、性能観点からはシングルリージョンが良いのではないかと考えます。

本番環境で利用する場合、可用性のために少なくとも3ノード以上が必要です。シングルAZに複数ノードをデプロイしても良いのですが、可用性の観点からは、ゾーン障害にも対応できるように、同一リージョン内の異なるAZにそれぞれノードをデプロイすることをお勧めします。

マルチAZ構成の場合はシングルAZ構成に比べると、可用性が大幅に向上します。リージョンを跨らないので、マルチリージョン構成に比べると、レイテンシが抑えられることもメリットとなります。

構成パターン2：マルチリージョン

アプリケーションの可用性要件としてリージョンレベルの障害に対する回復力が必須でしたら、マルチリージョン構成を選択頂くことになります。

マルチリージョン構成は「構成パターン1：シングルリージョンマルチAZ」と似ていますが、同一リージョン内の異なるAZでなく、それぞれ異なるリージョンにクラスタのノードをデプロイします。

1つのリージョンに障害が発生しても、あるいは自然災害で、リージョンがダウンしても、他の2つのリージョンでサービスを継続することが可能です。ただし、デメリットとしては、書き込みと読み取りレイテンシがシングルリージョン構成に比べて若干高くなります。

「構成パターン1：シングルリージョンマルチAZ」と「構成パターン2：マルチリージョン」ともにノード間のデータの複製は同期レプリケーションなので、障害が発生したとしても、データの損失はないことが保証されます。

構成パターン3：xCluster

前述の2つの構成は単一の YugabyteDB クラスタを複数のAZ、あるいは複数のリージョンに跨ってデプロイする手法です。YugabyteDB では 2つのYugabyteDBクラスタを異なるリージョンにデプロイする、xCluster と呼ばれる構成も利用可能です。クラスタ間で双方向、または単一方向の非同期レプリケーションによってデータの同期が行われます。

各クラスタ内では、ノード間の通信はリージョンを跨らないので、レイテンシが低いというメリットがあります。1つのリージョンがダウンしても、別のリージョンに存在するクラスタでサービスを継続させることで、システムのダウンタイムを最小限に抑え、迅速に障害や災害から復旧することが可能になります。

前述の「構成パターン2：マルチリージョン」構成でもリージョン障害には対応できますが、リージョン通信のレイテンシが増加するという代償が伴います。一方、xCluster はレイテンシを抑えつつ、リージョンレベルの可用性を実現できます。ただし、クラスタ間では非同期レプリケーションなので、障害時にデータ損失が発生する可能性があります。

マルチリージョン構成と xCluster、どちらでもDR（ディザスタリカバリ）目的で利用可能ですが、性能と信頼性のトレードオフがあり、アプリケーションの要件に応じて構成を選択する必要があります。

構成パターン4：地理的パーティショニング

地理的パーティショニングとは、テーブルパーティショニングと tablespace 機能を使って特定のパーティションテーブルを特定の地域に紐づけて、行単位でデータの地理的な配置場所を制御する機能です。複数の拠点に分散したアプリケーションに適した構成です。

例えば、グローバルに広がった複数の拠点に跨って YugabyteDB をデプロイし、利用ユーザの近いところにデータを配置することで、よりレイテンシを抑えることができます。また、個人情報など機密性の高い情報を国内や特定の地域のデータセンターに保管する、といったユースケースにも最適です。

利用するユーザは、ローカルリージョンにあるデータにアクセスするので、レイテンシを低く抑えることができます。1つのリージョンがダウンしても、他の2つのリージョンでサービスを継続することができますので、リージョンレベルの可用性を保証します。各リージョン内の異なるゾーンにノードをデプロイすることで、ゾーンレベルの障害にも回復力を持たせることが可能です。

構成パターン5：リードレプリカ

YugabyteDB では、リードレプリカと呼ばれる、プライマリクラスタと異なるリージョンに読み取り専用のノードを構成することができます。この構成を利用することで、ユーザは近い場所にあるリードレプリカからデータを読み取ることができるので、読み取りレイテンシを軽減する効果があります。

特定のリージョンからのみ書き込みが発生し、参照するユーザは世界中に存在するようなアプリケーションに活用できます。

具体的には、次のような動作になります。

• プライマリクラスタのデータが自動的に非同期で1つあるいは複数のリモートリージョン(リードレプリカ)に複製されます。
• 基本的にはプライマリクラスタは読み書き、リードレプリカは読み取り専用ですが、リードレプリカに対して、書き込みも行えます。その場合は、プライマリクラスタにリダイレクトされます。
• ユーザは近い場所にあるリードレプリカからデータを読み取るので、レイテンシが低いというメリットがあります。
• プライマリクラスタとリードレプリカの間は非同期レプリケーションとなりますので、どの程度のデータの遅延が許容できるかはパラメータyb_follower_read_staleness_msで設定できます。デフォルトは 30 秒です。
• リードレプリカは Raft コンセンサスに関与しないので、可用性はプライマリクラスタの可用性に依存することにご注意ください。

まとめ

ここまで YugabyteDB の5つの構成パターンについて紹介しました。

それぞれの構成にメリットがありますので、ここでは可用性や性能において各構成の特徴をまとめつつ、使い分けポイントや用途について説明します。

終わりに

今回は、PostgreSQL/Cassandra 互換の分散 SQL データベース YugabyteDB の構成パターンおよびそれぞれの特徴や用途について紹介しました。

YugabyteDB の構成パターンが多いため、導入する前に、それぞれの構成のメリット・デメリットを理解し、目的や用途に合った構成を選ぶことが重要です。本記事の内容が YugabyteDB の構成を検討していただく際にお役に立てば幸いです。