매드업에서는 프리즘이라는 시스템을 사용하여 광고 데이터를 수집하고 있습니다. 프리즘에 대해서는 여기를 참고해 주세요.프리즘은 여러 마이크로 서비스들로 이루어져 있고, 마이크로 서비스들 간의 통신을 위해 메시지 기반 비동기 통신 방식을 사용하고 있습니다. 따라서 메시지들을 안정적이고 효율적으로 전달할 수 있는 메시지 브로커를 선택하는 것은 매우 중요한 문제입니다. 이 글에서는 프리즘이 발전하는 과정에서 실제로 사용한 메시지 브로커의 변천사를 소개하고자 합니다. 어떠한 이유로 사용하던 메시지 브로커를 변경하게 되었는지 실제 경험에 기반한 내용을 이야기해 보겠습니다.프리즘을 위한 메시지 브로커가 갖춰야 할 기능 요건들메시지 브로커를 사용할 때 이상적인 동작은 “정확히 한 번”(Exactly Once) 전달일 것입니다. 하지만 현실적으로는 어렵기 때문에 “최소 한 번”(At Least Once) 전달과 “최대 한 번”(At Most Once) 전달 중에 선택을 하게 됩니다. 프리즘은 메시지를 중복으로 처리해도 문제가 없는 시스템이기 때문에 최소 한 번 전달을 현실적인 목표로 잡았습니다.프리즘에서 필요한 메시지 브로커가 갖춰야 할 기능 요건들은 다음과 같습니다.• 안정적인 메시지 전달 (최소 한 번 전달) 프리즘은 쿠버네티스 환경에서 운영되고 있습니다. 쿠버네티스 환경에서 파드의 종료는 배포나 HPA(Horizontal Pod Autoscaling) 등으로 인해 언제든 발생할 수 있기 떄문에, 파드가 종료되는 경우에도 메시지가 유실되지 않고 전달될 수 있어야 합니다.• 유연한 메시지 컨슈머(consumer) 스케일링 프리즘의 각 마이크로 서비스는 HPA를 사용하여 필요에 따라 파드 개수가 적절하게 조정됩니다. 따라서 메시지 컨슈머의 개수가 변하는 경우에도 큰 지연 시간 없이 메시지를 안정적으로 가져올 수 있어야 합니다.• 효율적인 메시지 분배 프리즘에서 수집하는 광고 데이터는 광고주에 따라 사이즈 차이가 크며, 그에 따라 소요되는 수집 시간도 차이가 큽니다. 데이터 사이즈가 작은 광고주의 경우 1분 안에 수집이 끝나기도 하지만, 사이즈가 큰 광고주는 20~30분이 걸리기도 합니다. 이처럼 메시지 처리 시간의 편차가 큰 편이기 때문에 일률적으로 메시지를 분배하는 라운드 로빈(Round Robin)과 같은 방식은 적합하지 않습니다. 여유가 있는 메시지 컨슈머에게 우선적으로 메시지를 전달할 수 있어야 합니다.실제로는 더 많은 기능 요건들이 있지만, 여기서는 이 글과 관련된 것들만 언급했습니다. 이러한 요건들에 맞는 최적의 메시지 브로커를 한 번에 찾았다면 좋았겠지만 아쉽게도 그러지 못 했습니다. 지금부터는 프리즘 운영 환경에서 실제로 사용했었던 메시지 브로커인 SQS와 카프카, 그리고 현재 사용 중인 RabbitMQ에 대해 얘기해 보겠습니다.새로운(v2) 프리즘을 만들면서 처음 사용한 메시지 브로커는 Amazon SQS(Simple Queue Service)였습니다. AWS를 사용하고 있기 때문에 쉽게 적용할 수 있었고, 다른 팀에서도 사용하고 있었기

