블루-그린 배포

예전에는 새 버전을 내보내려면 서비스를 멈춰야 했습니다. 돌고 있는 서버에서 옛 코드를 걷어 내고 새 코드를 얹는 동안에는 사용자에게 보여 줄 화면이 없었기 때문입니다. 그래서 "새벽 2시부터 4시까지 점검합니다" 같은 공지가 붙었고, 팀은 그 시간에 맞춰 사무실에 남았습니다.

진짜 문제는 멈춘 두 시간이 아니라 그 뒤였습니다. 새 코드를 올리고 나서 결제가 안 된다는 것을 발견하면, 되돌리는 일이 또 한 번의 배포였습니다. 옛 코드를 다시 꺼내 올리고 서버를 다시 띄우는 동안 30분이 더 갔고, 그사이 사용자는 깨진 화면을 봤습니다. 되돌리는 비용이 비싸니 팀은 애매한 증상 앞에서 "조금 더 지켜보자" 를 골랐고, 그만큼 장애 시간이 길어졌습니다.

블루-그린 배포는 이 두 가지를 한꺼번에 뒤집으려고 나온 방법입니다. 새 코드를 돌고 있는 서버에 얹지 않고, 옆에 똑같이 생긴 빈 환경을 하나 더 만들어 거기에 올립니다. 사용자는 그동안 옛 환경을 그대로 쓰고 있으므로 멈추는 시간이 없습니다. 그리고 문제가 보이면 옛 환경이 아직 그대로 살아 있으니, 되돌리는 일이 배포가 아니라 통로를 원래대로 돌려놓는 한 번의 설정 변경이 됩니다.

지금 사용자를 받고 있는 쪽을 블루, 새 버전을 올릴 빈 쪽을 그린이라고 부르는 데서 이름이 왔습니다. 순서는 다섯 단계입니다.

1. 블루와 같은 규모의 환경을 한 벌 더 준비합니다. 환경은 개발·스테이징·운영처럼 목적이 다른 실행 공간을 말하는데, 여기서는 운영과 성능·설정이 똑같아야 합니다. 서버가 반만 있는 그린에서 확인한 결과는 진짜 트래픽을 감당한다는 증거가 되지 못합니다.
2. 그린에 새 버전을 올립니다. 이 순간 그린은 완성된 서비스지만 아무도 들어오지 않는 상태입니다. 올리는 데 한 시간이 걸려도 사용자 쪽에는 영향이 없으므로 서두를 이유가 없습니다.
3. 그린에만 스모크 테스트를 돌립니다. 핵심이 살아 있는지만 빠르게 보는 테스트라, 로그인·문서 열기·저장·결제처럼 끊기면 안 되는 흐름 대여섯 개를 몇 분 안에 확인합니다. 전체 기능을 다 보려 들면 전환이 늦어집니다.
4. 로드 밸런서가 가리키는 곳을 블루에서 그린으로 바꿉니다. 로드 밸런서는 들어온 요청을 어느 서버로 보낼지 정하는 장치이고, 이 설정 한 줄을 고치는 순간부터 새로 들어오는 요청은 전부 그린으로 갑니다. 전환 자체는 몇 초입니다.
5. 블루를 바로 지우지 않고 한동안 켜 둡니다. 보통 다음 배포 전까지, 짧게 잡아도 몇 시간입니다. 이 시간 동안 블루는 롤백을 위한 보험입니다. 이상이 보이면 로드 밸런서를 블루로 되돌리는 것으로 끝나므로, 되돌리는 데 걸리는 시간이 30분에서 몇 초로 줄어듭니다.

한 가지 함정이 있습니다. 서버는 두 벌이지만 데이터베이스는 대개 한 벌을 같이 씁니다. 그린에서 만든 데이터를 블루로 돌아간 뒤에도 읽어야 하기 때문입니다. 그래서 표의 구조를 바꾸는 변경은 새 코드와 옛 코드 양쪽에서 모두 동작해야 합니다. 열 이름을 바꾸고 싶다면 새 열을 먼저 더해 두 열을 함께 채우는 배포를 한 번 하고, 옛 열을 지우는 일은 다음 배포로 미룹니다. 이 순서를 지키지 않으면 통로만 되돌아가고 데이터는 되돌아오지 않습니다.

