前回の記事では、YugabyteDB OSS版の使い方について紹介しました。

今回は有償版 YugabyteDB Aeon Self-Managed (旧 YugabyteDB Anywhere) の使い方について紹介します。

YugabyteDB Aeon Self-Managed (以下、YugabyteDB Anywhere) のデプロイおよび管理は、Web UI から行うか、以下の自動化ツールを利用して行います。本記事では、Web UIからの操作方法について紹介します。

• REST API
• Terraform
• CLI
• Kubernetes Operator

YugabyteDB Anywhere の構成

YugabyteDB Anywhere は YugabyteDB データベースクラスタのデプロイと管理を行うコントロールプレーン (以下、YBA) と Universe と呼ばれるデータベースノードで構成されています。

構成図は次の通りです。

デプロイ環境およびバージョン情報

YugabyteDB Anywhere は、その名前の通り、パブリッククラウド、Kubernetes、物理サーバ、仮想環境、プライベートクラウドなど、さまざまなプラットフォームに対応しています。

本記事では、同一リージョン内の3つの AZ に配置された EC2 インスタンスに YugabyteDB Anywhere をデプロイする方法を紹介します。

クラスタ構成は次の通りです。

事前準備

• YugabyteDB Anywhere ライセンスの準備
• サーバの準備
  YBA をインストールするサーバを準備します。YBA サーバのハードウェアやソフトウェア要件、対応OSについてはこちらを参照してください。
  オンプレミスで利用する場合は、データベースノード用のサーバを事前に準備する必要がありますが、本記事ではクラウド環境を利用するため、データベースノード用のサーバは自動的に作成され、プロビジョニングされるため、事前の準備は不要です。
• ネットワークの設定
  クラウド環境を利用する場合、使用する VPC やサブネット、セキュリティグループを事前に設定しておきます。YBA およびデータベースノードの特定ポート (構成図参照) へのアクセスを許可しておく必要があります。

YBA のインストール

以下のコマンドを実行し、YBA をインストールします。

$ wget https://downloads.yugabyte.com/releases/2024.1.3.0/yba_installer_full-2024.1.3.0-b105-linux-x86_64.tar.gz
$ tar -xf yba_installer_full-2024.1.3.0-b105-linux-x86_64.tar.gz
$ cd yba_installer_full-2024.1.3.0-b105/
$ sudo ./yba-ctl preflight
$ sudo ./yba-ctl install -l /path/to/license

インストールが完了すると、ブラウザから YBA の管理画面 https://<yugabytedbanywhere-host-ip>/register にアクセスし、Admin ユーザを作成し、ログインします。

ログインに成功すると、以下のダッシュボードが表示されます。

クラウドプロバイダーの設定

次に、クラウドプロバイダーの情報を登録します。

今回は AWS にデータベースクラスタを作成するため、「Integrations」 >「Create AWS Config」を選択します。

表示された画面で、アクセスキーとシークレットアクセスキーを入力します。

続いて、データベースノードがデプロイされるリージョンや AZ などの情報を追加します。

「Add Linux Version」を選択して、データベースノードのCPUアーキテクチャやAMIなどの情報を入力します。

Universe の作成

YugabyteDB Anywhere では YugabyteDB クラスタ全体を管理する単位を Universe と呼びます。

ここでは、Universe を作成する手順について説明します。

今回は以下の構成で Universe を作成します。

サイドバーから「Dashboard」または「Universes」を選択し、「Create Universe」をクリックします。必要な情報を入力し、作成ボタンをクリックします。

進捗は画面上で確認できます。

完了すると、以下のような画面が表示されます。

これで、Universe の作成が完了です。

Universeとデータベースノードの管理

ここでは、Universe とデータベースノードの管理方法について紹介します。

Universe のアップグレード、スケールアウト/スケールイン、構成変更などの管理は、作成済みの Universe を選択し、「Actions」>「Edit Universe」から行います。

ここでは、3ノードから6ノードへのスケールアウト方法を説明します。

「Actions」>「Edit Universe」を選択すると、Universe の設定画面が表示されます。「Total Nodes」を 3 から 6 に変更し、「Save」ボタンをクリックすると、ノードが追加されます。

