Zero Downtime Release
Zero Downtime Release: Disruption-free Load Balancing of a Multi-Billion User Website
페이스북의 다운타임 없는 릴리즈 방법에 대한 논문.
요약 설명
- 서버는 종종 재시작 됨 : 업그레이드, 버그픽스, 보안패치
- Continuous Release 의 도입으로
- 페이스북의 경우 2007년에 일주일에 1번이던게, 일주일에 100번 이상 배포 진행
- 수백만대의 서버가 매일 재시작
- AWS,아틀라시안,옐프,Ebay,우버 모두 마찬가지
- 헬스체크가 간헐적으로 실패하게 됨
- 전통적인 배포 방법
- Blue/Green 배포 (AWS CodeDeploy, Kubernetes) : 두개의 머신군으로 나누고 로드밸런서가 업데이트 먼저 한쪽으로 트래픽을 이관
- 비용이 많이 듬. 수많은 머신들이 있는 Edge에는 부적합
- Blue/Green 배포 (AWS CodeDeploy, Kubernetes) : 두개의 머신군으로 나누고 로드밸런서가 업데이트 먼저 한쪽으로 트래픽을 이관
- 업데이트 기간동안 CPU사용량이 적어지고, 느린 이터레이션.
- TCP에만 가능하고 UDP는 잘못된 라우팅 발생 가능
"어떻게 하면 릴리즈 업데이트를 다운타임 없이, 빠른 이터레이션으로, 중단없이 진행할수 있을까?"
페이스북의 Traffic Infrastructure
Edge PoP (L7 LB, ProxyGen) - Data Center(L7 LB, ProxyGen) - App. Server(HHVM,MQTT)
- 티어별로 리스타트해서 중단을 방지
- Edge 와 Data Center 의 머신은 각각 새 ProxyGen을 띄워서 "Socket TakeOver"
- Edge 와 Data Center 간의 "Downstream Connection Reuse"
- Data Center 와 App Server 강의 연결은 "Partial Post Replay"
Socket Takeover
새로운 프로세스를 띄워서 SCM_RIGHTS 와 CMSG로 TCP Listening , UDP VIP 소켓을 넘겨 받음
- SCM_RIGHTS : 다른 프로세스의 File Descriptor 를 넘겨 받게 해주는 소켓 타입
- CMSG : sendmsg() 기능으로 로컬프로세스 간에 제어 메시지를 전송할수 있게 해줌
- UDP 기반 커넥션인 QUIC을 위해서 기존 커넥션의 경우는 새 프로세스가 기존 프로세스에게 QUIC ConnectionID를 물어서 해당 패킷을 기존 프로세스로 포워딩
Partial Post Replay ( App 서버 재시작 )
- App 서버는 두가지의 워크로드가 존재 : 짧은 API 호출, 긴 HTTP POST 호출 (Upload)
- 이 앱서버는 가용 자원이 없기 때문에 Socket Takeover 가 하는듯이 새로운 인스턴스를 띄워서 소켓 넘기는게 불가능하고, 긴 업로드 시간도 문제
- 긴 업로드 중간에 앱서버가 업데이트 되면 프록시가 그 내용을 다 가지고 있지 않기 때문에, 해당 POST를 중단하면서 379코드와 함께 지금까지 받은 데이터를 다시 프록시로 리턴
- 프록시는 기존 앱서버로 부터 받은 데이터와 남은 데이터를 합쳐서 다시 새 머신으로 재 전송 시도
Zero Downtime Release의 장점
- Rolling Update 대비 20% 정도 높은 CPU 사용량
- Hot Restart 가 QUIC 패킷을 20K까지 미스라우팅 했던 거에 비해 거의 미스라우팅이 없음
- 페이스북 내에서 Socket TakeOver는 2013년부터, 나머지는 2015년 부터 사용 중