Lewis's Tech Keep

java 21 로 버전업하면서 Spring kafka consumer도 virtual threads 로 사용하고 싶었기에 ListenerContainerFactory 빈을 등록할 때 링크 를 참고해서 AsyncTaskExecutor와 virtualThread 옵션을 활성화 시켜봤다.그러나 운영 배포 후 rebalancing 이 계속 발생하면서 파드가 떨어지기 시작했다.왜 그런가 했더니 설정 시 asyncTaskExecutor.setConcurrencyLimit(SimpleAsyncTaskExecutor.UNBOUNDED_CONCURRENCY);아래와 같이 TaskExecutor ConcurrenyLimit 정책을 UNBOUNDED_CONCURRENCY로 가져갔더니 쓰레드를 무한히 생성하였고 이로 인하여..

Spring Hibernate Envers 사용 시 아무것도 설정하지 않고 사용 시 revisionId와 revision timestamp를 저장하는 revinfo라는 테이블이 있는데, 해당 테이블의 revisionId 값은 integer로 저장된다.Dev 환경이라면 괜찮지만 Production 환경에서 Envers를 사용하고 있고 자주 기록하는 서버라면 Integer MAX값인 21억을 넘는 것은 현실이 될 수도 있다.이런 경우 테이블이 이미 생성되어 있는 경우 마이그레이션과 함께아래와 같이 CustomRevisionEntity를 준비해서 변경해주는 것이 좋다.-- table seq type 변경ALTER TABLE revinfo ALTER COLUMN rev TYPE BIGINT USING rev::..

배경설명어느 날이었다.저녁 시간 대 쯤 갑자기 모니터링 보드에서 급격한 hps 증가를 보았다.예제 그림너무 급격하게 오른 요청 수로 인하여 요청들이 쓰레드를 모두 차지하여 혼잡 상태에 들어가게 되고,이로 인해 파드가 무한 재시작하는 상황이 발생했다.판단증가 폭이 빨라도 너무 빨랐다.재배포나 일반적 플로우에서의 일시적 혼잡 상태라면 어느정도 피크를 달성한 이후에 정상화되어야 하고 유저의 일반적 재요청일 경우의 그래프라고 하기 어려울 만큼 해당 그래프는 급격한 증가세에 있었다.진행이로 인하여 플로우 상 진행되지 않는 서버가 존재하자 비즈니스적 타격을 받게 되었다.기존에 RateLimiter가 존재했지만 해당 RateLimiter는 결국 어플리케이션 레벨에 있는 라이브러리였기 때문에 쓰레드 워커가 일을 할 수..

진행 범위 3.5 카프카 스트림즈 카프카를 사용하는 다른 팀 발표 사례 소개 우아한 형제들 https://www.youtube.com/watch?v=DY3sUeGu74M https://www.youtube.com/watch?v=YACC1t_oSlA 카카오 https://www.youtube.com/watch?v=7_VdIFH6M6Q 3.5 카프카 스트림즈 스트림즈 애플리케이션 토픽에 적재된 데이터를 상태기반 또는 비상태기반으로 실시간 변환하여 다른 토픽에 적재하는 라이브러리 공식 지원 라이브러리 ⇒ 카프카 클러스터와 완벽하게 호환되면서 스트림 처리에 필요한 편리 기능 제공함 정확히 한번(exactly once) 할 수 있도록 장애 허용 시스템(fault tolerant system)을 가지고 있어 데이터..

카프카 시작해보기 대부분의 것은 책을 참조하길 바람. 기억하고 싶은 것 위주로 넣었음 주키퍼, 카프카 브로커 실행 카프카 바이너리 패키지를 다운로드 (링크: https://kafka.apache.org/downloads) 카프카 브로커 힙 메모리 설정 카프카 브로커를 실행하기 위해 힙 메모리 설정이 필요함 브로커는 레코드의 내용은 페이지 캐시로 시스템 메모리를 사용하고 나머지 객체들을 힙 메모리에 저장하여 사용 힙 메모리는 5GB 이상으로 설정하지 않음 카프카 패키지 기본 설정으로 브로커 1GB, 주키퍼 512MB로 설정되어있음 KAFKA_HEAP_OPTS 를 exports하여 사용하면 힙 메모리 조정 가능 export KAFKA_HEAP_OPTS ="-Xmx400m -Xms400m" 브로커 메모리를 4..

카프카의 탄생 파편화된 데이터 수집 및 분배 아키텍처 운영을 위해 탄생함 기존 카프카 도입 이전 데이터를 생성하고 적재하기 위해 데이터를 생성하는 소스 애플리케이션과 데이터가 최종 적재되는 타깃 애플리케이션을 연결해야 함 아키텍처가 거대해짐 -> 소스 애플리케이션과 타깃 애플리케이션 개수가 점점 많아짐, 데이터를 전송하는 라인이 기하급수적으로 복잡해지기 시작함 파이프라인 개수가 많아지면서 소스코드 및 버전 관리에서 이슈가 생김 타깃 애플리케이션 장애 -> 소스 애플리케이션으로 바로 전달됨 기존에 링크드인은 오픈소스와 ETL 툴을 적용해 변경하려고 노력했지만 해결은 못함 기존 카프카 도입 이후 각각 애플리케이션끼리 연결해 데이터 처리하지 않고 한 곳에 모아 처리하도록 중앙집중화함 소스 애플리케이션과 타깃 ..

CAP 이론은 분산 데이터베이스 설계 시에 많이 찾아보게 되는 것 같다. 그 중 가장 자세히 설명하고 있다고 생각한 글 링크를 달아본다. https://hamait.tistory.com/197 [DB/분산] 초보자를 위한 CAP 이론 * CAP 은 네트워크로 분산된 DB , FileSystem, state machine (zookeeper 같은) 에서 의미를 가짐. 여담 ) NoSQL 이란게 유비쿼터스,클라우드,빅데이터 같은 상품명 처럼 휩쓸고 지나간 자리에는 더 이상 NoSQL 이 hamait.tistory.com 특히 논란 부분이 재밌다고 생각했는데 많이 보질 못해서 다 보고 난 이후에 정리하려고 생각 중이다. 기초 설명 중에 재밌는 링크 https://osy0907.tistory.com/95 NoS..

서론 객체 지향적 및 테스트 코드 기반 개발을 시도 해 보자! 라는 목적으로 현재 진행하고 있는 사이드 프로젝트가 있다. 이를 적용하며 겪은, 아직 모자란 지식으로 겪는 이슈에 대해 적어보고 해결됐을 때의 방법 또한 양식이 되지 않을까 하여 기록한다. 본론 1. JPA를 사용하였을 때 불변성을 유지하기 힘든 점에 대한 고민 https://lewisseo91.tistory.com/156 [JPA] 엔티티가 final이 될 수 없는 것에 대하여 JPA를 하면서 좀 불만아닌 불만이랄까... 불변성 보장을 하고 싶은데 final을 쓸 수 없는 모순에 자꾸 부딪히게 된다.. (참고 링크) 일단 왜 final을 이용해 불변 객체로 만들고 싶은가 하면 특히 진행 lewisseo91.tistory.com 나는 대체적으..