Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS月額利用料を$137,000→$87,000に削減して信頼性に投資した話
Search
Masaya Hayashi
September 02, 2023
Programming
8
3.8k
AWS月額利用料を$137,000→$87,000に削減して信頼性に投資した話
https://aws-startup-community.connpass.com/event/289498/
Startup Day 2023のセッションスライドです。
Masaya Hayashi
September 02, 2023
Tweet
Share
More Decks by Masaya Hayashi
See All by Masaya Hayashi
Four Keysだけじゃ足りなくない? 〜俺たちだけのFour Keysを探して〜
rinchsan
4
4.9k
「スニダン」開発組織の構造に込めた意図 ~組織作りはパッションや政治ではない!~
rinchsan
4
960
節約は技術!削減は芸術!何より必要なものは覚悟!
rinchsan
6
5.9k
QAエンジニアってスクラムで何をすればいいの?
rinchsan
2
2k
CTOって何をすればいいの?
rinchsan
0
540
フロー効率を重視して「2年半でエンジニア2名→35名」の急拡大組織で高い生産性を実現した話
rinchsan
20
13k
チームが自律して生産性を改善できる3つの原則
rinchsan
2
860
良い開発生産性を目指せば採用もうまくいく
rinchsan
2
770
“良い開発体験”との向き合い方
rinchsan
1
200
Other Decks in Programming
See All in Programming
Real-time message handling and notifications with API Platform and Symfony
alli83
1
100
学生の時に開催したPerl入学式をきっかけにエンジニアが組織に馴染むために勉強会を主催や仲間と参加して職能間の境界を越えていく
ohmori_yusuke
1
130
Subclassing, Composition, Python, and You
hynek
3
140
フロントエンドの現在地とこれから
koba04
10
4.4k
"Swarming" をコンセプトに掲げるアジャイルチームのベストプラクティス
boykush
2
230
C#および.NETに対する誤解をひも解く
ymd65536
0
250
Infrastructure as Code でセキュリティを楽にしよう!
konokenj
6
1.4k
PHPを書く理由、PHPを書いていて良い理由 / Reasons to write PHP and why it is good to write PHP
seike460
PRO
5
450
NEWTにおけるiOS18対応の進め方
ryu1sazae
0
230
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
1.2k
ファーストペンギンBot @Qiita Hackathon 2024 予選
dyson_web
0
220
ECS向けのドリフト検知機構を実装してみた
tkikuc
0
280
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
31
6.2k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
The Brand Is Dead. Long Live the Brand.
mthomps
53
38k
Testing 201, or: Great Expectations
jmmastey
38
7k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
29
1.7k
Practical Orchestrator
shlominoach
186
10k
KATA
mclloyd
27
13k
It's Worth the Effort
3n
183
27k
Building Applications with DynamoDB
mza
90
6k
From Idea to $5000 a Month in 5 Months
shpigford
380
46k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Transcript
2023/09/02 Startup Day 2023 - AWS Startup Community AWS月額利用料を $137,000
→ $87,000 に削減して 信頼性に投資した話 @rinchsan
今日はコスト削減ハンズオンもあるらしい ※ Startup Day 2023オフライン参加者限定
2023/09/02 AWS月額利用料を $137,000 → $87,000 に削減して 信頼性に投資した話 @rinchsan $146,000 Startup
Day 2023 - AWS Startup Community
今日のキーワード
ボトルネックから潰す 「覚悟」を持つ 今日のキーワード
目次 プロダクトの急成長 1 コスト削減もボトルネックから 2 いろいろなコスト削減 3 信頼性やセキュリティへの投資 4
株式会社SODA ◦ 2020年10月に入社 ◦ Webエンジニア → VPoE & EM (2022年1月〜)
◦ ミッション:エンジニアリングマネジメントをいい感じに ⇧⇧⇧ 株式会社サイバーエージェント ◦ 2019年新卒入社 バックエンドエンジニア ◦ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan @rinchsan
誰かEMやりませんか?
プロダクトの急成長 1
国内 No.1 スニーカー・トレカフリマ HYPE DROP メディア コミュニティ マーケットプレイス
取り扱いカテゴリ拡充 BtoCの一次流通も混ざり合う 海外展開 スニーカー&トレカCtoCフリマに留まらない事業展開をしていく
そんなスニダンの急成長を見てみる
MAU リクエスト数 デプロイ頻度 AWS月額利用料 プロダクトの急成長
2年半で 100万人 → 500万人 MAU プロダクトの急成長
負荷スパイク(人気スニーカー発売など) 1万〜2万 rps リクエスト数 プロダクトの急成長
Monthlyで デプロイ 約100回 デプロイ頻度 D/D/D = 0.3 (Deployments / a
Developer / a Day) デプロイ頻度 プロダクトの急成長
2年半で $43,000 → $146,000 AWS月額利用料 プロダクトの急成長
コスト削減もボトルネックから 2
パフォーマンスチューニングの鉄則は?
ボトルネックから潰す ボトルネックを放置したら効果ゼロ パフォーマンスチューニングの鉄則
“一カ所でも大きなボトル ネックが存在していると、 システム全体の性能が大き く上がることは決してあり ません。” ISUCON本
“実際に存在しているボトル ネックを解消せずに、他の 事例において効果的だった 手段だけをいくら積み重ね ても効果は薄いのです。” ISUCON本
支配的なコストから減らす 支配的な部分を放置したら効果ゼロ コスト削減も同じく ※ パフォーマンスの議論では計算量のオーダーが違うことが多いため、それと比べるとゼロというわけではない。
実際にどう削減されていったか
2022/08 - 2023/01 $146,000 → $87,000 半年で $60,000 削減
施策A:$40,000削減 施策B:$12,000削減 施策C:$2,700削減 ︙ 支配的なコストから削減
組織体制も軽くご紹介
直近2年半:2名→36名 コスト削減期間(2022/08-2023/01) :+11名 エンジニア組織の拡大
プロダクト開発組織の全体像
スペシャルサンクス:SREチーム @takehito @t-nagayama-soda @dangminhduc
あともう1つ重要なもの
覚悟
事業成長が大事 コストには目をつぶることも 後回しになりがち コスト削減には「覚悟」も必要
いろいろなコスト削減 3
まずはボトルネックを探す
削減金額予想が支配的なものを優先 ※ 構想段階のシートのため最終的な実施有無とは異なる部分があります。 ←サッと対応できるものもやる
VPC Endpoint導入:削減金額予想が最も大きいところから
まずは VPC Endpoint から!
スニダンはECS, Aurora, Elasticache, S3, ... などのオーソドックスな構成 ECS Aurora S3 Elasticache
VPC Endpoint導入の背景 ECS NAT Gateway ECR S3 Internet Private subnet
大量にNAT Gatewayを通っているのは主にECR/S3への通信のはず
数百MBytesなコンテナイメージのPullが大量に走る ECS Task起動数は35〜150個。デプロイは月に100回。1日に5回。
S3/ECRに対するVPC Endpointを作成 ECS VPC Endpoint ECR S3 Private subnet NAT
Gatewayの料金が $50,000 削減される見込み Private接続
NAT Gatewayの通信料が一気に削減!
ここまでで $40,000 の削減 🎉
あれ、 $10,000 足りない…?
あ!! ECR Public からの Pull が!!
ECS Taskの中に、ECR PublicからPullするサイドカーコンテナが ECS VPC Endpoint ECR S3 Private subnet
Private接続 NAT Gateway Internet ECR Public 試算すると、予想通り $10,000 に
ECR pull through cache の導入
ECR Public をキャッシュ Privateに自前で置かなくていい キャッシュ更新でイメージタグ更新 (自動でイメージタグが変わると困ることも多いので注意です) ECR pull through cache
とは
ECR pull through cache の利用 Pull through cache ECR Public
ECS VPC Endpoint ECR S3 Private subnet Private接続 Privateな ECR 上に ECR Public のイメージがキャッシュできるように 🎉
今度こそNAT Gatewayの通信量を大幅に削減!
ここまでで $52,000 の削減 🎉
次のボトルネックを探す
次のボトルネックを探す
WAFのログ配信先変更
WAFのログ配信先をCloudwatch LogsからS3へ Cloudwatch Logsに比べると分析・可視化は難しくなることに注意 ログ Cloudwatch Logs WAF ログ S3
WAF
ここまでで $54,700 の削減 🎉
次のボトルネック探しの旅へ...
不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を
不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を
アタッチされてないEIP削除 使われていない環境を削除 (EC2, ECS, Aurora, Elasticache…) 不要リソースの削除
不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を
Intelに比べてコスト効率20%向上 データストア系のみに適用 (ECSはARMで動くかの検証が必要でPendに) Gravitonインスタンスの利用
不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を
Step-scalingのしきい値調整 Target-tracking scalingの検証 Scheduled-scalingの設定調整 余分なECS/Auroraインスタンスが起動しないように
最終的に $60,000 の削減 🎉
信頼性やセキュリティへの投資 4
データストアのスケールアップ Security Hub導入 GuardDuty導入 信頼性やセキュリティへの投資
データストアのスケールアップ Security Hub導入 GuardDuty導入 信頼性やセキュリティへの投資
Aurora: db.r5 → db.r6g Elasticache(Memcached) : t3 → m6g Elasticache(Redis)
: r5 → r6g データストアのスケールアップ
データストアのスケールアップ Security Hub導入 GuardDuty導入 信頼性やセキュリティへの投資
Security Hub:ある評価基準に従ってセキュリティスコアを算出 導入当初の44%からは向上しているが、57%は低いのでまだまだ精進が必要…!
Security Hub:評価基準は5種類から選択可能(導入当初は3種類だった) 現時点では、ある程度更新頻度の高いもののみ有効化
Security Hub:AWS Configから評価に必要な情報を取得 Aurora ECS Elasticache ︙ AWS Config Security
Hub AWS Configは記録するリソース情報の量だけ課金される リソース情報を取得 リソース情報を取得して記録
Security Hub:AWS Configから評価に必要な情報を取得 Aurora ECS Elasticache ︙ AWS Config Security
Hub AWS Configは記録するリソース情報の量だけ課金される リソース情報を取得 リソース情報を取得して記録 AWS AppConfigとはちがうよ
コスト削減 番外編
AWS Configの料金が高騰 大量のECS Taskの起動/停止の記録によって $15,000 まで跳ね上がった! Aurora ECS Elasticache ︙
AWS Config Security Hub リソース情報を取得 リソース情報を取得して記録
記録対象に不要なリソース “以外” を指定することで回避 除外しないほうが理想なので、スケール戦略の見直しは今後の課題
ちなみに、現在はリソースタイプごとに除外設定が可能 https://aws.amazon.com/jp/about-aws/whats-new/2023/06/aws-config-recording-exclusions-resource-type/
つまり、今後はこうできる excluded resource types に除外したいリソースタイプを指定
データストアのスケールアップ Security Hub導入 GuardDuty導入 信頼性やセキュリティへの投資
GuardDuty:とりあえず有効化! 有効化して以降、脅威を検知していないのは良いのか悪いのか…(多分良い)
まとめ
ボトルネックから潰す 「覚悟」を持つ コスト削減で重要なコト
ボトルネックを放置すると効果ゼロ まずは作戦を練るところから ボトルネックから潰す ※ パフォーマンスの議論では計算量のオーダーが違うことが多いため、それと比べるとゼロというわけではない。
コスト削減は後回しになりがち 削減しないと削減されない (あたりまえ) 「覚悟」を持つ
ボトルネックから潰す 「覚悟」を持つ コスト削減で重要なコト