DRY 란?

Don’t Repeat Yourself 의 줄임말입니다. 소프트웨어 공학에서 기본이 되는 원칙으로, 로직이나 데이터들이 반복적으로 사용된다면 이를 메소드나 클래스, 변수 등으로 통합하도록 하는 원칙입니다. 또한, 큰 범위에서 재활용 될 가능성이 있는 로직은 라이브러리로 패키징하는 것이 일반적입니다.

MSA 환경에서 발생가능한 문제점

“A Library” 및 “B Library” 라는 이름을 가진 공유 라이브러리에 의존하는 마이크로서비스 “A Service”를 가정하겠습니다.

심각한 문제를 초래하는 버그가 확인되어, 긴급하게 “B Library”를 패치했으나, “B Library”는 이전 업데이트된 “A Library”의 최신버전에 의존하게 되었다 가정합니다.

발생가능한 문제

1. 이 경우, 언어나 런타임 환경의 차이로 인해 두 버전의 “A Library”를 의존하지 못하게 될 가능성이 있습니다.
2. 혹은, 사용중이던 “A Library”를 대응시키기 위해 불필요한 코드변경을 해야하고, 이에따른 테스트 또한 진행해야 합니다.

해결책

1. 사이드카 패턴

공통적으로 사용되는 분야를 컨테이너화 하여 사용될 서비스와 같은 환경에 배포합니다.

단점

• 컴퓨팅 리소스 사용량 증가
• 서비스 배포시 사이드카 이미지 설정을 같이 관리해야 합니다.

예시) Grafana Loki와 함께 사용되기도 하는 Promtail 등의 로그 수집기

2. 공유 라이브러리 사용

여전히 공유 라이브러리가 유효한 방법으로 적용될 수 있습니다. 로깅, 패턴매칭 등의 변경이 드물게 일어나는 Stable한 코드는 공유 라이브러리로 패키지화 하여 서비스에서 의존해 사용합니다.

단점

• 의존성 지옥에 빠질 우려가 있습니다.
• 잘못된 사용으로 인해 전체 서비스의 결합도를 높이는 결과를 초래할 수 있습니다.
• 다양한 프로그래밍 언어에 대응하기 어렵습니다.
• 라이브러리의 버전 변경에 전체 서비스의 테스트, 빌드, 배포 등의 작업이 필요할 가능성이 있습니다.

3. 데이터 중복의 허용

데이터베이스를 물리적으로 분리는 하되, 해당하는 데이터의 캐시를 서비스에 저장하는 방식입니다. 이를 위해선 데이터의 주인이 되는 서비스가 명확해야 합니다.

단점

• 데이터의 일관성을 유지하기 어렵기 때문에 모든 서비스 유형에 대응시키기 어렵습니다.
• 캐시 데이터의 추가 저장공간 필요로 인한 별도의 컴퓨팅 리소스가 필요합니다.