고민보단 실천을

Kafka 재시도 토픽/딜레이/ DLQ 설계: 실패를 '멈춤'이 아니라 '흐름'으로 만들기컨슈머가 실패했을 때 같은 메시지에서 계속 실패하면 파티션이 막힌다. 재시도/지연/DLQ를 설계해 실패를 흐름으로 만들어야 한다.기본 패턴main topic: 정상 처리retry topic: 일정 지연 후 재처리DLQ: 최종 실패를 모아 분석/재처리지연을 만드는 방법여러 retry 토픽(retry-5s, retry-1m...)로 단계를 둔다.컨슈머에서 sleep으로 지연하지 않는다(파티션 막힘).DLQ에 남겨야 하는 정보event_id(또는 message key)실패 reason(코드/요약) + stacktrace(또는 축약)원본 payload(또는 참조 위치)와 재처리 횟수최초 발생 시각/마지막 시각재처리(Repl..

Kafka Exactly-Once(정확히 한 번) 오해 정리: idempotent producer, transactions, 소비자 설계Kafka Exactly-Once는 중복이 절대 없다는 뜻이 아니다. 범위와 조건을 모르고 도입하면 더 복잡해진다.용어At-most-once: 중복은 없지만 누락 가능.At-least-once: 누락은 없지만 중복 가능.Exactly-once: 특정 경계에서 중복/누락을 통제.Idempotent Producer(개념)enable.idempotence=trueacks=allretries=...토픽->DB 경계에서의 현실적인 결론대부분은 at-least-once + DB 멱등(유니크/업서트)로 충분하다.Exactly-once는 토픽->토픽(스트림 처리)에서 효과가 더 크다...

Kafka Consumer 리밸런스 튜닝: 처리량 떨어지는 원인과 설정 체크리스트Kafka는 처음엔 잘 돌다가, 데이터가 늘거나 배포가 잦아지면 리밸런스가 반복되며 처리량이 흔들린다.대표 원인poll 처리가 너무 오래 걸린다(heartbeat 끊김).배포/스케일로 멤버 수가 바뀐다(재할당).네트워크/GC pause로 session timeout을 넘는다.핵심 설정(개념)max.poll.interval.ms: poll 사이(처리 포함) 최대 허용 시간session.timeout.ms: heartbeat 없을 때 추방까지heartbeat.interval.ms: heartbeat 주기poll 루프를 오래 잡지 않는 패턴poll은 자주, 처리는 워커(스레드/코루틴)로 넘긴다.max.poll.records로 한 ..

Idempotency-Key 설계 실전: 중복 요청을 안전하게 처리하는 API 패턴네트워크 타임아웃/재시도 때문에 같은 요청이 여러 번 들어오는 건 정상이다. 문제는 주문/결제 같은 요청이 한 번만 실행돼야 한다는 점이다.DB 테이블 설계 예시CREATE TABLE idempotency_keys ( id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL, endpoint TEXT NOT NULL, idem_key TEXT NOT NULL, request_hash TEXT NOT NULL, status TEXT NOT NULL, response_code INT, response_body JSONB, created_at TIMESTAMPTZ NOT NULL ..

HTTP 커넥션 풀/Keep-Alive 실전: 타임아웃, 재사용, 커넥션 누수로 장애 나는 패턴의외로 HTTP 커넥션(keep-alive/풀) 때문에 장애가 나는 경우가 많다. 풀 고갈/누수/타임아웃을 운영 관점에서 정리한다.OkHttp 설정 예시val client = OkHttpClient.Builder() .connectTimeout(300, TimeUnit.MILLISECONDS) .readTimeout(800, TimeUnit.MILLISECONDS) .callTimeout(1000, TimeUnit.MILLISECONDS) .connectionPool(ConnectionPool(50, 30, TimeUnit.SECONDS)) .build()커넥션 누수의 전형적인 원인응답 바디를 끝까지 ..

DB 데드락 실전: 원인(락 순서) 분석과 재시도/쿼리/인덱스로 줄이는 법데드락은 대부분 락 획득 순서가 서로 다르기 때문에 생긴다. 원인 분석과 예방/완화(재시도) 전략을 정리한다.전형적인 예시-- Tx ABEGIN;UPDATE accounts SET balance = balance - 100 WHERE id = 1;UPDATE accounts SET balance = balance + 100 WHERE id = 2;COMMIT;-- Tx B (순서 반대)BEGIN;UPDATE accounts SET balance = balance - 50 WHERE id = 2;UPDATE accounts SET balance = balance + 50 WHERE id = 1;COMMIT;데드락을 줄이는 3가지 큰 ..

CORS 프리플라이트 최적화: 왜 OPTIONS가 폭주하고 어떻게 줄이나CORS는 허용/차단만의 문제가 아니다. 운영에서는 OPTIONS 프리플라이트가 트래픽을 잡아먹는 경우가 있다. 발생 조건과 줄이는 방법을 정리한다.프리플라이트 발생 조건(요약)simple request가 아니다(커스텀 헤더, 특정 Content-Type 등).Authorization 헤더 사용.PUT/DELETE 같은 메서드.Access-Control-Max-Age로 캐시Access-Control-Allow-Origin: https://app.example.comAccess-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONSAccess-Control-Allow-Headers: Content-T..

API Pagination 실전: Offset vs Cursor, 정렬 안정성으로 중복/누락 방지하기페이지네이션은 구현이 쉬워 보여도, 데이터가 계속 변하는 서비스에서는 중복/누락과 성능 문제로 바로 운영 이슈가 된다.Offset과 Cursor(Seek) 방식의 차이를 비교하고, 정렬 안정성과 커서 설계까지 포함해 바로 적용 가능한 형태로 정리한다.Offset이 쉬운 만큼 위험한 이유OFFSET이 커질수록 앞쪽 행을 더 많이 스캔/버린다.데이터 삽입/삭제가 동시에 일어나면 페이지 사이에 중복/누락이 생긴다.정렬 키가 유일하지 않으면 결과가 흔들린다(createdAt만 정렬 등).Cursor(Seek) 페이지네이션 기본 쿼리실무에서는 (createdAt, id)처럼 유일해지는 조합을 정렬 키로 만든다.--..

타임아웃 설계 실전: 클라이언트-프록시-서버-DB 타임아웃을 '정렬'하는 방법타임아웃은 짧게가 아니라 '정렬'이 핵심입니다. 레이어마다 제각각이면 장애가 길어집니다.클라이언트/프록시/서버/DB 타임아웃을 어떤 순서로 맞추는지, 재시도 예산까지 포함해 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지 않게 됩니다.실전 내..