본문 바로가기

분류 전체보기

(16)
🔒 Redisson 분산락으로 사용자 매칭 중복 생성 문제 해결기 🙋🏻 문제 상황: 동시에 누른 "좋아요"가 만들어낸 버그저희 서비스는 두 사용자가 서로 좋아요를 눌렀을 때 매칭을 성립시키고, 채팅방을 생성해 연결해주는 구조입니다.좋아요 요청이 들어오면 서버에서는 아래와 같은 데이터를 처리합니다:UserLike: 좋아요 상태, 매칭 여부UserJoinChatRoom: 유저-채팅방 연결ChatRoom: 채팅방 정보서버의 매칭 판별 로직은 UserLikeJpaAdapter 에서 다음과 같은 흐름을 따릅니다:기존에 좋아요한 적이 있는지 조회 (있다면 수정, 없으면 생성)좋아요 상태 업데이트상대방 차단 여부 확인상대방도 나를 좋아요했는지 확인 → 매칭 여부 결정결과를 반환더보기UserLikeJpaAdapter 의 메서드 정리 findOrCreate() - UseLike..
Redis의 원자성(Atomicity)으로 로그인 API의 동시성과 성능을 한 번에 잡다 “로그인 한 번 하는데 5초 넘게 걸려?” 개발자라면 누구나 한 번쯤 들어본 무서운 말입니다.저 역시 Datadog 대시보드를 보다가 SignIn API가 때때로 5~10초씩이나 걸리는 상황을 발견했습니다특히 에러가 나는 경우엔 대기 시간이 더 길어져, 사용자 경험이 크게 떨어졌죠. 1. 원인 추적: 그놈의 낙관적 락로그인을 찬찬히 뜯어보니,JWT 토큰의 조회/삭제/삽입 과정에서 데이터베이스를 자주 탐색하고 있었습니다 JPA에서 흔히 쓰는 낙관적 락(Optimistic Lock) 은레코드 버전 충돌이 일어날 때“에이, 설마 동시에 같은 걸 바꾸겠어?” 라는 가정 하에 동작합니다. 하지만 그 가정을 깨는 상황이 오면 ObjectOptimisticLockingFailureException 이라는 예외가 발생..
[Kafka] Listener 기본 설정 (6) 이번에 카프카를 구현하면서 오랜만에 막연함을 느꼈던 것 같다. 구현을 하고, 원리 같은 걸 공부해보기는 했는데 붕 뜬 지식을 잡으려 손을 뻗는 기분이었다.왜 그런 기분을 느낄까 생각해 보면 답은 하나밖에 나오지 않았다.잘 모르기 때문에.나름대로 정리도 해보고 구현도 해봤는데 왜 잘 모를까.여러 가지 블로그를 기반으로 공부하다 보니까 카프카에 대해서 중구난방으로 공부하게 된 것 같았다.  내가 헷갈렸던 내용은 아래와 같다.BatchListner와 RecordListenerBatchListener를 ‘한 번에 여러 레코드를 처리한다’고 정리된 글을 읽고 BatchListener는 병렬처리를 하는 리스너라고 생각을 했다.하지만 코드를 보다보면 Concurrent… 가 붙은 용어( ex. ConcurrentKa..
[Kafka] Spring Kafka commit (5) 리스너 타입레코드 리스너(MessageListener)단 1개의 레코드 처리스프링 카프카 컨슈머의 기본 리스너 타입배치 리스너(BatchMessageListener)한 번에 여러 개의 레코드 처리 Acknowledging 이 붙은 리스너Manual Commit 을 사용하는 경우 (AcksMode: MANUAL, MANUAL_IMMEDIATE)ConsumerAware 가 붙은 리스너KafkaConsumer 인스턴스에 직접 접근하여 컨트롤하고 싶을 때    RecordListener - Record 인스턴스 단위로 프로세싱Listener생성 메서드 파라미터DescMessageListeneronMessage(ConsumerRecord data)onMessage(V data)오토 커밋 또는 컨슈머 컨테이너의 A..
[Kafka] commit 이해하기 (4) Kafka는 다른 메시지큐와 다른 가장 대표적인 특징을 떠올리면 consumer 가 메시지를 가져가더라도 메시지큐에서 바로 사라지지 않는다는 점이다. 그 덕분에 하나의 로그 메시지를 여러 컨슈머가 다양한 용도로 사용할 수 있다. 이때 문득 고민이 들었다. 메시지큐에서 바로 사라지지 않는다면 메모리는 어떻게 관리되고 있을까, consumer는 자신이 읽은 파티션을 어떻게 구분할까.    Commit깃허브를 다루면서 가장 많이 듣게 되는 용어, commit을 kafka에서도 만나게 된다.깃허브에서 commit 은 add 이후로 깃에 저장하는 단계에서 사용된다.카프카에서 commit 은 메시지 소비 여부를 구분하는 데 사용된다. 컨슈머가 브로커에서 메시지를 poll() 하고 나면 컨슈머 그룹은 카프카에서 불러..
[Kafka] Partition & Replication (3) Kafka 에서 Producer 는 Topic 에 메시지를 보내고 하나의 Topic 은 한개 이상의 Partition 으로 나뉘게 된다.이는 Topic 을 생성하는 시점에 명시할 수 있다.   PartitionTopic 을 분할한 단위Partition 이 여러개일 경우 Producer 가 전송한 메시지 순서는 보장되지 않는다.하지만 Partition 간의 메시지 순서는 보장된다.kafka 메시지에 key를 할당하고, 이 key에 따라 파티션이 선택된다.kafka는 key가 설정되지 않은경우, 메시지는 reound robin 방식으로 파티션을 선택하여 메시지가 전달key가 있다면 key값을 hashing하고 해싱 결과를 이용하여 파티션 선택만약 특정 메시지의 키에 따라 들어온 순서가 중요한 서비스라면, 키..
[Kafka] kafka 내부 구조 (2) 분산 메시징 시스템인 Kafka 의 구조를 들여다보자.      Cluster클러스터는 브로커(Kafka 서버)의 집합체를 말한다. 클러스터를 구분하는 각각의 브로커는 카프카 서버로 불린다.Broker - 메시지 수신 및 저장이벤트 스트리밍 플랫폼밑에서 추가 설명 Topic - 데이터 분류 단위브로커에서 데이터를 관리할 때 기준이 되는 단위다.여러 파티션으로 나뉘어서 데이터를 병렬처리할 수 있다. 리더 파티션 Leader PartitionProducer, Consumer 와 직접 통신하는 파티션읽기, 쓰기 연산팔로워 파티션 Follower Partition데이터 보관리더 파티션에서 전달된 데이터를 복제하여 저장리더 파티션이 속한 브로커에서 장애 발생 시, 팔로워 파티션이 리더 파티션 지위를 가질 수 있다..
[Kafka] 탄생 배경 (1) 전통적인 Database 시스템 구조는 애플리케이션과 DB가 연결된 end-to-end 형태를 띄고 있다. 하지만 간단한 구조에 반해 각각 분리된 Data 파이프 라인이 필요하고 요구사항이 증가함에 따라 더욱 복잡해지는 문제가 생긴다.시스템 복잡도가 증가하면 아래와 같은 문제가 발생한다.중앙화된 데이터 전송 영역의 부재데이터 흐름을 파악하기 어려움복잡한 시스템 관리일부 문제 발생 시 연결된 모든 애플리케이션을 확인end-to-end 형태 시스템은 시스템을 복잡하게 만드는 것에서 나아가 여러 문제를 일으킨다.데이터 일관성을 유지하기가 어려워진다실시간 데이터 처리가 어렵다확장성에 제한이 생긴다.이런 이유들로 인해 링크드인은 DB와 어플리케이션 사이를 중개하는 메시지 브로커, Kafka 를 만들게 된 것이다...
[Java] static, 잘 알고 사용하자. Static클래스 레벨의 변수나 메소드, 블록을 정의할 때 사용된다.인스턴스 생성 없이 접근 가능하며, 모든 인스턴스에서 공유 가능JVM 에서 드러나는 특성메모리의 메소드 영역에 할당Static 변수와 static 메소드는 Static 메모리 영역에 존재프로그램 시작 시 메모리에 할당되고 프로그램 종료될 때까지 유지된다.객체가 생성되기 이전에 이미 할당이 되어 있다.메모리의 메소드 영역에 할당되기 때문이다.주된 사용법모든 인스턴스가 공통적으로 사용해야 하는 값이 존재할 때단점객체지향 프로그래밍 원칙과 상반된다.과도한 static 사용 시 메모리 누수의 원인이 될 수 있다.💡 메모리의 메소드 영역Static 영역을 포함하고 있으며 GC 의 관리 영역 밖에 존재한다.일반적으로 우리가 만든 Class는 St..
Polling, Long Polling, Socket, SSE 웹 어플리케이션은 클라이언트가 서버에 데이터를 요청하는 클라이언트 서버 모델을 중심으로 발전해왔다. 그렇기에 서버가 클라이언트의 요청 없이 독립적으로 데이터를 보내고 받는 매카니즘은 없었다. 하지만 시대는 계속해서 변화하고 다양한 상황에 대응하기 위한 다양한 통신 방법의 필요성이 증가했다. 이에 아래와 같은 네트워크 기술들이 등장하기 시작했다.HTTP의 비연결성 특징을 해결하기 위한 기술Polling, Long Polling, WebSocket, SSEPolling, Long Polling, Socket, SSE 비교하기PollingHTTP Long Polling 기술은 서버가 사용자에게 가능한 빠르게 정보를 전달하는데 사용되는 기술이다. 그러니 서버는 클라이언트가 요청을 보낼 때까지 기다릴 필요가 없어..