배경지식

1. L4 스위치

L4 스위치 = 포트 + 로드밸런싱

로드밸런싱은, 동일한 역할을 수행하는 서버 그룹을 VIP (Virtual IP) 를 통해 관리하며, 서버로 향하는 트래픽을 일단 VIP를 가진 L4 스위치로 수신한 후 Round Robin 등 분배정책에 따라 적절한 서버에 분배해 주는 것을 말합니다. (부하 분산)

• VIP (Virtual IP) 는 서버그룹의 대표 IP라 할 수 있습니다.

1.1 왜 L4 스위치를 사용하는가?

1. 부하를 분산하기 위해
   예를 들어 한 서버에 웹 서비스(80)를 하는 서버가 있는데, 부하 문제로 서버를 증설해야 하는 상황이라고 가정하자. 그러나 서버를 여러대 두고 IP를 하나 더 할당하게 되면, 기본 서비스와 IP가 달라지는 문제가 발생한다.

   이 때 사용하는 것이 L4장비의 VIP 이다.

   예를 들어 기존에 사용하는 서버의 IP가 128.x.x.1 이라고 가정하자,

   1. 이 IP를 L4장비의 VIP로 할당한다. 128.x.x.1 / 80
   2. 기존 서버에는 128.x.x.2 와 새로운 서버에는 128.x.x.3을 할당한다.
   3. L4장비에 로드밸런싱이 가능하게 세팅합니다.
   4. 그러면 이제 128.x.x.1 로 요청하는 응답에 대해서 L4가 처리하게 됨
   5. hash, round-robin 방식 등을 이용하여 로드를 분산한다.

2. fail-over 기능 (실패 대비)
   L4에 fail over 기능을 이용 할 경우, 에러가 발생한 인스턴스 대신 다른 인스턴스가 대답하게 할 수 있다.

무중단 배포

https://perfectacle.github.io/2019/04/21/non-stop-deployment/

개요

먼저 우리가 일반적으로 생각하는 배포는 아래와 같다.

1. 새롭게 배포할 내용이 있으니, 포트 충돌 방지를 위하여 기존 운영되는 서버를 다운시킨다.
2. [공사중] 배너를 건다
3. 새롭게 배포될 서버를 띄운다.

개인 홈페이지 정도는 괜찮지만 핵심 서비스에 배포 때문에 새로운 서버를 띄우는데 오랜 시간이 걸린다면, 심각한 손실이 발생할 수 있다. (예를 들어 결제)
이를 방지하기 위해 무중단 배포가 필요하다.

무중단 배포의 조건

• 두대 이상의 서버로 서비스해야 한다. (하나를 내리면 하나는 살아있어야 하기 때문)
• 비용을 위해 배포시에만 두개의 서버를 운용해도 된다.

무중단 배포의 종류

1. Rolling Deployment

• 로드밸런서도 두개를 운용하는게 좋음

1. 배포할 서버 한대 (서버1) 를 로드밸런서에서 제외시킨다.
2. 제외된 서버1 에 배포한다.
3. 서버1의 배포가 끝나면, 다시 로드밸런서에 넣는다.
4. 배포가 아직 되지 않은 서버2를 로드밸런서에서 제외시킨다.
5. 제외된 서버2 에 배포한다.
6. 서버2의 배포가 끝나면, 다시 로드밸런서에 넣는다.

단점은 배포 시간이 오래걸리고,
누구는 이전 버전을 서비스 받고 누구는 다음 버전을 서비스받는 문제가 생긴다.

2. Blue / Green Deployment

Blue 는 실제 프로덕션 환경을 말하고, Green 은 새롭게 배포할 환경(alpha) 이다.
이 둘을 항상 띄워놓고 배포할때 사용하는것을 말한다.

장점

1. 새롭게 배포할 환경에만 배포하면 되기 때문에 속도가 빠르다.

2. 언제나 Green 환경도 준비되어 있으므로 만약에 잘못된 버전으로 배포했을 경우에 빠른 롤백이 가능하다.

3. 언제나 Green 환경이 준비되어있어야 하므로 비용도 두 배로 든다.

순서

1. 우선 기존의 서버그룹과 같은 서버그룹을 하나 더 만든다. 서버 버전도 동일하고 모든게 똑같지만 로드밸런서에 연결되어 있지는 않다.

   

2. 복사한 서버그룹 내부의 서버들을 1.0.2버전으로 업데이트 진행한다. 여전히 로드밸런서에는 연결되어 있지 않다.

   

3. 업데이트가 진행된 복사한 서버그룹을 로드밸런서에 연결한다.

   

4. 기존에 존재하던 1.0.1버전 서버그룹을 로드밸런서에서 연결 해제한다. 이 상태부터 사용자들은 온전하게 1.0.2버전을 이용할 수 있게 된다.

   

• 업데이트를 진행하는 도중에도 서버의 수는 그대로 유지되기 때문에 기존 사용되던 그대로 서버를 업데이트 하면 된다. 따라서 부하가 걸릴 위험이 사라진다.

• 만약 1.0.2버전에 문제가 있으면 아직 없애지 않은 1.0.1 버전의 서버그룹으로 로드밸런서를 연결해 주기만 하면 된다. 이후에 1.0.2 버전의 문제를 해결하고 다시 로드밸런서만 옮겨서 연결하면 된다.

회고

그러나 이같은 경우는 클라우드 환경이나 서버를 융통성있게 운용하는 환경에서나 가능하다. 물리 서버를 설치해놓고 평소에 그린환경의 서버그룹을 쓰지 않는다면 자원이 아깝다. (테스트서버를 그린환경으로 해놓고 쓰는 등의 효율적 운용이 필요)

2.1 Ngnix 를 이용한 무중단 배포

Ngnix 는 스레드와 프로세스를 사용하는 Apache 와 달리, 비동기 이벤트 호출 방식을 사용하는 오픈소스 웹 서버

위의 그림에는 Ngnix가 리버스 프록시 (대리인) 서버로 사용되고 있다.

하나의 EC2 혹은 리눅스 서버에 Nginx 1대 와 스프링부트 jar를 2대 를 사용
Nginx는 80(http), 443(https) 포트를 할당하고
스프링부트1은 8081포트로, 스프링부트2는 8082포트로 실행한다.

1. Ngnix 가 두 WAS 중, 하나에만 연결 시켜놓음
2. 연결되지 않은 놈을 배포 시키고 ngnix reload 를 통해, ngnix 가 바라보는 방향 변경

아키텍쳐 기본

1. NGINX

Apache 의 개선 버전의 웹서버 로 , 스레드 방식이 아닌 비동기 방식으로 처리한다.
가볍고 빠르며, 로드밸런싱과 리버스 프록시 기능도 지원한다.

• 그러나 Health Check 결과에 따른 융통성 있는 로드밸런싱 불가

2. HAProxy

하드웨어 로드밸런서 대체 위해 나온 고가용성 리버스 프록시 기반 SW 로드밸런서

• 특정 API 에 대해 헬스체크 하고 문제가 있으면 포워딩 안함 (서킷 브레이킹 방식 제공)