데브원영

카프카 source connector가 exactly-once를 지원하는 방법

AndersonChoi — Sun, 23 Nov 2025 13:22:24 +0900

KIP-618에서 Source connector의 exactly-once(일부) 지원을 건의하였고 이 내용은 3.3.0에서 처음 적용되었습니다.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-618%3A+Exactly-Once+Support+for+Source+Connectors

KIP-618: Exactly-Once Support for Source Connectors - Apache Kafka - Apache Software Foundation

Status Current state: Accepted Discussion thread: here Voting thread: here JIRA: KAFKA-10000 - 이슈 세부사항 가져오는 중... 상태 , KAFKA-6080 - 이슈 세부사항 가져오는 중... 상태 Please keep the discussion on the mailing list r

cwiki.apache.org

1. 기존에는 source connector의 EOS를 지원하지 않았던 이유

기존에는 다음과 같은 방식으로 데이터를 처리하고 오프셋을 저장했습니다.

1. 소스 DB로 부터 데이터를 읽어서 토픽으로 send()

2. __connect-offsets에 읽은 오프셋까지 따로 커밋(저장)

위 방식은 별도의 처리로 이루어졌기 때문에 만약 워커가 죽어서 오프셋 저장이 되지 않으면 send()는 수행했지만 다시금 실행하는 즉, 두번의 처리(at-least-once)가 수행되었습니다. 그리고 추가적으로 좀비 태스크의 문제가 있었는데, 같은 소스 파티션에서 태스크가 어떠한 이유로 두번 이상 읽어서 중복이 발생하는 부분이 있어서 이를 다음과 같은 방식으로 해결하려고 했습니다.

1. 소스 레코드 전송 + 오프셋 저장을 '원자적'으로 수행

2. 좀비 태스크 팬싱(fencing)으로 중복 처리 하지 않음

2. 관련 메커니즘

같은 트랜잭션(원자적 처리)안에 소스 레코드 전송과 오프셋 커밋을 동시에 하는 것이 중요하다. 결과적으로 완벽하게 동시에 반영되어야지만 중복이나 누락없이 정확한 위치에서 읽기가 가능해지기 때문이다. 그렇기에 source connector로 전송되는 레코드는 'transaction record'로 전송되고 이에 따라 commit 또는 abort되어 처리된다. 즉, consumer 입장에서 topic을 읽기위해서는 isolation.level을 read_committed로 해야지만 정확히 한번처리된 데이터만 읽을 수 있게 된다.

3. 설정하는 방법

exactly.once.source.support 옵션을 통해 이제 source connector는 exactly-once 전송을 수행할 수 있게 되었습니다. 관련 옵션의 설명은 다음과 같습니다.

- exactly.once.source.supprt : DISABLED(기본값), ENABLED, PREPARING

https://kafka.apache.org/39/documentation.html#connectconfigs_exactly.once.source.support

Whether to enable exactly once support for source connectors in the cluster by using transactions to write source records and their source offsets, and by proactively fencing out old task generations before bringing up new ones. To enable exactly-once source support on a new cluster, set this property to 'enabled'. To enable support on an existing cluster, first set to 'preparing' on every worker in the cluster, then set to 'enabled'. A rolling upgrade may be used for both changes. For more information on this feature, see the exactly-once source support documentation.
소스 커넥터에서 생성된 레코드와 해당 소스 오프셋을 트랜잭션으로 함께 기록하고, 새로운 태스크를 시작하기 전에 이전 세대의 태스크들을 적극적으로 펜싱하여 비활성화함으로써, 클러스터에서 소스 커넥터의 exactly-once 지원을 활성화할지 여부를 설정하는 옵션이다. 새로운 클러스터에서 처음부터 exactly-once 소스 지원을 사용하려면 이 값을 ‘enabled’로 설정하면 된다. 이미 운영 중인 클러스터에서는, 모든 워커에 대해 먼저 ‘preparing’으로 설정한 뒤, 그다음 단계에서 ‘enabled’로 설정해야 한다.

소스 커넥터 자체에서 exactly-once 처리를 지원하더라도 결과적으로 connect 클러스터 전체가 exactly-once 모드를 사용할 수 있도록 프레임워크 레벨에서 설정을 활성화 해야만 하고, 이 기능은 오직 distributed 모드(분산 커넥트)에서만 사용 가능하다.

특이한 점은 '처음' 커넥트 클러스터를 실행한다면 해당 옵션을 'enabled'로 설정하면 되고, 만약에 롤링 업그레이드 등을 통해 기존에는 'disabled(default)'로 되어 있다면 'preparing'으로 설정한 뒤에 'enabled'로 다시 변경해야만 한다.

카프카는 복제본(replica)를 자동으로 다른 브로커로 재배치하지 않습니다

AndersonChoi — Fri, 21 Nov 2025 00:13:36 +0900

브로커가 0, 1, 2, 3, 4번으로 구성된 클러스터가 있고, 특정 토픽의 파티션은 0번이 리더이며 1번과 2번에 복제본이 있다고 가정합니다.

- 브로커 : 0,1,2,3,4

- 토픽의 파티션 : 0(리더), 1(팔로워), 2(팔로워)

이후 브로커 2번을 graceful shutdown하거나 예상치 못한 장애로 인해 오래 오프라인 상태가 되는 상황을 떠올려볼 수 있습니다.

“브로커 2번이 장시간 오프라인이면, 카프카가 자동으로 복제본을 3번이나 4번 브로커로 옮겨주지 않을까?”

복제본이 자동으로 이동한다면 가용성과 내구성이 유지될 것처럼 보입니다. 그러나 실제 Kafka는 어떻게 동작할까요.

카프카의 동작

브로커 2번이 1분, 10분, 1시간, 그 이상을 오프라인 상태로 유지하더라도 Kafka는 오직 두 가지 동작만 수행합니다.

첫째, 브로커 2번이 일정 시간 동안 리더를 따라잡지 못하면 ISR(In-Sync Replicas)에서 제외합니다.
둘째, 필요한 경우 리더 교체만 처리합니다.

그러나 Kafka는 복제본을 다른 브로커로 이동하지 않습니다. 즉, replica 목록은 그대로 [0,1,2] 상태로 유지되며, 복제본 불일치 문제는 운영자가 직접 조치하지 않는 이상 해결되지 않습니다. 이로 인해 replication.factor가 3이라도 실질적으로는 2개의 replica만 운영되는 결과가 일어납니다. 이런 현상을 Under replicated partition 상태라고 부릅니다.

그렇다면 운영에서는 어떻게 대응해야 하는가

브로커가 단기간 오프라인인 경우에는 ISR에서 빠졌다가 복구 시 다시 합류하면 문제는 자연스럽게 해결됩니다. 그러나 브로커가 장기간 복구되지 않거나 아예 폐지할 예정이라면 운영자가 직접 복제본 재배치 작업을 실행해야 합니다. Kafka는 kafka-reassign-partitions.sh와 같은 관리 도구를 통해 명시적으로 원하는 replica 구성을 지정하도록 설계되어 있습니다. 관리자가 “파티션 0의 복제본을 0, 1, 3으로 옮기겠다”라고 지시해야만 Kafka는 이에 따라 실제 복제 작업을 수행합니다.

KIP-932 Queues for Kafka 사용해보기(KafkaShareConsumer)

AndersonChoi — Fri, 12 Sep 2025 13:49:38 +0900

일반적으로 사용되는 아파치 카프카는 이벤트 스트림으로 파티션단위로 데이터를 처리하기 때문에 컨슈머 개수를 파티션 개수만큼 실행시켜 운영하는 것이 일반적이다. Queues for Kafka는 이와 다르게 파티션 개수보다 더 많은 컨슈머를 운영하기 위한 기능이다.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka

KIP-932: Queues for Kafka - Apache Kafka - Apache Software Foundation

Status Current state: Accepted Discussion thread: https://lists.apache.org/thread/9wdxthfsbm5xf01y4xvq6qtlg0gq96lq JIRA: https://issues.apache.org/jira/browse/KAFKA-16092 Please keep the discussion on the mailing list rather than commenting on the wiki (

cwiki.apache.org

https://cwiki.apache.org/confluence/display/KAFKA/Queues+for+Kafka+%28KIP-932%29+-+Preview+Release+Notes

Queues for Kafka (KIP-932) - Preview Release Notes - Apache Kafka - Apache Software Foundation

Apache Kafka 4.1.0 is shipped with a preview release of KIP-932: Queues for Kafka. This feature is not yet recommended for use on production clusters, but it is ready for evaluation and testing. This KIP introduces the concept of a share group as a way of

cwiki.apache.org

4.1.0이 릴리즈되면서 Queues for Kafka는 이제 early access에서 preview로 바뀌었고, 상용환경에서도 위험을 감수하고 사용할만큼 보완되었다.

KafkaShareConsumer 사용 방법

1) cluster 실행 및 설정

version: "3.8"

services:
  kafka:
    image: apache/kafka:4.1.0
    container_name: kafka41
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_LISTENERS: INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9091,CONTROLLER://0.0.0.0:9093
      KAFKA_ADVERTISED_LISTENERS: INTERNAL://127.0.0.1:9092,EXTERNAL://host.docker.internal:9091
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@localhost:9093
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_NUM_PARTITIONS: 1

      # Share Coordinator 내부 상태 토픽 생성 조건 완화
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_REPLICATION_FACTOR: "1"
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_MIN_ISR: "1"

상기와 같이 설정하고 docker-compose up 으로 실행

$ ./kafka-features.sh --bootstrap-server localhost:9092 upgrade --feature share.version=1
share.version was upgraded to 1.

실행중인 브로커에 피쳐를 on 하기 위해 상기 명령어를 실행한다.

위 스크립트를 실행하지 않으면, 컨슈머에서 다음과 같은 에러가 발생한다.

Exception in thread "main" org.apache.kafka.common.errors.UnsupportedVersionException: The cluster does not support the share group protocol. To use share groups, the cluster must have the share group protocol enabled.

2) consumer code

2-1) ImplicitAck mode

package org.example;

import org.apache.kafka.clients.consumer.AcknowledgeType;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaShareConsumer;
import org.apache.kafka.common.serialization.StringDeserializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.time.Duration;
import java.util.List;
import java.util.Properties;

public class Main {
    private final static Logger log = LoggerFactory.getLogger(Main.class);

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        props.put("group.id", "test-group"); // 공유 그룹 ID

        KafkaShareConsumer<String, String> consumer =
                new KafkaShareConsumer<>(props, new StringDeserializer(), new StringDeserializer());

        consumer.subscribe(List.of("test"));

        while (true) {
            ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
            records.forEach(record -> {
                log.info("Processed: " + record.value());
            });
        }
    }
}

별도로 모드를 지정하지 않고 KafkaShareConsumer를 사용할 경우 암시적인 ack 모드로 사용된다. poll()로 가져온 배치는 자동으로 성공된것으로 간주되어 ACK가 된다.

[main] INFO org.apache.kafka.common.config.AbstractConfig - ShareConsumerConfig values: 
	allow.auto.create.topics = true
	auto.commit.interval.ms = 5000
	auto.offset.reset = latest
	bootstrap.servers = [localhost:9092]
	group.id = test-group
	share.acknowledgement.mode = implicit  // 기본으로 설정된 mode 
    
    ... 생략
[main] WARN org.apache.kafka.clients.consumer.internals.ShareConsumerDelegateCreator - Share groups and KafkaShareConsumer are part of a preview feature introduced by KIP-932, and are not recommended for use in production.
[main] INFO org.apache.kafka.common.telemetry.internals.KafkaMetricsCollector - initializing Kafka metrics collector
[main] INFO org.apache.kafka.common.utils.AppInfoParser - Kafka version: 4.1.0
[main] INFO org.apache.kafka.common.utils.AppInfoParser - Kafka commitId: 13f70256db3c994c
[main] INFO org.apache.kafka.common.utils.AppInfoParser - Kafka startTimeMs: 1757651562780
[main] INFO org.apache.kafka.clients.consumer.internals.ShareConsumerImpl - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Subscribed to topics: test
[consumer_background_thread] INFO org.apache.kafka.clients.consumer.internals.ShareMembershipManager - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Member Hq3kzUZhQ4mt3l6afzGrVg with epoch 0 transitioned from UNSUBSCRIBED to JOINING.
[consumer_background_thread] INFO org.apache.kafka.clients.Metadata - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Cluster ID: 5L6g3nShT-eMCtK--X86sw
[consumer_background_thread] INFO org.apache.kafka.clients.consumer.internals.CoordinatorRequestManager - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Discovered group coordinator Coordinator(key='test-group', nodeId=1, host='127.0.0.1', port=9092, errorCode=0, errorMessage='')
[consumer_background_thread] INFO org.apache.kafka.clients.consumer.internals.ShareMembershipManager - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Member Hq3kzUZhQ4mt3l6afzGrVg with epoch 10 transitioned from JOINING to RECONCILING.
[consumer_background_thread] INFO org.apache.kafka.clients.consumer.internals.ShareMembershipManager - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Reconciling assignment with local epoch 0
	Member:                                    Hq3kzUZhQ4mt3l6afzGrVg
	Assigned partitions:                       [test-0]
	Current owned partitions:                  []
	Added partitions (assigned - owned):       [test-0]
	Revoked partitions (owned - assigned):     []

[consumer_background_thread] INFO org.apache.kafka.clients.consumer.internals.ShareMembershipManager - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Member Hq3kzUZhQ4mt3l6afzGrVg with epoch 10 transitioned from RECONCILING to ACKNOWLEDGING.
[consumer_background_thread] INFO org.apache.kafka.clients.consumer.internals.ShareMembershipManager - [ShareConsumer clientId=consumer-test-group-1, groupId=test-group] Member Hq3kzUZhQ4mt3l6afzGrVg with epoch 10 transitioned from ACKNOWLEDGING to STABLE.

2-2) ExplicitAck mode

package org.example;

import org.apache.kafka.clients.consumer.AcknowledgeType;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaShareConsumer;
import org.apache.kafka.common.serialization.StringDeserializer;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.time.Duration;
import java.util.List;
import java.util.Properties;

public class Main {
    private final static Logger log = LoggerFactory.getLogger(Main.class);

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        props.put("group.id", "test-group"); // 공유 그룹 ID
        props.put("share.acknowledgement.mode", "explicit"); // ACK 모드

        KafkaShareConsumer<String, String> consumer =
                new KafkaShareConsumer<>(props, new StringDeserializer(), new StringDeserializer());

        consumer.subscribe(List.of("test"));

        while (true) {
            ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(500));
            records.forEach(record -> {
                try {
                    doProcessing(record.value());

                    // 성공적으로 처리 → ACK
                    consumer.acknowledge(record, AcknowledgeType.ACCEPT);

                } catch (RetryableException e) {
                    // 재시도 가능한 오류 → RELEASE
                    consumer.acknowledge(record, AcknowledgeType.RELEASE);

                } catch (Exception e) {
                    // 복구 불가능 오류 → REJECT
                    consumer.acknowledge(record, AcknowledgeType.REJECT);
                }
            });

            // 메시지 단위 ACK을 브로커에 커밋
            consumer.commitSync();
        }
    }

    private static void doProcessing(String task) throws Exception {
        // 예: 이미지 처리, API 호출 등
        if (task.contains("fail")) {
            throw new RetryableException("Temporary failure");
        }
        log.info("Processed: " + task);
    }

    static class RetryableException extends Exception {
        public RetryableException(String msg) {
            super(msg);
        }
    }
}

명시적 모드인 경우 commit을 수행해야 한다. AcknowledgeType은 총 3가지가 있으며 각 특징은 다음과 같다.

/**
 * The acknowledge type is used with {@link KafkaShareConsumer#acknowledge(ConsumerRecord, AcknowledgeType)} to indicate
 * whether the record was consumed successfully.
 */
@InterfaceStability.Evolving
public enum AcknowledgeType {
    /** The record was consumed successfully. */
    ACCEPT((byte) 1),

    /** The record was not consumed successfully. Release it for another delivery attempt. */
    RELEASE((byte) 2),

