포스트

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

Tech Blog Review
게시 수정 작성자 August
좋아요 조회 16 분 읽는 시간
시리즈 빅테크 기술 블로그 리뷰 32편 중 28편 빅테크 기술 블로그 리뷰
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
  32. 32 Airbnb 「Avoiding double payments in a distributed payments system」 리뷰 — 네트워크와 DB 트랜잭션을 섞지 않는 세 단계, 재시도 가능 여부의 분류, 그리고 복제본을 읽으면 이중 결제가 나는 이유
엔지니어링 요약 LINE은 하루 2,500억 건·210TB, 초당 4GB를 하나의 Kafka 클러스터로 받는다. 50개 서비스가 한 클러스터를 나눠 쓰면 한 클라이언트의 실...

Problem

LINE은 하루 2,500억 건·210TB, 초당 4GB를 하나의 Kafka 클러스터로 받는다. 50개 서비스가 한 클러스터를 나눠 쓰면 한 클라이언트의 실수가 전체를 멈출 수 있다. 원문은 그것을 막는 첫 번째 장치로 '데이터 양이 아니라 요청 수'를 제한한다고 말한다.

Decision

원문의 규모, 중앙집중 클러스터를 택한 이유, 신뢰성의 세 조건, 요청 쿼터(브로커 스레드 시간 제한)와 배칭의 논리를 옮기고, 규모가 다섯 자릿수 작은 monticker 실험과 이후의 ParityPay 실험에서 같은 원리가 어떻게 나타났는지 대조했다.

Result

'비용은 바이트가 아니라 요청 수'라는 원문의 핵심이 작은 규모에서도 그대로 재현됐다. monticker 게이트웨이는 acks를 켜자 종목당 발행률이 배치 왕복 하나에 묶여 90/s가 됐고, 파티션 12는 6보다 느렸으며(배치가 작아짐), 이후 ParityPay Outbox는 한 파티션 키에 적체가 몰리면 배치가 1건이 되어 처리량이 110배 떨어졌다. 원문이 쿼터로 푼 '한 클라이언트가 전체를 끌어내리는' 문제를 나는 monticker의 발행 풀로 먼저, 이후 ParityPay의 벌크헤드로 다시 만났고, 모양이 같았다.

원문: 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. 원문은 단일 클러스터 기준으로 세계 최대 규모라고 적는다.

클러스터를 서비스마다 나누지 않고 하나로 둔 이유는 데이터를 찾기 쉽고 아키텍처가 단순해지며 운영 효율이 높기 때문이다. 대신 다중 테넌트(여러 서비스가 한 클러스터를 나눠 쓰는 구조)의 위험을 진다. 한 서비스의 실수나 폭주가 나머지 서비스에 닿을 수 있다. 그래서 원문은 멀티테넌시 클러스터의 조건을 셋으로 정한다. 첫째, 가혹한 작업 부하에서 클러스터를 보호할 것. 사내 플랫폼이라 악의적 공격은 고려하지 않아도 되지만, 사용자의 설정이나 배포 실수로 예기치 못한 부하가 걸릴 수는 있다. 둘째, 어느 요청이 어느 클라이언트에서 왔는지 정확히 파악할 것. 셋째, 클라이언트 간 작업 부하를 일정 수준 격리할 것.

1편은 첫 번째 조건을 다룬다. 답은 요청 쿼터다. 원문의 논리는 이렇다. Kafka는 대용량 데이터를 잘 다루도록 설계됐다. 자체 캐시 대신 OS 페이지 캐시에 기대고, 클라이언트는 기본으로 배칭(여러 레코드를 하나의 큰 요청으로 묶기)을 지원한다. 배칭 덕에 데이터 양이나 레코드 수가 늘어도 요청 수는 덜 늘고, 요청마다 드는 오버헤드를 피할 수 있다. 그래서 제어할 대상은 데이터 양보다 요청 수다. 이를 위해 Kafka의 요청 쿼터(request quota)로 특정 클라이언트가 쓸 수 있는 브로커 스레드의 시간을 제한하고, 이것을 모든 클라이언트에 기본으로 건다. 한 클라이언트가 예기치 못한 폭주를 해도 클러스터 전체가 멈추거나 느려지지 않게 하는 것이 목표다. 다음 편은 클라이언트 간 작업 부하 격리를 실제 운영 문제를 예로 다룬다고 예고한다.

Kafka 문서는 두 종류의 클라이언트 쿼터를 구분한다. 바이트 속도 기준의 네트워크 대역폭 쿼터(0.9부터)와, 네트워크·I/O 스레드 사용률 기준의 요청 속도 쿼터(0.11부터)다. 요청 속도 쿼터는 쿼터 창 안에서 클라이언트가 각 브로커의 요청 처리 I/O 스레드와 네트워크 스레드를 쓸 수 있는 시간의 비율로 정의된다(Kafka 설계 문서, Quotas). 원문이 말한 “브로커 스레드의 시간”이 이 두 번째 쿼터다. 나는 바이트 쿼터만으로는 작은 요청을 아주 많이 보내는 클라이언트를 막기 어렵다는 것을 원문이 요청 쿼터로 간 이유로 읽는다. 원문이 바이트 쿼터를 직접 비교하지는 않는다.

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

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

첫째는 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편에 그 문장을 “상한이 없으면 격리가 아니다”로 적었다.

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

원문에서 예산은 플랫폼 쪽이 모든 클라이언트에 기본으로 건다. 예기치 못한 부하가 감지되면 원인 클라이언트를 빨리 찾아야 하므로 요청마다 출처를 알아야 한다(두 번째 조건). 나는 플랫폼과 서비스가 다른 팀이라는 것을 이 구조의 전제로 읽는다.

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

원문이 답하지 않는 것

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

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

가져갈 것

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

외부 출처

TechBlog, LINE
Tech Blog Review LINE Kafka Quota Multi-tenancy Batching Isolation
Kafka와 메시징
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

변경이력

3번 수정

  1. docs(posts): separate the sections of every post with a thematic break
  2. docs(posts): describe parity-pay work as later in posts that predate it
  3. docs(techblog): remove claims the line quota original does not make

댓글

아직 댓글이 없습니다