안녕하세요. 무신사에서 주문을 담당하는 백엔드 엔지니어 박준호입니다.이번 글에서는 무신사의 주문 시스템이 수많은 변화에 대응하며 대규모 트래픽과 이벤트 시즌에도 안정적인 서비스를 유지하기 위해 어떤 방식으로 변화해왔는지, 그 여정을 공유하고자 합니다.왜 개선이 필요한가?무신사와 같은 커머스 플랫폼에서 주문 시스템은 핵심적인 역할을 담당합니다. 주문 처리 속도와 안정성은 고객 경험에 직접적인 영향을 미치며, 주문 데이터를 신뢰할 수 있어야 모든 비즈니스가 원활하게 운영될 수 있기 때문입니다.무신사는 블랙프라이데이(이하 무진장) 시즌마다 최고 매출과 주문 수를 경신하며 놀라운 성장세를 이어가고 있습니다. 이처럼 가파른 성장을 뒷받침하기 위해 주문 시스템도 지속적인 발전이 필요합니다.하지만, 주문 도메인은 복잡한 비즈니스 로직을 포함하기 때문에 보수적으로 개발되는 면이 있습니다. 버그나 장애가 발생할 경우 장애 정도나 발생 시간과 관계없이 치명적인 결과로 이어질 수 있기 때문입니다.예를 들어 무신사의 경우 2023년 겨울 무진장 기준으로 시간당 평균 주문액이 10억 원 이상으로, 15분의 장애를 가정했을 때 약 2억 5천만 원 이상의 손실이 발생한다는 계산을 할 수 있습니다.따라서 주문 도메인을 다룰 때는 안정성과 신뢰성을 유지하면서도 변화와 개선을 추구하는 것이 매우 중요한 과제이고, 이를 위해 강한 책임감을 가지고 시스템을 관리하는 자세가 필요합니다.무신사 2.0 주문서여정의 시작, 모놀리식 아키텍처와 그 한계초창기 무신사 스토어는 모놀리식 아키텍처 (Monolithic Architecture) 로 구성되어 있었습니다. 하나의 데이터베이스를 공유하며 매거진을 제외한 모든 도메인이 하나의 리포지토리로 관리되어 있었습니다.주문 외에도 결제, 재고, 상품, 회원, 쿠폰, 적립금 등 모든 주요 도메인이 하나의 어플리케이션 내에 통합되어 있었기 때문에 매우 복잡하고 유지보수하기 어려운 구조였습니다. 특히 주문 시스템은 스파게티 코드처럼 복잡하게 얽혀 있었고, 콜 스택이 지나치게 깊어 분석이 어려웠습니다. 이러한 복잡성은 새로운 기능 추가나 버그 수정 시 높은 리스크를 동반하게 만들었습니다.모놀리식 아키텍처 무신사 스토어이 시스템은 DB 의존도가 높은 구조로 모든 요청이 데이터베이스를 통해 처리되었기 때문에 성능 문제가 빈번히 발생했습니다. 특히 무진장과 같은 대규모 이벤트 시 요청이 데이터베이스로 몰리면서 사이트가 다운되는 일이 잦았는데, 서버 다운타임과 성능 저하는 매출에 직접적인 영향을 미치는 민감한 문제이므로 이벤트 시즌에는 안정적인 시스템 운영이 필수적이었습니다.매년 서버를 증설하고 시스템을 튜닝했지만, 가파르게 증가하는 트래픽을 따라잡지 못해 한계에 도달하기 일쑤였습니다. 최적화되지 않은 코드들이 성능적 한계를 보이면서 근본적인 아키텍처 변화의 필요성이 대두되었습니다.변화의 시작, 리팩토링성능 개선과 유지보수의 용이성, 그리고 개발 생산성 향상은 매우 중요한 개선의 시작이였습니다.이를 해결하기 위해 리팩토링을 시작했고, 첫 단계로 시스템의

