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

배경 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: 두 개의 서로 다른 시스템을 연결하는 파이프라인을 만들면서 그 중간에 카프카를 사용하는 경우 예시: 트위터에서 카프카로 데이터를 전달한 후 다시 카프카에서 엘라스틱서치로 전달함으로써 트위터에서 가져온 데이터를 엘라스틱서치로 보내는 경우 데이터 파이프라인에 있어서 카프카가 갖는 주요한 역할은 데이터 파이프라인의 다양한 단계 사이사이에 있어 매우 크고 안정적인 버퍼 역할을 해 줄 수 있다는 점이다....

목표 테스트 환경에서 사용할 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는 다른 자료구조에 남아 있게 된다....

목표 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....

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

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

목표 stage 환경에서 Spring 애플리케이션이 컨테이너로 실행되고 있다. 해당 애플리케이션의 특정 API의 응답 속도가 늦어져서 원인을 파악한다. JMX JMX: JVM 애플리케이션을 관리하고 모니터링하기 위해 제공되는 API JMX 아키텍처 JMX는 3개의 계층으로 구성되어 있다. Instrumentation layer: 애플리케이션에서 관리하고자 하는 자원을 표현하는 MBean 객체를 관리 JVM에서 기본적으로 제공하는 MBean들이 있음 ThreadMXBean: 스레드 수, 스레드별 CPU 시간, 스레드들의 stack trace 정보 등을 제공 MemoryMXBean: 메모리 사용량 제공 JMX agent layer: MBeanServer 존재 MBean 객체들을 등록, 괸리하고 이를 접근할 수 있도록 인터페이스 제공 Remote management layer: JConsole, VisualVM 같은 툴을 가리키는 클라이언트 영역 VisualVM JVM 애플리케이션을 모니터링 하기 위한 툴 jstatd, JMX 등의 방식으로 JVM 애플리케이션과 통신해서 여러 메트릭 정보 확인 가능 Remote 환경의 컨테이너를 VisualVM으로 모니터링 하기 VisualVM을 JVM 애플리케이션과 JMX 연결하여 모니터링 할 수 있다....

트랜잭션은 작업의 완전성을 보장해준다. 잠금(Lock)은 트랜잭션과 비슷한 개념 같지만 동시성을 제어하기 위한 기능이다. 반면, 트랜잭션은 데이터의 정합성을 보장한다. 트랜잭션 MySQL에서의 트랜잭션 트랜잭션은 꼭 여러 개의 변경 작업을 수행하는 쿼리가 조합됐을 때만 의미 있는 개념은 아니다. 아래의 예를 본다. SLECT * FROM tab_innodb 트랜잭션을 지원하지 않는다면 1, 2가 부분 저장되고 3만 저장되지 않지만, 트랜잭션이 지원되기 때문에 1, 2, 3 모두 롤백이 되었다. 트랜잭션이 지원되는 않는 코드 부분 업데이트가 발생해서 쓰레기 데이터가 남을 수 있기 때문에, 복잡한 분기처리를 해줘야된다....

육각형 아키텍처는 도메인 중심의 아키텍처에 적합하다. 유스케이스 둘러보기 일반적으로 유스케이스는 다음과 같은 단계를 따른다. 입력을 받는다. 입력 유효성 검증은 다른 곳에서 처리한다. (유스케이스 코드가 도메인 로직에만 신경 써야하고 입력 유효성 검증으로 오염되면 안되기 떄문) 비즈니스 규칙을 검증한다. 도메인 엔티티와 유스케이스가 책임을 공유한다. 모델 상태를 조작한다. 영속성 어댑터를 통해 구현된 포트로 변경된 상태를 전달해서 저장될 수 있게 한다. 출력을 반환한다. 입력 유효성 검증 입력 유효성 검증은 입력 모델의 생성자 내에서 이루어진다....

프로듀서 개요 카프카에 메시지를 써야 하는 상황에 따라 요구사항이 다양하다. 메시지 유실이 용납되지 않는지 중복이 허용되도 상관없는지 반드시 지켜야할 지연이나 처리율이 있는지 이처럼 서로 다른 요구 조건은 카프카에 메시지를 쓰기 위해 프로듀서 API를 사용하는 방식과 설정에 영향을 미친다. 프로듀서 메시지 전송 과정 ProducerRecord 객체를 생성한다. 여기서는 레코드가 저장될 토픽과 밸류는 필수사항이지만, 키와 파티션 지정은 선택사항이다. ProducerRecord를 전송하는 API를 호출했을 때, 키와 값 객체가 네트워크 상에 전송될 수 있도록 직렬화해서 바이트 배열로 변환한다....

