중단 배포
컨슈머 애플리케이션을 완전히 종료한 이후에 개선된 코드를 가진 애플리케이션을 배포하는 방식이다. 이 방법은 한정된 서버 자원을 운영하는 기업에 적합하다. 중단 배포는 기존 애플리케이션을 완전히 종료한 이후 신규 애플리케이션을 배포, 실행하여 버전을 올리는 방식이다. 컨슈머 애플리케이션이 완전히 종료된 이후에 신규 애플리케이션이 배포된다는 점이 중요하다. 기존 컨슈머 애플리케이션이 종료되면 더는 토픽의 데이터를 가져갈 수 없어서 컨슈머 랙이 늘어난다. 이는 지연이 발생한다는 뜻이다.
중단 배포를 사용할 경우의 장점
새로운 로직이 적용된 신규 애플리케이션의 실행 전후를 명확하게 특정 오프셋 지점으로 나눌 수 있다.
- 배포 시점의 오프셋을 로깅
- 컨슈머 랙과 파티션별 오프셋을 기록하는 버로우 사용
이러한 특징으로 인해, 신규 배포한 애플리케이션에 이슈가 발생해서 롤백할때 유용하다. 롤백을 통해 기존 애플리케이션으로 원복하고 데이터를 재처리하기 위해 기존 애플리케이션이 처리 완료했던 오프셋으로 재지정하면 되기 때문이다.
무중단 배포
컨슈머의 중단이 불가능한 애플리케이션의 신규 로직 배포가 필요할 경우에는 무중단 배포가 필요하다.
1) 블루/그린 배포
이전 버전 애플리케이션과 신규 버전 애플리케이션을 동시에 띄어놓고 트래픽을 전환하는 방식이다.
파티션 개수와 컨슈머 개수를 동일하게 실행하는 애플리케이션을 운영할때 유용하다. 신규 버전 애플리케이션을 배포하고 동일 컨슈머 그룹으로 파티션을 구독하도록 실행하면 신규 버전 애플리케이션의 컨슈머들은 파티션을 할당받지 못하고 유후 상태(idle)로 기다릴 수 있기 때문이다. 파티션 개수와 컨슈머 개수를 동일하게 운영하고 있지 않다면 일부 파티션은 기존 애플리케이션에 할당되고 일부 파티션은 신규 애플리케이션에 할당되어 섞이기 때문이다.
신규 버전 애플리케이션들이 준비되면 기존 애플리케이션을 모두 중단하면 된다.
리밸런싱이 발생하면서 파티션은 모든 신규 컨슈머와 연동된다. 블루/그린 배포는 리밸런싱이 한번만 발생하여 많은 수의 파티션을 운영하는 경우에도 짧은 리밸런스 시간으로 배포를 수행한다.
블루/그린 배포는 파티션 개수, 컨슈머 개수가 동일한 경우에 사용할 수 있다.
| 토픽 | 컨슈머 애플리케이션 버전 | 컨슈머 |
| 파티션 #0 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #1 |
| 파티션 #0 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #1 |
| 유휴상태 | 컨슈머 스레드 #0 | |
| 컨슈머 스레드 #1 | ||
| 리밸런싱 | ||
| 파티션 #0 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #1 |
2) 롤링 배포
블루/그린 배포의 인스턴스 할당과 반환으로 인한 리소스 낭비를 줄이면서 무중단 배포를 할 수 있다.
파티션 개수가 인스턴스 개수와 같거나, 그보다 많아야 한다.
파티션을 2개로 운영하는 토픽이 있다.
롤링 배포를 위해 최소한 2개의 인스턴스가 필요하다. 2개의 인스턴스 중 1개의 인스턴스를 신규 버전으로 실행하고 모니터링한 이후에 나머지 1개의 인스턴스를 신규 버전으로 배포할 수 있다.
이 경우 리밸런스는 총 2번 발생하여, 파티션 개수가 많을수록 리밸런스 시간도 길어지므로 파티션 개수가 많지 않은 경우 효과적이다.
롤링 배포는 리밸런스가 여러번 발생한다.
| 토픽 | 컨슈머 애플리케이션 버전 | 컨슈머 |
| 파티션 #0 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #1 |
| 리밸런싱 | ||
| 파티션 #0 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #1 |
| 리밸런싱 | ||
| 파티션 #0 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #1 |
3) 카나리 배포
카나리 배포를 사용하면 많은 데이터 중 일부분을 신규 버전의 애플리케이션에 먼저 배포함으로써 이슈가 없는지 사전에 탐지할 수 있다.
100개의 파티션으로 운영하는 토픽이 있을 경우 1개 파티션에 컨슈머를 따로 배정하여 일부 데이터에 대해 신규 버전의 애플리케이션이 우선적으로 처리하는 방식으로 테스트할 수 있다.
카나리 배포로 사전 테스트가 완료되면 나머지 99개 파티션에 할당된 컨슈머는 롤링 또는 블루/그린 배포를 수행하여 무중단 배포가 가능하다.
카나리 배포는 소수 파티션에 신규 버전 카프카 애플리케이션을 할당함으로써 사전 테스트를 진행할 수 있다.
| 토픽 | 컨슈머 애플리케이션 버전 | 컨슈머 |
| 파티션 #0 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #1 |
| ... | 컨슈머 애플리케이션 V1 | ... |
| 파티션 #99 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #99 |
| 리밸런싱 | ||
| 파티션 #0 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V1 | 컨슈머 스레드 #1 |
| ... | 컨슈머 애플리케이션 V1 | ... |
| 파티션 #99 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #99 |
| 리밸런싱 | ||
| 파티션 #0 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #0 |
| 파티션 #1 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #1 |
| ... | 컨슈머 애플리케이션 V2 | ... |
| 파티션 #99 | 컨슈머 애플리케이션 V2 | 컨슈머 스레드 #99 |
'Coding > Apache Kafka' 카테고리의 다른 글
| [아파치 카프카 어플리케이션 프로그래밍] 22. 스프링 카프카 컨슈머 (0) | 2022.06.10 |
|---|---|
| [아파치 카프카 어플리케이션 프로그래밍] 21. 스프링 카프카 프로듀서 (0) | 2022.06.09 |
| [아파치 카프카 어플리케이션 프로그래밍] 19. 컨슈머 랙(LAG) (0) | 2022.06.02 |
| [아파치 카프카 어플리케이션 프로그래밍] 18. 멀티 스레드 컨슈머 - 컨슈머 멀티 워커 스레드 전략과 카프카 컨슈머 멀티 스레드 전략 (0) | 2022.06.01 |
| [아파치 카프카 어플리케이션 프로그래밍] 17. 멱등성(idempotence) 프로듀서와 트랜잭션(transaction) 프로듀서 (1) | 2022.05.30 |