新サービス開発で右肩上がりになってしまったAWSコスト　“塵も積もれば山となる”インフラコスト削減策

もともとはインフラを担当していた松浦隼人氏

松浦隼人氏（以下、松浦）：オーティファイの松浦から、当社でのAWSのコストの削減の事例について発表したいと思います。よろしくお願いします。

今日のトピックは、タイトルのとおりですが、オーティファイでAWSのコストを見直すきっかけになったことと、その時の見直しの手法、それから当社にとってインパクトのあったコストの削減策について紹介したいと思います。

まず自己紹介からします。オーティファイの松浦と申します。今、機械学習とQAのチームのエンジニアリングマネージャーをしていますが、もともとインフラを担当していたという経緯で、私はここに立っています。

趣味は翻訳です。（スライドを示して）ここにあるような本を翻訳しているので、もし本屋さんで見かけたら手に取っていただければなと思います。

インフラの構成を見直し、テスト実行に応じたコスト構造にした

最初にオーティファイの紹介をちょっとしたいと思いますが、当社は、テストを自動化するプラットフォームを提供しています。

プロダクトは大きく分けると2つあります。1つ目は、「Autify for Web」というWebアプリケーションをテストするツールです。こちらは、ブラウザ上でマウス操作をするだけで、コードを書かずにエンドツーエンドテストが誰でも作れるという製品になっています。

もう1つのプロダクトが、「Autify for Mobile」です。まったく同じようにモバイルアプリケーションをコードを書かずにテストできるツールです。これらの製品を提供しているのが私たちオーティファイです。

Autify for Webは、3年前、2019年ですね。もう4年前になりますかね、そうか……3年半以上前になりますが、2019年にサービスを提供し始めました。

サービスの開始当初は、お客さまの数にコストが比例して、あまりテストを実行していないのにコストがかかるという構成だったので、これを大幅に見直して適切なコスト構造にするというのが、最初の時の課題でした。

（スライドを示して）その結果出来上がったのが、今もほぼ同じかたちで続いているこちらのアーキテクチャです。このシステムがすべてAWS上で動いているのが当社のシステムの状況です。

簡単に説明すると、見てもらうとわかるとおり、サーバーは大きく分けると3種類あります。お客さまがアクセスしてテストシナリオを作ったり、テストの実行を開始したりするためのWebサーバーがあります。

その裏側には、ワーカーと呼ばれるサーバーが待ち受けていて、Webサーバーがテストを開始した時に、これがデータベース上に保存する情報を取ってきて、テストの実行を開始します。

テストを実行開始した時にどこに対してどこでテストを実行するかというと、ブラウザであったりモバイルアプリケーションだったりするわけで、それがこのテストデバイスと書かれている3つ目のレイヤーになります。

ここに対して、ワーカーのサーバーが、「マウスをクリックしろ」とか「テキストを入力しろ」というコマンドを投げてテストを実行することで、テストを実行します。

最後に、その結果を「S3」のバケットに入れるという流れでシステムは実行されています。

このワーカーとテストデバイスのところを「Fargate」に完全に移行して、テストが開始される時にコンテナを立ち上げて、終わったら捨てることによって、コスト削減とセキュリティの面の2つを両立しました。（スライドを示して）こんな感じでコスト最適化したのが、3年前です。

コスト最適化により、売上増＝インフラコスト増の構造になった

これで、テストの実行回数が増えたらインフラコストも増える構造になったので、お客さまにたくさん使っていただければ基本的には売上も増えて、インフラコストもそれに比例して増えるので、もうあまりコストのことは意識しなくてもしっかりと売上に比例するかたちになりました。

どちらかというと、たとえコストの削減施策は後回しになったとしても、まずはお客さまが喜んでテストを回してくれるような仕組みを作ることで、コスト増も自然にカバーできるようになったというかたちです。

ただ、それだけだとまずいので、請求書をクラスメソッドさん経由に切り替えると全体のコストが5パーセントカットされるというすばらしいプランに切り替えることによって、5パーセント安くなるということがありました。

Savings Plansはよくあるコスト削減の方法だと思いますが、以前はあまり積極的になっていませんでした。これはなぜかというと、Fargateを使っていたのですが、いろいろ事情があって「EC2」に乗り換える可能性が常に存在していたので、買いたいけれど買えないという状況が続いていました。

