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
38
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
29
Amazon Builder's Library 輪読会資料 ジッターを伴うタイムアウト、再試行、およびバックオフ
kjman678
0
75
時系列解析 輪読会資料 1章
kjman678
0
35
クリーンアーキテクチャ輪読会資料 27-29章
kjman678
0
42
Amazon Builder's Library 輪読会資料 分散システムでのフォールバックの回避
kjman678
0
64
クリーンアーキテクチャ輪読会資料 12-14章
kjman678
0
33
Other Decks in Technology
See All in Technology
「アウトプット脳からユーザー価値脳へ」がそんなに簡単にできたら苦労しない #RSGT2026
aki_iinuma
9
4.2k
テストセンター受験、オンライン受験、どっちなんだい?
yama3133
0
200
ECS_EKS以外の選択肢_ROSA入門_.pdf
masakiokuda
1
120
ソフトウェアエンジニアとAIエンジニアの役割分担についてのある事例
kworkdev
PRO
1
380
Data Hubグループ 紹介資料
sansan33
PRO
0
2.5k
業務の煩悩を祓うAI活用術108選 / AI 108 Usages
smartbank
9
19k
AIと融ける人間の冒険
pujisi
0
110
形式手法特論:コンパイラの「正しさ」は証明できるか? #burikaigi / BuriKaigi 2026
ytaka23
16
4.5k
_第4回__AIxIoTビジネス共創ラボ紹介資料_20251203.pdf
iotcomjpadmin
0
180
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
1k
AIエージェントを5分で一気におさらい!AIエージェント「構築」元年に備えよう
yakumo
1
140
Introduction to Bill One Development Engineer
sansan33
PRO
0
340
Featured
See All Featured
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
61
48k
Prompt Engineering for Job Search
mfonobong
0
140
WCS-LA-2024
lcolladotor
0
400
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Accessibility Awareness
sabderemane
0
32
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
76
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
0
100
Exploring anti-patterns in Rails
aemeredith
2
220
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
55k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
The Spectacular Lies of Maps
axbom
PRO
1
420
Statistics for Hackers
jakevdp
799
230k
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