서킷 브레이커 이해하기 서킷 브레이커 패턴은 우리가 작성한 코드가 실행에 실패하는 경우에 안전하게 처리되도록 해준다. 마이크로서비스의 경우, 한 마이크로서비스의 실패가 다른 마이크로서비스의 연쇄적인 실패로 확산되는 것을 방지해야 하기 때문에 더 중요하다. 서킷 브레이커는 메서드의 호출을 허용하며, 서킷은 닫힘 상태에서 시작된다. 어떤 이유로 실패하면, 서킷 브레이커가 개방되고 실패한 메서드에 더 이상 호출이 수행되지 않는다. 대신 폴백을 제공하여 자체적으로 실패를 처리한다. 개방 상태의 서킷이 때때로 절반-열림 상태로 바뀌면서 실패했던 메서드의 호출을 서킷 브레이커가 다시 시도한다....

쿼리 작성과 연관된 시스템 변수 SQL 모드 MySQL 서버의 sql_mode 라는 시스템 설정에는 여러 개의 값이 동시에 설정될 수 있다. sql_mode를 설정할 때는 구분자(,)를 이용해 키워드를 동시에 여러 개 설정할 수 있다. MySQL 서버의 sql_mode 시스템 변수에 설정된 값들은 SQL 문장 작성 규칙뿐만 아니라 MySQL 서버 내부적으로 자동 실행되는 데이터 타입 변환 및 기본값 제어 등과 관련된 옵션도 가지고 있다. 그래서 일단 MySQL 서버에 사용자 테이블을 생성하고 데이터를 저장하기 시작했담녀 가능한 한 sql_mode 시스템 변수의 내용은 변경하지 않는 것이 좋다....

JDBC 접속 문제 감지 쿼리를 보내려는 앱이 DB에 커넥션을 맺을 때부터 문제가 생길때 원인 파악을 프로파일러로 할 수 있다. 호출 그래프를 보고 앱의 코드 설계 파악 언젠가 코드를 정확히 분석하게 되겠지만, 호출 그래프를 활용하면 어떤 일이 일어나느지 미리 신속하게 개괄할 수 있다. 플레임 그래프를 그려 성능 문제 밝히기 호출 그래프가 객체와 메서드 호출 간의 관계에 집중한다면, 플레임 그래프는 잠재적인 레이턴시를 발견하는 데 가장 유용하다. NoSQL DB에서의 쿼리 분석

디스크 읽기 방식 하드 디스크 드라이브(HDD)와 솔리드 스테이트 드라이브(SSD) 데이터베이스 서버에서는 항상 디스크 장치가 병목이 된다. 이러한 기계식 하드 디스크 드라이브를 대체하기 위해 전자식 저장 매체인 SSD가 많이 출시되고 있다. 디스크의 헤더를 움직이지 않고 한 번에 많은 데이터를 읽는 순차I/O에서는 SSD가 하드 디스크 드라이브보다 조금 빠르거나 거의 비슷한 성능을 보이고 있다. SSD의 장점은 기존 하드 디스크 드라이브보다 랜덤 I/IO가 훨씬 바르다. 랜덤 I/O와 순차 I/O 디스크의 성능은 디스크 헤더의 위치 이동 없이 얼마나 많은 데이터를 한 번에 기록하느냐에 의해 결정된다....

목표 복잡한 구조의 클래스의 bean validation 적용 방법을 이해한다. nested child object의 검증 방법 Java bean validation은 기본적으로 검증하고자 하는 클래스에도 @Valid 어노테이션을 붙여줘야된다. @Valid 어노테이션은 field나 getter에 붙여줄 수 있다. data class Project( @field:NotBlank(message = "Project title must be present") @Size(min = 3, max = 20, message = "Project title size not valid") private val title: String, @field:Valid private val owner: User, ) data class User( @field:NotBlank(message = "User name must be present") @field:Size(min = 3, max = 50, message = "User name size not valid") private val name: String, @field:NotBlank(message = "User email must be present") @field:Email(message = "User email format is incorrect") private val email: String, ) 이유 Java bean validation이 nested child object 를 자동으로 스캔해서 검증해준다면, @Valid 어노테이션을 매번 직접 명시하지 않아도 되어서 편리할 것이라고 생각할 수 있다....

로그 메시지는 스트링일 뿐이라서 이론적으로는 어떤 문장이라도 남길 수 있지만, 깔끔하고 사용하고 편한 로그를 남기려면 앞으로 이 장에서 설명한 몇 가지 베스트 프랙티스를 따르는 것이 좋다. 개발자가 문제를 조사할 때는 무엇보다 로그를 가장 먼저 확인해야 한다. 로그를 보면 이상한 동작이 바로 보이기 때문에 어디서부터 조사를 시작해야 할지 정확하게 진단할 수 있기 때문이다. 로그가 모든 질문에 정답을 제공하는 것은 아니지만, 출발점을 찾아내는 일은 매우 중요하다. 로그를 이용하여 조사하기 로그는 과거 특정 기간의 앱 실행에 초점을 맞춘다....