自己紹介
こんにちは。株式会社DELTAでインフラエンジニアをしている浜崎です。
この記事は AWS（Amazon Web Services） Advent Calendar 2023 の13日目の記事となります。
はじめに
運用中のS3に保存しているオブジェクトについて、過去のものはアクセスがほとんどないはずだけど、実際どれくらい少ないのかわからない。
ライフサイクルを設定して、過去オブジェクトを費用の低いストレージクラスに移行できるのに、移行したら逆に費用が高くなるかもしれないから手が出せていない。
そんなS3バケットはありませんか？
今回はそういった状況を解消すべく、S3の機能のひとつ「S3ストレージ分析」を運用中のバケット(※東京リージョン)に対して有効化して、過去のデータをストレージ料金の低いストレージクラスに移行した場合、どれくらいコストが下がるのか(または本当にコストが下がるのか)を算出しました。
※本記事に記載のAWS利用料は執筆時点(2023年12月)の東京リージョンの料金です。また、料金の単位はすべてUSDで記載しています。
結果
最初に分析結果を書いてしまいます。
S3ストレージ分析をして、移行後の料金を計算すると以下の表のようになりました。
リクエスト/データ取り出しは、移行後のオブジェクトへのアクセスに対して発生する料金です。
S3コスト削減額が実際の削減額で、移行により削減されたストレージ料金からリクエスト/データ取り出しに発生する料金を差し引いたものになります。
- S3 標準 - 低頻度アクセス
| ～日以前を移行 | リクエスト/データ取り出し | ストレージ料金削減額 | S3コスト削減額 |
|---|---|---|---|
| 0 | 34.574 | △155.324 | △120.75 |
| 15 | 31.889 | △154.375 | △122.486 |
| 30 | 30.481 | △153.399 | △122.918 |
| 45 | 29.617 | △152.419 | △122.802 |
| 60 | 29.062 | △151.436 | △122.374 |
| 75 | 28.556 | △150.518 | △121.962 |
| 90 | 28.11 | △149.622 | △121.512 |
| 120 | 27.248 | △147.926 | △120.678 |
| 150 | 25.696 | △146.13 | △120.435 |
| 180 | 24.556 | △144.203 | △119.647 |
| 365 | 19.606 | △133.636 | △114.03 |
| 730 | 9.783 | △112.795 | △103.012 |
- S3 Glacier Instant Retrieval
| ～日以前を移行 | リクエスト/データ取り出し | ストレージ料金削減額 | S3コスト削減額 |
|---|---|---|---|
| 0 | 196.157 | △277.365 | △81.208 |
| 15 | 178.499 | △275.669 | △97.171 |
| 30 | 170.813 | △273.927 | △103.114 |
| 45 | 166.252 | △272.176 | △105.925 |
| 60 | 163.334 | △270.421 | △107.087 |
| 75 | 160.676 | △268.782 | △108.106 |
| 90 | 158.337 | △267.183 | △108.846 |
| 120 | 153.791 | △264.154 | △110.363 |
| 150 | 145.011 | △260.947 | △115.936 |
| 180 | 138.439 | △257.506 | △119.066 |
| 365 | 110.027 | △238.636 | △128.609 |
| 730 | 53.535 | △201.42 | △147.885 |
これらの結果から、今回分析を行ったバケットでは、アップロードから730日前のデータを「S3 Glacier Instant Retrieval」に移行するのが一番コスト効率がいいことがわかります。
では、なぜS3ストレージ分析を有効化するだけで、ここまで詳細な情報がわかったのか。
事項からそちらについて説明していきます。
S3ストレージ分析とは
詳細は公式ドキュメントに記載があります。
S3ストレージ分析を有効化すると、バケット全体(プレフィックスとタグによって対象を絞ることも可能)のオブジェクトのアクセスパターンを分析し、結果のCSVファイルを指定したバケットに出力されます。
分析結果は、S3にアプロードされてからの経過時間に基づいたグループ毎に、主に以下の情報が出力されます。
※AWS公式ドキュメントから抜粋
分析で取得できるデータ
- レコードが処理された日付
- 経過時間グループ内のその日における、ストレージクラスごとの合計ストレージ容量 (MB)
- 経過時間グループ内のその日に GET リクエストによって転送 (アウト) された、ストレージクラスごとのデータ量 (MB)
- 経過時間グループ内のその日に行われた、ストレージクラスごとの GET と PUT リクエスト数
※経過時間に基づいたグループ
15 日未満経過の Amazon S3 オブジェクト
15 ～ 29 日経過の Amazon S3 オブジェクト
30 ～ 44 日経過の Amazon S3 オブジェクト
45 ～ 59 日経過の Amazon S3 オブジェクト
60 ～ 74 日経過の Amazon S3 オブジェクト
75 ～ 89 日経過の Amazon S3 オブジェクト
90 ～ 119 日経過の Amazon S3 オブジェクト
120 ～ 149 日経過の Amazon S3 オブジェクト
150～179 日経過の Amazon S3 オブジェクト
180 ～ 364 日経過の Amazon S3 オブジェクト
365 ～ 729 日経過の Amazon S3 オブジェクト
730 日以上経過の Amazon S3 オブジェクト
要は、経過時間に基づいたグループ単位で、分析を有効化した期間の合計ストレージ容量と、データ転送量、GET/PUTリクエスト数がわかるみたいです。
また、取得できるデータはちゃんと容量が128KB以上のオブジェクトのみの数値となっているようです。
分析料金
ちなみに、S3ストレージクラス分析の料金は 0.10USD(月間監視対象100万件あたり・東京リージョン) です。
※公式による料金記載は、S3料金ページの[管理と洞察]タブ->[S3ストレージ分析]にあります。
まずは検証でやってみる
実際にどういったレポートが入手できるのだろうと思い、まずは検証用にバケットを作成して試してみることにしました。
検証用バケット作成
検証用バケットと分析レポート用バケットを作成します。
バケット名を入力する以外はデフォルトの設定値で問題ありません。
ファイルのアップロード
検証バケットに分析用のファイルをアップロードします。
今回は128KB以下のファイルは分析結果に反映されないことを確認するために、128KB以上のファイルを1つ、128KB以下のファイルを複数アップロードします。
1MBのファイルと、100KBほどの複数のファイルをアップロードしました。
S3ストレージ分析 有効化
次に検証用バケットにS3ストレージ分析を設定します。
対象バケットを選択し、[メトリクス]タブから「分析設定を作成」を押下します。
以下を入力し、CSV送信先バケットに作成した分析レポート用バケットを選択して、「設定を作成」を押下します。
名前：任意の名前
設定スコープ：バケット内のすべてのオブジェクトに適用
CSV をエクスポート：有効にする
ストレージクラス分析ができました。
だいたい24時間～48時間後に分析初日のレポートが出力されます。
ファイルのダウンロード
分析を有効化した状態でダウンロードをしてみます。
全ファイルを一回ずつ(1MBファイルを1個、100KBファイルを10個)ダウンロードしました。
hhamasaki@*****:~$ aws s3 cp s3://analytics-report-20231201/ ./s3test/ --recursive
download: s3://analytics-report-20231201/test_file_small_8.txt to s3test/test_file_small_8.txt
download: s3://analytics-report-20231201/test_file_small_2.txt to s3test/test_file_small_2.txt
download: s3://analytics-report-20231201/test_file_small_10.txt to s3test/test_file_small_10.txt
download: s3://analytics-report-20231201/test_file_small_3.txt to s3test/test_file_small_3.txt
download: s3://analytics-report-20231201/test_file_small_4.txt to s3test/test_file_small_4.txt
download: s3://analytics-report-20231201/test_file_small_5.txt to s3test/test_file_small_5.txt
download: s3://analytics-report-20231201/test_file_small_1.txt to s3test/test_file_small_1.txt
download: s3://analytics-report-20231201/test_file_small_7.txt to s3test/test_file_small_7.txt
download: s3://analytics-report-20231201/test_file_small_6.txt to s3test/test_file_small_6.txt
download: s3://analytics-report-20231201/test_file_small_9.txt to s3test/test_file_small_9.txt
download: s3://analytics-report-20231201/test_file.txt to s3test/test_file.txt
この状態でレポートが出力されるまで待ってみます。
分析レポート
二日後くらいにレポートができていました。
実際にCSVファイルをダウンロードし、Excelで開いたものが以下になります。
ObjectAge：000-014のデータ取り出し量(DataRetrieved_MB)が1MBほど、GETリクエスト数(GetRequestCount)が1です。
そのため、経過時間に基づいたグループ毎のデータ取り出し量、GETリクエスト数は、128KB以上のファイルのみカウントされていることがわかります。
運用中のバケットで試してみる
一通り挙動を確認したところで、運用中のS3バケットで分析を有効化しました。
一日分のレポートを取得し、標準ストレージに保存されたデータを「S3 標準 - 低頻度アクセス」「S3 Glacier Instant Retrieval」に移行した場合どれくらい料金がかかるかを試算します。
※「S3 標準 - 低頻度アクセス」「S3 Glacier Instant Retrieval」ストレージクラスは、ミリ表単位(標準ストレージと同じ)での取り出しが可能だが、リクエストやデータ取り出し量に応じた費用が標準より多くかかるという特徴があります。そのかわりに標準ストレージクラスに比べ、ストレージ料金が安価な価格設定になっています。
| S3 標準 | S3 標準 - 低頻度アクセス | S3 Glacier Instant Retrieval | |
|---|---|---|---|
| ストレージ | 0.025 | 0.0138 | 0.005 |
| GET/1000リクエスト | 0.00037 | 0.001 | 0.01 |
| データ取り出し/GB | - | 0.01 | 0.03 |
対象バケットの容量、オブジェクト数は以下です。
容量:約22TB
オブジェクト数：約3億8000万
結果
丸1日分の分析結果は、以下となりました。
※分析2日のデータになります。初日は分析有効化時点からスタートのため24時間分より少ない値が出ます。
※過去データのみの移行で、PUTは常に標準ストレージになるため、PUTについてのデータは除外します。
| ObjectAge | Storage_MB | DataRetrieved_MB | GetRequestCount |
|---|---|---|---|
| 000-014 | 84771 | 430.6023 | 44977 |
| 015-029 | 87114 | 299.1136 | 1623 |
| 030-044 | 87533 | 191.1596 | 922 |
| 045-059 | 87771 | 123.4268 | 586 |
| 060-074 | 81950 | 112.5473 | 534 |
| 075-089 | 79959 | 99.1664 | 469 |
| 090-119 | 151452 | 191.1025 | 917 |
| 120-149 | 160335 | 315.6904 | 1932 |
| 150-179 | 172080 | 226.0834 | 1477 |
| 180-364 | 943470 | 987.5117 | 6353 |
| 365-729 | 1860829 | 1955.0988 | 12657 |
| 730+ | 10071008 | 2074.6382 | 11329 |
この値から、新しいオブジェクトに対するアクセスが、より多いという傾向がわかります。
削減額の算出
これらの数値を使って、移行後の削減額を試算します。
※ひと月の日数は30.5日で計算します。
ストレージクラス移行をしたことでの追加料金(データ取り出し＋GETリクエスト)、ストレージ料金削減額はそれぞれ以下の計算です。
追加料金
- S3 標準 - 低頻度アクセス
([DataRetrieved_MB]/1000 × 0.01 + [GetRequestCount]/1000 × 0.001) × 30.5 - S3 Glacier Instant Retrieval
([DataRetrieved_MB]/1000 × 0.03 + [GetRequestCount]/1000 × 0.01) × 30.5
ストレージ料金削減額
- S3 標準 - 低頻度アクセス
(0.025 - 0.0138) × [Storage_MB]/1000 - S3 Glacier Instant Retrieval
(0.025 - 0.005) × [Storage_MB]/1000
※料金再掲
| S3 標準 | S3 標準 - 低頻度アクセス | S3 Glacier Instant Retrieval | |
|---|---|---|---|
| ストレージ | 0.025 | 0.0138 | 0.005 |
| GET/1000リクエスト | 0.00037 | 0.001 | 0.01 |
| データ取り出し/GB | - | 0.01 | 0.03 |
改めて算出結果
算出結果です。
表に記載の値は、経過時間に基づいたグループ以降すべてのグループのデータを移行した場合の料金です。
- S3 標準 - 低頻度アクセス
| 〇日経過 | リクエスト/データ取り出し | ストレージ料金削減額 | S3コスト削減額 |
|---|---|---|---|
| 0 | 34.574 | △155.324 | △120.75 |
| 15 | 31.889 | △154.375 | △122.486 |
| 30 | 30.481 | △153.399 | △122.918 |
| 45 | 29.617 | △152.419 | △122.802 |
| 60 | 29.062 | △151.436 | △122.374 |
| 75 | 28.556 | △150.518 | △121.962 |
| 90 | 28.11 | △149.622 | △121.512 |
| 120 | 27.248 | △147.926 | △120.678 |
| 150 | 25.696 | △146.13 | △120.435 |
| 180 | 24.556 | △144.203 | △119.647 |
| 365 | 19.606 | △133.636 | △114.03 |
| 730 | 9.783 | △112.795 | △103.012 |
- S3 Glacier Instant Retrieval
| 〇日経過 | リクエスト/データ取り出し | ストレージ料金削減額 | S3コスト削減額 |
|---|---|---|---|
| 0 | 196.157 | △277.365 | △81.208 |
| 15 | 178.499 | △275.669 | △97.171 |
| 30 | 170.813 | △273.927 | △103.114 |
| 45 | 166.252 | △272.176 | △105.925 |
| 60 | 163.334 | △270.421 | △107.087 |
| 75 | 160.676 | △268.782 | △108.106 |
| 90 | 158.337 | △267.183 | △108.846 |
| 120 | 153.791 | △264.154 | △110.363 |
| 150 | 145.011 | △260.947 | △115.936 |
| 180 | 138.439 | △257.506 | △119.066 |
| 365 | 110.027 | △238.636 | △128.609 |
| 730 | 53.535 | △201.42 | △147.885 |
これらの結果から、アップロードから730日前のデータを「S3 Glacier Instant Retrieval」に移行するのが一番コスト効率がいいことがわかります。
移行リクエスト料金に注意！
ストレージクラス移行の際は、移行リクエストに費用がかかります。
以下、1000 件のリクエストあたりの費用です。
| S3 標準 - 低頻度アクセス | S3 Glacier Instant Retrieval |
|---|---|
| 0.01 | 0.02 |
S3ストレージ分析で移行対象のオブジェクト数は取得できません。
そのため移行リクエストにかかる費用を正確に見積もるためには、AWS CLI等を使って対象のオブジェクト数をカウントする必要があります。
本記事では移行リクエスト料金の算出までは行いませんが、実施に大量のオブジェクトを移行する際はこの料金にも注意が必要です。
終わりに
今回はS3ストレージ分析の挙動を検証し、実際に運用中のバケットを分析を有効化して移行した場合の料金を試算してみました。
過去のデータへのアクセス数は少ないはずだけど実際にどのくらいなのかはわからないといったことから、ストレージクラス移行を躊躇っている状況は実際に多いかと思います。
今回紹介したS3ストレージクラス分析を有効化することで、そこの部分がクリアになります。
また、分析によって得たリクエスト数/データ取り出し量の情報は、ストレージ移行後の料金だけでなく、以下の観点でも役立つかと思います。
- 画像圧縮処理導入の検討にあたり、どのデータを処理対象にするとストレージや通信容量削減に効果的か実測値をもとに判断できる。
- 想定より多いリクエストを計測した場合は、アプリ側で改善すべき箇所がわかる。
- 高頻度でアクセスがある場合は、適切なキャッシュ戦略を導入してパフォーマンスを向上させることができる。
- 不自然なアクセス数を計測した場合は、Botリクエスト等の不審なアクセスの検知や遮断の仕組みの導入を検討する。
分析費用もそこまで高額にならないので、是非一度試してみてはいかがでしょうか。
We're Hiring!
DELTAではチームの一員になっていただける仲間を募集中です！
下記フォームよりお気軽にご連絡ください！
DELTAは、ベンチャースタートアップなどの成長企業向けに、ソフトウェア・プロダクト開発や技術選定支援などの技術支援事業を提供しています。 また、成長企業向けに様々な事業支援を提供するSEVENRICH GROUPに属して、グループ内の事業会社や、出資先の支援もおこなっています。
Discussion