14
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

atama plusAdvent Calendar 2023

Day 4

atama plusが2023年に取り組んだクラウドインフラコスト削減を振り返る

Posted at

こんにちは、atama plusという教育系スタートアップでSREチームオーナー/EM的な仕事をしている石井です。

この記事は atama plus Advent Calendar 2023 の4日目です。

atama plusでは、昨今の円安の影響を受けて、インフラ関連予算と実績の間に乖離が出始めていました。そこで、AWSを中心に、為替影響を受けるサービスについて大幅なコスト削減対策を行ってきました。今年行ったインフラコスト削減の取り組みについて紹介します。

コスト可視化と管理体制の構築

取り組み前はどんな状態だったか

  • リザーブドインスタンスなど、金額感の大きいコスト削減策は入れ始めていましたが、後どれくらいコスト削減の余地があるのか把握は出来ていませんでした。
  • 各クラウドについて、細かいコスト構造を常に追っている人はいませんでした。毎月の請求書金額をみて、その増減の要因について詳細な説明は出来ず、都度調べるといった無駄がありました。

体制構築後

  • コストの変化を週次、月次で追うようにしました。
    Cost Explorerを使ってもいいのですが、より変化に気づきやすいようにQuickSightでもグラフ化しており、週次で大きく増えたものがないかSREチームで確認するようにしています。
    先週から何が増えたかがひと目で分かるようになったので、意図せずコストが増えた部分に気づきやすくなりました。

  • 月次の変化については、予算との乖離も合わせて確認するため、AWSアカウント毎に予算管理を行っているスプレッドシート上に集計し、AWS以外のインフラやSaaSと合わせて予実管理を行うようにしていました。
    このスプレッドシートをSRE外のチームと合同でコスト確認を行うMTGを設定し、月次で開催しています。

CUR.png

各種施策

個別のコスト削減策について紹介します。

Cost Anomaly Detectionを有効にする

週次のコスト確認会でコスト変化については追っていますが、突発的な変化に早く気づくために、Cost Anomaly Detectionを有効にしました。
一定額以上の変化があった場合は、Slackに通知が飛ぶようになっています。
これにより、開発チームが大きなサイズのDBインスタンスを立ち上げたことや、大きなサイズのファイル転送をリージョン超えで実施したことにすぐに気づくことが出来ました。

Aurora / RDS

不要Snapshotの通知

数テラバイトのデータを持っているため、思いの外snapshotのデータにかかっているコストの影響が大きい状態でした。
特定のTagが付いてないスナップショットがあれば定期的にSlack通知するLambdaを作成し、不要なSnapshotの削除を行いやすいようにしました。
特別に残しておきたいSnapshotのみ手動でタグを付与して運用しています。

セカンダリリージョンのインスタンス停止

Auroraを使っているプロダクトでは、BCP観点から、メインリージョンとは別のリージョンにクラスターを作成し、リアルタイムにデータのレプリケーションを行っています。(Aurora Global Databaseの機能)
Auroraはストレージ層とコンピュート層が別になっているため、データのレプリケーションのみ行いたい場合はインスタンスを0台に設定してクラスターを運用することが可能です。(セカンダリリージョンのクラスター配下にインスタンスが0台の状態でも、データのレプリケーションが行われます)
セカンダリリージョンのインスタンスを0台にすることで、インスタンスコストを大幅に削減できました。

Backupの整理

AWS BackupによるSnapshotの世代数や保存間隔を見直すことにより、1/4程度まで削減しました。
過去時点のDBデータを見ることが、極稀にあるため、長期間保存用にAWS Backupを設定しているのですが、必要以上に多く残していたり、PITR可能な自動スナップショット保持期間と重複するバックアップを無駄に保管してしまっていたものを削減しています。

ECS

Arm移行

弊社ではFargateを利用しており、元々Savings Plansで利用料は下げていましたが、さらにCPUアーキテクチャをArmに切り替えました。
(Savings Plansでは、CPUアーキテクチャの指定は無いため、前払いがあっても期中で切り替えが可能です)

開発環境のサーバー自動停止

夜間に自動でタスクが0台になるようにEventBridgeを設定しました。
また、サーバを利用する際はSlackからAWS Chatbot経由でLambdaを呼び出すことで、タスクを起動するようにし、利用していない期間はコストが発生しないようにしました。
社内には20弱の開発環境があるのですが、コストを1/3まで削減することができました。
Chatbot経由にすることにより、AWS環境を普段触らないQAやUXデザイナーのメンバーの人でも操作できるようになっています。

