인그레스 운영 사례: 트래픽의 혼란을 정리하다
마이크로서비스 아키텍처를 도입하고 서비스 개수가 늘어날수록 예상치 못한 비용 폭탄을 맞게 돼요. 처음에는 각 서비스마다 LoadBalancer 타입의 서비스를 생성해서 외부로 노출했어요. 서비스가 10개라면 클라우드 업체로부터 10개의 공인 IP를 할당받아야 했고, 그만큼 비용도 10배로 뛰어올랐어요. 게다가 각 서비스마다 도메인을 연결하고 SSL 인증서를 관리하는 작업은 운영 팀의 손을 너무나도 무겁게 만들었죠.
트래픽이 어디서 어떻게 들어오는지 한눈에 파악하기도 어려웠어요. 특정 서비스에 갑자기 요청이 몰려도 어떤 경로를 통해 문제가 생겼는지 추적하는 데만 한참이 걸렸어요. 이런 혼란을 겪던 중에 찾은 해결책이 바로 인그레스(Ingress)였어요. 인그레스는 단순한 라우팅 도구를 넘어, 클러스터의 입구를 체계적으로 관리할 수 있는 핵심적인 역할을 해줘요.
이번 글에서는 실제 운영 환경에서 인그레스를 도입하며 겪었던 시행착오와 이를 통해 얻은 최적의 설정 값을 공유하려고 해요. 단순히 이론적인 개념을 나열하는 것이 아니라, 실무에서 바로 활용할 수 있는 운영 경험을 담았습니다.
이 글에서 확인하실 내용
- 인그레스 도입 전후의 인프라 비용과 관리 복잡도 변화
- 실무에서 바로 사용하는 Nginx 인그레스 컨트롤러 설정법
- SSL 인증서 자동화와 경로 기반 라우팅 적용 노하우
- 운영 중 반드시 마주하게 되는 트러블슈팅 사례
사전 준비: 인그레스 도입 전 반드시 체크할 사항
인그레스를 도입하기로 마음먹었다면, 무작정 설치부터 하기보다는 현재 우리 클러스터의 환경을 먼저 분석해야 해요. 인그레스는 그 자체로 동작하는 것이 아니라, 실제 트래픽을 처리해 줄 인그레스 컨트롤러(Ingress Controller)가 반드시 필요하기 때문이에요. 컨트롤러가 없다면 인그레스 설정 파일은 그저 읽히지 않는 문서에 불과해요.
가장 먼저 결정해야 할 것은 어떤 컨트롤러를 사용할 것인지예요. 가장 대중적인 것은 Nginx 인그레스 컨트롤러이지만, 최근에는 Envoy 기반의 컨트롤러나 Istio 같은 서비스 메쉬를 활용하기도 해요. 각 선택지마다 장단점이 뚜렷하므로 우리 서비스의 규모와 요구되는 기능에 맞춰 선택해야 합니다.
인그레스는 L7(Application Layer) 계층에서 동작해요. 즉, HTTP 헤더, 쿠키, 경로(Path) 등을 분석해서 트래픽을 분산할 수 있다는 점이 L4 계층의 로드밸런서와 가장 큰 차이점이에요.
서비스 노출 방식 비교
인그레스를 도입하기 전에 기존의 서비스 노출 방식과 비교해 보면 왜 인그레스가 필요한지 명확해져요. 아래 표를 통해 차이점을 확인해 보세요.
| 구분 | NodePort | LoadBalancer | Ingress |
|---|---|---|---|
| 작동 계층 | L4 | L4 | L7 |
| 비용 효율성 | 매우 높음 | 매우 낮음 | 높음 |
| 도메인 관리 | 어려움 | 어려움 | 매우 용이 |
| 주요 기능 | 단순 포트 노출 | 외부 IP 할당 | 경로/호스트 기반 라우팅 |
표에서 알 수 있듯이, 인그레스는 하나의 공인 IP(LoadBalancer 하나)를 공유하면서도 수많은 도메인과 경로를 효율적으로 나누어 가질 수 있게 해줘요. 비용 절감과 관리 편의성이라는 두 마리 토끼를 모두 잡을 수 있는 선택지인 셈이죠.
준비 과정에서 놓치지 말아야 할 체크리스트도 있어요. 첫째, 컨트롤러를 설치할 네임스페이스를 결정하세요. 보통은 별도의 ingress-nginx 네임스페이스를 만들어 격리하는 것이 관리에 유리해요. 둘째, 사용 중인 클라우드 환경이 로드밸런서 서비스를 지원하는지 확인하세요. 셋째, SSL 인증서를 자동 발급해 줄 Cert-manager 같은 도구를 미리 검토하는 것이 좋습니다.
인그레스 적용기: 단계별 구축 및 실무 설정
이제 본격적으로 인그레스를 구축해 볼게요. 실제 저희 팀에서는 Nginx 인그레스 컨트롤러를 기준으로 운영하고 있어요. 가장 안정적이고 레퍼런스가 풍부하기 때문이죠. 구축 과정은 크게 5단계로 나누어 진행했습니다.
STEP 1. 인그레스 컨트롤러 설치하기
가장 먼저 해야 할 일은 컨트롤러 자체를 클러스터에 올려두는 거예요. 저희는 Helm을 사용하여 설치했습니다. 명령어를 직접 입력하는 것보다 Helm을 쓰는 것이 버전 관리나 설정 변경 측면에서 훨씬 안전해요.
설치 시 주의할 점은 컨트롤러가 사용할 리소스를 미리 정의하는 것이에요. CPU와 메모리 제한(Limits)을 설정하지 않으면, 트래픽이 폭증할 때 컨트롤러가 노드의 자원을 모두 점유해 버려 클러스터 전체가 흔들릴 수 있어요. 컨트롤러는 클러스터의 관문이므로 반드시 적절한 자원 격리가 필요합니다.
STEP 2. 인그레스 리소스 정의 및 경로 라우팅
컨트롤러 설치가 끝났다면, 이제 어떤 요청을 어떤 서비스로 보낼지 정의하는 인그레스 리소스를 작성해야 해요. 예를 들어, example.com/api로 들어오는 요청은 백엔드 서비스로, example.com/static은 프론트엔드 서비스로 보내는 설정을 할 수 있어요.
이때 많은 분이 실수하는 부분이 Path Type 설정이에요. Prefix를 사용할지, Exact를 사용할지에 따라 매칭되는 경로가 달라지거든요. 저희는 대부분의 서비스에 Prefix 방식을 사용해서 하위 경로까지 유연하게 매칭되도록 구성했어요. 아래는 간단한 설정 예시의 흐름이에요.
- Host 설정: 서비스의 도메인 주소 지정
- Path 설정: 서비스별 구분 경로 정의
- Backend 설정: 연결할 서비스 이름과 포트 지정
STEP 3. SSL/TLS 인증서 자동화 구성
운영 환경에서 HTTPS 적용은 선택이 아닌 필수예요. 하지만 서비스가 늘어날 때마다 인증서를 수동으로 갱신하는 건 불가능에 가깝죠. 저희는 Cert-manager를 도입하여 Let’s Encrypt 인증서를 자동으로 발급받고 갱신하는 구조를 만들었어요.
인그레스 설정 파일에 tls 섹션을 추가하고, 발급된 Secret 이름을 적어주기만 하면 인그레스 컨트롤러가 알아서 인증서를 불러와 적용해요. 이 과정을 구축해 두면 인증서 만료로 인해 서비스가 중단되는 대형 사고를 원천 차단할 수 있어요.
인그레스 리소스에 인증서를 설정할 때는 반드시 해당 인증서가 저장된 네임스페이스와 인그레스 리소스의 네임스페이스가 일치해야 한다는 점을 잊지 마세요.
STEP 4. 어노테이션을 활용한 고급 설정
인그레스의 진짜 강력함은 Annotations에서 나와요. Nginx 컨트롤러는 수많은 어노테이션을 지원하는데, 이를 통해 아주 세밀한 제어가 가능해요. 저희 실무에서 가장 자주 쓴 설정 세 가지를 소개해 드릴게요.
nginx.ingress.kubernetes.io/proxy-body-size: 파일 업로드 용량을 조절할 때 사용해요. 기본값이 작아서 큰 파일을 올릴 때 413 오류가 발생할 수 있는데, 이때 이 값을 늘려줘야 해요.nginx.ingress.kubernetes.io/rewrite-target: 경로를 재작성할 때 유용해요. 예를 들어 인그레스에서는/api를 받지만, 실제 백엔드 서비스는/부터 시작하는 경로를 기다릴 때 유용하게 쓰이죠.nginx.ingress.kubernetes.io/limit-rps: 특정 서비스에 대한 초당 요청 수(Rate Limiting)를 제한하여 디도스 공격이나 과도한 트래픽으로부터 서비스를 보호해요.
STEP 5. 모니터링 및 관측성 확보
설정이 끝났다고 끝이 아니에요. 트래픽이 정상적으로 흐르고 있는지, 에러율은 어떤지 실시간으로 확인해야 해요. 저희는 Prometheus와 Grafana를 연동하여 인그레스 컨트롤러의 메트릭을 시각화했어요.
이를 통해 특정 시간대에 4xx나 5xx 에러가 급증하는지, 혹은 응답 속도(Latency)가 느려지는 지점을 즉시 파악할 수 있어요. 인그레스 로그를 실시간으로 수집하는 것도 잊지 마세요. 로그를 분석하면 클라이언트가 어떤 잘못된 경로로 접속을 시도하는지, 인증 오류가 발생하는지 명확히 알 수 있거든요.
자주 하는 실수와 해결법
인그레스를 운영하다 보면 예상치 못한 문제에 부딪히기 마련이에요. 저희가 겪었던 실제 사례들을 바탕으로 정리해 보았습니다.
- ❌ 404 Not Found 에러 발생 → 인그레스의 경로(Path) 설정과 실제 서비스의 경로가 일치하지 않거나, Path Type(Prefix vs Exact)을 잘못 지정한 경우예요. ✅ 인그레스 리소스의 경로 설정과 백엔드 서비스가 기대하는 경로를 다시 확인해 보세요.
- ❌ SSL 인증서 적용 후 브라우저 경고 → 인증서 Secret이 잘못 생성되었거나, 인그레스 설정에 TLS 섹션이 빠져 있을 때 발생해요. ✅
kubectl get secret으로 인증서 존재를 확인하고, 인그레스 YAML에tls설정이 있는지 체크하세요. - ❌ 대용량 파일 업로드 시 413 Request Entity Too Large → 인그레스 컨트롤러의 기본 업로드 제한 용량을 초과했기 때문이에요. ✅
proxy-body-size어노테이션을 사용하여 허용 용량을 늘려주세요. - ❌ 클라이언트 IP가 로드밸런서 IP로만 보임 → 인그레스가 클라이언트의 실제 IP를 전달하지 못하고 있는 상태예요. ✅
use-forwarded-headers설정을 활성화하여 X-Forwarded-For 헤더를 올바르게 읽도록 설정해야 해요. - ❌ 설정 변경 후 반영이 안 됨 → 인그레스 컨트롤러가 설정 파일을 다시 로드하는 데 시간이 걸리거나, 설정 문법에 오류가 있을 수 있어요. ✅ 컨트롤러의 로그를 살펴보고 문법 오류가 없는지 확인하세요.
자주 묻는 질문
Q. Nginx 인그레스 말고 다른 컨트롤러를 써도 괜찮을까요?
네, 당연해요. 만약 서비스 간 통신(East-West 트래픽)에 대한 세밀한 제어가 필요하다면 Istio 같은 서비스 메쉬를 고려해 보세요. 하지만 단순한 외부 노출(North-South 트래픽)이 목적이라면 Nginx가 가장 가볍고 관리하기 편합니다.
Q. 하나의 인그레스로 여러 도메인을 관리할 수 있나요?
그럼요, 그게 바로 인그레스의 핵심 기능이에요. 인그레스 리소스의 spec.rules 항목에 여러 개의 host를 정의하면, 하나의 컨트롤러와 하나의 IP로도 무수히 많은 도메인을 운영할 수 있어요.
Q. 인그레스 컨트롤러를 여러 개 띄우면 더 안정적인가요?
네, 고가용성(HA)을 위해 최소 2개 이상의 복제본(Replica)을 유지하는 것을 권장해요. 컨트롤러 하나가 죽더라도 다른 컨트롤러가 트래픽을 대신 처리할 수 있어야 서비스 중단을 막을 수 있습니다.
Q. 인증서 갱신이 자동으로 안 돼요. 어떻게 하죠?
대부분 Cert-manager의 Issuer 설정이나 DNS 인증(DNS-01 challenge) 과정에서 문제가 생긴 경우가 많아요. Cert-manager의 로그를 확인하여 인증서 발급 요청이 성공했는지, 도메인 소유권 확인 단계에서 막히지는 않았는지 점검해 보세요.
인그레스 운영을 위한 최종 체크리스트
인그레스를 성공적으로 도입하고 운영하기 위해 꼭 기억해야 할 핵심 내용들을 정리해 드릴게요. 이 내용만 잘 지켜도 운영 중 발생하는 문제의 80%는 예방할 수 있어요.
- 컨트롤러 설치 시 CPU/메Memory 리소스 제한(Limit)을 반드시 설정하세요.
- 경로 기반 라우팅 시 Prefix와 Exact의 차이를 명확히 이해하고 사용하세요.
- SSL 인증서는 Cert-manager를 통해 자동화하여 관리 리스크를 줄이세요.
- 어노테이션(Annotations)을 적극 활용해 파일 크기, 속도 제한 등을 제어하세요.
- Prometheus와 Grafana를 통해 트래픽과 에러율을 실시간으로 관측하세요.
- 실제 클라이언트 IP 확인을 위해 헤더 전달 설정을 점검하세요.
오늘 바로 무엇을 하면 좋을까요? 지금 운영 중인 클러스터가 있다면, 서비스마다 따로 쓰고 있는 로드밸런서가 있는지 확인해 보세요. 만약 그렇다면 인그레스를 도입하여 비용을 절감할 수 있는 계획을 세워보는 것이 이번 주에 할 수 있는 가장 가치 있는 일이에요.
실습 환경에서 직접 인그레스 설정을 적용해 보시면서, 잘 풀리지 않거나 설정값이 헷갈리는 부분이 있다면 언제든지 댓글로 질문을 남겨 주세요. 함께 고민하고 해결해 드릴게요!
더 깊이 있는 공부를 원하신다면 아래 글들도 함께 읽어보시는 것을 추천드려요.
