블로그

전체 게시글 (18)

결제 도메인의 재시도 상황 및 전략, 멱등성 연계

결제 과정은 금전과 관련된 일이기 때문에 반드시 한번 이상의 처리를 보장해야합니다. 이를 보장하려면 필연적으로 재시도가 생겨납니다.  네트워크 끊김 등 모든 상황에서도 한번 이상 올바르게 처리되도록 하기 위해서는 트랜잭션으로 보장받지 못하는 모든 연결부에서 발생하는 케이스에서 실패 시 재시도가 되어야 하기 때문입니다. 따라서 똑같은 로직이 여러번 발생하는 경우 생기는 문제를 막기 위해 멱등성을 보장했습니다. 시리즈의 전 포스트를 참고해주세요. 이번 글에선 결제 도메인에서 재시도 처리를 해야하는 케이스들을 살펴보고,

‌

protobuf 관리 전략 – Submodule, Buf, Schema Registry

IDL로 protobuf를 도입했을 때 필연적으로 따라오는 것은 protobuf에 대한 관리 문제입니다. IDL은 통신에서 사용되는 공유 계약으로 이용되어 서비스가 동일한 IDL 스펙을 반드시 따라야하게 만듭니다. 특히 protobuf 같은 경우엔 각 값의 key 값이 따로 존재하지 않고 field number만 이진화되어 전송되기 때문에, 해석하는 측에서 직렬/역직렬화 과정에서 이를 올바르게 해석하려면 양쪽 서비스가 동일한 proto 정의를 공유하고 있어야 합니다. 따라 protobuf를 올바르게 사용하고 관리하기 위해서는 스

‌

gRPC vs HTTP/REST - 실제 서비스 환경에서의 부하 테스트로 살펴본 성능과 오버헤드

마이크로서비스 아키텍처가 자리 잡으면서 서버 간 통신 방식으로 gRPC가 주목받고 있습니다. 많은 아티클에서 “gRPC는 HTTP/1.1 기반 API보다 빠르다”라는 이야기를 접해보셨을 겁니다. 하지만 실제로 얼마나 빠른지, 어떤 상황에서 빠른지, 그리고 기존 벤치마크 결과가 얼마나 신뢰할 만한지는 직접 실험해보지 않으면 체감하기 어렵습니다. 이번 글에서는 클라우드 환경에 배포된 DB I/O, Kafka 등이 연결된 실제 애플리케이션을 대상으로 부하 테스트를 진행했습니다. 단순히 프로토콜 차원뿐만 아니라, 애플리케이션 내부의 풀

‌

[Spring] 카프카 의존성 - Spring Cloud Stream vs Spring Kafka

