[마이크로서비스 아키텍처 : 패턴과 핵심 기술] MSA 분리 전략 - Microservice 분리 프로세스

< Microservice 분리 프로세스 >

 

서비스 분리 프로세스

서비스 분리 프로세스

• 서비스 분리 시 복잡도가 상당히 크다
• 프로세스는 이정표를 제시하여 복잡도를 완화해준다
• 완벽하게 정형화 된 SW 프로세스는 아니고 절차를 기술한 것이다

 

 

 

분리 대상 서비스 후보 선정

• 워크샵을 통해 서비스 분리 대상 후보를 선정한다
• 워크샵만으로는 분리 대상 서비스 확정이 어렵다
• 실제 코드/데이터 레벨에서 의존성 분석이 필요하다
• 2-3개 정도의 후보가 적절하다

 

 

 

자동화된 테스트 준비

• MSA는 일종의 SW Reengineering이다
• SW Reengineering 이란?
  • 기능의 변경 없이 SW의 내부 구조를 변경하는 활동이다
  • 일종의 리팩토링?
• 코드를 수정해쓴데 기능이 변경되지 않았음을 증명하는 방법
  • 개발자를 믿는다? - 사실상 쉽지 않다
  • 유일한 방법은 테스트이다

테스트 과정 (기도메타..)

• PDD - Prayer Driven Development (기도 기반 개발)
• HDD - Hope Driven Development (희망 기반 개발)
• JDD - Jesus Driven Development (예수님 기반 개발)
• Monolith에서 서비스를 분리하는 작업은 많은 코드 변경을 야기한다
• 수정시 마다 QA 인력이 수동으로 테스트하기에는 비용이 많이 든다
• 따라서 자동화된 테스트가 중요하다
• 테스트 레벨
  • 단위 테스트
  • 컴포넌트 테스트
  • 통합 테스트
  • UI 테스트
• 현재 테스트 케이스가 없다면?
  • 의존성을 분석하여 분리 대상 기능을 사용하는 부분에 대해서라도 테스트 케이스를 작성한다
  • API 테스트 (통합 테스트) 케이스라도 작성한다
  • 너무 완벽을 기하려고 하면 큰 허들이 생긴다

 

 

사용되지 않는 개체 제거

• 코드를 최대한 Compact하게 만들어 복잡도를 최대한 줄인다 => 코드 품질 향상
• 사용되지 않는 개체를 분석한다
  • Class, Method, Variable
  • 정적 분석을 사용한다
• 사용되지 않는 개체는 모두 제거한다
  • 주석 처리 된 코드도 모두 제거한다
  • 형상관리 도구로 관리한다
• 사용되지 않는 개체들이 불필요한 의존성을 만든다
  • 서비스 분리 시 복잡도를 높일 수 있다
  • 따라서 사용되지 않는 개체들은 제거해야 한다
• 한번에 제거할 수 없고 반복적으로 제거해야 한다
  • service -> repository -> domain -> util
  • 위와 같은 레이어를 갖고 있기 때문에 제거한 개체에서 갖고 있던 의존성이 사라지면서 새로운 Unused 개체들이 생성된다
  • 경험상 3-4회 정도의 반복이 필요하다고 함

 

 

 

SW 정적 분석

• 정적 타임 혹은 빌드 타임에 SW를 분석하는 기술이다
  • SW 지표 측정
  • 잠재 결함 분석
  • Coding Rule 위반 분석
  • 모듈별 의존성 분석
• 좋은 정적 분석 도구가 필수이다
  • 보통 SW는 수십만 라인을 갖고 있다
  • 수십만 라인을 수동으로 분석하는 것은 힘들다

 

 

 

Structure101 - SW 정적 분석

• C, Java, Python, .Net 등 다양한 언어, 플랫폼 지원
• 모듈간 의존성 분석 기능
• SW 지표 추출
• $99 ~ $1,190 까지 다양한 라이선스 옵션 존재

 

 

 

Stan4J - SW 정적 분석 (추천)

• Java 언어 정적 분석 도구
• 의존성을 분석하는데 탁월하다
• 패키지, 클래스, 메소드 단위로 깊이 분석을 해준다
• 숫자들이 의존성의 개수를 나타낸다
• 클릭하면 의존성 종류마다 상세한 파악이 가능하다
• 500 클래스까지 무료이다
• 라이선스 1개당 30만원 정도
• http://stan4j.com/

 

 

 

Klocwork - SW 정적 분석

• 다양한 언어를 지원하는 정적 분석 도구
• 코드 변경 없이 아키텍처 시뮬레이션 가능
• 다양한 Coding Rule 지원
• 가격이 상당히 비쌈 (몇천만원 ~ 몇억)

 

 

 

