こんにちは、しーまんです。
今回は、去年も行ったアドベントカレンダー用の記事になります。
サムザップ Advent Calendar 2022の12/2の記事です。
毎年このイベント用の記事を書いていると、今年も終わりだなぁという気持ちになります。
記事の内容をどうしようかといくつか考えてみましたが、直近だと複数プロジェクトのクラウドコスト削減に携わっていましたので、その中で注意が必要なS3ストレージクラス変更時の注意点について述べていきたいと思います。
軽く自己紹介
アドベントカレンダー用記事ですので、軽くですが私の業務内容について触れておきます。
現在はSREチームに所属しており、メインのプロジェクトのインフラの構築をしつつ、複数のプロジェクトの運用・改善に携わっています。
AWS/GCPクラウドをメインに担当していますが、プログラムの経験もありますので簡単なコードだったり、連携部分のソース読解などは問題なくできます。
直近の業務では「Web Siteのインフラ構築とデプロイのChatops化」「Snowflakeを用いた分析環境の構築」「複数プロジェクトのクラウドコスト削減」などなど、幅広く行っています！
クラウドコスト削減施策
今回の話題は直近の作業の「複数プロジェクトのクラウドコスト削減」に関して取り上げていきます。
前提条件
まず前提として今回コスト削減を行ったプロジェクトは、私がメインでインフラ構築した(している)プロジェクトではありません。(そもそも私がメインのプロジェクトは常にコスト最適化を図っていると個人的には思っている。)既に運用されているプロジェクトのコストを削減したいとの要望を受け、私がアサインされた感じです。
ですのでそのプロジェクトのインフラ構成や、仕様などは細かく把握しておりません。
ですが、そういったプロジェクトに入ってコスト削減してほしいというお悩みは、私の会社だけのことではなく、結構よくあることなのではないでしょうか。
そういった条件下でコスト削減に着手するのはとても難しいですが、やりがいはありますよね。
コスト削減手順
上記前提のもと、コスト削減を行っていきます。実際に行ったコスト削減手順は以下です。
- 目標値の設定
- 削減項目の洗い出し
- 工数・効果見積り
- 優先順位付け
- 実際のコスト削減作業
- 実績確認
一つずつ見ていきましょう！
目標値の設定
まずはいきなり作業に入ってはいけません。ちゃんと目標値を設定しましょう。
基本的にはプロジェクトの要望をまずヒアリングします。このくらいのインフラコストにしたいというのをもらいましょう。この時よくあるのが、「できるだけ安くしてくれ」という曖昧な依頼です。こういった依頼のされ方は一番困りますが、「どのくらいが妥当だか分からない」というのも本音でしょう！
その場合は一旦保留にして、「削減項目の洗い出し」と「工数・効果見積り」を行った後、こちらから目標値をいくつか提示しましょう！「このぐらいの工数をいただければ、このくらい削減できます。」みたいなものをいくつか提示してプロジェクトの希望に合わせる感じですね。
ちゃんとここをプロジェクトとすり合わせてから作業を開始しないといつまで経っても削減作業が終わりませんし、評価自体もされにくいので、この工程が抜けていたという方は是非今後はしっかりと目標設定を行ってから作業しましょう！
削減項目の洗い出し
次に行うのが、作業項目の洗い出しです。
プロジェクトの内情を理解している方はまずは使用していない余分なリソースがないか洗い出して見ましょう。見つかったら、それを削除するのが削減項目になります。
次はクラウド請求を確認しましょう！基本的にはクラウドコストを削減するときは実際の請求を確認し、どこにコストが掛かっているかを把握します。コストが小さいものに関しては基本的に無視をして、効果の大きいものから対応します。
次は使用しているリソースで余分なリソースを食っているインフラを洗い出します。
例えばDBのスペックがオーバーで、無駄に大きいインスタンスを使っているとかですね。
こういうオーバースペックなインフラは運用が長くなると多くなるので、定期的に見直せるといいですね。
工数・効果見積り
「削減項目」が洗い出せたらそれぞれ対応するのにかかる工数を見積もります。
見積もりには経験が必要ですが、大体自身が見積もったものに1.5倍くらいのバッファーを設けるのが普通です。見積もり通り作業が進むことはほとんどありませんし、作業途中で何かしら差し込み作業が挟まるものなので、そのくらいのバッファーは考慮しておきましょう。
工数の洗い出しとともに削減効果も一緒に見積もりを行いましょう。
これは実施に削減を行ったらどのくらいのコストを削減されるかを見積もるということです。
工数と効果は一緒に洗い出しておくと次の作業が行いやすいです。
優先順位付け
「作業項目の洗い出し」とそれに紐づく「工数・効果見積り」ができたら、作業優先順位を割り振って行きましょう。基本的には効果が大きくて、工数が小さいものを優先度高く設定しましょう！
結構多くの方がやってしまうのが、気になったものから手をつけるというやり方ですが、これはあまりよくありません。成果を出す方の考え方は、より少ない工数で大きな成果を上げる！ということです。
コスト削減でももちろん同じ考えです。この基本的な考えをもとに作業項目に優先順位を割り振って行きましょう！
実際のコスト削減作業
ここまでできたら、コスト削減で行うべきことと順番、工数・削減効果が洗い出せているはずです。
最初の目標値が握れていない場合はこのタイミングでプロジェクトとよく相談しましょう！
プロジェクトと目標が握れたら、作業項目のうちどこまでを対応すればよいのかが決まります。
あとは、項目の優先順位に従って、実際にコスト削減を行っていくだけです！
実績確認
コスト削減作業が終わったら終わりではありません。
実際に作業をしたら実績を確認することを忘れないでください。
実際に作業をしたら思ったより工数がかかったとか、思ったより削減できなかった、などの見積もりとのかえりがでます。その場合はプロジェクトと相談しましょう。もう少し工数をもらい更に削減に作業を行うかどうかは自分でかってに判断してはいけません。
あくまでプロジェクトの納得いく工数で、納得のいくコスト削減を目指しましょう！
S3ストレージクラス変更
ここまででコスト削減の流れを説明してきました。
ここからは実際に私が行ったコスト削減のうちの一つで効果が大きく、また少し注意しなければいけない「S3ストレージクラス変更」について説明したいと思います。
対応内容
AWSではログファイルや、分析情報などをS3に保存することはよくあります。運用が長くなるとこのS3の容量が肥大化し、毎月かなりのコストがかかるようになります。
そこでAWSではS3にストレージクラスという概念を取り入れています。基本的にはS3はストレージ料金とアクセス料金の2つから料金が算出(細かく分類すると6つ)されます。そこでその2つの組み合わせによってストレージクラスが設定されています。
具体的には通常よくアクセスがあるものには標準的なS3を、低アクセスなものにはストレージ料金の安いストレージクラスを使用することで総合的な料金を抑えることが可能になっています。
ログなんかが良い例で、古いログはそんなに高頻度でアクセスしませんよね。そんなログの為に標準のストレージ料金を払うのは無駄でしかありません。
そんな場合に下記の様なライフサイクルを設定してストレージクラスを変更します。
こちらの例では90日経過したファイルはストレージクラスをGlacierに変更するというものです。
下記でデータに関わるストレージ料金がどのくらいかかるのか見てみましょう。
ストレージ料金
| ストレージクラス | ストレージ料金 |
|---|---|
| S3 標準 | 最初の 50 TB/月 0.025USD/GB 次の 450 TB/月 0.024USD/GB 500 TB/月以上 0.023USD/GB |
| S3 Glacier Flexible Retrieval (旧 S3 Glacier) | 0.0045USD/GB |
| S3 Glacier Deep Archive | 0.002USD/GB |
ストレージ料金は上記のような設定になってみます。
例えばストレージデータ量が1000TBの時標準のS3とGlacierではどのくらい料金に差が出てくるのか計算してみましょう。
標準のS3の場合:
(50TB×1000×0.025USD) + (450TB×1000×0.024USD) + (500TB×1000×0.023) = 23550USD
Glacierの場合:
1000TB×1000×0.0045USD = 4500USD
その差が月額で19,050USDとなります。1$=140円計算でも月に2,667,000円ほどの差が生じます。
いかがでしょうか、データ量が大きくなるとストレージクラスによってコストがだいぶ違うということが実感できましたでしょうか。
これだけのコスト差が生じますので、S3を使用する際はしっかりとライフサイクルを設定し、不要なものは削除、必要なものもアクセス頻度を考慮してストレージクラスの変更を予め設定できているとよいですね！
注意点
上記のようにストレージクラスを変更することには絶大なコスト削減効果が表れます。
ただし、この記事を見て早速ライフサイクルを設定してみようと思ったあなたに、ここで一つ注意点です。
大事なのでもう一度！「ストレージクラスの変更には料金がかかります！」
はい、そうですこの点を注意しないといけません。どういうことかというと最初からライフサイクルを設定してストレージクラスを変更していたら問題ないのですが、コスト削減をしようとしていきなり大量のデータのストレージクラスを変更してしまうと、予想外の料金を請求されてしまう可能性があります！
それはライフサイクルによってストレージクラスを変更する場合に、クラス変更料金がかかってくるようです。東京リージョンの場合1000件あたり0.03426USDかかります。
例えばファイルが1億件あった場合に関して計算してみましょう。
(100,000,000 ÷ 1000件)×0.03426USD = 3426USD
上記の場合、1$=140円計算では479,640円かかります。月の請求に上乗せされてしまうのでかなりのインパクトですよね。グラフで表すと下記のようになってしまうことがあります。これだと将来的に削減されるコストの恩恵はありますが、その月のコストは爆増してしまいますね。
こうなるのを防ぐために、まずは不要なファイルは削除しましょう！
削除には料金がかからないので、不要であるならばまずは削除するのが良い対策ですね。
削除できるリソースがなくなったら、徐々にストレージクラスを変更しましょう。
ストレージクラスの変更を一度にやらずに月ごとに分割する感じですね。そうすることで月のコストは抑えつつコスト削減が可能です。
または、どちらにせよ削減につながるのであればその月のコストは一時的に上がっても構わないというプロジェクトであれば、そこまで気にする必要はないでしょう。とはいえ、何も報告せずに行ってしまうと、コスト削減しているのにコストが上がってしまうことになりかねないので、報告だけはしておいた方が良さそうですね。
まとめ
今回はS3ストレージクラス変更時の注意点について説明してきました。
S3のストレージクラスには複数の種類が存在します。その使い分けはアクセス頻度によって最適になるようなものを選択します。こちらを最適化することによって、S3のコストはかなり削減することが可能です。
ですが、運用中のプロジェクトで最適化を行う場合は要注意です。ライフサイクルを用いたストレージクラスの変更には別途料金がかかるからです。こちらを意識しておかないと、ライフサイクルを設定後、かなりのストレージクラス変更コストを支払うことになります。
ですのでなるべく運用前にS3のライフサイクルに関しては設定をしておくこと。また、運用中のプロジェクトの最適化を行う場合は、不要なファイルの削除を最初に行い、コストの一時的な増加をプロジェクトと相談することを忘れずに行ってください。
今回はアドベントカレンダーの記事ということですので、明日は @Gaku_Ishii さんの記事になります。年末恒例のイベントですので、他の方の記事や、他の会社のアドベントカレンダーも積極的に覗いてこの機会にいっぱいインプットしましょう！
コメント