신한 해커톤이 끝나고 완성된 프로젝트에 신규 기능을 붙여서 확장하는 프로젝트를 시작하려고 한다. 이때 개발을 시작하기 위한 설계를 어떻게 하였는지 공유해보겠습니다.
초기
우리는 기존 해커톤 팀에서 3명이 추가투입 되어 기존 3인, 추가된 팀원 3인이 협업하는 구조로 시작했다.
그렇게 기존 완성된 어플에서 쇼핑몰 서비스와 주식 투자 서비스를 추가하여 개발하려고 하였고,
이 상황에서 기존 서버와 결합도를 낮춰 개발하고 싶었고, MSA구조로 각각의 DB와 서버를 통해 개발한 후 둘 다 연관된 트랜잭션에 SAGA 패턴을 적용해서 분산 트랜잭션을 적용하려고 하였습니다.
그렇게 이와같은 정말 큰 그림만 잡은 아키텍처를 그렸습니다.
기존 쏠쏠해영의 입출금 계좌 서비스와 증권 계좌 서비스를 분리하여 MSA 아키텍처를 구상했습니다.
하지만 kafka에 요청이 진입되는 부분이 틀렸고, GateWay와 SAGA 패턴을 위한 오케스트레이션을 어떻게 설정할 것인지 고민했습니다.
중기
많은 자료들을 찾아가면서 조금 더 구체화 된 인프라를 구축해보려고 했습니다.
EC2 두대에 서비스를 분리해서 담아주고 SAGA 오케스트레이터를 메인 서버에 담았습니다.
Kafka Cluster도 EC2-1 에 배포하여 두 서비스에서 에러가 발생했을 때 보상 거래를 담을 수 있도록 설계하였고 이 그림을 통해 컨설턴트님에게 피드백을 받았습니다.
받은 피드백
1. SAGA 오케스트레이터가 저기에 구현된다면 무거워 지고, Application 서버가 다운되었을 때 그럼 전부 다운되는 구조인 것 같다. 결합도가 높아진다.
2. GateWay를 달아줘서 Prefix를 통해 분기해서 결합도를 더욱 낮춰라
최종
많은 회의를 거치고 결국 EC2 한대에 docker를 여러대 띄워서 분리 운영 하는 것으로 설계하였다. 그리고 Nginx를 도입하였고, 리버스 프록시를 통해 요청이 한 곳에만 쌓이도록 설정하였다.
또한 오케스트레이터를 도입해서 보상거래를 담당할 수 있도록 처리하였고, 디버깅과 모니터링이 용이하도록 설계하였다.
추가로 현재는 오케스트레이터에서 보상거래가 아닌 정상 요청을 담당할 수 있도록 설정할 지, 정상 요청은 HTTP를 통해 동기 요청을 보낼 지 선택하는 과정이고 일단 동기적으로 요청을 보내고 예상치 못한 에러 발생 시에 오케스트레이터를 통해 보상거래를 할 수 있도록 진행하려고 합니다.
왜 MSA?
- 기존 모놀리식으로 구성된 완성되어 있는 서비스를 클라우드 환경에서 확장 가능한 어플리케이션으로 바꿔야 한다는 필요를 느낌 추후 디벨롭 과정에서 새로운 기능을 추가하기 수월하다.
- 새로운 팀원, 새로운 기능이 추가되는 상황에서 독립적인 개발을 통해서 개발 생산성을 향상시키고, 빠른 개발 및 배포가 가능하도록 한다.
- 또한 장애 격리가 되어 한 서비스에서 장애가 발생하더라도, 다른 서비스에 영향을 주지 않도록 설계하여 안정성 측면에서 굉장히 유리해진다.
왜 DB 분리?
- 각 서비스(팀)마다 원하는 DB의 특성이 다르다. 증권 계좌 서비스는 조회와 수정이 정말 많이 일어나기 때문에 전반적으로 안정적인 성능을 자랑하는 MySQL을 사용하고, 쇼핑몰 같이 수정보다는 조회 성능이 더욱 중요한 서비스에서는 조회 성능이 높은 DB를 사용하는 식으로 각각의 서비스에 최적화된 DB를 사용하고 싶었다.
- 또한 장애 격리를 통해 한 DB가 다운 되었을 때 모든 서비스가 다운되는 것을 막고 안정적인 운영을 가능하게 설계하였다.
정리
MSA 아키텍처를 적용해서 개발을 시작할 것이고, 더욱 현대화된 아키텍처를 도입할 것 같다.
이 많은 docker 컨테이너를 활용하면서 굉장히 많은 에러와 위기를 겪을 것 같은데 쿠버네티스를 사용해야 한다는 필요성을 느낄 수 있지 않을까? 하는 생각을 가지고 개발을 시작할 것 같습니다.
