롤링 배포

배포가 곧 점검 공지였던 시절이 있었습니다. 새벽 2시에 서버를 내리고 새 파일을 올리고 다시 띄우는 동안 서비스가 30분 멈추고, 사용자에게는 그 시간에 쓸 수 없다는 안내가 미리 나갔습니다.

이 방식은 여러 가지를 막았습니다. 사람이 새벽에 남아야 하니 배포는 한 주에 한 번이 되고, 한 번에 올라가는 변경이 쌓입니다. 변경이 많으니 문제가 생겼을 때 어느 줄이 원인인지 찾기 어렵고, 되돌리는 동안 중단이 30분에서 한 시간으로 늘어납니다. 그래서 다음 배포는 더 조심스러워지고 주기는 더 길어졌습니다. 회의에서는 이번 주에 못 올린 것을 다음 점검 창구까지 기다리자는 말이 반복됐습니다.

롤링 배포는 서버가 여러 대라는 사실을 이용해 이 문제를 풉니다. 열 대를 한꺼번에 내리지 않고 두 대씩 다섯 번에 걸쳐 바꿉니다. 두 대가 교체되는 동안 남은 여덟 대가 요청을 받고 있으니 사용자 쪽에서는 멈춘 순간이 없습니다. 점검 공지가 필요 없어지면 배포를 낮에 할 수 있고, 낮에 할 수 있으면 하루에 여러 번 할 수 있습니다.

교체할 서버를 몇 대씩 묶을지 정하는 것에서 시작합니다. 한 번에 한 대면 가장 안전하고 가장 오래 걸리며, 절반씩이면 빠르지만 문제가 절반에 퍼집니다. 열 대에 두 대씩이 흔한 선택입니다.

1. 첫 묶음을 요청에서 떼어 냅니다. 앞단이 그 두 대로 새 요청을 보내지 않게 하고, 이미 처리 중인 요청은 끝날 때까지 기다립니다. 이 대기를 건너뛰면 그 순간 열려 있던 연결이 끊깁니다.
2. 새 판으로 바꿉니다. 실행에 필요한 것을 묶어 어디서나 같게 돌게 만든 단위인 컨테이너를 쓰면 이 단계가 이미지를 갈아 끼우는 일로 줄어듭니다.
3. 살아 있는지 확인합니다. 서버가 응답을 돌려주는지 보는 상태 점검을 먼저 하고, 핵심이 살아 있는지만 빠르게 보는 스모크 테스트를 붙여 로그인과 문서 열기 같은 몇 가지를 실제로 해 봅니다.
4. 요청을 다시 보내고 몇 분 지켜봅니다. 오류율과 응답 시간을 이전 묶음과 견줍니다. 오류율이 0.2퍼센트에서 3퍼센트로 뛰었으면 여기서 멈춥니다.
5. 다음 묶음으로 넘어가 1번부터 반복합니다. 열 대면 다섯 번을 돌고, 묶음마다 관찰 시간을 2분씩 두면 전체가 20분쯤 걸립니다.
6. 중간에 이상이 보이면 진행을 멈추고 롤백합니다. 이미 바꾼 묶음을 예전 판으로 되돌리는 일이라, 바꾼 묶음이 많을수록 되돌리는 시간도 길어집니다.

자동 도구가 1번부터 5번까지를 맡고, 사람은 멈출 조건만 미리 적어 둡니다. 오류율 1퍼센트를 넘기면 중단한다는 식으로 숫자를 정해 두지 않으면 도구는 이상을 보고도 끝까지 갑니다.

서버가 여러 대이고 어느 서버가 받아도 결과가 같은 구조에서 잘 맞습니다. 한 사용자의 요청이 특정 서버에만 저장된 정보에 묶여 있으면 그 서버를 내리는 순간 그 사용자만 오류를 봅니다. 하루에 여러 번 배포하려는 팀에는 사실상 기본값입니다.

