[MSA] MSA (Micro Services Architecture) 개요

본 글은 "MSA 이해와 구현"이라는 사내 강의 수강 후,
여러 MSA 관련 글을 참고하여 작성한 글입니다.

1. MSA란?

MSA는 Micro Services Architecture의 약자로 이름에서 유추할 수 있듯이 하나의 서비스를 Micro 단위로 쪼개서 관리하는 아키텍처를 의미합니다.

커머스 서비스를 예로 들면, 커머스라는 도메인 아래 하나의 서비스로 개발되고 운영되고 있었던 모놀리스(Monolith)형태가 아닌
주문, 정상, 회원, 상품 등 커머스 도메인 아래 여러 서비스로 추가 분리 및 개발하여 분리한 각 서비스를 각각의 서버에 배포하여 관리하는 MicroServices형태가 있을 수 있습니다.

위 사진은 가트너에서 제시한 표준 Micro Services Architecture 입니다.
MSA로의 구현 및 전환을 시도하는 많은 기업들에서 위 사진에서 제시된 표준 아키텍처를 따르고 있다고 합니다.
해당 아키텍처에 대해서는 다음글에서 다뤄보도록 하겠습니다.

2. Why? MSA

한눈에 보기에도 복잡한 이 MSA를 저희가 왜 써야할까요?
MSA를 쓰는 궁극적인 이유는 Loose Coupling, 느슨한 결합 특성때문이라고 볼 수 있습니다.
즉, 하나의 통합된 형태로 관리되던 서비스(ex. 커머스)를 여러 나눌 수 있는 최소한의 단위인 micro 단위의 서비스(ex. 주문, 정산, 회원 등)로 나눔으로써 각 서비스 간의 영향을 최소화할 수 있고(낮은 의존성), 이로 인해 모놀리스의 High Cohesion, 높은 응집력 특성으로 야기되는 다양한 문제(ex. 기능 단위 장애의 전체 확산 등)를 보완할 수 있게됩니다.

MSA의 이러한 Loose Coupling 특성은 다양한 기대효과를 낳을 수 있습니다.

장점

장애의 확산 차단

특정 Micro 서비스에서 장애가 발생하면, 전체 서비스로 확산되지 않습니다.

기존 모놀리스 구조에서는 특정 기능의 장애가 발생하면 전체 서비스가 마비되는 일이 흔했는데,
MSA에서는 Micro단위로 서비스를 세분화하여 각 기능을 독립시켰기 때문에
하나의 Micro 서비스가 타 서비스에 영향을 주지 않아 장애의 전체 확산을 막을 수 있습니다.

각 서비스의 개별 배포

각 Micro 서비스별로 개별 배포가 가능합니다.

기존 모놀리스 구조에서는 특정 기능에 대한 변경사항이 적용되려면, 서비스가 하나의 서버로 관리되었기 때문에 전체 서비스 배포가 불가피하였습니다.
MSA에서는 이러한 서비스를 여러 Micro 서비스로 나누어 별도의 서버로 각각 배포하는 구조이기 때문에
각 Micro 서비스별로 개별 배포가 가능합니다.

신속한 기능 수정 및 요구사항 반영

긴급하게 특정 기능에 대한 요구사항이 발생했을 때, 신속하게 반영할 수 있습니다.

위에서 언급했던 것처럼 MSA는 Micro 서비스 단위로 개별 서버에 배포되기 때문에, 서버의 크기가 비교적 작습니다.
이로 인해 배포 시간이 줄어들고 기능 수정이 신속하게 진행될 수 있습니다.

용이한 유지보수

용이한 유지보수가 가능합니다.

특정 서비스에 대한 장애나 이상징후 발생 시, 해당하는 서비스만 점검하면되기 때문에 대처할 영역이 좁아지므로
유지보수가 용이합니다.

Loose Coupling과는 별개로 다양한 기술 수용 등과 같은 장점이 존재합니다.

하지만 MSA의 Loose Coupling, 느슨한 결합 특성으로 인한 단점도 존재합니다.

단점

높은 복잡성

MSA를 활용하면 복잡성이 커집니다.

기존 모놀리스 기반 시스템은 하나의 서비스를 하나의 UI, 하나의 서버, 하나의 DB로 개발하고 관리해왔기 때문에,
타 모듈간 연동도 간단한 함수 호출로 이루어졌고, 데이터 동기화에 관한 부분도 단일 트랜잭션 처리로 간단하게 관리될 수 있었습니다.

하지만 MSA로 구현이 되는 서비스는 Micro 단위의 서비스마다 별개의 서버와 DB로 관리되고 있고,
이로 인해 타 모듈간 연동에 Rest나 gRPC 등과 같은 기술이 활용되어야 하고
데이터 동기화에 있어서도 분산 트랜잭션 환경의 메세지큐 기술이 도입되어 활용되어야하기 때문에,
개발 및 운영에 대한 복잡성이 커지게 되었습니다.

통신 비용 증가

MSA를 활용하면 통신비용 또한 증가됩니다.

여기서 말하는 통신비용은 latency에 따른 통신효율을 의미합니다.
위에서 언급한 것처럼 모놀리스 방식에서는 단순 메소드/함수 호출로 끝나는 연동이
MSA에서는 Rest나 gRPC와 같은 통신 기술이 활용되어야 합니다.
이로 인해 서비스 성능상의 비효율이 발생할 수 있습니다.

데이터 동기화의 어려움

MSA 기반 환경에서는 데이터 동기화를 위한 다양한 기술이 도입되어야 합니다.

