태그
10편
알림 생성과 알림 조회를 한 서버에 두면 무엇이 먼저 마르는지, 좋아요 서비스가 알림 서버를 동기로 부르는 순간 장애가 왜 중요도의 반대 방향으로 흐르는지를 먼저 본다. 그렇게 서버를 쪼갠 대가로 생기는 도메인 코드 두 벌 문제를 한 프로젝트 안의 멀티모듈로 받아 내고, 의존 방향과 Gradle 선언 키워드가 그 경계를 실제로 강제하는 자리까지 내려간다. 마지막은 여기서 멈출 것인가 MSA로 갈 것인가의 기준이다.
요청이 컨트롤러에서 테이블까지 내려가는 계층을 세우고 그 위에 로그인 상태를 붙이는 구간을 다룬다. 상태를 서버에 두는 방식과 토큰에 담아 보내는 방식이 각각 무엇을 얻고 무엇을 포기하는지, 그리고 접근 토큰과 갱신 토큰으로 나누는 회전 정책이 그 저울을 어떻게 매듭짓는지가 이 편의 주제다.
「배치로 돌립시다」는 느리게 해도 된다는 허가가 아니라 지연을 내주고 처리량을 사는 거래다. 이 글은 이커머스 거래 체인의 어디에 배치가 붙는지, 그 결정이 어떤 청구서를 되돌려 주는지, Spring Batch가 그 지형에서 책임지는 범위가 어디까지인지를 정한다.
「실시간으로 만들어 달라」는 요구는 기술의 이름이 아니라 증상의 이름이다. 이 글은 서버가 먼저 말을 걸어야 하는 문제를 다섯 가지 전송 방식으로 갈라 언제 무엇을 고르는지 정하고, WebSocket을 골랐을 때 실제로 무엇이 오가는지를 핸드셰이크·프레임·하트비트 세 층에서 본다.
병렬화는 튜닝 축 다섯 개 중 하나의, 그 안에서도 한 칸이다. 그마저도 병목이 어디인지 확정한 뒤에야 의미를 갖는다. 이 글은 측정 설비를 세우는 데서 시작해 Multi-threaded Step·Parallel Step·Partitioning 셋이 각각 무엇을 쪼개고 무엇을 깨뜨리는지, 그리고 여기서 말하는 파티셔닝이 왜 저장 구조를 바꾸는 파티셔닝과 다른 결정인지를 정한다.
Spring Batch를 쓴다는 것은 재시작 가능한 배치를 직접 설계하지 않겠다는 결정이다. 3계층 아키텍처가 무엇을 어디에 두었는지, JobRepository에 남는 기록이 어떻게 재시작이라는 성질로 이어지는지, 그리고 그 재시작이 안전하려면 배치 쪽이 무엇을 지켜야 하는지를 정한다.
전사 통합 인증을 만들기 전에 정해야 하는 것들을 다룬다. 인증과 인가를 왜 끝까지 따로 써야 하는지, 하나의 로그인을 여럿이 인정하게 만드는 방식들이 각각 무엇을 전제하는지, 그리고 그 결정이 범위 기술서·이벤트 목록·유스케이스·액티비티 다이어그램을 거쳐 다음 단계가 받아 쓸 수 있는 형태로 굳는 과정을 따라간다.
배치 Step의 세 인터페이스 중 둘은 한 건을 받고 하나는 묶음을 받는다. 이 비대칭이 트랜잭션 커밋 간격을 정하고, 그 간격이 Cursor냐 Paging이냐를 정하며, JPA를 얹는 순간 같은 계산이 전부 다시 돌아간다.
앞의 네 편이 쌓아 온 판단을 세 벌로 다시 짠다. 아직 무엇으로 읽고 어떻게 벌릴지 고르는 중이라면 선택지 표를, 이미 도는 배치가 윈도우를 넘기거나 숫자가 안 맞는다면 증상에서 출발하는 실패 모드 표를, 그 선택의 근거를 대야 한다면 25문답을 쓴다.
생 WebSocket은 바이트를 옮길 뿐 목적지를 모른다. 이 글은 그 공백을 STOMP가 어떤 규약으로 메우는지, Spring이 그것을 세 층위로 어떻게 감싸는지, 그리고 destination 접두사를 잘못 나누면 인가 검사가 통째로 우회되는 이유를 다룬다.