목표 인덱스 mapping 정보에서 properties와 fields의 차이점을 이해한다. properties 서브 필드를 가지고 있는 object와 nested 타입 매핑에서 사용된다. 새로운 속성을 추가하기 위해서 사용한다. fields 같은 필드를 다른 목적으로 사용한다는 의미다. 예를 들어, string 타입의 필드를 full-text search를 위한 text 필드와 정렬을 위한 keyword로 매핑할 때 사용할 수 있다. 참고 자료 https://www.elastic.co/guide/en/elasticsearch/reference/current/properties.html https://www.elastic.co/guide/en/elasticsearch/reference/current/multi-fields.html

목표 Pattern tokenizer 의 사용법을 이해한다. 사용법 정규식을 이용해서 토크나이징 할 때 사용한다. 패턴을 입력하지 않으면 기본값으로 \W+를 사용한다. 예시 아래와 같이 커스텀 토크나이저를 등록해서 사용할 수 있다. PUT my-index-000001 { "settings": { "analysis": { "analyzer": { "my_analyzer": { "tokenizer": "my_tokenizer" } }, "tokenizer": { "my_tokenizer": { "type": "pattern", "pattern": "," } } } } } POST my-index-000001/_analyze { "analyzer": "my_analyzer", "text": "comma,separated,values" } [ comma, separated, values ] 참고 자료 https://www....

스트림 처리란 무엇인가? 데이터 스트림(이벤트 스트림, 스트리밍 데이터)이란 무한히 늘어나는 데이터세트를 추상한 것이다. 무한이라 함은 끝없이 계속해서 늘어난다는 의미이다. 시간이 흐름에 따라 새로운 레코드가계속해서 추가되기 때문에 데이터세트가 무한해지는 것이다. 데이터 스트림의 또 다른 특성 이벤트 스트림에는 순서가 있다. 데이터 레코드는 불변이다. 이벤트 스트림은 재생이 가능하다. 스트림 처리: 하나 이상의 이벤트 스트림을 계속해서 처리하는 것 스트림 처리는 요청-응답과 배치 처리와 마찬가지로 프로그래밍 패러다임 중 하나다. 요청-응답: 응답 시간이 1밀리초 미만~몇 밀리초 수준인 패러다임으로, 가장 지연이 적은 패러다임이다....

지표 기초 자바 애플리케이션 모니터링의 기본적인 사항들과 모니터링, 경보 설정의 모범사례를 살펴보도록 하자. 지표는 어디에 있는가? 모든 지표의 출처가 카프카인 것은 아니다. 지푯값은 출처에 따라 다섯 종류로 나눌 수 있다. 애플리케이션 지표: 카프카 그 자체의 JMX 인터페이스에서 나온 지표 로그: 카프카 자체에서 나온 또 다른 타입의 모니터링 데이터. 숫자가 아니라 텍스트 내지 구조화된 데이터이기 때문에 추가 처리를 좀 더 해야 한다. 인프라스크럭처 지표: 카프카의 앞단, 요청이 들어오는 길목에 설치되어 있으며 내가 제어할 수 있는 시스템에서 발생하는 지표(예: 로드 밸런서) 특수 클라이언트 지표: 카프카 외부의 툴에서 나온 데이터....

토픽 작업 토픽 작업을 쉽게할 수 있는 툴은 kafka-topics.sh이다. 역할: 클러스터 내 토픽 생성, 변경, 삭제, 정보 조회 토픽 설정 변경은 kafka-topics.sh에서는 지원 중단 되었으니, 더 강력한 툴인 kafka-configs.sh를 사용하는 것이 좋다. kafka-topics.sh를 사용하려면 --bootstrap-server 옵션에 연결 문자열과 포트를 넣어 줘야한다. 이 장 전체에 걸쳐 모든 툴이 저장된 위치는 /usr/local/kafka/bin/ 디렉토리다. 새 토픽 생성하기 --create 명령을 사용해서 새로운 토픽을 생성할 수 있다. 생성할 떄는 3개의 필 수 인수가 있다. --topic: 생성하려는 토픽의 이름 --replication-factor: 클러스터 안에 유지되어야 할 레플리카의 개수 --partitions: 토픽에서 생성할 파티션의 개수 토픽 이름 짓기 토픽 이름에는 영문, 숫자, _, -, ....

