YugabyteDBを選択すべき10の理由
2024年3月5日
SRA OSS LLC
彭 博 (ペン ボ)© 2024 SRA OSS LLC

1

自己紹介ペン ボ• 名前： 彭 博 (Bo Peng)
pengbo@sraoss.co.jp• 所属：SRA OSS LLC
技術部 基盤技術グループ• 職務：• OSS技術サポート、ミドルウェア構築• クラスタリングソフトウェア：Pacemaker/Corosync• 監視ソフトウェア：Zabbix• Kubernetes• YugabyteDB• など• OSS活動© 2024 SRA OSS LLC

2

SRA OSSはパートナーとしてYugabyteDB関連サービスを提供• 2023年3月、Yugabyte社とパートナーシップを締結し、クラウドネイティブ分散データベースYugabyteDBの取り扱いを始めました。
• YugabyteDBのアセスメント・PoC、導入、サポートまでトータルに支援します。

アセスメント導入支援新規••••ヒアリング・情報収集機能・性能実現性の調査
レポート作成・報告
DB導入費用見積• データベース構成の設計• データベースの構築• データベースの動作確認テスト

移行•••••

ヒアリング・情報収集
移行可否および移行難易度の評価
DB設計変更が必要となる項目を洗い出す
レポート作成・報告
DB移行費用見積•••••

データベース構成の設計
テーブル定義の移行
データの移行
バックアップなど運用手順の移行
データベースの移行確認テスト© 2024 SRA OSS LLC

サポート• 24/365サポート• 24/365サポート

3

概要
YugabyteDBを選択すべき10の理由
1. 高可用性
2. 耐障害性
3. スケールアウトによる大量データ処理の負荷分散
4. 自動シャーディング
5. 地理的パーティショニング
6. PostgreSQL互換、ACIDトランザクション対応
7. PostgreSQL MVCCの欠点をYugabyteDBで解決
8. PostgreSQLの肥大化問題の回避
9. 運用・管理コストの削減
10. ゼロ計画外・計画ダウンタイム© 2024 SRA OSS LLC4YugabyteDBを選択すべき理由 1
高可用性© 2024 SRA OSS LLC

5

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

障害時
APP

APP

VIP

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

相互監視

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

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

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

昇格

プライマリ

レプリカ

ストリーミングレプリケーション

プライマリ© 2024 SRA OSS LLC

6

YugabyteDBの高可用性• 高可用性機能がビルトインされている• ユーザにノード障害を意識させることなく運用続行可能• 障害時、3秒以内に新しいリーダーが選出される• 更新・参照処理は透過的にリトライされる• 障害時データ損失なし© 2024 SRA OSS LLC

APP

ノード障害が発生しても、残りのノードでサービスを継続

7

障害時の挙動Leaderタブレット障害時の挙動• 3秒以内に新しいリーダーを選出• 更新・参照処理は透過的に新しいリーダーに継続

followerfollower

leaderfollower

leaderfollower

leaderfollower

3秒以内に、followerからleaderに昇格

followerfollower
leaderfollowerfollowerfollower

leaderleaderleaderfollowerfollowerfollowerfollowerfollowerfollowerfollowerfollowerfollower

leaderfollowerfollowerfollowerfollower

leaderfollowerfollowerfollowerfollowerfollower

leaderfollowerfollowerfollowerfollower

leadernode #1

node #2

node #3

node #4

node #5

node #1

node #2

node #3

node #4

node #5(RF=3の場合)
3つのtabletを維持するために、別のノードにtabletを複製© 2024 SRA OSS LLC

8

YugabyteDBを選択すべき理由 2
耐障害性• あらゆる規模の障害や災害に対してダウンタイムなしで回復できる© 2024 SRA OSS LLC

9

PostgreSQLにおける災害対策
バックアップによる災害対策• 定期的にバックアップを取得し、遠隔地へ転送
バックアップ転送

バックアップ
災害発生時にバックアップからリカバリ• 運用が容易• バックアップを取得した時点までしか復旧できないため、データの損失は多い© 2024 SRA OSS LLC

10

PostgreSQLにおける災害対策
レプリケーションによる災害対策
非同期レプリケーションによるサイト間データ同期

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

