상품 상세페이지 개편과 안정적 서비스를 위한 독립적 구조 설계
이번에 CJ온스타일 상품 상세페이지 개편 프로젝트를 진행하며 Back-End 개발자로서 고민한 것들을 회고해 보았습니다.
프로젝트 이야기는 아래에서 자세히 보실 수 있어요.
1st, Application 서비스 별로 독립적인 배포와 안정적인 서비스를 제공하자
1) Application Service Architecture 변경
아래 그림에서 볼 수 있듯이 상품 Front-WEB 서비스와 Front-API가 하나의 서버에서 서비스 되고 있었으나 To-Be 구조는, 서비스 별로 서버를 가지고 독립적으로 빌드/배포가 되도록 MSA 아키텍처를 적용해 보았습니다.
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를 제공하고 있었는데요,
TO-BE API 는 UI 컴포넌트에서 필요한 데이터만 심플하고, 가볍게 데이터를 제공하기 위해 API 설계를 진행했습니다.