서비스의 데이터가 하나의 DB로 관리되는 것이 아닌 Micro 단위의 서비스로 분리되어 각각 별도의 DB로 관리되는 형태이기 때문에,
데이터 일관성 또한 MSA환경에서 주요하게 다뤄야할 이슈라고 볼 수 있습니다.
이를 위한 기술도입 사례로 kafka 메세지큐 기술 도입 사례가 있는데,
특정 Micro 서비스에서 데이터 변경이 발생하여 kafka 메세지 큐에 이벤트를 발행하면,
kafka의 해당 이벤트를 구독하고 있는 Micro 서비스들이 이에 맞게 데이터 변경을 진행하는 방식이 있을 수 있습니다.

분산 트랜잭션 처리 필요

먼저 분산 트랜잭션 환경이란?
2개 이상의 네트워크 시스템간 트랜잭션 환경이라고 보면 됩니다.
모놀리스 환경에서 데이터베이스의 특성 ACID(원자성, 일관성, 고립성, 지속성)를 보장하기 위해 단일 서버/DB내 트랜잭션 처리를 하는 것처럼
MSA 환경의 여러 서버/DB 간에 ACID를 보장하기 위해 단일 트랜잭션이 처리되는 것처럼 여러 기술과 패턴이 도입되어 트랜잭션이 처리되어야 합니다.

이를 위한 대표적인 패턴으로 Saga패턴이 있습니다.

Monolith vs MSA

위와 같은 단점들이 있기 때문에 무조건적으로 모놀리스 방식이 아닌 MSA가 활용되어야 한다고 말할 수 없습니다.
MSA를 활용해야 하는지에 대해서는 구현해야 하는 도메인이나 비즈니스 환경, 사용기술, 해당 서비스를 관리해야하는 조직 등 특성에 따라 선택되어야 합니다.

1. 모놀리스

• 단일 코드베이스
• 쉬운 디버깅
• 쉬운 배포
• 상대적으로 좋은 성능
• 시스템 업데이트 시, 전체 시스템 배포 필요
• 코드 재사용의 어려움 (다른 시스템 모듈에서의 재사용)
• 변경 필요사항에 대한 유연한 대처 어려움
• 다양한 기술 사용에 제약
• 스케일링이 어려움

2. MSA

• 업데이트가 필요한 모듈만 배포 가능
• 코드 재사용이 쉬움 (다른 시스템에서의 코드 재사용)
• 변경 필요사항에 대한 유연한 대처 가능
• 특정 서비스의 장애로부터 독립 가능
• 다양한 기술 적용 가능
• 스케일링이 쉬움
• 개발난이도 증가
• 상대적으로 복잡한 배포
• 네트워크 지연으로 인해 상대적으로 떨어지는 성능
• 데이터 부정합에 취약
  
  

3. Cloud Native

MSA와 함께 많이 언급되는 개념인 Cloud Native에 대해 간략히 짚고 넘어가겠습니다.

Cloud Native란? 클라우드 환경에 맞게 서비스를 구축하여 클라우드의 이점을 최대한 활용한 환경이라고 보면 됩니다.
CNCF(Cloud Native Computing Foundation)에서 정의한 내용에서는 Cloud Native를 클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API가 이러한 접근 방식의 예시들이다. 이 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화 기능을 함께 사용하면 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다. 라고 정의하고 있습니다.
쉽게 말해서 Cloud 환경의 컨테이너, 서비스메쉬 등과 같은 기술들을 활용하면 관리편의성, 느슨하게 결합된 시스템 등과 같은 효과를 볼 수 있는 것이라고 보면 됩니다.

Cloud Native는 MSA로 구현되는 서비스에 적용되어야 하는 환경이라서 해당 개념을 더 자세하게 알고가면 좋을 것 같습니다.

아래 나열한 기술들은 Cloud Native의 4가지 핵심기술입니다.

1. CI/CD : Continuous Integration and Continuous Delivery(또는 Deployment), 각자가 작업한 코드를 하나의 결과물로 통합하여 테스트 빌드 지속적 수행(CI), 빌드된 결과물을 최종 배포하여 최종 사용자가 이용가능하도록 지속적 수행(CD), 이러한 과정을 지속적 자동 수행
2. DevOps : Development and Operation, 소프트웨어의 개발과 운영의 스피드와 품질을 향상하기 위한 새로운 조직 문화이자 접근방식. 개발계획 수립부터 비즈니스 타당성 검토, 개발, Build, Release, 서버 쪽에 Deploy , Operation, Monitoring까지 일련의 과정을 뫼비우스 띠처럼 반복
3. MicroServices : 하나의 서비스를 Micro 단위로 쪼개서 관리하는 아키텍처
4. Containers : 애플리케이션 구동을 위해 필요한 라이브러리나 구성파일들을 이미지라는 패키지 형태로 묶어서 구동시키는 환경. 해당 기술을 활용하면 서비스별 독립적인 구동이 가능하고, 효율적인 배포 및 Autoscale 가능
   
   

각 기술에 대한 설명을 간단하게 커멘트 남겼지만,
각 기술 하나하나 다룰내용이 많은 기술들입니다. 해당 기술들은 앞으로 작성될 글에서 더 자세하게 다뤄보겠습니다.

이어서

본 글에서 다양한 키워드가 소개되었습니다.
MSA, 모놀리스, Rest, gRPC, kafka, Saga, Cloud Native...
해당 키워드는 이어지는 글에서 MSA에 대해 상세히 다뤄보며 더 알아보겠습니다.

Reference

• MSA 이해와 구현방법 (사내강의)
• KT Enterprise - https://enterprise.kt.com/bt/dxstory/1007.do
• #2. 마이크로서비스 아키텍처, MSA가 주목 받고있는 이유 (tistory) - https://medium.com/twolinecode/2-마이크로서비스-아키텍처-msa가-주목-받고있는-이유-59092da625cd