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
800
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
0
3.2k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
190
TerraformでEC2 Auto Scaling構築してみた
tessy
4
980
Other Decks in Technology
See All in Technology
Devinで模索する AIファースト開発〜ゼロベースから始めるDevOpsの進化〜
potix2
PRO
8
3.5k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
0
110
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
180
AWSLambdaMCPServerを使ってツールとMCPサーバを分離する
tkikuchi
1
3k
Notion x ポストモーテムで広げる組織の学び / Notion x Postmortem
isaoshimizu
1
120
SnowflakeとDatabricks両方でRAGを構築してみた
kameitomohiro
1
420
LLM as プロダクト開発のパワードスーツ
layerx
PRO
1
240
Terraform Cloudで始めるおひとりさまOrganizationsのすゝめ
handy
2
180
AWSの新機能検証をやる時こそ、Amazon Qでプロンプトエンジニアリングを駆使しよう
duelist2020jp
1
260
プロダクト開発におけるAI時代の開発生産性
shnjtk
2
240
クォータ監視、AWS Organizations環境でも楽勝です✌️
iwamot
PRO
1
320
ブラウザのレガシー・独自機能を愛でる-Firefoxの脆弱性4選- / Browser Crash Club #1
masatokinugawa
1
490
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
It's Worth the Effort
3n
184
28k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
9
760
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
KATA
mclloyd
29
14k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
13
1.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
Speed Design
sergeychernyshev
29
900
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要素)
終わり