コスト削減で重要な「ボトルネックから潰す」「覚悟を持つ」　約60,000ドル削減のため、具体的に実行した6つのこと

コスト削減のために実行したこと1　VPC Endpointの導入

林雅也氏：ここまでどういうふうにコストを削減していくかの方針を見ていったので、それに沿って、実際に「SNKRDUNK」（以下、スニダン）でどのようなコスト削減が行われてきたのかをお話しします。

方針で言っていたとおり、まずはもちろんボトルネックを探すところからです。（スライドを示して）こちらの図は、コスト削減の取り組みとしていろいろ候補を上げてリストアップして、それぞれの削減金額予想をリストアップしたシートになっています。

ボトルネックから減らすということで、支配的な削除金額予想になっているものから優先して進めていこうと話しました。その中でも金額予想としては小さいのですが、サッとできちゃうというものも一緒にやってしまおうというような方針も立てていました。ちなみに右下の注釈にあるように、これは構想段階のシートなので、最終的な実施有無とは少し違うところがあります。

その中でも一番削減金額予想が大きかったものとしては、VPC Endpointを導入していくことなのではないかというものがありました。

なので、まずはVPC Endpointからということになります。ここでスニダンのアーキテクチャを簡単に説明しますが、簡単すぎて何の情報もないかもしれません。スニダンではECS､Aurora､Elasticache、S3といったオーソドックスな構成となっています。これ以降のお話は「こういう構成なんだな」と軽く頭に置いてもらえるとうれしいです。

VPC Endpointの導入の背景に入っていきます。先ほどの図にあったとおりECSが動いているのですが、プライベートサブネット上で動いています。そう考えると、ECSからNAT Gatewayを経由してECRだったりS3だったりの通信がインターネットに出て行っていることが主なコスト増大の原因なのではと考えました。

ちなみに、弊社のECSは、数百MBのコンテナのイメージのPullが大量に走っているような環境です。（スライドを示して）こちらの図はECSのタスクの起動数を監視している1日のグラフなのですが、低い時は35個、一番スパイクした時は150個ぐらいのECS Taskが立ち上がっています。

そして冒頭にお話していたように、デプロイメントは1ヶ月に100回、営業日で割るとだいたい1日あたり5回ぐらいデプロイがされているので、この回数分ECSのローリングアップデートが走り、コンテナのイメージのPullが走っていることになります。

そこで、S3やECRに対するVPC Endpointを作成する取り組みを行いました。プライベートサブネット上のECSがVPC Endpointを通り、ECRやS3に対しプライベート接続ができるようになり、VPC内で通信が完結してNAT Gatewayの料金が下がるともくろみました。これによって削減される通信料などを試算すると、だいたい$50,000ぐらい削減されるんじゃないかと予想して取り組みました。

実際にNAT Gatewayの通信量を一気に削減することに成功しました。これによって$40,000の削減に成功しました。

コスト削減のために実行したこと2　ECR pull through cacheの導入

「あれ？　先ほどは$50,000の試算と言っていたのに、$10,000足りないんじゃないか」と思ってよくよく考えてみると、ECR PublicからのPullが残っていることに気づきました。

（スライドを示して）つまりこのような図になっていたということです。弊社のECS Taskの中には、ECR PublicからPullしているサイドカーのコンテナが2種類ほどあります。そのコンテナイメージに対してはVPC Endpointではなくて、依然NAT Gatewayを通ってインターネットに出て行ってしまっているというところでした。

もちろんVPC Endpointを通るものが大半にできたので一気に削減はされたのですが、まだインターネットに出て行っている部分を試算してみると、予想どおり$10,000ぐらいになったので、「あ、ここが原因だったな」と思いました。

そこで、ECR pull through cacheを導入しました。pull through cacheとはECR Publicをキャッシュしてくれるもので、自前で作ったプライベートECRのレジストリ上にパブリックからのキャッシュを置いてくれるような機能になっています。

プライベートなECRを作って、パブリックのところからPullしてPushしておいてみたいなことをしてもいいのですが、それは自前でやらなくてもよかったりするし、キャッシュ更新される時にイメージタグを更新してくれたりもするので。もちろん自動でイメージタグが変わると困っちゃうことも多いので注意が必要ですが、そのような機能です。

（スライドを示して）ということで、ECRのpull through cacheを導入したらこのようになりました。プライベートサブネット上のECSからの通信はすべてVPC Endpointを通り、ECRやS3に接続されます。そして大元がECR Publicから取ってきているコンテナイメージの場合は、プライベートなECRがpull through cacheを用いてイメージをキャッシュしてくれるようになりました。これによって、プライベートなECR上にパブリックに置いてあるイメージがキャッシュできるようになりました。

ということで、今度こそNAT Gatewayの通信量をさらに大幅に削減させることができました。

予想より大きく削減されて、ここまでで合計で$52,000の削減に成功しました。

コスト削減のために実行したこと3　WAFのログ配信先の変更

では、最初の方針に戻って次のボトルネックを探しましょう。先ほどの図を見てみると、次に大きいのはWAFのログ配信先の変更でした。

AWS WAFは内部にあるログをいくつかのストアに保存することができるのですが、Cloudwatch LogsやS3などが選択可能です。

KinesisのFirehoseに送って、その後いい感じにすることもできます。弊社のスニダンでは、Cloudwatch Logsに保存していたものをS3に変えることを行いました。これによって$2,700ぐらいの削減に成功しました。Cloudwatch Logsに比べるとS3はやはり分析や可視化が難しくなるのでそこには注意しないといけないのですが、弊社SODAの中にはそのような動きというか、ワークロードみたいなものが特になかったので、問題ないと判断しています。

