Cloud Native開発者のためのDatabase with Kubernetes

12/8のJuly Tech Festa 2019での登壇資料です。

Transcript

1. Cloud Native開発者のための
   Database with Kubernetes
   July Tech Festa 2019 , 12/8
   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. 突撃！お宅のデータベース
   2. Managed Serviceで出来ること／出来ないこと
   3. ここまで出来る Database with Kubernetes
   4. Kubernetesはプラットフォームへ
   アジェンダ
   #JTF2019 #JTF2019_A
   

   View Slide

4. 4
   突撃！お宅のデータベース
   1
   

   View Slide

5. 5
   昔々あるところに、
   LB
   AP
   AP
   AP
   • 古きよきLB-AP-DBのWebシステムがありました。
   • VMかもしれないし、
   ベアメタルかも。
   • 機器は老朽化、アーキ
   テークチャも陳腐化。
   • ある日、
   偉い人は言いました。
   「これからはクラウド」
   

   View Slide

6. 6
   Lift & Shift だ！
   • 担当者は不眠不休でがんばりました。
   • クラウド上へシステムを
   移行。
   • アプリケーションをコン
   テナ化、Kubernetesに
   デプロイ。
   • データベースはManaged
   Serviceを使った。
   良くありますよね？
   (むしろ頑張ったほう）
   AP
   AP
   AP
   

   View Slide

7. 7
   使ってるDBはどこに？ @PostgreSQLアンカンファレンス
   オンプレ
   クラウド
   （Managed）
   コンテナ
   9
   11
   8
   4
   1
   5
   1
   

   View Slide

8. 8
   なぜManagedなデータベースを使うのか
   （建前）
   • RDSは素晴らしい。
   • ベストプラクティスでしょ？
   • 構築もらっくらく。
   • 運用もほぼ自動。
   （本音）
   • インストールとか面倒。
   • 開発が本業。DBAいない。
   • ストレージもわからない。
   • おれたちは雰囲気でDBやってる。
   DB
   

   View Slide

9. 9
   今日のゴール ～ Managed Service以外の選択肢を ～
    アプリケーションはコンテナ化して、Kubernetesも
   使う／使おうとしている、Cloud Native開発者の方に。
    データベースの選択肢もいろいろあります。
    Managed Serviceが唯一解ではありません。
    DBのコンテナ化、という手もあります。
    Kubernetes の力を借りてみましょう。
   

   View Slide

10. 10
    今日話さないこと
     Kubernetesの一般的な概念。
    （一部、Statefulな機能の紹介はあります。）
     Kubernetesクラスタの構築・管理方法。
    （K8sクラスタは構築済みを前提とします。
    異論はあると思います。）
     PostgreSQL以外のデータベースでの事例。
    （ちょっとは話すかも知れません。）
    

    View Slide

11. 11
    Managed Serviceで
    出来ること/出来ないこと
    2
    

    View Slide

12. 12
    RDSで出来ること
    電源、ラック
    サーバ管理
    OSインストール
    OSパッチ
    DBインストール
    DBパッチ
    バックアップ/リストア
    HA
    スケール
    アプリケーション
    電源、ラック
    サーバ管理
    OSインストール
    OSパッチ
    DBインストール
    DBパッチ
    バックアップ/リストア
    HA
    スケール
    アプリケーション
    オンプレミス Amazon RDS
    ユーザ
    による管理 による管理
    

    View Slide

13. 13
    RDSで出来ないこと（制限されること）
    制限事項（例） 具体的な例
    バージョン選択 現在の最新は11.5（12はBeta）
    リソース上限 r5.24xl(96vCPU、768GBメモリ)、ストレージは最大64TB
    リソース下限 t3.mic(2vCPU、1GBメモリ)
    一部パラメータが変更不可 full_page_writesなど一部のパラメータは変更できない
    Extensionが限られる pg_hint_planなど一部はインストール可、全てではない。
    OSログインできない ssh接続によるOSログインはできない。
    • オンプレミスでの構築の場合は、そもそもManagedは使えない。
    

    View Slide

14. 14
    それ、Database with Kubernetesでも出来ますよ？
    電源、ラック
    サーバ管理
    OSインストール
    OSパッチ
    DBインストール
    DBパッチ
    バックアップ/リストア
    HA
    スケール
    アプリケーション
    Database w/
    K8sクラスタ
    による管理
    バージョン選択 任意のバージョンを選べる
    リソース上限 Nodeのキャパシティ次第
    リソース下限 CPUはmill core単位で指定可
    パラメータ 全て変更可能
    Extension 全て導入可能
    OSログイン 可能（任意のユーザ作成も可）
    

    View Slide

15. 15
    ちょっと視点を変えて
    • ManagedなDBは確かに便利だが、全工程で最適ではない。
    特徴 • 開発者向け
    • 1人で1DBが理想
    • リリース確認用
    • ユーザ/内部テスト
    • 本番サービス用
    Managed
    向き？
    • No.
    • 1人1インスタンスは
    辛い
    • Yes.
    • インスタンスが増え
    ていくことも。
    • Yes.
    • Managedのサービス
    レベル次第
    Development Test/Staging Production
    

    View Slide

16. 16
    Developmentでは
    AP
    AP
    AP
    AP
    1人1DBあると捗る。
    詰め込んでお安く。
    可用性は諦める
    データ保護は開発者で。
    温かみのある手動デプロイ。
    

    View Slide

17. 17
    Test/Stagingでは
    連結テスト ユーザ確認
    環境をきちんと分ける。
    可用性は最低限レベルで必要。
    データ保護、バックアップも。
    データのCloneも便利。
    統制の利いたCI/CD。
    AP
    AP
    AP
    AP AP
    AP
    AP
    AP
    

    View Slide

18. 18
    Productionでは
    • ワークロード毎に求められる要件は変わってくる。
    梅 竹 松
    RDS
    (Multi-AZ)
    RDS
    (Readレプリカ)
    Aurora
    Spanner
    • 最低限の可用性。
    • AZ超えて、データを
    保護。
    • スケールはしない。
    • 3重以上のデータ保護。
    • Readのみスケールが
    可能。
    • 構成管理は複雑に。
    • 3重以上のデータ保護。
    • Writeヘビーなワーク
    ロードでもスケール。
    • データ設計が特殊に。
    例
    

    View Slide

19. 19
    ここまでできる
    Database with Kubernetes
    3
    

    View Slide

20. 20
    For Development
    • オンデマンドなインスタンス作成をKubernetesで実現。
    apiVersion: v1
    kind: Pod
    metadata:
    name: postgres-tzkb
    spec:
    containers:
    - name: postgres12-1
    image: postgres:12.1
    resources:
    requests:
    cpu: 500m
    memory: 512Mi
    limits:
    cpu: 1000m
    memory: 1024Mi
    volumeMounts:
    - name: pg-vol
    mountPath: /var/lib/postgresql/data
    

    View Slide

21. 21
    （解説）Development向けの超シンプルPostgreSQL
    apiVersion: v1
    kind: Pod
    metadata:
    name: postgres-tzkb
    spec:
    containers:
    - name: postgres12-1
    image: postgres:12.1
    resources:
    requests:
    cpu: 500m
    memory: 512Mi
    limits:
    cpu: 1000m
    memory: 1024Mi
    volumeMounts:
    - name: pg-vol
    mountPath: /var/lib/postgresql/data
    ports:
    - containerPort: 5432
    volumes:
    - name: pg-vol
    emptyDir: {}
    柔軟なバージョン選択
    リソース上限/下限の設定
    ローカルディスクの一時利用
    より詳細に知りたい方は
    「Production Ready Kubernetesに必要な15のこと」
    https://speakerdeck.com/govargo/production-ready-kubernetes-15-rules
    コンテナ(Pod)を停止すると
    データが消える。
    

    View Slide

22. 22
    Development->Test/Stagingの課題
     単純にコンテナをNodeに詰め込んだだけ。
    • 1ノードならDockerレベルのことをやっているだけ。
     Kubernetesのデータ永続化の仕組みを使っていない。
    • StatefulSetやPersistentVolumeという仕組みがある。
     ローカルディスクのキャパシティ管理が難しい。
    • ローカルディスクの空きはPodデプロイ時に考慮されない。
    

    View Slide

23. 23
    （参考）TopoLVMとは
    topolvm
    lvmd
    /dev/hoge1 /dev/hoge2 /dev/hoge3
    • サイボウズが開発した、LVMベースのCSIプラグイン。
    • ローカルボリュームのキャパシティ管理に関する問題を解決する。
    【特徴】
    • LVMによるボリューム管理。
    • サイズやフォーマットなどを作成時
    に指定可能。
    • 動的プロビジョニングに対応。
    • ノードの空き容量に応じたスケ
    ジューリング。
    https://github.com/cybozu-go/topolvm
    

    View Slide

24. 24
    For Test/Staging
    Kubernetesの仕組みを使って、
    正しく作る。
    • StatefulSet（sts）
    – 安定的なストレージ利用、一
    意なホスト名などデータベー
    スでの利用に向いている。
    • Persistent Volume（PV）
    – PV/PVC/StorageClassを用い
    て、データを永続化。
    – データ保護の面ではクラウ
    ド・ストレージを使うのが最
    も簡単。
    AP
    AP
    AP
    連結テスト ユーザ確認
    PV
    AP
    AP
    AP
    PVC
    PVC
    PVC
    PVC
    PV
    PV
    PV
    

    View Slide

25. 25
    Test/Stagingをオンプレで構築するなら ～既存機器の利用～
    AP
    クラウド・ストレージの変わりに、
    既設ハードウェアをそのまま使える
    ケースがある。
    • 下記の製品は自社ストレージを
    コンテナ・Kubernetesから利用
    可能とする仕組みを提供。
    – NetApp Trident
    – Pure Storage PSO
    既設のストレージ
    PVC
    

    View Slide

26. 26
    Test/Staging->Productionの課題
     可用性が十分でない。
    • StatefulSetのデプロイ対象Nodeを複数に出来ていない。
    • そのため、Auto-Healingが効かない。
    • EBSを使った場合、AZ障害で利用継続できない。
     シングルインスタンスでスケーラビリティがない。
    • データベースのスケールアウトに必要な、Readレプリカなどの
    仕組みが考慮されていない。
    

    View Slide

27. 27
    For Production
    • DB with Kubernetesで何処までカバーできるかの見極めが必要。
    梅 竹 松
    可用性
    データ保護
    運用性
    拡張性
    いずれも高
    2重化(Multi-AZ) 3重化以上
    なし Readレプリカ Wrire分散
    Operatorによる自動化
    DBAによる運用
    

    View Slide

28. 28
    For Production（梅モデル）～OSS版～
    kube-fencing
    AZ-a AZ-b 【特徴】
    • SDSを用いたAZ跨ぎのリア
    ルタイムなデータ冗長化。
    – LINSTOR/DRBDとは、Linuxの
    HA構成では昔からあるネット
    ワークRAIDをSDS化したもの。
    • kube-fencingによる自動
    フェイルオーバ。
    • はシングルインスタンス
    でシンプルで管理も容易。
    

    View Slide

29. 29
    Fencingとは？
    kube-fencing
    • Kubernetesに本来向かない、共有ディスク型HAに必要な仕組み。
    • K8sではNW分断などでsplit
    brainとなることを防ぐため、
    自動FOをしない。
    • kube-fencingは管理ポー
    ト・クラウドAPI等を使って、
    Nodeの電源を強制断。
    • リソースが解放され、待機系
    でDBが起動される。
    

    View Slide

30. 30
    For Production（梅モデル）～プロプライエタリ版～
    kube-fencing
    AZ-a AZ-b 【特徴】
    • NetAppがAWS等で提供する、
    Cloud Volume ONTAPを
    使ってAZを超えてデータの
    冗長化が可能。
    • HPE Cloud Volumesも同じ
    用途で利用可能と思われる。
    • その他の特徴はOSS SDSの
    ものと同じ。
    

    View Slide

31. 31
    For Production（竹モデル）
    kubedb-operator
    -0 -1 -2
    postgres snapshot
    dormantdabases
    S3等にスナップショットの
    保存が可能
    AZ-a AZ-b AZ-c 【特徴】
    • KubeDB というOSSで、
    Streaming Replication。
    • 1台のMaster、複数のSlave
    で構成され、Readクエリは
    分散可能。
    • 面倒な初期構築やリカバリを
    KubeDB Operatorが管理。
    • バックアップなどもK8sから
    実行可能、DBAの負荷が軽減
    される。
    

    View Slide

32. 32
    For Production：Zalandoのケース
    • PGConf.Asiaで発表された on Kubernetesの例。
    Productionとして大規模に展開。
    

    View Slide

33. 33
    For Producion（松モデル）
    

    View Slide

34. 34
    For Production（松モデル）？
     Writeヘビーなワークロードをこなせる分散DBは、そもそも
    非常に難しい。
     例えば、以下のようなソリューションがあるが、いずれも
    現時点でKubernetes上に実装するのは簡単でない。
    • Oracle Exadata
    • Amazon Aurora
    • Google Cloud Spanner
    • Azure Database for PostgreSQL – Hyperscale(Citus)
    

    View Slide

35. 35
    （参考）アプリケーション・パーティショニング
    AP AP AP
    0• サービス単位だけでなく、ア
    クセスするデータ範囲でも、
    分割してデプロイする。
    • DBレイヤで特別な技術
    (シャーディング等）を採用
    せず、構成がシンプルに。
    • 但し、サービス成長で
    リバランスが発生すると大変。
    

    View Slide

36. 36
    Kubernetesはプラットフォームへ
    4
    

    View Slide

37. 37
    Database with Kubernetesの現実
    • Productionで難しいケースがあることは事実。
    梅 竹 松
    RDS
    (Multi-AZ)
    RDS
    (Readレプリカ)
    Aurora
    Spanner
    Managed
    • SDSでAZを超えて
    データ冗長化。
    • 共有ディスク型HAを
    模した可用性。
    w/ K8s
    • Replicationで冗長化、
    Readはスケール。
    • Operatorで自動化、
    運用効率化。
    王道かつ現実解
    

    View Slide

38. 38
    For Producion（松モデル）も実現する可能性が！
    • with K8sな が開発されている。
    tablet3
    tablet2
    tablet1
    tablet4
    tablet2
    tablet1
    tablet4
    tablet3
    tablet1
    tablet4
    tablet3
    tablet1
    Distrbuted
    Txn Mgr
    Distrbuted
    Txn Mgr
    Distrbuted
    Txn Mgr
    Distrbuted
    Txn Mgr
    syscatalog syscatalog syscatalog
    【特徴】
    • Spannerに似た分散DB
    でWriteヘビーに強い。
    • PostgreSQLのSQLエン
    ジンと分散ストレージ
    としてのDocDBで構成
    される。
    • データはShardingかつ
    冗長化される。
    

    View Slide

39. 39
    （参考）MySQLでの分散DB(Sharding)の運用例
    VTtablet
    VTtablet
    VTtablet
    VTgate
    • MySQLでのwith Kubernetesといえば、Vitessが著名。
    • Youtubeで利用されている
    実績がある。
    • CNCFでもIncubatingから
    Graduatedになり、成熟化
    したと認められている。
    • 何十億ユーザの大規模データ
    ベースを実用レベルで動かす
    なら、ここまで必要。
    AP
    AP
    AP
    

    View Slide

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

    View Slide

41. 41
    Kubernetesはデータベース・プラットフォームへ
    Sharding
    RDB on 分散KVS
    • Vitessがメジャーな事例。
    • Hyperscale(Citus)も同様。
    • 多数のインスタンス管理は
    Kubernetesの得意ワザであり、
    相性は良い。
    • Spannerなどが典型。
    • プラットフォームとしての
    KubernetesでSQLエンジンと
    分散KVSを、大規模に展開・
    管理できる可能性がある。
    • 2種の分散DBのプラットフォームとして、Kubernetesに注目。
    

    View Slide

42. 42
    （再掲）今日のゴール ～ Managed Service以外の選択肢を ～
     アプリケーションはコンテナ化して、Kubernetesも
    使う／使おうとしている、Cloud Native開発者の方に。
     データベースの選択肢はいろいろあります。
     Managed Serviceが唯一解ではありません。
     DBのコンテナ化、という手もあります。
     Kubernetes の力を借りてみましょう。
    with K8sも選択肢になり得る時代です。
    Kubernetesでアプリだけ、は勿体ないですよ。
    

    View Slide

43. 43
    Questions?
    @tzkb
    @tzkoba
    

    View Slide