Kubernetesが拓くDatabaseとStorageの未来

by tzkoba

Slide 1

Slide 1 text

Takahiro, Kobayashi ( @tzkb) Kubernetesが拓く DatabaseとStorageの未来 AI Storage Tokyo Meetup#4 , 11/14

Slide 2

Slide 2 text

2 最近やっていること • Cloud Native Days Tokyo 2019 “Cloud Native Storageが拓く Database on Kubernetesの未来” • PostgreSQL Conference Japan 2019 “Kubernetesでつくる PostgreSQL as a Service” ＋＝∞

Slide 3

Slide 3 text

3 1. Cloud Nativeなデータベースとは 2. Database with Kubernetesの課題 3. Kubernetesストレージの現在地点 4. STasS with Kubernetesがもたらすものアジェンダ

Slide 4

Slide 4 text

4 Cloud Nativeなデータベースとは 1

Slide 5

Slide 5 text

5 Cloud Nativeって何でしょう？ https://speakerdeck.com/jacopen/fei-biip-mou-cloud-nativefalseshi-jie?slide=16

Slide 6

Slide 6 text

6 Cloud Nativeなデータベースの構成例 Compute Storage Managed Amazon Aurora Amazon Redshift Amazon RDS VM-based on Kubernetes • マネージドの形からVM、コンテナベースまで選択肢は多様。

Slide 7

Slide 7 text

7 (今更ですが) コンテナ／Kubernetesとは Pod Pod Pod Pod Pod • ステートレスなアプリケーションを動かす際に有用とされる。特徴として、 • 宣言的設定 • 自己修復 • Immutable DB向きじゃない？ ※KubernetesのPod＝1つ以上のコンテナをまとめて管理する概念

Slide 8

Slide 8 text

8 Database with Kubernetesの課題 2

Slide 9

Slide 9 text

9 データをどのように永続化するか？ Master Slave Replicate • データベースでは高可用性、データ永続化はできて当たり前。 • Immutableなので、通常は Podを再起動したらデータは消失。 • 自己修復機能があるが、データ損失とは別の問題。（≠DBリカバリ） • Podは同質、Replicationのように、それぞれ役割が異なる DBクラスタをどう表現するか。

Slide 10

Slide 10 text

10 データ冗長化とDBクラスタリング共有ディスク (Active/Standby) １ Sharding Replication (Active/Active) ２以上インスタンス数データ冗長化 2以上 Shared Disk Log Shipping (基本的に) なし × スケールアウト Read Read/ Write Failover (Fencing) 障害時切替 Promotion (Election) --- • 複数ノードでDBを構成するクラスタリングでは、データをどのレイヤで冗長化するなどに違いが見られる。

Slide 11

Slide 11 text

11 クラスタパターン① 共有ディスク型HA • 障害検知/切替はLinux-HA等で • 生死監視の専用NW(二重化) • データは共有ストレージで冗長化 <<避けるべき最悪ケース>> • 複数インスタンスでストレージに書き込みをしてしまうこと <<対策>> • Fencing：強制的なリソース解放 VIP Linux-HA Controller Controller • UNIX以前から使われる古典的クラスタリングだが、今なお有用。

Slide 12

Slide 12 text

12 Fencingとは VIP Linux-HA Controller Controller << 状態不明なマスターが発生したら>> ① 強制的にノードの電源落とす i. プロセスを確実に停止 ii. ストレージのマウントを外す iii. VIPを外す ② その上で別ノードでリソースを獲得して、マスターを起動 ※強制電源断はHWベンダ提供の管理ポートやクラウドAPIを通して行われる。 • 障害ノードをフェンスで囲うこと(隔離) ＝Fencing

Slide 13

Slide 13 text

13 クラスタパターン② Replication WAL • マスタはRead/Write、スレーブはReadのみを処理 • 障害検知/切替は別ツールが必要 • データはWAL転送で冗長化 <<避けるべき最悪ケース>> • 複数マスタが選出されること <<対策>> • リーダー選出：常に1台のマスタ • DBMSに組み込まれた冗長化機能で、データを相互同期する構成。マスタスレーブスレーブ

Slide 14

Slide 14 text

14 リーダー選出とは WAL データは最新、リーダーに選出。他はスレーブ。 • 複数候補から常に1台のマスタを選出 • 元マスタが復帰後もスレーブになっていることを通知する <<状態不明なマスタが発生したら>> ① 残ったスレーブから1台のリーダーを選出する ② 選出されたらマスターへ昇格 ③ 復帰ノードはスレーブになる • アルゴリズムとしてはPaxos、Raftなどが有名。マスタスレーブ

Slide 15

Slide 15 text

