[웹앱 실무 99] 배포 - 무중단 배포

서버 배포 개요 편에서 달리는 기차의 바퀴를 간다는 비유를 썼잖아요. 이번 편은 그 달리면서 갈아 끼우는 기술, 무중단 배포를 제대로 파고드는 자리예요. 서비스를 잠깐도 안 끊고 새 버전으로 넘어가는 방법들이죠. 저는 무중단 배포를 배우기 전엔 사람 없는 새벽에 몰래 배포하곤 했는데, 이 기술을 익히고 나서는 대낮에도 마음 편히 배포하게 됐어요. 사용자는 아무것도 못 느끼고, 저는 두렵지 않은, 그런 배포가 가능해진 거죠.

이번 편에서는 무중단 배포가 뭔지, 대표적인 세 가지 방식인 롤링, 블루그린, 카나리가 각각 어떻게 다른지, 데이터 모양이 바뀔 때는 어떻게 하는지, 그리고 무중단 배포에서 놓치기 쉬운 함정을 짚어 볼게요. 방식들 이름이 낯설지만, 원리는 다 상식적인 것이라 하나씩 풀면 어렵지 않아요.

무중단 배포가 대체 뭐예요?

무중단 배포는 서비스를 한순간도 끊지 않고 새 버전으로 넘어가는 걸 말해요. 순진하게 옛 서버를 끄고 새 서버를 켜면, 그 사이에 서비스가 뚝 끊기잖아요. 무중단 배포는 이 끊김을 없애려고, 새 버전을 먼저 준비해 두고 준비가 다 된 걸 확인한 다음에야 조심스럽게 넘어가요. 사용자는 어느 순간 버전이 바뀌었는지도 모른 채 계속 서비스를 써요.

핵심 원리는 서버 배포 편에서 말한 그대로예요. 새 게 확실히 준비된 걸 확인하기 전엔 옛 걸 안 치운다는 거죠. 새 버전을 옆에 띄우고, 준비 검사를 통과한 걸 본 뒤에, 요청을 새 버전으로 돌리고 나서야 옛 버전을 내려요. 이 순서만 지키면 준비 안 된 서버로 사용자를 보내는 사고를 막을 수 있어요.

여기서 중요한 조연이 요청을 나눠 주는 장치예요. 사용자 요청이 여러 서버 중 어디로 갈지를 정해 주는 문지기인데, 이 문지기한테 이제 새 서버로 보내 하고 말하면 요청 흐름이 새 버전으로 넘어가요. 무중단 배포는 결국 이 문지기한테 언제 어떻게 흐름을 바꾸라고 지시하느냐의 기술이라고 봐도 돼요.

무중단 배포가 왜 중요하냐면, 그게 있어야 배포를 자주 할 수 있기 때문이에요. 배포할 때마다 서비스가 끊긴다면, 아무도 낮에 자주 배포하려 하지 않겠죠. 무중단이 되어야 언제든 부담 없이 배포하고, 그래야 첫 편에서 말한 작게 자주가 가능해져요. 저는 무중단 배포를 잦은 배포의 전제 조건이라고 여겨요.

다만 무중단 배포는 공짜가 아니에요. 새 버전이랑 옛 버전이 잠깐 같이 도는 구간이 생기고, 서버를 잠깐 더 띄워야 하니 자원도 더 들죠. 그래서 두 버전이 섞여도 탈이 없게 만들어야 하는데, 이 이야기는 뒤에서 자세히 다룰게요. 지금은 무중단이 끊김을 없애는 대신 약간의 복잡함을 받아들이는 맞바꿈이라는 걸 짚어 둬요.

롤링 방식은 어떻게 해요?

롤링은 여러 대의 서버를 하나씩 순서대로 새 버전으로 바꾸는 방식이에요. 서버가 다섯 대라면, 한 대를 요청에서 빼서 새 버전으로 갈고 정상인 걸 확인한 뒤 다시 넣고, 그다음 대로 넘어가는 거죠. 교체하는 동안에도 나머지 서버가 요청을 받으니 서비스가 안 끊겨요. 다섯 대를 다 갈고 나면 배포가 끝나죠.

