年末大掃除と来年の抱負（AWSの大掃除とfreeeのFinOpsの未来）

メリークリスマス！！この記事はfreee 基盤チーム Advent Calendar 2023 の最終日（25日目）の記事です。

はじめに

SRE 統制チームのYです。今回は、最終日ということもあり、年末大掃除と来年の抱負と題して、AWSの大掃除とfreeeのFinOpsの未来を紹介します！ oracleとYの共同執筆となり、大掃除はoracleが、来年の抱負はYが担当します。

1. 年末大掃除（AWSの大掃除）

SRE 統制チームでは CFM (Cloud Financial Management) の取り組みを進めています。コスト効率を上げる手法の一つとして、不要なリソースを削除することが挙げられます。年末というタイミングに合わせて AWS でも大掃除(不要リソース掃除)を行っています。

今回の大掃除の対象

今回の大掃除の対象は、検証用アカウント上のリソースです。

計画された AWS の利用であれば SRE や専門チームが構築し、構成の管理やモニタリングも一緒に行われますが、それ以外の利用ケース、特に検証やちょっとした実験などの場合は、エンジニア個々人が検証専用のアカウント上に構築し、その管理を行います。構成管理を必須としていないため、野良リソースになりやすく、不要になったリソースが残っていることがあります。

掃除の方法

とても地味ですが、コストエクスプローラーからサービス別のコストを確認します。上位のサービスの利用タイプを確認します。例えばEC2が最も利用コストが高い場合は、サービスをEC2に絞り、更に使用タイプで group by を行い、利用タイプ別のコストを確認します。それが利用されているかどうかを確認し、利用していなければ削除を行います。

確認の手間

利用しているかどうかの確認は実は地味に手間がかかります。まず、リソースが利用しているかどうかは簡単に判断ができません。仮にメトリクスから利用していないように見えていても、作成者に確認すると「しばらくすると利用します」ということもあります。また、リソース名やタグから作成者を特定することができないことがあります。 cloudtrail にはリソースの作成者が記録されていますが、特定するのに手間がかかります。さらに、特定できたとしても、すでに退職している場合もありますので、その際上長にも確認したりします。

今回は短時間に削除作業を行うため、確認の手間を減らすように事前に社内のSNSツールで削除対象と条件を通知しています。

掃除してわかった事

ネットワーク関連のリソース、NAT Gateway、VPC Endpoint、EIP、ELB などのリソースが残っていることが多いです。メインのリソースと違ってコストに対する意識が薄く、コストがかかること自体を知らないかもしれません。実際はちゃんと課金されているので、意識を持って利用する必要があります。

作ったという意識が薄いリソースも多く残りやすいです。 k8s から作成されたPVC(ボリューム)やイングレス(ELB)などは、作成者が意識していないことが多いです。

今後の対応

コスト最適化を進めるために、リソースの作成者もコスト意識を持つ必要があります。それには学習と文化の醸成も必要で時間がかかります。

今まで検証用アカウントをみんなで共有して利用しているため、誰がどれくらい利用しているのかが把握しにくい状態でしたが、今後は team や個人単位でアカウントを発行しコストを含め各自で利用状況を把握できるように検討しています。さらにタグポリシーを設定し、タグを付けることを必須とすることで、リソースの作成者や用途を特定しやすくすることも検討しています。

2. 来年の抱負（freeeのFinOpsの未来）

freeeでは、様々なクラウドサービスを積極的に活用しており、その中でクラウドの利用コストが課題となっています。この課題に対処し、最適な費用管理を実現するために、FinOpsの導入が求められつつあります。

本章では、現在のfreeeにおいてSREが担当するインフラコスト*1の管理における課題と、今後の取り組みを記載します。FinOpsの詳細な説明は本文中で省略させていただきますので、FinOpsの概要やフレームワークに関心をお持ちの方は、以下のFinOps Foundationの公式ページをご参照ください。 www.finops.org

直面している課題

予実の乖離
freeeでは、予実管理において期初に策定した予算に対して、定期的な予実差の確認及び調整を行っています。しかしながら、予実差が生じ、その原因を明確に把握すること及び予算精度の向上が課題となっています。
コストの妥当性判断
予実の乖離が課題となっている中で、予実の乖離があっても問題のないケースや予実の乖離がなくても問題になるケースがあります。
例えば、前者は、企業が期初の計画より圧倒的成長を遂げた場合、後者は、システム構成や利用方法に無駄があり最適化できていない場合です。そこで、コストの妥当性を的確に判断する必要がありますが、目標の粒度や目標と実績を照合するための手間が発生しています。
コスト分析の困難さ
各サービス毎の全体の費用は把握可能ですが、何に、どの費用が、どれくらい使用されているか簡単にブレイクダウンできる状態にはなっておらず、調査に時間がかかることもさることながら、調査できる切り口が限られています。
例えば、AWSでは、Cost ExplorerやAWS CURとAthenaでアカウント別の費用やタグ別の費用を都度調査していますが、完全なアカウント分離はできておらず、タグの欠如、およびタグ表記の一貫性が不足しており、意図した結果が得られない問題に直面しています。
コスト最適化
今回のAWSの大掃除もそうですが、予算超過等で必要に迫られた場合や切りが良いタイミング、気づいたタイミングで不要リソースを削除したり、設定を見直したりしており、常にコストが最適化されているとは言い難い状況になっています。

