The Amazon Builders Libraryの負荷制限の記事を読んだ際のメモ

• The Amazon Builders Libraryの以下の記事がすごく勉強になる内容だったので、読みながらとったメモを残しておこうと思います。

メモ

リクエスト数と可用性の関係を把握する方法

• 問題
  • 一般に同時リクエスト数が増え、あるラインを超えるとリクエストが確率的に失敗するようになる。つまり、負荷の増加によりシステムの信頼性が毀損する。そのような、収容性と可用性の関係をどう視覚化するか？
• 解決策
  • グッドプットとスループットをそれぞれ別個にグラフにプロットする方法を推奨
  • グッドプットは、 エラーなしで処理され、クライアントが応答を利用するのに十分な低レイテンシーで処理されるスループットのサブセット

画像の出典：https://aws.amazon.com/jp/builders-library/using-load-shedding-to-avoid-overload/

負荷試験の重要性

• 自動スケールの有効性を考える時はアムダールの法則を念頭に入れる。自動スケール機構を持つシステムでも、e2eで見るとスケールしない区間があることが多く、そのためやがて収容限界を迎えやすい
• 過負荷対策の設計をする前に、必ず負荷テストをしてボトルネック区間を把握する
• 負荷試験をやっていない場合、システムは考えうる限り一番被害甚大な方法で壊れると想定すべき

負荷の急増に対処するための負荷制限メカニズム

• 負荷の増加に応じて、自動スケールだけでなく負荷制限機構も動かし始める
• 負荷制限の有用な選択肢としては、以下の併用を推奨
  • リクエストの優先順位付け : トリアージする。優先すべきパケットとそうでないパケットを分ける
  • スロットリング :
• キューについては、QueueLengthだけでなく、enqueueされた各アイテムの最大滞在時間についても制限をかける
• ロードバランサの場合、高負荷時にはサージキューする方式よりは、早く高速にリクエストを失敗させる方式の方が機能することがわかった。AWSではCLBでは前者、次世代のELBでは後者を採用する設計になっている *1
• Linux OSのスロットリング機能、特にiptablesは有用なので、障害対応手順の中でiptablesを操作して負荷を軽減することは検討する価値がある。ELBの場合は、ソースipフィルタを利用することも可能
• API Gateway, LB, WAF, Linux OSなど複数のコンポーネントで多層的に防御することが大事 [2]

[1] CLBとELBの負荷制限の仕様の違いは、re:Invent2016の以下の動画を参照、とのことでした www.youtube.com

[2] Adrian Cockcoft が layers of defense という考え方を説明していたのを思い出しました。日本語では、セキュリティの文脈で縦深防御という言葉もあるようです。

They also have similar mitigations, and the way you protect against all these things is to have some layered defense in depth. If one thing breaks, there's another thing behind it to save you, and behind that maybe there's another thing. Depending on how critical it is, there's layers of defense. That applies to security, availability, safety. They're all the same.