Kafka를 이용한 확장성 문제 해결

Kafka는 애플리케이션 외부에서 동작하는 로그 시스템이므로 메시지의 저장 상태를 유지하는 데에 애플리케이션 JVM의 자원을 소모하지 않는다. 따라서 대량의 메시지가 발생하더라도 애플리케이션 처리량에 직접적인 영향을 주지 않는다. 이런 측면에서 Kafka는 처리량 문제를 완화하기도 하지만, 근본적으로 대량의 이벤트 처리를 제어할 수 있는 구조적 수단을 제공하는 것이다.

 

실제 메시지 처리는 애플리케이션 내부에서 일어나므로 높은 처리량의 핵심은 어느 메시지(작업)를 누가, 언제 소비(처리)하느냐에 달려 있다. 즉, 한정된 JVM 자원을 최대 효율로 활용하는 것은 전적으로 오케스트레이션 방식에 의존한다. Kafka는 자체적으로 대량의 작업을 안정적으로 분배하고 병렬 처리할 수 있는 환경을 제공함으로써 단일 JVM을 넘어서는 비동기 처리 구조와 확장성을 제공한다.

 

특히 Kafka 자체도 분산 네트워크 시스템으로서 파티션 기반의 효율적인 로드 밸런싱을 제공한다. 이 구조는 병렬 처리를 단일 JVM 자원에 가두던 기존 한계를 해소하고, 네트워크로 연결된 MSA(Microservices Architecture) 환경에서 서비스 단위의 수평 확장을 가능하게 한다. 따라서 처리량 문제를 애플리케이션 내부가 아닌 시스템 구조 차원에서 근본적으로 완화한다.

 

추가로 Kafka 브로커는 메시지를 애플리케이션 외부 디스크에  파티션 단위 로그로 영속 저장하고, 이를 여러 브로커에 복제함으로써 장애 상황에서도 데이터 유실을 방지한다. 이를 통해 내구성 문제 역시 충분히 해결한다.

 

  • Kafka = 메시지를 안전하게 분산 저장하고, 병렬 처리 환경을 제공
  • 애플리케이션 = 높은 처리량과 시스템 안정성을 유지하며 작업을 수행하고, 장애시 복구 및 재처리 가능
MSA에서 마이크로서비스는 Kafka라는 오케스트레이션 환경 위에서 유기적으로 협업함으로써, 높은 확장성과 안정성을 갖춘 분산 애플리케이션으로 동작한다.

 

Kafka는 대규모 비동기 작업이 안정적으로 처리될 수 있도록 데이터를 로그로 저장하고, 애플리케이션에 오케스트레이션 환경을 제공함으로써 시스템의 안정성을 확보하고 수평적 확장성을 보장한다.

Kafka의 구조

Apache Kafka는 분산 네트워크 환경에서 메시지를 로그 형태로 저장하고 처리하는 시스템이다. 분산 시스템은 CAP 이론에 따라 Consistency(일관성),Availability(가용성),Partition Tolerance(분할 내성)간의 트레이드오프를 마주하며, Kafka는 Partition Tolerance를 전제로 Consistency와 Availability를 설정을 통해 조절할 수 있도록 설계됐다.

 

이러한 특성은 내부적으로 파티션 분할, Leader-Follower 복제 구조와 In-Sync Replica(ISR) 매커니즘을 통해 구현되며 애플리케이션이 요구하는 수준의 안정성과 확장성을 유연하게 선택할 수 있게 한다.

 

Kafka의 내부 구조를 통해 이러한 선택이 어떻게 구현되고 애플리케이션의 확장성에 기여하는지 알아보자.

Kafka의 기본 개념은 다음과 같다.

  • Producer
    • 스프링 내부에서 이벤트, 로그, 알림 등 메시지를 생성하고 Topic을 붙여서 Kafka로 전송하는 클라이언트
    • Spring Application → Kafka Broker
  • Consumer
    • Kafka에서 구독한 Topic의 메시지를 스프링 안으로 받아와 읽고 처리하는 역할
    • Kafka Broker → Spring Application
  • Broker
    • 스프링 외부에서 동작하는 Kafka 서버 자체
    • 여러 Broker 설정 가능, Partition을 디스크에 분산 저장
  • Topic
    • 메시지를 논리적으로 분류하는 단위
    • Kafka 서버는 Producer가 보낸 메시지를 Topic별로 저장, 저장된 메시지는 해당 Topic을 구독한 Consumer가 처리
  • Partition
    • Topic 내에서 메시지를 병렬 처리 가능하도록 나눈 단위
    • Partition은 순서가 보장되며, 병렬 소비 제공
  • Offset
    • log offset: Partition 내에서 메시지의 고유 위치를 나타내는 번호
    • Producer가 보낸 메시지를 append하며 LEO(Log End Offset) 증가
    • Consumer offset: Consumer Group 단위로 마지막으로 처리한 offset을 커밋하여 Broker에 전달
    •  Broker는 이를 기반으로 순서 보장과 안전한 분산 처리 제공

 

