본문 바로가기
개발/MSA

[MSA] 코드 재사용 및 공유 패턴 종류 및 장단점

by 궁즉변 변즉통 통즉구 2024. 8. 5.
반응형

서비스를 구현하면서 공통되는 코드들을 재사용 및 공유하는 방법을 알아보고, 각 패턴들의 장단점을 알아본다. 아래 내용들은 도서 '소프트웨어 아키텍처 The Hard Parts'를 참조했다. 

 

코드 재사용에 수반되는 트레이드오프에 대한 분석없이 무턱대고 사용하면 아키텍처적으로 문제가 될 수 있다. 예를들어, 21초반까지 유행했던 서비스지향 아키텍처(SOA)는 지나친 재사용을 강조하여 현재까지 많은 레거시들이 변경관리와 유지보수 등으로 힘들어한다. 기본적으로 코드 재사용은 추상화를 통해서 발생하지만, 변경 빈도가 낮을 때 가치가 있다.

 

1. 코드 복제

- 코드를 복제해서 각 서비스에 복사해서 사용하는 방법

- 코드가 정적이고, 버그 위험성이 없고, 변경이 거의 없는 경우에 적합(ex. 단순 유틸리티, 어노테이션 등)

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

 

장점 단점
 바운디드 컨텍스트 유지 가능  변경된 복제 코드 반영의 어려움
 코드 공유가 불필요(의존성 없음)  서비스 간 코드 불일치 발생
   서비스 간 복제 공유 코드에 대한 버저닝 처리가 안됨

 

2. 공유 라이브러리

- 단순, 직관적인 공유 방법

- 변경 빈도가 비교적 낮은 안정된 환경에 적합

- 공유 라이브러리 세분도 및 버저닝이 관건  

   : "큰 범위의 공유 라이브러리"는 의존성 처리는 단순하지만 영향받는 서비스가 많아짐(하단 왼쪽 그림)
      ⇒ 변경 발생 시 서비스 영향도 커짐(테스트, 배포 범위)

  : "공유 라이브러리 세분화" 시 변경 관리, 유지보수성은 개선, 의존성 처리 지저분해지고 및 관리 복잡도 증가(하단 오른쪽 그림 )

  : 가능한 "기능 별 공유 라이브러리(세분화)"를 만들어서 사용하는 것이 좋음(의존성도 보다는 변경 관리의 중요성)

  : 유 라이브러리는 무조건 버저닝 필요!!, 공유코드 변경에 따른 민첩성 향상, 서비스 영향도 축소

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

장점 단점
 버저닝 가능  의존성 관리 어려움
 공유코드가 컴파일 시점에 대응, 런타임 에러 발생 가능성 감소  잡다한 코드베이스가 뒤엉켜 코드 중복 가능성
 공유코드 변경에 민첩하게 대응 가능  버저닝의 어려움(버전 구식화, 버전 간 통신 등)

 

 

3. 공유 서비스

- 별도 서비스 형태로 공유 서비스 제공

- 공유 서비스의 런타임 변경으로 전체 서비스에 영향을 줄 수도 있음(변경 리스크가 큼)

- API 버저닝 필요, 버저닝 전략, 멀티 프로토콜 지원 필요

- 네트워크 레이턴시에 따른 성능 고려 필요

- 공유 서비스를 사용하는 서비스들의 확장성에 따라 공유서비스도 함께 확장 관리 필요

- 공유 서비스 가용성 관리 필요

- 고도의 폴리글랏(polyglot) 환경에 적합, 공유 기능 변경 빈도가 높은 경우 적합

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

장점 단점
 코드 변동성이 높은 때 유리   변경 버저닝 관리 필요 
 다양한 서비스, 코드베이스에 코드 중복이 없어짐  네트워크 레이턴시에 따른 성능 영향
 바운디드 컨텍스트 유지 가능  서비스 의존성에 따른 가용성, 내고장성 관리 필요
 정적 코드 공유가 없어짐  서비스 의존성에 따른 확장성, 처리량 관리 필요
   런타임 변경에 따른 리스크 증가(전체 서비스 영향 줄 수 있음)

 

 

4. 사이드카와 서비스 메시 

- 사이드카 패턴: 도메인 로직과 기술(인프라)로직을 분리한다는 육각형 아키텍처(포트&어탭터 패턴)와 동일한 개념

- 인프라 및 각종 횡단 관심사(ex. 모니터링, 로깅, 인증/인가, 회로차단기 등) 처리를 일관되게 격리해서 표준화 적용에 적합

- 사이드카에 도메인 로직 등 비즈니스 관련 로직을 포함하면 안됨

- 컨테이너 환경에서 구성이 용이(ex. Istio)

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

장점 단점
 커플링을 일관된 방법으로 분리 가능  플랫폼 당 하나의 사이드카 구현 방안으로 적용해야 함
 일관된 인프라 조정 및 관리 가능  사이드카 컴포넌트가 커지면 복잡해질 수 있음
 팀 별 오너십, 중앙집중식 등으로 적절히 조합해서 사용 가능  

 

 

반응형

댓글