
関連するソリューション

ID-Cross/クラウドサービス
サイバー・セキュリティ・ソリューション部
テクニカルスペシャリスト 松岡 政之 
前回、私が担当したコラムから3か月が経ち、年の瀬となりました。3か月前はまだ暑かったのに、今ではすっかり冬めいてきました。
東京の最低気温もいよいよ0度が見えてきた今日この頃、皆様いかがお過ごしでしょうか。私はというと自室は、暖房をつけずパソコンの排熱でぬくぬくと暮らしております。
はじめに
それでは本題です。今回は久しぶりにAWSの話題です。皆様は、S3を使用していますでしょうか。ファイルの長期保管や一時置き場、ウェブサイトのホスティング等、他のストレージサービスと比較して安価で用途も広いので、使用されている方も多いのではないでしょうか。
先日、AWSのニュースリリースを眺めていたら、S3に関して同じサービスが立て続けにアップデートされているのが目に留まりました。
そのサービスは、Amazon S3 Express One Zoneというものです。Amazon S3は知っているけど、Express One Zoneって何ぞや?という方は多いのではないでしょうか。
というわけで、初めにAmazon S3 Express One Zone(以下、Express One Zone)について軽くご紹介します。
Amazon S3 Express One Zoneとは
Express One ZoneはS3のストレージクラスの一つで、2023年11月28日に発表された比較的新しいサービスです。発表の詳細は「Amazon S3 Express One Zone ストレージクラスの発表」をご覧ください。簡単にご紹介させていただくと、ニュースリリースにも記載されているとおり、ほかのストレージクラスと比較して、特にパフォーマンスを重視しています。また、レイテンシの低いストレージクラスとなります。
料金的な面でスタンダードストレージクラスと比較すると、リクエスト数当たりの単価が安く、使用しているストレージ容量当たりの単価も安いです。
「それならスタンダードを選ぶ理由がなくなるのでは?」と思う方もいるかもしれませんが、名前にOne Zoneとあるとおり、一つのAZしか使用できないため耐障害性はスタンダードクラスには劣ります。
そのため、用途としては、データを安価に長期保管するような用途ではなく、頻繁に読み書きを行う、一時的なデータ置き場に向いており、Amazon EFSやAmazon FSx for Lustreとも比較されるようなサービスかと思います。
また、ダウンタイムが問題となるシステムであり、Express One Zoneを利用する場合、AZ障害時の対応も考慮して構成を考える必要があります。
さらに、Express One Zoneの発表と同時にMountpoint for Amazon S3への対応も発表されており、Express One Zoneの主な利用方法の一つとして、Mountpoint for Amazon S3が公式として想定されていることが見て取れます。
発表の詳細は、「Mountpoint for Amazon S3 が S3 Express One Zone ストレージクラスのサポートを開始」をご確認ください。
Mountpoint for Amazon S3の活用
さて、今度はMountpoint for Amazon S3とは何ぞや。という方がいらっしゃるかもしれません。Mountpoint for Amazon S3は、2023年8月23日に一般公開された、S3への高スループットでのアクセスを目的としており、Linuxのファイルシステムに直接S3バケットをマウントして利用できるソリューションです。
POSIX完全準拠ではない等いくつか注意点もありますが、今回詳細は割愛させて頂きます。
気になる方は「Mountpoint for Amazon S3 – Generally Available and Ready for Production Workloads」をご確認ください。
というわけで、今回はMountpoint for Amazon S3を使用し、EC2からExpress One Zoneを検証していきたいと思います。
また、Express One ZoneをMountpoint for Amazon S3のキャッシュとして使用できる機能が、2024年11月21日に発表されましたので、そちらも併せて検証していきます。
リリースの詳細は、「Mountpoint for Amazon S3 が高パフォーマンス共有キャッシュのサポートを開始」をご確認ください。
Mountpoint for Amazon S3を実際に触ってみた
Express One Zoneバケットの作成
それでは、実際にMountpoint for Amazon S3を使用して、Express One ZoneをEC2のAmazon Linuxからマウントしていきます。S3のコンソールにアクセスしてみると、以前にはなかった「ディレクトリバケット」というタブが増えています。こちらのタブに切り替えると、Express One Zoneのみのバケットリストが表示されます。

