11번가 기술블로그입니다. 고객으로부터 신뢰받는 최고의 커머스 플랫폼을 향한 개발문화와 기술을 공유합니다. https://11st-tech.github.io/ Wed, 26 Nov 2025 17:25:17 +0900 Wed, 26 Nov 2025 17:25:17 +0900 Jekyll v3.10.0 늘어나는 트래픽, 늘어나는 서버: 한계를 돌파하다 안녕하세요. 11번가 전시서비스개발팀에서 백엔드를 담당하고 있는 서장원입니다. 이번 글에서는 고객이 11번가에 처음 진입하는 관문인 전시서비스를 더 비용 효율적으로, 그리고 대량 트래픽 환경에서도 안정적으로 운영하기 위해 전시서비스개발팀의 김민교 님과 함께 고민하고 풀어나갔던 과정에서 다뤘던 주요 개선 포인트를 중심으로 소개합니다. 목차 미리보기: 핵심 개선 포인트 들어가며 트래픽의 꾸준한 증가 - 전시API 서버(DPWAS) 운영방식의 한계와 새로운 전략 협업 전략: 구조 개선과 최적화 개선과정(Tune Up + Fix in!) 1) 원인불명의 CPU Spike 발생: MongoDB 커넥션 재생성 부하 CPU Spike 원인 1 : 노후장비 서버 CPU Spike 원인 2: MongoDB 커넥션 재생성 부하 집중 CPU Spike 해결책: 집중된 CPU 부하를 분산시키자 2) 지연 트랜잭션을 줄여보자 커넥션 풀 사이즈 확보 재시도 기능 제어 대량 조회 분할을 통한 command 부하감소 3) 서버 리소스 관리와 성능 최적화 로컬 캐시 최대 사이즈 설정 캐시키 정렬 처리 대량 데이터 호출 로직 개선 기타 API 성능 개선 정리: 3가지 핵심 개선포인트 최종 트래픽 결과 AS-IS (MAX TPS: 65.9K) TO-BE (MAX TPS: 87.9K) 마치며 미리보기: 핵심 개선 포인트 들어가기 전에, 최적화 작업에서 핵심적으로 다룬 3가지 개선 포인트를 미리 소개하면 다음과 같습니다. CPU 스파이크 분산: MongoDB 커넥션 재생성 시간 분산으로 CPU 부하 안정화 지연 트랜잭션 병목 개선: 재시도 정책 조정 및 커넥션 풀 확충 서버 리소스 관리... Wed, 26 Nov 2025 00:00:00 +0900 https://11st-tech.github.io/2025/11/26/dpwas-improvement/ https://11st-tech.github.io/2025/11/26/dpwas-improvement/ java MongoDB spring-boot gc cache monitoring 목차 들어가며 시스템 구성 및 개선 배경 주요 이슈 분석 1. 이슈 1: Micrometer 객체 증가 현상 2. 이슈 2: 메모리 점진적 증가 현상 최종 결론 마무리하며 들어가며 안녕하세요. 주문플랫폼개발팀 이경진입니다. 최근 주문플랫폼개발팀과 쿠폰/PCS개발팀이 함께 진행한 최대할인가 구조 개선 과정에서 예상치 못한 몇 가지 성능 이슈를 마주하게 되었습니다. 이 글에서는 함께 논의하며 문제를 해결해 나갔던 과정을 되짚어보고, 어떤 이슈가 있었고 어떻게 대응했는지 공유하고자 합니다. 시스템 구성 및 구조 변경 해당 서비스는 다음과 같은 환경에서 운영 중입니다: JDK 21 Spring Boot 3.2.1 CompletableFuture 기반 병렬 처리 구조 기존에는 할인 계산에 필요한 데이터를 외부 API(Spring Boot 2.x) 를 통해 조회하는 구조였으나, 해당 API 로직을 내부 서비스(Spring Boot 3.x) 로 이관하며 구조를 변경하였습니다. 주요 이슈 분석 1. 이슈 1: Micrometer 객체 증가 현상 문제 서비스 개선 이후 메모리 사용률이 점점 상승하였으며, GC가 정상적으로 발생해도 Meter$Id, Tag, ImmutableTag 객체가 Old 영역에서 정리되지 않고 계속 쌓이는 현상이 발생하였습니다. 원인 분석 변경된 부분 기존: 쿠폰 API 1회 호출로 필요한 데이터를 한 번에 조회 변경: 쿠폰 API 로직이 서비스 내부로 이관되어, 상품 단위로 여러 DB 조회 + 다수의 API 호출 수행 호출 API 예시: 상품 정보: /api/products/{productNo}/~ 회원 정보: /api/members/{memberNo}/~ 기획전 정보: /api/plan/{productNo}/~ 변경된 부분이 미친 영향 Spring Boot 3.x에서는 Micrometer가 기본적으로 활성화되어 있으며, Micrometer는 HTTP 요청의... Thu, 29 May 2025 00:00:00 +0900 https://11st-tech.github.io/2025/05/29/maxdsc-memory-issue/ https://11st-tech.github.io/2025/05/29/maxdsc-memory-issue/ java spring-boot gc monitoring 11키티즈 게임에서 XState를 선택한 이유 11키티즈 게임에서는 주요 비즈니스 로직 구현을 위하여 XState를 선택했다. 일반적인 프론트엔드 개발에서는 React의 useState, Redux, Zustand 등을 사용하여 상태를 관리하지만, 게임이라는 특수한 환경에서는 상태 전환의 명확성과 개발 생산성 및 품질 관리가 중요하다고 판단했기 때문이다. 이 글에서는 왜 웹 어플리케이션 게임 개발에서 XState가 효과적인지, 크게 두 가지 측면에서 그 이유를 설명하고자 한다. 1. 개발 생산성과 품질: 유한 상태 머신의 명확성 React는 본질적으로 ‘무한 상태 머신(Infinite State Machine)’이다. 즉, 상태가 조건이나 사용자 입력에 따라 자유롭게 변화하며, 무한한 상태 조합이 발생할 수 있다는 의미다. 이로 인해 복잡한 상태 전환 로직을 관리하기 어렵고, 상태 간의 의존성이 얽히기 쉬워져 버그 발생 가능성 또한 높아진다. 반면, XState는 ‘유한 상태 머신(Finite State Machine)’을 기반으로 한다. 유한 상태 머신은 정해진 상태와 명확한 전환 규칙을 선언적으로 정의하여 상태를 엄격히 제한한다. 각 상태에서 허용되는 전환을 명확히 명시하고, 각 상태의 동작을 완벽히 격리하여 관리할 수 있다. 이로써 코드 유지보수가 용이하고 예기치 못한 오류 가능성을 줄일 수 있다. 일반적으로 게임은 매우 많은 상태의 조합을 통해 게임 화면과 동작을 구현한다. 예를 들어 플레이어 캐릭터가 ‘대기’, ‘이동’, ‘공격’, ‘방어’ 등 명확한 상태를 가질 때, XState는 각 상태에서 허용 가능한 전환만을 명시적으로 정의하도록 한다. 이는 정의되지 않은 상태 전환을 원천적으로 방지하여 예기치 않은 버그나 오작동의 위험을 크게 줄인다. 이번 프로젝트인... Wed, 16 Apr 2025 08:50:30 +0900 https://11st-tech.github.io/2025/04/16/11kitties-xstate/ https://11st-tech.github.io/2025/04/16/11kitties-xstate/ frontend xstate 들어가며 안녕하세요. 11번가 검색/추천 서비스 개발팀에서 11번가 검색 서비스의 프런트엔드 개발을 담당하고 있는 김다미, 이호찬입니다. 검색 서비스의 프런트엔드 파트에서는 검색 결과를 큐레이션하여 사용자가 원하는 상품을 더욱 쉽게 탐색할 수 있도록 돕는 다양한 형태의 UI를 개발하고 있습니다. 11번가 검색 서비스는 사용자의 클릭과 구매 전환율 등 다양한 활동 지표를 바탕으로, 더 나은 탐색 경험을 제공하기 위해 지속적으로 발전하고 있습니다. 또한, 상품을 탐색하는 사용자와 상품을 연결하는 핵심 통로로서, 전시, 상품상세, 주문, 배송, 혜택, 아마존 등 다양한 도메인의 신규 정책에 발맞춰 빠르게 변화해야 하는 역할을 담당하고 있습니다. 검색 결과 페이지 이러한 변화에 최소한의 비용으로 빠르게 대응하기 위해, 구조를 ‘민첩성’과 ‘유연성’을 갖춘 형태로 개선하고자 했습니다. 그러나 기존 검색 서비스의 PC와 모바일 코드는 상반된 설계 스타일을 가지고 있었기에, 어느 스타일을 기준으로 통합할지에 대한 깊은 고민이 필요했습니다. 이 과정에서 ‘어떤 코드가 좋은 품질의 코드인가?’라는 질문을 끊임없이 던지며, 검색 서비스의 특성에 적합한 컴포넌트를 설계하고 개선해 온 경험을 이번 글에서 공유하고자 합니다. 검색 리스팅과 컬렉션 검색 페이지에서 상품은 크게 (1) 리스팅과 (2) 컬렉션이라는 두 가지 유형으로 구분됩니다. 리스팅은 검색 페이지의 표준 UI로, 여러 상품을 묶어 나열하는 방식입니다. 상단에는 상품의 특성을 플래그나 텍스트 형태로 표시하고, 중간에는 주요 상품 정보를, 하단 확장 영역에는 리뷰와 같은 부가 정보를 노출하는 구조로 설계되어 있습니다. 컬렉션은 특정 목적에 따라 상품을 큐레이션하여 다양한 형태로 보여주는 UI로,... Mon, 25 Nov 2024 00:00:00 +0900 https://11st-tech.github.io/2024/11/25/search-service/ https://11st-tech.github.io/2024/11/25/search-service/ frontend React 안녕하세요, 11번가 전시서비스개발팀의 서장원입니다. 전시 딜 내재화 업무를 맡아 진행했던 과정과 개선 작업이 갖는 의미에 대한 개인적인 회고를 공유해 보고자 합니다. 내용 이해를 돕기위해, 기초적인 질문을 던져봅니다. 출처: https://chimhaha.net/story/111311 ‘딜’ 그리고 ‘내재화’ 라는게 무슨 뜻인가요? 딜은 상품 판매를 위한 판촉행사라고 생각하면 쉽습니다. 예를 들어, 단 10일간! 사과 한 박스에 단돈 3만원! 내재화는 외부 기술/데이터를 가져와서 우리만의 특성에 맞게 조정하고 직접 관리한다는 뜻입니다. 즉, 상품의 판촉행사 정보를 보여주는 영역에 필요한 정보는 우리 전시서비스개발팀에서 직접 구축하고 입맛에 맞게 최적화 시킨다는 뜻입니다. 왜 내재화 하나요? 내재화하는 이유는 간단히 말해, 전시에 사용하는 딜 정보를 최적화 시켜서 더 쉽고 빠르게 유지 보수 하기 위함입니다. 아래 이미지에서처럼 이미 THOR 플랫폼 에서 전시에 사용하는 상품정보는 내재화(with MongoDB)가 완료된 상태였고 딜 정보(=행사정보)는 내재화하기 전 반정규화 테이블(with OracleDB)을 사용하고있는 상태입니다. 다시 말해, [행사 판매 중인 상품] 정보를 가져오기 위해 상품정보는 MongoDB에서, 딜정보는 Oracle에서 조회하여 조합하고 있었습니다. 이러한 조회방식은 아래와 같은 단점을 지니고 있습니다. 매 호출마다 두 번, 서로 다른 DB에 커넥션을 받아야 하는 낭비 개발이나 이슈 발생 시 딜정보인지 상품정보인지에 구분하여 디버깅 필요(관리 포인트 중복) 전시서비스개발팀에서 즉각 대응/수정 가능한 상품정보와 달리, 딜정보는 OracleDB 관리 팀에 요청하는 프로세스로 개발과정 단위 테스트와 즉각적인 대응에 어려움 이를 반정규화 MongoDB로 전환하면 위의 단점을 극복하고 MongoDB의 장점을 그대로 살릴 수 있습니다. 탈 오라클(비용 절감,... Fri, 07 Jun 2024 00:00:00 +0900 https://11st-tech.github.io/2024/06/07/retrospective-deal-internalization/ https://11st-tech.github.io/2024/06/07/retrospective-deal-internalization/ java ApacheKafka spring-batch MongoDB 안녕하세요. 11번가 클레임개발팀 박지훈입니다. 중앙 집중식 데이터베이스를 영역별로 분리하는 탈중앙화를 대비하여 분리 대상 테이블을 참조하고 있는 쿼리를 분리하고, 이관하는 작업을 진행하고 있습니다. 코드를 이관하는 과정에서 가장 중요한 부분은 as-is, to-be 결과를 비교하는 부분일 텐데요. 기존 결과 비교를 위해 이관 전/후 로직을 실행하는 부분이 순차적으로 실행되다 보니 전체적인 실행시간이 두 배로 증가하는 문제를 마주하였고, 1초 차이로 조회 결과가 달라지는 경우 이관 전 로직 실행이 완료된 이후 이관 후 로직이 실행되면서 정상 케이스임에도 결과 비교가 실패하는 문제를 발견하게 되었습니다. as-is, to-be 로직을 순차적으로 실행하면서 발생하는 실행 시간 증가 문제와 1초 차이로 조회 결과가 달라지는 문제를 마주하여 안전한 이관을 위해 개선의 필요성을 느끼게 되었고 이 문제를 비동기로 해결하게 되었습니다. 비동기는 Java8에 등장한 CompletableFuture 클래스를 활용하게 되었는데요. 비동기를 처음 적용하다 보니 관련 내용을 학습하면서 나중에 다른 분들도 쉽게 비동기를 적용하실 수 있도록 기본적인 학습 내용을 공유하면 좋겠다는 생각을 시작으로 글을 작성하게 되었습니다. Contents Contents 비동기 처리 CompletableFuture CompletableFuture 인스턴스 순차적으로 연산 처리하기 연산 결합하기 thenApply or thenCompose 병렬처리 비동기 메서드 예외 처리 Timeout 마무리 비동기 처리 비동기 처리는 특정 작업이 다른 작업과 독립적으로 동작하도록 하여 다음 단계의 작업이 이전 작업의 완료를 기다리지 않고 동시에 실행할 수 있도록 하거나, 특정 작업의 완료를 기다리는 동안 다른 작업을 처리할 수 있는 장점이 있습니다. 흔히 사용하는 방식은 동기적... Thu, 04 Jan 2024 00:00:00 +0900 https://11st-tech.github.io/2024/01/04/completablefuture/ https://11st-tech.github.io/2024/01/04/completablefuture/ java async completableFuture 안녕하세요. 11번가 클레임개발팀 박지훈입니다. 11번가에서는 전사 배치 서버가 있고, 각 팀별로 팀 전용 배치 서버를 추가로 관리하기도 합니다. (최종 목표는 모든 팀이 함께 관리하는 레거시 배치를 각 팀 전용 배치로 이관하는 것입니다.) 클레임개발팀에서는 한 대의 서버로 운영되는 팀 배치 서버를 추가로 관리하고 있고, Spring Batch Job(이하 Job) 스케줄러는 Jenkins 툴을 사용하여 Job 들을 주기적으로 실행시켜 주고 있습니다. 평화롭던 어느 날..🌞 팀 배치 서버에서 한 가지 문제를 발견하게 되었습니다. Job 수행을 위해 jar 파일을 실행하는 도중 배포가 진행될 경우, jar 파일이 변경(업데이트, 제거)되면서 에러가 발생하는 문제입니다. 이러한 이슈를 해결하기 위해 스프링 배치 무중단 배포를 적용하게 된 과정을 공유해 드리고자 합니다. Contents Contents 문제 상황 기존 배포 방식 아이디어 Symbolic link 적용 배포 이후 단계 Job 실행 단계 적용 결과 마무리 문제 상황 아래와 같은 상황에 처하게 되면 java.lang.NoClassDefFoundError 또는 java.lang.ClassNotFoundException 예외가 터지면서 비정상적으로 배치가 실패하거나 중단되는 현상이 발생하였습니다. Job 실행 중일 때 배포 진행 빌드&배포 중일 때 Job 실행 마주했던 문제의 로그 일부입니다. Exception in thread "main" java.lang.reflect.InvocationTargetException ... Caused by: java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy ... Exception in thread "SpringApplicationShutdownHook" java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy ... 이제 열심히 서칭해야 할 시간입니다. stack overflow 에서 유사한 사례를 발견하게 되었는데, 서론에서 언급했듯이 Job 수행을 위해 jar 파일을 실행하는 도중 배포가 진행될 경우, jar 파일이 변경(업데이트, 제거)되면서 에러가 발생한다는... Mon, 11 Dec 2023 00:00:00 +0900 https://11st-tech.github.io/2023/12/11/spring-batch-non-stop-deploy/ https://11st-tech.github.io/2023/12/11/spring-batch-non-stop-deploy/ spring-batch deploy linux 안녕하세요. 11번가 Core플랫폼개발팀 전지원입니다. 저희 팀에서는 Spring Cloud 기반의 전사 MSA 플랫폼인 Vine의 공통 컴포넌트 개발과 운영을 담당하고 있습니다. 또한 각 소프트웨어 엔지니어링 조직이 Self-Service 기능을 사용할 수 있도록 툴체인과 워크플로우를 설계하고 있으며, 애플리케이션 전체 수명 주기에 필요한 운영 요구사항을 포괄하는 IDP (Internal Developer Platform)인 Wheelhouse를 개발하여 제공하고 있습니다. 이번 아티클에서는 Feature Flag 개념에 대해서 설명드리고, 기능을 Production 환경에서 안전하게 배포하고 실험하기 위해 Feature Flag를 도입한 사례를 소개해드리고자 합니다. Contents Contents 사례로 살펴보는 문제점 Feature Flag? Feature Flag 의 형태 OpenFeature / Flagd Flagd를 사용해 Flag Management System (Flag Backend, Flag Evaluation Engine) 구축하기 Flagd에서 사용할 Flag 정의하기 OpenFeature SDK (Java) 살펴보기 Evaluation API Evaluation Context Hooks 실제 애플리케이션 코드를 작성해볼까요? 마치며 References 사례로 살펴보는 문제점 Feature Flag를 소개드리기 전에, 문제 사례를 하나 소개드리겠습니다. 최근 저희 팀에서는 각 서비스 개발팀이 REST(HTTP) 호출 기반의 서버 개발을 보다 쉽게 gRPC 호출 기반으로 전환할 수 있게끔 전사 공통 라이브러리를 개발하여 제공하고 있었습니다. 개발한 서버 라이브러리는 개발 및 검증 환경에서는 충분히 검증이 되었지만, 실제 엄청난 트래픽이 들어오는 Production 환경에 적용되었을 때도 이슈 없이 완벽하게 동작할 수 있다는 확신이 없었습니다. 만약 Production 환경에 배포한 후 예상치 못한 이슈가 발생한다면 신속하게 롤백을 진행해야 하지만, 롤백 재배포에도 적지 않은 시간이 소요될 수 있습니다. 😱 따라서 코드를 배포할... Tue, 07 Nov 2023 00:00:00 +0900 https://11st-tech.github.io/2023/11/07/openfeature/ https://11st-tech.github.io/2023/11/07/openfeature/ kubernetes openfeature cncf feature-flag 안녕하세요. 11번가 PDP개발팀 신치용입니다. 작년 11월 중순부터 5주가량 진행된 인턴 기간동안 과제를 진행하면서 느낀 경험을 담은 글입니다. 많이 부족하지만 짧은 인턴 기간 동안 진행한 과제라는 점을 고려해주시면서 읽어주시면 감사하겠습니다! 😄 목차 인턴 과제 카탈로그 리뷰 API, 너 왜 문제 있어? 글로벌 캐시 도입 기존 구조 - Only 로컬 캐시 글로벌 캐시 로직 구현 글로벌 캐시를 추가한 후 흐름 캐시 자동 최신화 글로벌 캐시의 단점 동기 or 비동기 무엇이 더 좋을까? Test 1. 로컬 캐시에 데이터가 존재하지 않는 경우 Test 2. 로컬 캐시에 데이터가 존재하는 경우 Test 3. 로컬과 글로벌 캐시 모두 데이터가 존재하지 않는 경우 Test 4. 로컬과 글로벌 캐시 모두 데이터가 존재하는 경우 Test 5. 로컬과 글로벌 캐시 모두 데이터가 존재하지 않는 경우 Test 6. 로컬과 글로벌 캐시 모두 데이터가 존재하는 경우 테스트 결과 글로벌 캐시 도입으로 카탈로그 리뷰 API 개선 결과 되돌아보며 앞으로 인턴 과제 저의 인턴 과제는 카탈로그 리뷰 API를 개선하는 것이었습니다. 아래 사진은 2022년 그랜드 십일절 당시 카탈로그 리뷰 API로 인해 DB에 부하가 생긴 모습입니다. 카탈로그 리뷰 API, 너 왜 문제 있어? 카탈로그 리뷰 API는 어떤 이유로 DB에 부하를 가하는 문제점을 가지고 있을까요? API의 문제점을 분석하기 이전에 먼저 “카탈로그 리뷰” 에 대해 이해해야 한다고 생각했습니다. 먼저, 카탈로그란 11번가의 상품들이 고객에게 잘못 노출되는 경우를 없애기 위해 자체적으로... Wed, 19 Jul 2023 00:00:00 +0900 https://11st-tech.github.io/2023/07/19/improve-catalog-review-api/ https://11st-tech.github.io/2023/07/19/improve-catalog-review-api/ redis 안녕하세요. 11번가 Core플랫폼개발팀에서 MSA 플랫폼 Vine의 개발과 운영을 담당하고 있는 전지원입니다. 이번 Article에서는 Eureka 서버의 Multi-Zone 구성을 함에 따라 기존에 11번가 내에서 IDC의 Client-side Service Discovery와 EKS 클러스터의 Server-side Service Discovery 통합을 담당하던 Kubernetes Operator인 eurekube-operator 의 구현을 변경한 내용에 대해서 공유드리고자 합니다. 본 Article은 Service Discovery DR 구성 1부 - Eureka 서버를 지역 분산시켜 안정성을 높이자 와, Service Discovery DR 구성 2부 - Chaos Test로 찾은 예기치 못했던 문제를 고쳐라! 의 후속 게시물입니다. 해당 Article의 Context 를 더욱 쉽게 이해하시기 위해서 사전에 해당 게시물을 확인하시는 것을 권장드립니다. Background What is Vine Platform? 11번가는 서비스의 높은 확장성과 간단한 통합 및 배포, 그리고 운영을 위해 2016년 거대한 Monolithic 서비스를 Microservice Architecture로 전환하는 프로젝트를 진행하였으며, 그 결과 Spring Cloud 기반의 Vine 플랫폼이 개발되어 현재 약 720여개 인스턴스와 70여개의 애플리케이션 서비스가 Vine 플랫폼 위에서 성공적으로 운영되고 있습니다. 더 나아가 Vine 플랫폼은 유연함과 확장성 증대를 위해서 AWS를 도입하여 IDC와 Cloud 리소스를 함께 사용하는 Hybrid Cloud 형태로의 고도화가 이루어지고 있습니다. eurekube-operator eurekube-operator는 IDC의 Client-side Service Discovery와 EKS 클러스터의 Server-side Service Discovery를 통합하기 위해 구현한 Kubernetes Operator입니다. eurekube-operator가 개발됨에 따라 서로 다른 곳에 위치한 마이크로서비스 간의 호출에 있어서 장소 투명성 유지의 목적을 달성할 수 있었습니다. eurekube-operator의 자세한 내용에 대해서는 지난 게시물을 참고해주세요. 지난 1, 2부에서는 IDC... Mon, 16 Jan 2023 00:00:00 +0900 https://11st-tech.github.io/2023/01/16/eureka-disaster-recovery-3/ https://11st-tech.github.io/2023/01/16/eureka-disaster-recovery-3/ spring cloud kubernetes eureka msa service-discovery load-balancer