Cloud Native Storageが拓く Database on Kubernetesの未来 Cloud Native Days Tokyo 2019 [1B3] 2019/7/22 @tzkb

2 PostgreSQL on Kubernetes、色々やってます Cloud Native Developers JP #12 Database on Kubernetesの現在地点 - HA,Replication and more - PGConf.Asia 2019 @Bali Building PostgreSQL as a Service with Kubernetes  ＋ ＝∞

3 アジェンダ 1. Cloud Nativeなデータベースとは？ 2. Cloud Nativeなストレージとは？ 3. Kubernetes上でデータベースを動かす際の課題 4. Database on Kubernetesの実装例  HAパターン  Replicationパターン  Operatorパターン 5. DBプラットフォームとしてのKubernetes

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

5 Cloud Nativeなデータベースの様々な構成 Compute Storage マネージド Amazon Aurora Amazon Redshift Amazon RDS on Cloud on Kubernetes • マネージドサービスからコンテナ/K8sベースまで様々ある。

6 (すごく今更ですが) Kubernetesとは Pod Pod Pod Pod Pod • ステートレスなアプリケーションを動かす際に有用とされる。 特徴として、 • 宣言的設定 • 自己修復 • Immutable DB向きじゃない？

7 Cloud Nativeなデータベースの設計思想 • 例として、Auroraはどのような背景で開発されたのか。 Amazon Auroraは、AWSリソース をフル活用してDBを再開発すると、 どんな形？が前提。 そして、基本的な考えはK8sのそれ にもつながる。 Kubernetesを DBクラスタリングにも 応用できる可能性

8 2. Cloud Nativeなストレージとは？

9 ストレージの基本的な分類  一般的には以下の3つに分類される。 ① ブロックストレージ ② ファイルストレージ（例：NFS、SMB） ③ オブジェクトストレージ（例：S3、Swift）  現在では提供形態として、大まかに2つに分かれる。  物理ストレージ（例：Dell EMC、NetAppなど）  SDS（EBSも利用者から見るとSDSの一例）

10 Compute Control plane Data plane Kubernetes “Ready” と “Native” なストレージ Controler Controler • K8sがストレージのどこまでを管理する/できるかの違いがある。 Kubernetes Ready Kubernetes Native

11 CNCF landscapeにはReady/Nativeが並存 • K8sやコンテナとの接続できるというだけの場合もある。 • 当然、以下になくともK8s対応しているものもある。

12 データベースから利用 ≒ ブロックデバイス 名称 バックエンド ブロック？ OSS/Proprietary Rook Ceph ◎ OSS OpenEBS --- ◎ OSS Redhat OpenShift Container Storage GlusterFS △ Proprietary StorageOS --- ◎ Proprietary • K8s Native＋ブロック＋OSSのRookが目立つ存在となっている。

13 今日話すことは  データベースをKubernetesに載せよう。  ストレージも丸ごとKubernetesに任せよう。  もちろん「動かしてみた」ではなく、 「Production Ready」でないと意味がない。  高可用性・データ冗長性を備えた、 Database on Kubernetes について紹介していく。

14 3. Kubernetes上で データベースを動かす際の課題

15 Kubernetesの本質は分散システム • K8sクラスタはetcdを中心とした分散システムとして構築される。 • つまりノードが未応答の際に、 – ネットワーク分断？ – プロセス(kubelet)障害？ – ノード障害？ どれに該当するか、判断が難しい。 • ディスクリソースがattachされて いれば、その状態も把握する必要 がある。 永続ボリュームを利用する workloadが嫌われる理由はこれ。 FailOver?

16 解はあるのか？DBアーキテクトは知っている。 • 状態がわからないなら、安全側に倒して 処理を継続させたら良いんじゃない？ • 共有リソースをつくらなければ 良いんじゃない？ • それってクラスタリングでは昔から やっていることだよね。

18 DBクラスタリングの基礎知識 HA (Active/Standby) １ Sharding Replication (Active/Active) ２以上 インスタンス数 データ冗長化 2以上 Shared Disk Log Shipping (基本的に) なし × スケールアウト Read Read/ Write Failover (Fencing) 障害時切替 Promotion (Election) --- • 複数ノードでDBを構成するクラスタリングには下記の手法があり、 インスタンス数や切替方法で違いがある。

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

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

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

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

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

24 4. Database on Kubernetesの実装例

25 Database on Kubernetes構成のサマリ # 分類 利用OSS 説明 ⅰ HA構成 • 共有ストレージに Rook/Cephを利用 ⅱ • 共有ストレージに LINSTOR/DRBDを利用 ⅲ Replication • 共有ストレージなし、 Streaming Replication ⅳ Operator • Streaming Replicationを 自動で構築、運用する • K8sを用いたDBクラスタを4例、紹介する。

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

28 （参考）Fencingがない場合 Replicas:1 • ノード障害時にStatefulSetのポッドがフェイルオーバしない。 • NW分断や無応答などを K8sが判断できないため。 << 原因・対処 >> • 仕様通り。 • 以下設定でFOするが、 shutdown abortとなる ので非推奨。 TerminationGracePeriodSeconds=0

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

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

