[MSA] 서비스 분리 해야할 때와 통합 해야할 때(서비스 분해와 통합 요인)

MSA에서 서비스 분리를 고려할 때 어떤 경우에 서비스를 분리해야하고 반대로 어떤 경우에 서비스를 통합해야하는지 서비스의 분해인과 통합인에 대해서 알아본다.

 

간단하게 모률화, 세분도라는 용어부터 알아보자

• 모듈화: 사용상의 유연성과 다양성을 위해 표준화된 단위로 만듬, 시스템을 별도의 파트로 분해하는 것
• 세분도: 더 큰 단위를 형성하는 많은 입자 중 하나로 구성하거나, 그렇게 보임. 모듈화로 나눠진 개별 파트의 사이즈에 관한 것

MSA에서 이 세분도를 어디까지 어떻게 가져가야 하는지에 대한 고민을 많이하게 된다. 서비스를 너무 작게 나누면 관리의 복잡도, 통신 복잡도, 결국 아키텍처의 복잡도가 증가하게 되고, 너무 큰 단위로 나누게 되면 서비스간의 결합도, 영향도 등이 증가하게 된다. 아래의 서비스 분해인과 통합인을 고려해서 서비스 세분도를 잘 판단해야 한다.

 

서비스 분해인(어떤 경우에 서비스를 더 나눠야 하는가?)

1. 서비스의 범위와 기능

• 서비스를 분해하는 가장 일반적인 동인
• 서비스가 얼마나, 어떻게 서로 연관돼 있는지 응집도 분석(응집도가 강하면 서비스 분해가 적합하지 않음)
• 컴포넌트의 전체 사이즈 분석(클래스 수, 전체 코드 라인 수, 서비스 진입점 수 등 계산)서비스의 범위와 기능

출처: 소프트웨어 아키텍처 The Hard Parts

2. 코드 변동성

• 코드의 변동성 관련 분해인(코드 변동성의 차이에 따른 분해)
• 코드 변동성이 다른 기능들이 묶여 있으면 테스트 범위가 넓어지고, 배포 리스크가 증가
• 서비스에서 코드가 자주 변경되는 곳은 분해하기 적합

출처: 소프트웨어 아키텍처 The Hard Parts

3. 확장성/처리량

• 확장성/처리량이 다른 기능들이 묶여 있으면 불필요한 기능까지 확장이 발생 함
  => 불필요한 리소스 낭비, 불필요한 서비스 시작 증가 등 문제점
• 확장성과 처리량이 다르면 좋은 분해인이 됨

출처: 소프트웨어 아키텍처 The Hard Parts

4. 내고장성/가용성

• 한 서비스 내에 특정 기능에 문제가 생기면 다른 기능들에도 영향을 주게 됨(내고장성/가용성 저하)
• 문제가 자주 발생하는 기능과 아주 안정적인 기능을 분리하는 등의 내고장성 기준의 서비스 분해
• 가용성이 보장되어야 하는 기능과 그렇지 않은 기능을 기준으로 서비스 분해

출처: 소프트웨어 아키텍처 The Hard Parts

4. 보안

• 기능 별로 보안 처리 요건이 상이한(ex. 개인정보처리, 카드 정보 등) 파트를 별도 서비스로 분리하여 각 서비스 별로 보안을 달리 설정
• 보안 적용의 복잡도 감소, 불필요한 기능에 과도한 보안이 적용되는 비효율 감소 등

출처: 소프트웨어 아키텍처 The Hard Parts

5. 신장성

• 계속 발전되고 기능이 추가되는 파트는 코드 변경 및 배포 주기가 잦음.
• 테스트 범위 및 배포 리스크, 코드 영향도를 축소하기 위해 신장성이 높은 파트와 그렇지 않은 파트를 별도 서비스로 분리
• 서비스 별 새로운 기능 확장과 추가가 용이하여 서비스 민첩성 가능
• 어떤 패턴이 확실히 드러나거나 지속적으로 확장될 거라는 확신이 생기기 전에는 무작정 분해하는 것이 능사는 아님

출처: 소프트웨어 아키텍처 The Hard Parts

분해인 정리

