[Tip] MSA ( 마이크로 서비스 아키텍처 ) 에 대한 고찰

최근에 MSA 관련 문의를 종종 받는다.

 

가끔은 MSA 가 무엇인지 전혀 이해하지 못한 발주처의 질문을 받을때 난감하다.

 

그럼 MSA 가 뭘까...?

대부분의 IT 분야의 용어들은 영문 약어( 이니셜 )인 경우가 많다.
약어가 아닌 제대로 풀어서 제대로 단어를 나열하면 의외로 쉽게 이해가는 경우가 많다.

 

단어를 풀어보면

M	Micro	작은 , 소규모
S	Service	서비스
A	Architecture	아키텍처, 컴퓨터 시스템의 구성

 

풀어진 내용을 IT 분야의 관점에서 다시 조립하면
[ "작은 규모 컴퓨터 시스템 구성" ]
으로 이해할 수 있다.

 

여기서 아마도 대부분의 사람들은
MSA 방식은 현재까지 사용되고 구축되어온 컴퓨팅 시스템의 규모를 축소하겠다는 말인가...?
라는 의문점이 발생할 수 있다.

만약 컴퓨팅 시스템의 규모를 축소 한다면 서비스의 제공이 불가능할 것이다. 라는 예상도 가능하다.

 

여기서 한가지 생각의 관점을 추가하면 이 상황이 설명된다.

 

[  현재 운영되는 기업의 메인서비스는 여러가지 작은 서비스가 모여서 이루어 진다. ]

 

실생활에서 사용하는 많은 IT 서비스들은 하위에 여러가지 서비스가 모여서 이루어 진다.

다음 그림를 예로 이어서 설명하겠다.

 

-- 그림A. 드론 배달 애플리케이션에 대한 도메인( 소프트웨어로 해결하고자 하는 문제의 영역 ) 스케치 --

출처 : https://learn.microsoft.com/ko-kr/azure/architecture/microservices/model/domain-analysis

 

드론배달 ( 메인 서비스 ) 서비스는 인식할 수 있다.

그러나 실제로는

그림A.에서 나열된 많은 하위 서비스가 모여서 구성된다.

만약
그림A. 서비스들을 다른 하위서비스와 시스템적으로 독립적으로 존재하고
서비스간에 통신을 통해 드론배달 서비스가 운영된다면
드론배달 ( 메인 서비스 ) 서비스가 MSA 형식으로 구성되었다고 볼 수 있다.

 

 

마지막으로 기존 모놀리틱 구조에 대비한 장 단점을 정리해 보겠다.

 

