오늘도 제목 어그로로 시작하는 데브옵스 시리즈

이번 글은 싱글 파드/서비스 환경에서 무중단 업데이트를 구현하기 위해 x꼬 쇼를 했던 저의 경험담입니다

글을 쓰게 된 동기

제 다른 글들을 읽으신 분들은 대충 눈치를 채셨겠지만 저는 인프라, 데브옵스, 등등 에 관심이 많습니다.

프로젝트를 하다보면 어쩔수없이 백엔드나 프런트를 하고싶은 분들이 많고 인프라나 데브옵스를 좋아하시는분들 많지 않습니다. 일단 뎁옵스 신입시장이 너무 안좋습니다

누군가는 해야지. 그래 내 팔 길다

그래서 보통 프로젝트를 하게 되면 제가 많이 하는 편인데...
이번 프로젝트는 실서비스를 목표로 하고 있기에 무중단 배포를 구현 하는게 필요해졌습니다.

무중단 배포를 안하면 아무리 빨리 배포를 자동으로 해도 다운타임이 생길수 밖에 없습니다. 그리고 그 사이에 서비스를 사용하고 있던 사람들은....

뭐긴 뭐야. 온라인 게임 4대 명검 소환이지 ㅋㅋㅋ

그리고 만약에 배포를 하는데 새로운 버젼에서 예상하지 못한 버그가 발견되거나 배포 과정에서 오류가 떠 늦어지면?

추가점검

이렇듯이 사용자들 입장에서는 편할수가 없고 짜증만 유발하는 상황이 생깁니다.

그래서 이런일이 일어나지 않게 무중단 배포 를 구현합니다.

무중단 배포가 뭔데요

말 그대로 중단 없이 배포를 하는겁니다.
사실... 그게 끝입니다. 꺄르륵

물론 더 자세히 얘기를 하자면 무중단 배포에서 오는 이점이 있습니다.

1. 다운타임 제로. 서비스가 내려가는 일이 없습니다
2. 롤백 가능
3. 지속적인 업데이트가 쉬움

서비스가 내려가는일이 없으면 점검이라는게 거의 존재 하지 않기에 사용자가 불편함 없이 사용할수 있습니다.

롤백이 가능하면 새로 올린 버젼의 문제가 생겨도 바로 그 전 버젼으로 바꿀수 있습니다.

지속적인 업데이트가 쉬우면 자잘한 수정과 패치를 자주 올리며 더 안정적으로 서비스를 운영할수있습니다.

명검 소환을 안해도 됩니다

무중단 배포 종류

무중단 배포를 구현하는 방법은 크게 3가지가 있습니다.

1. 블루 그린
2. 롤링
3. 카나리

블루 그린

블루 그린 방식은 기존 파드/서비스/컨테이너 (그냥 파드로 통일 하겠습니다) 는 놔두고 새로운 버젼의 파드를 올린뒤 네트워크 트래픽을 그 새로운 파드로 연결해주는 방식입니다.

보통 로드 밸런서 (리버스 프록시)가 트래픽을 예전 버젼에서 새로운 버젼으로 연결 해줍니다.

장점은 기존의 올라와 있는 서비스를 건드는게 아니라 새롭게 더 만드는거기 때문에 서비스의 영향이 거의 없습니다.

단점으로는 그만큼 서비스를 더 띄워서 테스트를 하니 돈이 많이 듭니다.

제 프로젝트는 그게 좀 곤란합니다

롤링

이 롤링 아닙니다

저희가 보통 쿠버네티스나 도커 스웜을 사용하면 이 방법으로 자동으로 됩니다.

서비스가 3개가 있다는 가정하에 롤링 업데이트는 그중 2개로 트레픽을 몰아놓고 다른 한개를 새 버젼으로 올립니다.

그 후 다시 트래픽을 벨런싱 해줍니다.

이 과정에서 문제가 없으면 나머지 2개에도 똑같이 해줍니다.

장점은 인스턴스를 새로 늘리지 않아도 된다는 점입니다. 오오오 그리고 점진적으로 바꾸기 때문에 문제를 금방 찾고 롤백이 더욱 쉽습니다.

단점으로는 결국 다른 버젼들이 함께 공존을 하는 순간이 존재하고 특정 파드로 트래픽이 몰리는 경우도 존재를 해서 서비스가 느려지거나 장애가 생길수 있는 리스크를 가지고 있습니다.

