참고 : http://www.infoworld.com/article/3138018/security/developers-dont-ddos-your-own-apps.html ,
https://cloudplatform.googleblog.com/2016/11/how-to-avoid-a-self-inflicted-DDoS-Attack-CRE-life-lessons.html
앱의 기본 데이터 리프레시 주기와 서버의 장애시 재시도 주기가 고정된 값을 갖는 경우 둘이 겹치는 상황에서 트래픽이 배가 되어 앱 스스로 자신의 서비스에 DDoS 공격과 유사한 상황을 야기하고 이러한 좋지않은 주기가 반복되는 문제에 대한 이야기인데..
구글 엔지니어가 이야기하는 3가지 해법은 다음과 같다.
지수의 형태로 증가하는 지연시간(exponential backoff)
고정된 짧은 재시도 주기를 사용할 경우 로드벨런서에 요청이 쌓이고 서버가 정상으로 돌아왔을 때 과부하 상황을 야기하기 좋기 때문에 고정된 재시도 주기가 아닌 1, 2, 4, 8, 16과 같은 형태로 재시도 주기를 증가 시키고 정상적인 상황의 동기화 주기가 15분이라면 재시도 주기는 최대 16 정도로 잡을 수 있다. 하지만 이역시 다수의 장비들의 재시도 주기가 동기화 되는 현상을 해결하기엔 부족하다..
무작위 주기를 더하거나 빼기(a little jitter)
장시간 서버의 다운타임을 겪게 되면 지수의 형태로 증가하는 지연시간을 이용하더라도 재시도 주기가 맞물리는 현상은 발생하며 이를 피하기 위해 지연시간에 +/- 고정 비율의 주기에서 랜덤하게 시간을 선택할 수 있다. 예를 들면 다음 재시도 주기가 4분에 30% 비율을 이용하기로 했다면 최소 2.8분 최대 5.2분 사이의 값을 랜덤하게 적용하도록 하는 것이다.
이 방법은 실생활에서 폰과 컴퓨터 사용자들의 수면과 기상 패턴과 같은 점을 고려 했을 때 일반적인 동기화 주기에 적용해도 효과가 있다고 한다.
재시도 횟수 기록하기(retry marking)
대규모 분산 시스템의 경우 장애에서 전체 처리량이 완전히 복구 되기 까지 어느정도 시간이 걸리기 때문에 앞의 두가지 방법 만으로는 충분하지 않다.
이를 해소하기 위한 손쉽고 효과적인 방법으로 클라이언트에서 정상적인 연결과 재시도 횟수의 비율을 기록해 백엔드에서 접속의 우선순위를 두는 것이며 이에대한 판단은 사업의 성격에 따라 다를 수 있다.
