Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetesが拓くDatabaseとStorageの未来

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
November 12, 2019

 Kubernetesが拓くDatabaseとStorageの未来

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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

November 12, 2019
Tweet

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) 1 Sharding Replication (Active/Active) 2以上 インスタンス数

    データ冗長化 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を支える。