반응형

전체 글 163

Temporal과 DB 트랜잭션 — 워크플로우 상태와 정합성 맞추기

목차두 개의 진실 원천이 생긴다이중 쓰기가 발생하는 세 자리워크플로우 시작과 커밋의 순서액티비티 안의 트랜잭션 경계조회 모델과 최종 일관성맺음말두 개의 진실 원천이 생긴다Temporal을 도입하면 시스템에 상태 저장소가 하나 늘어납니다. 서비스의 DB에는 주문이 있고, Temporal의 히스토리에는 그 주문을 처리하는 워크플로우가 있습니다. 둘은 서로를 모르고, 같은 트랜잭션으로 묶이지도 않습니다.이 사실을 인정하고 설계를 시작하는 것이 중요합니다. "워크플로우 시작과 주문 저장을 원자적으로 처리하고 싶다"는 요구는 분산 트랜잭션 요구와 같은 모양이고, 같은 방식으로만 풀립니다.무엇이 어디에 있나정보사는 곳조회 방법주문 내용·금액서비스 DBSQL처리가 몇 단계까지 갔나Temporal 히스토리워크플로우 조..

Loki와 Promtail로 Kubernetes 로그 집계 파이프라인 구축하기

대 금지 || 사용자 ID | user_id="12345" | 매우 높음 | ❌ 절대 금지 |권장 전략은 namespace, app, env, level 정도로 레이블을 최소화하고, Pod 이름이나 요청 ID 같은 고변동 값은 레이블이 아닌 로그 본문에 포함시키는 것입니다. 로그 본문은 인덱싱되지 않으므로 카디널리티 문제가 발생하지 않습니다. 검색 시에는 레이블로 스트림을 좁힌 뒤 |= "trace_id=abc-def" 처럼 텍스트 필터로 찾으면 됩니다.파이프라인 스테이지와 로그 파싱Promtail의 파이프라인은 수집된 로그를 Loki에 전송하기 전에 변환, 파싱, 필터링하는 처리 단계입니다. JSON 형식의 구조화된 로그를 처리할 때는 json 스테이지로 필드를 추출하고 레이블로 승격시킬 수 있으며, ..

Temporal Spring Boot 연동 — 워커 구성과 의존성 주입 기준

목차스타터가 해 주는 일과 해 주지 않는 일설정과 워커 구성의존성 주입이 갈리는 지점테스트 구성배포와 종료에서 걸리는 것들맺음말스타터가 해 주는 일과 해 주지 않는 일Temporal Java SDK만으로도 Spring Boot 애플리케이션에 워커를 띄울 수 있습니다. WorkflowServiceStubs, WorkflowClient, WorkerFactory를 직접 만들어 @Bean으로 등록하면 됩니다. 그런데도 스타터를 쓰는 이유는 연결·워커·등록·종료의 수명 주기를 스프링 컨텍스트에 맞춰 주기 때문입니다.주의할 점 하나를 먼저 짚습니다. Spring Boot 스타터는 워크플로우 구현 클래스에 스프링 빈을 주입해 주지 않습니다. 이것은 스타터의 한계가 아니라 Temporal의 실행 모델에서 나오는 성질..

Bounded Context와 Context Map으로 마이크로서비스 경계 설계하기

목차개요Bounded Context의 개념과 내부 구조Context Map으로 서비스 관계 설계하기마이크로서비스 경계 도출 과정구현 예제: 주문 시스템의 Bounded Context 분리운영 환경 적용 시 고려사항맺음말개요문제 배경마이크로서비스 아키텍처를 설계할 때 가장 어려운 질문은 "서비스를 어떻게 나눌 것인가?"입니다. 기능 단위로 나눌 것인지, 팀 단위로 나눌 것인지, 데이터베이스 테이블 단위로 나눌 것인지—기준이 불분명하면 잘못된 경계로 인해 서비스 간 결합도가 높아지고, 결국 분산 모놀리스(Distributed Monolith)라는 최악의 결과를 낳습니다. Domain-Driven Design(DDD)의 Bounded Context와 Context Map은 이 질문에 구조적인 답을 제시합니다...

카테고리 없음 2026.09.21

CORS 쉽게 이해하기 — 심부름꾼이 물건을 받고도 주지 않는 이유

목차화면은 떴는데 안이 비어 있습니다화면 하나는 여러 집에서 물건을 받아 옵니다명단에 없으면 심부름꾼이 물건을 건네지 않습니다그래서 고칠 수 있는 자리는 정해져 있습니다맺음말화면은 떴는데 안이 비어 있습니다화면은 멀쩡히 떴습니다. 메뉴도 보이고 로고도 제자리에 있습니다. 그런데 정작 봐야 할 목록 자리만 텅 비어 있거나, 빙글빙글 도는 표시가 멈추지 않습니다. 담당자에게 물으면 "코스 오류라서 그렇다"는 답이 돌아옵니다.이 말은 대개 이렇게 들립니다. 어딘가 고장이 났고, 알아들을 수 없는 이름이 붙어 있다는 뜻으로요. 하지만 이것은 고장 난 부품의 이름이 아니라 다른 집끼리 물건을 주고받을 때 지키는 규칙(CORS, 교차 출처 자원 공유)의 이름이고, 비어 있는 화면은 대개 그 규칙이 제대로 지켜진 결..

캐시 쉽게 이해하기 — 책상 위 물건으로 알아보는 빠름과 낡음