    /** The record was not consumed successfully. Reject it and do not release it for another delivery attempt. */
    REJECT((byte) 3);

AcknowledgeType	의미	사용 상황	브로커 동작
ACCEPT	성공적으로 처리됨	정상 처리 완료	Archived(완료)로 이동, 재전달 없음
RELEASE	일시적 실패, 재시도 필요	네트워크/DB 오류, 일시적 장애	다시 Available 상태로 이동, deliveryCount +1, 동일 컨슈머 또는 다른 컨슈머가 재시도
REJECT	처리 불가능한 오류	포이즌 메시지, 스키마 불일치	즉시 Archived 상태, 재전달 없음

deliveryCount란?

Share Group(KIP-932)에서 각 레코드가 컨슈머에게 획득(acquire) 될 때마다 증가하는 카운터. 즉, 이 메시지가 몇 번 재시도되었는가를 추적하는 값임. 메시지가 무한정 재시도되는 것을 막기 위함. 잘못된 메시지(포이즌 레코드)가 무한 루프에 빠지지 않도록 최대 횟수 제한을 둠. group.share.delivery.count.limit(기본값 5) 설정에 의해 limit 제어됨. 기본값(5)이라면 한 레코드는 최대 5회까지 poll → acquire 될 수 있음. 6번째부터는 더 이상 Available로 돌아가지 않고 Archived(폐기)상태로 전환됨.

┌──────────────────────────────────────────────────────────────────────┐
│                          Share Group State Machine                   │
└──────────────────────────────────────────────────────────────────────┘

[Produced]
    │  (레코드가 토픽에 기록됨)
    ▼
[Available]
    │  poll() 시 컨슈머가 획득(acquire)
    ▼
[Acquired / In-Flight]  ── 처리 시도 (process)
    │
    ├─ acknowledge(..., ACCEPT)
    │        │
    │        ▼
    │   [Acknowledged]  ──(commitSync/Async)──► __share_group_state 반영
    │                      (완료 상태. 재전달되지 않음)
    │
    ├─ acknowledge(..., RELEASE)
    │        │
    │        ├─ deliveryCount < maxDeliveries
    │        │        │
    │        │        ▼
    │        │   [Available] 로 복귀
    │        │   (같은 컨슈머 또는 다른 컨슈머가 재시도 가능,
    │        │    deliveryCount += 1)
    │        │
    │        └─ deliveryCount ≥ maxDeliveries
    │                 │
    │                 ▼
    │            [Archived]  (더 이상 배달하지 않음)
    │
    ├─ acknowledge(..., REJECT)
    │        │
    │        ▼
    │   [Archived]  (즉시 보관/차단. 재전달 없음)
    │   (보통 DLQ로 복사 후 REJECT)
    │
    └─ (명시적 ACK 없이 루프 종료)
             │
             ├─ share.acknowledgement.mode = explicit
             │     → ACK 안 한 레코드들은 같은 acquisition으로 재제공
             │       (다음 poll에서 다시 처리, deliveryCount 증가 없음)
             │
             └─ share.acknowledgement.mode = implicit
                   → 다음 poll() 시 이전 배치가 암시적 ACK 처리됨
                     (실패 레코드도 성공으로 간주될 수 있으므로 주의)

[Archived] / [Acknowledged]
    └─ 단말 상태(terminal). 컨슈머에게 더 이상 전달되지 않음.

5개 인스턴스(컨슈머) 실행해보기

- test 토픽, 파티션0개

- intellij에서 multi instance run

쉘스크립트로 상태 확인하기

$ ./kafka-groups.sh --bootstrap-server localhost:9092 --list
GROUP                TYPE                 PROTOCOL
test-group           Share                share

$ ./kafka-share-groups.sh --bootstrap-server localhost:9092 --list
test-group

$ ./kafka-share-groups.sh --bootstrap-server localhost:9092 --describe --group test-group
GROUP           TOPIC           PARTITION  START-OFFSET
test-group      test            0          13

$ ./kafka-share-groups.sh --bootstrap-server localhost:9092 --describe --group test-group --members
GROUP           CONSUMER-ID            HOST            CLIENT-ID             #PARTITIONS  ASSIGNMENT
test-group      531rie8GTeGXgr4mT0jViw /192.168.65.1   consumer-test-group-1 1            test:0
test-group      GMGiDkymRLqmH2sA_Py4yw /192.168.65.1   consumer-test-group-1 1            test:0
test-group      Wq1DHTFSRQWTH5m1-AA_-A /192.168.65.1   consumer-test-group-1 1            test:0
test-group      WyCVBVNBQsyeAFHMeYJCKw /192.168.65.1   consumer-test-group-1 1            test:0
test-group      aaeOrPSiQC-r69sdvoIsOQ /192.168.65.1   consumer-test-group-1 1            test:0

$ ./kafka-share-groups.sh --bootstrap-server localhost:9092 --describe --group test-group --state

GROUP           COORDINATOR (ID)          STATE           #MEMBERS
test-group      127.0.0.1:9092  (1)       Stable          5

토픽의 파티션 개수가 변경되면 어떻게 될까?

$ ./kafka-topics.sh --bootstrap-server localhost:9092 \
  --alter --topic test --partitions 2

$ ./kafka-share-groups.sh --bootstrap-server localhost:9092 --describe --group test-group
GROUP           TOPIC           PARTITION  START-OFFSET
test-group      test            0          13
test-group      test            1          -

$ bin ./kafka-share-groups.sh --bootstrap-server localhost:9092 --describe --group test-group --members
GROUP           CONSUMER-ID            HOST            CLIENT-ID             #PARTITIONS  ASSIGNMENT
test-group      531rie8GTeGXgr4mT0jViw /192.168.65.1   consumer-test-group-1 1            test:0
test-group      GMGiDkymRLqmH2sA_Py4yw /192.168.65.1   consumer-test-group-1 1            test:1
test-group      Wq1DHTFSRQWTH5m1-AA_-A /192.168.65.1   consumer-test-group-1 1            test:1
test-group      WyCVBVNBQsyeAFHMeYJCKw /192.168.65.1   consumer-test-group-1 1            test:0
test-group      aaeOrPSiQC-r69sdvoIsOQ /192.168.65.1   consumer-test-group-1 1            test:0

kafka-share-groups.sh에 partitions는 해당 컨슈머가 점유중인 파티션 개수를 뜻함. 그리고 assignment는 해당 컨슈머가 할당된 토픽+파티션의 조합을 나타냄. kafkaShareConsumer인 경우 assignment는 기존 방식과 다름. Share Coordinator가 가용상태에 따라 동적으로 정함.

Apache Kafka 4.1.0 docker-compose.yaml 실행

AndersonChoi — Fri, 12 Sep 2025 12:42:05 +0900

version: "3.8"

services:
  kafka:
    image: apache/kafka:4.1.0
    container_name: kafka41
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_LISTENERS: INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9091,CONTROLLER://0.0.0.0:9093
      KAFKA_ADVERTISED_LISTENERS: INTERNAL://127.0.0.1:9092,EXTERNAL://host.docker.internal:9091
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@localhost:9093
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_TRANSACTION_STATE_LOG_NUM_PARTITIONS: 1

파일 생성 후 다음 스크립트 실행

$ docker-compose up

이후 카프카 바이너리에서 실행

➜  kafka cd kafka_2.13-4.1.0
➜  kafka_2.13-4.1.0 ls
bin       config    libs      LICENSE   licenses  NOTICE    site-docs
➜  kafka_2.13-4.1.0 cd bin
➜  bin ./kafka-topics.sh --bootstrap-server localhost:9092 --topic test --create
Created topic test.

카프카 바이너리 다운로드

https://kafka.apache.org/downloads

Apache Kafka

Apache Kafka: A Distributed Streaming Platform.

kafka.apache.org

Openapi API 사용시 ⚠️선결제하면 안되는 이유.. - 돈낭비..

AndersonChoi — Wed, 10 Sep 2025 18:18:50 +0900

2024년 8월에 개인 프로젝트도 할겸 겸사겸사 openapi platform에서 선결제를 했었다. 그 당시 생각으로는 당장 사용하지 않더라도 차차 api key를 활용하면서 안전하게 돈이 빠져나가면 되겠다는 생각에 50달러(당시 7만원 정도)를 결제했었다.

그리고 어쩌다저쩌다 하다보니 2025년이 되었고, 다시 프로젝트를 할 일이 생겨서 예전에 충전했던 50달러 사용해야지~ 하고 들어갔더니

왠걸~ 내가 사용할 수 있는 금액이 0.00 달러로 찍혀있는게 아닌가;;;

그래서 내가 이걸 어디 낭비해서 다썻나..? 하고 payment history 내역을 찾아봐도 아무리 쓴 내역이 없다. 그러다가 들어간 곳은 credit grants. 여기서 수상한 state를 볼 수 있었는데 EXPIRE 라는 글자가 있는게 아닌가;

9월 1일에 expire 되었다는 충격적인 이야기 선결제한 금액이 다 쓰지 않으면 소멸되는 이런 듣도 보도 못한 정책에 화가 나서 구글링해보니 일부 레딧 사용자들도 빡쳐서 글을 올린 내용을 확인할 수 있었다.

https://community.openai.com/t/are-openai-credits-expiring/511215

Are OpenAI credits expiring?

Since dashboard change, I see no warning about credit expiration date. They forgot to put it, they placed it somewhere else or credits are not expiring any more?

community.openai.com

레딧에서 성토하는 댓글들

약관을 찾아봤더니

https://openai.com/ko-KR/policies/service-credit-terms/

아니 선결제하면서 누가 약관을 찾아보겠냐구용.. 실제로 4번 항목에 선불 서비스(선결제) 시 환불도 안될 뿐만 아니라 크래딧 구매 이후 1년 안에 소진을 못하면 소멸되는 특이한 정책을 사용하고 있었다. 이런 약관은 결제 페이지에서 쉽게 찾아볼 수 없으며, 수십장의 문서가 난무하는 약관을 찾아봐야 알 수 있다는 사실 ㅜㅜ 화난다

Ubuntu에서 JDK11 설치 후 기본값으로 설정하기

AndersonChoi — Sun, 25 May 2025 15:48:53 +0900

1) JDK 버전 확인

$ java -version

2) apt 업데이트, jdk11 설치

$ sudo apt update
$ sudo apt install openjdk-11-jdk -y

3) 버전 확인

$ java -version
openjdk version "11.0.27" 2025-04-15
OpenJDK Runtime Environment (build 11.0.27+6-post-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.27+6-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)

윈도우즈 wsl2 환경에서 로컬 카프카 브로커 연동하기

AndersonChoi — Sun, 25 May 2025 14:55:01 +0900

윈도우즈 wsl 환경에서 ipv6를 사용할 경우 localhost 또는 127.0.0.1 접근이 안될 경우가 있습니다. 이 경우 접근을 위해 다음과 같이 셋팅을 할 경우 접근이 가능합니다.

준비물

- wsl2

- Ubuntu

- Apache kafka 3.9.0

- Intellij CE

1) Apache kafka 3.9.0 다운로드 및 압축 풀기

https://kafka.apache.org/downloads 에서 3.9.0 바이너리를 다운로드 합니다.

이후 다운로드 받은 압축파일을 푼다.

2) Ubuntu 터미널 실행 및 다운로드 환경 접근

dvwy@dvwy:~$ cd /mnt/c/Users/choco/Downloads/kafka_2.12-3.9.0/kafka_2.12-3.9.0
dvwy@dvwy:/mnt/c/Users/choco/Downloads/kafka_2.12-3.9.0/kafka_2.12-3.9.0$

WSL 우분투 환경에서 윈도우즈 다운로드 디렉토리에 접근하기 위해서는 /mnt/c/Users/사용자이름/Downloads 로 접근하면 된다

3) config/server.properties 설정

$ vi config/server.properties
broker.id=0
listeners=PLAINTEXT://[::1]:9092

wsl 환경에 접근하기 위해 IPv6 기준 로컬호스트인 [::1] 을 입력한다. 이후 카프카 브로커를 실행한다.

1) 주키퍼 실행
$ bin/zookeeper-server-start.sh config/zookeeper.properties

2) 카프카 실행
$ bin/kafka-server-start.sh config/server.properties

4) kafka-console-producer.sh확인

$ bin/kafka-console-producer.sh --bootstrap-server [::1]:9092 --topic test
>a
>b
>c

[::1]:9092로 전송하여 데이터가 정상적으로 전달되는지 확인합니다.

5) /etc/hosts 수정

우분투 내에서 해당 host로 접근을 하는 추가 호스트를 만들기 위해 다음과 같이 수정합니다.

$ sudo vi /etc/hosts
[::1] my-kafka

// 이후 부터는 my-kafka:9092 로 접근 가능
$ bin/kafka-console-producer.sh --bootstrap-server my-kafka:9092 --topic test
>a
>b
>c

6) intellij CE 에서 접근 확인

public class SimpleProducer {
    private final static Logger logger = LoggerFactory.getLogger(SimpleProducer.class);
    private final static String TOPIC_NAME = "test";
    private final static String BOOTSTRAP_SERVERS = "[::1]:9092";

    public static void main(String[] args) {

        Properties configs = new Properties();
        configs.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP_SERVERS);
        configs.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        configs.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

        KafkaProducer<String, String> producer = new KafkaProducer<>(configs);

        String messageValue = "testMessage";
        ProducerRecord<String, String> record = new ProducerRecord<>(TOPIC_NAME, messageValue);
        producer.send(record);
        logger.info("{}", record);
        producer.flush();
        producer.close();
    }
}

bootstrap-server에 [::1]:9092 로 설정했을 경우 정상 접근됨을 확인합니다.

7) hosts 설정 수정 및 확인

메모장을 '관리자 권한으로 실행' 으로 실행합니다. 이후, \Windows\System32\drivers\etc\hosts 파일을 실행하여 다음과 같이 수정합니다.

이후 intellij CE에서 my-kafka:9092 로 접근해서 브로커와 연동되는지 확인합니다.

public class SimpleProducer {
    private final static Logger logger = LoggerFactory.getLogger(SimpleProducer.class);
    private final static String TOPIC_NAME = "test";
    private final static String BOOTSTRAP_SERVERS = "my-kafka:9092"; // 변경된 호스트

