サービス基盤グループの大谷です。日頃はロコガイドが提供する各種サービスのインフラ全般を担当しています。
今回はtokubai.co.jpにて実施したコスト削減事例について紹介したいと思います。
トクバイサービスが抱えていたオブジェクトストレージのコスト課題
トクバイサービスでは大量の画像データを取り扱い、日々ユーザの行動ログデータを収集しています。ストレージとしてはAmazon S3を利用していますが、昨年度より発生している為替レート(USD/JPY)の急激な変化により、利用コストが無視できない状況になってきました。
トクバイでは従来EC2Spotやリザーブドインスタンス/SavingPlansを積極的に活用しています。しかし、これまで各バケット/オブジェクトに対してストレージクラスを細かく設定する等のストレージ領域に対するコスト削減施策は手つかずの状態でした。
この状況に対応するため S3 Intelligent-Tieringを導入したため実施した施策の詳細について以下にまとめます。
S3 Intelligent-Tieringの紹介
Amazon S3にはストレージクラスという概念があります。 通常、S3 Standardというストレージクラスが適用されますが、対象のS3オブジェクトのアクセス頻度をより少なく抑えられたり、データの取得時間が長くなることが許容できる場合は適切なストレージクラスに切り替えることで大幅なコスト削減の見込みがあります。
| ストレージクラス | アクセスパターン | アクセス頻度 | データの取得時間 | 料金（GBあたり/月） |
|---|---|---|---|---|
| S3 Standard | ミリ秒アクセスで頻繁にアクセスされるデータ | 月に 2 回以上 | 即時 | $0.025 |
| S3 Standard-IA | 存続期間が長く、ミリ秒単位のアクセスデータであまり頻繁にアクセスされない | 1 か月に 1 回 | 即時 | $0.0138 |
| S3 Intelligent-Tiering | 認識されていない、変更されている、または予測不可能なアクセスパターンを持つデータ | 不定 | 即時 | $0.023 (別途モニタリング料金等も発生する) |
| S3 One Zone-IA | 再作成可能で、ミリ秒単位でアクセスされたデータでアクセス頻度が低い | 月に 1 回 | 即時 | $0.011 |
| S3 Glacier Instant Retrieval | ミリ秒単位で瞬時に取り出し、四半期に 1 回アクセスするような長期保存アーカイブデータ | 四半期に 1 回 | 即時 | $0.005 |
| S3 Glacier Flexible Retrieval | 存続期間が長く、取得時間は分から数時間になり、年に 1 回アクセスされたアーカイブデータ | 年に 1 回 | 分〜数時間 | $0.0045 |
| S3 Glacier Deep Archive | 存続期間が長く、年に 1 回未満でアクセスされ、12 時間以内に復元できる長期のデータアーカイブの場合 | 年に 1 回未満 | 12時間以内(大容量は48時間以内) | $0.002 |
上記のストレージクラスの内、トクバイでは全面的にS3 Intelligent-Tieringを導入することにしました。
S3 Intelligent-Tieringの特徴はざっくり以下のような特徴があります。
- S3オブジェクトのアクセスパターンを監視し、30日間連続してアクセスされていないオブジェクトを低頻度のアクセス層に移動する
- 自分でライフサイクルポリシーを設定したりS3オブジェクトの使用状況を分析したりする必要がない
- 自動でアクセス層を分類してくれるため手軽にS3コストの削減ができる
導入の決め手は特に導入と運用の簡単さです。実は削減できるS3コストだけに着目すると別のストレージクラスの方がより削減効率は高い可能性があります。特にS3 Intelligent-Tieringは自動でアクセス層を分類するためのモニタリング・オートメーション料金も追加でかかります。
しかし、各バケット/オブジェクトのアクセス傾向を詳細に分析・分類する手間(※1)と、今後の運用において適切なストレージクラスを適合させ続ける手間(※2)を考えるとAWSへ任せられるのであれば任せてしまった方が楽そうという判断によりS3 Intelligent-Tieringの採用に至りました。
※1 この辺りの判断は対象のバケット数や、バケットの運用ポリシーにアクセス頻度など含めて運用できていたか等にもよるかもしれません。まずS3のアクセス分析を詳細に行いたいという方はAmazon S3 Storage Lens等を活用すると良さそうです。
※2 ストレージクラスに対してアクセス傾向が違うオブジェクトが混入するとトラブルの元になり得るため、しっかりガバナンスを効かせる必要がありそうですが、そのための監視のこと等まで考えると大分手間になりそうだなという気持ちでした。
S3 Intelligent-Tieringへの移行方針
現行のS3 standardからS3 Intelligent-Tieringへの移行にあたり以下の方針で作業を進めました。
- S3 standardにオブジェクト作成30日後に S3 Intelligent-Tiering ストレージクラスに移行するように設定する。 これにより、移行直後から頻繁にアクセスされないInfrequent Access tierを利用する可能性が高まります。
- 移行対象とするオブジェクトのサイズを256KB以上に限定する。 これは、モニタリングと自動化に関連する料金の増加を抑えるための措置です。
- S3の全使用量において、上位90％を占めるバケットを移行対象とする。 ポリシー管理の複雑さを避けるため全体の下位10％は移行から除外。対象となる上位90％のバケットについてはアーカイブアクセス階層の有効化(※3)を検討しました。
※3 非同期アーカイブアクセス階層の利用により更にコストを圧縮できる可能性があります。90日以上アクセスが無かったオブジェクトに対して適用され、復元には復元作業が必要かつ復元まで最長48時間掛かるため、それが許容できるオブジェクトに限定する必要があります。
S3 Intelligent-Tieringの設定例と作業に役立つAWS CLI
ここからは実際の設定例と作業に役立つAWS CLIについてTips的に紹介します。
S3 Intelligent-Tieringストレージクラスへ移行するためのS3ライフサイクルポリシーの設定例
resource "aws_s3_bucket_lifecycle_configuration" "lifecycle_configuration" { bucket = aws_s3_bucket.s3_intelligent_tiering_bucket.id rule { id = "s3-intelligent-tiering" filter { object_size_greater_than = 256*1024 } transition { days = 30 storage_class = "INTELLIGENT_TIERING" } noncurrent_version_transition { noncurrent_days = 30 storage_class = "INTELLIGENT_TIERING" } status = "Enabled" } }
S3 Intelligent-Tiering ストレージクラスの Archive Access tier / Deep Archive Access tier の利用をアクティブにする場合の例
resource "aws_s3_bucket_intelligent_tiering_configuration" "intelligent_tiering_configuration" { bucket = aws_s3_bucket.s3_intelligent_tiering_bucket.id name = "intelligent_tiering_configuration" tiering { access_tier = "ARCHIVE_ACCESS" days = 90 } tiering { access_tier = "DEEP_ARCHIVE_ACCESS" days = 180 } }
S3 Intelligent-Tiering ストレージクラスの Archive Access tier / Deep Archive Access tier の状況を確認するAWS CLI
$ aws s3api list-bucket-intelligent-tiering-configurations --bucket "s3-intelligent-tiering-bucket"
{
"IsTruncated": false,
"IntelligentTieringConfigurationList": [
{
"Id": "intelligent_tiering_configuration",
"Status": "Enabled",
"Tierings": [
{
"Days": 180,
"AccessTier": "DEEP_ARCHIVE_ACCESS"
},
{
"Days": 125,
"AccessTier": "ARCHIVE_ACCESS"
}
]
}
]
}
※ Archive_Access_tier/Deep_Archive_Access_tierが非アクティブの場合 {"IsTruncated": false} が返却されます
Deep Archive Access tierに落とされた S3 オブジェクトの復元
$ aws s3api restore-object --bucket s3-intelligent-tiering-bucket --key example.objct --restore-request '{}'
導入後のコスト削減効果
今回の施策の結果、S3 Intelligent-Tiering適用後のコスト傾向は以下になります。
コストエクスプローラー上の使用タイプも
- (適用前)APN1-TimedStorage-ByteHrs
- (適用直後)APN1-TimedStorage-INT-FA-ByteHrs
- (適用後30日)APN1-TimedStorage-INT-IA-ByteHrs
- (適用後90日)APN1-TimedStorage-INT-AA-ByteHrs
という順で適用されていってるのが観察できて面白いですね。
実際の金額について公開することはできませんが、大幅なコスト削減が実現できていることが見て取れるかと思います。
最後に
今回の施策により割合的にはトクバイサービス全体のS3コストを4割まで圧縮することができました。 コスト削減の実現にあたり、日々くふうカンパニーグループのコスト分析及びコスト削減提案に尽力頂いてるAWSエンタープライズサポートチームの皆様、S3 Intelligent-Tiering導入に辺り中心となって作業頂いた youkun19 に感謝申し上げます。
