왜 인그레스 운영 사례를 알아야 할까요?
새벽 2시, 서비스 장애 알람이 울려 로그를 확인하는데 트래픽 경로가 꼬여서 원인을 못 찾고 있을 때가 있어요. 마이크로서비스(MSA) 환경에서 서비스가 수십 개로 늘어나면, 각각의 서비스에 로드밸런서를 붙이는 것만으로는 감당할 수 없는 상황이 오기 마련이에요. 매달 청구되는 클라우드 비용은 치솟고, 관리해야 할 엔드포인트는 끝도 없이 늘어나죠.
단순히 로드밸런서(LoadBalancer) 타입을 써서 서비스를 노출하는 방식은 초기에는 편할 수 있어요. 하지만 서비스가 늘어날수록 관리가 불가능해지는 지점이 반드시 찾아와요. 많은 백엔드 개발자가 이 지점에서 혼란을 겪고, 결국 인그레스(Ingress)를 도입하며 비로소 체계적인 라우팅 시스템을 구축하게 돼요.
이 글은 이론적인 설명에 그치지 않아요. 실제 운영 환경에서 인그레스를 어떻게 구성했고, 어떤 문제를 겪으며 개선했는지에 대한 생생한 인그레스 운영 사례를 담았어요. 이 글을 다 읽고 나면, 여러분도 복잡한 트래픽 경로를 깔끔하게 정리하고 비용까지 아끼는 운영 노하우를 얻어갈 수 있어요.
- 인그레스 도입 전의 문제 상황과 필요성
- 실제 서비스에 적용한 단계별 구성 방식
- 도입 후 변화된 운영 지표와 개선 포인트
- 운영 중 겪은 시행착오와 해결 방법
인그레스 도입 전 필수 체크리스트
인그레스를 무작정 설치한다고 모든 문제가 해결되지는 않아요. 우리 서비스의 규모와 네트워크 구조에 인그레스가 적합한지 먼저 판단해야 해요. 준비 없이 도입했다가는 오히려 트래픽 병목 현상의 원인이 될 수도 있거든요.
가장 먼저 결정해야 할 것은 인그레스 컨트롤러를 무엇으로 쓸 것인지예요. 가장 대중적인 것은 엔진엑스(Nginx) 기반의 컨트롤러지만, 서비스 특성에 따라 트래픽 제어 방식이 다른 컨트롤러가 더 유리할 수도 있어요. 또한, 도메인을 관리하는 DNS 설정과 SSL/TLS 인증서를 자동으로 갱신해 줄 수 있는 환경이 갖춰져 있는지도 확인해야 해요.
인그레스는 그 자체로 트래픽을 전달하는 도구가 아니라, 라우팅 규칙을 정의하는 리소스예요. 실제로 트래픽을 처리하려면 반드시 엔진엑스(Nginx)나 HAProxy 같은 컨트롤러가 클러스터 내에 설치되어 있어야 해요.
아래 표를 통해 현재 우리가 사용하는 노출 방식과 인그레스의 차이를 비교해 보세요. 어떤 기준으로 선택해야 할지 감이 잡힐 거예요.
| 비교 항목 | NodePort | LoadBalancer | Ingress |
|---|---|---|---|
| 관리 편의성 | 낮음 (포트 직접 관리) | 보통 (서비스별 설정) | 높음 (중앙 집중 관리) |
| 비용 효율성 | 매우 높음 | 낮음 (서비스당 비용 발생) | 매우 높음 (하나로 통합) |
| L7 기능 지원 | 없음 | 제한적 | 강력함 (경로 기반 라우팅) |
| 추천 상황 | 테스트 환경 | 소규모 단일 서비스 | 다수의 마이크로서비스 |
만약 우리 서비스가 도메인 하나에 여러 개의 경로(Path)를 써야 하거나, SSL 인증서를 한 곳에서 통합 관리하고 싶다면 인그레스가 가장 현명한 선택이에요. 반대로 단순히 외부에서 특정 포트로 접속만 하면 되는 단순한 구조라면 굳이 인그레스를 도입할 필요는 없어요.
실전! 인그레스 도입 및 운영 단계별 가이드
실제 이커머스 플랫폼을 운영했던 인그레스 적용기를 바탕으로, 아무것도 없는 상태에서 어떻게 인그레스를 구축하고 안정화했는지 단계별로 설명해 드릴게요. 이 과정은 단순한 설치를 넘어 실제 서비스 운영 환경의 복잡함을 해결하는 과정이에요.
STEP 1. 기존 서비스 구조의 한계와 문제점 파악하기
도입 전 우리 환경은 20개가 넘는 마이크로서비스가 각각 LoadBalancer 타입으로 노출되어 있었어요. 서비스가 하나 추가될 때마다 클라우드 업체로부터 새로운 로드밸런서 IP가 할당되었고, 이는 곧바로 비용 상승으로 이어졌어요. 무엇보다 관리 포인트가 너무 많았어요. 특정 도메인으로 들어온 요청을 어떤 서비스로 보낼지 결정하는 로직이 애플리케이션 코드에 섞여 있거나, 각 서비스의 설정 파일에 파편화되어 있었죠.
이 상태로 트래픽이 몰리면 어떤 서비스에서 병목이 생기는지 파악하기가 매우 어려웠어요. 모든 트래픽이 각기 다른 통로로 들어오니, 전체적인 트래픽 흐름을 한눈에 볼 수 있는 대시보드를 만드는 것도 불가능에 가까웠어요. 통합된 진입점(Entry Point)이 절실한 시점이었어요.
STEP 2. 인그레스 컨트롤러 선정 및 설치하기
우리는 가장 검증된 엔진엑스(Nginx) 인그레스 컨트롤러를 선택했어요. 커뮤니티가 워낙 커서 문제 발생 시 해결책을 찾기 쉽고, 설정 가능한 옵션(Annotation)이 매우 풍부하기 때문이에요. 설치는 헬름(Helm)을 이용해 진행했어요. 헬름을 사용하면 복잡한 설정값들을 차트 형태로 관리할 수 있어 운영 측면에서 매우 유리해요.
설치 시 가장 신경 써야 했던 부분은 고가용성(HA) 구성이었어요. 인그레스가 모든 트래픽의 관문이 되기 때문에, 컨트롤러 파드(Pod)가 죽으면 서비스 전체가 중단될 수 있어요. 그래서 최소 3개 이상의 파드를 서로 다른 노드에 배치되도록 설정했고, 리소스 제한(Resource Limit)을 넉넉하게 잡아 트래픽 급증 시에도 파드가 중단되지 않도록 조치했어요.
STEP 3. 도메인 및 SSL/TLS 인증서 자동화 설정
운영 환경에서 보안은 타협할 수 없는 부분이에요. 모든 서비스에 HTTPS를 적용하기 위해 cert-manager를 도입했어요. cert-manager는 Let’s Encrypt와 연동되어 인증서 발급부터 갱신까지의 과정을 완전히 자동화해 줘요. 개발자가 일일이 인증서 파일을 업로드하고 만료일을 체크할 필요가 없어진 거죠.
인그레스 설정 파일에 특정 어노테이션(Annotation)만 추가하면, 컨트롤러가 자동으로 인증서를 요청하고 적용하는 구조를 만들었어요. 덕분에 새로운 서비스를 추가할 때마다 보안 설정에 신경 쓰지 않고 비즈니스 로직에만 집중할 수 있었어요.
SSL 인증서를 적용할 때는 인그레스 리소스 내의
tls: 섹션에 인증서가 저장된 Secret 이름을 정확히 명시해야 해요. 이 부분이 틀리면 브라우저에서 보안 경고가 뜨면서 접속이 차단돼요.STEP 4. 라우팅 규칙 및 경로(Path) 최적화하기
이제 본격적으로 트래픽을 분산할 차례예요. 우리는 도메인 기반 라우팅과 경로 기반 라우팅을 혼합해서 사용했어요. 예를 들어, `api.example.com`은 API 서버군으로, `web.example.com`은 프론트엔드 서버군으로 보내는 식이죠. 또한, 하나의 도메인 안에서도 `/users`, `/orders`, `/products`와 같이 경로에 따라 서로 다른 마이크로서비스로 연결되도록 구성했어요.
여기서 중요한 기술적 포인트는 Rewrite Target 설정이에요. 백엔드 서비스는 `/users`라는 경로를 모르고 루트(`/`)부터 시작하는 경우가 많거든요. 인그레스에서 `/users`로 들어온 요청을 실제 서비스에는 `/`로 전달하도록 경로를 재작성해 주는 설정이 꼭 필요해요. 이 설정을 잘못하면 404 에러가 발생하며 서비스가 동작하지 않으니 주의해야 해요.
STEP 5. 도입 후 지표 변화와 성과 확인
인그레스를 도입하고 나서 가장 먼저 체감한 변화는 비용 절감이었어요. 20개가 넘던 로드밸런서를 단 하나로 통합하면서 클라우드 비용을 약 70% 이상 절감할 수 있었어요. 관리 효율성도 엄청나게 좋아졌어요. 이제 모든 트래픽 흐름이 인그레스 컨트롤러의 로그와 메트릭에 집중되기 때문에, 트래픽 패턴을 분석하거나 장애 지점을 찾는 속도가 눈에 띄게 빨라졌어요.
또한, 중앙 집중식 설정을 통해 SSL 인증서 관리나 보안 헤더 적용 같은 공통 작업을 한 곳에서 처리할 수 있게 되었어요. 서비스가 늘어나도 인그레스 설정 파일 하나만 수정하면 되니 운영 부담이 획기적으로 줄어들었죠.
모든 트래픽이 하나의 컨트롤러를 거치기 때문에, 특정 서비스의 잘못된 설정이나 과도한 트래픽이 전체 인그레스 컨트롤러의 성능을 저하시킬 수 있어요. 반드시 서비스별로 리소스 제한과 속도 제한(Rate Limiting)을 고려해야 해요.
자주 하는 실수와 해결법
실무 운영 경험을 바탕으로, 인그레스를 처음 다룰 때 가장 흔히 겪는 실수들을 정리했어요. 이 내용만 숙지해도 삽질 시간을 절반 이상 줄일 수 있어요.
- ❌ 경로 매칭 오류 (Path Mismatch)
왜 발생하는가: 인그레스의 경로 설정 시 `Prefix`와 `Exact`의 차이를 명확히 구분하지 못해 발생해요.
✅ 해결법: 대부분의 서비스는 하위 경로를 포함해야 하므로 `Prefix` 타입을 사용하고, 정확히 일치해야 하는 경우에만 `Exact`를 사용하세요. - ❌ SSL 인증서 적용 실패
왜 발생하는가: cert-manager가 인증서를 발급받기 전 인그레스가 먼저 실행되거나, Secret 이름이 틀린 경우예요.
✅ 해결법: 인증서 발급 상태를 `kubectl get certificate` 명령어로 반드시 확인하고, 인그레스 설정의 Secret 이름과 일치하는지 체크하세요. - ❌ 대용량 파일 업로드 제한
왜 발생하는가: 엔진엑스(Nginx)의 기본 설정값이 클라이언트 요청 본문(Body) 크기를 작게 제한하기 때문이에요.
✅ 해결법: 인그레스 어노테이션에 `nginx.ingress.kubernetes.io/proxy-body-size` 값을 원하는 크기(예: 50m)로 명시하세요. - ❌ 리다이렉트 루프 (Redirect Loop)
왜 발생하는가: SSL 설정이 중복되거나, 로드밸런서와 인그레스 사이의 프로토콜 전달 방식이 꼬였을 때 발생해요.
✅ 해결법: X-Forwarded-Proto 헤더 설정을 확인하고, 인그레스에서 SSL을 강제하는 어노테이션이 올바른지 점검하세요. - ❌ 서비스 타임아웃 발생
왜 발생하는가: 백엔드 처리 시간이 인그레스 컨트롤러의 기본 타임아웃보다 길 때 발생해요.
✅ 해결법: `proxy-read-timeout`과 `proxy-send-timeout` 어노테이션을 통해 타임아웃 시간을 적절히 늘려주세요.
자주 묻는 질문
Q. 인그레스와 로드밸런서의 결정적인 차이점은 무엇인가요?
로드밸런서는 보통 L4 계층에서 작동하며 IP와 포트를 기반으로 트래픽을 전달해요. 반면 인그레스는 L7 계층에서 작동하여 URL 경로, 호스트 이름, 쿠키 등 더 상세한 정보를 보고 트래픽을 똑똑하게 나누어 줄 수 있어요.
Q. 어떤 컨트롤러를 선택하는 것이 가장 좋을까요?
가장 무난한 선택은 엔진엑스(Nginx) 컨트롤러예요. 기능이 가장 많고 자료도 풍부하죠. 하지만 만약 서비스 메쉬(Service Mesh)를 사용 중이거나 아주 고도화된 트래픽 제어가 필요하다면 Istio나 Traefik 같은 대안을 고려해 보세요.
Q. 보안을 강화하려면 인그레스에서 무엇을 해야 하나요?
가장 먼저 모든 통신을 HTTPS로 강제하는 어노테이션을 사용하세요. 또한, 특정 IP 대역만 허용하도록 하는 화이트리스트 설정이나, 요청 횟수를 제한하는 Rate Limiting 설정을 인그레스 단계에서 적용하는 것이 좋습니다.
Q. 인그레스 하나로 여러 도메인을 관리할 수 있나요?
네, 당연히 가능해요! 하나의 인그레스 리소스 안에 여러 개의 `host` 규칙을 정의하면, 각 도메인에 따라 서로 다른 서비스로 트래픽을 보낼 수 있어요.