Producer-Broker-Consumer 구조

Kafka의 Producer-Broker-Consumer 구조에서 메시지는 토픽 내 파티션 단위로 분할되어 각 브로커에 분산 저장된다. 각 파티션은 하나의 컨슈머 스레드에 의해 순차적으로 소비되며, 동일 파티션 내 메시지의 순서 보장을 위해 하나의 파티션은 동시에 하나의 컨슈머 스레드에만 할당된다. 이로 인해 파티션 수가 곧 병렬 처리의 단위가 되며 컨슈머의 concurrency 설정은 이러한 병렬성을 얼마나 효율적으로 활용할 수 있는지를 결정한다.

브로커와 파티션

브로커는 이러한 파티션을 분산 저장하는 물리적 노드로서 디스크와 네트워크 부하를 분산시키고 파티션은 병렬 처리를 위한 논리적 분할 단위이다. 파티션 수와 브로커 수는 독립적으로 설정할 수 있지만 파티션 수가 충분히 많을수록 각 브로커에 리더 파티션이 고르게 분산되어 부하가 균등하게 분산된다. 반대로 파티션 수가 적은 경우 일부 브로커는 리더를 갖지 못해 실제 트래픽을 고르게 처리하지 못하는 비효율적인 상태가 발생할 수 있다.

브로커 수 = 2, 파티션 수 = 3
브로커 수 = 3, 파티션 수 = 2

 

첫번째 그림과 같이 브로커 개수가 파티션 개수보다 적으면 한 브로커가 다수의 파티션 리더를 가질 수 있고, 반대의 경우 두번째 그림과 같이 어떤 파티션 리더도 갖지 않는 브로커가 존재하게 된다.

 

전자의 경우 시스템이 더 많은 리더를 가진 특정 브로커에 의존하는 구조가, 후자의 경우 저장 비용에 비해 트래픽 분산 효과가 없는 비효율적인 구조가 되므로 서비스 규모에 맞는 적절한 구조를 설계할 필요가 있다.

 

따라서 Kafka의 처리량과 확장성은 파티션 기반의 병렬 처리 구조와 이를 소비하는 컨슈머 설정에 의해 결정되며 브로커는 이를 안정적으로 분산 처리하는 기반을 제공한다. 실무에서는 파티션 수를 브로커 수 이상으로 설정하고 균등하게 분산시킴으로써 안정성과 부하 분산, 병렬성을 동시에 확보하는 것이 일반적이다.

 

파티션과 컨슈머

컨슈머 그룹 내에서 설정하는 concurrency는 메시지를 동시에 처리할 수 있는 스레드 수를 의미하지만 병렬 처리의 실질적인 상한은 파티션 개수에 의해 제한된다. 한 파티션을 처리하는 담당 스레드는 두개 이상이 될 수 없으므로 concurrency가 파티션 수보다 클 경우 일부 스레드는 병렬 처리에 참여하지 못하게 된다. 반대의 경우 여러 파티션이 하나의 스레드에 묶여 처리되므로 병렬성이 충분히 활용되지 못한다.

파티션 수 = 3, concurrency = 20 인 경우 17개의 스레드가 유휴 상태
파티션 수 = 3, concurrency = 2 인 경우 파티션 2개를 T2 스레드 혼자 처리하며 병렬성 저하

 

파티션 수가 충분히 많을 경우 각 스레드가 하나의 파티션을 담당하여 병렬 처리 효율이 늘어나지만 파티션 수를 과도하게 증가시키는 것은 오히려 시스템에 부담을 줄 수 있다. 파티션이 많아질수록 파일 핸들 수와 메타데이터 관리 비용이 증가하고, 리더 선출 및 복제 오버헤드와 컨슈머 리밸런싱 비용이 증가하기 때문이다.

 