[ 장점 ] ( 출처 : https://learn.microsoft.com/ko-kr/azure/architecture/microservices/ )

- 민첩성.  마이크로 서비스는 독립적으로 배포되기 때문에 버그 수정 및 기능 릴리스를 관리하기가 더 쉽습니다.  전체 애플리케이션을 다시 배포하지 않고 서비스를 업데이트할 수 있고,  문제가 발생하면 업데이트를 롤백할 수 있습니다.  기존의 많은 애플리케이션의 경우,  버그가 애플리케이션의 한 부분에서 발견되면 전체 릴리스 프로세스를 차단할 수 있습니다  버그 수정이 통합, 테스트 및 게시될 때까지 새로운 기능은 보류될 수 있습니다.  - 집중화된 소규모 팀.  마이크로 서비스는 규모가 작아서 한 기능 팀에서 충분히 구축, 테스트 및 배포할 수 있습니다.  소규모 팀은 민첩성이 높습니다.  대규모 팀은 커뮤니케이션의 속도가 느리고, 관리 오버헤드가 증가하며,  민첩성이 감소되기 때문에 생산성이 떨어지는 경향이 있습니다.  - 소규모 코드 기준.  모놀리식 애플리케이션의 경우 시간이 경과하면서 코드 종속성이 얽히는 경향이 있습니다.  새 기능을 추가하려면 여러 지점의 코드를 손봐야 합니다.  마이크로 서비스 아키텍처는 코드나 데이터 저장소를 공유하지 않으므로  종속성이 최소화되며 그 결과 새로운 기능을 추가하기 쉽습니다.  - 기술의 혼합.  팀은 혼합된 기술 스택을 적절히 사용하여 서비스에 가장 적합한 기술을 선택할 수 있습니다.    - 결함 격리.  개별 마이크로 서비스를 사용할 수 없게 되더라도,  장애를 제대로 처리하도록 업스트림 마이크로 서비스를 설계하면 전체 애플리케이션에 방해가 되지 않습니다.  예를 들어 회로 차단기 패턴을 구현하거나 마이크로 서비스가 비동기 메시징 패턴을  사용하여 서로 통신하도록 솔루션을 디자인할 수 있습니다.    - 확장성.  서비스는 별도로 확장될 수 있어 전체 애플리케이션 규모를 확장하지 않고도  리소스가 더 많이 필요한 하위 시스템의 규모를 확장할 수 있습니다.  Kubernetes 또는 Service Fabric 등의 오케스트레이터를 사용하면  단일 호스트에 서비스를 보다 높은 밀도로 패킹할 수 있기 때문에 리소스를 보다 효율적으로 활용할 수 있습니다.  - 데이터 격리.  단일 마이크로 서비스만 영향을 받기 때문에 스키마 업데이트를 수행하는 것이 훨씬 쉽습니다.  모놀리식 애플리케이션에서는 스키마 업데이트가 매우 어려울 수 있습니다.  애플리케이션의 다양한 부분이 모두 동일한 데이터에 영향을 미칠 수 있어서  스키마를 변경하는 것이 위험하기 때문입니다.

[ 개인 의견 및 요약  ]      MS 에서 장황하게 작성해 놓았으나 요약하면 아래 2 가지 장점을 가질 것으로 생각된다.      1. 전체 서비스보다 규모가 작은 하위 서비스 단위로 업무가 진행된다 따라서          작업 및 배포 S/W 규모가 작아지기 때문에 얻을 수 있는 장점들이 있다.      2. 하위 서비스의 일부 장애가 발생하더라도 계속적인 서비스 운영이 가능하다.

 

[ 단점 ] ( 출처 : https://learn.microsoft.com/ko-kr/azure/architecture/microservices/ )

- 복잡성.  마이크로 서비스 애플리케이션에는 동등한 모놀리식 애플리케이션보다 작동 부분이 더 많습니다.  각 서비스는 더 단순하지만 전체 시스템이 더 복잡합니다.  - 개발 및 테스트.  다른 종속 서비스에 의존하는  소규모 서비스를 작성하려면 기존의 모놀리식 또는 계층화된 애플리케이션을 작성하는 것과  다른 접근 방식이 필요합니다.  기존 도구는 항상 서비스 종속성 작업에 맞게 설계되지 않습니다.  서비스 경계를 벗어난 리팩터링은 어려울 수 있습니다.  특히 애플리케이션이 빠르게 발전하는 경우 서비스 종속성을 테스트하기도 어렵습니다.  - 통제 부족.  마이크로 서비스 빌드에 대한 분산 접근 방법에는 장점이 있지만 문제가 발생할 수도 있습니다.  언어와 프레임워크가 너무 많아서 애플리케이션 유지 관리가 어려워질 수 있습니다.  팀의 유연성을 지나치게 제한하지 않고 몇 가지 프로젝트 전체 표준을 적용하는 것이 유용할 수도 있습니다.  특히 로깅과 같은 교차 기능에 해당합니다.  - 네트워크 정체 및 대기 시간.  다수의 작고 세분화된 서비스를 사용하면 서비스 간 통신이 증가할 수 있습니다.  또한 서비스 종속성 체인이 너무 길어질 경우 (서비스 A가 B를 호출하고, B가 C를 호출하고...)  추가 대기 시간이 문제가 될 수 있습니다. API를 신중하게 디자인해야 합니다.  통신량이 과도한 API를 피하고, 직렬화 형식을 고려하고,  큐 기반 부하 평준화와 같은 비동기 통신 패턴을 사용할 영역을 찾아보 세요.  - 데이터 무결성.  각 마이크로 서비스가 자체 데이터 지속성을 담당합니다. 그 결과, 데이터 일관성이 과제가 될 수 있습니다.  가능한 경우 결과적 일관성을 수용합니다.  - 관리.  마이크로 서비스에 성공하려면 성숙한 DevOps 문화가 필요합니다.  전체 서비스의 상관관계 로깅이 까다로울 수 있습니다.  일반적으로 로깅은 단일 사용자 작업에 대한 여러 서비스 호출을 상호 연결해야 합니다.  - 버전 관리.  서비스 업데이트로 인해 종속된 서비스가 손상되지 않아야 합니다.  언제든지 여러 서비스가 업데이트될 수 있으므로 신중하게 디자인하지 않으면  이전 버전 또는 이후 버전과의 호환성 문제가 발생할 수 있습니다.  - 기술 수준.  마이크로 서비스는 고도로 분산된 시스템입니다.  팀이 성공을 위한 기술과 경험을 가지고 있는지 신중하게 평가합니다.

[ 개인 의견 및 요약 ]      1. 하나의 서비스를 작은 여러개의 서비스로 결합으로 재설계 및 구축 하는 과정에서          발생하는 기존 모놀리식 구조에서 존재하지 않았던          문제점들의 발생을 해결해야하고 이 과정에는 시간과 비용이 발생한다.      2. 전체적인 복잡도가 증가하며 복잡도가 증가한 상태에서 서비스의 운영 및 유지보수를          고려하면 요구되는 기술 수준과 개발부서의 성숙한 DevOps 문화가 아주 중요한 요소가 된다.