TL;DR
- KubernetesでRaw Block（Raw Deviceともいう） VolumeがBeta版になった。
- Raw Block(Device)とは何なのか。メリットは？
- Kubernetesから見たRaw Block対応の意味
KubernetesのRaw Block VolumeサポートがBetaに
去る3/8、KubernetesのRaw Block Volume サポートがBetaとなったことが発表されました。
#Kubernetes v1.13 moves raw block volume support to beta, allowing persistent volumes to be exposed inside containers as a block device instead of as a mounted file system. More on the blog ⬇️⬇️https://t.co/B8RsRWZWS1
— Kubernetes (@kubernetesio) 2019年3月8日
私（@tzkb）は「Kubernetesでデータベースを動かそう」なる活動をしていますので、今回の一報に歓喜したのですが、DBでもRawデバイスの利用は減ってきています。そこで歴史的な背景を振り返り、今KubernetesがRaw Block Volumeをサポートする意味を再考したいと思います。
歴史から振り返るRaw Block(Device)の意義
今回のKubernes公式のアナウンスをまとめると、以下が書かれています。
- Raw Block Volumeはファイルシステムのオーバヘッドを回避する選択肢であること
- ユースケースとしてデータベースとSDS(Software Defined Storage)を想定していること
まず、1.についてオーバーヘッドとは何のことなのかを見ていきましょう。
ファイルシステムのオーバーヘッドとは何か？
Why add raw block volumes to kubernetes? の冒頭には以下のように書かれています。
There are some specialized applications that require direct access to a block device because, for example, the file system layer introduces unneeded overhead.
たとえば、ファイルシステム層に不要なオーバーヘッドが発生するため、ブロックデバイスに直接アクセスする必要がある特殊なアプリケーションがいくつかあります。
ファイルシステムの利用で発生するオーバーヘッドといわれて私が思いつくのは、
- ジャーナリングファイルシステムによるもの
- カーネルキャッシュによるもの
の2つです。
ジャーナリングファイルシステムのオーバーヘッド
私がデータベースをさわり始めた約20年前には商用UNIXにデータベースを乗せることが一般的で、Oracle（当時はOracle8の頃）利用時には、UNIXが持つジャーナリングファイルシステムを経由せずに、RAWデバイスにデータファイルを置くという構成がベストプラクティスでした。
その理由として以下があげられていたと記憶しています。
- そもそもDBレイヤでログ先行書込みがされており、ファイルシステムでジャーナルを書く必要はない
- ジャーナルログの書き出しでIOパフォーマンスが落ちる
当時のOracleはRAWデバイスを扱うことが出来たので、主に性能上の観点からRAWデバイスを選ぶというのは妥当な選択肢でした。
しかし、RAWデバイスの扱いは非常に煩雑です。そのため、利便性を下げてまでRDBMSでRAWデバイスを使う理由は今はない、というのが個人的な見解です。Oracle12c以降、RAWデバイスは非サポートになっていますし、他のOSSデータベースでも、私の知る限りサポートしているものはありません。
※ちなみにジャーナリングファイルシステムって何？という方はこちらなども参考にどうぞ。
カーネルキャッシュのオーバーヘッド
もう一つのカーネルキャッシュについては、2010年頃にPostgreSQLのIOを説明するために記述した図を載せておきます。
この図で言いたかったのは、ファイルシステム経由のIOはカーネルキャッシュ（図中ではページキャッシュ）を使う、ということです。データベースではこれが冗長になります。つまり、DBサーバにおいて重要な物理メモリが、データバッファ以外にカーネルキャッシュとしても使われてしまうのです。それらにバッファリングされるデータが同じものになってしまうことも良く見られます。
しかし、このメモリ部分の冗長性も、昨今のLinuxではDirectIOの対応により回避できるようにとなっています。MySQLではinnodb_flush_methodによりDirectIOを指定することができます。PostgreSQLでは現時点でこれに対応するパラメータはありません。
※ここまでのRAW、DirectIOの関係をまとめた記事はこちらが分かりやすいです。
KubernetesにおけるRaw Block Volumeの利用シーン
歴史的な話が長くなりました。
ここまで見てくると、データベースでRAWデバイスが必要とされてきた大きな問題は解消されており、OracleやMySQL、PostgreSQLが対応を打ち出していない点からDBレイヤでは今後もサポートする必要がない、というのが一般認識になりつつあるように見えます。
では、KubernetesにおけるRaw Block Volumeの利用シーンを上の2点以外で考えてみましょう。
Open-Channel SSDの紹介
2019年のSNIA-jのトレンドセミナーでも紹介されたOpen-Channel SSDというものがあります。
※この辺りを見るとプロジェクト概要が載っています。
これはSSD側のコントローラでやっていた処理をSW化して、ホスト側に持っていこうというプロジェクトです。そうすることで、
- IOの並列度をアプリケーション側で細かく管理できる
- SSDのライトアンプリフィケーションをアプリケーション側で管理することで、IOの安定化が可能
- SSDのコストが低くなる（コントローラがpoorで良い）
というメリットがあります。
RocksDBのOpen-Channel SSD対応
では、このOpen-Channel SSDをデータベースで利用している例を紹介しましょう。残念ながらRDBMSでの事例は見つかりませんでしたが、いわゆるNoSQLと呼ばれるRocksDBというものが見つかりました。
資料はこちらにありますが、非常に細かくIOをアプリケーション（ここではRocksDB）から制御している様子が見てとれます。
上記のRocksDBで見られるように、データベースのIO最適化をハードウェアに近いレイヤで行うというの考え方は、OracleのExadataやAmazonのAuroraでも見られます。
さらにMySQLではストレージエンジンがPlaggableであり、PostgreSQLでもPlaggable Storageへの対応が議論されています。そのことから、RocksDBのOpen-Channel SSD対応のような形がストレージエンジンの一つの形として今後登場してくる可能性があります。
KubernetesレイヤでのIO最適化が可能になる（かもしれない）
RocksDBでのOpen-channel SSDのように、最新デバイスのIO性能を最大限に引き出すためにファイルシステムではなくRaw Blockとして扱うケースが今後出てくるでしょう。
そして、それらの実装を"そのまま"Kubernetes上で動かすというワークロードで、今回のRaw Block Volumeサポートが活躍してくれるのではないか、というのが現時点での私の見解です。
今、巷ではNVMe-SSDや不揮発性メモリと呼ばれるようなIOデバイスの進化が著しいですが、それらを活かすために、DBMSだけでなくCloud Native Storageでもハードウェア層まで踏み込んだ実装の形が見られるようになる、と私は考えています。
まとめ
「Kubernetesはクラウド時代のOSになる」と言われたのは2017年だったと思いますが、今回のRaw Block VolumeサポートはこのOSとしての可能性を拡げる機能になるでしょう。
今回は書くことができませんでしたが、CSIの状況も合わせてウォッチしながら、Rawデバイスとしてのボリューム利用について今後も情報を集めていきたいと思います。