AWS環境内における全アカウントのコスト分析・最適化を実施

ジョンフンモ氏（以下、ジョン）：ディップでコスト最適化を実施した結果を発表します。インフラソリューション部システム基盤課のジョンフンモと申します。

本日のアジェンダです。まず自己紹介ですね。ジョンフンモと申します。出身は韓国で、2019年に日本に来ました。2022年6月にディップに入社して、現在は全プロダクトに対して横断的にAWSのコスト最適化を行っています。

次に背景をお話しします。AWS環境における複数のアカウントにディップのさまざまなサービスが構築されており、全アカウントのコスト分析・最適化が必要でした。特に使用率が多い「EC2」「RDS」「ElastiCache」をターゲットとして、全アカウントのコスト分析・最適化を定期的にする必要がありました。

AWS最適化サービス「Trusted Advisor」「Compute Optimizer」の紹介

利用したAWSの最適化サービスを軽く紹介しようと思います。

まず、「Trusted Advisor」です。これは、パフォーマンスとセキュリティを最適化するためのサービスです。どのくらいの金額を削減できるかを表示してくれます。詳しい内容は割愛します。

次は、「Compute Optimizer」です。最適なAWSコンピューティングリソースを推奨してくれるサービスです。いろいろなサービスに対応していますが、最近「Fargate」での「ECS」サービスが新機能として追加されました。Trusted Advisorよりもコンピューティングリソースの分析に特化したサービスで、良いです。

Compute Optimizerの詳細ですが、使用中のサーバーを「CloudWatch」サービスでモニタリングし、そのモニタリングデータをCompute Optimizerから分析して、最適なタイプを推奨してくれます。

推奨タイプを確認して、各システムの特徴を考慮しつつタイプ変更を行います。推奨オプションによって、差額やリスクを確認したり、変更後のメトリクスの比較をしたりすることが可能です。

定期的な分析・最適化のためにコスト分析のレポートを作成

次のステップで、定期的に分析・最適化を実施するために、コスト分析のレポートを構成しました。（スライドの）真ん中にある、各「Lambda」に行って、コスト分析に必要なメトリクスを収集します。

Compute Optimizerで対応していないリソースであるRDS、ElastiCacheは、「CloudWatchメトリクス」と「CloudWatch Logs」の情報を取得します。

「EventBridge」から、毎月1日、各Lambdaを実施する「Step Functions」を実行します。各Lambdaで収集された内容についてはS3にアップロードされます。

（スライドを示して）このコストレポートに対する結果がこちらです。収集されたメトリクスを基に、タイプ変更対象を選定します。例えばある方針を決めたとして、スケールダウンする場合を予想します。スペックが半分になるとして、最大値30パーセント、もしくは40パーセント以下のリソースを選定できます。

6月から段階的に最適化を行いましたが、変更した対象のデータを蓄積するために、1ヶ月間はEC2関連ではなく、ほかのリソースの最適化を行いました。

年間料金の約10パーセントのコスト削減が実現

その結果、年間料金の約10パーセントのコスト削減ができました。定期的なコスト分析・最適化を実施したので、10月以降は過剰なプロビジョニングのリソースがどんどん少なくなり、全体的に安定している状況になりました。

そのため、コンピューティングリソースに対しては「Savings Plans」を購入し、RDS、ElastiCacheについては、「リザーブドインスタンス」を購入しようと考えています。

ちょっと早いですが、私の発表は以上です。ご清聴ありがとうございました。

質疑応答

司会者：ジョンさん、発表ありがとうございました。それでは、質疑パートに移りたいと思います。「Slido」に質問が来ているので読み上げていきます。

「Compute Optimizerで推奨されたインスタンスタイプに変更することによる問題はなかったでしょうか？（推奨はT系インスタンスだったが、ワークロードのコンピュート性能的にR系に変更する必要があったなど）」、そこの推奨と実際の差異みたいなものがあったかどうかというところですかね？

ジョン：基本的にCompute Optimizerからは、オプションとして3つの選択肢を出してくれるのでそこから選択しますが、例えば「8分の1にダウンしてください」みたいな推奨も出ているので、基本的には先ほどお話ししたとおり、段階的にスケールダウンすることをお勧めしています。

再度R系にタイプを変更することに対しては、基本的には使用量ごとにオプションが出しているし、そのタイプ変更によるリスクも、ある程度Compute Optimizerで判断して出してくれるので、その部分を注意して変更すれば、大きな問題はないかと思います。

司会者：ありがとうございます。続いて「コスト削減を進めるに当たって、全体的に苦労した点は何ですか？」

ジョン：どこから手をつければ良いか？　というところが一番難しかったと思いますが、使用量が一番高いものから手をつけて、その部分に対して柔軟に対応している感じです。

司会者：なるほど、ありがとうございます。

Published at