メインサイト

DRサイト

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

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

プライマリ

レプリカ

レプリカ

プライマリ

レプリカ

レプリカ

カスケードレプリケーション

非同期レプリケーション• データ損失の可能性あり• 運用がやや複雑• サイト障害時、手動でサイト切り替えが必要© 2024 SRA OSS LLC

11

YugabyteDBの耐障害性様々なデプロイメントパターン
AZレベルからクラウドサービスレベルまでの耐障害性

zone aregion azone czone bregion b

region c

マルチAZ

マルチリージョン

マルチクラウド

AZレベルの耐障害性

リージョンレベルの耐障害性

クラウドレベルの耐障害性© 2024 SRA OSS LLC

12

YugabyteDBにおける災害対策
マルチリージョン構成

xCluster構成

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

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

Region A
更新 参照

参照

メインサイト(Region A)
Zone A

DRサイト(Region B)
Zone A

非同期
レプリケーション

Region B

Region C

Zone B© 2024 SRA OSS LLC

Zone C

Zone B

Zone C

13

YugabyteDBを選択すべき理由 3
スケールアウトによる大量データ処理の負荷分散© 2024 SRA OSS LLC

14

PostgreSQLのスケールアウト
PostgreSQLの機能のみでスケールアウトするにはpostgres_fdwによるシャーディング

ストリーミングレプリケーション•

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

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

APP

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

APP

参照

更新 参照

外部テーブル

プライマリ

レプリカ

レプリカ
外部テーブルレプリケーション• 更新処理はスケールアウトできない• 大規模データになると、処理性能が落ちてしまう• 大規模データの書き込み処理性能が求められるア
プリケーションには適していない© 2024 SRA OSS LLC

更新・参照
FDW
更新・参照
FDW

分散トランザクションが未対応
15

YugabyteDBのスケールアウト• 分散アーキテクチャを採用している• クエリレイヤ：クエリを受け付けて処理する• ストレージレイヤ：データを処理・保管する• 必要に応じてスケールアウト/スケールイン可能• 参照・更新ともにスケールアウト可能• 分散トランザクション対応

自由に拡張可能

更新・参照

どのノードでも更新・参照可能

APP

分散アーキテクチャ

クエリレイヤクエリレイヤクエリレイヤストレージレイヤ

ストレージレイヤ

どのノードのストレージレイヤにも接続できるストレージレイヤ

follower

leaderレプリケーション

follower

レプリケーション

leaderfollowerfollowerfollowerfollower

leader

Node #1

Node #2

Node #3© 2024 SRA OSS LLC

tabletpeer

16

YugabyteDBのスケールアウト
ノードの追加ノードを追加すると、Tabletのリバランスは自動で行われる

leaderfollowerfollower

leaderfollowerfollower

leaderfollowerfollower

leaderleaderfollowerfollowerfollowerfollower

leader

Node #1

Node #2

Node #3

followerfollowerfollowerfollower

leaderfollowerfollower

leaderfollower

Node #1

Node #2

Node #3

Node #4

Node #4を追加© 2024 SRA OSS LLC

17

YugabyteDBを選択すべき理由 4
自動シャーディング• RDBにおけるシャーディングの構築・管理の複雑さを軽減© 2024 SRA OSS LLC

18

YugabyteDBにおけるシャーディング• YugabyteDBにおけるシャーディング（Tabletの分割）• テーブルのプライマリキーで自動的に行われる• テーブルを作成すると、デフォルトではノードごとに1つのTabletが作成される(Tabletの数を指定してテーブルを作成することも可能)• Tabletのシャーディング方法はHashまたはRange• ホットスポットを防ぐためにHashシャーディングを使う
Hashシャーディングの場合

デフォルトでは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を指定© 2024 SRA OSS LLC

19

YugabyteDBを選択すべき理由 5
地理的パーティショニング© 2024 SRA OSS LLC

20

地理的パーティショニング
地理的パーティショニングとは• パーティショニングとtablespace機能を利用• 特定のパーティションテーブルを特定の地域に紐づけて、行単位でデータの地理的な配置場所を制御

