현우의 개발노트

다중화된 서버에서 중복 요청을 막는 다섯 가지 방법, 그리고 각각이 뚫리는 지점

결제 도메인에서 중복 요청을 막기 위해 쓰는 다섯 가지 방법을 정리하고, 각 방법이 실제로 어디서 뚫리는지를 다중화 환경 기준으로 짚어봅니다. 안녕하세요, 구독 결제와 정산 도메인을 개발하고 있는 백엔드 엔지니어입니다. 결제 도메인에서 중복은 버그가 아니라 사고입니다. 화면에 데이터가 두 줄 찍히는 정도로 끝나지 않습니다. 사용자 계좌에서 두 번 빠져나가고, CS가 들어오고, 환불이 나가고, 그날 정산 데이터를 다시 계산해야 합니다. 운이 나쁘면 원천사와의 대사에서 며칠 뒤에야 발견됩니다.서버가 한 대였을 때는 이 문제가 어렵지 않았습니다. synchronized 하나면 대부분 해결됐으니까요. 그런데 트래픽이 늘어 인스턴스를 늘리고, 오토스케일링을 걸고, 배포 방식을 롤링으로 바꾸는 순간 이전에 쓰던 방..

1. 시작은 코드 리뷰에서 깨진 자존심주니어 시절에 파일 업로드 기능을 만든 적이 있습니다. 서비스 레이어에서 IOException이 튀어나오길래 별생각 없이 throws IOException을 붙였고, 그 위 컨트롤러도 컴파일이 안 되니까 또 throws를 붙였습니다. 결국 컨트롤러 메서드 시그니처가 이렇게 됐죠. java@PostMapping("/files")public ResponseEntity upload(MultipartFile file) throws IOException { ...}PR을 올렸더니 리뷰어가 딱 한 줄 남겼습니다. "이 예외, 컨트롤러가 받아서 뭘 할 수 있죠?"할 말이 없었습니다. 컨트롤러는 그 예외로 아무것도 안 했거든요. 그냥 컴파일러가 시켜서 던진 거였습니다. 그날 ..

Q. 메시지가 중복 소비될 수 있나요? 네. Kafka의 기본 전달 보장은 at-least-once이므로 컨슈머 로직은 멱등하게 설계하는 것이 원칙입니다. 한 줄로 넘어갔지만, 사실 이 문장이 실무에서는 가장 많은 시간을 잡아먹는 부분입니다. 특히 결제나 이용권처럼 "한 번만 일어나야 하는 일"을 다루는 도메인이라면 더 그렇습니다.이번 글에서는 컨슈머를 멱등하게 만드는 구체적인 방법을 다룹니다. Redis, DB 제약, 대사 배치를 겹쳐 쌓는 3중 방어 구조이고, 마지막에는 그게 실제로 동작하는지 테스트로 증명하는 부분까지 정리했습니다.1. 왜 중복이 발생하는가Kafka가 못 만들어서 중복이 생기는 게 아닙니다. 분산 환경에서 "정확히 한 번"을 보장하는 게 원래 어렵기 때문입니다.메시지 전달 보장은 ..

1. 쿠버네티스란 무엇인가?쿠버네티스(Kubernetes, 줄여서 K8s)는 컨테이너화된 애플리케이션의 배포, 확장, 복구를 자동화하는 컨테이너 오케스트레이션 플랫폼입니다. 구글이 내부 시스템(Borg) 운영 경험을 바탕으로 만들어 오픈소스로 공개했고, 현재 CNCF(Cloud Native Computing Foundation)가 관리하는 사실상의 업계 표준입니다. 이름은 그리스어로 '조타수'라는 뜻이며, K8s는 K와 s 사이 8글자를 줄인 표기입니다.도커로 컨테이너를 쓰다 보면 개수가 빠르게 늘어납니다. 서버 10대에 컨테이너 100개를 굴리는 순간, 다음 질문들이 생깁니다.죽은 컨테이너는 누가 다시 띄우는가?트래픽이 몰리면 누가 컨테이너 수를 늘리는가?새 버전 배포 시 어떻게 무중단으로 교체하는가?..

1. Kafka란 무엇인가?Apache Kafka는 LinkedIn에서 개발되어 오픈소스로 공개된 분산 이벤트 스트리밍 플랫폼입니다. 초당 수백만 건의 메시지를 처리할 수 있는 높은 처리량(Throughput)과, 디스크 기반의 내구성(Durability)을 동시에 제공하는 것이 특징입니다.한 줄로 요약하면 이렇습니다."데이터를 발행(Publish)하고 구독(Subscribe)하는, 대용량 처리에 특화된 분산 로그 저장소"실무에서는 주로 다음과 같은 용도로 사용됩니다.서비스 간 비동기 통신 — 주문 서비스 → 결제 서비스 → 알림 서비스처럼 시스템을 느슨하게 연결이벤트 소싱 / 데이터 파이프라인 — DB 변경 사항(CDC)을 다른 시스템으로 실시간 전파로그 수집 — 여러 서버의 로그를 한 곳으로 모아 E..

