인그레스 운영 사례: 왜 지금 변화가 필요할까요
마이크로서비스 아키텍처(MSA)로 전환한 뒤 갑자기 늘어난 클라우드 비용 때문에 밤잠을 설친 적이 있나요? 서비스가 10개, 20개로 늘어날 때마다 매번 새로운 LoadBalancer 타입을 생성하고 관리하는 일은 정말 고역이에요. 각 서비스마다 별도의 공인 IP가 할당되니 비용은 기하급수적으로 늘어나고, DNS 설정도 복잡해져서 실수할 위험이 커져요.
어느 날 운영 중인 서비스에서 갑자기 접속 지연이 발생했을 때, 어떤 로드밸런서에서 문제가 생긴 건지 파악하는 데만 한참이 걸렸던 경험이 있다면 아마 공감하실 거예요. 서비스가 많아질수록 개별적인 엔드포인트를 관리하는 방식은 한계에 부딪힐 수밖에 없어요. 트래픽 관리의 효율성이 떨어지면 결국 운영팀의 피로도로 이어지거든요.
이런 문제를 해결하기 위해 저희 팀은 모든 트래픽을 한 곳으로 모아 효율적으로 분산해 주는 인그레스(Ingress)를 도입하기로 결정했어요. 단순히 기술을 도입하는 것을 넘어, 어떻게 하면 기존의 복잡한 구조를 정리하고 안정적인 서비스 환경을 구축할 수 있을지에 대해 치열하게 고민했어요.
이 글에서는 실제 현장에서 겪었던 인그레스 운영 사례를 바탕으로, 도입 과정에서 어떤 문제를 만났고 이를 어떻게 극복했는지 생생하게 전달해 드릴게요. 이론적인 설명보다는 실무에서 바로 적용할 수 있는 실전 팁 위주로 구성했어요.
인그레스는 쿠버네티스 클러스터 외부에서 내부 서비스로 HTTP/HTTPS 트래픽을 전달하는 규칙 집합이에요. 단순히 연결만 해주는 게 아니라, 경로(Path)나 호스트(Host)에 따라 트래픽을 똑똑하게 나누어 주는 역할을 해요.
이번 글에서 함께 살펴볼 내용은 다음과 같아요.
- 인그레스 도입 전 겪었던 네트워크 구조의 문제점
- 성공적인 인그레스 구축을 위한 컨트롤러 선택 기준
- 실제 서비스에 적용한 단계별 설정 과정과 검증 방법
- 운영 중 마주한 트러블슈팅 경험과 핵심 교훈
인그레스 도입 전 꼭 챙겨야 할 준비 사항
무턱대고 인그레스를 설치한다고 해서 모든 문제가 해결되지는 않아요. 오히려 잘못된 설계는 트래픽 병목 현상을 일으켜 서비스 전체를 마비시킬 수도 있어요. 본격적인 구축에 앞서 현재 우리 클러스터의 상태를 점검하고, 어떤 컨트롤러가 우리 팀의 요구사항에 맞는지 판단하는 과정이 반드시 필요해요.
사전 체크리스트와 인프라 요구사항
가장 먼저 확인해야 할 것은 도메인 관리 체계예요. 인그레스는 도메인 기반의 라우팅을 핵심으로 하기 때문에, 각 서비스별로 사용할 서브도메인이 준비되어 있어야 해요. 또한, SSL/TLS 인증서를 어떻게 관리할 것인지도 미리 정해두어야 해요. 인증서 갱신 과정을 자동화할 준비가 되어 있지 않으면, 나중에 인증서 만료로 인해 서비스가 중단되는 대참사를 겪을 수 있거든요.
클러스터 내부의 네트워크 구성도 다시 살펴봐야 해요. 인그레스 컨트롤러가 각 서비스(Service)와 통신할 수 있는 적절한 권한과 네트워크 경로가 확보되어 있는지 확인하는 작업이 선행되어야 해요. 만약 네트워크 정책(Network Policy)을 엄격하게 사용하고 있다면, 인그레스 컨트롤러가 허용 목록에 포함되어 있는지 꼭 체크하세요.
인그레스 컨트롤러 선택 기준 비교
시중에는 다양한 인그레스 컨트롤러가 존재해요. 각 제품마다 장단점이 뚜렷하기 때문에 우리 서비스의 특성에 맞춰 골라야 해요. 아래 표를 참고해서 결정해 보세요.
| 컨트롤러 유형 | 주요 특징 | 추천 상황 |
|---|---|---|
| Nginx Ingress | 가장 대중적이고 설정이 방대함 | 일반적인 웹 서비스 운영 |
| Traefik | 동적 구성과 마이크로서비스에 최적화 | 자주 변하는 환경의 MSA |
| Istio (Service Mesh) | 고도로 정밀한 트래픽 제어 가능 | 복잡한 보안 및 관찰성이 필요한 경우 |
Istio와 같은 서비스 메시 솔루션은 매우 강력하지만, 학습 곡선이 매우 높아요. 인그레스 기능만을 위해 도입하기에는 운영 리소스가 너무 많이 들 수 있으니 신중하게 결정해야 해요.
저희 팀의 경우, 이미 많은 엔지니어가 익숙하게 사용하고 있는 설정값(Annotation)이 많았던 Nginx Ingress Controller를 선택했어요. 새로운 기술을 배우는 시간보다, 기존의 안정성을 확보하고 빠르게 적용하는 것이 더 중요하다고 판단했기 때문이에요.
인그레스 적용을 위한 실전 단계별 가이드
이제 본격적으로 인그레스를 클러스터에 올리고 실제 트래픽을 흘려보내는 과정을 살펴볼게요. 단순히 명령어를 입력하는 것을 넘어, 각 단계에서 어떤 의도를 가지고 설정을 진행했는지 상세히 설명해 드릴게요.
STEP 1. 기존 서비스 구조의 문제점 파악하기
도입 전 저희의 구조는 매우 비효율적이었어요. 서비스가 15개였는데, 각각 `type: LoadBalancer`를 사용하고 있었죠. 이로 인해 클라우드 업체로부터 15개의 개별 로드밸런서 인스턴스를 할당받았고, 이는 곧바로 비용 폭탄으로 돌아왔어요. 또한, 각 서비스마다 다른 도메인을 연결하느라 DNS 레코드를 하나하나 수정해야 하는 번거로움도 있었어요.
이 문제를 해결하려면 단 하나의 로드밸런서만 외부로 노출하고, 그 뒤에서 인그레스 컨트롤러가 경로(Path)에 따라 요청을 적절한 서비스로 넘겨주는 구조로 바꿔야 했어요. 이 단계에서 저희는 트래픽 흐름을 시각화하며 어떤 경로로 데이터가 들어오고 나가는지 명확히 정의했어요.
STEP 2. Nginx Ingress Controller 설치 및 기본 설정
저희는 설정의 유연성을 위해 Helm을 사용하여 인그레스 컨트롤러를 설치했어요. Helm을 사용하면 복잡한 YAML 파일들을 하나씩 관리할 필요 없이, 차트(Chart)를 통해 일관된 설정으로 배포할 수 있어 매우 편리해요.
설치 과정에서 가장 신경 쓴 부분은 리소스 제한(Resource Limit) 설정이었어요. 인그레스 컨트롤러는 클러스터의 관문이기 때문에, 만약 컨트롤러 자체가 메모리 부족으로 죽어버리면 모든 서비스의 접속이 끊기게 돼요. 그래서 CPU와 메모리의 최소/최대치를 서비스 규모에 맞춰 넉넉하게 할당해 두었어요.
예를 들어, 초당 요청 수(RPS)가 급증할 때를 대비해 CPU의 경우 `request`는 낮게 잡되 `limit`은 높게 설정하여 버스트(Burst) 상황에 대응할 수 있도록 구성했어요.
STEP 3. 경로 기반 라우팅 규칙 설계하기
가장 핵심적인 단계예요. 도메인 하나로 여러 서비스를 운영하려면 `Ingress` 리소스를 어떻게 정의하느냐가 관건이에요. 저희는 서비스의 특성에 따라 두 가지 방식을 혼합해서 사용했어요.
첫 번째는 호스트 기반 라우팅이에요. `api.example.com`은 API 서버로, `web.example.com`은 프론트엔드 서버로 보내는 식이죠. 이는 서비스 간의 경계를 명확히 나누고 보안 정책을 적용하기에 매우 유리해요.
두 번째는 경로 기반 라우팅이에요. 하나의 도메인 아래에서 `/users`, `/orders`, `/products`와 같이 URL 경로에 따라 다른 백엔드 서비스로 트래픽을 넘겨줘요. 이때 주의할 점은 Rewrite Target 설정이에요. 백엔드 애플리케이션이 `/users`라는 경로를 직접 인식하지 못하고 루트(`/`)에서 동작한다면, 인그레스 설정에서 경로를 재작성해 주는 작업이 반드시 필요해요.
경로 기반 라우팅을 설정할 때는 `/` 경로가 가장 우선순위가 높다는 점을 잊지 마세요. 너무 포괄적인 경로를 상단에 두면, 하위 경로로 들어오는 세밀한 요청들이 모두 엉뚱한 곳으로 전달될 수 있어요.
STEP 4. TLS 인증서 자동화 및 보안 강화
서비스를 운영하다 보면 HTTPS 적용은 선택이 아닌 필수예요. 매번 인증서를 수동으로 발급받고 인그레스에 등록하는 것은 불가능에 가까운 일이죠. 그래서 저희는 cert-manager를 도입했어요. Let’s Encrypt와 연동하여 인증서 발급부터 갱신까지 모든 과정을 자동화했죠.
인그레스 리소스에 `tls` 섹션을 추가하고, `cert-manager`가 생성한 시크릿(Secret) 이름을 지정하기만 하면 끝이에요. 이렇게 하면 인증서 만료로 인해 서비스가 중단되는 사고를 원천적으로 차단할 수 있어요. 또한, 보안 강화를 위해 TLS 버전 제한이나 암호화 스위트(Cipher Suite) 설정을 통해 취약한 프로토콜 접속을 막는 설정도 인그레스 어노테이션(Annotation)을 통해 적용했어요.
STEP 5. 모니터링과 지표 분석 체계 구축
인그레스가 제대로 작동하는지 확인하기 위해서는 눈에 보이는 지표가 필요해요. 저희는 Prometheus와 Grafana를 연동하여 인그레스 컨트롤러의 상태를 실시간으로 모니터링했어요. 특히 주목해서 본 지표는 다음과 같아요.
- Request Rate (RPS): 초당 들어오는 요청 수의 변화 추이
- Error Rate (4xx, 5xx): 응답 에러 발생 비율 (특히 5xx 에러 급증 시 즉시 알람)
- Latency (P95, P99): 요청 처리 지연 시간 (사용자가 느끼는 실제 속도)
- Bandwidth: 인그레스를 통과하는 네트워크 트래픽 양
이 지표들을 통해 특정 서비스에서 에러가 발생하는지, 혹은 특정 시간대에 트래픽이 몰려 컨트롤러에 부하가 걸리는지를 즉각적으로 파악할 수 있게 되었어요. 이는 단순히 문제를 발견하는 것을 넘어, 향후 인프라 확장 계획을 세우는 데 아주 귀중한 데이터가 되었어요.
실제 운영 시나리오를 하나 예로 들어볼게요. 블랙 프라이데이와 같은 이벤트 기간에는 평소보다 10배 이상의 트래픽이 몰려요. 이때 저희는 Grafana 대시보드를 통해 5xx 에러가 조금이라도 상승하면 즉시 인그레스 컨트롤러의 복제본(Replica) 수를 늘리는 스케일 아웃(Scale-out) 작업을 수행했어요. 덕분에 단 한 건의 서비스 중단 없이 이벤트를 성공적으로 마칠 수 있었답니다.
자주 하는 실수와 해결법
인그레스를 운영하다 보면 이론과는 다른 예상치 못한 문제들이 계속해서 발생해요. 저희가 직접 겪으며 정리한 몇 가지 대표적인 사례를 공유할게요.
❌ 서비스 포트 불일치
인그레스 설정에는 80번 포트를 적었는데, 실제 백엔드 서비스는 8080번에서 돌고 있는 경우예요. 이 경우 인그레스는 트래픽을 보내지만, 서비스가 응답하지 않아 503 에러가 발생해요.
✅ 해결법: `kubectl get svc` 명령어로 실제 서비스가 리스닝하고 있는 포트를 확인하고, 인그레스의 `backend.service.port.number`와 정확히 일치시키세요.
❌ 잘못된 어노테이션(Annotation) 사용
Nginx 인그레스 전용 설정을 사용해야 하는데, 다른 컨트롤러의 어노테이션을 넣는 경우예요. 설정이 무시되거나 인그레스 리소스 자체가 유효하지 않다는 에러를 뱉어요.
✅ 해결법: 사용하는 컨트롤러의 공식 문서를 항상 곁에 두세요. 설정이 적용되지 않는다면 `kubectl describe ingress [이름]` 명령어로 이벤트 로그를 확인하는 것이 가장 빨라요.
❌ TLS 인증서 경로 오류
인증서를 Secret으로 만들었지만, 인그레스 설정에서 그 Secret 이름을 잘못 적거나 네임스페이스가 다른 경우예요. 접속 시 ‘연결이 비공개로 설정되어 있지 않습니다’라는 경고가 떠요.
✅ 해결법: Secret은 반드시 인그레스 리소스와 동일한 네임스페이스에 존재해야 해요. 이름을 오타 없이 입력했는지 다시 한번 확인하세요.
❌ 너무 큰 페이로드(Payload) 요청
파일 업로드 같은 작업 시, 기본 설정된 body 크기 제한 때문에 413 Request Entity Too Large 에러가 발생해요.
✅ 해결법: `nginx.ingress.kubernetes.io/proxy-body-size` 어노테이션을 사용하여 허용 용량을 명시적으로 늘려주세요.
❌ 헤더 누락 문제
프록시를 거치면서 클라이언트의 실제 IP 주소나 프로토콜(HTTP/HTTPS) 정보가 유실되는 경우예요. 백엔드 앱에서 접속자 IP를 식별하지 못하게 되죠.
✅ 해결법: `use-forwarded-headers` 설정을 활성화하고, 필요한 헤더(X-Forwarded-For 등)를 통과시키도록 설정하세요.
자주 묻는 질문
Q. 인그레스를 사용하면 성능이 저하되지 않나요?
네, 물리적으로 한 단계를 더 거치는 것이니 미세한 지연은 발생할 수 있어요. 하지만 서비스마다 개별 로드밸런서를 두는 것에 비하면 관리 효율과 비용 측면에서 얻는 이득이 압도적으로 커요. 성능이 걱정된다면 인그레스 컨트롤러의 리소스를 충분히 할당하고, 가벼운 컨트롤러를 선택하는 것이 방법이에요.
Q. 서비스가 많아지면 인그레스 하나로 다 감당할 수 있나요?
한 개의 인그레스 컨트롤러가 수백 개의 규칙을 처리할 수는 있지만, 물리적인 한계가 있어요. 트래픽이 매우 크다면 도메인 그룹별로 인그레스 컨트롤러를 분리하여 운영하는 것이 안정성 면에서 유리해요.
Q. Path를 설정할 때 주의할 점이 있다면 무엇인가요?
가장 긴 경로(Longest Prefix Match)가 우선순위를 갖는 경우가 많지만, 설정에 따라 엉뚱한 규칙이 먼저 적용될 수 있어요. 항상 규칙을 적용한 뒤에는 `curl` 명령어로 실제 경로별로 응답이 잘 오는지 테스트하는 습관을 가져야 해요.
Q. SSL 인증서를 수동으로 관리하는 것보다 cert-manager가 나은 이유가 뭔가요?
사람은 반드시 실수를 하기 때문이에요. 인증서 만료일을 엑셀에 적어두고 관리한다고 해도, 담당자의 휴가나 퇴사 등으로 인해 놓치는 경우가 생겨요. 자동화는 이러한 휴먼 에러를 제거해 주는 가장 확실한 방법이에요.
글을 마치며: 효율적인 트래픽 관리를 위한 제언
지금까지 실제 인그레스 운영 사례를 통해 구축 과정부터 트러블슈팅까지 살펴보았어요. 인그레스 도입은 단순히 기술적인 변화를 넘어, 우리 팀의 운영 방식을 더 체계적이고 비용 효율적으로 바꾸는 중요한 전환점이에요.
처음에는 복잡한 설정과 예상치 못한 에러 때문에 막막할 수 있어요. 하지만 하나씩 규칙을 정립하고 자동화해 나가다 보면, 어느 순간 트래픽 관리가 훨씬 수월해졌다는 것을 느끼실 거예요. 기술은 도구일 뿐이며, 중요한 것은 우리 서비스의 안정성을 어떻게 확보할 것인가 하는 고민이라는 점을 잊지 마세요.
- 인그레스 도입은 비용 절감과 관리 효율성을 위해 필수적이에요.
- 컨트롤러 선택 시 팀의 숙련도와 서비스 특성을 고려해야 해요.
- Helm을 활용하면 인그레스 배포와 관리가 훨씬 수월해져요.
- 경로 기반 라우팅 시 Rewrite Target 설정을 주의 깊게 확인하세요.
- SSL 인증서는 cert-manager를 통해 반드시 자동화하세요.
- 모니터링 지표(RPS, Error Rate, Latency)를 통해 상태를 상시 확인하세요.
🚀 다음 단계로 나아가기
- 오늘 할 일: 현재 운영 중인 서비스의 로드밸런서 비용과 사용량을 파악해 보세요.
- 이번 주 할 일: 테스트 환경(Minikube 등)에서 Nginx Ingress를 설치하고 간단한 경로 라우팅을 실습해 보세요.
- 실행 직전 할 일: 인그레스 도입 시 사용할 도메인 체계와 인증서 관리 전략을 팀원들과 논의하세요.
실습 환경에서 직접 적용해 보다가 막히는 부분이나 궁금한 점이 생기면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하며 해결해 나가면 좋겠어요!
관련해서 더 깊이 있는 내용이 궁금하다면 쿠버네티스 인그레스 기본 개념 글이나 클러스터 구축 입문 글을 먼저 읽어보시는 것을 추천해요.
