해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.
h1 -> #0b6e99
h2 -> #d9730d
간단히 말하면 서비스를 중단하지 않고 배포 하는 것을 의미한다.
배포라는 말은 새로 개발된 코드를 패키징 하여 서버에서 새로운 버전의 애플리케이션을
실행하도록 하는 행위를 말한다.
v1 서비스가 실행 중일 때 v2 버전을 다운로드 받는다.
v1 서비스를 종료 시키는 시점부터 v2를 시작하기 전까지 서비시는 중단된다.
이렇게 서비스가 중단되는 시간을 다운타임(downtime)이라고 한다.
v1 서비스를 꼭 중단시켜야 v2를 실행시킬 수 있는가?
동일한 포트를 사용한다고 하면 당연한 이야기이다.
이전에 docker 컨테이너를 띄울때 명령어를 보면 docker run -p 8080:8080 이미지
를 입력했다. 즉 8080포트를 특정 컨테이너가 사용중일때 다른 컨테이너를 8080 포트로 띄울수는 없다.
사용자가 두 서버의 IP를 모두 알아야 한다.
어떤 서버가 운영중인 IP인지 알 수 없다.
위 두 가지 문제를 해결하기 위해서는 클라이언트와 서버 사이에 중계해줄 누군가가 필요하다.
이러한 누군가를 리버스 프록시라고 한다.
프록시란?
리버스 프록시란?
로드 밸런싱(부하 분산)
위 그림처럼 된다면 트래픽도 분산할 수 있지 않을까?
하나의 서버에서 받아야 할 요청을 여러 서버로 분산하면 된다. 이를 로드밸런싱이라 한다.
이러한 리버스 프록시 역할과, 로드밸런싱을 수행할 수 있는 현 시점에서 가장 인기있는 웹서버가 Nginx이다.
구 버전을 블루, 신 버전을 그린 이라고 해서 붙여진 이름이다. 신 버전을 배포하고 일제히 전환하여 모든 연결을 신 버전을 바라보게 하는 전략이다. 구 버전, 신 버전 서버를 동시에 나란히 구성하여 배포 시점에 트래픽이 일제히 전환된다. 빠른 롤백이 가능하고, 운영환경에 영향을 주지 않고 실제 서비스 환경으로 신 버전 테스트가 가능하다. 단 이런 구성은 시스템 자원이 두배로 필요하여 비용이 더 많이 발생한다.
카나리 배포에 대한 설명에 앞서 카나리에 대한 어원을 알아보자. Canary의 사전적 의미에는 카나리아라는 새이다. 카나리아는 유독가스에 굉장히 민감한 동물로 석탄 광산에서 유독가스 누출의 위험을 알리는 용도로 사용되어왔다. 미리 위험을 감지하기 위함이다.
카나리 배포는 위험을 빠르게 감지할 수 있는 배포 전략이다. 지정한 서버 또는 특정 user에게만 배포했다가 정상적이면 전체를 배포한다. 서버의 트래픽을 일부를 신 버전으로 분산하여 오류 여부를 확인할 수 있다. 이런 전략은 A/B 테스트가 가능하며, 성능 모니터링에 유용하다. 트래픽을 분산시킬 때는 라우팅을 랜덤 하게 할 수 있고, 사용자로 분류할 수도 있다.
트래픽이 매우 많아져도 Nginx만으로 충분할까?
답은 그렇지 않다. 결국 모든 트래픽은 Nginx를 거치기 때문에 다른 방법을 추가해야한다.
Nginx 서버 스케일 업, 네트워크 장치로 로드밸런싱, DNS 리다이렉션 세 가지 방법이 있다.
Nginx 스케일 업
네트워크 장치로 로드밸런싱
DNS 리다이렉션
우리가 웹 브라우저에 url을 입력하게 되면 DNS 서버로 url을 전송하여 url에 매칭되는
IP주소를 찾게 된다. 해당 IP로 접속해야 할 서버가 어딘지 알게 된다. 이 때 하나의 도메인에 여러개의 IP가 있는 것이다. (우리가 웹 브라우저에 url을 입력하면 어떻게 되는지 자세한 내용은 아래에 추가했다.)
그림에서 보면 10.10.10.x와 같은 여러개의 IP가 존재하는걸 볼 수 있다.
DNS에서 각 IP로 트래픽을 분산시켜 주는 것 이다.
L4 스위치와, L7 스위치는 Nginx와 비슷한 역할을 수행하지만, 근본적으로 다르다.
Nginx는 결국 서버위에 올라가고, 서버에서 돌아가는 애플리케이션에 불과하다.
서버에서 사용하는 리소스를 Nginx가 공유하여 사용하는 형태이기 때문에 트래픽을 처리하는데 온전히 모든 리소스를 사용할 수 없다. 또한 서버 자체는 트래픽을 처리하기 위해서만 존재하지 않는다. 여러가지 범용적인 애플리케이션을 실행할 수 있도록 만들어져 있다.
컴퓨터 과학은 거의 대부분 장점의 이면에서 트레이드 오프가 존재하는데, 범용적이라는 말은 전문적이지 않다는 것을 의미한다. 이말은 Nginx가 올라가 있는 서버 역시 범용적이지만 전문적이지 않다.
하지만 L4스위치, L7스위치는 네트워크 장비이다. 이 장비들은 네트워크 트래픽을 전문적으로 처리한다. 반대로 범용성은 떨어진다.
L4와 L7이라는건 OSI 7계층중 각 4계층 7계층에서 동작한다는 의미이다.
L4스위치는 4계층에서 동작하는 스위치이므로 4계층까지만 트래픽을 확인하고 로드밸런싱한다. 4계층에는 IP, Port와 같은 데이터는 포함되지만 URL같은 데이터는 볼 수 없다. 따라서 L4스위치는 IP, Port를 기준으로 로드밸런싱을 한다. (4계층은 1,2,3 계층을 포함한다.)
L7스위치는 7계층에서 동작하므로 모든 데이터를 볼 수 있다. IP, Port, Http Host 정보, URL등 으로 로드밸런싱이 가능하다.
위와 같은 것들이 어떻게 가능한가? 라는 생각이 든다.
그러면 우리가 웹 브라우저에서 url을 입력하면 어떻게 되는지 자세히 알아보자.
웹 브라우저에 URL을 입력한다.
HTTP Requset Message를 만든다.
Message를 OS에게 전송요청을 부탁해서 메시지를 전달한다.
DNS 서버로 URL을 전송하여 URL에 매칭되는 IP주소를 찾는다.
(이 과정에서 DNS 리다이렉션 방법을 수행한다.)
프로토콜 스택(OS에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메시지를 받는다.
메시지를 패킷에 저장하며 수신처 주소와 같은 제어정보를 덧붙인다.
패킷은 LAN 어댑터에 전송한다.
LAN 어댑터는 이를 전기신호로 변환시켜 LAN 케이블에 송출시킨다.
송출된 신호는 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착한다.
라우터는 패킷을 프로바이더(통신사)에게 전달하고 인터넷으로 들어가게 된다.
패킷은 인터넷의 입구에있는 액세스 회선에 의해 POP(통신사용 라우터)까지 운반된다.
POP를 거쳐 인터넷의 핵심부로 들어가고 고속 라우터들을 지나 목적지에 도착한다.
패킷은 목적지의 LAN에 도착하고 방화벽이 패킷을 검사한다.
패킷이 웹 서버까지 가야하는지 가지 않아도 되는지 캐시서버가 판단한다.
패킷이 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 애플리케이션 서버(was)에 넘긴다. 이 was가 보통 우리가 만든 웹 애플리케이션이 된다.
웹 서버 애플리케이션은 요청 메시지에 따른 응답 메시지를 클라이언트로 회송한다.
왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.
일반적으로 우리가 웹브라우저에 url을 입력하면 위와 같은 플로우로 진행된다.
아래 내용은 뇌피셜이다.
보통은 위 플로우대로 진행되며 L4,L7 스위치와 같은 장비는 필요에 의해 추가적으로
설치하여 사용하는 것 같다. 만약 위 플로우에서 L4스위치가 추가된다면 3계층에서 동작하는 라우터를 거친 이후인 4~5번 어딘가에서 L4스위치 로드밸런싱을 수행하지 않을까 싶다.
자세히 알고 싶다면 해당 링크를 참고해보자. 굉장히 자세히 잘 정리되어 있다.
잘봤습니다^^