모든 블로그
채널톡

채널톡

주요 카테고리 AI · 백엔드

활동 요약

대표 인기 포스트Grafana Mimir에 Kafka를 도입하기 전 미리 알았다면213 조회
최근 30일
12개
평균 조회
32
누적 조회
4,647
전체 글
147개
마지막 발행
2026. 11. 13.
블로그 방문

채널톡 기술 블로그 글 (32)

백엔드

메시지 전송 트래픽 100배에도 끄떡 없는 User 테이블로 뜯어고치기 (2)

DynamoDB Export/Glue/Import로 UserBadge를 분리해 16억 건 규모 마이그레이션을 수행했습니다. 비용은 36% 줄고 시간은 7일에서 약 6시간으로 단축했습니다.

#DynamoDB#AWS Glue#S3
900

백엔드

메시지 전송 트래픽 100배에도 끄떡 없는 User 테이블로 뜯어고치기 (2)

User 테이블의 Badge 트래픽 병목을 분리해 온라인 마이그레이션으로 이전했습니다. AWS 관리형 서비스를 활용해 비용과 시간을 크게 줄이고 안정성도 높였습니다.

#DynamoDB#AWS Glue#S3
3000

백엔드

급증하는 트래픽 안정적으로 처리하기: 개선편(2) 논리적 파티셔닝

단일 Queue의 HOL Blocking과 인스턴스 단위 스케일링 비효율을 논리적 파티셔닝으로 개선했습니다. Partition별 독립 스케일링으로 10만 건 처리 시간을 25분에서 4분으로 줄였습니다.

#Redis#Kafka#AWS Lambda
1400

백엔드

급증하는 트래픽 안정적으로 처리하기: 개선편(2) 논리적 파티셔닝

단일 큐에서 발생하던 HOL Blocking을 논리적 파티셔닝으로 완화했습니다. Coordinator 기반 독립 스케일링으로 10만 건 처리 시간을 84% 줄였습니다.

#Redis#Kafka#partitioning
2100

백엔드

급증하는 트래픽 안정적으로 처리하기: 개선편(1) 동적 스케일링

벌크액션 트래픽에 대응하기 위해 PWQD를 핵심 메트릭으로 삼아 동적 스케일링을 설계했습니다. 연속 초과 시 확대하고 Time Decay로 축소해 Spike에도 안정적으로 대응했습니다.

#traffic#동적 스케일링#Kubernetes
1700

백엔드

급증하는 트래픽 안정적으로 처리하기: 개선편(1) 동적 스케일링

벌크액션 트래픽의 지연과 오실레이션 문제를 해결하기 위해 동적 스케일링을 개선했습니다. PWQD와 Time Decay를 결합해 Spike에도 안정적으로 대응했습니다.

#동시성#traffic#system
2400

백엔드

고객 타게팅을 좀 더 정교하게, ClickHouse 도입기

고객 타게팅 정교화를 위해 주문·쿠폰·장바구니 데이터를 ClickHouse 기반 OLAP로 옮긴 과정을 정리했습니다. 다만 ReplacingMergeTree, JOIN, Point Query 한계를 보완하려고 하이브리드 아키텍처를 함께 도입했습니다.

#ClickHouse#OLAP#PostgreSQL
1100

백엔드

고객 타게팅을 좀 더 정교하게, ClickHouse 도입기

고객 타게팅 정교화를 위해 대용량 커머스 데이터를 처리할 OLAP로 ClickHouse를 도입했습니다. 다만 JOIN, Point Query, 업데이트성 데이터 제약은 Hot/Cold 분리와 보조 저장소로 보완했습니다.

#ClickHouse#OLAP#RDBMS
3600

백엔드

메시지 트래픽 100배에도 끄떡 없게 고객 테이블 뜯어고치기 (1)

16억 건 규모의 User 테이블에서 Badge 업데이트가 쓰로틀링을 유발한 원인을 분석했습니다. Badge를 별도 테이블로 분리하고, Export/Import와 Glue로 안전한 마이그레이션 전략을 설계했습니다.

#DynamoDB#AWS Glue#ETL
800

백엔드

메시지 트래픽 100배에도 끄떡 없게 고객 테이블 뜯어고치기 (1)

Badge 업데이트가 User 테이블 전체를 느리게 만든 원인을 분석하고, 별도 테이블 분리 전략을 설명했습니다. 16억 건 규모를 안전하게 옮기기 위해 Export/Import와 Glue 기반 마이그레이션을 설계했습니다.

#DynamoDB#AWS Glue#ETL
2400

백엔드

Cursor + Git Worktree 병렬 개발 한계와 해법

Cursor와 Git worktree를 함께 써서 단일 레포 병렬 개발의 브랜치 충돌과 인덱싱 부담을 줄였습니다. PLAN and ACT 규칙과 이슈 분해로 AI IDE 작업의 컨텍스트 전환 비용도 낮추는 방법을 소개했습니다.

#Cursor#Git#Linear
800

백엔드

Cursor + Git Worktree 병렬 개발 한계와 해법

Cursor와 단일 레포 병렬 작업의 한계를 Git worktree로 해결한 사례를 정리했습니다. 또한 랜덤 포트 설정과 PLAN and ACT rule로 테스트 충돌과 컨텍스트 전환 부담을 줄였습니다.

#Cursor#Git Worktree#Context engineering
1900

백엔드

Distributed Cache 도입기 (3): RDB 조회 90% 감소시키기

BillSetting 조회 부하를 줄이기 위해 로컬 캐시와 Redis 글로벌 캐시를 시도했지만 각각 한계와 병목을 겪었습니다. 이후 Redis Pub/Sub 기반 분산 캐시로 전환해 RDB 조회를 93% 줄였습니다.

#Redis#cache#RDB
800

백엔드

Distributed Cache 도입기 (3): RDB 조회 90% 감소시키기

BillSetting 조회 부하를 줄이기 위해 로컬 캐시와 Redis 글로벌 캐시를 검토했지만 각각 한계가 있었습니다. 결국 Redis Pub/Sub 기반 분산 캐시로 전환해 RDB 조회를 93% 줄였습니다.

#Redis#cache#RDB
2100