バニッシュ・スタンダードでインフラを担当していますTmaと申します。
前回は「コスト削減の軌跡 Part2」と題しまして、インフラもアプリケーションも変更がないコスト削減の具体例について書かせていただきました。
今回は弊社で具体的に行った施策の中でも、インフラは変更するが、アプリケーションは変更がないパターンのコスト削減について、具体的な内容を書かせていただきます。
不要なリソースの削除、統合
何はともあれ使ってないリソースはアプリケーションの変更の必要がないことは確実なので手をつけやすいです。とはいえ本当に使っていないかを慎重に吟味しないと、実は使っていたという痛いオチになってしまうので、細心の注意を払いたいところです。testとかdevとかのprefixがついてても本番で使われているという事もあるので油断しないように。
CloudFrontやALB, S3のようにアクセスログを出力できるわかりやすいリソースはそれらを調査することで、クローラーや攻撃アクセスを取り除くのが厄介な場合もありますが、ある程度の傾向は見えます。検索するのが若干大変ですが、CloudTrailのログを調査することも不要リソース判断の一助になります。
S3やCloudWatch Logsは容量によってはそれなりのコスト削減になりますし、EIPやCloudWatch Alarmのように削減コスト自体は小さいですが、数字には見えにくい管理コスト削減という観点でも綺麗にしておきたいですね。
ECR, EBS, S3, Cloudwatch LogsなどのリソースはLifecycleを設定して容量を削減することができます。不要なリソースの調査の過程で、一定期間は必要なんだけどなぁというものに対してはLifecycleを設定して今後容量が肥大化しないようにしました。
また、ALBやEc2 InstanceやRDSなどは複数環境を統合することでコスト削減を行うことができます。弊社ではあまり行いませんでしたが、ALBのRuleやミドルウェアの設定、ストレージの相乗りを駆使すれば統合できるようなものもあるケースもあります。特にルール変更でミスをしても被害の小さい開発系は検討の余地があるかと思います。
ECRの最適化
弊社のObserbavilityの戦略として、Datadogを中心にログやトレースの取得を行っています。Fluentbit, DatadogのDocker ImageをSidecarで稼働させており、アプリケーション起動時にこれらのイメージを頻繁に取得するようになっています。
通常Private Subnetで稼働させているこれらのアプリケーションはNat Gatewayを通じてECRにイメージをとりに行くためECR Endpointを設定して通信コストを下げるように設定していたのですが、DatadogやFluentbitなどのパブリックなImageは対象ではありません。
WebだけであればよほどScaleIn/SclaeOutやリリースが頻発しない限りそこまでのコスト増にはつながらないのですが、弊社の場合頻繁に起動するバッチもEvent Bridge経由で起動するFargateで行っているため、コストは無視できない額になっていました。
ここで登場するのがECR Pull Through Cacheです。この機能はパブリックなDocker ImageをECRにキャッシュしてくれるので、一度取得したイメージはECR Endpointを通じて取得することができ通信料削減につながります。
Graviton化
AWSではさまざまなリソースのArm化が進んでいます。リソースのバージョンなどの制限はありますが、Graviton化することでコストが安くできます。可能であれば積極的に採用していきたいところです。弊社では特にアプリケーションの変更も必要なくRDSやLambdaをGraviton化することができました。
ただし、Aurora の g7インスタンスのように同じインスタンスタイプだと値上がりしているケースもあるので注意しましょう。性能が上がっている分インスタンスサイズを下げられる可能性もありますが。
また、最近、Fargate spotもGraviton化されたので、弊社としてもさらにコスト削減を進められそうです。
ログ出力の最適化
CloudWatch Logsにログ出力するだけでそれなりのコストがかかってしまう事を意外と見落としがちです。弊社の例で言うとRDS監査ログやWAFログがそうでした。
もちろん必要なログであれば仕方がないのですが、使わないログ出力のためにコストをかけるのは不毛なので、抑止できるものは抑止しましょう。
RDSの監査ログであれば対象ユーザーによって絞る事も可能ですし、WAFログも出力対象を絞ることができます。ログは必要にならないとそのありがたみがわからないところもあるので、本当に必要ないかはなかなか判断が難しいですが、コストとの兼ね合いを見つつ抑止できるものは抑止しました。
まとめ
今回はインフラは変更するが、アプリケーションは変更がないパターンのコスト削減ということでお届けしました。
次回Part4ではアプリケーションも積極的に変更してコスト削減を行った事例をご紹介できればと思います。
Discussion