판교의 메타몽
무중단 배포, 그리고 L4와 L7의 로드 밸런서
순서
- 무중단 배포란?
- 무중단 배포 전략 3대장
- 블루 / 그린 배포 (Blue / Green Deployment)
- 롤링 배포 (Rolling Update Deployment)
- 카나리 배포 (Canary Deployment)
- Nginx가 만능일까?
- L4 스위치와 L7 스위치, 그리고 Nginx
0. 무중단 배포란?
서비스를 중단하지 않고 배포하는 것을 의미한다.
1월에 점검이 진행되고, 점검날에 1월동안 새로 개발한 코드들을 반영한다고 상상하자.
점검 이전에 실제 서비스에 돌아가던 프로젝트를 v1, 점검 이후 반영되는 신규 프로젝트를 v2라고 가정했을때,
v1이 돌아가던 서비스를 종료하고 v2를 배포 + 반영하기까지 서비스가 중단된 시간을 다운타임(downtime)이라고 한다.
(1) v1 서비스를 중단시켜야 v2를 실행할 수 있을까?
- 동일한 포트를 사용한다면 당연한 이야기
(2) 서버를 두 대로 늘린다면?
- 두 대로 늘려서 한 서버씩 배포를 진행하면 되지 않을까 생각할 수 있지만, 여기엔 2가지 문제점이 존재
- 사용자가 두 서버의 IP를 모두 알아야함
- 어떤 서버가 운영중인 IP인지 사용자는 모름
(3) 리버스 프록시와 로드 밸런싱
(2)번의 두 가지 이슈를 해결하기 위해서는 클라이언트와 서버 사이의 중계자 역할이 필요한데, 이를 리버스 프록시라고 함
프록시란?
- 대리자라는 뜻으로, 일반적인 프록시는 클라이언트가 누구인지 숨겨주는 역할. 즉, 서버에서는 클라이언트가 누구인지 식별할 수 없음
리버스 프록시란?
- 반대로 클라이언트에서 서버가 누군지 식별할 수 없음. 단지 서버를 대리하는 존재만을 알게됨. 다시 말해 서버가 누군지를 숨겨주는 역할.
- 로드 밸런싱(부하 분산)
- 하나의 서버에서 받아야 할 요청을 여러 서버로 분산하는 것을 로드 밸런싱이라고 함
- 이러한 리버스 프록시 역할과 로드 밸런싱을 함께 수행하는 역할로 대표적으로
Nginx가 있음
1. 무중단 배포 전략 3대장
가장 유명한 무중단 배포 전략을 말해보자면 크게 3가지 종류가 있다.
- 블루 / 그린 배포 (Blue / Green Deployment)
- 롤링 배포 (Rolling Update Deployment)
- 카나리 배포 (Canary Deployment)
💡 아래 이미지에서에서 블루는 구버전의 인스턴스, 그린은 신버전의 인스턴스를 뜻한다.
(1) 블루 / 그린 배포 (Blue / Green Deployment)
특징
- 운영중인 구버전과 동일하게 신버전의 인스턴스를 구성 한 다음, 로드밸런서를 통해 모든 트래픽을 한 번에 신버전 쪽으로 전환
장점
- 구버전의 인스턴스가 남아있어서 롤백에 용이
- 운영 환경에 영향을 주지 않고 새 버전 테스트 가능
단점
- 시스템 자원이 두 배로 필요
(2) 롤링 배포 (Rolling Update Deployment)
특징
- 사용 중인 인스턴스 내에서 새 버전을 점진적으로 교체
- 기존 서버가 3개라면, 먼저 1대의 서버에 버전 업그레이드 진행
- 버전 업데이트 완료 후, 해당 인스턴스로 라우팅
- 나머지 2대도 동일한 방법으로 진행
장점
- 인스턴스마다 차례로 배포를 진행하기때문에 상황에 따라 롤백에 용이
- 블루 / 그린과 다르게 인스턴스를 2배로 늘릴 필요는 없음
단점
- 새 버전을 배포할 때 사용중인 인스턴스에 트래픽이 몰릴 수 있음
- ex : 3개의 서버 중 1대의 서버에 신규 버전 반영 후 배포 진행시, 나머지 2개의 서버에 트래픽이 몰리게 됨
- 배포가 진행될때 구 버전과 신 버전이 공존하기에 호환성 문제가 발생할 수 있음
- ex : 개의 서버 중 1대의 서버에만 신규 버전 배포가 완료됐을 경우, 해당 서버의 유저와 나머지 2대의 서버의 유저들은 균일한 서비스를 받지 못함
(3) 카나리 배포 (Canary Deployment)
옛날에 광부들이 광산을 조사할 때, 유독 가스에 민감한 카나리아 조류를 이용해 가스 누츨에 노출되는 상황을 피했던 상황에서 유래된 배포 방식이다.
특징
- 신 버전을 선배포 후, 소수의 유저들에게만 공개하여 문제가 없는것을 확인한 다 점진적으로 많은 유저들에게 배포하는 방식
- 블루 그린 배포 방식과 유사한, 트래픽을 한 번에 바꾸는 것이 아닌 단계적 전환을 진행하기 때문에 잠재적 위험을 최소화하고 상황에 따라 트래픽 양을 조절하며 롤백에 용이
장점
- 문제 상황을 빠르게 감지
- A/B 테스트로 활용 가능
💡 A/B 테스트 : 대조군과 실험군을 나누어 특정 UI나 알고리즘의 효과를 비교하는 방법론
단점
- 네트워크 트래픽 제어 부담
- 다른 두 배포 방식보다 전체 릴리즈에 대한 준비 과정이 보다 오래 소요됨
2. Nginx가 만능일까?
트래픽이 많을 경우, Nginx만으로 충분하지 않을 수 있다. 결국은 모든 트래픽이 Nginx를 거치기 떄문이다.
따라서 이를 개선하고자 아래와 같이 3가지 방법을 고려할 수 있다.
- Nginx 스케일 업
- 스케일 업은 성능을 향상시킨다는 뜻으로, CPU나 메인 메모리가 더 좋은 인스턴스로 교체하는 방법이 그 예시
- 네트워크 장치로 로드 밸런싱
- Nginx와 같은 소프트웨어가 아닌 하드웨어적으로 로드밸런싱 진행
- DNS 리다이렉션
- 웹 브라우저아 url을 입력하면 DNS 서버로 url을 전송하여 url에 매칭되는 IP 주소를 찾게됨
- 해당 IP로 접속해야 할 서버가 어디인지 이 과정에서 알게되는데, 이때 알 수 있는건 하나의 도메인에 여러개 IP가 있다는 점
- 따라서 DNS에서 각 IP로 트래피을 분산시켜주면 됨
3. L4 스위치와 L7 스위치, 그리고 Nginx
L4 스위치와 L7 스위치, Nginx는 모두 비슷한 역할을 수행하지만 근본적으로 다르다.
L4
- OSI 7계층 중 4번째 레이어 (= Transport)에 해당
- TCP, UDP와 같은 프로토콜에 대한 책임이 있음
L7
- OSI 7계층 중 7번째 레이어 (= Application)에 해당
- HTTP, HTTPS와 같은 프로토콜에 대한 책임이 있음
Nginx
- OSI 7계층 중 4번째, 7번째 레이어 모두 위에서 동작 가능
- 때문에 UDP, TCP, HTTP, HTTPS와 같은 프로토콜에 책임이 있음
참고로 4계층은 1,2,3 계층을 모두 포함하며, 7계층은 모든 계층을 포함한다.
4번째 레이어(Transport)에서는 IP, Port와 같은 데이터는 포함되지만 URL같은 데이터는 확인이 불가능하다.
따라서 L4 스위치는 IP, Port를 기준으로 로드 밸런싱을 한다.
반면 7번째 레이어(Application)에서는 최상위 레이어이므로 모든 데이터를 볼 수 있다. 따라서 IP, Port, Http, Host 정보, URL등으로 로드 밸런싱이 가능하다.