1. 잘못된 의존성 분석 및 정리

• 잘못된 의존성
  • 레이어를 넘어서 호출
  • 타 기능의 DB를 직접 호출한다
  • 상위 레이어를 호출한다
• 모든 호출은 바로 다음 레이어를 통하도록 한다
• 타 기능의 사용은 비즈니스 레이어를 통해 사용하도록 수정한다
• 규칙에 따라 의존이 정리되면 서비스 분리가 용이해진다

 

 

 

2. 분리 대상 후보들의 의존성 분석

의존성 분석 결과

• 분리 대상 서비스들과 관련된 파일들을 하나의 패키지로 이동시킨다
• 해당 패키지와 다른 기능들과의 의존성을 분석한다 (정적 분석 도구 사용)
• 주요 의존성에 대한 리스트 업
  • Method Call
  • Inheritance
  • Implements

 

 

DB 의존성 분석

• 데이터베이스 의존성 분석
• 외래키 분석
• 제약 조건 분석
• 코드 상 Join되는 부분 분석 
• 트랜잭션 분석

 

 

 

3. 분리 대상 기능 확정

• 워크샵을 통해 다같이 분리 대상 기능을 확정한다
• 의존성 분석 결과 공유 및 분리 기능을 확정한다
• 각 의존성의 개수 및 형태를 공유한다
• 데이터베이스 의존성 결과를 공유한다
  • 외래키 및 제약 조건 제거가 가능한가?
  • 트랜잭션이 없어도 되는가?
  • 만약 트랜잭션이 제거가 되면 무슨 문제가 야기되는가?

 

 

 

4. 분리 대상 기능의 코드들을 한 패키지로 모듈화

• 새로운 Branch를 생성하여 분리 대상 기능을 모두 한 패키지로 모듈화한다
• Domain 객체, 공통 유틸, 상수에 대한 의사 결정이 필요하다
  • 복사
  • 공통 라이브러리
  • 서비스화
• 물론 이 과정들은 신규 서비스가 아닌, 기존 서비스를 분리화할 떄 필요한 것이다

 

 

 

5. 기존 시스템과 분리 대상 서비스의 호출 관계 수정 - 실제 분리 과정

• 기존 시스템과 분리 대상 서비스의 의존을 분석
• 메소드 호출을 REST API 등의 호출로 변경한다
• 완전한 분리 전에는 동일한 서버를 호출하도록 유지한다
• 변경해야 할 의존성들이 굉장히 많을 수 있기 때문에 반복적으로 수정 및 작업을 진행해야 한다
• 사실상 가장 오래걸리는 작업이다

 

 

 

6. 데이터베이스 분리

• 서비스 별 스키마
• 서비스 별 데이터베이스
• Polyglot 데이터베이스
• 외래키를 제거한다
• Join 제거 -> 애플리케이션 조인으로 변경
• Constraint(제약조건) 제거
• 트랜잭션 제거
  • 가장 어려운 문제
  • 트랜잭션 제거했을 경우 나타날 수 있는 상황들을 시뮬레이션 한다
  • 예를 들어 데이터 저장 시에 굳이 검색 테이블까지 트랜잭션을 걸어야 하는가?
  • 만약 트랜잭션 제거가 불가하고 반드시 필요하면 하나의 서비스로 묶어준다
  • Eventual Consistency에 대한 가능성을 재고한다

 

 

 

7. 신규 서비스를 독립적인 프로젝트로 구성

• 새로운 독립된 프로젝트를 생성하낟
• 패키지로 묶었던 파일들을 새로운 프로젝트로 복사한다
• 기존 코드들은 에러를 대비하여 어느정도 유지 후 제거한다
• 기존 시스템과 신규 서비스 간의 호출 정보를 수정한다
• 테스트 및 배포를 진행한다

 

 

 

서비스 분리 프로세스 정리!

• 후보 서비스 도출
  • 워크샵을 통해 모든 이해관계자가 함께 서비스 후보를 선정한다
• 분리 준비
  
  • 분리에 대한 복잡도는 낮추고 안정성은 높인다
  • 잘못된 의존성들을 규칙에 맞게 정리한다
• 의존성 분석 및 서비스 확정
  • 정적 분석 도구를 통해 의존성 분석을 한다
  • 코드와 데이터베이스에 대한 의존성을 분석한다
• 서비스 분리
  • 신규 서비스를 재개발 하는 경우에는 재개발을 하면 된다
  • 기존 서비스를 분리하는 경우에는 기존 코드를 모듈화하여 호출 관계를 전환한다