무중단 배포

무중단 배포란? 무중단 배포를 위한 환경 이해하기

무중단 배포란?

• 서비스를 중단하지 않고 배포 하는 것을 의미
  • 배포라는 말은 새로 개발된 코드를 패키징 하여 서버에서 새로운 버전의 애플리케이션을 실행하도록 하는 행위

애플리케이션의 중단

• v1 서비스가 실행 중일 때 v2 버전을 다운로드 받음
  • v1 서비스를 종료 시키는 시점부터 v2를 시작하기 전까지 서비스가 중단됨
  • 이렇게 서비스가 중단되는 시간을 다운타임(downtime)이라고 함

• v1 서비스를 꼭 중단시켜야 v2를 실행시킬 수 있는가?
  • 동일한 포트를 사용한다고 하면 당연한 이야기
  • 예를 들어 docker 컨테이너를 띄울 때 docker run -p 8080:8080 [이미지]를 입력한 경우, 8080 포트를 컨테이너가 사용 중이므로 다른 컨테이너를 8080 포트로 띄울 수는 없음

서버를 두 대로 늘리면?

• 한 서버에서만 배포를 진행하면 되지않을까? 라고 생각할 수 있지만 여기에는 두 가지 문제점 존재
  • 사용자가 두 서버의 IP를 모두 알아야 함
  • 어떤 서버가 운영중인 IP인지 알 수 없음

리버스 프록시와 로드 밸런싱

• 위 두 가지 문제를 해결하기 위해서는 클라이언트와 서버 사이에 중계해줄 누군가가 필요한데 이러한 누군가를 리버스 프록시라고 함

프록시란?

• 대리자라는 뜻을 가지는데, 일반적인 프록시는 클라이언트가 누군지를 숨겨주는 역할을 함
  • 즉 서버에선 클라이언트가 누구인지 식별할 수 없음

리버스 프록시란?

• 반대로 클라이언트에서 서버가 누구인지 식별할 수 없음
  • 단지 서버를 대리하는 존재만을 알게 되며 서버가 누군지를 숨겨주는 역할을 함

로드 밸런싱 (부하 분산)

• 위 그림처럼 된다면 트래픽도 분산할 수 있지 않을까?
  • 하나의 서버에서 받아야 할 요청을 여러 서버로 분산하면 되는데 이를 로드 밸런싱이라 함

• 이러한 리버스 프록시 역할과 로드 밸런싱을 수행할 수 있는 현 시점에서 가장 인기있는 웹서버가 Nginx

무중단 배포 방식

① 롤링 (Rolling)

• 일반적인 배포를 의미하며 단순하게 서버를 구성하여 배포하는 전략
  • 다시 말해 구 버전에서 신 버전으로 트래픽을 점진적으로 전환하는 배포
  • 관리가 편하지만 배포 중 한쪽 인스턴스의 수가 감소되므로 서버 처리 용량을 미리 고려해야 함

• 롤링 배포는 사용 중인 인스턴스 내에서 새 버전을 점진적으로 교체하는 것으로 무중단 배포의 가장 기본적인 방식
  • 서비스 중인 인스턴스 하나를 로드 밸런서에서 라우팅하지 않도록 한 뒤, 새 버전을 적용하여 다시 라우팅하도록 함
  • 이를 반복하여 모든 인스턴스에 새 버전의 애플리케이션을 배포

• 적용 방법
  • ⑴ 4개의 기존 버전(v0.0.1)이 있다고 가정
  • ⑵ 그 중에 2개의 라우팅을 끊고 업데이트 버전(v0.0.2)로 업그레이드
  • ⑶ 업데이트 버전이 배포가 되면 다시 라우팅을 시작
  • ⑷ 나머지 2개 인스턴스의 라우팅을 끊고 업데이트 버전을 배포
  • ⑸ 나머지 2개의 인스턴스의 업데이트가 끝나면 다시 라우팅을 연결

• 장점
  • 인스턴스마다 차례로 배포를 진행하기에 상황에 따라 손쉽게 롤백이 가능
  • 추가적인 인스턴스를 늘리지 않아도 됨
  • 간편한 관리

• 단점
  • 새 버전을 배포할때 인스턴스의 수가 감소하기 때문에 사용 중인 인스턴스에 트래픽이 몰릴 수 있음
    • 즉, 서비스 처리 용량을 고려해야 함
    • 적용 방법에서 2번 과정과 4번 과정에서 4개의 인스턴스에서 감당하던 트래픽이 2개의 인스턴스로 몰리는 경우
  • 배포가 진행될때 구 버전과 신 버전이 공존하기에 호환성 문제가 발생할 수 있음
    • 적용 방법에서 3번 과정에서 업데이트 된 버전 2개, 안된 버전 2개가 공존하므로 사용자들은 균일한 서비스를 받지 못함

