Kubernetesが拓くDatabaseとStorageの未来

2019/11/14のAI Storage TOKYO Meetup#4の発表資料です。

Transcript

1. Takahiro, Kobayashi ( @tzkb) Kubernetesが拓く DatabaseとStorageの未来 AI Storage Tokyo Meetup#4 , 11/14
2. 2 最近やっていること • Cloud Native Days Tokyo 2019 “Cloud Native Storageが拓く Database on Kubernetesの未来” • PostgreSQL Conference Japan 2019 “Kubernetesでつくる PostgreSQL as a Service” ＋ ＝∞
3. 3 1. Cloud Nativeなデータベースとは 2. Database with Kubernetesの課題 3. Kubernetesストレージの現在地点 4. STasS with Kubernetesがもたらすもの アジェンダ
4. 4 Cloud Nativeなデータベースとは 1
5. 5 Cloud Nativeって何でしょう？ https://speakerdeck.com/jacopen/fei-biip-mou-cloud-nativefalseshi-jie?slide=16
6. 6 Cloud Nativeなデータベースの構成例 Compute Storage Managed Amazon Aurora Amazon Redshift Amazon RDS VM-based on Kubernetes • マネージドの形からVM、コンテナベースまで選択肢は多様。
7. 7 (今更ですが) コンテナ／Kubernetesとは Pod Pod Pod Pod Pod • ステートレスなアプリケーションを動かす際に有用とされる。 特徴として、 • 宣言的設定 • 自己修復 • Immutable DB向きじゃない？ ※KubernetesのPod＝1つ以上のコンテナを まとめて管理する概念
8. 8 Database with Kubernetesの課題 2
9. 9 データをどのように永続化するか？ Master Slave Replicate • データベースでは高可用性、データ永続化はできて当たり前。 • Immutableなので、通常は Podを再起動したらデータは 消失。 • 自己修復機能があるが、デー タ損失とは別の問題。 （≠DBリカバリ） • Podは同質、Replicationのよ うに、それぞれ役割が異なる DBクラスタをどう表現する か。
10. 10 データ冗長化とDBクラスタリング 共有ディスク (Active/Standby) １ Sharding Replication (Active/Active) ２以上 インスタンス数 データ冗長化 2以上 Shared Disk Log Shipping (基本的に) なし × スケールアウト Read Read/ Write Failover (Fencing) 障害時切替 Promotion (Election) --- • 複数ノードでDBを構成するクラスタリングでは、データをどのレ イヤで冗長化するなどに違いが見られる。
11. 11 クラスタパターン① 共有ディスク型HA • 障害検知/切替はLinux-HA等で • 生死監視の専用NW(二重化) • データは共有ストレージで冗長化 <<避けるべき最悪ケース>> • 複数インスタンスでストレージに 書き込みをしてしまうこと <<対策>> • Fencing：強制的なリソース解放 VIP Linux-HA Controller Controller • UNIX以前から使われる古典的クラスタリングだが、今なお有用。
12. 12 Fencingとは VIP Linux-HA Controller Controller << 状態不明なマスターが発生したら>> ① 強制的にノードの電源落とす i. プロセスを確実に停止 ii. ストレージのマウントを外す iii. VIPを外す ② その上で別ノードでリソースを獲得し て、マスターを起動 ※強制電源断はHWベンダ提供の管理ポートや クラウドAPIを通して行われる。 • 障害ノードをフェンスで囲うこと(隔離) ＝Fencing
13. 13 クラスタパターン② Replication WAL • マスタはRead/Write、 スレーブはReadのみを処理 • 障害検知/切替は別ツールが必要 • データはWAL転送で冗長化 <<避けるべき最悪ケース>> • 複数マスタが選出されること <<対策>> • リーダー選出：常に1台のマスタ • DBMSに組み込まれた冗長化機能で、データを相互同期する構成。 マスタ スレーブ スレーブ
14. 14 リーダー選出とは WAL データは最新、 リーダーに選出。 他はスレーブ。 • 複数候補から常に1台のマスタ を選出 • 元マスタが復帰後もスレーブに なっていることを通知する <<状態不明なマスタが発生したら>> ① 残ったスレーブから1台の リーダーを選出する ② 選出されたらマスターへ昇格 ③ 復帰ノードはスレーブになる • アルゴリズムとしてはPaxos、Raftなどが有名。 マスタ スレーブ
15. 15 クラスタパターン③ Sharding • ノード間でデータを分割して保持、 一つのDBのように見せる。 • コーディネータが処理を振り分け、 負荷を分散する。 • データ冗長化は基本的に含まない。 合わせて実装することもある。 • トランザクション実装が難しい。 ※当資料でShardingの細かな解説はしない。 • 可用性よりも拡張性を高める際に使われる構成。 コーディネータ
16. 16 Kubernetesストレージの現在地点 3
17. 17 Kubernetesが持つ永続化の仕組み PV PV PVC PVC • K8sはステートフルなワークロードでも対応が進んでいる。 • StatefulSet（sts） – 一意に特定可能なネットワークアド レス、順次処理できるdeployなどを 提供。 • Persistent Volume – PV/PVC/StorageClassを用いて、 データを永続化する。 – データの可搬性を高めるには、図の ようにクラウド・ストレージを使う のが最も簡単。
18. 18 オンプレミスでは Volume Plugin Orchestration Storage Management • 各ベンダがK8s対応のストレージ・ソフトウェアを提供。 • 下記のように自社ストレージへ コンテナ対応のIFを持つ製品が 増えてきている。 – NetApp Trident – Pure Storage PSO • クラウド・ストレージのAZ問題を 解決するのに使えるサービスも展開 が進む。 – NetApp Cloud Volume ONTAP – HPE Cloud Volumes
19. 19 Compute Control plane Data plane さらにその先へ Controler Controler • Kubernetes自身がSDSのプラットフォームとなる可能性も。 Kubernetes Ready Kubernetes Native
20. 20 Cloud Nativeなストレージも選択肢が拡がっている • K8sやコンテナとの接続できるというだけの場合もある。 • 当然、以下になくともK8s対応しているものもある。
21. 21 データベースでの利用 ≒ ブロックデバイス 名称 バックエンド ブロック？ OSS/Proprietary ◎ OSS ◎ OSS Redhat OpenShift Container Storage ◎ Proprietary StorageOS --- ◎ Proprietary • CNCF incubatingのRookが目立つが、OpenShiftも成長中。
22. 22 （参考） • 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の機能で自動化 する仕組みを目指している。
23. 23 DB＋K8sストレージ： with Replicas:1 • PostgreSQLはStatefulSet、PVとしてRook/Cephを用いる。 • DBもストレージも全て K8sで管理するHA構成 • 共有ディスクはCeph • kube-fencingでNode 障害時のFencing << 課題 >> • 複雑すぎるCeph • ネットワーク越しのIOに よる性能劣化 kube-fencing
24. 24 DB+K8sストレージ： with Replicas:1 kube-fencing • LINSTORがProvisioning/AttachするDRBDボリュームを用いる。 • DBもストレージも全て K8sで管理するHA構成 • DRBDでデータ冗長化 • シンプル • ReadはローカルIO、 性能面でCephに優る << 課題 >> • K8s対応が進んでいない • スケール上限あり
25. 25 （参考）SDS別のベンチマーク結果 シングル構成(EBS) Rook/Ceph DRBD 1インスタンス 5インスタンス 2インスタンス 100 37.8 77.1 • pgbenchによる簡易ベンチマークでは以下のような差が出た。 TPS
26. 26 STaaS with Kubernetesがもたらすもの 4
27. 27 ここまで見てきたこと  Cloud Nativeな形態の一つとして、データベースを Kubenetesで動かす流れは加速している。  現在はReplicationによる高可用設計が主流だが、SDSの Kubernetes対応により、ストレージレイヤでデータを 冗長化される構成も可能となっている。  CSI(Container Storage Interface)もGA、更に進化。 Cloud Native Storage ＋ ＋ ＝ ???
28. 28 DB/Storage プラットフォームとしてのKubernetes DBaaS by Kubernetes STaaS by Kubernetes <<DBaaSの基本要素>> • HA • Replication • DB Operator <<STaaSの基本要素>> • シンプルな冗長化 • 分散ストレージ • 互換性の高いIF(CSI) • “Platform for Platforms”として、K8sが各Serviceを支える。