7/1向けcndjpの発表資料です。 Database on Kubernetesの現在状況を整理した資料になっています。

1. Database on Kubernetesの現在地点
- HA,Replication and more -
2019/7/1
@tzkb
@tzkoba

2. ちょっと質問①
• あなたは(どちらかといえば)○○勢？
1. Kubernetes 勢
2. データベース勢
3. その他

3. ちょっと質問②
• 普段お使いのデータベースは？
1. Oracle Database
2. MySQL
3. PostgreSQL
4. その他

4. 自己紹介
• 名 前 ：Takahiro Kobayashi
• 勤務先 ：SIer
• 出没場所 ：Oracle、PostgreSQL、k8s関連に色々と
• キャリア ：DB、ストレージを中心にインフラ
• 好きなもの：速いDB 、太い帯域、小さいレイテンシ

5. DB on Kubernetes、色々やってます。
•CloudNativeDays Tokyo 2019で、
Cloud Native Storageが開く
Database on Kubernetesの未来
というタイトルで登壇予定。
• と を近付けたい！

6. 今日話すこと
• Cloud Nativeなデータベース？？
• Database on Kubernetesのモチベーション
• DBクラスタを扱う際の基礎知識
• DB on K8sのリファレンス・アーキテクチャ
• 今後のDatabase on Kubernetes

7. Cloud Nativeなデータベース？
Compute
Storage
Managed
Amazon Aurora
Amazon Redshift
Amazon RDS
on Cloud on Kubernetes
本日のTOPIC

8. Kubernetes is 何？
Node
Pod
Node
Pod
Node
Pod
Pod Pod
• コンテナ・オーケストレーションのプラットフォーム。
yaml 特徴として、
• 宣言的設定
• 自己修復
• Immutable
あれ？
DB向きじゃない？

9. Database on Kubernetesのモチベーション
• Auroraはすごい！
– 3つのAZ、6本のディスクに冗長化
– 再起動でもキャッシュ消えない！
– No checkpoint (!?)
– Vacuumも賢くなってる
– 詳しくはDeep Diveを参照
• でも、設計思想はこんな感じ。
• あれ？k8sで出来そうじゃない？

10. DBの高可用性/スケーラブルな構成とは
HA
(master/cold-standby)
１
Sharding
(multi-master)
Replication
(master/hot-standby)
２以上
インスタンス数 データ冗長化
2以上
Shared
Disk
Log
Shipping
(基本的に)
なし
×
スケールアウト
Read
Read/
Write
Failover
(Fencing)
障害時切替
Promotion
(Election)
---

11. DBクラスタの基礎知識① HA
<< 特徴 >>
• 障害検知/切替はLinux-HA
• 生死監視の専用NW(二重化)
• データは共有ストレージで冗長化
<<避けるべき最悪ケース>>
• 複数インスタンスでストレージに
書き込みをしてしまうこと
<<対策>>
• Fencing：強制的なリソース解放
VIP
Linux-HA
Controller Controller
【PostgreSQL on Linux-HA】

12. Fencingとは
• リソースをフェンスで囲うこと
＝Fencing
<< 状態不明なマスターが発生したら>>
① 強制的にノードの電源落とす
i. プロセスを確実に停止
ii. ストレージのマウントを外す
iii. VIPを外す
② その上で別ノードでリソースを
獲得して、Masterを起動
VIP
Linux-HA
Controller Controller
【PostgreSQL on Linux-HA】

13. DBクラスタの基礎知識② Replication
<< 特徴 >>
• マスターはRead/Write、
スレーブはReadのみを処理
• 障害検知/切替は別ツールが必要
• データはWAL転送で冗長化
<<避けるべき最悪ケース>>
• 複数マスタが選出されること
<<対策>>
• リーダー選出：常に1台のみ
WAL
【PostgreSQL Streaming Replication】

14. リーダー選出とは
• 複数候補から常に1台のマスター
を選出
• 元マスターが復帰後もスレーブに
なっていることを通知する
<<状態不明なマスターが発生したら>>
① 残ったスレーブから1台の
リーダーを選出
② 選出されたらマスターへ昇格
③ 復帰ノードはスレーブに
【PostgreSQL Streaming Replication】
WAL
データは最新。
リーダーに！
他はスレーブ。

15. Database is Hard!!

16. DB on K8s構成のサマリ
（１）HA構成 Rookパターン
– 共有ディスク：Rook/Ceph【分散ストレージ】
（２）HA構成
– 共有ディスク：LINSTOR/DRBD【ディスク冗長化】
（３）Replication構成：
– リーダー選出：Kubernetes(etcd)を利用

17. DB on K8sの構成(1) HA - Rook -
<< 特徴 >>
• DBもストレージも全て
K8sで管理するHA
• 共有ディスクはCeph
• kube-fencingでNode
障害時のFencing
<< 課題 >>
• 複雑すぎるCeph
• ネットワーク越しのIO
Replicas:1
kube-fencing

18. （参考）Fencingがないと
Replicas:1
• ノード障害時に
StatefulSetのポッドが
フェイルオーバしない。
<< 原因 >>
• 仕様です。
• 以下設定でFOするが、
shutdown abortとなる
ので非推奨。
TerminationGracePeriodSeconds=0

19. DB on K8sの構成(２) HA - DRBD -
<< 特徴 >>
• DBもストレージも全て
K8sで管理するHA
• 共有ディスクはDRBD
• シンプルな構成
• ReadはローカルIO、
Writeは他ノードに伝播
<< 課題 >>
• やや煩雑なデプロイ
Replicas:1
kube-fencing

20. DB on K8sの構成(3) Replication
<< 特徴 >>
• proxy：接続管理
• keeper：レプリケー
ションを構成
• sentinel：リーダー選出
• 共有リソースなし
<< 課題 >>
• コンポーネントの多さ
• Readの分散不可
proxy proxy proxy
keeper keeper keeper
sentinel sentinel sentinel

21. ここまでで分かったこと
• 分散システムであるK8sでも、注意点はあるものの
DBクラスタを動かす部品が揃ってきている。
• でも、各種OSSを組み合わせたり、運用に必要な機能
(スナップショットやクローンなど)は弱い？
⇒Operatorで補完できるよ！
• あれ？Shardingはどうなった？？
⇒Citusとかあるよ！MySQLなら だよ。

22. 今後のDatabase on Kubernetes
• ReplicationやShardingなど、DBMSの機能やオプション
をK8sで動かす形の進化は今後も続く。
• Operatorによって、DBAが行ってきた作業の自動化も
進んでいく。
• しかし、それで終わりではない。
• Aurora/Hyperscaleに見られるような、DBMSの機能を
各レイヤにオフロードする、進歩的なDBクラスタが
構築できるはず。その一端を担うのはCSIかもしれない。

23. Azure HyperscaleAWS Aurora(PostgreSQL)
RDBMSの機能を分割した例
SQL
Transactions
Caching
Storage
Logging
Storage
Logging
Storage
Logging
CPU
Memory
Cache(SSD)
Page
Cache(SSD) Log
• DB on K8sの最終目的地はここかもしれない。