pandaterry's 개발로그

이전 글(https://pandaterry.tistory.com/10)에서는 Redis AOF, RDB과 Kafka를 비교하며 메시지 유실 문제를 직접 실험했습니다. AOF(Append Only File)와 RDB 설정을 활용해 Redis에 유실되지 않는 메시지 큐 구조를 흉내내는 실험을 진행했었고,단순 큐잉 수준에서는 Redis로도 Kafka의 일부 역할을 대체할 수 있다는 가능성을 확인했습니다. 하지만 여전히 해결되지 않은 문제가 있었습니다. Kafka가 주목받는 진짜 이유는 ‘복구’와 ‘재처리’에 있습니다. 단순히 메시지를 저장하는 것을 넘어서,누가 메시지를 소비했는지 추적하고실패한 메시지는 다시 재시도하거나결국에는 DLT(Dead Letter Topic)으로 보낼 수 있는 운영 가능한 복구 흐름..

이전 글(https://pandaterry.tistory.com/9)에서는 Redis Pub/Sub과 Kafka를 비교하며 메시지 유실·재처리 이슈를 검증했습니다. 이번 글에서는 “Redis만으로도 신뢰형 메시지 큐를 구현할 수 있지 않을까?”라는 의문으로 다음 방식으로 직접 비교·실험해보겠습니다. 왜 Pub/Sub만으로는 부족했을까?현재 개발중인 SaaS 서비스는 “사용자의 Saas 기능 사용 -> 사용량 측정”이라는 흐름을 비동기로 처리합니다. 이 구조에서 가장 먼저 선택한 메시지 브로커는 Redis Pub/Sub이었습니다. 설정이 간단하고, 즉각적인 전달이 가능했기 때문입니다.하지만 곧 문제를 마주하게 됩니다."만약 메시지를 구독 중이던 서버가 죽는다면?""그 사이에 발행된 메시지는 어떻게 되는가..

Kafka로 전환하기 전, 직접 실험해봤습니다 SaaS에서 비동기 메시지는 선택이 아니라 필수입니다제가 구축하고 있는 SaaS 시스템은 마케팅/비즈니스 부서가 자연어로 데이터를 요청하면, 그 요청을 백엔드에서 SQL로 변환하고 엑셀로 응답해주는 플랫폼입니다. 문제는 여기서 끝나지 않았습니다. 사용자의 요청은 내부 시스템에서 백엔드 작업자에게 전송돼야 하고동시에 로그로 남겨져야 하며실패 시 재시도도 가능해야 합니다 처음엔 Redis Pub/Sub으로 충분하다고 생각했습니다.하지만 “요청이 처리됐는지 안 됐는지조차 확인할 수 없다면, 그건 SaaS가 아니라 알 수 없는 상자”가 되어버리더군요. 그래서 Kafka를 검토하게 되었고, “진짜로 필요한가?”라는 의문에 답하기 위해 직접 실험을 진행했습니다...

사가 패턴 : 오케스트레이션여러 마이크로서비스에 걸친 분산 트랜잭션을 관리하기 위해 사용한다.일련의 로컬 트랜젝션으로 만들어서 비즈니스 프로세스를 구성하고, 각 단계별로 실패시 보상 트랜젝션을 통해 이전 상태로 롤백한다.사가 오케스트레이션 + 아웃박스 패턴Command는 즉시성때문에 아웃박스 XOrchestrator가 각 서비스에 명령(Command)를 보낼 때 아웃박스 패턴을 사용하지 않음. (바로 카프카로 전송. 그리고 아웃박스 패턴을 사용하려면 Command도 EventStore에 저장해야하는데, Relay하지도 않는 메시지를 굳이 이벤트 스토어에 저장하여 부하를 발생시킬 이유도 없음.)이벤트로 비동기 응답처리는 아웃박스 O각 서비스의 Response(성공/실패)도 아웃박스 패턴으로 발행타 마이크로..

용어 정리 : 이벤트 vs 커맨드이벤트(Event)이벤트는 단순히 이걸 했다! 정도의 이력을 기록하는 용도이다. 어떠한 작용을 강제하는 역할을 하지는 않는다. 그래서 단순히 작업에 따라 event store에 event를 저장만 한다.커맨드(Command)커맨드는 말그대로 요청을 의미한다. 외부(External) 비동기 요청 : 마이크로서비스 환경에서 타 서비스에 작업을 요청할 수도 있고, 통신을 할 때 전달하는 객체 형태의 단위라고 보면 좋다. 내부(Internal) 요청 : 마이크로서비스 형태가 아니더라도, 하나의 서비스에도 여러 애그리게이트가 존재할 수도 있는데, 트랜젝션의 범주가 분리되는 기준으로 말이다. 그래서 다른 애그리게이트의 서비스에도 요청을 할 때 내부적으로 command를 사용할 수 있..

출처 : Credly.com24.08.12 에 봤던 AWS Certified Solution Architect Professional 시험 후기입니다. 현재는 군인 신분이라 나머지 날은 쉬고 싶어서 이번 8월 휴가 첫날에 바로 선릉 SRTC 시험장에 가서 빠르게 치고 왔네요. 군대에서 1.5개월이라는 시간동안 준비하고 붙은 후기가 회사를 다니시면서 빠른 시간내에 붙고 싶으신 다른 분들에게 도움이 되기를 바라면서 얘기를 해보겠습니다.​​시험 준비 배경일단 이전과 상황이 많이 바꼈기에 소개를 하자면, 사업을 마무리하고 대학 졸업도 하고 현재 공군으로 복무하면서 지내고 있습니다. 군 복무 1년간 커리어 계획을 세우고 그에 맞춰 단계별로 격파해나가고 있는데, 그 중 하나가 바로 이 'AWS 자격증따기' 입니다...

Q. 이커머스 사이트에서 '나의 구매목록'을 조회하는 기능이 있다고 할 때, 초반에는 데이터가 적어 페이지 로딩이 빠르지만 시간이 지나 억 단위의 데이터가 생성되었다면 조회할 때마다 페이지 로딩이 느려질 것입니다. 로딩 시간을 개선하기 위해 어떤 해결책을 제시할 수 있을까요? 이 문제를 봤을 때, pagination을 하면 되는거 아니야? 라고 단순하게 생각할 수도 있다.그러나 억단위의 데이터의 경우, order by와 limit 쿼리가 실행될 때 페이지가 넘어갈수록 스캔해야할 데이터가 너무 많아지는 문제가 여전히 존재한다. 그러면 시간순으로 미리 index 처리를 하면 되지 않는가? 라고 반박할 수도 있다. 그러나 '나의 구매목록' 조회라는 페이지의 특성상 userId로 where 쿼리가 추가적으로 실..

Q.동시성과 병렬성을 설명해보세요. 질문을 받으면 헷갈려서 생각이 안날 수 있다.일단 둘은 완전 다른 개념이다.  동시성(Concurrency) 동시성, 영어로는 Concurrency이다. 정말 말그대로 함께 진행되는가? 에 대한 단어이다. 근데 이 말은 동시에 진행되는가랑은 조금 거리를 둘 필요가 있다. 실제로는 Concurrency는 함께 진행되는지 여부를 묻는 것이다. Parallelism인 병렬과 다르게 나란히 진행되지는 않는다.Concurrency는 함께 진행되고는 있으나 매우 빠른 속도로 번갈아가며 실행되는 것을 의미한다.아래는 동시성이 적용되는 사례이다. 단일 스레드에서 이벤트 루프를 통해 요청을 번갈아 가며 처리를 할 수 있다.Non-blocking IO를 사용해 기존 단일스레드를 블로킹하..