본문 바로가기

분류 전체보기

 (16)
Kafka 모니터링 이 글에서는 항상 모니터링 해야하는 중요한 메트릭은 어느 것인지, 그에 대해 어떻게 대응해야 하는지에 대해 알아볼 예정이다. 크게 브로커, 프로듀서, 컨슈머에서 각각 중요한 메트릭 정보가 나올 것이며, 브로커는 다시 토픽, 파티션, 로깅과 같이 3가지 세부항목으로 나누어 좀 더 상세한 메트릭 정보를 제공할 예정이다. Kafka의 메트릭 카프카의 모든 메트릭은 JMX(Java Management Extensions) 인터페이스를 통해 사용할 수 있다. 외부 모니터링 시스템에서 카프카 메트릭을 사용할 때는, 해당 모니터링 시스템의 모니터링 에이전트를 카프카 프로세스에 연결하는 것이 가장 쉬운 방법이다. 카프카 브로커의 JMX에 직접 연결하는 애플리케이션을 도와주기 위해 주키퍼에 저장된 브로커 정보에는 JMX..
Kotlin 이란 어떤 언어일까 오늘은 코틀린이라는 언어가 어떤 철학을 가진 언어인지, 어느 이유로 많이들 쓰기 시작한건지 알아보겠다 코틀린 탄생 배경 코틀린 언어에 대한 아이디어는 2010년 젯 브레인스(JetBrains)에서 생겼다. 그 시절 젯브레인스는 Java,C#,Javascript,Python,Ruby,PHP 등의 다양한 언어에 대한 개발도구를 제공하는 널리 알려진 꽤 유명했었다고 한다. 그들은 이렇게 다양한 언어에 대해 도구를 개발해온 경험으로 프로그래밍 언어라는 영역을 전체적으로 조망할 수 있는 독특한 시야와 이해를 가질수 있었고, 아래와 같은 이유로 자바를 대신할 언어를 찾고싶었으나 찾을 수 없었다고 한다 - 정적 타입 지정(static typing)이 가능한 언어 - 기존 자바코드와 완전히 호환이 되는 언어 - 배우기..
AbstractRoutingDataSource AbstractRoutingDataSource란? spring-jdbc 모듈에 포함되어 있는 클래스로써, 여러 DataSource를 등록하고 특정 상황에 맞게 원하는 DataSource를 사용할 수 있도록 추상화한 클래스이다. 이 친구가 나오게 된 배경은? Spring Boot를 사용해 Database Sharding 처리 니즈로 인해 생겨난 것으로 보인다. 알고있다시피 NoSQL에서는 샤딩 기능에 대해 많은 편의를 제공하고 있으며 RDBMS의 몇몇 벤더들 또한 샤딩 기능을 제공하기 위한 방법들은 제공중에 있을 것이다. 그러나 Spring에서는 이러한 NoSQL, RDBMS에 의존해서 샤딩을 구현하지 않고 Spring Boot로 편리하게 설정을 추상화하여 사용할 수 있는 방법을 만들고자 이러한 친구가 생..
QueryDSL QueryDSL 이란 ? - 스프링에서 Type-Safe한 쿼리르 보장하기 위해 제공되는 Domain Specific Language - 일반적으로 SQL은 Type Check가 불가능하고 실행되기 전까지 작동 여부를 확인하기가 어렵다. QueryDSL은 이러한 부분을 보완하여 Java로 Type-Safe 하게 개발할 수 있도록 제공해주는 프레임워크 이다 - Repository 인터페이스에서 메서드명이 너무 길어지거나, 메서드명으로 쿼리문을 만들기 까다로운 조건일 때 유용하게 쓰일 수 있다 왜 필요할까? - 위에서 언급한 것처럼 Type Check가 불가능하고 실행되기 전까지 작동여부를 알 수 없음을 보완하기 위해서 - SQL이 class처럼 Type이 있고 Java코드로 작성할수 있으면 편하지 않을까?..
Kafka 신뢰성 보장 이번 글에서는 카프카에서 보장할 수있는 신뢰성은 어떤것인지, 신뢰성을 보장하기 위해 브로커, 프로듀서, 컨슈머를 각각 어떤식으로 구성하면 될 것인지를 알아볼 예정이다. 카프카에서의 신뢰성 아파치 카프카에서 보장하는 것들은 무엇인지 아래의 항목들을 살펴보자 - 카프카는 파티션의 메세지 순서를 보장한다 - 각 파티션의 모든 동기화 리플리카에 메세지를 썼다면, 해당 메세지는 '커밋' 된 것으로 간주한다 - 최소한 하나의 리플리카가 살아있다면, 커민된 메세지는 유실되지 않는다 - 컨슈머는 커밋된 메세지만 읽을 수 있다 복제 복제 메커니즘은 카프카의 신뢰성 보장의 핵심이다. 복제된 리플리카들의 동기화 여부 체크 - 주키퍼와 세션이 연결되어 있는 경우 (주키퍼와 리플리카 간의 하트비트 전송 시간이 존재함 defau..
Kafka 내부 메커니즘 - 1)소개,주키퍼, 복제 실제 개발자가 Kafka를 사용하는 경우 이 내부 메커니즘이 필수적으로 필요한 내용은 아니다. 다만 어떻게 동작하는지 알아둔다면 Kafka를 운영하면서 튜닝이 필요한 부분을 보다 빨리 캐치하거나 감을잡기 위한 목적으로 이 글을 보기 바란다. 무엇에 대해 알아볼 것인가 내부 메커니즘 챕터를 통해서 크게 아래의 세가지 항목에 대해 알아볼 예정이다 - 카프카 복제(replication)가 동작하는 방법 - 카프카가 프로듀서와 컨슈머의 요청을 처리하는 방법 - 카프카가 스토리지를 처리하는 방법 Kafka Cluster 알고 넘어가기 Kafka Broker는 일반적으로 Load Balancing 및 HA (High Availability)를 위해서 다수의 Node 위에서 Cluster를 이루어 동작한다. Brok..
Kafka 내부 메커니즘 - 4)스토리지 앞서 Kafka가 요청에 대해 어떻게 쓰고, 읽는지 흐름을 알아 보았다. 그렇다면 실제로 Kafka가 데이터를 어떤식으로 저장하고 있을까? 이 부분에 대해 알아보자 카프카의 스토리지 단위 먼저 카프카의 기본적인 스토리지 단위는 파티션이다. 하나의 파티션은 여러 브로커 간에 분할될 수 없다. 따라서 하나의 파티션 크기는 단일 마운트 포인트에 사용 가능한 공간으로 제한된다. 카프카 저장공간 설정 카프카를 구성할 때, 파티션이 저장 될 디렉터리 내역을 log.dirs 매개변수에 설정 한다. (카프카 로그를 저장하는 곳이 아닌 저장공간인 디렉터리를 설정하는 매개변수임을 잊지 말자!! 실제 카프카 에러로그는 log4j.properties파일에 설정되니 참고바란다) 스토리지 파악 순서 1) 브로커와 브로커의 디렉터..
Kafka 내부 메커니즘 - 3)쓰기/읽기요청 쓰기요청(produce request) 일단 쓰기 요청의 흐름을 알기 전에 acks 매개변수에 대해 간단히 알고 넘어가자. acks매개 변수란, Producer config정보에서 ack(acknowlegement)옵션이 있다. 메세지를 보내고 잘 받았다고 확인받는 메세지라고 보면된다. 이 ack옵션에 따라서 네트워크를 몇번을 타야하는지를 결정할 수 있다. all 메세지를 리더한테 보내고 쓰여지고, 나머지 follower들이 똑같이 메세지를 다 복사할 때까지 기다린다. 복사까지 완벽하게 되면, 그제서야 ack옵션을 producer에게 보낸다.(메세지 잘 쓰여졌고, 복사까지 잘 됬어!)라고 - 장점은 leader가 어느 순간 뻗어도, 복제된 데이터가 follower들에게 있으니, 메세지의 유실이 전혀 없다..

티스토리툴바