MSA 란 무엇일까


기존의 모놀리식 구조와 비교하며 이해하면 MSA의 이해가 편합니다.

  • 모놀리식 : 모든 기능이 다 들어 있는 하나의 애플리케이션
  • MSA : 각 기능별로 애플리케이션을 만들어 여러개의 애플리케이션을 모아 놓은 구조

그렇다면 왜 모놀리식 구조에서 MSA 구조로 바꾸려하는 것일까?

하나의 애플리케이션에는 여러 기능들이 복합적이고 유기적으로 연결되어 있기 때문에 하나의 기능을 수정하더라도 내부적으로 어떻게 서로가 연결되어 있어 영향을 끼칠 수 있을지 가늠하기가 어려워 전체 테스트를 해야하는 번거로움이 있다.
따라서 100가지 기능 중 1가지 기능만 업데이트 하더라도 100가지 기능을 전체 테스트 해야하는 업무 과중이 발생하게 된다. 이를 개선하기 위해 MSA라는 마이크로서비스아키텍처를 사용하여 개발 속도와 효율성을 향상시키고자 한다.

## 모놀리식 아키텍처의 장점

  1. 개발이 간단하다.
  2. 애플리케이션을 쉽게 변경할 수 있다.
  3. 테스트하기 쉽다.
  4. 배포하기 쉽다.
  5. 확장하기 쉽다.

=> 모두 애플리케이션의 규모가 작았을 적의 장점이다. 시간이 지나고 애플리케이션의 몸집이 커질 수록 위의 모든 것이 힘들어진다. 그 이유는?

  1. 너무 복잡해서 개발자가 코드 분석을 하기가 겁난다.
  2. 개발이 느려진다.
    코드량이 증가할 수록 IDE 실행 속도 저하, 빌드 속도 증가
  3. 확장하기 어렵다.
    데이터 용량이 큰 서비스는 메모리 사양을 필요로 하지만 이미지 처리가 많은 서비스는 CPU 사양을 필요로 하기 때문에 리소스 배분에 까다로움이 존재
  4. 테스트에 대한 신뢰성 저하
    테스트 양이 증가할 수록 테스트에 대한 정확성과 꼼꼼함이 부족해지게 되고 그러다 보면 프러덕션이 중단되는 사태도 발생하여 매출감소와 고객의 신뢰도 상실에 직격탄을 맞게 된다.
  5. 기술 스택의 발전의 어렵다.
    새로운 프레임워크, 새로운 언어등을 시도해보기에는 리스크가 크게 따른다. 특히 버전 차이에 따른 리스크가 존재하기 때문에 새 버전으로 업그레이드하기 위해서는 어마어마한 테스트를 감당해야한다.


애플리케이션 확장의 3가지 방법 <hr>

  1. 수평 복제 (다중인스턴스)
  2. 데이터 분할 (데이터를 분할하여 다중인스턴스에 분배)
  3. 기능 분해 (기능별로 애플리케이션을 나누어 서비스 요청 분배)


SOA vs MSA <hr>

|구분|SOA|MSA| |—-|—–|——-| |서비스간 통신| SOAP,WS 표준등 무거운 프로토콜을 사용하여 통신|REST나 gRPC처럼 가벼운 프로토콜을 응용한 메시지 브로커 사용| |데이터|전역 데이터 모델 및 공유 DB| 서비스 개별 데이터 모델 및 DB| |주요 사례|대규모 모놀리식 애플리케이션(덩어리가 상대적으로 큰 앱들의 집합)|소규모 서비스(덩어리가 상대적으로 작고 많은 앱들의 집합)


MSA의 장점 <hr>

  1. 크고 복잡한 애플리케이션을 지속적으로 전달/배포할 수 있다.
  2. 서비스 규모가 작아 관리가 용이
  3. 서비스를 독립적으로 배포/확장 가능
  4. 팀의 자율성 보장
  5. 결함 격리가 잘됨
  6. 새로운 기술의 도입이 쉬움


MSA의 단점 <hr>

  1. 적절한 서비스를 찾기 어렵다.
  2. 분산시스템의 복잡성이 존재한다.
  3. 여러 서비스에 걸친 기능을 배포할 때는 더 조심해야한다.
  4. MSA 도입 시점을 결정하기가 쉽지 않다.

각기 다른 환경과 구조속에서 여러 설계/아키텍처 이슈를 해결해야하는 상황이 따른다. 각각의 트레이드 오프가 존재하지만 이를 보다 쉽게 해결하기 위해 MSA패턴이 정리되어 있고, 이를 숙지하여 각각의 상황에 잘 대처하는 설계를 해나갈 수 있다.


MSA의 패턴 언어 개요 <hr>

MSA패턴 언어란 MSA화 할때 유용한 패턴 모음집이다. 다양한 아키텍처/설계 이슈를 해결할 수 있는 가장 최적의 MSA 패턴을 적용하는 것이 관건이다.

  1. 애플리케이션을 여러 서비스로 분해하는 패턴
    1. 비즈니스 능력에 따라 분해
    2. 하위 도메인에 따라 분해
  2. 통신 패턴
    • 통신 스타일 : 어떤 종류의 IPC를 사용하는지?
    • 디스커버리 : 클라이언트는 서비스 인스턴스의 IP 주소를 어떻게 가져오는지?
    • 신뢰성 : 서비스 불능시 서비스 간 통신의 신뢰성 보장은?
    • 트랜잭셔널 메시징 : DB 트랜잭션에 메세지를 송신하고 이벤트를 발행하는 행위는 어떻게 통합하는지 ?
    • 외부 API : 클라이언트는 서비스와 어떻게 통신하는지 ?
  3. 트랜잭션 관리를 위한 데이터 일관성 패턴
    • 기존의 분산 트랜잭션은 요즘 어플에 안 맞는 방법이라 사가 패턴에 따라 데이터 일관성을 유지
  4. 데이터 쿼리 패턴
    • 서비스마다 DB를 두었을 때 각 서비스가 소유한 각각의 데이터를 조인해야하는 상황이 발생했을 때 어려움이 따른다. 따라서 API를 조합해서 사용하던지, CQRS 패턴을 사용하여 이를 구현한다. API 조합은 하나 이상의 서비스를 호출해서 그 결과를 조합하는 방식이고, CQRS(Command Query Responsibility Segregation , 커맨트 쿼리 책임 분리)는 하나 이상의 데이터 레플리카를 유지해서 쉽게 쿼리하는 방식이다.
  5. 서비스 배포 패턴
  6. 관측성 패턴 : 애플리케이션 동작 파악
  7. 서비스 테스트 자동화 패턴
  8. 횡단 관심사 처리 패턴
  9. 보안 패턴