開発生産性を落とさないAWSリソース管理
はじめに
コスト削減活動でコスト削減したのに、日々の運用の中で気づかないうちにコストが増加していたなんてことはないでしょうか。
弊社でも過去に「誰からも管理されていないリソース」や「オーバースペックで利用しているリソース」といった、いわゆる 「不要なリソース」 が長期間増加し続けていたことがありました。
この苦い経験を踏まえ、「不要なリソース」を増やさないためにどのように管理したらよいかとても悩みました。
本記事では、弊社のコスト管理の考え方と運用方法について紹介します。
ターゲット
AWSのコスト削減を検討・実施している方
この記事で伝えたいこと
厳しいルールを設けず自由度を保ったAWSリソース管理を選んだ理由
弊社のコスト管理方法
弊社では、技術横断チームがほぼ毎日AWS Cost Explorerを確認し、気になったコストが有れば利用している開発チームに確認をしています。
また、slackとスプレッドシートを活用し、一時的に利用されている各リソースの使用期間や用途を管理し、使用期間が過ぎたリソースは申請者へ自動通知され、無駄なコストが発生しづらいしくみを構築しています。
悩んだ点
弊社では2023年6月からコスト削減を実施し40%程のコスト削減に成功しました。
しかし、今後「不要なリソース」が増えないように環境をどのように維持・管理するかが課題でした。
ルールを厳しくすれば「不要なリソース」の増加を防げますが、厳しすぎるとエンジニアの開発生産性を下げてしまう可能性がある
という点でルールの厳しさのバランスに悩みました。
決断したこと
私たちはスタートアップであり、市場へ製品を届けるスピードが何よりも重要です。
しかし、コスト管理のためにルールを厳しくし過ぎると、エンジニアの開発生産性を落としかねません。
このジレンマに直面し、エンジニアの創造性と自由度を維持しながら、効果的なコスト管理を実現する方法を模索しました。CTOの久良木とも議論を重ねた結果、「開発者を信頼し、一定の自由度」 をもたせたAWSリソース管理の仕組みを構築することを決断しました。
もちろん、これは開発者のAWSリソース利用時のモラルに依存するため不安要素もありました。
しかし、開発者のコスト意識を高めるための啓蒙活動を行うこと、
ある一定の自由度を維持する仕組みを構築することでこの不安要素を小さくできると判断しました。
コスト管理のルール
下記は弊社のコスト管理の大枠のルールになります。
実際のルールは申請が必要な環境やリソースなど細かく決めています。
リソース利用期間 | 利用手続き方法 | 利用可否条件 |
---|---|---|
1週間以上 | slackワークフローから利用申請手続きを実施 | 技術横断チームからOKが出れば利用可能 |
1週間未満※1 | 技術横断チームのチャンネルに一言利用する旨を伝える | 技術横断チームからの許可待たずに利用可能 |
コスト管理の仕組み
下記の図は現在運用しているコスト管理の仕組みです。
AWSリソースの利用申請流れ
slackワークフローの画面
リソース利用申請書・兼管理表
- このスプレッドシートが申請書と管理表を兼ねています。
- GAS(Google Apps Script)が毎朝このシートで 「利用終了日」 の日付が過ぎていて、「利用状況」のステータスが "利用中" のものをチェックし申請者に通知します。
1年運用した結果
上記のルールで運用して1年が経ちましたが、ルールは当初から大きな変更はありません。
たまに申請し忘れるメンバーもいますが、技術横断チームが把握していなくコストが増加し続けるといった状況はありませんでした。
これは、「利用者の方々がコストへの意識とモラルをもって利用してくれている」 結果だと思います。
運用が成功した要因として考えられるもの
開発者のAWSコストへの関心啓蒙:
エンジニア定例会などで技術横断チームからコスト削減活動の報告を行い、普段から開発者とのコスト削減・管理関連のやり取りはslackのオープンチャンネルで行うようにしました。
これにより、そのやり取りを見た他のメンバーにもAWSコストへの関心を持ってもらえるよう取り組んできました。
ルールが定着するまでは細かく管理:
AWSリソース利用のルールが定着するまでは、毎日AWSCostExplorerの画面を確認し、
申請なしで利用されているリソースがあれば都度対象チームに確認し必要な対応をしていただきました。
開発者との信頼関係の構築:
常に開発チームのスクラムに参加し、開発時のインフラ・CI/CDや技術横断チームでしか対応できない困り事や相談を受け付けました。
優先度の高いものはチケット化し、迅速に対応することで信頼関係を構築しました。
まとめ
弊社の開発部の状況に合わせて「自由度を保ったAWSリソース管理」をする方針でコスト管理の仕組みを構築・運用してきましたが、これが最適解とは思っていないですしこれから開発人数、サービスが増えるにつれて今の運用ルールもアップデートしていく必要があります。
ただ、どのようなルールになっても根底のあるのは利用者(開発者)との信頼関係だと思っています。
ここまで記事を読んでいただきありがとうございます。
最後に、一言だけ弊社の紹介をさせてください。
弊社は「歳を重ねることが楽しみになる社会の創造」を目指しているスタートアップです。このミッションを実現するために、迅速かつ効率的なサービス開発を行っています。
Discussion