2025/02/08 JAWS-UG福岡 #19: re:Invent re:Cap!! George Yoshida AWS Distinguished Engineerに学ぶ リトライの技術 #ARC403

⾃⼰紹介 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

re:Invent 2024の⽬⽟は分散データベースAmazon Aurora DSQL 3

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/

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 ● 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.

re:Invent 2024ではリトライについてのセッションあり #ARC403 7 https://www.youtube.com/watch?v=rvHd4Y76-fs

Marc Brookerって誰? 8 ● ロール ○ AWS VP/Distinguished Engineer ● 経歴 ○ AWS Lambdaの育ての親 https://podcasts.apple.com/be/podcast/aws-lambda-a-decade -of-transformation/id1574162669?i=1000675303451

Marc Brookerって誰? 9 ● ロール ○ AWS VP/Distinguished Engineer ● 経歴 ○ AWS Lambdaの育ての親 ○ Amazon Aurora DSQLの育ての親 ■ re:Invent 2024でセッションx2 ■ 個⼈ブログでもDSQLの誕⽣秘話 を熱く語る https://brooker.co.za/blog/

“Try again: The tools and techniques behind resilient systems” を5分でおさらい

セッションのアジェンダ 11 ● リトライのお作法 ● サーキットブレーカー ● レイテンシーの外れ値を⼩さくする ● コードを書くようにシミュレートする

セッションのアジェンダ 12 ● リトライのお作法 ● サーキットブレーカー ● レイテンシーの外れ値を⼩さくする ● (Marc推し)コードを書くようにシミュレートする システムの振る舞いをたくさんシミュレートすることで ⻑く運⽤しないと気付けないような課題に気づける

セッションのアジェンダ 13 ● リトライのお作法 ← 今回解説 ● サーキットブレーカー ● レイテンシーの外れ値を⼩さくする ● コードを書くようにシミュレートする

retry VS no retry VS adaptive retry

エラーも⾊々 15 ● OCCコンフリクト change conflicts with another transaction, please retry ● スロットリング You have sent too many requests. Wait before trying again.

エラーも⾊々 16 ● OCCコンフリクト change conflicts with another transaction, please retry すぐにリトライしても成功しそう ● スロットリング You have sent too many requests. Wait before trying again. しばらく待たないと失敗しそう

Transient failure vs Systemic failure 17 ● ⼀時的な障害(transient) ○ ネットワーク障害など ○ リトライすれば成功 ○ クライアントはレイテンシーの微増 ● システム障害(systemic) ○ ロック、バグなど同じ原因で起こされ る障害 ○ リトライは悪化させるだけ

システム障害時のリトライは悪影響 18 ● サーバーが⾼負荷状態 ● リクエストを受け付けない ● オレンジ: ○ リトライしない ○ しばらくすると、リクエスト再開 ● パープル: ○ リトライする ○ ⾼負荷のダメ出し ○ 3回リトライ=4倍のトラフィック ○ いつまで経っても負荷が収まらない

adaptive(bucket token)モードもある 19 ● リトライする‧しないとは別にAdaptive Retry という考え⽅もある ● APIのスロットリングやAWSのT系インス タンスのクレジットと同様 ● 処理に対してトークン(クレジット)を消費 し、使いすぎると回復するまでお休み ● 最⼤負荷をコントロールできる https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burst able-credits-baseline-concepts.html

Adaptiveは汎⽤的に使える 20 障害種類 一時的障害 システム障害 リトライ無し X ◯ リトライ有り ◯ X Adaptive ◯ ◯

Jitter & Backoff

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

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に書い ている

Jitterは汎⽤的に使える 24 障害種類 Open Closed Backoff X ◯ Jitter ◯ ◯

AWS SDKにはリトライロジックが組み込まれている 25 https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html#standardvsadaptive

遡ること10年前

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に組み込まれる様 になったとも

DSQL作者のリトライを⽀えるセッション #ARC403 28 https://www.youtube.com/watch?v=rvHd4Y76-fs

Everything fails all the time. Dr. Werner Vogels, VP & CTO at Amazon.com

No content