포스트

LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법

Tech Blog Review
게시
By August
좋아요 조회 14 분 읽는 시간

원문: 초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기 — LY Corporation Tech Blog, 한창구·정현우·Haruki Okada, 2026-07-10

한 줄 요약

Kafka의 TLS·SASL·ACL은 “이동 중”과 “누가 접근하는가”를 지키지만 브로커 디스크의 페이로드는 평문이다. LINE은 개인정보급 데이터에 한 층을 더해 프로듀서에서 암호화하고 컨슈머에서만 복호화하는 종단 간 암호화를 초당 최대 100만 건 토픽에 무중단으로 적용했다. 설계는 봉투 암호화(DEK-KEK)다. 페이로드는 AES-GCM 대칭키(DEK)로, DEK는 KMS의 ECC 공개키(KEK)로 ECIES 암호화해 헤더에 싣는다. Kafka 클라이언트를 고치지 않고 인터셉터(헤더)와 시리얼라이저 래퍼(바디)만으로 구현했고, 여러 팀의 컨슈머가 KEK 하나를 공유해 메시지 크기를 일정하게 유지한다. 평문 폴백 + 1% → 100% 점진 배포 + 구·신 KEK 공존 키 교체로 2주간 장애 0건, CPU 증가 1% 미만이었다.

배경: 왜 한 층이 더 필요한가

LINE 대화방 메시지에는 이미 Letter Sealing(E2EE)이 있다. 그런데 메시지 데이터는 여러 시스템으로 Kafka를 타고 흘러가고, 그중에는 높은 보안이 필요한 것이 있다. Kafka 기본 보안은 셋이다. 전송 구간 암호화(TLS), 인증(SASL), 인가(ACL). 브로커 서버도 엄격히 통제되지만 그것은 “누가 접근할 수 있는가”이고 저장된 데이터 자체는 평문이다. 접근 통제 위에 데이터 자체를 암호화하는 층을 더하는 심층 방어(defence in depth)가 이 글의 목적이다.

요구사항은 기밀성(허가된 컨슈머만 복호화), 확장성(프로듀서·컨슈머를 유동적으로 추가·삭제), 최소 성능 오버헤드(CPU·메모리·메시지 크기).

핵심 결정 1: 레코드 단위 암호화

배치 단위(여러 레코드를 모아 압축 후 암호화)는 효율이 좋지만 Kafka 클라이언트의 공식 확장점(인터셉터 등)은 모두 레코드 단위이고 배치 조립 이후에는 개입할 수 없어 클라이언트 내부 코드를 고쳐야 한다. 레코드 단위는 압축 효율이 떨어져 비용이 조금 높고 크기가 소폭 늘지만 표준 확장점을 쓸 수 있다. 버전 업그레이드에도 안전하고 기존 프로듀서·컨슈머의 클라이언트를 수정하지 않아도 된다. 레코드 단위를 택했다.

핵심 결정 2: DEK-KEK

키 하나면 노출 시 전부 무너진다. DEK(data encryption key)는 페이로드를 암호화하는 AES 대칭키(AES-GCM), KEK(key encryption key)는 허가된 컨슈머들이 공유하는 ECC 비대칭 키 쌍(secp521r1, ECIES)으로 KMS에 등록한다. 프로듀서는 공개키로 DEK를 암호화하고, 인가된 컨슈머는 개인키로 DEK를 복호화한다. 이점은 셋이다.

  1. 성능: 비대칭 연산은 짧은 DEK에만, 대용량 페이로드는 빠른 대칭키로.
  2. 메시지 크기 일정: 컨슈머가 늘어도 프로듀서는 한 번만 암호화하고 헤더에는 암호화된 DEK 하나만.
  3. 권한 분리: 프로듀서에는 암호화(공개키) 권한만, 컨슈머에만 복호화(개인키) 권한. 공개키가 새도 기존 메시지는 안전하다.

메시지 구조는 키(파티셔닝용, 그대로) + 헤더(0.11.0부터 가능, KEK ID와 암호화된 DEK) + 바디(DEK로 암호화된 페이로드). 외부 저장소(DB·캐시)에 메타데이터를 두면 의존성이 복잡해져 메시지 자체에 넣었다.

구현: 인터셉터 + 시리얼라이저

프로듀서. 인터셉터가 전송 직전에 DEK를 만들고 KEK로 암호화해 헤더에 넣는다. 시리얼라이저는 기존 시리얼라이저를 감싸는 래퍼로, 1차 직렬화된 바이너리를 DEK로 2차 암호화한다. 둘이 같은 스레드에서 실행되는 점을 이용해 DEK를 ThreadLocal로 넘기고 끝나면 정리한다. 메시지마다 DEK를 새로 만들어 KEK로 암호화하는 것은 낭비라 DEK를 일정 시간 캐싱해 그 동안의 메시지는 같은 DEK를 쓴다. 대부분의 메시지는 대칭 암호화 비용만 든다.

