この記事はLAPRAS Advent Calendar 2024の12日目の記事です。
こんにちは。LAPRAS株式会社でSREをしているnappaです。
LAPRASのSREチームでは2024年の春から夏にかけ、AWSのコスト削減に取り組んでまいりました。
結果としてはドルベースでおおよそ30%ほど削減することができましたので、その際のコスト削減に対する取り組み方など(具体的なコスト削減のTipsというよりは心がまえの部分)を共有できればと思います。
（以下、当記事内での「コスト削減」はAWSの利用料金に対するものとしてお読みください）
およそ30%削減に成功
背景
これまで弊社ではAWSのコストに対して本格的に向き合うタイミングを設けてきませんでした（少なくとも自分が入社した3年前から）
これは現実逃避して目を背けていたわけではなく、やるべきことのトリアージをした結果としてコスト削減の優先順位がほかを上回らなかったというのが実態です。専任SREの交代やクリティカルな問題への対処など、より優先順位が高いものを対処すべきとの判断があった形になります。
もちろん完全にノータッチだったかというとそういうわけではなく、意図しないレベルでコストが伸びている要素はないか、明確に不要なリソースはないかなどの調査は不定期にですが実施していました。ただ、それはあくまで現状を維持する（SRとして確保しているインフラ予算が破綻しないようにする）ための行動でしかなかったため、クリティカルなもの以外への対応についてはどうしても及び腰になってしまっていました。
そういった状況がしばらく続いていましたが、2024年の春頃に弊社CTOの rockyから 「一度SRでAWSのコスト削減に取り組んでみてはどうか」というお話があり、ほかの優先すべきタスクが落ち着いていたことも相まって、一度腰を据えて対応することになりました。
コスト削減への向き合い方
コスト削減へ向き合う上で、特に気をつけていたのは以下の3点です。
- ゴールを決める（削減量 or 期限）
- 事実から仮説を立て、より費用対効果の良いものから手を付ける
- なるべく1つずつ対処する
それぞれについて少し解説します。
ゴールを決める（削減量 or 期限）
コスト削減は突き詰めようと思えばどこまででも追求できてしまうものです。
よりコスト効率のいい構成に変えるためアーキテクチャを見直したり、やりがいのある骨太な方法はいくらでも見つけることができてしまいます。さらにコスト削減は実際に「請求金額」という形で明確な効果を実感できてしまうため、ついつい楽しくなって深追いしてしまいがちです。
が、残念なことに時間も人的なリソースも有限です。また、いくらコストを削減してもエンドユーザーにとって直接的な価値を提供することはほとんどの場合ありません。もちろんランニングコストを下げることは大事なことですし、下げたコストと同等の利益を売上ベースで考えるとなかなかのボリュームになることもあります。
コスト削減へのモチベーションが高まっていた場合、そこには何かしらの理由があるはずで、インフラに責務を持つものとして理性を働かせ、その理由に沿ったゴールを設定しておくことが重要だと考えました。
今回の場合、不定期で実施してきたコスト調査の過去情報から月額でXX万円（すみませんボカさせてください）の削減は狙えそう、というわりと具体的な試算がすぐにできたため、特定の金額を下げることを削減量としての目的として定めました。
これがもし「サービスの成長曲線を超える勢いでコストが増加しているので状況を改善したい」といった理由であれば「コストの月次増加率をXX%以内にする」といったゴールになると思いますし。その時の状況によって適切なゴールが引けるとよいかと思います。
事実から仮説を立て、より費用対効果の良いものから手を付ける
ついつい自分の中でイメージしている「あれは無駄なはず！」と思い込んでいる問題に突進しがちですが、多くの場合それよりももっと簡単にできることがたくさんあります（ありました）
まずはAWSの全体コストを俯瞰してサービス別のボリュームを確認しつつ、そこから各サービスの利用状況を深堀りしてコスト削減に効きそうなIssueを洗い出し、効果の試算と想定工数規模の見積もりを行いました。それらをスプレッドシートにまとめ、より費用対効果のよいものから順に対処する、という方針で進めていました。実際にはコスト削減に効きそうなIssue洗い出しは不定期に行っていたので、完全にゼロから始める必要がなかったのでとてもスムーズでした。
少なくとも全体のIssueを洗い出すことにより、前述のゴールの達成が現実的なものであるかどうかも判断することが可能ですし、効果の試算をすることによってAWSの課金体系への造詣も深まるのでおすすめです。
ほとんどマスクしちゃってますが、このような形で一覧化して進めました
なるべく1つずつ対処する
これは必ずしも守る必要はありませんが、コスト削減行動を「試算 -> 対処 -> 削減金額の確認」といったサイクルを回して進めていきたかったため、なるべく確認作業で影響が出ないようあまり多くのことを同時に対応しないようにしました。
AWSのコストはオフィシャルに明記されていますが、複数のコンポーネントが絡むことにより実態としてはとても複雑になっています。特定のサービスは1時間あたり$Xが利用料金、と明文化されていた場合でも、ログがCloud Watch LogsやS3に流れていたり、APIコールがCloudTrailで記録されていることにより最終的な金額は時間あたりの利用料金とは乖離してきます。複数の対応をまとめて対処してしまうと、そういった認識外でのコスト変動に気づきづらくなってしまうため、このような方針で作業を進めることにしていました。
コスト分析のやり方
事実の観測と仮説だし、対応後の削減コスト確認をするためには分析が不可欠です。今回は王道のCostExplorerに加え、CUR(Cost and Usage Reports)も使用して分析を行いました。
CostExplorerで全体感を把握
おなじみですがAWSのコストを俯瞰して見るにはCostExplorerが最も簡単です。まずは月別かつディメンションをサービスにしてサービス別のボリュームを確認しました。
この時点である程度コストを占める上位サービスが見つかるので、そこからそれぞれのサービスでフィルターをかけ、ディメンションタイプを使用タイプに変えて内容を確認・・・といった流れでコストボリュームの大きいポイントを見つけていました。
特定の使用タイプが支配的、ということがわかる
そこからは実際のリソースを確認するなり、後述のCURを使ってより具体的な確認を進めていった形です。
CostExplorerにあまり慣れていない場合、このあたりの記事を一度読んでおくと理解が深まるかもしれません
CURを使って詳細の確認
今回のコスト削減対応を期に使い始めました。CURではCostExplorerよりも細かくコストの情報を分析できることができるため、具体的な調査を行うためには非常に重宝します。
ただCostExplorerと違い、CURはコスト詳細の情報をExportする機能しかないため。S3に出力されたものを別途可視化をする必要があります。弊社ではAthenaとRedashを使用しているため、S3に出力されたCURの情報をAthenaでクエリできようにし、RedashからAthenaへクエリを実行することによってダッシュボードの作成を行いました。
日毎のリソース別コスト状況。これでコストインパクトの大きいものを観測しました
弊社サービスはEKS上で稼働しているため、EKSの各種リソース別でどのようなコストが発生しているかまでを観測できるのは非常に有用でした。
おまけ:どのようなコスト削減を行ったのか
今回は心構えがメインということで実際にコスト削減の内容まではきちんとご紹介していませんが、簡単にどのようなことを行ったかを軽く触れておこうかと思います。
-
EKSで使用しているALBの集約
- 1つのingressに対して1つのALBが作成されている状況にあり、無駄にコストが発生していたのである程度の粒度で集約を行いました
-
EKSで過剰転送を行っているジョブの改善
- CURで確認したところ一部のジョブの転送量が異常に高い状態になっていることを観測したので、原因となるアプリケーションロジックの修正を行いました
- このあたりはCURでなければ特定できていなかったポイントかと思います
-
DynamoDBのテーブル物理削除
- 機能の廃止などによりアプリケーションから参照されずともテーブルだけが残留してしまっていたので、勇気をもってバッサリ削除しました
- こういった物理削除はどうしても腰が重くなりがちなので、今回対処することができてよかったです
-
Redash -> Athenaへの無駄なスケジュールクエリを削減
- 過去に作成されたクエリが一部放置されており、無駄なスキャンコストが発生してしまっていたので原因を突き止めて停止しました
- 副次的なものとしてS3（APIコール）とCloudTrail（APIコールの記録）それぞれのコストも下がったため、当初の想定以上の結果が出ました
他にも細かいリソースの削除、Glueのクロール設定見直しなど細かいことをいくつか対処することができました。
最後に
コスト削減の具体的な事例の紹介はできませんでしたが、この心がまえがなにかの役に立ててば何よりです。
実際に大掛かりなコスト削減を行うことは大変ですが、普段から不定期にでもコスト調査とIssue出しをしておくといざというときに役に立つかもしれないので、ぜひ試していただければと思います。調査時に意外な新機能やコスト外の問題に気づくことができるのでおすすめです。
Discussion