各データベースノードの管理（例えば、ノードの再起動・停止、ログのダウンロード、スロークエリやライブクエリの表示など）は、Universe のノードタブ内にある各ノードの「Actions」ボタンから行えます。

バックアップ

バックアップの設定は、サイドバーの「backups」を選択し、「Backups」、「Scheduled Backup Policies」、「Point-in-time Recovery」タブから行います。

• Backups (オンデマンドバックアップ)/Scheduled Backup Policies (定期バックアップ)

オンデマンドバックアップの実行や定期バックアップの設定が可能です。バックアップデータは、事前に設定したストレージ（例えば、Amazon S3）に保存されます。

• Point-in-time Recovery (PITR)

特定のデータベースで PITR を有効にすると、1 日に 1 回データのスナップショットが取得され、各スナップショットには継続的な変更履歴が保持されます。そのスナップショットを使ってスナップショット内の任意の時点にリカバリが可能です。デフォルトではスナップショットは 7 日間保持され、過去 7 日間の任意の時点にリカバリできます。スナップショットの保持期間は設定で変更可能ですが、保持期間を延長するとディスク容量の消費が増加するため、注意が必要です。

モニタリング

OSS版ではメトリクスの収集や可視化のために Prometheus や Grafana を別途構築する必要がありますが、YugabyteDB Anywhere では外部ツールを導入せずに、標準でモニタリング機能を利用できます。

「Universes」 > 「Metrics」タブから、リソース監視やパフォーマンス監視のグラフを確認できます。

トラブルシューティングや性能問題の解決に役立つ機能

PostgreSQL では、トラブルシューティングの際に、pg_stat_activity ビューを使用して現在実行中の処理や開始時刻を確認したり、遅いクエリをログに出力する方法がありますが、YugabyteDB Anywhere では Web UI からこれらの情報を簡単に確認できます。

「Live Queries」タブでは、実行中のクエリや経過時間、クライアント情報などを確認できます。

「Slow Queries」タブでは、スロークエリの確認が可能です。また、特定のクエリで絞り込んで表示することもできます。

YugabyteDB Anywhere のメリット

ここまで、YugabyteDB Anywhere の使い方について紹介しました。

最後に、YugabyteDB OSS版と比較した YugabyteDB Anywhere のメリットをまとめます。

まず、運用方法に関して、OSS版ではコマンドライン操作が必要ですが、YugabyteDB Anywhere では Web UIを通じてデプロイや運用管理ができるため、運用管理の手間を大幅に削減できます。

次にセキュリティ面では、OSS版が事前に証明書を作成する必要があるのに対し、YugabyteDB Anywhere では証明書の自動生成や無停止での証明書更新がサポートされており、セキュリティ強化が容易です。

モニタリングについても、OSS版では Prometheus や Grafana などの外部ツールの導入が必要ですが、YugabyteDB Anywhere には標準でモニタリングとアラート通知機能が搭載されています。

障害対応においては、OSS版ではデータベースノードにアクセスしてログを確認し、クエリを実行する必要があり、専門知識が要求され、調査に時間がかかることがあります。しかし、YugabyteDB Anywhere では Web UI を介してパフォーマンスの確認やライブクエリ、スロークエリのモニタリング、ログのダウンロードが行えるため、対応にかかる手間や時間が大幅に削減されます。

さらに、OSS版では 24/365 のエンタープライズサポートが提供されていないのに対し、YugabyteDB Anywhere ではこのサポートが含まれているため、安心して運用を続けられる点も大きなメリットです。

おわりに

前回の記事（YugabyteDB OSS版の使い方）に続き、今回は有償版製品である YugabyteDB Anywhere の使い方やメリットについて紹介しました。

YugabyteDB Anywhere は、運用・管理の自動化やトラブルシューティングに役立つ機能が追加されており、エンタープライズ向けの 24/365 サポートも提供されています。そのため、本番環境での利用においても安心して運用を続けられることから、YugabyteDB Anywhere の利用を強く推奨いたします。

これらの記事が、YugabyteDB の製品を検討される際にお役に立てれば幸いです。

