db_df.csv

title,text,link,sum
"무신사 성장과 함께 거대해져온 600줄짜리 쿠폰 쿼리와의 아름다운 이별
","Sign up Sign in Hangjun Cho Follow MUSINSA tech 12  안녕하세요, 무신사 캠페인개발팀에서 무신사의 최대 이벤트인 무진장과 여러 이벤트들을 담당하고 있는 조항준입니다. 이번 글에서는 오래된 레거시 시스템 중 하나였던 쿠폰 시스템을 개선하는 과정에서의 실패와 성공 사례를 공유하고자 합니다. 왜 개선이 필요한가? 과거에는 사용자가 쿠폰을 사용할 때만 자신이 보유한 쿠폰을 확인하는 구조였습니다. 그러나 Musinsa 2.0이 도입되면서, Musinsa에서 가장 트래픽이 높은 페이지인 상품 상세 페이지에서 최적의 쿠폰을 실시간으로 제공해야 하는 요구가 생겼습니다. Musinsa의 빠른 성장과 함께 트래픽이 폭발적으로 증가했고, 단순했던 쿠폰 쿼리가 점점 복잡해져 결국 600줄에 달하는 거대한 코드로 변모했습니다. 이러한 거대한 쿼리는 더 이상 높은 트래픽을 감당하기 어려웠고, 계속해서 유지하기 위해 막대한 인프라 비용을 지불해야 한다는 문제가 있었습니다. 지금까지 거대해지면서도 버티고 있었던 개인적인 생각은
막대한 인프라 비용과 오래 함께한 팀원들의 노력으로 유지 되고 있었다고 생각합니다. 어떻게 개선하기로 했나? 1. 쿼리 분할 단일책임원칙은 객체지향 프로그래밍의 SOLID 원칙 중 하나로, 각 클래스나 함수가 하나의 책임만 가져야 한다는 원칙입니다. 각각의 기능이 고유한 책임을 가질 때 코드의 재사용성과 유지보수성이 높아지는 것이 핵심입니다. 긴 쿼리를 하나의 책임을 가진 여러 개의 짧은 쿼리로 분리하는 작업을 단일책임원칙으로 비유할 수 있습니다. 즉, 각 쿼리는 특정한 데이터나 기능에만 집중하도록 설계하여 효율적으로 필요한 데이터만을 반환할 수 있게 만드는 것입니다. 위와 같은 이유로 600줄짜리 거대한 쿼리를 여러개의 짧은 쿼리로 쪼개어 자신만의 데이터를 가져오고 그 데이터를 조합하여 Application에서 계산하도록 변경했습니다. 이를 통해 쿼리의 복잡성을 줄이고, 처리 속도를 크게 개선할 수 있었습니다. 2. 캐싱 처리 캐싱을 통한 조회 최적화 모델 구성: 캐싱을 적극적으로 활용해 변화가 많치않고 자주 요청되는 데이터는 캐시된 결과를 반환하도록 최적화, 데이터베이스에는 변화가 적은 데이터만 접근하도록 하여, 데이터베이스 부하를 줄이고 응답 속도를 높히는데 집중을 했습니다. 3. Application 자원 활용 데이터베이스의 책임은 주로 데이터를 안전하게 저장하고, 빠르고 효율적으로 조회하는 데 집중 애플리케이션의 책임은 비즈니스 로직과 관련된 연산과 데이터 조작을 담당하며, 데이터베이스로부터 데이터를 받아 필요한 연산을 수행하는 역할 각 자원의 특성을 생각해서 데이터베이스는 안전하고 빠르게 데이터를 주는데 집중하고 Application은 연산을 집중적으로 담당해서 처리 하였습니다. Application 자원의 사용은 비용이 더 저렴하고, 운영 측면에서도 더 효율적이라는 장점이 있었습니다. 실패 사례 첫 번째 시도: S3 모든 쿠폰 데이터를 배치로 생성해 S3에 업로드 문제점: 다운로드 지연과 네트워크 비용 증가
(1480개 쿠폰 데이터 용량: 5MB) 두 번째 시도: Memcached Memcached에 쿠폰 데이터를 저장 문제점: 단일 Key 최대 용량 1MB의 한계에 부딪힘 세 번째 시도: Memcached 분산 저장 데이터를 분산해 저장한 후 조합 문제점: 조합 과정의 시간 소요 증가 및 호출 횟수 증가 최종 개선 방향: 최소한의 DB 사용 1. 쿼리 구성 요소 분석 쿼리 구성 요소: JOIN, SubQuery, UNION, GROUP BY, ORDER BY, CASE등
쿼리를 짜면서 볼수있는 모든것의 집합 문제점: 쿼리의 복잡성과 무거운 구조가 성능 저하와 유지보수 비용을 증가 2. 개선 방안 쿼리 분리: 가벼운 쿼리로 나누어 개별 성능 향상. 캐싱 처리: 캐싱할 수 있는 데이터는 최대한 캐싱. 로직 처리: 특정 조건은 쿼리가 아닌 로직으로 처리해 복잡성 경량화. 3. 구체적 개선 방법 사용 가능한 쿠폰 필터링 및 캐싱: 쿠폰 유형으로 필터링한 후 캐싱하여 효율성을 높임 회원 등급 캐싱: 개별 회원의 등급 정보를 캐싱하여 조회 성능을 향상 쿠폰 조건 로직 처리: 온라인 쿠폰 및 등급 쿠폰의 다양한 조건을 로직으로 처리하여 복잡성을 경감 회원 보유 쿠폰 처리: 회원이 보유한 쿠폰을 실시간으로 조회하고 로직을 통해 필터링 4. 결과 평균 Latency가 110ms → 83ms 로 응답속도 약 24.55% 향상 최초 진입시에는 약 150ms로 기존로직 약 110ms로 기존 보다 조금 느려졌지만 이후 캐싱을 통해서 서비스하면서 속도가 향상됨. 쿼리를 단순화시켜서 여러번 수행시키면서 기존 사용가능한 쿠폰의 데이터를 구하는 쿼리가 60ms걸렸지만 개선 후 20ms로 쿼리가 가벼워짐 동일한 로직을 수행시 기존 DB사용량의 변화
- 개선 전 로직 DB 사용률 72.5%
- 개선 후 최초 호출시 49.5%
- 캐싱이 된 후에는 13.6% 쿼리를 분할하고 Application 로직을 사용하면서 데이터베이스 부하는 줄어들고, 인프라 비용 역시 절감할 수 있었습니다. 이 과정을 통해 무거웠던 600줄짜리 레거시 쿼리와의 아름다운 이별이 가능했습니다. 마무리 이번 개선 작업을 통해 쿼리의 속도가 빠르다고 해서 그 복잡성이 괜찮다고 여기는 것은 잘못된 생각이라는 것을 깨달았습니다. 단순히 성능만을 추구하는 것이 아닌, 더 효율적이고 관리하기 쉬운(유지보수가 용이한) 대안을 찾아야 한다는 중요한 교훈을 얻었습니다. 이번 개선에서의 경험은 다양한 접근 방식이 존재한다는 것을 느끼게 해주었고, 복잡한 쿼리를 단순화하는 것이 기술적 부채를 줄이고 향후 유지보수를 용이하게 한다는 것을 느끼게 해준 개선 작업이었습니다. 앞으로도 다양한 방법과 유지보수가 용이하도록 지속적인 개선을 통해 더 나은 시스템을 구축해 나갈 것입니다. 함께할 동료를 찾습니다. 무신사의 폭발적인 성장에는 매년 말 진행 했던 무진장(블랙프라이데이)가 큰 역할을 했습니다. 해당 이벤트로 매출 부스팅 및 신규 유저를 확보 했고, 이렇게 증가된 매출과 유저로 인해 매년 높은 매출 성장을 이뤘으며, 지금의 무신사가 만들어졌습니다. 캠페인개발팀은 무신사의 핵심 행사인 무진장(블랙프라이데이) 캠페인을 주도적으로 개발 및 운영지원 하고 있습니다. 그 외에도 무신사에서 전개 하는 다양한 캠페인 및 이벤트를 적극적으로 지원하고 있습니다. 우리는 팀원 각자 전문성과 열정을 바탕으로 다양한 캠페인을 성공적으로 오픈하고 있으며, 파트너와 함께 고민하며 성장하기 위해 최선을 다하고 있습니다. 🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요) 🚀 팀 무신사 테크 소식을 받아보는 링크드인 🚀 무신사 테크 블로그 🚀 29CM 테크 블로그 🚀 무신사 테크 유튜브 채널 채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요! Sign up to discover human stories that deepen your understanding of the world. Free Distraction-free reading. No ads. Organize your knowledge with lists and highlights. Tell your story. Find your audience. Membership Read member-only stories Support writers you read most Earn money for your writing Listen to audio narrations Read offline with the Medium app  12 Written by Hangjun Cho MUSINSA tech More from Hangjun Cho and MUSINSA tech MUSINSA tech in MUSINSA tech 모노레포 이렇게 좋은데 왜 안써요? 스냅, 패션톡, 체험단 등 커뮤니티 제품들을 운영하고 있는 무신사테크 커뮤니티 트라이브 프론트엔드 팀의 모노레포 도입기 최영민 in MUSINSA tech AI와 함께하는 패션 큐레이션 — 무신사 2.0 시나리오 기반 추천 시스템 개발 안녕하세요. 무신사 데이터사이언스 팀에서 최영민, 이명휘 입니다. 최근 무신사 2.0 오픈 후, 추천 영역에도 많은 변화가 있었습니다. 기획 부터 오픈 까지 저희 팀이 고민하고 해결 한 부분을 공유하고자 합니다. CHANMUL in MUSINSA tech 재고 서비스의 진화와 혁신: 지속적인 개선을 통한 안정성과 확장성 강화 이 포스트에서는 재고 시스템의 개선을 위한 구조적 변화와 다운타임을 최소화하기 위해서 정기적인 유지보수, 백업 시스템, 고가용성(HA) 아키텍처, 재난 복구 계획 등의 전략을 세우고 개선하는 것에 대해 소개하고자 합니다. Heewon Chae in MUSINSA tech 허튼짓은 그만: Kafka Streams를 활용한 실시간 이상 로그인 감지 시스템 도입하기 비정상 사용자를 모니터링하고 대응하기 위해 만든 이상 로그인 감지 시스템과 기반 기술인 카프카 스트림즈(Kafka Streams) 도입기를 소개합니다. Recommended from Medium Abdur Rahman in Stackademic Python is No More The King of Data Science 5 Reasons Why Python is Losing Its Crown Carlyn Beccia Republicans Know Why Americans Don’t Fear Authoritarians Because they asked them. Lists Coding & Development Stories to Help You Grow as a Software Developer Ida Silfverskiöld in Towards Data Science Economics of Hosting Open Source LLMs Leveraging various deployment options Harendra How I Am Using a Lifetime 100% Free Server Get a server with 24 GB RAM + 4 CPU + 200 GB Storage + Always Free Joe Procopio in Entrepreneurship Handbook The Great Tech Worker Revolution Has Begun Pushed too far, tech workers are pushing back, and it’s a volcano waiting to erupt AI Rabbit in CodeX Has Anthropic Claude just wiped out an entire industry? If you have been following the news, you may have read about a new feature (or should I call it a product) in the Claude API — it is… Help Status About Careers Press Blog Privacy Terms Text to speech Teams","https://surfit.io/link/O4LMk
","무신사 캠페인개발팀에서 무신사의 최대 이벤트인 무진장과 여러 이벤트들을 담당하고 있는 조항준을 통해 오래된 레거시 시스템 중 하나였던 쿠폰 시스템을 개선하는 과정에서의 실패와 성공 사례를 공유하고자 한다. 자원 활용 데이터베이스의 책임은 주로 데이터를 안전하게 저장하고 빠르게 조회하는 데 집중하였습니다 무신사 테크 블로그 테크 블로그  무신사 테크 유튜브 채널 채용이 완료되면 공고가 닫힐 수 있습니다 커뮤니티 제품들을 운영하고 있는 무신사테크 커뮤니티 트라이브 프론트엔드 팀의 모노레포 도입기 최영민AI와 함께하는 패션 큐레이션 — 무신사시나리오 기반 추천 시스템 개발 안녕하세요
무신사 데이터사이언스 팀에서 최영민이명휘 입니다 "
"Transactional Outbox message-relay 개선하기
","ABOUT BUSINESS STORY NEWSROOM CONTACT CAREER         	MySQL을 중심으로 안녕하세요. 리디 서비스백엔드팀 강규입니다. 지난 글에서 Transactional Outbox 패턴을 사용해 메시지 발행을 보장하는 message-relay를 리디에서 어떻게 운영하고 있는지 소개했습니다. 오늘은 message-relay를 운영하면서 겪은 다음 이슈를 개선한 내용을 소개하겠습니다. 많은 양의 메시지가 message 테이블에 입력되는 상황에서 처리된 메시지의 삭제가 지연되었을 때 select 쿼리의 latency가 저하되는 문제 message 테이블에 대한 select for update 쿼리와 delete 쿼리의 latency가 간헐적으로 치솟는 문제 불필요한 JOIN 제거하기 기존에 message-relay는 처리할 메시지가 기록된 message 테이블로부터 메시지를 읽어서 kafka에 발행하고 processed_message 테이블에 처리된 메시지 id를 기록하는 방식으로 동작했습니다. 이러한 구조에서는 message-relay가 처리할 메시지를 가져올 때, 아래의 쿼리가 사용됩니다. explain analyze를 이용해서 쿼리 실행 계획을 확인해 봤습니다. nested loop anti join 방식으로 조회하면서, driving 테이블은 message, driven 테이블은 processed_message 테이블로 결정된 것을 알 수 있습니다. message 테이블 row를 하나씩 읽어가면서 processed_message.id = message.id 조건으로 processed_message 테이블 row를 찾고 processed_message.id IS NULL 조건에 해당하는지 확인합니다. anti join이기 때문에 해당 조건을 만족하지 않는 row가 많을수록 실행 시간이 늘어날 것을 짐작할 수 있습니다. processed_message 테이블에 있는 처리된 메시지 삭제가 비동기로 동작했기 때문에 처리된 메시지의 삭제 속도가 메시지가 새로 쌓이는 속도보다 느려질 수 있었습니다. 즉, 많은 양의 메시지가 processed_message 테이블에 쌓여서 processed_message.id = message.id AND processed_message.id IS NOT NULL 조건을 만족하는 row가 늘어나면 위 select 쿼리의 성능이 악화될 수 있었습니다. nested loop join으로 인해 성능 저하될 수 있는 것을 개선하기 위해서 left join을 제거하고 message 테이블 하나만 사용하도록 수정이 필요했고, 아래의 방법을 검토했습니다. 처리된 메시지가 다시 처리되지 않도록 message 테이블에 status column을 추가해서 메시지의 처리 상태를 변경해 두고 비동기적으로 삭제하는 방법 처리가 완료된 메시지를 동기적으로 곧바로 삭제하는 방법 처리가 완료된 메시지를 유지할 필요가 없기도 하고, 곧바로 삭제해도 delete 쿼리의 lock wait 문제가 발생하지 않도록 개선할 수 있게 되어 후자를 선택했습니다. delete 쿼리의 lock wait 개선과 관련된 내용은 이번 글에서 소개됩니다. 결과적으로 message 테이블 하나만 사용하게 되면서 테이블 row의 개수에 영향을 받지 않고 일관된 select 쿼리 성능을 유지할 수 있었습니다. 또한 처리된 메시지의 삭제를 동기로 실행하게 되면서 전반적인 코드도 간결해졌습니다. MySQL NOWAIT 가용성을 위해 message-relay node를 2대 운영하고 있기 때문에 message 테이블 row에 적절하게 lock을 설정해서 동일한 메시지에 대해서 중복으로 처리되지 않도록 하는 것이 중요합니다. 기존에는 MySQL record lock 용도로 분리된 테이블(이하 lock 테이블)에 exclusive lock을 설정해서 동시성을 제어했습니다. lock 테이블에 exclusive lock이 성공한 message-relay node에서만 메시지를 처리할 수 있습니다. (message 테이블 row에 대한 lock 경합이 있는 상태에서 message 테이블에 직접 lock을 제어하는 것보다 lock 테이블을 분리하는 것이 message 테이블의 deadlock 문제를 회피하는 데 편리했습니다.) 두 node에서 동일한 index record에 exclusive lock을 시도하게 되면 어느 한쪽은 lock wait가 발생하게 되고, 이는 DB 서버에 대해 부하를 유발합니다. 그래서 lock을 시도하는 MySQL transaction을 Redis pessimistic lock으로 감싸서 최대한 lock wait가 발생하지 않도록 했습니다. lock 테이블이 분리된 점과 Redis에 추가로 의존성이 발생하는 구조를 개선하기 위해 MySQL 8.0부터 사용 가능한 NOWAIT를 활용해보기로 합니다. 아래 예시처럼 NOWAIT는 lock을 설정하려는 index record가 이미 다른 transaction에서 lock을 소유하고 있다면, 곧바로 에러와 함께 쿼리가 종료됩니다. 두 message-relay node의 transaction 사이에서 lock wait가 발생하지 않기 때문에 deadlock이 발생하지 않게 되는 효과를 얻었습니다. 더 이상 lock 테이블을 사용하지 않고도 message 테이블만 가지고 lock을 제어할 수 있었습니다. 그리고 lock wait로 인한 DB 서버 부하가 발생하지 않기 때문에 MySQL transaction을 감싸고 있던 Redis pessimistic lock을 제거했습니다. MySQL 테이블 하나로 lock을 제어할 수 있어 관리가 매우 편해졌습니다. Full Scan은 한 끗 차이 아래 쿼리는 모두 message 테이블로부터 처리할 메시지를 가져오는 쿼리입니다. 두 개의 방식은 어떤 차이가 있을까요? 전자는 id에 대해 오름차순으로 최대 500개의 message 테이블 row를 읽어가면서 lock을 설정하는 쿼리입니다. 후자는 id에 대해 오름차순으로 최대 500개의 message 테이블 row를 읽은 후 해당 row들의 id를 가져와서, 해당 id들에 대해서 오름차순으로 읽어가면서 lock을 설정하는 쿼리입니다. 두 방식은 반환하는 결과가 동일하기 때문에 하나의 쿼리로 보다 간단한 처리가 가능한 전자를 선택할 수 있을 것 같습니다. 하지만 두 방식은 lock과 관련하여 서로 동작이 다를 수 있어서 주의가 필요합니다. message 테이블에 500개보다 row가 많이 있는 상황에서는 두 방식이 보통 똑같이 작동합니다. 반면 message 테이블에 500개보다 row가 적게 있는 상황에서는 다르게 동작할 수 있기 때문에 이 상황을 가정해 보겠습니다. 또한 transaction 격리 수준은 REPEATABLE READ 또는 READ COMMITTED를 전제합니다.  전자의 방식부터 살펴보겠습니다. T1의 select for update 쿼리에서 lock을 설정하려고 할 때 T2, T3, T4의 insert 쿼리가 lock을 소유한 record를 포함해서 lock을 wait 하게 됩니다. 따라서 T2, T3, T4가 모두 commit 될 때까지 lock wait가 지속되고, T2, T3, T4가 모두 commit 된 이후가 되어야 T1의 commit이 가능합니다. 심지어 T4의 insert 쿼리는 T1보다 늦게 실행되었지만, T1의 lock wait 대상이 되기도 합니다. 이는 T1의 select for update 쿼리가 T2와 T3의 commit을 기다리고, T3이 commit 된 시점부터 T1은 T4가 commit 되는 것을 기다리기 때문입니다. T2, T3, T4가 처리 시간이 짧게 걸리는 transaction이라면 T1에 영향이 적을 수 있겠지만, T2, T3, T4의 종료가 늦어지거나 동시에 실행되는 transaction이 더 많다면 T1의 lock wait 시간이 증가해 처리 지연이 발생하는 원인이 될 수 있습니다.  이번에는 후자의 방식을 살펴보겠습니다. 후자에서는 T1에서 이미 commit 된 row를 lock 없이 먼저 조회해서 해당 id에 대해서만 select for update 쿼리를 통해서 lock을 설정합니다. T2, T3, T4에서는 index에 새로운 record를 insert 합니다. 따라서 T1와 T2, T3, T4는 lock을 경합하는 index record가 서로 다르기 때문에 T1의 select for update 쿼리는 다른 transaction이 commit 되기를 기다리지 않습니다. 따라서 다른 transaction에서 가지고 있는 lock을 wait 하지 않는 후자의 방식을 선택하는 것이 처리 지연을 막는 데 안전합니다. LIMIT의 효과 message-relay는 아래의 방식으로 메시지에 lock을 설정하고 메시지를 삭제합니다. 때때로 findMessages()와 deleteMessages() 에서 latency가 높게 치솟는 경우가 있었습니다. select나 delete 쿼리들이 단순한 쿼리들이기 때문에 쿼리가 무겁다기보다는 lock wait가 원인일 것으로 생각했습니다. 모니터링을 해보니 동시에 다른 transaction에서 insert 쿼리가 빈번한 상황에서 주로 문제가 발생했습니다. findMessages()나 deleteMessages() 는 이미 commit 된 index record에 대한 lock을 설정하려 하고, 다른 transaction의 insert 쿼리는 새로 추가되는 index record에 대해서 lock을 설정하려 합니다. 얼핏 봤을 때는 둘 사이에 lock 경합이 없어서 문제가 없을 것 같다고 생각할 수 있습니다. MySQL 8.0부터는 performance_schema.data_locks 테이블을 조회함으로써 현재 어떤 index record에 lock이 설정되어 있는지, 어떤 index record에 대해 lock을 wait 하고 있는지 쉽게 확인할 수 있습니다. 다음 표는 insert 쿼리가 포함된 다른 transaction이 아직 종료되지 않은 상황에서 select * from message where id in (1, 2, …, 499, 500) order by id asc for update 쿼리를 실행했을 때의 performance_schema.data_locks 테이블을 조회한 결과입니다. LOCK_DATA column을 보시면 primary key 값이 501인 index record에 insert 쿼리가 lock을 획득했는데, 해당 index record에 select 쿼리가 lock을 wait 하고 있음을 보여줍니다. select 쿼리의 where id in (:ids) 에 501이 없는데도, 501에 해당하는 index record까지 lock을 wait 하고 있었습니다. 해당 현상이 왜 발생하는지 의문이 생겨서 MySQL 공식 문서를 확인해 보다가, 아래 문장이 눈에 띄었습니다. A locking read, an UPDATE, or a DELETE generally set record locks on every index record that is scanned in the processing of an SQL statement. select for update와 같은 locking read와 update, delete 쿼리의 경우, query optimizer에 의해서 사용할 index와 query plan이 정해지면 해당 query plan대로 데이터를 조회하면서 scan 하는 모든 index record에 lock이 설정됩니다. 그렇다면 query plan이 중요한 단서가 됩니다. explain analyze를 이용해서 select * from message where id in (1, 2, …, 499, 500) order by id asc for update 쿼리의 실행 계획을 살펴보니 index full scan을 하고 있었습니다. index 전체를 full scan 하면서 index record 전체에 lock을 설정하려고 하니, insert가 쿼리가 lock을 가지고 있는 index record에도 lock을 wait 했던 것입니다. 이제 해야할 일은 index full scan이 발생하는 것을 최소화하고, 최대한 index range scan으로 유도하는 것입니다. 쿼리를 조금씩 바꿔가며 실험을 해보니, order by와 limit을 같이 사용하면서 limit을 where절에 입력되는 ids의 개수보다 1을 작게 넣으면 대부분의 경우 index range scan으로 쿼리가 실행되는 것을 확인했습니다. 이 방법을 select for update와 delete 쿼리에 한번 적용해봤습니다. select for update 쿼리의 경우, select * from message where id in (:ids) order by id asc limit ${ids.length - 1} for update 쿼리와 같은 방법으로 실행하고, ids의 가장 마지막 id에 해당하는 row는 다음 while loop에서 처리될 수 있어서 따로 select 하지 않고 다음 while loop에 맡깁니다. delete 쿼리의 경우, kafka에 중복으로 발행되는 것을 막기 위해 반드시 현재의 while loop에서 삭제를 해야합니다. 그래서 쿼리를 다음과 같이 2가지로 나눠서 처리했습니다. delete from message where id in (:ids) order by id asc limit ${ids.length - 1} delete from message where id in (:ids[ids.length - 1]) order by id asc limit 1 몇 개월 모니터링을 진행한 결과 lock wait로 인해 쿼리 latency가 이따금씩 치솟는 현상이 사라졌고, 전반적인 쿼리 latency 그래프도 상당히 안정화 된 것을 확인했습니다. 지금까지 공유드린 내용을 적용한 결과, 최종적으로 아래의 코드로 수정됐습니다. 마치며 지금까지 message-relay를 운영하면서 겪었던 문제를 MySQL을 중심으로 개선한 내용을 소개했습니다. MySQL의 lock을 실제적인 측면에서 더욱 깊이 들여다볼 수 있어서 유익한 시간이었고, message-relay를 운영하면서 신경 쓰였던 lock wait와 관련된 문제로부터 벗어나 효과적인 개선이었습니다. 리디 서비스 내에서 점점 Transactional Outbox 패턴을 사용해서 메시지 발행을 보장하려는 경우가 많아지면서 message-relay의 중요성이 나날이 커지고 있습니다. 앞으로도 새롭게 맞닥뜨리는 문제들이 생기겠지만, message-relay의 목표인 ‘메시지의 안전한 발행’을 훌륭히 수행할 수 있도록 지속적으로 개선하겠습니다. 감사합니다. 고객과 발맞춰 새로운 콘텐츠 경험을 선보이는
리디와 함께할 당신을 기다립니다. Insight
먹는 데 진심! 정주행 추천하는 판타지 힐링물
연휴엔 힐링이지  Insight 먹는 데 진심! 정주행 추천하는 판타지 힐링물 연휴엔 힐링이지 People & Culture
리디 책 덕후들의 ‘내 서재’를 열어봤다
리더스 3인의 #왓츠인마이책장  People & Culture 리디 책 덕후들의 ‘내 서재’를 열어봤다 리더스 3인의 #왓츠인마이책장 개인정보처리방침 서울시 강남구 테헤란로 325 어반벤치빌딩 4,10,11층 (06151)
4,10,11F, Urban Bench, 325 Teheran-ro, Gangnam-gu, Seoul, Korea (06151) © 리디주식회사 RIDI Corporation","https://surfit.io/link/0AGBo
","MySQL을 중심으로 안녕하세요리디 서비스백엔드팀 강규입니다  두 node의사이에서wait가 발생하지 않기 때문에 deadlock이 발생하지 않게 되는 효과를 얻었습니다 T1와T4는 lock을 경합하는record가 서로 다르기 때문에 T1의쿼리는 다른 transaction이되기를 바란다. LIMIT의 효과 message-relay는 아래의 방식으로 메시지에 lock을 설정하고 메시지를 삭제합니다 message-relay의 목표인 ‘메시지의 안전한 발행’을 훌륭히 수행할 수 있도록 지속적으로 개선하겠습니다 힐링물 힐링물 연휴엔 힐링이지&리디 책 덕후들의 ‘내 서재’를 열어봤다 리더스 3인의 왓츠인마이책장 개인정보처리방침 서울시 강남구 테헤란로 반벤치빌딩 4,10,11층 (06151)(06151) 026151)(06151)  "
"멀티 테넌트 데이터를 격리하고 더 안전하게 만드는 방법
","검색  이번 글에서는 멀티 테넌트 서비스에서 테넌트 데이터 격리 방법과 격리 수준을 높일 수 있는 몇 가지 방법에 대해 알아봅니다. 테넌트(tenant)는 하나의 플랫폼을 사용하는 사용자나 조직, 프로젝트를 의미합니다. 일반적인 클라우드 서비스나 플랫폼 서비스는 각 테넌트에게 독립적인 데이터 접근과 관리 기능을 제공하면서도, 서버나 데이터베이스 같은 인프라 자원은 서비스에 요구되는 보안 수준, 성능, 비용에 따라 구성합니다. 이번 글에서는 테넌트 데이터를 저장하는 데이터베이스의 테넌트 데이터 격리 수준에 대해 알아봅니다. 테넌트 데이터 격리 수준은 크게 3가지로 나눌 수 있습니다. 테넌트 데이터 격리 수준 레벨 3, 데이터베이스 단위 격리가 격리 수준이 가장 높습니다. 하지만, 테넌트마다 데이터베이스가 할당되어 데이터베이스 운영 및 관리 비용이 크고, 테넌트 수에 따라 비용이 선형적으로 증가할 수 있습니다. 반대로 레벨 1은 테넌트 데이터 격리 수준이 가장 낮습니다. 하지만, 하나의 데이터베이스만 존재하기 때문에 운영 및 관리 비용이 저렴해 경제적입니다. 그에 따라 고객에게 저렴한 가격에 서비스를 제공할 수 있습니다. 각 방법은 고유한 장점과 단점을 가지는데요. 아래에서 레벨 1인 행 단위 격리 수준의 장점과 단점에 대해 더 자세히 알아보고 단점을 극복할 수 있는 방법을 살펴보겠습니다. 이 글에서도 어느 정도 다루겠지만 멀티 테넌트 데이터 관리 방법에 대해 더 많은 지식을 원하시는 분은 Microsoft Azure 글을 읽어보시는 것을 추천합니다. 제가 멀티 테넌트 데이터를 효과적으로 관리하기 위해 고민했던 부분에 대해서 잘 정리되어 있습니다. Multi Tenant SaaS Pattern Architectural approaches for storage and data in multitenant solutions  레벨 1, 행 단위 격리 수준의 장점과 단점 서비스에 요구되는 성능과 보안 관련 요구 사항에서 이슈가 없다면 테넌트 데이터 격리 수준을 레벨 1로 하는 것이 가장 경제적이고 서비스 구조를 단순하게 가져갈 수 있습니다. 테넌트 데이터 격리 수준 레벨 1의 장점과 단점에 대해 더 알아보겠습니다. 하나의 데이터베이스 안에 하나의 테이블에 여러 테넌트들의 데이터를 저장하기 때문에 각 테이블마다 테넌트를 식별할 수 있는 테넌트 ID 칼럼이 필요합니다. 장점 - 비용 절감 하나의 데이터베이스와 테이블에 많은 수의 테넌트의 데이터를 저장할 수 있습니다. 이는 적은 자원으로 많은 수의 테넌트를 수용할 수 있어 경제적입니다. 개발 및 운영에 들어가는 자원도 낮게 유지할 수 있습니다. 단점 - 보안 위험 증가, 성능 저하 여러 테넌트가 동일한 데이터베이스와 테이블을 공유하고 있기 때문에, 예기치 않은 버그나 취약점 공격으로 인해 다른 테넌트의 데이터에 접근할 위험이 있습니다. 이러한 리스크를 방지하기 위해 보안 측면에서 고려해야 할 사항들이 많아지며, 그중 하나가 멀티 테넌트 데이터 격리 방법입니다. 일부 고객은 낮은 격리 수준을 꺼려 할 수도 있습니다. 특히 금융이나 공공과 같이 높은 보안 수준을 요구하는 산업에서 다른 테넌트 데이터에 접근할 리스크 때문에 테넌트 데이터 격리 수준이 레벨 1인 클라우드 서비스 도입에 주저할 가능성이 있습니다. 또한 여러 테넌트가 같은 데이터베이스를 공유하기 때문에 시끄러운 이웃 효과로 특정 테넌트가 전체적인 성능을 저하시킬 수 있습니다. 시끄러운 이웃 효과: 하나의 테넌트가 클라우드 자원을 과도하게 점유해 다른 테넌트가 정상적으로 자신의 자원을 이용하지 못하는 것을 뜻합니다. 위에서 설명했지만 레벨 1에서 다른 테넌트의 데이터에 접근하는 것을 방지하기 위한 방법 중 가장 간단하고 강력한 방법 중 하나는 애플리케이션 개발 시 항상 테넌트를 식별하는 테넌트 아이디를 필수로 사용하도록 강제화하는 것입니다. 테넌트 데이터는 다양한 곳에 다양한 형태로 저장될 수 있습니다. 이번 글에서는 데이터베이스에 저장하는 사례에서 멀티 테넌트 데이터 격리를 강화하는 방법에 대해 알아보겠습니다. 멀티 테넌트 데이터 격리 실패 사례 설계 및 코드 리뷰 시 데이터 격리를 중요하게 생각하고, 항상 고려해 개발을 해도 시스템적으로 강제화하지 못한다면 테넌트 데이터 격리가 실패할 가능성이 있습니다. 다음은 테넌트 데이터 격리가 실패한 예시입니다. 아래는 메시지 단건 조회 API입니다. 테넌트 아이디와 메시지 아이디를 전달받아 데이터베이스에서 메시지를 조회합니다. 메시지를 저장하는 테이블은 다음과 같이 정의되어 있었습니다. 하지만, 테넌트 데이터 격리에서 문제가 되는 부분은 메시지를 조회하는 쿼리입니다. 위 쿼리에서 테넌트 데이터 격리가 실패한 원인은 테넌트 아이디가 메시지를 조회하는 쿼리에서 사용되지 않았다는 것입니다. API 요청을 받을 때, 테넌트 아이디 인증을 수행한다 하더라도 문제가 됩니다. 공격자는 자신의 테넌트 식별자를 사용하고 다른 테넌트의 메시지 아이디를 입력해 자신의 테넌트가 아닌 테넌트 메시지를 조회할 수 있습니다. 애플리케이션 로직에서 테넌트의 아이디와 메시지 아이디와 관계를 검증하는 로직을 추가해 보완할 수 있겠지만, 제일 단순하며 근본적으로 이런 보안 위협을 제거하는 방법은 쿼리에 항상 테넌트 아이디가 들어가는 지 검증해 테넌트 아이디 사용을 강제화하는 것입니다. 테넌트 아이디 검증을 통한 테넌트 아이디 강제화 방법 멀티 테넌트 데이터를 다루기 때문에 코드 리뷰에서도 항상 테넌트 데이터 격리를 달성하기 위한 시큐어 코딩에 대해 생각하는 것은 매우 중요합니다. 앞서 말씀드린 것처럼 시스템적으로 강제화하지 못한다면 테넌트 데이터 격리가 실패할 보안 리스크가 항상 존재합니다. 멀티 테넌트 기반 클라우드 서비스에서 테넌트 데이터 격리가 실패하면 서비스의 안정성과 신뢰 하락에 큰 영향을 미칩니다. 쿼리에 테넌트 아이디가 사용되도록 강제화하는 방법으로 애플리케이션 레벨에서는 JDBC DataSource를 확장하는 방법, Spring AOP나 AspectJ를 이용한 방법도 고려해 볼 수 있습니다. 그리고 시스템 아키텍처 레벨에서는 데이터베이스 미들웨어인 Apache ShardingSphere도 고려해 볼 수 있습니다. 개인적으로 이런 테넌트 데이터 격리를 클라우드 서비스 전체의 거버넌스로 가져가 중앙에서 관리를 한다면 Apache ShardingSphere와 같은 데이터베이스 미들웨어를 사용하는 것이 더 적절하다고 생각합니다. 상대적으로 단순하고 적용하기 쉬운 JDBC DataSource를 확장해 Spring 애플리케이션에서 테넌트 아이디를 강제화하는 방법에 대해 아래에서 알아봅니다. JDBC DataSource Wrapper 클래스 구현과 Spring BeanPostProcessor 이용해 테넌트 아이디 강제화 Spring에서 쿼리 실행 시 쿼리를 검증하는 방법에는 여러 가지가 있습니다. 여기에서는 쿼리에서 테넌트 아이디 칼럼을 검증하는 JDBC DataSource Wrapper 클래스를 구현하고 Spring의 BeanPostProcessor를 이용해 원래 Bean으로 등록된 DataSource를 Wraper 클래스로 감싸서 다시 Bean으로 등록해 쿼리의 테넌트 아이디 강제화를 달성하는 방법에 대해 알아보겠습니다. 아래 코드는 설명을 위한 예시이므로 실제 구현에서는 추가적인 작업이 필요할 수 있습니다. 제일 먼저 PreparedStatement Wrapper 클래스인 TenantIsolationPreparedStatementWrapper를 구현합니다. 생성자에서 PreparedSatement와 쿼리를 파라미터로 받아 쿼리를 검증하는 역할을 합니다. 아래 코드에서 쿼리를 검사하는 로직은 예시를 위해 단순하게 구현된 코드입니다. 실제 구현에서는 복잡한 쿼리도 검사해야 하기 때문에 SQL Parser를 이용해 쿼리를 검사하는 방법이 더 좋을 수 있습니다. 두 번째로 PreparedStatement를 생성하는 Connection에 대한 Wrapper 클래스 TenantIsolationConnectionWrapper를 구현합니다. 쿼리를 파라미터로 받아 PreparedStatement를 리턴하는 메서드를 오버라이딩해 TenantIsolationPreparedStatementWrapper로 감싸서 리턴합니다. 세 번째로 DataSource를 감싸 TenantIsolationConnectionWrapper를 사용하도록 하는 TenantIsolationDataSourceWrapper 클래스를 구현합니다. 먼저 등록된 DataSource Bean을 받아 TenantIsolationDataSourceWrapper로 감싸서 리턴합니다. 이렇게 하면 DataSource Bean으로 TenantIsolationDataSourceWrapper가 사용되어 실행되는 쿼리를 검증해 테넌트 데이터 격리를 강제화할 수 있습니다. 위에서 언급한 '테넌트 데이터 격리에 실패한 쿼리'처럼 WHERE에 tenant_id 칼럼이 없다면 아래와 같이 예외를 발생시킵니다. 멀티 테넌트 데이터 격리를 위해 테넌트 아이디 강제화도 중요하지만, 멀티 테넌트 데이터 격리가 실패했을 때 리스크를 최소화하기 위한 방법도 중요합니다. 제일 일반적인 방법은 테넌트 데이터를 테넌트별 고유 키로 암호화하여 저장하는 것입니다. 이렇게 하면 테넌트 데이터 격리에 실패하더라도 다른 테넌트는 해당 데이터를 해석할 수 없게 되어 테넌트 데이터를 보호할 수 있습니다. 아래에서 이러한 방법에 대해 더 구체적으로 알아보겠습니다. 테넌트별 키를 통한 암복호화 멀티 테넌트 환경에서 데이터 격리가 실패한 경우, 다른 테넌트의 데이터가 노출되는 리스크를 최소화하기 위한 한 가지 방법 중 하나는 테넌트 별로 고유 키를 부여하고 이 키를 이용해 암호화하는 것입니다. 이 방법은 같은 데이터베이스 및 테이블을 공유하는 상황에서도 각 테넌트의 데이터는 각 테넌트의 암호화 키로 암호화되어 저장되기 때문에 다른 테넌트의 데이터가 노출되어도 해석할 수 없습니다. 멀티 테넌트 환경에서 테넌트 데이터 격리는 보안을 보장하기 위한 필수 요소입니다. 특히 여러 테넌트가 동일한 데이터베이스와 테이블을 공유하는 상황에서 테넌트 간의 데이터 접근을 방지하고 격리 수준을 강화하는 것은 클라우드 서비스의 신뢰성을 높이는 중요한 과제입니다. 행 단위, 테이블 단위, 데이터베이스 단위의 격리 방법은 각각 장단점이 있으며, 각 서비스의 요구 사항에 따라 적합한 방식을 선택해야 합니다. 더 높은 수준의 데이터 격리를 제공하는 방법은 보안성과 안정성을 높일 수 있지만, 운영 비용의 증가도 고려해야 합니다. 시큐어 코딩 원칙을 적용하여 쿼리 내에서 테넌트 아이디를 강제하는 것과 같은 기술적 조치는 데이터 격리 실패로 인한 보안 위험을 크게 줄일 수 있습니다. 그리고 이러한 기술적 접근과 더불어 테넌트별 암호화 키를 사용하여 데이터를 보호하는 방법은 데이터 노출 리스크를 최소화하는 추가적인 보안 장치로 작용합니다. 결론적으로, 멀티 테넌트 환경에서 성공적인 데이터 격리는 보안성, 비용 효율성, 성능의 균형을 고려하는 전략적인 접근을 요구하며, 이를 통해 안정적이고 신뢰할 수 있는 서비스를 제공할 수 있습니다. 작성자 신진호 메시징플랫폼개발팀
NHN Cloud에서 Notification 개발을 이끌고 있습니다. NHN Cloud에서 Notification 개발을 이끌고 있습니다.	© NHN Cloud Corp. All rights reserved. 깃허브 바로가기 페이스북 바로가기 RSS 바로가기","https://surfit.io/link/yYqAX
",검색이번 글에서는 멀티 테넌트 서비스에서 테넌트 데이터 격리 방법과 격리 수준을 높일 수 있는 몇 가지 방법에 대해 알아봅니다. 하나의 데이터베이스와 테이블에 많은 수의 테넌트의 데이터를 저장할 수 있습니다만 단점보안 위험 증가성능 저하 여러 테넌트가 동일한 데이터베이스와 테이블을 공유하고 있기 때문에 예기치 않은 버그나 취약점 공격으로 인해 다른 테넌트의 데이터에 접근할 위험이 있습니다 멀티 테넌트 데이터를 다루기 때문에 항상 테넌트 데이터 격리를 달성하기 위한 시큐어 코딩에 대해 생각하는 것은 매우 중요하며 시스템적으로 강제화하지 못한다면 테넌트 데이터 격리가 실패할 보안 리스크가 항상 존재한다. TenantIsolationDataSourceWrapper를 통해 원래 Bean으로 등록된 DataSource를클래스로 감싸서 다시 Bean으로 등록해 쿼리의 테넌트 아이디 강제화를 달성하는 방법에 대해 알아보겠습니다 멀티 테넌트 환경에서 데이터 격리는 보안을 보장하기 위한 필수 요소이며 데이터 노출 리스크를 최소화하는 추가적인 보안 장치로 작용한다. 
"Redis Vs Mongo DB By Item View Count
","Redis Vs Mongo DB By Item View Count (이 상품 몇명이 보고 있어요) 안녕하세요 저는 VI Engineering 팀 김윤제입니다.
Gmarket Mobile Web Vip(View Item Page = 상품 상세)를 담당하고 있는 Backend Engineer 입니다. 이번 블로그에서는 개인적으로 상품 상세 페이지에 넣고 싶었던
현재 이 상품 몇 명이 보고 있어요 기능을 혼자 공부하며 개발해보는데 있어서 어떻게 설계를 해야 최적의 성능을 낼 수 있을지 고민하였고 그 과정을 설명드리려고 합니다.
자세한 내용은 아래에서 살펴보도록 하겠습니다. 요구사항은 다음과 같았습니다. 상품 별로 중복되지 않은 사용자가 몇 명이 보고 있는지 실시간으로 집계하여 보여준다.