REST API에서 반드시 기억할 핵심 개념 HTTP MethodMethod역할예시GET조회/users?id=1POST생성/usersPUT전체 수정/users/1PATCH부분 수정/users/1DELETE삭제/users/1 상태 코드 (Status Code)코드의미200 OK성공201 Created생성 성공400 Bad Request파라미터 오류401 Unauthorized인증 필요403 Forbidden권한 없음404 Not Found리소스 없음500 Internal Server Error서버 오류 URL 패턴 규칙잘못된 방식올바른 방식/getUser?id=1/users/1/deleteUser/1/users/1 (DELETE 메서드 사용)/createUser/users (POST 사용) Query ..

코딩테스트 공부할때 알아두면 좋은 문법 정리 1. 입력(Input) 빠르게 받기BufferedReader br = new BufferedReader(new InputStreamReader(System.in));StringTokenizer st = new StringTokenizer(br.readLine());int n = Integer.parseInt(st.nextToken()); // 예: 입력 "5" → n = 5 2. 문자열 처리String s = "hello world";s.length(); // 11s.charAt(0); // 'h's.substring(0, 5); // "hello"s.split(" "); // ["h..

시스템 디자인(System Design) 완벽 정리 “기능은 잘 돌아가는데, 왜 실제 서비스는 자꾸 느려지고 장애가 날까?”“트래픽만 조금 몰려도 서버가 버티질 못하네… 대체 어디서 막히는 거지?” 서비스가 커질수록 이런 질문들이 자주 등장한다.그리고 이 문제들의 공통된 원인은 대부분 구조(Architecture) 설계 부족이다.기능 구현은 잘 되어 있어도, 서비스 전체가 트래픽을 견딜 수 있는 구조로 설계되지 않았다면 결국 병목이 생기기 마련이다.이 “구조적 병목”을 해결하기 위해 등장한 분야가 바로 시스템 디자인(System Design)이다. 1. 시스템 디자인이란 무엇인가?먼저 큰 그림부터 보자.대부분의 웹 서비스는 아래와 같은 계층 구조를 가진다.위로 갈수록: 사용자와 가까워서 빠르고 가..

CPU 캐시와 메모리 계층 구조 완벽 정리 “CPU는 초당 수십억 번 연산한다는데, 왜 내 프로그램은 이렇게 느릴까?” 이 질문의 결론은 생각보다 간단하다.대부분의 병목은 ‘연산’이 아니라 ‘메모리 접근’에서 발생한다.CPU는 미친 듯이 빠르지만, 우리가 일반적으로 말하는 메모리(DRAM)는 그 속도를 절대 따라오지 못한다.이 속도 차이를 메우기 위해 만들어진 게 바로 캐시(Cache)다.오늘은 CPU 캐시가 왜 중요한지, 그리고 실제 프로그램 성능에 어떤 영향을 미치는지 정리해보려고 한다. 1. 메모리 계층 구조 전체 흐름 컴퓨터의 메모리는 위로 갈수록 빠르고 비싸고 작고, 아래로 갈수록 느리고 싸고 크다.레지스터(Register)L1 캐시L2 캐시L3 캐시메인 메모리(DRAM)SSD / ..

CPU 캐시와 메모리 계층 구조 완벽 정리 “CPU는 초당 수십억 번 연산한다는데, 왜 내 프로그램은 이렇게 느릴까?” 답은 대부분 메모리에 있다.CPU는 엄청 빠른데, 메모리(특히 DRAM, 우리가 말하는 ‘메모리’)는 상대적으로 너무 느리다.이 “속도 차이”를 줄이기 위해 등장한 게 바로 캐시(Cache)다. 1. 메모리 계층 구조일단 큰 그림부터 보자. 실제 컴퓨터의 메모리는 대략 이렇게 계층으로 되어 있다.위로 갈수록: 빠르고, 용량이 작고, 비싸다아래로 갈수록: 느리고, 용량이 크고, 싸다레지스터(Register) – CPU 안에 있는 진짜 찐-고속 저장소L1 캐시 – CPU 코어 안에 붙어 있는 가장 빠른 캐시L2 캐시 – L1보다 크고 약간 느린 캐시L3 캐시 – 여러 코어가 공유하..