以前の記事では、YugabyteDB の概要、ユースケースおよび構成パターンについて紹介しました。

今回は、実際に YugabyteDB を使ってみたい方に向けて、OSS 版の使い方として以下について紹介します。

• デプロイ
• 接続方法
• 設定変更
• バックアップ・リストア
• モニタリング

デプロイ環境およびバージョン情報

YugabyteDB はパブリッククラウド や Kubernetes、物理サーバ、仮想環境、プライベートクラウドなどほとんどのプラットフォームに対応しています。

本記事では、同一リージョン内の3つの AZ に配置された EC2 インスタンスに YugabyteDB クラスターをデプロイする方法を紹介します。

クラスタ構成は次の通りです。

EC2 の詳細情報は以下の通りです。

なお、ブラウザから YB-Master と YB-TServer の Web インターフェイスに接続するために、パブリック IP アドレスを有効にしてください。

事前準備

YugabyteDBをインストールする前に、各EC2インスタンスで以下の設定をあらかじめ行ってください。

• chrony（NTPサーバ）のインストール

YugabyteDB がデータの一貫性を保つためには、すべてのノードの時刻が正確に同期されている必要があるため、NTP サーバ chrony をインストールして起動します。

$ sudo yum install -y chrony
$ sudo systemctl start chronyd

• ulimits の設定

Linux で YugabyteDB をデプロイする際に推奨される ulimits の設定については、こちらを参照して適切に設定してください。

• python 3 のインストール

python 3 が必要ですので、python 3 がインストールされているかご確認ください。

$ python --version

一部の環境では python コマンドが python 2 に設定されている場合があります。その場合は、python 3 を指すように設定する必要があります。

$ sudo alternatives --set python /usr/bin/python3

デプロイ

本記事では、replication factor を 3 に設定した 3ノード構成の YugabyteDB クラスターをデプロイします。

インストール

ユーザの作成は任意ですが、本記事では YugabyteDB の起動ユーザとして yugabyte というユーザを作成します。

(すべてのサーバで実行)
# useradd yugabyte
# su - yugabyte

YugabyteDB をダウンロードします。

(すべてのサーバで実行)
$ wget https://downloads.yugabyte.com/releases/2024.1.2.0/yugabyte-2024.1.2.0-b77-linux-x86_64.tar.gz
$ tar xvfz yugabyte-2024.1.2.0-b77-linux-x86_64.tar.gz && cd yugabyte-2024.1.2.0

以下のスクリプトを実行し、YugabyteDB の設定を行います。

(すべてのサーバで実行)
$ ./bin/post_install.sh

YugabyteDB の各種実行ファイルが格納されているディレクトリ yugabyte-2024.1.2.0/bin および yugabyte-2024.1.2.0/postgres/bin を PATH に追加します。

(すべてのサーバで実行)
$ cat >> ~/.bashrc << 'EOF'
export PATH=$PATH:/home/yugabyte/yugabyte-2024.1.2.0/bin:/home/yugabyte/yugabyte-2024.1.2.0/postgres/bin
EOF
$ source ~/.bashrc

デプロイ

YugabyteDB のデータを保存するためのディレクトリを作成します。ディスク障害に対応するために異なるディスク上のディレクトリにデータを保存することができますが、本記事は検証目的なので、1つのディレクトリ /mnt/yugabyte 配下にデータを保存します。

(すべてのサーバで実行)
# mkdir /mnt/yugabyte
# chown yugabyte:yugabyte /mnt/yugabyte

YugabyteDB クラスタは、YB-Master と YB-TServer という 2 つのサービスから構成されています。YugabyteDB のアーキテクチャについてはこちらの記事を参照してください。

YB-Master はクラスタメタデータを管理する役割を担っており、最初に YB-Master を起動し、その後に YB-TServer を起動する必要があります。

YB-Master のデプロイ

まず、ノード1 (172.31.71.100) に YB-Master をデプロイします。
YB-Master は最大 replication factor の数までしか作成されませんので、今回構築するクラスタは replication factor = 3 ですので、3つの YB-Master を作成します。

