MSA 백엔드 분리작업

코드너리 | 2022. 03. 01

MSA

사용된 기술:

Legacy Service

서비스별 의존성 분리 작업을 진행합니다.
- 직접 관리하는 DB 테이블이 아닌 경우 DB 계정의 권한 제어를 이용하여 접근하지 못하게 막습니다.
- 접근 권한이 없어 가져오지 못하게 된 Json필드는 Empty 또는 ID만 응답합니다.
사용하지 않게 된 코드를 모두 삭제합니다.
코드 개선이나 버그 수정은 진행하지 않습니다.

Aggregator

레거시 API 인터페이스를 유지하기 위한 Abstraction Layer 역할을 수행합니다.
- 여러 마이크로서비스의 응답을 조합하여 기존과 100% 동일한 결과를 만들어 줍니다.
- 새로 만드는 기능은 Aggregator를 사용하지 않도록 설계합니다. (아래 BFF 를 사용합니다.)
개발하면서 @Deprecated를 추가하는 코드들입니다. 비즈니스로직과 코드를 최소화합니다.
- Aggregation이 필요한 필드로만 DTO(Data Transfer Object)를 생성합니다.
- 응답에 A, B, C 필드가 있지만 B만 Aggregation이 필요하다면 Aggregator의 DTO에는 B만 선언합니다. A, C 는 공통 로직에 의해 ByPass됩니다.

개발 편의를 위해 Spring Cloud Gateway와 CustomFilter를 활용하였고, 앞서 소개해 드린 멀린 님의 공통 모듈을 적용하였습니다. 공통 모듈은 기본적으로 Reactive Stream과 Coroutine을 지원하기 때문에, 다른 마이크로서비스에서 필요한 정보를 병렬로 요청하고 Aggregation해서 응답속도도 개선되었습니다.

Microservice

브레인스토밍 과정에서 명확하게 분리가 가능한 서비스를 대상으로 시작합니다.
초기에는 타서비스와의 연동 시 레거시 서비스를 은닉하기 위한 Abstraction Layer로도 동작합니다.
데이터베이스의 분리 등을 진행하면서 Abstraction Layer에서 서비스로 진화합니다.

Backend For Frontend

마이크서비스로 개선했다고 하더라도 하나의 Aggregator로 API 응답을 의존하는 방식을 사용한다면, 플랫폼별 새로운 기능을 추가할 때마다 걸림돌이 될 수 있습니다. 실제 오늘의집 구버전 API를 분석해 보니 코드 안에 플랫폼에 대한 분기문이 생각보다 많이 존재하고 있었고 관리가 쉽지는 않았습니다. 개발 시 리소스가 조금 더 들어갈 수 있지만, 유저의 관점에서 가장 최적의 서비스를 제공할 수 있을 것이라 판단하여 BFF 패턴도 도입하기로 하였습니다.

BFF를 도입하면 CX(Customer Experience) 관점에서 플랫폼별 최적의 기능을 제공할 수 있고, 하위 버전에 대한 코드나 긴급 대응을 위한 분기 처리도 별도 관리가 가능합니다.
각 플랫폼이 잘하는, 잘 아는 방법을 제약 없이 사용할 수 있습니다. 안드로이드는 gRPC, 웹은 graphQL, iOS는 RestAPI를 사용할 수도 있습니다.
(이론상) 사용하지 않는 데이터는 조회하지 않아 리소스의 효율을 높일 수 있습니다.

Traffic Shadowing

가장 최신 버전을 기준으로 QA까지 마무리되었지만, 유저들이 사용하는 모든 앱에 대한 검증이 완료되었다고 할 수는 없었습니다. 마이크로서비스로 전환된 시스템을 서비스에 투입하기 전에 트래픽 쉐도잉을 통한 GET 메소드 요청에 대한 검증을 진행하기로 했습니다.

Y-Pipe-Gateway(Shadow Gateway)에서 레거시 시스템에 전달한 요청을 마이크로서비스 Aggregator에 Async로 요청합니다.
레거시 시스템과 Aggregator의 응답을 Kafka로 전송합니다.
Diff Cheker에서 두 개의 응답을 비교한 후 다를 경우 Slack으로 알려줍니다.
- 위에서 여러 번 강조했던 “코드 개선이나 버그수정은 진행하지 않습니다.”라는 룰이 깨진 경우 이 단계에서 감당할 수 없는 스팸 메시지를 받게 될 수 있습니다.
코드상 문제가 발견된 경우 마이크로서비스 코드를 수정하고 재배포한 후 모니터링합니다.
Known Issue인 경우 알림이 오지 않도록 예외 처리합니다.