‘오네’(O-NE) 배송을 오네가이시마스 — 레거시 API 떠나보내기
안녕하세요. CJ온스타일 상품서비스개발팀 김동민입니다.
CJ온스타일은 상품을 구매하는 고객들에게 CJ대한통운이 론칭한 ‘판매자와 구매자를 잇는 통합 배송’ 브랜드인 ‘오네’(O-NE) 배송정보를 노출시키기 위해 ‘오네’(O-NE) 배송 서비스 고도화 프로젝트를 진행했습니다.
오네(O-NE) 배송 서비스 고도화 프로젝트
상품서비스개발팀은 상품상세 API와 전시, 검색, 장바구니 영역을 위한 Spring Batch, 어드민 시스템 등 상품 관련 전반적인 영역을 담당했습니다.
특히, 상품 상세 화면에 필요한 배송 정보 레거시 API를 신규 API 서버로 전환하는 작업을 중점적으로 수행했습니다. 이번 글에서는 신규 API 전환기를 회고하고자 합니다.
Why?
상품 레거시 API에는 오래전부터 인지되어온 한 가지 이슈가 있었습니다.
바로 MLC(Mobile-Live Commerce) API와의 높은 결합도입니다.
MLC API를 개발할 당시, MLC 편성 정보 조회 메소드를 방송 편성 정보 조회 공통 메소드에 추가하였고, 시간이 지나면서 이 공통 메소드를 장바구니, 마이존, 상품, 전시 등 여러 영역에서 사용하게 되면서 불필요한 결합도가 높아졌습니다.
이로 인해 MLC API 호출 빈도가 증가했고 불필요한 네트워크 비용이 발생하였습니다. 또한, MLC API 타임아웃 이슈가 발생하면 상품 서비스에도 영향이 미치는 문제가 생겼습니다.
따라서, API 간 결합도를 낮춰야 했습니다.
사실, 상품 API에 캐싱과 분기처리 등의 작업을 통해 MLC API 호출 빈도를 줄여 왔으나, 완전히 해결되지는 않았습니다.
마침, ‘오네’(O-NE) 배송 서비스 고도화 프로젝트를 통해 신규 API로 개선하고, 불필요한 네트워크 비용을 줄일 수 있는 일석삼조의 기회가 생겨 과감히 이관을 결정하게 되었습니다. 👏🏼👏🏼👏🏼
(의견 주신 JEFF Ahn님께 감사드립니다🙇🏻♂️)
Problem!
AS-IS 상품상세 배송 정보 영역을 위한 API는 오래전부터 유지보수되어 온 이른바 ‘레거시 소스’로 구성되어 있었습니다.
이 레거시 API에는 다음과 같은 문제점들이 있었습니다.
- 전설로 전해지고 있는 JBoss/Wildfly 서버로 구성되어 있어 개발 환경 설정과 서버 Restart에 많은 시간이 소요되며, 리소스를 많이 사용하는 무거운 서버로 알려져 있음
- 낮은 Spring Framework 버전
- 이미 지원이 종료된 Java 1.7
- 스파게티 소스
- 데드 필드로 Over-Fetching 된 JSON Response
- 코드 가독성이 떨어지고 데드 코드가 굉장히 많음
(@Deprecated 처리를 하더라도 호출해서 사용하면 무의미하다) - API 간 결합도가 높아 배송영역에서 불필요한 방송편성 정보를 조회함
Resolve!
레거시의 단점을 해결하기 위한 신규 API는 다음과 같은 장점이 있습니다.
- Spring boot 2.X 버전으로 개발환경 세팅과 서버 Restart가 빠름
- Java 1.8
(공식 릴리스된 Java 버전 중 비교적 높은 버전은 아니지만, 유지보수 기간이 넉넉하며 Lambda와 Stream을 활용할 수 있다)
- 높은 가독성
- 데드 코드 최소화
- API 간 결합도를 낮추어 방송편성 정보를 조회하지 않아 불필요한 네트워크 비용을 줄일 수 있음 (핵심!)
Design!
신규 API는 BFF(Backend For Frontend) 디자인 패턴에 따라 필요한 각 API 서버를 호출하고 있으며, 전반적으로 MSA(Microservices Architecture) 구조를 따릅니다.
BFF(Backend For Frontend) 패턴은 아래와 같은 장점이 있습니다.
- 프론트엔드에 최적화된 API 제공
- API 서버로부터 데이터를 통합 및 변환하여 프론트엔드에서의 복잡한 데이터 처리를 감소
- API 확장성이 좋음
이에 더하여, 각 API 서버는 최대한 원본 데이터를 제공하도록 하여 필요에 따라 재활용할 수 있도록 설계하였습니다.
위와 같은 BFF(Backend For Frontend) 패턴의 여러가지 장점과 현재 온스타일 서버 구조에 적합하기에 BFF 패턴을 활용하는 방식으로 개발을 진행하였습니다.
Results!
결과적으로 TO-BE 배송정보 API에서 MLC API를 더이상 호출하지 않는다는 것을 확인하였습니다.
따라서, MLC API 호출 빈도를 줄인 만큼의 불필요한 네트워크 비용도 절감할 수 있었습니다.
또한, BFF(Backend For Frontend) 서버에서 각 API 서버를 호출하는 Feign Client 에 Redis @Cacheable 어노테이션를 추가하여 평균 응답 시간(Elapsed)을 감소시켰습니다.
추가로, 데드 코드를 제거하여 Over-Fetching 문제를 해결하였고 DTO 용도를 명확하게 나누어 API 가독성과 운영 효율성을 높일 수 있었습니다.
Behind-the-scenes 1) 프론트개발팀과의 협의
레거시 배송영역 API를 호출하는 프론트 영역의 전반적인 검토와 영향도 파악이 필요했고, 프로젝트 일정 협의가 필요했습니다. 또한, 프론트개발팀의 추가 공수가 발생하여 신규 API 전환 작업을 계속 진행할지 고민되었습니다.
그러나!
CJ온스타일 상품 서비스 개선을 위해 신규 API 이관 작업에 적극 협조해 주신 프론트개발팀 상상상님께 감사드립니다.
Behind-the-scenes 2) Buggggggg!
운영 중인 서비스에 신규 API를 적용하면서 배송 예정일 일부 케이스에서 API 응답 예외처리가 되지 않아 급히 버그를 수정 배포하는 수모(?)를 겪었지만,
항상 실패를 통해 배우듯.. 같은 실수는 두 번만 안하면 된다는 말처럼..
이번 과오를 통해 예외 케이스에 대해 한 번 더 검토하자는 생각이 뉴런 속에 깊게 자리 잡게 되었습니다.
마치며
앞으로도 상품서비스개발팀은 상품 서비스 개선을 위해 레거시 API를 최소화하고 MSA(Microservices Architecture) 구조에 적합한 신규 API로 점진적으로 이관할 계획입니다. 또한, API 성능 개선을 위한 방법을 계속해서 모색할 것입니다.
긴 글 읽어주셔서 감사드립니다. 👋
