こんにちは、最近 30 MINUTES SISTERS にはまっている、SRE Gの渡邉です。今回で2回目になります。

昨今、AWSのコスト削減が流行っていたりするみたいですが、弊社も時流に遅れることなく？AWSのコスト削減を行ったので、その話を何回かにわけて書いていきたいと思います。

まずは成果から

絶対値はあれなので、数字はないですが、どん

AWSのコストエクスプローラー、償却コスト、サービス別より

5月から12月で、およそ 45% の削減となっております。ってタイトルに既に書いていましたね。

なお、Reserved InstancesやSavings Plansで2、3月に期限が切れるものがあるので、更に削減がされることが想定されています。

はじまり

春の終わり頃に、本部長からコスト削減の話がでてきました。

まぁ暗号資産の相場はわかっているし、公表されている決算の数字だってもちろん理解しているので、そんな話がでてくるのはとっくの想定ずみで、こっちもインフラエンジニア歴はそれなりに長いし、そんなのとっくに想定ずみですよ、ということで、コスト削減は元から考えていたり、仕込んだりしていたのですが、、、、

経営からの要望は、システムの費用で〇〇円くらい削減と、、、、え、それ元の費用の40%くらいなんですが？！

ということで今回の削減活動が始まったのでした。

これが最初のコスト削減の取り組みだったら、まぁすぐに打てるてがたくさんあるわけですが、暗号資産の相場が山あり谷あり、とのことで、前回の谷の時とそれ以降に、既に定番の一通りの削減施策は実施済みなのでした

私がSRE Gに加入する前の話もあって、詳細はわからないところもありますが、以下のようなことをやっていました。

Reserved Instances(RI) : RDSなら常時起動のインスタンスは100%
Savings Plans(SP) : 開始してすぐに導入。Compute Savings Plansを 3 years で購入して、70%くらいのカバレッジ
EC2 Spot Instances : WEBアプリケーションサーバのスケーリング分はすべてSpot Instances
EC2 Instance Type : 割安なAMDインスタンスも活用。コスト効率の悪い古いタイプはほとんどなし
S3 : ログなどはライフサイクルで Glacier Deep Archive に変換
Kinesis Data Firehose : サーバのログ転送で利用すると高額なので廃止してログアグリゲーターとしてlogstashを自前で運用
などなど

これはなかなかにハードルが高くなっているやつです。

とはいえ、良いこともあります。経営から40%の削減をしろ、って数字をだして指示してくるということは、数字感と、それが意味することの覚悟があるということを意味するからです。

これがもし、出来るだけ削減しろ、なんて話だと、まぁ色々考えても何かと理由つけて実現しないとか、フリーランチでなんか削減できると思っているとか、そんなですが、今回は明らかに違う、ということです。

まぁこれがあれば勝ったも同然？、とまでは言わないにしても一番重要なところは抑えられている、といっても過言ではないでしょう。

戦略と作戦

まず一般的な節約系の削減だけでは絶対に無理な目標です。これは前述の通りすでにそういったことは一通りやっているので余地が少ないというのもありますが、そもそも絶対的にそれでは足りないというのが現実です。

大きく分けて3つのカテゴリーにわけてやっていきます。

キャパシティなどを再検討することでの削減
アプリケーションの改修による削減
節約系の積み上げ

見ての通り、上のほうが効果が大きいですが、より大きな判断が求められるものとなります。

アプリケーションの改修は、細かい積み上げ系のチューニングではなくて、アーキテクチャとかデータ構造レベルでの大きな話のやつです。これはコインチェックのSRE Gはインフラ特化型に近いので、SRE Gで進めるのは無理なのでアプリケーション部門で進める必要があります。

また制約条件として

RI, SPをかなり購入している

があります。

おっと、コスト削減にあたっては、大事なことを先に確認しないといけないですね。

PLなのかキャッシュフローなのか？
PLなら除却ありなのか？

これが違っているとどうもピント外れな削減になりがちなのでとても大事。

今回はPLで除却はなしとのことだったので、やっぱりRI、SP購入分の削減については期限を待つしかなさそうです。

話を戻して、進め方としては、「キャパシティなどのリスクを再検討することでの削減」の検討・調整を行いながら、「アプリケーションの改修による削減」をアプリケーション部門にすすめてもらう。

で細かいやつも積み上げていく、ですね。

キャパシティなどを再検討することでの削減

これは詳細は省かせて頂きますが、大きく言えば、暗号資産の相場の山を前提にしたままになっていたものを、現状にあわせて再検討した、ということになります。

大前提として、もちろん過度なリスクを追って削減する、ということはしないのは当然です。

とはいえ、こういったことは経営のコミットがなければなかなか難しいので、「はじまり」に書いたような、経営の覚悟、はとても大事な要素になってきます。

序盤のEC2 Instances や RDSの削減はこれによるものが大きいです。

これにより、Savings PlansとRDSのカバレッジは100%となり、一時的にはかなりの量が余っている状態になりました。

この余った分を利用して、大規模なコスト削減を進めつつも、いろいろな案件の検証などを同時に進めることが可能となりました。

参考：

Billing and Cost Managementの、Savings Plans カバレッジ

Billing and Cost Managementの、RDSのカバレッジは、、、これ、価格関係なしに時間だけで計算するから、よくわからないですね。

この仕様はどうにかしてほしいものです。

アプリケーションの改修による削減

これも色々とありますが、自分が主体でおこなったものではないことから、あまり詳細把握できていないので簡単に。

一番大きなものは、ElastiCache for Redisの縮小になります。

Coincheckのシステムのセッションの作り上、どうしてもセッション管理用のRedisのメモリが肥大化する問題が以前からあり、大きなElastiCache for Redisのインスタンスを利用していたのですが、こちらアプリケーションの改修により大幅に肥大化を抑制することができ、5月の段階では大きな割合を占めていたElastiCacheのコストが、9月には非常に少なくなりました。（この期間からもわかる通り数ヶ月にわたる大きな改修でした）

この問題に対しては、ElastiCache for Redisのデータ階層化インスタンス(r6gd系)を使うという選択肢も考えられましたが、アプリケーションの改修で肥大化が抑制できるということで、そちらのほうがより確実なのでアプリケーションの改修を選びました。