『AWS Distinguished Engineerに学ぶ リトライの技術』 #ARC403/Marc Brooker on Try again: The tools and techniques behind resilient systems

https://jawsug-fukuoka.connpass.com/event/341319/

Transcript

1. 2025/02/08 JAWS-UG福岡 #19: re:Invent re:Cap!! George Yoshida AWS Distinguished Engineerに学ぶ リトライの技術 #ARC403
2. George Yoshida 2 • 部署 ◦ クラスメソッド クラウド事業本部 エンジニア （東京→ベルリン→）福岡オフィス • 技術ブログ ◦ https://dev.classmethod.jp/author/quiver/ • re:Invent参加回数 ◦ 2024年が4回⽬ • Awards ◦ 2024 Japan AWS Top Engineers(Database) ◦ 2024 AWS All Certifications Engineers w/ Raluca Constantin Senior Database Engineer @ Distributed SQL database team
3. re:Invent 2024の⽬⽟は分散データベースAmazon Aurora DSQL 3
4. Aurora DSQLは楽観的同時実⾏制御(OCC)を採⽤ 4 • DSQLは分散データベース • 悲観的にロックすると、スケールしないという学び • 同時トランザクションの更新が競合したら、アボートすれば良い Using OCC with Aurora DSQL is well-suited due to its distributed architecture, because it allows for higher throughput and system efficiency by avoiding the need for resource locking during transaction execution. https://aws.amazon.com/blogs/database/concurrency-control-in-amazon-aurora-dsql/
5. OCCで競合が起きたらリトライすれば良い 5 • PCCのロック待ちの世界からOCCの競合の世界への発想転換 • DynamoDBのConditional Writesでおなじみ • 競合発⽣時のリトライではbackoffやjitterが肝 Effectively managing OCC exceptions in distributed systems requires a comprehensive retry strategy that can incorporate backoff and jitter in the case that very high contention areas of the application key space (hot keys) can’t be avoided. https://aws.amazon.com/blogs/database/concurrency-control-in-amazon-aurora-dsql/
6. システム間通信はいろいろな例外が発⽣する 6 • API呼び出し過多のスロットリング例外はどうすれば良い? An error occurred (ThrottlingException) when calling the InvokeModel operation (reached max retries: 4): Too many requests, please wait before trying again. You have sent too many requests. Wait before trying again.
7. レジリエントなシステムのためのリトライの技術 #ARC403 7 https://www.youtube.com/watch?v=rvHd4Y76-fs
8. Marc Brookerって誰? 8 • ロール ◦ AWS VP/Distinguished Engineer • 経歴 ◦ AWS Lambdaの育ての親 https://podcasts.apple.com/be/podcast/aws-lambda-a-decade -of-transformation/id1574162669?i=1000675303451
9. Marc Brookerって誰? 9 • ロール ◦ AWS VP/Distinguished Engineer • 経歴 ◦ AWS Lambdaの育ての親 ◦ Amazon Aurora DSQLの産みの親 ▪ re:Invent 2024でセッションx2 ▪ 個⼈ブログでもDSQLの誕⽣秘話 を熱く語る https://brooker.co.za/blog/
10. “Try again: The tools and techniques behind resilient systems” を5分でさらうのは無理でした
11. セッションのアジェンダ 11 • リトライのお作法 • サーキットブレーカー • レイテンシーの外れ値を⼩さくする • コードを書くようにシミュレートする
12. セッションのアジェンダ 12 • リトライのお作法 ← 今回解説 • サーキットブレーカー • レイテンシーの外れ値を⼩さくする • (Marc推し)コードを書くようにシミュレートする システムの振る舞いをたくさんシミュレートすることで ⻑く運⽤しないと気付けないような課題に気づける
13. no retry VS retry VS adaptive retry
14. エラーも⾊々 14 • OCCコンフリクト change conflicts with another transaction, please retry すぐにリトライしても成功しそう • スロットリング You have sent too many requests. Wait before trying again. しばらく待たないと失敗しそう
15. Transient failure vs Systemic failure 15 • ⼀時的な障害(transient) ◦ リトライすれば成功 ◦ クライアント側でレイテンシーの微増 ◦ 障害そのものに気づかないことも • システム障害(systemic) ◦ ロック、バグなど同じ原因で繰り返し 起こる障害 ◦ リトライは悪化させるだけ
16. システム障害時のリトライは悪影響 16 • サーバーが⾼負荷状態(systemic failure) • リクエストを受け付けない • オレンジ:リトライしない ◦ しばらくすると、リクエスト再開 • パープル:リトライする ◦ 3回リトライ=4倍のトラフィック ◦ ⾼負荷時にダメ出し ◦ いつまで経っても負荷が収まらない
17. adaptive(bucket token)モードもある 17 • リトライする‧しないとは別にAdaptive Retry という考え⽅もある • APIのスロットリングやAWSのT系インス タンスのクレジットと同様 • 処理に対してトークン(クレジット)を消費 し、使いすぎると回復するまでお休み • クレジットで最⼤負荷をコントロール https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burst able-credits-baseline-concepts.html
18. Adaptiveは汎⽤的に使える 18 障害種類 一時的障害 システム障害 リトライ無し X ◯ リトライ有り ◯ X Adaptive ◯ ◯
19. Jitter & Backoff
20. Open System vs Closed System 20 • Open system ◦ ウェブサイトのようにリクエストタイ ミングが予測できないもの • Closed system ◦ ジョブワーカーのように、スループッ トが予測できるもの “Open versus closed: a cautionary tale” https://dl.acm.org/doi/10.5555/1267680.1267698
21. Backof vs Jitter 21 https://aws.amazon.com/builders-library/timeouts-retries-and -backoff-with-jitter/ • Backoff ◦ Exponential Backoffが有名 ◦ リトライのたびに、1(=2^0)秒、 2(=2^1)秒、4(2^2)秒、8(2^3)...と待ち 時間を指数的に伸ばす ◦ リトライタイミングがかぶる • Jitter ◦ 0秒から2N秒の間でランダムに待つ • 詳細はMarcさんがAmazon Builder's Libaryに書いている
22. Jitterは汎⽤的に使える 22 障害種類 Open Closed Backoff X ◯ Jitter ◯ ◯
23. AWS SDKにはセッションのリトライロジックが組み込まれている 23 https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html#standardvsadaptive
24. 今を遡ること10年前
25. Marc Brookerは10年前にも同じことをブログに書いてくる 25 https://aws.amazon.com/blogs/architecture/exponential-backoff- and-jitter/ • リトライモード(standard/adaptive)や Backoff/JitterやDynamoDBではOCC (Conditional Writes)が使えることを解説 • OCCとリトライはセットという考え • Marcが⼤事と訴えるシミュレーション付 • 冒頭には、8年経過しても、相変わらず relisientなシステムに⽋かせないと追記 • ほとんどのAWS にSDKに組み込まれる様 になったとも
26. 古くて新しいリトライを⽀えるセッション #ARC403 26 https://www.youtube.com/watch?v=rvHd4Y76-fs
27. Everything fails all the time. Dr. Werner Vogels, VP & CTO at Amazon.com