oguri's garage

개요게시글 조회나 목록 조회처럼 로직은 단순하지만 많은 사용자가 반복적으로 호출하는 API는 데이터베이스에 큰 부하를 준다. 이런 상황에서 캐싱을 적용하면 응답 속도를 극적으로 개선할 수 있다. 실제로 146ms에서 8ms로, 842ms에서 6ms로 개선된 사례들이 있다.이번 글에서는 최고의 속도와 확장성을 동시에 확보하기 위한 2-Level 캐싱 전략에 대해 정리한다.2-Level 캐싱이란?2-Level 캐싱은 로컬 캐시(L1)와 분산 캐시(L2)를 조합하는 전략이다. 마치 학생의 책상과 도서관의 관계와 같다.L1 캐시 (책상): 가장 자주 보는 자료를 손만 뻗으면 바로 집을 수 있도록 준비해 두는 곳 (초고속 접근)L2 캐시 (도서관): 책상에 없는 자료를 찾으러 가는 곳. 조금 느리지만 모든 학생이..

개요프로젝트 초기에 데이터 접근 기술을 선택할 때마다 고민이 된다. JPA를 쓸지, MyBatis를 쓸지, 아니면 둘 다 쓸지. 간단한 CRUD는 JPA가 편하지만, 복잡한 통계 쿼리는 MyBatis가 낫다는 얘기를 들었다. 직접 사용해보면서 각각의 장단점과 선택 기준을 정리했다.핵심 차이JPA는 ORM(Object-Relational Mapping), MyBatis는 SQL Mapper다.JPA: 객체와 테이블을 자동으로 매핑, SQL 자동 생성MyBatis: SQL을 직접 작성, 결과를 객체에 매핑JPA: 객체 → SQL 자동 생성 → DBMyBatis: SQL 직접 작성 → 결과를 객체로 매핑 Spring Data JPAEntity와 Repository// Entity 정의@Entity@Tab..

개요Spring MVC 개발 중 Interceptor가 특정 API에서만 작동하지 않거나, 예외 처리가 예상과 다르게 동작하는 경우를 겪었다. 이런 문제를 해결하려면 요청이 어떤 순서로 처리되는지 이해해야 한다. 핵심 흐름Spring MVC의 요청 처리 순서:요청 → DispatcherServlet → HandlerMapping → HandlerAdapter → Interceptor → Controller → ViewResolver → View → 응답 DispatcherServlet이 모든 요청의 진입점이다. Front Controller 패턴으로 하나의 서블릿이 모든 요청을 받아서 적절한 Controller로 분배한다. DispatcherServletDispatcherServlet은 ..

예외 처리의 중복 코드 문제Spring으로 개발하면서 가장 귀찮았던 작업 중 하나가 예외 처리였다.처음엔 각 Controller마다 try-catch로 예외를 잡거나, @ExceptionHandler를 만들었다.그런데 Controller가 늘어나면서 똑같은 예외 처리 코드를 계속 복사-붙여넣기하는 내 모습을 발견했다.// UserController@RestController@RequestMapping("/api/users")public class UserController { @ExceptionHandler(UserNotFoundException.class) public ResponseEntity handleUserNotFound(UserNotFoundException ex) { ..

세 가지를 혼동했던 경험Spring으로 개발하면서 가장 헷갈렸던 게 Filter, Interceptor, AOP의 차이였다. 셋 다 "요청을 가로채서 뭔가 처리한다"는 점에서 비슷해 보였다. 인증 로직을 어디에 넣어야 할지, 로깅은 어디서 해야 할지 매번 고민했다.그러다 운영 중에 문제가 생겼다. Interceptor에서 처리하려던 인증이 Filter에서 막혀버렸고, AOP로 구현한 로깅이 Controller에 도달하기 전 에러에서는 작동하지 않았다. 이때 실행 순서와 각각의 동작 레벨을 제대로 이해해야겠다는 생각이 들었다.핵심 차이점Filter는 서블릿 레벨, Interceptor는 Spring MVC 레벨, AOP는 메서드 레벨에서 동작한다.실행 순서:요청 → Filter → DispatcherSer..

개요Spring Boot를 처음 사용할 때 가장 신기했던 게 "어떻게 설정 파일 하나 없이 바로 실행되지?"였다.spring-boot-starter-data-jpa만 추가하면 DataSource, EntityManager, TransactionManager가 알아서 생성됐다. 하지만 막상 커스터마이징하려니 어디서부터 손대야 할지 막막했다.그러다 운영 중에 이상한 문제를 겪었다. 분명 내가 설정한 DataSource를 사용해야 하는데 자동 설정의 DataSource가 먼저 생성되는 것 같았다. 디버깅하다 보니 Auto Configuration의 동작 원리를 제대로 이해해야겠다는 생각이 들었다. 핵심 동작 원리@EnableAutoConfiguration → spring.factories 로드 → 조건 평..

우선순위 핵심 개념커맨드라인 > 환경변수 > 프로파일 설정 > 기본 설정 순서다.같은 키가 여러 곳에 있으면 우선순위 높은 쪽이 이긴다.1. 커맨드라인: java -jar app.jar --server.port=90902. 환경변수: export SERVER_PORT=90903. jar 외부 설정: ./config/application-prod.properties4. jar 내부 설정: application-prod.properties5. jar 내부 기본: application.properties환경변수 명명 규칙환경변수는 특별한 규칙으로 매핑된다:server.port → SERVER_PORTspring.datasource.url → SPRING_DATASOURCE_URLa..

문제 상황점수 집계 기능을 개발하던 중, 흥미로운 질문이 생겼다.하나의 문서에 여러 엔티티가 연관되어 있을 때, 검색 결과에서 이 문서가 몇 번 카운트될까?예를 들어, 2개의 엔티티가 모두 검색 조건에 해당하는 문서가 있다면, 이 문서는 1번 카운트될까 2번 카운트될까? OpenSearch의 nested 쿼리 동작 원리결론부터 말하면, 1번만 카운트된다.OpenSearch는 문서(document) 단위로 검색하기 때문이다.nested 쿼리의 동작 방식을 이해하기 위해 간단한 예시를 살펴보자.예시 데이터{ "_id": "doc123", "items": [ {"name": "항목A"}, {"name": "항목B"} ], "date": "2025-05-15"}검색 쿼리 구조{ "bool..