아파치 카프카(Apache Kafka)의 프로듀서(Producer) 설정에 따른 성능 [8]

busybean3·2021년 9월 7일
0

카프카

목록 보기
8/13

이번 포스팅을 통해서 프로듀서의 옵션 중 acks 옵션을 어떻게 설정하는지에 따라서 카프카로 메시지를 전송할 때 메시지 손실 여부메시지 전송 속도처리량 등이 달라지는지 자세히 살펴보겠습니다.

1. 메시지 손실 가능성 🔺 전송 속도 🔺

메시지를 전송할 때 프로듀서는 카프카 서버에서 응답을 기다리지 않고, 메시지를 보낼 준비가 되는 즉시 다음 요청을 보냅니다. 다시 말해, 카프카로부터 응답을 기다리지 않고 프로듀서만 준비되면 즉시 보내기 때문에 매우 빠르게 메시지를 보낼 수 있습니다. 하지만 이런 방법은 프로듀서가 카프카로부터 자신이 보낸 메시지에 대해 응답을 기다리지 않기 때문에 메시지가 손실될 수 있습니다.

1-1. option

메시지 손실 가능성이 있지만 빠른 전송 속도를 보여주는 옵션은 acks=0 입니다.

acks=0

1-2. 작동방식은?

해당 옵션은 카프카가 메시지를 잘 받았는지 못 받았는지 알 수 있는 ack를 기다리지 않습니다. 그래서 해당 메시지가 잘 받았는지 못 받았는지 확인하지 않고 계속해서 메시지를 전달하는 방식으로 중간에 장애가 발생되어 메시지가 손실되어도 알지를 못해 다시 보내거나 할 수 없어서 메시지 손실 가능성은 있지만, 계속해서 전달하기 때문에 전송 속도는 빠릅니다.

그렇다고 해서 메시지의 손실이 브로커가 다운되는 장애가 아닌 이상 발생되지 않기 때문에 손실 가능성은 낮다고 이해하는 편이 좋습니다.

2. 메시지 손실 가능성 🔻전송 속도 🔸

이번에는 메시지 손실 가능성이 적고, 적당한 전송 속도가 필요한 경우의 동작 방식을 살펴보겠습니다.

2-1. option

acks=1 옵션은 프로듀서가 카프카로 메시지를 보낸 후 보낸 메시지에 대해 카프카가 잘 받았는지 확인(acks)을 합니다. 응답 대기 시간 없이 계속 메시지만 보내던 방법과 달리 확인을 기다리는 시간이 추가되어 메시지를 보내는 속도는 약간 떨어지게 됩니다.

acks=1

2-2. 작동방식은?

acks=0과 비교했을 때 전송 시간의 차이가 얼마나 나는지 간단하게 비교하겠습니다. 모든 행동 하나가 1초가 소요된다고 가정하겠습니다. acks=0 일 때 첫 번째 메시지를 보내는 행동 한 번에 메시지는 프로듀서에서 브로커로 전달되었고, 두 번째 메시지도 바로 전송해 메시지를 보내는데 총 2초가 소요되었습니다. 반면 acks=1 일 경우 메시지 하나를 보내면 '보내는 행동 + 응답을 받는 행동' 총 두 가지 행동이 하나로 간주되어 한 개 메시지를 보낼 때마다 2초가 걸립니다. 그러므로 총 2개의 메시지를 보내면 4초가 걸리게 되는 것입니다. 이렇게 메시지 전송 시간은 다소 느리지만, 보낸 메시지에 대한 응답을 받기 때문에 메시지 손실률은 매우 낮습니다.

2-3. 예외적 상황

하지만 매우 예외적으로 acks=1로 설정했지만 메시지가 손실이 날 케이스가 존재합니다. 메시지를 보내고 리더에 장애가 발생하는 순간이 바로 그 케이스입니다. 예를 들면, 리더가 이제 메시지를 받은 후 저장합니다. 그리고 리더는 프로듀서에게 메시지를 잘 받았다고 acks를 보낸후 바로 장애가 발생되는 경우 팔로워들은 리더를 주기적으로 바라봐야 하는데 리더가 없는 상태로 새로운 메시지가 있는지를 모르기 때문에 메시지를 가져올 수 없는 상태가 되어 버립니다. 이런 아주 예외적인 상황을 제외하고는 메시지 손실 가능성이 낮습니다.

3. 메시지 손실 가능성 ✖️ 전송 속도 🔻

앞서 설명드린 acks=1일 경우 예외적인 상황이 발생하는 경우 매우 낮지만 어느정도의 메시지 손실 가능성이 있다고 했습니다. 이번에는 카프카를 사용하는 사용자의 입장에서 절대 손실되지 않는 메시지를 보내는 경우도 있습니다. 그래서 카프카에서는 acks=1 보다 더 강력한 보장을 할 수 있는 acks=all이라는 옵션을 제공합니다. acks=all의 작동 방법은 프로듀서가 메시지를 전송하고 난 후 리더가 메시지를 받았는지 확인하고 추가로 팔로워까지 메시지를 받았는지 확인하는 것입니다. 속도적으로는 물론 가장 느리지만 메시지를 손실을 허용하지 않는다는 장점이 있습니다. 하지만 완벽하게 사용하고자 한다면, 프로듀서의 설정뿐만 아니라 브로커의 설정도 같이 조정해야 합니다. 브로커의 설정에 따라 응답 확인을 기다리는 수가 달리지기 때문입니다.

3-1. 프로듀서의 acks=all + 브로커의 min.insync.replicas=1

메시지 손실을 허용하지 않는 옵션인 acks=all 과 최소 리플리케이션 팩터를 지정하는 옵션인 min.insync.replicas를 1로 설정해줍니다. 이 설정은 브로커의 환경설정 파일인 server.properties 에서 변경할 수 있습니다.

