hyunjuuun.dev

Topic replication factor 토픽은 replication factor를 가진다. 보통 2와 3 정도로 설정하며 3으로 설정하는 경우가 가장 흔하다. 이를 통해 카프카 서버(브로커)가 다운되었을 때 또 다른 브로커에 있는 데이터 사본을 통해 작업을 수행할 수 있게 된다. ex) Topic-A, 2개의 파티션, 복제 계수 2의 브로커 리더 파티션 1개의 브로커가 파티션 리더 역할을 수행한다. 프로듀서는 파티션의 리더인 브로커에만 데이터를 전송할 수 있다. 리더 브로커가 아닌 브로커들은 리더 브로커의 데이터를 복제한다. 이 때 리더 브로커의 데이터를 복제한 레플리카를 ISR이라 한다. (in-sync replica) (반대로는 out-of-sync replica) 리더 파티션의 기본 동작 기본..

Kafka Broker 카프카 클러스터는 다수의 카프카 브로커로 구성된다. 브로커는 서버를 의미한다. 카프카 브로커는 Integer 타입의 ID로 식별된다. 각각의 브로커는 특정한 토픽 파티션을 가진다. 데이터가 모든 브로커에 걸쳐 분산된다. 클러스터에 있는 모든 브로커를 미리 알고 있을 필요는 없다. 하나의 브로커에 연결하면 클라이언트가 자동으로 나머지에 연결된다. 브로커 개수는 3개 정도로 시작하는 것이 좋으며 여러 개로 설정 가능하다. 예시를 통해 브로커와 토픽의 관계를 이해해보자. 3개의 파티션으로 이루어진 토픽 A와 2개의 파티션으로 이루어진 토픽 B가 있다. 토픽 파티션은 순서에 상관 없이 모든 브로커에 걸쳐 분산되었다. (수평적 스케일링) 파티션과 브로커를 더 추가하면 더 많은 데이터가 전체..

앞서 토픽에 데이터를 보내는 프로듀서에 대해 알아보았으니 이제 토픽으로부터 데이터를 읽는 역할을 수행하는 컨슈머에 대해 알아보자. 카프카 브로커가 컨슈머에 데이터를 push 하는 것이 아니라 컨슈머가 데이터를 pull 해온다. 하나 이상의 파티션으로부터 데이터를 읽어오는 것도 가능하다. 위처럼 파티션으로부터 데이터를 읽어와야 하는 컨슈머들은 자동적으로 어떤 카프카 브로커(서버)로부터 데이터를 읽을지 알고 있다. 파티션으로부터 오프셋에 따라 데이터를 순차적으로 읽어온다. Consumer Deserializer 컨슈머는 메시지를 읽고 Kafka로부터 받은 바이트를 객체나 데이터로 역직렬화한다. 컨슈머에서 역직렬화하기 위해서는 프로듀서에서 해당 토픽을 저장할 때 어떠한 형식의 Serializer인지에 따라 알..

Producer 카프카 토픽 내 파티션으로 데이터를 전송하는 역할을 수행한다. 프로듀서는 토픽 내 어떤 파티션으로 데이터가 전송될 지를 미리 알고 있다. 장애가 발생했을 경우 자동적으로 대응한다. (추후 학습) Message key 프로듀서는 생성하는 카프카 메시지에 메시지 키를 설정 할 수 있다. (optional) 메시지 키가 존재하지 않는 경우(null인 경우) 라운드 로빈 방식으로 파티션에 데이터를 전달한다. 키가 존재하는 경우 같은 키를 가진 데이터들은 같은 파티션으로의 전달을 보장받는다. (hashing) Kafka Message 카프카 메시지는 아래와 같은 정보들로 구성된다. Kafka Message Serializer 프로듀서로부터 입력값으로 직렬화 된 바이트만을 받고 컨슈머에게 출력값으로..

Topic Topic은 카프카 클러스터 내의 특정한 데이터 스트림을 의미한다. 하나의 Kafka cluster가 다수의 토픽을 가질 수 있다. ex)로그 토픽, 구매 토픽, 댓글 토픽 비유하자면 DB의 테이블이라고 할 수 있다. 테이블과 다르게 constraint은 존재하지 않는다. 카프카 토픽으로 무엇을 보내더라도 데이터에 대한 검증은 이루어지지 않는다. 클러스터 내의 토픽 간의 구분은 name을 통해 이루어진다. 다양한 메시지 포맷을 지원한다. Partition 토픽은 파티션으로 나뉜다. ex) 특정한 토픽이 [파티션 0, 파티션 1, 파티션 2] 3개의 파티션을 가질 수 있다. 토픽으로 보내진 메시지는 이러한 파티션들에게로 순차적으로 전달된다. 한 번 파티션에 저장된 메시지는 immutable하다...

