쿠다의 공부 블로그

이전 글에서는 병원·약국 CSV 갱신 중 발생한 Java heap space 오류와 active 배치 방식으로 바꾼 과정을 적었습니다. 전체 데이터를 Java 메모리에 올리지 않도록 바꾼 뒤에는 다른 질문이 남았습니다.기존 병원·약국 데이터를 새 CSV로 최신화할 때, 변경 판단과 쓰기를 어디에서 처리하는 편이 적합할까?기준 데이터는 100,676건, 새 2026.6 CSV는 105,448건입니다. AWS에서 JPA, 현행 active 배치, Java 스테이징, DB 스크립트를 비교했습니다. 핵심은 단순한 속도 순위가 아니라, 24시간 조회를 제공하는 애플리케이션의 메모리 부담을 제한하면서 실제 변경분을 정확히 반영하는 방법을 고르는 것이었습니다.📝 갱신 방식은 어떻게 달랐나?JPA: 애플리케이션에서 ..

PlusKM의 주변 의료기관 검색에 맞는 MySQL 공간 쿼리를 비교했습니다. DB 선택 과정은 이전 글에 있습니다.지정 반경 안의 의료기관을 가까운 순서로 보여주려면 어떤 쿼리가 적합할까?필요한 것은 인덱스로 후보를 줄이면서도, 실제 반경 안에 있는 병원을 가까운 순서대로 돌려주는 쿼리였습니다.📝 무엇을 기준으로 평가할까?대상은 SRID 4326 POINT로 저장한 응급실 좌표입니다. 이 글의 반경은 ST_Distance_Sphere의 구면 거리로 정의했습니다. MySQL 문서먼저 병원 ID와 정렬 순서를 확인했습니다. 그다음 100 VU에서 초당 처리 건수를 비교했습니다. 이때 p95는 DB 실행 시간만이 아니라 연결 풀에서 기다린 시간까지 포함합니다.📝 공간 함수 중 무엇을 후보로 남길까?MyS..

저는 개인 프로젝트로 응급실 검색 애플리케이션을 제작했습니다.주변 의료기관을 조회하는 기능에서는 사용자의 위치를 기준으로 가까운 장소를 검색해야 합니다.기존 프로젝트에서는 MySQL을 사용하고 있었지만, 공간 검색이 주요 기능이라면 MySQL을 그대로 사용하는 것이 적절한지 확인해보고 싶었습니다.비교 대상은 세 가지로 정했습니다.MySQLPostgreSQL + PostGISMongoDB단순히 가장 빠른 DB를 찾기보다는 다음 질문에 답하는 것을 목표로 했습니다.약 10만 건의 공간 데이터를 검색하는 현재 서비스에서 DB를 변경할 만큼 의미 있는 차이가 있을까?📝 같은 공간 검색인데 어떻게 다를까?세 DB 모두 공간 인덱스를 제공하지만 검색 방식에는 차이가 있습니다.PostGISPostGIS에서는 GiS..

자취선배의 백엔드 기술 스택을 정하면서 JPA와 Spring Security를 사용하지 않기로 했습니다.둘 다 Spring 기반 프로젝트에서 자주 사용되고, 팀원들도 사용 경험이 있는 기술입니다.그럼에도 익숙한 기술을 먼저 선택하기보다 다음 기준을 세웠습니다.현재 발생한 문제를 먼저 확인하고, 그 문제를 해결하기 위해 기술을 도입한다.이번 글에서는 이 기준으로 JPA와 Spring Security를 사용하지 않은 이유와, 어떤 상황에서 다시 도입을 고려할지 정리합니다.📝 익숙한 기술이라고 반드시 필요할까?프로젝트를 시작하면서 사용할 기술을 정리했습니다.구분선택LanguageJava 21FrameworkSpring Boot 3.5PersistenceSpring JDBC / JdbcTemplateDatab..

이전 글에서는 부하 테스트의 합격 기준과 실행 계획을 정리했습니다.이번 글에서는 실제 테스트를 진행하며 겪은 시행착오와 설정 변경, 그리고 측정 결과를 성능과 비용 기준으로 나눠 해석한 과정을 기록합니다.📝 CloudShell 결과를 신뢰할 수 있을까?처음에는 AWS CloudShell에서 k6를 실행했습니다. 별도의 인스턴스 없이 애플리케이션 서버와 부하 발생기를 분리할 수 있어 간편했습니다. 하지만 부하를 높이자 목표 RPS에 도달하지 못하고 Dropped Iteration이 발생했습니다.관찰 결과판단목표 RPS 미달부하 발생기 성능 확인 필요Dropped Iteration 발생대상 서버의 실패로 단정하기 어려움반복 시험의 결과 편차시험 조건 점검 필요 Dropped Iteration은 계획된 it..

📝 배경개발자라면 자신이 만든 서버가 얼마나 버티는지 알아야 하지 않을까? 팀원들과 논의해 정해진 예산 안에서 인프라를 구성했습니다. 그러던 중 이런 질문을 받았습니다.“현재 프로젝트의 서버는 어느 정도의 트래픽까지 버틸 수 있나요?” 서버가 실행된다는 사실만으로는 답하기 어려웠습니다. 처리 가능한 요청량뿐만 아니라 응답시간과 오류율, 병목이 발생하는 지점도 함께 확인해야 했습니다.막연하게 추측하는 대신 측정값으로 답하기 위해 부하 테스트를 계획했습니다.📝 부하 테스트란 무엇일까요?처음에는 부하 테스트를 단순히 많은 요청을 보내 서버가 죽는지 확인하는 작업이라고 생각했습니다.하지만 서버가 살아 있어도 응답에 몇 초씩 걸리거나 요청 일부가 누락된다면 정상적으로 서비스를 제공했다고 보기 어렵습니다.부하 ..