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
260
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1k
Other Decks in Technology
See All in Technology
モダンフロントエンド 開発研修
recruitengineers
PRO
2
320
VPC Latticeのサービスエンドポイント機能を使用した複数VPCアクセス
duelist2020jp
0
230
アジャイルテストで高品質のスプリントレビューを
takesection
0
110
キャリアを支え組織力を高める「多層型ふりかえり」 / 20250821 Kazuki Mori
shift_evolve
PRO
2
300
GCASアップデート(202506-202508)
techniczna
0
250
我々は雰囲気で仕事をしている / How can we do vibe coding as well
naospon
2
220
マイクロモビリティシェアサービスを支える プラットフォームアーキテクチャ
grimoh
1
230
kintone開発チームの紹介
cybozuinsideout
PRO
0
73k
mruby(PicoRuby)で ファミコン音楽を奏でる
kishima
1
230
Goでマークダウンの独自記法を実装する
lag129
0
210
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
500
人を動かすことについて考える
ichimichi
2
320
Featured
See All Featured
Writing Fast Ruby
sferik
628
62k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
480
Why Our Code Smells
bkeepers
PRO
338
57k
Mobile First: as difficult as doing things right
swwweet
223
9.9k
Gamification - CAS2011
davidbonilla
81
5.4k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Become a Pro
speakerdeck
PRO
29
5.5k
We Have a Design System, Now What?
morganepeng
53
7.7k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
4 Signs Your Business is Dying
shpigford
184
22k
Code Reviewing Like a Champion
maltzj
525
40k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
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要素)
終わり