② 블루 그린 (Blue Green)

• 구 버전을 블루, 신 버전을 그린 이라고 해서 붙여진 이름
  • 신 버전을 배포하고 일제히 전환하여 모든 연결을 신 버전을 바라보게 하는 전략
  • 구 버전, 신 버전 서버를 동시에 나란히 구성하여 배포 시점에 트래픽이 일제히 전환
  • 빠른 롤백이 가능하고 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 신 버전 테스트가 가능
  • 단 이런 구성은 시스템 자원이 두배로 필요하여 비용이 더 많이 발생

• 블루는 구 버전, 그린은 신 버전을 의미
  • 운영 중인 구 버전과 동일하게 신 버전의 인스턴스를 구성한 후 로드 밸런서를 통해 모든 트래픽을 한번에 신 버전 쪽으로 전환하는 방식

• 장점
  • 구 버전의 인스턴스가 그대로 남아있어서 손쉬운 롤백이 가능
  • 구 버전의 환경을 다음 배포에 재사용할 수 있음
  • 운영 환경에 영향을 주지 않고 새 버전 테스트 가능

• 단점
  • 시스템 자원이 두배로 필요
  • 새로운 환경에 대한 테스트가 전제되어야 함

③ 카나리 (Canary)

• 카나리 배포에 대한 설명에 앞서 카나리에 대한 어원을 알아보면 사전적 의미는 카나리아라는 새
  • 카나리아는 유독가스에 굉장히 민감한 동물로 석탄 광산에서 유독가스 누출의 위험을 알리는 용도로 사용되어 왔는데 미리 위험을 감지하기 위함이었음

• 카나리 배포는 위험을 빠르게 감지할 수 있는 배포 전략
  • 지정한 서버 또는 특정 유저에게만 배포했다가 정상적이면 전체를 배포
  • 서버의 트래픽을 일부를 신 버전으로 분산하여 오류 여부를 확인할 수 있음
  • 이런 전략은 A/B 테스트가 가능하며 성능 모니터링에 유용
  • 트래픽을 분산시킬 때는 라우팅을 랜덤 하게 할 수 있고 사용자로 분류할 수도 있음

• 신버전을 소수의 유저들에게만 배포를 해보고 문제가 없는 것을 확인해가며 점차 많은 유저들에게 배포하는 기법
  • 블루 그린 배포와 유사하지만 블루 그린처럼 트래픽을 한번에 확 바꾸는 것이 아니라 단계적으로 전환하기에 부정적 영향을 최소화하고 상황에 따라 트래픽 양을 조절하며 롤백할 수 있

• 장점
  • 문제 상황을 빠르게 감지
  • A/B 테스트로 활용 가능

• 단점
  • 네트워크 트래픽 제어 부담

④ 롤링 방식 시나리오

• ⑴ A 서버에 새로운 버전을 배포
• ⑵ A 서버로 가던 요청은 실패
• ⑶ A 서버로 가던 실패한 요청을 Nginx가 다른 서버로 다시 요청
• ⑷ A 서버가 정상적으로 실행되면 다른 B, C ... 서버에 배포

Nginx + 𝛼

• 트래픽이 매우 많아져도 Nginx만으로 충분할까?
  • 그렇지 않음
  • 결국 모든 트래픽은 Nginx를 거치기 때문에 다른 방법을 추가해야 함

• 세 가지 방법이 있음
  • Nginx 서버 스케일 업, 네트워크 장치로 로드밸런싱, DNS 리다이렉션

Nginx 스케일 업

• 스케일 업이란 성능을 향상 시킨다는 의미
  • CPU나 메인 메모리가 더 좋은 인스턴스로 교체된다고 생각하면 쉬움

네트워크 장치로 로드밸런싱

• Nginx와 같은 소프트웨어가 아닌 하드웨어적으로 로드 밸런싱을 하는 것
  • 대표적으로 L4 스위치나 L7 스위치를 사용하는 방법이 있음
  • 아래 추가 내용 있음

DNS 리다이렉션

