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
840
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
1
3.5k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
250
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1k
Other Decks in Technology
See All in Technology
【OptimizationNight】数理最適化のラストワンマイルとしてのUIUX
brainpadpr
2
520
[OCI Technical Deep Dive] OracleのAI戦略(2025年8月5日開催)
oracle4engineer
PRO
1
220
「Roblox」の開発環境とその効率化 ~DAU9700万人超の巨大プラットフォームの開発 事始め~
keitatanji
0
140
歴代のWeb Speed Hackathonの出題から考えるデグレしないパフォーマンス改善
shuta13
2
120
プロジェクトマネジメントは不確実性との対話だ
hisashiwatanabe
0
110
UDDのススメ - 拡張版 -
maguroalternative
1
610
プロダクトエンジニアリングで開発の楽しさを拡張する話
barometrica
0
200
工業高校で学習したとあるエンジニアのキャリアの話
shirayanagiryuji
0
120
専門分化が進む分業下でもユーザーが本当に欲しかったものを追求するプロダクトマネジメント/Focus on real user needs despite deep specialization and division of labor
moriyuya
2
1.4k
僕たちが「開発しやすさ」を求め 模索し続けたアーキテクチャ #アーキテクチャ勉強会_findy
bengo4com
0
2.5k
開発 × 生成AI × コミュニケーション:GENDAの開発現場で感じたコミュニケーションの変化 / GENDA Tech Talk #1
genda
0
290
AWS DDoS攻撃防御の最前線
ryutakondo
1
170
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.4k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
Automating Front-end Workflow
addyosmani
1370
200k
Code Review Best Practice
trishagee
69
19k
The Invisible Side of Design
smashingmag
301
51k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
Mobile First: as difficult as doing things right
swwweet
223
9.9k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
For a Future-Friendly Web
brad_frost
179
9.9k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
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要素)
終わり