『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. ⾃⼰紹介 2 • 名前 ◦ George Yoshida • 部署 ◦ クラスメソッド クラウド事業本部 福岡オフィス • 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. re:Invent 2024ではリトライについてのセッションあり #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. セッションのアジェンダ 13 • リトライのお作法 ← 今回解説 • サーキットブレーカー • レイテンシーの外れ値を⼩さくする • コードを書くようにシミュレートする
14. retry VS no retry VS adaptive retry
15. エラーも⾊々 15 • OCCコンフリクト change conflicts with another transaction, please retry • スロットリング You have sent too many requests. Wait before trying again.
16. エラーも⾊々 16 • OCCコンフリクト change conflicts with another transaction, please retry すぐにリトライしても成功しそう • スロットリング You have sent too many requests. Wait before trying again. しばらく待たないと失敗しそう
17. Transient failure vs Systemic failure 17 • ⼀時的な障害(transient) ◦ ネットワーク障害など ◦ リトライすれば成功 ◦ クライアントはレイテンシーの微増 • システム障害(systemic) ◦ ロック、バグなど同じ原因で起こされ る障害 ◦ リトライは悪化させるだけ
18. システム障害時のリトライは悪影響 18 • サーバーが⾼負荷状態 • リクエストを受け付けない • オレンジ: ◦ リトライしない ◦ しばらくすると、リクエスト再開 • パープル: ◦ リトライする ◦ ⾼負荷のダメ出し ◦ 3回リトライ=4倍のトラフィック ◦ いつまで経っても負荷が収まらない
19. adaptive(bucket token)モードもある 19 • リトライする‧しないとは別にAdaptive Retry という考え⽅もある • APIのスロットリングやAWSのT系インス タンスのクレジットと同様 • 処理に対してトークン(クレジット)を消費 し、使いすぎると回復するまでお休み • 最⼤負荷をコントロールできる https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burst able-credits-baseline-concepts.html
20. Adaptiveは汎⽤的に使える 20 障害種類 一時的障害 システム障害 リトライ無し X ◯ リトライ有り ◯ X Adaptive ◯ ◯
21. Jitter & Backoff
22. Open System vs Closed System 22 • Open system ◦ ウェブサイトのようにリクエストタイ ミングが予測できないもの • Closed system ◦ ジョブワーカーのように、スループッ トが予測できるもの “Open versus closed: a cautionary tale” https://dl.acm.org/doi/10.5555/1267680.1267698
23. Backof vs Jitter 23 https://aws.amazon.com/builders-library/timeouts-retries-and -backoff-with-jitter/ • Backoff ◦ Exponential Backoffが有名 ◦ リトライのたびに、1(=2^0)秒、 2(=2^1)秒、4(2^2)秒、...と待ち時間 を指数的に伸ばす • Jitter ◦ 0秒から2N秒の間でランダムに待つ • 詳細はMarcさんがBuilder's Libaryに書い ている
24. Jitterは汎⽤的に使える 24 障害種類 Open Closed Backoff X ◯ Jitter ◯ ◯
25. AWS SDKにはリトライロジックが組み込まれている 25 https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html#standardvsadaptive
26. 遡ること10年前
27. Marc Brookerは10年前にも同じことをブログに書いてくる 27 https://aws.amazon.com/blogs/architecture/exponential-backoff- and-jitter/ • リトライモード(standard/adaptive)や BackoffとJitterやDynamoDBではOCC (Conditional Writes)が使えることを解説 • OCCとリトライはセットという考え • 冒頭には、8年が経過しても、相変わらず relisientなシステムに⽋かせないと追記 • ほとんどのAWS にSDKに組み込まれる様 になったとも
28. DSQL作者のリトライを⽀えるセッション #ARC403 28 https://www.youtube.com/watch?v=rvHd4Y76-fs
29. Everything fails all the time. Dr. Werner Vogels, VP & CTO at Amazon.com