AWS Lambda - SQS를 활용한 인프라 아키텍처 재설계 ( + S3, 맥미니?)

1. 갖고 있던 문제

자세히 말할 수는 없지만 회사에 그래픽카드가 필요한 컨버팅 서버가 있었다. 해당 서버는 AWS EC2에서 그래픽 카드가 있는 맥서버로 배포되어 있었는데 큰 문제가 있었다. 바로 월 100만 원가량의 비싼 비용과 트래픽에 취약하다는 문제였다.

 

해당 서버를 배포한 동료직원의 얘기를 들어보면 컨버팅에 필요한 프로그램을 돌리는데 필요한 최소조건의 서버를 빌렸다고 했기 때문에 사양을 낮춰서 금액을 줄이는 방법은 사용할 수가 없었다.

그리고 http통신으로 컨버팅에 필요한 정보를 받아오는 구조였는데 트래픽에 대한 대비가 전혀 없어 위험했고, 오토스케일링으로 스케일 아웃을 적용하려고 해도 비싼 비용이 너무 부담되는 상황이었다.

---

2. 인프라 아키텍처 재설계

회사에서도 해당 서버 비용에 대한 부담이 심해 결국 AWS EC2을 내리고 회사내부에 맥미니를 구비해 컨버팅용 서버로 사용하기로 결정했다. (윈도우 서버도 선택지에 있었지만 컨버팅 프로그램을 윈도 환경에서 돌리기는 어렵다는 판단에 맥미니를 구입했다고 들었다.)

 

일단 맥미니 3대를 구입해서 사용하게 되면 위에 비싼 서버비용이 주기적으로 나가는 문제는 해결되지만 실제 물리적인 서버는 복구하기 위한 절대적인 시간이 필요하기 때문에 트래픽에 대해서는 더 큰 문제였다.

 

일단 백엔드 팀에서 맥미니를 인계받고 기본적인 세팅을 하면서 인프라 아키텍처에 대한 설계를 다시 하기로 결정했다. 먼저 수동적으로 요청을 받는(http통신) 서버에서 능동적으로 자기가 필요한 만큼만 가져올 수 있는 SQS를 도입하기로 했다. 또한 서버에 부담을 최대한 줄이기 위해 컨버팅에 필요한 값들은 presigned url을 통해 클라이언트 쪽에서 S3에 직접 올리게 구성했고, 해당 S3 업로드를 트리거로 사용해 Lambda에서 최대한의 데이터를 파싱 하기로 결정했다. 파싱 된 데이터는 Lambda에서 바로 SQS로 집어넣고 맥미니가 해당 SQS를 바라보다가 큐들을 하나씩 컨슘에 컨버팅 하는 인프라였다.

 

변경한 인프라 아키텍처 구조

 

SQS나 Lambda는 대용량 트래픽에도 안정적인 서비스를 유지할 수 있기 때문에 이전보단 더 안정적인 서버가 됐다고 생각한다.
(먼저 여기서 구현한 SQS는 컨버팅 데이터의 경우 순서가 정확히 지켜지지 않아도 큰 문제가 없어서 FIFO 방식을 사용하지 않았다. )

 

하지만 아직 다른 문제점들이 있어 앞으로 하나하나 보완해 나갈 예정이다.

---

3. 남은 문제점들

Dead Letter Queue라던지 컨버팅에 대한 모니터링과 같은 세팅들은 아직 남은 문제점들이다. 당장에 큰 문제없이 서버 사용이 가능하겠지만 나중에 어떤 문제가 생길지 모르기 때문에 하나하나 보완해 가야겠다.