롤링의 장점은 자원이 적게 든다는 거예요. 서버를 통째로 두 벌 띄울 필요 없이, 있던 서버를 하나씩 갈면 되니까요. 그래서 많은 곳에서 기본으로 쓰는 방식이에요. 컨테이너를 관리하는 도구들도 대개 이 롤링을 기본 동작으로 삼아, 우리는 새 버전을 지정하기만 하면 도구가 알아서 하나씩 갈아 줘요.

다만 롤링은 잠깐 두 버전이 같이 도는 구간이 길어요. 다섯 대를 하나씩 가는 동안, 어떤 사용자는 새 버전을 어떤 사용자는 옛 버전을 받거든요. 그래서 두 버전이 섞여도 괜찮게 만들어 둬야 해요. 특히 화면 쪽이랑 서버 쪽을 함께 바꿀 땐, 옛 화면이 새 서버한테 요청하거나 그 반대일 때도 안 깨지게 신경 써야 하죠.

롤링에서 문제가 생기면 되돌리기도 하나씩이라 조금 느려요. 이미 몇 대를 새 버전으로 갈았는데 문제를 발견하면, 그 대들을 다시 옛 버전으로 돌려야 하니까요. 그래서 저는 롤링을 쓸 때, 한 대를 갈고 나서 충분히 지켜본 뒤 다음으로 넘어가게 해요. 서두르면 다 갈아 놓고 문제를 뒤늦게 발견해 되돌릴 게 많아지거든요.

저는 롤링을 가장 무난한 기본기로 여겨요. 자원이 적게 들고 도구가 잘 받쳐 주니, 특별한 이유가 없으면 롤링으로 시작해요. 다만 두 버전 공존을 늘 염두에 두고, 문제를 빨리 알아채게 지켜보는 눈을 붙여 두죠. 무난한 만큼 방심하기 쉬운데, 방심하면 두 버전이 섞이는 구간에서 은근한 사고가 나거든요.

블루그린 방식은요?

블루그린은 똑같은 환경 두 벌을 두고 통째로 갈아타는 방식이에요. 지금 사용자를 받는 걸 파랑이라 하면, 새 버전을 초록이라는 별도 환경에 통째로 띄워 둬요. 초록이 완전히 준비된 걸 확인한 다음, 문지기한테 이제 초록으로 보내 하고 흐름을 한 번에 넘기는 거죠. 그러면 순식간에 모든 사용자가 새 버전을 받아요.

블루그린의 가장 큰 장점은 되돌리기가 순식간이라는 거예요. 초록으로 넘겼는데 문제가 생기면, 문지기한테 다시 파랑으로 하면 끝이거든요. 옛 환경인 파랑이 그대로 살아 있으니, 되돌리는 데 몇 초면 돼요. 저는 이 즉시 되돌리기 때문에 중요한 배포엔 블루그린을 즐겨 써요. 문제가 나도 바로 물러설 수 있다는 안심이 크거든요.

또 하나 좋은 점은 두 버전이 섞이는 구간이 거의 없다는 거예요. 흐름을 한 번에 넘기니, 롤링처럼 오래 공존하지 않죠. 그래서 두 버전 호환을 덜 걱정해도 돼요. 다만 넘기는 그 순간에 처리 중이던 요청은 챙겨야 하고, 데이터베이스처럼 두 환경이 공유하는 것은 여전히 조심해야 해요.

블루그린의 단점은 자원이 두 배로 든다는 거예요. 같은 환경을 두 벌 띄워야 하니까요. 배포하는 잠깐만 두 벌이고 평소엔 한 벌이라 해도, 그 잠깐을 위해 넉넉한 여유가 필요하죠. 그래서 저는 자원이 빠듯한 작은 서비스보단, 안정이 중요하고 여유가 있는 서비스에 블루그린을 써요.

