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)
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. 突撃！お宅のデータベース 2. Managed Serviceで出来ること／出来ないこと 3. ここまで出来る Database with Kubernetes 4. Kubernetesはプラットフォームへ アジェンダ #JTF2019 #JTF2019_A
4. 4 突撃！お宅のデータベース 1
5. 5 昔々あるところに、 LB AP AP AP • 古きよきLB-AP-DBのWebシステムがありました。 • VMかもしれないし、 ベアメタルかも。 • 機器は老朽化、アーキ テークチャも陳腐化。 • ある日、 偉い人は言いました。 「これからはクラウド」
6. 6 Lift & Shift だ！ • 担当者は不眠不休でがんばりました。 • クラウド上へシステムを 移行。 • アプリケーションをコン テナ化、Kubernetesに デプロイ。 • データベースはManaged Serviceを使った。 良くありますよね？ (むしろ頑張ったほう） AP AP AP
7. 7 使ってるDBはどこに？ @PostgreSQLアンカンファレンス オンプレ クラウド （Managed） コンテナ 9 11 8 4 1 5 1
8. 8 なぜManagedなデータベースを使うのか （建前） • RDSは素晴らしい。 • ベストプラクティスでしょ？ • 構築もらっくらく。 • 運用もほぼ自動。 （本音） • インストールとか面倒。 • 開発が本業。DBAいない。 • ストレージもわからない。 • おれたちは雰囲気でDBやってる。 DB
9. 9 今日のゴール ～ Managed Service以外の選択肢を ～  アプリケーションはコンテナ化して、Kubernetesも 使う／使おうとしている、Cloud Native開発者の方に。  データベースの選択肢もいろいろあります。  Managed Serviceが唯一解ではありません。  DBのコンテナ化、という手もあります。  Kubernetes の力を借りてみましょう。
10. 10 今日話さないこと  Kubernetesの一般的な概念。 （一部、Statefulな機能の紹介はあります。）  Kubernetesクラスタの構築・管理方法。 （K8sクラスタは構築済みを前提とします。 異論はあると思います。）  PostgreSQL以外のデータベースでの事例。 （ちょっとは話すかも知れません。）
11. 11 Managed Serviceで 出来ること/出来ないこと 2
12. 12 RDSで出来ること 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション オンプレミス Amazon RDS ユーザ による管理 による管理
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は使えない。
14. 14 それ、Database with Kubernetesでも出来ますよ？ 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション Database w/ K8sクラスタ による管理 バージョン選択 任意のバージョンを選べる リソース上限 Nodeのキャパシティ次第 リソース下限 CPUはmill core単位で指定可 パラメータ 全て変更可能 Extension 全て導入可能 OSログイン 可能（任意のユーザ作成も可）
15. 15 ちょっと視点を変えて • ManagedなDBは確かに便利だが、全工程で最適ではない。 特徴 • 開発者向け • 1人で1DBが理想 • リリース確認用 • ユーザ/内部テスト • 本番サービス用 Managed 向き？ • No. • 1人1インスタンスは 辛い • Yes. • インスタンスが増え ていくことも。 • Yes. • Managedのサービス レベル次第 Development Test/Staging Production
16. 16 Developmentでは AP AP AP AP 1人1DBあると捗る。 詰め込んでお安く。 可用性は諦める データ保護は開発者で。 温かみのある手動デプロイ。
17. 17 Test/Stagingでは 連結テスト ユーザ確認 環境をきちんと分ける。 可用性は最低限レベルで必要。 データ保護、バックアップも。 データのCloneも便利。 統制の利いたCI/CD。 AP AP AP AP AP AP AP AP
18. 18 Productionでは • ワークロード毎に求められる要件は変わってくる。 梅 竹 松 RDS (Multi-AZ) RDS (Readレプリカ) Aurora Spanner • 最低限の可用性。 • AZ超えて、データを 保護。 • スケールはしない。 • 3重以上のデータ保護。 • Readのみスケールが 可能。 • 構成管理は複雑に。 • 3重以上のデータ保護。 • Writeヘビーなワーク ロードでもスケール。 • データ設計が特殊に。 例
19. 19 ここまでできる Database with Kubernetes 3
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
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)を停止すると データが消える。
22. 22 Development->Test/Stagingの課題  単純にコンテナをNodeに詰め込んだだけ。 • 1ノードならDockerレベルのことをやっているだけ。  Kubernetesのデータ永続化の仕組みを使っていない。 • StatefulSetやPersistentVolumeという仕組みがある。  ローカルディスクのキャパシティ管理が難しい。 • ローカルディスクの空きはPodデプロイ時に考慮されない。
23. 23 （参考）TopoLVMとは topolvm lvmd /dev/hoge1 /dev/hoge2 /dev/hoge3 • サイボウズが開発した、LVMベースのCSIプラグイン。 • ローカルボリュームのキャパシティ管理に関する問題を解決する。 【特徴】 • LVMによるボリューム管理。 • サイズやフォーマットなどを作成時 に指定可能。 • 動的プロビジョニングに対応。 • ノードの空き容量に応じたスケ ジューリング。 https://github.com/cybozu-go/topolvm
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
25. 25 Test/Stagingをオンプレで構築するなら ～既存機器の利用～ AP クラウド・ストレージの変わりに、 既設ハードウェアをそのまま使える ケースがある。 • 下記の製品は自社ストレージを コンテナ・Kubernetesから利用 可能とする仕組みを提供。 – NetApp Trident – Pure Storage PSO 既設のストレージ PVC
26. 26 Test/Staging->Productionの課題  可用性が十分でない。 • StatefulSetのデプロイ対象Nodeを複数に出来ていない。 • そのため、Auto-Healingが効かない。 • EBSを使った場合、AZ障害で利用継続できない。  シングルインスタンスでスケーラビリティがない。 • データベースのスケールアウトに必要な、Readレプリカなどの 仕組みが考慮されていない。
27. 27 For Production • DB with Kubernetesで何処までカバーできるかの見極めが必要。 梅 竹 松 可用性 データ保護 運用性 拡張性 いずれも高 2重化(Multi-AZ) 3重化以上 なし Readレプリカ Wrire分散 Operatorによる自動化 DBAによる運用
28. 28 For Production（梅モデル）～OSS版～ kube-fencing AZ-a AZ-b 【特徴】 • SDSを用いたAZ跨ぎのリア ルタイムなデータ冗長化。 – LINSTOR/DRBDとは、Linuxの HA構成では昔からあるネット ワークRAIDをSDS化したもの。 • kube-fencingによる自動 フェイルオーバ。 • はシングルインスタンス でシンプルで管理も容易。
29. 29 Fencingとは？ kube-fencing • Kubernetesに本来向かない、共有ディスク型HAに必要な仕組み。 • K8sではNW分断などでsplit brainとなることを防ぐため、 自動FOをしない。 • kube-fencingは管理ポー ト・クラウドAPI等を使って、 Nodeの電源を強制断。 • リソースが解放され、待機系 でDBが起動される。
30. 30 For Production（梅モデル）～プロプライエタリ版～ kube-fencing AZ-a AZ-b 【特徴】 • NetAppがAWS等で提供する、 Cloud Volume ONTAPを 使ってAZを超えてデータの 冗長化が可能。 • HPE Cloud Volumesも同じ 用途で利用可能と思われる。 • その他の特徴はOSS SDSの ものと同じ。
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の負荷が軽減 される。
32. 32 For Production：Zalandoのケース • PGConf.Asiaで発表された on Kubernetesの例。 Productionとして大規模に展開。
33. 33 For Producion（松モデル）
34. 34 For Production（松モデル）？  Writeヘビーなワークロードをこなせる分散DBは、そもそも 非常に難しい。  例えば、以下のようなソリューションがあるが、いずれも 現時点でKubernetes上に実装するのは簡単でない。 • Oracle Exadata • Amazon Aurora • Google Cloud Spanner • Azure Database for PostgreSQL – Hyperscale(Citus)
35. 35 （参考）アプリケーション・パーティショニング AP AP AP 0<id<100 101<id<500 501<id<999 • サービス単位だけでなく、ア クセスするデータ範囲でも、 分割してデプロイする。 • DBレイヤで特別な技術 (シャーディング等）を採用 せず、構成がシンプルに。 • 但し、サービス成長で リバランスが発生すると大変。
36. 36 Kubernetesはプラットフォームへ 4
37. 37 Database with Kubernetesの現実 • Productionで難しいケースがあることは事実。 梅 竹 松 RDS (Multi-AZ) RDS (Readレプリカ) Aurora Spanner Managed • SDSでAZを超えて データ冗長化。 • 共有ディスク型HAを 模した可用性。 w/ K8s • Replicationで冗長化、 Readはスケール。 • Operatorで自動化、 運用効率化。 王道かつ現実解
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かつ 冗長化される。
39. 39 （参考）MySQLでの分散DB(Sharding)の運用例 VTtablet VTtablet VTtablet VTgate • MySQLでのwith Kubernetesといえば、Vitessが著名。 • Youtubeで利用されている 実績がある。 • CNCFでもIncubatingから Graduatedになり、成熟化 したと認められている。 • 何十億ユーザの大規模データ ベースを実用レベルで動かす なら、ここまで必要。 AP AP AP
40. 40 （参考）Shardingとは • ノード間でデータを分割して保持、 一つのDBのように見せる。 • コーディネータが処理を振り分け、 負荷を分散する。 • ReadもWriteも分散できる。 • データ冗長化は基本的に含まない。 合わせて実装することもある。 • トランザクション実装が難しい。 • 可用性よりも拡張性を高める際に使われる構成。 コーディネータ
41. 41 Kubernetesはデータベース・プラットフォームへ Sharding RDB on 分散KVS • Vitessがメジャーな事例。 • Hyperscale(Citus)も同様。 • 多数のインスタンス管理は Kubernetesの得意ワザであり、 相性は良い。 • Spannerなどが典型。 • プラットフォームとしての KubernetesでSQLエンジンと 分散KVSを、大規模に展開・ 管理できる可能性がある。 • 2種の分散DBのプラットフォームとして、Kubernetesに注目。
42. 42 （再掲）今日のゴール ～ Managed Service以外の選択肢を ～  アプリケーションはコンテナ化して、Kubernetesも 使う／使おうとしている、Cloud Native開発者の方に。  データベースの選択肢はいろいろあります。  Managed Serviceが唯一解ではありません。  DBのコンテナ化、という手もあります。  Kubernetes の力を借りてみましょう。 with K8sも選択肢になり得る時代です。 Kubernetesでアプリだけ、は勿体ないですよ。
43. 43 Questions? @tzkb @tzkoba