というわけで、そんなにコストを大きく意識していなかったというのはちょっとおかしいのですが、基本的には何もしなくてもコストが増えるという構造ではありませんでした。

Autify for Mobileの開発が本格化した途端コストが増加

ただ、急にこのコストのグラフが急激に右肩上がりになってしまった時がありました。2021年10月にAutify for Mobileという新しいサービスをリリースしたのですが、その開発が本格化した5月ぐらいから急にコストが増えてしまいました。

これはなぜかというと、開発用インスタンスを起動したり、リリース後はお客さまが少ない状態なので、すごくコスト効率が悪いサーバーの使い方をしないといけなかったり……それから、実は2022年の初頭は、Autify for Webのほうでいろいろな障害がありやや大きめのリソースをけっこう割り当てていたため、がんがんコストが増えてしまいました。

というわけなので、このAutify for Mobileの開発が原因なのはわかるのですが、これをきっかけに、全体的なコストを見直そうとなったという経緯があります。

2022年8月から本格的にAWSコスト見直しを開始

これは、マイナスともプラスとも取れるのですが、当社はクラスメソッドさんを通しているので、AWSのコスト削減ツールの一部が使えないんですね。

それもあって、私たちはこのクラスメソッドさんのダッシュボードからダウンロードできるCSVのファイルを基に、スプレッドシートを作って一つひとつ優先順位付けしていったという、けっこう泥臭い感じのことをしました。

ちなみに当社は、日本とアメリカのリージョンを両方ともけっこう使っているので、それぞれのリージョンでどういうリソースがあるかを書いて、コスト見直しをどうできるかをスプレッドシートに一つひとつ記入していって、優先順位付けしていきました。

コスト削減の具体策　トラフィック削減

ここからがコスト削減の具体策です。ワークロードによって、どれがインパクトがあるかには差があると思いますが、当社に一番効いたのは、トラフィックを削減することでした。NATゲートウェイを通るトラフィックが課金対象になるのをみなさんもご存じかと思いますが、当社の場合、歴史的な経緯からIPを固定して外にトラフィックを出したいという希望があり、ほぼ全トラフィックがNATゲートウェイを通過していたので、トラフィックの課金が大きかったです。

これを防止するよくある方法は、VPCエンドポイントの設定で、これはきちんやっていた……と思い込んでいただけで、実は日本のリージョンではきちんとやっていたのに、アメリカのリージョンでは中途半端な状態になったままでした。これがけっこう大きいところだったので、すぐに設定して削減しました。

また、歴史的経緯からNATゲートウェイを通過していたのですが、よくよく精査してみると動的なIPでもいいものがあったので、そういうものに関してはセキュリティグループを適切に設定した上で、パブリックサブネットに置いて、動的なIPを使うことによりNATゲートウェイを通らないようにしました。これでかなりの削減ができました。

コスト削減の具体策　Intelligent-Tieringの有効化

2つ目に大きな削減ができたのは、S3の使用に関してです。当社の場合、テストの実行結果をスクリーンショットとして保存するので、この画像データがかなりの容量を食います。

古いものはあまりアクセスされないのですが、実は全部Standardのバケット、Tierに保存していました。これも無駄があったので、Intelligent-Tieringを有効にして、あまりアクセスされないInfrequent AccessはTierのパケットに移されるようにしました。

ちなみにこれ、実行されたことがある方ならご存じかもしれませんが、すでに存在している、Standardバケットに存在しているデータが多い時は、このIntelligent-Tieringを有効にした時に、（スライドを示して）こんな感じでデータの移動に伴う課金が発生します。9月28日に移動が発生したということで、課金がここでものすごく大きくなるので、これはご注意ください。

ただ、全体として見ると、ここで1度大きな課金が発生しても、その後削減される金額を考えると、全体としてはペイします。

コスト削減の具体策　EC2・RDS関連

あとは、あるあるだとは思いますが、EC2・RDS関連でいうと、インスタンスタイプをダウングレードしたり、EBSボリュームをダウングレードしたりしました。