멈추는 시간이 그대로 손실로 이어지는 서비스에 맞습니다. 결제나 예약처럼 2분만 끊겨도 돈과 문의가 쌓이는 쪽, 또는 사용자가 여러 나라에 흩어져 있어 모두가 자는 시간대가 없는 쪽입니다. 서버를 명령 한 줄로 늘렸다 줄였다 할 수 있는 클라우드 환경이면 준비 비용도 낮습니다.

되돌릴 일이 잦은 시기에도 값을 합니다. 되돌리는 비용이 싸다는 사실 자체가 판단을 빠르게 만들어, 애매한 오류 보고에 "일단 되돌리고 보자" 를 고를 수 있습니다.

한계는 셋입니다. 첫째는 비용입니다. 같은 규모의 환경을 두 벌 굴리므로 서버 비용이 두 배가 됩니다. 월 300만 원 쓰던 팀은 600만 원을 씁니다. 그린을 배포 직전에만 띄웠다가 전환 뒤 블루를 내리는 식으로 줄일 수 있지만, 그러면 롤백용 보험도 같이 사라집니다.

둘째는 데이터베이스입니다. 통로는 몇 초 만에 되돌아가지만 그사이 쌓인 데이터는 되돌아가지 않습니다. 셋째는 오래 걸리는 작업입니다. 전환 순간에 블루에서 파일을 올리고 있던 사용자는 그 작업이 끊깁니다. 새 요청만 그린으로 보내고 진행 중이던 요청은 블루에서 끝내도록 시간을 주는 설정이 따로 필요합니다.

"이번 건은 블루-그린으로 갑시다. 문제 생기면 바로 되돌릴 수 있어야 해요."

위험이 큰 변경이니 되돌리는 시간이 짧은 방식을 쓰자는 말입니다.

"그린 올려 뒀습니다. 스모크 확인되면 전환할게요."

새 환경 준비는 끝났고 핵심 흐름만 확인한 뒤 통로를 돌리겠다는 뜻입니다.

"블루 아직 안 내렸죠? 결제 쪽 문의가 들어와서요."

되돌릴 수 있는 상태가 아직 유지되고 있는지를 먼저 확인하는 말입니다.

페이지덱에서 결제 모듈을 갈아 끼우던 날의 모습이 전형적입니다. 태오가 오후 3시에 그린 환경을 띄워 새 버전을 올리고, 두 흐름을 확인한 뒤 3시 12분에 로드 밸런서를 돌립니다.

3시 40분에 수아가 고객사에서 카드 등록이 안 된다는 연락을 받습니다. 원인을 알아내는 데는 시간이 걸리지만 되돌리는 데는 걸리지 않으므로, 태오가 먼저 통로를 블루로 돌려놓고 그다음에 원인을 찾습니다. 사용자가 깨진 화면을 본 시간은 28분에서 멈추고, 원인을 찾는 동안에도 서비스는 정상입니다.

블루-그린으로 배포하면 무엇이든 되돌릴 수 있다고 여기는 오해가 가장 많습니다. 통로를 돌리는 데 몇 초밖에 안 걸리는 것을 보면 그렇게 느끼기 쉽습니다. 하지만 되돌아가는 것은 코드뿐입니다. 그린에서 돌던 30분 동안 새 형식으로 저장된 주문 기록은 블루의 옛 코드가 읽지 못하고, 그사이 고객에게 나간 메일은 취소되지 않습니다. 이 사실을 모른 채 안심하고 있으면 되돌린 뒤에 더 이상한 상태를 만납니다.

무중단이라는 말을 화면이 한 번도 안 깜빡인다는 뜻으로 읽는 것도 흔합니다. 실제로는 전환 순간에 블루에 붙어 있던 요청이 정리될 시간이 필요해서, 그 처리를 설계해 두지 않으면 몇몇 사용자는 한 번 실패를 겪습니다. 무중단은 진행 중인 요청을 어떻게 넘길지 정해 두었을 때 생기는 결과입니다.