弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコムがエンジニア・デザイナーのサービス開発事例やデザイン活動を発信する公式ブログです。

AWS COST CUT FIGHT 回答を作ってみました

SRE イベント・カンファレンス

概要

10月5日(土)に開催されたYAPC::Hakodate 2024 で「AWS COST CUT FIGHT」という株式会社DELTA様のイベントがありました*1。

その中で弊社SREが2000$越えのコスト削減を達成しました。

とても良い問題ということが弊社で話題になりSREチーム内で議論をしさらにコスト削減ができたので解答速報として公開します。

注意書き

DELTA様のAWS COST CUT FIGHTの問題を引用させていただきます。

解答はDELTA様の正式なものではありません。 また、提供する情報の正確性や完全性に関しては、責任を負いかねます。ご注意ください。

問題

アーキテクチャ図を参考にコスト削減を達成してください

Q1

ec2インスタンスはm5.2xlarge(vCPU:8,memory:32GiB)を利用しており、CPU負荷状況が平均20%で安定しています。 インスタンスのサイズチューニングを実施する際に、変更先として確実かつ一番効果がある選択肢はどれですか?

選択

  • A: m5.xlarge(vCPU:4,memory:16GiB)
  • B: m7g.xlarge(vCPU:4,memory:16GiB)
  • C: r5.xlarge(vCPU:4,memory:32GiB)
  • D: r7g.xlarge(vCPU:4,memory:32GiB)

答え

D: r7g.xlarge(vCPU:4,memory:32GiB)

ポイント

  • グラビトンが安いことを知っているか
  • 要件に確実ということはどういうことか

解説

ポイントの通りグラビトンを使った方が安い。 また要件に確実ということなのでメモリの変更はしない。
よってD。

Q2

アーキテクチャ図には記載されていませんが、開発者が過去検証で利用していたEC2が起動状態で放置されています。 将来的に必要になった際の運用負荷も踏まえた上で一番コストを意識した対応の選択肢はどれですか？

選択

  • A: 業務時間以外はインスタンスを停止する起動停止設定を組む。
  • B: インスタンスを基本停止して利用時に起動する運用にする。
  • C: AMIを取ってインスタンスを削除する。
  • D: インスタンスを削除して利用時に再構築する。

答え

C: AMIを取ってインスタンスを削除する。

ポイント

  • 一番コストが安いのは何か
  • 運用の負荷が低いのはどれか

解説

インスタンスを停止するだとEBSボリュームのお金がかかる
インスタンスを削除して再構築するだと構築の手間がかかってしまう(Cloudformationですぐに建てるとかだとまた別だが)
AMIを使うことによってEBSのコストを抑えつつ素早くインスタンスを再作成できる。
よってC。

Q3

サービスがリリース直後であり、SPOF(単一障害点)を許容できる状況下で”regional data transfer - in/out/between EC2 AZs or using elastic IPs or ELB”の料金がかなり高いことが発見できました。 この通信料削減のために、一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: Route 53から直接EC2に接続する。
  • B: オブジェクトをS3ではなく、EBSに保存する。
  • C: CloudFrontのキャッシュ設定を見直す。
  • D: RDSのRead replicaを削除する。

答え

D: RDSのRead replicaを削除する。

ポイント

  • SPOFを許容できる状況下であること
  • 通信料削減のためにはどうすればいいか

解説

regional data transfer - in/out/between EC2 AZs or using elastic IPs or ELBということはリージョン間の通信料金が高いということである。
アーキテクチャの図を見るとEC2からRDSのリードレプリカにアクセスしている。
SPOFを許容できるのでリードレプリカを削除することで通信料を削減できる。
よってD。

Q4

RDSはdb.r5.4xlargeのインスタンスタイプを利用しており、3ヶ月前に1年分のdb.r5.4xlargeのRIを2台分購入しています。 サービスが成長してきたため、日中にリーダーインスタンスのリソースが枯渇するケースが発生したため、対応しようとしています。 一番コストを意識したアーキテクチャ改善の選択肢はどれですか？

