컨슈머 랙과 처리량 튜닝

기울기부터 봅니다. 같은 숫자여도 뜻이 다릅니다.

그 다음 순서입니다.

1. 파티션별로 나눠 본다. 전체 평균은 정상인데 한 파티션만 쌓이는 경우가 가장 흔합니다.
2. 처리 시간을 잰다. 메시지 하나에 얼마나 걸리는지 모르면 대수를 못 정합니다.
3. 어디서 걸리는지 본다. 대개 외부 호출이나 DB 쓰기입니다. 컨슈머 CPU 가 한가한데 느리면 기다림이 원인입니다.
4. 컨슈머 수와 파티션 수를 비교한다. 컨슈머가 파티션보다 많으면 남는 쪽은 놉니다.
5. 재시도와 실패를 본다. 실패가 반복되면 같은 메시지를 계속 붙잡고 있습니다.

1번을 건너뛰면 나머지가 전부 헛수고입니다. 쏠림이 원인인데 대수를 늘리면 놀고 있는 컨슈머만 늘어납니다.

흔한 실수: 랙 숫자만 보고 바로 컨슈머를 늘리는 것. 원인이 처리 시간이면 대수를 늘려도 그대로고, 쏠림이면 아예 효과가 없습니다. 무엇이 병목인지 정한 뒤에 손댑니다.

가장 흔한 이유는 파티션 수가 상한이기 때문입니다. 한 파티션은 한 컨슈머만 읽으므로 컨슈머가 파티션보다 많으면 남는 쪽은 아무것도 안 받습니다.

세 번째가 특히 흔합니다. 컨슈머를 늘리면 뒤쪽 DB 로 가는 부하도 같이 늘어서, 그쪽이 포화면 전체 처리량이 그대로이거나 오히려 나빠집니다. 그때는 컨슈머가 아니라 뒤를 고쳐야 합니다.

파티션은 늘릴 수 있지만 줄이기는 대개 안 됩니다. 그리고 늘리는 순간 같은 키가 다른 파티션으로 갈 수 있어 순서 보장이 끊깁니다. 그래서 파티션 수는 지금 필요한 양이 아니라 앞으로 필요할 양으로 잡습니다.

흔한 실수: 컨슈머 수를 파티션보다 크게 잡아 두고 여유가 있다고 보는 것. 그 여유는 실제로는 놀고 있는 프로세스이고, 자원만 쓰면서 지표를 좋게 보이게 만듭니다.

리밸런싱은 그룹 구성원이 바뀌었다고 판단될 때 일어납니다. 반복된다면 컨슈머가 계속 죽었다 살아나는 것으로 보이고 있다는 뜻입니다.

첫 줄과 마지막 줄이 같은 문제의 앞뒤입니다. 한 번에 500건을 가져와 건당 100ms 면 50초인데, 폴링 간격 상한이 그보다 짧으면 매번 쫓겨납니다.

대응은 셋입니다. 한 번에 가져오는 건수를 줄이거나, 폴링 간격 상한을 실제 처리 시간보다 넉넉하게 잡거나, 처리 자체를 빠르게 만드는 것입니다. 가져오는 건수를 줄이는 쪽이 가장 안전합니다. 상한만 늘리면 진짜 죽은 컨슈머를 알아채는 시간도 같이 늘어납니다.

리밸런싱 중에는 그 파티션의 처리가 멈추므로, 반복되면 랙이 계속 쌓입니다. 즉 리밸런싱 반복은 원인이자 결과로 얽힙니다.

흔한 실수: 랙이 쌓이니까 한 번에 더 많이 가져오게 설정을 키우는 것. 처리 시간이 길어져 리밸런싱이 더 자주 나고, 랙은 더 쌓입니다.

설정과 구성만으로 손댈 수 있는 곳이 몇 군데 있습니다.

먼저 무엇이 병목인지 재야 합니다. 네트워크가 병목이 아닌데 압축을 켜면 CPU 만 쓰고 느려집니다. 컨슈머가 기다리기만 한다면 대수 늘리기가 듣고, CPU 가 붙어 있다면 안 듣습니다.

구성으로 가장 크게 얻는 것은 대개 한 번에 가져오는 양입니다. 건당 왕복이 지배적인 구간에서 묶음을 키우면 몇 배가 납니다. 다만 처리 시간이 폴링 상한을 넘지 않는 선까지만 올립니다.

흔한 실수: 커밋 주기를 크게 늘려 처리량을 올리고 끝내는 것. 장애가 나면 그 주기만큼 다시 처리하므로 중복 처리량이 늘어납니다. 받는 쪽이 멱등하지 않으면 그때 사고가 납니다.