Ingress NGINX 이후, 뭘로 갈아탈까

3월 24일에 ingress-nginx가 공식적으로 EOL 됐다. 이제는 CVE 패치도 안 나온다. 우리 팀도 절반이 아직 ingress-nginx를 쓰고 있어서 지난 두 달 동안 대체제 검토를 이어왔다. Envoy Gateway, Cilium Gateway, Traefik, kgateway. 이 네 개를 실제로 클러스터에 붙여봤고, 그 중 하나로 결정을 내렸다. 결정 자체보다는 각각 뭐가 다른지, 어디서 삽질했는지를 정리해보려 한다.

전제 조건부터 짚자. 우리는 EKS 위에서 돌아가고, 노드는 대략 90대. 트래픽은 RPS 8k 정도이고 대부분 gRPC와 HTTP/2. 사내 서비스 60여개가 하나의 Ingress 컨트롤러 뒤에 붙어있는 형태다. 만약 여러분 환경이 GKE 매니지드 게이트웨이를 그냥 켜면 되는 상황이라면 이 글의 절반은 필요 없을 수 있다.

왜 그냥 F5 NGINX Ingress Controller로 안 가는가

가장 먼저 검토한 건 이거였다. 기존 nginx.conf 지식이 그대로 살아있고, 어노테이션 이름도 거의 겹친다. 마이그레이션 비용이 가장 낮은 선택지. 근데 몇 가지가 걸렸다.

첫째, 상용 라이선스와 오픈소스 버전이 갈라져 있어서 기능 매트릭스를 매번 확인해야 한다. 우리가 쓰던 어노테이션 몇 개가 상용 전용이었다. 이걸 검토하는 과정에서 이미 팀 회의 두 번을 썼다.

둘째, Ingress API 자체에서 벗어날 수 있는 기회를 놓치게 된다. 지금 시점에 컨트롤러만 바꾸는 건 결국 같은 문제를 몇 년 뒤에 다시 마주하겠다는 얘기다. 어차피 갈아탈 거면 Gateway API로 가는 게 맞다고 판단했다.

셋째, 사이드로 SIG-Network가 3월 20일에 ingress2gateway 1.0을 릴리즈했다. 어노테이션 30개 넘게 변환해준다. 이 툴 덕분에 Gateway API로 넘어가는 비용이 확 내려갔다. 이게 F5로 안 가고 Gateway API 진영으로 넘어간 결정적 이유다.

Envoy Gateway vs Cilium Gateway vs kgateway

이 셋이 실질적인 후보였다. Traefik도 봤지만, 우리 팀에서 이미 Envoy를 서비스 메시로 쓰고 있어서 Envoy 계열로 자연스럽게 좁혀졌다.

Envoy Gateway는 Envoy Proxy 팀이 직접 만드는 Gateway API 구현체다. 컨셉이 명확하다. 필요한 만큼만 노출하고 나머지는 EnvoyPatchPolicy로 직접 Envoy 설정을 넣을 수 있게 한다. 우리처럼 Envoy 튜닝을 이미 하고 있는 팀에겐 학습곡선이 거의 없다. 근데 문제가 하나 있었다. EnvoyPatchPolicy가 alpha 상태라서 프로덕션에서 진짜로 이걸 켜도 되나 계속 애매했다. 결국 우리는 몇 군데에서 이걸 안 쓰고 우회하는 걸로 결론냈고, 그러다 보니 원래 익숙한 nginx의 configuration-snippet 만큼의 유연함은 안 나왔다.

Cilium Gateway는 우리 클러스터 CNI가 이미 Cilium이라 자연스럽게 시야에 들어왔다. 장점은 명확하다. 별도 데이터 플레인이 추가로 안 생긴다. eBPF 기반이라 이론적으로 지연도 낮다. 실제로 벤치를 돌려봤을 때 P99가 약간 더 좋게 나왔다(우리 워크로드 기준 2-3ms 차이, 통계적으로 의미있는 수준까지는 아니었다). 문제는 Gateway API의 신기능 반영 속도가 Envoy 계열보다 약간 느리다는 것. HTTPRoute의 일부 필터가 아직 부분 지원이었다. 그리고 팀 내에 Cilium eBPF 디버깅을 편하게 할 수 있는 사람이 두 명 뿐인데, 이걸 게이트웨이 담당자까지 요구하는 게 부담이었다.

kgateway는 Solo.io가 밀고 있는, Envoy 기반의 상대적으로 신생 프로젝트다. 문서와 마이그레이션 가이드가 가장 잘 갖춰져 있다는 게 첫인상이었다. Pulumi나 kgateway 자체 블로그가 ingress-nginx에서 넘어오는 절차를 매우 구체적으로 설명한다. 다만 이 프로젝트의 CNCF 성숙도가 아직 낮고, 우리 조직 아키텍처 리뷰에서 "3년 뒤에도 유지될까"라는 질문에 확답이 어려웠다.

결국 우리는 뭘 선택했나

Envoy Gateway로 갔다. 이유는 세 가지.

첫째, Envoy 지식이 팀에 이미 있다. 문제가 생겼을 때 Envoy config를 열어서 이해할 수 있는 사람이 여러 명 있다는 게 실전에서 크다. 이건 벤치마크로 안 잡히는 요소다.

둘째, CNCF 프로젝트로 이미 어느 정도 성숙했고, Envoy 자체의 백엔드가 든든하다. 우리가 3년 뒤에 다시 마이그레이션을 논의하는 상황을 만들고 싶지 않았다.

셋째, EnvoyPatchPolicy가 alpha라도 실제로 우리가 쓰려던 use case의 8할은 이미 Gateway API 표준 리소스로 커버되더라. 진짜 어쩔 수 없을 때만 EnvoyPatchPolicy를 쓰기로 하고, 그 목록을 팀 위키에 명시했다.

Cilium Gateway를 안 고른 건 성능이 부족해서가 아니다. 오히려 성능은 미세하게 나았다. 다만 "게이트웨이 문제가 CNI 문제와 붙어버릴 수 있는" 리스크가 마음에 걸렸다. 장애가 나면 어디서 시작해야 할지 판단하기 어려워지는 상황을 만들고 싶지 않았다.

솔직히 6개월 뒤에 이 선택을 후회할 수도 있다. 특히 EnvoyPatchPolicy가 GA 안 되고 계속 alpha에 머무르면 골치가 아파진다. 검토 과정에서 알게 된 건, 지금 시점에 완전무결한 선택은 없다는 것. 각자 자기 팀의 스킬셋과 이미 굴리고 있는 스택에 붙는 걸 골라야 한다.

혹시 Traefik이나 HAProxy Ingress로 이미 넘어가신 분 있으면 후기 좀 남겨주세요. 그쪽 계열은 우리가 진지하게 안 봤는데, 판단이 맞았는지 계속 궁금하다.