컨슈머. 디시리얼라이저 래퍼가 헤더의 KEK ID로 자기 키를 찾아 DEK를 복호화하고, 페이로드를 복호화한 뒤 역직렬화한다. 프로듀서가 여럿이면 DEK도 여럿이므로 암호화된 DEK → 복호화된 DEK 쌍을 캐싱해 같은 것이 오면 건너뛴다.

KMS. 토픽 오너가 키 쌍을 만들어 등록한다. 새 컨슈머는 개인키 접근 권한을 요청하고 토픽 오너가 승인한다.

대규모 적용의 세 과제

메시지 크기: 공유 KEK. 컨슈머마다 고유 KEK를 주면 헤더에 컨슈머 수만큼 메타데이터가 붙어 크기가 비례해 는다. 배치당 레코드 수가 줄고 대역폭·CPU·메모리가 급증하며, 컨슈머가 추가될 때마다 커져 지속 불가능하다. 그래서 처음부터 여러 컨슈머가 KEK 하나를 공유한다. 컨슈머별 키 격리 대신 일정한 크기를 택한 트레이드오프이고, KMS 인가와 주기적 키 교체로 보완한다.

무중단 마이그레이션: 평문 폴백 + 점진 배포. 모든 프로듀서·컨슈머를 동시에 바꿀 수 없으니 암호문과 평문이 공존한다. 디시리얼라이저가 헤더 유무로 판단해, 있으면 복호화하고 없으면 기존대로 역직렬화한다. 순서는 폴백 컨슈머 먼저 배포 → 프로듀서 암호화 활성화 → 평문 비중 0% 확인. 활성화도 한 번에 100%가 아니라 동적 설정으로 1% → 10% → 50% → 100%이며, CPU·지연·에러율을 보다가 이상하면 설정만으로 0%로 롤백한다.

무중단 키 교체. 공유 KEK가 새면 과거와 미래 메시지 모두 위험하므로 주기 교체가 필수인데 중단 없이 해야 한다. 프로듀서 인터셉터가 KMS의 공개키 목록을 주기적으로 폴링하다 변경을 감지하면 현재 DEK를 등록된 모든 공개키로 각각 암호화해 헤더에 함께 싣는다. 전환 기간에는 구 KEK용 DEK와 신 KEK용 DEK가 나란히 있다. 컨슈머도 폴링으로 새 개인키를 받고, 헤더에서 자기 KEK ID와 맞는 항목만 골라 복호화한다. 절차는 신규 KEK 등록 → 약 1분 후 프로듀서가 둘 다 쓰는지 지표 확인 → 약 1분 후 컨슈머가 신규로 복호화하는지 확인 → 그 뒤에만 구 KEK 비활성화 → 프로듀서가 신규만 쓰는지 최종 확인.

숫자

프로덕션과 같은 장비, 전용 토픽, 프로덕션 최대 RPS와 최대 메시지 크기 재현, 평문·암호문 각 10분씩 인스턴스당 CPU 비교, 파티션 수에 맞춰 컨슈머 동시성 비례 조정.

항목결과
인스턴스당 CPU 증가모든 대상에서 1% 미만
최고 RPS(~5,000/초) + 수십 KB 메시지 토픽프로듀서·컨슈머 모두 약 1%
결론서버 증설 불필요
프로덕션 배포약 2주에 걸쳐 100%까지
암/복호화 장애 알림0건
프로덕션 실측 CPU예측과 같이 1% 이하

읽고 남는 질문

  • 제목의 “초당 100만 건”과 벤치마크의 “~5,000건/초 토픽”의 관계가 불분명하다. 100만은 전체 토픽 합산 또는 파티션 합산이고 5,000은 인스턴스당일 것 같은데 명시가 있으면 좋겠다.
  • AES-GCM은 같은 키로 nonce가 반복되면 치명적이다. DEK를 일정 시간 캐싱해 여러 메시지에 재사용한다면 nonce를 어떻게 생성·관리하는지(카운터인지 랜덤인지, 캐시 시간 동안 메시지 수 상한이 있는지)가 보안 관점에서 가장 중요한 세부인데 언급이 없다.
  • 공유 KEK는 “컨슈머 A가 컨슈머 B의 메시지도 읽을 수 있다”는 뜻이다. 같은 토픽이니 어차피 ACL로 같은 데이터를 보는 것이라 문제없다고 볼 수 있지만, 토픽 오너가 특정 컨슈머의 권한만 회수할 때는 키 교체가 필요하다. 그 빈도와 운영 부담이 궁금하다.

한 줄로 가져가기

Kafka에 종단 간 암호화를 넣는 것은 암호학이 아니라 배치·헤더·확장점·키 교체의 운영 설계다. 표준 확장점만 쓰고, 페이로드는 대칭키로 키는 비대칭키로, 헤더에 메타데이터를, 폴백과 1%부터 시작하는 점진 배포를 두면 대규모 토픽에도 CPU 1%로 들어간다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 30편

이전 시리즈 글 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용 다음 시리즈 글 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
  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, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, LINE
Tech Blog Review LINE Apache Kafka Encryption Security KMS Envelope Encryption Zero Downtime
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다