[번역]카프카 스트림즈 운영하기(상태 복구)

원글 : https://docs.confluent.io/platform/current/streams/developer-guide/running-app.html

Running Streams Applications | Confluent Documentation

카프카 스트림즈 실행하기

카프카 스트림즈 라이브러리를 사용하여 자바 애플리케이션을 개발, 실행할 수 있습니다. 카프카 스트림즈는 state에 대한 여러가지 알림 설정을 제공합니다. 실행 중 자세한 모니터링에 대해서는 모니터링 가이드를 참고하세요. https://docs.confluent.io/platform/current/streams/monitoring.html#streams-monitoring

Monitoring Kafka Streams Applications | Confluent Documentation

카프카 스트림즈 실행하기

자바 애플리케이션을 fatJar로 압축하여 다음 명령어로 실행합니다.

# Start the application in class `com.example.MyStreamsApp`
# from the fat JAR named `path-to-app-fatjar.jar`.
  java -cp path-to-app-fatjar.jar com.example.MyStreamsApp

 

애플리케이션 리밸런스때 발생하는 상태 복구 과정

카프카 스트림즈 내부의 태스크의 이동이 발생하면 태스크가 처리하던 상태 데이터는 스트림즈 애플리케이션이 다시 실행되기 전에 완전히 복구를 진행합니다. 이를 통해 exactly once 처리를 위한 준비가 되는 것입니다. 카프카 스트림즈에서 상태를 복구하기 위해서 changelog 토픽을 사용하여 상태 저장소를 재생성합니다. changelog기반 복구를 진행하는데 지연을 줄이기 위해 local state store를 사용하기도 합니다. num.standby.replicas를 설정하여 이 지연 정도를 조절할 수 있습니다. 스트림즈 애플리케이션에서 태스크가 초기화되거나 다시 초기화가 필요할 때 다음과 같은 형태로 상태 저장소가 복구됩니다.

num.standby.replicas
The number of standby replicas. Standby replicas are shadow copies of local state stores. Kafka Streams attempts to create the specified number of replicas per store and keep them up to date as long as there are enough instances running. Standby replicas are used to minimize the latency of task failover. A task that was previously running on a failed instance is preferred to restart on an instance that has standby replicas so that the local state store restoration process from its changelog can be minimized. Details about how Kafka Streams makes use of the standby replicas to minimize the cost of resuming tasks on failover can be found in the State section.

Note : If you configure n standby replicas, you need to provision n+1 KafkaStreams instances.

- 만약 로컬 상태 저장소가 없다면 changelog토픽으로부터 데이터를 replay진행합니다. 상태 저장소를 다시 생성합니다.

- 만약 로컬 상태 저장소가 있다면 changelog토픽으로부터 replay를 진행하여 체크포인트를 확인합니다. 가장 최신의 snapshot부터 데이터를 처리할 수 있도록 도와줍니다. 이 방법은 작은 개수의 changelog에 대해 적용되기 때문에 시간이 적게 걸립니다. 

 

카프카 스트림즈 라이브러리 2.6 이상 버전에서는 태스크를 복구하기 위해 백그라운드에서 레플리카를 사용합니다. 스트림즈 애플리케이션이 실행중인 인스턴스에서 상당히 많은 태스크의 상태를 복구가 필요할 수 있습니다. 상태가 있는 태스크의 경우 acceptable.recovery.lag을 통해 상태에 대한 정보를 설정 할 수 있습니다.

acceptable.recovery.lag
The maximum acceptable lag (total number of offsets to catch up from the changelog) for an instance to be considered caught-up and able to receive an active task. Streams only assigns stateful active tasks to instances whose state stores are within the acceptable recovery lag, if any exist, and assigns warmup replicas to restore state in the background for instances that are not yet caught up. Should correspond to a recovery time of well under a minute for a given workload. Must be at least 0.

위 옵션을 통해 태스크의 이동이 발생할 때 다운타임을 막는 것입니다. 인스턴스에서 상태를 복구할 때 복구가 완료된 인스턴스에서는 데이터를 지속적으로 처리할 수 있게 하는 것입니다. 카프카 스트림즈에서 태스크에 대한 복구와 변경상태를 확인하기 위해 probing.rebalance.interval.ms 옵션을 제공합니다.

probing.rebalance.interval.ms
The maximum time to wait before triggering a rebalance to probe for warmup replicas that have restored enough to be considered caught up. Kafka Streams assigns stateful active tasks only to instances that are caught up and within the acceptable.recovery.lag, if any exist. Probing rebalances are used to query the latest total lag of warmup replicas and transition them to active tasks if ready. They will continue to be triggered as long as there are warmup tasks, and until the assignment is balanced. Must be at least 1 minute.

추가 정보

The exception to this task availability is if none of the instances have a caught up version of that task. In this case, Kafka Streams can only assign the active task to an instance that isn’t caught up and must block further processing on restoration of the task’s state from the changelog. If high availability is important for your application, we strongly recommended that you to enable standbys.