ユースケース• グローバルに広がった複数の拠点にまたがってYugabyteDBをデプロイし、利用ユーザの近いところにデータを配置することで、よりレイテンシーを抑える• 個人情報などの機密情報を特定の地域のデータセンターに保管することで、データの地理的な配置場所を制御できる© 2024 SRA OSS LLC

21

地理的パーティショニング
Step 1: tablespace作成
CREATE TABLESPACE us_west_2_tablespace WITH (replica_placement='{"num_replicas": 3, "placement_blocks": [{"cloud":"aws","region":"us-west-2","zone":"us-west-2a","min_num_replicas":1},{"cloud":"aws","region":"us-west-2","zone":"us-west-2b","min_num_replicas":1},{"cloud":"aws","region":"us-west-2","zone":"us-west-2c","min_num_replicas":1}]}');

id

Region

1US2

India

3

France4US

5

France…

Step 2: 親テーブル作成
CREATE TABLE users (idINTEGER NOT NULL,...
region VARCHAR,) PARTITION BY LIST (region);

id

RegionidRegion

1US3

France4

US5France

Step 3: パーティションテーブル作成

idRegion

2IndiaCREATE TABLE users_us PARTITION OF users (id, ..., region,
PRIMARY KEY (id HASH))
FOR VALUES IN ('US') TABLESPACE us_west_2_tablespace;© 2024 SRA OSS LLC

22

YugabyteDBを選択すべき理由 6
PostgreSQL互換、ACIDトランザクション対応© 2024 SRA OSS LLC

23

PostgreSQL互換、ACIDトランザクション対応• PostgreSQLと高い互換性を持っている• SQLを使って複雑な集計や検索が可能• ACIDトランザクションをサポートしており、強力なデータ一貫性を担保できる

YSQL API© 2024 SRA OSS LLC

YCQL API24

YugabyteDBを選択すべき理由 7
PostgreSQL MVCCの欠点をYugabyteDBで解決© 2024 SRA OSS LLC

25

PostgreSQL MVCCの仕組み• PostgreSQLは多版型同時実行制御(MVCC)をサポートしている• MVCCとは、複数のトランザクションを同時に実行する際にデータの一貫性を保証する仕組み(トランザクションA開始)
BEGIN;
SELECT * FROM test;
c1----1(1 row)
UPDATE test SET c1 = 2 WHERE c1 = 1;
(トランザクションB開始)
BEGIN;
SELECT * FROM test;
c1----1(1 row)

トランザクションAがコミットする前に、データの変更が見えない

SELECT * FROM test;
c1----2(1 row)

トランザクションAがコミットした後に、データの変更が見える(トランザクションAコミット)
COMMIT;(トランザクションBコミット)
COMMIT;© 2024 SRA OSS LLC

26

トランザクションID (XID) とは
PostgreSQLでは、同時実行制御にトランザクションIDを利用している• すべてのトランザクションにXIDと呼ばれるトランザクションIDが割り当てられる• XIDは単調増加する32bitの非負整数値• 各タプルのヘッダにxmin、xmaxと呼ばれるXIDが格納されている• xmin：タプルを挿入するトランザクションID• xmax：タプルを削除するトランザクションID© 2024 SRA OSS LLC

27

PostgreSQLのMVCCの課題
XID周回問題• 利用できるXIDは約42億（2^32-1）のみ• XIDが最大値に達し、周回すると、存在するはずのデータが見えなくなってしまう• 防止するために、VACUUMが必要© 2024 SRA OSS LLC

28

YugabyteDBにおけるMVCC
YugabyteDBにおけるMVCC• XIDを利用していない• ハイブリッドロジカルクロック（HLC）を利用している• HLCは物理クロックと論理クロックを組み合わせたもの• 使い切ることはない(physical component, logical component)
NTPを使用して同期された 因果関係を示すLamport
クロック
物理クロック© 2024 SRA OSS LLC

29

YugabyteDBを選択すべき理由 8
PostgreSQLの肥大化問題の回避• VACUUM不要• 自動コンパクション© 2024 SRA OSS LLC

30

PostgreSQLにおける更新／削除の仕組み• PostgreSQLは追記型アーキテクチャを採用している• UPDATE、DELETEで発生した不要領域が発生する
UPDATE
id