• 웹 브라우저에 URL을 입력하게 되면 DNS 서버로 URL을 전송하여 URL에 매칭되는
  IP 주소를 찾게 됨
  • 아래 추가 내용 있음
  • 해당 IP로 접속해야 할 서버가 어딘지 알게 되는데 이 때 하나의 도메인에 여러 개의 IP가 있는 상태

• 그림에서 보면 10.10.10.x와 같은 여러개의 IP가 존재하는걸 볼 수 있음
  • DNS에서 각 IP로 트래픽을 분산시켜 주는 것

L4 스위치, L7스위치와 Nginx의 차이

• L4 스위치와 L7 스위치는 Nginx와 비슷한 역할을 수행하지만 근본적으로 다름

• Nginx는 결국 서버 위에 올라가고 서버에서 돌아가는 애플리케이션에 불과
  • 서버에서 사용하는 리소스를 Nginx가 공유하여 사용하는 형태이기 때문에 트래픽을 처리하는데 온전히 모든 리소스를 사용할 수 없음
  • 또한 서버 자체는 트래픽을 처리하기 위해서만 존재하지 않으며 여러가지 범용적인 애플리케이션을 실행할 수 있도록 만들어져 있음

• 컴퓨터 과학은 거의 대부분 장점의 이면에서 트레이드 오프가 존재하는데 범용적이라는 말은 전문적이지 않다는 것을 의미
  • 이 말은 Nginx가 올라가 있는 서버 역시 범용적이지만 전문적이지 않다는 뜻

• 반면 L4 스위치, L7 스위치는 네트워크 장비
  • 이 장비들은 범용성은 떨어지지만 네트워크 트래픽을 전문적으로 처리
  • L4와 L7이라는건 OSI 7계층 중 각 4계층과 7계층에서 동작한다는 의미

• L4 스위치는 4계층에서 동작하는 스위치이므로 4계층까지만 트래픽을 확인하고 로드 밸런싱함
  • 4계층에는 IP, 포트와 같은 데이터는 포함되지만 URL 같은 데이터는 볼 수 없음
    • 4계층은 1•2•3계층을 포함
  • 따라서 L4 스위치는 IP, 포트를 기준으로 로드밸런싱 함
• L7 스위치는 7계층에서 동작하므로 모든 데이터를 볼 수 있음
  • 따라서 L7 스위치는 IP, 포트, Http Host 정보, URL 등으로 로드 밸런싱 가능

웹 브라우저에 URL을 입력할 때

① 브라우저

• ⑴ 웹 브라우저에 URL을 입력
• ⑵ HTTP Requset Message를 만듬
• ⑶ Message를 OS에게 전송 요청을 부탁해서 메시지를 전달
• ⑷ DNS 서버로 URL을 전송하여 URL에 매칭되는 IP 주소를 찾음
  • 이 과정에서 DNS 리다이렉션 방법을 수행

② 프로토콜 스택, LAN 어댑터

• ⑴ 프로토콜 스택(OS에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 Message를 받음
• ⑵ Message를 패킷에 저장하며 수신처 주소와 같은 제어 정보를 덧붙임
• ⑶ 패킷은 LAN 어댑터에 전송
• ⑷ LAN 어댑터는 이를 전기신호로 변환시켜 LAN 케이블에 송출

③ 허브, 스위치, 라우터

• ⑴ 송출된 신호는 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착
• ⑵ 라우터는 패킷을 프로바이더(통신사)에게 전달하고 인터넷으로 들어가게 됨

④ 액세스 회선, 프로바이더

• ⑴ 패킷은 인터넷의 입구에 있는 액세스 회선에 의해 POP(통신사용 라우터)까지 운반됨
• ⑵ POP를 거쳐 인터넷의 핵심부로 들어가고 고속 라우터들을 지나 목적지에 도착

⑤ 방화벽, 캐시서버

• ⑴ 패킷은 목적지의 LAN에 도착하고 방화벽이 패킷을 검사
• ⑵ 패킷이 웹 서버까지 가야하는지 가지 않아도 되는지 캐시 서버가 판단
  • 액세스한 페이지의 데이터가 캐시 서버에 있으면 웹서버에 의뢰하지 않고 바로 그 값을 읽을 수 있음

⑥ 웹 서버

• ⑴ 패킷이 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 애플리케이션 서버(was)에 넘김
  • 이 웹 애플리케이션 서버가 보통 우리가 만든 웹 애플리케이션이 됨
• ⑵ 웹 서버 애플리케이션은 요청 메시지에 따른 응답 메시지를 클라이언트로 회송
• ⑶ 왔던 방식대로 응답 메시지가 클라이언트에게 전달됨