SRE 統制チームの oracle です。 この記事は freee 基盤チームアドベントカレンダー の16日目になります。 今回は AWS の コスト統制についてお話させて頂きたいと思います。
先日「 AWS の組織移行をしました 」という記事の中で AWS の組織移行のために SRE 統制チームが発足されたと紹介しました。実はこのチームは AWS のコストについても責務を負っています。つまりコストの統制も含まれているということになります。
課題
AWS のコストがずっと上がり続けています。
freee は組織として、また提供しているサービスはまだまだ成長している段階です。その分利用が増えて、AWS のコストが上がること自体は特段問題ではないと思います。 ただ、確度の高い状態で「今のコストは必要なコストです」と言えるかというとそうではありません。
実は SRE はこれまで明確にコストコントロールを行う責務を負っていませんでした。自主的に行っているコスト対策以外では、財務チームが見ているデータからトレンドが予算を大きく超える可能性があると判断した場合、コスト削減の要請を受けて対応するケースも多くありました。
すべての AWS リソースは SRE 経由で作成さているわけではなありません。SRE がメインで見ているのはサービスを行っている SDLC (ソフトウェア開発ライフサイクル) の関連リソースとなります。依存関係があまりないリソースについては専門の担当チームにおまかせしております。そのため把握しきれていないものもあります。
そのような状況では AWS のコストの最適化は難しいテーマの一つだと思っています。
- Q1. AWS のリソースは誰が利用していますか
- A1. 各サービスチーム
- Q2. AWS のリソースは誰が構築していますか
- A2. 多くは SRE チーム、一部専門の担当チーム
- Q3. AWS のコストは誰が見ていますか
- A3. SREチーム、財務チーム
- Q4. AWS のコスト予算は誰が決定していますか
- A4. 財務チーム
- Q5. AWS のコストの利用が適正かどうかは誰が判断していますか
- A5. SREチームがある程度判断している
- Q6. AWS のコストの最適化は誰が実行していますか
- A6. SREチーム
このように複数のチームが関わっていて、担当している領域、コストに対する感度、意識、責任がそれぞれ違っています。 AWS のコストを高いレベルで最適化するには各チームが AWS のコスト体系を十分に把握できいて、お互いに連携する必要があると思います。
ただ、AWS のコストの基本は、コンピューティング、ストレージ、トラフィックとなりますが、AWS の各サービスでぞれそれ個別の料金体系を持っています。 それらを正確に把握することは難しいと思います。 公式から提供されている試算ツール https://calculator.aws を以てしてもなかなか難しいのではないでしょうか。 calculator.aws
また、AWS には購入オプションがいくつか用意されています。どれを選択するのが良いのかは規模や、計画によって変わりますので、自分たちで判断する必要があります。 そしてAWS は従量制が基本となりますので、自分たちの現状を常に把握している必要もあるかと思います。
つまり、組織間の連携の仕方、コストに対する知識、運用計画、コスト状況の把握をどのように行っていけばよいのかを考える必要があります。
これまでの SRE とこれからの SRE
これまで、 freee の SRE チームはリソースの構築、その利用状況の確認、そしてコストの最適化を行っていました。 ただ明確なコストコントロールの責務を負っていないので、微妙な立ち位置のなかで行っているコスト最適化の効果を最大化しにくいところがありました。 AWS の利用コストが増加していく中で、ちょっとしたことがコストの増減に大きく影響するようになってきました。 コストのコントロールの重要性は SRE 統制チームの発足時に再認識され、SRE がオーナーシップを以て行うことが最もスムーズで、その中でも SRE 統制チームが主導することで責務を明確化にし、より高い視座を持って進められるという判断のもとに SRE 統制チームのミッションの一つとなりました。
これまで行ってきたことや今取り組んでいること、今後やろうとしていることを混ぜながら紹介させて頂きます。
コンピューティングの最適化について
パフォーマンスの効率を上げるにはサービスチームと連携して調整する必要があるので一朝一夕でできるものではありません。 RI (Reserved Instance) と SP (Savings Plans ) は SRE チーム単体で行いやすいコスト最適化手法となります。おそらく一般的にもポピュラーかと思います。 基本的に Term は 1年としています。３年後の予測が難しく、また毎年登場する新しい Instance Type はコストやパフォーマンスが上がっているのでそれらに乗り換えし易いようにしています。 その分割引率とはトレードオフとなります。
EC2 については Spot Instance と Savings Plans を利用してコスト最適化しています。 非プロダクション環境では信頼性、可用性を重視しない環境のリソースはコスト効率が一番よい Spot Instance を利用しています。 プロダクション環境でも spot instance をうまく扱えられると良いですが、まだそこまで至ってないので Savings Plans を利用しています。 RI と比べて適用条件が緩いのがメリットとなります。
EC2 以外のデータストアサービスは RI となります。 非プロダクション環境のデータストアサービスは利用していない時間帯については stop 対応しているものは stop を行い、プロダクション環境などの常時起動のインスタンスは計画をして RI の購入を行っております。 (Instance Type については Graviton を選択できるものについては徐々にシフトを行っています。)
アカウントレベルで環境を分離できていれば、AWS からのレコメンドを精査するだけで良かったのですが、 同僚の hamaa さんの記事の中で言及されていますし、私の前回の記事でも触れたように、環境をアカウントレベルで分離できていないサービスがあるため、
developers.freee.co.jp 購入する際に少し労力を必要とします。
Reservations の Coverage Report の Reservations coverage breakdown から On-Demand cost を降順にソートし、起動時間なども注意しつつ Instance Type をリストアップし、 それを現在利用しているリソース一覧と突き合わせて購入対象を洗い出しています。非プロダクション環境は利用しない時間は stop しているため、RIの購入対象に含めないようにする必要があります。
基本的にRI/SP のカバレッジは 70% 以上を目標として Budgets に設定をしています。 下回ったときは ChatBot から Slack に通知するようにしていて、確認したら追加購入の計画を立てるようにしています。
freee では開発環境を EC2 で利用しているケースも多くあります。以前は常時起動をしていましたが、 Instance Scheduler を導入して、就業時のみ起動するようにスケジュールしたことによりかなりのコスト削減ができるようになりました。
ストレージの最適化について
EBSについては gp3 が登場してからは EBS の多くを gp3 に移行してコストの節約を行っております。(現在は特に意識しなくともデフォルトで gp3 のタイプになっています。)
S3 については Storage Lens を有効化し、分析しながら適切なストレージクラスへの移行を徐々に行っています。歴史的な経緯で、 S3 運用についてのルール化などが整備しきれていないときに、とりあえず S3 にあげているものも多く、オブジェクトの種類の分類、整理に時間要しているところです。
トラフィックについて
トラフィックについては実はあまりケアできていない部分となります。
Region to Internet と Inter AZ、 Region to Region が全体の中で上位を占めています。このあたりについては 18日に同じチームの Y さんの記事の中で言及されるますのでご期待ください。
またトラフィックに関連した話題で、Public IPv4 の課金 が始まります。そのために IPAM (IP Address Manager )を有効化し、現在の Public IP の利用状況を分析して課金が抑えられるように対策を練っております。
コストの分析
AWS でコストを把握したい場合に一番最初に出てくるのは Cost Explorer ではないでしょうか。意味のある分析を行うにはやはり AWS の各サービスのコスト体系を理解している必要があります。さらに詳細な分析を行うには CUR (Cost and Usage Reports)と Athena or QuickSight との連携が必要となってきます。地味で時間がかかる作業だったりします。
AWS が提供しているCID (CLOUD INTELLIGENCE DASHBOARDS) というソリューションがあります。backend ではまさに CUR と Athena / QuickSight を利用しています。慣れない方からすると導入するのは少々ハードルを感じるかもしれませんが、地道にコスト分析するのとでは比べ物にならないくらいにコストに対する解像度が上がりますので、まだ導入されていなければ強くおすすめ致します。
CID の Demo 画面の画像となります。
ほかには freee では AWS のテクニカルアカウントマネージャー（TAM）と定期的に Meeting を行っております。Meeting の中で TAM 観点からのコストレポートを一緒にレビューをすることでもコストの分析を行っております。 これらのコスト分析の結果を経理/財務チームと共有しています。
コスト意識について
freee では CID を導入してまだ日が浅いですが、社内では広く公開する試みをしています。SRE がコストコントロールを行っていきますが、サービスチームもコストチームを持っていることに越したことがありません。 コストを可視化することで全体のコスト意識を高めて行きたいと思っています。
また、AWS TAM に相談して、freee のエンジニア全体に対してコスト勉強会を開催して頂きました。AWS の方からコストに対するベース知識をとてもわかり易く教えてもらえました。多くの方に参加して頂いて大盛況でした。実は皆さん関心が高かったことを知れました。
コスト統制の道
コストの可視化、コストの分析、コストの最適化が螺旋状に繋がっているようにするにはコストコントロールを明確なミッションとして持つ必要があると感じました。
SRE 統制チームでは AWS のコスト以外に IT ツール群 Datadog、github、CircleCI などのコストの最適化も進めています。
明日は同僚の Chore さんの記事となりますのでご期待ください。
