KubernetesでつくるPostgreSQL as a Service

11/15に開催される PostgreSQL Conference Japan 2019の発表資料です。

Transcript

1. Kubernetesでつくる PostgreSQL as a Service PostgreSQL Conference Japan 2019 , 11/15 Takahiro, Kobayashi ( @tzkb)
2. 2 最近やっていること • Cloud Native Days Tokyo 2019 “Cloud Native Storageが拓く Database on Kubernetesの未来” • PGConf.Asia 2019 “Building PostgreSQL as a Service with Kubernetes” ＋ ＝∞
3. 3 1. PostgreSQL as s Serviceの目指すところ 2. Database on Kubernetesの課題 3. 銀の弾丸を探す 4. PostgreSQL on Kubernetesの実装例 5. DBプラットフォームとしてのKubernetes アジェンダ
4. 4 PostgreSQL as a Serviceの目指す所 1
5. 5 今日のゴール  あなたはDBプラットフォーマーです。  社内や顧客に提供する PostgreSQL as a Serviceを 構築する必要があります。  パブリッククラウドを使いますか？  オンプレミスでやりますか？  VMにしますか？コンテナにしますか？  Kubernetes の力を借りてみましょう。
6. 6 PostgreSQL as a Serviceの構成パターン Compute Storage Managed Amazon Aurora Amazon Redshift Amazon RDS VM-based on Kubernetes • DBaaSの形からVMベース、コンテナベースまで選択肢は多様。
7. 7 Cloud Nativeなデータベースの設計思想 • 例として、Auroraはどのような背景で開発されたのかを考える。 Kubernetesを DBクラスタリングにも 応用できる可能性 Amazon Auroraは、AWSリソースを フル活用してDBを再開発すると、どんな 形になるか？が考え抜かれている。 そして、基本的な考えはK8sのそれ にもつながる。
8. 8 Database on Kubernetesの課題 2
9. 9 Database on Kubernetesの大きな課題は２つ ストレージ 分散システム • データはどうやって永続化？ • 高可用性は必要。 • コンテナなので、データの 可搬性も重要。 • SDSか？既存HWが使える？ • ノード、コンテナの生死を どう扱うか？ • 共有リソースをどう扱うか？ • 可搬性と相反する一貫性、 どのように保証するか？
10. 10 （今更ですが）コンテナとは Node Linux Kernel Container Runtime(Docker) Container Container Files Process Files Process • 一言でいえば、隔離されたプロセスと最小限のファイルシステム。 • OS部分(カーネル)は共有。 • VMに比べてサイズが小さく、 効率的にリソースを管理で きる。 • ノードを超えて、配置を管 理することが基本的に出来 ない。
11. 11 （今更ですが） Kubernetesとは Pod Pod Pod Pod Pod • ステートレスなアプリケーションを動かす際に有用とされる。 特徴として、 • 宣言的設定 • オートヒーリング • Immutable DB向きじゃない？ ※KubernetesのPod＝1つ以上のコンテナを まとめて管理する概念
12. 12 データをどのように永続化するか？ Master Slave Replicate • ステートフルなDBではデータは永続化できて当たり前。 • Immutableなので、通常は Podを再起動したらデータは 消失。 • 自己修復機能があるが、 データ損失とは別の問題。 （≠DBリカバリ） • Podは同質、Replicationのよ うに、異なる役割を持つDB クラスタをどう表現するか。
13. 13 Kubernetesの本質は分散システム • K8sクラスタはetcdを中心とした分散システムとして構築される。 • つまりノードが未応答の際に、 – ネットワーク分断？ – プロセス(kubelet)障害？ – ノード障害？ どれに該当するか、判断が難しい。 • ディスクリソースがattachされていれ ば、その状態も把握する必要がある。 永続ボリュームを利用する workloadが嫌われる理由はこれ。 フェイルオーバ？
14. 14 銀の弾丸を探す ～ストレージと分散システムに撃ち込むために～ 3
15. 15 Kubernetesが持つ永続化の仕組み PV PV PVC PVC • K8sはステートフルなワークロードでも対応が進んでいる。 • StatefulSet（sts） – 一意に特定可能なネットワークアド レス、順次処理できるdeployなどを 提供。 • Persistent Volume – PV/PVC/StorageClassを用いて、 データを永続化する。 – データの可搬性を高めるには、図の ようにクラウド・ストレージを使う のが最も簡単。
16. 16 オンプレミスでは Volume Plugin Orchestration Storage Management • 各ベンダがK8s対応のストレージ・ソフトウェアを提供。 • 下記のように自社ストレージへ コンテナ対応のIFを持つ製品が 増えてきている。 – NetApp Trident – Pure Storage PSO • クラウド・ストレージのAZ問題を 解決するのに使えるサービスも展開 が進む。 – NetApp Cloud Volume ONTAP – HPE Cloud Volumes
17. 17 Compute Control plane Data plane さらにその先へ Controler Controler • Kubernetes自身がSDSのプラットフォームとなる可能性も。 Kubernetes Ready Kubernetes Native
18. 18 Cloud Nativeなストレージも選択肢が拡がっている • K8sやコンテナとの接続できるというだけの場合もある。 • 当然、以下になくともK8s対応しているものもある。
19. 19 （参考） • 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の機能で自動化 する仕組みを目指している。
20. 20 （再掲）Kubernetesの本質は分散システム • K8sクラスタはetcdを中心とした分散システムとして構築される。 • つまりノードが未応答の際に、 – ネットワーク分断？ – プロセス(kubelet)障害？ – ノード障害？ どれに該当するか、判断が難しい。 • ディスクリソースがattachされていれ ば、その状態も把握する必要がある。 永続ボリュームを利用する workloadが嫌われる理由はこれ。 フェイルオーバ？
21. 21 DBクラスタリングの基礎知識 共有ディスク (Active/Standby) １ Sharding Replication (Active/Active) ２以上 インスタンス数 データ冗長化 2以上 Shared Disk Log Shipping (基本的に) なし × スケールアウト Read Read/ Write Failover (Fencing) 障害時切替 Promotion (Election) --- • 複数ノードでDBを構成するクラスタリングには下記の手法があり、 インスタンス数や切替方法で違いがある。
22. 22 クラスタパターン① 共有ディスク型HA • 障害検知/切替はLinux-HA等で • 生死監視の専用NW(二重化) • データは共有ストレージで冗長化 <<避けるべき最悪ケース>> • 複数インスタンスでストレージに 書き込みをしてしまうこと <<対策>> • Fencing：強制的なリソース解放 VIP Linux-HA Controller Controller • UNIX以前から使われる古典的クラスタリングだが、今なお有用。
23. 23 Fencingとは VIP Linux-HA Controller Controller << 状態不明なマスターが発生したら>> ① 強制的にノードの電源落とす i. プロセスを確実に停止 ii. ストレージのマウントを外す iii. VIPを外す ② その上で別ノードでリソースを獲得し て、マスターを起動 ※強制電源断はHWベンダ提供の管理ポートや クラウドAPIを通して行われる。 • 障害ノードをフェンスで囲うこと(隔離) ＝Fencing
24. 24 クラスタパターン② Replication WAL • マスタはRead/Write、 スレーブはReadのみを処理 • 障害検知/切替は別ツールが必要 • データはWAL転送で冗長化 <<避けるべき最悪ケース>> • 複数マスタが選出されること <<対策>> • リーダー選出：常に1台のマスタ • DBMSに組み込まれた冗長化機能で、データを相互同期する構成。 マスタ スレーブ スレーブ
25. 25 リーダー選出とは WAL データは最新、 リーダーに選出。 他はスレーブ。 • 複数候補から常に1台のマスタ を選出 • 元マスタが復帰後もスレーブに なっていることを通知する <<状態不明なマスタが発生したら>> ① 残ったスレーブから1台の リーダーを選出する ② 選出されたらマスターへ昇格 ③ 復帰ノードはスレーブになる • アルゴリズムとしてはPaxos、Raftなどが有名。 マスタ スレーブ
26. 26 クラスタパターン③ Sharding • ノード間でデータを分割して保持、 一つのDBのように見せる。 • コーディネータが処理を振り分け、 負荷を分散する。 • データ冗長化は基本的に含まない。 合わせて実装することもある。 • トランザクション実装が難しい。 • 可用性よりも拡張性を高める際に使われる構成。 コーディネータ
27. 27 PostgreSQL on Kubernetesの実装例 4
28. 28 Database on Kubernetes構成のサマリ # 分類 利用OSS 説明 ⅰ 共有ディスク • 共有ストレージとして Rook/Cephを利用 ⅱ • 共有ストレージとして LINSTOR/DRBDを利用 ⅲ Replication • Streaming Replicationを 自動で構築、運用する • K8sを用いたDBクラスタを三つ、紹介する。 • ストレージの課題には、Kubernetes-NativeなSDSで対応。 • 分散システムの課題には、共有ディスクとReplicationで対応。
29. 29 共有ディスクパターン(i)： Replicas:1 • PostgreSQLはStatefulSet、PVとしてRook/Cephを用いる。 • DBもストレージも全て K8sで管理するHA構成 • 共有ディスクはCeph • kube-fencingでNode 障害時のFencing << 課題 >> • 複雑すぎるCeph • ネットワーク越しのIOに よる性能劣化 kube-fencing
30. 30 （参考）Fencingがない場合 Replicas:1 • ノード障害時にStatefulSetのポッドがフェイルオーバしない。 • NW分断や無応答などをK8s が判断できないため。 << 原因・対処 >> • 仕様通り。 • 以下設定でFOするが、 shutdown abortとなるので 非推奨。 TerminationGracePeriodSeconds=0
31. 31 共有ディスクパターン(ii)： Replicas:1 kube-fencing • LINSTORがProvisioning/AttachするDRBDボリュームを用いる。 • DBもストレージも全て K8sで管理するHA構成 • DRBDでデータ冗長化 • シンプル • ReadはローカルIO、 性能面でCephに優る << 課題 >> • K8s対応が進んでいない • スケール上限あり
32. 32 （参考）SDS別のベンチマーク結果 シングル構成(EBS) Rook/Ceph DRBD 1インスタンス 5インスタンス 2インスタンス 100 37.8 77.1 • pgbenchによる簡易ベンチマークでは以下のような差が出た。 TPS
33. 33 Replicationパターン： • KubeDBはPostgreSQLに限らず、様々なDBを扱えるOperator。 kubedb-operator -0 -1 -2 postgres snapshot dormantdabases • KubeDBでは – PostgreSQL – MySQL – Redis 等の管理を自動化。 • kubedb-operatorが PostgreSQLのSRを構成。 • SnapshotのCRDもあり、 バックアップ・リストアが 可能。 S3等にスナップショット の保存が可能
34. 34 （例）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構成のデータベースを定義可能。
35. 35 （例）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も指定が可能。
36. 36 DBプラットフォームとしてのKubernetes 5
37. 37 （再掲）今日のゴール  あなたはDBプラットフォーマーです。  社内や顧客に提供する PostgreSQL as a Serviceを 構築する必要があります。  パブリッククラウドを使いますか？  オンプレミスでやりますか？  VMにしますか？コンテナにしますか？  Kubernetes の力を借りてみましょう。 実現するイメージは沸きましたか？
38. 38 PGConf.Asia 2019：Zalandoの例 • Replicationでの on K8s、コミュニティでも共有されている。 しかもProductionで。
39. 39 今後、コミュニティがKubernetesで取り組むべき課題 プラガブル・ストレージ Sharding • 分散ストレージとNativeに 組み合わせることが可能 • Replicationと別のアプローチ • OpenなAuroraを目指すという 方向性 • 多数のインスタンス管理は Kubernetesの得意ワザ • Hyperscale(Citus)をOpenに • MySQLではVitessがCNCFで Graduatedとなっている • 私個人の意見です。
40. 40 MySQLでのSharding with Kubernetes：Vitess VTtablet VTtablet VTtablet VTgate app app app SQL SQL SQL • KubernetesでのDB利用は、MySQLの方が活発。 • Youtubeで利用されている 実績がある。 • CNCFでもIncubatingから Graduatedになり、成熟化 したと認められている。 • 何十億ユーザの大規模データ ベースを実用レベルで動かす なら、ここまで必要？
41. 41 （参考）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の機能を分割し、自社クラウドで展開している。
42. 42 DB/Storage プラットフォームとしてのKubernetes aaS by Kubernetes STaaS by Kubernetes << aaSの基本要素>> • 共有ディスク型HA • Replication • プラガブル・ストレージ <<STaaSの基本要素>> • 分散ストレージ • Kubernetes-Native • 互換性の高いIF(CSI) • “Platform for Platforms”として、K8sが各Serviceを支える。
43. 43 Questions? @tzkb @tzkoba