[신투 프디아] 파이널 프로젝트 - MSA 인프라 설계 의도 회고

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

MSA 인프라 설계 의도 회고

이번 프로젝트에서 처음으로 인프라 아키텍처 설계를 직접 맡아봤다. 금융 서비스에 맞게 보안과 안정성을 챙겨야 한다고 생각했다. 한 달이라는 제한된 시간 안에서 가능한 수준도 고려했다. 괜히 보여주기식으로 잘게 나누기보다는 각 선택에 타당한 이유가 있도록 신경 썼다.

 

 

AND 아키텍처

 

신경 쓴 포인트는 다음과 같다.

 

 

보안과 네트워크 분리

Public Subnet에는 외부 접근이 필요한 리소스만 배치하도록 했다.

• Gateway EC2 : 외부 사용자 요청을 받아서 내부 서비스로 라우팅하는 용도
• RabbitMQ : Gateway와 내부 모듈 간에 메시지 전달 브로커
• Data-Collect : 외부 API와 통신
• Jenkins : CI/CD 관리 서버, GitHub와 연동하여 배포 자동화 담당

Private Subnet에는 핵심 비즈니스 로직과 데이터 저장소를 배치하도록 했다.

• Process, Alert, Trade, User 모듈 : 핵심 비즈니스 로직
• MySQL, Redis : 민김한 데이터 저장소는 외부에서 직접 접근할 수 없도록 또 나눠둠.(Private Subnet에 있는 비즈니스 모듈로만 접속 가능)

이렇게 함으로써 외부 노출을 최소화하고 내부 데이터를 보호하도록 했다.

 

 

 

모듈화 책임 분리

모듈을 분리함으로써 각 기능이 독립적으로 배포되게 하여 하나가 죽어도 다른 서비스들은 살 수 있도록 했다.

• Data-Collect : 외부 데이터를 수집 (지표 데이터, ai 연동)
• Data-Process : 수집된 데이터를 가공/분석하여 저장
• Alert + User : 사용자 조건에 맞는 알림 실행
• Trade + User : 사용자 조건에 맞는 자동매매 실행

 

데이터 저장소 이원화

MySQL은 안정성과 트랜잭션 보장에 초점을 두고, Redis에는 빠른 조회나 갱신이 필요한 데이터들을 캐싱할 수 있도록 했다.

• MySQL: 영속 데이터 저장
• Redis : 휘발성/실시간 상태 저장

 

클라이언트 흐름

User → Phone → Internet Gateway → Gateway EC2

• 외부 사용자는 Gateway EC2 까지만 접근 가능
• 이후 로직은 RabbitMQ + Private Subnet의 내부 서비스가 처리

 

RabbitMQ를 Public Subnet에 둔 이유

private에 두면 관리하기 어렵기 때문에 Public에 둬서 관리 부담을 줄입

 

Public Subnet을 2개로 둔 이유

• 첫 번째 Public Subnet: Gateway, RabbitMQ, Jenkins → 서비스 접근/운영 관문
• 두 번째 Public Subnet: Data-Collect → 외부 API 통신 전용

보안 정책 적용을 다르게 하기 위해

• 예: Subnet1은 80/443, 8086, 8085 같은 게이트웨이/브로커 포트만 열고
• Subnet2는 외부 API 호출만 허용

 

 

데이터 수집은 FastAPI, 나머지는 Spring 으로 하는 이유

데이터 수집에 FastAPI를 쓴 이유

• 데이터 수집 모듈은 주식 시세, 외부 API 등 I/O 중심의 작업이 많은데 FastAPI는 Python 기반이라 비동기 I/O에 강하고, 데이터 파싱/처리용 라이브러리도 바로 쓸 수 있어서 유리하다.
• FastAPI는 코드 변경 -> 테스트 -> 배포 사이클이 가벼워서 외부 API 스펙이 바뀌더라도 변화에 빠르게 대응할 수 있다.

나머지는 Spring을 선택한 이유

• 핵심 비즈니스 로직은 안정적인 트랜잭션, 보안, 세션 관리가 중요해서 Java + Spring Boot의 생태계를 활용하고 싶었다.
• 팀 내에도 Spring 기반 개발자가 많아서 협업과 유지보수에 용이하다고 생각했다.

 

MySQL을 서비스마다 분리하지 않고 하나로 둔 이유

• 프로젝트 기간과 인원이 제한적이라 DB를 서비스마다 따로 두면 관리 비용이 커지기 때문에 운영을 수월하게 하기 위해 선택했다.
• 실제 대규모 금융 서비스라면 서비스별 DB분리를 적용할 수 있겠지만 이번 프로젝트는 단일 DB에서 스키마로 나누는 게 데이터 정합성을 쉽게 맞출 수 있고 합리적이라고 생각했다.

 

 

 

예전에 클라우드 시간에 신투 현업 세션에서 아키텍처를 봤을 때는 그냥 ‘저렇게 하는구나’ 하고 넘어갔는데, 직접 설계를 맡아보니 왜 그렇게 구성했는지 더 잘 이해할 수 있었다. 이번 프로젝트는 작은 규모였지만, 실제 금융 서비스라면 단순한 모듈 분리 외에도 장애 대응 체계와 모니터링까지 포함되어야 한다는 걸 느꼈다. 그리고 나중에는 쿠버네티스라던지 DB를 더 분리해본다던지 하는 고도화도 적용해보고싶다!