대부분 현재 시스템을 잘 설명해주는 문서는 존재하지 않는다. 존재한다고 해도 현행화가 되어 있지 않기에, 오해의 여지가 발생하기도 한다. 상황이 어떻든 최소한 아래의 정보는 수집해야 한다.
- 애플리케이션의 기능 모듈 및 상호간의 관계
- API 및 서비스 인터페이스
- 모듈에 대한 설명이 있는 논리 다이어그램
- 시스템 구성을 알 수 있는 물리 다이어그램
데이터
어떤 데이터를 다루는지 알 필요가 있다. 각 모듈별 어떤 데이터를 다루는지 추출을 해야 향후 마이크로서비스로 전환시 경계를 설정할 수 있다.
현황 파악
기능이 이미 외부에 존재하는 경우도 있다. 이 경우 외부 서비스를 재사용하도록 고려해야 한다.
사용자 파악
애플리케이션을 어떤 사용자가 사용하는지 파악해야 한다. 이 작업을 수행하면 사용하지 않는 기능을 추출할 수 있고 분할 방법, 분할하는 이유 및 효과등을 알 수 있다.
분할해야 하는 이유
모놀리스를 마이크로서비스로 분할해야 하는 이유에 대한 답을 찾기가 어려울 수 있다. 가능하면 두가지를 얻으려고 노력한다. 비즈니스/기술 지향 관점에서 이점을 가져가려고 노력해야 한다.
비즈니스 관점
비즈니스 지향 관점에서 분할하는 이유를 고려해야 한다.
- 애플리케이션 출시 기간 단축
- TCO 절감 → 트래픽 증가시 필요 부분만 확장
- 손실 감소
- 더 나은 사용자 경험 → 이 경우 UX를 반영한 UI가 개선되어야 한다.
현재 프로젝트는 위 4가지 개선 사항이 모두 포함되어 있다.
기술 관점
기술 지향 관점은 비즈니스 Guy들은 이해하기가 어렵지만, 중장기적 관점에서 원할한 MA를 위해서 필요한 작업들이다.
- 더 이상 사용되지 않는 기술을 제거하고 현재 사용중인 기술로 마이그레이션 → Stored Procedure, EAI등
- 복잡성 감소
- 테스트 커버리지 증대 → 장애 감소
오랫동안 사용되었던 시스템을 구조개선해야하는 업무를 수행중이다.
모놀리스 시스템을 분할하기 위해서는 몇 가지 목표를 설정해야 한다. 분할 비용과 분할 되었을 때의 이점을 고려해야 하고, 이 보다 애플리케이션 및 데이터베이스 Scale-up이 더 유리한지 판단해야 한다.
애플리케이션의 특성으로 인해 모놀리스는 매우 지저분해 보일 수 있다. 대규모 시스템이며 상호간 튼튼하게 결합되어 있다.
마이크로 서비스로 전환?
마이크로 서비스의 이점
무작정 마이크로 서비스로 전환하려는 것은 아니다. 오래전 Gartner가 소개한 MSA에 대한 관점을 보면, 통합 DB를 사용하는 경우 Miniservices라는 표현을 했고, 현재 구조개선을 해야 할 시스템은 마이크로서비스보단 미니서비스가 적합해 보인다. 모든 것을 한걸음으로 해결하면 좋겠지만 현실은 녹녹치 않다.
| 이점 | 요구사항 |
|---|
| 서비스 유연성: 모놀리스에 비해 상대적으로 작은 서비스는 유연하기에 기능을 수정하기 쉽다. | 출시 시간 단축, 개발 비용 절약, 복잡성 해소, 테스트 커버리즈 증대 |
| 서비스 재사용성: 서비스는 비즈니스 기능을 중심으로 구성되기에 재사용하기 쉬워야 한다. | 개발 비용 절약 |
| 표준화된 서비스 개발 및 기술에 구애받지 않는 구현: 다양한 기술이 포함된 Stack을 활용 | 개발 비용 절약, 더 나은 리소스 계획, 재사용 |
| 서비스 확장: 추가, 제거, 업데이트 및 이벤트 대응등 확장하기 쉬워야 한다. | TCO 절감, 더 나은 사용자 경험 |
| 복원력: 오케스트레이션을 통한 단일 서비스의 장애 격리 | 더 나은 사용자 경험, 손실 감소 |
분할 준비
사전 준비하기
모놀리스를 분할하는 단계이다. 비즈니스 요구 사항, 애플리케이션 상태, CI/CD 프로세스를 고려하여 단계를 조정할 수 있다.
기준이 설정되면 모듈/서비스 목록은 비즈니스 기능을 중심으로 구성해야 한다.
리팩토링
분할해야 하는 애플리케이션이 좋은 형태를 가지고 있을 가능성은 거의 없다. 그 애플리케이션 개발되는 시점에는 최선의 선택이었겠지만, 시간이 흐르면 바라보는 관점이 달라지기 때문이다. 따라서 모놀리스에서 리팩토링이 수행될 수 있다.
우리는 각 유형별 Boiler plate를 만들었고, 개발 되는 모든 작업들은 Boiler plate 표준 기반으로 동작되도록 가이드했다. 기존 시스템도 Boiler plate기반으로 리팩토링을 진행했다. 리팩토링을 진행하면서 Controller, Service, DAO등과 같은 애플리케이션의 주요 계층을 이해하고 관찰했다.
서비스/기능 경계 및 API
비즈니스 모델을 모델링하는 대신 기존 애플리케이션에서 비즈니스 기능을 추출해야 한다. 비즈니스 기능을 기존 애플리케이션 서비스 및 도메인 모델에 매핑하여 경계를 식별하기만 하면 된다.
일반적인 모놀리스 시스템에서 컨트롤러는 API를 추출하는데 도움이 된다. 기존 시스템은 DTO 없이 모두 HashMap으로 Request/Response를 처리하고 있었고, DTO 작업을 통해 Request/Response에 대해 미리 파악할 수 있었다.
서비스 외관 작업
서비스 경계가 정의되면 비즈니스 기능을 한 애플리케이션이 처리하는 대신 상호 작용 방식으로 변경해야 한다. 모놀리스 애플리케이션에서 Facade를 만들고 Facade를 통해 작업해야 한다.
서비스를 추출하기 전에 느슨하게 결합된 모놀리스로 리팩토링 되어야 한다.
데이터
데이터베이스로 하나의 서비스를 추출하면 다른 서비스에 영향을 줄 수 있다. 서비스 데이터에 대한 접근은 데이터베이스가 아닌 API를 통해서만 이루어지도록 해야 한다. (통합DB를 사용하더라도, 가능하면 계정을 분리하고 각 서비스에서 제공하는 API를 통해 접근해야 한다.)
이 작업은 상당한 노력이 필요하다. 우리팀의 경우 예기치 않은 Join이 발생했을 경우를 제외하고는 이 정책을 유지하려고 노력중이다.
모놀리스 시스템의 새로운 기능 추가 중단
미니서비스로 분할하는 작업을 진행할 경우, 기존 운영중인 모놀리스 시스템과 병렬로 작업이 수행된다. 이 경우 모놀리스 시스템에 추가되는 기능은 법적인 문제, 버그등으로 제한할 필요가 있고, 신규 기능들은 새롭게 구현되는 미니서비스에서 충족시켜줄 필요가 있다.
사전 준비 마무리
위에서 언급한 단계는 모두 분할전에 수행되어야 한다. 애플리케이션은 세분화된 서비스, API 및 경계, 각 서비스간 데이터 격리의 정책을 기반으로 느슨하게 결합된 모놀리스로 제공되어야 한다.
분할 수행
분할할 서비스 우선 순위 지정
비즈니스 기능/도메인별로 기존 애플리케이션을 재구성/리팩토링/그룹화하려는 시도가 필요하다.
- 가장 자주 변경되는 서비스: 배포에 대한 영향을 최소화
- 외부 서비스로 대체될 수 있는 서비스: 굳이 개발할 필요가 없기에
- 확장해야 할 서비스: 성능을 최적화
- 서비스 복잡성: 자동화된 프로세스 구축
마이크로 서비스간 통신 방식 선택
대부분의 경우 REST 또는 gRPC를 선호한다. 이유는 상대적으로 단순하고, 팀내에 경험자가 많고, 다양한 도구의 지원이 가능하기 때문이다.
서비스 구현
통신 방식을 선택 후, 미니서비스를 구현한다. 기존에 리팩토링된 모놀리스의 코드를 참조한다.
미니서비스 사용으로 전환
구현이 완료되면 통합 테스트 후, 기존 모놀리스에서 미니서비스로 프로덕션 레벨에서 전환한다.
