LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록

원문: LINE에서 Kafka를 사용하는 방법 - 1편 — LINE Engineering, Kawamura Yuto, 2019-10-28 (LINE DEVELOPER DAY 2018 발표 기록). 현재 LY Corporation 기술 블로그로 리다이렉트된다.

이 글을 고른 이유는 규모 때문이 아니라 규모 차이 때문이다. 원문의 클러스터는 초당 4GB를 받고, 내가 monticker에서 잰 파이프라인은 초당 2,000틱이다. 다섯 자릿수가 다르다. 그런데 원문이 가장 중요한 교훈으로 꼽은 것이 내 실험에서 그대로 나왔다. 그것이 규모와 무관한 성질이라는 뜻이고, 그래서 대조할 가치가 있다.

원문이 말하는 것

LINE은 Kafka를 두 가지로 쓴다. 백그라운드 작업을 넘기는 분산 큐, 그리고 서비스 간 데이터를 전파하는 데이터 허브. 약 50개 서비스가 하나의 중앙 클러스터를 쓴다. 하루 2,500억 건, 210TB, 최고 초당 4GB. 원문은 단일 클러스터 기준으로 세계 최대 규모라고 적는다.

클러스터를 서비스마다 나누지 않고 하나로 둔 이유는 데이터를 찾기 쉽고 아키텍처가 단순해지며 운영 효율이 높기 때문이다. 대신 다중 테넌트의 위험을 진다. 한 서비스의 실수나 폭주가 다른 49개 서비스를 멈출 수 있다. 그래서 신뢰성의 조건을 셋으로 정한다. 악의적이거나 실수로 인한 과부하를 차단할 것, 어느 클라이언트인지 알 수 있을 것, 클라이언트 간 작업 부하를 격리할 것.

1편은 첫 번째 조건을 다룬다. 답은 요청 쿼터다. Kafka에는 바이트 단위 쿼터(초당 몇 MB)가 있지만 원문은 그것으로 부족하다고 본다. 브로커의 비용은 데이터 양이 아니라 요청 수에 비례한다. 작은 메시지를 배치 없이 초당 수만 번 보내는 클라이언트는 바이트 쿼터에 걸리지 않으면서 브로커의 네트워크·요청 처리 스레드를 독점한다. 그래서 클라이언트가 쓸 수 있는 브로커 스레드의 시간을 제한하고, 클라이언트 쪽에서는 배칭으로 요청당 오버헤드를 줄이게 한다. 한 클라이언트가 예기치 못한 폭주를 해도 클러스터 전체가 멈추지 않게 하는 것이 목표다. 두 번째·세 번째 조건은 2편으로 넘긴다.

같은 곳: 비용은 바이트가 아니라 요청 수다

이 문장을 내 실험에서 세 번 만났다.

monticker 게이트웨이의 90/s 상한. 24편에서 kafka-go Writer의 acks=0을 RequireAll로 고치자 종목 고루틴의 동기 Publish가 배치 왕복(BatchTimeout 10ms + RTT)마다 한 건이 됐다. 핫 종목에 2ms 간격(500/s)을 요청해도 실제 발행률은 약 90/s에 묶였다. 바이트는 문제가 아니었다. 틱 하나는 수백 바이트다. 요청 하나가 왕복 하나이고, 왕복이 비용이었다.

파티션 12가 6보다 느린 이유. 같은 글에서 202종목·2,015 tick/s를 파티션 {1, 3, 6, 12} × 스레드 {1, 3, 6}으로 돌렸는데 P6·C6이 꼬리 지연 최소였고 P12·C6은 더 나쁘거나 같았다. 파티션을 늘리면 파티션당 배치가 작아지고, 스레드당 파티션 2개를 번갈아 폴링한다. 같은 바이트를 더 많은 요청으로 나눈 것이다.

ParityPay Outbox의 110배. 5편에서 순서 보장을 위해 파티션 키별 선두 이벤트만 선점하게 바꾸자, 적체가 1,000개 Aggregate에 흩어져 있으면 비용이 1.06배였지만 한 지갑에 몰리면 배치가 1건이 되어 2,947건/초가 26.6건/초로 떨어졌다. 배치 왕복 약 12ms가 상한이었다. 처리량이 바이트가 아니라 왕복 수에 묶인 것이다.

세 경우 모두 원문의 논리와 같다. 브로커든 DB든 외부 기관이든, 요청 하나에 고정 비용이 있으면 처리량은 배치 크기가 정한다. 원문은 그것을 50개 서비스가 나눠 쓰는 클러스터의 관점에서 “그러니 요청 수를 제한해야 한다”로 썼고, 나는 한 서비스의 관점에서 “그러니 배치를 채워야 한다”로 만났다. 같은 사실의 두 면이다.