インスタンスタイプは特にRDSですが、CPU使用率やメモリの使用量にかなり注意しないと、容量不足になってしまいます。

ただ、EBSボリュームに関しては、当社だけというか、BtoBのサービスを提供している当社だと、アクセス量が実は多くなく、gp2、gp3でも十分だということがわかったので、最初はio2を使っていましたが、データベースのEBSボリュームをダウングレードしました。

コスト削減の具体策　ログ関連の見直し

けっこう大きかったのが、（スライドを示して）このログ関連ですね。「CloudWatch」を当社では使っているのですが、CloudWatchにけっこうなんでもかんでも送りすぎていたというところがありました。

調査がとてもやりやすいので、CloudWatchに送ることが悪いわけではないのですが、必要そうだから送っておくとなると、コストがかかってしまうということですね。なので、削除したものもありました。

あとは、リアルタイム性がけっこう低い、常に実行されているものを見たい、Webアプリケーションのログみたいに常に最新のものを見たいわけではない、検索の必要がない場合は、CloudWatchに送らずS3に保存すると劇的にコストが安くなるので、見直しをすることによって、CloudWatchのコストも下げることができました。

コスト削減の具体策　「Datadog」の見直し

余談ですが、私たちは監視に「Datadog」を使っているのですが、Datadogも、ログをけっこうがんがん送っていました。

Datadogにログを送ると、監視の項目と関連付けてログを見られるので非常に便利なのですが、CloudWatchよりもさらに高いので、ここもけっこうコストがプラスになります。なので、CloudWatchで見られるものはDatadogに送らないなど、得意分野を分けて使用量を削減しました。

あと、監視項目も停止したり間引きしたりして、Datadogのコストも併せて削減しました。

その他、細かな改善策

細かい改善でいうと、「ECR」の不要なイメージを削除したり、ライフサイクル設定を入れて削除したり、「Packer」を使っているのですが、途中で失敗したインスタンスが残っているのを削除する仕組みを入れたりしました。

BIツールでコストを可視化した

併せて、コストの可視化はけっこう大事ですね。それまで、クラスメソッドさんのダッシュボードで可視化はされていたのですが、BIツールで可視化することによって、ほかのビジネスKPIと一緒に見られるようにしました。さらに、インフラコストが売上の何パーセントなのかをトラッキングすることにより、これを最小化しようという取り組みをしてきました。

その結果、AWSコストは、この取り組みを本格的に始めた9月から劇的に減り、さらに、売上の増加に対してAWSコストの増加の幅が小さくなったことで、だいぶ改善が進みました。

（スライドの）右側が、こAWSのコストと売上の比率ですが、これを右肩下がりにしていくというのをエンジニアリングチームの目標にしているというのが今の取り組みです。

今着手していること

ここまで、今までやってきたことですが、今着手中の項目がいくつかあります。例えば、リソースへのタグ付けなどを行っています。

これによって、コンポーネントごと、リージョンごとなど、当社にはAutify for WebとAutify for Mobileという2つのサービスがありますが、そのサブコンポーネントごとのコストがすぐわかるようになります。

当社だと、インフラのデプロイには「Terraform」を使っているので、ここでけっこう簡単に付与できます。今7割ぐらい完了していて、かなり精度を高く、コストが出せるようになってきているので、非常に便利です。あとは、Savings Planの購入を進めたりしています。

また、冒頭にFargateを使っているとお話ししましたが、EC2の「EKS」に移行しようとしていて、まさに今進行中です。

これは、当社独特の理由もあるとは思いますが、テストを実行するというワークロードにおいて、どちらかというとCPUよりはメモリのほうが重要なんですね。

仮想マシンやコンテナの上でブラウザを起動したりモバイルアプリケーションを起動したりする時にメモリのほうが大事で、メモリが多くてvCPUが小さいコンテナが欲しいのですが、Fargateの場合、この2つのメモリとCPUの割合がある程度固定されているのでこれができないんですね。

なので、メモリをたくさん積んだEC2インスタンスを用意して、そこにたくさんコンテナを詰め込むほうが効率的なんですね。

あとはコンテナキャッシュが効くなど、いろいろあるので、これを進めています。実は今週から本番移行をちょっとずつ有効にしてきて、今少しずつ広めていて、問題なく、むしろパフォーマンスは上がっているというのが今の状況です。