목차왜 나만 옛날 화면이 보일까요빠른 이유는 가까이 두었기 때문입니다가까이 둔 것은 낡습니다"캐시를 지워보세요"가 하는 일맺음말왜 나만 옛날 화면이 보일까요공지가 올라왔다는 말을 듣고 화면을 봤는데 아무것도 없습니다. 옆자리 사람 화면에는 이미 떠 있습니다. 새로고침을 눌러 봅니다. 그제야 공지가 나타납니다. 방금 전까지 제 화면만 어제에 머물러 있던 셈입니다.이럴 때 고객센터에서 자주 듣는 말이 있습니다. "캐시를 지워보세요." 시키는 대로 하면 대개 해결되지만, 왜 그런 일이 생겼는지는 알려 주지 않습니다. 이 글은 그 말이 무슨 뜻인지를 책상 하나로 설명합니다. 다 읽고 나면 그 안내가 왜 효과가 있는지, 왜 애초에 그런 일이 생기는지까지 이해하실 수 있습니다.고장이 아닙니다. 두 화면이 서로 다른..

API 스타일 선택 가이드 — 8가지를 가르는 네 가지 질문

목차여덟 가지를 한 장에 놓기네 가지 질문으로 좁히기요청-응답 계열 — REST · GraphQL · gRPC · SOAP서버 주도 계열 — SSE · WebSocket · Long Polling · Webhooks함께 쓰는 구성과 이행 경로맺음말여덟 가지를 한 장에 놓기API 스타일을 고르는 자리에서 가장 자주 나오는 말은 "요즘은 뭘 쓰나요"입니다. 그런데 여덟 가지를 나란히 놓고 보면, 이들은 같은 문제의 경쟁자가 아니라 서로 다른 질문에 대한 답입니다.앞선 여덟 편에서 각각을 따로 다뤘습니다. 이 글은 그 결론만 모아 선택 앞에서 무엇을 물어야 하는지로 정리합니다.첫 갈림길은 성능도 유행도 아니고 "누가 먼저 말을 거는가"입니다. WebSocket만 양쪽에 걸쳐 있습니다.이 갈림길을 축으로 여덟 ..

Temporal Retry 정책 설계 — 백오프와 비재시도 오류 구분

목차재시도를 플랫폼에 맡긴다는 것RetryOptions 다섯 가지 값재시도하면 안 되는 오류 구분하기계층별로 재시도가 걸리는 자리재시도가 만드는 부작용맺음말재시도를 플랫폼에 맡긴다는 것분산 호출에 재시도를 붙이는 일은 어렵지 않습니다. 어려운 것은 재시도 상태를 프로세스 재시작 너머까지 들고 가는 일입니다. 애플리케이션 안의 재시도 루프는 프로세스가 죽는 순간 함께 사라지고, 그 요청이 몇 번째 시도였는지도 같이 사라집니다.Temporal에서 재시도는 코드가 아니라 선언한 정책입니다. 몇 번째 시도인지, 다음 시도가 언제인지는 서버가 기록하고, 워커가 전부 죽었다가 30분 뒤에 떠도 재시도는 이어집니다.직접 짠 재시도 코드가 안고 있는 것직접 구현감춰진 문제for 루프 + Thread.sleep대기 동안..

Long Polling 판단 기준 — 폴백으로 쓸 때의 조건과 비용

목차롱 폴링이 서 있는 자리요청 하나가 오래 머무는 구조유실 없는 이어받기자원과 한도언제 롱 폴링이 합리적인가맺음말롱 폴링이 서 있는 자리롱 폴링(long polling)은 클라이언트가 요청을 보내면 서버가 알려 줄 것이 생길 때까지 응답을 미루는 방식입니다. 응답을 받으면 클라이언트는 곧바로 다음 요청을 보냅니다.여덟 가지 방식 중 가장 오래됐고 가장 자주 "구식"으로 불립니다. 그런데도 아직 쓰이는 이유는 필요한 것이 평범한 HTTP 요청 하나뿐이기 때문입니다.항목짧은 폴링롱 폴링SSEWebSocket요청 형태주기적 요청보류되는 요청끝나지 않는 응답업그레이드 후 프레임빈 응답대부분이 빈 응답없거나 드묾없음없음지연최대 폴링 주기만큼거의 없음거의 없음가장 작음중간 계층 호환가장 좋음좋음버퍼링 설정 필요업..

Temporal Saga 구현 — 보상 트랜잭션을 코드로 다루는 법

목차분산 트랜잭션과 보상의 자리Temporal에서 Saga가 단순해지는 이유Saga 클래스로 구현하기보상 설계에서 어긋나는 지점오케스트레이션 방식의 한계맺음말분산 트랜잭션과 보상의 자리주문 하나가 결제·재고·배송 세 서비스를 건드리고 각 서비스가 자기 DB를 갖고 있다면, 하나의 트랜잭션으로 묶을 방법이 없습니다. 두 번째 단계에서 실패했을 때 첫 단계를 되돌리는 일을 애플리케이션이 직접 해야 하고, 이 되돌림의 집합을 Saga라고 부릅니다.Saga 패턴 자체의 개념과 설계 기준은 앞서 한 편으로 정리한 적이 있으니, 패턴을 처음 보신다면 그쪽을 먼저 읽는 편이 순서가 맞습니다.2026.03.11 - [프로그래밍 PROGRAMMING/아키텍쳐] - 분산 트랜잭션을 안전하게 처리하는 Saga 패턴 설계 가..

반응형