MSA (Microservice Architecture)는 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일이다. 각 서비스는 특정 비지니스 기능을 수행하며, 서로 독립적으로 배포되고 확장될 수 있다.

 

Monolithic Architecture는 하나의 큰 코드베이스로 구성된 애플리케이션으로 모든 기능이 하나의 애플리케이션 내에 포함된다. 이로인해 배포가 단순하고 하나의 DB를 사용해 데이터 일관성을 쉽게 유지할 수 있다. 하지만 특정 기능을 확장하려면 전체를 확장해야 하므로 확장성이 부족한다. 비슷한 맥락으로 작은 변경 사항에도 전체를 다시 배포해야한다.  또한 새로운 기술 도입이 어렵고 특정 모듈에 종속적이다.

 

MSA 는 모놀리틱의 대표적인 단점들을 극복해 특정 서비스만 확장하여 성능을 최적화할 수 있고 개별 서비스의 변경 사항을 독립적으로 배포할 수 있다. 또한 서비스 별로 적합한 기술 스택을 선택할 수 있다. 하지만 장점만 있지는 않다. 여러개의 서비스로 나눈만큼 서비스 간 통신, 데이터 일관성 유지, 트랜잭션 관리등의 복잡성이 증가한다. 추가로 그에대한 모니터링, 로깅, 장애 대응 등을 개별적으로 관리해야 하므로 운영 비용이 증가한다. DB또한 분산되어 있어 데이터 일관성 유지가 어려울 수 있다. 각 서비스 간의 통신이 네트워크를 통해 이루어지므로 지연 시간이 발생할 수 있다.

 

언뜻 보기엔 MSA로 개발하는게 무조건 좋다는것 처럼 보이기도 한다. 하지만 개발엔 정답이 없다. 프로젝트의 방향에 따라 개발의 크기, 기능의 구성 등 정말 다양한 사항들이 결정된다. 앞으로 입사할 회사들의 개발된 레거시의 구조, 신규 프로젝트에서의 합의된 구조를 잘 파악하고 따라 가는것이 중요하다. 그래야 유지보수도 수월할 것이고 추가 투입 인원이 있다면 수월하게 진입할 수 있다.

 

특히 MSA는 너무 많은 것들이 사용되며, 정책 설정을 해야 할 것이 많다. 빠르게 프로젝트의 프로토 타입을 만들어야 한다면 모놀리틱 아키텍쳐를 사용하고, 후에 부분부분 전환하는 것도 방법이다.

 

저번 면접시에 받았던 질문이 있다. 우리회사엔 레거시가 좀 많은데 레거시에 대해서 어떻게 생각하는지? 였다.

이에대한 대답중 하나로 기존 레거시가 최신기술 혹은 내가알고있는 패턴과 많이 다르다고해서 레거시를 최신기술로 변경한다거나 하는것은 오히려 안좋을 수 있다. 기존의 있는 패턴을 최대한 유지해야한다고 생각한다. 그 이유는 만약 내가 변경하려는 프로젝트는 다른 누군가가 같은 프로젝트를 보고있다면 갑자기 2개의 패턴이 되버리는 것이다. 그리고 또 다른 누군가가 2개가 되버린 패턴을 보고 혼동이 와서 다른 패턴으로 개발을 시작해버린다면 3개가 되버리는것이다. 

 

만약 내가 기존의 프로젝트에 투입되게 된다면 기존 코드의 'CRUD Search'를 한번 샘플로 만들어보는것이다. 이처럼 기존 프로젝트를 파악할 때 CRUD관점으로  파악하면 좀더 쉬울 수 있다. Restful한 API라면 이미CRUD로 되어있을것이고 Restful 하지 않은 API라도 Restful하게 CRUD관점에서 보는게 더 파악하기 쉽다.

 

'TIL' 카테고리의 다른 글

Spring Security의 @AuthenticationPrincipal 이해하기  (0) 2025.02.25
restdocs  (0) 2025.02.20
n+1을 해결하는 여러가지 방식의 장단점  (0) 2025.02.19
data.sql을 활용한 초기 데이터 설정  (0) 2025.02.14
Github Project & Issue  (0) 2025.02.13

+ Recent posts