LY Corporation이 LINE 메신저의 Kafka 클라이언트 간 종단 간 암호화(E2EE)를 설계·구현·배포한 과정을 다룬다. 초당 최대 100만 건의 트래픽을 처리하는 프로덕션 토픽에 무중단으로 적용했으며, CPU 오버헤드 1% 미만이라는 성과를 냈다.
핵심 포인트- DEK(AES-GCM) + KEK(ECIES secp521r1) 이중 키 구조로 성능과 보안을 동시에 확보했다.
- Kafka 표준 인터셉터/시리얼라이저 확장 포인트만 활용해 기존 클라이언트 코드 수정 없이 적용했다.
- 다수 컨슈머 환경에서의 헤더 크기 폭증 문제를 공유 KEK(Shared KEK) 방식으로 해결했다.
- 평문 폴백(Plaintext Fallback) + 점진적 암호화 비율 확대(1%→100%)로 무중단 마이그레이션을 실현했다.
- KMS 폴링 기반 무중단 키 교체 메커니즘으로 운영 중 키를 서비스 중단 없이 교체할 수 있다.
- 프로덕션 규모 벤치마크에서 전 토픽에 걸쳐 CPU 증가량 1% 미만을 확인해 서버 증설이 불필요했다.
상세 정리- 보안 목표: TLS/SASL 기반 기존 보안은 브로커 저장 데이터가 평문이라는 한계가 있어, 심층 방어(defence in depth) 전략으로 클라이언트 간 E2EE 레이어를 추가했다.
- 암호화 단위 선택: 배치 단위(압축 효율 우수, 클라이언트 내부 수정 필요)와 레코드 단위(표준 인터셉터 활용, 코드 무수정)를 비교 후 레코드 단위를 채택했다.
- DEK 구조: 메시지 페이로드는 AES-GCM 대칭 DEK로 암호화. DEK는 ThreadLocal로 인터셉터와 시리얼라이저 간 전달하며, 일정 시간 캐싱해 비대칭 연산 빈도를 최소화한다.
- KEK 구조: DEK 자체는 ECIES(secp521r1) 기반 비대칭 KEK로 암호화해 Kafka 헤더에 포함. KMS가 KEK 생성·배포·교체를 전담하며, 프로듀서는 공개 키, 인가된 컨슈머만 비공개 키를 조회한다.
- 메시지 구조: 헤더에 KEK ID + 암호화된 DEK, 바디에 DEK 암호화 페이로드. 컨슈머는 헤더에서 자신의 KEK ID를 찾아 DEK 복호화 후 페이로드를 복호화한다.
- DEK 캐싱: 프로듀서는 DEK를 캐싱해 비대칭 암호화 연산 빈도를 줄이고, 컨슈머는 암호화 DEK와 평문 DEK 쌍을 캐싱해 동일 DEK 재복호화를 생략한다.
- 공유 KEK 문제: 컨슈머마다 고유 KEK를 부여하면 헤더에 컨슈머 수만큼 메타데이터가 누적돼 초당 100만 건 환경에서 메시지 크기, 네트워크, CPU 사용이 급증한다.
- 공유 KEK 해결: 모든 컨슈머가 하나의 KEK를 공유해 헤더를 단 하나의 메타데이터로 유지. 보안 경계는 KMS 인가 절차와 주기적 키 교체로 보완한다.
- 평문 폴백: 컨슈머 디시리얼라이저가 헤더 존재 여부로 암호화/평문 메시지를 구분 처리. 마이그레이션 순서는 컨슈머 먼저 배포 후 프로듀서 암호화 활성화 순으로 진행한다.
- 점진적 배포: 동적 설정으로 암호화 비율을 1% → 10% → 50% → 100%로 단계적 확대. 이상 징후 시 설정값 변경만으로 즉시 0% 롤백 가능하다.
- 키 교체 절차: 신규 KEK 등록(구 버전 유지) → 약 1분 후 프로듀서가 구·신규 KEK 모두 헤더에 포함 확인 → 컨슈머 신규 키 전환 확인 → 구 KEK 비활성화 → 최종 모니터링 순으로 진행한다.
- 벤치마크 설계: 프로덕션과 동일한 서버, RPS, 메시지 크기 조건에서 평문 vs 암호화를 각 10분씩 비교. 최고 부하(약 5,000 RPS, 수십 KB) 토픽 포함 전 대상 측정.
- 배포 결과: 약 2주 단계적 배포, 암/복호화 관련 장애 알림 0건, 실제 CPU 증가량도 예측치(1% 이하)와 동일. 서버 증설 없이 E2EE 전면 적용 완료.
왜 읽나대규모 Kafka 환경에 E2EE를 무중단으로 적용해야 하는 백엔드·보안 엔지니어에게 DEK-KEK 설계부터 키 교체·점진적 마이그레이션 절차까지 실전 레퍼런스.
LY Corporation·
Cloudflare Blog·