Apache APISIX Kafka TLS 연결 지원 추가 본문
배경
회사에서 레거시 Api 서비스의 유료화 프로젝트를 진행하고 있다.
기존에는 부족했던 사용량 제한과 집계, 서버 가용성, 응답 속도 등 개선해야 할 것이 많았다.
나는 그중 전면의 게이트웨이를 구성하고, 인증 흐름, 요청/응답 로깅, 사용량 제한을 처리하는 역할을 맡았다.
게이트웨이로는 다양한 플러그인과 활발한 커뮤니티, NginX 기반의 빠른 성능을 갖고 있는 ApiSix를 선정했다.
사용 내역 조회, 사용량 제한을 위한 구조가 가장 재밌었다.
액세스 로그를 Kafka로 전달하고, 이를 OLAP가 수신, 집계 처리하는 구성이었는데,
사용자별 사용량, API 별 요청량, 사용 패턴이나 응답 속도 등, 수억건의 데이터에 대한 집계가 수 초 안에 처리되는 것에 놀랐다.
그리고 그렇게 집계한 데이터는 사용자 페이지에 전달되거나, 월간 사용량 제한을 위한 사용 횟수 보정의 기반이 된다.
이를 위해 액세스 로그를 카프카에 전달해야 했다.
관리 포인트 최소화를 위해, 가급적 커스텀 없이 플러그인의 기본 설정을 활용하려 노력했고,
ApiSix는 이미 플러그인으로 이 기능을 지원하여 간단한 설정만으로 액세스 로그를 카프카로 전달할 수 있었다.
이슈
베어메탈로 구성된 개발 환경 PoC와 달리, AWS로 구성된 Stage 환경에선 정상 동작하지 않았다.
사용하고자 했던 ApiSix의 kafka-logger 플러그인은 TLS를 지원하지 않았고,
TLS를 강제하는 MSK의 환경에선 카프카 연결이 실패했던 것이 원인이었다.
팀의 문제를 빠르게 푸는 것이 먼저였다.
액세스 로그를 파일로 남겼고, Fluentbit 를 사이드카로 액세스 로그를 카프카에 전달했다.
빠르게 요구 사항을 만족할 수 있었지만, 관리되어야 하는 코드가 생겼고, 팀에서 당초 원했던 관리 영역 최소화와 멀어졌다.
그렇게 작업은 우선 마치고, 해당 플러그인의 구성을 개인적으로 파보기 시작했다.
플러그인은 Kafka producer로 "lua-resty-kafka"라는 오픈소스 라이브러리를 사용하고 있었다.
해당 라이브러리는 TLS를 지원하지만, ApiSix에서 이를 사용하는 과정에서 TLS 옵션을 전달하지 않고 있음을 확인했다.
신경 쓴 것
크게 3가지를 신경썼던 것 같다.
1. 메인 테이너의 시간을 뺏지 않을 것
- 메인 테이너가 내가 발견한 문제와 풀이 방법을 확인하기 위한 시간을 최소화하기 위해 노력했다.
- 그들에게 익숙한 문서화와 주변 코드 스타일을 익혔고, 질문은 가급적 이미 작성된 다른 코드의 패턴을 근거로 했다.
- 작업 범위 외 코드 변경은 작업 전 내 판단과 방향이 맞는지 질의 후 진행하였다.
2. 하위호환이 가능할 것
- 내 작업의 영향 범위를 명확히 했다.
- 문제 플러그인 외 다른 플러그인도 동일한 Kafka producer를 사용, 영향 범위에 있었고, 같은 문제를 갖고 있었다.
- 작업의 결과로 이슈 해결만 아니라, 기존 설정, 영향 범위의 다른 코드가 유효한지 역시 검증했다.
3. 작업 결과를 테스트로 증명할 것
- PR의 소개에서는 작업 결과를 짧고 깔끔하게 정리하는 데 집중하고, 실제 동작은 테스트를 통해 증명되도록 했다.
- 성공 / 실패해야 하는 케이스를 나눠 유닛, 통합 테스트를 작성하고, 로컬에 CI 환경을 재현하여 실제로 동작하는지 검증했다.
- 테스트가 불가능한 케이스에, 왜 불가능한지 검토 과정과 대안을 PR 코멘트에 남겨 리뷰어가 판단할 수 있게 했다.
작업
- 기술 스택
- APISIX(OpenResty/Lua), lua-resty-kafka, Perl Test::Nginx, GitHub Actions CI
- 목표
- kafka-logger, error-log-logger 플러그인에 TLS 연결 옵션을 추가하여 MSK 같은 TLS 브로커 연결을 지원
- 재현
- 플러그인 코드를 따라가 하위 라이브러리(lua-resty-kafka)가 TLS를 지원함을 확인
- 플러그인이 해당 옵션을 사용자에게 노출하지 않고 하위 라이브러리에 전달하지 않음을 확인
- 같은 라이브러리를 사용하는 다른 플러그인 검토, 동일 버그 확인
- 기능 추가
- 두 플러그인에 tls object 스키마 추가, broker_config에 ssl/ssl_verify 옵션 전달
- 기존 관례에 따라 인증서 검증이 꺼져있을 때 보안 경고를 남기는 훅 추가
- 사용 문서에 TLS 속성 테이블과 사용 예시 추가
- 테스트 추가
- 단위: 스키마 검증(tls 유효, 하위호환, 타입 오류 거부), 보안 경고 검증
- 통합: 공용 CI 환경에 SSL Kafka 리스너 추가, TLS 연결 성공과 인증서 검증 거부를 대비시켜 옵션 동작 증명
- 검증: 로컬에 CI 환경을 재현, 영향 범위 전체 통과 확인
정리
- 프로젝트: Apache APISIX / OpenResty, Lua 기반 API 게이트웨이
- PR: https://github.com/apache/apisix/pull/13607
- 배경:
- 사내 API 서비스 유료화, 이를 위한 ApiSix 구성과 액세스 로그 카프카 전달 기능 개발
- kafka-logger 플러그인이 TLS를 지원하지 않아 MSK 같은 TLS 강제 브로커에 연결 불가
- 작업:
- 하위 라이브러리(lua-resty-kafka)는 TLS 지원, 플러그인이 옵션 전달을 누락한 것이 원인
- kafka-logger, error-log-logger 두 플러그인에 tls 스키마 추가, broker_config에 ssl/ssl_verify 전달
- 공용 CI 환경에 SSL Kafka 리스너 추가, 성공/실패 대비 통합 테스트 작성
- 보안 경고, 하위호환 검증, 문서 업데이트 포함

'KimJinHwan > Project' 카테고리의 다른 글
| 데이터 레이크 구축 : 초당 6천 개의 이벤트를 담는 똑똑한 호수 (0) | 2026.03.29 |
|---|---|
| 인증 서버 리팩토링 : OAuth 인증 시나리오와 PKCE (0) | 2026.03.21 |
| 이벤트 파이프라인 성능 개선 : 처리량 향상과 리소스 과부하 대비 (0) | 2026.03.11 |
| 웹 소켓 서버 구조 개선 : Api Gateway 를 사용한 상태 리스 전환 (0) | 2025.12.21 |
| WebRTC 시그널링 서버 개발 : P2P 통신 원리와 데이터 중개 (0) | 2025.11.28 |
