backend
-
프로세스와 스레드, 그리고 뮤텍스 — 리눅스에서 clone()과 futex로 직접 확인하기
프로세스는 격리되고 스레드는 공유한다는 설명은 어디에나 있지만, 리눅스 커널 입장에서 둘은 clone() 플래그 몇 개 차이일 뿐입니다. Debian 12 컨테이너에서 fork와 pthread_create가 실제로 부르는 시스템콜을…
-
[채팅 백엔드 보안] WebSocket은 무엇으로 지키고, 셀프호스팅한 메시지 큐는 누가 들여다보나
WebSocket 채팅을 무엇으로 인증·격리하는지(JWT HS256 + TLS + 테넌트 네임스페이싱), 메시지 큐로 RabbitMQ를 고른 이유와 PV 구성, 그 큐를 headless ClusterIP로 바깥에 안 여는 접근…
-
[채팅 백엔드 설계] 방이 두 pod에 흩어졌을 때 — RabbitMQ fan-out과 app_key 멀티테넌시
게이트웨이를 여러 pod로 늘리면 같은 방의 두 사용자가 서로 다른 인스턴스에 붙는다. RabbitMQ topic exchange에 인스턴스별 ephemeral 큐를 바인딩하고 origin 태그로 중복을 막는 fan-out, 그리고…
-
[채팅 백엔드 설계] 게이트웨이를 일부러 멍청하게 — 실시간 릴레이와 영속화를 분리한 이유
채팅 백엔드에서 실시간 전달과 메시지 영속화를 한 서비스에 묶으면 DB 장애가 실시간을 죽이고 스케일링이 어려워진다. room-gateway를 DB도 비즈니스 로직도 없는 ‘dumb pipe’로 두고, 클라이언트가 WS…
-
[백엔드 운영] 풀을 키우기 전에 — 느린 SQL이 커넥션을 잡고 있을 때
active가 max에 붙었다고 풀이 작은 건 아니다. 각 커넥션이 어떤 SQL을 몇 ms째 잡고 있는지(held)부터 봐야 한다. items.order_id 인덱스 하나로 hold time을 줄여, 풀을 키우지…
-
[백엔드 운영] 긴 작업이 짧은 요청을 잡아먹을 때 — 풀 격리와 읽기/쓰기 분리
풀은 FIFO 큐다. 긴 작업 하나가 슬롯을 오래 잡으면 빠른 SELECT까지 줄 뒤에서 대기한다. short/long 풀 격리와 읽기/쓰기 분리를 Spring의 AbstractRoutingDataSource(마법)와 Go의 명시 호출로 비교한다.
-
[백엔드 운영] Hikari가 공짜로 해주던 것 — 커넥션 누수 추적을 직접 만들어 보다
커넥션을 빌리고 반납을 안 하면 풀은 조용히 고갈된다. HikariCP는 leakDetectionThreshold 한 줄로 누수를 stacktrace까지 잡아주지만, Go pgxpool엔 그 기능이 없어 직접 만들어야 한다. 같은 UX를…
-
[백엔드 운영] 커넥션을 얼마나 기다리고 얼마나 오래 살릴까 — timeout과 lifetime을 Hikari·pgxpool로 비교
풀이 비었을 때 얼마나 기다릴지(connectionTimeout vs ctx deadline)와 커넥션을 얼마나 오래 살릴지(maxLifetime). ‘실패를 빨리 만들수록 건강하다’는 fast-fail 원리와, DB가 먼저 끊은 죽은 커넥션을 풀이 빌려주는…
-
[백엔드 운영] 커넥션 풀이 막히는 순간을 숫자로 읽는 법 — Hikari와 pgxpool은 같은 고갈을 다르게 보여준다
active·idle·awaiting·total·max 다섯 숫자와 p50·p99로 풀의 상태를 읽는 법. 그리고 같은 풀 고갈을 HikariCP는 awaiting 게이지로, Go pgxpool은 누적 카운터로 보여주는 관측 패러다임 차이까지 — 두…