본문 바로가기

전체 글142

정렬 버블정렬가장 큰 값이 가장 뒤로 떠오른다(bubble)시간복잡도 n^2실제연산은 n(n-1) / 2 숫자가커질수록 대략적으로 n^2에 가깝게 증가0인덱스부터 옆자리와 비교하면서 위치를 바꾸면서 뒤로간다 그러다보면 가장 오른쪽 제일 큰수부터 하나씩 완성하는것4개 6회10개 45회100개 4950회1000개 499500회n^2의 절반에 가깝게증가함4321342132413214231421341234선택정렬버블정렬과 반대로 앞에서 최솟값부터 채워나간다.가장앞 인덱스를 최솟값으로 지정배열전체를 탐색하며 최솟값을 갱신최솟값지점과 가장앞 인덱스를 교체그 다음 인덱스도 반복시간복잡도 n^2실제연산은 n(n-1) / 2 432113241234버블정렬보다 스왑은 2배 적지만 모든 배열을 탐색하므로 시간복잡도는n(n-1) .. 2025. 12. 6.
작성자 검색 인덱스 사용 불가 문제 해결 게시판의 제목, 제목+내용 검색에는 FULLTEXT 인덱스를 적용했지만, 작성자 검색에는 적용하지 않았습니다. FULLTEXT에는 불용어 개념이 있습니다. 한마디로 텍스트를 언어의 개념으로 간주하여 의미가 있는 제목, 내용에는 적합하나 주로 의미 없는 문자열로 구성된 작성자 검색에는 부적합하다 생각했습니다. 문제 진단 및 원인 분석따라서 유니크 인덱스를 이용하여 작성자 검색을 하게 되는데 %LIKE% 검색 시 유니크 인덱스를 사용할 수 없다는 문제가 있었습니다. 이로 인해 인덱스를 포기하고 %LIKE%로 정확성을 확보할 것인지, 혹은 인덱스를 활용하여 속도를 확보할 것인지 고민했습니다.다음과 같은 분석을 통해 해결책을 모색했습니다.짧은 검색어일수록 중간 단어 검색(%LIKE%)을 선호하는 경향이 있습니다.. 2025. 11. 25.
배치 기반 친구 추천 API의 실시간 전환 목차1. 기존 방식 및 문제점 1.1 기존 친구 추천 API 방식 1.2 기존 방식의 문제점 1.3 실시간 조회를 구축하기 위해 반드시 해결해야 할 것2. 결과 요약 2.1 원인 2.2 성능 지표 2.3 성과 요약3. 설계 목표와 고민 3.1 설계 목표 3.2 고민과 대안 4. 실시간 친구 추천 API 아키텍처5. 테스트 5.1 테스트 결과 5.2 친구가 많고 많은 추천친구를 보여줘야하는 상황의 테스트 결과 5.3 레디스 장애시 DB조회 테스트 결과6. 정합성 1. 기존 방식 및 문제점1.1 기존 친구 추천 API 방식아래는 기존 친구 추천 API의 아키텍처입니다.1시간마다 전체 유저를 대상으로 기준에 따라 친구 점수를 계산한 뒤, 상위 10.. 2025. 11. 23.
분산락에서 비동기 스레드풀 실행 거부 예외 식별과 해결 서론캐시 스탬피드를 발견하고 많은 스레드가 DB를 동시 접근 하는 것을 방지하기 위해 다양한 방식의 해결법을 적용하던 과정에서 분산락을 적용했을 때 게시글을 조회하지 못하는 오류가 발생했습니다.요약캐시평균 Throughput캐시 갱신 시 레디스 CPU 사용량캐시 갱신 시 실행거부 오류분산락 개선 전2350.06%RejectedExecutionExeption 466건분산락 개선 후2600.03%오류 0건 증상 요약1. 캐시 스탬피드 해결2. 커넥션 획득 시간 50배 감소3. 레디스 메모리 사용량 1.8배 감소4. TTL 만료시 비동기 스레드로 캐시 갱신을 할 때 RejectedExecutionExeption 발생 결론 요약1. 비동기 스레드에서 waitTime을 설정해 스레드 풀 병목이 발생했다. wai.. 2025. 11. 19.
Redis TTL 만료 시점 병목 해소: Cache Stampede 방어 전략 측정 및 분석 스탬피드 현상의 측정과 방어 이전에 캐시 다이어그램을 보여드리겠습니다.아래 사진은 제 기존 캐시 설계입니다. 빠른 복구를 위해 Tier2로 설계했습니다.아래 사진은 캐시 전략입니다.아래 사진은 전체 캐시 흐름도 입니다. 캐시 스탬피드의 방법들에 대해 측정했습니다.10분간 부하테스트를 실시했습니다.글 상세 조회 30%주간 인기글 상세 조회 14%레전드 인기글 상세 조회 10%실시간 인기글 목록 조회 20%주간 인기글 목록 조회 14%레전드 인기글 목록 조회 12%로 구성했습니다.테스트 시작후 8분까지 선형적으로 램프업 해나가며 마지막 2분은 최대 부하를 유지했습니다.최대 부하는 사용자 300명이 0.4초에 한 번씩 요청을 보냅니다.커넥션 풀은 30으로 고정하였습니다.캐시최대 TPS평균 Latancy레디스.. 2025. 11. 3.
Redis를 활용한 게시판 캐싱 커뮤니티 게시판의 인기글 목록 조회 시 다음과 같은 비효율적인 부분이 있었습니다.1. 반복적인 DB 조회 부담 : 자주 조회되는 실시간/주간/레전드 인기글 목록을 DB에서 조회하여 응답 시간이 증가했습니다.2. 실시간 인기도 반영의 어려움: RDB만으로 글의 인기도를 실시간으로 반영하려면 요청마다 복잡한 인기글 재선정 로직이 필요했습니다.따라서 자주 조회되는 요청은 캐싱을 하여 DB의 부담을 낮추고자 했습니다. 캐싱 요구 사항TTL이 만료되어도 집계 쿼리가 재실행되면 안됩니다.실시간 인기글은 사용자 활동(조회, 댓글, 추천)에 따라 동적으로 변화합니다.글이 삭제되거나 수정되었을 때 사용자는 이전 버전의 글을 보면 안됩니다.자주 조회되고 변하지 않는 인기 게시글 목록은 통째로 캐싱하여 반환해야 합니다.캐시.. 2025. 11. 2.

티스토리툴바