코딩공장공장장

프로젝트 공유spring boot 환경에서 sharding-sphere를 적용하는데 버전 이슈 등으로 연동이 잘 안되는 문제가 있어,gradle 파일 등 전문을 공유하겠다. [build.gradle.kts]plugins { kotlin("jvm") version "1.9.25" kotlin("plugin.spring") version "1.9.25" id("org.springframework.boot") version "3.5.6" id("io.spring.dependency-management") version "1.1.7" kotlin("plugin.jpa") version "1.9.25"}group = "org.example"version = "0.0.1-SNAPSHOT"..

샤딩이란데이터를 여러 서버에 분산 저장하는 기술이다.서버를 여러개 두어 scale-out하는 기법으로 단일 DB의 서버의 용량과 성능의 한계를 극복할 수 있는 기법이다. 샤딩의 장점성능 향상여러 DB 인스턴스에 데이터를 나누고 각 데이터가 존재하는 DB에서 연산을 수행하므로부하와 데이터가 분산되어 쿼리 성능 향상을 이룰 수 있다.장애 격리샤드 단위 백업 및 복구샤딩의 단점일괄성 유지 어려움- 분산 트랜잭션 처리 및 데이터 동기화에 대한 관리 필요- auto_increment 충돌 (충돌 방지 미들웨어 사용해야함, sharding-sphere)복잡성 증가조인 연산이나 복잡한 쿼리는 샤딩 이전 환경의 쿼리보다 느리고 에러 발생 빈도가 높아질 수 있다.샤드 불균형 발생 가능샤딩은 스케일업으로 DB 스펙이 한계..

파티셔닝(Partitioning)파티셔닝은 논리적인 하나의 테이블을 여러개의 물리적인 파티션으로 나누어 저장/관리하는 기법이다.이때, 파티션을 나누는 기준을 파티션 키 칼럼이라고 한다.mysql 파티션은 파티션 단위로 테이블과 인덱스가 모두 분리되기에 파티션 키 설정이 매우 중요하다.자주 사용되는 키가 아니라면 인덱스 조회시 모든 파티션 탐색을 수행할 수 있기에파티션 키는 가급적 자주 사용되는 조건이어야한다. 파티션이 필요한 이유하나의 테이블에 너무 많은 레코드가 쌓이는 경우,스캔 범위가 넓어지는 것 뿐만 아니라 레코드나 인덱스를 메모리에 올리지 못하여 디스크 접근을 유발하여 더더욱 성능 저하를 유발할 수 있다.이때, 하나의 테이블을 물리적으로 여러 파티션으로 나누게 되면 파티션 단위 접근과 파티션 단위..

RDB의 부하를 줄이는 방법단일 DB 내에서 최적화쿼리 최적화인덱스 추가CQRS파티션스케일업분산 DB를 통한 부하 분산복제캐싱 DB 별도 사용(redis)DB MSA샤딩서비스가 지속되고 사용자와 트래픽이 증가하게 되면 DB의 부하가 증가할 수 있다.이때 가장 고려해볼만한 옵션은 쿼리 최적화나 인덱스 추가, CQRS 패턴 같은 것들이 있다.이는 단일 DB 내에서 CPU, 메모리, IO 자원을 효율적으로 사용하기 위해 고려하는 옵션이다. 단일 DB는 컴퓨터의 용량과 스펙이라는 한계가 존재하기 때문에,쿼리 최적화, 인덱스, CQRS 패턴으로는 한계에 직면할 수 있다. 이때, 고려해볼 수 있는 옵션이 레플리케이션(복제)이다.복제는 RDB에서 제공해주는 옵션으로 쉽게 적용 가능하고 데이터의 신뢰성 측면에서도 안정..

애플리케이션 정보스프링 부트 3.2.xmysql 8.0로컬 pc 환경cpu - 16 core메모리 32GB부하 테스트 조건동시 접속자 100명반복 100회위와 같은 환경에서 부하테스틑 진행해보았다.테스트한 api는 GET 요청으로 내부 로직은 select만 존재하며 100건의 게시글을 조회하는 api이다. 애플리케이션 지표cpu 가장 먼저 cpu 지표를 보면 시스템 cpu 사용량은 99%이지만,애플리케이션의 cpu 사용량은 6% 정도이다.로컬에서 테스트를 하다보니 크롬, mysql, 도커 등 여러 프레스를 실행중이라 애플리케이션의 cpu 사용량은 높지 않았다.정확한 테스트를 수행하기 위해서는 별도의 서버 인스턴스에 애플리케이션만 구동하여 테스트 해야한다. 메모리 메모리 사용량을 보면 old 영역의 지표..

Topic 설정Topic 설정은 kafka-UI를 통해 설정하였다. partition을 3으로 설정하여 해당 토픽의 메시지를 3개 단위로 나누어 병렬처리가 될 수 있도록 하였다.(Consumer 설정에서 해당 Topic을 처리하는 Consumer Group의 Consumer를 3개로 해야함, 뒤에서 설명) replica.factor는 3으로 설정하여 각 파티션이 3개의 브로커에 복제되도록 하였고,min.insync.replicas를 2로 설정하여 최소 2개의 브로커에 각 파티션이 복제되면 메시지 전송이 성공하도록 하였다. 이 조건을 만족할 경우에만 다음 메시지 처리가 가능하도록 설정하였다.[잠깐] min.insync.replicasmin.insync.replicas는 Kafka 파티션이 메시지를 정상적으..

ConsumerConsumer는 Kafka Topic에서 메시지를 읽어오는 주체이다.Consumer는 반드시 Consumer Group에 속해 있다.토픽에 쓰여진 메시지를 Pull 방식으로 가져옴Partition의 데이터는 동일 Consumer Group 내에서 단 하나의 Consumer만 읽을 수 있음(Consumer Group 내에서 offset을 공유함)Consumer Group 이 다르면 Partition의 데이터를 여러 Consumer가 읽을 수 있음-> 하나의 메시지에 다양한 처리 진행 가능한 Consumer는 여러 Partition을 담당할 수 있음 Consumer Offset 관리Kafka 컨슈머가 어디까지 메시지를 읽었는지 추적하고, 장애 복구나 재시작 시 중복 처리 없이 메시지를 이어..

Kafka Producer는 Broker에 메시지를 발행(Publish)하는 클라이언트이다.Producer의 메시지 발행 방식메시지 생성ProducerRecord로 메시지 구성(key, value, topic, optional partition) 지정파티셔너가 파티션 결정파티셔너는 클라이언트에 존재명시된 파티션이 있으면 그대로 사용없다면 key가 있을 경우 → key.hashCode() % partition 수key도 없으면 → round-robin 방식배치 처리 (Batch Accumulator)같은 파티션의 메시지는 batch 단위로 묶음설정에 따라 linger.ms, batch.size 조건 만족 시 전송목적: latency 줄이고 throughput 증가브로커 전송 (send)네트워크를 통해 파티..