[SWA/Structure] MSA(Micro Services Architecture) vs Monolih (단일체 아키텍쳐)

Software Architecture Patterns

시스템의 설계, 구조, 행동을 결정하는 일련의 설계 원칙과 같은 가이드라인의 집합이다. 이런 가이드라인은 시스템을 효율적으로 구성하고 유지보수 할 수 있도록 돕는다. 오늘은 이중 요즘 뜨고있는 MSA와 많이 쓰인다고 볼 수 있는 Monolithic에 대해서 알아보려고 한다.

---

1. Monolith Architecture

단일체 아키텍처라고 부른다.

모든 업무 로직을 하나의 코드베이스로 묶어서 서비스하는 방식이다.

즉 하나의 큰 단일 단위로 개발하고 배포하는 방식이다.

쇼핑몰을 예로 들자면 하나의 App에 쇼핑, 결제, 회원관리등 BusinessLogic, Data Access, User Interface모두가 한 App에 들어가 있다.

장점 

1. 하나의 코드 베이스에 모든 기능이 들어가 있기 때문에 구현이 비교적 간단해진다.
   -> 초반 개발 및 유지보수가 간편해진다.
2. 빠른 배포가 가능하다.
   -> 단일 단위로 배포됨으로 배포 프로세스가 단순화되어 빠른 배포가 가능하다.
3. 통합 용이성이 좋다.
   -> 모든 구성요소가 하나의 코드베이스에 있음으로 시스템의 모든 부분이 서로 상호 작용할 수 있다.
4. 성능 향상
   -> 기능이 단일 프로세스에서 동작해 통신에 사용되는 자원을 줄일 수 있다.
5. 테스트 용이성
   ->모든 테스트가 하나의 환경에서 이루어져 테스트 환경 유지 하는것이 간단해 진다.

이렇게만 보면 나쁜 것 하나 보이지 않는다. 근데왜 요즘 MSA가 대세로 가는 걸까?

단점

1. 확장성의 제한
   -> 모든 기능이 단일 단위로 묶여 있어서 톡정 부분만 확장하기 어렵다. 전체 시스템을 증가시켜야 하는 것이다.
   예를들어 어떤 라이브러리는 자바 17에서만 사용가능하고 어떤 라이브러리는 자바 21 에서만 사용가능할때 하나는 사용 못하는 것이다.
2. 복잡성의 증가
   -> 시스템이 커질수록 코드베이스가 거대해지니 복잡도가 증가해서 버그수정 기능 추가 빠른 배포가 가능할지 몰라도 배포하는 과정이 매우 복잡해진다. 이는 오류 발생 가능성을 증가시킨다.
3. 기술 스택의 제약
   -> 하나의 기술 스택으로 구축되기 때문에 새로운 기술 도입이나. 기존기술 업그레이드에 제약이 있다. 예를 들면 Spring만 사용해야해서 다른 인공지능 서비스 같이 python을 주로 이용하는 서비스를 넣기 까다로워 진다.
4. 유연성 부족
   -> 시스템의 기능이 변경되거나 확장되는 경우 전체 시스템을 수정해야 할 수도 있다. 이는 기능을 빠르게 반영하거나 새로운 기능을 실험하기 어렵게 한다.

이를 개선하기 위해서 나온것이 SOA라는것 서비스 지향 아키텍처라는 것이다. 이는 SOAP라는 무거운 통신방식을 사용하는데 이를 좀더 발전시킨것 REST API를 사용하는 방식이 MSA이다(REST API를 주로 사용한다는 것이지 다른 방식도 있다.). MSA에 대해서 알아보자

---

2. Micro Service Architecture

소규모의 독립적인 구성 요소로 구분해서 개발하는 방식이다.

Monolith방식은 전체 서비스의 연결관계를 다 이해해야 개발할 수 있었지만 서비스하는 단위 즉 모듈 단위로 분해해서 개발하기 떄문에 자신이 개발하는 부분만 이해해도 개발할 수 있다. 개인이 전체를 이해할 필요가 없다는 뜻이다.

 

장점 

1. 작은 코드 베이스
   -> 관리가 용이해진다.
2. 높은 확장성
   -> 부하가 많이 걸리는 서버만 성능을 증가시킨다던지 할 수 있다.
