[211일차]microservice architecture VS monolithic architecture

Reference

전통의 소프트웨어 아키텍처 모델 - 모놀리식(Monolithic) 아키텍처 - Jins' Dev Inside
마이크로 서비스와 모놀리식 서비스 아키텍쳐 - IT's me
모놀리식 아키텍처와 마이크로 서비스 아키텍처의 장점과 단점
마이크로서비스란? - Red Hat

microservice architecture vs monolithic architecture

monolithic architecture

모놀리식 아키텍쳐란 하나의 프로젝트에 대해 하나의 어플리케이션만 대응되어 있는 것이다.
프로젝트의 어떤기능이던 하나의 어플리케이션과 상응하고 있다는것이다.
마이크로 서비스 아키텍쳐가 각광받는 시점에서 단지 하나의 앱만 상응한다고 했을 때
단점이 많아 보이지만 이 또한 몇가지 장점을 가지고 있다.

• 초기 개발에 용이
  초기 개발단계에서는 아키텍쳐가 간단하기 때문에 빠른 구현을 위해서
  설계를 위해 머리를 깊게 쓸 필요가 없다.
• End-to-End 테스트가 용이
  e2e테스트는 기능별로 코드를 테스트 하는 것이다.
  앞서 말했든 하나의 어플리케이션만 있기에 전체적인기능을 한번에 테스트할 수 있다.
• 쉽게 고가용성 서버 환경을 만들 수 있다.
  하나의 어플리케이션만 갖고있기 때문에 로드밸런싱을 통해 애플리케이션을 하나더 만들거나
  줄이기 용이하다.

그러나 프로젝트 규모가 커짐에 따라 단점이 많아지는데

• 코드관리가 어렵다
  많은 양의 코드가 한번에 몰려있어 옛날코드는 정말 예전작성자만 알아보는 경우가 생긴다.
• 빌드, 배포시간이 길어짐
  조그만한 수정사항이 생기더라도 코드 전체를 빌드하고 배포하게 된다.
• 테스트 시간 길어짐
  앱하나에 많은 코드가 들어가다 보니 테스트자체에도 시간이 많이 소모된다.
• 다른 언어를 사용하기 힘듬
  하나의 앱환경이기 때문에 php프로젝트는 php만 활용해서 코드를 작성해야하고,
  java는 java를활용해서 프로젝트를 진행해야한다.

microservice architecture

모놀리식 아키텍쳐의 한계에대한 해결책으로 나온것은 바로
마이크로 서비스 아키텍처이다.
하나의 어플리케이션을 서비스단위로 작게나눈다.
쇼핑몰을 예로들면 상품db와 상품을 조회하는 API어플리케이션을 따로 만들고,
상품 결제내역db와 결제를 수행하는 API어플리케이션을 따로 두어 각각의 API형태로 제공한다.
부분적인 서비스가 고장나더라도, 이상이 없는 서비스는 정상작동한다.
이 외에도 여러 장점을 포함하고 있는데,

• 서비스별로 집중해서 개발가능
  각각의 다른 API를 가지고 있기 때문에 각 서비스별로 팀을 나눠서 개발 할 수도 있다.
• 수정 및 유지보수가 쉬워진다.
  각 서비스를 담당하는 API가 철저히 분리되어 있기 때문에 코드에 접근이 용이하다.
• 서비스별 독립적인 배포 확장이 가능
  한가지 기능에 수정이 있을 경우 전체코드를 빌드 배포해야되는 모놀리식과 달리,
  서비스를 담당하는 부분이 분리되어있기 때문에 수정을 하더라도 빌드와 배포에 무리가없다.
• 서비스에 맞는 스택을 결정할 수 있다.
  요청량에 따라서 요청의 성질에따라 유리한 스택을 선택해서 서비스의 API를 각각 만들 수 있다.

그렇다고 무조건 나눈다고 전부 능사일까?
규모가 그리 크지않다면 굳이 나눌 필요가 없다. 또 무작정 분산 했을 땐 어떤 문제점을 안고갈까?

• 서비스간 통신방법을 고려해야된다.
  각각의 다른 기능을 한다지만, 리소스의 상태등을 공유해야될 일이 발생한다.
  그럴 때 어떻게 상호 통신을 해서 상태를 공유할 지 고려해봐야한다.
• 데이터 중복이 발생할 수 있다.
  각각의 db를 갖고있기 때문에 낭비되는 리소스가 있을 수도 있다.
  예를들면 회원정보를 삭제 했을 때 그 회원의 결제내역은 남는 경우가 발생하기 때문
• 배포구조가 복잡해짐
  각각 따로 배포해서 장점도 가지지만 그만큼 복잡한 구조를 통해 배포를 해야된다는 단점도 안고가야한다.