저는 블루그린을 비싸지만 든든한 방식이라고 불러요. 자원을 더 쓰는 대신 즉시 되돌리기랑 깔끔한 전환을 얻으니까요. 되돌리기가 몇 초 만에 된다는 건, 사고가 나도 피해를 최소로 줄일 수 있다는 뜻이라 값어치가 커요. 롤백 편에서 다룰 빠른 되돌리기의 가장 확실한 형태가 바로 이 블루그린이에요.

카나리 방식은요?

카나리는 새 버전을 일부 사용자한테만 먼저 흘려보는 방식이에요. 이름은 옛날 광부들이 위험을 먼저 알려 주는 새를 데리고 들어가던 데서 왔어요. 새 버전을 처음엔 사용자의 아주 일부한테만 주고, 괜찮으면 조금씩 비율을 넓혀 가는 거죠. 문제가 있어도 일부만 겪으니 피해가 작아요.

카나리의 장점은 실제 사용자로 미리 검증한다는 거예요. 아무리 검증 환경에서 확인해도 진짜 사용자, 진짜 트래픽에서만 드러나는 문제가 있거든요. 카나리는 그걸 작은 범위에서 먼저 만나게 해 줘요. 처음 5퍼센트한테 주고 오류가 안 늘면 20퍼센트로, 그다음 50퍼센트로 넓히며 단계마다 지켜보는 거죠.

이 방식은 지켜보는 눈이 특히 중요해요. 일부한테 준 새 버전에서 오류가 늘거나 느려지는지를 잘 봐야, 넓힐지 물러설지 판단하거든요. 그래서 카나리는 탄탄한 관측이 받쳐 줘야 제값을 해요. 지켜보는 장치 없이 비율만 늘리면, 문제를 넓어진 뒤에야 알게 돼 카나리의 의미가 사라져요.

카나리에서 문제가 감지되면 비율을 0으로 되돌리면 돼요. 새 버전한테 가던 흐름을 끊고 다시 옛 버전으로 몰면, 새 버전을 겪던 일부 사용자도 안전해지죠. 넓히기 전에 잡았으니 피해가 최소예요. 저는 이 넓히기 전에 잡는다는 점이 카나리의 진짜 힘이라고 봐요. 문제를 크게 터지기 전에 작게 만나는 거니까요.

카나리는 앞의 두 방식이랑 섞어 쓰기도 해요. 블루그린처럼 두 환경을 두되, 초록으로 한 번에 넘기는 대신 조금씩 흘리는 식이죠. 요즘 배포 도구들은 이 카나리를 자동으로 해 주기도 해요. 비율을 단계적으로 올리다 오류가 늘면 스스로 멈추고 되돌리게 말이죠. 저는 중요한 서비스일수록 이런 자동 카나리가 참 든든하다고 느껴요.

데이터 모양이 바뀌면 어떻게 해요?

무중단 배포의 진짜 어려움은 데이터 모양이 바뀔 때 드러나요. 새 버전이 데이터베이스 모양을 바꿔야 하는데, 잠깐은 옛 버전이랑 새 버전이 같이 도니까요. 새 모양으로 확 바꿔 버리면, 아직 도는 옛 버전이 새 모양을 못 알아봐 깨져요. 그래서 데이터 변경은 한 번에 하면 안 되고 단계를 나눠 해야 해요.

정석은 더하는 것부터, 지우는 건 나중에예요. 예를 들어 어떤 칸의 이름을 바꿔야 한다면, 먼저 새 칸을 더하기만 하고 옛 칸은 그대로 둬요. 이 단계에선 옛 버전도 새 버전도 각자 아는 칸을 쓰니 둘 다 멀쩡하죠. 새 버전이 다 배포되고 옛 버전이 완전히 사라진 다음에야, 아무도 안 쓰는 옛 칸을 지워요.

