왜 모든 팀이 인그레스를 고민할까요
클라우드 환경에서 쿠버네티스 클러스터를 운영하다 보면 어느 순간 당혹스러운 상황을 마주하게 돼요. 서비스가 하나둘 늘어날수록 각 서비스마다 별도의 LoadBalancer 타입을 할당하게 되고, 이는 곧이어 폭발적인 클라우드 비용 청구서로 돌아와요. AWS나 GCP 같은 환경에서 로드밸런서 하나당 매달 나가는 고정 비용은 무시할 수 없는 수준이거든요.
게다가 관리해야 할 외부 IP 주소와 SSL 인증서의 개수가 늘어나면 운영팀의 업무량은 기하급수적으로 증가해요. 서비스가 10개라면 10개의 인증서를 각각 관리하고, 10개의 엔드포인트를 각각 모니터링해야 하는 비효율이 발생하죠. 이런 혼란을 겪지 않으려면 트래픽의 입구를 단일화하는 전략이 반드시 필요해요.
실제로 많은 백엔드 개발자와 데브옵스 엔지니어들이 겪는 이 문제는 단순히 비용의 문제를 넘어 운영의 복잡성을 결정짓는 핵심 요소예요. 이번 인그레스 운영 사례 글을 통해 복잡한 네트워크 구조를 어떻게 단순화했는지, 그리고 실무에서 어떤 설정이 실제 서비스 안정성을 높여주었는지 구체적으로 나누어 보려고 해요.
오늘 글에서는 다음과 같은 내용을 심도 있게 다뤄요.
- 로드밸런서 방식에서 인그레스로 전환하게 된 실제 배경
- Nginx Ingress Controller를 활용한 실전 구성 전략
- 도입 과정에서 만난 기술적 난관과 해결 방법
- 운영 효율과 비용 절감 측면에서의 데이터 변화
도입 전 반드시 점검해야 할 핵심 요소
인그레스를 무작정 도입한다고 해서 모든 문제가 마법처럼 해결되지는 않아요. 오히려 관리 포인트가 네트워크 계층으로 이동할 뿐이죠. 도입을 결정하기 전에 우리 팀의 현재 네트워크 구조가 어떤 방식에 가장 적합한지 냉정하게 판단해야 해요. 단순히 유행을 따르기보다는 현재의 트래픽 패턴과 예산을 기준으로 선택 기준을 세워야 합니다.
먼저 우리가 사용 중인 쿠버네티스 환경에서 인그레스 컨트롤러를 설치할 수 있는 준비가 되었는지 확인하세요. 클러스터에 외부 트래픽을 받아줄 수 있는 최소한의 진입점이 필요하며, 도메인을 연결할 DNS 설정 권한도 확보되어 있어야 해요. 준비물은 생각보다 명확해요. 적절한 컨트롤러 소프트웨어, SSL 인증서를 관리할 메커니즘, 그리고 트래픽 흐름을 가시화할 모니터링 도구가 그 예예요.
인그레스는 그 자체로 트래픽을 전달하는 엔진이 아니에요. 반드시 Ingress Controller라는 실제 동작하는 프로세스가 클러스터 안에 떠 있어야 규칙을 해석하고 트래픽을 전달할 수 있습니다.
서비스의 규모와 요구사항에 따라 어떤 방식을 선택할지 아래 표를 통해 비교해 보세요.
| 비교 항목 | NodePort | LoadBalancer | Ingress |
|---|---|---|---|
| 비용 효율성 | 매우 높음 | 매우 낮음 | 매우 높음 |
| 관리 편의성 | 낮음(포트 관리) | 보통 | 높음(중앙 집중) |
| L7 기능 지원 | 지원 안 함 | 제한적 | 매우 강력함 |
| 보안(SSL/TLS) | 수동 설정 | 클라우드 의존 | 중앙 집중 관리 |
위 표를 보면 알 수 있듯이, 서비스 개수가 많아질수록 Ingress가 가장 경제적이고 강력한 대안이 될 수 있어요. 하지만 L7 레이어에서 트래픽을 제어한다는 것은 그만큼 설정 실수 시 전체 서비스에 영향을 줄 수 있다는 뜻이기도 해요. 따라서 도입 전에는 반드시 테스트 환경에서 경로 기반 라우팅과 인증서 적용 과정을 충분히 검증해야 합니다.
실전 인그레스 구축과 운영 단계
본격적인 인그레스 운영 사례를 단계별로 나누어 설명할게요. 저희 팀은 수십 개의 마이크로서비스를 운영하면서 비용 절감과 보안 강화를 최우선 목표로 잡았어요. 이 과정은 단순히 설정을 복사하는 것이 아니라, 우리 서비스의 트래픽 특성에 맞춰 최적화하는 과정이었습니다.
STEP 1. 인그레스 컨트롤러 선정과 환경 구성
가장 먼저 결정해야 할 것은 어떤 컨트롤러를 사용할 것인가 하는 문제예요. 시장에는 Nginx, Traefik, Kong 등 다양한 선택지가 있죠. 저희는 가장 커뮤니티가 활성화되어 있고 레퍼런스가 풍부한 Nginx Ingress Controller를 선택했어요. 안정성이 검증되었다는 점이 결정적이었죠.
설치는 Helm을 사용하여 진행했어요. Helm을 사용하면 복잡한 설정값들을 values.yaml 파일 하나로 관리할 수 있어 편리해요. 설치 시 주의할 점은 클라우드 환경의 로드밸런서와 컨트롤러가 어떻게 연결되는지 확인하는 것이에요. 컨트롤러 자체가 하나의 LoadBalancer 타입 서비스로 생성되어 외부 트래픽을 가장 먼저 받아들이게 됩니다. 이 지점이 인그레스 구조의 핵심 관문이에요.
STEP 2. 경로 기반 라우팅 및 호스트 기반 라우팅 설계
인그레스를 도입한 가장 큰 이유는 하나의 IP로 여러 서비스를 운영하기 위해서예요. 저희는 두 가지 라우팅 전략을 병행해서 사용했어요. 첫 번째는 호스트 기반 라우팅이에요. 예를 들어 api.example.com은 API 서버로, web.example.com은 프론트엔드 서버로 보내는 방식이죠. 이는 서비스 간의 도메인 격리를 완벽하게 해줘요.
두 번째는 경로 기반 라우팅이에요. 하나의 도메인 안에서 example.com/users는 사용자 서비스로, example.com/orders는 주문 서비스로 연결하는 방식이죠. 이때 주의할 점은 경로 끝에 슬래시(/) 처리를 어떻게 할 것인지에 대한 규칙을 엄격히 정해야 한다는 점이에요. 슬래시 하나 차이로 API 호출이 404 에러를 뱉는 일이 빈번하게 발생하거든요.
경로 기반 라우팅을 사용할 때는 정규표현식(Regex)을 활용할 수 있지만, 너무 복잡한 정규식은 인그레스 컨트롤러의 CPU 부하를 높일 수 있으니 가급적 단순한 매칭 방식을 권장해요.
보안은 타협할 수 없는 부분이죠. 수십 개의 도메인에 대해 인증서를 수동으로 발급하고 갱신하는 것은 불가능에 가까워요. 그래서 저희는 Cert-manager를 도입하여 Let’s Encrypt 인증서를 자동 발급받는 파이프라인을 구축했어요.
과정은 이렇습니다. 인그레스 리소스에 TLS 설정을 추가하고, Cert-manager가 DNS-01 또는 HTTP-01 챌린지를 통해 도메인 소유권을 인증해요. 인증이 완료되면 쿠버네티스 Secret으로 인증서가 자동 저장되고, 인그레스 컨트롤러는 이를 가져와 트래픽에 암호화를 적용하죠. 이렇게 구축해두면 인증서 만료로 인해 서비스가 중단되는 사고를 원천적으로 차단할 수 있어요.
STEP 4. 트래픽 제어 및 안정성 강화
실제 운영 환경에서는 갑작스러운 트래픽 폭주에 대비해야 해요. 인그레스 컨트롤러의 Annotation 기능을 활용하면 매우 세밀한 제어가 가능해요. 예를 들어 특정 서비스에 과도한 요청이 몰리는 것을 막기 위해 Rate Limiting(속도 제한)을 걸거나, 서비스가 감당하기 힘든 양의 요청이 들어올 때를 대비해 Connection Limit을 설정할 수 있어요.
또한, 배포 과정에서의 안정성을 위해 카나리(Canary) 배포도 인그레스로 구현했어요. 새로운 버전의 서비스를 전체 트래픽의 5%만 받도록 설정하여 문제가 없는지 확인한 후, 서서히 비중을 늘려가는 방식이죠. 이는 서비스 장애 위험을 최소화하는 데 엄청난 도움을 주었어요.
STEP 5. 모니터링 체계 구축과 지표 분석
마지막 단계는 눈에 보이지 않는 트래픽을 데이터로 시각화하는 작업이에요. 인그레스 컨트롤러의 로그와 메트릭을 추출하여 Prometheus와 Grafana로 대시보드를 구성했어요. 우리가 중점적으로 본 지표는 다음과 같아요.
- Request Per Second (RPS): 초당 요청 수의 변화를 통해 트래픽 패턴을 파악해요.
- Error Rate (4xx/5xx): 특정 경로에서 에러가 급증하는지 실시간으로 감시해요.
- Latency (P95, P99): 사용자 경험에 직접적인 영향을 주는 응답 지연 시간을 분석해요.
- Bandwidth Usage: 네트워크 대역폭 사용량을 통해 인그레스 노드의 병목 현상을 체크해요.
이런 지표들을 통해 우리는 인그레스가 병목 지점이 되는지, 아니면 백엔드 서비스의 문제인지를 명확히 구분할 수 있게 되었어요. 데이터에 기반한 의사결정이 가능해지니 운영팀의 신뢰도도 자연스럽게 높아졌습니다.
자주 하는 실수와 해결법
인그레스를 운영하다 보면 예상치 못한 에러를 마주하게 됩니다. 실제 현장에서 자주 발생하는 사례들을 정리했으니, 비슷한 상황이 발생하면 빠르게 대처해 보세요.
❌ Service Name이나 Port 설정 오류
가장 흔한 실수예요. 인그레스 리소스에 적은 서비스 이름이나 포트 번호가 실제 Service 객체와 일치하지 않으면 503 Service Unavailable 에러가 발생해요. 반드시 kubectl get svc 명령어로 정확한 포트 번호를 확인하세요.
❌ Ingress Class 미지정
클러스터에 여러 개의 컨트롤러가 있거나 특정 컨트롤러를 지정해야 할 때, ingressClassName을 누락하면 규칙이 적용되지 않아요. 설정이 반영되지 않는다면 이 부분을 가장 먼저 체크해야 합니다.
❌ SSL 인증서 Secret 누락
HTTPS 접속 시 인증서 오류가 난다면, TLS 섹션에 지정한 Secret이 실제로 존재하는지 확인하세요. Cert-manager가 인증서를 발급하기 전에는 Secret이 생성되지 않아 오류가 날 수 있습니다.
❌ Path 매칭 방식의 오해/api로 설정했을 때 /api/v1은 매칭되지만, 규칙에 따라 미세한 차이가 생길 수 있어요. 경로 끝에 슬래시 유무에 따른 동작을 미리 테스트 환경에서 꼭 검증하세요.
❌ Annotation 오타
Nginx 전용 기능(예: rewrite-target)을 사용할 때 Annotation 이름에 오타가 있으면 설정이 무시됩니다. 공식 문서를 보고 정확한 키 값을 입력했는지 다시 한번 살펴보세요.
잘못된 인그레스 설정은 클러스터 전체의 트래픽 흐름을 망가뜨릴 수 있습니다. 운영 환경에 적용하기 전에는 반드시 스테이징 환경에서 실제 요청을 보내보며 검증하는 절차를 거쳐야 해요.
자주 묻는 질문
Q. 인그레스와 로드밸런서의 차이가 무엇인가요?
로드밸런서는 주로 L4(전송 계층)에서 트래픽을 분산하는 역할에 집중하는 반면, 인그레스는 L7(애플리케이션 계층)에서 동작해요. 즉, 인그레스는 URL 경로, 호스트 이름, 쿠키 정보 등을 읽고 판단해서 트래픽을 보낼 수 있는 훨씬 똑똑한 입구라고 생각하시면 돼요.
Q. Nginx Ingress 외에 다른 컨트롤러도 써볼 만한가요?
네, 당연하죠. 만약 서비스 메쉬(Service Mesh)를 사용 중이라면 Istio Ingress Gateway가 더 적합할 수 있고, 더 복잡한 API 관리 기능이 필요하다면 Kong이 좋은 선택이 될 수 있어요. 각자의 요구사항에 따라 선택하세요.
Q. 인증서 갱신은 어떻게 자동화하나요?
앞서 말씀드린 것처럼 Cert-manager를 사용하는 것이 표준이에요. Cert-manager가 Let’s Encrypt와 통신하여 인증서를 자동으로 가져오고, 갱신 시점에도 알아서 Secret을 업데이트해 줍니다.
Q. 트래픽이 갑자기 몰릴 때 대응 방법은요?
인그레스 컨트롤러의 리소스를 확장(HPA 적용)하거나, 컨트롤러가 실행 중인 노드의 사양을 높이는 방법이 있어요. 또한, Rate Limiting 설정을 통해 특정 IP나 서비스의 과도한 유입을 차단하는 것도 방법입니다.
Q. 인그레스 규칙이 제대로 적용되었는지 어떻게 확인하나요?kubectl describe ingress [인그레스명] 명령어를 사용하면 현재 적용된 규칙과 대상 서비스, 이벤트 로그를 확인할 수 있어요. 설정 오류가 있다면 이벤트 로그에 에러 메시지가 남습니다.
안정적인 인그레스 운영을 위한 마지막 단계
인그레스 도입은 단순한 설정 변경이 아니라, 인프라 관리 방식의 패러다임을 바꾸는 과정이에요. 비용은 줄어들고 관리의 중앙화는 이루어지지만, 그만큼 네트워크 입구에 대한 책임감도 커지게 됩니다. 오늘 정리한 내용을 바탕으로 여러분의 클러스터도 더 효율적으로 운영해 보세요.
- 비용 절감을 위해 다수의 LoadBalancer 대신 인그레스를 도입하세요.
- Nginx Ingress Controller와 Helm을 활용해 표준화된 환경을 만드세요.
- 호스트 및 경로 기반 라우팅을 통해 트래픽을 체계적으로 분류하세요.
- Cert-manager로 SSL/TLS 인증서 관리를 자동화하세요.
- Prometheus와 Grafana를 통해 트래픽 지표를 반드시 가시화하세요.
- 설정 변경 시에는 반드시 테스트 환경에서 검증 단계를 거치세요.
이제 무엇을 해야 할까요? 바로 오늘 할 일을 정해보세요. 우선 현재 사용 중인 클라우드 로드밸런서 비용을 확인하고, 인그레스 도입 시 예상되는 절감액을 계산해 보는 것이 첫걸음이에요. 그 다음에는 개발 환경에 Nginx Ingress Controller를 설치해 보고 간단한 서비스 두 개를 연결해 보는 실습을 진행해 보세요.
직접 실습 환경에서 적용해 보시다가 설정이 꼬이거나 예상치 못한 에러가 발생한다면, 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하며 해결해 나가는 과정이 가장 큰 성장이 될 거예요.
관련해서 더 깊이 있는 공부를 원하신다면 아래 글들도 참고해 보세요.
쿠버네티스 인그레스 기본 개념 글 | 클러스터 구축 입문 글
