Pro Yearly is on sale from $80 to $50! »

#CNDT2019 Cloud Native Storageが拓くDatabase on Kubernetesの未来

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
July 19, 2019

#CNDT2019 Cloud Native Storageが拓くDatabase on Kubernetesの未来

2019/7/22 CloudNativeDays Tokyoの発表資料です。
Database on Kubernetesの課題と現在地点、未来予想図について紹介しています。

・PostgreSQL+Rook/Ceph
・PostgreSQL+LINSTOR/DRBD
・Stolon
・KubeDB

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

July 19, 2019
Tweet

Transcript

  1. Cloud Native Storageが拓く Database on Kubernetesの未来 Cloud Native Days Tokyo

    2019 [1B3] 2019/7/22 @tzkb
  2. 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. 3 アジェンダ 1. Cloud Nativeなデータベースとは? 2. Cloud Nativeなストレージとは? 3. Kubernetes上でデータベースを動かす際の課題

    4. Database on Kubernetesの実装例  HAパターン  Replicationパターン  Operatorパターン 5. DBプラットフォームとしてのKubernetes
  4. 4 1. Cloud Nativeなデータベースとは?

  5. 5 Cloud Nativeなデータベースの様々な構成 Compute Storage マネージド Amazon Aurora Amazon Redshift

    Amazon RDS on Cloud on Kubernetes • マネージドサービスからコンテナ/K8sベースまで様々ある。
  6. 6 (すごく今更ですが) Kubernetesとは Pod Pod Pod Pod Pod • ステートレスなアプリケーションを動かす際に有用とされる。

    特徴として、 • 宣言的設定 • 自己修復 • Immutable DB向きじゃない?
  7. 7 Cloud Nativeなデータベースの設計思想 • 例として、Auroraはどのような背景で開発されたのか。 Amazon Auroraは、AWSリソース をフル活用してDBを再開発すると、 どんな形?が前提。 そして、基本的な考えはK8sのそれ

    にもつながる。 Kubernetesを DBクラスタリングにも 応用できる可能性
  8. 8 2. Cloud Nativeなストレージとは?

  9. 9 ストレージの基本的な分類  一般的には以下の3つに分類される。 ① ブロックストレージ ② ファイルストレージ(例:NFS、SMB) ③ オブジェクトストレージ(例:S3、Swift)

     現在では提供形態として、大まかに2つに分かれる。  物理ストレージ(例:Dell EMC、NetAppなど)  SDS(EBSも利用者から見るとSDSの一例)
  10. 10 Compute Control plane Data plane Kubernetes “Ready” と “Native”

    なストレージ Controler Controler • K8sがストレージのどこまでを管理する/できるかの違いがある。 Kubernetes Ready Kubernetes Native
  11. 11 CNCF landscapeにはReady/Nativeが並存 • K8sやコンテナとの接続できるというだけの場合もある。 • 当然、以下になくともK8s対応しているものもある。

  12. 12 データベースから利用 ≒ ブロックデバイス 名称 バックエンド ブロック? OSS/Proprietary Rook Ceph

    ◎ OSS OpenEBS --- ◎ OSS Redhat OpenShift Container Storage GlusterFS △ Proprietary StorageOS --- ◎ Proprietary • K8s Native+ブロック+OSSのRookが目立つ存在となっている。
  13. 13 今日話すことは  データベースをKubernetesに載せよう。  ストレージも丸ごとKubernetesに任せよう。  もちろん「動かしてみた」ではなく、 「Production Ready」でないと意味がない。

     高可用性・データ冗長性を備えた、 Database on Kubernetes について紹介していく。
  14. 14 3. Kubernetes上で データベースを動かす際の課題

  15. 15 Kubernetesの本質は分散システム • K8sクラスタはetcdを中心とした分散システムとして構築される。 • つまりノードが未応答の際に、 – ネットワーク分断? – プロセス(kubelet)障害?

    – ノード障害? どれに該当するか、判断が難しい。 • ディスクリソースがattachされて いれば、その状態も把握する必要 がある。 永続ボリュームを利用する workloadが嫌われる理由はこれ。 FailOver?
  16. 16 解はあるのか?DBアーキテクトは知っている。 • 状態がわからないなら、安全側に倒して 処理を継続させたら良いんじゃない? • 共有リソースをつくらなければ 良いんじゃない? • それってクラスタリングでは昔から

    やっていることだよね。
  17. 18 DBクラスタリングの基礎知識 HA (Active/Standby) 1 Sharding Replication (Active/Active) 2以上 インスタンス数

    データ冗長化 2以上 Shared Disk Log Shipping (基本的に) なし × スケールアウト Read Read/ Write Failover (Fencing) 障害時切替 Promotion (Election) --- • 複数ノードでDBを構成するクラスタリングには下記の手法があり、 インスタンス数や切替方法で違いがある。
  18. 19 クラスタパターン① HA • 障害検知/切替はLinux-HA等で • 生死監視の専用NW(二重化) • データは共有ストレージで冗長化 <<避けるべき最悪ケース>>

    • 複数インスタンスでストレージに 書き込みをしてしまうこと <<対策>> • Fencing:強制的なリソース解放 VIP Linux-HA Controller Controller • UNIX以前から使われる古典的クラスタリングだが、今なお有用。
  19. 20 Fencingとは VIP Linux-HA Controller Controller << 状態不明なマスターが発生したら>> ① 強制的にノードの電源落とす

    i. プロセスを確実に停止 ii. ストレージのマウントを外す iii. VIPを外す ② その上で別ノードでリソースを 獲得して、マスターを起動 ※強制電源断はHWベンダ提供の管理ポートや クラウドAPIを通して行われる。 • 障害ノードをフェンスで囲うこと(隔離) =Fencing
  20. 21 クラスタパターン② Replication WAL • マスタはRead/Write、 スレーブはReadのみを処理 • 障害検知/切替は別ツールが必要 •

    データはWAL転送で冗長化 <<避けるべき最悪ケース>> • 複数マスタが選出されること <<対策>> • リーダー選出:常に1台のマスタ • DBMSに組み込まれた冗長化機能で、データを相互同期する構成。 マスタ スレーブ スレーブ
  21. 22 リーダー選出とは WAL データは最新、 リーダーに選出。 他はスレーブ。 • 複数候補から常に1台のマスタ を選出 •

    元マスタが復帰後もスレーブに なっていることを通知する <<状態不明なマスタが発生したら>> ① 残ったスレーブから1台の リーダーを選出する ② 選出されたらマスターへ昇格 ③ 復帰ノードはスレーブになる • アルゴリズムとしてはPaxos、Raftなどが有名。 マスタ スレーブ
  22. 23 クラスタパターン③ Sharding • ノード間でデータを分割して保持、 一つのDBのように見せる。 • コーディネータが処理を振り分け、 負荷を分散する。 •

    データ冗長化は基本的に含まない。 合わせて実装することもある。 • トランザクション実装が難しい。 ※当資料でShardingの細かな解説はしない。 • 可用性よりも拡張性を高める際に使われる構成。 コーディネータ
  23. 24 4. Database on Kubernetesの実装例

  24. 25 Database on Kubernetes構成のサマリ # 分類 利用OSS 説明 ⅰ HA構成

    • 共有ストレージに Rook/Cephを利用 ⅱ • 共有ストレージに LINSTOR/DRBDを利用 ⅲ Replication • 共有ストレージなし、 Streaming Replication ⅳ Operator • Streaming Replicationを 自動で構築、運用する • K8sを用いたDBクラスタを4例、紹介する。
  25. 27 HA構成パターン(i): Replicas:1 • PostgreSQLはStatefulSet、PVとしてRook/Cephを用いる。 • DBもストレージも全て K8sで管理するHA構成 • 共有ディスクはCeph

    • kube-fencingでNode 障害時のFencing << 課題 >> • 複雑すぎるCeph • ネットワーク越しのIO による性能劣化 kube-fencing
  26. 28 (参考)Fencingがない場合 Replicas:1 • ノード障害時にStatefulSetのポッドがフェイルオーバしない。 • NW分断や無応答などを K8sが判断できないため。 << 原因・対処

    >> • 仕様通り。 • 以下設定でFOするが、 shutdown abortとなる ので非推奨。 TerminationGracePeriodSeconds=0
  27. 29 HA構成パターン(ii): Replicas:1 kube-fencing • LINSTORがProvisioning/AttachするDRBDボリュームを用いる。 • DBもストレージも全て K8sで管理するHA構成 •

    DRBDでデータ冗長化 • シンプル • ReadはローカルIO、 性能面でCephに優る << 課題 >> • スケール上限あり
  28. 30 (参考)SDS別のベンチマーク結果 シングル構成(EBS) Rook/Ceph DRBD 1インスタンス 5インスタンス 2インスタンス 100 37.8

    77.1 • pgbenchによる簡易ベンチマークでは以下のような差が出た。 TPS
  29. 31 Replicationパターン: proxy proxy proxy keeper keeper keeper sentinel sentinel

    sentinel • PostgreSQLのSRをK8s上に構築、リーダー選出を実装。 • proxy:接続管理 • keeper:DBの実体、 レプリケーションを構成 • sentinel:リーダー選出 • 共有リソースなし ※SR=Streaming Replication << 課題 >> • コンポーネントの多さ • Readの分散不可
  30. 32 • Operatorでこうした問題も解決。 • KubernetesのOperatorは、 – Custom Resource Definition(CRD) –

    Custom Controller で構成される。 • ユーザ定義のCRDに対応して、 Controllerが状態維持を行う。 Database on Kubernetesの更なる課題 • HA(+SDS)やReplicationでDBクラスタリングの部品は揃ったが、 共通の課題が存在する。 コンポーネントが沢山あって、 インストールが大変。 CephやDRBD、PostgreSQLの コマンドを知らないと バックアップ・リストアなど 運用ができない YAMLが多くて 記述・管理がつらい。
  31. 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の数やモニタ リングの設定も宣言的に 設定が可能。
  32. 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等にスナップショット の保存が可能
  33. 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構成のデータベースを定義可能。
  34. 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も 指定が可能。
  35. 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コマンド等を使いこなす必要あり。
  36. 39 5. DBプラットフォームとしてのKubernetes

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

     しかし、それで終わりではない(かも知れない)。 Cloud Native Storage + + = ???
  38. 41 手掛かりとなるもの (兆候1)  PostgreSQLのPluggable Storage 対応  MySQLのようにバックエンドストレージを選択可能に。 

    DBに最適化されたストレージを利用可能となる。 (兆候2)  AWS Aurora、Azure Hyperscaleのようにクラウド・ リソースをフル活用して、RDBMSを再構築する試み。
  39. 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の機能を分割し、自社クラウドで展開している。
  40. 43 DB/Storage プラットフォームとしてのKubernetes DBaaS by Kubernetes STaaS by Kubernetes <<DBaaSの基本要素>>

    • HA • Replication • DB Operator <<STaaSの基本要素>> • シンプルな冗長化 • 分散ストレージ • 互換性の高いIF(CSI) • “Platform for Platforms”として、K8sが各Serviceを支える。
  41. Building PostgreSQL as a Service with Kubernetes PGConf.Asia 2019 2019/9/9

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

  43. 46 Appendix