タスク起動の高速/安定化

サーバーがスケールアウトした際に、各ECSタスクのメモリに持っているキャッシュが空の状態から始まることによってレスポンスタイムが悪化していました。一度に多数のタスクが立ち上がるとレイテンシーが上がるため、オートスケールする際のしきい値(CPU利用率)にかなりバッファを持たせて緩やかにスケールするようにしていました。
そこで、サーバー起動時にキャッシュをpre-loadし、キャッシュが載った状態でALBと繋がるようにすることでレスポンスタイムが悪化しなくなり、スケールアウトのしきい値を引き上げることができました。
合わせて、Seekable OCIの導入も行った為、スケールアウトに要する時間も以前に比べて短縮しています。
結果として必要以上にタスクがスケールアウトすることがなくなり、ECSのコストを引き下げることができました。

ECR

Pull Through Cache Repositoryを設定

DockerHubなどのPublic RepositoryからイメージをPullする際にはNATを経由するため転送コストが都度発生してしまいます。
Pull Through Cache Repositoryを有効にすることで、イメージに更新版が無い限りはPrivate Rpositoryからのpullになり、VPC Endpoint経由で通信されます。
これにより、NAT Gatewayの転送量が半分程度に減りました。

NAT Gateway

開発環境のNAT GatewayをNATインスタンスに変更

もともと本番、開発環境で極力ネットワーク構成を揃えていた為、開発環境においてもVPCに関しては3AZでの可用性を担保する構成になっており、AZ数分のNAT Gatewayが存在していました。
NAT Gatewayはマネージドである分、管理は楽ですがコストは高いので、あまり可用性を求めない開発環境はEC2でNATインスタンスを立てる構成に戻しました。

S3

ワークロードアカウントのログ保存期間を短縮

監査目的で各AWSアカウントからのログを専用のAWSアカウントに集約して保存しているのですが、各々のAWSアカウント上にもログが残っており重複保管されていたため、ワークロードアカウントのログ保管用S3バケットにてライフサイクルを設定して削除するようにしました。

その他

AWS Migration Acceleration Programの利用

(恒久的なコストダウンではありませんが、金額としてかなり大きい額を補填できるので紹介します)
弊社は昨年度までアプリケーションサーバーの稼働環境としてHerokuを使っていたのですが、今年の前半に全面的にAWSへの移行を行いました。(もともとDBはAWS上にあったので、Herokuで動いていたAPIサーバーやバッチ実行環境をECSへ載せ替えました)
その際、Migration Acceleration Program(MAP)というプログラムの申請をAWSに対して行うことで、移行対象の利用量の何割かをクレジットとして還元してもらうことができました。
MAPの多くのユースケースではオンプレ環境からAWSへの移行がメインだと思いますが、他のクラウドからの移行にも利用できるということは意外と知られていないかもしれません。
https://aws.amazon.com/jp/migration-acceleration-program/

Google Cloud

弊社では一部プロダクトにてFirebaseやBigQueryを利用しており、Google Cloudで特にコスト削減効果が大きかった施策も紹介します。

Cloud Loggingのログ保存ストレージをBigQueryに変える

Google Cloud利用量のうち、大半がLoggingという状態でした。
Cloud Loggingの独自ストレージであるログバケットへ保存するSinkは無効にしてしまい、BigQueryに保存するSinkを作りました。これにより、Cloud Loggingのコストが0になり、Google Cloudの利用量が半額近くになりました。

終わりに

大きくコスト削減しようとする中で、最初のうちはSavings PlanやReserved Instanceなど、構成に手を入れずにすぐ出来る施策で削減効果も多いところからやってしまいがちですが、あまりカバレッジ率を高くし過ぎると、その後コストダウンを行うことで利用率が100%を下回ってしまうことになるので、ほどほどの量を予約しつつ、並行して各種削減施策を進めると良いと思います。
また、早いうちにコスト構造の可視化に着手しておくことで、各種施策の削減効果や、思わぬコスト構造の変化に気づくことができ、いち早く対応を取ることができます。
atama plusでは昨年度からSREでOKRを立て、3回ほどに分けてコスト削減を重ねてきました。結果として、半額程度までインフラコストを下げることに成功しています。

14
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?