    public static void main(String[] args) {

... 생략

Sent auto-creation request for Set(__consumer_offsets) to the active controller 에러 해결 방법

AndersonChoi — Fri, 18 Apr 2025 12:49:50 +0900

로컬에서 테스트 도중에.. 발생한 에러이다.

Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller
Sent auto-creation request for Set(__consumer_offsets) to the active controller

너무 뜬금없기도 하고, 로컬에서 새로 띄운 카프카로 테스트 도중에 발생한 것이라서 더욱 당황스러웠다;;

겨우 찾아낸 링크 https://github.com/bitnami/charts/issues/19522#issuecomment-2341364442

[bitnami/kafka] messages are not getting generated in topics from producer to consumer · Issue #19522 · bitnami/charts

Name and Version bitnami/kafka What architecture are you using? amd64 What steps will reproduce the bug? I have no name!@kafka-controller-0:/$ kafka-topics.sh --bootstrap-server localhost:9092 --cr...

github.com

이유는 broker 셋팅시에 다음과 같이 설정을 안해서 그렇다

offsets.topic.replication.factor=1

이게 기본값이 3이라서 그런데, 로컬에서 브로커1개로 띄웠을때는 3개 rf로 만들 수 없기 때문에 무한반복 나는 것 ㅜㅜ

위 상황과 유사하게 transaction rf도 마찬가지로 로컬에서는 수정해줘야 한다;;

카프카4.0 부터는 eager rebalancing protocol이 삭제됩니다.

AndersonChoi — Fri, 28 Feb 2025 15:28:04 +0900

https://issues.apache.org/jira/browse/KAFKA-18839

[KAFKA-18839] Drop support for eager rebalancing in Streams - ASF JIRA

In 3.1 we deprecated the EAGER protocol in Kafka Streams (see KAFKA-13439). This ticket covers actually dropping this protocol in 4.0. Note that KAFKA-8575 covers the actual task cleanup we can do once we no longer have to support eager rebalancing, which

issues.apache.org

이 이슈(KAFKA-18839)는 Kafka Streams에서 기존에 사용되던 EAGER 재분배(eager rebalancing) 프로토콜에 대한 지원을 완전히 제거하는 작업입니다. Kafka Streams는 버전 3.1부터 EAGER 프로토콜을 사용 중단(deprecated)했고, 4.0 버전부터는 이 프로토콜을 아예 제거하기로 결정했습니다.

Why drop?

EAGER 프로토콜은 오래된 방식으로, 유지보수와 코드 복잡성을 증가시키는 요인이었습니다. 더 나은 성능과 안정성을 제공하는 COOPERATIVE 재분배 프로토콜로 전환하면서, EAGER 프로토콜은 불필요한 잔재물이 되었습니다. 단일 재분배 프로토콜에 집중하여 스트림즈 개선을 할 수 있게 됩니다.

이후 버전에서는?

이제부터 Kafka Streams는 오직 COOPERATIVE 재분배 프로토콜만 지원합니다.
기존에 EAGER 프로토콜을 사용하던 설정은 더 이상 유효하지 않으며, 시스템 구성 시 반드시 COOPERATIVE 프로토콜로 전환해야 합니다.

EAGER 리밸런싱 프로토콜이란?

컨슈머가 그룹에 합류/실패/종료 할 경우 그룹 코디네이터가 이를 감지하고 전체 파티션에 대해 Revoke(할당 취소 또는 연결 해제)를 수행. 이후, 그룹 코디네이터는 사전에 할당된 알고리즘(range, roundrobin 등)을 통해 재분배 수행합니다. 로직이 단순하지만 전체 파티션에 대해 재분배가 이루어져서 전체적으로 리밸런싱에 시간이 많이 소요되게 됩니다.

반면, COOPERATIVE는 부분적으로 파티션을 재분배하기 때문에 점진적 리밸런싱을 통해 컨슈머들에게 끼치는 영향을 최소화 합니다.

코드로 설정하는 방법?

뭐 별도로 있는 것은 아니고 Cooperative가 붙어있는 Rebalancing 을 선택하면 됨. CooperativeStickyAssignor가 대표적입니다.

public class CooperativeStickyAssignorExample {
    public static void main(String[] args) {
    
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        props.put("group.id", "cooperative-sticky-group");

        props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
        props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

        // cooperative rebalancing을 사용하기 위한 assignor 지정
        props.put("partition.assignment.strategy", 
            "org.apache.kafka.clients.consumer.CooperativeStickyAssignor");

[local macOS 환경] apache kafka(3.5.0기준) + redpanda/console 로 편하게 테스트 하기

AndersonChoi — Wed, 26 Feb 2025 17:24:31 +0900

로컬 환경에서 개발을 하다보면 항상 shell script로 사용하지만 좀 불편할때가 많습니다. redpanda에서는 console을 통해 apache kafka와 연동하는 웹 콘솔을 오픈소스로 제공하고 있습니다.

https://github.com/redpanda-data/console

GitHub - redpanda-data/console: Redpanda Console is a developer-friendly UI for managing your Kafka/Redpanda workloads. Console

Redpanda Console is a developer-friendly UI for managing your Kafka/Redpanda workloads. Console gives you a simple, interactive approach for gaining visibility into your topics, masking data, manag...

github.com

이를 사용하여 로컬에서 테스트하기 용이하도록 설정하는 방법을 알아보겠습니다.

1) Apache kafka binary setting & start

config/kraft/server.properties

# 소켓 서버가 수신할 주소와 포트를 설정합니다.
# 여기서 Kafka 브로커는 세 가지 리스너(INTERNAL, EXTERNAL, CONTROLLER)를 통해 외부와 내부의 연결 요청을 받게 됩니다.
# - INTERNAL: 내부 통신용으로, 모든 네트워크 인터페이스(0.0.0.0)에서 포트 9092로 수신합니다.
# - EXTERNAL: 외부 접속용으로, 모든 네트워크 인터페이스(0.0.0.0)에서 포트 9091로 수신합니다.
# - CONTROLLER: Kafka 클러스터의 컨트롤러 전용 리스너로, 주로 KRaft 모드에서 사용하며 포트 9093으로 수신합니다.
listeners=INTERNAL://0.0.0.0:9092,EXTERNAL://0.0.0.0:9091,CONTROLLER://:9093

# 브로커 간 통신에 사용할 리스너의 이름을 지정합니다.
# 이 설정은 Kafka 브로커들끼리 데이터 복제나 메타데이터 교환 등 내부 통신에 사용됩니다.
# 위의 예제에서는 INTERNAL 리스너를 사용하도록 지정되어 있습니다.
inter.broker.listener.name=INTERNAL

# 클라이언트에게 브로커의 접속 정보를 알릴 때 사용할 리스너 이름, 호스트명 및 포트를 지정합니다.
# 만약 이 설정을 지정하지 않으면, 기본적으로 listeners에 설정된 값이 사용됩니다.
# 예제에서는 다음과 같이 설정되어 있습니다:
# - INTERNAL 리스너는 127.0.0.1:9092로 광고되어 로컬 클라이언트(예: 로컬 셸 스크립트)에서 사용됩니다.
# - EXTERNAL 리스너는 host.docker.internal:9091로 광고되어 Docker 등 외부 환경에서 사용됩니다.
advertised.listeners=INTERNAL://127.0.0.1:9092,EXTERNAL://host.docker.internal:9091

# 리스너 이름과 보안 프로토콜 간의 매핑을 설정합니다.
# 각 리스너는 지정된 보안 프로토콜(예: PLAINTEXT, SSL 등)을 사용하게 되며,
# 이 설정을 통해 리스너별로 사용할 프로토콜을 명시할 수 있습니다.
# 위 예제에서는 다음과 같이 설정되어 있습니다:
# - CONTROLLER, INTERNAL, EXTERNAL 리스너는 모두 PLAINTEXT(암호화 없이 평문 통신)로 사용됩니다.
# - 그 외 SSL, SASL_PLAINTEXT, SASL_SSL 등 다른 프로토콜에 대한 매핑도 포함되어 있습니다.
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL,INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT

기본설정과 다르게 추가로 INTERNAL, EXTERNAL 이라는 리스너를 별도로 선언했고, 각각 PLAINTEXT의 특징을 가진다. 그리고 advertised.listeners를 통해 외부 환경에서 접근을 하게 되면 통신이 가능하도록 설정하였다.

이후 다음 스크립트를 통해 시작한다.

$ bin/kafka-server-start.sh config/kraft/server.properties

접근가능한 포트를 살펴보면 다음과 같다.

$ sudo lsof -iTCP -sTCP:LISTEN -n -P | grep java

java       1935 cory  114u  IPv6 0xb5d56fea76ceb187      0t0  TCP *:50654 (LISTEN)
java       1935 cory  138u  IPv6 0x120b860a979e4dc8      0t0  TCP *:9093 (LISTEN)
java       1935 cory  179u  IPv6 0x694fc65154f5a4d6      0t0  TCP *:9091 (LISTEN)
java       1935 cory  180u  IPv6 0xbaf49a6f1b8ea763      0t0  TCP *:9092 (LISTEN)

쉘스크립트로 접근 가능한지 확인 한다.

$ bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

2) Redpanda console start

$ docker run -p 8080:8080 -e KAFKA_BROKERS=host.docker.internal:9091 docker.redpanda.com/redpandadata/console:latest

3) Result

카프카에서 데이터 삭제는 어떻게 이루어 지는가>

AndersonChoi — Thu, 13 Feb 2025 19:55:35 +0900

카프카의 데이터의 삭제는 로그 세그먼트 단위로 삭제가 이루어진다. 노드(구 브로커)의 로그매니저는 시간(time) 또는 용량(size)에 따라 삭제여부를 결정한다. 시간 기반 정책에서는 레코드의 timestamp에 따라 달라진다. 해당 세그먼트 파일에 존재하는 가장 큰 timestamp 값(레코드 순서와는 무관)을 토대로 찾아낸다. 용량 기반 정책은 기본적으로 설정되지 않는다. 만약 설정된다면, 로그매니저는 가장 오래된 세그먼트 파일을 용량이 다 찼을때 부터 차례 대로 삭제하게 된다.

만약, 시간과 용량 두개의 설정이 동시에 설정된다면 먼저 도달하는 정책의 기준에 따라 삭제가 이루어진다. 언제든지 삭제가 될 수 있도록 copy-on-wirte 방식으로 세그먼트 목록을 사용한다. 이를 통해 삭제가 되는 동안에도 데이터 목록이 갑자기 변경되지 않아서 일관된 데이터 검색이 가능하다. 즉, 데이터 처리를 수행하면서도 안정적으로 삭제를 할 수 있다는 뜻~

https://kafka.apache.org/documentation/#impl_deletes

kafka 4.0부터는 스칼라 2.12가 더 이상 사용되지 않습니다.

AndersonChoi — Thu, 13 Feb 2025 18:39:24 +0900

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=181308218

KIP-751: Drop support for Scala 2.12 in Kafka 4.0 (deprecate in 3.0) - Apache Kafka - Apache Software Foundation

Status Current state: Adopted Discussion thread: link Vote thread: link JIRA: KAFKA-12930 - 이슈 세부사항 가져오는 중... 상태 (3.0) KAFKA-12895 - 이슈 세부사항 가져오는 중... 상태 (4.0) Please keep the discussion on the ma

cwiki.apache.org

Kafka는 현재 Scala 2.12와 2.13 버전에서 빌드되고 있지만, Scala 3.0 출시 이후 사용자들이 해당 버전 지원을 요청할 가능성이 큼. 여러 버전을 지원하는 것은 개발과 테스트 측면에서 비용이 크므로, Kafka 3.0에서 Scala 2.12 지원을 deprecate하고, Kafka 4.0에서 완전히 제거할 것을 제안함.

Kafka 3.0에서는 Scala 2.12 빌드 지원을 비권장하고 관련 문서를 업데이트할 예정이며, Kafka 4.0에서는 build.gradle과 dependencies.gradle에서 Scala 2.12 관련 코드를 삭제하고, README에서도 지원 여부를 제거하는 등의 변경을 수행할 계획임. Scala 2.12를 계속 사용해야 하는 사용자들은 Kafka 3.x에서 머물러야 하며, 최신 Scala 버전으로 업그레이드할 수 있을 때 Kafka 4.0을 사용할 수 있음. 다만, kafka core module 내 클래스들은 공식적인 공개 API는 아니지만 많은 프로젝트가 통합 테스트에서 이를 활용하고 있음.

https://issues.apache.org/jira/browse/KAFKA-12895 에서 본격적으로 삭제하는 작업이 이루어졌고 현재 모든 티켓이 머지 완료되었음.

그럼 스칼라3은 언제 배포되나?

스칼라 3은 이미 2021년 5월 14일에 배포되었음.

https://www.scala-lang.org/download/3.0.0.html

Scala 3.0.0

Other Releases You can find the links to prior versions or the latest development version below. To see a detailed list of changes for each version of Scala please refer to the changelog. Note that different major releases of Scala 2 (e.g. Scala 2.11.x and

www.scala-lang.org

2025년 1월 20일 3.6.3 릴리즈됨

https://www.scala-lang.org/download/3.6.3.html

Scala 3.6.3

www.scala-lang.org

standalone 카프카(kraft모드 in local) 실행 스크립트(1줄)

AndersonChoi — Tue, 11 Feb 2025 13:33:45 +0900

standalone 카프카(kraft모드 in local) 실행을 위한 준비와 실행

$ bin/kafka-storage.sh random-uuidcKUMbEGERui8cHUhwdc6XA$ bin/kafka-storage.sh format -t cKUMbEGERui8cHUhwdc6XA -c config/kraft/server.propertiesFormatting /tmp/kraft-combined-logs with metadata.version 3.6-IV2.$ bin/kafka-server-start.sh config/kraft/serv

blog.voidmainvoid.net

지난 포스팅에서 kraft모드를 로컬에서 실행할 때 차례대로 실행해야 하는 코드를 올린적이 있었는데, 불편해서 한줄로 요약한 버전을 올려봄!

$ UUID=$(bin/kafka-storage.sh random-uuid | tr -d '\n') && echo "Generated UUID: ${UUID}" && bin/kafka-storage.sh format -t "${UUID}" -c config/kraft/server.properties && bin/kafka-server-start.sh config/kraft/server.properties

bin/kafka-storage.sh random-uuid로 UUID를 생성하고 변수 UUID에 저장합니다.
생성된 UUID를 출력합니다.
해당 UUID를 사용하여 Kafka storage를 format 합니다.
마지막으로 Kafka 서버를 시작합니다.

4.0.0에서는?

$ UUID=$(bin/kafka-storage.sh random-uuid | tr -d '\n') && echo "Generated UUID: ${UUID}" && bin/kafka-storage.sh format  --standalone -t "${UUID}" -c config/server.properties && bin/kafka-server-start.sh config/server.properties

KIP-932: Queues for Kafka 조사

AndersonChoi — Sun, 12 Jan 2025 15:27:46 +0900

https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka

KIP-932: Queues for Kafka - Apache Kafka - Apache Software Foundation

cwiki.apache.org

KIP-932는 Kafka에 새로운 Queue Topic을 도입하여 기존 Topic/Partition 모델의 한계를 보완하고, 메시지를 단일 Consumer에 할당하는 Single-Consumer Semantics를 제공하려는 제안임. Queue Topic은 기존 Kafka Topic과 달리 FIFO(First-In-First-Out) 메시지 순서를 보장하며, 메시지 처리의 동적 확장성을 제공함.

프로듀서는 어떻게 다르게 동작하나?

프로듀서의 동작은 기존과 거의 동일하지만, 파티션 키가 불필요하다. Queue Topic이라고 불리는 이 토픽은 전체에서 순서를 유지하도록 설계되어 있다.

Queue 토픽

- QUEUE 모드라는 것을 명시적으로 선언하지 않아도 됨. 이런 동작을 위해서 컨슈머측에서만 따로 그룹 설정시 정의하면 됨.

- FIFO 순서보장 : 전체 Queue에 대해 FIFO 유지. 파티션들을 단일 파티션으로 보이게 하는 것.

- 내부적으로 파티션을 사용하긴하지만 컨슈머입장에서는 단일 큐로 보임.

컨슈머가 동작하게 하는 방법?

kafka-console-consumer.sh --bootstrap-server <broker-address> \
    --topic <topic-name> \
    --group <share-group-name> \
    --consumer-property group.type=share

GroupType에 "share"라는 ENUM이 새로 만들어지게됨. 그리고 kafka-console-share-consumer.sh라는 새로운 쉘 명령어가 만들어질듯함.

Option	Description
--bootstrap-server <String: server to connect to>	REQUIRED: The server(s) to connect to.
--consumer-config <String: config file>	Consumer config properties file. Note that [consumer-property] takes precedence over this config.
--consumer-property <String: consumer_prop>	Consumer property in the form key=value.
--enable-systest-events	Log lifecycle events of the consumer in addition to logging consumed messages. (This is specific for system tests.)
--formatter <String: class>	The name of a class to use for formatting Kafka messages for display. (default: kafka.tools.DefaultMessageFormatter)
--formatter-config <String: config file>	Config properties file to initialize the message formatter. Note that [property] takes precedence of this config.
--group <String: share groud id>	The share group id of the consumer. (default: "console-share-consumer" )
--help	Print usage information.
--key-deserializer <String: deserializer for keys>	The name of the class to use for deserializing keys.
--max-messages <Integer: num_messages>	The maximum number of messages to consume before exiting. If not set, consumption is continual.
--property <String: prop>	The properties to initialize the message formatter. Default properties include: print.timestamp=true\|false print.key=true\|false print.offset=true\|false print.delivery=true\|false print.partition=true\|false print.headers=true\|false print.value=true\|false key.separator=<key.separator> line.separator=<line.separator> headers.separator=<line.separator> null.literal=<null.literal> key.deserializer=<key.deserializer> value.deserializer=<value.deserializer> header.deserializer=<header.deserializer> Users can also pass in customized properties for their formatter; more specifically, users can pass in properties keyed with 'key.deserializer.', 'value.deserializer.' and 'headers.deserializer.' prefixes to configure their deserializers.
--reject	If specified, messages are rejected as they are consumed.
--reject-message-on-error	If there is an error when processing a message, reject it instead of halting.
--release	If specified, messages are released as they are consumed.
--timeout-ms <Integer: timeout_ms>	If specified, exit if no message is available for consumption for the specific interval.
--topic <String: topic>	REQUIRED: The topic to consume from.
--value-deserializer <String: deserializer for values>	The name of the class to use for deserializing values.
--version	Display Kafka version.

실제 코드는 어떻게 될까?

아직 모든게 만들어지지 않아서 앞으로 변화될 여지는 있지만, 아래와 같이 설정될 것으로 추정됨.

import org.apache.kafka.clients.consumer.KafkaShareConsumer;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.ShareConsumerConfig;

import java.time.Duration;
import java.util.Collections;

public class SharedGroupConsumer {
    public static void main(String[] args) {
        // Kafka Share Consumer 설정
        ShareConsumerConfig config = new ShareConsumerConfig();
        config.setBootstrapServers("localhost:9092");
        config.setGroupId("my-shared-group");
        config.setTopic("my-queue-topic");

        // KafkaShareConsumer 생성
        try (KafkaShareConsumer<String, String> consumer = new KafkaShareConsumer<>(config)) {
            // 메시지 처리 루프
            while (true) {
                ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
                records.forEach(record -> {
                    System.out.printf("Consumed record: key = %s, value = %s, offset = %d%n",
                            record.key(), record.value(), record.offset());
                    // 메시지 처리 후 Ack 전송
                    consumer.ack(record);
                });
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

trunk branch에 merge되고 있으므로 trunk에서 확인 가능

https://github.com/apache/kafka/tree/trunk

GitHub - apache/kafka: Mirror of Apache Kafka

Mirror of Apache Kafka. Contribute to apache/kafka development by creating an account on GitHub.

github.com

trino에서 java.sql.SQLException: Unrecognized connection property 'url' 에러가 나는 이유와 해결 방법

AndersonChoi — Wed, 16 Oct 2024 20:12:36 +0900

spark jdbc를 통해 trino를 접근하기 위해 아래와 같은 코드를 짤 수 있다.

import org.apache.spark.sql.{DataFrame, SparkSession}
import java.util.Properties

// Spark 세션 생성
val spark = SparkSession.builder()
  .appName("Spark Trino JDBC Example")
  .getOrCreate()

// JDBC URL 설정
val jdbcUrl = "jdbc:trino://<trino-host>:<port>/<catalog>/<schema>"

// Trino JDBC 속성 설정
val connectionProperties = new Properties()
connectionProperties.setProperty("user", "<your-user>")
connectionProperties.setProperty("password", "<your-password>")
connectionProperties.setProperty("driver", "io.trino.jdbc.TrinoDriver")
connectionProperties.setProperty("SSL", "true") // 필요 시 SSL 활성화

// Trino 테이블 또는 SQL 쿼리 설정
val hiveTable = "(SELECT * FROM your_table LIMIT 10) AS tmp"

// DataFrame 생성 및 데이터 로드
val dfJdbc: DataFrame = spark.read
  .jdbc(jdbcUrl, hiveTable, connectionProperties)

// 결과 출력
dfJdbc.show()

문제는 실행했을 때 아래와 같은 에러가 발생할 경우이다.

java.sql.SQLException: Unrecognized connection property 'url'.

위 에러는 url이라는 key가 trino에 인입되어 발생하는 에러인데, trino에서는 용인되지 않는 설정값이 추가되면 warning도 아니고 에러로 뱉어버린다.......

spark에서는 url이라는 key에 value를 jdbc:trino:// 로 시작되는 값을 강제 주입하기 때문인데, 이는 3.2.x대 버전까지 이어져 왔다.

해결방법

이후 https://issues.apache.org/jira/browse/SPARK-36163 에서 해당 문제를 해결하고자 했고, 그 결과로 3.3.x 이상 버전에서는 해당 에러는 더이상 발생하지 않는다 ㅠ

Spark 개발시, main/resources 패키지에 hdfs-site.xml, core-site.xml 등을 넣는 이유

AndersonChoi — Tue, 13 Aug 2024 13:42:17 +0900

main/resources 디렉터리는 Apache Maven이나 SBT와 같은 빌드 도구를 사용하는 프로젝트에서 애플리케이션의 리소스 파일을 저장하는 표준 위치이다. 이 디렉터리에 배치된 파일들은 컴파일된 클래스와 함께 JAR 파일에 포함되며, 런타임에 애플리케이션에서 사용될 수 있다.

HDFS 설정 파일 (hdfs-site.xml)

hdfs-site.xml 파일은 Hadoop 분산 파일 시스템(HDFS)의 설정을 정의한다. 이 파일에는 HDFS 클러스터의 동작을 제어하는 다양한 구성 옵션이 포함되어 있다. 예를 들어, 네임노드의 주소, 데이터 디렉터리, 복제 수 등의 정보가 포함될 수 있다.

main/resources 디렉터리에 배치하는 이유

main/resources는 애플리케이션의 모든 리소스 파일(예: 설정 파일, 정적 파일, 템플릿 등)을 저장하는 표준 위치다. 이러한 파일들은 컴파일된 애플리케이션의 클래스패스에 자동으로 포함되므로, 애플리케이션 코드에서 손쉽게 접근할 수 있다. Spark 애플리케이션이 실행될 때, main/resources에 있는 hdfs-site.xml 파일이 자동으로 클래스패스에 포함되므로, 별도의 설정 없이도 Spark 애플리케이션이 해당 파일을 로드하고 사용할 수 있다.

standalone 카프카(kraft모드 in local) 실행을 위한 준비와 실행

AndersonChoi — Sun, 23 Jun 2024 23:44:20 +0900

$ bin/kafka-storage.sh random-uuid
cKUMbEGERui8cHUhwdc6XA

$ bin/kafka-storage.sh format -t cKUMbEGERui8cHUhwdc6XA -c config/kraft/server.properties
Formatting /tmp/kraft-combined-logs with metadata.version 3.6-IV2.

$ bin/kafka-server-start.sh config/kraft/server.properties
$ bin/kafka-broker-api-versions.sh --bootstrap-server localhost:9092 --version
3.6.2

카프카 바이너리 다운로드 링크 : https://kafka.apache.org/downloads

Apache Kafka

Apache Kafka: A Distributed Streaming Platform.

kafka.apache.org

bin/kafka-storage.sh 로 따로 파일과 디렉토리를 만들어야 하는 이유

bin/kafka-storage.sh 스크립트를 사용하여 별도의 파일과 디렉토리를 만드는 이유는 성능 최적화, 데이터 관리 용이성, 안정성 및 복구 편의성을 확보하기 위함.

scala에러 Unable to make private java.nio.DirectByteBuffer 해결 방법

AndersonChoi — Mon, 3 Jun 2024 19:54:14 +0900

Unable to make private java.nio.DirectByteBuffer(long,int) accessible: module java.base does not "opens java.nio"

와 같은 코드가 떠서 놀랬다. intellij에서 sbt로 빌드한 스칼라코드가 실행되지 않을 때가 있는데, 이 오류는 jvm컴파일 버전 때문에 생기는 이슈이다.

https://stackoverflow.com/questions/70153343/unable-to-make-private-java-nio-directbytebufferlong-int-accessible

Unable to make private java.nio.DirectByteBuffer(long,int) accessible

I'm using Python to access Databricks through databricks-connect. Behind the wall, this uses spark which is indeed java based so in order to use this, I need java. The JDK has been downloaded (vers...

stackoverflow.com

해결방법

$ brew install --cask adoptopenjdk/openjdk/adoptopenjdk8

와 같이 jdk8을 깔고 해당 버전을 빌드버전으로 설정하면 된다. 또는 Intellij에서는 project structure에서 다음과 같이 변경하면 된다.

아파치 플링크는 2.0 버전부터는 더이상 scala API를 지원하지 않습니다.

AndersonChoi — Fri, 10 May 2024 22:10:18 +0900

https://cwiki.apache.org/confluence/display/FLINK/FLIP-265+Deprecate+and+remove+Scala+API+support

FLIP-265 Deprecate and remove Scala API support - Apache Flink - Apache Software Foundation

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast). Motivation Apache Flink offers APIs for building your Flink application using the DataStream and Table API. These are offered in Java an

cwiki.apache.org

플링크1.15버전까지는 스칼라와 강결합되어 있는 코드를 제공했습니다. 그러나 점차 스칼라 관련 기여가 적어지고 있는 상황에서 더 이상 스칼라에 대한 직접적인 api 지원이 의미 없다고 생각되어서 더 이상 지원을 하지 않는 방향의 의견이 나왔습니다.

이에 따라 플링크 PMC(Project Management Committee)의 투표를 받았고, 거의 만장일치로 승인이 떨어졌습니다. vote 관련 링크는 다음에서 볼 수 있습니다. https://lists.apache.org/thread/qfz4opcbc2p59fhmymncxyzxb70cn098

https://lists.apache.org/thread/qfz4opcbc2p59fhmymncxyzxb70cn098

lists.apache.org

플링크 프로젝트 운영 규칙(Flink Bylaws)에 따라 PMC는 이런 사안에 대해 투표를 해야만 합니다. 투표에 대한 상세한 사항은 https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws 에서 확인할 수 있습니다.

무엇이 바뀌나?

가장 크게 바뀌는 부분은 직접적인 scala api가 없어진다는 부분입니다. scala는 tuple, 간결한 문법, collection 등 다양한 장점을 가진 언어이고 이를 지원함으로써 스칼라를 사용하는 유저들은 플링크를 더욱 scala 친화적으로 사용할 수 있었습니다. 동일한 jvm 라이브러리라고 하더라도 언어가 다르면 지저분해지기 때문에 이런 부분은 스칼라 유저들에게 친숙하게 다가왔습니다. 스파크를 사용하던 스칼라 유저는 이런 점이 반가웠으리라 생각됩니다.

Flink Scala API를 활용한 예제

import org.apache.flink.api.scala._

object WordCountScala {
  case class WordWithCount(word: String, count: Int)

  def main(args: Array[String]): Unit = {
    val env = ExecutionEnvironment.getExecutionEnvironment

    val text = env.fromElements(
      "Who's there?",
      "I think I hear them. Stand, ho! Who's there?"
    )

    val counts = text
      .flatMap(_.toLowerCase.split("\\W+"))
      .filter(_.nonEmpty)
      .map(word => WordWithCount(word, 1))
      .groupBy(_.word)
      .reduce { (a, b) => WordWithCount(a.word, a.count + b.count) }

    counts.print()
  }
}

위와 같이 scala flink로 사용한 구문은 무척이나 간결합니다. 그럼 자바 라이브러리로 구현하면 어떻게 될까요?

// Java Tuple2를 사용하는 예제
import org.apache.flink.api.common.functions.FlatMapFunction
import org.apache.flink.api.java.tuple.Tuple2
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.util.Collector

object JavaStyleWordCount {
  def main(args: Array[String]): Unit = {
    val env = StreamExecutionEnvironment.getExecutionEnvironment

    val text = env.socketTextStream("localhost", 9999)

    val counts = text
      .flatMap(new FlatMapFunction[String, Tuple2[String, Integer]] {
        override def flatMap(value: String, out: Collector[Tuple2[String, Integer]]): Unit = {
          for (word <- value.toLowerCase.split("\\W+")) {
            if (word.nonEmpty) out.collect(new Tuple2(word, 1))
          }
        }
      })
      .keyBy(0)
      .sum(1)

    counts.print()
    env.execute("Java Style Word Count in Scala")
  }
}

JAVA api를 그대로 사용하면 코드의 구조 자체가 자바에 의존적이기 때문에 상대적으로 읽기 어렵고 장황해집니다. 예를 들자면, Java의 Tuple 클래스를 사용하거나, Collector를 사용한 사용자 정의 함수 정의가 필요할 때 코드가 더 복잡해집니다. 그리고 Java POJO를 사용하면 타입 정보가 감소되고 간결한 코드 작성이 어려워집니다. Scala에서는 케이스 클래스를 사용하여 더욱 타입 안전하고 간결한 코드를 작성할 수 있습니다.

Redis-go를 interface화 하여 사용하기

AndersonChoi — Mon, 26 Feb 2024 23:57:05 +0900

golang에서 Redis를 사용할 때는 보통 go-redis 라이브러리를 많이 사용합니다. 이 때, 바로 메서드를 사용하기 보다는 내부 비즈니스 로직이 포함된 RedisClient 인터페이스를 만들어 사용하곤 하는데요. 아래는 그 예시 입니다.

redis.go

package main

import (
    "context"
    "fmt"
    "github.com/go-redis/redis/v8" // go-redis import
)

// RedisClientInterface 인터페이스 정의
type RedisClientInterface interface {
    Set(key string, value interface{}) error
    Get(key string) (string, error)
}

// RedisClient 구조체 정의
type RedisClient struct {
    client *redis.Client
}

// NewRedisClient 함수는 RedisClient 인스턴스를 초기화합니다.
func NewRedisClient(addr string) *RedisClient {
    return &RedisClient{
        client: redis.NewClient(&redis.Options{
            Addr: addr, // Redis 서버 주소
        }),
    }
}

// Get 메서드는 주어진 키에 대한 값을 Redis에서 검색합니다.
func (c *RedisClient) Get(key string) (string, error) {
    ctx := context.Background()
    result, err := c.client.Get(ctx, key).Result()
    if err != nil {
        return "", err
    }
    return result, nil
}

main.go

func main() {
    // RedisClient 인스턴스 생성
    redisClient := NewRedisClient("localhost:6379")

    // Set 예시
    err := redisClient.Set("key", "value")
    if err != nil {
        fmt.Println("Set error:", err)
        return
    }

    // Get 예시
    result, err := redisClient.Get("key")
    if err != nil {
        fmt.Println("Get error:", err)
        return
    }

    fmt.Println("Get result:", result)
}

위와 같은 방식은 일반적으로 많이 사용되는 Struct 선언 구문입니다. 하지만, Testify와 같은 도구로 테스트를 할 때는 RedisClient를 Interface화 해야하는데, 이 때는 RedisClientInterface를 따로 정의해야 합니다. 아래는 그 예시입니다.

// RedisClientInterface 정의
type RedisClientInterface interface {
    Get(key string) (string, error)
}

단순히 위와 같이 정의만 하더라도 interface를 사용할 수 있습니다. 다만, main.go에서 사용할 때는 RedisClient를 파라미터로 받되, 형을 RedisClientInterface로 받아야만 인터페이스로 사용할 수 있습니다. 아래는 그 예시입니다.

// CacheOperation 함수는 RedisClientInterface를 사용하여 캐시 작업을 수행합니다.
func CacheOperation(redisClientInterface를 RedisClientInterface, key string, value string) error {
    if err := redisClientInterface를.Set(key, value); err != nil {
        return fmt.Errorf("failed to set value: %w", err)
    }
    return nil
}

func main() {
    // RedisClient 인스턴스 생성
    redisClient := NewRedisClient("localhost:6379")

    // CacheOperation 함수를 사용하여 캐시 작업 수행
    key := "sampleKey"
    value := "sampleValue"
    if err := CacheOperation(redisClient, key, value); err != nil {
        fmt.Println("Cache operation error:", err)
    }
}

위와 같이 CachOperation은 RedisClientInterface를 받아서 사용하게 됩니다. 이렇게 사용할 경우, 상위 레벨 로직으로 부터 분리하고 코드의 유연성과 테스트의 용이성이 향상될 수 있습니다.

카프카 컨슈머의 auto.offset.reset 옵션을 반드시 earliest로 변경해야 하는 이유

AndersonChoi — Mon, 5 Feb 2024 14:34:32 +0900

auto.offset.reset는 카프카 컨슈머를 다루는데 있어 아주 중요한 부분입니다. 해당 옵션이 가질 수 있는 값은 다음과 같습니다.

earliest : 마지막 커밋 기록이 없을 경우, 가장 예전(낮은 번호 오프셋) 레코드부터 처리
latest : 마지막 커밋 기록이 없을 경우, 가장 최근(높은 번호 오프셋) 레코드부터 처리
none : 커밋 기록이 없을 경우 throws Exception

해당 옵션은 필수 옵션이 아닌 선택 옵션으로서 입력을 하지 않으면 자동으로 latest로 설정됩니다. 일반적으로 컨슈머를 운영할 때 이 옵션을 건드리는 경우는 거의 드문데요. 그러다보니 기본값인 latest로 설정할 경우 우리도 모르게 운영 중 데이터의 유실이 발생할 수 있다는 사실을 놓치기도 합니다.

그러다보니, 예전과 다르게 해당 옵션은 다음과 같은 경고문이 붙게 되었습니다.

Note that altering partition numbers while setting this config to latest may cause message delivery loss since producers could start to send messages to newly added partitions (i.e. no initial offsets exist yet) before consumers reset their offsets.

왜 데이터가 유실 될까?

파티션의 개수가 변경될 경우 컨슈머는 metadata.max.age.ms 만큼 메타데이터 리프래시 기간 이후 리밸런싱이 일어나면서 파티션 할당과정을 거치게 됩니다. 문제는 메타데이터 리프레시(파티션 변경 여부를 알아차리는 시간) 기간동안 새로운 파티션에 데이터가 들어올 수 있다는 사실입니다. 다음 그림은 컨슈머의 auto.offset.reset이 latest일 경우 데이터가 일부 유실되는 모습을 그렸습니다.

1) 파티션2개인 토픽에 컨슈머 2개가 연동되어 있는 그림

2) 파티션을 3개로 늘린 그림

3) 새로운 파티션에 데이터가 들어가는 그림

4) 메타데이터가 리프래시 되고 리밸런싱이 일어나는 그림

5) 리밸런싱이 완료되고 가장 최근 데이터(오프셋 2번)부터 컨슈머가 가져가는 그림