15 クラスタパターン③ Sharding • ノード間でデータを分割して保持、一つのDBのように見せる。 • コーディネータが処理を振り分け、負荷を分散する。 • データ冗長化は基本的に含まない。合わせて実装することもある。 • トランザクション実装が難しい。 ※当資料でShardingの細かな解説はしない。 • 可用性よりも拡張性を高める際に使われる構成。コーディネータ

Slide 16

Slide 16 text

16 Kubernetesストレージの現在地点 3

Slide 17

Slide 17 text

17 Kubernetesが持つ永続化の仕組み PV PV PVC PVC • K8sはステートフルなワークロードでも対応が進んでいる。 • StatefulSet（sts） – 一意に特定可能なネットワークアドレス、順次処理できるdeployなどを提供。 • Persistent Volume – PV/PVC/StorageClassを用いて、データを永続化する。 – データの可搬性を高めるには、図のようにクラウド・ストレージを使うのが最も簡単。

Slide 18

Slide 18 text

18 オンプレミスでは Volume Plugin Orchestration Storage Management • 各ベンダがK8s対応のストレージ・ソフトウェアを提供。 • 下記のように自社ストレージへコンテナ対応のIFを持つ製品が増えてきている。 – NetApp Trident – Pure Storage PSO • クラウド・ストレージのAZ問題を解決するのに使えるサービスも展開が進む。 – NetApp Cloud Volume ONTAP – HPE Cloud Volumes

Slide 19

Slide 19 text

19 Compute Control plane Data plane さらにその先へ Controler Controler • Kubernetes自身がSDSのプラットフォームとなる可能性も。 Kubernetes Ready Kubernetes Native

Slide 20

Slide 20 text

20 Cloud Nativeなストレージも選択肢が拡がっている • K8sやコンテナとの接続できるというだけの場合もある。 • 当然、以下になくともK8s対応しているものもある。

Slide 21

Slide 21 text

21 データベースでの利用 ≒ ブロックデバイス名称バックエンドブロック？ OSS/Proprietary ◎ OSS ◎ OSS Redhat OpenShift Container Storage ◎ Proprietary StorageOS --- ◎ Proprietary • CNCF incubatingのRookが目立つが、OpenShiftも成長中。

Slide 22

Slide 22 text

22 （参考） • RookはCeph他のSDSを構築・管理するオーケストレータ。 operator agent/discover agent/discover agent/discover osd osd osd mon mon mon CSI csi-provisioner csi-rbdplugin csi-rbdplugin csi-rbdplugin Rook • RookはCephクラスタや他の SDS、DBをKubernetesへ展開する。 • 複雑なCephの構築・運用を、 Kubernetesの機能で自動化する仕組みを目指している。

Slide 23

Slide 23 text

23 DB＋K8sストレージ： with Replicas:1 • PostgreSQLはStatefulSet、PVとしてRook/Cephを用いる。 • DBもストレージも全て K8sで管理するHA構成 • 共有ディスクはCeph • kube-fencingでNode 障害時のFencing << 課題 >> • 複雑すぎるCeph • ネットワーク越しのIOによる性能劣化 kube-fencing

Slide 24

Slide 24 text

24 DB+K8sストレージ： with Replicas:1 kube-fencing • LINSTORがProvisioning/AttachするDRBDボリュームを用いる。 • DBもストレージも全て K8sで管理するHA構成 • DRBDでデータ冗長化 • シンプル • ReadはローカルIO、性能面でCephに優る << 課題 >> • K8s対応が進んでいない • スケール上限あり

Slide 25

Slide 25 text

25 （参考）SDS別のベンチマーク結果シングル構成(EBS) Rook/Ceph DRBD 1インスタンス 5インスタンス 2インスタンス 100 37.8 77.1 • pgbenchによる簡易ベンチマークでは以下のような差が出た。 TPS

Slide 26

Slide 26 text

26 STaaS with Kubernetesがもたらすもの 4

Slide 27

Slide 27 text

27 ここまで見てきたこと  Cloud Nativeな形態の一つとして、データベースを Kubenetesで動かす流れは加速している。  現在はReplicationによる高可用設計が主流だが、SDSの Kubernetes対応により、ストレージレイヤでデータを冗長化される構成も可能となっている。  CSI(Container Storage Interface)もGA、更に進化。 Cloud Native Storage ＋＋＝ ???

Slide 28

Slide 28 text

28 DB/Storage プラットフォームとしてのKubernetes DBaaS by Kubernetes STaaS by Kubernetes <> • HA • Replication • DB Operator <> • シンプルな冗長化 • 分散ストレージ • 互換性の高いIF(CSI) • “Platform for Platforms”として、K8sが各Serviceを支える。