課題解決のための来年の取り組み

計画段階であり、必要性の検討は引き続き行っていきますが、以下は課題解決の手段として予定している取り組みです。
これらの手段は、FinOpsの6つの原則を参考にしつつ、freee独自の視点で実践していく予定です。全てを一年で完了させることは難しく、またFinOpsの原則に完全に準拠しているわけではありませんので、ご了承ください。

準備
まず、上記の課題解決にあたり、各クラウドサービスのコストや使用量をAPIを用いてモニタリングツールやデータウェアハウスに取り込みます。
予実の乖離の解決
FinOps data should be accessible and timely及びTeams need to collaborateを実践していきます。
- モニタリングと迅速な検知
  - 実績のモニタリング
    各クラウドサービスのコストを、freee会計やfreee人事労務等のプロダクト単位や環境毎（本番環境、ステージング環境など）で可視化します。
  - 予実差のモニタリング
    各クラウドサービスのデータだけでなく、策定した予算をデータウェアハウスやモニタリングツールに反映し、実績だけでなく、予実差のコストモニタリングを行っていきます。
  - Anomaly detectionの活用
    AWSではすでに活用していますが、他のクラウドサービスにおいてもモニタリングツールやデータウェアハウスに備わっている機能でAnomaly detectionを有効化し、コスト増加の異常値を迅速に検知し対処できるようにしていきます。
- 予算精度の向上
  各クラウドサービスのコストと相関が強い指標を洗い出し、予算作成時に相関が強い指標と関連させることで予算精度を向上させます。例えば、GithubやCircleCIではfreeeのエンジニア数やfreeeの営業日数等であり、AWSの本番環境ではプロダクトKPIやシステムトラフィックです。また、予実管理に使用する指標を予算同様データウェアハウスやモニタリングツールに反映します。
- 予算の自動作成
  指標や過去実績、現在の使用実績、組織目標に基づき、予算を自動生成できるようにすることで、予算修正案を迅速に提供できるようにしていきます。予算シミュレーションできる機能もあれば尚良いでしょう。
コストの妥当性
Decisions are driven by business value of cloudを実践します。
- コストの指標と目標の策定
  SLI/SLOの考えをコストに取りいれ、CLI/CLO*2を組織のステークホルダーが必要としている粒度で策定します。この指標は、組織KPIや各プロダクトのKPIが紐づいたものにします。
  例えば、「四半期の予実差を+-5%以内に収める。」や「インフラ全体のコストは組織のARRの5%以下とする」、「CircleCIの1営業日あたりの消費クレジットは開発者一人あたり5000クレジット以下とする」等です。
- 指標のモニタリング
  策定した指標を必要とされる迅速さで可視化しアクセスできるようにします。また各クラウドサービスの指標を一元化し、アクセシビリティを向上します。
  例えば、freee会計のコストダッシュボードでは、freee会計が使用している各インフラコスト（AWSコスト、CircleCIコスト、Githubコスト等）、freee会計のトータルのインフラコスト、freee会計のKPI（ARR、売上、ユーザー数等）、freee会計のKPIとインフラコストの比率（ARR比率や売上比率）、CLI/CLOを表示させ、日や月毎の推移を閲覧できるようにします。
コスト分析
- AWSではSCPとタグポリシーにより、タグを必須化しコスト分析に使用するタグの設定漏れや表記のゆれを防ぐことで分析しやすくします。また、アプリケーションのログやトラフィックに応じてコストを按分できるようにします。
- GithubやCircleCI等は、APIでデータを収集し、プロダクト単位やユーザー単位等でコストを可視化できるようしていきます。
コスト最適化
A centralized team drives FinOps及びTake advantage of the variable cost model of the cloudを実践し、リアクティブな最適化からプロアクティブな最適化へシフトしていきます。
- SREの統制チームがFinOpsを推進
  契約、料金、割引の最適化を一元化し、規模のメリットを最大限に活かすとともに煩雑な事務処理から開発チームを解放します。
- 定期的に実施するコスト改善施策の計画と運用
  現在不定期で行っているコスト改善施策を定期的に行えるよう施策と実施計画を策定し、運用します。
  例えば、AWSでは、毎月末には使用頻度の少ないリソースのリストアップと削除等です。リアクティブなコスト対策にはなりますが、プロアクティブなコスト最適に向けたアプローチを実施していくうえでfreeeにおいては必要な工程です。
- 不要リソース削除の自動化
  策定したコスト改善施策を自動化によって運用し、自動化された改善施策については、実行間隔を短くし極力常に最適化された状態を目指していきます。
  例えば、AWSの検証用アカウントのリソースについて、作成から30日を経過したものを日時でチェックし削除する等です。手動運用では毎日チェックすることは膨大な工数が発生してしまいますが、自動化することで毎日実行するが可能となります。
- プロアクティブなコスト最適なシステム設計支援
  freeeの非機能要件を満たしたコスト最適なシステムテンプレートを準備し、開発チームへ提供します。
- コストが大幅に増加する利用の制限
  SCPやAWS Configにより特定の操作や使用できるインスタンスタイプを制限する等の意図せずコストが発生してしまうオペレーションを制限していきます。これによりコストの意図しない増加を防ぐとともに開発者が安心してクラウドサービスを使用することができるようにします。