こんにちは。rakumoコンサルティング部の末木(id:ksueki)です。
本記事ではGoogleから提供されているCloud Storage FUSE(GCS FUSE)について扱います。 GCS FUSEはオープンソース(Apache License)のFuseアダプタで、 これを利用することでGoogle Cloud Storage(GCS)のバケットをLinuxもしくはOS X上でファイルシステムとしてマウントすることが可能です。
今回はGCS FUSEをGCPリソース上で利用する方法、 またGoogle Compute Engine(GCE)インスタンスでGCSバケットをマウントした環境におけるベンチマークの結果について紹介します。
GCP環境
前述の通り、今回はGCEインスタンスにGCSバケットをマウントする構成を想定しました。 以下にGCE・GCSの構成を列挙します。
- GCE
- OS: Debian GNU/Linux 8 (jessie)
- マシンタイプ:
f1-micro
(vCPU x 1, メモリ 0.6GB) - ゾーン:
asia-northeast1-a
- GCSバケット
- ストレージクラス:
Regional
- リージョン:
asia-northeast1
- ストレージクラス:
GCS FUSEの導入
Googleによるチュートリアルに沿った形で、GCEにGCS FUSEを導入します。 GCS FUSEはGitHubでホスティングされています。 以下の行程では、Cloud Shellを利用してGCEインスタンス上で作業します。
- gcsfuseのインストール
apt-get
でgcsfuse
をインストールします。
$ export GCSFUSE_REPO=gcsfuse-`lsb_release -c -s` $ echo "deb http://packages.cloud.google.com/apt $GCSFUSE_REPO main" | sudo tee /etc/apt/sources.list.d/gcsfuse.list $ curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - $ sudo apt-get update $ sudo apt-get install gcsfuse
- GCEにGCSバケットをマウント
$ mkdir ${LOCAL_DIR} $ gcsfuse ${BACKET_NAME} ${LOCAL_DIR}
これでGCS FUSEの導入とGCSバケットのマウントは完了です。
ベンチマーク
さて、構成した環境についてベンチマークを実施しました。 今回はfioというベンチマーカーを利用して、シーケンシャル/ランダム アクセスそれぞれの read/write 処理に関してレイテンシを計測しました。 fioはディレクトリを指定してベンチマークを実行することができます。
以下、ランダムアクセス時のベンチマーク結果です。
read/write | ファイルサイズ | ジョブ数 | 最小レイテンシ /msec | 最大レイテンシ /msec | 平均レイテンシ /msec | 標準偏差 /msec | |
---|---|---|---|---|---|---|---|
1 | read | 1GB | 1 | 21.00 | 451.00 | 102.06 | 84.67 |
2 | read | 1MB | 500 | 60.00 | 1568.00 | 919.47 | 482.98 |
3 | write | 1GB | 1 | 0.00 | 28666.00 | 0.23 | 56.02 |
4 | write | 1MB | 500 | 0.00 | 22359.00 | 142.08 | 1393.01 |
次に、シーケンシャルアクセス時のベンチマーク結果です。
read/write | ファイルサイズ | ジョブ数 | 最小レイテンシ /msec | 最大レイテンシ /msec | 平均レイテンシ /msec | 標準偏差 /msec | |
---|---|---|---|---|---|---|---|
5 | read | 1GB | 1 | 0.00 | 139.30 | 0.01 | 0.37 |
6 | read | 1MB | 500 | 0.00 | 5545.20 | 893.67 | 1641.82 |
7 | write | 1GB | 1 | 0.00 | 28957.00 | 0.24 | 56.70 |
8 | write | 1MB | 500 | 0.00 | 27091.00 | 154.34 | 1484.77 |
まとめ
さて、今回はCloud Storage FUSEを利用してGCSバケットをマウントし、fioを使ってその性能を検証しました。 単純な比較ではありませんが、サイズの大きなファイルのアクセス(一括アクセス)の方が、レイテンシが小さいことがわかりました。 特にシーケンシャルアクセスでは大きな差が出ていることがわかります。 このことに関してはGCS FUSEのドキュメントにも以下のように記載があります。
パフォーマンス: Cloud Storage FUSE のレイテンシは、ローカル ファイル システムよりもはるかに高くなっています。そのため、サイズの小さなファイルを 1 つずつ読み取る / 書き込むと、スループットが低下することがあります。サイズの大きなファイルを使用するか複数のファイルを一括転送することで、スループットは上がりやすくなります。
また、所感としてもwriteの最大レイテンシが非常に大きいという印象を得ました。 NFSを利用した分散ストレージ環境などと比較調査していく必要があるかもしれません。
rakumo コンサルティング部 Tech Blogでは随時GCP関連の情報をお届けしていきます! お楽しみに!
おまけ
ベンチマークに利用したfioの設定ファイルを以下に掲載します。 番号はベンチマーク結果表と照合してください。
[random-read-remote-1gx1] rw=randread size=1g numjobs=1 group_reporting directory=./gcs_cfuse_test/ runtime=600
[random-read-remote-1mx500] rw=randread size=1m numjobs=500 group_reporting directory=./gcs_cfuse_test/ runtime=600
[random-write-remote-1gx1] rw=randwrite size=1g numjobs=1 group_reporting directory=./gcs_cfuse_test/ runtime=600
[random-write-remote-1mx500] rw=randwrite size=1m numjobs=500 group_reporting directory=./gcs_cfuse_test/ runtime=600
[sequencial-read-remote-1gx1] rw=read size=1g numjobs=1 group_reporting directory=./gcs_cfuse_test/ runtime=600
[sequencial-read-remote-1mx500] rw=read size=1m numjobs=500 group_reporting directory=./gcs_cfuse_test/ runtime=600
[seqencial-write-remote-1gx1] rw=write size=1g numjobs=1 group_reporting directory=./gcs_cfuse_test/ runtime=600
[sequencial-write-remote-1mx500] rw=write size=1m numjobs=500 group_reporting directory=./gcs_cfuse_test/ runtime=600