(ノード1で実行)
$ yb-master \
--master_addresses 172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100 \
--rpc_bind_addresses 172.31.71.100:7100 \
--fs_data_dirs "/mnt/yugabyte" \
--replication_factor=3 \
--placement_cloud aws \
--placement_region us-west-2 \
--placement_zone us-west-2a \
>& /mnt/yugabyte/yb-master.out &

• --master_addresses：すべての YB-Master のIPアドレスをカンマ区切りで指定
• --rpc_bind_addresses：YugabyteDBのノード同士やクライアントとの間でRPC通信を行うためのIPアドレスを指定。ここでは、ノード1のIPアドレスを指定する
• --fs_data_dirs：YugabyteDB のデータを保存するためのディレクトリ。カンマ区切りで複数指定可
• --replication_factor：--replication_factor を 3 に設定する
• --placement_cloud：このYugabyteDBノードがデプロイされているクラウドの名前
• --placement_region：このYugabyteDBノードがデプロイされているリージョン
• --placement_zone：このYugabyteDBノードがデプロイされているアベイラビリティーゾーン (AZ)

何らかの原因で YB-Master が立ち上がらなかった場合は、/mnt/yugabyte/yb-master.out からエラーの内容を確認してください。

次に、ノード2（172.31.72.100）とノード3（172.31.73.100）に YB-Master をデプロイします。--rpc_bind_addresses は、それぞれのノードのIPアドレスに置き換えてください。

(ノード2で実行)
$ yb-master \
--master_addresses 172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100 \
--rpc_bind_addresses 172.31.72.100:7100 \
--fs_data_dirs "/mnt/yugabyte" \
--replication_factor=3 \
--placement_cloud aws \
--placement_region us-west-2 \
--placement_zone us-west-2b \
>& /mnt/yugabyte/yb-master.out &

(ノード3で実行)
$ yb-master \
--master_addresses 172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100 \
--rpc_bind_addresses 172.31.73.100:7100 \
--fs_data_dirs "/mnt/yugabyte" \
--replication_factor=3 \
--placement_cloud aws \
--placement_region us-west-2 \
--placement_zone us-west-2c \
>& /mnt/yugabyte/yb-master.out &

3台の YB-Master が正常に起動すれば、1台が LEADER に選出され、他の2台が FOLLOWER として動作します。

YugabyteDB の管理コマンド yb-adminを用いて、YB-Master サーバの状態を確認します。
次のコマンドの結果から、ノード1が LEADER で、ノード2 と ノード3が FOLLOWER であることがわかります。

$ yb-admin --master_addresses "172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100" list_all_masters
Master UUID RPC Host/Port State Role Broadcast Host/Port 
8709f57eb8e14433b9b2b0e6018d1b63 172.31.71.100:7100 ALIVE LEADER N/A 
f50db74c5461467d8dc96fa88b4b89f4 172.31.72.100:7100 ALIVE FOLLOWER N/A 
632005861c4146aa95dc031e72cdb67f 172.31.73.100:7100 ALIVE FOLLOWER N/A

YB-TServer のデプロイ

次に、YB-TServer をデプロイします。

YB-TServer の数は replication factor と同じか、それ以上である必要があります。本記事では、3つの YB-TServer をデプロイします。

以下のコマンドを実行し、それぞれのノードに YB-TServer をデプロイします。

--rpc_bind_addresses はそれぞれのノードのIPアドレスに置き換えてください。ここでは、PostgreSQL 互換のインターフェイスを有効にするために、--enable_ysql フラグを指定します。

(ノード1で実行)
$ yb-tserver \
--tserver_master_addrs 172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100 \
--rpc_bind_addresses 172.31.71.100:9100 \
--enable_ysql \
--fs_data_dirs "/mnt/yugabyte" \
--placement_cloud aws \
--placement_region us-west-2 \
--placement_zone us-west-2a \
>& /mnt/yugabyte/yb-tserver.out &

(ノード2で実行)
$ yb-tserver \
--tserver_master_addrs 172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100 \
--rpc_bind_addresses 172.31.72.100:9100 \
--enable_ysql \
--fs_data_dirs "/mnt/yugabyte" \
--placement_cloud aws \
--placement_region us-west-2 \
--placement_zone us-west-2b \
>& /mnt/yugabyte/yb-tserver.out &

