MSA의 등장 [ Micro Service Architecture ]

모놀리식 아키텍처와 SOA( Service Oriented Architecture )

- 처음 소프트웨어 아키텍처의 시작은 모놀리식 이다.

- 그리고 여기서 오는 고통들과 제한적인 환경에서나마 해결하고자 했던 노력에서 나온 아키텍처가 SOA이다.

MSA가 나오기 전의 아키텍처..

모놀리식

- 하나의 어플리케이션이 하나의 서버에 배포

- 단일 코드베이스

- 싱글/멀티 모듈 방식으로 개발은 가능하지만, 근본적으로 하나의 프로세스

SOA

- "서비스" 단위로 개발하고, 서비스 간 규격화된 프로토콜(인터페이스)를 사용하여 통신

- 대개 동일한 기술 스택들을 가지고 서비스들을 개발하며, 각 서비스들간이 재사용이 목적

- ESB(Enterprise Service Bus) 라는 개념을 통해, 요청에 대해 어떤 서비스들을 호출할 지 캡슐화 된 Layer 존재

- 서비스 간 통합을 강조 

모놀리식 아키텍처와 SOA( Service Oriented Architecture )

공통점

- Shared DB 사용

- 대개 원 코드베이스

- 모듈/서비스 간 규격화된 호출 방식 사용( 서비스 간 통합 관점 )

  - > 모듈/서비스 간 강한 의존성, 결합도

SOA 만의 특징, 차이점

- 독립적으로 배포 가능

- 비지니스 로직에 따라, 어떤 서비스를 호출할 지 결정하는 Layer 존재

- 트랜잭션 구현은 별개로 해야 한다

- ESB의 관리 ( Integration of Monolithic )

  - > MSA 의 원칙을 정면으로 반박

- 동일 플랫폼( e.g JVM 환경 ) 에서 서비스 간 호출을 하다보니, 성능 이슈 존재

 

SOA 와 MSA

공통점

- 개발의 단위를 "서비스"로 인지

- 다른 서비스와 독립적으로 개발, 배포 가능

 

MSA 만의 특징, 차이점

- 비즈니스 로직(서비스)의 재사용 지양

   - 서비스 간 결합도를 낮추는 것이 목표

- 낮은 결합도로 변화에 애자일한 대응 가능

- 각 서비스는 각 서비스의 특성에 맞는 최적의 기술스택을 독립적으로 선택 가능

- 서비스 간 자유로운 방식으로 통신 가능

   - HTTP, gRPG, ..

MSA 의 등장

모놀리식과 SOA 의 문제점

- 협업, 커뮤니케이션, 확장성, 유연성, 결합도, 응집도, 빌드와 배포..

   - 하나의 앱 안에서 여러개의 서비스가 있기 때문에 단 한줄의 코드가 수정돼도 앱 전체가 배포되어 빌드와 배포가 오래걸린다

요구사항 변화에 따른 빠른 대처
Business Capa

MSA의 개발방법

- 이러한 모놀리식 환경에서는 비교적 필요성이 크지 않았던 것들을 MSA환경에서는 꼭 필요하게 되었다.

   - > CI/CD Pipeline, Automation, API Gateway.. 등등

 

결론

Monolithic 대비 MSA가 어렵고 복잡하지만 과거에는 어렵고 복잡한 것을 해결해 줄 수단들이 부족하였지만 기술의 발전에 따라 MSA로 인한 고통보다 MSA로 인한 이점이 커지게 되면서 MSA를 사용하게 됐다