한 개의 웹 서버가 트래픽을 감당하지 못해 터져버린다. -> 수직적 확장 혹은 수평적 확장이 필요
새 버전의 웹 어플리케이션을 배포시
새로운 웹 서버에 배포하는 경우 IP가 변경
기존의 웹 서버에 배포를 하더라도 기존 버전을 정지하고 새 버전을 구동하는 동안 유저는 사용하지 못함.
✅트래픽 분산
로드 밸런서를 웹 서버의 앞단에 두고, IP를 부여한 뒤 웹 클라이언트가 해당 로드밸런서를 호출하게 하면
로드 밸런서는 앞단의 모든 웹 클라이언트의 요청을 받아, 뒷단의 모든 웹 서버에게 요청을 분산
🔷로드 밸런서를 이용하여 해결 가능한 이슈
배포이슈 해결: 클라이언트는 고정된 IP의 로드 밸런서만 호출하기에 웹 서버가 몇개든 죽든 말든 상관없다
클라이언트는 고정된 IP를 가진 로드 밸런서를 호출하면 로드밸런서는 요청을 받아 웹 서버에게 뿌린다. -> 특정 웹 서버가 죽어도 다른 웹 서버가 요청을 받아서 해결
흔히 apache나 nginx를 로드 밸런서로 두고 뒷단에 서버를 두는 경우 -> 로드 밸런서도 서버이다.
트래픽 이슈 해결: 아무리 많은 요청이 들어와도 로드 밸런서 뒷단에 서버 수만 늘리면 된다. -> 수평적 확장
🔷로드 밸런서의 목적
무중단 배포: 새 버전의 웹 어플리케이션을 배포하면 새로운 IP가 할당되어서 IP가 변경된다 -> 새 웹 어플리케이션 배포 전까지 유저가 사용하지 못함.
가용성: 대용량 트래픽에 대한 가용성
[심화] 메시지 큐를 통한 요청 트래픽에 대한 비동기 처리
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 배포 방식
