Amazon S3（いわゆるオブジェクトストレージ）をファイルシステムとしてマウントする、という手法について、これまでも非公式にはいくつかの方法があった。これができるとかなり便利だ。Linuxで例えるなら、/S3というマウントポイントを作ってオブジェクトストレージのバケットをマウントする。その下が容量制限なしの使い放題となる。
一般的なローカルファイルシステムだと、確実に容量制限があるし、制限に達することが認められないシステムにおいては余裕をもって容量確保するのが鉄則だ。使っていないのにお金を取られることになるので、もったいないな、という実感はある。しかし将来的にはデータは増える方向にしか行かないので、容量を多めに確保してお金を支払う。そんなジレンマにぶち当たる人は多いはずだ。オブジェクトストレージのマウントはその問題を華麗に解決できる。
それで私も、マウントする設計を何度かやっている。確かに便利だ。便利なポイントは上に書いたとおりだ。
ここからが本当に伝えたいことで、この構成には落とし穴がある。それは、ディスクの読み書きについて、結局はHTTPSパケットにしてS3とやり取りをしなければいけない作りにある。
アプリケーションからI/OリクエストをOSが受領したあと、ソフトウェアにてHTTPSパケットに翻訳し、S3と通信することになる。したがって入出力が発生するたびにCPUリソースを使う。たくさんの入出力をだらだらと行うプログラムだと、常にCPUがS3とのやりとりのために利用されることになる。
ローカルストレージの場合は、I/O WAITの場合はCPUは休むものなんだけど、S3とのやり取りの場合はCPUが使われるのでI/O WAITの高さとCPUリソースの利用が同時に高くなるという現象が見られる。まあ作り的には仕方ないよね、と思いつつもインフラ運用をしている身からすると、ああミッションクリティカルなシステムにはこの方式は無理だな、と思った。CPUが高い状態というのは胃に悪いものだ。
もしバックアップ用途として使うとしても、一度バックアップサーバーにファイルを送ってからS3に吸い上げるような仕組みのほうが良い。本番のWebサーバーやDBサーバーなどでS3を直接マウントし、バックアップを直接保管するような仕組みにすると、バックアップ開始時点でCPU使用率がぐんと上がり、なんだなんだと確認すると実は、オブジェクトストレージを使用しているときに起こっていた、なんてことを数度経験した。
便利なものではあるんだけど。
また、大きな1つのファイルを送信・受信する、みたいなことはすごく向いている。セッションを１つ作り、ずっと送信・受信し続けるから、一度セッションを作ってしまえば結構スピードは出たりする。問題は1Kバイトに満たないようなファイルをたくさん受信・送信するとき。毎回セッションを作るので、送受信開始のタイミングでどうしても遅くなる。それが何百、何千ファイルもあると、遅くて使えない、みたいなことも経験した。これはWindowsのファイル共有でも似たようなことは感じるけれど。tarなど1つのファイルにまとめてからオブジェクトストレージに送ったほうが幸せになれる。
今回は結構専門的な話で、あまり多くの人には参考にならないと思うが、何でもオブジェクトストレージをマウントすれば解決すると思われると困るのでこの記事を残しておきたい。適材適所であり使用シーンは限られること。本番系で直接マウントして使わないこと。バックアップ用途に切り離して使うには便利なこと。これらが重要である。