위와 같은 상황에서 1,2 오프셋에 해당하는 레코드들이 컨슈머에서 처리되지 않고 지나간 것을 알 수 있습니다. 이는 데이터 양이 적을때는 유실량이 겨우 2개 밖에 안되? 라고 생각할 수도있겠지만, 초당 1억건 이상 들어올 때는 이 데이터양이 매우 많을 수 있습니다. 또한 metadata의 리프래시 주기에 따라서도 유실량이 달라 질 수 있습니다.

사실상 컨슈머가 알 수 있는 warning 구문 조차 없기 때문에 많은 개발자들은 유실이 되었는지도 모르고 지나갈 때가 많습니다.

유실을 막기 위 해서 어떻게 해야 하나

파티션 증설에 따른 유실을 막기 위해서는 단순히 컨슈머의 옵션을 auto.offset.reset earliest로 설정하는 것이 가장 손쉬운 방법입니다. 그러나 개발자가 컨슈머를 운영하는 상황에서 offset reset을 다 챙기지 못하는 상황이 많고, 파티션을 늘리면 당연히 처음 데이터부터 가져간다고 이해하는 경우가 많기 때문에 오해를 일으키기 좋습니다.

이에 대해 많은 카프카 개발자들은 우려를 표했고 카프카 3.6(23년 10월)이 되어서야 드디어 경고 문구를 DOCS에 추가하는 수준에 끝나게 되었습니다. 관련 PR은 다음과 같습니다. DOCS에 추가된지 6개월도 안되었으니 이미 많은 카프카 컨슈머 개발자들은 이를 놓쳤을거라 생각됩니다.

https://github.com/apache/kafka/pull/10167/files

KAFKA-12261: Mention about potential delivery loss on increasing partition when auto.offset.reset = latest by ocadaruma · Pull

Splitting partitions while setting auto.offset.reset to latest may cause message delivery loss, but users might not be aware about that since currently it isn't documented anywhere. Committer Check...

github.com

이에 대한 대응 책으로 텐센트 개발자 hudeqi는 기존 컨슈머 그룹의 auto.offset.reset을 기존 earliest, latest, none에서 더 세분화하여 개발자로 하여금 오해가 없이 운영할 수 있도록 하는 방안을 KIP-842에서 제안했고 이는 현재도 논의 진행 중에 있습니다.

https://cwiki.apache.org/confluence/display/KAFKA/KIP-842%3A+Add+richer+group+offset+reset+mechanisms

KIP-842: Add richer group offset reset mechanisms - Apache Kafka - Apache Software Foundation

Status Current state: Under Discuss JIRA: here Pull Request: here Discussing thread: here Vote thread: here Motivation When the server expands partitions for a topic, the producer firstly perceives the expansion, and some data is written in the newly e

cwiki.apache.org

애석하게도 이런 논의가 진행되는 discusstion thread를 살펴보면 이렇게 변경하는 안에 대해 그다지 호의적이지는 않은 것 같습니다. latset, earliest, none 외에 추가하는 것이 개발자로 하여금 더 어렵게 만들고, seekToEnd()와 같은 컨슈머에서 다룰 수 있는 오프셋 지정 메서드들이 제공되기 때문입니다.

For the original use-case you mentioned, that you want to start from "latest" when the app starts, but if a new partition is added you want to start from "earliest" it seem that the right approach would be to actually configure "earliest", and when the app is deployed for the first time, use a `seekToEnd()` to avoid triggering auto-offset-reset?
- Matthias J. Sax

아무쪼록 해당 기능에 대해 잘 이해하고 예상치 못한 데이터 유실을 경험하지 않길 바라는 마음에 작성해 보았습니다.

json value가 null일때 golang은 Unmarshal을 잘 할 수 있을까?

AndersonChoi — Thu, 18 Jan 2024 16:54:44 +0900

golang은 JSON Format 데이터를 struct로 변환할 수 있는데 이것을 Unmarshal이라고 부릅니다. 예를 들어 다음과 같은 함수로 구현될 수 있습니다.

func getStructFromJSON(jsonData string, valuePtr interface{}) error {
	return json.Unmarshal([]byte(jsonData), valuePtr)
}

jsonData : json포맷으로된 String 데이터
valuePtr : struct타입

예를 들어 다음과 같이 호출할 수 있습니다.

type SampleStruct struct {
	A int32 `json:"a"`
	B int32 `json:"b"`
}

func main() {

	var valuePtr SampleStruct
	err := getStructFromJSON("{\"a\": 13,\"b\": 11}", &valuePtr)
	if err != nil {
		log.Print(err)
	}
	log.Print(valuePtr.A)
	log.Print(valuePtr.B)
}

결과는 다음과 같습니다.

2024/01/01 16:50:25 13
2024/01/01 16:50:25 11

그런데 만약에 숫자 대신에 null이 들어가 있으면 어떻게 될까요?

{"a": 13,"b": null}

상기 데이터가 들어갈 경우 결과는 다음과 같습니다.

2024/01/01 16:51:28 13
2024/01/01 16:51:28 0

0으로 초기화 되는 것을 알 수 있습니다.

만약 0으로 초기화가 아니라 null로 초기화 하고 싶다면?

golang에서 int32는 nil 표현이 불가능합니다. 만약 nil을 표현하고 싶다면 pointer 타입으로 정의해야 합니다.

type SampleStruct struct {
	A int32  `json:"a"`
	B *int32 `json:"b"`
}
func main() {

	var valuePtr SampleStruct
	err := getStructFromJSON("{\"a\": 13,\"b\": null}", &valuePtr)
	if err != nil {
		log.Print(err)
	}
	log.Print(valuePtr.A)
	log.Print(valuePtr.B)
}

실행시 결과는 다음과 같습니다.

2024/01/01 16:53:08 13
2024/01/01 16:53:08 <nil>

JSON은 null을 키값으로 가질 수 있을까?

AndersonChoi — Thu, 18 Jan 2024 15:21:40 +0900

JSON을 정의할 때 null을 키로 가질 수 있을지 궁금해서 jsonlint.com을 사용하여 테스트를 진행했습니다.

https://jsonlint.com/

JSON Online Validator and Formatter - JSON Lint

Loading... About the JSONLint Editor JSONLint is a validator and reformatter for JSON, a lightweight data-interchange format. Copy and paste, directly type, or input a URL in the editor above and let JSONLint tidy and validate your messy JSON code. What Is

jsonlint.com

상기 사이트는 valid한 JSON 데이터인지 확인해 줍니다.

테스트용 데이터는 다음과 같습니다.

{
  null:""
}

결과는

JSON의 key로 STRING이 있어야 하는데 NULL이 있어서 invalid json으로 결과값이 나왔습니다.

왜그럴까요?

https://www.json.org/json-ko.html

JSON

JSON (JavaScript Object Notation)은 경량의 DATA-교환 형식이다. 이 형식은 사람이 읽고 쓰기에 용이하며, 기계가 분석하고 생성함에도 용이하다. JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1

www.json.org

json은 name/value 형태의 쌍으로 collection 타입의 element로 ㄱ성되어 있고 이 element는 string으로 이루어져야 합니다. Value에는 null이 들어갈 수 있지만 name에는 반드시 string이 들어가야만 합니다

You aren't going to Need it(YAGNI). 그 기능이 필요할 때 만들어라!

AndersonChoi — Thu, 4 Jan 2024 17:46:22 +0900

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

You aren't gonna need it - Wikipedia

