AWS S3 Intelligent Tieringについて調べてみた
目次
- S3 Intelligent Tieringの概要
- S3 Intelligent Tieringが解決していること
- S3 Intelligent Tieringのメリット・デメリット
- 代替技術
- まとめ
1. S3 Intelligent Tieringの概要
S3 Intelligent Tieringとは、S3[1]が提供するストレージクラス[2]の1種。
Amazon S3 Intelligent-Tiering (S3 Intelligent-Tiering) は、パフォーマンスへの影響、取り出し費用、運用上のオーバーヘッドなしに、アクセス頻度に基づいてデータを最も費用対効果の高いアクセス階層に自動的に移動することにより、きめ細かいオブジェクトレベルでストレージコストを自動的に削減できる初めてのクラウドストレージ
https://aws.amazon.com/jp/s3/storage-classes/ より
オーバーヘッド:処理に時間がかかるようになるなど、システムの負荷になるもの
https://www.sophia-it.com/content/オーバーヘッド より
アクセス頻度に応じて、オブジェクト[3]のアクセス階層を移動することで、S3のコストを削減できるストレージクラス。
(オブジェクトのストレージクラスの移動は、後述のルールに従って行われる)
1.1 Intelligent Tieringにおけるアクセス階層とは
Intelligent Tieringにおけるアクセス階層は、5つ存在します。
アクセス階層とは、ストレージクラスに相当する概念です。
<Intelligent Tieringが自動で移動する階層>
高頻度アクセス階層
低頻度アクセス階層
インスタントアクセス階層
<オプションを設定することで使用できる階層>
アーカイブアクセス階層
ディープアーカイブアクセス階層
高頻度アクセス階層
デフォルトのアクセス階層。
オブジェクトがアクセスされている限りは、この階層にオブジェクトが配置される。
低レイテンシー[4]と高スループット[5]のパフォーマンス。
低頻度アクセス階層
オブジェクトが30日連続してアクセスされない場合、低頻度アクセス階層に配置される。
低レイテンシーと高スループットのパフォーマンス。
インスタントアクセス階層
オブジェクトが90日連続でアクセスされない場合、インスタントアクセス階層に配置される。
低レイテンシーと高スループットのパフォーマンス。
アーカイブアクセス階層
オプションとして、90〜730日連続で(自身で調整可能)アクセスがされないオブジェクトをアーカイブアクセス階層に移行することが可能。
S3 Glacier Flexible Retrievalというストレージクラスと同じパフォーマンスの階層。
ディープアーカイブアクセス階層
オプションとして、180〜730日連続で(自身で調整可能)アクセスがされないオブジェクトをディープアーカイブアクセス階層に移行することが可能。
S3 Glacier Deep Archieveというストレージクラスと同じパフォーマンスの階層。
※アーカイブアクセス階層・ディープアーカイブアクセス階層にあるオブジェクト取り出しにかかる時間は、以下。
アーカイブアクセス階層:3~5時間
ディープアーカイブアクセス階層:12時間以内
アクセス後は、高頻度アクセス層に移動される。
イメージ図
2. S3 Intelligent Tieringが解決していること
S3 Intelligent Tieringは、パフォーマンスを落とすことなく、いつそのファイルにアクセス[6]されるか未知のケースで使用されるファイルのストレージ料金を抑えることができます。
アクセスされないのに、低レンテンシーのパフォーマンスが出せるコストのかかるストレージを使用することやアクセスが頻繁に行われるのに、データ取り出しにコストが多くかかるかつレイテンシーが発生するストレージを使用してしまっているケースでかかるコストを回避することができます。
2.1 本当に解決できているのかを試算
Intelligent Tieringが本当に、上記の問題を解決しているかを試算してみます。
今回は、3つのケースで3つのストレージクラスの試算をしてみます。
<比較するケース>
- 各ストレージには、1Mbのファイルが10万件ある(≒100GB)ケースを想定します。
- アクセスがされるケースを以下とします。
1. 1年に1度もアクセスをしないで、ファイルを保存しておくだけのケース
2. 半年に1度(1年に2度)、 全ファイルに対してのアクセスがあるケース(5ヶ月間アクセスせずに6ヶ月目の初日にアクセス)
3. 1ヶ月に1度、全ファイルにアクセスがされるケース
(例としてシンプルにするために、データ転送先はデータ転送料金がかからないcloudfrontに送ることにします)
<比較するストレージクラス>
ストレージクラスの選定は、以下とします。
- オブジェクトに対する低レイテンシー・高スループットを実現できるS3 Standard
- S3 Intelligent Tiering
- ストレージ料金が最も安いS3 Glacier Deep Archive
1. 1年に1度もアクセスをしないで、ファイルを保存しておくだけのケース
S3 standard: $30/1year
S3 Intelligent Tiering: $13.64/1year
S3 Glacier Deep Archive: $5.4/1year
2. 半年に1度(1年に2度)、 全ファイルに対してのアクセスがあるケース
S3 standard: $30.074/1year
S3 Intelligent Tiering: $21.364/1year
S3 Glacier Deep Archive: $6.874/1year
3. 1ヶ月に1度、全ファイルにアクセスがされるケース
S3 standard: $30.444/1year
S3 Intelligent Tiering: $33.444/1year
S3 Glacier Deep Archive: $29.244/1year
上記の試算からわかることとしては、以下でした。
-
1年に1度もアクセスがないケースは、S3 standardと比較して、Intelligent Tieringの階層移動が行われることによるコスト削減が図れる。ただ、S3 Glacier Deep Archiveが最も安い。
-
半年に一度のアクセスがされるケースでも、S3 standardと比較してmIntelligent Tieringの階層移動が行われることによるコスト削減が図れる。ただ、S3 Glacier Deep Archiveが最も安い。
-
1ヶ月に1度、全ファイルにアクセスがされるケースでは、データ取り出しやモニタリングコストの分、S3 standardよりもコストが高くついてしまう。
上記、コスト面のみを考慮すると、S3 Glacier Deep Archiveが最もコストとしては低いものになっているが、1度のデータ取り出しには12時間以内の時間がかかるため、アプリケーションで使用される画像などのストレージとしては現実的ではないです。
上記から、低レンテンシーのパフォーマンスが求められるが、Intelligent Tieringの階層移動が行われる30日や90日でアクセスがあるかどうかのファイル
では、Intelligent Tieringの使用が良いです。
3. S3 Intelligent Tieringのメリット・デメリット
3.1 メリット
-
アクセスの有無から自動的にアクセス層を移行し、コスト削減を図ることができる
→低頻度アクセス階層は、ストレージコストを最大 40% 節約
→アーカイブインスタントアクセス階層は、ストレージコストを最大 68% 節約
https://aws.amazon.com/jp/s3/storage-classes/ より -
取り出し料金がかからない
→S3 Glacierなど,データを低コストに保存することが目的のストレージだと、
データを取り出すことに加え、データ取り出しをリクエストすること自体にもコストがかかる。
しかし、Intelligent Tieringに関してはデータを取り出すことには、料金がかからない。
(インスタンスアクセス階層にあるデータへの迅速取り出しなど一部コストがかかるデータ取り出しの方式もある) -
ストレージクラス移行には料金がかからない
→アクセス階層が変更されることに関してはコストがかからない。
3.2 デメリット
-
モニタリングコストがかかる
→Objectのサイズが、128KBより大きなものに対してはアクセスの有無を判定するために、モニタリングコストというものがかかる($0.0025 per 1000 OBJ) -
(デメリットというよりは注意点となりますが、)128KB未満の場合のオブジェクトは、高頻度アクセス階層に保存され、自動の階層移動は行われない。
4. 代替技術
Intelligent Tieringの代替になりうるのがS3のライフサイクル管理
になります。
ライフサイクル管理
を使用することで、ストレージクラスの変更やオブジェクトの古いバージョンの削除などを行うことができます。
4.1 ライフサイクル管理の特徴
ライフサイクル管理では、ライフサイクルルールというものを使用して、ストレージクラスの移行を行います。
ライフサイクル管理では、時間軸に応じたファイル管理を行うことが目的。
ライフサイクル管理では、以下のことを行います。
- オブジェクトの最新バージョンをストレージクラス間で移動
- オブジェクトの古いバージョンをストレージクラス間で移動
- オブジェクトの最新バージョンを有効期限切れにする
- オブジェクトの古いバージョンを完全に削除
- 有効期限切れのオブジェクト削除マーカーまたは不完全なマルチパートアップロードを削除
(大容量のファイルアップロードを行った際のマルチパートアップロードの失敗データ)
ただし、注意点として以下があります。
- ウォーターフォール的にオブジェクトの移行がされていくので、矢印とは反対方向へのストレージクラスの移行は行うことができない
-
アクセスの有無に関わらず、自動的にストレージクラスを移行するため、ライフサイクルルールによって、オブジェクトへのアクセスが想定よりも遅くなるケースが生まれる
-
S3 Standard – IA, S3 1 ゾーン - IA, Glacier Instant Retrievalへの移行は、128KB以上のオブジェクトでないとできない
-
UTCの午前0:00にライフサイクルルールの適用がされるため、JSTで使用する際には注意が必要
-
ライフサイクル移行を行う際に、コストがかかるストレージクラスが存在する
4.2 各機能の特徴とユースケースについて
上記から、Intelligent Tieringとライフサイクル管理については、以下のような特徴があります。
ライフサイクル管理 | 項目 | Intelligent Tiering |
---|---|---|
ストレージクラスの変更によるコスト削減 | 目的 | アクセスが行われる頻度が変動するファイルへのコストとパフォーマンス最適化 |
時間 | 何によってストレージクラスを変動するか | アクセス頻度 |
ストレージクラスの移動は一方向にしかできない。 オブジェクトの最新・古いバージョンに対してのストレージクラスの管理ができる。 | 特徴 | アクセス階層を双方向に変動できる。 ストレージクラス自体の移動ではなく、アクセス階層の移動がされる。 |
それでは、上記の目的や特徴から、どのようなケースにライフサイクル管理を使用し、どのようなケースにIntelligent Tieringを使用すれば良いでしょうか。
上記より、以下のようなケースでの使い分けができます。
Intelligent Tiering: いつアクセスが起きるかわからないが、即座にレスポンスを返す必要があるファイルのコスト最適化として
ex) ユーザーの利用履歴内にある画像など
→いつアクセスされるかはわからないが、即座にレスポンスを返す必要があるファイル
ライフサイクル管理: ファイルの使用用途が明確で、パフォーマンスや耐久性・可用性を落として、ストレージコストを優先しても良いファイルのコスト最適化として
ストレージタイプを戻す必要がない、使用用途が明確なもの。
ex) リリース後に最初の3ヶ月のみ使用したが、後々年単位で使用する可能性もあるログファイルなど
5. まとめ
本記事では、S3 Intelligent Tieringの特徴やメリット・デメリットについてまとめました。
S3という便利なストレージだからこそ、コスト管理やユースケースにおける最適なストレージクラスを探すのは難しいです。
読者の方々の環境でも、本記事を参考にながら、各々の環境でのコスト及びストレージクラス最適化を実現してみてください。
備考
試算
###### 1. 1年に一度もアクセスをしないで、ファイルを保存しておくだけのケース
- S3 standard
<ストレージ料金>
$0.025/1GB × 100GB = $2.5/1month
<総計>
$2.5 × 12months = $30/1year
- S3 Intelligent Tiering
<ストレージ料金>
高頻度アクセス層
$0.025/1GB × 100GB = $2.5/1month
低頻度アクセス層
$0.0138/1GB × 100GB = $1.38/1month
インスタンスアクセス層
$0.005/1GB × 100GB = $0.5/1month
<モニタリングコスト>
$0.0025 * (100,000 OBJ / 1000) = $0.25/1month
<総計>
$2.5 × 1month + $1.38 × 3month + $0.5 × 8month + $0.25 * 12month
= $13.64/1year
- S3 Glacier Deep Archive
<ストレージ料金>
$0.002/1GB × 100GB = $0.2/1month
<総計>
$0.2 × 12month = $2.4/1year
###### 2. 半年に1度(1年に2度)、 全ファイルに対してのアクセスがあるケース
- S3 standard
<ストレージ料金>
$0.025/1GB × 100GB = $2.5/1month
<データ取り出しリクエスト料金>
$0.00037/1000OBJ × 100,000OBJ = $0.037/1回
<総計>
$2.5/1month × 12month + $0.037/1回 × 2 = $30.074/1year
- S3 Intelligent Tiering
<ストレージ料金>
高頻度アクセス層
$0.025/1GB × 100GB = $2.5/1month
低頻度アクセス層
$0.0138/1GB × 100GB = $1.38/1month
インスタンスアクセス層
$0.005/1GB × 100GB = $0.5/1month
<データ取り出しリクエスト料金>
$0.00037/1000OBJ × 100,000OBJ = $0.037/1回
<モニタリングコスト>
$0.0025/1000OBJ * 100,000OBJ = $0.25/1month
<データ取り出し含め半年間にかかるコスト>
$2.5/1month × 1month + $1.38/1month × 3month + $0.005/1month × 1month + $2.5/1month × 1month + $0.037/1回 + $0.25/1month × 6month= $10.682/6month
<総計>
$10.682/6month × 2 + = $21.364/1year
- S3 Glacier Deep Archive
<ストレージ料金>
$0.002/1GB × 100GB = $0.2/1month
<データ取り出しリクエスト料金>
$0.00037 × (100,000OBJ / 1000) = $0.037
<データ取り出し料金>
$0.022/1GB * 100GB = $2.2/1回
<総計>
$0.2 × 12month + $0.037 × 2 + $2.2 × 2 = $6.874/1year
###### 3. 1ヶ月に1度、全ファイルにアクセスがされるケース
- S3 standard
<ストレージ料金>
$0.025/1GB × 100GB = $2.5/1month
<データ取り出しリクエスト料金>
$0.00037/1000OBJ × 100,000OBJ = $0.037/1回
$2.5/1month × 12 + $0.037/1month × 12 = $30.444/1year
- S3 Intelligent Tiering
<ストレージ料金>
高頻度アクセス層
$0.025/1GB × 100GB = $2.5/1month
データ取り出しリクエスト料金
$0.00037 × (100,000OBJ / 1000) = $0.037/1month
<モニタリングコスト>
$0.0025 * (100,000 OBJ / 1000) = $0.25/1month
$2.5/1month × 12months + $0.037/1回 × 12months +$0.25/1month × 12months = $33.444/1year
- S3 Glacier Deep Archive
<ストレージ料金>
$0.002/1GB × 100GB = $0.2/1month
<データ取り出しリクエスト料金>
$0.00037 × (100,000OBJ / 1000) = $0.037/1回
<データ取り出し料金>
$0.022/1GB * 100GB = $2.2/1回
<総計>
$0.2 × 12month + $0.037 × 12 + $2.2 × 12 = $29.244/1year
---
<計算に使用した価格>
https://aws.amazon.com/jp/s3/pricing/
計算に使用した料金表
参考資料
参考資料
-
S3:データを保存するストレージ ↩︎
-
ストレージクラス:S3へのデータの格納方式(他のストレージクラスの例としては、S3 StandardやS3 Glacier Deep Archiveなどがある) ↩︎
-
オブジェクト: ストレージの単位であるバケットに保存されるデータの単位(htmlファイルや画像データなど) ↩︎
-
スループット:一定時間で、どれだけの量のデータを転送できるか ↩︎
-
アクセスとは:AWS Management Console を介して、あるいは GetObject または CopyObject を実行してオブジェクトをダウンロードまたはコピーすると、アクセスが開始されます。HEAD、LIST、GET 、または PUT オブジェクトタグのオペレーションを実行しても、アクセスは構成されません。
AWS公式より ↩︎
Discussion