현재 이 상품 몇 명이 보고 있어요 기능의 동작 과정은 다음과 같습니다. 사용자가 웹 또는 앱을 통하여 상품 상세 페이지에 접속한다. 상품 상세 서버에서는 상품 번호와 사용자 인식 정보를 데이터베이스에 저장한다. 상품 상세 서버에서는 데이터베이스에서 해당 상품번호에 몇 명의 사용자가 있는지 검색한다. 데이터베이스에서 검색한 사용자 수를 현재 사용자에게 반환한다. 접속 중인 사용자 (웹 또는 앱)는 주기적으로 상품 상세 서버에 현재 몇명이 이 상품을 보고 있는지 요청한다. 사용자가 이탈 (상품을 벗어남)하면 데이터베이스에서 해당 상품번호에 저장된 해당 사용자 인식 정보를 제거합니다. 5번에서 주기적으로 상품 상세 서버에 요청을 해야 하는데 웹 / 앱이 동일한 방법을 써야 관리하기가 쉬울 것 같다는 점에서 웹소켓 / 소켓이 아닌 API 요청을 받는 게 좋다고 생각했습니다. 실시간으로 쏟아지는 트래픽 속에서 집계를 해야 하는 상황이라 RDB로는 성능이 안 나올 것 같아 NoSql 데이터베이스를 선택했습니다.   이제 Nosql 데이터베이스 중 Redis와 MongoDb 사이에서 선택해야 했는데요.
아래에서 각 데이터베이스 별로 장단점을 알아보도록 하겠습니다.       Item View Count (지금 이 상품 몇 명이 보고 있어요) 기능은 실시간 집계가 필요하며 성능적으로도 빨라야 해서
고속의 인 메모리 기반의 데이터베이스 레디스를 생각하게 되었습니다. 하지만 레디스로 구현을 해당 기능을 올바르게 구현하기 위해서는 자료구조를 어떤 것을 선택하는지가 중요합니다.
아래에서 레디스에서 자료구조 선택하는 데 있어서 했던 고민들을 살펴보도록 하겠습니다. 자료 구조 선택의 과정 Set (1) 가정: 제일 먼저 생각했던 방법입니다. (굉장히 간단할 것이라고 생각했습니다.)   Set 자료구조에 Key로 상품번호를 넣고, Value에 사용자 인식 정보를 넣는다면 ex (key = ""123456789"", value=""rlanwl"") 사용자는 중복되지 않을 것이고, Insert, Select 시간 복잡도 O(1) 성능 이슈 X 앱은 라이프 사이클에 따라 웹은 브라우저 종료 감지로 사용자 이탈 시 제거하면 럭키 비키합니다.   현실: 파이어 폭스 같은 브라우저는 자바스크립트의 종료 감지 이벤트가 안될 수 있습니다. 네트워크 이슈로 종료 감지를 못하면? Set에 저장된 데이터는 영영 삭제되지 않는 문제가 있습니다. 유감.   Set (2) 위와 같은 방식으로 저장하되 각 키에 ExpireTime (60초)를 설정 그럴 경우 만약 1번 상품에 대하여 60초 동안 아무도 안 본다면 1번 상품을 레디스에서 삭제. 레디스에서 삭제가 되려면 60초 동안 각 상품을 안 봐야 하는데... 새벽에나 가능하지 않을까 또한 최대한 사용자 수를 동기화를 해야 하는데 너무 오차가 크다는 문제가 있습니다. 유감.   Set X Hash 가정: Set 자료구조에 Key로 상품번호를 넣고, Value에 사용자 인식 정보를 넣고.. Hash에는 모든 상품과 사용자 정보, 현재 시간을 넣어서 별도의 Batch을 통해 이탈 감지 실패한 케이스들을 삭제합니다. Insert, Select 시간복잡도 O(1)   현실: Hash에 저장된 데이터를 Batch 을 통해 지울 경우 모든 상품을 검사하며 저장된 모든 유저들의 저장시간을 비교해야 하는데 해시에 저장된 모든 키 조회로 인한 레디스 부하 -> 시간 복잡도: O(N) (Hash의 필드 수) 키 리스트를 순회하며 유저 조회 후 날짜 비교 어플리케이션 부하 Sorted Set 가정: Sorted Set에는 Key, Value, Score을 저장할 수 있으니 Key에는 상품번호, Value에는 사용자 인식 정보, Score에는 현재 시간을 저장합니다. -> 시간 복잡도 O(log n) 중복된 Value를 허용하지 않으며 동일한 데이터 입력 시 Score를 업데이트할 수 있습니다.   현재 상품을 몇 명이 보고 있는지는 해당 Key에 저장된 길이를 구하면 됩니다. -> 시간 복잡도 O(1) 또한 Sorted Set에는 ZREMRANGEBYSCORE라는 명령어가 있는데 이 것을 활용하면 일정 시간 동안 Score가 업데이트되지 않은 사용자 정보를 제거 할 수 있습니다.   현실: 가장 이상적인 자료구조 조합이지만 Batch를 돌려서 일정 시간 동안 Score가 업데이트 되지 않은 사용자 정보를 제거해야 하는데 SortedSet에 저장된 모든 키를 다 찾아야 합니다. => ZRANGE 시간 복잡도 O(log n + m) 그 키 별로 ZREMRANGEBYSCORE 명령어를 실행해야 하기 때문에 => 시간 복잡도 O(log n + m)   총 시간 복잡도는 O(log n + m) + 상품 수 * O(log n + m)으로 레디스의 부하가 예상되나 SortedSet에 저장된 상품별 사용자 정보에서 얼마나 많은 수의 이탈 감지 실패가 발생했는지가 관건 Batch도 언제 돌릴지가 관건이었습니다. (하지만 이탈 감지 실패는 그렇게 많지 않을 것으로 보이기 때문에 이 자료구조를 선택하였습니다.)   위 Set  X Hash 구조와 성능적으로는 크게 차이가 나지 않지만 확실히 SortedSet 자료구조가 가져다주는 편리한 이점이 있어서 해당 기능을 사용하였습니다. 이번에는 몽고 DB에서는 어떨지 살펴보았습니다.   	몽고 디비에서는 아래와 같이 2가지 설계를 생각해 보았습니다. 첫 번째, 다음과 같이 컬렉션 구조를 가져갔습니다. userProductView   Flow는 다음과 같습니다. userProductView -> 상품 별로 사용자 인식 정보와 현재 시간을 upsert한다. -> 시간 복잡도 O(log n) 위 userProductView에 저장된 상품 번호 별 document 수를 구한다. -> 시간 복잡도 O(n) 위 2번에서 구한 상품 별 ViewCount를 반환한다. 이 구조는 생각보다 레디스보다 간단해 보이지만 숨은 내용이 있었습니다. 검색 속도 개선을 위한 인덱스 설정
몽고 디비를 사용할 경우 userProductView 컬렉션에 itemNo(상품 번호) 필드에 index를 걸어야 합니다. 사용자 수 동기화를 위한 timestamp에 expire를 설정
몽고 디비를 사용할 경우 각 도큐먼트 별로 expire를 설정할 수 있기 때문에
레디스처럼 별도의 Job을 구성하여 이탈 감지 실패 케이스들에 대하여 검사를 할 필요가 없습니다.
하지만 정확한 만료 시간 보장이 어렵다는 단점이 있으며, 성능 저하가 있을 수 있습니다.   두 번째, 다음과 같이 하나의 컬렉션 구조를 가져갑니다. 동작 Flow는 다음과 같습니다. 상품 조회 => 인덱스가 있는 경우 O(log n) 또는 인덱스가 없는 경우 O(n)
사용자가 상품을 조회할 때, 해당 itemNo에 대한 Document를 찾아야 합니다.
사용자 정보를 users 배열에 추가하여 timestamp를 갱신합니다.
해당 itemNo에 expire 설정 상품에 속한 users 배열을 순회하며 특정 시간 기준으로 활동하지 않은 user라 판단하는 비교 로직을 수행해야 하므로, 배열의 크기에 따라 O(n)시간이 걸립니다. 배열에 사용자 추가 => O(1) 하지만 이 방식에도 문제가 있었습니다. 상품 번호에 expire가 설정되어 있기 때문에 실제로 자주 보는 상품이라면 삭제가 되지 않을 수 있어서 데이터의 양이 엄청나게 커질 수 있습니다. 그럴 경우 상품 전체 조회 O(n) + user 배열 순회 O(n) + 배열 삭제 및 업데이트 O(n) 이에 따라 또다시 Batch Job을 구성해 삭제해야 하는... 레디스와 몽고 DB를 전체 Flow에 시간복잡도를 비교해 보았을 때 테이블로 보면 다음과 같습니다.   	해당 기능을 구현하기에 있어서 실시간이라는 점, 여러 도메인에 조회 기능을 제공해야 한다는 점에서 보면 성능적으로 레디스가 나을 듯합니다.
하지만 레디스는 가격이 비싸다는 가장 큰 문제가 있습니다.   복잡성과 유지보수면에서는 Batch Job이 없는 몽고 DB가 더 나아 보이지만,
몽고 DB는 Index 설정, Expire 설정 등 따져야 할 게 몇 가지 있습니다. 각 데이터베이스별로 장단점이 있어서 어떤 것을 사용하는 게 좋을지는 면밀히 검토해봐야 할 듯합니다.   처음에는 간단할 것이라 판단하였지만 생각보다 따져볼 것이 많아 복잡했습니다.
만들고 싶었던 기능을 이것저것 따져가며 여러 데이터베이스와 비교를 해보는 것도 꽤 재미있는 경험이 되었습니다. 이제는 주니어보단 시니어 개발자에 가까운 연차가 되어가네요.
꾸준히 노력하여 부끄럽지 않은 개발자가 되도록 하겠습니다. 감사합니다. 트밀
몽고와 레디스를 시간복잡도별로 비교해서 저도 검토하는데 도움될 것 같아요. 감사합니다.
2024.09.28 18:35 신고 workingscorpion
좋은 자료 잘 보았습니다.
글 초반 개발하고자 하는 내용만 들었을때는, 저 역시 set구조의 간단한 구조만을 처음 떠올렸습니다.
백엔드 입장에서 frontend에서 발생가능한 firefox등과 같은 특이케이스까지 고려하는 점을 본받아야겠네요 ㅎㅎ

