전체 글

PDF 리포트 다운로드를 약 13초에서 1.6초로 줄였다. 병목은 쿼리가 아니라 암호화 문서의 복호화가 반복되는 구조와, 요청하지 않은 산출물까지 렌더링하는 경로에 있었다.혈압 모니터링 시스템에서 느린 다운로드는 사용자 경험 저하와 커넥션 풀 경고로 이어지고 있었다. 렌더링 구조를 정리하고, 복호화 경로의 호출당 비용과 대상 필드 수를 줄였으며, 동시 생성 상한으로 피크 부하를 제어했다. 출력 데이터와 300 DPI 렌더 품질은 검증 범위에 포함했다.스택은 Java 17, Spring Data MongoDB(AWS DocumentDB), Apache PDFBox, JCA Cipher, java.util.concurrent다. 모든 수치는 측정 환경에서 얻은 값이며, 구간별 비교 조건은 5절에 함께 적었다..

생체데이터 수집 서버에서는 HTTP 요청에서 원본 데이터를 S3에 저장한 뒤, 혈압 추정 작업을 @Async로 처리하고 있었다.현재 운영 트래픽에서는 문제가 없었다. 다만 혈압 추정 과정에서 외부 AI API를 여러 차례 호출하기 때문에 한 가지 의문이 있었다.요청 유입 속도가 AI 서버의 처리 속도를 넘어가면 이 구조는 어디에서 먼저 실패할까?RabbitMQ를 먼저 도입하기보다 기존 구조의 실패 조건을 재현하고, 실제 한계가 무엇인지 확인하는 것부터 시작했다.1. k6로 기존 구조의 포화 지점을 재현했다부하 테스트는 요청 처리시간이 길어지더라도 k6의 VU 부족 때문에 목표 RPS가 떨어지지 않도록 ramping-arrival-rate 방식으로 구성했다.실제 테스트 스크립트는 RPS를 환경변수로 조절하..

ALB/uvicorn 간 connection 정책 불일치를 로그 분석으로 발견,인프라 설정 정렬 + retry 전략으로 데이터 누락 완전 제거1. 문제 정의시스템 개요IoT 디바이스가 일정 주기로 센서 데이터를 수집하고, 서버가 이를 받아 외부 추정 API를 호출해 분석 결과를 산출하는 구조다. 이 추정 결과가 모여 최종 리포트가 된다.[디바이스] → [앱] → [Spring 서버] → [외부 추정 API (Python/uvicorn)] ↑ ALB를 통해 접근이 외부 API 호출에서 간헐적으로 502 Bad Gateway가 발생하고 있었다. 전체 API 호출 대비 실패율..

한눈에 보기문제같은 환자의 같은 측정 데이터를 사용했지만 PDF 리포트와 클립보드 복사 결과에서 일부 혈압 수치가 다르게 나타났다.문제 재정의처음에는 700줄짜리 레거시 메서드가 문제라고 생각했다. 그러나 실제 문제는 코드의 길이가 아니라, 출력 채널마다 서로 다른 조회·계산 경로를 가지고 있어 시스템 안에 계산 기준이 여러 개 존재한다는 점이었다.해결최근 발급된 리포트 450건을 Fixture로 만들고, 기존 코드의 실제 출력을 Golden Master로 저장했다. 계산 결과를 7개 검증 축으로 나눈 뒤 리팩토링의 각 단계마다 기존 결과와 비교했다.계산과 표현을 분리하고 모든 출력 채널이 하나의 분석 결과를 공유하도록 구조를 변경했다.결과슬롯별 혈압, 요약 통계, Dipping, 수면 시간, 측정 횟수..

이 글은 24시간 혈압 모니터링 서비스에서 생체 신호 수집 완료를 판단하고 리포트를 생성하는 과정을 개선한 경험을 다룬다. 환자가 측정을 시작하면 하드웨어는 일정 시간 동안 생체 신호를 수집한다. 측정이 끝난 뒤에는 수집한 신호를 한 번에 보내지 않고 여러 API 요청으로 나누어 서버에 전송한다.서버는 각 요청의 신호를 저장하면서 건별 1차 혈압값을 산출한다. 모든 신호 처리가 끝나면 수집된 결과를 외부 분석 서버로 보내 최종 혈압값을 계산하고, 그 결과를 바탕으로 리포트를 생성한다.초기 구조에서는 마지막 데이터 요청을 받은 서버가 이전 요청들의 처리가 모두 끝날 때까지 Redis의 처리 건수를 polling했다. 마지막 전송 API가 성공한 직후 앱에서 리포트를 조회할 수 있어야 했기 때문이다.if (..

Hibernate 개발자 분과 소통하며 Jira에 관련 이슈를 등록한 기점으로 오픈소스에 관심이 생겼고,오픈 소스를 보는 것 자체가 너무 즐거워서 자바로 작성된 오픈소스들을 찾아봤다. 그 중, 우연히도 JabRef라는 논문 관리 오픈소스를 알게 됐다.(사실, Hibernate, Spring, elasticSearch 심지어 Kafka까지 모두 찾아봤었지만, 워낙 대중이고 많은 사람들이 사용하는 만큼 내가 직접 버그를 발견하거나 올라온 이슈를 해결하기에 버거움을 느꼈다.) https://github.com/JabRef JabRef e.V.JabRef e.V. has 46 repositories available. Follow their code on GitHub.github.com 그럼 내가 어떻게 오픈소..