카나리

카나리 (canary)는 사실 저희가 카나리아 라고 부르는 새 이름에서 유래된 방식입니다.

예전에 광부들이 광산에 들어갈때 일산화탄소가 존재하는지 확인하기 위해 카나리아를 새장에 넣어서 대리고 들어가던 행위 때문에 생긴 이름입니다.

광부들은 카나리아한테 노래를 시키거나 해서 안전한지 확인을 하고 만약에 카나리아가 조용해지면 위험하다고 판단하고 나갔었죠. (카나리아는 사람보다 일산화탄소를 더 빨리 느낀다고 합니다)

이 방법과 비슷하게 실사용자들 중 특정 몇 퍼센트의 사용자들을 새로운 버젼으로 라우팅 해주고 반응을 보는겁니다. 이정도면 카나리아가 아니라 모르모트 아닌가

장점은 새로운 버젼으로 바꾸기 전에 실사용자들이 어떻게 반응하는지 볼수있다는 점과 문제가 터져도 사용자가 누군지 쉽게 알아서 대처가 가능하다는점입니다.

단점으로는 네트워크 설정을 통해 특정 사용자한테 새로운 버젼을 보여줘야되는 점 때문에 설정이 복잡해질수 있습니다.

제가 선택한 방식

저는 위 방식들을 조금 짬뽕해서 씁니다.

돈이 없어서 그렇습니다

사실 짬뽕이라고 하기에는 뭐하고 위 방식들의 문제점이 있어서 그렇습니다.

네 바로 그 점은... 무조건 최소 2개의 단독적인 컨테이너든 파드든 서비스든 인스턴스든이 필요합니다... 즉 하나로는 못합니다.

하지만 저희는 아직 실사용자가 2개를 띄울 만큼 트래픽이 들어오지 않기 때문에 하나면 됩니다. 하나 더 만들면 그거 다 돈 입니다

전생에 집게사장

그래서 제가 사용한 방식은 롤링+블루그린을 합친 방식입니다.

일단 저는 Jenkins를 사용해 아래 플로우가 자동화 했습니다.

대략적인 플로우 입니다:

1. 백엔드 서버가 1개 존재한다 (v1.0.0 x 1)
2. 업데이트가 트리거 되면 잠시 두개로 replica를 만든다 (v1.0.0 x2)
3. 새로 만들어진 서버는 버젼을 올린다 (v1.0.0 x 1, v1.0.1 x 1)
4. 새로운 버젼이 제대로 돌아가는지 확인 한다
5. 둘이 잠시동안 공존을 하며 예전 버젼으로 들어오는 새로운 트래픽들은 다 새로운 버젼으로 옮긴다. 기존에 처리하던 요청들은 예전서버가 하도록 놔둔다. (로드 밸런서)
6. 예전 서버에서 해결하고 있는 요청들이 더이상 없으면 그 서버도 새로운거로 올린다 (v1.0.1 x 2)
7. 둘이 문제가 없는지 마지막으로 확인을 더 한다. (메트릭, 로그 확인)
8. 다시 한개로 줄인다 (v1.0.1 x 1)

롤링 업데이트 방식으로 업데이트를 진행하지만 새로운 파드를 생성하는 부분은 블루 그린 방식인 아주 희한한 방식으로 개조를 했습니다.

사실 이 방식은 서버를 1개만 유지하려고 하는 제 고집 짠돌이 때문에 생긴 일입니다.

물주를 찾는게 더 빠를수도 있습니다

결론

무중단 배포는 프로젝트 정도나 실서비스가 별로 없는 서비스에서는 필요가 없습니다. 사실 머리만 더 아파지고 장점은 비교적으로 적거든요.

하지만 실서비스를 생각하시고 계신분들은 무중단 배포가 옵션이 아닌 필수가 될수도 있습니다. 그래야지 사용자들이 안떠나겠죠? 회사가 하라면 해야됩니다

사실 서버를 1개 이상만 만들면 무중단 배포 구현은 쉽습니다. 하지만 대부분의 개발자들이 프로젝트를 만들때 서버를 1개 이상 만들어야되는 이유가 많아질까요..? 솔직히 서버리스로 구현해도 충분하지 않나

이상 무중단 배포 얘기였습니다. 읽어주셔서 감사합니다.