name

id

• 不要領域が増えると、どうなるのか？

DELETE
name

id

name

1 sato1 sato1 sato2 suzuki

2 suzuki

2 suzuki

3 takahashi

3 takahashi

3 takahashi

1 tanaka

1 tanaka• UPDATEでは、更新前のデータに削除フラグをつけて、更新後のデータを新たに登録• DELETEでは、削除対象のデータに削除フラグをつける削除フラグのついた領域＝不要領域© 2024 SRA OSS LLC• ファイルサイズが大きくなり、ディスク使用量が増える• メモリにキャッシュされにくくなり、ディスクアクセ スが増え、性能が下がる
ディスク使用量4倍
不要領域
80%
不要領域
20%

1GBのデータを格納するのに、不要領域の割合が20%だと1.25GB必要なのに対して、80%だと５GB必要になる

不要領域が増えないように定期的なVACUUMの実行が必要
31

VACUUMとは
VACUUMはVACUUMとVACUUM FULLの2種類
VACUUM

VACUUM FULL

• 不要領域を空き領域マップ(FSM)に登録して、再利用可能にする処理• 不要領域を削除する処理• ファイルサイズは基本的に小さくならない• SELECTとも並行して実行できない• INSERT、UPDATE、DELETEと並行して実行できる
VACUUMid

name1 sato2 suzuki

idname• ファイルサイズが小さくなる• 対象テーブルと同程度の空き容量が必要• インデックスも再構築される

ページごとに空き領域の大きさを記録

id

1 sato空き領域

3 takahashi

3 takahashi

1 tanaka

1 tanaka

name

VACUUM
name
FULL id
3 takahashi

2 suzuki
空き領域マップ

3 takahashi
1 tanaka

1 tanaka

削除

自動VACUUMが適切に実行されるように、ワークロードの特徴に合わせて自動VACUUMの設定を調整することが重要© 2024 SRA OSS LLC

32

YugabyteDB自動コンパクション• コンパクションとは• DocDBに書き込まれた複数のSSTファイルを1つのファイルにまとめる• 不要となったデータをディスクから削除し、ストレージの使用容量を削減• データはまずメモリに書き込まれる• メモリ上のデータが定期的にディスクにフラッシュされ、新しいSSTファイルに書き込まれる• コンパクションにより複数のSSTファ
イルが１つのファイルに集約• 読み取りパフォーマンスの向上• ディスク容量の最適化 © 2024 SRA OSS LLC

33

YugabyteDBを選択すべき理由 9
運用・管理コストの削減© 2024 SRA OSS LLC

34

運用・管理コストの削減
ほとんどの運用管理タスクは管理コンソールで操作できるアップグレード
無停止バージョンアップ

スケーリング
無停止ノード追加/削除
インスタンスタイプ変更

トラブルシューティング

Day2運用が容易に

実行中クエリの可視化
スロークエリの検出

バックアップ・リストア

モニタリング

自動バックアップオンデマンドバックアップ
リストア
PITR

メトリクス収集・可視化
障害やリソース負荷超過時にアラート
通知メール送信
リソース使用の効率化
インデックスやスキーマの改善© 2024 SRA OSS LLC

35

YugabyteDBを選択すべき理由 10
ゼロ計画外・計画ダウンタイム© 2024 SRA OSS LLC

36

ゼロ計画外・計画ダウンタイム• ユーザにノード障害を意識させることなく運用続行可能• ダウンタイムなしで• スケールアウト/スケールイン• バージョンアップなどのメンテナンス

24h© 2024 SRA OSS LLC

37

まとめ• YugabyteDBは「一貫性」、「スケーラビリティ」、「高可用性」を兼ね備えたクラウドネイティブなデータベース• YugabyteDBを使うことで、従来のRDBの以下の課題を解決できる• スケールアウトが困難• ダウンタイム• 障害時のデータ損失• XID問題、データの肥大化などのMVCCの課題• 運用・管理の複雑さ• など© 2024 SRA OSS LLC

38

ご清聴ありがとうございました。

製品・サービスに関するお問い合わせ:sales@sraoss.co.jp© 2024 SRA OSS LLC

03-5979-2701
39