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
22
Amazon Builder's Library 輪読会資料 ジッターを伴うタイムアウト、再試行、およびバックオフ
kjman678
0
73
時系列解析 輪読会資料 1章
kjman678
0
35
クリーンアーキテクチャ輪読会資料 27-29章
kjman678
0
40
Amazon Builder's Library 輪読会資料 分散システムでのフォールバックの回避
kjman678
0
63
クリーンアーキテクチャ輪読会資料 12-14章
kjman678
0
33
Other Decks in Technology
See All in Technology
LINEギフト/ショッピングタブ
lycorptech_jp
PRO
0
160
チームとマネージャーと組織文化とわたし
hayatoshimiu
0
120
ツールの壁を越えろ!Backlog APIで実現する越境タスク管理
u_hoshi
0
200
組織規模に応じたPlatform Engineeringの実践
hacomono
PRO
0
240
「その開発、認知負荷高すぎませんか?」Platform Engineeringで始める開発者体験カイゼン術
sansantech
PRO
2
1.3k
メディアカンパニー LINE NEWS QA採用
lycorptech_jp
PRO
0
210
はじめてのOSS開発からみえたGo言語の強み
shibukazu
4
1.1k
測りにくい成果を測る — BtoB SaaSにおける効果検証への挑戦 / Shirokane Kougyou vol 20
sansan_randd
3
480
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
170
そろそろ FormatStyle
treastrain
1
430
What's new in Firebase / Google I/O 2025 報告LT会
atria
0
180
Создание мультиагентной системы на базе AI Studio
shwars
0
130
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Making the Leap to Tech Lead
cromwellryan
135
9.5k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
590
Facilitating Awesome Meetings
lara
56
6.5k
Fireside Chat
paigeccino
40
3.6k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Automating Front-end Workflow
addyosmani
1371
200k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
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