IT LAB

백은빈, 이성욱 님의 "Real MySQL" 책을 정리한 포스팅 입니다. 6. InnoDB Buffer Pool디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해두는 공간 버퍼링쓰기 작업을 메모리에 먼저 저장 후, 일괄 처리로 디스크에 기록 시스템 변수변수명설명innodb_buffer_pool_size버퍼 풀 전체 사이즈를 설정함. (동적으로 조정 가능)innodb_buffer_pool_instances버퍼 풀을 여러 인스턴스로 나누어 병렬 처리- 기본 8개 (버퍼 크기가 1GB 이하면 1개만 사용) 구성 요소페이지InnoDB가 디스크에서 데이터를 읽거나 메모리에 저장할 때 사용하는 기본 단위(블록)하나의 페이지 안에는 여러 개의 레코드(행) 또는 인덱스 정보가 들어갈 수 있음기본값은 16KB..

1. Pub/Sub메시지를 채널을 통해 발행자와 구독자가 느슨하게 연결하는 구조발행자는 단순히 메시지를 채널에 발행구독자는 관심 있는 채널을 구독하여 해당 메시지를 수신서로 존재를 몰라도 메시지 통신이 가능하여 확장성과 유연성이 높음 2. 메시지형식message: [message, 채널명, 메시지 내용]pmessage: [pmessage, 패턴, 채널명, 메시지 내용] 특징메시지는 최대 한번만 전송됨일반적인 key-value 공간과는 무관함 (db 상관 없음)수신 실패 시 재전송 없음 (내구성이 필요한 경우 Redis Streams를 고려할 것) 3. 명령어더보기SUBSCRIBE ch1 ch2PSUBSCRIBE patternUNSUBSCRIBE chPUNSUBSCRIBE patternPUBLISH ch ..

1. Data modelPrometheus는 모든 데이터를 time series 형태로 저장함메트릭 이름 + 라벨로 고유한 시계열 데이터를 만들어냄항목설명예시Metric Name측정 대상의 기능/특징을 설명하는 이름http_requests_total (총 HTTP 요청 수)Label같은 메트릭의 상태를 구분하기 위한 key-valuemethod="POST", handler="/api/tracks"Notation메트릭 이름과 라벨을 함께 사용하는 표기 형식http_requests_total{method="POST", handler="/api/tracks"}Sample하나의 값(value) + 시간(timestamp)0.56 at 2024-05-31T12:00:00Z 2. Metric TypePromethe..

1. OverviewPrometheus란?오픈소스 (CNCF 공식 프로젝트)시스템 모니터링 & 알림 툴킷애플리케이션을 time series로 수집하고 저장함 주요 기능기능설명다차원 데이터 모델Label로 시계열 데이터 구분 (metrics + key-value)PromQL강력하고 유연한 쿼리 언어 (시계열 데이터 분석용)자율 동작단일 서버만으로 동작 (분산 스토리지 불필요)Pull 기반 수집HTTP로 타겟에 접근해 메트릭을 수집 (스크래핑)Push 지원짧은 작업(job)의 메트릭도 수집 가능 (Push Gateway 활용)서비스 디스커버리/정적 설정자동화 or 수동 설정 지원시각화 도구 연동 가능Grafana 등과 연동하여 대시보드 생성 및 시각화 지원 Metrics란?숫자 기반 지표숫자 데이터를 시간별..

3. Developer Guide항목명간단 설명Writing a Streams Application스트림 처리 로직을 작성하고 실행하는 기본 구조 제공 (토폴로지 정의)Configuring a Streams Application설정 지정 (브로커 주소, 앱 ID, 직렬화 방식 등)Streams DSL고수준 연산을 위한 간편 API (map, filter 등)Processor API사용자 정의 처리 로직을 위한 저수준 APINaming OperatorsDSL 연산자에 이름 붙이기 (디버깅/모니터링 용이)Data Types & Serialization메시지 직렬화/역직렬화 방식 정의TestingTopologyTestDriver로 로컬 테스트 가능Interactive Queries상태 저장소 데이터를 외부에서..