それでは、バケットを作成していきましょう。
バケットの作成画面を開くと、「バケットタイプ」から「ディレクトリ」を選択します。
次に、通常のバケットにはない設定ですが「アベイラビリティーゾーン」を選択します。2024年12月現在、東京リージョンでは「apne1-az4 (ap-northeast-1a)」と「apne1-az1 (ap-northeast-1c)」の二つが選択できます。
そして、「私は、アベイラビリティーゾーンに障害が発生した場合、データが利用できなくなったり、失われたりする可能性があることを認識しています。」にチェックを入れます。ちょっと怖いですね。

次に、バケット名を指定しますが、汎用バケットとは異なり、実際に作成されるバケット名は、ここで入力した「ベース名」に「--[AZ名]--x-s3」がサフィックスとして追加されます。
例えば、ベース名に「ex-bucket-name」と入力し、アベイラビリティーゾーンで「apne1-az4」を選んでいた場合、「ex-bucket-name--apne1-az4--x-s3」がバケット名となります。

続けて、ACLとパブリックアクセスブロックについては、デフォルトから変更できないので、設定できるのは暗号化タイプのみとなります。今回は検証のためSSE-S3を選択します。

以上で、Express One Zoneのバケットを作成することができます。作成されたバケットは「ディレクトリバケット」のリストに表示されます。
Mountpoint for S3を用いたExpress One Zoneバケットのマウント
続いて、先ほど作成したバケットをEC2上のAmazon Linuxからマウントしてみます。Mountpoint for Amazon S3はAmazon Linuxとはいえデフォルトでは入っていないため、以下のようにrpmを取得してインストールする必要があります。$ wget https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.rpm
$ sudo yum install -y ./mount-s3.rpm
インストールしたら接続してみましょう。
今回は、ローカルにexpressというディレクトリを作成し、そこにバケットをマウントします。
ちなみに、通常ではmount-s3を介し、バケット上のファイルの削除や上書きを行うことはできません。削除を行う場合は、--allow-delete。上書きを行う場合は--allow-overwriteのオプションが必要となります。
また、キャッシュを利用する際は、ローカルキャッシュの場合は--cache [ローカルパス]。Express One Zoneをキャッシュにする場合は--cache-xz [バケット名]のオプションを指定できます。
$ mount-s3 --allow-delete --allow-overwrite s3-test-XXXXXXXXXXXX--apne1-az4--x-s3 express/
マウントできたら、試しにファイルを作成してみます。lsコマンドで確認してみると、問題なく作成されていることが分かります。
$ touch express/test.txt
$ ls -l touch express/test.txt
total 0
-rw-r--r--. 1 ssm-user ssm-user 0 Dec 18 09:14 test.txt
AWSマネジメントコンソールから確認すると、こちらからも作成したファイルを確認することができます。
さらに、ストレージクラスの記載からもS3 Express One Zoneであることが確認できます。