inverted index란 문서에 포함된 문자열을 어떤 기준으로 단어로 나누는데 이렇게 나뉜 단어들을 토큰이라고 부른다. 이렇게 토큰을 만들어내는 과정을 토크나이징이라고 부른다. 토큰을 기준으로 저장된 문서를 아래와 같이 저장하는데 이것을 inverted index라고 부른다. analyzer 종류 마다 토크나이징 결과가 달라진다. analyzer 살펴보기 analyzer를 구성할 때는 tokenizer를 필수로 명시해야 하며 하나의 tokenizer만 설정할 수 있다. character filter와 token filter는 필요하지 않은 경우 기술하지 않거나 여러 개를 기술할 수 있다. character filter: analyzer로 들어온 문자열을 변형한다....

목표 Spring 애플리케이션의 로그를 남기기 위해 ELK를 구축한다. Spring MVC의 액세스 로그도 ELK에 남기도록 구현한다. ELK란? Elasticsearch, Logstash, Kibana의 약자 Elasticsearch: 검색 및 분석 엔진용 분산 시스템 Logstash: 여러 source로부터 데이터를 수집하고 가공하는 데이터 처리 파이프라인 Kibana: Elasticsearch 데이터 시각화 도구 ELK 작동 방식 Logstash가 다양한 서버, 애플리케이션, 시스템 등에서 생성되는 로그나 데이터를 수집한다. Logstash가 수집된 원본 데이터를 파싱하고, 필드를 추가하거나 불필요한 부분을 제거하여 분석에 용이한 형태로 가공한다. 가공된 데이터는 Elasticsearch에 인덱싱되어 저장된다....

하나 이상의 카프카 클러스터로 구성되는 아키텍처가 필요한 경우가 있다. 여러 개의 별도 클러스터를 운영하는 것은 단일 클러스터를 여러 개 운영하는 것과 같다. 하지만, 클러스터 사이에 데이터를 지속적으로 복사해 줘야 하는 경우도 있다. 미러링: 카프카 클러스터 간의 데이터 복제 미러메이커: 아파치 카프카에서 클러스터간 데이터 복제를 수행하기 위한 툴 클러스터간 미러링 활용 사례 지역 및 중앙 클러스터: 하나의 기업이 지리적으로 분산된 지역, 도시, 대룩 간에 하나 이상의 데이터센터를 가지고 있을 수 있으며, 각각의 데이터센터에 카프카 클러스터가 설치되어 있는 경우 고가용성와 재해 복구: 첫 번째 클러스터의 모든 데이터를 보유하는 여분의 두 번째 클러스터를 준비해 뒀다가 만약의 사태가 발생했을 때 애플리케이션을 두 번째 클러스터를 사용해서 작동함으로써 평상시처럼 작업을 계속하게 할 수 있다....

배경 Spring Batch에서 하나의 Job이 여러 가지 조건에 따라 다른 step이 흘러가야되는 경우가 필요할 수 있다. 이를 구성할 수 있는 방법을 이해한다. 순차 실행 next() 메서드로 다음으로 실행할 스텝을 선언할 수 있다. 만약 stepA에서 실패하면 해당 Job은 실패처리되고 stepB부터는 실행되지 않는다. @Bean fun testJob(stepA: Step, stepB: Step, stepC: Step) = jobBuilder("testJob") .start(stepA) .next(stepB) .next(stepC) .build() 조건부 실행 on() 메서드로 스텝의 실행 결과에 따라 다음 스텝을 정할 수 있다. on() 메서드는 스텝의 실행 결과인 ExitStatus 의 패턴 매칭으로 동작한다....

카프카를 사용한 데이터 파이프라인 구축하는 대표적인 사례 사례1: 아파치 카프카가 두 개의 엔드포인트 중 하나가 되는 데이터 파이프라인 구축 예시: 카프카에서 가져온 데이터를 Amazon S3에 넣거나 몽고DB의 데이터를 카프카로 가져오기 사례2: 두 개의 서로 다른 시스템을 연결하는 파이프라인을 만들면서 그 중간에 카프카를 사용하는 경우 예시: 트위터에서 카프카로 데이터를 전달한 후 다시 카프카에서 엘라스틱서치로 전달함으로써 트위터에서 가져온 데이터를 엘라스틱서치로 보내는 경우 데이터 파이프라인에 있어서 카프카가 갖는 주요한 역할은 데이터 파이프라인의 다양한 단계 사이사이에 있어 매우 크고 안정적인 버퍼 역할을 해 줄 수 있다는 점이다....

