MSA(Micro-Service Architecture) 설계

Micro-Service Architecture

MSA(Microservices Architecture)는 대규모 시스템을 구축하기 위한 아키텍처 패턴 중 하나로, 서비스 기능 단위로 시스템을 구성하는 접근 방식입니다. MSA는 기능을 독립적으로 개발하고 배포할 수 있는 잘 분리된 마이크로서비스들로 시스템을 구성합니다. 이로 인해 시스템이 탈중앙화되고, 서비스 간의 느슨한 결합을 갖게 됩니다.

 

MSA는 대규모 시스템을 구축하기 위한 아키텍처로 사용되며, 각 서비스는 컴포넌트 집합이라고 볼 수 있습니다.

 

분산 처리 시스템: MSA는 분산 처리 시스템의 한 유형입니다. 시스템의 기능은 작은 단위의 서비스로 나누어지고, 이 서비스들은 분산되어 서로 다른 서버 또는 컨테이너에서 실행됩니다. 이렇게 분산되어 실행되는 서비스들은 서로 독립적으로 동작하며, 다른 서비스들과 통신을 통해 상호작용합니다.

 

대규모 시스템: MSA는 대규모 시스템을 지원하기 위해 설계되었습니다. 기능을 작은 단위로 분리하고 각 서비스를 별도로 확장할 수 있으므로, 시스템의 규모가 커져도 유연하게 대응할 수 있습니다.

 

컴포넌트 집합: MSA는 서비스 단위로 기능을 분리하고 구성합니다. 각 서비스는 특정 기능을 제공하는 컴포넌트 집합으로 볼 수 있습니다. 이러한 컴포넌트들이 모여서 전체 시스템을 구성하게 됩니다.

 

시스템 확장: MSA의 장점 중 하나는 시스템의 확장성입니다. 대규모 시스템이 증가하는 부하에 따라 확장이 필요할 때, 전체 시스템을 확장하는 것이 아니라 특정 서비스만 확장할 수 있습니다. 이는 비용 효율적인 자원 사용과 성능 향상에 도움이 됩니다.

 

 

서비스 지향 아키텍쳐란?

• 서비스 기능 단위로 시스템 구성
• 표준화된 인터페이스 통한 시스템 통합
• 서비스 지향 아키텍처의 설계를 따르면서 발전시킨 것이 MSA
• 엔터프라이즈 시스템(=대구모 시스템) 구축을 위한 아키텍처
• 기능이 복잡하고 처리량이 많은 시스템에 적합
• 복잡한 시스템의 개발과 운영을 위한 기능을 서비스 단위로 분리
• 컴포넌트간 네트워크를 통해 데이터를 통합

 

MSA의 특징

• 잘 분리된 (fine grained) 마이크로서비스로 인한 탈중앙화
• 대규모 시스템을 위한 아키텍처
• 가벼운 네트워크 프로토콜
• 느슨한 결합
• 서비스 지향 아키텍처

 

MSA의 장점

• 독립성
• 대규모 데이터 처리/저장 용이
• 내결함성
• 서비스의 빠른 배포주기
• 확장성
• 유저 피드백에 민첩한 반응

 

MSA의 단점

• 개발의 어려움: MSA는 많은 작은 서비스들로 시스템을 구성하기 때문에 개발자들은 여러 개별 서비스를 동시에 개발해야 합니다. 이로 인해 전체 시스템의 복잡성이 증가하고, 다양한 서비스 간의 상호작용 및 통합 문제가 발생할 수 있습니다.
• 운영의 어려움: MSA 시스템은 많은 수의 서비스로 구성되어 있으며, 각각의 서비스는 독립적으로 운영 및 배포됩니다. 따라서 모니터링, 로깅, 오류 처리, 복구 등의 운영 측면에서 더 많은 관리가 필요합니다. 이로 인해 운영 복잡성이 증가할 수 있습니다.
• 설계의 어려움: MSA 시스템은 기능별로 서비스를 분리하므로, 전체 시스템을 하나의 단일 애플리케이션으로 보는 것보다는 각 서비스 간의 인터페이스와 데이터 흐름을 잘 설계해야 합니다. 적절한 바운디드 컨텍스트를 식별하고, 서비스 간의 상호작용을 정확하게 설정하는 것이 중요합니다.
• 자동화 시스템 요구: MSA는 여러 개별 서비스들로 구성되기 때문에 자동화된 배포, 테스트, 모니터링 시스템이 요구됩니다. 개발 및 운영 과정에서 자동화를 통해 효율성을 높이고 오류를 최소화할 수 있습니다. 하지만 이러한 자동화 시스템을 구축하는데 추가적인 노력이 필요할 수 있습니다.
• 개발자의 높은 기술 숙련도 요구: MSA는 여러 개별 서비스들로 이루어지기 때문에 각 서비스를 독립적으로 개발, 테스트, 배포할 수 있는 능력이 필요합니다. 또한 서비스 간의 상호작용, 데이터 일관성 등을 고려하여 설계하는 능력도 중요합니다. 따라서 개발자들에게 높은 기술 숙련도와 경험이 요구됩니다.

 

