こんにちは、DevBrandingのellyです。5月20日に配信した「AWSコスト倍になっちゃった！〜削減への道のり〜」の様子をご紹介します。
今回はITストラテジーチームとSREチームから2人のゲストを招いて、freeeで実際に起きたAWSコスト増加の事例をもとに、気がつけば増えるインフラ費用の無駄をどのように見つけ、コスト削減していったのか、実話のストーリーを話してもらいました。
miry:写真左上。2015年入社。ITストラテジー。全社のITツールのコスト管理やIT戦略の策定を担当。
nakagawa:写真右上。2020年5月入社。SREチームエンジニア。基盤の更改やクラスタ管理効率化を担当。
のぶじゃす (@noblejasper): 写真右下。ラジオパーソナリティ、2017年に中途入社。mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。しゃべりたがり。声が大きい。
AWSコストが予算計画の2倍に
―miryさんはITストラテジーで予算を管理していて、nakagawaさんはSREでインフラの管理や信頼性の担保のための基盤作りをしていますよね。今回はどうやってコストを下げるかというお話がメインですが、まずは「コストが倍になっちゃった」というのはどういうことだったんでしょう？
miry:昨年末くらいからEC2環境で動かしていたプロダクトをEKSに移行するというプロジェクトが動いていました。
6月と比べて7月のコストが突如倍になっていて、「これはなんだ？」と思って確認したところ、EKS移行で旧環境と新環境が並行稼働していたんですね。並行稼働してるから上がっているんだ、と思ってそのままにしていたんですが、8月に「移行が完了したので落としました」と連絡が来たのに9月になっても倍のまま推移していて「あれ？」とざわざわしだすということが起きていました。
―想定としてはEKS移行で元のサーバーと新しいサーバーが2つ動いているから、倍かかっても仕方ない、と思っていたことですね。 それはmiryさんだけじゃなくて、関わってるみんなもそうだと思ってたってことですよね？
miry:そうです。
―蓋を開けてみたら全然下がってなかったんですね。倍のままだということが分かって関係者たちはどうしたんですか？
miry:そのときはまだヤバイって感じはなくて、というのも毎月ITストラテジーとSREチームのみなさんで目線合わせをする定例を行っていて、すでにコスト削減施策をSREの皆さんで進めてもらっていました。なので時が来たら下がるだろう、と思っていました。（笑）
―でも、予測は外れてたんですね。
miry:そうなんですよね。毎月実績をチェックしてたんですけど、全然下がらなくて。見通しを引き直して、このまま使い続けたらヤバイぞ、と分かったのが11月頃ですね。
でもその頃はまだ現場の温度感とは少し距離があって、1月頃にQ単位でやっているCFOやCIOにコストと予算の差を共有する会があって、そこで「このままだととてもヤバイです」という報告をしたところ、全社的にコスト削減施策に振り切ろうと舵を切ることになりました。
―freeeでは珍しいトップダウン感がちょっとありますね（笑） プロダクト開発でユーザーにマジ価値を届けるのが僕らの本懐なので、今回のように別の軸足を置かなきゃいけない場合は、全社から降りてくることもあるという例ですね。
SREチーム的には全社から舵を切るという方向性が示されるまで温度感が上がらなかったのは何か理由があるんですか？
nakagawa:実際にはコスト削減対応っていうのは徐々に進めていて、旧環境も落としたし、インスタンスタイプを見直したりというちょっとした変更をちょこちょこやっていたので、SREとしてはまだ緊急チームを作ってなんとかしなきゃいけないみたいには思っていませんでした。freeeではQごとにOKRを引いて動いていますが、そこにコスト削減がメインでは入ってなかったというのも理由のひとつだと思います。
―何かのついでに行うような温度感で進んでいたけどプロジェクト化しませんか？という話になり、燃え始めたんですね。
miry:燃え始めるって言うか、いきなり大炎上でしたよね。（笑）
nakagawa:温度感的には、はい、そうですね。（笑）
コスト削減の道のり
―具体的にどのようにコスト削減を進めていったんですか？
nakagawa:時系列的でいうと、まず最初に並行稼働してるインスタンスなどを全て落としたんですが、それでもやっぱり戻らない事が分かりました。
次に、移行した先のクラスターで何かリソースを使いすぎてるんじゃないかということで、まずは一番影響が少ないようなロールのプロダクトのインスタンスタイプをちょっと減らしたんですね。それでちょっとは下がったんですけど、まだ目標金額には届かないという感じでした。
さらに、EKS上に存在するコンテナに割り当てているリソースやメモリ、CPUを減らして、なるべく一つのインスタンスの中にたくさんのコンテナを積みました。集約率を上げられて、1台のインスタンス上にいっぱいコンテナを入れることができたんですけども、やっぱりまだまだ目標金額には届きませんでした。
その次に確認したのが、不要となったノードをどんどん減らしてくれるCluster Autoscalerというツールで、その設定の修正を行ったらいい感じにインスタンスを減らしてくれるようになっていきました。
―一つのクラスターにあるポッドの数の最適化、Cluster Autoscalerの設定の修正で無駄なものがちゃんと落ちて目標値に戻ったんですね。ちなみにいまの話は期間で言うとどれくらいなんですか？
nakagawa:並行稼働をさせたのが8月くらいなので、そこから2月くらいまでずっと対応してた感じですね。
―半年以上動いていたプロジェクトなんですね。落としたことによって障害や不具合は起きていないんでしょうか？
nakagawa:大きな不具合は起きていませんが若干パフォーマンス劣化が起きていたので、ここをこれ以上減らしたらやばそうだというのをモニタリングしたり、エラーデータを見ながら悪化して来たら戻すみたいな対応をしていました。
―不具合を起こさないために気を付けていたことはありますか？
nakagawa:なるべく影響度を少なくするために、例えば高価なインスタンスタイプをちょっと安価なインスタンスに変える場合、どうしてもCPUのアーキテクチャとかも変わったりするので、性能劣化がないかを見るために、全体のインスタンスのごく一部だけインスタンスタイプを変えてみて、そこを通るリクエストと元々のインスタンスを通るリクエストのデュレーションを比較しながら、問題ないかを確認して徐々に安価なインスタンスのタイプに変更していきました。
―複数の施策を事故なく進めつつ、コストを削減できたのはすごくいいですね。コスト削減プロジェクトには何人くらい関わっていたんですか？
nakagawa:私を含めて4人くらいが実際に手を動かしてコスト削減したり、調査したりしてくれていました。
―miryさんは削減プロジェクトの中では、どういう役割だったんですか？
miry:1月頃からはデイリーでSREのチームとMTGを設けて、今動いている施策から削減の見通しを立てていました。その施策を入れるといつまでにどのくらい下がるのか毎日計算してSREの皆さんに共有して、「今だとこれくらいしか下がらないです」と伝えたり、金額の実績ベースでグラフを出して「ここは減らせませんか？」と提案したり、そういった関わり方をしていました。
―具体的に言われたら、エンジニアとしても「ちょっとそれ考えてみるか」となりますもんね。
miry:あとはAWSさんの本社の方にも「何か下げれないですか？」「探してくれませんか？」ってお願いしたりとか（笑）そんなことも裏でしていました。
―miryさんは提供元とのコミュニケーションも対応してるからそれもできるんですね。たしかに他社の事例とかも参考になりそうですしね。
いまはコスト削減の目標金額に達していると思いますが、今後もこの状態を維持できるんでしょうか？
nakagawa:基礎となる指標がきれいに最適化されている状態なので、利用状況によって増えたりはするんですけれども、今までみたいに突発的にコストがかかってしまう状況は避けられるんじゃないかなと思っています。
―未来への良い投資ですね。
コスト削減対応を進める中での気づき、苦労した点
―コストが増えている要因を調べる中で難しかったことはありますか？
nakagawa:そうですね、やっぱりCluster Autoscalerに対する理解っていうところが全然足りなかったです。
いままで、Cluster Autoscalerってノードの上に乗っているポッドがいなくなったら、基本的にはそのノードはリソースを全然使ってないから落としてくれるんだろうなっていう理解でいたんですけど、その仕様が全然違っていて、ある条件が引っかかるようなポッドがいた場合には、そのノードは改めて落とさない、他のノードを落とすみたいな条件になっていることが分かりました。
今回だと、CoreDNSというEKSクラスターの中の名前解決するための重要なコンポーネントがあるんですけど、デフォルトだとPDB（PodDisruptionBudget）という設定が未設定なんですね。
これが未設定だとCluster AutoscalerはCoreDNSが乗っているノードを落としてくれないんです。CoreDNSは名前解決するので、結構なポッド数が色んなノードに散らばっていて、そのノードが全然落ちてくれないっていうことが分かりました。
PDBは、クラスター内のCoreDNSの内、何％を落としてもいいよみたいなざっくりとした設定なんですが、その設定を新たに追加することで想定した通りにノードが段々減っていきました。特に夜間や何もリクエストが少ないような時間帯でも、2,30台ずっと何もしないノードがいたんですが、それがガクっと減ってくれるようになったのはすごい気づきになったなと思ってます。
―原因を実際のサーバーに調べに行くというよりは、仕様書をもう一回読み直す方が効果が出やすいんですね・・・難しい。
コスト管理するうえで大切なこと、今後の展望
―コスト管理していくために大事にしたいことや今後の展望を教えてください。
miry:コストって実績が後から出てくるものなので、そのタイミングでは温度感が下がってしまっていたりすることが多いと思うんですね。見通しなどを常にリアルタイムでアップデートして、とにかく早い段階で検知できることが重要だと痛感しました。
AWSの例で言うと、コストエクスプローラーという機能があって、毎日グラフをリアルタイムでどれくらい使ったか出してくれるので、それを毎日確認するということをやっていました。
あとは、やっぱり不要なものが多いという話が結構出てきたので、不要なものが多いということは開発者の人たちも不要なものがたくさんある中でリソースを探したりインスタンスを探したり、本質的なところじゃないところに時間をかけてしまうことにもつながるので、定期的にゴミ掃除のような動きは必要だなと思いました。
無駄遣いを減らして、開発チームは必要な分だけ使っているということを経営陣が把握してくれれば、常に監視しようとか管理しようとかそういう気持ちにはならなくて、どんどん信頼貯金が貯まっていくと思うんですね。
そうすることによってコストを開発チームに任せてOKって思ってもらえて、それで初めて開発チームの皆さんも潤沢に投資できるような環境が作れると思うので、ITストラテジーとしてはそういう環境を作っていければと思って日々仕事しています。
―めっちゃいい話ですね（笑）信頼関係があって、やりたいと言ったときにどうぞと使わせてもらえる関係性を作るのはとても大事ですね。
配信中には視聴者のみなさんからも「データの可視化重要」「パフォーマンスとコストの落としどころを決めることができるかどうかが大事そう」などなど共感のコメントも多くいただきました！
▶次回freee Tech Night
7月15日（金）19:00～「これからの『freeeのセキュリティ』の話をしよう」
freee-tech-night.connpass.com
▶今回のイベントのアーカイブ（録画）
