태그
17편
알림 생성과 알림 조회를 한 서버에 두면 무엇이 먼저 마르는지, 좋아요 서비스가 알림 서버를 동기로 부르는 순간 장애가 왜 중요도의 반대 방향으로 흐르는지를 먼저 본다. 그렇게 서버를 쪼갠 대가로 생기는 도메인 코드 두 벌 문제를 한 프로젝트 안의 멀티모듈로 받아 내고, 의존 방향과 Gradle 선언 키워드가 그 경계를 실제로 강제하는 자리까지 내려간다. 마지막은 여기서 멈출 것인가 MSA로 갈 것인가의 기준이다.
사내 인증 서비스 여섯 편의 마지막이다. 앞의 다섯 편을 세 벌로 다시 엮는다. 고를 때 저울질하는 선택지 다섯, 증상만 보고는 원인을 잘못 짚기 쉬운 실패 모드 여덟, 설명해야 할 때 필요한 문답 스물다섯과 길게 답해야 하는 넷이다.
요청이 컨트롤러에서 테이블까지 내려가는 계층을 세우고 그 위에 로그인 상태를 붙이는 구간을 다룬다. 상태를 서버에 두는 방식과 토큰에 담아 보내는 방식이 각각 무엇을 얻고 무엇을 포기하는지, 그리고 접근 토큰과 갱신 토큰으로 나누는 회전 정책이 그 저울을 어떻게 매듭짓는지가 이 편의 주제다.
요구사항 명세서에서 ERD로 내려오는 구간을 따라간다. 기능 요구 문장 옆에 엔드포인트를 붙여 추적할 수 있는 표로 만들고, 그 표에서 되풀이되는 명사를 엔티티로 꺼내고, 한 사람이 역할을 둘 이상 가진다는 요구 한 줄이 어떻게 열 하나를 테이블 하나로 갈라놓는지를 본다. 떠올려서 그린 저장 구조와 표에서 뽑아낸 저장 구조가 무엇이 다른지가 이 편의 주제다.
실시간 채팅 시리즈가 내린 판단을 세 벌로 다시 짠다. 아직 방식을 고르는 중이라면 선택지 표를, 이미 돌아가는 서비스에서 메시지가 안 오거나 연결이 끊긴다면 증상에서 출발하는 진단 표를, 근거를 설명해야 한다면 25문답을 쓴다.
「배치로 돌립시다」는 느리게 해도 된다는 허가가 아니라 지연을 내주고 처리량을 사는 거래다. 이 글은 이커머스 거래 체인의 어디에 배치가 붙는지, 그 결정이 어떤 청구서를 되돌려 주는지, Spring Batch가 그 지형에서 책임지는 범위가 어디까지인지를 정한다.
「실시간으로 만들어 달라」는 요구는 기술의 이름이 아니라 증상의 이름이다. 이 글은 서버가 먼저 말을 걸어야 하는 문제를 다섯 가지 전송 방식으로 갈라 언제 무엇을 고르는지 정하고, WebSocket을 골랐을 때 실제로 무엇이 오가는지를 핸드셰이크·프레임·하트비트 세 층에서 본다.
병렬화는 튜닝 축 다섯 개 중 하나의, 그 안에서도 한 칸이다. 그마저도 병목이 어디인지 확정한 뒤에야 의미를 갖는다. 이 글은 측정 설비를 세우는 데서 시작해 Multi-threaded Step·Parallel Step·Partitioning 셋이 각각 무엇을 쪼개고 무엇을 깨뜨리는지, 그리고 여기서 말하는 파티셔닝이 왜 저장 구조를 바꾸는 파티셔닝과 다른 결정인지를 정한다.
Spring Batch를 쓴다는 것은 재시작 가능한 배치를 직접 설계하지 않겠다는 결정이다. 3계층 아키텍처가 무엇을 어디에 두었는지, JobRepository에 남는 기록이 어떻게 재시작이라는 성질로 이어지는지, 그리고 그 재시작이 안전하려면 배치 쪽이 무엇을 지켜야 하는지를 정한다.
사내 인증 서비스 여섯 편의 지도다. 로그인이 시스템마다 따로인 상황에서 출발해 범위 기술서 한 장이 API 표가 되고 그 표가 스키마와 파드 개수까지 내려가는 경로를 그린다. 「역할」·「토큰」·「세션」처럼 편마다 다른 층을 가리키는 낱말도 여기서 먼저 갈라 둔다.
배치 Step의 세 인터페이스 중 둘은 한 건을 받고 하나는 묶음을 받는다. 이 비대칭이 트랜잭션 커밋 간격을 정하고, 그 간격이 Cursor냐 Paging이냐를 정하며, JPA를 얹는 순간 같은 계산이 전부 다시 돌아간다.
캐시 무효화 방식 네 가지와 TTL 설계 원칙, Stampede·Penetration·Avalanche 방어, Spring Cache 구현 3계층의 함정, 그리고 원자 카운터와 분산 락으로 동시성을 다루는 법을 정리한다.
브로커를 끼워 넣으면 장애가 거꾸로 번지는 경로는 사라지지만 그 대가로 지연과 중복과 순서 뒤집힘이 청구된다. 토픽과 파티션이 무엇을 정하는지, 컨슈머를 늘려도 처리량이 늘지 않는 구간이 왜 생기는지, 오프셋을 언제 커밋하느냐가 전달 보장을 어떻게 바꾸는지를 차례로 본다. 이어서 순서가 지켜지는 범위와 중복을 견디는 도메인 설계, 끝내 실패하는 한 건을 줄 밖으로 빼내는 장치까지 다룬다.
소셜 로그인은 비밀번호를 우리가 들고 있지 않으면서 사용자를 식별하는 방법이다. 이 글은 Authorization Code를 한 번 더 거치는 이유, Spring Security가 폼 로그인과 대칭으로 그것을 얹는 구조, 그리고 인증이 끝난 뒤 필요한 채팅 도메인 모델과 페이징·알림 설계를 다룬다.
캐시 전략과 자료구조 선택지를 한 표로 모으고, 운영에서 실제로 밟는 실패 모드 여덟 가지와 대응, 그리고 설계·무효화·동시성·운영에 걸친 25개 질문에 결론부터 답한다.
앞의 네 편이 쌓아 온 판단을 세 벌로 다시 짠다. 아직 무엇으로 읽고 어떻게 벌릴지 고르는 중이라면 선택지 표를, 이미 도는 배치가 윈도우를 넘기거나 숫자가 안 맞는다면 증상에서 출발하는 실패 모드 표를, 그 선택의 근거를 대야 한다면 25문답을 쓴다.
생 WebSocket은 바이트를 옮길 뿐 목적지를 모른다. 이 글은 그 공백을 STOMP가 어떤 규약으로 메우는지, Spring이 그것을 세 층위로 어떻게 감싸는지, 그리고 destination 접두사를 잘못 나누면 인가 검사가 통째로 우회되는 이유를 다룬다.