入門リトライ

Transcript

1. ⼊⾨ リトライ 再試⾏を制するものは信頼性を制するかもしれない編 渡部⿓⼀ Road to SRE NEXT@札幌
2. • リトライの重要性 • 実装編 • どのレイヤーでやるの？ • TCP再送制御 • まとめ アジェンダ
3. • 渡部⿓⼀ • 株式会社IVRy SRE • X: @ryuichi_1208 • SRE NEXT Co-Chair • 札幌は4回⽬ • 障害対応‧EOL対応 ⾃⼰紹介
4. 株式会社 IVRy • 対話型⾳声AI SaaS ◦ 最⾼の技術をすべての企業に届ける • Architectureプロジェクト SREチーム ◦ 全⼈類が電話をかけてきても耐えられるサービスを⽬指す
5. リトライの重要性
6. リトライしてますか？
7. • 1台の物理マシンかつ1プロセスで完結するサービスは少ない • モノリス、マイクロサービス • プロセス間通信、LAN内の通信、インターネット越しの通信 • プロセス内からプロセス間へ 現代のアプリケーション
8. • 同⼀のプロセス内で⾏われるデータやメソッドの呼び出しを指す • 以下の理由で⾼速 ◦ メモリ空間を共有する ◦ オーバーヘッドが⾮常に少ない ◦ 迅速なデータの転送（メモリ内での参照渡しが可能） • 10,000回呼び出せば10,000回成功する プロセス内通信
9. • パイプ • メッセージキュー • 共有メモリ • セマフォ • シグナル • ソケット プロセス間通信 (IPC)
10. • ネットワークの信頼性 ◦ ネットワークは障害が起きるし遅延も起きる ▪ ケーブルや中間機器の故障、プロトコルのオーバーヘッド、 ▪ 帯域、ルーティング、トラフィックの競合 • それが原因でネットワーク越しのプロセス間通信の失敗を引き起こす可能性がある プロセス間通信における信頼性
11. • そういった障害は相⼿のサーバが⼀時的に繋がらなかっただけの可能性もある ◦ ⾼負荷によって繋がらない ◦ デプロイ起因などで障害が起きていた ◦ OOMとかでプロセス再起動が発⽣して瞬断が発⽣していた • 時間が経ったら正常に繋がるようになる可能性がある プロセス間通信における信頼性
12. リトライしたら成功しそう！
13. 全部リトライだ！
14. • そんなことはない • プロセス間通信で発⽣するエラーには、「⼀時的なエラーと永続的なエラー」がある • エラーに合わせてリトライ可否を判断する必要がある エラーは全てリトライすれば良いのか？
15. • 失敗が⼀時的なものであり、リトライによって回復する可能性がある ◦ ネットワークの瞬断 ◦ サーバ側の⼀時的な⾼負荷 ◦ タイムアウトや接続の遅延 ◦ HTTPレスポンスコード ▪ 502 Bad Gateway ▪ 503 Service Unavailable ▪ 504 Gateway Timeout ⼀時的なエラー
16. • エラーの原因が解決可能でない、または根本的な問題がある場合であり、リトラ イを試みても問題が解決しないことが多い ◦ 不正なデータの送信、要求の送信 ◦ HTTPレスポンスコード ▪ 400 Bad Request ▪ 401 Unauthorized ▪ 404 Not Found(キャッシュで⾒れないとかはあり得る) 永続的なエラー
17. ⼀時的なエラーは全部リトライだ！
18. • リトライは必ずしも安全ではない • 冪等でないAPIは、同じリクエストを複数回実⾏すると、異なる結果が⽣じる可 能性がある ◦ 例えば、データベースへの書き込み操作が冪等でない場合、リトライによっ て意図しないデータの重複や⽭盾が発⽣するかもしれない • リトライを⾏う場合は、APIをべき等になるように設計することが推奨される 冪等性も重要
19. • サーバ側の操作がRDBとのやり取りだけならBEGIN ~ COMMITで括る ◦ トランザクションが失敗した場合リトライ • 外部のAPIとかDBを2つ使うとか普通にあるのでRDBのようには⾏かない ◦ RDSに書いてDynamoDBにも書いて〜みたいなやつ ◦ 分散トランザクション...?? ▪ XA, 2PC, Paxos, Raft • ロールバックを考慮すると操作単位で冪等性を担保しておく トランザクションでなんとかなる...のか?
20. リトライの実装
21. 素朴にリトライ
23. No Sleepでリトライ
24. • クライアントが⼀時的な障害を検知し、⼤量のリクエストをリトライ • サーバーが⾼負荷になり、さらに レスポンスが遅延‧エラー増加 • クライアントが 「まだ応答がない」 とさらにリトライ • 結果、システム全体が スローダウンする リトライの連鎖
25. • サーバーやネットワークに問題が発⽣した場合、複数のクライアントでほぼ同時 に問題が起こることがある • 通常時は1,000[req/sec]のところが2,000[req/sec]とかになり得る • リトライ間隔にブレを持たせることで、リトライのタイミングをある程度分散さ せることが期待できる リトライにおけるsleep（待機）の重要性
26. • 待機時間が指数的に増加するため、初回のリトライ後に少しだけ待機し、次第に リトライ間隔を⻑くする ◦ 1回⽬: 2秒、2回⽬: 4秒待機、3回⽬: 8秒待機 • 最初のリトライではサーバが⼀時的に回復する時間を与え、徐々に負荷が減少す る可能性が⾼まる Exponential Backoff（指数バックオフ）
28. • デジタル信号における「揺らぎ」のこと • リクエストのタイミングをランダムにずらす ◦ 複数のクライアントが同じタイミングでリトライを⾏うのを避けるために使 ⽤する • 指数バックオフと組み合わせることで、さらに効果的に動作する jitter
31. • HTTPS通信の場合はDNSで名前解決して、TCPのハンドシェイクしてTLSのハン ドシェイクしてデータを送信する • どこのレイヤーでエラーが起きているのか次第では何をリトライすれば良いのか がわかる ◦ DNSで名前解決したIPの宛先が落ちていた場合 ◦ リクエスト処理中のサーバ側が原因の場合 • TCP接続からやり直すのが良いのか接続後のHTTPリクエストだけをやり直せば良 いのかはそれぞれ別で考えておく 何をリトライする？
32. • Exponential Backoffの課題としてレイテンシの増加やスループットの低下 • 再送間隔を増加させるためレイテンシがどんどん⻑くなる ◦ ユーザー体験に悪影響を与える可能性がある ◦ リトライ間隔は指数関数的バックオフを使うとともに、最⼩待機時間を 50msに設定し、最⼤待機時間を200msに制限 ▪ DynamoDBとかだと推奨されている設定 SLO: p99.99で500msのサービスでリトライは？
33. • アーキテクチャの最適化 ◦ インターネット越しのAPI通信はネットワーク遅延や不安定さが原因でリト ライが増えがち ◦ インターネットを通さないようにする、キャッシュ、フォールバック • SLI/SLOの⾒直し ◦ ユーザー体験を考慮し、「リトライしても成功しない可能性が⾼い場合は、 最初のエラーで諦める」設計 ◦ 機能⾃体を縮退してユーザーには最低限レスポンスを返す ▪ 重要でない操作は再試⾏してスループットに影響を与えるよりも、フェ イルファストする SLO: p99.99で500msのサービスでリトライは？
34. どのレイヤーでやる？
35. • 1つの⾔語、1つのアプリケーションが1つのサーバとだけやり取りするならアプ リケーションコードで実装すれば良さそう • 数種類の⾔語で書かれた100以上のアプリケーションがそれぞれ100以上のサーバ とプロセス間通信するようになったら？？ • 指数関数的にリトライロジックを実装する必要が出てくる • アプリのビジネスロジック開発に集中したい！ リトライの設定
36. • インフラ層でリトライやトラフィック管理を⼀元化する ◦ Envoy や Nginx などのプロキシ • アプリケーションはGatewayに対してHTTPリクエストを投げておくだけでイン フラ層でリトライ制御を実装してくれる • リトライ制御だけでなくCircuit Breakerとしても働く ◦ 障害発⽣時にリトライを⼀定時間停⽌し、過負荷状態を防ぐ 役割 • リトライが発⽣したかの監視もやりやすかったりする ◦ 特定の時間に⼤量にリトライが発⽣していたなどを後から追える API Gateway / Service Proxy
37. • BerriAI/litellm • OpenAI形式の100以上のLLM（OpenAI、Bedrock）への呼び出し • リトライ制御以外にも予算やレート制限の設定などを管理できる • LLMを使ったプロダクトに置いてリトライ制御やフォールバックのはとても重要 (コラム)LiteLLM Proxy
38. TCPの再送制御
39. • HTTP/1.1, HTTP/2他の多くのネットワークプロトコルでも多く使われている • TCPは、接続型のプロトコルであり、送信側と受信側の間でデータが順序通り に、かつ信頼性を持って送信されることを保証している • データが確実に⽬的地に到達することを保証するために、さまざまな仕組みを提 供している • RFC 9293でも「3.8.1. Retransmission Timeout」として書かれている • synやackが届かない場合のリトライについても決まっている TCPの再送制御
40. • 再送タイムアウト（RTO） ◦ 再送は、RTO（Retransmission Timeout）というタイマーを基に⾏われる ◦ 送信側はデータを送信後、⼀定の時間内にACKを受け取れなかった場合、そ のデータを再送する ◦ RTOの時間は、通常、ネットワークの遅延や輻輳状態によって動的に決まる ◦ OSごとにデフォルトだったり実装が異なる ▪ Linuxではカーネルパラメータで設定をすることができる • tcp_syn_retries • tcp_retries2 TCPの再送制御
41. https://ryuichi1208.hateblo.jp/entry/2021/02/10/000000_1
42. まとめ
43. • ネットワーク越しに通信を⾏うアプリケーションの信頼性を⾼めるためにリトラ イは重要な技術の⼀つ • サービスレベルに合わせたタイムアウトや再送間隔の調整も重要 • リクエストの殺到を防ぐためにsleep（待機）が重要であり、Exponential Backoffやジッターの追加が有効 まとめ
44. 参考書籍
45. • SRE サイトリライアビリティエンジニアリング / オライリージャパン • マイクロサービスアーキテクチャ 第2版 / オライリージャパン • 実⽤ Go⾔語 / オライリージャパン • UNIXネットワークプログラミング Vol.1 第2版 / ピアソン‧エデュケーション • TCP技術⼊⾨ / 技術評論社 • マイクロサービスパターン / インプレス 参考書籍
46. ご清聴ありがとうございました