はじめに
AWSリソースを運用していてよくある状況として、
「これもう使ってないのに課金されたままやん！」 「このリソース誰か使用しているの？」 「このインスタンスの使用ルールどうなっているの？」
という状況があるかと思います。
チーム内で業務の棚卸しをした際に、これら状況を見直すべき、これまでほとんどやってこなかったAWSリソースの見直しを行うことになりました。
AWSリソースの使用状況を可視化し、チーム内の暗黙の共通認識で決まっていたルールを明文化して、運用・保守体系を整備することが目的です。
合わせて、「せっかくならコスト最適化と絡めて実現していこう」 と思い、進めていくことになりました。
3行自己紹介
- 自社開発SaaS企業でアプリケーション開発 / インフラ基盤の構築・最適化・運用・保守（俗に言うSRE）
- AWS認定資格9個保持（AWS CLF, SAA, SOA, DOA, SAP, DOP, SCS, DBS, DAS）
- 好きな言葉 ： 「全ての人に可能性がある」
ひとことで結論
AWSリソースの見直し・コスト最適化を行い、リザーブドインスタンスの導入無しで、前月比約10%（年間換算¥40~50万円） のコスト削減を行なった
▼ やったこと
0. コスト調査と既存リソースの洗い出し
私自身もチーム内でどれだけAWSコストがかかっているのか正確には把握できていなかったため、まずは全体的なコストの把握とどのリソースにどれだけのコストがかかっているかを算出した
CostExploerから課金されているAWSリソースの一覧を取得し、直近6ヶ月の使用状況とコストを分析した。
すると、現在は使用していない未使用リソースや、無駄に冗長なアーキテクチャ構成となっているものなど、コスト最適化な状態とは言えない現状が浮き出てきた。
特に、自チームの現状では、EC2とRDS（ともにオンデマンド）に関するリソースで全体コストの約70% を占めていることがわかったため、これら2つのサービスを中心にコスト最適化を図っていく必要がある
1.事例収集
AWSのコスト最適化に取り掛かるにあたり、私自身もコスト削減に関して 点としての知識しかなく、全体最適を考慮しながら線で推進していくということに、知見があまりなかったので、徹底的に情報収集をしようとまずは、以下のようなことを行なった
- 他社事例収集
- クラスメソッドのイベント参加
- 某メガベンチャーのSREチームのエンジニアリングマネージャーに話聞く
様々な情報を得て、知見を蓄えていく中で、コスト最適化を行うポイントとして大事なことは、以下のような当たり前かつシンプルなことをきちんと精度高く行えるかということだと学んだ
コスト最適化のポイント
- 無駄に稼働させない
- 未使用リソースは削除
- コスト意識を高く持つ
2. インスタンス稼働時間の見直し
- 使用中のインスタンスの一覧を洗い出し
- 未使用インスタンスは削除
- 稼働時間の見直し
- 開発に使用するインスタンス群は
Lambda✖︎EventBridgeを使用して自動起動停止を行い、9:00-21:00の運用となっているが、そもそもそんなに使用しないインスタンスは、使用する時だけ都度起動する運用に変更
- 開発に使用するインスタンス群は
- 祝日も考慮したインスタンスの自動起動・停止
【Tips】
これまで、Lambda✖︎EventBridgeでインスタンスの自動起動・停止を実現していたが、EventBridgeSchdulerの登場により、EventBridge単体でスケジューリングができるようになった
3. インスタンスサイズ・ボリュームサイズの変更
- AWS ComputeOptimizerを使用して、最適なインスタンスサイズ・ボリュームサイズの可視化
- オーバースペックのインスタンスについては、インスタンス・ボリュームサイズの変更を実施（グレードダウン）
※ AWS ComputeOptimizerを使用するにはOrganizationコンソールから使用を有効にする必要がある
4. 未使用リソースの削除
CostExploerから課金対象となっている一覧を見ることができるので、そこからリソース一覧を確認し、未使用リソースを洗い出し対応
- EC2, AMI, EBS, スナップショット（EBSボリューム・RDSの手動スナップショット）
- AWS Trusted Advisor でアイドル状態のリソースを検出
- ElasticIP
- 課金体系が独特なので特に注意が必要
では、未使用リソースをそもそも発生させないようにするベストプラクティスは・・・
AWSアカウントを分割する
アカウント分割には、以下のようなメリットがある。
- 権限の管理が楽になる
- 部門やシステム単位でコストを管理できる
- 細分化されることで、使用リソースの管理・視覚化が容易になる
5. ボリュームタイプ変更
- EBSボリュームタイプを
gp2→gp3へ移行- 同性能で比較した場合、コスト削減
- クレジッドの枯渇問題がなくなる
【Tips】
2022/11/9にAWS公式でRDSもgp3に対応することが発表されたので、今後はRDSもgp3への移行を実現したい
6. バックアップライフサイクル
これまでAMI, EBSスナップショットを含むバックアップに関する取り決めが無く、ルールが明文化されていなかった
そこで、バックアップ方針を確立し、バックアップライフサイクルを決定する事で、不要なバックアップが発生しない構造を作った
【具体的に行なったこと】
- バックアップ方針の策定
- AMI, スナップショットどちらから復元するか
-
AWS Bacukup,LifeCycleManagerどちらでバックアップを取得していくかなど
- バックアップ手順のドキュメント化
-
LifeCycleManagerを使用したスナップショットの自動取得とスケジューリング
7. ストレージ・ログのライフサイクル
ログストレージには、CloudWatchやS3を使用しているが、両者に共通して、ライフサイクルに関する取り決めが無く、こちらもルールが明文化されていなかった
そこで、ログのライフサイクル方針を確立することで、余分なストレージコストが発生しない構造を作った
【具体的に行なったこと】
- ストレージライフサイクル方針の策定
- S3ライフサイクルルールの設定
- 不要バケット・オブジェクトの洗い出し
- バケットごとのアクセスセキュリティ向上
- CloudWatchログ保持期間設定
▼ やらなかったけど検討したこと
Graviton2への移行
EC2インスタンスは基本的に最新世代のほうがコスパが良い。
従来のIntel製のプロセッサを使用したEC2よりも、AWSが独自に開発したArm製のAWS Graviton2プロセッサ搭載のEC2は前世代比で約20%のコストダウンを実現できる
Gravitonへの移行を検討し、提案を行ったが、現環境がEC2→ECSへの移行期であること、既存環境へのGravitonの適用はリスクがあることから移行はとりやめることにした。
これから新規にインフラ環境を構築する場合などは、Gravitonを搭載したインスタンスで環境構築することでよりコスト最適に近い環境が実現できる（AWSも推奨）
リザーブドインスタンス（SavingPlan）への移行
AWSのインスタンスにはある一定期間の使用を確約する代わりに、大幅なインスタンス料金の削減が可能になるリザーブドインスタンスという購入オプションがある。
AWSのコスト最適化を考える上で、まず1番に検討することだが、今回は、現環境がEC2→ECSへの移行期であることやECSでの必要スペックが未確定なことから、リザーブドインスタンスの使用は考慮せず、とりあえずはオンデマンドでの運用とした。
また、AutoScalingグループ（オンデマンド + スポットインスタンス）を使用した構成もコスト最適ではあるが、現環境への需要予測から不要と判断し、見送ることにした
コスト最適化の結果
全体のAWSコスト
~2022/7/20ごろ取り組み開始~
前月比：$-243（約10%削減)
年間削減コスト：¥40万~50万（為替¥140換算）
| 日付 | EC2 ($) | RDS ($) | EC2その他 ($) （ELB,EIP,Nat,etc.） |
・・・ | 合計コスト($) | 為替 | 合計コスト(¥) |
|---|---|---|---|---|---|---|---|
| 2022/7/1~ 7/30 | 1195 | 923 | 836 | ・・・ | 3839 | 133 | 517514 |
| 2022/8/1~ 8/31 | 1130 | 889 | 667 | ・・・ | 3596 | 140 | 504701 |
EC2, RDS使用量（稼働時間）の変化
- EC2： -863時間（約9%削減）
- RDS： -88時間（約3%削減）
| 日付 | EC2 (h) | RDS (h) |
|---|---|---|
| 2022/7/1~ 7/30 | 10478 | 2795 |
| 2022/8/1~8/31 | 9615 | 2707 |
運用で今後やりたいこと
- コスト最適化継続の項目作成と定期実行
- 月１回でAWSコストを共有する時間作る
- コストモニタリングアーキテクチャの設計
- 使用状況をレポート化し、CSVで出力。S3に保存し、Athenaで集計・分析。Re:dashでダッシュボード化して、Slack上でコストを参照できるようにする
- コスト配分タグの活用
- サービスごとにコストを把握
- すべてのリソースにコスト配分タグをつけるようにする
- AWS Configを使用して、配分タグのルールを義務付ける
- 定期的なTruted Advisorの実行を行い、アイドル状態のリソースを監視
コスト削減において最も重要なこと
コスト削減にあたり、どの事例でも共通して述べられていたこと かつ 自分自身で体験して感じたこと
それぞれのプロジェクトメンバーが、コスト削減を自分事として捉えること
さいごに
コスト最適化の活動を通して、新たな気付き・学びがありました。
PJメンバーが共通して使用するリソースを誰かが1人で管理しようとするのは限度があり、やはり難しいです。
各々のメンバーがコスト意識を高く持ち、リソースの使用に繋げた行動していくこと求められます。
ただ、やはり意識するだけでは日々薄れていってしまうものです。
仕組みを通して意識づけ・自動化・実現できるようにサポートし、運用していくことが大切だと感じました。
私個人としては、SREとしてこれまで誰もやってこなかったようなことや、誰もやりたがらないような領域に対して、情熱とエネルギーを持って取り組んでいきたいと思っています！
参考資料
参考
ベストプラクティス
他社事例