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
810
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
0
3.3k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
220
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1k
Other Decks in Technology
See All in Technology
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
360k
Devin&Cursor、それぞれの「本質」から導く最適ユースケース戦略
empitsu
8
2.5k
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
4
1.5k
Babylon.jsでゲームを作ってみよう
limes2018
0
100
実践Kafka Streams 〜イベント駆動型アーキテクチャを添えて〜
joker1007
0
440
プロジェクトマネジメント実践論|現役エンジニアが語る!~チームでモノづくりをする時のコツとは?~
mixi_engineers
PRO
3
180
Swiftは最高だよの話
yuukiw00w
2
290
MCP Clientを活用するための設計と実装上の工夫
yudai00
1
810
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
25k
令和最新版TypeScriptでのnpmパッケージ開発
lycorptech_jp
PRO
0
110
データ戦略部門 紹介資料
sansan33
PRO
1
3.1k
toittaにOpenTelemetryを導入した話 / Mackerel APM リリースパーティ
cohalz
1
490
Featured
See All Featured
Navigating Team Friction
lara
186
15k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
BBQ
matthewcrist
88
9.7k
Making Projects Easy
brettharned
116
6.2k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
42
2.3k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
5
620
Stop Working from a Prison Cell
hatefulcrawdad
269
20k
Thoughts on Productivity
jonyablonski
69
4.7k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
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要素)
終わり