選択

  • A: db.r5.4xlarge(USD 2.28/h)のインスタンスタイプを最小台数=1でauto scalingを設定する。
  • B: db.r5.2xlarge(USD 1.14/h)のインスタンスタイプを最小台数=2でauto scalingを設定する。
  • C: db.r6g.4xlarge(USD 2.041/h)のインスタンスタイプを最小台数=1でauto scalingを設定する。
  • D: db.r6g.2xlarge(USD 1.02/h)のインスタンスタイプを最小台数=2でauto scalingを設定する。

答え

B(Aの方が性能が変わらないので良い気もするが db.r5.2xlarge を1台づつ増やせる方が安くすむのかもしれない)

ポイント

  • RIの適用条件
  • 性能について

解説

db.r5.4xlargeのRIを2台分購入しているので、r5系のファミリーを使うことでRIを使用できる。
性能が不足している2台にしつつ、最小台数を2にしておくことでRIを使いつつコストを抑えることができる。

Q5

RDSの監査ログをCloudWatch Logsに出力しているが、PutLogEvents料金が高額になってしまったため何か対策を打ちたいと考えています。
年に1回の監査時に利用できれば良くその後破棄できる場合、一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: ライフサイクルルールを設定し、1年経過したらログを削除する。
  • B: ログクラスをInfrequent Accessに変更する。
  • C: Infrequent Accessのロググループを新たに作成し、そこに出力するようにする。
  • D: CloudWatchのログを日次でS3に転送し、その後削除する。

答え

C: Infrequent Accessのロググループを新たに作成し、そこに出力するようにする。

ポイント

  • 年に1回の監査時に利用できれば良い
  • PutLogEventsを減らしたい

解説

A,DだとCloudwatchlogsへ出力しているのでPutLogEventは変わらない。
年に1回の監査時に利用できれば良いのでInfrequent Accessを使えば良いがロググループは途中から変更できない。
よってC。

Q6

検証環境でIaC化の検証を行っており、頻繁に変更等が発生しています。 セキュリティを懸念してAWS Configを設定し最終的にメール通知をする仕組みを構築したが、料金が高くなってきたため設定等を見直そうとしています。 要件として、終業時間のタイミングで意図しない設定になっていないことが確認できれば問題ない場合に、一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: 記録頻度を変更が発生したタイミングでのみ記録を行う継続的な記録にする。
  • B: 記録頻度を1日に1回記録を行う日次記録にする。
  • C: 記録戦略を利用するリソースに絞った特定のリソースタイプにし、特定の記録頻度を変更が発生したタイミングでのみ記録を行う継続的な記録にする。
  • D: 記録戦略を利用するリソースに絞った特定のリソースタイプにし、記録頻度を1日に1回記録を行う日次記録にする。

答え

B: 記録頻度を1日に1回記録を行う日次記録にする。

ポイント

  • 終業時間のタイミングだけの通知で良い
  • セキュリティを懸念する

解説

要件的に1日に一回の記録だけで良いのでB,Dが残る。
Dだと意図しないリソース(例えばかなり大きなRDSを立てた場合など)を作った時の検知ができない。
よってBとなる。

Q7

現在標準のS3ストレージクラスを利用していますが、ストレージクラスを見直すことでストレージ保存料の削減を実現しようとしています。 要件としてオブジェクトに対しては年に数回アクセスする必要があり、ミリ秒単位のアクセス速度が求められます。 ストレージレンズが以下の通りの場合、一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: S3 標準 - 低頻度アクセス (USD 0.0138/GB)
  • B: S3 Glacier Instant Retrieval (USD 0.005/GB)
  • C: S3 Glacier Flexible Retrieval (USD 0.0045/GB)
  • D: S3 Intelligent - Tiering (USD USD 0.005/GB~USD 0.025/GB)

答え

A: S3 標準 - 低頻度アクセス (USD 0.0138/GB)