3. 기술의 다양성
   -> 어떤 서비스는 장고 어떤서비스는 스프링 어떤 서비스는 nodejs로 만들 수있다. REST API같은 통신방식만 맞추면 된다.
4. 결함을 고립해서 전체 시스템 다운을 방지할 수 있다.
   -> 쇼핑서버에 디도스 공격을 당해도 결제 서버와 회원관리 서버는 살아남을 수 있다.
5. 독립적인 배포가 가능하다.
   -> 한 서비스를 업데이트했다고 모든 서비스를 같이 배포할 필요없이 업데이트한 서비스만 다시 배포하면 된다.

단일 단위 개발의 단점들을 많이 보환하고 있는 모습이다. 안정성과 애자일리티에 집중할 수 있다는 것이 가장 큰 장점이다. 

단점

1. 디버깅 추적이 어렵다.
   -> 분산 환경이라 다른 디버깅 추적을 하려면 다른 코드베이슬 봐야 할 수도 있다.
2.  CI/CD가 중요해진다.
   ->특정 서비스는 다른 서비스랑 통신을 하게 되는데 이런 연결 고리 때문에 개발과 배포 방법이 중요해진다.
   
3. 통신 비용 증가.
   ->서비스끼리 통신할때 API등을 사용해야하기 때문에 비용이 증가한다.

이런 방식때문에 모노리식 아키텍처에 비해서 알아야하는 기술 스택도 증가한다.

 

해결 해야하는 것

'->' 는 예시이다

• 다수의 필요한 서비스를 어떻게 찾아야 하는가?
  -> 서비스 디스커버리
• 사용하기 위한 다수 서비스의 인스턴스를 어떻게 결정해야 하는가?
  -> 클라이언트-사이드 로드 벨런싱
• 개별적인 서비스가 응답하지 않을 때 어떤 일이 발생하는가
  -> 결함허용
• 보안, 속도제한과 같은 서비스 접근을 어떻게 제어하는가?
  -> 서비스 보안
• 다수의 서비스는 서로 어떻게 커뮤니케이션 하는가?
  -> HTTP/메세징
• 서비스간 ACID는 어떻게 달성하는가?
  -> CQRS

---

3. 정리

특징	Mololith	Micro Service
구조	하나의 단일 단위	작고 독립적인 서비스들의 집합
개발 및 배포	단일 코드베이스, 단일 단위로 배포	각각의 서비스는 독립적으로 개발, 배포
통신	내부 함수 호출 또는 모듈 간 직접 호출	주로 HTTP를 통한 RESTful API호출
데이터 관리	단일 데이터 베이스	단일일 수도 있고 독립적인 데이터베이스 일수도 있다.
확장성	전체 시스템을 단일 단위로 확장	각 서비스는 독립적으로 확장 가능
기술 다양성	모든 기능이 동일한 기능 스택 사용	각 서비스는 서로 다른 기술 스택 사용 가능
변경 관리	한번에 전체 시스템 변경	각 서비스 독립적 번경 가능
운영 복잡성 (시스템 운영 작업양과 복잡성)	단일 단위로 운영 및 관리	각 서비스 독립적 운영 및 관리
유연성	변경이 어려울 수 있음	변경 및 확장이 쉬움
신뢰성 및 오류 격리	한 부분의 오류가 전체 시스템에 영향	서비스 간의 느슨한 결합으로 인한 오류 격리
개발 및 배포의 간편성	빠르고 간편한 개발 및 배포	더 복잡한 개발 및 배포 프로세스
모노리식 아키텍처에 대한 지식 집중	개발자들은 하나의 코드베이스에 집중해서 시스템 이해	서비스간의 상호 작용같은 복잡성에 집중해야함
운영 난이도 (기술적 및 조직적인 어려움)	단일 서비스로 운영 및 관리	서비스간 통신 동기화 문제 해결등으로 인한 난이도 증가
성능 향상	내부 통신 오버헤드 적음	분산 시스템의 오버헤드 존재
강력한 일관성	하나의 코드베이스로 인한 일관성	서비스 간의 일관성 유지 어려움

 

지금까지 항상 Waterfall 방식으로 mololith 아키텍처만 하다가, Agile 방식으로 개발할때 MSA가 편하다고 해서 사용해 보려고한다. 요즘들어 구현만이 아닌 설계도 중요하다는 것을 느끼고 있다.