Backoff 및 retry에 대한 질문

[algoORgoal]

302c4f1fcf00834473f00e3e5fffab980a5fb5a6에서 질문이 있습니다.

backoff stragedy를 exponential backoff로 선택한 과정이 궁금합니다!
그리고 retry 횟수도 어떤 기준으로 설정하시는지 궁금합니다.

[tgyuuAn]

@algoORgoal

302c4f1fcf00834473f00e3e5fffab980a5fb5a6에서 질문이 있습니다.

backoff stragedy를 exponential backoff로 선택한 과정이 궁금합니다! 그리고 retry 횟수도 어떤 기준으로 설정하시는지 궁금합니다.

헉!! 이 부분 저 처음 작성해봐서 일단 끄적여봤습니다..

대학교때 네트워크에서 충돌(?) 혹은 혼잡이 되었을 때 지수 백오프를 사용해서 해결할 수 있다라는 것을 배웠던 것 같아서 적용해보았습니다. (Slow Start 였어요!)

재시도 횟수는 임의로 3회에서 5회로 적용하였고, 맥시멈 10초로 설정한 이유는 안드로이드에서 5초만 넘어가도

ANR이 뜨는데 10초를 넘어가는 지수 백오프 대기시간은 사용자가 기다리지 못한다고 판단하여서 이것도 제 느낌대로 설정하였습니다 .. ㅎㅎ..

와우... 제가 그냥 쓴 코드인데도 이렇게 관심가져주시고 질문해주시니 부끄럽기도하고 앞으로 더 꼼꼼하고 잘 코드를 짜야겠다는 생각이 드네요...

이 프로젝트에 있는 코드들은 너무 부끄러운데...

[algoORgoal]

답변 감사합니다!

저도 컴퓨터 네트워크 시간에 tcp reno와 tahoe에서 네트워크의 혼잡 제어를 위해서 linear backoff와 exponential backoff를 배웠던 거 같은데, 제가 사용하고 있는 http client 라이브러리(ky)에서는 exponential backoff를 기본 값으로 설정했더라고요. linear backoff도 있는데 exponential backoff가 보통 많이 쓰나 궁금했습니다.

혹시, timeout이 발생하였을 때도 재시도를 하시는 편이신가요? timeout에 재시도를 설정하려면 라이브러리에서 따로 커스터마이징을 귀찮게 해야하는 부분이 있어서 좀 의아했는데, 제 개인적인 생각에는 timeout에 대해서도 재시도를 해주는 게 좋을 거 같아요. 생각하고 있는 플로우는 이렇습니다.

1. 요청을 보내기 직전에 사용자 기기가 offline으로 전환된다.
2. timeout error로 인해 '정보를 받아올 수 없어요' 에러를 보여준다.
3. 백그라운드에서는 재시도를 해보면서, online으로 돌아와서 요청이 정상적으로 받아졌을 때 success 화면으로 전환시켜준다.

그런데 여러 앱들을 사용해본 결과(당근마켓, 유튜브 등) timeout이 걸렸을 때는 굳이 retry를 안 하는 서비스들이 많은 거 같더라고요.
그래서 제가 혼자 잘못 생각하고 있는지도 궁금하네요..ㅎㅎ

[tgyuuAn]

@algoORgoal

답변 감사합니다!

저도 컴퓨터 네트워크 시간에 tcp reno와 tahoe에서 네트워크의 혼잡 제어를 위해서 linear backoff와 exponential backoff를 배웠던 거 같은데, 제가 사용하고 있는 http client 라이브러리(ky)에서는 exponential backoff를 기본 값으로 설정했더라고요. linear backoff도 있는데 exponential backoff가 보통 많이 쓰나 궁금했습니다.

혹시, timeout이 발생하였을 때도 재시도를 하시는 편이신가요? timeout에 재시도를 설정하려면 라이브러리에서 따로 커스터마이징을 귀찮게 해야하는 부분이 있어서 좀 의아했는데, 제 개인적인 생각에는 timeout에 대해서도 재시도를 해주는 게 좋을 거 같아요. 생각하고 있는 플로우는 이렇습니다.

1. 요청을 보내기 직전에 사용자 기기가 offline으로 전환된다.
2. timeout error로 인해 '정보를 받아올 수 없어요' 에러를 보여준다.
3. 백그라운드에서는 재시도를 해보면서, online으로 돌아와서 요청이 정상적으로 받아졌을 때 success 화면으로 전환시켜준다.

그런데 여러 앱들을 사용해본 결과(당근마켓, 유튜브 등) timeout이 걸렸을 때는 굳이 retry를 안 하는 서비스들이 많은 거 같더라고요. 그래서 제가 혼자 잘못 생각하고 있는지도 궁금하네요..ㅎㅎ

이 부분에 대해서 저도 더 공부해볼게용!!

