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)
   

   View Slide

2. 2
   最近やっていること
   • Cloud Native Days Tokyo 2019
   “Cloud Native Storageが拓く
   Database on Kubernetesの未来”
   • PGConf.Asia 2019
   “Building PostgreSQL as a Service
   with Kubernetes”
   ＋ ＝∞
   

   View Slide

3. 3
   1. PostgreSQL as s Serviceの目指すところ
   2. Database on Kubernetesの課題
   3. 銀の弾丸を探す
   4. PostgreSQL on Kubernetesの実装例
   5. DBプラットフォームとしてのKubernetes
   アジェンダ
   

   View Slide

4. 4
   PostgreSQL as a Serviceの目指す所
   1
   

   View Slide

5. 5
   今日のゴール
    あなたはDBプラットフォーマーです。
    社内や顧客に提供する PostgreSQL as a Serviceを
   構築する必要があります。
    パブリッククラウドを使いますか？
    オンプレミスでやりますか？
    VMにしますか？コンテナにしますか？
    Kubernetes の力を借りてみましょう。
   

   View Slide

6. 6
   PostgreSQL as a Serviceの構成パターン
   Compute
   Storage
   Managed
   Amazon Aurora
   Amazon Redshift
   Amazon RDS
   VM-based on Kubernetes
   • DBaaSの形からVMベース、コンテナベースまで選択肢は多様。
   

   View Slide

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

   View Slide

8. 8
   Database on Kubernetesの課題
   2
   

   View Slide

9. 9
   Database on Kubernetesの大きな課題は２つ
   ストレージ 分散システム
   • データはどうやって永続化？
   • 高可用性は必要。
   • コンテナなので、データの
   可搬性も重要。
   • SDSか？既存HWが使える？
   • ノード、コンテナの生死を
   どう扱うか？
   • 共有リソースをどう扱うか？
   • 可搬性と相反する一貫性、
   どのように保証するか？
   

   View Slide

10. 10
    （今更ですが）コンテナとは
    Node
    Linux Kernel
    Container Runtime(Docker)
    Container Container
    Files
    Process
    Files
    Process
    • 一言でいえば、隔離されたプロセスと最小限のファイルシステム。
    • OS部分(カーネル)は共有。
    • VMに比べてサイズが小さく、
    効率的にリソースを管理で
    きる。
    • ノードを超えて、配置を管
    理することが基本的に出来
    ない。
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. 14
    銀の弾丸を探す
    ～ストレージと分散システムに撃ち込むために～
    3
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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の機能で自動化
    する仕組みを目指している。
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. 27
    PostgreSQL on Kubernetesの実装例
    4
    

    View Slide

28. 28
    Database on Kubernetes構成のサマリ
    # 分類 利用OSS 説明
    ⅰ
    共有ディスク
    • 共有ストレージとして
    Rook/Cephを利用
    ⅱ • 共有ストレージとして
    LINSTOR/DRBDを利用
    ⅲ Replication • Streaming Replicationを
    自動で構築、運用する
    • K8sを用いたDBクラスタを三つ、紹介する。
    • ストレージの課題には、Kubernetes-NativeなSDSで対応。
    • 分散システムの課題には、共有ディスクとReplicationで対応。
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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等にスナップショット
    の保存が可能
    

    View Slide

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構成のデータベースを定義可能。
    

    View Slide

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も指定が可能。
    

    View Slide

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

    View Slide

37. 37
    （再掲）今日のゴール
     あなたはDBプラットフォーマーです。
     社内や顧客に提供する PostgreSQL as a Serviceを
    構築する必要があります。
     パブリッククラウドを使いますか？
     オンプレミスでやりますか？
     VMにしますか？コンテナにしますか？
     Kubernetes の力を借りてみましょう。
    実現するイメージは沸きましたか？
    

    View Slide

38. 38
    PGConf.Asia 2019：Zalandoの例
    • Replicationでの on K8s、コミュニティでも共有されている。
    しかもProductionで。
    

    View Slide

39. 39
    今後、コミュニティがKubernetesで取り組むべき課題
    プラガブル・ストレージ
    Sharding
    • 分散ストレージとNativeに
    組み合わせることが可能
    • Replicationと別のアプローチ
    • OpenなAuroraを目指すという
    方向性
    • 多数のインスタンス管理は
    Kubernetesの得意ワザ
    • Hyperscale(Citus)をOpenに
    • MySQLではVitessがCNCFで
    Graduatedとなっている
    • 私個人の意見です。
    

    View Slide

40. 40
    MySQLでのSharding with Kubernetes：Vitess
    VTtablet
    VTtablet
    VTtablet
    VTgate
    app
    app
    app
    SQL
    SQL
    SQL
    • KubernetesでのDB利用は、MySQLの方が活発。
    • Youtubeで利用されている
    実績がある。
    • CNCFでもIncubatingから
    Graduatedになり、成熟化
    したと認められている。
    • 何十億ユーザの大規模データ
    ベースを実用レベルで動かす
    なら、ここまで必要？
    

    View Slide

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の機能を分割し、自社クラウドで展開している。
    

    View Slide

42. 42
    DB/Storage プラットフォームとしてのKubernetes
    aaS by Kubernetes
    STaaS by Kubernetes
    << aaSの基本要素>>
    • 共有ディスク型HA
    • Replication
    • プラガブル・ストレージ
    <>
    • 分散ストレージ
    • Kubernetes-Native
    • 互換性の高いIF(CSI)
    • “Platform for Platforms”として、K8sが各Serviceを支える。
    

    View Slide

43. 43
    Questions?
    @tzkb
    @tzkoba
    

    View Slide