결과적으로 Kafka의 처리량은 파티션 수와 이를 소비하는 컨슈머의 concurrency 설정에 의해 결정되며, 브로커는 이러한 파티션을 분산 저장하고 복제함으로써 부하를 분산하고 시스템 안정성을 확보하는 역할을 한다.

 

Kafka의 병렬 처리 단위는 파티션에 의해 결정되며 프로듀서와 컨슈머는 그 병렬성을 효율적으로 활용하여 성능 확장성을 확보한다. 브로커는 파티션을 복제 및 분산 저장함으로써 시스템의 안정성 측면에서 확장성을 확보한다.

 

Broker-Topic-Partition 구조

KRaft 모드 Kafka 클러스터 구조

 

프로듀서는 (topic, key, value) 형식으로 메시지를 전송하는데 이때 key는 value로 보내진 이벤트 객체의 식별자가 된다. 기본적으로 이 key를 해시한 뒤, 토픽의 파티션 개수로 모듈러 연산하여 여러 파티션 중 어느 파티션에 저장될 지 결정한다. 데이터 읽기, 쓰기는 파티션 리더만이 수행할 수 있으므로 프로듀서는 자신이 전송할 이벤트가 들어갈 파티션의 리더 브로커에게 전송해야한다. 따라서 다음 과정을 통해 프로듀서는 리더 브로커에게 새 메시지를 전송하고, 클러스터는 새로운 파티션 상태를 동기화한다.

  1. 파티션 결정: 프로듀서는 메시지를 완성한 후 key를 해시 후 모듈러 연산해서 목적지 파티션 번호를 계산
  2. 부트스트랩 서버 접속: bootstrap-servers 목록에 있는 브로커 중 아무에게나 연결을 시도
  3. 리더 정보 요청: 연결이 된 브로커에게 프로듀서는 토픽과 계산한 파티션 번호를 보내고, 브로커(이자 컨트롤러)는 클러스터 메타데이터 확인 후 현재 파티션 리더인 브로커 번호를 알려줌
  4. 리더 파티션에 메시지 전송: 프로듀서는 파티션 리더를 갖고 있는 브로커에게 메시지 전송
  5. 팔로워 파티션의 복제: 파티션 리더가 메시지를 새로 추가하고 LEO를 갱신하면 해당 파티션의 팔로워는 리더의 로그를 복제

3개의 파티션을 운영하고 showId로 파티셔닝하는 apporval-show-topic

 

다음은 3개의 replica와 3개의 partition 구조로 운영 중인 approval-show-topic이다. 각 브로커는 이 토픽의 파티션 리더를 하나씩 갖고 있다.  이 토픽이 showId를 기준으로 파티셔닝이 된다고 하면, showId가 34, 15, 60인 이벤트가 순서대로 들어왔을 때 프로듀서가 보낸 메시지가 클러스터 내부에서 어떻게 분산 저장되는지 알아보자.

id=34인 이벤트 전송 시

 

34%3=1이므로 프로듀서는 메시지의 목적지가 partition 1임을 계산 후, 리더 파티션이 Broker 2에 있다는 정보를 받아 메시지를 전송한다. Broker 2의 파티션 리더는 새 매시지를 파티션 1에 추가하고 Broker 1, 3의 파티션 팔로워들은 Broker 2의 파티션 1을 복제한다.

id=15인 이벤트 전송 시

 

15%3=0이고 프로듀서는 Broker 1로 메시지를 전송한다. Broker 2, 3은 Broker 1의 파티션 0을 복제한다.

id=60인 이벤트 전송 시

 

60%3=0이고 프로듀서는 Broker 1로 메시지를 전송한다. Broker 2, 3은 Broker 1의 파티션 0을 복제한다.

  • 일부 브로커에 장애가 발생해도 전체 시스템 장애로 확산되지 않도록 하는 구조적 기반을 제공한다 → Availability

Leader–Follower 구조와 Replica

단일 토픽에서 Leader-Follower 구조

리더(Leader) 

  • 해당 파티션의 대표 복제본(replica)
  • 읽기/쓰기 요청을 담당해서 처리

팔로워(Follower) 

  • 리더의 데이터를 복제하는 replica
  • 직접 읽기/쓰기 요청을 처리하지 않고 리더의 데이터를 동기화

 

Replica 매커니즘