From Wikipedia, the free encyclopedia Software engineering principle "You aren't gonna need it"[1][2] (YAGNI)[3] is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary.[4] Other

en.wikipedia.org

Always implement things when you actually need them, never when you just foresee that you [will] need them. - Ron Jeffries

간단한 작업임에도 불구하고 거대한 개발로 인해 지연되고 있음.

"You Aren't Gonna Need It" (YAGNI) 원칙은 소프트웨어 개발에서 중요한 개념으로, 개발자들이 실제 필요하지 않은 기능을 미리 구현하지 않도록 하는 것이 기본 원칙입니다. 특히 애자일 개발 방법론에서 강조되는데, 애자일 방식으로 개발을 할 때 현재의 요구사항에 집중하고 불필요한 작업을 피하는 것이 핵심아라 볼 수 있습니다.

원칙

현재 필요한가?: YAGNI는 개발자가 현재의 요구사항에만 집중하도록 도와줍니다. 이는 추측에 의한 기능 개발을 방지하고, 현재 사용자의 필요에 직접적으로 대응하는 기능에 집중하게 합니다.
개발로 인해 시간과 자원의 효율적으로 변하는가?: 불필요한 기능을 개발하는 것은 시간과 자원의 낭비를 의미합니다. YAGNI를 따름으로써, 개발 팀은 더 중요하고 긴급한 작업에 집중할 수 있습니다.
유지보수의 용이성이 커지는가? : 덜 복잡한 코드는 유지보수하기가 더 쉽습니다. 불필요한 코드가 없으면 버그 발생 가능성이 줄어들고, 코드에 대한 이해와 수정이 더 간단해집니다.
반응성과 유연성이 좋아지는가? : 미래의 변화에 더 잘 대응할 수 있습니다. 불필요한 기능을 구현하지 않음으로써, 나중에 요구사항이 변경되었을 때 이에 더 빠르게 반응하고 필요한 기능을 추가할 수 있습니다.

한계

장기적 비전 부족: 때때로 YAGNI는 장기적인 시스템 설계나 아키텍처의 발전을 간과할 수 있습니다. 이는 추후 시스템이 확장될 때 문제가 될 수 있습니다.
과도한 단순화: 일부 경우에는 YAGNI가 너무 강조되어 시스템의 확장성이나 유연성이 무시될 수 있습니다. 이는 장기적으로 더 많은 작업을 초래할 수 있습니다.

고려사항

균형 잡힌 접근: YAGNI 원칙은 상황에 따라 다르게 적용되어야 합니다. 현재의 필요와 미래의 가능성 사이에 균형을 찾는 것이 중요합니다.
팀과의 의사소통: 개발 팀 내에서 YAGNI 원칙에 대한 명확한 이해와 합의가 필요합니다. 이를 통해 과도한 기능 개발을 방지하고 프로젝트의 방향성을 유지할 수 있습니다.

맥킨지 연구에 의하면 기업들은 프로덕트 개발비를 50%초과 지출하면 세후 이익을 3.5% 손실하는 반면, 6개월 늦게 출시하면 33%를 잃는다고 한다. - 찰스 H. 하우스, 레이먼드 L. 프라이스

map[string]interface 데이터를 avro 포맷으로 파일 저장하는 방법

AndersonChoi — Tue, 28 Nov 2023 12:30:29 +0900

package main

import (
	"encoding/json"
	"fmt"
	"github.com/linkedin/goavro"
	"os"
	"time"
)

func main() {
	// Avro 스키마 정의
	schemaJSON := `{
	   "type": "record",
	   "name": "Example",
	   "fields": [
	       {"name": "username", "type": "string"},
	       {"name": "age", "type": "int"}
	   ]
	}`

	codec, err := goavro.NewCodec(schemaJSON)
	if err != nil {
		panic(err)
	}

	// 파일 생성
	file, err := os.Create("avro_data.avro")
	if err != nil {
		panic(err)
	}
	defer file.Close()

	// Avro 데이터 생성 및 파일에 적재
	ticker := time.NewTicker(1 * time.Second)
	defer ticker.Stop()

	for range ticker.C {
		// 예시 데이터 생성
		data := map[string]interface{}{
			"username": "JohnDoe",
			"age":      30,
		}

		b, err := json.Marshal(data)
		if err != nil {
			panic(err)
		}
		fmt.Println(string(b))

		//Avro 데이터 생성
		native, _, err := codec.NativeFromTextual(b)
		if err != nil {
			panic(err)
		}

		binaryData, err := codec.BinaryFromNative(nil, native)
		if err != nil {
			panic(err)
		}

		// 파일에 Avro 데이터 쓰기
		if _, err := file.Write(binaryData); err != nil {
			panic(err)
		}

		// 줄 바꿈
		if _, err := file.WriteString("\n"); err != nil {
			panic(err)
		}

		fmt.Println("Avro 데이터를 파일에 적재했습니다.")
	}
}

위 코드에서 중요한 것은 NativeFromTextual 메서드와 json.Marshal을 통해 byte로 변환하는 부분입니다. NativeFromTextual는 Avro 데이터를 지정한 포맷을 기반으로 데이터를 저장하는데 사용됩니다. 그런데 이 메서드를 받는 파라미터는 byte이므로 반드시 byte로 변환해야만 합니다.

이를 위한 json.Marshal을 사용하여 데이터를 byte로 변환하여 avro 형태에 맞는 codec을 통해 변환시키는데 사용됩니다.

참고 문헌

https://pkg.go.dev/github.com/linkedin/goavro/v2#section-readme

goavro package - github.com/linkedin/goavro/v2 - Go Packages

Discover Packages github.com/linkedin/goavro/v2 Version: v2.12.0 Opens a new window with list of versions in this module. Published: Aug 19, 2022 License: Apache-2.0 Opens a new window with license information. Imports: 23 Opens a new window with list of i

pkg.go.dev

카프카에서 계층 저장소(Tiered storage)가 필요한 이유

AndersonChoi — Fri, 20 Oct 2023 20:01:28 +0900

2020년 11월 Cofluent Platform 6.0이 릴리즈되면서 카프카의 계층 저장소가 처음으로 대중에게 소개되었습니다. 이전까지 카프카 오픈소스 진영에서 많이 논의 되었지만 실제로 개발자가 사용 가능한 형태로 나온 것은 이때가 처음입니다. 컨플루언트를 사용하는 많은 개발자와 회사에서는 카프카의 계층 저장소를 사용해왔습니다. 이후 2023년 10월, 오픈소스 카프카 3.6.0이 릴리즈 되면서 계층 저장소 얼리 엑세스 모드를 사용할 수 있게 되었습니다.

카프카에서 계층 저장소는 현재의 브로커 구조에서 아주 중요한 역할을 수행하게 될 것입니다. 계층 저장소는 많은 장점이 있겠으나 그 중 핵심은 비용 절감이라고 생각합니다. 비용 절감에는 크게 두가지가 있는데 컴퓨팅 리소스 비용과 휴먼 리소스 비용입니다. 이 2가지 측면에서 카프카의 계층 저장소가 어떤 역할을 하는지 알아보겠습니다.

1) 컴퓨팅 리소스 감소

현재의 카프카는 여러대의 브로커(서버)에 로컬의 파일시스템에 레코드를 세그먼트 단위로 저장하고 있습니다. 프로듀서가 토픽에 데이터를 전달할 때 마다 세그먼트에 레코드를 추가, 저장함으로써 파일시스템의 크기가 계속해서 늘어나는 구조를 가지고 있죠.

문제는 이 데이터의 양이 많아지고 리텐션(Retention)기간을 길게 가져가야할 때 입니다. 파일시스템이 저장되는 공간인 로컬 디스크가 아무리 램에 비해 저렴하다고 하더라도 100TB, 1000TB 혹은 그 이상으로 구성하기는 매우 어렵고 비용이 많이 발생합니다. 카프카의 분산 이벤트 스트리밍 플랫폼 특성상 모든 토픽의 리텐션을 3일, 3시간 이내로 가져가는 것은 카프카의 특징을 오히려 상쇄 시키는 역효과로 가져옵니다. 그렇기 때문에 더 긴 리텐션을 만족시키기 위해서는 로컬 저장소 저장 방식이 아니라 리모트 저장소가 필요합니다.

카프카에서 제공하는 계층 저장소는 S3, HDFS, Azure storage 등 우리에게 익숙한 저장소를 지원합니다. 리모트 저장소 사용 여부 설정은 토픽 단위로 지정 가능합니다. 그렇기 때문에 리텐션 기간이 짧고 자주 접근이 필요한 데이터가 들어 있다면 로컬 저장소로 선택하면 됩니다. 반대로 자주 접근하지 않는 데이터를 오랜기간 저장해야 한다면 리모트 저장소로 설정하면 됩니다. 이 설정을 활용하여 로컬 저장소의 저장 용량은 줄이되, 자주 접근하지 않는 데이터는 로컬 저장소보다 더 저렴한 리모트 저장소에 저장함으로서 비용적인 측면에서 더 효율적이라고 볼 수 있습니다.

리모트 저장소와 로컬 저장소로 설정한 토픽 둘 다 최근 데이터 읽기/쓰기는 거의 비슷합니다. 다만, 리모트 저장소에 저장된 토픽의 레코드 중 브로커의 페이지 캐시에 존재하지 않는 데이터를 읽을 때(컨슈머)는 약간의 지연이 발생할 수 있습니다. 일반적으로 우리가 스트림 데이터를 다룰 때 가장 최신의 데이터를 자주 접근하고 오래된 데이터를 다시 가져오는 리플레이 상황은 빈번히 일어나지 않기 때문에 리모트 저장소로 설정된 토픽의 지연은 일반적인 상황에서 크게 문제되지 않는다고 볼 수 있습니다.

2) 휴먼 리소스 감소

오랜기간 동안 카프카를 운영하면서 많은 카프카 운영자들은 브로커를 운영하기 위해 많은 피땀을 흘려왔습니다. 운영을 지속함에 따라 토픽의 개수가 계속해서 늘어나고 토픽의 파티션 개수는 각양 각색이며, 토픽별 데이터양도 모두 다르기 때문입니다. 그렇기 때문에 브로커의 디스크 용량 불균등 현상으로 인해 특정 토픽의 파티션 개수를 배수로 늘리거나 파티션 재설정(partition reassign)을 수행해야만 했습니다. 카프카 클러스터의 로컬 디스크 모니터링/운영은 컴퓨터가 자동으로 하거나 일반적인 자동화 툴로는 하기 어려운 일이며 카프카 클러스터 운영자가 수동으로 해야 합니다.

리모트 저장소는 카프카 클러스터 운영자가 들이는 수고를 한층 줄여줄 수 있습니다. 리모트 저장소로 설정된 토픽은 로컬 디스크에 저장되는 것이 아니라 외부 저장소에 저장되기 때문에 각 브로커별 로컬 디스크의 데이터양을 이전만큼 민감하게 모니터링할 필요가 없습니다. 또한 브로커 업그레이드와 같은 롤링 리스타트 상황에서도 각 브로커의 영향도가 한층 적어진다는 장점이 있습니다. 이전 만큼 대규모로 비싼 비용의 브로커를 운영할 필요가 없어집니다.

물론, 리모트 저장소를 사용한다고 모든게 해결되는 것은 아닙니다. 리모트 저장소와 연결된 토픽을 따로 관리해야할 것입니다. 예를 들어 카프카와 리모트 저장소의 연결 상태, 데이터 크기, 네트워크 속도 등 다양한 부분을 인프라 관점에서 고민이 필요합니다.

정리

카프카가 제공하는 계층 저장소는 아직 얼리 엑세스 모드로서 많은 기능들이 제한적으로 제공됩니다. 한번 리모트 저장소로 저장한 토픽은 다시 로컬 저장소로 변경이 불가능, 카프카 클라이언트와 호환성 부족 등이 대표적이며 이외에도 안정성 측면에서 프로덕션 레벨에서 사용하기에는 아직 부적합 합니다.

그럼에도 불구하고 카프카의 계층 저장소는 상당히 가치있기 때문에 빠르게 프로뎍션 레벨로 제공될 것이라 생각됩니다.

참고문서

- https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes

Kafka Tiered Storage Early Access Release Notes - Apache Kafka - Apache Software Foundation

This is an early access release for tiered storage feature(KIP-405), and it is not recommended for use in production environments. Instead, we advise users to create new clusters with version 3.6.0 and test the feature there. Alternatively, you can try the

cwiki.apache.org

- https://cwiki.apache.org/confluence/display/KAFKA/KIP-950%3A++Tiered+Storage+Disablement

KIP-950: Tiered Storage Disablement - Apache Kafka - Apache Software Foundation

This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own des

cwiki.apache.org

- https://dzone.com/articles/the-stairway-to-apache-kafka-tiered-storage

The Stairway to Apache Kafka® Tiered Storage - DZone

Tiered Storage, a feature of Apache Kafka that allows the offloading of data to object storage in the cloud, was developed in the open by the community.

dzone.com

- https://joshua-robinson.medium.com/simplify-kafka-at-scale-with-confluent-tiered-storage-ae8c1a2c9c80

Simplify Kafka at Scale with Confluent Tiered Storage

Confluent recently announced the general availability of Tiered Storage in the Confluent Platform 6.0 release, a new feature for managing…

joshua-robinson.medium.com

- https://www.confluent.io/blog/confluent-platform-6-0-delivers-the-most-powerful-event-streaming-platform-to-date/

Confluent 6.0 Delivers the Most Powerful Event Streaming Platform to Date

Confluent Platform 6.0 delivers all phases of Project Metamorphosis for the most powerful, cost-efficient Kafka with infinite data retention, scale, and global availability.

www.confluent.io

- https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage

KIP-405: Kafka Tiered Storage - Apache Kafka - Apache Software Foundation

Authors Satish Duggana, Sriharsha Chintalapani, Ying Zheng, Suresh Srinivas Status Current State: "Accepted" Discussion Thread: here JIRA: KAFKA-7739 - 이슈 세부사항 가져오는 중... 상태 Motivation Kafka is an important part of data infrastr

cwiki.apache.org

- https://www.confluent.io/blog/introducing-apache-kafka-3-6/

Introducing Apache Kafka 3.6

Apache Kafka 3.6 brings Tiered Storage Early Access, migrating clusters from ZooKeeper to KRaft with no downtime, a grace period for stream-table joins, and more!

www.confluent.io

신뢰성 있는 카프카 애플리케이션을 만드는 3가지 방법

AndersonChoi — Fri, 22 Sep 2023 18:25:43 +0900

카카오 공개 기술 세미나인 kakao tech meet에서 '신뢰성 있는 카프카 애플리케이션을 만드는 3가지 방법' 에 대해 발표하는 자리를 가졌습니다.

https://www.youtube.com/watch?v=7_VdIFH6M6Q

이벤트 드리븐 아키텍처와 스트림 데이터 파이프라인을 만들때 고민해야 하는 부분을 다룹니다. 프로듀서/컨슈머와 같은 카프카 애플리케이션의 전달 신뢰도를 높이기 위해서 적용할 수 있는 기술들에 대해 설명하고 내부적으로 적용했던 경험을 공유합니다.

카프카에서 다루는 신뢰도에 대해 다시 한 번 고민해보고, 내가 만든 애플리케이션이 고객에게 어떻게 가치를 줄 수 있는지 생각해볼만한 주제도 함께 알려드립니다.

카프카 프로듀서의 acks=all 옵션은 사실(?) 느리지 않다!

AndersonChoi — Tue, 8 Aug 2023 19:08:23 +0900

카프카 3.0 부터는 카프카 프로듀서의 acks 옵션이 all로 지정됩니다. acks=all이 기본값으로 지정된 이유 중 하나는 프로듀서와 브로커 간 통신을 멱등성(idempotence)있게 만들기 위함입니다. 프로듀서와 브로커는 acks를 통해 레코드가 전송되었는지 확인합니다. 문제는 acks가 유실되었을 경우입니다. 네트워크 상태, 브로커 상태에 따라서 언제든 유실될 수 있는 acks를 정상적으로 전송하기 위해서는 acks를 위한 acks(!)를 만들어야만 합니다. 이는 두 장군 문제 알고리즘과 동일하다고 볼 수 있습니다.

결과적으로 프로듀서의 중복 전달을 제거하기 위해 카프카 3.0부터는 enable.idempotence가 true로 변경되었고 이에 딸려오는 추가 옵션인 acks가 all로 설정되게 되었습니다. 프로듀서가 여러번 브로커로 전송하더라도 결과적으로 하나의 레코드만 적재하는 전략을 취했습니다.

프로듀서의 옵션 중 acks는 all로 설정할 경우 min.insync.replicas 개수 만큼 리더/팔로워 파티션에 레코드가 분산 저장되었는지 확인하는 역할을 합니다. 당연하게도 acks=0(적재를 확인하지 않음), acks=1(리더에 적재 확인)보다도 더 느릴 수 밖에 없습니다. 그렇다면 이렇게 느릴 수 있는 acks=all 옵션을 왜 카프카 프로듀서에 기본 값으로 적용하게 되었던걸까요?

이유는 max.inflight.requests.per.connection과 관련 있습니다. An analysis of the impact of max.in.flight.requests.per.connection and acks on Producer performance 에 따르면 acks=all로 설정하더라도 max.in.flight.requests.per.connection를 3으로 설정하고 비동기 프로듀서(Asynchronous producer)를 사용하면 acks=1과 동일한 성능을 낼 수 있음을 증명하였습니다. 비동기 프로듀서란 브로커로부터의 응답을 동기로 받지 않는 것을 뜻합니다. 즉, 프로듀서의 샌더가 max.in.flight.requests.per.connection 개수만큼 병렬로 레코드를 전송하면 되는 것이죠. 당연하게도 동기 프로듀서(Synchronous producer)를 사용하게 되면 속도는 매우느립니다.

Asynchronous producer

KafkaProducer<String, String> producer = new KafkaProducer<>(configs);
ProducerRecord<String, String> record = new ProducerRecord<>(TOPIC_NAME, messageValue);
producer.send(record); // 비동기 프로듀서 코드 #1
========
producer.send(record, new ProducerCallback()); // 비동기 프로듀서 코드 #2

Synchronous producer

ProducerRecord<String, String> record = new ProducerRecord<>(TOPIC_NAME, messageValue);
try {
    RecordMetadata metadata = producer.send(record).get();
    logger.info(metadata.toString());
} catch (Exception e) {
    logger.error(e.getMessage(),e);
} finally {
    producer.flush();
    producer.close();
}