7장까지는 ‘최소 한 번’ 전달에 초점을 맞췄다. 하지만 메시지 중복의 가능성은 여전히 있다. 현실에서 사용되는 대부분의 애플리케이션들은 메시지를 읽는 애플리케이션이 중복 메시지를 제거할 수 있도록 메시지에 고유한 식별자를 포함한다. 카프카 ‘정확히 한 번’ 의미 구조는 두 개의 핵심 기능의 조합로 이루어진다. 멱등성 프로듀서: 프로듀서 재시도로 인해 발생하는 중복을 방지한다. 트랜잭션 의미 구조: 스트림 처리 애플리케이션에서 ‘정확히 한 번’ 처리를 보장한다. 멱등성 프로듀서 멱등성: 작업을 여러 번 실행해도 한 번 실행한 것과 결과가 같은 성질 프로듀서에서 메시지가 중복으로 발생하는 일반적인 시나리오 파티션 리더가 프로듀서로부터 레코드를 받아서 팔로워들에게 성공적으로 복제한다....

목표 테스트 환경에서 사용할 Kafka 브로커를 컨테이너로 실행하는 방법을 이해한다. Kafka 브로커는 KRaft 모드로 실행하여 ZooKeeper 없이 실행 가능하도록 구성한다. KRaft 모드 KRaft 모드가 존재하기 이전에는 Kafka의 메타데이터를 관리하기 위해 Zookeeper 에 의존했다. 이는 여러 문제점이 존재했다. ZooKeeper의 한계로 인해 클러스터의 확장에 한계가 존재 ZooKeeper 자체로도 하나의 분산 시스템이여서 Kafka를 사용하기 위해 2가지 기술의 학습 필요 이를 해결하기 위해서 KRaft 모드가 Apache Kafka 2.8 버전에서 처음 선보였고, 3.3 버전부터 프로덕션 환경에서 사용 가능한 것으로 발표했다....

신뢰성 보장 보장: 서로 다른 상황에서도 시스템이 지킬 것이라고 보장되는 행동 아파치 카프카가 보장하는 것 파티션 안의 메시지들 간에 순서를 보장한다. 만약 메시지 A 다음에 B가 쓰여졌다면, 동일한 프로듀서가 동일한 파티션에 썼을 경우, 카프카는 B의 오프셋이 A보다 큰 것을 보장한다. 컨슈머 역시 A를 읽어온 다음에 B를 읽게 된다. 클라이언트가 쓴 메시지는 모든 인-싱크 레플리카의 파티션에 쓰여진 뒤에야 커밋된 것으로 간주한다. 프로듀서는 메시지가 완전히 커밋된 다음 응답이 올지, 리더에게 쓰여진 다음 응답이 오지 아니면 네트워크로 전송된 다음 바로 응답이 올지 선택할 수 있다....

환경 설정 운영체제 선택하기 아파치 카프카는 다양한 운영체제에서 실행이 가능한 자바 애플리케이션이다. 카프카는 윈도우, macOS, 리눅스 등 다양한 운영체제에서 실행이 가능하지만, 대체로 리눅스가 권장된다. 주키퍼 설치하기 아파치 카프카는 카프카 클러스터의 메타데이터와 컨슈머 클라이언트에 대한 정보를 저장하기 위해 아파치 주키퍼를 사용한다. 주키퍼는 설정 정보 관리 이름 부여, 분산 동기화, 그룹 서비스를 제공하는 중앙화된 서비스이다. 독립 실행 서버이 가능하다. 주키퍼는 고가용성을 보장하기 위해 앙상블이라 불리는 클러스터 단위로 작동하도록 설계되었다. 주키퍼가 사용하는 부하 분산 알고리즘 때문에 앙상블은 홀수 개의 서버를 가지는 것이 권장된다....

클러스터 멤버십 카프카는 현재 클러스터의 멤버인 브로커들의 목록을 유지하기 위해 아파치 주키퍼를 사용한다. 각 브로커는 브로커 설정 파일에 저장되었거나, 자동으로 생성된 고유 식별자를 가진다. 브로커 프로세스는 시작될 때마다 주키퍼에 Ephemeral 노드의 형태롤 ID를 등록한다. 컨트롤러들과 몇몇의 생태계 툴들은 브로커가 등록되는 주키퍼의 /brokers/ids 경로를 구독함으로써 브로커가 추가되거나 제거될 때마다 알림을 받는다. 만약 동일한 ID를 가진 다른 브로커를 시작한다면, 에러가 발생한다. 브로커가 정지하면 브로커를 나타내는 ZNode는 삭제되지만, 브로커의 ID는 다른 자료구조에 남아 있게 된다....