ここまでで$2,700の削減があったので、合計$54,700の削減に成功しました。

コスト削減のために実行したこと4　不要リソースの削除

またまた次のボトルネック探しの旅へ向かうのですが、他にもいくつか細かいコスト削減を行いました。

まずは不要リソースの削除です。これは本当に基本中の基本なので多くは説明したりしないのですが、アタッチされていないElastic IPを消したり、使われていない環境……。ここでいう環境はDev環境とかステージング環境などです。そのEC2やECSやAuroraやElasticacheを削除したりしました。

コスト削減のために実行したこと5　Gravitonインスタンスの利用

次にGravitonインスタンスの利用も行いました。GravitonインスタンスはIntelのCPUアーキテクチャに比べるとコスト効率は20パーセントぐらい向上しているもので、弊社ではデータストア系のみに適用しました。というのも、ECSはARMで動くかの検証が必要なので、いったんPendみたいなかたちになりました。

コスト削減のために実行したこと6　Auto-scaling policyの見直し

そして次に、Auto-scaling policyの見直しも行いました。時間の関係上細かい数値を伝えられず恐縮なのですが、つまりは余分なECSやAuroraのインスタンスが起動しないように、いろいろなしきい値を調整した感じです。例えばStep-scalingのしきい値を調整して、無駄な、必要以上のインスタンスが立ち上がらないように調整しました。

Target-tracking scalingとうまくStep-scalingが同居できないかを検証したり、あとはScheduled-scaling……。弊社のサービスのスニダンは、スニーカーの発売などで負荷が高騰することはある程度予測できるので、スケジュールをしているのですが、早すぎるスケールアウトをしないように調整します。そういうことを泥臭く進めました。

ということで、細かいのも合わせて全体で最終的には$60,000ぐらいの削減に成功しました。

削減後に行なった信頼性やセキュリティへの投資

最後に、ここまでの削減のあとに、信頼性やセキュリティに投資したという取り組みを少し紹介したいと思います。信頼性やセキュリティへの投資という意味だと、データストアのスケールアップ、Security Hubの導入、GuardDutyの導入。こういうことを行いました。

データストアのスケールアップでは、これも細かい検証などを伝えられず恐縮なのですが、全体的にr6gとか、m6gのGraviton系のインスタンスに変更しました。先ほどのコスト削減のところでGravitonの言及があったように、コスト削減も少し含まれてはいるのですが、t3だったElasticacheを変更したりなど、スケールアップしているという観点もあります。

次にSecurity Hubの導入を行いました。Security Hubというのはある評価基準に従ってセキュリティスコアを算出してくれるAWSのサービスになっています。（スライドを示して）真ん中の図にあるように、その評価基準に対する準拠率がセキュリティのスコアとして算出されます。弊社は、57パーセントとまだまだ低いので精進が必要だと思っています。

ちなみにSecurity Hubの評価基準というのは、5種類から選択することが可能です。スニダンでは一番上の「AWS基礎セキュリティのベストプラクティス」のみ有効化しているのですが、これは導入当初が3種類だったというのもあります。

ある程度更新頻度が高いものがこれだったので、他のルールというか評価基準は古い情報もあったりするのかな？　というのもあって、この1つ目のみをいったん有効化しています。今後の対応として、CISも有効化することを検討したいと思っています。

ここでSecurity Hubの仕組みみたいなものを簡単に見てみると、Security HubはAWS Configというサービスから評価に必要な情報を取得しています。そしてそのAWS Configはさまざまなリソースに対して、そのリソース情報を取得して記録してくれるサービスです。このAWS Configは、記録するリソース情報の量だけ課金されるような体系になっています。

ちなみに、今日のカミナシの佐藤さんのセッションにあったAWS AppConfigとはぜんぜん違うサービスなのでご注意ください。先ほど急いでスライドを追加しました。

AWS Configの料金高騰にどう対応したか

ここで脱線したいと思います。AWS Configの料金が高騰したというような小話です。冒頭のスケールアウトの量だったりなどでECS Taskがすごい量立ち上がっていたり、ローリングアップデートがたくさん走っていたりしたことがありました。それによって大量のECS Taskの起動や停止の記録がAWS Config上に記録されていて、AWS Configだけで$15,000ぐらいまで料金が跳ね上がりました。

これにどう対応したかというと、めちゃくちゃシンプルに、記録対象に不要なリソース以外を指定することで回避しました。ただこれは除外しないほうが理想というか、これによってSecurity Hubでうまく評価できない基準とかも出てきてしまうので。スケール戦略の見直しが根本解決になるかなと思っているので、それを今後の課題としています。

ちなみに、現在はリソースタイプごとの除外設定が可能になっています。スニダンが対応したタイミングではまだなかったのですが、2023年6月に「除外をする」という設定ができたので、同じような対応をされる方はこちらの対応をするのが良いかなと思います。

（スライドを示して）つまり、今後はこうできるというところです。先ほどの図ではrecorded resource typesを指定していたのですが、新たにexcluded resource typesを指定できるようになったので、そこに除外したいものを入れることができます。

GuardDuty導入

最後にGuardDuty導入の話をしたいのですが、これはもうめちゃくちゃシンプルで、とりあえず有効化しておけというサービスだと思います。弊社でも、すごく単純に「Terraform」で有効化しただけの感じになっています。有効化して以降、脅威を検知していないのは良いのか悪いのかと考えてしまうのはエンジニアの性かもしれませんが、たぶん良いでしょう。

これを検知してから、どういうアクションを取っていくかの運用体制を敷くなど、そのあたりはまだうまくできていないので、今後の課題といったところです。何か「こうしているよ」という知見がある方がいれば教えてほしいです。