지금까지 학습한 내용을 간단하게 정리해보면, offset은 broker에 저장된 메시지의 순서를 의미하고, consumer는 이 offset을 기준으로 메시지를 읽고 처리하게 됩니다.그리고 어디까지 처리했는지를 기록하는 과정을 offset commit이라고 합니다. 이 commit 방식에는 크게 두 가지가 존재합니다. 자동 commit은 일정 주기에 따라 offset을 자동으로 기록해주기 때문에 구현이 간단하다는 장점이 있습니다. 하지만 처리 완료 여부와 관계없이 offset이 기록되기 때문에, 메시지를 처리하는 도중 애플리케이션에 장애가 발생할 경우 문제가 발생할 수 있습니다. 이 경우 Kafka는 해당 메시지를 이미 처리된 것으로 인식하게 되고, consumer가 재시작되더라도 메시지는 다시 전달되지..
카프카의 설정은 진짜일까?? - offset(1)원래 시나리오대로면, producer를 전부 끝내고 나서 consumer를 학습하려고 하였지만 살짝 우회하기로 결정하였습니다. 그 이유가 뭐냐면 카프카의 주요 특징중 하나가 offset으로 알고 있습니다. 제b-programmer.tistory.com오랜만에 Kafka 관련 글을 작성하게 되었습니다. 이번 글에서는 offset commit에 대해 알아보려고 합니다. Kafka의 offset은 기본적으로 broker에 저장됩니다. 하지만 이 offset을 기준으로 어디까지 처리했는지 관리하는 주체는 consumer입니다. 그 이유는 broker와consumer의 역할이 다르기 때문입니다. broker는 메시지를 저장하고 전달하는 역할을 할 뿐, 우리 서비스의..
웹소켓과 MQ는 모두 데이터를 전달하는 통로라는 공통점을 가지고 있습니다. 겉보기에는 둘 다 어떤 큐를 통해 메시지를 주고받는 것처럼 느껴질 수 있습니다. 하지만 실제로는 사용하는 목적도 다르고, 시스템 안에서 맡는 역할도 다릅니다. 보통 웹소켓은 실시간성, MQ는 비동기 처리라고 설명합니다. 물론 틀린 말은 아닙니다. 다만 이렇게 이분법적으로 나누면 두 기술의 차이를 충분히 설명하기에는 다소 부족하다고 느껴졌습니다. 웹소켓도 결국 비동기적으로 동작하고, MQ 역시 상황에 따라 실시간에 가깝게 활용될 수 있기 때문입니다. 따라서 이 글에서는 단순한 특징 비교에 그치지 않고, 웹소켓과 MQ에서 말하는 "큐"를 각각 어떻게 이해해야 하는지에 초점을 맞춰 정리해보겠습니다.각각의 큐에는 어떤것을 전달 할까?간단..
Race condition은 여러 작업이 동시에 같은 데이터를 처리할 때, 실행 순서에 따라 결과가 달라지는 문제입니다.쉽게 말해, 같은 자원에 대한 접근이 동시에 발생하면서 기대한 결과와 실제 결과가 달라지는 상황입니다.이전 선착순 쿠폰 시스템을 개발할 때도 이러한 문제가 발생했습니다.예를 들어 100명의 사용자가 동시에 쿠폰 발급을 요청했다고 가정하겠습니다. 응답 결과만 보면 6건만 성공했고, 94건은 실패했습니다.그렇다면 정상적인 시스템이라면 실제 DB에도 성공한 6건만 저장되어 있어야 합니다.하지만 실제로 확인해보니 DB에는 96건의 쿠폰 발급 내역이 저장되어 있었습니다.즉, 애플리케이션이 사용자에게 반환한 결과와 실제 데이터베이스 상태가 서로 일치하지 않았습니다.이런 상황을 정합성이 깨졌다고 할..
배치의 전반적인 처리 과정에 대해 학습을 진행하였다. 배치는 기본적으로 3가지 단계로 동작한다.Reader → Processor → Writer데이터를 읽고, 가공하고, 저장하는 구조이다.하지만 현재까지는 이 흐름을 단순하게 확인하기 위해 배치를 강제로 실행시키는 방식으로 동작을 확인하고 있었다.즉, 배치의 구조를 제대로 사용하기보다는 동작 자체를 이해하는 데에 초점을 맞춘 상태였다. 하지만 스프링 배치에서는 이러한 작업 흐름을Job과 Step이라는 개념을 통해 구조적으로 관리할 수 있다. 단순 실행에서 벗어나, 실행 단위와 흐름을 명확하게 정의할 수 있는 것이다.그렇다면 스프링 배치에서는 이 Job과 Step을 어떻게 구성하고 사용하는지 확인해보자. 그리고 저번시간에 재대로 설명하지 않은 chunk도 ..
저번시간에 간단하게 배치가 어떤것인지 그리고 Reader에 대해 짧게 학습을 진행하였다. 간단하게 복습하면 Reader은 어딘가에 쌓여있는 데이터를 읽는 작업을 일컫는다. 하지만 배치의 전 과정을 생각해보면, 단순히 읽는 것으로 끝나지 않는다. 데이터를 읽고, 가공하고, 저장하는 흐름으로 이루어져 있다. 그렇다면, 어째서 이러한 과정을 거칠까? 이유는 생각보다 단순하다.첫 번째는 데이터의 크기 때문이다. 대량의 데이터를 한 번에 처리하려고 하면 메모리 부담이 커지고, 중간에 실패했을 때 다시 처음부터 실행해야 하는 문제가 발생한다. 그래서 배치는 데이터를 일정 단위로 나누어 끊어서 처리하는 방식을 선택한다.두 번째는 데이터의 구조가 서로 다르기 때문이다. 어딘가에 쌓여있는 데이터의 구조와 DB에 저장되어..
원래 시나리오대로면, producer를 전부 끝내고 나서 consumer를 학습하려고 하였지만 살짝 우회하기로 결정하였습니다. 그 이유가 뭐냐면 카프카의 주요 특징중 하나가 offset으로 알고 있습니다. 제가 알기로 offset은 카프카(브로커)에서 값을 읽을때 특정 부분까지 읽도록 하는걸로 알고 있습니다. 물론 이게 틀린내용일 수 도 있지만, 뭐 상관없습니다. 다시 제대로 학습하면 되는거니까요. 시작해봅시다.그래서 offset이 뭐냐면..offset은 메시지의 위치를 나타내는 번호입니다. kafkasms 메시지를 다음과 같이 저장합니다.[0] [1] [2] [3] [4] ...여기서 숫자가 바로 offset입니다. 즉, kafka는 메시지를 순서대로 쌓고, index처럼 offset을 붙입니다.또한,..
저번 글에서는 스프링 배치를 왜 사용하는지에 대해 살펴보았다. 일괄 작업이 필요한 경우, 배치는 효과적인 선택지가 될 수 있다.배치의 기본 흐름은 단순하다. 데이터를 읽고, 가공한 뒤, 저장하는 것이다. 데이터의 출처가 어디든 상관없이, 해당 위치에서 데이터를 읽어오고, 배치 애플리케이션 내부에서 가공한 뒤, 최종 결과를 저장한다. 여기서 중요한 특징 중 하나는 배치가 주로 스케줄링 기반으로 실행된다는 점이다. 즉, 정해진 시간에 자동으로 실행되며, 사용자 요청과는 분리되어 동작한다.이 말은 곧, 배치가 처리하는 작업은 실시간으로 즉시 반영될 필요가 없으며, 대량의 데이터를 나누어 처리하더라도 서비스에 직접적인 영향을 주지 않는다는 의미다. 따라서 배치는 뒤에서 안정적으로 대량 데이터를 처리하는 데 적합..
2026년 4월3일 면접을 보게 되었습니다. 그때 나왔던 질문중 하나가 인덱스에 대한 질문이었습니다. 과거에 인덱스를 활용해서 성능을 개선해본적이 있었냐는 질문이었습니다. 했었던거 같아 일단 답변은 하긴했었는데 정재되지 않았습니다. 버벅된게 아니라 무슨 답변을 했는지도 기억이 안나는 정도였으니까요. 저는 인덱스를 통해 읽기 성능을 올렸던적이 있었다고 답변하였는데 지금 생각해보면 이것도 애매한 답변이었던거 같습니다. 왜냐하면 성능을 올렸던적이 있었다면 정확한 수치가 필요했을텐데 그렇지 못했으니까요.아무튼 제 경험을 토대로 인덱스를 정리를 해보겠습니다.인덱스는 어떤 성능을 올릴 수 있을까? 기존 테스트..인덱스 적용브랜드 Id만 인덱스를 거는 경우는 어떨까? 생각보다 속도는 비슷하게 나오는듯하다.요렇게 나왔..
이제는 레디스를 언제 쓰고, 카프카를 언제 써야 하는지에 대해서는 어느 정도 감이 잡힌 것 같다. 그런데 이상하게도 이 두 기술보다 더 직관적으로 느껴질 것 같은 스프링 배치는 여전히 잘 와닿지 않는다. 분명 사용해본 적은 있지만, 전체 흐름이 머릿속에 자연스럽게 그려지지는 않는다. 아마 구조가 복잡해서일 수도 있지만, 그보다 더 큰 이유는 내가 배치의 핵심을 제대로 이해하지 못했기 때문일지도 모른다. 그래서 이번 기회에 스프링 배치의 본질을 제대로 짚고 넘어가보려고 한다.그래서 본질이 뭔데?google은 배치를 다음과 같이 설명하고 있습니다.배치는 데이터를 한 번에 모아서 처리하는 방식으로 이해할 수 있다. 좀 더 정확하게 말하면, 이미 쌓여있는 데이터를 가져와 처리하는 것을 의미한다.그렇다면 이 데이..
최근 ChatGPT, Gemini, Grok 등 다양한 LLM 서비스가 빠르게 확산되고 있습니다. LLM(Large Language Model)은 말 그대로 대규모 언어 모델을 의미하며, 인간의 언어를 이해하고 생성할 수 있는 인공지능 기술입니다. 불과 몇 년 전까지만 해도 LLM은 일부 기업이나 연구 기관만 다룰 수 있는 고난도 기술이었습니다. 하지만 현재는 상황이 완전히 달라졌습니다. 누구나 손쉽게 사용할 수 있고, 나아가 직접 활용하거나 구축까지 가능한 수준으로 대중화되었습니다. 지금은 마치 전기나 클라우드처럼 LLM을 '구독'하여 사용하는 시대입니다. 그러나 머지않아 개인이 LLM을 기반으로 서비스를 만들고, 이를 통해 직접 가치를 창출하는 시대가 올지도 모릅니다. 이러한 변화 속에서 LLM을 단..