같은 곳: 한 클라이언트가 전체를 끌어내리는 경로

원문의 첫 번째 조건(과부하 차단)은 다중 테넌트 문제다. 공유 자원을 쓰는 클라이언트 하나가 나머지를 굶긴다. 원문의 공유 자원은 브로커 스레드이고, 해법은 클라이언트별 스레드 시간 예산이다.

같은 모양을 두 곳에서 봤다. ParityPay 9편에서 타임아웃 없는 외부 호출이 Tomcat 스레드 200개를 24초 만에 전부 점유해 결제와 무관한 잔액 조회까지 멈췄다. 공유 자원은 Tomcat 스레드였고, 해법은 외부 호출용 벌크헤드(동시 50)였다. monticker 23편에서 읽지 않는 WebSocket 연결 25개가 발행 스레드 풀 10개를 전부 붙잡아 정상 클라이언트 1,000개를 p99 19초 멈췄다. 공유 자원은 발행 풀이었고, 해법은 풀을 느린 소비자 수보다 크게 잡는 것이었다.

세 경우의 구조가 같다. 공유 자원, 그것을 독점할 수 있는 클라이언트, 클라이언트별 예산. 원문은 이 예산을 Kafka 브로커 안에 넣었고(요청 쿼터), 나는 애플리케이션 안에 넣었다(벌크헤드, 풀 크기). 넣는 자리가 다를 뿐 “예산 없는 공유 자원은 격리가 아니다”는 같다. 9편에 그 문장을 “상한이 없으면 격리가 아니다”로 적었다.

다른 곳: 누가 예산을 정하는가

원문에서 예산은 플랫폼 팀이 정하고 클라이언트(50개 서비스)에 강제한다. 클라이언트는 자기가 쿼터에 걸렸는지 알 수 있어야 하고(두 번째 조건, 정체성), 걸리면 배칭으로 요청을 줄여야 한다. 플랫폼과 서비스가 다른 팀이라는 것이 이 구조의 전제다.

내 실험에서는 플랫폼과 서비스가 같은 사람이다. 그래서 예산을 브로커에 강제하는 대신 클라이언트 코드를 고쳤다. 게이트웨이의 acks, 발행기의 배치, 소비자의 풀. 이 방식은 한 팀일 때는 빠르지만 50개 팀이면 통하지 않는다. 각 팀이 배칭을 잘 하리라고 기대할 수 없고, 한 팀의 실수가 나머지에 닿는 것을 막으려면 플랫폼 쪽에 강제 장치가 있어야 한다. 원문이 “클라이언트가 알아서 배칭하라”가 아니라 “브로커가 스레드 시간을 제한한다”로 간 이유가 그것이다. 격리 장치는 신뢰 경계에 둔다. 같은 팀 안이면 코드 규약으로 충분하고, 팀을 넘으면 강제가 필요하다.

원문이 답하지 않는 것

1편은 요청 수 제어까지다. 두 번째 조건(어느 클라이언트인가)과 세 번째 조건(클라이언트 간 격리)은 2편으로 넘겼다. 그리고 원문은 쿼터의 효과를 수치로 보이지 않는다. 2018년 발표를 2019년에 기록한 글이라 규모 수치(2,500억, 4GB/s)는 있지만 “쿼터를 걸기 전과 후에 어떤 클라이언트가 얼마나 제한됐고 나머지의 지연이 어떻게 달라졌는가”는 없다.

그 빈칸을 내 실험이 작은 규모에서 채운 셈이다. 벌크헤드 50을 걸자 결제 601건이 거절되고 무관한 API가 p95 30초에서 10ms로 돌아왔다. 발행 풀을 50으로 늘리자 정상 클라이언트가 19초에서 0.2초로 돌아왔다. 격리의 대가(거절된 요청)와 효과(살아남은 나머지)를 같은 표에 놓는 것이 격리 장치를 평가하는 방법이고, 원문의 쿼터도 같은 표로 평가돼야 한다.

가져갈 것

• 브로커의 비용은 바이트가 아니라 요청 수다. 처리량은 배치 크기가 정하고, 파티션을 늘리는 것이 배치를 쪼개는 것이면 느려진다.
• 공유 자원에는 클라이언트별 예산이 있어야 한다. 예산 없는 공유 자원은 격리가 아니다.
• 예산을 어디에 두는가는 신뢰 경계가 정한다. 같은 팀이면 코드 규약, 팀을 넘으면 플랫폼의 강제.
• 격리 장치는 거절한 것과 살린 것을 같은 표에 놓고 평가한다.