ポイント

  • ミリ秒単位のアクセス速度が求められる
  • 年に数回アクセスする

解説

msで所得したいのでS3 Glacier Flexible Retrievalは不適。
Bだとmsで取れるがオブジェクト数が187.7B もありGracierに置き直すときにPut 料金が発生する。
CのIntelligent-Tieringはオブジェクトサイズが128KB未満は s3 標準のストレージ金額になる。
今回は平均が107.1KBなのでs3標準料金になる可能性が高い。
よってA。

次のアーキテクチャです。

Q8

自社基幹システムは社員が業務時間(09時～20時)にのみ利用するが、利用中は常に処理が行われています。 強力なインスタンスタイプを利用しているため、できるだけコスト削減をしたいと考えています。 一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: 起動停止運用を導入する。
  • B: RIを購入する。
  • C: Compute Savings Plansを契約する。
  • D: スポットインスタンスを利用する。

答え

A: 起動停止運用を導入する。

ポイント

  • 常に処理をしたい
  • 業務時間(09-20)のみ利用

解説

常に処理をしている基幹システムなのでスポットインスタンスは不適。
またRIとSavingsPlansだと3-4割ぐらいしか安くならない。
今回要件的に12時間しか使わないので起動停止運用を導入すればコストを半分（5割以上）抑えることができる。
よってA。

Q9

リーダーインスタンスは基本的に30%程度のリソース負荷で安定していたが、バッチ処理機能を追加したことによって定期的に負荷が高騰するようになり スケールアウトによるコスト増が無視できなくなってきました。 既存インスタンスの負荷軽減も視野に入れつつ、一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: auto scalingの最低台数を1つ増やし、3年前払いのRIを購入する。
  • B: バッチ起動時間にリーダーインスタンスを追加する。
  • C:リーダーインスタンスをAurora Serverless v2にする。
  • D:リーダーインスタンスをAurora Serverless v2にし、既存のインスタンス相当のACU用のRIを購入する。

答え

B: バッチ起動時間にリーダーインスタンスを追加する。

ポイント

  • バッチの処理
  • AuroraServerlessのコストについて

解説

AuroraServerlessは ACUが高い。
今回のケースだとリーダーを置き換えることでコストが増加する可能性があるためC,Dは不適。
A の最低台数を増やすと常時コストが発生する。
要件的にはバッチでの利用なのでインスタンスを適宜追加した方がコストを抑えることができる。
よってB。

Q10

NATゲートウェイの通信量が気になっています。 ここを通るのはECSからの通信だけであり、外部API連携やライブラリの取得等は存在しません。 NATゲートウェイ周辺に対して、一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: Gateway型のS3,ECR用VPCエンドポイントとInterface型のCloudWatch用のエンドポイントを作成する。ECRにはプルスルーキャッシュの設定を追加する。
  • B: Gateway型のS3,ECR用VPCエンドポイントとInterface型のCloudWatch用のエンドポイントを作成する。ECRにはライフサイクルの設定を追加する。
  • C: Gateway型のS3VPCエンドポイントとInterface型のECR用,CloudWatch用のエンドポイントを作成する。ECRにはプルスルーキャッシュの設定を追加する。
  • D: Gateway型のS3VPCエンドポイントとInterface型のECR用,CloudWatch用のエンドポイントを作成する。ECRにはライフサイクルの設定を追加する。

答え

C: Gateway型のS3VPCエンドポイントとInterface型のECR用,CloudWatch用のエンドポイントを作成する。ECRにはプルスルーキャッシュの設定を追加する。

ポイント

  • エンドポイントについて
  • ECSからの通信だけ

解説

gateway型のVPCエンドポイントはS3か DynamoDB しかない、よってA,Bは不適。
またECSの通信なのでイメージのpullをしている。ECRに保管されているdocker imageのライフサイクルは今回関係ない。
よってCとなる。

Q11