バフォーマンス検証
ここまでで、Mountpoint for Amazon S3を使用してExpress One Zoneの利用を始めることができました。ここからは軽くパフォーマンスを検証してみようと思います。
実は、Mountpoint-S3公式のGitHubリポジトリにExpress One Zoneを含むベンチマークの結果が公開されております。しかし、新しいものはやはり自分で体感することで良さを実感することができるかと思います。
検証方法と環境
というわけで、今回はddコマンドを使用して、簡易にですが以下の5パターンのディレクトリのパフォーマンスを見ていきたいと思います。EBSに関しては今回、直接の目的ではないため参考程度の比較とさせていただきます。
No. | 対象 | 備考 |
---|---|---|
1 | Mountpoint for S3でS3 Standardをマウントしたディレクトリ | 後述の検証結果では「Standard」と表記 |
2 | Mountpoint for S3でS3 Express One Zoneをマウントしたディレクトリ | 後述の検証結果では「Express One Zone」と表記 |
3 | Mountpoint for S3でExpress One Zoneをキャッシュとして指定してS3 Standardをマウントしたディレクトリ | 後述の検証結果では「Standard(Express One Zoneキャッシュ)」と表記 |
4 | Mountpoint for S3でEBS上のディレクトリをキャッシュとして指定してS3 Standardをマウントしたディレクトリ | EBSはEC2のローカル上にマウント 後述の検証結果では「Standard(EBSキャッシュ)」と表記 |
5 | EBS上のディレクトリ | EBSはEC2のローカル上にマウント 後述の検証結果では「EBS」と表記 |
検証を行うインスタンスは以下のとおりです。
インスタンスの性能がボトルネックにならないよう、インスタンスタイプは少し大きめのものを採用していますが、S3側の検証が主なのでEBSについては最低限としています。
項目名 | 設定 | |
---|---|---|
OS | Amazon Linux 2023 | |
インスタンスタイプ | t3.xlarge(4vCPU/16GiB RAM) | |
EBS | サイズ | 10GiB |
ボリュームタイプ | gp3 | |
IOPS | 3000 | |
スループット | 125MB/s | |
暗号化 | なし |
また、検証方法としては以下の4パターンで行います。
- 乱数により生成された100MiBのファイルを[マウント先ディレクトリパス]に10回書き込む
$ for i in {1..10} ; do dd if=/dev/urandom of=/[マウント先ディレクトリパス]/100M_data bs=1M count=100 oflag=direct 2>&1 | grep 'B/s' ; done
- [マウント先ディレクトリパス]から10回100MiBのファイルを読み込む
$ for i in {1..10} ; do dd if=/[マウント先ディレクトリパス]/100M_data of=/dev/null bs=1M count=100 iflag=direct 2>&1 | grep 'B/s' ; done
- 乱数により生成された4KiBのファイルを[マウント先ディレクトリパス]に10回書き込む
$ for i in {1..10} ; do dd if=/dev/urandom of=/[マウント先ディレクトリパス]/4k_data bs=4k count=1 oflag=direct 2>&1 | grep 'B/s' ; done
- [マウント先ディレクトリパス]から10回4KiBのファイルを読み込む
$ for i in {1..10} ; do dd if=/[マウント先ディレクトリパス]/4k_data of=/dev/null bs=4k count=1 iflag=direct 2>&1 | grep 'B/s' ; done
検証結果と考察
それでは、検証結果を見ていきます。1. 書き込み(100MiB)
まずは、100MiB/sの書き込みを10回行った結果を見ていきます。
ここでは、Express One Zoneの速さが目を引きます。Standardと比較しても2倍程の速度が出ています。
このことから、単純に書き込み速度がStandardより速いことがわかります。EBSについてはスループットが125MB/sなので妥当なところでしょう。
一方で、Mountpoint for S3のキャッシュについては、書き込みでは効かないため、Standardとほとんど変わりません。

2. 読み取り(100MiB)
次に、100MiB/sの読み取りを10回行った結果を見ていきます。
こちらは、EBS(1回目)とStandard(EBSキャッシュ)(2回目以降)が速いため、グラフを見やすくするために別で作成しています。
こちらも、Express One ZoneがStandardと比較して2倍程の速度が出ています。
単純に読み取り速度もStandardより速いことが分かります。
EBSについては、1回目が速く、それ以降は速度が落ち込んでいます。
これは想定になりますが、前の読み取りが終わる前に、次の読み取りが始まってしまったことが原因なのかもしれません。なぜなら、1ループごとにsleepを入れてインターバルを設けることで、1回目と同等の速度になることが確認できているためです。
一方で、Mountpoint for S3のキャッシュについては、落ち込み具合に差があるものの、1回目が落ち込んでその後は速度が上がっている様子が見て取れます。
1回目は、おそらくキャッシュファイルの生成に時間がかかっていると思われます。
Express One Zoneをキャッシュとして使用した場合の速度については、Express One Zoneから直接読み取った場合と近い速度が出るのではないかと想定していました。
しかし、想定に反してかなり落ちており、Standardとあまり変わらない程度でした。
これは私の想像ですが、キャッシュからの読み取り単位が小さいファイルに分割されており、Express One Zoneから直接読み取った場合より、レイテンシの影響を受けてしまったのかもしれません。
Express One Zoneは関係ないですが、EBSに直接書き込んだ場合とMountpoint for S3のキャッシュとしてEBSを指定した場合を比較すると、キャッシュとしてEBSを利用した場合、2回目以降の書き込みがEBSに直接書き込んだ場合よりも速度が出ていることが分かります。
Mountpoint for S3のアーキテクチャを紐解いたわけではないので、個人的な想像にはなりますが、キャッシュからの読み取りより、複数に分割されたデータを並列化して読み込むことで、EBSのIOPSをより効率的に活用できたのかもしれません。


