상품 상세페이지 개편과 안정적 서비스를 위한 독립적 구조 설계

이번에 CJ온스타일 상품 상세페이지 개편 프로젝트를 진행하며 Back-End 개발자로서 고민한 것들을 회고해 보았습니다.

프로젝트 이야기는 아래에서 자세히 보실 수 있어요.

[온스탕탕] 상품 상세페이지를 개편하고 클릭률이 .. 더보기

1st, Application 서비스 별로 독립적인 배포와 안정적인 서비스를 제공하자

1) Application Service Architecture 변경

아래 그림에서 볼 수 있듯이 상품 Front-WEB 서비스와 Front-API가 하나의 서버에서 서비스 되고 있었으나 To-Be 구조는, 서비스 별로 서버를 가지고 독립적으로 빌드/배포가 되도록 MSA 아키텍처를 적용해 보았습니다.

(Front-API 서버가 꼴까닥 하려고 그래도 Front-WEB 서비스는 문제 없겠쥬?)

2) 대외 API 호출에 Circuit Breaker 적용

고객에게 다양한 서비스를 제공하기 위해 외부 솔루션의 API 도 빈번히 발생하고 있는데요.

(외부 솔루션이 장애 상황이면.. 우리 서비스도 같이 장애? 😥)

우리 서비스 장애를 최소화 하기 위해 Circuit Breaker 를 적용하였습니다.

Circuit Breaker?
분산 시스템에서 장애를 처리하고 시스템 안정성을 유지하기 위한 디자인 패턴입니다. 이 패턴은 외부 서비스 호출이나 데이터베이스 쿼리와 같은 리소스에 대한 요청을 관리하는 데 사용됩니다. 장애 발생 시 Circuit Breaker는 해당 호출을 중단하여 시스템의 과부하를 방지하고, 일정 시간이 지나거나 서비스가 회복되면 다시 시도할 수 있도록 합니다. 이는 시스템 전체의 안정성을 유지하고 장애를 겪은 서비스에 대한 부하를 방지합니다. from.chat GPT

#따라하기

A. 오픈소스 라이브러리를 온스타일 시스템에 Dependency 설정

B. Circuit Breaker 의 동작환경 설정

C. 외부 솔루션을 호출 메서드에 적용

• 외부 솔루션 호출하는 메서드에 @CircuitBreaker 어노테이션으로 손쉽게 사용
• 외부 호출 메서드가 실패 시 실행될 메서드 생성

2nd, UI Component 에 맞춰 간결하고, 가벼운 API 를 제공하자

기존에 제공하고 있던 상품정보 API는 엄청 많은 데이터와 비지니스 로직을 품고 있는 뚱뚱한 API를 제공하고 있었는데요,

API 설계 계획대로 전체가 진행되지는 못해서 아쉽…

TO-BE API 는 UI 컴포넌트에서 필요한 데이터만 심플하고, 가볍게 데이터를 제공하기 위해 API 설계를 진행했습니다.

상품 상세 개편 프로젝트를 진행하면서 외부 솔루션 2개 도입과 Compact API 를 만들기 위해 분석/설계를 함께한 EunJI 님한테 고마움을 전하고 싶습니다.

글 솜씨가 없는데 포스팅에 도움을 주신 하늘 님도 감사합니다.

취향공감 라이브쇼핑 — CJ ONSTYLE