[ASAC 6기] 웹 개발이란 무엇이며, 어떻게 동작하나? BE(4) - Load Balancer + 다양한 배포 방식

한 개의 웹 서버를 통해 우리 웹 어플리케이션 서비스를 제공하는 경우 아래 두 문제 발생

1. 대량의 트래픽이 한개의 웹 서버에 집중되는 경우
   • 한 개의 웹 서버가 트래픽을 감당하지 못해 터져버린다. -> 수직적 확장 혹은 수평적 확장이 필요
2. 새 버전의 웹 어플리케이션을 배포시
   • 새로운 웹 서버에 배포하는 경우 IP가 변경
   • 기존의 웹 서버에 배포를 하더라도 기존 버전을 정지하고 새 버전을 구동하는 동안 유저는 사용하지 못함.

✅트래픽 분산

로드 밸런서를 웹 서버의 앞단에 두고, IP를 부여한 뒤 웹 클라이언트가 해당 로드밸런서를 호출하게 하면

로드 밸런서는 앞단의 모든 웹 클라이언트의 요청을 받아, 뒷단의 모든 웹 서버에게 요청을 분산

🔷로드 밸런서를 이용하여 해결 가능한 이슈

• 배포이슈 해결: 클라이언트는 고정된 IP의 로드 밸런서만 호출하기에 웹 서버가 몇개든 죽든 말든 상관없다
  • 클라이언트는 고정된 IP를 가진 로드 밸런서를 호출하면 로드밸런서는 요청을 받아 웹 서버에게 뿌린다. -> 특정 웹 서버가 죽어도 다른 웹 서버가 요청을 받아서 해결
  • 흔히 apache나 nginx를 로드 밸런서로 두고 뒷단에 서버를 두는 경우 -> 로드 밸런서도 서버이다.
• 트래픽 이슈 해결: 아무리 많은 요청이 들어와도 로드 밸런서 뒷단에 서버 수만 늘리면 된다. -> 수평적 확장

🔷로드 밸런서의 목적

1. 무중단 배포: 새 버전의 웹 어플리케이션을 배포하면 새로운 IP가 할당되어서 IP가 변경된다 -> 새 웹 어플리케이션 배포 전까지 유저가 사용하지 못함.
2. 가용성: 대용량 트래픽에 대한 가용성

 

[심화] 메시지 큐를 통한 요청 트래픽에 대한 비동기 처리

Producer 는 메세지(요청)를 발행하고, Queue 는 메세지를 저장하는 버퍼에 해당하며, Consumer 는 메세지(요청)을 처리

위에서 설명한 로드밸런서를 통해 웹 서버 개수를 늘려서 트래픽에 대응하는 것은 모든 요청들을 동기적으로 처리하기 위함이다.

만약, 실시간으로 요청에 대한 동기적 처리가 필요한 것이 아니라면 비실시간으로 비동기로 처리하는 방법도 있다 -> 메세지 큐 이용

 

메시지 큐 통신 방식은 중간에 메세지 큐를 두고 Producer / Consumer를 갖는다.

• Producer: 메세지(요청)를 발행
• Queue: 메세지를 저장하는 버퍼
• Consumer: 메세지(요청)을 처리

[메시지 큐 동작 원리]

Producer가 요청 -> Queue에 요청 저장 -> 서버에 여유가 생기면 그때 consumer가 요청 처리

 

[메세지 큐의 장점]

🔹비동기: Queue라는 메세지를 저장하는 버퍼(임시 저장소)가 있기 때문에 나중에 처리 가능
🔹탄력성: consumer 서비스가 다운되거나, 문제가 생겨도 다시 살아나서 메세지를 소비만 하면 된다. (비
🔹확장성: Producer가 엄청 많아져도, Consumer가 적어도 서비스를 원하는대로 확장할 수 있음.
🔹낮은 결합도: consumer와 분리되어 있어, consumer에 문제가 생겨도, 구현체가 바뀌어도 상관 없음
🔹보장성: Queue안에 있는 모든 메시지는 Consumer 서비스에서 모두 처리됨을 보장

---

✅배포의 종류: Rolling / Canary / Blue-Green

로드밸런서의 등장으로 인해 수평적 확장으로 다수의 웹 서버를 한번에 운용할 수 있게되었다.
이에 따라 웹 어플리케이션의 버전을 바꾸기 위해 재배포를 할때 단 하나의 웹 서버만 바꾸는것이 아니라 모든 다수의 웹 서버를 새로운 버전으로 바꾸는 재배포를 해야해서, 관련된 몇가지 전략들이 등장하였다.

 

1. Rolling 배포 방식

구버전 하나 죽이고 -> 신버전 하나 살리고 -> 반복 

• 버전 간 트래픽이 섞이지 않는다.
• 이미 갖고있는 인스턴스 수 안에서 점진적 배포에 해당하기에 추가 비용 발생이 없고, 가용성이 좋다.

[Rolling 배포 2가지 방법]

(좌)Rolling With Additional Batches 방식 / (우)Immutable 배포 방식

1. Rolling With Additional Batches 방식 
   • 트래픽에 대한 기존 인스턴스 수(Capacity) 유지(출처)
   • 가용성을 해치지 않기 위해서 하나의 서버가 죽으면 그 서버에 대한 additional batch가 실행
     • 위 그림에서 V2가 additional batch
2. Immutable 배포 방식
   • 그룹(후에 배울 ASG)을 기준으로 구버전 / 신버전 구별 및 배포, 전환(출처)
   • auto scaling group이 2개(auto sacling group: 최소 보장 인스턴스 수) 있어서 불변성이다.

---

2. Canary 배포 방식

신버전 테스트 후 -> 신버전 전체 전환(기미상궁st)

• 버전 간 트래픽이 섞인다.
  • 의도적으로 트래픽을 섞이도록하여 버전 간 트래픽이 섞이면 A/B 테스트나 성능 테스트에 굉장히 용이하다.

💡A/B 테스트

다음과 같은 상황을 A/B테스트라고 한다.
유저가 빨간색 버튼과 파란색 버튼 중 어느 버튼을 더 많이 누르는지 확인하고 싶을 때
트래픽을 50:50으로 나눠서 유저를 대상으로 사회실험을 한다고 한다. -> 로드 밸런서의 중요성

오늘의 집 같은 경우 UI 컴포넌트들을 모두 api로 만들어서 A/B 테스트를 진행한다고 한다.
따라서 페이지를 호출할 때마다 컴포넌트 api를 호출하면 부담이 많으니 이건 SSR로 처리하고 나머지는 CSR..

---

3. Blue-Green 배포 방식

그룹을 기준으로 구버전 / 신버전 구별하며, 문제 발생 시 즉시 롤백이 가능

일반적으로 Canary + Blue-Green 방식을 합쳐 배포하며, Blue-Green 이 Canary 개념을 내포하기도함

---

4. Blue-Green + Canary 방식 배포 사례

빅테크 기업에서는 Canary 배포 + Blue+Green 배포 두 전략의 각 장점만 합쳐 혼합 사용