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
Amazon Builder's Library 輪読会資料 負荷制限を使用して過負荷を回避する
Search
koji
February 02, 2020
Technology
0
39
Amazon Builder's Library 輪読会資料 負荷制限を使用して過負荷を回避する
参加しているコミュニティ、Challeng-Every-Monthの輪読会で作成した資料。
koji
February 02, 2020
Tweet
Share
More Decks by koji
See All by koji
20250914_Vibe Coding初学者向け勉強会_Devinについて
kjman678
0
31
Amazon Builder's Library 輪読会資料 ジッターを伴うタイムアウト、再試行、およびバックオフ
kjman678
0
77
時系列解析 輪読会資料 1章
kjman678
0
36
クリーンアーキテクチャ輪読会資料 27-29章
kjman678
0
44
Amazon Builder's Library 輪読会資料 分散システムでのフォールバックの回避
kjman678
0
65
クリーンアーキテクチャ輪読会資料 12-14章
kjman678
0
34
Other Decks in Technology
See All in Technology
[JAWSDAYS2026][D8]その起票、愛が足りてますか?AWSサポートを味方につける、技術的「ラブレター」の書き方
hirosys_
3
120
20260311 技術SWG活動報告(デジタルアイデンティティ人材育成推進WG Ph2 活動報告会)
oidfj
0
290
GitLab Duo Agent Platform + Local LLMサービングで幸せになりたい
jyoshise
0
290
JAWSDAYS2026_A-6_現場SEが語る 回せるセキュリティ運用~設計で可視化、AIで加速する「楽に回る」運用設計のコツ~
shoki_hata
0
3k
8万デプロイ
iwamot
PRO
2
230
堅牢.py#2 LT資料
t3tra
0
130
マルチロールEMが実践する「組織のレジリエンス」を高めるための組織構造と人材配置戦略
coconala_engineer
3
710
製造業ドメインにおける LLMプロダクト構築: 複雑な文脈へのアプローチ
caddi_eng
1
560
僕、S3 シンプルって名前だけど全然シンプルじゃありません よろしくお願いします
yama3133
1
190
AI時代のSaaSとETL
shoe116
1
110
IBM Bobを使って、PostgreSQLのToDoアプリをDb2へ変換してみよう/202603_Dojo_Bob
mayumihirano
1
320
越境する組織づくり ─ 多様性を前提にしたチームビルディングとリードの実践知
kido_engineer
2
190
Featured
See All Featured
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
120
A Tale of Four Properties
chriscoyier
163
24k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
14k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
1.7k
Accessibility Awareness
sabderemane
0
77
Java REST API Framework Comparison - PWX 2021
mraible
34
9.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.4k
Skip the Path - Find Your Career Trail
mkilby
1
76
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
270
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
30k
Transcript
abl輪読会 2回目 2020/2/2(日)21:00- 負荷制限を使用して過負荷を回避する https://go.aws/3b1cT6D 発表者 koji/メガネ男 1
• 最大接続数がシステムの安定に大きく影響するが、以下の問題あり。 • 最大接続数の概念は不正確すぎて、最適解が導き出せない。 • 最大接続数が低すぎても✖ サービスに十分な容量がある場合でも、ロー ドバランサーがリクエスト数の増加を遮断する可能性がある。 • 最大接続数が高すぎても✖ とサーバーが遅くなり応答しなくなる。 •
作業負荷に最適な最大接続数を設定 ?? 確実ではない。 処理負荷が変動したり、依存関係のパフォーマンスが変化し、再び値に誤 りが生じ、不必要な停止または過負荷が発生することも。 負荷制限を回避する 》冒頭の文章 2
• そこで・・・ • システムが過負荷状態になる前に積極的にスケーリングするように 設計することにより、過負荷を回避。 • AWSはアプリケーションをモニタリングし、容量を自動で調整 これにより、安定かつ低コストを実現。 負荷制限を回避する 》過負荷の解析 3
< ドヤァ!
• アムダールの法則・・・プロセッサーの処理における、並列度と性能 の関係を示したもの。 処理スピードがある一定を下回ってタイムアウトすると悪い結果にな るが、それについてはこのグラフは触れていない。 並行度合 処理スピード 演算装置の数 負荷制限を回避する 》過負荷の解析 プロセッサーの並行度合が高くなると
めちゃくちゃ処理スピードが 上がる! 4
• 遅延により半分くらいタイムアウトすると、システムは極端に使い物 にならなくなる。 • いわゆる『カスケード再試行』に陥る。 →過負荷でクライアントがタイムアウト、 →今までの作業がムダになり、 →システムがリクエストを繰り返してさらに負荷がアップ! ←カスケード(連なった滝)のように 迫りくるエラー・・・!
負荷制限を回避する 》正のフィードバックループ 5
• 負荷制限の仕組み サーバーが過負荷に近づくと、過剰なリクエストを拒否し、 特定のリクエストのみを受け入れる。 負荷制限を回避する 》作業が無駄にならないようにする 6
• サービスのカオスエンジニアリングテストを実行するときに役立つ(例 :ネットフリックスのツール、カオスモンキー) • 正常稼働中の分散システム(サーバー)であえて小さな障害を起こす ことで、大きな障害にもちゃんと耐えられるようにする。 →炭鉱のカナリヤ 毒に弱いカナリヤが 先に死ぬ →炭鉱に毒ガスがもれて
いることがわかる ddd 負荷制限を回避する 》 テスト1/2 7
• エンドツーエンドの負荷テストでは、そのサービス相互間の負荷も増 加するので、思わぬボトルネックが明らかになるかもしれない。 負荷制限を回避する テスト2/2 8
• 負荷制限がリクエストを拒否する場合、クライアントが誰なのか、ど のオペレーションが呼び出されているか、予防措置の調整に有用な あらゆる情報を知るための適切な手段を備えているかを確認する。 • 予防措置が膨大なトラフィックをシャットアウトしているかどうかを検 出するためにアラームを使用する。 負荷制限を回避する 》 可視性 1/2
9
• 電圧低下が発生した場合は、容量を追加し、現在のボトルネックに 対処することが優先事項。 • (微妙ではあるが)もう一つの重要な考慮事項。 ウェブサービスの遅延の判断の基準値は、異常値、すなわちリクエ ストに失敗した遅延を排除して算定すること。 負荷制限を回避する 》 可視性 2/2
10
• 適切な構成を組まないと、自動スケーリングが上手く反応しないことが ある。 • サーバーのフリートの容量と余力を確かめるために、どのくらいの負荷 でダウンするのか、耐久テストを行う必要がある。 • ピーク時以外は、負荷制限をかけてサーバーの利用を削減し、コスト カットを図る。 •
負荷の原因は、予測不可能なものだけではなく、予測可能な電圧低下 であることも多いので、しっかり対策すること。 11 負荷制限を回避する 自動スケーリング〜略〜制限の影響
• 負荷制限と予測不可能なシナリオについて議論するときは、電圧低 下につながる多くの予測可能条件に焦点を当てることも重要。 • Amazon は、サービスの容量を追加しなくても、アベイラビリティー ゾーンの障害を処理するのに十分な余分の容量を維持している。 • だが、サービスにはいつでも容量には限界があるため、さまざまな理 由から過負荷になる可能性がある。
負荷制限を回避する 負荷制限メカニズム 1/9 12 < 2回目のドヤァ! < サーセン、フヒヒww
• 過負荷を管理するために長年使用してきた考慮事項と手法 ① リクエストを削除するコストを理解する。 受信したデータの量が安定するポイントをはるかに超えた水準で負 荷テストを行うことで、負荷制限中のリクエスト削除コストを最小限に 抑えることができる。 負荷制限を回避する 負荷制限メカニズム 2/9 13
② リクエストの優先順位付け。 サーバーが過負荷になると、受信リクエストの優先付けを行う。 サーバーが受信する最も重要なリクエストは、ロードバランサーからの ping (ピン)リクエストである。 優先順位付けとスロットリングを同時に使用して、サービスを過負荷から 保護しながら、厳密なスロットリング上限を回避する。 負荷制限を回避する 負荷制限メカニズム 3/9
14
③ クロックから目を離さない。 サービスがリクエストを処理する途中でクライアントのタイムアウト を検出した場合、残りの作業をスキップして、その時点でリクエストを 失敗させることができる。 そうしない場合、サーバーはリクエストを処理し続け、サービスは遅 延し続ける。 各リクエストにタイムアウトのための絶対的な時間(≒すべての サーバーの時間設定が正しく統一されている状態)を設定すること で、わずかなコストでリクエストを削除することが可能になる。
負荷制限を回避する 負荷制限メカニズム 4/9 15
④ 開始したものを仕上げる。 サービスが時間内に応答しない場合、クライアントがリクエストを再 試行することが多い。 そこでリクエストを削除すると、1つのリクエストが、たくさんのリソー スを消費するリクエストへと変わり、サービスの負荷が増大する。 作業を完了するために、クライアントstart() リクエストとend() リクエ ストを呼び出す必要があるとすると、end()リスクエストを優先させな
いと、クライアントは開始した作業を完了できず、結果として電圧低下 が発生する。 負荷制限を回避する 負荷制限メカニズム 5/9 16
⑤ キューに注意する。 キューに注意することは重要。 作業をキューから取り出すとき、その機会を利用して、作業がキュー にどれだけの時間関わっていたかを調べます。 ロードバランサーは、サージキューという機能を使用して、サービスが 過負荷になったときに着信リクエストまたは接続をキューに組み込む ことがある。これらのキューは、サーバーが最終的にリクエストを取得 したときに、リクエストがキュー内にどれだけの時間置かれていたかわ からないため、電圧低下につながる可能性がある。
負荷制限を回避する 負荷制限メカニズム 6/9 17
⑥ 下層の過負荷から保護する。 サービスは、複数のレイヤーで構成されており、各レイヤーは、サー ビスを保護する機能を提供する。 サーバーリソースの使用を制限するオペレーティングシステムの機 能は強力であり、緊急時に使用すると役立つ。 iptables ユーティリティ、Elastic Load Balancing、Network
Load Balancer等。 負荷制限を回避する 負荷制限メカニズム 7/9 18
⑦ レイヤーで保護する。1/2 場合によっては、サーバーのリソースが不足して、速度を落とさずに リクエストを拒否することがある。 この現実を念頭に置いて、サーバーとクライアントの間のすべての ホップを調べて、サーバーとクライアントがどのように連携して過剰な 負荷を減らすのかを確認する。 早期に拒否すれば、低コストで過剰なトラフィックを削除できるが、可 視性が犠牲になる。 負荷制限を回避する 負荷制限メカニズム
8/9 19
⑦ レイヤーで保護する。2/2 そのため、レイヤーで保護する。 サーバーが処理できる以上の処理を行い、超過分を削除し、削除し ているトラフィックを把握するために十分な情報をログに記録する。 負荷制限を回避する 負荷制限メカニズム 9/9 20
• AWS構築は、予測可能で一貫したパフォーマンスをキープできる設 計を行うこと。 例)Amazon DynamoDB、AWS Lambdaなど • 各 APIごとに独立したリソースを確保すると、リソースのバッティング を回避できるので有効。
負荷制限を回避する 》 過負荷について異なる考え方をする 21
以上です、ありがとうございました! 22
• DynamoDB全くわからない、から、ちょっとわかるようになるまでの道 しるべ https://bit.ly/37Ueauc • AWS初心者入門 第7回~「Lambda」ってなにがスゴイんですか? https://bit.ly/2SeIJEB 参考) 23