この記事はRookと仲間たち、クラウドネイティブなストレージの Advent Calendar 2020 25日目の記事です。(過ぎてるけど…)
こんにちは。レッドハットでストレージを中心にクラウドインフラを生業にしている宇都宮です。
今日はOpenShiftをはじめとするコンテナ環境における…に限らずの一般的な環境でストレージがハマりやすいわけについての愚痴お話しをしたいと思います。
あんまりストレージ詳しくないかたに読んでもらって、へぇと思っていただければ嬉しいです。
コンテナ環境でハマるストレージの落とし穴
コンテナ環境におけるストレージは、CSI(Container Storage Interface)の仕組みができてから、使い始めるにはかなり簡単になりました。パブリッククラウドにしろオンプレにしろ、そこにあるストレージをコンテナストレージとして使えるようになったからです。
とは言えまだまだチャレンジが多いエリアではあります。それはどんなストレージを要求するアプリケーションがコンテナで動いてくるのか分からないことに起因します。
例えばOpenShiftやKubernetesの環境で、そこにあるブロックストレージがRWO PVとして使えるからこれで大丈夫だろ、と間に合わせた後、ユーザーから『RWX PVが欲しい』と言われたとします。
ほぼ全てのブロックストレージはRWXはできませんので、RWXができるストレージを用意してなくてはなりません。NASが用意できればベストですが、ちゃんとしたNASを買うには3-4桁万円は要るので、そんな追加投資は難しい。急場しのぎでNFSサーバーを立てるパターンが良くありますが…アクセス制御が十分でない、Quotaも効かせられない、ベンダーサポートも期待できない、運用上で安定性に欠けるNFSサーバーがガンガン使われていき、いつ止まるか恐れおののきながら運用することになります。これはとてもおすすめできません。
この例の他にも、Snapshotを取りたいとか、ハイブリッドクラウド対応したいとか、様々なユーザーの要求は来る可能性はあります。また運用管理側でもツラい思いをする可能性もあります。
なぜストレージはハマりやすいのか
コンテナ環境に限らず、一般的にストレージはハマりやすいシステムコンポーネントです。データを格納するだけのものがなぜハマりやすいのでしょうか。
第一の理由は、少なからずストレージを検討する時間が充分でないケースがあることです。
ストレージは大抵、システム検討において最後の方の段階で考えられます。これ自体は自然なことで、ビジネスパフォーマンスに直結するアプリケーションのレイヤーから、MW、OS、サーバーHW…と順番に降りて検討するのはある種の定跡です。ストレージへの要件は上の層にあるコンポーネントの要求が積み重なって出てくるので、最後にストレージの検討になるのは仕方ないことですが、問題はその時に充分な時間がない事です。
データを保管する物置なんだから簡単に決められるでしょ、と思っていたら痛い目を見ます。ストレージだって単にデータを保管するだけの簡単なものではありません。これが第二の理由です。
ストレージは思っている以上に、考慮すべき要素が多いものです。ブロック・ファイル・オブジェクトの種類はもちろん、接続インターフェースとプロトコル、冗長化の方法、容量、性能、デバイスの種類、コスト…とにかくまあ、たくさんあります。
厄介な(そして、面白い)ことに、これらの要素は独立ではなく依存関係があります。
例えば10PBのストレージが必要だという場合、これだけ大容量だとかなりの台数のサーバーやクライアントから共用することになるでしょうから、ブロックではなくファイルかオブジェクトになるでしょう。また、スケールアップでこの容量はほぼ不可能なので、スケールアウトの分散型ストレージになるでしょう。まず、分散ファイルシステムと分散オブジェクトストアのどちらが望ましいか？を決めなくてはなりません。
また具体的な構成を決める段階でも、コストを考えるとデバイスはHDDを使うことが得策でしょうし、RAID1のようなミラーリング/レプリケーションだと容量効率が悪いのでRAID6やErasure Codingを使うほうがコスト的に良さそうです。HDDのErasure CodingとなるとIOPSやレイテンシは期待できないですが、用途としてそれでも問題ないか…？などなど、ドミノのように次々と繋がってきます。
このあたりの繋がりは、ストレージに明るくない人にとっては結構つらいところがあると思います。なるべく早い段階からストレージに明るい人やベンダーを巻き込んで検討をする方がよいと思います。
クラウドネイティブとストレージ
クラウドネイティブの考えは人によって三々五々違うでしょうが、プラットフォームを問わずにその場その場のリソースでダイナミックにアプリケーションを開発&稼働させるという観点では、そもそもストレージはクラウドネイティブと本質的に相容れにくいものと個人的には考えます。
あらゆるプラットフォームにあるアプリケーションから等しくデータにアクセスできるストレージは、クラウドネイティブのコンセプトに合致すると思います。 しかし相互接続性や性能やセキュリティなどの様々な観点から、全てのデータをこのようなストレージに入れることは事実上できません。どうしてもデータとデータを使うアプリケーションの特性上、ストレージは局所性を持つことを否めない、これが本質的に相容れにくいと考える理由です。
クラウドネイティブストレージって？
本質的に相容れにくいのに、クラウドネイティブストレージって何だ？と思いますよね。
何をもってクラウドネイティブストレージなのかの定義は正直ハッキリとは分からないし、言ったもん勝ちみたいな雰囲気も感じます。
少なくともクラウドネイティブな開発手法や基盤で使える必要はありそうなので、コンテナ環境で永続ストレージとして使える事は求められそうです。
しかしそれ以上に何を備えるべきかは考え方によって違うと思います。
これは一つの主張ですが、Red Hat OpenShift Container StorageおよびRook-Cephは、
- パブリッククラウドでもオンプレでもプラットフォームを問わず全く同じストレージシステムとして利用でき、
- 無停止で容易にアップデートおよびスケールでき、
- 全ての操作がAPIで行え、
- 他のリソースと同様に管理でき、
- 継続的に利用できる(=可用性が高い)
ような特徴があります。これはクラウドネイティブな環境で使われるストレージにはこういう性質が必要だという主張です。
これが絶対というわけではもちろんなく、あくまで一つの答えであり、参考です。
もっとユーザーさん自身にしっくりする主張やストレージがあるかもしれませんし、これから生まれてくるかもしれません。
ご自身の環境にしっくりくるストレージを追究する事が重要ですので、継続的にストレージ動向をチェックしてもらえればと思います。
ストレージを生業にする者としての思い
今年も少なくないシステムトラブルのニュースがありました。そのうちいくつかはストレージが原因のものもありました。
これはインフラ全般的に言える事かもしれませんが、ストレージは悪目立ちしがちなコンポーネントです。データが新たな企業活動の資源だと言われて久しいながら、そのデータを預かるストレージが企業や組織体のパフォーマンスに直結する事は少なく、花形的な見え方で目立つことはほぼありません。
その割に簡単ではなく、僅かなミスが命取りになる修羅の世界と思われるかもしれません。
しかし反対の見方をすれば、ストレージほど安定稼働が求められているものは無いと思いますし、どんなシステムでもストレージには何かしら課題を抱えているもので、いわば最も銀の弾丸が求められている要素のひとつだと思います。
だからこそ毎年毎年新しいストレージ技術が研究開発され、大量のストレージスタートアップが生まれるのだと。
ストレージは世界中から求められている技術で、かつ進化し続ける奥が深い世界です。だからこそ、ストレージはつらいことも多いけど、来年も再来年もストレージで食って行こうと思うし、ストレージが好きだし面白いなあと思います。
というわけで、最後はやけにエモい話でしたが、今回はここまで。
それでは皆さん、良いお年を。
