Tech (6) 썸네일형 리스트형 다시 느려진 쿼리를 마주했을 때__레거시 프로시저 튜닝기 운영 중인 시스템에 고객 전환 현황을 보여주는 통계 화면이 있다.2~3년 전에 한 번 튜닝했던 화면인데, 어느새 조회 버튼을 누르면 2분 41초가 걸리는 화면이 되어 있었다.이 글은 그 화면을 두 번째로 튜닝한 기록이다.무엇이 다시 느려지게 만들었는지, 이번에는 무엇을 다르게 했는지, 그리고 시도했다가 버린 것들까지.TL;DR한 번 튜닝했던 Oracle 통계 프로시저가 데이터가 쌓이면서 다시 2분 41초까지 느려졌다.두 번째 판에서는 실측(A-Rows)으로 병목 다섯 개를 확정하고, 쿼리를 "항목이 늘어도 스캔이 늘지 않는 구조"로 다시 짰다 — 반복 스캔은 CTE 한 벌로, 행마다 돌던 서브쿼리는 조인으로, 대형 정렬은 고정폭 문자열 MAX로.DBA 손을 빌리지 않고 쿼리 변경만으로 161.7초가 62.. 돌려보내지 않고, 잠깐 기다리게 하기 블랙 프라이데이급 트래픽에도 시스템을 보호하면서, 유저에게 공정한 대기 경험을 제공할 것.주문 API 앞단에 Redis 기반 대기열을 세우는 과제였다.막상 만들기 시작해보니 이 한 줄 안에 답해야 할 질문이 다섯 개나 들어 있었다.질문마다 선택지가 있었고, 뭘 고르든 아쉬운 점이 하나씩 남았다. 이 글은 그 다섯 개의 질문에 어떻게 답했는지의 기록이다.TL;DR주문은 유저에게 "기회"라서, 거부(429) 대신 줄을 세웠다.순번은 Redis INCR로 겹치지 않게 매기고, 입장 속도는 커넥션 풀에서 거꾸로 계산해 초당 100명 — 몰아넣지 않고 100ms마다 10명씩 나눠 들여보낸다.입장 토큰은 실패한 유저가 다시 시도할 수 있도록 주문이 성공했을 때만 지우고, 기다리는 유저에게는 예상 시간과 조회 주기(.. Kafka는 이벤트를 잃지 않는다, 도달했다면 Kafka에 send() 하나면 끝난 줄 알았다한 줄이면 될 줄 알았다.kafkaTemplate.send("catalog-events", productId, event);TX가 커밋되면 Kafka로 흘러가고, Kafka가 이벤트를 잃지 않도록 보관하고, Consumer가 집계한다. 실제로 대부분의 시간엔 그대로 굴러간다.문제는 "대부분"에 있었다.broker가 잠깐 죽거나, 옵션 조합이 어긋나거나, ISR이 부족한 그 짧은 순간에 이벤트가 조용히 사라진다. 조용해서 놓치기 쉽다. "Kafka는 durable하다"는 말은 실은 이벤트가 도달하고 나서의 얘기였고, 도달 이전은 다른 문제였다.그 도달 실패의 순간을 직접 봐야 Outbox Pattern이 왜 필요한지 감이 온다. 3-broker 클러스터를 세팅.. Resilience4j CB, 기본 설정만 믿으면 안 된다 TL;DRResilience4j 서킷브레이커(이하 CB)를 PG 연동에 붙이면서 "기본 설정만 하면 될 줄 알았던" 두 가지 함정을 발견했다.① slowCallDurationThreshold 실험에서 PG 응답이 TimeLimiter(600ms)를 초과하는 순간 slow call이 아닌 failure로 집계되어 실험 전제 자체가 무너졌다.② retry가 활성화된 상태에서 CB 슬라이딩 윈도우는 결제 요청이 아닌 PG 호출 단위로 채워지기 때문에, 예상보다 빠르게 CB가 열렸다. 두 현상 모두 k6로 직접 측정해 수치로 확인했다.본문Context (배경 및 목표)어떤 시스템을 만드는가: PG(Payment Gateway) 외부 연동. pg-simulator는 40% 확률로 즉시 에러를 반환하고, 60%는 .. 거짓말 안 하는 챗봇 만들기 "AI가 지어내면 어쩌지"에서 시작한 사내 RAG 챗봇사내 문서를 근거로 가벼운 질의응답을 해주는 챗봇을 만들고 있다. 아직 개발이 끝난 건 아니지만, 지금까지 시스템을 세우며 고민한 결정들을 정리해 둔다.이 글은 기능 설명이 아니다. "왜 굳이 이 방식을 골랐나"에 초점을 맞췄다. 챗봇을 만들다 보면 선택지가 계속 갈라지는데, 그 갈림길마다 무엇을 버리고 무엇을 택했는지가 결국 시스템의 성격을 결정하더라.전체 흐름은 단순하다.문서 업로드 → 문서 분할/저장 → 사용자 질문 → 저장된 문서와 유사도 측정 후 답변이 흐름의 바탕에는 RAG(검색 증강 생성)가 있다. 사용자가 올린 문서 안에서만 근거를 찾아 답하는 방식이다. AI가 제멋대로 사실을 지어내는 걸 구조적으로 막고, 주어진 데이터 안에서만 답하게.. 테스트가 의도한 코드를 실제로 검증하고 있는가 TL; DR 1. Windows Docker Desktop app은 포트와 소켓을 열어주도록 설정해야 테스트가 가능하다. 2. 의도한 대로 테스트가 잘 진행되는가 더블 체크가 필요하다. -- TDD 진행을 하면 테스트 환경을 세팅하는 것 자체가 걸림돌이 되는 경우가 있다.특히 통합 테스트에서 실제 DB를 사용하려고 Testcontainers를 도입하면Windows 환경에서 예상치 못한 문제를 만나기도 하고,테스트가 초록불로 통과했는데 정작 검증하려던 코드가 한 번도실행되지 않았다는 걸 나중에 깨닫기도 한다. 본문에서는 그 두 가지 상황을 소개한다.Windows에서 Testcontainers가 Docker를 못 찾는 문제Testcontainers는 테스트 실행 시 Docker 컨테이너를 직접 .. 이전 1 다음