개요
트래픽을 견디기 위해 어떤 것을 사용해야할까?
너드팩토리의 제품들은 매우 많은 데이터를 수집하고 있다보니 서비스가 불안정한 경우가 종종 있었습니다.
예를 들면 고객사에서 특별한 이벤트를 진행하거나 급성장하여 트래픽이 급증할 수 있습니다.
소프트웨어 아키텍트 입장에서 안정적으로 트래픽을 감당하기 위해 Message Queue와 Load Balancer를 고려해보았습니다.
물론 더 다양한 방법이 존재하지만 여기서는 두 방법론에 대해서만 다루겠습니다.
본 포스팅에서는 두 방법을 비교하여 적절하게 활용하는 관점을 제공하고자 합니다.
기술 설명
기술 비교에 앞서 각 기술을 간략히 설명해두었습니다.
Message Queue(MQ)란?
MQ는 메시지 큐(Message Queue)의 줄임말로 인스턴스 간 데이터 교환 시 통신하는 방법입니다.
메시지 큐는 대용량 데이터를 처리하기 위해 배치 작업에 사용하거나 비동기 동작을 위해서 사용하게 됩니다.
일반적으로 Django, Flask는 사용자가 많아지거나 서비스의 크기가 증가함에 따라, 응답 시간이 길어지거나 서비스가 무너지게 됩니다.
이 경우에는 생산자(Producers)와 소비자(Consumers)가 붙어있는 형태로 볼 수 있습니다.
MQ가 도입될 경우 위 그림처럼 생산자와 소비자 사이에 브로커(broker)가 추가됩니다.
생산자는 교환대의 역할을 수행하는 Exchange에 접근하여 요청을하고 Exchange에서는 정해진 규칙에 따라 알맞은 큐에 메시지를 전달합니다.
큐에 전달된 메시지는 Consumer에게 전달됩니다.
Load Balancer란?
로드 밸런서는 다수의 컴퓨팅 리소스로 분산하기 위해 사용합니다.
서비스를 확장하는 방법에는 2가지 방법이 있습니다.
- Scale-up: 서버의 성능을 향상 (수직 확장)
- Scale-out: 서버의 수를 증대 (수평 확장)
로드 밸런서는 Scale-out 방법론에 해당합니다.
단일 서버가 아닌 다수의 서버를 구성하여 로드 밸런서가 정해진 알고리즘에 따라 서버에 요청을 분산합니다.
클라이언트는 서버에 직접 접근하는 것이 아닌 로드 밸런서로 접근하게 됩니다. 이는 서버 또한 동일합니다.
클라이언트가 로드 밸런서로 요청을 전달하면, 로드 밸런서는 분배 알고리즘을 통해 서버에 전달합니다.
서버는 로드 밸런서로 응답을 하면, 로드 밸런서가 클라이언트에게 응답 결과를 전달합니다.
어느 방법이 적합할까?
이를 활용하는데 있어 적합한 방법을 찾는 관점이 필요합니다.
아래 내용에는 적합한 방법을 찾는 관점에 대해 기술하였습니다.
MQ를 사용하기 적절한 경우
이미지, 영상, 대용량 처리를 수행하는 경우 동시에 처리할 수 있는 작업량은 비교적 적습니다.
메시지 큐를 사용할 경우, 동시에 처리할 양만 서버에서 가져가 처리하게 됩니다.
이와 같이 대용량 데이터를 처리하는 작업을 수행할 경우 MQ가 적합합니다.
MQ를 사용하기 부적절한 경우
MQ의 경우 기본적으로 서버가 큐로부터 작업을 가져가야만 처리가 이루어집니다.
따라서 응답속도가 비교적 느립니다.
빠른 응답속도가 보장되어야 하는 서비스의 경우 MQ가 적합하지 않습니다.
Load Balancer를 사용하기 적절한 경우
MQ를 사용하기 부적절한 경우의 반대로 생각하시면 간단합니다.
Load Balancer는 서버에 즉시 작업을 전달하여 빠르게 처리가 이루어집니다.
따라서 빠른 응답속도가 보장되어야 할 경우 Load Balancer가 적합합니다.
Load Balancer를 사용하기 부적절한 경우
MQ를 사용하기 적절한 경우의 반대로 생각하시면 간단합니다.
Load Balancer는 모든 서버가 바쁘더라도 작업을 전달하게 됩니다.
서버에 무거운 작업이 전달될 경우 서버의 안정성을 보장하기가 힘듭니다.
대용량 처리 작업 같이 무거운 작업을 수행할 경우 Load Balancer가 적합하지 않습니다.
결론
소프트웨어 아키텍트 관점에서 서비스를 개선하기 위해 여러 방법들을 선택할 수 있습니다.
본 포스팅에서는 두 기술의 특성과 장단점을 파악하고 적재적소에 활용하는 관점을 제공하였습니다.