昨日の夜は、Cloud Native Developers JP さんの主催する「結局Kubernetesのストレージどうするの? - cndjp第8回勉強会」に参加してきました。
「永続化データを保持しないのが基本であるコンテナ/Kubernetesでは、如何にストレージを選択し、組み合わせて行くかが設計上の重要なトピック」ということで、Kubernetesとストレージというテーマで3本のセッションがありました。
Kubernetes標準のストレージ機能をおさらいしよう
最初は日本オラクルの早川(@hhiroshell)さんによる、「Kubernetes標準のストレージ機能をおさらいしよう」という発表でした。 基礎編、ということで、幅広く、かつややこしいKubernetesのストレージ周りの標準機能を整理するという自分にとってありがたい内容でした。
Kubernetesでストレージを利用する方法
大きく分けると以下の3つがある。
- Volumeを直接指定してContainerにマウントする
- Volumeの要件を指定して、満たすものを自動的にマウントする
- Volumeの要件を指定して、満たすストレージを動的にプロビジョニングしてマウントする
ここで大事なストレージの設定項目を書き出しておくと
- Volume
- PersistentVolume(PV)
- PersistentVolumeClaim(PVC)
- StorageClass
PVやPVCでよく使う設定としては
- Reclaim Policy
- Access Mode
が挙げられていました。資料の方にそれぞれの説明が詳しく書かれています。strage.yaml の記述を例に説明がされていて、とてもわかり易かったです。
いろいろなストレージタイプ
Volumeの種類
- いわゆるストレージ
- 設定情報等の受け渡し用
- configMap
- secret
- downwardAPI
- テンポラリな保存領域として
- emptyDir
- hostPath
- 他
- flocker
- gitRepo
多くのストレージタイプがあって、目的に応じて使い分ける必要があることもわかりました。
What’s New in Kubernetes 1.12
以下の3つが挙げられていました。
Mount Propagation (beta -> GA)
- マウントされたVolume配下に更に追加のマウントが行われたときに、Pod/Nodeでそれを共有できるかどうかを決める設定
Volume Binding Mode (alpha -> beta)
- 動的プロビジョニングやPVとVolumeの結合(Bind)が実行されるタイミングを制御するモード(volumeBindingMode)の追加
Volume Snapshots (new / alpha)
- PVのSnapshotの取得/リストアを行う機能
- Kubernetes 1.8でprototypeとしてリリースされていた
感想
全体的に分かりやすく説明をしていただき、分かりにくかったところもスッキリしました。
Vitessのパフォーマンスと運用性を検証してみた
続いては、同じく日本オラクルの しげる こと(@cotoc)さんによる「Vitessのパフォーマンスと運用性を検証してみた」という発表でした。
Vitessとは
VitessはシャーディングによるMySQLの水平スケーリングのためのデータベースクラスタリングシステムで、YouTubeによって開発された技術とのこと。 kubernetes専用というわけではないが、kubernetesでの動作もサポートされている。
アーキテクチャ
アーキテクチャはスライドにある絵が分かりやすかったので、貼っておきます。
用語説明
- Topology
サーバー、シャーディング・スキームなどの構成情報を管理するメタデータストア。 - VTgate
アプリケーションからのクエリを正しいVTtabletにルーティングし、統合された結果をクライアントに返す軽量なプロキシサーバー。 不正なSQLを実行しないようにSQLパーサーも持っているので、MySQLへのクエリをすべて実行できるわけではない。 - VTctld
Vitessクラスタに対する管理操作を受け付けるHTTPサーバー - VTctl
Vitessクラスタを管理するためのコマンドラインツール - VTtablet
MySQLデータベースの前に置かれているプロキシサーバー - tablet
mysqldとVTtabletの組み合わせ
シャーディング
2つ以上のデータベースにデータを分割し格納すること。
用語説明
- Keyspace
シャードを複数まとめた論理的なデータベース。アプリケーションからは単一のデータベースとして見える。 - VSchema
テーブルが複数のShard間でどのように編成されているかに関するメタデータ。 - Vindex
キーとなる列とKeyspace IDの算出ロジックを定義。 - Keypsace ID
特定の行がどのShardに存在するかを決定・特定するために使用される値。
新しいShardに切り替える時のダウンタイム
- Readはダウンタイムなし
- Writeのみ5秒程度のダウンタイムあり
検証
バックアップ・リストア
- バックアップを取得した状態で、VTtablet(Master/Replica/Ronly)全てを削除、VTTabletを再作成したらどうなるか?
- 新たにVTtabletを起動後、自動的に最新のバックアップからリストアされデータの復元できた
Sharding前後のパフォーマンス
- フル・スキャンするようなクエリーを実行、どっちがはやい?
- シャード4つで検証し約3.5倍Shardingしたほうが速かった。 オーバーヘッドもあるので、4倍にはならなかった。
感想
データベースクラスタリング、こういう方法もあるんだなと改めて勉強になりました。 実行計画も確認できるようなので、Vitessについて自分でも調べてみようかな、という内容でした。
オンプレ、クラウドに対応するKubernetesストレージの実現
最後は NetAppの @makotow さんによる「オンプレ、クラウドに対応するKubernetesストレージの実現」という発表でした。
コンテナをプロダクション運用をするための最大の課題
コンテナを本番運用するときの課題として、ストレージがある。 高可用性/データ保護を実現したコンテナのデータ永続化が本番運用への大きな障壁となっている、
オンプレ・クラウドでオンデマンドにストレージリソースの提供、データモビリティ
- 消費型ストレージプラットフォームの実現
- データモビリティの実現
消費型ストレージプラットフォームの実現
NetApp社がOSSとして提供している Trident というストレージオーケストレーションツールを使って Dynamic Provisioning を行う。
- データプラットフォームの統合的なインターフェース
- External Dynamic Provisioner
Trident 自体は Pod としてクラスタにデプロイされる。
Tridentの特徴的な機能:Fast Cloning 超巨大ボリュームでも容量を消費せずに超高速にデータコピー デモ動画では 1.5TBのデータベース9つを30秒位でコピーしていた。しかも使用している容量としては100GBくらいしか増えていない。 恐らくリアルデータをすべてコピーするのではなく、メタデータををうまく利用してコピー状態を作っているのではないかと思われる。 (じゃないと速度はともかく、サイズの増分が少なすぎる)
データモビリティの実現
Kubernetes と NetApp を使うと、Cluster Federation から1つのデータソースのように扱う Cluster Federation を実現することが可能になるとのこと。 Heptio Arkを使ったクラスタ間の構成情報のDRを実現するソリューションもNetApp社で提供している。
Kubernetes as a Service始めました
NetApp Kubernetes Service(NKS) マルチクラウドオーケストレーターを提供していた Green quloud qstack社を買収してサービスに組み込み。
デモも見せていただきましたが、Web画面からポチポチやるだけで環境が作成されていって、本当に環境が作成されているんだろうかと感じるくらいでした。すごいですね。。。
LT
最初のLTはつかまん(@tsukamania)さんによる「Rancherのヤツ知ってる?いや、そっちじゃなくてLonghornのほう」と、青山(@amsy810)さんによる「PersistentVolumeClaimResizeで ボリュームを途中で拡張しよう」という発表でした。発表時間は10分でしたが、メモを取りきれなかったので資料だけ貼っておきます。
懇親会中の発表なのに椅子があったせいかみんな熱心に聞き入っていて、いい意味でちょっと不思議な雰囲気でした。
まとめ
Cloud Native Developers JP さんの主催する勉強会には初めて参加したのですが、初心者から上級者までの幅広い層に向けた内容となっていていいなと思いました。 エウレカさんの会場もきれいでいいところでした。 また次回も参加したいと思っています。(応募者が多いので抽選で当たるかどうか、微妙なところかもしれませんが)