3. 書き込み(4KiB)
続けて、4KiB/sの書き込みを10回行った結果を見ていきます。
こちらもEBSが突出して速いため、グラフを見やすくするために別に作成しています。
EBSについてはIOPSが3000なので、これだけの速度が出ていることは想定の範囲内です。それよりもやはり、Express One ZoneがStandardと比較して10倍程の速度が出ており、その速さが目を引きます。
100MiBの書き込み時と比較すると、さらに差が開いています。書き込み時にかかるレイテンシが、Express One Zoneではかなり小さく抑えられていることが分かります。
また、Mountpoint for S3のキャッシュについては、100MiBの場合と同様、Standardとほとんど変わりません。


4. 読み取り(4KiB)
最後に4KiB/sの読み取りを10回行った結果を見ていきます。
こちらもEBSとStandard(EBSキャッシュ)が突出して速いため、グラフを見やすくするために別にしています。
まず、EBSが速いことは当然とし、Express One ZoneがStandardと比較して、4倍程の速度が出ています。書き込み時と同様に読み取りの場合も、100MiBの時と比較して差が開いており、読み取り時にかかるレイテンシもExpress One Zoneではかなり小さく抑えられていることが分かります。
一方で、Mountpoint for S3のキャッシュとして、Express One Zoneを指定した場合については、1回目がぐっと落ち込み、その後は速度が出ていることが見て取れます。
こちらは、100MiBの時とは異なり、Express One Zoneから直接読み取りを行った場合とほぼ同じ速度が出ています。こちらは、元のファイルが小さいのでキャッシュでも、それ以上はあまり分割されなかったのかもしれません。
また、Express One Zoneとは関係なく、EBSに直接書き込んだ場合とMountpoint for S3のキャッシュとしてEBSを指定した場合では、こちらも100MiBの時と同様の傾向が見て取れました。


まとめ
今回はMountpoint for S3を使ってS3 Express One Zoneの様々な使い方のパフォーマンスを検証してきました。その結果、Express One ZoneはStandardと比較して、読み書きの速度が2倍程速く、レイテンシはそれ以上に低減されていることが分かりました。
今まで、他のサービスでファイルを処理する際に、ファイルの一時置き場やサービス間でのファイル連携にS3を使用していた場合、Express One Zoneを採用することでパフォーマンスが向上する可能性があります。
実際に、頻繁にファイルの読み書きが発生するとS3ではそのレイテンシが気になり、他のストレージサービスを採用していた場面もあったかもしれません。
しかし、Express One ZoneはS3というだけあってコストの面でも非常に優れており、Express One Zoneで十分なパフォーマンスが得られるかは用途ごとに検討が必要ですが、コストパフォーマンスの面でも大きなメリットを得られるかもしれません。
また、Mountpoint for S3のキャッシュとしてExpress One Zoneを使用した場合は、読み取るファイルのサイズによって得られる効果が大きく異なります。
また、用途によっては大きなメリットを得られる可能性があることが分かりました。
もちろんEBSをキャッシュとして使用できるのであれば、得られるパフォーマンスはそちらの方が大きいですが、S3は実際に使用している容量に対してのみコストがかかるのに対して、EBSは実際に使用していなくてもプロビジョニングした容量に対し、コストがかかります。
実際に使用する容量を予測しにくいキャッシュ用途のために、EBSを余分に確保しておくことのコストと、それによって得られるパフォーマンスの向上を比較検討することは重要です。
どちらにメリットがあるかは、具体的な用途やシステムの要件によって異なるため、それぞれのケースごとに慎重に考える必要があります。(実際には、S3ではリクエストごとの料金もかかるので単純な比較は難しいです…)
S3 Express One Zone では、AZレベルでの冗長性が確保されていないというデメリットはありますが、このストレージクラスの登場によって選択肢が広がったことは素直に喜ばしいです。
皆様も、S3では遅いけど他のストレージサービスは高いと思っている案件があれば、S3 Express One Zoneを検討してみてはいかがでしょうか。
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。