안녕하세요, 뉴넥스 AI 검색팀의 신누리입니다.현재 팀 내 유일한 검색 담당으로서, 뉴넥스의 패션 커머스 플랫폼들 -브랜디, 하이버, 서울스토어, 셀피- 전체 검색 프로덕트를 책임지고 있습니다. 구체적으로는 검색 데이터 파이프라인 구축 및 유지보수, 검색엔진 관리, 검색 API 개발, 검색 사전 관리 등 검색과 관련된 모든 부분을 매니징하고 있습니다.클라우드(AWS) PaaS 및 SaaS 환경에서 검색 시스템을 A부터 Z까지 설계하고 매니징하는 경험은 처음 이었지만, 이전에 온프로미스(On-Premise) 기반의 자바(Spring) 환경에서 검색 서비스를 개발하고 ElasticSearch를 활용한 경험이 있었기 때문에 운영과 관리가 용이한 검색 내재화를 목표로 시스템을 구축하게 되었고, 현재까지도 검색시스템을 안정적으로 운영하고 있습니다.이 경험을 바탕으로, 이번 포스팅에서 최소한의 휴먼 리소스로 여러 서비스의 검색 시스템을 운영할 수 있도록 구축한 검색 시스템을 소개하려 합니다.🤔 검색 시스템 구축 이전브랜디와 하이버는 기존에 SaaS 형태로 제공되는 타사의 검색 솔루션을 사용하고 있었습니다. 이는 상품 데이터를 주기적으로 JSON 파일로 추출하여 검색 솔루션과 연계하고, REST API를 통해 검색 질의를 수행하는 방식이었습니다. 이러한 접근법은 단순하고 편리한 점이 있었으나, 뚜렷한 한계점이 있었습니다.비즈니스 및 요구사항 변화에 대한 빠른 대응의 어려움 대표적으로 전시 정책 변경이 있습니다. 검색은 전시 정책과 밀접하게 연관되지만, 정책 변경 시 내부 시스템에는 즉시 반영되지만 외부 솔루션에는 적용이 지연되는 문제가 있었습니다.확장성 부족 새로운 서비스를 추가할 때, 비즈니스 특성을 빠르게 이해하고 도메인을 반영하기 위해서는 내부 인력의 긴밀한 협조가 필요했지만, 외부 솔루션 사용 시 이 과정이 더 어려웠습니다.증분 색인 주기 하루에 한 번 전체 색인 주기가 있었고, 30분마다 추가/수정/삭제된 상품들을 증분 색인을 통해 반영했습니다. 도메인에 따라 30분마다 충분할 수 있지만, 패션 커머스 플랫폼에서는 빠른 수정 사항 반영이 필요합니다.이러한 문제점들을 해결하고자, 저희는 더 유연하고 효율적으로 시스템을 운영하기 위해 내부에서 직접 검색 시스템을 구축하고 관리하기로 했습니다.🎈검색 파이프라인 도입기데이터가 검색 결과로 노출되기까지는 대부분 아래와 같은 단계로 이루어 집니다.데이터 추출 → 데이터 색인 → 검색 질의 및 응답💡색인이란데이터를 분석하고 구조화하여 검색 엔진이 빠르게 검색 결과를 반환할 수 있도록 데이터베이스나 인덱스를 구축하는 것앞으로 데이터추출과 데이터색인 과정을 편의상 ‘검색 파이프라인’이라고 부르겠습니다.즉, 검색 데이터 파이프라인은 체계적으로 설계된 프로세스로 주기에 따라 운영됩니다. 이 과정에서 유효한 데이터를 정교하게 추출(Extract)하고, 비즈니스 인텔리전스를 적용하여 최적화된 형태로 변환(Transformation)합니다. 최종적으로 이렇게 가공된 데이터는 검색 시스템의 효율적으로 색인(In

안녕하세요. SpoonRadio Buisiness Platform 팀에서 Billing 도메인 관련 백엔드 업무를 담당하고 있는 Eunice(손 윤)입니다. AWS Summit Seoul 2024에 참석할 수 있는 기회가 주어졌습니다.AWS Summit에 처음 참여라 설레는 마음으로 참가하게되었습니다. 참가 등록 데스크를 거쳐서 기조연설을 시작으로, 미리 들으려고 표시해 두었던 강연을 들으러 바쁘게 움직였습니다.가장 인상깊었던 강연은 채널톡 스타트업 기술 성장기: RDBMS에서 NoSQL로의 전환 이었습니다. 해당 강연의 내용을 소개해 드리고자 합니다.RDBS에서 NoSQL로의 마이그레이션을 하게 된 동기와 원인DynamoDB와 SQS의 장점과 활용 방안배경 설명채널코퍼레이션는 서비스 성장에 따라 트래픽 증가는 필연적으로 예전보다 더 많은 트래픽을 유발할 거라고 판단하였습니다. 간단한 대응 방법으로 RDS인스턴스 타입 스케일업(Scale-up)을 생각하였으나, 결과적으로 NoSQL을 도입하기로 합니다. 그에 따라, 아래 네 가지의 문제 해결이 필요했습니다.오버 프로비저닝으로 인한 비용 비효율 문제: 스파이크 트래픽의 피크(peak) 트래픽에 맞춰 RDS 인스턴스 사이즈를 선택해야 하기 때문에 비용 비효율이 예측됨.테이블 간 부하 전파 문제: 특정 테이블들의 부하가 RDS 인스턴스 전체에 영향을 끼쳐 전체 서비스에 장애를 우려함.NoSQL로의 오퍼레이션 대체 가능 여부: 특히 여러 채팅 방의 안 읽은 메시지 개수 합을 구하는 문제와 같은 특수한 작업.PostgreSQL에서 DynamoDB로의 데이터 마이그레이션 전략.DynamoDB를 선택한 이유위의 네 가지 문제 해결과 동시에 다음 세 가지 주요 이유로 DynamoDB를 선택했습니다.이벤트 소싱: 데이터베이스의 변경 사항을 쉽게 다른 서비스로 이벤트 소싱할 수 있어야 함.AWS 서비스들과의 연동: 기존 AWS 서비스들과의 풍부한 연동.ACID 트랜잭션 지원: 트랜잭션 지원 필요.이러한 요구 사항을 고려했을 때, AWS DynamoDB는 규모에 상관없이 빠르고 유연한 완전 관리형 NoSQL 데이터베이스 서비스로 적합Spike 트래픽 처리스파이크 트래픽 비용 비효율 문제 같은 경우에는 이전 처리량이 동일한 30분 이내에 2배에 해당하는 피크 트래픽을 동시에 수용할 수 있는 온디맨드 모드가 있고, 평소에는 내가 설정한 만큼 사용하다가 오토 스케일링에 의해서 유연하게 처리량을 조절해 주는 프로비저닝 모드가 있는데, 이 두 가지 모드 중에 적절하게 선택하여 DynamoDB를 선택한 것만으로 간단히 해결할 수 있었다고 합니다.1. 온디맨드온디맨드 용량 모드를 사용하는 DynamoDB 테이블은 애플리케이션의 트래픽 볼륨에 따라 자동으로 조정됩니다. 온디맨드 용량 모드의 테이블은 이전 피크 트래픽의 최대 2배 용량을 즉시 수용합니다.2. 프로비저닝애플리케이션 트래픽이 예측 가능한 경우트래픽이 일관되거나 점진적으로 변화하는 애플리케이션을 실행할 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. Auto Scaling을 사용하여 트래픽 변경에 따라 테이블의 프로비저닝된 용량을 자동으로 조정할 수 있습니다.온디맨드 모드의 기존 테이블은 언제든지 프로비저닝된 용량 모드로 전환할 수 있습니다. 하지만 온디맨드로의 전환을 나타내는 마지막 타임스탬프가 발생한 지 24시간이 지난 후에야 다시 온디맨드 모드로 전환할 수 있습니다.Spike 트래픽과 SQS채널톡은 외부로부터의 여러 서비스 요청에 대한 로그를 기록하고 있다고 합니다. 이 로그를 DynamoDB에 기록한다면, 갑자기 많은 로그 record를 추가되어 DynamoDB의 ProvisionedThroughput을 넘어서 문제가 발생이 있었습니다. 따라서, Spike 트래픽이 발생할 경우 Amazon SQS를 이용해서 서비스 요청 로그를 버퍼링하고, Amazon SQS에서 일정한 속도로 로그를 읽어서 DynamoDB나 RDS와 같은 저장소에 저장하는 아키텍처를 설계하였다고 합니다.채널톡의 Amazon SQS를 이용한 효율적인 Spike 트래픽 처리 방법PostgreSQL 오페레이션을 DynamoDB로 처리 과정이 외에도 기존 PostgreSQL을 통한 안읽음 표시 오페레이션을 DynamoDB를 통해 어떻게 처리했는 지 등에 대한 내용들 또한 공유해주었습니다.설명을 돕기위한 채널톡 채팅의 주요 요소기존에는 PostgreSQL을 사용했기 때문에 ChatBadge는 원자적 연산을 사용했고, ManagerBadge는 ChatBadge들의 합을 구하면 됐었습니다. 하지만 DynamoDB에서 기존과 같은 방식으로 구현한다면 채팅 방이 많은 사용자는 ManagerBadge를 계산하는 속도가 점점 느려질 것으로 예측하였습니다. 이 문제를 해결하기 위해 DynamoDB 트랜잭션을 통해 어떻게 핸들링하였는 지 공유해 주셨습니다.DynamoDB table 예시특정 채팅 방에서 메시지가 작성되면, 작성자를 제외한 각 참여자에겐 다음과 같은 오퍼레이션이 수행됩니다.참여자의 ChatBadge를 증가시키는 UpdateItem을 생성합니다.참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.이를 통해, ChatBadge들의 합은 ManagerBadge가 됨을 보장하였고, 또한, 동시에 다량의 메시지가 발생하여아래 그림에서 보시는 바와 같이 충돌이 발생했을 때는 exponential backoff retry 전략을 활용하며, DynamoDB 트랜잭션은 ClientRequestToken 파라메터를 사용하는 경우 멱등성을 지원하기 때문에 연결 시간 초과 등의 문제로 동일 요청이 여러 번 제출된 경우에도 10분 이내라면 정확하게 ChatBadge와 ManagerBadge를 관리하였습니다.참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.이를 통해, ChatBadg