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

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

この記事は [atama plus Advent Calendar 2023](https://qiita.com/advent-calendar/2023/atamaplus) の4日目です。


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



# コスト可視化と管理体制の構築 
### 取り組み前はどんな状態だったか
- リザーブドインスタンスなど、金額感の大きいコスト削減策は入れ始めていましたが、後どれくらいコスト削減の余地があるのか把握は出来ていませんでした。
- 各クラウドについて、細かいコスト構造を常に追っている人はいませんでした。毎月の請求書金額をみて、その増減の要因について詳細な説明は出来ず、都度調べるといった無駄がありました。
### 体制構築後
- コストの変化を週次、月次で追うようにしました。
Cost Explorerを使ってもいいのですが、より変化に気づきやすいようにQuickSightでもグラフ化しており、週次で大きく増えたものがないかSREチームで確認するようにしています。
先週から何が増えたかがひと目で分かるようになったので、意図せずコストが増えた部分に気づきやすくなりました。

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

![CUR.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/521073/cb50ab3d-4f8b-dbf7-2d31-c16e10efd779.png)



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


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


## Aurora / RDS

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

### セカンダリリージョンのインスタンス停止
Auroraを使っているプロダクトでは、BCP観点から、メインリージョンとは別のリージョンにクラスターを作成し、リアルタイムにデータのレプリケーションを行っています。(Aurora Global Databaseの機能)
[Auroraはストレージ層とコンピュート層が別になっている](https://pages.awscloud.com/rs/112-TZM-766/images/01_Amazon%20Aurora%20%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E6%A6%82%E8%A6%81.pdf)ため、データのレプリケーションのみ行いたい場合はインスタンスを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](https://aws.amazon.com/jp/blogs/news/under-the-hood-lazy-loading-container-images-with-seekable-oci-and-aws-fargate/)の導入も行った為、スケールアウトに要する時間も以前に比べて短縮しています。
結果として必要以上にタスクがスケールアウトすることがなくなり、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回ほどに分けてコスト削減を重ねてきました。結果として、半額程度までインフラコストを下げることに成功しています。