| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Java
- thread
- 이스티오
- Real MySQL
- 쿠버네티스
- JPA
- 보조스트림
- K8s
- 백준
- mysql
- 토비의 스프링
- Stream
- 토비의 스프링 정리
- MSA
- IntellJ
- SpringBoot
- redis
- Collection
- OS
- spring
- GC
- list
- 자바 ORM 표준 JPA 프로그래밍
- Kotlin
- 자바
- Stack
- 스트림
- gradle
- 스프링
- jvm
- Today
- Total
목록전체 글 (155)
인생을 코딩하다.
목차1. 배경2. 테스트 환경3. 테스트 결과4. 마치며..1. 배경최근 차세대 마이그레이션을 진행하는 업무를 맡아 수행하게 되었습니다. 이번 마이그레이션에서는 지금까지의 JDK 버전 흐름과 지원 현황을 종합적으로 검토한 결과, 여러 기술적·운영상의 이유로 JDK 25를 도입하는 것이 가장 적합하다고 판단하여 이를 채택하였습니다. JDK 21부터 정식으로 도입된 Virtual Thread는 동기식 코드 스타일을 유지하면서도 JVM 경량 스레드를 사용하여 적은 리소스로도 높은 동시성을 효율적으로 처리할 수 있는 실행 모델을 제공합니다. 저는 이러한 특징들로 인해 Virtual Thread를 적극적으로 도입하여 아래와 같은 장점들을 경험할 수 있었습니다.Spring MVC 기반 동기·블로킹 서버의 스레드 풀..
목차1. 실험을 하게 된 배경2. 왜 JMH를 사용했는가3. 테스트 환경4. 결과 및 요약 해석5. 정리6. 왜 Jackson3이 더 빠를까?1. 실험을 하게 된 배경최근 차세대 마이그레이션을 진행하는 업무를 맡아 수행하게 되었습니다. 이번 마이그레이션에서는 지금까지의 JDK 버전 흐름과 지원 현황을 종합적으로 검토한 결과, 여러 기술적·운영상의 이유로 JDK 25를 도입하는 것이 가장 적합하다고 판단하여 이를 채택하였습니다. JDK 25의 주요 변화 중 하나는 Jackson 메이저 버전이 Jackson 2에서 Jackson 3으로 전환되었다는 점입니다. Jackson 3로의 전환 배경과 상세한 변경 사항에 대해서는 아래의 공식 문서와 커뮤니티 자료에 잘 정리되어 있어, 본 글에서는 해당 내용을 깊게 다..
안녕하세요. 이전에 파티션 증가 없이 동시 처리량을 늘리기 위해 Parallel Consumer에 관해 살펴보고 PoC를 진행해보았습니다. 파티션이 증가하게 되면 아래와 같은 문제들이 발생합니다 브로커 파일 시스템 리소스 증가장애에 더 취약한 구조복제 비용 증가저는 이러한 문제들을 해결하기 위해 파티션 증가 없이 동시 처리량을 늘려보고자 하였고 이에 대한 글도 작성하였습니다. 저는 기존 카프카에서 파티션이 증가할 수록 브로커 파일 시스템 리소스가 증가할 것이라고 생각했습니다. 왜냐하면 동시 처리량을 늘리기 위해서는 파티션과 컨슈머를 늘려야합니다. 컨슈머 수가 늘어난 만큼 오프셋 커밋도 늘어나서 comit_offset log file에 기록되는 리소스 또한 증가할 것이라고 생각했기 떄문입니다.오프셋 커밋은..
보통 Kafka 사용 시 처리량을 늘리기 위해 컨슈머와 파티션 수를 늘린 후 병렬처리를 통해 처리량을 증가시킵니다. 하지만 저는 처리량을 늘릴 때마다 파티션을 추가하는 것이 최선인지에 대한 의문을 가지고 있었습니다. 파티션을 늘리는 대신, 한 파티션에서 단일 메시지가 아니라 여러 개의 메시지를 가져와 병렬 처리하면, 파티션 개수를 증가시키지 않고도 성능을 높일 수 있지 않을까 하는 고민을 해왔습니다. 이러한 고민을 하게 된 이유는 아래와 같습니다. 인프라 비용 증가 파티션이 많아질수록 추가적인 브로커가 필요할 가능성이 높아지고 브로커 노드 수 증가에 따른 서버 비용, 네트워크 비용 등이 상승할 수 있습니다. 브로커 파일 시스템 리소스 사용량 증가 Kafka 브로커는 각 ..
카프카를 사용시 consume이 단 한 번만 일어나면 좋겠지만 실제로 그렇지 않은 경우가 종종 있습니다. consume이 딱 한 번만 일어나지 않으면 어떤 문제가 발생할까요? consumer가 카프카 브로커로부터 메시지를 가져와서 데이터 처리를 할 텐데, 만일 중복 consume이 발생하면 그 데이터 처리도 중복으로 처리될 수 있습니다. 때로는 consume 누락이 발생할 수도 있습니다. 그럼 데이터 처리도 누락됩니다. 이 문제를 막기 어려운 근본적인 이유는 아래와 같습니다. commit 시점과 데이터 처리 완료 시점이 완벽하게 일치할 수 없는 경우(그 시간 간극 동안 리밸런싱이 발생할 수도 있음) offset 관리가 consumer측이 아니라 broker 측에서 이루어지는 경우(_consumer_off..
컨트랙트 바운디드 컨텍스트 모델은 서로 독립적으로 발전하고 구현될 수 있다. 그러나 바운디드 컨텍스트 자체는 독립적이지 않고 서로 상호작용 해야한다. 결국, 바운디드 컨텍스트 사이에는 항상 접점이 있는데 이것을 컨트랙트라 고 부른다. 왜 상호작용 해야하는데? 비즈니스 프로세스 흐름: 예를 들어, 주문이 생성되고 처리되는 과정에서 고객 관리, 재고 관리, 결제 시스템 등 여러 컨텍스트 간의 상호작용이 필요할 수 있음 데이터 공유: 서로 다른 컨텍스트 간에는 종종 데이터를 공유해야함. 예를 들어, 고객 정보를 처리하는 서비스는 주문 처리 시스템과 고객 정보를 공유해야 할 수 있음. 업무 통합: 여러 바운디드 컨텍스트 간의 상호작용은 업무 통합을 가능하게. 서로 다른 컨텍스트 간에 정보를 교환하고 업무를 조율..
reWriteBatchedInserts은 MySql 전용 옵션입니다. 사실 PostgreSql에서도 동일하게 사용되는 것으로 착각하고 있었으나 PostgreSql에서는 reWriteBatchedInserts가 아닌 rewriteBatchedStatements 사용하는게 맞습니다. mySql postgreSql reWriteBatchedInserts rewriteBatchedStatements 그럼 reWriteBatchedInserts, rewriteBatchedStatements은 무엇일까요? - 주말에 작성하기
ColpletableFuture 2014년에 발표된 java8에소 처음 도입 비동기 프로그래밍 지원 Lambda, Metho reference 등 java 8의 새로운 기능 지원 Method reference :: 연산자를 이용해서 함수에 대한 참조를 간결하게 표현 method reference statuc method reference instance method reference constructor method reference ColpletableFuture 클래스 CompletableFuture Future CompletionStage 비동기적인 작업을 수행 비동기적인 작업을 수행 해당 작업이 오한료되면 결과를 반환하는 인터페이스 해당 작업이 완료되면 결과를 처리하거나 다른 CmpletionSt..