PostgreSQLユーザに向けた
YugabyteDBのご紹介
DSS Asia 2023
2023/03/28

SRA OSS LLC
彭 博 (ペン ボ)© 2023 – All Rights Reserved

1

自己紹介
○○○○

名前： 彭 博 (Bo Peng)
pengbo@sraoss.co.jp
所属：SRA OSS LLC
基盤技術グループ
職務：◼ OSS技術サポート、ミドルウェア構築⚫
クラスタリングソフトウェア: Pacemaker/Corosync⚫
監視ソフトウェア: Zabbix⚫
Kubernetes⚫など◼ PostgreSQLクラスタ管理ツールPgpool-II開発者© 2023 – All Rights Reserved2

概要○○YugabyteDBの特長◼

スケーラビリティ◼

高可用性・耐障害性

PostgreSQLから移行の考慮事項© 2023 – All Rights Reserved

3

YugabyteDBの特長
YugabyteDBとはRDBの一貫性とNoSQLの拡張性を兼ね備えた、クラウドネイティブな分散SQLデータベース

PostgresSQL、Cassandra互換

水平方向のスケーラビリティ• データの増加に応じた柔軟なスケーラビリティ• 膨大な書き込み処理に対応できる

ACIDトランザクションに対応• データの一貫性を担保

分散アーキテクチャ• 高可用性、耐障害性

さまざまな稼働環境をサポート• オンプレミス• クラウド• Kubernetes

地理分散• 耐障害性、災害対策© 2023 – All Rights Reserved4スケーラビリティ© 2023 – All Rights Reserved

5PostgreSQLのスケールアウト
PostgreSQLの機能のみでスケールアウトするにはストリーミングレプリケーション

postgres_fdwによるシャーディング•

1台のプライマリと複数台のレプリカからなるストリーミング
レプリケーション構成•••

レプリカを増やすことで、参照処理をスケールアウトできる•

データを複数台のPostgreSQLに分割配置
postgres_fdwを利用してSQLの実行負荷を分散させることで、スケールアウトを実現
参照・更新ともにスケールアウト可能APP

APP
参照

更新 参照

更新・参照
外部テーブル
プライマリ

レプリカ

レプリカ

外部テーブルレプリケーション

更新処理はスケールアウトできない

FDW
更新・参照
FDW

分散トランザクションが未対応© 2023 – All Rights Reserved

6

YugabyteDBのスケールアウト
分散アーキテクチャを採用している
必要に応じてスケールアウト/スケールイン可能参照・更新ともにスケールアウト可能
分散トランザクション対応

APP

更新・参照

○○○○

© 2023 – All Rights Reserved

7

YugabyteDBのアーキテクチャ○

YB-MasterとYB-TServerから構成される◼

◼

YB-Master⚫
クラスタメタデータと構成管理⚫
Raftによる冗長化
YB-TServer⚫
クライアントクエリの処理⚫
データの保持クラスタ管理YB-Master(leader)

YB-Master(follower)

YB-Master(follower)

SQL

YB-TServer

YB-TServer

YB-TServer

YB-TServer

Node #1

Node #2

Node #3

Node #4

YB-TServerを増減することで、拡張性を実現© 2023 – All Rights Reserved8

YB-TServerの内部構造
クエリレイヤどのノードでも更新・参照可能

••
•
•

APP

PostgreSQLのクエリレイヤを再利用
リクエストを受け付ける
ステートレスどのノードのストレージレイヤにも接続できるストレージレイヤ
クエリレイヤクエリレイヤクエリレイヤDocDB
ストレージレイヤ

DocDB
ストレージレイヤ

DocDB
ストレージレイヤ••••

Tabletと呼ばれるシャーディング単位で分割
各tablet peerは1つのleaderと複数のfollowerから構成される
tablet単位でレプリケーション
同一tablet peerの中でRaft合意形成が行われる

follower
Node #1

Node #2

Node #3

レプリケーション

leaderレプリケーション

follower

leaderfollowerfollowerfollowerfollower

leader

Node #1

Node #2

Node #3© 2023 – All Rights Reserved

Tabletpeer9高可用性・耐障害性© 2023 – All Rights Reserved

10PostgreSQLで高可用性を実現するには○○PostgreSQLでは高可用性機能が提供されていない
クラスタリングソフトウェアを用いて高可用性を実現するのが一般的

障害時

正常時

APP

APP

VIP

VIP
クラスタリング
ソフトウェア系統切り替えにはダウンタイムが生じる

相互監視

クラスタリング
ソフトウェア

クラスタリング
ソフトウェア

クラスタリング
ソフトウェア

昇格

プライマリ

レプリカ

プライマリ

ストリーミングレプリケーション© 2023 – All Rights Reserved

11

YugabyteDBの高可用性
高可用性機能がビルトインされている○ ユーザにノードダウンを意識させることなく運用続行可能○••○

障害時、3秒以内に新しいリーダーが選出される
更新・参照処理は透過的に新しいリーダーに継続

