The Tail at Scale을 읽고

구글에서 2013년에 쓴 글인데 너무 배울게 많다… https://ai.google/research/pubs/pub40801

응답시간이 왜 중요한가?

• 사용자 체감 때문에
• interactive usage (eg VR)이 많아지면 더 중요

왜 같은 요청인데 응답 시간이 차이가 나나?

• 머신의 다른 앱들이 자원을 많이 먹어서
• GC, 로그 머지 등의 비정기적인 작업
• 같은 자원을 두고 경쟁하니까 등등

tail latency의 중요성

• 보통 작업 하나는 작은 요청 여러개를 수반하는데 그 중 하나가 느리면 전체 작업 완료가 느려질 수밖에 없다.
  • 예를 들면 서버 한 대가 1/10000 의 확률로 응답에 1초 이상 걸린다고 하면
  • 이런거 2000개를 가지고 만드는 응답은 대략 1/5 확률로 응답에 1초 이상 걸린다고

설계 레벨의 노력들

• 빠른 응답을 요하는 요청이랑 그렇지 않은 요청을 구분
  • 후자가 전자를 block 하지 않도록
• 큰 작업을 작은 작업으로 나눔
  • 큰 작업 수행 때문에 다른 작업이 수행이 못되는 경우가 없도록
• 백그라운드 작업 관리
  • 쪼개서 돌리기, 안바쁠때 돌리기, 쓰로틀링 등등
  • 여러 대에서 동시에 돌리는 것이 한 대씩 돌아가면서 돌리는 것보다 tail latency에 도움이 된다
• 캐싱은 논외로 하자
• 그럼에도 불구하고 tail latency는 생긴다

피할 수 없다면 공생해야 한다 - 짧은 요청의 경우

• hedged request
  • 요청을 보냈는데 p95 응답시간 지나도 완료가 안된다? 이 때 다시 요청을 보낸다
  • 이러면 전체 요청 개수는 5%만 늘어나는데, 전체 tail latency는 확 준다
  • 이 hedge request의 priority를 일반 request보다 높게 주면 효과가 더 좋다
• tied request
  • 사실 실행 시간 자체 보다도 큐에 머무는 시간 때문에 variability가 생긴다
  • 그래서 여러 머신의 큐에 넣어놓은 다음에 한 쪽에서 실행이 되면 나머지꺼에서 캔슬하는 방법이 있다
  • 두 작업이 동시에 실행될 수가 있으니 첫번재 작업을 넣고 딜레이를 좀 준 다음에 다음 작업을 넣으면 피할 수 있다

피할 수 없다면 공생해야 한다 - 오래 걸리는 요청의 경우

• imbalance 때문에 variability가 생기니까 파티션을 작게 만들어야 한다
• 레플리케이션을 똑똑하게
  • 처리하기 비싼 파티션, 아니면 자주 불리는 파티션은 레플리키이션을 늘리면 좋다
• 느린 머신을 잠깐 빼버린다
• IR 시스템의 경우
  • 다 기다릴 필요가 없다 - 느린건 빼고 그냥 빨리 나머지 대부분의 결과를 내보내는게 더 품질이 좋은 것이다

근데 저거 다 읽기의 이야기 아님? 쓰기의 경우는?

• 일단 읽기에 비해 요청 횟수가 적다
• 쓰기는 천천히 진행되도 되는 경우가 많다
• 그리고 쓰기는 보통 여러 머신에 쓰기 때문에 tail latency 문제에서 자유로운 편이다
  • 5개 중 3개에서 쓰기 성공하면 성공이니 나머지 2개는 느려도 티가 안난다