이런 특징으로 인해 KIP-679에서는 프로듀서와 브로커간 통신에서 레코드를 단 한번만 전송(Exactly-once)하기 위해 enable.idempotence를 true와 변경함과 동시에 acks를 all로 설정하게 되었습니다. 이를 통해 카프카 클라이언트 3.0 이후 버전에서 프로듀서는 브로커로 단 한번만 레코드를 전송할 수 있게 되었죠.

결론

카프카 클라이언트 프로듀서 3.0 이후에는 acks가 all로 기본값으로 설정됨
acks=all로 성능이 유지되기 위해서는 비동기 프로듀서를 사용해야 함
만약 카프카 클라이언트 3.0 미만 버전을 사용하고 있다가 3.0 이상으로 올려야 할 경우 acks 옵션의 기본값이 변경되므로 성능 및 동작에 차이에 대해 파악해야 함

기존에 생성된 compact topic의 cleanup.policy를 변경하는 방법

AndersonChoi — Fri, 30 Jun 2023 08:08:35 +0900

현재 cleanup.policy 확인

$ ./kafka-topics.sh --bootstrap-server localhost:9092 --topic compact-
test --describe
Topic: compact-test	PartitionCount: 1	ReplicationFactor: 1	Configs: cleanup.policy=compact,segment.bytes=1073741824
	Topic: compact-test	Partition: 0	Leader: 0	Replicas: 0Isr: 0

kafka-configs.sh를 사용하여 토픽 수정

$ ./kafka-configs.sh --bootstrap-server localhost:9092 --alter --entit
y-type topics --entity-name compact-test --add-config cleanup.policy=delete
Completed updating config for topic compact-test.

토픽 변경된 내용 확인

$ ./kafka-topics.sh --bootstrap-server localhost:9092 --topic compact-
test --describe
Topic: compact-test	PartitionCount: 1	ReplicationFactor: 1	Configs: cleanup.policy=delete,segment.bytes=1073741824
	Topic: compact-test	Partition: 0	Leader: 0	Replicas: 0Isr: 0

Compacted topic에 null key 레코드를 전송하면?

AndersonChoi — Fri, 30 Jun 2023 07:59:49 +0900

Compacted topic에 null key를 전송(produce)하면 어떻게 될까요?

1) Compacted 토픽 생성

$ ./kafka-topics.sh --bootstrap-server localhost:9092 --topic compact-test --config "cleanup.policy=compact" --create
Created topic compact-test.

$ ./kafka-topics.sh --bootstrap-server localhost:9092 --topic compact-test --describe
Topic: compact-test	PartitionCount: 1	ReplicationFactor: 1	Configs: cleanup.policy=compact,segment.bytes=1073741824
	Topic: compact-test	Partition: 0	Leader: 0	Replicas: 0	Isr: 0

2) null key 레코드 전송

public static void main(String[] args) throws Exception{
    Properties configs = new Properties();
    configs.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP_SERVERS);
    configs.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
    configs.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

    KafkaProducer<String, String> producer = new KafkaProducer<>(configs);
    ProducerRecord<String, String> record = new ProducerRecord<>(TOPIC_NAME, "test");
    RecordMetadata meta = producer.send(record).get();
    logger.info(meta.toString());
    producer.flush();
    producer.close();
}

3) 결과 로그

Exception in thread "main" java.util.concurrent.ExecutionException: org.apache.kafka.common.InvalidRecordException: This record has failed the validation on broker and hence be rejected.
	at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.valueOrError(FutureRecordMetadata.java:98)
	at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:67)
	at org.apache.kafka.clients.producer.internals.FutureRecordMetadata.get(FutureRecordMetadata.java:30)
	at com.example.SimpleProducer.main(SimpleProducer.java:27)
Caused by: org.apache.kafka.common.InvalidRecordException: This record has failed the validation on broker and hence be rejected.

FAILURE: Build failed with an exception.

InvalidRecordException와 함께 레코드가 전송되지 않는다!

아파치 카프카 Exactly-once 처리의 진실과 거짓

AndersonChoi — Tue, 20 Jun 2023 10:38:12 +0900

아파치 카프카와 같은 분산 이벤트 스트리밍 플랫폼을 사용하거나 메시지 브로커를 활용하다 보면 항상 마주치는 문제는 마로 메시지 전달 시멘틱(message delivery semantic)입니다. 메시지 전달 시멘틱은 A지점에서 B지점으로 데이터를 전송할 때 어느 만큼의 신뢰도로 데이터를 전송하는지에 대한 정의입니다. 즉, 특정한 장애 상황(또는 임계치를 벗어난 상황)에서도 보증하는 데이터 전달 신뢰도라고 볼 수 있습니다.

메시지 전달 시멘틱은 크게 세가지로 나뉩니다. 적어도 한번(at least once), 많아도 한번(at most once), 정확히 한번(exactly once). '적어도 한번'은 데이터가 전달될 때 유실이 발생하지는 않지만 중복이 발생할 가능성이 있음을 뜻합니다. 아파치 카프카는 기본 옵션으로 사용할 경우 '적어도 한번'을 보장합니다. '많아도 한번'은 최대 한번의 메시지를 보내고 일부 데이터는 유실될 수 있음을 뜻합니다. 마지막으로 '정확히 한번'은 A에서 B로 데이터를 보낼 때 어떠한 경우에서도 유실이나 중복이 발생하지 않는 것을 뜻합니다.

'정확히 한번' 처리에서 중요한 것은 '어떠한 경우'입니다. '어떠한 경우'라는 것은 다양한 상황을 뜻할 수 있는데요. 데이터 센터가 셧다운 되는 끔찍한 상황도 그 경우에 포함될 수 있고 일반적으로 자주 일어날 수 있는 네트워크 순단 현상도 포함될 수 있습니다. 즉, 엔지니어가 모르는 사이 어떠한 일이 있더라도 데이터는 단 한번만 처리되는 것을 뜻하는 것입니다.

그렇다면 반대로 '적어도 한번'과 '많아도 한번'은 항상 평소에도 중복/유실이 발생하는 것을 뜻하는 걸까요? 아파치 카프카를 예로 말씀드리자면 '아니다'라고 말씀드릴 수 있습니다. 아파치 카프카를 기본 옵션으로 사용할 경우 '적어도 한번'을 보장한다는 것은 '어떠한 경우'가 발생하는 경우에 대응하여 말하는 것입니다. 즉, 아파치 카프카를 사용하는 상황에서 '어떠한 경우'가 발생하지 않는다면 기본적으로는 '정확히 한번'을 수행합니다.

카프카에서 '어떠한 경우'가 생기는 것의 예는 네트워크상 이슈 또는 애플리케이션 이슈를 예로 들 수 있습니다. 프로듀서 입장에서 브로커에 레코드가 정상적으로 저장되더라도 ack가 유실되면 데이터가 적재되지 못했다고 생각해서 retry를 하게 되어 데이터의 중복 전달이 발생할 수 있습니다. 컨슈머 입장에서는 데이터를 안전하게 처리했음에도 불구하고 애플리케이션 장애로 인해서 commit을 못하게 되면 이전 레코드를 중복처리할 수 있는 경우가 발생할 수 있습니다.

이런 '어떠한 경우'가 발생하더라도 데이터 처리의 중복/유실을 방지 위해 아파치 카프카는 많은 노력을 기울여 왔습니다. 크게 두가지가 있는데요. 첫번째는 멱등성 프로듀서(idempotence producer)이고 두번째는 트랜잭션 프로듀서/컨슈머(transaction producer/consumer)입니다. 멱등성 프로듀서는 네트워크 장애가 발생하더라도 브로커에 단 하나의 레코드만 보낼 수 있도록 보장하여 '정확히 한번'을 달성하였습니다. 트랜잭션 프로듀서/컨슈머는 여러 레코드를 원자(atomic) 단위로 데이터를 처리할 수 있도록 설계되었는데, 여기에 추가적으로 컨슈머의 커밋을 트랜잭션에 포함시키는 기능(sendOffsetsToTransaction)을 가지고 있습니다. 이를 통해 A토픽->컨슈머->데이터 처리->프로듀서->B토픽 으로 이어지는 파이프라인에서 '정확히 한번'을 달성할 수 있게 되었습니다.

위 경우를 보면 알겠지만 프로듀서->토픽 또는 토픽->컨슈머->프로듀서->토픽 에 대해서 '정확히 한번'을 달성하였다는 사실이 있지만 우리가 흔히 사용하게 되는 토픽->컨슈머 는 '정확히 한번' 달성에 대한 이야기가 없습니다. 왜냐면 컨슈머가 레코드를 토픽에서 가져가서 처리한 뒤 중복처리를 막기 위해 오프셋 저장을 수행하는데, 오프셋 저장을 특정 처리와 함께 트랜잭션으로 묶는 것이 어렵기 때문입니다. 예를 들어 토픽의 레코드들을 데이터베이스에 데이터를 저장한다고 가정할 경우 데이터 insert와 commit offset을 하나의 트랜잭션으로 묶는 것은 불가능합니다. 서로 연동되는 서비스가 아니기 때문이죠. 그렇기 때문에 토픽->컨슈머 처리에서 '정확히 한번'을 달성하기 위해서는 멱등성(idempotence) 처리를 하도록 가이드합니다. 멱등성이라는 것은 동일한 명령이 여러번 가더라도 결과물은 동일한 것을 뜻합니다. 컨슈머가 멱등성 특징을 가지게 하기 위해서는 관련 데이터베이스에서 해당 기능을 지원해야 합니다. 예를 들어 동일한 레코드가 중복 적재될 때는 결과가 하나만 나올 수 있도록 유니크 키 같은 것을 지원한다면 이 문제가 쉽게 해소될 수 있습니다. 이를 통해 토픽->컨슈머까지 '정확히 한번' 달성을 수행할 수 있게 됩니다.

마무리

카프카 뿐만 아니라 플링크, 스파크 등 많은 스트리밍 플랫폼을 사용할 때 간과하는 것이 메시지 전달 시멘틱입니다. 또한 어떻게 동작하는지 모르는 상태에서 단순히 exactly_once=true 옵션을 적용하고 사용하는 경우가 많습니다. 비즈니스 요구사항에 따라 어떤 동작을 할지 정의하고 우리가 사용하는 플랫폼이 어떤 동작을 할지 결정하고 내부적으로 어떻게 동작하는지 명확히 파악하고 사용하는 것이 중요합니다. 그렇기 때문에 관련 옵션이나 오픈소스 도큐먼트에 적혀있는 내용이 모든 것을 커버한다고 과장해서 생각하면 추후 운영시 이슈가 발생할 확률이 커질 수 있습니다.

마지막으로 카프카를 사용할 때, '정확히 한번'을 달성하기 위한 방법을 알려드립니다. 크게 3단계에 대해 고려해야 하는데요. 프로듀서->토픽, 토픽->컨슈머->프로듀서->토픽, 토픽->컨슈머 입니다. '어떠한 경우'가 발생하지 않는 이상 데이터의 중복/유실이 발생하지 않겠지만 데이터 처리가 중요한 기업에서는 중복/유실이 크리티컬 할 수 있습니다. 이에 대응하여 아키텍처를 구성하기 위해서는 각각 다음과 같은 기술을 사용해야 합니다.

- 프로듀서->토픽 : 멱등성 프로듀서

- 토픽->컨슈머->프로듀서->토픽 : 트랜잭션 프로듀서/컨슈머

- 토픽->컨슈머 : 멱등성 처리

아무쪼록 카프카를 활용하면서 메시지 전달 처리를 고민하는데 많은 도움이 되었으면 좋겠습니다.

P.S.

- https://issues.apache.org/jira/browse/KAFKA-8587

[KAFKA-8587] One producer per thread for Kafka Streams EOS - ASF JIRA

Currently exactly-once producer is coupled with individual input partitions. This is not a well scaled solution for client application such as Kafka Streams, and the root cause is that EOS producer doesn't understand the topic partition move throughout con

issues.apache.org

- https://www.confluent.io/blog/simplified-robust-exactly-one-semantics-in-kafka-2-5/

Apache Kafka’s Exactly-Once Semantics Are Now Easier & More Robust

Kafka 2.5 brings important improvements to exactly-once semantics: enhanced producer error handling and simplified transactional APIs for more powerful, simplified production use cases.

www.confluent.io

[개발자를 넘어 기술 리더로 가는 길]읽고 정리

AndersonChoi — Mon, 19 Jun 2023 15:54:44 +0900

타냐 라일리

https://www.linkedin.com/in/tanyareilly/

타냐 라일리는 중간급 엔지니어가 되었을 때 매니저가 되고 싶지 않았고 '스태프 엔지니어의 길'로 가고 싶었다. 기술 전략 수립, 조직을 성공적으로 이끌기 위한 방법에 대해 고민했고 이에 대한 내용을 정리했다.

두 가지 진로

개발자는 크게 두가지 진로가 있다.

1) 매니저

- 명확하게 소통

- 위기 상황에서 침착함 유지

- 동료들이 더 나은 일을 할 수 있도록 도움

- 많은 사례들이 나와 있음

2) 스태프 엔지니어(기술 리더)

- 불분명한 길

타냐 라일리가 생각하는 스태프 엔지니어의 필요한 역할 3가지

1) 빅 픽처 관점의 사고력 : 현재 상황에 대해 인지하고 기업에 필요한 것이 무엇인지 파악하여 n년 단위 프로젝트 진행

2) 성공적인 프로젝트 실행력 : 정치적 자본, 영향력, 기업 문화 적용

3) 조직 차원의 레벨 업 : 엔지니어의 표준과 스킬 역량을 향상. 롤모델이 되어 영향력을 발휘

위 3가지를 다루기 위해서는 반드시 다양한 기술적 지식과 풍부한 경험이라는 토대가 중요하다고 언급함. 그렇기 때문에 스태프 엔지니어로서 발전하고 싶고 잘 해내기 위해서는 스킬 역량(기술적 지식)을 키우기 위해 계속해서 노력해야함.

기술적 역량 뿐만 아니라 추가적으로 키워야 하는 스킬은 다음과 같은 소프트 스킬이 있다.

- 커뮤니케이션 및 리더십

- 복잡한 문제 탐색

- 업무상 관점 제시

- 멘토링, 후원, 위임

등

빅 픽처 관점의 사고력

모든 엔지니어 조직은 다양한 배경지식 아래에 최고의 결정을 내리기 위해 노력한다. 이런 상황을 파악하기 위해서는 전체적인 맥락(context)를 파악해야만 한다. 그렇기 때문에 시니어 엔지니어는 항상 동일한 답을 하지 않는다. 오히려 때에 따라 다른 답을 내린다. 좋은 답을 내리기 위해서는 단순히 특정 기술의 장단점을 아는 것을 넘어서서 세부사항까지 완벽하게 알고 있어야만 한다.

또한 현재에 장단점에 미치지 않고 기업에 추구하는 방향에 맞는 가치를 제공하기 위한 방법이 무엇인지 파악하고 개발을 진행해야만 한다. 당장 공수가 적게들어가는 일보다는 1년 후, 3년 후 가치를 더 향상시키기 위한 작업을 진행해야 한다. 이런 결정의 맥락은 모든 사람에게 공유되어야 하며 공감대가 형성되도록 노력해야 한다.

추가적으로 문서를 만드는데도 노력을 상당히 기울여야하며 문서를 바탕으로 비전과 전략을 말로 잘 풀어내는 것이 중요하다.

성공적인 프로젝트 실행력

첫번째는 업무 선별을 하는 것이고 두번째는 시간 측면을 고려하는 것이다. 유한한 시간안에서 최고의 성과를 내기 위해서는 무엇을 어떻게 하는지가 가장 중요하다. 하지만 모든 사람에게 동일한 시간이 주어지는 것은 아니다. 근무시간은 동일하겠지만 각자의 삶, 휴가, 휴식, 질병 등으로 인해 수정이 필요할 수 있기 때문이다. 또한 업무에 집중하기 위해서는 포기해야하는 부분도 필연적으로 있다. 그러므로 이런 모든 부분에 대해서 관리가 필요하다.

조직 차원의 레벨 업

훌륭한 스태프 엔지니어의 세번째 핵심 역량이다. 팀, 조직의 동료, 기업이나 업계 차원에서 엔지니어의 표준 및 스킬 역량을 향상시켜야할 책임이 있다. 스스로 롤모델이 되는 것 뿐만 아니라 무의식적으로 영향력을 바뤼하고 가르침과 멘토링을 통해 의도적으로 널리 영향을 발휘하는 것도 필요하다.

이 책을 읽고

여러모로 의외였던 내용으로 가득차 있었습니다. 사실 세상에 많은 개발자를 위한 교양서적이 많지만 와닿는 내용이 적힌 경우는 거의 없었습니다. 많은 교양 서적들은 문서화를 잘 하고 미래 가치를 보고 어떻게 개발을 진행할지 적혀있지만 실제로 어떻게 행해야할지 너무 구체적으로 적혀 있어서 작가의 색이 짙게 들어나는 경우도 있어서 공감이 가지 않을 때도 많았습니다. 하지만 이 책은 그런 선입견을 타파하는 아주 좋은 책입니다.

현재 내가 주니어 이더라도 혹은 지금 시니어더라도 현재 바로 집중해서 어떻게 개발자로 살아가야할지 보여주는 지침서라고 할 수 있습니다. X라고 하는 방향을 가지고 반드시 무엇을 해야한다고 강요하는 것이 아니라, '상황에 따라 변할 수 있다' 라는 가정하에 개발자가 나아가야할 방향을 설명하고 있습니다. 그렇기 때문에 글이 더 잘 읽히는 것 같습니다.

너무 좋은 책이라 생각되고 앞으로 개발자로 삶을 살아가는데 있어서 반복해서 읽을 예정입니다.

모던 데이터 플로우: 데이터 파이프라인을 잘 운영하는 방법

AndersonChoi — Mon, 12 Jun 2023 17:04:42 +0900

https://www.confluent.io/events/kafka-summit-london-2022/modern-data-flow-data-pipelines-done-right/

Kafka Summit London 2022 Keynote | Jay Kreps, CEO, Confluent featuring Avi Perez, Wix.com

Confluent is building the foundational platform for data in motion so any organization can innovate and win in a digital-first world.

www.confluent.io