コスト可視化と定期的な見直しが大切

ということで、まとめに入りますが、基本的には、売上とコストが比例するシステム、つまり、売上が立たないのにそこにサーバーがあるだけでコストを使ってしまうみたいなものは選択しないというのが基本です。

それにあぐらをかいていると痛い目に遭ってしまうので、やはり定期的に見直しするのと、あとは常にコストを可視化しないといけないということがすごく学びで、今まさにそのシステムを全力で作っています。

余談ですが、おさらいを兼ねて、AWS Solutions Architect（※正式名称は「AWS Certified Solutions Architect」）の試験を受けたのですが、コスト管理に関する問題がいっぱい出てくるので、試験を受けないまでも、勉強するだけでテクニックとしてすぐ使えるものがいっぱいあるので、お勧めかなと思いました。

最後、試験の宣伝みたいになっちゃいましたが、当社ではそんなことに取り組むエンジニアを募集しています。それから、テストでお悩みの方は、Autify for Webとfor Mobileもお使いいただければと思いますので、ぜひお申し込みいただければと思います。

以上です。ありがとうございます。

タグを分ける時に念頭に置いていることは？

司会者：松浦さん、発表ありがとうございました。「Slido」に、質問が3件ほど来ているので読んでいきたいと思います。

1つ目ですね。「タグ付けの粒度はかなり悩むところだと思いますが、参考までにどのぐらいの粒度でサブコンポーネントを分類したのか教えてほしいです」と来ておりますが、いかがでしょうか？

松浦：先ほど、当社の場合はリージョンを複数使っているとお伝えしたのですが、リージョンとそれからAutify for WebかMobileかということと、その次のグレードぐらいまでのコンポーネントまで分けるようにしています。

タグを分ける時にどういうふうにするか、何を念頭に置いているかというと、「価格のプランを作る時に参考になる情報は何か？」を念頭に置いてタグ付けをしている感じになっていますね。

司会者：ありがとうございます。

Intelligent-Tieringの有効化は最初からできていたところ

司会者：（質問が）けっこう来ているので、次、読んでいきたいと思います。

「Tierの切り替え時の移動課金の話がありましたが、最初から有効化しておく選択肢はありませんでしたか？」というものです。

松浦：ありました。これは、お恥ずかしいのですが、ありました。

司会者：ここはちょっと最初からできていればなというところでしたよね。

松浦：はい。

司会者：ありがとうございます。

FargateからEC2への移行で意外だったこと

司会者：では3つ目です。「チリツモということですが、その中でも着手前に想像していた以上に減らせた項目はありますか？」と来ています。

松浦：着手前に想像していた以上に減らせた項目。そうですね、それがまさに今着手中の、このFargateからEC2に移行するところで、当社のワークロード的に、意外と1インスタンスに詰め込めるということがわかりました。もちろん詰め込んだら詰め込んだだけ、「そのインスタンスが落ちた時どうするんだ？」みたいなことを考えないといけないので、そことのバランスなんですけれども。

「Fargateのほうが楽じゃん」という考えに凝り固まってしまうと良くないなということがあったので、ちょっと意外というか、そういうところはあったかなと思います。

司会者：そうですね。これ、ちょっと僕も「あぁ、そうなんだ」とびっくりしながらちょっと聞いていました。

クラスメソッドを通すことで使えなくなるコスト管理ツールは？

司会者：では、最後ですね。「クラスメソッドさんを通すことで使えなくなるコスト管理ツールは何になりますか？」

松浦：まず「Cost Explorer」に表示されるコストは、謎の中途半端になるところがあります。

オプティマイザーなどのツール、EC2やFargateに関するオプティマイザーはAWSのものが使えるので、クラメソ（クラスメソッド）さんのダッシュボードとAWSのコンソールを行ったり来たりしないといけないのが、ちょっとマイナスかなと思っています。それでも5パーセントも引かれるというのはけっこう魅力的なんですよね。

司会者：ありがとうございます。では、いったん大丈夫そうなので、松浦さんの発表を以上で終わりにしたいと思います。ありがとうございます。

松浦：ありがとうございます。

（会場拍手）