TL;DR거래대금 상위 50개 기업 조회 API가 임시 테이블 정렬로 인해 10초 이상 걸리자 redis에 캐싱해 3초까지 줄였지만 실시간 주가 50회 개별 조회가 RTT 70 ms씩 추가돼 병목이 남았다. redis 파이프라인을 활용한 벌크 조회로 redis 요청을 50→1회로 줄여 최종 응답을 200 ms 이하로 단축했고, 병목은 항상 ‘가장 느린 부분’을 찾아야 한다. 최근 신규 서비스를 준비하며 신규 API를 개발하는 일이 많았는데, 그중 API 성능을 높이기 위해 Redis 캐시를 도입하여 성능 개선을 시도했으나 기대한 만큼 개선 효과를 보지 못한 일이 발생하였습니다. 이번 글에서는 해당 성능 이슈의 원인을 알아보고, 병목 지점을 분석하여 API 성능을 개선한 해결방안을 정리해보려고 합니다. 문..

TL;DR단일 스레드에서 멀티스레드로 전환했음에도 배치 성능이 개선되지 못했던 이유MySQL CPU 사용률 99%가 병목의 원인이었으며, 이는 비즈니스 요구사항 때문에 불가피했던 LIKE 패턴 매칭 쿼리 때문이었습니다. 문제 해결을 위해 LIKE 쿼리를 IN 절로 변환하는 작업을 진행했고, 그 결과 CPU 사용률은 20% 이하로 떨어지고 배치 처리 시간은 10분에서 단 25초로 단축되어 사용자들이 최신 데이터에 즉시 접근할 수 있게 되었습니다. "배치 성능 개선? 그거 멀티스레드 쓰면 해결되는 거 아니었어?"아마 많은 개발자분들이 저와 같은 생각을 해보셨을 겁니다.저는 사용자에게 최신 데이터를 제공하는 신규 기능을 개발하고 있었습니다. 이 신규 기능의 핵심은 사용자가 원하는 특정 기준으로 데이터를 커스텀..

멀티 스레드로 병렬 처리하는 것은 항상 성능에 이점이 있을까?업무를 진행하며 멀티 스레드로 성능 개선을 할 일이 있었는데, “멀티 스레드로 병렬 처리하는 것이 항상 성능 향상에 이점이 있을까?”라는 의문점이 생겼습니다. 가령, 스타크래프트 같은 게임에서 일꾼 수가 많을수록 더 많은 미네랄을 동시에 캐는 것처럼, 스레드가 많으면 그만큼 동시에 처리할 수 있는 작업이 많아져서 단일 스레드보다 빠르다고 생각하기 쉽습니다.저도 처음엔 “스레드가 많으면 빠르다, 따라서 스레드 수와 애플리케이션의 성능 속도는 정비례한다”고 단순하게 생각했습니다.하지만 실제로는 꼭 그렇지만은 않습니다. 예를 들어 단일 스레드로 동작한다고 알고 있는 Redis는 매우 빠른 처리 속도를 보여주는데, 이는 “단일 스레드 = 느리다”라는 ..

TL;DRPPT 보고서를 LLM을 통해 특정 형식(JSON)으로 요약할 때, 키워드 누락 문제가 발생하여 명시적 지시문 추가, Chain-of-Thought(생각의 사슬), 역할 기반 프롬프팅, 퓨샷(Few-Shot) 프롬프팅 등 다양한 전략을 시도함.결과적으로 원샷 대신 퓨샷 프롬프팅으로 변경하니 입력 토큰은 약 22% 증가했지만, 키워드 누락 없이 정확도가 크게 개선됨.비용과 정확성의 트레이드오프를 고려했을 때 퓨샷 프롬프팅이 효과적임을 확인함.  PPT로 작성된 보고서를 텍스트만 전달하여 LLM 기반으로 보고서를 특정 형식에 맞게 요약하는 시스템을 개발하고 있었습니다. 현재 이슈는 보고서의 특정 슬라이드에 포함되어 있는 키워드들만 가져와서 요약해줘야 했는데, 키워드들이 누락되어 요약되는 이슈가 있었..

TL;DR주식 시장 마감 후 코스피/코스닥 종목의 종가와 수익률을 계산해 시황 피드를 생성하는 시스템에서 종가 변동률 계산 오류가 발생했습니다. 문제는 시황 정보 생성 시점에 당일 종가 정보가 DB에 아직 저장되지 않아 이전 영업일 데이터를 참조한 데 있었습니다. 이를 해결하기 위해 피드 생성 서버 코드를 수정하여 시황 정보 수신 시 종가 데이터 유무를 확인하고, 종가 정보가 없으면 상태를 저장한 후 스케줄러를 통해 주기적으로 재시도하는 방안을 도입했습니다. 이로써 데이터 정합성을 확보하고 버그를 수정했습니다. 항상 버그는 퇴근하고 발생하는 것 같은 기분이 듭니다.  주식 시장이 마감되고 코스피/코스닥에 상장된 종목들의 종가 및 종목 수익률을 계산하여 당일 시황의 전반적인 상황을 피드로 생성하여 제공하는..

문제기존 Protobuf 포맷으로 정의된 스키마(Version 1)에 새로운 inner message를 생성하여 스키마 버전(Version 2) 업을 하는 경우 이전 버전 스키마가 새로 생성한 inner message 를 참조하지 못하여 스키마 업그레이드를 하지 못하는 문제가 발생. 해결스키마에 inner message를 생성하는 방식이 아닌 별도의 schema를 생성하여 수정할 스키마에서 이를 참조하는 방식으로 해결 + Terraform Provider로 Confluent Schema Reference 적용 시 발생한 문제A스키마에서 B스키마를 참조할 경우 참조할 스키마(B)가 먼저 생성이 되어 있어야 한다. "A" 스키마에서 새로운 메시지인 "B" 스키마를 참조하려고 할 때, "B" 스키마 생성과, ..