MSA ( MicroService Architecture )

MSA란?

 

MSA에 대한 공식적인 정의는 찾을 수 없었다.

그래서 나름대로 MSA의 특징이라고 생각되는 것을 적어보았다.

- 서비스가 작게 나뉘어져있어야하고, 개별 서비스는 독립적인 배포가 가능해야한다.
- API를 통해 각 서비스간 통신한다.
- 각 서비스간 영향도가 최소화 되어야한다.
  ※ DB조차도 중앙관리 될 필요가 없으며, 개별 서비스가 DB를 소유한채 API를 통해서만 데이터를 가져온다.

---

장점

앞서 작성했던 Monolithic의 단점이, MSA의 장점이 될 수 있다.

( 2021.07.03 - [IT/아키텍처] - Monolithic )

 

다른 서비스들에 영향을 끼치지 않음

  - 독립적인 서비스 구성으로, 배포 실패나 장애 발생시에 시스템 전체에 영향을 끼치지 않는다.

 

요구사항의 빠른 반영이 가능하다

 - 다른팀의 개발을 기다릴 필요없이, 빠르게 개발 및 테스트를 진행할 수 있고, CI/CD가 가능하다.

  ※ CI ( Continuous Integration ) : 지속적 통합으로, 코드의 변경사항이 형상관리 시스템에 계속 반영되어 품질을 유지
                                             개발 / 테스트 / 병합 단계를 의미

     CD ( Continuous Deploy 혹은 Delivery ) : 지속적 서비스 제공 또는 배포. 테스트 및 운영서버로 자동 배포를 의미.

 

배포시간의 감소

  - 기존 Monolithic에서는 몇십, 몇백GB 짜리 소스코드를 디플로이 하느라 시간이 오래걸린다.

    해당시간동안 서비스가 불가능하다는 의미이기도 하며, Time out 으로 디플로이가 실패할 수도 있다.

    

    하지만 MSA에서 소스코드 용량은 KB,MB 단위이기때문에 배포에 오랜시간이 걸리지 않는다.

 

다양한 형태의 아키텍처

  - 각 서비스간에 프로그래밍 언어나 프레임워크에 엮여있지 않아, 다양한 아키텍처 구성이 가능하다

   

 

---

단점

 

시스템 복잡도 상승

  - 위의 다양한 컴포넌트들에서 보이듯,  각 서비스별 관리에 있어 어느정도 컴포넌트에 대한 지식이 필요하다.

 

성능 하락

  - 서비스간 통신을 모두 API를 통해 진행하기 때문에, latency 및 네트워크 비용 발생

 

데이터 정합성

  - 데이터가 단일 DB가 아닌, 개별 서비스에 종속되어 있기때문에
    관리가 어렵고 정합성 문제가 발생할 수 있다.