こんにちは、Datadogでメトリクスを眺めるのがとにかく大好きな SRE Gの渡邉です。Tech Blogは今回で3回目ですね
前回の AWSのコストを45%削減した話 の続きになります。
今回からは色々なAWSサービスでの「節約系の積み上げ」の詳細になります。で、今回はS3について書こうと思います。
何をどうするのか？
S3のコストといえば、ユーザがアップロードするコンテンツや、ビッグデータ系のデータが定番ですが、Coincheckではサービスの性格上ユーザがアップロードするコンテンツはほとんどなく、またビッグデータ系も他のシステムを利用しているので、これらはほとんどありません。
その代わりに、Coincheckではいろいろなログが大量に保管されており、これが大きなコストとなっています。
ログなので、基本的には以下を行うこととなります
- 減らす
- 出力するログを減らす
- 保管期間を短くする
- 単価を下げる
ログを減らすのは可能な限り避けたいので、今回、メインで行ったのは
- 保管期間を短くする
- 単価を下げる
になります
保管期間を短くする
Coincheckはサービス開始からそれほど長い年数が経っていないこともあり、ログの多くは削除を行っておらず、初期からずっと保管している状態でした。
今回、改めてログの必要な保管期間を整理して、S3のライフサイクルでの削除設定をいれました。
ログの保管期間の整理にあたっては、弊社の規程や、監督官庁のガイドラインなどの定めを満たすようにするのは当然のこと、関係各部署に実際にはどれだけとっておくことが望ましいか？を確認して、保管期間を決めていきました。
その結果、例えば、ユーザのリクエストログについては、今まで通り無期限保管のままとしたものもあります。
単価を下げる？
これは、S3のストレージクラスを活用することで実現ができます。
ただ、前回の AWSのコストを45%削減した話 にも簡単に書いた通り、以前からライフサイクル設定で Glacier Deep Archive に変換することはやっていました。
期間のチューニングなどはやるにしても、既に保管料金は最安のGlacier Deep Archive にしているし、取り出し費用はほとんど発生していなかったので、なにか大きな余地があるのか？という状態だったのですが、以前行っていた設定には大きな問題があったことに気づきました。
それは、単純に期間が過ぎたらGlacier Deep Archiveにする、というルールにしていたことです。
Glacier Deep Archiveの料金は 料金表 をみればわかりますが、それなりに複雑です
いちばん大事なのは
- 変換に料金がかかる
- オブジェクトあたり 32 KB と 8KB のデータがさらに必要となる(これはS3 標準となる)
なので、小さいファイルは対象外にしないと損をすることになりますし、Glacier Deep Archiveに変換後、短い期間で削除してしまう場合も損になってしまいます。
Glacier Deep Archiveの損益分岐点を計算すると、、、以下になりました (2023年8月時点の計算になります)
念の為、AWSのサポートケースにもこれであっているか確認して、これで問題ないとの回答をもらいました。
|
保管年数 |
変換リクエスト＋固定ストレージ 1000Obj |
S3標準との本体ストレージ単価差額(GBあたり) |
1Objで元が取れるKB |
1Objで元が取れるByte |
|
1 |
0.06784 |
0.25200 |
282.276 |
289,050 |
|
1.5 |
0.06926 |
0.37800 |
192.120 |
196,731 |
|
1.75 |
0.06997 |
0.44100 |
166.362 |
170,354 |
|
1.916666667 |
0.07044 |
0.48300 |
152.922 |
156,592 |
|
2 |
0.07068 |
0.50400 |
147.043 |
150,572 |
|
3 |
0.07351 |
0.75600 |
101.965 |
104,412 |
|
4 |
0.07635 |
1.00800 |
79.426 |
81,332 |
|
5 |
0.07919 |
1.26000 |
65.903 |
67,484 |
|
6 |
0.08203 |
1.51200 |
56.887 |
58,252 |
|
7 |
0.08487 |
1.76400 |
50.448 |
51,658 |
|
8 |
0.08771 |
2.01600 |
45.618 |
46,713 |
|
9 |
0.09054 |
2.26800 |
41.861 |
42,866 |
|
10 |
0.09338 |
2.52000 |
38.856 |
39,789 |
|
20 |
0.12176 |
5.04000 |
25.333 |
25,941 |
|
100 |
0.34881 |
25.20000 |
14.514 |
14,863 |
|
1000 |
2.90313 |
252.00000 |
12.080 |
12,370 |
|
10000 |
28.44635 |
2,520.00000 |
11.837 |
12,121 |
|
100000 |
283.87848 |
25,200.00000 |
11.812 |
12,096 |
|
100000000000 |
283,813,476.62750 |
25,200,000,000.00000 |
11.810 |
12,093 |
これを元に、ライフサイクル設定で、最低サイズも設定をすることにしました。
また、一部では即時に確認したいログもあるので、そういったものに対しては、Glacier Instant Retrieval を利用しました。Glacier Instant Retrievalは「課金対象となる最小オブジェクトサイズは 128 KB 」となっているので、保管期間による損益分岐点を計算して最小サイズを設定したいところですが、CloudFormationだと128KB未満の設定はエラーになってしまう、という問題があり、128KBでの設定としています。（CloudFormation以外ではエラーになるかどうかは確認していません。もしかしたらライフライクル設定そのもの制限なのかもしれません）
Glacier Instant Retrieval は S3 標準 - 低頻度アクセスと同じく、通常のS3とは課金が違うだけで、全く同じように使えるので、かなり便利です。
成果
Aug 16 の途中から新しいライフサイクル設定になっています。
APN1-TimedStorage-GDA-ByteHrs と APN1-TimedStorage-ByteHrsが減ったのは、保管期間の削減の効果ですが、
それよりも APN1-Requests-Tier3 が大きく減っています。APN1-Requests-Tier3はストレージクラスの変換コスト（Glacier Deep Archiveへの変換コスト）となっています。
つまり、いままでサイズ指定なしでGlacier Deep Archiveに変換していたことの改善が１番大きかった、という結果になりました。
AWSのコストエクスプローラー サービス: S3で、償却コスト、使用タイプ別より
さらにやるには？
さらにコストを削減するには、以下などが考えられると思いますが、今回はいままでの施策で十分な削減ができたので、手をだしませんでした。ログファイルの集約などは簡単にはできないので、当面やることもないとも思いますが、S3 標準 - 低頻度アクセス や、Glacier Instant Retrieval の活用はそれほど大変ではないので、うまくはまるところがあればさらに活用していきたいと考えています
- ストレージクラスのさらなる活用
- Glacier Deep Archive にするまでの期間を、 S3 標準 - 低頻度アクセス や、Glacier Instant Retrieval にするなど
- ログの圧縮の強化
- ログファイルの集約（小さいファイルを大きなファイルにまとめる） → Glacier Deep Archive が有効活用できる
- カラムナフォーマットにしてしまえば、圧縮率もあがるし、Athenaでの使い勝手もあがるので最強では？
次回に続く
次はまた別のサービスについて書こうと思います。
なお、コインチェックでは一緒に働くエンジニアを募集中です！詳しくは求人ページをご覧ください。
https://corporate.coincheck.com/recruit/jobsearch/engineering
