第2回のオンライン輪読会は既に終わってしまったが、会に備えて読んだ内容を自分なりにまとめておく。
今回の記事はこちら。
前回同様、事前に何が書かれているかを予想しながら読んだ。こうした手法は精緻化リハーサルと呼ばれ、医学的にも効果が認められているらしいので。
[期待/予想する内容]
この記事の目次は次のとおりである。
- はじめに
- 過負荷の解析
- テスト
- 可視性
- 負荷制限メカニズム
- 過負荷について異なる考え方をする
- 参考文献
記事の本文を読む前に、目次から想定する内容を書き出してみる。
前回読んだロールバックの記事ほど目次に具体性がないのでちょっと厳しいが……。
「過負荷の解析」……過負荷を解析する手法やその際に気を付けるべきポイントについて書かれているのだろうか。そもそも解析をするのはいつだろう？本番で過負荷が観測されたとき？リリース前の負荷テスト中？解析は、やはり専門のネットワークエンジニアとかインフラエンジニアが担当するのだろうか、それとも負荷を生じさせているアプリケーションエンジニアと協力して進めたりするんだろうか。「負荷制限を使用して」とタイトルにあるが、制限を使用する主体は……インフラ担当？アプリ担当？どういうソフトウェアの作りになっているかにもよるから、一概に決められないかな。
「テスト」……当たり前だけど、過負荷が起きないようにするテストと、過負荷が起きたときのテストと、多分両方やってそう。でもタイトルの方向性からすると、過負荷が起きないようにするテストが重要ってことなんだろうか。
「可視性」……これは多分、過負荷が起きたときのモニタリングとかの話だろう。見えないものは回避のしようがない。見えるようにしておくことが大事なのは言うまでもないので、何を見るべきか、どのように見るべきかという話だろうか。最初の「過負荷の解析」が原因の分析に焦点を当てているのに対して、この章はまずは問題に気づくために、という話だろうか。だとしたら話の順番逆の方が分かりやすそうな気もするから、そういう内容じゃないかも。
「負荷制限メカニズム」……いよいよ本題っぽい。可視化された過負荷に対して、どのように制限をかけるか、ということだろう。具体的なソフトウェアの名前はあまり出ないだろうか……OSの、メモリやCPUなどのメトリクスの取り方とか、気をつけるべきメトリクスとか、負荷制限のリミットの上げ方とか？エクスポネンシャルバックオフアルゴリズムみたいな話も関連してくるだろうか。
「過負荷について異なる考え方をする」……これは何の章だろう……。タイトルからはいまいち予想ができない。
「参考文献」……なんだろう、『入門 監視』みたいな本が並んでいるんだろうか。
[記事の要約]
次に、実際に記事を読んだ内容を箇条書きでまとめる。
はじめに
- 著者：Amazonのサービスフレームワークチームに所属
- Route 53チームやElastic Load Balancingチームのサービス構築に役立つツール作成（認証、モニタリング、ドキュメント生成など）
- パフォーマンスや可用性関連のデフォルト値決められない問題
- 例：ロードバランサーとサーバー間の最大接続数（うまくいかず）
- ワークロードの変動や依存関係のパフォーマンス変化により、過負荷に
- うまくいった負荷制限について説明する
過負荷の解析
- 過負荷になる前にスケーリングして回避
- サーバーの使用率とレイテンシーは比例関係にある（ユニバーサルスケーラビリティ法則）
- サーバーのレイテンシーがクライアントのタイムアウトを超えるとエラー、可用性が低下する
- リクエストの再試行により、下部レイヤーのサービスが過負荷になる
- 負荷制限を利用すると、過剰な負荷が減るのでスループットをより長く維持できる
テスト
- サービスが破損するポイントを遥かに超えてテストをすることで、サービスの挙動を理解する
- スループットが増加して可用性が低下するなら負荷制限を検討すべし
- Chaos Monkeyを利用したテスト
- サーバーを削除することでそれ以外のインスタンスへの負荷を増やしてテスト（E2Eテストの代替にはならないので注意）
- クライアントの認識する可用性とレイテンシーも記録すべし
可視性
- 過負荷対策に有効なメトリクスを慎重に検討
- クライアントが誰か、どの操作を呼び出しているか、などなど
- サービスのレイテンシーが、失敗した（拒否された）リクエストのレイテンシーで汚染されないようにすべし
- アベイラビリティーゾーン障害が起きると負荷に耐える余力がない可能性がある
- なのでサービスが破損する限界までテストすべし
- 例：過剰なクローラリクエストは優先度が低いので、負荷制限してコストを節約
負荷制限メカニズム
- ロードバランサーからのpingリクエストは優先度が高い
- 検索インデックスのクローラのリクエストは優先度が低い
- スロットル制限を利用してクライアントを制限し、ワークロードを予測可能に
- クロックを同期して、リクエストにタイムアウトのヒントを含める
- 見積もりがタイムアウトを超える場合はリクエストを早期に削除
- ただし、キャッシュヒットやパーティション分割などで複雑なため、リクエストの評価は困難
- 時間のかかる処理でタイムアウトすると無駄が生まれるので、ページングなどにより制限する
- ELBでは、CLBはサージキューを利用していたがALBは過剰なトラフィックを拒否するようになった
- nginxなどのプロキシはリクエスト優先順位づけが困難なのでiptablesなど別レイヤーで保護すべし
過負荷について異なる考え方をする
- 過負荷状態でも、過剰な負荷を受け流し、予測可能なパフォーマンスを維持するのが重要
- 例：DynamoDBのキャパシティ
- Lambda、Fargate、ECSなどのサーバーレスはリソースが分離されており、スループットが増えてもグッドプットが維持される
- ただし、スロットルや同時実行数の制御など高レベルの手段で過負荷から保護する必要あり
[予想のふりかえりなど]
スループットとグッドプットの違いとか、可視化する上で、負荷状態でのリクエスト拒否実行時におけるレイテンシー汚染の話とか、言われればなるほど確かに、と思えるような内容が多かった。しかし、言われないと気がつけないので、読んでよかったと思う。
最後の、サーバーベースのアーキテクチャとサーバーレスアーキテクチャで考えることが違うという部分も、これまでぼんやりとしか捕らえられていなかったので、もう少し読みなおすといいことありそう。
今回の記事は日本語訳だけではスムーズに理解しづらい内容だった。英語の原文をすべて読んだわけではないので、訳文の問題なのかそもそも内容が難しいのか、理解し切れていない。
ともあれ、そういう難解な今回の記事をまとめて発表してくださった@kojiさん、ありがとうございました。
[まとめ]
ちょっと雑なまとめ方になってしまった……反省。
やはり時間に余裕を持って準備をしないといけない。次の輪読会は2日後……急がねば。
