요즘에 이벤트소싱이라는 개발 방법을 채택한 프로젝트를 진행하고 있는데, 다음과 같은 공통의 문제 패턴을 툴마다 비슷하게, 그리고 조금씩 다르게 해결하고 있는 모습이 눈에 띄는 것이 아닌가!! (그리고 또, 작년에 만들었던 job dispatcher도 결국은 이런거였구나.. 라는게 이제야 좀 눈에 들어왔다) 하나의 스트림을 여러 인스턴스로 (중복되지 않게, 그러나 처리되지 않는 것도 없게) 잘~ 분배하는 법. (심화 미션: 런타임에 인스턴스 개수가 줄거나 늘어날 수 있답니다.) kafka kinesis (KCL library) axon TEP (tracking event processor) topic stream event stream (event store) 처리해야하는 스트림 partition shar..

LeaseCoordinator 아래 두 작업을 주기적으로 실행하는 스레드. worker랑 1:1...? (예) ShardRecordProcessor-0001에 LeaseCoordinator-0001) - LeaseTaker owner가 없는, 혹은 다른 worker가 오랜 기간 renew하는 데 실패한 lease를 가져감. - LeaseRenewer lease 갱신 (TEP 토큰 reclaim이랑 비슷한 듯) 2023-11-19 14:55:44.104 [LeaseCoordinator-0001] INFO s.a.k.l.dynamodb.DynamoDBLeaseTaker - {} Worker ed8f5dba-03ce-4082-93d4-264518669baa saw 1 total leases, 1 availab..

Rebalancing 카프카 파티션을 consumer 인스턴스에 고르게 재분배하는 과정! 크게 2-step으로 이루어짐. (1) group management (membership) - active 컨슈머 인스턴스 리스트업 (2) resource assignment - 파티션 분배해주기 그리고 각 스텝의 책임자가 다름. (1) coordinator (broker 중 하나) - heartbeat 받고, 리밸런싱 트리거하는 주체 (파티션이나 컨슈머에 변경 감지하면) (2) group leader (consumer 중 하나) - 일반적으로 가장 먼저 조인한 consumer가 리더가 됨. partition assignment strategy 정하고 수행하는거 담당. cf) 그럼 controller는 뭔가?? z..

📖 Real MySQL 책 내용 발췌... 스트리밍 방식 서버 쪽에서 처리해야 할 데이터가 얼마나 될지에 관계없이 조건에 일치하는 레코드가 검색될 때마다 바로바로 클라이언트로 전송해주는 방식. 클라는 쿼리 요청 후 곧바로 첫번째 레코드를 전달 받음. 마지막 레코드를 받는 시점은 알 수 없음. 클라이언트는 바로 데이터 가공 시작할 수 있음. 레코드 수에 상관 없이 빠른 응답 시간 보장 가능. 💡 클라이언트 도구, API에 따라 스트리밍 처리 방식이 다를 수 있음 JDBC => mysql 서버는 레코드를 읽자마자 클라이언트로 그 결과를 전달할 것이지만, JDBC가 mysql 서버로부터 받는 레코드를 일단 자체적인 버퍼에 모두 담아 두고, 마지막 레코드가 전달되면 그 때서야 비로소 클라이언트 어플리케이션에 반..

yield 키워드 지난 yield 와 generator에 대한 글에서 제너레이터를 2가지 관점으로 바라봤었는데 1) 반복적으로 실행 flow를 pause, resume할 수 있는 경량(유저레벨) 스레드 같은 것. => cpu 스케줄 타임을 점유하는 문제와 관련되어 있다. => 코루틴 (일반적인 언어들) / Fiber (루비) 으로 연결된다. 2) 호출할 때마다 값을 하나씩 produce 함 (next로 호출, yield문을 만나면 caller에게 값을 돌려주고 멈춘다.) => memory를 효율적으로 사용하는 문제와 관련되어 있다. => 연산전에 모든 element를 메모리에 올릴 것인가? (전통적인 배열 같이) 아님 lazy하게 필요할 때 하나씩 갈 것인가? => stream processing 개념으..

iterator 패턴 자료구조 (list, tree, stack..)를 노출하지 않고 추상화시켜서 collection의 요소를 traverse하는 패턴. 메인 아이디어 collection의 traverse behavior를 iterator라는 분리된 객체로 뽑아내기 iterator 객체에 traverse 알고리즘을 구현해두고, 외부에서는 그 디테일을 알 수 없도록 은닉한다. 여러 iterator를 사용하면, 같은 collection을 동시에 독립적으로 탐색할 수도 있다. 모든 iterator는 같은 인터페이스를 구현해서, client code가 어떤 자료구조의 collection이든, 어떤 traverse 알고리즘이든 호환 가능하게 만들어져야 한다. 보통 더이상 element가 없을 때까지 (traver..