인그레스 운영 사례: 왜 서비스가 커질수록 네트워크가 복잡해질까요
마이크로서비스 아키텍처(MSA)를 도입하고 서비스 개수가 하나둘 늘어나다 보면 어느 순간 당혹스러운 순간이 찾아와요. 각 서비스마다 외부 접속을 위해 별도의 LoadBalancer 타입을 사용하다 보니, 클라우드 비용 청구서에 찍힌 숫자가 예상치를 훌쩍 뛰어넘는 경험을 하게 되거든요. 게다가 서비스가 10개, 20개로 늘어날수록 관리해야 할 DNS 레코드와 SSL 인증서 개수도 기하급수적으로 늘어나면서 운영팀의 업무량은 감당하기 어려운 수준에 도달해요.
실제로 많은 백엔드 개발자와 데브옵스 엔지니어들이 겪는 이 문제는 단순히 비용의 문제를 넘어 운영의 안정성과 직결돼요. 각 서비스가 개별적으로 외부 노출 경로를 가지면 보안 정책을 일관되게 적용하기도 어렵고, 트래픽 제어나 경로 기반 라우팅을 구현하기가 매우 까다로워지기 때문이에요. 네트워크 구조가 파편화되면 장애가 발생했을 때 원인을 파악하는 데만도 엄청난 시간이 소요돼요.
이런 혼란을 해결하기 위해 등장한 것이 바로 쿠버네티스 인그레스(Ingress)예요. 인그레스는 클러스터 외부에서 내부 서비스로 들어오는 HTTP/HTTPS 트래픽을 하나의 진입점으로 모으고, 설정된 규칙에 따라 적절한 서비스로 전달해 주는 스마트한 길잡이 역할을 수행해요. 이 글에서는 실제 운영 환경에서 인그레스를 어떻게 도입했고, 어떤 시행착오를 거쳐 최적의 설정을 찾아냈는지에 대한 생생한 인그레스 적용기를 공유해 드리려고 해요.
오늘 내용을 통해 여러분은 다음과 같은 실무 지식을 얻어 가실 수 있어요.
- 기존 LoadBalancer 방식의 한계와 인그레스 도입의 필요성
- 실무에서 바로 활용 가능한 인그레스 컨트롤러 선택 기준
- 경로 기반 및 호스트 기반 라우팅을 구현하는 구체적인 설정 방법
- SSL/TLS 인증서를 자동화하여 관리하는 노하우
- 운영 과정에서 마주한 트러블슈팅 사례와 해결책
사전 준비: 인그레스 도입 전 반드시 체크해야 할 요소들
인그레스를 무턱대고 설치한다고 해서 모든 문제가 마법처럼 해결되지는 않아요. 오히려 준비 없이 도입했다가는 기존에 잘 돌아가던 서비스의 접속이 끊기거나, 설정 오류로 인해 보안 취약점이 노출되는 상황을 맞이할 수 있어요. 따라서 본격적인 구축에 앞서 우리 클러스터의 환경과 요구사항을 명확히 정의하는 과정이 반드시 필요해요.
핵심 용어와 구성 요소 이해하기
먼저 인그레스를 구성하는 두 가지 핵심 요소를 구분해야 해요. 많은 분이 이 둘을 혼동하곤 하는데, 이 차이를 아는 것이 운영의 시작이에요. 인그레스 리소스(Ingress Resource)는 ‘어디로 트래픽을 보낼 것인가’를 정의한 규칙서이고, 인그레스 컨트롤러(Ingress Controller)는 그 규칙서를 읽고 실제로 트래픽을 배분하는 실행 엔진이에요. 규칙만 적어둔다고 트래픽이 움직이지 않으며, 규칙을 실행해 줄 컨트롤러가 반드시 클러스터 내에 떠 있어야 해요.
가장 대중적으로 사용되는 인그레스 컨트롤러는 NGINX 기반이에요. 하지만 최근에는 서비스 메시(Service Mesh) 환경이나 고성능 요구사항에 따라 Traefik, Kong, 혹은 클라우드 네이티브한 Gateway API를 고려하기도 해요.
노출 방식 비교와 선택 기준
인그레스를 도입하기 전에 현재 사용 중인 외부 노출 방식과 비교해 보는 과정이 필요해요. 아래 표를 통해 각각의 방식이 어떤 상황에 적합한지 확인해 보세요.
| 특징 | 장점 | 단점 | |
|---|---|---|---|
| NodePort | 노드의 특정 포트를 개방 | 설정이 매우 간단함 | 포트 번호가 복잡하고 보안에 취약함 |
| LoadBalancer | 클라우드 LB를 서비스당 할당 | 안정적이고 관리가 편함 | 서비스 개수만큼 비용 발생 |
| Ingress | L7 레이어 기반 통합 관리 | 비용 절감 및 경로 기반 라우팅 가능 | 컨트롤러 설정 및 운영 난이도 있음 |
도입 전 체크리스트
성공적인 인그레스 사례 구축을 위해 다음 질문들에 스스로 답해 보세요. 이 질문들에 대한 답이 준비되어야 실제 설정 단계에서 헤매지 않아요.
- 우리가 사용하는 서비스들이 주로 HTTP/HTTPS 프로토콜을 사용하는가? (gRPC나 TCP/UDP가 주력이라면 추가 설정이 필요해요.)
- 사용할 인그레스 컨트롤러의 기능(예: Canary 배포 지원, Rate Limiting 등)이 우리 서비스 요구사항을 충족하는가?
- 인증서 관리를 자동화할 준비가 되었는가? (Cert-manager 같은 도구 도입 검토)
- 트래픽 급증 시 컨트롤러 자체의 스케일 아웃 전략이 수립되었는가?
핵심 본문: 인그레스 구축 및 실무 적용 단계별 가이드
이제 본격적으로 인그레스를 통해 네트워크 구조를 개선하는 과정을 살펴볼게요. 저희 팀은 기존에 약 15개의 마이크로서비스를 각각 별도의 LoadBalancer로 운영하고 있었어요. 이로 인해 매달 클라우드 비용이 상당했고, 신규 서비스가 추가될 때마다 DNS 설정을 수동으로 변경해야 하는 번거로움이 있었죠. 이 과정을 5단계의 실전 프로세스로 정리해 보았어요.
STEP 1. 기존 네트워크 문제 진단 및 목표 설정
가장 먼저 했던 일은 현재의 비용과 관리 리소스를 데이터로 확인하는 것이었어요. 각 서비스마다 할당된 외부 IP와 LoadBalancer 비용을 합산해 보니, 서비스당 평균 $20 정도의 비용이 발생하고 있었죠. 15개 서비스면 매달 $300가 넘는 돈이 단순히 외부 접속 통로를 만드는 데만 쓰이고 있었던 셈이에요. 또한, 개발팀이 새로운 API 버전을 배포할 때마다 인프라 팀에 DNS 변경을 요청해야 했고, 이 과정에서 발생하는 커뮤니케이션 비용과 지연 시간도 무시할 수 없었어요.
우리의 목표는 명확했어요. 하나의 외부 IP(하나의 LoadBalancer)만 사용하면서, 도메인 주소나 URL 경로에 따라 트래픽을 알아서 분류해 주는 통합 진입점을 만드는 것이었죠. 이를 통해 비용을 80% 이상 절감하고, 개발팀이 스스로 라우팅 규칙을 정의할 수 있는 자율성을 부여하기로 했어요.
STEP 2. 인그레스 컨트롤러 선정 및 설치
저희는 가장 범용적이고 커뮤니티 지원이 강력한 NGINX Ingress Controller를 선택했어요. 설치 방식은 클라우드 환경(EKS)에 맞게 Helm 차트를 이용해 진행했어요. 설치 시 가장 주의 깊게 본 부분은 컨트롤러가 어떤 방식으로 노드에 배치되느냐였어요. 고가용성을 위해 최소 3개의 파드가 서로 다른 가용 영역(Availability Zone)에 분산되도록 Anti-Affinity 설정을 추가했어요.
설치 명령어는 단순하지만, 커스텀 값을 설정하는 과정이 중요해요. 예를 들어, 클라우드 로드밸런서와 컨트롤러 간의 통신을 위해 `service.beta.kubernetes.io/aws-load-balancer-type` 같은 어노테이션을 설정하여, 외부 트래픽이 NLB(Network Load Balancer)를 통해 들어와 컨트롤러의 NodePort로 연결되도록 구성했어요.
STEP 3. 경로 및 호스트 기반 라우팅 구현
컨트롤러가 준비되었다면, 이제 실제 규칙을 담은 인그레스 리소스를 작성할 차례예요. 저희는 두 가지 방식을 혼합하여 사용하고 있어요.
첫째는 호스트 기반 라우팅이에요. 예를 들어, `api.example.com`으로 들어오면 API 서버로, `web.example.com`으로 들어오면 프론트엔드 서비스로 보내는 방식이죠. 이는 서비스 성격이 완전히 다를 때 유용해요.
둘째는 경로 기반 라우팅이에요. 하나의 도메인 아래에서 `/users`, `/orders`, `/products`와 같이 URL 경로에 따라 서로 다른 마이크로서비스로 트래픽을 분산시키는 방식이에요. 이 방식은 서비스 규모가 커질수록 도메인 관리가 단순해진다는 강력한 장점이 있어요.
YAML 작성 시 `pathType` 설정에 유의하세요. `Prefix`는 해당 경로로 시작하는 모든 요청을 포함하고, `Exact`는 정확히 일치하는 요청만 허용해요. 저희는 대부분의 경우 유연한 대응을 위해 `Prefix`를 사용하고 있어요.
실제 적용된 설정 시나리오를 예로 들어볼게요. 사용자가 `example.com/api/v1/users`로 요청을 보내면, 인그레스 컨트롤러는 규칙을 확인하고 이를 `user-service`라는 이름의 쿠버네티스 서비스로 연결해 줍니다. 이 과정은 단 몇 밀리초(ms) 내에 이루어지며, 개발자는 그저 자신의 서비스가 어떤 경로를 사용할지만 정의하면 돼요.
STEP 4. SSL/TLS 인증서 자동화 관리
운영 단계에서 가장 귀찮은 일 중 하나가 바로 인증서 만료 관리예요. 저희는 이 문제를 해결하기 위해 cert-manager를 도입했어요. Let’s Encrypt와 연동하여 인증서 발급부터 갱신까지의 전 과정을 자동화했죠. 인그레스 리소스에 `tls` 섹션을 정의하고, 사용할 인증서의 이름을 `Secret`으로 지정하기만 하면 끝나요.
만약 인증서 자동 갱신 설정을 놓친다면, 어느 날 갑자기 모든 서비스의 HTTPS 접속이 차단되는 재앙을 맞이할 수 있어요. 그래서 저희는 갱신 성공 여부를 모니터링하는 알람을 별도로 구성해 두었어요. 이제 더 이상 인증서 만료 날짜를 달력에 표시하며 불안해할 필요가 없게 되었어요.
STEP 5. 모니터링 및 트래픽 최적화
마지막으로, 인그레스가 잘 작동하는지 확인하기 위해 Prometheus와 Grafana를 활용한 대시보드를 구축했어요. 우리는 단순히 ‘살아있는지’를 확인하는 것을 넘어, 다음과 같은 지표들을 집중적으로 관찰해요.
- Request Per Second (RPS): 특정 서비스에 트래픽이 몰리는지 확인
- Latency (P95, P99): 요청 처리 시간이 지연되는 구간이 있는지 파악
- HTTP Error Rate (4xx, 5xx): 설정 오류나 백엔드 서버의 장애를 즉시 감지
- Bandwidth: 네트워크 대역폭 사용량 확인
이러한 지표를 바탕으로 트래픽이 몰리는 시간대에 인그레스 컨트롤러의 파드 수를 자동으로 늘려주는 HPA(Horizontal Pod Autoscaler)를 적용하여 안정성을 한 단계 더 높였어요.
실전 적용 전후 비교 요약
인그레스 도입 후 저희 서비스 환경은 다음과 같이 극적으로 변화했어요.
| 도입 전 (LoadBalancer 개별 사용) | 도입 후 (Ingress 통합 관리) | |
|---|---|---|
| 외부 IP/LB 개수 | 서비스당 1개 (총 15개) | 통합 1개 |
| 월간 인프라 비용 | 약 $300 이상 | 약 $20 내외 |
| DNS/SSL 관리 | 각 서비스별 개별 관리 (매우 번거로움) | 중앙 집중식 자동 관리 |
| 라우팅 유연성 | L4 수준의 단순 연결 | L7 수준의 경로/호스트 기반 제어 |
자주 하는 실수와 해결법 + FAQ
인그레스 운영은 강력하지만, 그만큼 설정의 디테일이 중요해요. 저희가 겪었던 실제 실패 사례들을 통해 여러분의 시행착오를 줄여드릴게요.
자주 하는 실수와 해결법
❌ 서비스 이름이나 포트 번호 오타
왜 발생하는가: YAML 파일은 매우 민감해요. 인그레스 리소스에서 지정한 backend.service.name이 실제 서비스 이름과 다르거나, 포트 번호가 서비스의 포트와 맞지 않으면 503 Service Unavailable 에러가 발생해요.
✅ 해결법: 작성 후 `kubectl describe ingress <이름>` 명령어를 통해 컨트롤러가 해당 서비스를 제대로 찾고 있는지 반드시 확인하세요.
❌ Path 설정 시 trailing slash(/) 누락
왜 발생하는가: `/api`라고 설정했을 때, 요청이 `/api/users`로 들어오면 매칭이 될 수도 있지만, 컨트롤러 설정에 따라 실패할 수도 있어요. 특히 경로 매칭 규칙에 따라 결과가 달라져요.
✅ 해결법: 가급적 `Prefix` 타입을 사용하고, 경로 끝에 `/`를 붙일지 말지에 대한 팀 내 컨벤션을 통일하세요.
❌ SSL 인증서 Secret 미생성
왜 발생하는가: 인그레스 설정에는 TLS 섹션을 적었지만, 실제 `kubernetes.io/tls` 타입의 Secret이 생성되어 있지 않으면 HTTPS 접속 시 브라우저에서 보안 경고가 뜨거나 접속이 차단돼요.
✅ 해결법: Cert-manager가 Secret을 생성할 때까지 기다리거나, 생성된 Secret 이름을 `kubectl get secret`으로 직접 확인하세요.
❌ Annotation 오타로 인한 설정 무시
왜 발생하는가: NGINX 인그레스는 동작을 제어하기 위해 수많은 Annotations를 사용해요. 예를 들어 `nginx.ingress.kubernetes.io/proxy-body-size`를 적어야 하는데 오타가 나면, 파일 업로드 용량 제한에 걸려 413 Request Entity Too Large 에러가 발생해요.
✅ 해결법: 공식 문서를 옆에 띄워두고 정확한 키 이름을 복사해서 사용하세요.
❌ 백엔드 서비스의 헬스 체크 실패
왜 발생하는가: 인그레스 컨트롤러는 백엔드 파드가 살아있는지 확인해요. 만약 서비스의 Readiness Probe가 제대로 설정되어 있지 않으면, 인그레스는 해당 파드를 ‘준비되지 않음’으로 판단해 트래픽을 보내지 않아요.
✅ 해결법: 파드의 상태가 `Running`이더라도 `Ready` 상태인지 `kubectl get pods`로 확인하는 습관을 들이세요.
자주 묻는 질문
Q. 인그레스와 API 게이트웨이(API Gateway)의 차이점이 무엇인가요?
인그레스는 쿠버네티스 클러스터 내부로 트래픽을 들여보내는 기본적인 L7 규칙 기반의 입구 역할을 해요. 반면 API 게이트웨이는 인증, 인가, 복잡한 트래픽 제어, API 버전 관리 등 훨씬 더 고도화된 기능을 제공하는 서비스예요. 규모가 작다면 인그레스로 충분하지만, 복잡한 API 생태계를 운영한다면 게이트웨이를 고려해야 해요.
Q. 하나의 클러스터에 여러 개의 인그레스 컨트롤러를 띄울 수 있나요?
네, 가능해요. 예를 들어, 일반 서비스용 NGINX 컨트롤러와 관리자 전용(Admin) 컨트롤러를 분리하여 운영할 수 있어요. 이때는 각 컨트롤러가 서로 다른 Ingress Class를 사용하도록 설정해야 충돌이 없어요.
Q. 인그레스를 사용하면 속도가 느려지지는 않나요?
트래픽이 한 곳을 거쳐가기 때문에 아주 미세한 레이턴시(Latency)가 추가될 수는 있어요. 하지만 현대적인 컨트롤러들은 매우 최적화되어 있어 서비스에 미치는 영향은 체감하기 어려운 수준이에요. 오히려 구조적 단순함으로 얻는 이득이 훨씬 커요.
Q. HTTPS 인증서를 수동으로 관리해야 하나요?
아니요, 권장하지 않아요. Cert-manager 같은 도구를 사용하면 Let’s Encrypt를 통해 인증서 발급부터 갱신까지 완전히 자동화할 수 있어요. 운영의 안정성을 위해 자동화를 꼭 도입하세요.
Q. 파일 업로드 용량을 늘리고 싶을 땐 어떻게 하나요?
인그레스 컨트롤러의 어노테이션을 수정해야 해요. NGINX 인그레스 기준으로 `nginx.ingress.kubernetes.io/proxy-body-size: “50m”`과 같이 설정하면 업로드 제한을 늘릴 수 있어요.
핵심 요약과 다음 단계: 인그레스 운영의 성공적인 안착을 위해
지금까지 실제 운영 환경에서의 인그레스 운영 사례를 통해 도입의 필요성부터 트러블슈팅까지 폭넓게 살펴보았어요. 인그레스는 단순히 트래픽을 전달하는 도구를 넘어, 클라우드 비용을 절감하고 운영의 효율성을 극대화하는 핵심 인프라 요소예요.
- 인그레스는 비용 절감과 관리 효율화를 위한 필수적인 도구예요.
- 인그레스 리소스(규칙)와 인그레스 컨트롤러(실행기)를 반드시 구분하세요.
- 경로 기반 및 호스트 기반 라우팅을 적절히 혼합하여 설계하세요.
- SSL/TLS 인증서는 Cert-manager를 통해 반드시 자동화하세요.
- 모니터링 지표(RPS, Latency, Error Rate)를 통해 건강 상태를 지속적으로 체크하세요.
인그레스 도입을 고민하고 있다면, 다음 단계를 따라 차근차근 실행해 보세요.
- 오늘 할 일: 현재 사용 중인 LoadBalancer 서비스들의 목록과 비용을 파악하고, 인그레스로 통합했을 때의 예상 절감액을 계산해 보세요.
- 이번 주 할 일: 개발 환경(Dev) 클러스터에 NGINX 인그레스 컨트롤러를 Helm으로 설치하고, 간단한 웹 서비스를 경로 기반으로 연결하는 테스트를 진행해 보세요.
- 실행 직전 할 일: 운영 환경에 적용하기 전, 반드시 어노테이션 설정과 헬스 체크(Readiness Probe)가 제대로 구성되었는지 검증 시나리오를 만드세요.
실습 과정에서 설정이 꼬이거나 예상치 못한 에러 메시지가 나타난다면 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하면 더 빠르게 해결할 수 있어요! 여러분의 성공적인 클러스터 운영을 응원합니다.
함께 읽으면 도움이 되는 글:
– 쿠버네티스 인그레스 기본 개념 정리하기
– 안정적인 쿠버네티스 클러스터 구축 입문 가이드