일단은 말씀해주신 TimeOut이 일어났을 때에 재시도를 처리는 현재 되어있지 않지만, 유저의 특정 행동으로 인해 의도적으로 disconnect된 것이 아니라면 모두 재시도 해야한다고 생각합니다!

제 레포지토리에 찾아오셔서 이런 양질의 대화를 할 수 있게 해주셔서 정말 감사드립니다 (__).

이 부분에 대해서 추가적으로 알게되는 부분이 있다면 언제든지 또 찾아와주세요!😋😋

[tgyuuAn]

@algoORgoal

https://aws.amazon.com/ko/blogs/architecture/exponential-backoff-and-jitter/

지수 백오프만을 사용하면 Thndering Herd Problem이 생길 수 있음 (동시다발적으로 유저가 호출하는 경우의 문제)

이를 대비하여 지수 백오프에 랜덤으로 지연 시간을 할당하는 Jitter를 추가적으로 사용해야 함을 추천

https://www.nngroup.com/articles/response-times-3-important-limits/

최대 10초를 넘어가면 사용자들의 이탈률이 증가함.

10초가 넘어가는 요청의 경우에는 시각적으로 표시해주어야 함

하지만 재연결 작업은 백그라운드에서 동작하기 때문에 꼭 10초 이내를 사용해야한다 이런 건 없는 것 같아요.

근데 명확한 해답은 없어서 10초, 30초, 60초 정도에서 사용하시다가 트래픽에 문제가 생긴다 그러면 맥스 값을 높이는 식으로 사용하면 될 것 같아요.

[algoORgoal]

@algoORgoal

https://aws.amazon.com/ko/blogs/architecture/exponential-backoff-and-jitter/

지수 백오프만을 사용하면 Thndering Herd Problem이 생길 수 있음 (동시다발적으로 유저가 호출하는 경우의 문제)

이를 대비하여 지수 백오프에 랜덤으로 지연 시간을 할당하는 Jitter를 추가적으로 사용해야 함을 추천

https://www.nngroup.com/articles/response-times-3-important-limits/

최대 10초를 넘어가면 사용자들의 이탈률이 증가함.

10초가 넘어가는 요청의 경우에는 시각적으로 표시해주어야 함

하지만 재연결 작업은 백그라운드에서 동작하기 때문에 꼭 10초 이내를 사용해야한다 이런 건 없는 것 같아요.

근데 명확한 해답은 없어서 10초, 30초, 60초 정도에서 사용하시다가 트래픽에 문제가 생긴다 그러면 맥스 값을 높이는 식으로 사용하면 될 것 같아요.

서버 관점에서는 생각해본 적이 없는 문제인데 서버 부하를 분산시키기 위해 retry backoff에 무작위성을 넣어볼 수도 있겠네요.
다만 지터같은 경우 티켓팅, 쿠폰발급, 사전 공개 같이 짧은 순간에 클라이언트의 요청이 굉장히 많아질 경우가 효과가 좋을 것 같다고 생각이 듭니다.
좋은 글 올려주셔서 감사합니다.

10초 이상의 지연 시간이 걸리는 경우 대부분 파일 업로드 및 다운로드에서 시간이 오래 걸릴 것이기 때문에 progress indicator를 배치하면 좋을 것 같기도 하네요.
https://www.youtube.com/watch?v=4GWqJEfzvmg

[tgyuuAn]

서버 관점에서는 생각해본 적이 없는 문제인데 서버 부하를 분산시키기 위해 retry backoff에 무작위성을 넣어볼 수도 있겠네요. 다만 지터같은 경우 티켓팅, 쿠폰발급, 사전 공개 같이 짧은 순간에 클라이언트의 요청이 굉장히 많아질 경우가 효과가 좋을 것 같다고 생각이 듭니다. 좋은 글 올려주셔서 감사합니다.

그렇네요. 아무래도 웹소켓 연결보다는 사전 공개, 이벤트 페이지와 같이 트래픽이 단기간에 쏠리는 곳에서 Jitter를 도입하면 좋겠네요.

이 글을 조금더 빨리 봤더라면 지수 백오프만 도입했을텐데 하하하.

머리 맞대니 정말 재밌네용 😋

[Turtle-Hwan]

와 좋은 글 잘 읽었습니다. 감사합니다!

[tgyuuAn]

@algoORgoal @Turtle-Hwan

그럴지는 모르겠는데, 웹소켓 로직에 대해서 아주 드물게 간혹 서버가 문제가생겨 클라이언트의 로직이 모두 끊겼을 때 모두 재시도를 하게 되면 Thndering Herd Problem이 생길 수 있어서,

웹소켓 백오프 전략에도 Jitter를 추가해주면 좋다고 하네요.

클라이언트 딴에서의 약간의 보험인 것 같아요. 구현 비용도 비싼게 아니니.