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.3k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
210
TerraformでEC2 Auto Scaling構築してみた
tessy
4
990
Other Decks in Technology
See All in Technology
正式リリースされた Semantic Kernel の Agent Framework 全部紹介!
okazuki
1
1.2k
とあるEdTechベンチャーのシステム構成こだわりN選 / edtech-system
gotok365
5
350
インフラからSREへ
mirakui
3
480
AI駆動で進化する開発プロセス ~クラスメソッドでの実践と成功事例~ / aidd-in-classmethod
tomoki10
1
1.2k
データベース04: SQL (1/3) 単純質問 & 集約演算
trycycle
PRO
0
730
自動化の第一歩 -インフラ環境構築の自動化について-
smt7174
1
130
猫でもわかるS3 Tables【Apache Iceberg編】
kentapapa
2
210
分解し、導き、託す ログラスにおける“技術でリードする” 実践の記録
hryushm
0
300
名単体テスト 禁断の傀儡(モック)
iwamot
PRO
1
270
LLMの開発と社会実装の今と未来 / AI Builders' Community (ABC) vol.2
pfn
PRO
2
150
SaaS公式MCPサーバーをリリースして得た学び
kawamataryo
5
1.3k
Новые мапы в Go. Вова Марунин, Clatch, МТС
lamodatech
0
2.1k
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Documentation Writing (for coders)
carmenintech
71
4.8k
Optimizing for Happiness
mojombo
378
70k
Site-Speed That Sticks
csswizardry
6
540
Building Adaptive Systems
keathley
41
2.5k
Being A Developer After 40
akosma
91
590k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Done Done
chrislema
184
16k
How to train your dragon (web standard)
notwaldorf
91
6k
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要素)
終わり