코틀린에서의 조건문 자바에서 if-else는 Statement이지만, 코틀린에서는 Expression이다. Statement 프로그램의 문장, 하나의 값으로 도출되지 않음 Expression 하나의 값으로 도출되는 문장 코틀린에서는 if-else를 expression으로 사용할 수 있으므로 삼항 연산자가 없다. 코틀린에서는 switch문보다 강력한 기능을 가진 when 을 사용할 수 있다. 코틀린에서의 반복문 for each문 자바에서는 : 를 사용하는 것과 달리 코틀린에서는 in 을 사용한다. ..연산자 범위를 만들어 내는 연산자 코틀린에서의 예외 Checked Exception과 Unchecked Exception 코틀린에서는 Checked Exeption과 Unchecked Exeption을 구분하..

코틀린에서 변수 다루기 var과 val의 차이점 var variable의 약자 변할 수 있는 값을 담는 변수 선언 시 사용 val value의 약자 변하지 않는 값을 담는 변수 선언 시 사용 Kotlin에서 nullable 변수 Nullable한 변수는 타입 뒤에 ?를 붙인다. 코틀린에서 Null 다루기 null 체크 null이 아닌 경우에만 호출되는 Safe call 사용 ex) str?.length (str이 null이면 null 리턴) Elvis 연산자 str?.length ?: 0 str이 null인 경우 0 리턴 코틀린에서 Type 다루기 기본 타입 Byte Short Int Long Float Double 부호 없는 정수들 기본 타입이 아닌 경우) is java에서의 instance of as..

대규모의 서비스는 하나의 서버가 아니라 다수의 서버를 통해 운영된다. (수평적 확장) 스케일 아웃된 서버의 효과적인 동작을 위해서는 서비스의 데이터들이 균등하게 분배되어야 한다. 간단한 방식으로는 해시 함수를 통한 처리가 있다. N개의 캐시 서버가 있다고 해보자. serverIndex = hash(key) % N과 같이 간단한 모듈러 연산을 통해 서버를 선정한다. 하지만 위 방식의 경우 서버의 추가, 삭제가 일어났을 때 문제가 발생한다. 키에 대한 해시 값은 변화하지 않지만 서버의 개수인 N의 값이 달라지므로 서버 인덱스 값이 달라지게 된다. 따라서 대부분의 캐시 클라이언트가 데이터가 없는 엉뚱한 서버로 접속하게 된다. (대규모의 캐시 미스 발생) 안정 해시는 이러한 문제를 효과적으로 해결해준다. 해시 ..

Redis Transaction 여러 개의 명령을 내부 큐에 모아두고 트랜잭션 완료를 전달하면 일련의 명령을 한번에 처리한다. 트랜잭션 관련 명령어 MULTI 트랜잭션 시작 EXEC 트랜잭션으로 큐에 쌓여있던 명령 실행 DISCARD 트랜잭션 취소 WATCH 동시에 같은 키를 수정하는 상황이 일어났을 때 트랜잭션 취소 오류 발생 시 트랜잭션 내 모든 명령은 취소된다. 단 잘못된 인자 전달의 경우에는 해당 명령어만 에러 처리하고 정상 처리된다.

QR 코드 스캔을 통한 결제는 어떻게 동작할까? 동작 방식을 순차적으로 알아보자. [Scan to pay process] The merchant generates QR code and displays The consumer scans and pays QR 코드 생성 생성 과정을 하나씩 살펴보자 계산원이 구매한 상품들을 확정하면 구매 데이터가 PSP(payment service provider)에 전달될 것이다. PSP에서는 주문 번호와 해당 주문 번호에 맞는 QR 코드 URL을 생성하여 응답해줄 것이다. 계산원은 응답 받은 QR 코드를 고객에게 보여준다. 고객 결제 디지털 지갑에서 QR 코드 스캔을 진행한다. 디지털 지갑 앱에서 PSP로 해당 QR 코드에 대한 결제가 완료되었음을 전달한다. PSP에서는 ..