이렇게 더하기, 옮기기, 지우기를 여러 번의 배포로 나누면, 각 단계에서 옛 버전이랑 새 버전이 둘 다 견뎌요. 저는 이걸 서로 견디게 만든 뒤에 옮긴다고 표현해요. 조급하게 한 배포에서 다 바꾸려 하면, 공존 구간에서 반드시 한쪽이 무너지거든요. 데이터 변경은 느긋하게 여러 걸음으로 가는 게 안전해요.

이 원칙은 되돌리기에도 중요해요. 데이터를 지우는 것부터 해 버리면, 옛 버전으로 되돌아가려 해도 옛 버전이 쓸 데이터가 이미 없어 못 돌아가거든요. 더하기만 한 단계에선 언제든 옛 버전으로 깔끔하게 돌아갈 수 있어요. 그래서 저는 되돌릴 수 있는 순서로 데이터를 바꿔요. 지우기는 정말 안 쓰는 게 확실할 때 마지막에만요.

데이터 변경은 무중단 배포에서 가장 신중해야 할 부분이에요. 코드는 되돌리면 그만이지만, 데이터는 한번 잘못 건드리면 되돌리기 어렵거든요. 저는 데이터 모양을 바꾸는 배포는 평소보다 몇 배 더 조심하고, 되돌릴 길을 확실히 확보한 뒤에만 진행해요. 이 신중함이 무중단 배포의 마지막 관문이에요.

무중단 배포에서 뭘 조심해요?

첫째는 처리 중이던 요청을 지키는 거예요. 옛 서버를 내릴 때 곧바로 죽이지 말고, 지금 처리 중인 건 끝까지 마치게 두고 새 요청만 안 받게 해야 해요. 이 우아한 종료가 없으면, 하필 그 순간 요청하던 사용자가 애먼 오류를 만나요. 저는 서버를 내리기 전에 진행 중인 일을 마칠 시간을 꼭 줘요.

둘째는 두 버전 공존을 늘 염두에 두는 거예요. 무중단 배포엔 어떤 방식이든 잠깐이라도 두 버전이 같이 도는 순간이 있어요. 그러니 새 버전을 짤 때 옛 버전이랑 섞여도 괜찮은지를 늘 생각해야 해요. 특히 화면이랑 서버를 함께 바꿀 땐, 어느 조합이든 안 깨지게 신경 써야 하죠.

셋째는 준비 검사를 제대로 두는 거예요. 무중단 배포는 새 게 준비됐다는 신호를 믿고 흐름을 넘기니, 그 신호가 진짜 준비를 반영해야 해요. 껍데기만 살아 있음을 답하는 검사를 믿고 넘기면, 준비 안 된 서버로 사용자를 몰아넣죠. 저는 준비 검사가 데이터베이스 연결까지 진짜 확인하는지 꼭 챙겨요.

넷째는 지켜보며 되돌릴 채비를 하는 거예요. 무중단으로 매끄럽게 넘어갔다고 끝이 아니라, 넘어간 직후 오류가 늘지 않는지를 지켜보고 이상하면 바로 되돌려야 해요. 특히 블루그린이나 카나리는 되돌리기가 빠르니, 망설이지 말고 되돌리는 게 좋아요. 이 되돌리기 이야기는 바로 다음 편에서 깊이 다룰게요.

정리하면, 무중단 배포는 새 걸 준비해 확인한 뒤 조심히 넘기는 원리 위에 롤링, 블루그린, 카나리 같은 방식이 있어요. 롤링은 무난하고, 블루그린은 되돌리기가 빠르고, 카나리는 일부한테 먼저 대 보죠. 데이터 모양은 더하고 나중에 지우는 순서로 나눠 바꾸고, 두 버전 공존을 늘 염두에 둬야 해요. 다음 편에서는 무슨 일이 생겼을 때 즉시 이전으로 돌아가는 롤백 전략을 이야기해 볼게요.