회고: Nginx에서 Kong 3.0으로 마이그레이션, API 가시성 40% 향상
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll translate it into Korean while preserving the original formatting, markdown, and any code blocks or URLs.
Introduction
우리 팀이 Nginx를 Kong 3.0으로 교체한 여정을 깊이 있게 살펴보고, 네이티브 관측 가능성 기능이 API 가시성을 40 % 향상시킨 방법을 소개합니다.
우리 팀은 120개 이상의 내부 및 외부 API를 관리하며, 모두 Nginx 리버스 프록시 군집을 통해 라우팅합니다. 수년간 Nginx는 기본 라우팅, SSL 종료, 그리고 속도 제한에 충분히 잘 작동했습니다. 그러나 API 생태계가 성장함에 따라 다음과 같은 중요한 관측 가능성 제한에 직면했습니다:
- 분산된 로깅 – Nginx 접근 로그는 API‑특정 메타데이터(소비자 ID, 엔드포인트 버전, 오류 코드)를 추출하기 위해 맞춤 파싱이 필요했으며, 이로 인해 문제 해결이 지연되었습니다.
- 네이티브 메트릭 부재 – Nginx 상태 메트릭을 가져오기 위해 서드‑파티 익스포터에 의존했지만, API별 요청량, 지연 시간, 오류 비율에 대한 세부 정보가 부족했습니다.
- 수동 계측 – 새로운 API에 대한 관측 가능성을 추가하려면 Nginx 설정을 수정하고 재배포해야 했으며, 이는 DevOps 팀의 병목 현상이었습니다.
- 추적 간극 – 분산 추적을 위해 헤더를 수동으로 삽입해야 했고, 마이크로서비스 간에 추적 체인이 자주 끊어졌습니다.
2023년 3분기까지 우리 팀의 API 사고 평균 복구 시간(MTTR)은 47분에 이르렀으며, 그 중 **60 %**가 관측 데이터 수집에 소요되었습니다. 우리는 맞춤형 도구 없이도 관측 가능성을 네이티브로 통합할 수 있는 솔루션이 필요했습니다.
API 게이트웨이 평가
우리는 여러 API 게이트웨이를 평가했지만, Kong 3.0이 세 가지 핵심 이유로 돋보였습니다:
- 네이티브 가시성 플러그인 – Kong의 플러그인 생태계에는 로깅(HTTP, TCP, Syslog), 메트릭(Prometheus, StatsD), 트레이싱(OpenTelemetry, Zipkin)을 위한 사전 구축된 도구가 포함되어 있어 커스텀 코드를 전혀 작성할 필요가 없습니다.
- 호환성 – Kong은 OpenResty(즉 Nginx와 유사) 위에 구축되어 있어 기존 Nginx 설정을 마이그레이션할 때 라우팅 규칙과 SSL 설정을 최소한으로만 변경하면 되었습니다.
- 성능 – Kong 3.0의 최적화된 요청 처리 덕분에 요청당 지연 시간이 < 2 ms만 추가되어 우리 SLA 요구사항을 충분히 만족했습니다.
우리의 목표는 3개월 이내에 모든 프로덕션 API의 마이그레이션을 완료하고 가시성을 30 % 개선하는 것이었습니다. 우리는 이를 초과 달성하여 40 % 개선을 이루었습니다.
Migration Approach
1. Assessment
- 모든 Nginx 설정을 감사했습니다.
- 120개 이상의 API 라우트를 매핑했습니다.
- Kong 플러그인으로 변환이 필요한 18개의 맞춤형 Nginx Lua 스크립트를 식별했습니다.
2. Staging Validation
- 스테이징 환경에 Kong 3.0을 배포했습니다.
- 섀도잉을 통해 프로덕션 트래픽을 복제했습니다.
- 라우팅, SSL 및 레이트‑리밋 동작을 검증했습니다.
3. Plugin Configuration
모든 API에 대해 세 가지 핵심 관측 플러그인을 활성화했습니다:
| Plugin | Purpose |
|---|---|
opentelemetry | 트레이스 헤더를 자동으로 삽입하고 스팬을 Jaeger 백엔드로 내보냅니다. |
prometheus | API 별 요청 수, 지연시간(p50, p95, p99) 및 4xx/5xx 오류 비율에 대한 메트릭을 노출합니다. |
http-log | 소비자 ID, API 버전, 업스트림 응답 시간 등을 포함한 구조화된 JSON 로그를 ELK 스택으로 스트리밍합니다. |
4. Gradual Rollout
- 트래픽이 적은 내부 API부터 시작해 10개씩 배치로 API를 마이그레이션했습니다.
- DNS 가중치를 사용해 한 번에 **10 %**씩 트래픽을 전환하면서 오류율과 지연시간을 지속적으로 모니터링했습니다.
5. Decommission
- 마이그레이션 후 2 주 동안 트래픽이 전혀 없음을 확인한 뒤 Nginx 노드를 폐기했습니다.
결과
우리는 관측 가능성 개선을 네 가지 요소에 가중치를 둔 맞춤 점수로 측정했습니다: 메트릭 세분화 (30 %), 로그 구조 (25 %), 트레이스 완전성 (25 %), 데이터 접근 시간 (20 %).
- 마이그레이션 전 점수: 62 / 100
- 마이그레이션 후 점수: 87 / 100 (+40 %)
주요 정량적 결과
- MTTR이 47 분에서 28 분으로 감소 (40 % 감소).
- 트레이스 완전성이 **68 %**에서 **99 %**로 향상 – 더 이상 끊어진 트레이스 체인이 없습니다.
- 로그 파싱 시간이 사고당 12 분에서 거의 0으로 감소 (구조화된 JSON이 자동으로 인덱싱됨).
- 실시간 API별 메트릭이 이제 새로운 API에 대해 수동 설정 없이 제공됩니다.
- Kong의 속도 제한 및 인증 플러그인이 12개의 맞춤형 Nginx Lua 스크립트를 대체하여 구성 규모를 35 % 줄였습니다.
직면한 과제
| 문제 | 해결책 |
|---|---|
플러그인 충돌 – opentelemetry와 prometheus가 충돌하는 헤더를 주입함. | 충돌을 해결한 Kong 3.0.1으로 업데이트함. |
| 트래픽 섀도잉 오버헤드 – 프로덕션 트래픽의 100 %를 섀도잉하면 Kong 노드에 15 % CPU 부하가 추가됨. | 섀도잉 비율을 트래픽의 **10 %**로 낮춰 CPU 영향을 감소시킴. |
교훈 및 팁
- 관측 플러그인을 일찍 시작하세요. 플러그인을 사후 생각으로 다루다 보니 스테이징 검증이 2주 지연되었습니다.
- DNS 가중치 또는 카나리 방식을 사용해 트래픽을 점진적으로 전환하고 주요 지표를 모니터링하세요.
- 트래픽 섀도잉 시 리소스 사용량을 주시하세요; 샘플링을 통해 오버헤드를 완화할 수 있습니다.
결론
Nginx에서 Kong 3.0으로 마이그레이션한 것은 우리 팀에게 순이익이었습니다. 40 % boost in API observability는 사고 해결 시간을 단축하고, 맞춤형 툴링을 없애며, 향후 API 거버넌스 이니셔티브를 위한 기반을 마련했습니다. 기본적인 관측 기능으로 Nginx를 벗어나 성장하는 팀에게 Kong 3.0은 낮은 지연 시간과 호환 가능한 업그레이드 경로를 제공하며, 막대한 관측 이점을 제공합니다.