메이븐에서 카프카 자바 라이브러리의 사용율이 급격하게 올라가는 것을 볼 수 있음. 그만큼 카프카의 사용량이 엄청나게 많아지고 있다는 것을 뜻함.

카프카는 많은 기업에서 중추신경과 같은 역할을 수행하고 있음. 모든 데이터를 모으고 해당 데이터를 기반으로 연동하여 운영되고 있음.

이렇게 카프카를 사용하는 것은 크게 두가지 타입으로 나뉠수 있음. 애플리케이션과 파이프라인. 그리고 이 2개가 속한 스트리밍 플랫폼. 물론. 이 2개의 타입을 나누는 것은 정확하지 않을 수 있고 때로는 파이프라인이 애플리케이션으로 전환될 때도 있음.

문제는 여기서 이 스트리밍 데이터가 옳은 시간에 올바른 포맷으로 올바른 팀에게 적절히 가고자 할 때는 어떻게 해야하는지 고민해야 한다는 점임.

이런 문제를 해결하기 위해 다양한 솔루션들이 나왔었음. 그러나 각기 따로 운영되고 통합되지 못했음. 현재의 카프카는 필수조건이지만 카프카 자체로 모든 요구사항을 만족시키지 않다는 특징이 있음.

KAFKA IS NECESSARY BUT NOT SUFFICIENT

그리고 대부분이 배치기반 데이터 처리에 집중되고 있음. 일부는 스트리밍을 지원하지만 2022년에 새로 만들어지는 플랫폼도 배치 위주로 개발되고 있음 이런 현상은 좀 회의적임. 이와 함께 제이 크랩스는 핸리 포드의 명언을 인용했음.

핸리포드 - 만약 고객에게 무엇을 원하는지 물었다면 그들은 더 빠른 말(horse)라고 답했을 것이다

그만큼, 현재 나아가고 있는 미래는 스트림 데이터 처리임에도 불구하고 현재 배치 기반 플랫폼을 만들거나 관련 기술을 성장시키기 위해 노력하는 모습이 부정적으로 보이는 것으로 말함.

그렇기 때문에 모던 데이터 플로우를 달성하기 위해서는 카프카라는 기술적인 개념에서 넘어서서 5가지의 핵심 개념을 항상 생각해야만함.

1. 스트리밍
2. 탈중앙화
3. 선언적
4. 개발자 중심
5. 거버넌스 & 관측성

조직에 데이터가 흐르고 있는 상태에서 잘 활용하기 위한 조건이라 보면 됨.

1. 스트리밍

배치로 많은 데이터가 사용되고 있지만 앞으로 스트림 데이터가 사용될 것임에 틀림없다고 생각함. '눈을 감고 횡단보도를 걷는다고 생각할 때 5분전 교통정보를 토대로 걸을 것인가?'라는 인용과 함께 실시간 데이터만이 실제 비즈니스를 운용하는데 중심이 됨을 설명. 스트림 데이터 처리가 완벽하게 정확하지 않을 수도 있고, 리소스가 더 많이 들 수도 있고, 운영상 회의적일 수 있음. 하지만 카프카는 이런 파이프라인을 운영하는데 적합하게 구성(확장성, 내구성 등)되어 있음.

그렇기 때문에 모든 데이터를 배치 따로 스트리밍 따로 처리하지 말고 실시간으로 들어오는 데이터를 한번에 잘 처리하는 것이 더 좋은 방법이라고 생각함.

2. 탈중앙화

옛날 ETL은 상기 그림과 같이 단순하지만 복잡한 파이프라인을 운영하기 어려웠고 항상 중앙화된 데이터를 보아야만 했음. 실제로 우리가 비즈니스를 운영할 때는 매우 다양한 실시간/배치 데이터가 발생하고 있고 이를 상황에 따라 개별 추출하여 봐야할 경우도 있기 때문에 현대 비즈니스에는 부적합함.

그렇기 때문에 데이터를 사용하는 고객을 위한 토픽(데이터 저장)을 마들고 이를 개별적으로 가져갈 수 있도록 만드는 것이 중요.

또한, 이런 아키텍처에서는 REST+JSON 만큼이나 카프카를 스키마와 함께 사용하는 것이 중요하다고 설명함. 이 스키마를 토대로 데이터를 정확히, 잘 사용할 수 있기 때문. 다양한 요구사항을 가진 여러 고객들을 위해 토픽에 데이터를 넣고 활용할 수 있는 기회를 만들어주는 격.

이는 일반적인 배치 프로세싱의 도구 사용 방법을 보여줌. A가 끝나면 B를 하고 C를 수행하는 이런 단계를 구성하는데 익숙함. 이런 순서 지향적 데이터 처리는 확장이 어렵기 때문에 데이터 처리 이슈를 찾기 어려움. 이를 스트림으로 구성하면 다음과 같음

데이터는 DAG로 표현가능하기 때문에 구형의 순서지향 배치처리가 아니라 확장가능하고 여러 종류로 통합 가능한 처리를 지향.

3. 선언적

우리가 실제로 데이터를 처리할 때 어떤 것을 원하는지 정확히 적는것이 중요함. 이전에 배치성 데이터는 SQL을 잘 구성함으로서 데이터를 잘 뽑아낼 수 있었음.

스트림도 SQL로 구성하여 뽑아 낼 수 있음. ksqlDB 광고.

4. 개발자 중심

모든 개발은 개발자 중심으로 되어야 하며 코드기반의 데이터 처리가 되어야 함. 또한 개발은 항상 발전이 되어야 하기 때문에 이를 지원하는 형태가 되어야함. 마지막으로 오픈 플랫폼을 통해 카프카 관련 파이프라인을 운영하기 위한 low level 코드와 같은 시스템이 관련 에코 시스템을 운영하기 좋아질 수 있다고 볼 수 있음.

예를 들어 새로운 커넥터가 여러 에코시스템에서 개발하고 지원하는 것을 예로 들 수 있음

5. 거버넌스 & 관측성

사실 이건 모든 데이터에서 중요함. 하지만 스트리밍에서는 이를 잘 다루어야함. 배치에서는 사실 다루기 쉬웠음. 되거나/안되거나 둘중 하나였고 실제로 안되었다면 다시 실행하면 되었기 때문임. 스트리밍은 배치와 다르게 투명하게 운영해야만 하며 이를 놓쳐서는 안됨. 또한 데이터를 사용할 때는 여러 법적인 측면도 잘 다루어야 하기 대문에 이 데이터가 어떻게 운영되고 있는지, 어떤 원천 데이터를 활용하고 있는지 파악이 되어야만함. 이를 위해 confluent에서는 Catalog, Schema, Lineage를 지원하고 있음

결론

데이터의 흐름은 모두 스트림으로 흐르고 있음. 스트림 데이터를 배치에서 변환하면 상기 이미지와 같음.

golang struct type을 JSON으로 Print 하기

AndersonChoi — Wed, 29 Mar 2023 19:52:30 +0900

package main

import (
	"encoding/json"
	"fmt"
)

type Person struct {
	Name string
	Age  int
}

func main() {
	myStruct := Person{"dvwy", 145}
	fmt.Println("=======")
	fmt.Println(myStruct)
	fmt.Println(prettyPrint(myStruct))
}

func prettyPrint(i interface{}) string {
	s, _ := json.MarshalIndent(i, "", "\t")
	return string(s)
}

결과는 다음과 같습니다.

{dvwy 145}
{
        "Name": "dvwy",
        "Age": 145
}

출처 : https://stackoverflow.com/a/51270134

How to print struct variables in console?

