배포 전략, 한 번에 전부 바꾸지 않기

한 번에 바꾸는 범위가 실패 범위입니다

배포 방식의 차이는 결국 '한 번에 몇 대를 바꾸는가'입니다. 전체를 동시에 바꾸면 배포는 빠르지만 문제가 생길 때 모든 사용자가 영향을 받습니다. 몇 대씩 나눠 바꾸면 배포는 느리지만 문제가 일부 사용자에게만 보이고, 다음 묶음을 멈추면 확산이 끝납니다. 그래서 선택 기준은 속도가 아니라 '실패를 몇 퍼센트의 사용자에게 보여도 되는가'입니다. 이 질문에 답하면 묶음 크기가 정해집니다. 또 묶음 사이에 관찰 시간을 둬야 효과가 있습니다. 관찰 없이 연속으로 넘기면 나눈 의미가 사라지고 전체 교체와 같아집니다.

새 환경을 따로 띄우는 방식도 있습니다

세 번째 방식은 새 버전을 별도 묶음으로 전부 띄운 뒤 트래픽을 한 번에 넘기는 것입니다. 되돌림이 가장 빠릅니다. 트래픽을 예전 묶음으로 돌리면 끝이기 때문입니다. 대가는 배포 중 두 배의 자원이 필요하다는 점입니다. 그래서 자원 여유와 되돌림 속도를 교환하는 선택입니다. 이 방식에서 주의할 점은 데이터 계층입니다. 두 묶음이 같은 데이터베이스를 쓰면 데이터 구조는 양쪽 코드가 모두 동작하도록 만들어야 합니다. 그렇지 않으면 트래픽을 넘긴 뒤 되돌릴 때 데이터가 맞지 않아 되돌림이 불가능해집니다.

영향 범위와 되돌림 시간을 비교합니다

학습용 가정으로 계산합니다. 가정값은 서버 10대이고 순차 방식에서 2대씩 바꾼다고 두겠습니다. 묶음 수는 5개이고 한 묶음의 영향 범위는 전체의 20퍼센트입니다. 전체 교체 방식은 영향 범위가 100퍼센트입니다. 되돌림 시간은 전체 교체가 12분, 순차 방식이 첫 묶음에서 멈출 경우 3분이라고 가정하면 차이는 9분입니다. 이것이 중간 계산값입니다. 최종 판단은 중단 손실로 합니다. 영향 범위와 시간을 곱하면 손실 규모가 나오고, 순차 방식은 두 값이 모두 작으므로 손실이 크게 줄어듭니다.

묶음을 나눌 수 없는 변경이 있습니다

결론을 뒤집는 조건은 버전 호환성입니다. 새 버전과 예전 버전이 동시에 돌 수 없는 변경이라면 순차 방식을 쓸 수 없습니다. 예를 들어 서로 주고받는 메시지 형식을 바꾸면 두 버전이 섞여 있는 동안 오류가 납니다. 그래서 이런 변경은 두 단계로 나눕니다. 먼저 양쪽 형식을 모두 이해하는 버전을 배포하고, 다음 배포에서 예전 형식을 제거합니다. 두 번째 조건은 사용자 세션입니다. 서버에 세션을 들고 있으면 묶음을 교체할 때 그 사용자들이 로그아웃되므로, 세션을 공유 저장소로 옮기는 작업이 선행 조건이 되고, 그 작업이 끝나기 전에는 묶음 교체 방식을 쓰지 않습니다.

서버 운영 실행 전 점검표

• 실패를 보여도 되는 사용자 비율로 묶음 크기를 정했다
• 묶음 사이에 관찰 시간을 두었다
• 두 버전이 동시에 동작할 수 있는지 확인했다
• 세션을 공유 저장소로 옮겼다