(ノード3で実行)
$ yb-tserver \
--tserver_master_addrs 172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100 \
--rpc_bind_addresses 172.31.73.100:9100 \
--enable_ysql \
--fs_data_dirs "/mnt/yugabyte" \
--placement_cloud aws \
--placement_region us-west-2 \
--placement_zone us-west-2c \
>& /mnt/yugabyte/yb-tserver.out &

YugabyteDB の管理コマンド yb-admin を用いて、YB-TServer の状態を確認します。

以下のコマンドの結果から、すべての YB-TServer が起動中 (ALIVE) の状態であることが確認できます。

$ yb-admin --master_addresses "172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100" list_all_tablet_servers
Tablet Server UUID RPC Host/Port Heartbeat delay Status Reads/s Writes/s Uptime SST total size SST uncomp size SST #files Memory Broadcast Host/Port 
1b66c3cac2154d7fa8ea6f823dd346f6 172.31.73.100:9100 0.56s ALIVE 0.00 0.00 10 0 B 0 B 0 36.58 MB N/A
16a4004527284f4da35ac5187ca55089 172.31.72.100:9100 0.94s ALIVE 0.00 0.00 35 0 B 0 B 0 32.42 MB N/A
162f28708ff24259a68bc517c25cba3e 172.31.71.100:9100 0.94s ALIVE 0.00 0.00 65 0 B 0 B 0 32.87 MB N/A

これで、YugabyteDBのデプロイが完了しました。

ysqlshによる接続確認

ysqlsh は YSQL（YugabyteDB の PostgreSQL 互換 SQL インターフェース）に接続するためのコマンドです。

アプリケーションからの接続には、既存の PostgreSQL ドライバー（例えば、Javaアプリケーション向けの PostgreSQL JDBC Driver など）を使用するか、または既存の PostgreSQL ドライバーをベースに YugabyteDB 向けに開発された「Smart Driver」を使用します。アプリケーション言語ごとの対応ドライバー情報については、こちらを確認してください。

ここでは、ysqlsh を使用して YugabyteDB に接続してみます。一部の未対応機能を除き、ほとんどの PostgreSQL の構文がそのまま使用できます。

$ ysqlsh -h 172.31.71.100 -U yugabyte
ysqlsh (11.2-YB-2024.1.2.0-b0)
Type "help" for help.

yugabyte=# CREATE DATABASE test;
yugabyte=# \c test
test=# CREATE TABLE t1 (c1 int primary key, c2 text);
CREATE TABLE
test=# \d t1
Table "public.t1"
Column | Type | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
c1 | integer | | not null | 
c2 | text | | | 
Indexes:
"t1_pkey" PRIMARY KEY, lsm (c1 HASH)
test=#
test=# INSERT INTO t1 SELECT n, md5(n::text) FROM generate_series(1,10) AS n;
INSERT 0 10
test=# 
test=# SELECT * FROM t1 order by c1;
c1 | c2 
----+----------------------------------
1 | c4ca4238a0b923820dcc509a6f75849b
2 | c81e728d9d4c2f636f067f89cc14862c
3 | eccbc87e4b5ce2fe28308fd9f2a7baf3
4 | a87ff679a2f3e71d9181a67b7542122c
5 | e4da3b7fbbce2345d7772b0674a318d5
6 | 1679091c5a880faf6fb5e6087eb1b2dc
7 | 8f14e45fceea167a5a36dedd4bea2543
8 | c9f0f895fb98ab9159f51fd0297e236d
9 | 45c48cce2e2d7fbdea1afc51c7c6ad26
10 | d3d9446802a44259755d38e6d163e820
(10 rows)

クラスタの管理

YB-Master と YB-TServer の設定変更

YB-Master と YB-TServer で設定可能なフラグ一覧は以下のドキュメントを参照してください。

• YB-Master：https://docs.yugabyte.com/stable/reference/configuration/all-flags-yb-master/
• YB-TServer：https://docs.yugabyte.com/preview/reference/configuration/all-flags-yb-tserver/

起動時にのみ設定可能なフラグについては、YB-Master や YB-TServer を再起動する必要があります。