추가적으로 궁금한 부분인데,
ZSET에서 timestamp를 score로 쓰실텐데, 꼭 배치를 통해 정리해주어야할까요?
정책만 명확하다면, 새로운 유저가 접근해서 zset이 업데이트되는 시점에 정리해줄 수 있지 않을까요?
이런 생각을 해봅니다 ㅎㅎ
2024.09.30 11:16 신고","https://surfit.io/link/28E40
",현재 상품 상품 몇 명이 보고 있어요 기능은 실시간 집계가 필요하며 성능적으로도 빨라야 해서 고속의 인 메모리 기반의 데이터베이스 레디스를 생각하게 되었습니다 Key로 상품번호를 넣고 Value에 사용자 인식 정보를 넣으면 Value를 허용하지 않으며 동일한 데이터 입력 시 Score를 업데이트할 수 있다. 몽고 DB는 상품 별로 사용자 인식 정보와 현재 시간을 upsert한다-> 시간 복잡도 O(n) 위 userProductView에 저장된 상품 번호 별수를 구한다-> 시간 복잡도 O(n) 위 2번에서 구한 상품 별 ViewCount를 반환한다이 구조는 생각보다 레디스보다 간단해 보이지만 숨은 내용이 있었습니다 몽고와 레디스를 시간복잡도별로 비교해서 검토해야 할 것 같습니다 백엔드 입장에서 frontend에서 발생가능한 firefox등과 같은 특이케이스까지 고려하는 점을 본받아야겠습니다