카프카 컨슈머: 개념 컨슈머와 컨슈머 그룹 카프카 컨슈머는 보통 컨슈머 그룹의 일부로서 작동한다. 이유: 우리는 토픽으로부터 데이터를 읽어 오는 작업을 확장할 수 있어야 한다. 동일한 컨슈머 그룹에 속한 여러 개의 컨슈머들이 동일한 토픽을 구독할 경우, 각각의 컨슈머는 해당 토픽에서 서로 다른 파티션의 메시지를 받는 것이다. 컨슈머 그룹에 컨슈머를 추가하는 것은 카프카 토픽에서 읽어오는 데이터 양을 확장하는 주된 방법이다. 토픽을 생성할 때 파티션을 크게 잡아주는 게 좋은 이유: 부하가 증가함에 따라서 더 많은 컨슈머를 추가할 수 있게 해주기 때문 토픽에 설정된 파티션 수 이상으로 컨슈머를 투입하는 것은 아무 의미가 없는 점도 명심하라 새로운 컨슈머 그룹, G2를 추가하게 된다면 이 컨슈머는 G1 컨슈머 그룹에서 무엇을 하고 있든지 상관없이 T1 토픽의 모든 메시지를 받게 된다....

목표 MySQL 을 사용 중인 환경에서 Hibernate의 각 GenerationType이 PK를 생성하는 방식을 이해한다. GenerationType GenerationType: JPA에서 PK를 생성하는 전략을 나타내는 enum TABLE: 데이터베이스 테이블을 사용해서 PK 할당 SEQUENCE: 데이터베이스 시퀀스를 사용해서 PK 할당 IDENTITY: 데이터베이스의 식별자 컬럼(MySQL의 AUTO_INCREMENT)을 사용해서 PK 할당 UUID: 애플리케이션에서 UUID를 생성해서 PK 할당 JPA 3.1, Hibernate 6.2부터 지원 시작 AUTO: 사용 중인 데이터베이스 종류에 따라서 자동으로 전략 선택 GenerationType.AUTO의 전략 선택 과정 Hibernate 5.2 Spring Boot 2부터 hibernate....

@Entity JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 어노테이션을 필수로 붙여야한다. @Entity 적용 시 주의사항 기본 생성자가 필수다(파라미터가 없는 public 또는 protected 생성자) final 클래스, enum, interface, inner 클래스에는 사용할 수 없다. 저장할 필드에 final을 사용하면 안 된다. kotlin을 사용할 때는 maven의 jpa 플러그인을 사용 한다면 파라미터가 없는 생성자를 만들 필요가 없다. (https://kotlinlang.org/docs/no-arg-plugin.html#jpa-support) kotlin을 사용할 때는 기본적으로 final 클래스로 만들어지는데, 아래와 같이 플러그인을 이용해서 특정 어노테이션이 붙어 있는 경우에는 open 클래스로 만들도록 수정할 수 있다....

0.11 부터 프로그램적인 관리 기능 API를 제공하기 위한 목적으로 AdminClient가 추가되었다. AdminClient 개요 비동기적이고 최종적 일관성을 가지는 API 카프카의 AdminClient는 비동기적으로 작동한다. 카프카 컨트롤러로부터 브로커로의 메타데이터 전파가 비동기적으로 이루어지기 때문에, AdminClient API가 리턴하는 Future 객체들은 컨트롤러의 상태가 완전히 업데이트된 시점에 완료된 것으로 간주한다. 이 시점에 모든 브로커가 전부 다 새로운 상태에 대해 알고 있지는 못할 수 있기 때문에, listTopics 요청은 최신 상태를 전달받지 않은 브로커에 의해 처리될 수 있다. 이러한 속성을 최종적 일관성(eventual consistency)이라고 한다....

예외 처리 JPA 표준 예외 정리 JPA 표준 예외들은 PersistenceException의 자식 클래스다. 그리고 이 예외 클래스는 RuntimeException의 자식이므로 JPA 예외는 모두 언체크 예외다. JPA 표준 예외는 2가지로 나눌 수 있다. 트랜잭션 롤백을 표시하는 예외: 심각한 예외이므로 복구해선 안 된다. 트랜잭션을 강제로 커밋해도 트랜잭션이 커밋되지 않고 대신 RollbackException이 발생한다. 트랜잭션 롤백을 표시하지 않는 예외 심각한 예외가 아니다. 스프링 프레임워크의 JPA 예외 변환 서비스 계층에서 데이터 접근 계층의 구현 기술에 직접 의존하는 것은 좋은 설계라 할 수 없다....