[소프트웨어 마에스트로] - 백엔드 아키텍처 설계

개요

백엔드 아키텍처를 설계하기 전 아래와 요구사항을 만족하는 아키텍처를 설계하는 것을 목표로 삼고 서버 구성도를 작성했습니다.

• 모든 데이터 전달은 유저 친화적이여야 한다.
• 트래픽이 높은 경우에도 서버는 동작해야한다.
• 데이터 보안을 유지하기 위한 적절한 접근 제어 및 암호화 기술을 도입한다.

보안

HTTPS

 

Plaintext 를 주고 받는 HTTP 통신의 단점을 보완하기 위해 VPC 외부의 클라이언트와 서버가 통신할때 HTTPS 프로토콜을 사용하여 통신 할 수 있도록 서버를 구성했습니다. HTTPS 프로토콜로 통신하기 위해서는 신뢰할수 있는 인증기관과 그 인증기관에서 발급한 키를 활용해야 합니다.

 

아마존을 CA 로 설정하고 아마존에서 인증서를 발급한 이후 클라이언트와 HTTPS 프로토콜 기반 통신을 수립했습니다.

AWS Security Group

아키텍처를 구성할 아래와 같이 당시 총 4개의 서버 그룹으로 구분했었습니다.

• API 서버: 클라이언트로부터 직접 요청 받음
• MongoDB 서버: API 서버에서 접근하여 데이터를 수정하고 조회함
• REDIS 서버: AI Inference pipeline 서버에서 접근하여 이벤트를 발행함
• 추천 서버: API 서버에서 접근하여 데이터를 전달 받음

각 서버와 주고 받는 트래픽은 VPC 내부에서만 전달되어야 했기 때문에 Security Group 으로 인바운드 트래픽 / 아웃바운드 트래픽을 제한하였습니다.

가용성

API 서버 가용성

Application Load Balancer

 

• API 서버의 트래픽이 높아져도 유연하게 늘리기 위해 AWS 의 Application Load Balancer 를 도입했습니다. 많은 LB 중 ALB 를 사용한 이유는 API 서버와 HTTP 프로토콜 기반 통신을 하기 위함입니다.

Auto Scaling Group

• ALB 에 연결시킬 Auto Scaling Group 을 사용했습니다. 당시 한정된 자원으로 서버를 운영환경에서 유지하기 위해 아래와 같이 최대로 가용가능한 서버 수를 지정했습니다.
  • minimum_size: 1
  • desired_size: 2
  • maximum_size: 4
• CloudWatch 에서 수집한 서버의 CPU 정보를 활용하여 동적으로 Scaling 할 수 있게 구현했습니다.
  • https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/as-scale-based-on-demand.html

데이터베이스 가용성

MongoDB 의 Replicaset 을 사용함으로써 데이터베이스 가용성을 보장했습니다. MongoDB Replicaset 은 두가지 방법으로 구성할 수 있었습니다.

1. Primary 와 Secondary 노드만 도입하여 투표기반으로 선출
2. Primary 와 Secondary 노드를 도입하고 투표는 Arbiter 노드가 책임짐으로써 자원 절약

MongoDB 에서 투표의 신뢰성을 높이려면 홀수개의 Available 한 노드들에서 투표가 이뤄지는데요 이때 한정된 금액으로 인프라를 구축했어야 했기 때문에 Secondary 노드를 많이 사용할 수 없었습니다. 그래서 2개의 Secondary 노드를 배치하고 Arbiter 로 부족한 투표수를 채움으로써 자원을 절약하고 투표의 신뢰성을 높임으로써 가용성을 확보하려고 했습니다.

유저 친화적 데이터 전달

문제점

유튜브 음원은 videoID 로 구분할 수 있습니다. 각 videoID 에 대한 코드 악보 변환 작업은 최초 요청시 평균 8~10초 정도소요되고 같은 videoID 에 대한 이후의 요청에서는 MongoDB 에 저장되어서 사용자에게 빠르게 응답을 줄 수 있었습니다. 하지만 최초 요청시 사용자가 진행 단계도 모르고 무작정 기다리는 것은 사용자 친화적이지 않다고 생각했습니다. 그래서 이벤트 기반으로 각 단계가 완료될때 클라이언트에게 상태정보를 전파하여 Progress 정도를 보여주는 것이 좋다고 생각했습니다.

만약 롤에 로딩창이 없었다면? ㅎㅎ

 

만약 롤에 아래와 같은 로딩창이 없었다면..?

기존에 API 서버는 악보 생성 요청을 메세지 큐로 전달하기 때문에 매개체를 통하여 완료 정도를 전달받을 필요가 생겼습니다. 이를 해결하기 위해 Redis 의 Publish, Subscribe 기능을 활용했습니다.

API 서버는 클라이언트와 SSE 기반 통신 연결을 수립하고 단계가 완료될때 마다 서버에서 클라이언트로 상태정보를 전송해주었습니다.