YugabyteDB OSS版の使い方

分散データベース YugabyteDB は、運用・管理の自動化機能やエンタープライズ向けのサポートが追加された有償版「YugabyteDB Aeon」以外にも、自動化機能やサポートがない代わりに、無償で利用できるオープンソースソフトウェア (OSS) 版も提供されています。

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

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

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

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

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

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

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

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

ノード#1 ノード#2 ノード#3
リージョン us-west-2 us-west-2 us-west-2
AZ us-west-2a us-west-2b us-west-2c
IPアドレス 172.31.71.100 172.31.72.100 172.31.73.100
インスタンスタイプ m6i.2xlarge
OS Red Hat Enterprise Linux 9
(サポートされているOSはこちらを参照してください。)
YugabyteDBバージョン 2024.1
(投稿時点の最新STSバージョン)

なお、ブラウザから 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 や 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
リージョン us-west-2
AZ us-west-2d
IPアドレス 172.31.74.100

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_dumpysql_dumpall は PostgreSQL の pg_dumppg_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 の使い方について紹介します。