Coffee Order Service의 포인트 결제를 설계하면서 처음 떠올린 해법은 Redis 분산 락이었다. 결제처럼 정합성이 중요한 기능에 동시 요청이 들어온다면, 같은 사용자의 요청을 한 줄로 세워야 안전하다고 생각했다. 그런데 설계를 따라가다 보니 질문이 달라졌다. 정말 Redis가 있어야 포인트 잔액을 지킬 수 있을까? DB가 이미 ...

Redis를 캐시나 분산 락에 사용하면서도 그동안은 Redis 프로세스가 정상적으로 동작한다는 전제를 당연하게 생각했다. 장애에 대비하려면 Replica를 두면 된다고 막연히 생각했고, Sentinel은 그 Replica를 관리하는 부가 기능 정도로 이해했다. 이번에 학습하며 생각이 달라졌다. Replica는 데이터를 복제하지만 스스로 장애를 판단해...

대용량 트래픽을 처리해야 한다는 말을 들으면 먼저 서버 사양을 높이거나 인스턴스를 늘리는 방법을 떠올렸다. 캐시를 붙이고 비동기 처리를 적용하는 것도 빠지지 않았다. 하지만 Redis, Kafka, k6를 함께 학습하면서 질문이 조금 달라졌다. 대용량 트래픽을 처리한다는 것은 단순히 서버 성능을 높이는 일이 아니라, 데이터 처리 책임을 분리하...

온톨로지를 알아보게 된 이유 AI 세컨드 브레인이라는 개념을 알아보다가 온톨로지(Ontology)라는 낯선 용어를 만났다. 처음에는 AI 세컨드 브레인을 메모를 저장해 두었다가 자연어로 검색하는 시스템 정도로 생각했다. 그런데 내용을 따라가다 보니 단순히 기록을 찾는 것만으로는 충분하지 않은 경우가 있었다. 예를 들어 Redis라는 단어가 포함된 ...

들어가며 Kafka를 처음 보면 Producer가 메시지를 보내고 Consumer가 메시지를 처리하는 구조가 먼저 보인다. 나도 처음에는 “주문 서비스가 이벤트를 발행하고, 결제나 포인트 서비스가 구독해서 처리하면 되겠구나” 정도로 이해했다. 하지만 공부할수록 더 중요한 질문은 메시지를 보내는 방법이 아니었다. Consumer가 처리하다 실패하면 ...

들어가면서 Kubernetes를 처음 보면 용어가 꽤 많다. Pod, Service, Deployment, ReplicaSet, Controller, Scheduler, kubelet 같은 단어가 한꺼번에 나오기 때문에 처음에는 “이걸 다 외워야 하나?”라는 생각이 들었다. 하지만 Docker와 EC2 기반 배포를 공부한 흐름에서 다시 보니, Ku...

오늘 정리한 이유 RAG를 처음 봤을 때는 단순히 “LLM 답변을 더 잘하게 만드는 기능” 정도로 생각했다. 사용자가 질문하면 관련 문서를 찾아서 답변에 넣어준다. 겉으로만 보면 그렇게 복잡해 보이지 않았다. 그런데 조금 더 정리해보니 핵심은 LLM보다 검색 파이프라인에 가까웠다. RAG는 LLM 자체를 더 똑똑하게 만드는 기술이 아니다. 답변 전...

들어가면서 이전에 Nginx는 왜 Spring Boot 앞단에 있을까?를 정리하면서, Nginx를 외부 요청을 먼저 받고 내부 Spring Boot 애플리케이션으로 전달하는 앞단 서버로 이해했다. 그때의 핵심은 다음 구조였다. Client → Nginx → Spring Boot 이 정도만 보면 Nginx는 Spring Boot 앞에서 요청을 ...

Kubernetes를 공부하게 된 이유 최근 배포 흐름을 공부하면서 단일 EC2 배포, Docker Compose, GitHub Actions를 이용한 CI/CD, 무중단 배포, Blue-Green, ASG 같은 개념들을 차례대로 살펴봤다. 처음에는 애플리케이션을 서버에 올리고 실행하는 것 자체가 배포의 핵심이라고 생각했다. 하지만 배포를 공부할수...

처음 Spring Boot 애플리케이션을 EC2에 배포한다고 생각했을 때, 가장 단순한 구조는 애플리케이션을 실행하고 8080 포트로 직접 접근하는 방식이었다. User ↓ Spring Boot : 8080 접근 주소도 자연스럽게 다음처럼 떠올렸다. http://example.com:8080 개발 환경에서는 localhost:8080으로...