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
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
Search
tessy
October 18, 2023
Technology
0
900
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
Kindに頼らない!おうちで構築するマルチマスターKubernetes Cluster
tessy
0
130
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
1
3.8k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
1
350
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1.1k
Other Decks in Technology
See All in Technology
男(監査)はつらいよ - Policy as CodeからAIエージェントへ
ken5scal
5
770
us-east-1 に障害が起きた時に、 ap-northeast-1 にどんな影響があるか 説明できるようになろう!
miu_crescent
PRO
12
3.7k
vLLM Community Meetup Tokyo #3 オープニングトーク
jpishikawa
0
190
製造業ドメインにおける LLMプロダクト構築: 複雑な文脈へのアプローチ
caddi_eng
1
510
Kaggleの経験が実務にどう活きているか / kaggle_findy
sansan_randd
6
950
オレ達はAWS管理をやりたいんじゃない!開発の生産性を爆アゲしたいんだ!!
wkm2
3
330
AWS SES VDMで 将来の配信事故を防げた話
moyashi
0
120
AIエージェント・エコノミーの幕開け 〜 オープンプロトコルが変えるビジネスの未来 〜
shukob
0
110
All About Sansan – for New Global Engineers
sansan33
PRO
1
1.4k
クラウド時代における一時権限取得
krrrr38
1
170
GitLab Duo Agent Platform + Local LLMサービングで幸せになりたい
jyoshise
0
170
Abuse report だけじゃない。AWS から緊急連絡が来る状況とは?昨今の攻撃や被害の事例の紹介と備えておきたい考え方について
kazzpapa3
1
120
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
Facilitating Awesome Meetings
lara
57
6.8k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
960
GitHub's CSS Performance
jonrohan
1032
470k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.6k
Designing for humans not robots
tammielis
254
26k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
290
How Software Deployment tools have changed in the past 20 years
geshan
0
32k
Are puppies a ranking factor?
jonoalderson
1
3.1k
Ethics towards AI in product and experience design
skipperchong
2
220
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8.8k
Transcript
EC2 AutoScalingでスケーリングポリシー設定を 失敗してうまく⾏かなった件とその対策 ⽇本IBM ⼿嶋 達也 2023/10/18
⾃⼰紹介 @tterima Teshima-Tatsuya 主なAWS資格
⽬次 • 構成 • オートスケーリングの設定 • 何がダメだったのか • 解決⽅法
構成
オートスケーリング要件 オートスケーリンググループ内の 平均CPU利⽤率での スケールイン・スケールアウト サーバ個別の メモリ利⽤率での スケールイン・スケールアウト
結果 分かりますか 負荷急上昇!!
パヤ…パヤ… 起動 停⽌ 起動 停⽌ ❌ ❌
何がダメだったのか? CPU ↑ メモリ↓ うわ、負荷上昇中や アラーム上げるで インスタンス増加や よっしゃ、低負荷や アラーム上げるで インスタンス削減や
何がダメだったのか? CPU ↑ メモリ↓ うわ、負荷上昇中や アラーム上げるで インスタンス増加や インスタンス増加が成⽴している場合は インスタンス増加を優先したい! よっしゃ、低負荷や
アラーム上げるで インスタンス削減や
解決⽅法は? 複合条件でポリシーを 設定したいな。 でも、複合条件のポリシーは 作れない。。 詰んだ。。。?
皆さんなら どう考えますか?
解決⽅法(1/2) オートスケーリングポリシーなんて邪道!! Lambdaで無理やり頑張る!! 1.LambdaでCloudWatchメトリクスを取得 2.CPU,メモリ使⽤率のうち、上昇している項⽬のみ抽出 3.スケールアウト発動!
解決⽅法(2/2) CloudWatchアラームには複合アラームがある。 これで、いずれか⼀⽅が負荷上昇中ものを判定 →スケールアウト発動! OR
解決したけどそれで⼤丈夫?
解決したけどそれで⼤丈夫? そもそもCPUとメモリで複合アラームを設定すべきなのか? メモリに関しては、⼀定以上の閾値を超える場合はメモリリーク を起こしている可能性が⾼い。 →インスタンス再起動が最善⼿の可能性もある。 このあたりはしっかりと、メトリクスを計測して、継続して改善 案を探していきましょう!(申し訳程度のSRE要素)
終わり