MSA 설계

잘 분리해야 한다. 여기에서 잘이란?

• 전체 서비스 관점에서, 어느 정도 크기로 마이크로서비스를 분리해야 하는가?
• 너무 작게 분리하는 것은 아닐까?
• 너무 크게 분리하는 것은 아닐까?
• 분리된 마이크로서비스 사이의 표준 인터페이스 통신은 어떻게 할까?
• 새로운 서비스가 추가되면 어떤 마이크로서비스가 처리하면 좋을까?

에 대해서 고려해 보는 것이다.

 

서비스 세분화 원칙

MSA에서는 기능을 세분화하여 독립적인 서비스로 구성합니다. 이는 작은 단위로 서비스를 나누어 각 서비스가 한 가지 기능에 집중하도록 유도합니다. 이렇게 서비스를 세분화함으로써 더 작은 팀이 각 서비스를 개발하고, 기능별로 확장할 수 있으며, 시스템의 복잡성이 감소합니다.

 

비즈니스 기능

• 이상적인 형태는 서비스와 비즈니스 동작이 1:1
• 서비스가 여러 비즈니스 동작 수행 시, 복잡도 증가
• 마이크로 서비스의 크기와 관련된 요소

 

성능

• 특정 마이크로서비스의 성능 이슈 발생시 고려
• 코드상 문제인지 서비스 크기로 인한 오버헤드인지 판단
• 크기가 크다면 리소스 사용량, 데이터 종류 증가
• 기능이 큰 마이크로서비스에 전체시스템이 의존
• 마이크로서비스가 전체의 안정성과 성능 저하 발생

 

메시지 크기

• API 설계 시, 전송 메시지 크기가 크면 분할 고려
• 메시지 크기가 크면 직렬화/역직렬화에 성능이슈
• 비즈니스 기능이나 일관성 유지하는 트렌젝션에 문제가 없다면 무시해도 좋음

 

트랜젝션

• 데이터 정합성을 유지하는 트랜젝션 단위로 서비스 분할
• 데이터를 기준으로 분리하는 방법
• 트랜젝션으로 보장되는 서비스는 데이터 유실 방지
• 하나의 비즈니스 로직 처리하는데 세트로 동작하므로 최소한의 마이크로서비스를 설계하는데 도움

 

DDD와 바운디드 컨텍스트

Domain : 비즈니스 전체나 조직이 행하는 일 – 유사한 업무의 집합

DDD는 복잡한 도메인 문제를 해결하기 위해 도메인 주도 설계를 촉진하는 방법론입니다. MSA에서는 DDD의 개념 중 하나인 "바운디드 컨텍스트"를 적용하여, 각 마이크로서비스가 특정 도메인 영역 내에서 책임을 가지도록 합니다. 이로 인해 서비스 간의 경계가 명확해지고, 도메인 별로 분리되어 비즈니스를 잘 모델링할 수 있습니다.

 

 

단일책임원칙

• 남자 객체는 여러 엑터에 대해 여러 역할과 책임을 수행하고 있음
• 너무 많은 책임을 보유
• 클래스 크기가 커질 수 있음
• 특정 기능 변경 시 클래스 전체 변경해야 함
• 낮은 응집도 / 높은 결합도

 

• 단일 클래스는 하나의 엑터에 대한 하나의 역할과 책임만을 수행
• 클래스 크기가 작아짐
• 특정 기능 변경 시 해당 책임이 있는 클래스만 변경 => 유지보수 용이
• 높은 응집도 / 낮은 결합도

 

 

응집도

응집도(Cohesion): 응집도는 하나의 모듈(서비스)이 얼마나 관련 기능들을 묶어놓았는지를 나타냅니다. 높은 응집도는 서비스 내부의 기능들이 관련성 있게 묶여 있음을 의미합니다. MSA에서는 각 서비스가 특정 기능에 집중하도록 설계하며, 이는 높은 응집도를 가진 서비스를 만들어냅니다. 이렇게 함으로써 개발 및 유지보수가 용이해지고, 코드의 가독성이 높아집니다.

 

 

결합도

결합도(Coupling): 결합도는 서비스 간의 의존성 정도를 나타냅니다. 낮은 결합도는 각 서비스가 서로 독립적으로 존재하며, 서비스 간의 상호작용이 최소화되는 것을 의미합니다. MSA에서는 각 서비스가 완전히 독립적인 데이터베이스를 가지고 있고, 서비스 간의 통신은 표준화된 인터페이스를 통해 이루어집니다. 이로 인해 낮은 결합도를 유지하고, 서비스 간의 영향을 최소화하여 서비스의 독립성과 유연성을 높입니다.

 

 

MSA의 단일책임원칙

 = Single Responsibility Principle, SRP

위의 응집도와 결합도의 내용을 따르면,

응집도는 높고, 결합도는 낮은...

단일 책임 원칙을 잘 따르는 것을 의미합니다.