1. Basics주요 구성 요소구성 요소설명예시StreamsBuilder스트림 처리 로직을 정의하는 객체 생성KStream, KTable 등KafkaStreams스트림들을 실제로 실행하는 객체- kafka 클러스터와 연결- 스트림 처리 시작 (토폴로지 실행)- 스트림 처리 종료- KStream연속된 이벤트 스트림 - insert (append-only 로그 형식)카드 결제 기록, 서버 로그 등- KTable상태 변경 기록- update집계 테이블 등 동작 흐름StreamsBuilder: Stream 처리 로직 정의StreamsConfig: 설정 (Kafka 클러스터 정보, 기본 직렬화/역직렬화 설정, 보안 설정 등)KafkaStreams: 스트림 처리 시작KafkaStreams: 스트림 처리 종료 2. ..

1. Exactly Once Semantics읽기 → 처리 → 쓰기 과정이 정확히 한 번만 실행되는 것을 보장 2. 처리 흐름컨슈머KafkaAwareTransactionManager를 리스너 컨테이너에 설정하면, 리스너 호출 전에 트랜잭션을 시작합니다.리스너 내부에서 수행하는 KafkaTemplate 작업들은 트랜잭션에 참여합니다.리스너가 정상적으로 처리하면,producer.sendOffsetsToTransaction()를 호출해서 컨슈머 오프셋을 트랜잭션에 포함시킵니다.이후 트랜잭션을 커밋합니다.리스너에서 예외가 발생하면,트랜잭션을 롤백하고,컨슈머는 오프셋을 다시 설정해서, 실패한 레코드를 다음 poll() 때 다시 읽어 재처리합니다 3. 셋팅spring: kafka: producer: ..

1. 트랜잭션 활성화 방법DefaultKafkaProducerFactory의 transactionIdPrefix 설정트랜잭션이 활성화됨트랜잭션 전용 Producer 캐시를 유지함각 프로듀서의 transactional.id는 transactionIdPrefix + 번호(n) 형식으로 생성됨spring boot는 spring.kafka.producer.transaction-id-prefix 만 설정하면 됨 2. KafkaTransactionManagerSpring의 PlatformTransactionManager를 구현한 클래스Spring 트랜잭션 지원 방식과 함께 사용이 가능함 (@Transactional, TransactionTemplate 등)KafkaTemplate의 모든 작업은 트랜잭션 범위 안에서..

1. 컨슈머 오프셋 관리오프셋컨슈머가 읽은 메시지 위치를 나타내는 번호다음에 어디부터 읽을지 알 수 있음 __consumer_offest 토픽항목설명역할각 컨슈머 그룹이 어떤 파티션의 몇 번째 메시지까지 읽었는지 기록함포맷key: (group.id, topic, partition), value: offset파티션 수 조정offsets.topic.num.partitions (기본: 50)복제 수 조정offsets.topic.replication.factor (기본: 3 추천) 기본 동작컨슈머지정된 토픽의 메시지를 읽음읽은 메시지의 오프셋 정보를 __consumer_offest에 기록컨슈머 그룹컨슈머들의 오프셋 추적장애 시, 지정된 오프셋을 통해 복구 2. 그룹 코디네이터그룹 코디네이터컨슈머 그룹의 구성,..

1. 파티셔너프로듀서가 메시지를 어느 파티션에 보낼지 결정하는 컴포넌트기본적으로 키 값을 해싱하여 파티션을 결정함하지만 키가 없으면 전략에 따라 파티션이 선택됨 주의사항동적으로 파티션이 증가할 경우, 기존의 키와 파티션의 매핑이 일치하지 않을 수 있음되도록이면 파티션 수를 변경하지 않는것이 권장됨 전략구분라운드 로빈 전략스티키 파티셔닝 전략전송 방식순차적으로 여러 파티션에 균등 분배하나의 파티션에 몰아서 일정량의 레코드를 채운 뒤 전송장점데이터가 파티션에 고르게 분산됨배치 전송이 빠르고 효율이 높음단점파티션별로 데이터가 얇게 퍼져 버퍼가 빨리 안 채워짐 파티션 간 데이터 분포가 고르지 않을 수 있음배치 효율낮음 (파티션별 최소 레코드 수 미달로 대기 → 비효율)높음 (한 파티션에 집중해 빠르게 배치 전송..