一部の YB-TServer のフラグ設定は、yb-ts-cli ... set_flag を使用して、稼働中の YugabyteDB に反映させることができます。

例えば、YugabyteDB には PostgreSQL の log_statement に相当するフラグとして、--ysql_log_statement があります。デフォルト値は none です。ノード1でこのフラグを all に変更するには、以下のコマンドを実行します。

$ yb-ts-cli --server_address="172.31.71.100:9100" set_flag ysql_log_statement all

上記のコマンドを実行すると、YB-TServer の /mnt/yugabyte/yb-data/tserver/logs/postgresql-xx.log ログに以下のようなメッセージが出力されます。

2024-10-04 14:44:59.986 JST [150696] LOG: received SIGHUP, reloading configuration files
2024-10-04 14:44:59.987 JST [150696] LOG: parameter "log_statement" changed to "all"

スケールアウト

YugabyteDB では、必要に応じて YB-TServer の数を自由に増減させることができます。ここでは、YugabyteDB の YB-TServer をスケールアウトする方法を説明します。

新たに追加する4つ目のノードの情報は次の通りです。

4つ目のノードをクラスタに追加します。

(ノード4で実行)
$ yb-tserver \
--tserver_master_addrs 172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100 \
--rpc_bind_addresses 172.31.74.100:9100 \
--enable_ysql \
--fs_data_dirs "/mnt/yugabyte" \
--placement_cloud aws \
--placement_region us-west-2 \
--placement_zone us-west-2d \
>& /mnt/yugabyte/yb-tserver.out &

4つ目の YB-TServer が追加されていることを確認します。

$ yb-admin --master_addresses "172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100" list_all_tablet_servers
Tablet Server UUID RPC Host/Port Heartbeat delay Status Reads/s Writes/s Uptime SST total size SST uncomp size SST #files Memory Broadcast Host/Port 
1b66c3cac2154d7fa8ea6f823dd346f6 172.31.73.100:9100 0.21s ALIVE 0.00 0.00 1118 0 B 0 B 0 46.16 MB N/A
dd21987f812b4a3b81e7c7b324321356 172.31.74.100:9100 0.21s ALIVE 0.00 0.00 36 133.27 KB 133.33 KB 2 37.35 MB N/A
16a4004527284f4da35ac5187ca55089 172.31.72.100:9100 0.21s ALIVE 0.00 0.00 1145 0 B 0 B 0 41.80 MB N/A
162f28708ff24259a68bc517c25cba3e 172.31.71.100:9100 0.22s ALIVE 0.00 0.00 1172 66.65 KB 66.71 KB 1 51.26 MB N/A

バックアップ・リストア

YugabyteDB をバックアップするために、いくつかの方法があります。

ysql_dump や ysql_dumpall を使った論理バックアップ

ysql_dump や ysql_dumpall は PostgreSQL の pg_dump や pg_dumpall と同様にデータベースのバックアップを SQL 形式で取得するコマンドです。

• ysql_dump：特定のデータベースやテーブルをバックアップする際に使用します。
• ysql_dumpall：クラスター全体のバックアップを取得し、ユーザーやロールなどのグローバル設定も含めたい場合に使用します。

例えば、test データベースのバックアップを test-dump.sql に取得するには以下のコマンドを実行します。

$ ysql_dump -h 172.31.71.100 -U yugabyte -d test -f test-dump.sql

バックアップファイルをリストアするには、ysqlsh を使います。

例えば、バックアップファイルを new_test というデータベースにリストアする場合は、以下のコマンドを実行します。

$ ysqlsh -h 172.31.71.100 -U yugabyte -d new_test -f test-dump.sql

分散スナップショット

YugabyteDB をバックアップする最も効率的な方法は、分散スナップショットを作成することです。

YugabyteDB の分散スナップショットは、クラスタ全体にわたってデータベースの特定の時点での状態をキャプチャし、障害やデータの破損時に確実に復元できるバックアップ手法です。スナップショットは YugabyteDB クラスタ内のすべてのノードで同時に取得され、データの一貫性が保証されます。