31 Replicationパターン： proxy proxy proxy keeper keeper keeper sentinel sentinel sentinel • PostgreSQLのSRをK8s上に構築、リーダー選出を実装。 • proxy：接続管理 • keeper：DBの実体、 レプリケーションを構成 • sentinel：リーダー選出 • 共有リソースなし ※SR=Streaming Replication << 課題 >> • コンポーネントの多さ • Readの分散不可

32 • Operatorでこうした問題も解決。 • KubernetesのOperatorは、 – Custom Resource Definition(CRD) – Custom Controller で構成される。 • ユーザ定義のCRDに対応して、 Controllerが状態維持を行う。 Database on Kubernetesの更なる課題 • HA(+SDS)やReplicationでDBクラスタリングの部品は揃ったが、 共通の課題が存在する。 コンポーネントが沢山あって、 インストールが大変。 CephやDRBD、PostgreSQLの コマンドを知らないと バックアップ・リストアなど 運用ができない YAMLが多くて 記述・管理がつらい。

33 （参考）Operatorの例： • RookはCeph他のSDSを構築・管理するOperatorである。 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クラスタや CSI対応を容易にする。 • CephクラスタはCRDと して管理される。 • osdやmonの数やモニタ リングの設定も宣言的に 設定が可能。

34 Operatorパターン： • KubeDBはPostgreSQLに限らず、様々なDBを扱えるOperator。 kubedb-operator -0 -1 -2 postgres snapshot dormantdabases • KubeDBでは – PostgreSQL – MySQL – Redis 等のCRDが準備済。 • kubedb-operatorが PostgreSQLのSRを構成。 • SnapshotのCRDもあり、 バックアップ・リストア が可能。 S3等にスナップショット の保存が可能

35 （例）KubeDBでPostgreSQL apiVersion: kubedb.com/v1alpha1 kind: Postgres metadata: name: ha-postgres namespace: demo spec: version: “10.6-v2" replicas: 3 storageType: Durable storage: storageClassName: "standard" accessModes: - ReadWriteOnce resources: requests: storage: 100Gi • バージョン、replica数を指定する だけで、良しなに構築。 • CRDには他にもプロパティがある ので、詳細な指定も可能。  spec.archiver – アーカイブログの格納先を指定可能  spec.init – 初期化元となるscript、snapshotを指定  spec.backupSchedule – バックアップ取得タイミングを指定 • シンプルにReplication構成のデータベースを定義可能。

36 （例）KubeDBでSnapshot apiVersion: kubedb.com/v1alpha1 kind: Snapshot metadata: name: snapshot-to-s3 labels: kubedb.com/kind: Postgres spec: databaseName: ha-postgres storageSecretName: s3-secret s3: endpoint: 's3.amazonaws.com' bucket: kubedb-qa prefix: demo • Snapshotの定義もYAMLで宣言的に管理可能。 • 取得するDB名と格納先の接続情報 を記述したYAML（左）をapply、 簡単にバックアップできる。 • 格納先はS3だけでなく、GCS、 Azure Storageなどのクラウドや Swift、さらにKubernetesのPVも 指定が可能。

37 （参考）PostgreSQL+Rook/Cephでのバックアップ $ kubectl exec -it -n rook-ceph rook-ceph-tools-seq -- rbd -p replicapool ls pvc-bdbc6e53-f6e9-11e8-b0d9-02f062df6b48 $ kubectl exec -it pg-rook-sf-0 -- psql -h localhost -U postgres -c "SELECT pg_start_backup(now()::text);" pg_start_backup ----------------- 0/C000028 (1 row) $ kubectl exec -it -n rook-ceph rook-ceph-tools-seq -- rbd snap create replicapool/img@snap $ kubectl exec -it pg-rook-sf-0 -- psql -h localhost -U postgres -c "SELECT pg_stop_backup();" NOTICE: pg_stop_backup complete, all required WAL segments have been archived pg_stop_backup ---------------- 0/D000050 (1 row) • Postgresのbackup、Cephのrbdコマンド等を使いこなす必要あり。

39 5. DBプラットフォームとしてのKubernetes

40 ここまで見てきたこと  DBクラスタリングをKubernetes Nativeで行うことに ついては、SDSやFencingなど部品が揃いつつある。  Replication構成をK8s化する試みは続いており、 Operatorを利用してDBAタスクを自動化する流れが 生まれてきている。  しかし、それで終わりではない（かも知れない）。 Cloud Native Storage ＋ ＋ ＝ ???

41 手掛かりとなるもの （兆候１）  PostgreSQLのPluggable Storage 対応  MySQLのようにバックエンドストレージを選択可能に。  DBに最適化されたストレージを利用可能となる。 （兆候２）  AWS Aurora、Azure Hyperscaleのようにクラウド・ リソースをフル活用して、RDBMSを再構築する試み。

42 （参考）THE LOG IS THE DATABASE. SQL Transactions Caching Storage Logging Storage Logging Storage Logging CPU Memory Cache(SSD) Page Cache(SSD) Log AWS Aurora(PostgreSQL) Azure Hyperscale • 両者ともRDBMSの機能を分割し、自社クラウドで展開している。

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

Building PostgreSQL as a Service with Kubernetes PGConf.Asia 2019 2019/9/9 @tzkb

45 Questions? @tzkb @tzkoba tzkoba/postgresql-on-k8s

46 Appendix