[Side Project] MSA 이해하기, 코인 자산 관리 시스템

https://fearless-hardboard-bd6.notion.site/Document-26266e6d385d4ee19e024644ec4cb0be

 

코인사조 Document

프로젝트 주제

fearless-hardboard-bd6.notion.site

 

[AWS Architecture]

MSA 인사이트를 얻을 목적으로 시작한 사이드프로젝트 후기를 작성합니다.
주제는 코인 자산 관리 시스템(~ 다양한 거래소의 코인을 모아서 보여주는 앱)을 간단하게 만들어보기로 했고
프론트 1명, 백엔드 3명이서 작업을 진행했으며, 백엔드 영역에서 커뮤니티 도메인과 자산 도메인의 일부를 담당했습니다.

첫 3주 동안은 EDA(Event Driven Architecture), DDD(Domain Driven Development) 등에 에 대해 빠르게 학습했고,
후 3주동안은 프로젝트 기획 및 구현작업을 했습니다.
3주라는 제한된 시간과 각자의 그동안 업무 경험치를 기준으로 그리고 모두가 직장인인지라
퇴근 후 프로젝트 작업을 한다는 가정 아래에 구현범위를 최대한 축소했고, MSA를 이해하는 데에 초점을 맞추기로 했습니다.

[ DB - Mysql RDS ]
원래 DB는 도메인별로 따로 구축하는게 이상적인 MSA의 DB이지만,
DB는 하나로 구축하고 도메인별로 데이터베이스를 나눠 분산DB로 MSA형태를 가져가기로 했습니다.

[ AWS Architecture ]

계획           -->         결과


아키테쳐 구성시에는 VPC, ec2 분산, Route53 등도 빼버리고, 최소한의 인스턴스로 아키테쳐를 구성하여 진행했습니다.
도메인 단위로 EC2 서버를 구성하고, gateway, s3, 람다 인스턴스로 아키테쳐 구성을 했으나
구현 진행시에는 API gateway를 Spring Cloud의 Eureka로 대체( gateway에 JWT 인증필터 구현 )했고, S3를 아키테쳐에서 제거했습니다.
AWS 안에서 작업을 진행해보니, 인스턴스를 자유롭게 설치하고 설정이 가능하여 구현의 방향을 빠르게 수정할 수 있는 점이 매우 큰 장점이었습니다.

[ 기술스택 ]
기술스택은 백엔드는 spring, webflux를 주로 사용함으로 MVC패턴이 아닌 flux패턴을 학습겸 진행하기로 했습니다.
webflux는 비동기, 논블로킹으로 동작을 하기 때문에 분산처리 작업에 탁월하고, 장애시에도 일관된 패턴으로 동작하여, 최근 규모가 커지고 있는 서비스들에 많이 도입되고 있는 것으로 알고 있습니다. 블로킹 방식의 JDBC에 적응되어있기에 논블로킹 방식 구현이 익숙하지 않았고 레퍼런스도 MVC 대비 적어 구현에 어려움을 겪었습니다.

[MSA 느낀점.. ]
MSA 형태로 구현을 진행하며, 몇 가지 느낀 점이 있다면
1. 기존의 모놀리스 구조에서 트랜잭션 단위로 작동했던 기능들이 도메인이 쪼개짐에 따라, 롤백과 같은 작업을 코드의 형태로 구현할 필요가 있어 작업량이 크게 증가한다는 부분입니다.

2. 여러개의 인스턴스 단위로 서비스가 동작하기 때문에, 수동으로 배포를 진행한다면 더 많은 리소스가 들어가게 되고, MSA를 위해서는 도커, 쿠버네티스를 포함한 배포자동화가가 거의 필수처럼 필요해집니다.

3. 트래픽이 몰릴 시 클라우드상에서 클릭만으로 서버를 Scale out할 수 있다는 점이 MSA 구조에서 큰 이점으로 작용하지만, 물리적 서버를 두는 On-promise의 경우 실제로 새로운 서버가 도착하는 데에 한 달이 넘는 시간이 걸리기에 MSA가 적합한 아키테쳐 구조가 아닐 수 있다는 점입니다.

4. 서비스가 쪼개져있어, 로그를 잘 작성해야 어디서 에러가 나는지, 어떤 이벤트가 발생하는 지 추적이 용이함으로 로그를 남기는데에도 리소스를 충분히 투입시켜야 합니다.

5. MSA 구현시 개발이 복잡해지고, 운영 숙련도가 필요해지고, 배포가 복잡해지고, 통합테스트가 어려워지는 등 MSA의 한계를 극복하기 위해 EDA란 개념이 나왔으며, Kafka와 같은 메시지큐에 Producer가 Event를 만들어서 Event Bus에 발행하면 Event 소비하는 서비스(Consumer)가 필요한 Event를 가져다 사용하는 구조입니다. 



앞으로의 계획!
 -
현재 프로젝트가 종료되었지만, 도메인 별로 구성된 현재 EC2 서버는 활용할 수 있는 것들이 많을 것으로 판단되어
작업된 내용을 바탕으로 1) AWS의 인프라(route53, nginx 등)을 추가로 적용!, 2) 배포 자동화를 추가!하고 구현이
3) 미완료된 자산 부분을 구현 할 예정 입니다.

https://github.com/coinbuying/backend

 

GitHub - coinbuying/backend

Contribute to coinbuying/backend development by creating an account on GitHub.

github.com

 

참고 자료)

https://abbo.tistory.com/98

 

Spring 5와 WebFlux

Author: 니용 Spring MVC는 다들 알고 계실겁니다. Model-View-Controller의 기본 웹 코드 작성기법이며, 대부분 MVC 패턴이라고 알고 계신 분들도 많으실 거에요. MVC는 Servlet을 기반으로 작성된 하나의 템플.

abbo.tistory.com

 

https://happycloud-lee.tistory.com/154

 

마이크로서비스 패턴: 핵심패턴만 빠르게 이해하기

크리스 리처드슨의 '마이크로서비스 패턴'에 나오는 44가지 패턴 중 핵심 패턴인 Saga. Event sourcing, API composition, CRQS, External API, Transactional Outbox/Polling publisher/Transaction Log tailing..

happycloud-lee.tistory.com

 

https://azderica.github.io/01-architecture-msa/

 

[Architecture] MSA : SAGA 패턴이란 - Azderica

[Architecture] MSA : SAGA 패턴이란 Posted 22. December 2020. 7 min read. MSA : SAGA 패턴의 정의과 종류 이전에 MSA 개념에 대해 잡아보았습니다. 오늘은 MSA를 듣다보면 꼭 듣게 되는 SAGA 패턴에 대해 공부해보겠

azderica.github.io

https://velog.io/@vies00/Circuit-Breaker-Pattern

 

[프로그래밍 패턴] Circuit Breaker 패턴

Circuit Breaker가 왜 필요한가 외부 API 호출과 같은 remote call시, 호출 실패나 hang 등을 고려하지 않을 수 없습니다. 일시적이고 단발성인 오류는 적절히 timeout을 주고 오류를 try-catch 하면 되지만, 오

velog.io

 

댓글

Designed by JB FACTORY