분류 전체보기
-
2025.04.29 좋아요 정렬TIL 2025. 4. 29. 23:58
Case 1'좋아요'를 구현할 때 어찌해야 하는가를 다루고 있습니다. 정렬을 제외했을 때는..데이터가 많지 않다면 post_like 매핑 테이블을 만들어서 group by sum을 통해서 값을 얻을 수 있습니다.데이터가 많아지면 버퍼에 없을 가능성이 커지므로 디스크 IO가 증가하게 될 것입니다.또 group by이기 때문에 임시 테이블을 사용하게 되고, 데이터가 많으면 디스크 스필이 이뤄지게 되고 더 느려지게 됩니다.그럼 그때 성능 최적화를 하면 됩니다. Case 2성능 최적화 방법으로는 뭐가 있을까요?음..캐시 생각하기 전에 게시물당 좋아요를 카운팅 하는 테이블을 둡시다.게시글에 칼럼에 카운팅을 두지 않으므로서 게시물의 데이터 경합에서 벗어날 수 있습니다. 좋아요 카운팅 경합이 더 많겠지요? post_..
-
2025.04.27 high-load-queueTIL 2025. 4. 27. 22:45
이 영상을 보고 만들어봤습니다. 최근 임영웅 티켓팅을 해봤는데 수십만 대기열이 생겼던 기억이 있습니다.부하가 생길 때, 트래픽에 성격에 따라 모두 수용이 아닌 대기열을 줄 수 있습니다.티켓팅 성격의 공유자원은 대기열을 도입할 수 있습니다.대기열과 참가열을 나누는 것이지요. 스케줄러는 참가열에서 소화할 수 있을 만큼만 대기열에서 가져옵니다.주문을 완료한 고객은 참가열에서 나가게되고 순환이 이뤄지게 됩니다.대기열 발행 서버는 처음 트래픽을 견딜 수 있어야 합니다. 대기열 구조는 레디스의 sorted set을 사용해서 구현되었습니다.timestamp를 score로 가져가고 순위를 정할 수 있습니다.sorted set의 시간복잡도는 log n이기 때문에 데이터가 많아지면 오래걸리는 문제는 있습니다. Some u..
-
카프카 부하 분산: 동적 쓰로틀링과 캐시글또 2025. 4. 26. 22:59
들어가며안녕하세요.이번 글에서는 카프카 기반 쓰로틀링에 대해 이야기 해보려합니다. 서비스 특성상 특정 시간대에 카프카 트래픽이 집중되며 DB 병목이 발생하는 문제가 있었습니다.단순히 서버를 증설하는 방식보다는 현재 가지고 있는 자원을 활용해 문제를 해결하고자 했습니다. 해결 전략일반적으로 부하 해결을 위해 자주 사용하는 방법은 캐시, DB 읽기/쓰기 분리, 쓰로틀링 적용입니다.저희 서비스에는 아직 글로벌 캐시를 적용하지 않았습니다.또 트래픽이 항상 높은 게 아니라 특정 시점에만 몰리는 구조였기 때문에, 상시 유지되는 캐시는 오히려 불필요한 관리 포인트 증가라고 생각했습니다.결국, 현재 리소스 내에서 문제를 해결할 수 있는 방법으로 동적 쓰로틀링 전략을 선택하게 되었고, 필요에 따라 캐시를 결합해 트..
-
2025.04.18 disk IOTIL 2025. 4. 16. 23:46
여태까지 큰 테이블에 대한 쿼리를 조사한 이유가 있습니다.큰 테이블 조회가 DB서버의 전체적인 부하를 줄 수 있을까요?예상 추측.전체적인 부하는 CPU와 메모리 부하로 생각해 보겠습니다.이들이 높은 수치를 기록하면 응답지연이 발생하게 됩니다. 쿼리들의 전체적인 응답지연이지요.IO의 증가가 어떻게 전체적인 지연으로 연결될까요.단순히 "로우 수가 많아서 I/O가 많아졌다"이 자체는 단일 쿼리 성능만 떨어뜨립니다.하지만 그 쿼리가 동시 다발적으로 들어오면, 디스크 병목 + 스레드 블로킹 + 요청 대기 전체적인 응답 지연으로 확산됩니다 로우 수 증가 처리 데이터양 증가 → 각 쿼리 I/O 증가캐시 효율 낮음 디스크 접근 비율 ↑ 요청 수 증가 디스크 병렬 한도 초과 I/O queue 적체스레드(쿼..
-
2025.04.16 huge tableTIL 2025. 4. 16. 22:26
어제 이야기했던 것을 마저 이야기해 보겠습니다.로우가 많아져서 느려지는 원인에 대한 이야기를 했습니다.조회 검색 시 데이터를 읽을 때, 가령 인덱스가 커서 버퍼 풀에 전부 적재되지 않아 캐시 미스, 디스크 IO가 빈번하게 이뤄질 것입니다. (결괏값은 result buffer에 저장)카운트도 인덱스를 사용했다고 해도 로우가 많으면 전체 인덱스가 버퍼에 올라가지 않을 것이며 이 또한 디스크 IO가 이뤄진다는 것입니다. 카운트가 추가적인 연산이 있다기보다는 전체 로우를 읽는 경우가 많기 때문에 느리다고 인식할 수 있습니다.버퍼 풀이 핵심이라는 것입니다. 사실 캐시의 개념이 다 그렇지요. 조인을 하게 된다면 nested loop join이기 때문에 드리븐 테이블이라 하더라도 순회를 많이 하게 되겠죠. 또 정렬,..
-
2025.04.15 nested loop join, huge tableTIL 2025. 4. 15. 22:04
어제 공부하던 것을 복습해 보겠습니다.join 시 대표적인 알고리즘으로 nested loop join이 있습니다.이는 드라이빙 테이블을 기준으로 드리븐 테이블을 순회하도록 구현되어 있습니다.순회 시 인덱스가 없을 경우드라이빙 테이블과 드리븐 테이블은 n * m으로 동일해 보이지만, 데이터 페이지 접근을 생각해야 합니다.예로 A테이블은 튜플이 10개, 데이터 페이지 IO는 1번입니다. B테이블은 튜플이 100개 데이터 IO는 10번입니다.A를 드라이빙 테이블로 하게 된다면 A데이터 페이지 IO(1) + [A튜플(10) * B데이터페이지(10)] = 101이 됩니다.B를 드라이빙 테이블로 하게 된다면 B데이터 페이지 IO(10) + [B튜플(100) * A데이터페이지(1)] = 110이 됩니다. 차이가 얼마..
-
2025.04.14 nested loop joinTIL 2025. 4. 14. 21:23
mysql 기반입니다. 조인이 많으면 성능에 영향일 준다. 왜 일까?가장 기본이되는 nested loop join의 동작을 살펴봅시다. 드라이빙 테이블이 드리븐 테이블을 순회하면서 조회합니다.For each tuple r in R do For each tuple s in S do If r and s satisfy the join condition Then output the tuple 드리븐 테이블에 인덱스가 걸려 있어야 빠른 조회가 가능할 것입니다.조인이 많아지면 순회해야하는 테이블이 많아지기에 느려질 것입니다.중첩의 중첩이겠지요? 궁금한 것이 있습니다.둘 다 인덱스가 없다면 왜 작은 테이블을 드라이빙 테이블로 해야할까요?두 경우 모두 N * M인데 말이죠.데이터는 데이터 페이지에 저장..
-
2025.04.13 kafka-consumer-throttling 부하 전염TIL 2025. 4. 13. 18:07
2025.04.08 kafka-consumer-throttling카프카 컨슈머에 동적 쓰로틀링 적용하기 | 우아한형제들 기술블로그이 글은 카프카(Kafka)를 사용하는 스프링 환경에서 메시지 처리 속도를 동적으로 조절해야하는 상황과 여러 쓰로틀링 기법gisungcu.tistory.com 기본적인 구조는 위와 같습니다. 카프카 브로커에 커밋을 보내기 전 프로메터우스를 통해 서드파티(ex.DB)의 부하를 확인한다는 것이죠.부하가 서드파티뿐 아니라 프로메테우스에도 전염이 되지 않을까? 생각했습니다. 1. max.poll.records sizeack 설정이 batch인 경우에는 max.poll.records이 끝나고 프로메테우스를 조회합니다.총메시지가 10,000개이고 max.poll.records가 100..