단 한 개의 웹서버를 통해 웹 어플리케이션 서비스를 제공하는 경우 다음과 같은 두 문제가 발생할 수 있다.
먼저 대량의 트래픽이 한 개의 웹 서버에 집중되는 경우 한 개의 웹 서버가 트래픽을 감당하지 못해 터져버린다. 이를 해결하기 위해 수직적 또는 수평적 확장이 필요하다. 두번째로, 새 버번의 웹 어플리케이션 배포시 새로운 웹서버에 배포하는 경우 IP 변경이 필요하고, 기존의 웹 서버에 배포하더라도 기존 버전을 정지하고 새 버전을 구동하는 동안 유저는 사용하지 못하는 문제가 발생한다.
01. 트래픽 분산
로드밸런서를 웹 서버의 앞단에 두고 IP 부여한 뒤 웹 클라이언트가 해당 로드밸런서를 호출하게 되면, 로드 밸런서는 앞단의 모든 웹 클라이언트의 요청을 받아 뒷 단의 모든 웹서버에게 요청을 분산할 수 있다. 다음과 같은 방식으로 배포 이슈, 트래픽 이슈를 해결할 수 있다.
배포 이슈 해결 : 클라이언트는 고정된 IP의 로드밸런서만 호출하기에 웹서버의 갯수, 실행 가능성이 상관이 없다.
트래픽 이슈 해결 : 아무리 많은 요청이 들어와도 로드밸런서 뒷단에 서버 수만 늘리면 된다.
02. 메시지 유출 통한 요청 트래픽에 대한 비동기 처리
로드밸런서를 통해 웹 서버의 갯수를 늘려 트래픽에 대응하는 것은 모든 요청들을 동기적으로 처리하기 위함이다.
만약, 실시간으로 요청에 대한 동기적 처리가 필요한 것이 아니라면, 비실시간으로 비동기로 처리하는 방법이 존재한다.
먼저 모든 요청들을 가운데에 메시지 큐에 담아놓고, 서버가 처리할 여유가 생겼을 때 메시지 큐에 담긴 요청을 하나씩 가져와 처리하면 된다.
위와 같이 메시지 큐를 이용한 통신 방식은 중간에 메시지 큐를 두고 Producer/Consumer를 갖는다.
Producer는 메시지 요청을 발행하고, Queue는 메시지를 저장하는 버퍼에 해당하며, Consumer는 메시지 요청을 처리한다.
Producer : 메시지(요청)을 발행
Queue : 메시지를 저장하는 버퍼
Consumer : 메시지(요청)을 처리
💡 메시지 큐 장점
비동기 : Queue라는 메시지를 저장하는 버퍼가 존재해 나중에 처리 가능
탄력성 : Consumer 서비스가 다운되거나 문제 발생해도 다시 살아나서 메시지를 소비만 하면 됨
확장성 : Producer가 엄청 많아도, Consumer가 서비스를 원하는대로 확장 가능
낮은 결합도 : Consumer와 분리되어 있어, Consumer에 문제 발생하거나 구현체가 바뀌어도 상관 없음
보장성 : Queue안에 있는 모든 메시지는 Consumer 서비스에서 모두 처리됨을 보당
메시지 큐의 장점은 서버의 수가 아무리 적어도 많은 요청들을 결국에는 다 처리할 수 있다는 것이다.
따라서, 로그나 매트릭과 같이 실시간 처리가 필요하지 않은 빅데이터 수집이나 분석 작업에 적합하다.
💡 메시지 큐 서비스 예시
◼︎ Kafka
Topic 기반으로 메시지들을 나누어 담고, 메시지는 실제로 소비되는 것이 아닌 오프셋만 변경된다.
Queue는 Broker 집단의 Cluster로 동작되며, Broker 집단은 Zookeeper로 관리된다.
장기적으로는 Non-Persistence Messaging이기에 개별 저장소에 연결하여 백업이 필요하다.
◼︎ RabbitMQ
AMQP, Stomp, MQTT 프로토콜을 지원하며, 메시지는 실제로 소비되면 바로 삭제된다.
다중 노드를 통한 Load Distribution으로 High Availibility를 보장한다.
◼︎ AWS SQS
자체적으로 메시지를 추적할 수 있는 콘솔을 제공한다.
03. 배포의 종류 : Rolling / Canary / Blue-Green 방식
로드밸런서의 등장으로 인해 수평적 확장으로 다수의 웹 서버를 한 번에 운용할 수 있게 되었다.
이에 따라 웹 어플리케이션의 버전을 바꾸기 위해 재배포를 할 때 단 하나의 웹 서버만 바꾸는 것이 아닌 모든 다수의 웹 서브를 새로운 버전으로 바꾸는 재배포를 해야하기 때문에 몇 가지 전략들이 등장하였다.
#1. Rolling 방식
Rolling 배포 방식은 서버를 한 대씩 구 버전에서 새 버전으로 교체하는 방식이다.
즉, 전체 서버 중 하나의 서버를 선택하여 구버전 어플리케이션을 종료시키고, 그 자리에 신버전 어플리케이션을 배포한다. 이 과정을 모든 서버에 대해 순차적으로 반복한다.
트래픽은 항상 새로운 버전과 기존 버전의 서버 간에 정확하게 구분된다.
한 서버가 업데이트되는 동안 나머지 서버는 여전히 구버전으로 서비스하고 있으므로 트래픽이 섞이지 않는다.
서비스 중단 없이 어플리케이션 버전 업그레이드 가능하지만, 구버전과 신버전이 공존하는 동안의 상태 관리가 중요하다. 특히 데이터베이스 스키마 변경 등에서 버전 간 호확성을 유지해야 한다. 이미 갖고있는 인스턴스 수 안에서 점진적 배포에 해당하기 때문에 추가 비용 발생이 없고 가용성이 좋다.
#2. Canary 방식
Canary 배포 방식은 카나리아 새처럼 위험을 빠르게 감지할 수 있는 배포 방식이다.
구버전의 서버와 새버전의 서버들을 구성하고 일부 트래픽을 새버전으로 분산하여 오류 여부를 판단한다.
버전간 트래픽이 섞이는 특징으로 인해 A/B 테스트도 가능하며 오류율 및 성능 모니터링에 유용하다.
#3. Blue-Green 방식
Blue-Green 배포 방식은 구버전을 Blue, 신버전을 Green이라 해서 붙여진 이름으로, 구버전에서 신버전으로 일제히 전환하여 모든 연결을 신버전으로 전환하는 전략이다. 하나의 버전만 프로덕션되므로 버전 관리 문제를 방지할 수 있고, 빠른 롤백이 가능하다.
운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새버전 테스트가 가능하다. 하지만 시스템 자원이 두배로 필요하기 때문에 비용이 더 많이 발생한다.
일반적으로 Canary + Blue-Green 방식을 합쳐 배포하며, Blue-Green 이 Canary 개념을 내포하기도한다.
Load Balancer : 대량 트래픽에 의한 서버 부담 분산
단 한 개의 웹서버를 통해 웹 어플리케이션 서비스를 제공하는 경우 다음과 같은 두 문제가 발생할 수 있다.
먼저 대량의 트래픽이 한 개의 웹 서버에 집중되는 경우 한 개의 웹 서버가 트래픽을 감당하지 못해 터져버린다. 이를 해결하기 위해 수직적 또는 수평적 확장이 필요하다. 두번째로, 새 버번의 웹 어플리케이션 배포시 새로운 웹서버에 배포하는 경우 IP 변경이 필요하고, 기존의 웹 서버에 배포하더라도 기존 버전을 정지하고 새 버전을 구동하는 동안 유저는 사용하지 못하는 문제가 발생한다.
01. 트래픽 분산
로드밸런서를 웹 서버의 앞단에 두고 IP 부여한 뒤 웹 클라이언트가 해당 로드밸런서를 호출하게 되면, 로드 밸런서는 앞단의 모든 웹 클라이언트의 요청을 받아 뒷 단의 모든 웹서버에게 요청을 분산할 수 있다. 다음과 같은 방식으로 배포 이슈, 트래픽 이슈를 해결할 수 있다.
02. 메시지 유출 통한 요청 트래픽에 대한 비동기 처리
로드밸런서를 통해 웹 서버의 갯수를 늘려 트래픽에 대응하는 것은 모든 요청들을 동기적으로 처리하기 위함이다.
만약, 실시간으로 요청에 대한 동기적 처리가 필요한 것이 아니라면, 비실시간으로 비동기로 처리하는 방법이 존재한다.
먼저 모든 요청들을 가운데에 메시지 큐에 담아놓고, 서버가 처리할 여유가 생겼을 때 메시지 큐에 담긴 요청을 하나씩 가져와 처리하면 된다.
위와 같이 메시지 큐를 이용한 통신 방식은 중간에 메시지 큐를 두고 Producer/Consumer를 갖는다.
Producer는 메시지 요청을 발행하고, Queue는 메시지를 저장하는 버퍼에 해당하며, Consumer는 메시지 요청을 처리한다.
💡 메시지 큐 장점
메시지 큐의 장점은 서버의 수가 아무리 적어도 많은 요청들을 결국에는 다 처리할 수 있다는 것이다.
따라서, 로그나 매트릭과 같이 실시간 처리가 필요하지 않은 빅데이터 수집이나 분석 작업에 적합하다.
💡 메시지 큐 서비스 예시
◼︎ Kafka
Topic 기반으로 메시지들을 나누어 담고, 메시지는 실제로 소비되는 것이 아닌 오프셋만 변경된다.
Queue는 Broker 집단의 Cluster로 동작되며, Broker 집단은 Zookeeper로 관리된다.
장기적으로는 Non-Persistence Messaging이기에 개별 저장소에 연결하여 백업이 필요하다.
◼︎ RabbitMQ
AMQP, Stomp, MQTT 프로토콜을 지원하며, 메시지는 실제로 소비되면 바로 삭제된다.
다중 노드를 통한 Load Distribution으로 High Availibility를 보장한다.
◼︎ AWS SQS
자체적으로 메시지를 추적할 수 있는 콘솔을 제공한다.
03. 배포의 종류 : Rolling / Canary / Blue-Green 방식
로드밸런서의 등장으로 인해 수평적 확장으로 다수의 웹 서버를 한 번에 운용할 수 있게 되었다.
이에 따라 웹 어플리케이션의 버전을 바꾸기 위해 재배포를 할 때 단 하나의 웹 서버만 바꾸는 것이 아닌 모든 다수의 웹 서브를 새로운 버전으로 바꾸는 재배포를 해야하기 때문에 몇 가지 전략들이 등장하였다.
#1. Rolling 방식
Rolling 배포 방식은 서버를 한 대씩 구 버전에서 새 버전으로 교체하는 방식이다.
즉, 전체 서버 중 하나의 서버를 선택하여 구버전 어플리케이션을 종료시키고, 그 자리에 신버전 어플리케이션을 배포한다. 이 과정을 모든 서버에 대해 순차적으로 반복한다.
트래픽은 항상 새로운 버전과 기존 버전의 서버 간에 정확하게 구분된다.
한 서버가 업데이트되는 동안 나머지 서버는 여전히 구버전으로 서비스하고 있으므로 트래픽이 섞이지 않는다.
서비스 중단 없이 어플리케이션 버전 업그레이드 가능하지만, 구버전과 신버전이 공존하는 동안의 상태 관리가 중요하다. 특히 데이터베이스 스키마 변경 등에서 버전 간 호확성을 유지해야 한다. 이미 갖고있는 인스턴스 수 안에서 점진적 배포에 해당하기 때문에 추가 비용 발생이 없고 가용성이 좋다.
#2. Canary 방식
Canary 배포 방식은 카나리아 새처럼 위험을 빠르게 감지할 수 있는 배포 방식이다.
구버전의 서버와 새버전의 서버들을 구성하고 일부 트래픽을 새버전으로 분산하여 오류 여부를 판단한다.
버전간 트래픽이 섞이는 특징으로 인해 A/B 테스트도 가능하며 오류율 및 성능 모니터링에 유용하다.
#3. Blue-Green 방식
Blue-Green 배포 방식은 구버전을 Blue, 신버전을 Green이라 해서 붙여진 이름으로, 구버전에서 신버전으로 일제히 전환하여 모든 연결을 신버전으로 전환하는 전략이다. 하나의 버전만 프로덕션되므로 버전 관리 문제를 방지할 수 있고, 빠른 롤백이 가능하다.
운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새버전 테스트가 가능하다. 하지만 시스템 자원이 두배로 필요하기 때문에 비용이 더 많이 발생한다.
일반적으로 Canary + Blue-Green 방식을 합쳐 배포하며, Blue-Green 이 Canary 개념을 내포하기도한다.
'ASAC > 웹 기초 프로그래밍' 카테고리의 다른 글