당사에서는 홈쇼핑 백오피스 시스템에 대해 2018년부터 Application Modernization 마스터플랜을 수립하여
업무 도메인 별 구조개선 작업을 진행 하고 있습니다.
고객, 자산 영역을 시작으로 방송, 주문 ,결제 도메인 영역에서 각각 마이크로 서비스로의 전환 작업이 진행되고 있습니다. 그 과정 중의 하나로 23년 1월부터 SR 도메인에 대한 구조개선 프로젝트를 진행 한 과정을 공유하고자 합니다.
홈쇼핑 프로세스 와 Service Request(SR)
쇼핑몰/홈쇼핑비즈니스에서 "Service Request"는 일반적으로 고객이 상품 또는 서비스에 관련된 사항을 문의하거나 요청하는 것을 의미합니다. 홈쇼핑 고객은 문의, 불만사항, 상품 교환 또는 환불관련 사항을 고객센터에 직접 전화를 하거나, 쇼핑몰상에서 온라인채팅, 1:1 상담, 상품문의, 이메일 등을 통해 요청할 수 있습니다.
콜센터 상담원은 고객의 요청사항을 신속하고 효과적으로 처리하기위해 다양한 정보를 조회하고 처리상태를
관리하고 있습니다.
그림 1처럼 SR 은 모든 서비스에 연관 되어 고객과 쇼핑몰 간의 소통과 상호작용을 원활하게 유지하기 위해 필요한 도메인입니다.
그림 1. 쇼핑몰 프로세스와 SR
프로젝트 배경
레거시 시스템의 문제점 (pain-point)
기존 홈쇼핑 시스템은 업무영역별 대부분의 기능이 하나의 소스 repository로 관리되는 통합(모노리스) 구조입니다.
이러한 모노리스 시스템 구조로 인해, 기능 추가 시 복잡한 현행 시스템 분석으로 개발시간이 오래 걸리고, 개발 후 배포시에도 타 개발자와의 배포 충돌을 피하기 위해 기다리는 경우도 많이 발생했으며, 거대한 규모의 소스코드가 서로 엉켜 있어 영향평가도 쉽지 않았습니다.
또한 10여 년전에 개발된 시스템으로 미사용 기능도 누적되어 있고, 기술적으로 노후화 되어 유지보수 비용도 증가하고 있었습니다. 타 업무영역의 오류로 장애가 발생한 경우, 상담원의 시스템에도 장애가 전파되어수많은 상담원이 시스템을 사용할 수 없는 경우도 발생하였습니다.
전환범위 식별
SR 도메인 영역의 기능은 크게 두 가지로 나눌 수 있습니다.
하나는 온라인상에서 고객이 직접 요청한 SR을 저장하는 기능과, 다른 하나는 상담원이 고객과 직접 통화하면서 SR을 접수하고, 이에 대한 활동들을 이력으로 남기는 기능입니다.
상담원이 사용하는 콜센터시스템의 Front 화면 UI 개편 작업은 별도의 프로젝트로 계획되어 있어, 백엔드 프로그램을 전환대상으로 먼저 진행하였습니다.
프로젝트목표
기존 시스템이 갖고 있는 pain-point를 해결하고자, 프로젝트의 목표를 두가지로 수립하였습니다.
l 시스템의 현대화 : Cloud Native Application 구축 및 IT 표준 기술 업그레이드
l 서비스 경량화 : SR 도메인의 장애격리 및 수시 배포를 위한 독립된 서비스 구축
모노리스에서 마이크로서비스로의 여정
레거시 시스템에 대한 분석
모노리스 구조인 기존 시스템은 WEB과 API 서비스에 대한 요청을 공통으로 제어하고 있었습니다. 그래서 로직은 길고 복잡해졌으며 , 사용 여부를 알 수 없는 코드들로 가득차 있었습니다.
API 서비스는 비교적 간단한 로직으로 구성되어 있고, Web 즉 콜센터 상담원의 서비스가 보다 복잡한 상태였으나 공통으로 관리되다 보다 둘 다 복잡해 보였습니다.
API 서비스를 단순화하기 위해 API용 서비스와 Web Backend 서비스를 분리하기로 결정하였습니다. 코어 로직에 대한 이중 관리 우려도 있었으나, 레거시의 수많은 분기문들은 대부분 WEB 서비스의 요구사항으로 생겨난 것으로 인지하여서, API 서비스의 처리 로직은 본 기능에만 충실 하도록 하는 것을 목표로 하였습니다.
대상 프로그램 정리
기존 시스템을 분석하면서 가장 먼저 미사용 기능과 불필요한 서비스에 대한 정리작업을 진행하였습니다
현 시스템은 시스템 간의 통신을 ESB ( Enerprise Service Bus)를 이용하고 있습니다.
ESB 기능을 API로 전환 하기 위해 ESB 인터페이스 정의서를 기반으로 설계를 진행하되, 실 로그 정보와 호출하는 클라이언트 시스템에 실 사용 여부를 재확인하였습니다.
그 결과 총 60 여개의 ESB 목록에서 미사용을 제거하여 26개로 줄였고, API 설계 과정에서 중복된 기능을 정리하여 다시 10여 개로 대상을 줄일 수 있게 됩니다.
WEB 서비스 또한 메뉴 접근 로그 데이터를 토대로, 실 사용 없는 메뉴 서비스에 대해서는 주요 사용자들과 확인을 통해 대상 프로그램을 제외 처리 하는 과정을 거쳐 20% 정도의 미사용 기능을 제거할 수 있었습니다.
아키텍처 환경 및 설계
사내 인프라 관리 정책이 기존 IDC 환경에서 클라우드 환경으로 전환하고 있으므로, 인프라 및 애플리케이션을 클라우드 환경에 구성하였습니다.
빌드/테스트 배포 환경 또한 자동화되어 있어 지속적인 통합과 배포가 가능하였습니다.
멀티모듈 구성
API와 Web 서비스를 분리하면서 공통 기능은 공유할 수 있도록 4개의 멀티 모듈로 프로젝트를 구성하였습니다.
독립적으로 어플리케이션을 실행하는 Web 과 API모듈은 공통 Domain모듈과 Outer 모듈을 포함하여 기동 됩니다.
Domain 모듈에는 DB Entity 클래스들과 Repository를 포함하고, Outer 모듈은 공통 Util 성( 예를 들어 파일 업로드, 메일 발송 및 타도메인에 대한 호출 처리) 에 대한 Interface 기능들을 분리하여 구성하였습니다.
데이터 분할 작업
SR 도메인에 대한 서비스 독립성을 확보 하기 위해, SR 도메인에서 타도메인 참조하는 경우와 타도메인에서 SR을 참조하는 대상을 전수 조사 하였습니다.
SR에서 타도메인들에 대한 참조를 식별하고, SQL Query의의 Join 은 모두 풀어 여러 개의 쿼리들로 분해하고
논리적 DB 분리를 위해 DB 계정을 별도로 생성, 도메인 영역에 대한 권한 제어를 두었습니다.
WEB 서비스 화면의 경우 주문, 상품, 고객 정보를 기본적으로 같이 보여 주는 경우가 많기 때문에 애플리케이션 레이어에서 조합하여 처리할 수 있도록 진행하게 됩니다.
External Service 구성 : 타 도메인 데이터 접근
타 도메인에 대한 정보 조회는 external 서비스를 별도로 구성하여 자체적으로 개발을 진행하고, 각 도메인 업무 운영 팀에 요청하여 순차적으로 API를 교체하는 작업을 진행하게 됩니다.
이는 본 프로젝트의 진행 일정은 맞추면서 , 자체 검증 이후에 필요한 인터페이스 항목을 요청 함으로써 불필요한 API Contract에 대한 협의 과정을 최소화할 수 있었습니다.
External Api 서비스의 기능 교체는 Feign을 이용하여 운영 서비스에 영향이 없이 교체가 가능하였습니다.
서비스 1차 오픈 이후 주문 정보를 제공 하는 API는 3-4 차례 단계를 거쳐 자체 external API에 주문팀에서 제공하는 Microservice API로 교체를 완료하였고, 이후 타 영역 또한 API 가 제공 되는 시점에 순차적으로 교체해 나갈 예정입니다.
l Feign
넷플릭스에서 만든 API client 라이브러리로 interface와 annotation 구현으로 간단하게 RestTemplate 기능을 대체 가능 합니다. Feign Client 별로 Header 나 , Timeout 등을 설정할 수 있습니다.
https://docs.spring.io/spring-cloud-openfeign/docs/current/reference/html/
통합 테스트, UAT
운영 중 시스템을 신규 시스템으로 교체하는 프로젝트이다 보니, 전환 전후의 동일한 서비스가 유지될 수 있도록 검증하는 것이 관건이었습니다.
API 서비스는 동일한 요건으로 기존 ESB와 신규 API를 테스트하여 기능 테스트뿐 아니라, 데이터 비교를 통해 기능의 완성도를 높이고자 노력하였습니다.
Web 서비스는 테스트 사용자 계정을 기준으로 기존 서비스와 신규 서비스 사용을 분기 처리 하고, 동일한 동작 및 데이터가 노출되는지를 확인하는 방식으로 진행하였으며, 현업(콜센터 상담원) 분들의 적극적인 지원 덕분에 가능할 수 있었습니다.
점진적 오픈 전략
SR서비스는 고객의 불만이나 문의를 처리하는 시스템으로 시스템의 가용성이 중요합니다.
서비스 장애시 고객 문의 접수 자체가 되지 않거나 상담원 업무 처리에 대한 지연으로 인해 고객 불편이 가중 되게 될 것이기 때문입니다. 따라서 장애가 발생 하더라도 장애시간을 최소화 하고, 서비스를 빠르게 정상화 하는 것과, 점진적으로 오픈 하여 안정적으로 운용 할 수 있도록 전략을 수립 하였습니다.
API 서비스는 오픈후 모니터링이나 알림 장치를 통해 이상 징후 감지를 감지하게 되면 배포 없이 신속하게
기존 ESB 서비스로 전환 할 수 있도록 스위칭 체계를 준비 하였습니다.
서비스를 오픈하면서 방화벽 이슈부터, 필수 파라미터 누락 등 여러 가지 상황들이 발생하였지만, 스위칭 기능으로 인해 빠르게 장애 전파를 막고 조치 대응 할 수 있었습니다.
WEB 서비스는 대상 기능을 3개 그룹으로 나누어 영향도가 적은 순으로 단계별 오픈을 진행하였고, 기능을 사용 할 수 있는 사용자를 특정 하여 오픈 함으로써 안정성을 확보하였습니다. 서비스 오픈시 이상 감지는 상담원으로부터 빠르게 피드백을 받을 수 있도록 핫 채널을 열어 소통하였습니다. WEB 서비스 또한 스위칭 체계를 통해 배포 없이 기존 기능으로 원복 하고 신속하게 조치 하였습니다.
로깅, 모니터링
서비스 어플리케이션 로그는 통합 로그 시스템이 구축되어 있어, Open Search로 로그 분석을 사용할 수가 있었습니다.
분산 환경에 대한 로그 추적을 용이하게 하기 위해서 Sleuth를 적용 하였고, Traceid 와 SpanID 를 통해 서비스간 로그를 확인할 수 있게 되었습니다.
l Sleuth
형사라는 뜻으로 분산된 마이크로 서비스 간에 트래픽의 흐름을 추적할 수 있도록 Trace 기록을 로그에 자동 삽입해 줍니다. ( sleuth는 Micrometer로 대체되었다고 합니다.)
https://spring.io/projects/spring-cloud-sleuth
또한 MDC(Mapped Diagnostic Context)를 활용하여 Request/Response 에 추가적인 값을 기록하고
해당 Key 값을 Elastic Search 에 추가 인덱싱 하여 로그 검색 필터로 활용 할 수 있게 하였습니다.
이렇게 수집된 데이터를 기반으로 DashBoard 구성 및 알람 서비스를 통해 서비스 이상 현상에 대해 조기 감지 할 수 있게 하였습니다.
프로젝트 회고 및 향후 진행 방향
이번 프로젝트가 큰 장애(?) 없이 서비스 오픈 할 수 있었던 것은, 홈쇼핑 시스템에 경험이 많은 시니어 개발자분들과 운영 경험이 많은 PL , 현업의 적극적인 지원으로 연계 테스트 및 이행 전략을 안전하게 가져 갈 수 있었기 때문입니다.
긴말이 필요 없는 팀워크 였다고 생각 합니다.
또한 연계 채널 서비스 오픈을 위해 협업해 주신 유관 부서원들과 인프라 환경 및 CI/CD 지원해 주신 클라우드 팀원분들의 지원으로 더 든든했던 프로젝트 였습니다.
모놀리식 시스템을 마이크로서비스 아키텍처로 한 번에 옮기는 것은 어렵습니다 !!
따라서 단위를 작게 세분화하여 요구사항에 맞는 서비스부터 점진적으로 전환해 나가는 것이 성공 가능성을 높일 수 있습니다.
이번 SR 구조 개선 프로젝트는 마이크로 서비스 전환을 하기 위한 과정에서 작게 실행해 보는 단계였고, 이번 프로젝트를 통해 다음 두번째, 세번째 를 더 쉽게, 추진할 수 있는 경험을 얻었다고 볼 수 있습니다.
마이크로서비스로의 여정은 아직 끝나지 않았습니다... To be Continued...
장 진 (Jeany) | 디지털서비스본부 > 홈쇼핑서비스부문 > 고객/상품 서비스팀
홈쇼핑 기간계 구조개선 업무를 담당하고 있습니다.
Live Life with no excuse
'APP' 카테고리의 다른 글
| 엔터프라이즈 MSA 이야기 4탄 – GS SHOP 주문서비스팀의 현대화 여정 (2) | 2023.10.25 |
|---|---|
| Flutter Code Push의 고찰 (7) | 2023.10.11 |
| 우리동네GS BFF 구현기 Step 1 - 도입 배경과 설계 (1) | 2023.07.28 |
| Flutter App 실시간 CDN 이미지 변경 상태 적용 방안 (1) | 2023.06.20 |
| 엔터프라이즈 MSA 이야기 2탄-RateLimit 적용으로 시스템장애 예방하기 (0) | 2023.06.20 |