こんにちは。

Google Cloud 上ではオブジェクトストレージとして Cloud Storage が提供されています。
Cloud Storage は下記の特徴をもつ優れたストレージですが、トレードオフとしてアクセス速度がネックとなりがちでした。
・ 可用性が高い(99.99%)
・ データを書き込む前に常に暗号化
・ 安価に大容量を保管できる

今回、Google Cloud Next ’24 で「Cloud Storage FUSE Read Cache」が一般提供( GA )となったことを受け、アクセス速度がどのくらい向上できるのか、調査してみたいと思います。

「Cloud Storage FUSE Read Cache」は、ファイルシステムのように Cloud Storage をマウントし、ファイルを扱う際に「読み取りキャッシュ」を利用してレスポンスの改善を図る仕組みです。

一般的にキャッシュは、速度の違うレイヤ間で緩衝材として働き、最終的な遅延を防ぐアーキテクチャの一つで、CPU コアの L1 ／L2 キャッシュ、 エンタープライズクラスの物理ストレージ機器が搭載するキャッシュ機能、Web サーバのコンテンツキャッシュ等が有名ですね。

※ 参考までにベースとなっている技術／情報について簡単に記載します。

• FUSE ：

FileSystem in Userspaceの略で、特別な権限を必要とせずファイルシステムをマウントする機能

• Cloud Storage FUSE：

FUSE を利用して、Cloud Storage バケットをローカル ファイル システムとしてマウントして透過的にアクセスできるようにする FUSE アダプタ

• Cloud Storage FUSE Read Cache：

「Cloud Storage FUSE」に Read Cache 機能を搭載

今回は「キャッシュあり／キャッシュなし」の2パターンで、パフォーマンスの測定を行いました。

• 構成概要図

• Cloud Storage FUSE キャッシュ設定

file-cache:

 max-size-mb: -1

 cache-file-for-range-read: false



metadata-cache:

 stat-cache-max-size-mb: 32

 ttl-secs: 3600

 type-cache-max-size-mb: 4



cache-dir: /mnt/cache_dir

• 計測ツール

fio (Flexible I/O tester) 3.19

主な設定

bs=4k

numjobs=16

runtime=10

• 計測方針

今回は、「ストレージの限界速度」より「通常のファイル利用」を想定した計測を目的として、ブロックサイズは「4k」とし、ファイルサイズや I/O パターンについても下記を指定しました。

• 仮説

測定にあたり、下記の仮説をたてて検証を行います。

• read は「キャッシュあり」の方が早い
• random read は「キャッシュあり」の方が早い
• Cloud Storage FUSE は小さいファイルの扱いが苦手
• write／Random Write は 「キャッシュ有無」にかかわらず、ほぼ同程度

下記の手順で、環境を準備し、測定を実施しました。

① 検証用の Compute Engine／Cloud Storage バケット を作成
② 必要なツールをインストール

sudo tee /etc/yum.repos.d/gcsfuse.repo > /dev/null <

③ （構成２のみ）ローカルSSDをフォーマット(ext4)し、インスタンスにマウント

sudo fdisk /dev/sdb

sudo mkfs.ext4 /dev/sdb1

sudo mount -o discard,defaults /dev/sdb1 /mnt/cache_dir

④ （構成２のみ）Cloud Storage FUSEの設定ファイルを作成

sudo tee /etc/fuse.config > /dev/null <

⑤ Cloud Storage FUSE にて、検証サーバに Cloud Storage をマウント

sudo mkdir -p /mnt/target_dir

sudo gcsfuse --config-file /etc/fuse.conf (Cloud Storage バケット名) /mnt/target_dir

⑥ パフォーマンスの測定
ファイルサイズに応じて、パフォーマンスを測定。
※ 試験項目に応じて、I/O パターン (-rw オプション) を 「read、write、random read、random write」に適宜変更する。

# 10KB

sudo fio -filename=/mnt/target_dir/test10k -direct=1 -rw=read -bs=4k -size=10K -numjobs=16 -runtime=10 -group_reporting -name=file1-1-1



# 200MB

sudo fio -filename=/mnt/target_dir/test200m -direct=1 -rw=read -bs=4k -size=200M -numjobs=16 -runtime=10 -group_reporting -name=file2-1-1



# 1GB

sudo fio -filename=/mnt/target_dir/test1g -direct=1 -rw=read -bs=4k -size=1G -numjobs=16 -runtime=10 -group_reporting -name=file3-1-1

測定ツール (fio) による測定にて以下のような結果となりました。
※ インスタンス性能や、測定時間帯などによって変動がある可能性があるため、本結果がパフォーマンスを保証するものではありません。

• 計測項目

• Read

• Write

• Random Read

• Random Write

• 考察

測定結果を事前に立てた仮説と比較すると、ほぼ想定通りの結果を得ることができました。

また、パフォーマンスが発揮できると記載がある「200MB、Read」については、かなり良い数値がでているのではないかと思います。

今回は「Cloud Storage FUSE Read Cache」の検証を行いました。
読み込み／書き込みにてパフォーマンス特性の違う「Cloud Storage / Cloud Storage FUSE」ですが、
キャッシュを利用することによって、メリットを生かしたシステムアーキテクチャも検討できるのではないかなと思います。

・ 同じファイルを何回も読み込む特性があるシステムには、かなり効果的。
・ 逆に、書き込みが多いシステムはボトルネックとなる可能性が高い。
・ 費用面は「キャッシュディスク費用」と「アクセス頻度 × Cloud Storage オペレーション費用」の比較が必要。
・ キャッシュディスクは、ネットワークを経由しない「ローカルSSD」や「インメモリ」がおすすめです。
・ ディスクへのアクセス性能はインスタンスタイプを向上することによって、改善する可能性もあります。

日々新しい機能が開発／提供されていくのがクラウド環境のいいところですね。
新しく GA されたキャッシュ機能を是非ご活用ください。

最後まで読んでいただき、ありがとうございました！

当社システムサポートは、Google Cloud の導入・移行・運営支援を行っています。
クラウド移行含めた最適なシステム環境構築のご相談は、以下よりお願いいたします！