🏷 서비스 분리 프로세스
서비스를 분리하는 과정은 복잡도가 상당히 크다.
프로세스는 이정표를 제시하여 복잡도를 완화시켜 준다.
이는 완벽하게 정형화 된 SW 프로세스는 아니고 단지 절차를 기술한 것이다.
🏷 후보 서비스 도출
1. 워크샵을 통해 분리 대상 서비스 후보 선정
후보 서비스 도출 과정에서는 워크샵을 통해 분리 대상 서비스 후보를 선정해야 한다.
워크샵만으로는 분리 대상 서비스 확정이 어려울 수도 있으므로 실제 코드나 데이터 레벨에서 의존성 분석을 해야한다.
2~3개 정도의 후보가 적절하다.
🏷 분리 준비
1. 자동화 된 테스트 준비
2. 사용되지 않는 개체 제거 후 테스트
3. 잘못된 의존성 분석 및 정리
1. 자동화 된 테스트 준비
MSA는 일종의 SW Reengineering 이다.
SW Reengineering : 기능의 변경 없이 SW의 내부 구조를 변경하는 활동
Monolith에서 서비스를 분리하는 작업은 많은 코드 변경을 야기하고, 수정 시 마다 QA 인력이 수동으로 테스트 하기에는 비용이 많이 들기 때문에 자동화 된 테스트가 매우 중요하다.
테스트 레벨으로는 단위 테스트/컴포넌트 테스트/통합 테스트/UI 테스트 등이 있고,
만약 현재 테스트 케이스가 없다면 의존성을 분석하여 분리 대상 기능을 사용하는 부분에 대해서라도 테스트 케이
스를 작성해서 준비해야 한다.
2. 사용되지 않는 개체 제거
사용되지 않는 개체들은 불필요한 의존성을 만들고, 서비스 분리 시 복잡도를 높일 수 있다.
따라서 사용되지 않는 개체(Class, Method, Variable 등)을 분석하여 코드를 최대한 Compact하게 만들어 복잡도를 줄여야 한다.
이 개체는 한번에 제거할 수 없고 반복적으로 제거해야 한다.(약 3~4회 정도)
🏷 의존성 분석 및 서비스 확정
1. 분리 대상 기능들의 외부 의존성 분석
2. 분리 대상 기능 확정
1. 분리 대상 기능들의 외부 의존성 분석
분리 대상 서비스들과 관련된 파일들을 하나의 패키지로 이동시키고, 해당 패키지와 다른 기능들과의 의존성 분석을 한다.
- 데이터베이스 의존성 분석
- 외래키 분석
- 제약 조건 분석
- 코드 상 Join 되는 부분 분석
- 트랜잭션 분석
2. 분리 대상 기능 확정
워크샵을 통해 이 과정을 진행할 수 있다.
의존성 분석 결과를 공유하고 분리 기능을 확정한다.
- 의존성 개수 공유
- 의존성 형태 공유
- 데이터베이스 의존성 결과 공유
🏷 서비스 분리
1. 분리 대상 기능의 코드들을 한 패키지로 모듈화
2. 기존 시스템과 분리 대상 서비스의 호출 관계 수정
3. 데이터베이스 분리
4. 신규 서비스를 독립적인 프로젝트로 구성
1. 분리 대상 기능의 코드들을 한 패키지로 모듈화
새로운 Branch를 생성하고 분리 대상 기능을 모두 한 패키지로 모듈화한다.
Domain 객체, 공통 유틸, 상수에 대한 의사 결정이 필요하다.
- 복사
- 공통 라이브러리
- 서비스화
2. 기존 시스템과 분리 대상 서비스의 호출 관계 수정
기존 시스템과 분리 대상 서비스의 의존을 분석한다.
메소드 호출을 REST API 등의 호출로 변경한다.
주의할 점은, 완전한 분리 전에는 동일한 서버를 호출해야 한다는 것이다.
3. 데이터베이스 분리
- 서비스 별 스키마
- 서비스 별 데이터베이스
- Polyglot 데이터 베이스
외래키/Join/Constraint 등을 제거하는데 가장 중요한 부분은 트랜젝션 제거이다.
- 트랜잭션을 제거했을 경우 나타날 수 있는 상황들을 시뮬레이션
- 예를 들어, 데이터 저장시에 굳이 검색 테이블까지 트랜잭션 걸려야하나?
- 반드시 필요하면 하나의 서비스로
- Eventual Consistency에 대한 가능성 제고
4. 신규 서비스를 독립적인 프로젝트로 구성
새로운 독립된 프로젝트 생성하여, 패키지로 묶었던 파일들을 새로운 프로젝트로 복사한다.
(여기서 기존 코드들은 어느정도 유지 후 제거해야 한다.)
기존 시스템과 신규 서비스 간의 호출 정보 수정하고 테스트 및 배포한다.
