N+1은 언제 의심하고, 무엇부터 고치나
글로벌 EAGER/LAZY로는 못 막는다. fetch join·@EntityGraph·배치 페치를 쿼리 단위로 고른다
JPA N+1 쿼리 성능 개선성능 사례
castle.log
기술 글
서비스 운영 중 마주친 배포, 장애 대응, 성능, 캐시, 테스트 이야기를 정리했습니다.
글로벌 EAGER/LAZY로는 못 막는다. fetch join·@EntityGraph·배치 페치를 쿼리 단위로 고른다
좋은 파이프라인은 배포를 빠르게 하는 게 아니라 되돌아갈 기준을 남긴다
타임아웃·벌크헤드·서킷브레이커가 기본 축. 장애 주입으로 실제 동작을 확인한다
계층별로 무엇을 캐시하는지 분리. 안 그러면 API와 화면이 따로 논다
테스트가 많은 코드가 아니라, 변경했을 때 어디를 볼지 분명한 코드
서버 상태와 클라이언트 상태를 분리하는 게 핵심
전체 글
화면·API·데이터·배포를 하나의 흐름으로 본다
변경 후 클릭 흐름과 배포 안정성을 반복 가능한 절차로 검증한다
좋은 파이프라인은 배포를 빠르게 하는 게 아니라 되돌아갈 기준을 남긴다
횡단 관심사를 한곳에 모으되, 책임을 몰면 단일 장애점이 된다
막는 주체는 브라우저다. 서버는 허용 범위를 명시할 뿐
binlog → Relay Log → SQL 스레드. 복제 지연을 전제로 읽기를 배치한다
글로벌 EAGER/LAZY로는 못 막는다. fetch join·@EntityGraph·배치 페치를 쿼리 단위로 고른다
정렬된 탐색 구조. 컬럼 순서와 카디널리티가 사용 여부를 가른다
프록시가 경계를 만든다. 같은 클래스 내부 호출엔 안 걸린다
타임아웃·벌크헤드·서킷브레이커가 기본 축. 장애 주입으로 실제 동작을 확인한다