분해인	설명
서비스 범위/기능	서비스가 자신과 무관한 일을 너무 많이 하고 있는가?  응집도가 강한 단일 목적의 서비스
코드 변동성	변경이 서비스의 어느 한 부분에만 국한돼 있는가?  코드의 변경 빈도 및 민첩성(테스트 범위와 배포 리스크가 줄어듬)
확장성/처리량	서비스 파트마다 확장을 달리해야 하는가?  비용절감, 빠른 응답성 가능
내고장성/가용성	중대한 기능 실패를 유발하는 에러가 서비스에 존재하는가?  전체 가동율 개선(서비스 분리로 장애 영향범위 축소)
보안 액세스	서비스의 어떤 파트가 다른 파트보다 높은 보안 수준을 필요로 하는가?  서비스 별 개별 보안 기능 적용 가능
신장성	서비스가 항상 새로운 컨텍스트를 추가하기 위해 확장하고 있는가?  민첩성(서비스 별 새로운 기능 확장, 추가 용이)

 

서비스 통합인(어떤 경우에 서비스를 다시 통합하는 해야하는가?)

1. 데이터베이스 트랜잭션

• 비즈니적으로 ACID 트랜잭션이 필요한 프로세스는 단일 서비스로 통합
• 데이터의 신뢰성, 무결성 고려에 따라 여러 서비스로 분리되어 있는 경우 신뢰성, 무결성이 깨질 수 있음

출처: 소프트웨어 아키텍처 The Hard Parts

2. 워크플로(WorkFlow)와 코레오그래피

• 서비스 간 통신이 많아지면 내고장성, 가용성, 신뢰성에 큰 문제될 수 있음
• 여러 서비스 호출에 따른 성능, 응답성도 고려 필요(ex. 30%정도 서비스간 호출, 70%정도 단일 서비스에서 처리가능하면 서비스 분리가 합리적)
• 워크플로의 중요성 고려 필요 (ex. 서비스간 30%정도만 서비스간 호출만 있더라도 빠른 응답이 중요한 요청이면 통합 고려)

출처: 소프트웨어 아키텍처 The Hard Parts

3. 공유 코드

• 공유 라이브러리 사용에 따른 서비스 의존성
• 서비스 통합 or 공유 라이브러리 사용하여 버저닝, 하위 호환성 유지 방안 고려
• 횡단 기능(ex. 로깅, 감사, 인증, 인가, 모니터링 등) 관련 공유코드는 서비스 통합의 고려 대상이 아님
• 공유코드의 잦은 결함, 자주 변경되는 경우 통합 고려(전체 서비스에 영향)

출처: 소프트웨어 아키텍처 The Hard Parts

4. 데이터(테이블) 관계

• 서비스와 데이터의 관계 고려
• 서비스가 쓰기를 하는 테이블은 데이터 오너십을 가짐, 오너십이 없는 테이블 접근을 위해서는 해당 서비스의 API를 호출하는 방향으로 변경이 필요해짐
• 도메인 기능에 따른 데이터 연관이 많은 테이블은 함께 접근하는 것이 좋고, 이런 데이터에 대한 오너십이 있는 서비스들은 데이터에 직접 접근하는 것이 성능/관리적으로 좋음

출처: 소프트웨어 아키텍처 The Hard Parts

통합인 정리

통합인	설명
데이터베이스 트랜잭션	서비스가 자신과 무관한 일을 너무 많이 하고 있는가?  응집도가 강한 단일 목적의 서비스
워크플로(WorkFlow)	변경이 서비스의 어느 한 부분에만 국한돼 있는가?  코드의 변경 빈도 및 민첩성(테스트 범위와 배포 리스크가 줄어듬)
공유코드	서비스 파트마다 확장을 달리해야 하는가?  비용절감, 빠른 응답성 가능
데이터 관계	중대한 기능 실패를 유발하는 에러가 서비스에 존재하는가?  전체 가동율 개선(서비스 분리로 장애 영향범위 축소)

 

서비스 분해냐 통합이냐는 고민해야 할 항목도 많고, 각 항목들이 너무 개념적인 것 같기도 하지만 지속적으로 설계를 검토하고 반영하면서 경험을 통한 노하우를 쌓아야 할 것 같다.

 

관련글:

[MSA] 모놀리식 어플리케이션 분해 전략(서비스 분리)

[MSA] 모듈화와 아키텍처 퀀텀

[MSA] 데이터베이스 분해인과 통합인 - 어떤 이유로 분해 또는 통합해야하는가?