반응형

전체 글 152

SSE 도입 판단 기준 — 단방향 푸시의 최소 비용과 프록시 함정

목차SSE가 맡는 좁은 일형식과 재연결 규약중간 계층이 스트림을 망가뜨리는 자리HTTP 버전과 동시 연결 한도SSE를 고를 조건맺음말SSE가 맡는 좁은 일서버 전송 이벤트(Server-Sent Events, SSE)는 끝나지 않는 HTTP 응답입니다. 클라이언트가 요청을 한 번 보내면, 서버가 그 응답 본문에 이벤트를 계속 이어 씁니다.핵심은 "새 프로토콜이 아니다"라는 점입니다. 요청도 응답도 평범한 HTTP이고, 그래서 얻는 것과 잃는 것이 모두 여기서 나옵니다.항목폴링SSEWebSocket연결요청마다 새로한 번 열고 유지한 번 열고 유지방향요청-응답서버 → 클라이언트만양방향프로토콜HTTPHTTP업그레이드 후 별도 프레임재연결클라이언트가 반복 요청브라우저가 자동 재연결직접 구현유실 복구매 요청이 최신..

Temporal Activity 설계 — 타임아웃·멱등성·하트비트 기준

목차액티비티가 맡는 일과 경계네 가지 타임아웃 고르기최소 한 번 실행과 멱등성하트비트로 긴 작업 다루기로컬 액티비티와 비동기 완료맺음말액티비티가 맡는 일과 경계워크플로우가 "무엇을 어떤 순서로"를 정한다면, 액티비티(Activity)는 실제로 바깥 세계를 건드리는 코드입니다. HTTP 호출, DB 쓰기, 파일 업로드, 메시지 발행이 전부 여기 들어갑니다.액티비티는 평범한 Java 메서드입니다. 결정성 제약도 없고, 스레드를 써도 되고, 현재 시각을 읽어도 됩니다. 대신 재시도와 타임아웃이라는 다른 규칙이 붙습니다. 이 글은 그 규칙을 어떤 기준으로 정하는지 정리합니다.경계를 어디에 긋는가액티비티를 잘게 쪼갤수록 재시도 단위가 정밀해지지만 히스토리 이벤트와 저장소 쓰기가 늘어납니다.나누는 기준예시판단외부 ..

WebSocket 도입 판단 기준 — 연결 상태를 서버가 떠안는 대가

목차WebSocket이 바꾸는 것연결 상태를 서버가 떠안는다는 뜻끊김을 전제로 설계하기자원 한도와 역압WebSocket을 고를 조건맺음말WebSocket이 바꾸는 것WebSocket은 HTTP 요청으로 시작해 같은 TCP 연결을 양방향 통로로 바꾸는 규약입니다. 한 번 열리면 양쪽 모두 언제든 메시지를 보낼 수 있습니다.이 설명만 보면 이득만 있는 것처럼 보입니다. 실제로 달라지는 것은 서버가 무엇을 기억해야 하는가입니다.항목HTTP 요청-응답WebSocket새로 떠안는 것연결 수명요청 단위로 끝남분·시간 단위로 유지연결 수만큼 메모리·파일 디스크립터상태 보관서버가 기억하지 않아도 됨어떤 노드에 누가 붙었는지 기억노드 간 메시지 전달 경로배포요청이 끝나면 교체 가능연결이 살아 있어 남음종료 신호와 재접속..

SOAP은 왜 밀려났나 — 그리고 아직 SOAP이 맞는 자리

목차SOAP이 풀려던 문제봉투와 계약 — Envelope, WSDL, FaultWS-* 확장이 맡던 세 가지아직 SOAP이 남아 있는 자리기존 SOAP 서비스를 다루는 방법맺음말SOAP이 풀려던 문제SOAP은 XML 봉투에 담긴 메시지를 주고받아 원격 호출을 언어·플랫폼과 무관하게 만들려던 규약입니다. 2000년대 초 기업 시스템 연동의 기본값이었습니다.지금은 새 프로젝트에서 고를 일이 거의 없지만, 왜 밀려났는지를 정확히 알아 두면 REST·gRPC를 고를 때의 판단 기준이 함께 정리됩니다. 오늘날 당연하게 여기는 선택 대부분은 SOAP이 비쌌던 지점의 반작용이기 때문입니다.원격 호출을 언어 중립으로 만들려던 시도목표 자체는 gRPC와 같습니다. 계약을 먼저 정의하고 양쪽 언어의 코드를 생성한다는 발상..

gRPC 도입 판단 기준 — 스키마 우선 계약과 사내 통신의 조건

목차gRPC가 옮겨 놓는 결정스키마 우선 계약을 지탱하는 규칙네 가지 호출 방식과 스트리밍의 대가운영에서 드러나는 비용어디까지 gRPC로 둘 것인가맺음말gRPC가 옮겨 놓는 결정gRPC는 .proto 파일에 정의한 서비스와 메시지를 양쪽 언어의 코드로 생성해, HTTP/2 위에서 이진 형식으로 주고받는 호출 방식입니다.빠르다는 점이 먼저 알려져 있지만, 성능은 도입 근거로 삼기에 약한 편입니다. 사내 호출 한 번의 직렬화 비용은 대개 데이터베이스 왕복에 묻힙니다. 실제로 달라지는 것은 계약을 관리하는 방식입니다.REST + JSON에서 있던 것gRPC 도입 후새로 떠안는 것계약이 문서·스키마 파일로 따로 존재계약이 빌드 산출물로 코드에 들어옴proto 저장소와 배포 순서를 관리해야 함필드 이름이 곧 호환..