한계는 두 판이 동시에 도는 구간에서 옵니다. 절차 중간에는 새 판 네 대와 예전 판 여섯 대가 같이 요청을 받고 있어서, 두 판이 서로 다른 규격을 기대하면 그 사이에 오류가 납니다. 데이터베이스에 열을 추가하는 변경이 대표적입니다. 새 판만 아는 열을 예전 판이 읽으면 깨지니, 열을 먼저 추가해 두 판이 모두 견디게 만든 뒤 판을 올리고 그다음에 예전 열을 지우는 순서로 나눕니다. 이 순서를 지키지 않으면 무중단 배포를 하다가 중단을 만듭니다.

시간도 한계입니다. 열 대를 두 대씩 바꾸면 20분이 걸리고, 되돌릴 때도 비슷한 시간이 듭니다. 지금 당장 멈춰야 하는 장애 상황에서는 이 20분이 길게 느껴집니다. 용량도 봐야 합니다. 두 대를 뺀 동안 남은 여덟 대가 열 대 몫의 요청을 받아야 하니, 평소 부하가 80퍼센트를 넘는 상태라면 오토스케일링으로 배포 중에만 대수를 늘려 두거나 여유를 미리 잡아 둡니다.

"롤링으로 두 대씩 나가고 있고 지금 여섯 대까지 새 판입니다."

배포가 진행 중이며 어디까지 바뀌었는지를 알리는 보고입니다.

"이 변경은 열을 지우는 거라 롤링으로 못 나갑니다. 두 단계로 나눠야 합니다."

두 판이 함께 도는 구간을 견디지 못하는 변경이라는 지적입니다.

"오류율이 튀어서 세 번째 묶음에서 멈추고 되돌렸습니다."

미리 정한 중단 조건에 걸려 진행을 멈췄다는 말입니다.

페이지덱에서는 태오가 주 1회 새벽 점검을 없애면서 이 방식으로 옮겼습니다. 서버 열두 대를 세 대씩 네 묶음으로 나누고 묶음마다 3분을 관찰하도록 맞춰, 배포 하나가 15분쯤 걸리게 됐습니다. 배포 횟수는 한 주 1회에서 하루 2회로 늘었고, 한 번에 올라가는 변경이 줄어 원인을 찾는 시간이 짧아졌습니다.

옮긴 첫 달에 사고가 한 번 있었습니다. 알림 기능이 쓰는 열 이름을 바꾸는 변경을 한 번에 올렸는데, 예전 판 서버가 없는 이름을 찾으면서 8분 동안 알림이 나가지 않았습니다. 그 뒤로 데이터 구조를 바꾸는 변경은 열을 더하는 배포와 예전 열을 지우는 배포로 나눠 두 번에 걸쳐 올립니다.

무중단이라는 말을 사용자가 아무것도 느끼지 못한다는 뜻으로 읽는 경우가 많습니다. 서비스가 멈추지 않는다는 점은 맞습니다. 그런데 교체되는 서버에 붙어 있던 연결은 정리되고, 진행 중에는 두 판이 함께 돌아서 새로고침을 할 때마다 다른 화면을 보게 될 수 있습니다. 화면 구조가 바뀐 배포에서 사용자가 이전 화면과 새 화면을 번갈아 보는 일이 그래서 생깁니다. 무중단은 멈추지 않는다는 뜻이고, 똑같이 보인다는 뜻이 아닙니다.

문제가 생기면 빨리 되돌릴 수 있다고 보는 것도 흔합니다. 조금씩 바꾸니 조금씩 되돌릴 수 있을 것처럼 느껴집니다. 하지만 되돌리는 일도 같은 절차를 거꾸로 밟는 것이라 바꾼 만큼 시간이 듭니다. 여덟 대까지 바꾼 상태에서 되돌리려면 다시 네 묶음을 돌려야 합니다. 몇 초 안에 전체를 예전 상태로 돌려야 하는 서비스라면 새 환경을 따로 띄워 두고 한 번에 전환하는 쪽이 맞습니다.