Retry も重要。このへんが Application によってしてくれたりしてくれなかったりするのを Envoy がしてくれると助かるよね。
- Envoy は Resilience のために retry を system の外で実装できるぞ
- Choose appropriate defaults
- Limit retry-able requests
- Consider the calling context
Choose appropriate defaults / A typical Envoy retry policy
まぁ simple な retry 設定はこんな感じ
retry_on: "5xx" num_retries: 3 per_try_timeout_ms: 2000
ふむ。
それぞれ default 値がある。 per_try_timeout_ms は retry のときの timeout, default は通常の request のときの timeout。
Limit Retry-able Requests
- Retry 可能であるものだけを Retry すべき
- つまり non idempotent 冪等でないリクエストは Retry すべきではない
- キャンセルできないリクエストも同様
- http GET なんかはリトライしやすい好例
Consider the Calling Context
リトライを設定するときには呼び出し側がどのようにリクエストするかを考慮する必要がある。
parameter としては timeout_ms , per_try_timeout_ms , num_retries とある。 per_try_timeout_ms * num_retries は timeout_ms を超えられない。retry ははやめに fail させたほうがよい。
また、global timeout がない場合で、timeout も長く retry がある場合はパフォーマンスは大きく低下する。このような高ファンアウト処理は retry をするべきではない。
最後に、retry と合わせて circuit breaking を同時に設定したほうがいい。retry は cascading failure を招きかねない。それを防ぐためにも必要。
このへん、最終的にはチューニング必要なんだなと思いつつ、前提としての考え方はめっちゃ重要だと思った。