replica는 리더 파티션의 복제본으로 브로커 장애시 리더를 대체하기 위한 장치이다. 각 파티션은 여러 개의 replica로 복제되어 서로 다른 브로커에 분산 저장되며 leader도 replica로 집계한다. 각 파티션은 하나의 leader와 여러 follower로 구성되며 producer와 consumer는 leader를 통해서만 데이터를 쓰거나 읽는다. follower는 leader의 데이터를 복제하여 동기화하고, leader 브로커에서 장애 발생 시 follower에서 새로운 leader로 승격될 수 있도록 함으로써 Durability와 Availability을 보장한다.

 

각 replica가 서로 다른 브로커에 분산 저장되므로 특정 브로커에 장애가 발생하여 leader가 죽더라도, 다른 브로커에서 동기화를 유지하던 나머지 replica 중 하나가 기존 leader를 대체하여 데이터 유실 없이 서비스를 지속할 수 있다.

 

Replication Factor

Replication Factor는 각 파티션이 유지해야 하는 replica의 개수이다. Kafka에서 각 파티션은 설정된 Replication Factor에 따라 여러 replica로 복제되어 서로 다른 브로커에 분산 저장된다. 이는 장애 발생 시에 데이터를 보존하고 서비스 가용성을 유지하기 위한 핵심 메커니즘이다.

 

Kafka에서 replica는 서로 독립적인 장애 도메인을 구성하는 단위로 정의한다. 만약 replica 개수가 브로커 수보다 많다면 하나의 파티션에 대해 여러 replica를 갖는 브로커가 생길 수 있다. 그러나 동일한 브로커에 여러 replica가 존재할 경우 해당 브로커 장애 발생 시 동시에 손실되어 복제의 의미가 사라지게 된다.

 

따라서 Kafka는 각 replica가 반드시 서로 다른 브로커에 배치되도록 강제하며 Replication Factor는 클러스터 내 브로커 수를 초과할 수 없다는 제약을 갖는다. 예를 들어 브로커가 3개인 환경에서는 replication factor를 최대 3까지 설정할 수 있으며, replication factor가 3인 경우 각 파티션은 모든 브로커에 하나씩 복제된다. 반대로 브로커가 2개인 경우 replication factor를 3으로 설정하는 것은 불가능하다.

파티션 수 = 3, RF = 1
파티션 수 = 3, RF = 2
파티션 수 = 3, RF = 3

 

Replication Factor가 높을수록 더 많은 장애 상황에서 견딜 수 있지만 복제를 위한 저장 공간과 네트워크 비용이 증가한다. 따라서 실무에서는 브로커 수를 고려하여 이 값을 설정하고, 일반적으로 3을 기준으로 데이터 안정성과 저장 비용 사이의 균형을 맞추는 것이 보편적이라고 한다.

  • 데이터 흐름이 단일 진입점으로 수렴되므로 쓰기 순서와 데이터 일관성이 보장된다 → Consistency
  • Leader 장애 시 동기화 상태를 유지하던 Follower 중 하나가 승격되어 서비스가 지속된다 → Availability
  • Broker 간 네트워크가 끊겨도 Follower와의 동기화만 중단될 뿐, Leader가 존재하는 Partition은 계속 요청을 처리하며 시스템을 지속할 수 있다 → Partition Tolerance
모든 읽기와 쓰기는 Leader를 통해서만 수행됨으로써 일관성을 보장하고,
Follower는 Leader의 파티션을 복제하며 가용성을 보장하고,
Replica는 서로 다른 브로커에 분산 저장되며 분할 내성을 보장한다.

 

Controller 

ZooKeeper 기반 단일 컨트롤러 구조와 KRaft 모드 다중 컨트롤러 구조

 

Kafka는 다중 브로커를 지원하는 분산 시스템으로 클러스터 메타데이터와 파티션 상태를 관리하는 컨트롤러가 존재한다. 과거에는 ZooKeeper라는 외부 분산 코디네이터가 액티브 컨트롤러 선출과 관리를 전담하는 의존적 구조였으나, 최근에는 이 역할을 내부적으로 통합한 KRaft 모드가 표준화되었다.

 

