HTTP Retry の実装

HTTP Retryの実装 AI事業本部アプリ運用センター岩見彰太

自己紹介岩見彰太趣味：サックス・ドローン・カメラ AI事業本部小売DX アプリ運用センター 22卒バックエンドエンジニア B_Sardine

事の発端とあるAPIに対して特定のステータスコードの時に Exponential Backoffによるリトライを実装したい

最初こんな感じで実装してみたということで…

client.Do(req)を実行する responseのステータスコードが429ならエラーを返すエラーだった時にリトライする cenkalti/backoff 用メソッド maxRetryNumberで設定した回数だけリトライする

最初の1回目以降、Request Bodyが空だと怒られて Do がエラーになる適当なサーバを立てて叩いて見ると…

こんな感じで、Bodyを入れ直すと通る Bodyの巻き戻し. 入れ直しが必要先に結論

Requestの構造体を見てみる Bodyはio.ReadCloserというインターフェース型今回入れた具象型はbytes.Buffer 複数回リトライする場合, これが複数回実行される bytes.Bufferの構造体を見てみる lastReadという読み切った場所を内部で保存してるなぜなくなる？リトライする場合は Request.Bodyを初期状態に戻す必要がある
つまり…

http.Clientの中のTrasport.roundTripがリトライ処理してるネットワークエラーとかになった時にリトライしてる rewindBodyというメソッドを呼んでる Request.Bodyを閉じる body, err := req.GetBody()でRequst.Bodyのコピーを取り出す
取り出したものをもう一度reqに入れる rewindBodyの流れ 1. 2. 3. 実はnet/httpもリトライしてるコネクションの確立とかコネクションプールの管理を行なってる Transport

*bytes.Buffer <----- 今回の場合 *bytes.Reader *strings.Reader Request.Bodyの具象型が以下の時に GetBodyがセットされる io.NopCloser は何もしない io.ReadCloser
（Bodyで指定されているinterface型）を実装できる req.GetBody()は Request作成時に作られる

Transport.roundTripでも終了判定しているリトライをする場合、呼び出し元のcontextを伝播する必要がある同じように判定する必要がある Contextの終了を確認する

レスポンス内容はio.ReadCloserの Response.Bodyから読み取れる呼び出し側で最後まで読み取ってから Close しないと keep-aliveの TCPコネクションが再利用されないレスポンスを返した後に接続を維持し、次のリク
エストを送るときにその接続を再利用して送ることができる Keep-AliveはResponseが読み切られてCloseしたタイミングで再利用できるようになる > Bodyを閉じるのは呼び出し側の責任である。 > デフォルトの HTTP クライアントの Transport は、Body を最後まで読んで閉じないと、 HTTP/1.x の "keep-alive" TCP コネクションを再利用しないかもしれません。 Keep-Alive http.Response.Bodyを読み切ってから閉じる

Transport 内部では、connectMethodKey（接続先）単位で idel 状態のTCPコネクションや確立待ちのキューが管理されているこれがデフォルトの場合はDefaultTransportが使用される 90s: IdleConnTimeout（リクエストが終わってもコネクションが維持される時間） 2:
MaxIdleConnsPerHost（接続先ごとのKeep-Aliveの最大数） TransportでのTCPコネクションの管理

CloseIdleConnections()でコネクションプールを一括で閉じることができるリトライ終了後に意図的に解放したい場合は使える（これを呼ばない場合、IdleConnTimeoutが過ぎると自動的に解放される）コネクションプールを閉じる

リトライが必要となる場面（429 Too Many Requests）では、短期間で同じ宛先にリクエストする場合そうなると、 MaxIdleConnsPerHost だと少ない可能性が高いリトライしている期間中占有してしまい、解放まで時間がかかる可能性があるから場合によっては専用の
Transport を作成した方がいいこの場合、使わないのに IdleConnTimeout で設定されている時間分 Keep-Alive が保持されて、コネクションリソースを消費してしまうので、リトライが終了した後は CloseIdleConnections を読んでコネクションプールを開放するべき　（終了したらコネクションプールを閉じる）リトライ用のTransportを別で用意するべき？

ただリトライしたいだけなのに考えること多くてめんどくさい… ここら辺まるっとやってくれる便利なライブラリないのか……

今まで説明してきたようなことが考慮されてる TransportはMaxIdleConnsPerHostを増やして、リトライ後には閉じるようになっている net/httpと同じように使えて直感的 -> 結局これを使いました Hashicorp製 hashicorp/go-retryablehttp ありました

まとめリクエストの内容（Request.Body）をリトライ前に巻き戻す Request.Context()の終了を確認するリトライ前にResponse.Bodyを全て読み切ってから閉じるデフォルトのTransportを使用してコネクションプール管理するか検討する hashicorp/go-retryablehttpの使用を検討するちなみに、AWS SDK for GoとかでAPIコールする場合は、勝手にリトライしてくれるようになってる

HTTP Retry の実装

HTTP Retry の実装

Shota Iwami

More Decks by Shota Iwami

Other Decks in Programming

Featured

Transcript