MSA구조에 맞는 인프라를 설계해보자!

이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다.

 

 

 

 

 

 

이번 프로젝트는 MSA 구조로 설계하여 진행하는 프로젝트이기때문에 인프라가 무엇보다도 중요하다.

근데 내가 인프라를 담당해버렸다,,,, 인프라를 많이 안해봐서 이번에 해보려고 하겠다 한거인데 생각보다 엄청 중요한 역할을 맡게된 기분... 
그치만 이걸 해내면 많은걸 배워갈 수 있을거 같다.

 

 

 

 

 

 

 

 

일단 우리가 설계한 아키텍처구조도는 이렇다 

모듈별 역할 정리

alert-module

• 사용자 알림 조건 판별
• 조건 충족 시 알림 발송 서비스 호출
• 알림 히스토리 저장

data-process-module

• 수집된 원본 데이터를 정제하고 저장소에 반영
• 지표 계산 (SMA, RSI, 볼린저밴드)
• Redis, MySQL 업데이트

trade-module

• 사용자 자동매매 조건 판별
• 조건 충족 시 자동매매

user-module

• 사용자 인증인가
• 계좌 관리

data-collect-module

• 1분 단위 1일 단위 시세 데이터 수집
• 수집한 데이터를 data-process-module로 전달
• OpenAI랑 연결해서 데이터 가져오기

 

각자 역할에 따라 나누고 public과 private가 되어야할 애들도 나누었다. 그 결과 ec2를 7개 만들어야 하는 상황이 되었다.

 

 

그래서 이 부분을 어떻게 해결해야할까 알아본 결과 이렇게 3가지 후보가 나왔다.

 

MSA를 구현하기 위한 후보군

1. 7개의 ec2를 두어 ec2 별로 분리
   • 장점: 장애 안정성이 확실하게 보장됨, 하나의 ec2가 죽어도 다른 서비스는 잘 작동
   • 단점: 비용이 너무 많이 들고, 관리가 힘들다
2. 2~3개의 EC2를 두고 다시 이 안에서 docker로 분리
   • 장점: 어느정도 분리하여 안정성을 고려하면서 관리가 용이, 비용이 7개두는거보다 저렴
   • 단점: ec2 하나가 죽으면 같이 죽는 서비스가 발생함
3. 1개의 EC2를 두고 그 안에서 쿠버네티스와 도커를 활용하여 분리

 

 

 

 

 

이 중에 2번을 하려다가 1번을 하기로 선택했다.

 

이유는 다음과 같다

일단 ec2를 7개 만들었을 때 가장 걱정했던 부분은 비용이였는데 일단 우리가 진행하는 프로젝트 기간, 서비스의 규모를 생각했을 때 예산안을 초과하지 않는다는 판단이 들었고 현재 아키텍처 설계도에서 합치고자 하였을 때 성격이 너무 다른 것들이 합쳐지는 결과가 생기게 된다.

 

이렇게 되면 MSA구조 설계라는 목적에 어긋나는 설계를 하게될 것 같아서 MSA라는 목적에 가장 적합한 1번의 형태로 설계하기로 했다.

 

 

또한 고민했던 부분이 DB도 분리해서 설계해야할 지 여부였는데 고민 끝에 이 부분은 분리하지 않기로 하였다.

왜냐하면 우리가 설계한 DB는 테이블간에 서로 조인이 필요한 경우가 많은데 이를 분리하게 될 경우에는 통신을 너무 많이 해야돼서 빠르게 정보를 조회하지 못할 것 같아서 분리하지 않기로 결정하였다.

 

 

 

 

 

Jenkins를 활용한 CI/CD 구축, 7개의 EC2 관리, RDS, Redis 까지 많은 난관이 예상되는 프로젝트이지만 이번 기회에 많은 걸 배워 갈 수 있을 거 같다.