KRaft 체제에서 각 브로커는 컨트롤러 후보 노드로서 Raft 합의 알고리즘에 참여하여 Quorum을 형성한다. 이들 중 투표로 선출된 한 대의 노드가 액티브 컨트롤러로 승격되어 클러스터의 메타데이터 결정 및 상태 조율을 전담한다. 모든 노드는 컨트롤러 후보자로서 선출시 언제든 컨트롤러 역할을 수행할 수 있다(이로 인해 클러스터 메타데이터를 조회해서 프로듀서에게 리더 브로커를 알려줄 수 있다). 이로써 외부 코디네이터 없이도 액티브 컨트롤러가 선출되고 실질적인 지휘권을 행사하는 자치 관리 구조를 갖는다.

 

KRaft 모드:

  • KRaft 모드에서는 Zookeeper없이 내부에서 합의 알고리즘을 통해 직접 클러스터 상태를 관리
  • 브로커 중 Active Controller 하나가 전체 클러스터를 조율
  • 컨트롤러 역할을 위한 통신 채널의 포트번호는 일반적으로 9093


활성 컨트롤러는 파티션 리더 선출, ISR 동기화 관리, 브로커 장애 감지 등 클러스터 오케스트레이션을 수행한다.

 

  • Broker 장애를 감지하고, 리더가 없어진 파티션에 대해 빠르게 리더를 재선출해 응답 가능한 상태를 유지한다 → Availability
  • 일부 Broker가 단절된 상태에서도 남은 Broker에서 새 Leader를 선출하여 단일 리더 집합과 클러스터 구조를 유지한다 → Partition Tolerance
  • 새 Leader는 반드시 ISR(In-Sync Replicas)에 속한 브로커 중에서만 선출되며 ISR이 비어 있는 경우에는 파티션이 오프라인 상태로 전환된다 → Consistency

 

ISR(In-Sync Replicas)

ISR(In-Sync Replica)은 leader와 충분히 동기화된 follower들의 집합을 의미한다. ISR은 각 파티션의 메타데이터로 관리되며 해당 파티션의 leader와 충분히 동기화된 replica들이 위치한 브로커 ID의 집합 형태로 저장된다. 이 정보는 컨트롤러를 통해 클러스터 전체에 공유되며 follower의 동기화 상태 변화에 따라 동적으로 갱신된다.

 

ISR의 상태는 producer의 acks 설정 및 min.insync.replicas 조건과 함께 메시지 쓰기의 성공 여부를 결정하는 기준으로 작용하는데 그 매커니즘은 다음과 같다.

 

acks

acks는 producer가 메시지 전송 후 broker로부터 응답을 받을 시점을 결정하는 설정으로, 메시지 쓰기의 신뢰성과 처리량 간의 트레이드오프를 제어하는 역할을 한다. Kafka에서 실제 ack 전송은 leader 브로커가 수행하며 producer는 이 응답을 기준으로 메시지 전송의 성공 여부를 판단한다.

 

acks=0으로 설정할 경우 producer는 broker의 응답을 기다리지 않고 즉시 다음 작업을 수행한다. 이는 가장 높은 처리량을 제공하지만 메시지 유실 가능성이 존재한다.

 

acks=1인 경우 leader에 데이터가 기록된 이후 응답을 반환하므로 일정 수준의 내구성을 보장하지만 follower로의 복제가 완료되기 전 장애가 발생할 경우 데이터가 유실될 수 있다.

 

acks=all(-1)로 설정하면 ISR에 포함된 모든 replica가 데이터를 기록한 이후에만 leader가 응답을 반환한다. 이를 통해 가장 높은 수준의 데이터 일관성과 내구성을 확보할 수 있지만, 그만큼 지연 시간이 증가하고 ISR 상태에 따라 쓰기가 실패할 수 있다.

 

따라서 acks 설정은 데이터 일관성과 처리량 간의 균형을 조절하는 핵심 요소이며, min.insync.replicas와 함께 메시지 쓰기의 성공 조건을 정의한다.

 

브로커와 producer가 ack 통신을 기반으로 동작하는 과정은 다음과 같다.

1. Producer는 이벤트 생성 후 Leader 파티션을 가진 브로커에 전송
2. 브로커는 leader 파티션에 저장 후 Follower들에게 replicate
3. ISR에 있는 replica들이 기록 완료
4. Leader가 producer가 설정한 ack 조건 만족 여부 판단
5. 조건 만족시 Leader는 Producer에게 ack 응답 전송
6. Producer는 전송 흐름을 “성공”으로 간주하고 다음 작업 진행

 