CloudFrontに割引があることを発見したので、キャッシュによる速度改善とコスト削減効果を期待して利用を検討しています。 各ALBの総通信量は等しく、api.xxx.comへのHTTPリクエストがweb.xxx.comの3,000倍あるとき、一番コスト削減効果の高い選択肢はどれですか？

選択

  • A: api.xxx.comのALBの前にCloudFrontを配置し、Savings Plansを適用する。
  • B: api.xxx.comのALBの前にCloudFrontを配置し、Security Savings Bundleを適用する。
  • C: web.xxx.comのALBの前にCloudFrontを配置し、Savings Plansを適用する。
  • D: web.xxx.comのALBの前にCloudFrontを配置し、Security Savings Bundleを適用する。

答え

D: web.xxx.comのALBの前にCloudFrontを配置し、Security Savings Bundleを適用する。

ポイント

  • Cloudfrontのコスト削減方法について
  • １リクエストあたりの通信量が多いのはどちらか

解説

Cloudfrontのコスト削減はSecurity Savings Bundleという名前である、よってA,Cは不適。
また総通信量が一緒なので1リクエスト的にはwebの方が通信量が多い、つまりwebをキャッシュさせることでコストを削減できる (またapiはget requestをキャッシュさせたくないケースが多い) よってD。

Q12

本番環境と検証環境で同じ構成でサービスを構築しています。 CloudWatchの料金が増えてきたため、コスト削減の施策を打とうとしています。 一番コストを意識した選択肢はどれですか？

選択

  • A: 検証環境のECSのContainer Insightを無効化する。
  • B: 検証環境のRDSのPerformance Insightsを無効化する。
  • C: 本番環境と検証環境のCloudWatchに出力しているログをKinesis Data FirehoseでS3に転送し、標準機能でgz形式に圧縮する。
  • D: DataDog等外部サービスからCloudWatchのメトリクスを監視するようにする。

答え

C: 本番環境と検証環境のCloudWatchに出力しているログをKinesis Data FirehoseでS3に転送し、標準機能でgz形式に圧縮する。

ポイント

  • CloudWatchの料金が増えてきた=>PutLogEvent ã‚„ PutMetrics 等の料金が高い

解説

A、B は PutLogEvent や PutMetrics 等を減らせる可能性はあるが検証環境のみなので効果が薄そう。
D は Datadog からの GetMetrics リクエストが増え CloudWatch の料金が増える。
C は kinesis への料金は発生するがPutLogEvent が発生しなくなるので安くなる。
よってC。

Q13

ECSのタスク定義jsonは画像の通りでコンテナは1つのみ定義されています。 無駄なリソースがあることが分かったので、チューニングを行う必要があります。 一番最適なコストを意識した選択肢はどれですか？

選択

  • A: cpu:1024 , memory:4096 , containerDefinitions内のcpu:1024 , containerDefinitions内のmemory:4096
  • B: cpu:512 , memory:3072 , containerDefinitions内のcpu:1024 , containerDefinitions内のmemory:4096
  • C: cpu:512 , memory:3072 , containerDefinitions内のcpu:512 , containerDefinitions内のmemory:3072
  • D: cpu:512 , memory:3072 , containerDefinitions内のcpu: 0 , containerDefinitions内のmemory:-

答え

D: cpu:512 , memory:3072 , containerDefinitions内のcpu: 0 , containerDefinitions内のmemory:-

ポイント

  • cpuとmemoryの設定について
  • 無駄なリソース

解説

Aは無駄なリソースのチューニングができていない。
Bは CPU、メモリともにタスク定義より containerDefinitions内の設定が大きいので登録できない。
Cもタスク定義と containerDefinitions内の設定が同じ。予約される容量があるはずなので登録できない。
よってD。

あとがき

皆さんはいくら削減できましたか？ このような問題を作成いただき改めてコスト削減についての理解を深める機会をいただきました株式会社DELTA様に改めて感謝申し上げます。

株式会社DELTA様のご紹介

*1:本問題の挑戦は2024年10月8日でサービスが終了したみたいです。

© Bengo4.com, Inc. 2005