스프링에서 카프카 Producer과 Consumer를 사용하기 위해서는 대게 2가지 방법이 있습니다. 바로 Spring Cloud Stream 과 Spring Kafka입니다. 두 기술은 서로 철학과 장단이 다른데, 이름에서 볼 수 있듯 Spring Cloud Stream은 추상화 레벨이 높고, Spring Kafka는 Kafka라는 이름이 직접 들어가는 만큼 더 세밀한 카프카 지향적인 제어가 가능합니다. 이번엔 두 기술을 비교해보며 각각의 철학 및 사용법을 확인해보고 장단점을 알아보겠습니다. 스프링 클라우드 스트림 (Spri

‌

결제 도메인에서의 멱등성 보장

결제 도메인과 같이 일관성이 중요하면서도 PG사에 통신이 들어가는 등 일련된 비즈니스 로직을 하나의 트랜잭션에 담기 어려운 경우 멱등성 처리가 굉장히 중요해집니다. 일관성과 안전성을 챙기다 보면 자연스럽게 재시도 혹은 중복 요청 발생에 대한 위험성이 같이 늘어가기 때문이죠. 멱등성(Idempotency)은 동일한 연산을 여러 번 적용해도 그 결과가 최초 한 번 적용했을 때와 달라지지 않는 성질을 뜻합니다. 가령 유저가 PG 통신을 통한 결제 이후 결제 승인 API를 연속적으로 호출해도, 서버 내 결제 승인에 관한 처리는 한번 호

‌

결제 도메인 거래·환불의 동시성 제어 전략

서비스에서 수익 창출을 이루려면 결국 결제 도메인을 구축해야합니다. 필자가 극초기 스타트업에서 결제 도메인을 처음부터 구축하고, 25년 9월까지 6억 매출을 처리한 시스템을 개발한 경험을 토대로 결제 도메인에 대해 분석 및 발생할 수 있는 문제상황과 처리 전략에 대해 소개하겠습니다. 결제 도메인에 대한 설명이나 PG사 연동 방법 같은 부분은 소개하지 않겠습니다. 또한 저 역시 스타트업에서 필요한 결제 시스템 구축 경험에서 비롯되어 핸들링을 하기 때문에 큰 규모의 서비스에서 필요한 요구사항과는 다를 수 있습니다. 결제와 같이 실제

‌

Kafka Consumer - 오프셋 커밋과 재처리 전략, Dead Letter Queue(DLQ)

지난 글에선 카프카 프로듀서 측 주요 개념과 발생할 수 있는 시나리오 및 대응법들을 살펴봤습니다. 사실 프로듀서 측은 세팅만 잘 해두면 큰 문제가 생기지는 않습니다. 데이터의 영속화와 메시지 발행간의 무결성만 잘 지킨다면 외에는 크게 신경 쓸 부분이 없기 때문이죠. 다만 컨슈머 측엔 토픽을 다루는 서비스 로직이 들어가다 보니 발생할 수 있는 상황의 복잡도가 굉장히 높습니다. 이번 글에선 컨슈머 측에서 여러 상황을 컨트롤하기 위해 필요한 개념과 방법들에 대해 알아보겠습니다. 오프셋 커밋 전략 오프셋은 파티션 내에서 각 메시지가

‌

Kafka Producer - ACKS 옵션과 ISR, 메시지 전송 신뢰도

지난 글에서는 프로듀서, 컨슈머, 브로커, 토픽, 파티션 등 카프카의 핵심 개념과 아키텍처에 대해 알아보았습니다. 프로듀서가 producer.send()를 통해 메시지를 발행하면, 해당 메시지는 토픽의 파티션으로 전송되고 컨슈머가 이를 가져가 처리하는 흐름을 이해했습니다. 그런데 여기서 한 가지 중요한 질문이 생깁니다. producer.send()를 호출하고 나면, 우리는 "메시지가 안전하게 전송되었다"라고 언제 확신할 수 있을까요? 프로듀서의 요청이 리더 브로커에 도달하자마자일까요? 아니면 모든 복제본에 저장이 완료되었을 때일까

‌

아파치 카프카란? 기본 개념 및 철학

\*본 시리즈는 필자가 Confluent의 문서들과 강의 한번에 끝내는 Kafka Ecosystem, 이외의 여러 자료들을 통해 학습한 내용을 기반으로, 응용 서비스 개발자들이 카프카를 사용하는데 필요한 개념과 코드들을 컴팩트하게 모아 정리하는 것을 취지로 합니다. 따라 인프라적인 내용이나 DevOps 관점에서의 깊이 있는 탐구는 다루지 않습니다. 시작하며: 왜 Kafka인가? Spaghetti Code 현대의 소프트웨어는 점점 더 복잡해지고, 비즈니스가 성장함에 따라 관여하는 이해관계자와 기능의 수도 늘어납니다. 자연스럽게

‌

2025 하반기 삼성SDS 알고리즘 특강 & PRO 시험 합격 후기

4학년 2학기를 앞둔 방학에서, 슬슬 취준 및 코테 준비를 시작하던 중, 대학교 지인한테 추천받아서 삼성 SDS 대학생 알고리즘 특강을 지원해보았습니다. 2주간 매일 8시간동안 알고리즘만 풀고, 시험도 치고 드디어 모든 과정이 끝난 김에 복기겸 글을 써봅니다! 지원 과정 25년 하반기에 올라온 포스터 사진입니다. 포스터에 있는 QR을 통해 구글폼을 제출하는 식으로 지원서를 작성하실 수 있습니다. 생각보다 서류가 복잡한데, 자기소개서, 재학증명서, 성적증명서를 제출했었던 걸로 기억합니다. 특히 자기소개서 대충 쓴 지인들을 다 떨

‌