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

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 

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. 

レジリエントなシステムのためのリトライの技術 #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推し)コードを書くようにシミュレートする システムの振る舞いをたくさんシミュレートすることで ⻑く運⽤しないと気付けないような課題に気づける 

no retry VS retry VS adaptive retry 

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

Transient failure vs Systemic failure 15 ● ⼀時的な障害(transient) ○ リトライすれば成功 ○ クライアント側でレイテンシーの微増 ○ 障害そのものに気づかないことも ● システム障害(systemic) ○ ロック、バグなど同じ原因で繰り返し 起こる障害 ○ リトライは悪化させるだけ 

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

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

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

Jitter & Backoff 

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 

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

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

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

今を遡ること10年前 

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

古くて新しいリトライを⽀えるセッション #ARC403 26 https://www.youtube.com/watch?v=rvHd4Y76-fs 

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

No content