acks 설정 Broker 동작 Producer 동작
acks = 0 응답 X (leader 기록 여부도 보장 못함) 응답을 기다리지 않고 즉시 다음 작업 진행
acks = 1 leader에만 기록 후 즉시 응답 (follower 복제 보장 X) ack 수신하면 성공으로 판단 후 다음 작업 진행
acks = all (-1) ISR에 포함된 모든 브로커의 replica에 기록 완료해야 응답
(ISR 복제 보장)		 ack 수신하면 성공으로 판단 후 다음 작업 진행

 

min.insync.replicas

min.insync.replicas는 메시지 쓰기가 성공하기 위해 반드시 유지되어야 하는 최소 ISR(In-Sync Replica) 크기를 의미한다. producer가 acks=all 설정을 사용할 경우, leader는 ISR에 포함된 replica들이 메시지 기록을 완료해야만 producer에게 응답을 반환한다. 이때 ISR의 크기가 min.insync.replicas보다 작을 경우, 데이터 일관성을 보장하기 위해 leader는 메시지 쓰기를 실패로 처리한다.

Producer는 retries, delivery.timeout.ms, enable.idempotence 설정에 따라 실패 처리된 작업을 재처리할 수 있다. 

 

즉, min.insync.replicas는 단순한 복제본 개수가 아니라, 메시지의 내구성과 일관성을 보장하기 위한 최소한의 동기화 수준을 정의하는 기준이다. 따라서 이 값을 작게 설정하면 Kafka는 일부 replica가 장애 상태에 있더라도 leader를 중심으로 시스템을 지속함으로써 Availability를 추구할 수 있다.

 

반면 이 값을 크게 설정할 경우, 충분한 수의 replica가 동기화되지 않은 상태에서는 메시지 쓰기를 차단하는 방식으로 follower의 과도한 뒤쳐짐 및 leader의 과도한 앞서감을 제어할 수 있고 데이터 손실을 방지할 수 있다. 이러한 설정은 시스템의 Latency 및 Availability를 대가로 데이터의 Durability와 Consistency를 강화하는 방향으로 동작한다.

 

이 설정은 ack과 함께 사용되며 메시지 쓰기의 성공 조건을 구성한다. 예를 들어 acks=all로 설정된 경우, leader는 ISR에 포함된 모든 replica가 데이터 기록을 완료한 이후에만 producer에게 ack을 반환한다. 이때 만약 어떤 지역에 대규모 정전이 발생하여 ISR을 구성하던 다수의 브로커가 다운되며 ISR의 크기가 min.insync.replicas보다 작아질 경우, 데이터 일관성을 보장하기 위해 leader는 메시지 쓰기를 실패로 처리한다.

 

이러한 구조를 통해 Kafka는 상황에 따라 Consistency와 Availability간의 균형을 조절할 수 있으며 일부 브로커에 장애가 발생하더라도 다른 replica를 통해 서비스가 지속될 수 있도록 하여 높은 가용성과 확장성을 동시에 달성한다.

 

 

ISR은 Leader의 데이터와 동기화된 Follower 집합으로 기존 Leader가 다운되면 새 Leader는 반드시 ISR에 속한 브로커 중에서 선출된다.

 

  • 리더와 동일한 상태를 유지함으로써 장애 상황 동안에도 최신 데이터 상태를 유지한다 → Consistency
  • Broker 장애 발생 시 ISR이 존재하지 않는다면 리더 선출을(Availability) 포기하고 파티션 처리를 중단한다 → Consistency
  • 네트워크 분리 상황에서 동기화가 깨진 Replica를 ISR에서 제거함으로써 Split-Brain을 방지하고 신뢰 가능한 단일 데이터 상태를 유지한다 → Partition Tolerance

 

Kafka는 Partition Tolerance 하에서 Availability와 Consistency 트레이드오프의 선택을 제공하는 분산 시스템이다.

 

 

 

Kafka를 적용한 비동기 이벤트 처리 구조 구현은 다음 시간에 알아보자.  

'dev > infra' 카테고리의 다른 글

Kafka - 이벤트 기반의 비동기 작업 처리 구조로 알림 기능 구현하기 (4)  (0) 2026.01.22
Kafka - 이벤트 기반의 비동기 작업 처리 구조로 알림 기능 구현하기 (3)  (0) 2026.01.22
Kafka - 이벤트 기반의 비동기 작업 처리 구조로 알림 기능 구현하기 (1)  (0) 2026.01.19

티스토리툴바