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
730
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
0
2.6k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
120
TerraformでEC2 Auto Scaling構築してみた
tessy
4
910
Other Decks in Technology
See All in Technology
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
180
Amazon Kendra GenAI Index 登場でどう変わる? 評価から学ぶ最適なRAG構成
naoki_0531
0
130
AWS re:Invent 2024 ふりかえり勉強会
yhana
0
390
事業貢献を考えるための技術改善の目標設計と改善実績 / Targeted design of technical improvements to consider business contribution and improvement performance
oomatomo
0
150
非機能品質を作り込むための実践アーキテクチャ
knih
5
1.6k
AWS re:Invent 2024で発表された コードを書く開発者向け機能について
maruto
0
210
Server-Side Engineer of LINE Sukimani
lycorp_recruit_jp
0
340
TypeScript開発にモジュラーモノリスを持ち込む
sansantech
PRO
2
350
GitHub Copilot のテクニック集/GitHub Copilot Techniques
rayuron
39
16k
UI State設計とテスト方針
rmakiyama
3
780
コンテナセキュリティのためのLandlock入門
nullpo_head
2
330
Work as an App Engineer
lycorp_recruit_jp
0
350
Featured
See All Featured
Designing for Performance
lara
604
68k
The Invisible Side of Design
smashingmag
298
50k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
29
2k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Writing Fast Ruby
sferik
628
61k
Testing 201, or: Great Expectations
jmmastey
41
7.1k
Git: the NoSQL Database
bkeepers
PRO
427
64k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5k
Building Better People: How to give real-time feedback that sticks.
wjessup
366
19k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
450
Scaling GitHub
holman
459
140k
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要素)
終わり