Monitoring
Actuator와 Micrometer (2) - Micrometer로 메트릭 수집하고 Prometheus로 내보내기
1. 개요 1편에서는 Actuator의 health 로 "서버가 살아 있는가"를 확인했다. 하지만 운영에서는 "좌석 조회 API가 요즘 느려지지 않았나?", "오늘 예매가 몇 건 성공했나?"처럼 숫자로 답해야 하는 질문 도 많다. 이런 숫자를 메트릭 (metric)이라…
CATEGORY
Backend
13개의 글
Monitoring
Actuator와 Micrometer (1) - Actuator로 애플리케이션 상태 확인하기
1. 개요 공연 예매 서비스를 운영하다 보면 "서버가 지금 살아 있나?", "DB 연결은 괜찮나?", "좌석 조회 API가 요즘 느려지지 않았나?" 같은 질문에 답해야 한다. 로그만으로는 이런 질문에 빠르게 답하기 어렵다. Spring Boot는 이 문제를 두 도구로…
Logging
MDC와 OncePerRequestFilter로 요청마다 로그 ID 붙이기
1. 개요 공연 예매 서비스에서 여러 사용자가 같은 좌석을 동시에 예매하면, 서버 로그에는 여러 요청의 로그가 한데 섞여 찍힌다. 이때 "이 로그 한 줄이 어느 요청에서 나왔는가"를 알 수 없으면 동시성 문제를 추적하기 어렵다. 이 글에서는 요청마다 짧은 식별자(요청…
Test
AssertJ assertThat과 assertThatThrownBy로 테스트 검증하기
1. 개요 테스트는 "코드를 실행한 결과가 기대와 같은가"를 확인하는 작업이다. 이 확인 단계를 검증(assertion) 이라고 부르고, 검증이 틀리면 테스트가 실패한다. Java 테스트에서는 JUnit의 assertEquals 대신 AssertJ 의 assertTha…
Backend
ddl-auto: update에서 Flyway로 옮기기
1. 개요 Spring Boot 프로젝트를 처음 만들면 JPA의 ddl auto: update 로 테이블을 만드는 경우가 많다. 엔티티만 고치면 개발용 DB 구조가 따라오므로 시작하기 편하다. 하지만 프로젝트가 커지고 개발·테스트·운영 DB가 나뉘면, 같은 코드라도 D…
Backend
MockMvcTester로 좌석 조회 API 통합 테스트하기
1. 개요 GET /schedules/{scheduleId}/seats 는 컨트롤러만 정상이라고 해서 충분하지 않다. 요청 경로가 컨트롤러에 연결되고, 서비스가 회차와 좌석을 조회하고, JPA가 DB에서 데이터를 읽고, 마지막으로 JSON 응답까지 만들어져야 한다. 이…
Backend
도메인 예외를 ProblemDetail HTTP 응답으로 변환하기
1. 개요 공연 예매 API의 GET /schedules/{scheduleId}/seats 는 회차의 좌석 목록을 돌려준다. 그런데 없는 회차 ID로 요청하면 어떻게 응답해야 할까? 처음 구현에서는 서비스가 IllegalArgumentException 을 던졌고, 이를…
Backend
JpaRepository 에 대한 간단한 이해
1. 개요 공연 예매 서비스에서 Performance 는 공연 제목과 공연장 정보를 가진 엔티티다. 이 엔티티를 데이터베이스에 저장하거나 ID로 다시 찾으려면 SQL을 직접 작성할 수도 있지만, Spring Data JPA의 JpaRepository 를 사용하면 기본적…
Backend
@Embedded와 @Embeddable로 값 객체 매핑하기
1. 개요 공연 좌석의 위치는 A구역 3열 12번 처럼 구역, 열, 번호가 함께 의미를 만든다. 이 값을 Seat 엔티티에 각각의 필드로 두면 간단해 보이지만, 위치에 관한 검증과 화면 표시 규칙이 엔티티에 섞이기 쉽다. JPA의 @Embeddable 과 @Embedd…
Backend
Redis 분산 락의 한계와 강한 정합성
1. 락을 얻었다고 항상 안전한 것은 아니다 결제 승인, 리더 선출, 되돌릴 수 없는 외부 명령처럼 두 번 실행되는 비용이 매우 큰 작업 은 "락을 얻었으니 안전하다"고 가정하면 안 된다. 이 글에서는 Redis 락이 실패할 수 있는 지점과, 오래된 작업자를 막는 펜싱…
Backend
Redis 분산 락 기초와 Redisson 적용
1. 여러 서버에서는 JVM 락만으로 부족하다 쿠폰 발급, 선착순 구매, 재고 차감처럼 같은 자원을 동시에 변경하는 요청은 한 번만 처리되어야 할 때가 있다. 예를 들어 남은 수량이 1개인 쿠폰을 두 요청이 동시에 발급하면, 두 요청 모두 "아직 남아 있다"고 판단할…
Backend
Redis와 Memcached, 캐시 서버 선택하기
1. 캐시는 원본 저장소 앞에 두는 빠른 복사본이다 상품 상세, 인기 게시글, 사용자 프로필처럼 자주 읽히지만 매번 바뀌지는 않는 데이터를 요청마다 데이터베이스에서 조회하면, 데이터베이스 연결과 디스크 I/O에 요청이 집중된다. 캐시(Cache) 는 자주 쓰는 데이터를…
Backend
낙관적 락과 비관적 락
1. 동시에 같은 데이터를 수정하면 문제가 생긴다 여러 요청이 같은 데이터를 동시에 읽고 수정하면 한 요청의 변경 내용이 사라질 수 있다. 예를 들어 재고가 10개일 때 두 사용자가 동시에 1개씩 주문한다고 생각해 보자. 두 번의 주문이 처리됐지만 최종 재고는 8이 아…