How can I print (to the console) the Id, Title, Name, etc. of this struct in Golang? type Project struct { Id int64 `json:"project_id"` Title string `json:"title&qu...

stackoverflow.com

아파치 카프카 브로커 설정에서 listener와 advertised.isteners의 차이?

AndersonChoi — Sun, 26 Mar 2023 21:08:35 +0900

Kafka 브로커의 설정에서 listener와 advertised.listeners 옵션은 다음과 같은 특징이 있다.

listener는 Kafka 브로커가 클라이언트로부터 듣고있는 네트워크 인터페이스와 포트를 나타낸다. 예를 들어, listener를 PLAINTEXT://localhost:9092로 설정하면 브로커는 localhost의 9092 포트에서 PLAINTEXT 프로토콜을 사용하여 들어오는 클라이언트 연결을 수신한다.

advertised.listeners는 Kafka 브로커가 클라이언트에게 알려주는 네트워크 인터페이스와 포트를 나타낸다. 클라이언트는 이 정보를 사용하여 브로커에 연결한다. 이 정보는 일반적으로 브로커가 외부에 노출되는 경우 사용된다. 예를 들어, advertised.listeners를 PLAINTEXT://example.com:9092로 설정하면 클라이언트는 example.com의 9092 포트에서 PLAINTEXT 프로토콜을 사용하여 브로커에 연결한다.

결론

listener는 브로커가 실제로 수신 대기 중인 네트워크 인터페이스와 포트를 설정하고, advertised.listeners는 브로커가 클라이언트에게 알려주는 네트워크 인터페이스와 포트를 설정한다.

spring boot HttpServletRequest 사용 쿠키 구현시 HttpSession.getAttribute(String) is null 에러 발생 대응

AndersonChoi — Tue, 14 Mar 2023 22:50:05 +0900

spring boot에서 쿠키/세션 로그인 기능 구현시 다음과 같은 에러를 만났습니다

...HttpSession.getAttribute(String)" is null

분명히 다음과 같이 attribute를 제대로 설정했는데 왜그랬을까요?

HttpSession session = request.getSession(true);
session.setAttribute("LOGIN_MEMBER", 123);

이유는 다음과 같습니다. 제가 가진 특수한 상황 때문이였는데요.

- server : localhost:8080

- client : localhost:3000

- client는 server로 axios 요청을 함

위 상황은 여러가지 문제가 있었고 해결방안은 다음과 같습니다.

1) CORS 문제

크로스 도메인에 대응하여 spring boot에 다음과 같은 옵션을 줬습니다.

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowCredentials(true)
                .allowedHeaders("*")
                .allowedOrigins("http://localhost:3000");
    }
}

2) withCredential 문제

axios 전역변수에 다음과 같이 설정하여 헤더에 session id가 넘어가도록 설정하였습니다.

import axios from "axios";
axios.defaults.withCredentials = true;

이후 정상동작함을 확인할 수 있었습니다.

golang prviate repository에서 디펜던시 가져오는 방법

AndersonChoi — Mon, 6 Mar 2023 16:55:00 +0900

golang private repository를 하위 모듈로 가져올 때 그냥 import를 실행하고 나면 다음과 같은 이슈가 종종 발생하곤합니다.

$ go get github.com/AndersonChoi/my-private-repo
go: downloading github.com/AndersonChoi/my-private-repo v0.0.0-20230306053459-dec1333da9d3
go: github.com/AndersonChoi/my-private-repo@v0.0.0-20230306053459-dec1333da9d3: verifying module: github.com/AndersonChoi/my-private-repo@v0.0.0-20230306053459-dec1333da9d3: reading https://sum.golang.org/lookup/github.com/AndersonChoi/my-private-repo@v0.0.0-20230306053459-dec1333da9d3: 404 Not Found
        server response: not found: github.com/AndersonChoi/my-private-repo@v0.0.0-20230306053459-dec1333da9d3: unrecognized import path "github.com/AndersonChoi/my-private-repo": https fetch: Get "https://github.com/AndersonChoi/my-private-repo?go-get=1": dial tcp 10.93.97.11:443: connect: connection refused

이런 경우에는 다음과 같이 명령어를 내리면 module로 디펜던시를 가져오게 됩니다.

$ GOPRIVATE="github.com" go get github.com/AndersonChoi/my-private-repo
go: downloading github.com/AndersonChoi/my-private-repo v0.0.0-20230306053459-dec1333da9d3
go: added github.com/AndersonChoi/my-private-repo v0.0.0-20230306053459-dec1333da9d3

문제는 다음에 다른 사람이 이렇게 추가한 서브모듈이 있는 레포지토리를 사용할때 다시 이 명령어를 사용하여 가져와야 한다는 점입니다.

이를 해결하기 위해서는 vendor를 사용하면됩니다.

$ go mod tidy                                                                                                     1 ↵
$ go mod vendor

이후에 vendor 디렉토리가 생긴 것을 확인할 수 있습니다.

$ ls
Dockerfile README.md  go.mod     go.sum     src        vendor

goroutine 함수 여러번 실행 결과값 기다리는 2가지 방법 - js callback 처럼

AndersonChoi — Fri, 3 Mar 2023 16:22:11 +0900

WaitGroup을 사용하는 방법

1) sync.WaitGroup을 사용하여 대기

2) go func 사용하여 goroutine 함수 호출

위 2가지 방법을 사용하면 여러번 실행된 결과값을 병렬 처리한 뒤 한개의 결과값으로 추출할 수 있습니다. 예제 코드는 다음과 같습니다.

package main

import (
	"fmt"
	"math/rand"
	"strconv"
	"sync"
	"time"
)

func main() {

	result := 0
	count := 10
	var wg sync.WaitGroup // WaitGroup 선언
	wg.Add(count) // Wait 개수 지정

	for i := 1; i <= count; i++ {

		go func(goroutineNumber int) {
			defer wg.Done() // function이 종료될 때 Done() 호출로 1 감소
			time.Sleep(time.Duration(rand.Intn(3)) * time.Second)
			result++
			fmt.Println(strconv.Itoa(goroutineNumber) + " is done") // goroutine 번호
		}(i)
	}

	wg.Wait()
	fmt.Print("result:" + strconv.Itoa(result)) // result는 1씩 증가 x 10번
}

결과는 다음과 같습니다.

3 is done
5 is done
1 is done
4 is done
7 is done
8 is done
6 is done
2 is done
9 is done
10 is done
result:10

channel을 사용하는 방법

package main

import (
    "fmt"
    "time"
)

func worker(id int, c chan int) {
    // 각 함수에서 실행할 작업
    time.Sleep(time.Second)
    result := id + 1
    // 결과값을 채널에 보내기
    c <- result
}

func main() {
    // 결과값을 저장할 채널 생성
    c := make(chan int)

    // 3번의 함수 실행
    for i := 0; i < 3; i++ {
        go worker(i, c)
    }

    // 채널을 통해 결과값 수집
    var results []int
    for i := 0; i < 3; i++ {
        result := <-c
        results = append(results, result)
    }

    // 결과값 출력
    fmt.Println(results)
}

worker() 함수를 3번 실행시키고, 각 함수에서 반환된 값을 채널 c를 통해 수집. worker() 함수에서는 각각 다른 id 값을 받아와서 1을 더한 값을 결과값으로 반환. 이렇게 반환된 결과값은 c 채널에 보내지고, main() 함수에서는 채널을 통해 모든 결과값을 수집합니다. 마지막으로 수집된 결과값들을 출력합니다.

go gin framework graceful shutdown 예제

AndersonChoi — Fri, 3 Mar 2023 11:25:59 +0900

https://gin-gonic.com/docs/examples/graceful-restart-or-stop/

Graceful restart or stop

Do you want to graceful restart or stop your web server? There are some ways this can be done. We can use fvbock/endless to replace the default ListenAndServe. Refer issue #296 for more details. router := gin.Default() router.GET("/", handler) // [...] end

gin-gonic.com

gin은 golang에서 많이 쓰이는 웹프레임워크입니다. graceful shutdown을 적용 유무에 따른 동작 방식을 알아보고자 합니다.

1) graceful shutdown 적용한 경우

package main

import (
	"context"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"

	"github.com/gin-gonic/gin"
)

func main() {
	router := gin.Default()
	router.GET("/", func(c *gin.Context) {
		time.Sleep(5 * time.Second)
		c.String(http.StatusOK, "Welcome Gin Server")
	})

	srv := &http.Server{
		Addr:    ":8080",
		Handler: router,
	}

	go func() {
		// service connections
		if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
			log.Fatalf("listen: %s\n", err)
		}
	}()

	// Wait for interrupt signal to gracefully shutdown the server with
	// a timeout of 5 seconds.
	quit := make(chan os.Signal)
	// kill (no param) default send syscanll.SIGTERM
	// kill -2 is syscall.SIGINT
	// kill -9 is syscall. SIGKILL but can"t be catch, so don't need add it
	signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
	<-quit
	log.Println("Shutdown Server ...")

	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancel()
	if err := srv.Shutdown(ctx); err != nil {
		log.Fatal("Server Shutdown:", err)
	}
	// catching ctx.Done(). timeout of 5 seconds.
	select {
	case <-ctx.Done():
		log.Println("timeout of 5 seconds.")
	}
	log.Println("Server exiting")
}

실행 후 localhost:8080에 호출을 수행합니다.

$ curl localhost:8080/

이후 해당 process를 찾아 kill -term 명령어를 내리면

$ kill -term 80021

다음과 같은 로그와 함께 안전하게 종료됩니다.

2021/03/03 22:16:23 Shutdown Server ...
[GIN] 2021/03/03 - 22:16:27 | 200 |  5.000389654s |       127.0.0.1 | GET      "/"
2021/03/03 22:16:28 timeout of 5 seconds.
2021/03/03 22:16:28 Server exiting

이와 동시에 안전하게 종료되기 전 요청에 대해서 리턴을 수행합니다. 그렇기 때문에 요청이 끊키지 않습니다.

Welcome Gin Server

2) graceful shutdown 적용하지 않은 경우

package main

import (
	"net/http"
	"time"

	"github.com/gin-gonic/gin"
)

func main() {
	router := gin.Default()
	router.GET("/", func(c *gin.Context) {
		time.Sleep(5 * time.Second)
		c.String(http.StatusOK, "Welcome Gin Server")
	})

	err := router.Run(":8080")
	if err != nil {
		panic(err)
		return
	}
}

실행 후 localhost:8080에 호출을 수행합니다.

$ curl localhost:8080

이후 해당 process를 찾아 kill -term 명령어를 내리면

$ kill -term 80529

다음과 같이 에러가 발생하고 원치 않은 리턴값이 노출됩니다.

$ curl localhost:8080/
curl: (52) Empty reply from server

windows의 WSL환경에서 아파치 카프카 설치, 실행하는 방법

AndersonChoi — Fri, 24 Feb 2023 18:00:41 +0900

1) git 설치

https://git-scm.com/download/win

Git - Downloading Package

Download for Windows Click here to download the latest (2.39.2) 32-bit version of Git for Windows. This is the most recent maintained build. It was released 10 days ago, on 2023-02-14. Other Git for Windows downloads Standalone Installer 32-bit Git for Win

git-scm.com

상기 URL에서 windows용 git을 설치합니다.

2) WSL 환경 설치

Windows Subsystem for Linux는 리눅스 또는 맥환경처럼 bash쉘을 활용하는 것을 뜻합니다.

https://learn.microsoft.com/ko-kr/windows/wsl/about

Linux용 Windows 하위 시스템이란?

다양한 버전 및 이를 사용하는 방법을 포함하여 Linux용 Windows 하위 시스템에 대해 알아봅니다.

learn.microsoft.com

기본적으로Windows 기능 켜기/끄기 로 가서 다음 내역을 활성화 합니다.

- Linux용 Windows 하위 시스템

- Windows 하이퍼바이저 플랫폼

- 가상 머신 플랫폼

아직까지는 터미널에서 bash를 쳐도 정상동작하지 않는점 참고.

다음으로 Ubuntu를 마이크로소프트 스토어에서 설치합니다.

다음으로 아래 링크에서 커널을 설치하세요.

이전 버전 WSL의 수동 설치 단계 | Microsoft Learn

이전 버전 WSL의 수동 설치 단계

wsl install 명령을 사용하지 않고 이전 버전의 Windows에 WSL을 수동으로 설치하는 방법에 대한 단계별 지침입니다.

learn.microsoft.com

이후에 터미널을 실행시키고 명령어를 실행할 때는 Bash 명령을 사용할 수 있습니다.

2) JDK 1.8 설치

터미널을 실행하고 bash를 입력하여 쉘을 변경합니다.

$ bash

이후에 아래 명령어를 실행하여 openjdk-8-jdk를 설치합니다.

$ sudo apt update
$ sudo apt install openjdk-8-jdk

설치가 완료되면 아래 명령어를 쳐서 openjdk-8-jdk가 잘 설치되었는지 확인합니다.

$ java -version

위 스크린샷과 같이 현재 자바 버전이 나오게 된다면 설치가 잘 된 것입니다.

3) 카프카 바이너리 파일 다운로드 및 압축 풀기

https://kafka.apache.org/downloads

Apache Kafka

Apache Kafka: A Distributed Streaming Platform.

kafka.apache.org

상기 url에서 카프카 바이너리파일을 다운로드할 수 있습니다. 여기서는 kafka 2.7.0을 다운로드하여 테스트합니다.

kafka_2.12-2.7.0.tgz를 다운로드, 압축을 풀고 적절한 디렉토리로 옮깁니다. 압축을 풀 때는 알집과 같은 도구를 사용해도 되고 아니면 터미널 환경에서 다음 명령어로 압축을 풀 수도 있습니다.

$ cd Downloads
$ tar -xvf kafka_2.12-2.7.0.tgz
$ ls
kafka_2.12-2.7.0
kafka_2.12-2.7.0.tgz

위와 같이 tgz와 디렉토리가 보인다면 정상적으로 압축이 풀렸다고 볼 수 있습니다.

4) 주키퍼, 카프카 브로커 실행하기

주키퍼는 다음 명령어로 실행 할 수 있습니다.

$ bin/zookeeper-server-start.sh config/zookeeper.properties
[2023-02-24 18:52:26,944] INFO Reading configuration from: config/zookeeper.properties (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
[2023-02-24 18:52:26,946] WARN config/zookeeper.properties is relative. Prepend ./ to indicate that you're sure! (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
[2023-02-24 18:52:26,951] WARN UserschocoDownloadskafka_2.12-2.7.0/zookeeper is relative. Prepend ./ to indicate that you're sure! (org.apache.zookeeper.server.quorum.QuorumPeerConfig)
[2023-02-24 18:52:26,957] INFO clientPortAddress is 0.0.0.0:2181 (org.apa
...

이후에 새로운 탭에서 카프카 브로커를 다음 명령어로 실행합니다.

$ bin/kafka-server-start.sh config/server.properties
[2023-02-24 18:53:13,530] INFO Registered kafka:type=kafka.Log4jController MBean (kafka.utils.Log4jControllerRegistration$)
[2023-02-24 18:53:14,078] INFO Setting -D jdk.tls.rejectClientInitiatedRenegotiation=true to disable client-initiated TLS renegotiation (org.apache.zookeeper.common.X509Util)
...

5) 카프카 명령어 테스트하기

새로운 터미널 탭을 열고 카프카 바이너리 위치로 이동하여 다음 코드를 실행합니다.

$ bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic test --create

실행이 잘 되었다면 다음과 같이 토픽 이름이 노출됩니다.

intellij에서 golang 프로젝트 인식이 잘 안될때

AndersonChoi — Wed, 22 Feb 2023 14:31:07 +0900

intellij에서 golang을 최초로 실행 시키고 난뒤에

$ go mod init myapplication

프로젝트가 정상적으로 라이브러리들을 Import시키지 못할 때가 있습니다. 그럴 경우에는 cmd + , 를 눌러서 Preferences로 간 뒤 Go Modules의 Enable Go modules integration을 체크하면 싱크됩니다.

싱크가 완료된 go.mod 파일 모습

module myapplication

go 1.19

require (
	github.com/gin-gonic/gin v1.9.0
	github.com/prometheus/client_golang v1.14.0
)

require (
	github.com/beorn7/perks v1.0.1 // indirect
	github.com/bytedance/sonic v1.8.0 // indirect
	github.com/cespare/xxhash/v2 v2.1.2 // indirect
	github.com/chenzhuoyu/base64x v0.0.0-20221115062448-fe3a3abad311 // indirect
	github.com/gin-contrib/sse v0.1.0 // indirect
	github.com/go-playground/locales v0.14.1 // indirect
...

맥 벤투라 디스플레이 해상도 조정하기

AndersonChoi — Wed, 21 Dec 2022 15:02:11 +0900

맥 벤투라에서 디스플레이 옵션에서 확장된 해상도를 확인하기 위해서는 5개 디스플레이 옵션 위에서 마우스 우클릭을 하여 '목록 보기'를 클릭하면 됩니다.

이때 모든 해상도 보기 버튼을 누르면 hidpi가 적용되지 않은 해상도도 함께 볼 수 있습니다.

RestHighLevelClient로 구현한 idempotence 데이터 적재

AndersonChoi — Tue, 29 Nov 2022 11:22:32 +0900

SHA-256이란? http://wiki.hash.kr/index.php/SHA256

SHA256 - 해시넷

SHA-256은 SHA(Secure Hash Algorithm) 알고리즘의 한 종류로서 256비트로 구성되며 64자리 문자열을 반환한다. SHA-256은 미국의 국립표준기술연구소(NIST; National Institute of Standards and Technology)에 의해 공표된

wiki.hash.kr

SHA-256 해시 함수는 어떤 길이의 값을 입력하더라도 256비트의 고정된 결과값을 출력한다. 일반적으로 입력값이 조금만 변동하여도 출력값이 완전히 달라지기 때문에 출력값을 토대로 입력값을 유추하는 것은 거의 불가능하다. 아주 작은 확률로 입력값이 다름에도 불구하고 출력값이 같은 경우가 발생하는데 이것을 충돌이라고 한다. 이러한 충돌의 발생 확률이 낮을수록 좋은 함수라고 평가된다.

그렇다면 ES의 Document의 id를 적재하고자 하는 데이터의 HASH로 사용하면 멱등성 적재가 되지 않을까?

RestHighLevelClient client = new RestHighLevelClient(
                RestClient.builder(new HttpHost("localhost", 9200)));
BulkRequest request = new BulkRequest();

String data = "{\"data\":{\"type\":\"company\",\"name\":\"es\",\"time\":\"2022-01-29T01:59:00.275Z\"}}";
String index = "test-log";
request.add(new IndexRequest(index)
        .source(data, XContentType.JSON)
        .id(encrypt(data)));

client.bulk(request, RequestOptions.DEFAULT);
client.close();

encrypt 메서드

public static String encrypt(String text) throws NoSuchAlgorithmException {
    MessageDigest md = MessageDigest.getInstance("SHA-256");
    md.update(text.getBytes());
    return bytesToHex(md.digest());
}
private static String bytesToHex(byte[] bytes) {
    StringBuilder builder = new StringBuilder();
    for (byte b : bytes) {
        builder.append(String.format("%02x", b));
    }
    return builder.toString();
}

ElasticsearchClient 7.17.7 기준 java client example code

AndersonChoi — Mon, 28 Nov 2022 16:59:04 +0900

1) host, port 주입

RestClient restClient = RestClient.builder(
    new HttpHost("localhost", 9200, "http"),
    new HttpHost("localhost", 9201, "http")).build();
    
    

BulkRequest.Builder br = new BulkRequest.Builder();
ElasticsearchTransport transport = new RestClientTransport(restClient, new JacksonJsonpMapper());
ElasticsearchClient  esClient = new ElasticsearchClient(transport);

2) String으로 된 JSON 데이터 정의

String json = "{\"test\":1}"
Reader input = new StringReader(json);
IndexRequest<JsonData> request = IndexRequest.of(i -> i
        .index("test-log")  //set index
        .withJson(input)
);

3) 전송

IndexResponse response = esClient.index(request);
log.info("Indexed with version " + response.version());

출처

https://www.elastic.co/guide/en/elasticsearch/client/java-api-client/7.17/java-rest-low-usage-initialization.html

Initialization | Elasticsearch Java API Client [7.17] | Elastic

A RestClient instance can be built through the corresponding RestClientBuilder class, created via RestClient#builder(HttpHost...) static method. The only required argument is one or more hosts that the client will communicate with, provided as instances of

www.elastic.co

https://www.elastic.co/guide/en/elasticsearch/client/java-api-client/7.17/indexing.html

Indexing single documents | Elasticsearch Java API Client [7.17] | Elastic

Indexing single documentsedit The Java API Client offers several ways to index data: you can provide application objects that will be automatically mapped to JSON, or you can provide raw JSON data. Using application objects is more suited to applications w

www.elastic.co

커넥트 REST API 확장 플러그인 : Connect Rest Extension Plugin

AndersonChoi — Tue, 4 Oct 2022 20:59:47 +0900

Connect Framework offers REST API that is used to mange the lifecycle of the connector. Its imperative in most enterprises to secure the API and also add authorization to the end points. We could add the ability for authentication and authorization in the framework. But the security requirements are so broad that it's not practical to support all of them in the framework. Hence we must provide ability for users to plug resources that help achieve the required capabilities.

While security is prime use cases for this extension. Its not limited to that. Some of the common use cases are

- Build a custom Authentication filter
- Build a custom Authorization filter
- Complex extensions can even provide filters that rewrite/validate the connector requests to enforce additional constraints on the connector configurations

https://cwiki.apache.org/confluence/display/KAFKA/KIP-285%3A+Connect+Rest+Extension+Plugin

KIP-285: Connect Rest Extension Plugin - Apache Kafka - Apache Software Foundation

Status Current state: Accepted Discussion thread: here JIRA: KAFKA-6776 - 이슈 세부사항 가져오는 중... 상태 PR : https://github.com/apache/kafka/pull/4931 Released: 2.0.0 Motivation Connect Framework offers REST API that is used to mange t

cwiki.apache.org

Debezium 사용 예제

https://github.com/debezium/debezium-ui/blob/main/backend/src/main/java/io/debezium/configserver/rest/client/KafkaConnectClient.java

GitHub - debezium/debezium-ui: A web UI for Debezium; Please log issues at https://issues.redhat.com/browse/DBZ.

A web UI for Debezium; Please log issues at https://issues.redhat.com/browse/DBZ. - GitHub - debezium/debezium-ui: A web UI for Debezium; Please log issues at https://issues.redhat.com/browse/DBZ.

github.com

@POST
@Path("/connectors/{connector-name}/restart")
@Consumes("application/json")
@Produces("application/json")
Response restartConnector(@PathParam("connector-name") String connectorName) throws ProcessingException, IOException;

@POST
@Path("/connectors/{connector-name}/tasks/{task-number}/restart")
@Consumes("application/json")
@Produces("application/json")
Response restartConnectorTask(@PathParam("connector-name") String connectorName, @PathParam("task-number") int taskNumber) throws ProcessingException, IOException;

 // 새로운 endpoint 
@GET
@Path("/debezium/transforms")
@Produces("application/json")
List<TransformsInfo> listTransforms() throws ProcessingException, IOException;

@GET
@Path("/debezium/topic-creation")
@Produces("application/json")
Boolean isTopicCreationEnabled() throws ProcessingException, IOException;

추가적인 rest endpoint를 활용한다.

https://github.com/debezium/debezium/blob/aa1982adc50cad10cf1c7e4123335a7900e3d16e/debezium-connect-rest-extension/src/main/java/io/debezium/kcrestextension/DebeziumResource.java#L114

GitHub - debezium/debezium: Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/brows

Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/browse/DBZ. - GitHub - debezium/debezium: Change data capture for a variety of databases. Please log i...

github.com

@GET
@Path("/transforms")
public List<TransformsInfo> listTransforms() {
    return this.getTransforms();
}

private synchronized List<TransformsInfo> getTransforms() {
    if (this.transforms.isEmpty()) {
        for (PluginDesc<Transformation<?>> plugin : herder.plugins().transformations()) {
            if ("org.apache.kafka.connect.runtime.PredicatedTransformation".equals(plugin.className())) {
                this.transforms.add(new TransformsInfo(HasHeaderKey.class.getName(), (new HasHeaderKey<>().config())));
                this.transforms.add(new TransformsInfo(RecordIsTombstone.class.getName(), (new RecordIsTombstone<>().config())));
                this.transforms.add(new TransformsInfo(TopicNameMatches.class.getName(), (new TopicNameMatches<>().config())));
            }
            else {
                this.transforms.add(new TransformsInfo(plugin));
            }
        }
    }

    return Collections.unmodifiableList(this.transforms);
}

@GET
@Path("/topic-creation")
public boolean getTopicCreationEnabled() {
    return this.isTopicCreationEnabled;
}

private synchronized Boolean isTopicCreationEnabled() {
    Version kafkaConnectVersion = parseVersion(AppInfoParser.getVersion());
    String topicCreationProperty = (String) config.get("topic.creation.enable");
    if (null == topicCreationProperty) { // when config is not set, default to true
        topicCreationProperty = "true";
    }
    return TOPIC_CREATION_KAFKA_VERSION.compareTo(kafkaConnectVersion) <= 0
            && Boolean.parseBoolean(topicCreationProperty);
}

데브원영

카프카 source connector가 exactly-once를 지원하는 방법

1. 기존에는 source connector의 EOS를 지원하지 않았던 이유

2. 관련 메커니즘

3. 설정하는 방법

카프카는 복제본(replica)를 자동으로 다른 브로커로 재배치하지 않습니다

카프카의 동작

관련 문서

Decommissioning brokers

그렇다면 운영에서는 어떻게 대응해야 하는가

KIP-932 Queues for Kafka 사용해보기(KafkaShareConsumer)

KafkaShareConsumer 사용 방법

1) cluster 실행 및 설정

2) consumer code

deliveryCount란?

5개 인스턴스(컨슈머) 실행해보기

Apache Kafka 4.1.0 docker-compose.yaml 실행

카프카 바이너리 다운로드

Openapi API 사용시 ⚠️선결제하면 안되는 이유.. - 돈낭비..

약관을 찾아봤더니

Ubuntu에서 JDK11 설치 후 기본값으로 설정하기

윈도우즈 wsl2 환경에서 로컬 카프카 브로커 연동하기

준비물

Sent auto-creation request for Set(__consumer_offsets) to the active controller 에러 해결 방법

카프카4.0 부터는 eager rebalancing protocol이 삭제됩니다.

Why drop?

이후 버전에서는?

EAGER 리밸런싱 프로토콜이란?

코드로 설정하는 방법?

[local macOS 환경] apache kafka(3.5.0기준) + redpanda/console 로 편하게 테스트 하기

1) Apache kafka binary setting & start

2) Redpanda console start

3) Result

카프카에서 데이터 삭제는 어떻게 이루어 지는가>

kafka 4.0부터는 스칼라 2.12가 더 이상 사용되지 않습니다.

그럼 스칼라3은 언제 배포되나?

standalone 카프카(kraft모드 in local) 실행 스크립트(1줄)

4.0.0에서는?

KIP-932: Queues for Kafka 조사

프로듀서는 어떻게 다르게 동작하나?

Queue 토픽

컨슈머가 동작하게 하는 방법?

실제 코드는 어떻게 될까?

trino에서 java.sql.SQLException: Unrecognized connection property 'url' 에러가 나는 이유와 해결 방법

해결방법

Spark 개발시, main/resources 패키지에 hdfs-site.xml, core-site.xml 등을 넣는 이유

HDFS 설정 파일 (hdfs-site.xml)

main/resources 디렉터리에 배치하는 이유

standalone 카프카(kraft모드 in local) 실행을 위한 준비와 실행

bin/kafka-storage.sh 로 따로 파일과 디렉토리를 만들어야 하는 이유

scala에러 Unable to make private java.nio.DirectByteBuffer 해결 방법

해결방법

아파치 플링크는 2.0 버전부터는 더이상 scala API를 지원하지 않습니다.

무엇이 바뀌나?

Redis-go를 interface화 하여 사용하기

redis.go

main.go

카프카 컨슈머의 auto.offset.reset 옵션을 반드시 earliest로 변경해야 하는 이유

왜 데이터가 유실 될까?

유실을 막기 위 해서 어떻게 해야 하나

json value가 null일때 golang은 Unmarshal을 잘 할 수 있을까?

만약 0으로 초기화가 아니라 null로 초기화 하고 싶다면?

JSON은 null을 키값으로 가질 수 있을까?

왜그럴까요?

You aren't going to Need it(YAGNI). 그 기능이 필요할 때 만들어라!

원칙

한계

고려사항

map[string]interface 데이터를 avro 포맷으로 파일 저장하는 방법

카프카에서 계층 저장소(Tiered storage)가 필요한 이유

1) 컴퓨팅 리소스 감소

2) 휴먼 리소스 감소

정리

참고문서

신뢰성 있는 카프카 애플리케이션을 만드는 3가지 방법

카프카 프로듀서의 acks=all 옵션은 사실(?) 느리지 않다!

결론

기존에 생성된 compact topic의 cleanup.policy를 변경하는 방법

Compacted topic에 null key 레코드를 전송하면?

1) Compacted 토픽 생성