min.insync.replicas=1

작동방식은?

해당 옵션을 통해서 어떻게 메시지의 전달과정이 이루어지는 알아보겠습니다. 일단 토픽은 리플리케이션 팩터 옵션은 3으로 구성되어 있다고 가정하겠습니다.

  1. 프로듀서가 acks=all 옵션으로 peter-topic의 리더에게 메시지를 보냅니다.
  2. 토픽의 리더는 메시지를 받은 후 저장합니다.
  3. 리더는 min.insync.replicas가 1로 설정되어 있고 최소 하나의 리필리케이션 조건을 갖췄기 때문에 프로듀서에게 메시지를 받았다고 acks를 보냅니다.

손실 없는 메시지 전송으 ㄹ위해 프로듀서가 acks=all 옵션을 사용해 메시지를 전송했지만, 동작 방식은 acks=1과 동일하게 동작하게 됩니다. 이렇게 동작하는 이유는 바로 브로커 환경설정에 정의된 min.insync.replicas가 1로 되어 있기 때문입니다. 이처럼 프로듀서만 acks=all로 메시지를 보낸다 해도 손실 없는 메시지를 보장해주는 것이 아니기 때문에 옵션을 잘 이해하고 설정해야 합니다.

3-2. 프로듀서의 acks=all + 브로커의 min.insync.replicas=2

이번에는 최소 리플리케이션 팩터를 지정하는 옵션인 min.insync.replicas를 2로 설정할 경우입니다.

min.insync.replicas=2

작동방식은?

메시지 전달과정은 아래와 같습니다.

  1. 프로듀서가 acks=all 옵션으로 peter-topic의 리더에게 메시지를 보냅니다.
  2. 토픽의 리더는 메시지를 받은 후 저장합니다. 브로커1에 있는 팔로워는 변경된 사항이나 새로 받은 메시지가 없는지를 리더로부터 주기적으로 확인하면서, 새로운 메시지가 전송된 것을 확인하면 자신도 리더로부터 메시지를 가져와 저장합니다.
  3. 리더는 min.insync.replicas가 2로 설정되어 있기 때문에 acks를 보내기 전 최소 2개의 리플리케이션을 유지하는 확인 합니다.
  4. 토픽의 리더는 프로듀서가 전송한 메시지에 대한 acks를 프로듀서에게 보냅니다.

만약 리더가 acks를 보내자마자 아주 예외적인 경우로 리더 선출 작업이 발생해도 그 메시지를 가지고 있는 팔로워가 있기 때문에 메시지 손실은 발생하지 않습니다. 다시 말해 1대 정도의 서버 장애가 발생하더라도 손실 없는 메시지 전송을 유지할 수 있습니다.

아파치 카프카 document에서는 손실 없는 메시지 전송을 위한 조건으로 프로듀서는 acks-all, 브로커의 min.insync.replicas 의 옵션은 2, 토픽의 리플리케이션 팩터는 3으로 권장합니다.

3-3. 프로듀서의 acks=all + 브로커의 min.insync.replicas=3

이번에는 최소 리플리케이션 팩터를 지정하는 옵션인 min.insync.replicas를 3으로 설정할 경우입니다. 앞서 설명드린 아파치 카프카 document에서 권장하는 옵션이 왜 min.insync.replicas 3보다 좋은지 알아보겠습니다.

min.insync.replicas=3

작동방식은?

메시지 전달 과정은 아래와 같습니다.

  1. 프로듀서가 acks=all 옵션으로 peter-topic의 리더에게 메시지를 보냅니다.
  2. 토픽의 리더는 메시지를 받은 후 저장합니다. 브로커1에 있는 팔로워는 변경된 사항이나 새로 받은 메시지가 없는지를 리더로부터 주기적으로 확인하면서, 새로운 메시지가 전송된 것을 확인하면 자신도 리더로부터 메시지를 가져와 저장합니다.
  3. 리더는 min.insync.replicas가 3으로 설정되어 있기 때문에 acks를 보내기 전 최소 3개의 리플리케이션을 유지하는 확인 합니다.
  4. 토픽의 리더는 프로듀서가 전송한 메시지에 대한 acks를 프로듀서에게 보냅니다.

4. min.insync.replicas 2를 추천하는 이유는?

동작방법을 보면 min.insync.replicas 3도 좋은 방법처럼 보이지만 왜 min.insync.replicas 2를 추천하는 것까요?

팔로워 중 하나가 다운되는 경우 min.insync.replicas 3으로 설정해 리플리케이션 팩터가 부족하다는 내용의 메시지가 나타나고, 프로듀서는 메시지를 보낼 수 없다는 로그가 발생됩니다.

왜 그런 것일까요?

그 이유는 리더, 팔로워, 팔로워 이렇게 3곳에서 모두 메시지를 받아야만 리더는 프로듀서에게 메시지를 잘 받았다는 acks을 보낼 수 있기 때문입니다. 다시 말해, 여기서 팔로워 중 한 개가 종료되어 ISR에는 리더와 팔로워 하나만 남아있어 옵션으로 설정한 조건을 충족시킬 수 없는 상황이 발생했기 때문이라는 것입니다. 카프카는 브로커 하나가 다운되더라도 크리티컬 한 장애 상황 없이 서비스를 잘 처리할 수 있도록 구성되어있는데, 해당 옵션들을 사용하면 안 되는 장애가 발생되게 됩니다.

REFERENCE

해당 글의 모든 레퍼런스는 "카프카, 데이터 플랫폼의 최강자" (고승범, 공용준 지음) 을 알립니다.

https://coupa.ng/b5xV58

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

profile
엉덩이 무거운 개발자가 되기 위해서 몸무게를 찌웠다...

0개의 댓글