データ損失なし

follower

leaderfollowerfollowerfollower

leaderfollowerからleaderに昇格

Node #1

Node #2

Node #3

Node #1

Node #2

Node #3© 2023 – All Rights Reserved

12PostgreSQLのDR構成例
非同期レプリケーションによるサイト間データ同期
DRサイト

メインサイトカスケードレプリケーションによる
サイト間データ同期
DRサイト

メインサイト

クラスタリング
ソフトウェア

クラスタリング
ソフトウェア同期
レプリケーション同期
レプリケーション

プライマリ

レプリカ
非同期レプリケーション

レプリカ

プライマリ

レプリカ

レプリカ

カスケードレプリケーション• データ損失あり• 運用がやや複雑• サイト障害時、手動でサイト切り替えが必要© 2023 – All Rights Reserved

13

YugabyteDBのDR構成例
マルチリージョン構成

xCluster構成

複数のリージョンに跨ってクラスタを構築

クラスタ間双方向非同期レプリケーション

Region A

Region B

メインサイト(Region A)

DRサイト(Region B)

Zone A

Zone A

双方向非同期レプリケーション

Region C
Zone C

Zone B利点••

データ損失なし
手動切り替え不要

参照

更新 参照

欠点
•高レイテンシー

Zone B利点•低レイテンシー

Zone C

欠点••

データ損失あり運用がやや複雑© 2023 – All Rights Reserved

14

PostgreSQLから移行の考慮事項© 2023 – All Rights Reserved

15シャーディング方法
ホットスポットを回避するようにスキーマを設計することが重要
ホットスポットとは？
書き込みが 1 つのシャード (tablet) に集中してしまう現象
ホットスポット

Leaderuser_id

name

201…

202…

203…

…

…

プライマリキーが単調増加/減少の場合、新しいデータが同一tabletに追加され、同一tabletに書き込みが集中してしまう© 2023 – All Rights Reserved

16シャーディング方法○Tabletの分割••

プライマリキーで自動的に行われる
予めTablet数を指定することも可能

Tabletの分割方法はHashまたはRange○ ホットスポットを防ぐためにHashシャーディングを使う○Hashシャーディングの場合

デフォルトではHash分割となる。
明示的に指定する場合は、
PRIMARY KEY (user_id HASH)CREATE TABLE user_table (user_id int, name VARCHAR NOT NULL, PRIMARY KEY (user_id));

Rangeシャーディングの場合
CREATE TABLE user_table (user_id int, name VARCHAR NOT NULL, PRIMARY KEY (user_id ASC));
Rangeシャーディングの場合は、ASC/DESCを指定© 2023 – All Rights Reserved

17

SERIAL型の注意点○○

YugabyteDBでSERIAL型を使う場合、新しいIDを取得するために、余分なオーバヘッドが発生する
頻繁にSERIAL型のデータをINSERTすると、パフォーマンスが低下しやすくなる
解決策①
シーケンスのキャッシュサイズを大きくする (デフォルト1)
ALTER SEQUENCE <シーケンス名> CACHE 1000;

解決策②
SERIAL型の代わりにUUID型を使う
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE TABLE user_table (user_id UUID DEFAULT gen_random_uuid(),name VARCHAR NOT NULL,PRIMARY KEY (user_id));© 2023 – All Rights Reserved18アプリケーションでの配慮事項○

リトライ処理の追加•••○

デフォルトのトランザクション分離レベルが異なる
コンフリクトによってトランザクションがアボートされた時に(エラーコード 40001:serialization_failure)、リトライするように修正
Read CommittedはBeta版としてリリースされている (2023/3時点)

パフォーマンス向上のため、プリペアドステートメントの使用が推奨されている© 2023 – All Rights Reserved

19非互換機能について
YugabyteDBはPostgreSQL互換だが、非互換機能もある。

非互換機能に関してはドキュメントをご参照ください。
https://docs.yugabyte.com/preview/explore/ysql-language-features/postgresqlcompatibility/© 2023 – All Rights Reserved20データの移行方法①

移行ツールYugabyteDB Voyagerを使う••

移行手順の簡素化
スキーマ分析レポートによる修正方法の提案
インポート

エクスポートMySQLMariaDB
PostgreSQL
Oracle②

SchemaData
Indexes/Triggers

SchemaData

スキーマ分析 -> 修正
YB-Voyager

pg_dump/ysql_dumpを使う© 2023 – All Rights Reserved

21

SRA OSSはパートナーとしてYugabyteDB関連サービスを提供
SRA OSSはパートナーとして、YugabyteDBのアセスメント・PoC支援、導入支援、サポートまでをトータルでサポートします。

• アセスメント・PoC支援• 導入支援• サポート支援

YugabyteDBに関するご相談は、sales@sraoss.co.jpまでお問い合わせください。

© 2023 – All Rights Reserved22Thank You© 2023 – All Rights Reserved

23