YugabyteDB がスナップショットを作成する際、データは物理的にコピーされるのではなく、関連するすべてのファイルにハードリンクが作成されます。スナップショットは、データが保存されているのと同じストレージに保存されます。

スナップショットの作成およびリストア手順は次の通りです。

$ yb-admin --master_addresses <YB-Master-ip1:7100,YB-Master-ip2:7100,YB-Master-ip3:7100> create_database_snapshot ysql.<database_name>
$ yb-admin --master_addresses <YB-Master-ip1:7100,YB-Master-ip2:7100,YB-Master-ip3:7100> restore_snapshot <snapshot-UUID>

ここでは test データベースのスナップショットの作成手順と復元手順を説明します。

$ ysqlsh -h 172.31.71.100 -U yugabyte -d test
ysqlsh (11.2-YB-2024.1.2.0-b0)
Type "help" for help.
test=# SELECT * FROM t1 ORDER BY c1;
c1 | c2 
----+----------------------------------
1 | c4ca4238a0b923820dcc509a6f75849b
2 | c81e728d9d4c2f636f067f89cc14862c
3 | eccbc87e4b5ce2fe28308fd9f2a7baf3
4 | a87ff679a2f3e71d9181a67b7542122c
5 | e4da3b7fbbce2345d7772b0674a318d5
6 | 1679091c5a880faf6fb5e6087eb1b2dc
7 | 8f14e45fceea167a5a36dedd4bea2543
8 | c9f0f895fb98ab9159f51fd0297e236d
9 | 45c48cce2e2d7fbdea1afc51c7c6ad26
10 | d3d9446802a44259755d38e6d163e820
(10 rows)

以下のコマンドを実行し、スナップショットを作成します。

$ yb-admin --master_addresses "172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100" create_database_snapshot ysql.test
Started snapshot creation: c638b5ac-9fcc-4f6a-8b89-3975fc560ed1

以下のコマンドを実行すると、作成済みのスナップショットの一覧を表示できます。

$ yb-admin --master_addresses "172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100" list_snapshots
Snapshot UUID State Creation Time
c638b5ac-9fcc-4f6a-8b89-3975fc560ed1 COMPLETE 2024-10-24 13:21:14.113310

test データベースの操作を行います。

$ ysqlsh -h 172.31.71.100 -U yugabyte -d test
ysqlsh (11.2-YB-2024.1.2.0-b0)
Type "help" for help.
test=# INSERT INTO t1 SELECT n, md5(n::text) FROM generate_series(11,20) AS n;
INSERT 0 10
test=# SELECT * FROM t1 ORDER BY c1;
c1 | c2 
----+----------------------------------
1 | c4ca4238a0b923820dcc509a6f75849b
2 | c81e728d9d4c2f636f067f89cc14862c
3 | eccbc87e4b5ce2fe28308fd9f2a7baf3
4 | a87ff679a2f3e71d9181a67b7542122c
5 | e4da3b7fbbce2345d7772b0674a318d5
6 | 1679091c5a880faf6fb5e6087eb1b2dc
7 | 8f14e45fceea167a5a36dedd4bea2543
8 | c9f0f895fb98ab9159f51fd0297e236d
9 | 45c48cce2e2d7fbdea1afc51c7c6ad26
10 | d3d9446802a44259755d38e6d163e820
11 | 6512bd43d9caa6e02c990b0a82652dca
12 | c20ad4d76fe97759aa27a0c99bff6710
13 | c51ce410c124a10e0db5e4b97fc2af39
14 | aab3238922bcc25a6f606eb525ffdc56
15 | 9bf31c7ff062936a96d3c8bd1f8f2ff3
16 | c74d97b01eae257e44aa9d5bade97baf
17 | 70efdf2ec9b086079795c442636b55fb
18 | 6f4922f45568161a8cdf4ad2299f6d23
19 | 1f0e3dad99908345f7439f8ffabdffc4
20 | 98f13708210194c475687be6106a3b84
(20 rows)

データベースをスナップショットを取得した時点の状態にリストアします。

スナップショットの完了には時間がかかる場合があるため、スナップショットを使用する前に、次のコマンドを実行して State が COMPLETE であることを確認してください。

