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

KubernetesでつくるPostgreSQL as a Service

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
November 14, 2019

KubernetesでつくるPostgreSQL as a Service

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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

November 14, 2019
Tweet

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の大きな課題は2つ ストレージ 分散システム • データはどうやって永続化? • 高可用性は必要。

    • コンテナなので、データの 可搬性も重要。 • 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) 1 Sharding Replication (Active/Active) 2以上 インスタンス数

    データ冗長化 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