Temporal Workflow 설계 — 결정성 제약과 상태 다루기

목차워크플로우 코드가 보통 코드와 다른 점결정성 제약 — 쓸 수 없는 것들밖에서 안으로: 신호·조회·업데이트오래 도는 워크플로우 다루기무엇을 워크플로우에 담을 것인가맺음말워크플로우 코드가 보통 코드와 다른 점Temporal 워크플로우는 평범한 Java 클래스처럼 보입니다. if를 쓰고 for를 돌리고 예외를 잡습니다. 그런데 이 코드는 한 번의 실행 동안 여러 번, 처음부터 다시 실행됩니다. 이 사실 하나가 워크플로우 작성 규칙 전부를 결정합니다.이전 편에서 이벤트 히스토리와 재생(replay)이 지속 실행의 뼈대라는 점을 정리했습니다. 이번에는 그 뼈대 위에서 코드를 어떻게 써야 하는지, 그리고 규칙을 어겼을 때 무슨 일이 벌어지는지를 봅니다. 여기서 다루는 제약이 실제 주문 처리 코드에서 어떤 모양으..

GraphQL 도입 판단 기준 — N+1·캐시·쿼리 비용 다루기

목차GraphQL이 옮겨 놓는 문제스키마와 리졸버가 만드는 N+1캐시를 다시 세우는 방법쿼리 비용을 제한하는 기준REST와 나누는 기준맺음말GraphQL이 옮겨 놓는 문제GraphQL은 클라이언트가 필요한 필드만 골라 한 번에 받아 가는 질의 언어입니다. 화면마다 응답을 새로 만들지 않아도 되고, 왕복도 한 번으로 줄어듭니다. 문제는 이 이득이 공짜가 아니라는 점입니다. REST에서 서버가 쥐고 있던 결정 세 가지가 클라이언트 쪽으로 넘어가고, 그 대신 서버가 새로 떠안는 부담이 생깁니다.REST에서 있던 것GraphQL 도입 후새로 떠안는 것화면별 응답을 서버가 확정클라이언트가 필드를 조합조합마다 조회 계획이 달라져 N+1이 쉽게 생김URL 단위 HTTP 캐시대부분 단일 주소에 POST캐시 계층을 새로..

Temporal이란 무엇인가 — 지속 실행 워크플로우 엔진의 구조

목차워크플로우 엔진을 따로 두는 이유Temporal이 보장하는 지속 실행서버 구성 요소와 실행 흐름코드로 보는 최소 구성도입 판단 기준맺음말워크플로우 엔진을 따로 두는 이유결제 승인 → 재고 차감 → 배송 요청 → 알림 발송처럼 여러 서비스를 순서대로 부르는 로직은 어느 서비스에나 있습니다. 문제는 이 순서가 한 번에 끝나지 않는다는 것입니다. 세 번째 호출에서 상대 서비스가 502를 뱉으면, 앞의 두 단계는 이미 벌어진 일이고 네 번째 단계는 아직 시작도 못 했습니다.Temporal은 이 "중간에 멈춘 상태"를 코드가 아니라 플랫폼이 기억하게 만드는 도구입니다. Uber에서 만든 Cadence를 이어받아 만들어진 오픈소스 프로젝트이며, 스스로를 워크플로우 엔진이 아니라 지속 실행(Durable Exec..

Grafana란 무엇인가 — 등장 배경과 Prometheus 대시보드 구성 방법

목차개요Grafana는 어떤 문제를 풀려고 등장했나구성 요소와 대시보드 모델Prometheus에 붙이는 기본 활용법맺음말개요한 줄 정의와 이 글의 범위Grafana(그라파나)는 여러 곳에 흩어진 데이터 소스에 질의를 대신 던지고, 돌아온 결과를 한 화면에 그래프·수치·표로 그려 주는 오픈소스 시각화 도구입니다. 2014년 Torkel Ödegaard가 시작했고, 지금은 Prometheus를 비롯한 시계열 데이터베이스의 화면을 맡는 사실상 기본 선택지로 쓰이고 있습니다.이 글에서 다루는 것다루지 않는 것왜 등장했는지, 데이터 소스의 내장 화면과 무엇이 다른지Loki·Tempo를 포함한 Grafana 자체 스택 구축구성 요소와 대시보드 모델(패널·변수·시간 범위)알림 라우팅·묵음 처리 심화 설정Prometh..

Rust란? Rust 뜻부터 특징·장단점·사용 분야까지 정리

목차개요Rust란 무엇인가 — 뜻과 등장 배경Rust의 핵심 특징: 소유권이 만드는 메모리 안전성Rust 장단점 — 얻는 것과 치르는 비용Rust 사용 분야와 도입 판단 기준맺음말개요Rust를 둘러싼 말과 실제Rust는 리눅스·윈도우 커널에 코드가 들어갔고, Cloudflare와 Discord가 핵심 서비스를 이 언어로 다시 썼습니다. 그런데 "그래서 우리 팀이 써야 하나"라는 질문 앞에서는 답이 잘 나오지 않습니다. 소개 글 대부분이 "빠르고 안전하다"에서 멈추기 때문입니다.빠르고 안전하다는 말은 어느 언어나 합니다. 판단에 필요한 것은 무엇을 대가로 그 두 가지를 얻는가입니다. Rust가 요구하는 비용은 학습 기간과 컴파일 시간이고, 이 비용이 정당화되는 영역은 생각보다 좁습니다.자주 듣는 말실제로는..

반응형