$ yb-admin --master_addresses "172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100" list_snapshots
Snapshot UUID State Creation Time
c638b5ac-9fcc-4f6a-8b89-3975fc560ed1 COMPLETE 2024-10-24 13:21:14.113310

リストアします。

$ yb-admin --master_addresses "172.31.71.100:7100,172.31.72.100:7100,172.31.73.100:7100" restore_snapshot c638b5ac-9fcc-4f6a-8b89-3975fc560ed1
Started restoring snapshot: c638b5ac-9fcc-4f6a-8b89-3975fc560ed1
Restoration id: 13eb17de-55b3-4afc-b19d-59d71cb4f85f

データがスナップショット作成時点の状態にリストアされていることが確認できます。

$ ysqlsh -h 172.31.71.100 -U yugabyte -d test
ysqlsh (11.2-YB-2024.1.2.0-b0)
Type "help" for help.

test=# SELECT * FROM t1 ORDER BY c1;
c1 | c2 
----+----------------------------------
1 | c4ca4238a0b923820dcc509a6f75849b
2 | c81e728d9d4c2f636f067f89cc14862c
3 | eccbc87e4b5ce2fe28308fd9f2a7baf3
4 | a87ff679a2f3e71d9181a67b7542122c
5 | e4da3b7fbbce2345d7772b0674a318d5
6 | 1679091c5a880faf6fb5e6087eb1b2dc
7 | 8f14e45fceea167a5a36dedd4bea2543
8 | c9f0f895fb98ab9159f51fd0297e236d
9 | 45c48cce2e2d7fbdea1afc51c7c6ad26
10 | d3d9446802a44259755d38e6d163e820
(10 rows)

YugabyteDB には定期スナップショット機能も提供されています。

なお、YugabyteDB の PITR（Point-In-Time Recovery）は、定期スナップショットを基にして過去の任意の時点にデータを戻すため、利用するには分散スナップショットが必要です。

例えば、スナップショットを1日に1回 (1,440 分ごと) 生成し、それを3日間 (4,320 分) 保持するスケジュールを作成するには、次のコマンドを実行します。

$ yb-admin --master_addresses "<YB-Master-ip1:7100,YB-Master-ip2:7100,YB-Master-ip3:7100>" create_snapshot_schedule 1440 4320 ysql.<database_name>

分散スナップショットの注意点：

• スナップショットはクラスタ内に保存されるため、ストレージの消費量が増加します。また、ファイルシステムの破損やハードウェア障害からの保護は提供されません。
  このような問題を軽減するため、スナップショットを外部ストレージに保存することも可能です。
  スナップショットを外部ストレージに保存することで、ストレージ使用量の削減やストレージ障害への対応が可能になるほか、別のクラスターにリストアすることもできます。
• スナップショットを使ったリストアでは、データの変更のみが元に戻され、スキーマの変更は元に戻らない点に注意してください。
  たとえば、スナップショットを作成した後にテーブルを削除した場合、スナップショットをリストアしてもそのテーブルはリストアされません。
  この問題を回避するためには、スナップショットを外部ストレージに保存するか、PITR (Point-In-Time Recovery) を使用する方法があります。

モニタリング

YugabyteDB は、クラスタのパフォーマンスや状態をモニタリングするため、さまざまなメトリクスを JSON や Prometheus 形式で出力します。これにより、システムの動作状況を監視し、トラブルシューティングやパフォーマンス最適化が容易になります。YugabyteDB が提供するメトリクスエンドポイントはこちらを参照してください。

さらに、Prometheus と Grafanaと連携してデータを可視化することも可能です。

おわりに

今回は、YugabyteDB OSS版の使い方について紹介しました。

YugabyteDB OSS版は、有償版の YugabyteDB Aeon に比べて運用コストが高く、商用サポートが提供されていないため、本番環境への導入には適しませんが、気軽に始めたいユーザーにとって便利なので、OSS版をお試しになってはいかがでしょうか。

次回は、YugabyteDB の有償版製品である YugabyteDB Aeon Self-Managed の使い方について紹介します。

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 の構成を検討していただく際にお役に立てば幸いです。

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のユースケースや構成について詳しく紹介します。