Rookがサポートするストレージプロバイダ

本記事はRookと仲間たち、クラウドネイティブなストレージの Advent Calendar 2020 22日目の記事を後からこっそり埋めたものです。

RookはCephのオペレータとして有名ですが、Cephだけではなくそれ以外のソフトウェアもサポートしています。それぞれのストレージソフトウェアのことをRookではストレージプロバイダと呼んでいます。

さまざまなストレージプロバイダをサポートできるように、RookにはRookフレームワークというライブラリが存在しており、このライブラリを使って各ストレージプロバイダのオペレータを実装しています。

現在サポートされているストレージプロバイダの一覧は公式ドキュメントに書いています。

ストレージプロバイダはいったいどれだけの数があるかというと、もっとも多いときで7個ありました。「もっとも多い時で」と但し書きをしたのには理由があって、現在はそこからずいぶん減って3個になっています。

各バージョンでサポートされるストレージプロバイダは以下の通りです。

バージョン	ストレージプロバイダの数	ストレージプロバイダ一覧
v0.1~v0.7	1	Ceph
v0.8	3	Ceph, Cockroach DB, Minio
v0.9	5	Ceph, Cockroach DB, Minio, EdgeFS, Cassandra
v1.0	6	Ceph, Cockroach DB, Minio, EdgeFS, Cassandra, NFS
v1.1~v1.2	7	Ceph, Cockroach DB, Minio, EdgeFS, Cassandra, NFS, YugabyteDB
v1.3~v1.5	6	Ceph, Cockroach DB, EdgeFS, Cassandra, NFS, YugabyteDB
master	3	Ceph, NFS, Cassandra

v1.1まで増えていたものがだんだん減ってきたのはなぜかというと、メンテしている人が実質的にいないためにサポートが困難だというのが主な理由です。

とくに業務経験のないかたであれば「せっかくコードがあるなら残しておけばいいんじゃないの?」と思うかもしれませんが、メンテされていないコードを残すことには存在しているだけで次のような問題を引き起こします。

• ユーザがメンテされていないストレージプロバイダについてサポートを求めてきても対処できない
• メンテされていないコードのためにKubernetesなどの新規バージョンへの追従などでビルドが通らなくなったりする
• ロジックが無駄に複雑になる

削除されたストレージプロバイダがメンテされないようになった理由はそれぞれさまざまですが、いくつか例を挙げると次のようなものがありました。

• サポートを追加するPRのマージ後、一度もPRが投稿されない出し逃げ状態だった
• 開発元が別会社に買収されて、ストレージプロバイダの開発をやめた
• 開発元が別のオペレータを実装することに変更したので不要になった

上記のような理由によって、次版であるv1.6以降ではサポートされるストレージプロバイダの数を一気に半分に減らすと共に、今後は無暗に追加できないように、サポートに必要な条件が明文化されました。

といっても門戸が閉じられたわけではなく、ある意味当たり前のことが書いているだけです。よいものがあればサポートを増やすという姿勢は崩していません。実際、数回前のcommunity meetingではSambaのサポート追加が検討されていたようです。

ストレージプロバイダの数だけではなく、今後は別の方面からも大きな変化が検討されています。それは[rookリポジトリ](https://github.com/rook/rook]はRookフレームワークだけにして、ストレージプロバイダごとに別のプロジェクトを作るというものです。これには次のような様々な利点があります。

• ストレージプロバイダ間の依存なくせる
• それぞれストレージプロバイダが望むタイミングで新バージョンをリリースできる
• Rookリポジトリの肥大化を防げる
• Rookフレームワークのストレージプロバイダを作りたいが大きなリソースを投入してまで本体にマージするつもりがないというときの対応が楽

これはちょうどKubernetes本体のプロジェクト(github上のkubernetes/kubernetesプロジェクトなので、俗にk/kと呼ばれます)からなるべく多くの機能をモジュール化して別のプロジェクトに分けようとする動きと同じです^[1]。

ストレージプロバイダごとのプロジェクトという案はまだ採用が決まったわけではありませんが、筆者はこの方法のほうが利点が多いと思っているので賛成しています。少なくともv1.6においては現在の姿のままですが、いずれv1.7以降で本格的に動きがあるかもしれません。

脚注

1. 代表的なものを挙げると、過去Kubernetesのストレージのコードはk/kが丸抱えしていましたが、現在ほとんどすべてはCSIドライバとして別プロジェクトとして実装しています。