왜 지금 인그레스 운영 사례에 주목해야 할까요
새벽 2시, 갑자기 쏟아지는 트래픽 때문에 서비스가 먹통이 되었을 때의 당혹감을 기억하시나요? 분명 쿠버네티스 클러스터는 잘 돌아가고 있는데, 외부에서 들어오는 요청이 특정 서비스에서만 엉키고 비용은 눈덩이처럼 불어나는 상황 말이에요. 서비스 규모가 커질수록 단순히 LoadBalancer 서비스를 서비스마다 하나씩 만드는 방식은 한계에 부딪히기 마련이에요.
클라우드 환경에서 LoadBalancer 타입의 서비스를 10개 생성하면, 그만큼의 고정 비용이 매달 청구돼요. 게다가 각 서비스마다 별도의 IP를 관리해야 하니 운영 리소스도 엄청나게 소모되죠. 이런 문제를 해결하기 위해 많은 팀이 인그레스(Ingress) 도입을 고민해요. 하지만 이론과 실전은 엄연히 달라요. 단순히 설정 파일 하나 만든다고 해서 모든 트래픽 문제가 마법처럼 해결되지는 않거든요.
이번 글에서는 제가 실무에서 직접 겪은 인그레스 운영 사례를 바탕으로, 어떤 과정을 거쳐 설정을 최적화했는지 아주 자세하게 풀어보려고 해요. 이론적인 정의보다는 실제 트래픽이 어떻게 흐르고, 어떤 설정 하나가 서비스를 살렸는지에 집중했어요.
이 글을 읽고 나면 다음 내용들을 확실히 이해하게 될 거예요.
- 서비스 규모에 따른 인그레스 도입의 경제적 이유
- 실제 운영 환경에서 사용하는 인그레스 설정 구성 방식
- 트래픽을 안정적으로 분산하기 위한 단계별 실행 전략
- 운영 중 반드시 마주하게 되는 실수와 해결 방법
도입 전 반드시 체크해야 할 사전 준비 사항
무턱대고 인그레스를 설치한다고 해서 바로 서비스가 안정화되는 것은 아니에요. 인그레스는 결국 인그레스 컨트롤러(Ingress Controller)라는 실제 일꾼이 있어야 작동하거든요. 이 일꾼을 어떤 종류로 선택하느냐에 따라 여러분이 앞으로 겪을 운영 난이도가 완전히 달라져요.
먼저 우리 팀의 네트워크 요구사항을 명확히 해야 해요. 단순히 하나의 도메인으로 여러 서비스를 나누고 싶은 건지, 아니면 경로(Path)에 따라 아주 세밀한 트래픽 제어가 필요한 건지 결정해야 하죠. 만약 복잡한 인증 로직이나 대규모 트래픽 처리가 우선이라면 단순한 설정만으로는 부족할 수 있어요.
인그레스는 규칙(Rule)을 담은 명세서이고, 인그레스 컨트롤러는 그 규칙을 보고 실제로 트래픽을 전달하는 엔진이에요. 명세서만 있다고 해서 트래픽이 흐르지 않는다는 점을 꼭 기억하세요!
또한, 비용과 관리 효율성 사이의 균형을 잡는 것도 중요해요. 아래 표를 통해 현재 우리 서비스 상황에 어떤 방식이 적합한지 비교해 보세요.
| 구분 | NodePort | LoadBalancer | Ingress |
|---|---|---|---|
| 비용 효율성 | 매우 높음 | 낮음 (서비스당 과금) | 매우 높음 (공유 가능) |
| 관리 복잡도 | 높음 (포트 관리 필요) | 낮음 (클라우드 자동화) | 보통 (컨트롤러 관리 필요) |
| 기능 확장성 | 거의 없음 | 기본적인 L4 기능 | 매우 높음 (L7 제어 가능) |
| 추천 상황 | 테스트용 | 단일 서비스 운영 | 다중 서비스 및 도메인 관리 |
결론적으로, 우리가 다루려는 인그레스 사례의 핵심은 L7 계층에서의 정교한 트래픽 제어를 통해 비용을 절감하고 관리 포인트를 단일화하는 데 있어요. 준비 단계에서 컨트롤러의 종류(Nginx, Kong, Traefik 등)를 정했다면, 이제 본격적인 구축 단계로 넘어갈 준비가 된 거예요.
실무에 바로 쓰는 인그레스 구축 및 운영 5단계
실제 운영 환경에서는 단순히 설치하는 것보다 ‘어떻게 안정적으로 유지하느냐’가 훨씬 중요해요. 제가 직접 적용했던 흐름을 따라가며 단계별로 살펴볼게요.
STEP 1. 인그레스 컨트롤러 설치 및 환경 구성
가장 먼저 할 일은 트래픽을 받아줄 엔진을 설치하는 일이에요. 저희 팀은 가장 커뮤니티가 활발하고 설정 옵션이 풍부한 Nginx Ingress Controller를 선택했어요. 설치는 Helm을 사용하는 것이 가장 깔끔해요. 명령 한 줄로 복잡한 설정이 포함된 컨트롤러를 클러스터에 배포할 수 있거든요.
설치할 때는 반드시 Resource Quota를 설정해야 해요. 컨트롤러가 클러스터의 모든 자원을 다 써버리면 다른 서비스들이 죽어버릴 수 있거든요. CPU와 메모리 제한을 미리 걸어두는 습관이 운영의 안정성을 결정해요. 설치 후에는 반드시 외부 IP가 제대로 할당되었는지 확인하는 과정을 거쳐야 해요.
STEP 2. 도메인 기반의 라우팅 규칙 설계
이제 엔진이 준비되었으니, 어떤 도메인으로 들어오는 요청을 어떤 서비스로 보낼지 규칙을 정해야 해요. 예를 들어, `api.example.com`은 백엔드 서비스로, `web.example.com`은 프론트엔드 서비스로 보내는 식이죠.
이 과정에서 가장 많이 실수하는 부분이 Path 설정이에요. `/` 경로를 사용할 때와 `/api` 같은 특정 경로를 사용할 때의 우선순위를 잘 고려해야 해요. 만약 `/api` 규칙이 `/` 규칙보다 먼저 정의되지 않으면, 모든 요청이 엉뚱한 곳으로 흘러갈 수 있어요. YAML 파일을 작성할 때는 항상 구체적인 경로를 상단에 배치하는 것이 안전해요.
STEP 3. SSL/TLS 인증서 자동화 적용
서비스를 운영하면서 인증서를 수동으로 교체하는 작업만큼 위험한 일은 없어요. 인증서 만료 날짜를 놓쳐서 서비스가 중단되는 사고는 실무에서 생각보다 자주 발생하거든요. 그래서 저희는 Cert-manager를 도입해 Let’s Encrypt 인증서를 자동으로 발급받고 갱신하도록 구성했어요.
인그레스 설정에 tls 섹션을 추가하고, Cert-manager가 관리하는 Secret 이름을 지정해주기만 하면 돼요. 이렇게 하면 인증서가 만료되기 전에 시스템이 알아서 갱신해주기 때문에, 운영자는 더 이상 인증서 만료 알람에 밤잠을 설칠 필요가 없어져요. 이는 인그레스 적용기 중 가장 만족도가 높았던 부분이에요.
STEP 4. 카나리(Canary) 배포를 통한 트래픽 제어
새로운 버전의 서비스를 배포할 때, 한꺼번에 모든 사용자를 대상으로 적용하는 건 너무 위험해요. 이때 인그레스의 강력한 기능 중 하나인 Canary 배포를 활용할 수 있어요. 특정 비율(예: 전체 트래픽의 5%)만 신규 버전으로 보내고, 문제가 없는지 모니터링하는 방식이죠.
Nginx Ingress의 경우 특정 애노테이션(Annotation)을 추가하는 것만으로 아주 쉽게 구현할 수 있어요. `nginx.ingress.kubernetes.io/canary: “true”`와 같은 설정을 통해 트래픽을 쪼갤 수 있죠. 이 기능 덕분에 저희는 배포 시 발생하는 리스크를 획기적으로 줄일 수 있었어요. 실무 운영 경험상, 이 설정 하나가 장애 대응 시간을 얼마나 단축해 주는지 경험해 보지 않으면 모른답니다.
STEP 5. 메트릭 수집 및 모니터링 체계 구축
마지막 단계는 눈에 보이지 않는 트래픽을 데이터로 시각화하는 거예요. 인그레스 컨트롤러에서 생성되는 로그와 메트릭을 Prometheus와 Grafana로 연결해야 해요. 이를 통해 현재 초당 요청 수(RPS), 에러율(4xx, 5xx), 응답 지연 시간(Latency)을 실시간으로 확인할 수 있어요.
만약 특정 경로에서 갑자기 5xx 에러가 치솟는다면, 인그레스 대시보드를 통해 즉시 원인을 파악할 수 있어야 해요. 단순히 “서버가 이상해요”라는 말 대신, “현재 `/api/v1/order` 경로의 에러율이 15%로 급증했습니다”라고 말할 수 있는 환경을 만드는 것이 진정한 운영의 완성이에요.
모니터링을 할 때는 전체적인 트래픽 양도 중요하지만, 반드시 ‘에러율의 변화’와 ‘응답 지연 시간의 변화’를 함께 봐야 해요. 트래픽이 늘어나는 것과 에러가 늘어나는 것은 전혀 다른 문제입니다!
자주 하는 실수와 해결법
현장에서 직접 겪으며 정리한, 인그레스 운영 시 가장 빈번하게 발생하는 문제들이에요. 비슷한 상황을 겪고 있다면 아래 해결법을 먼저 확인해 보세요.
- ❌ 애노테이션(Annotation) 오타로 인한 설정 무시
왜 발생하는가: 인그레스 컨트롤러는 YAML의 애노테이션을 보고 특수 기능을 수행하는데, 철자 하나만 틀려도 그냥 무시돼요.
✅ 해결법: 설정 적용 후 반드시 `kubectl describe ingress` 명령어로 설정이 정상적으로 반영되었는지 확인하세요. - ❌ SSL 인증서와 Secret 이름 불일치
왜 발생하는가: TLS 설정에 적은 Secret 이름과 실제 생성된 Secret 이름이 다르면 HTTPS 접속 시 에러가 발생해요.
✅ 해결법: `kubectl get secret`으로 이름을 확인하고, YAML 파일의 `secretName`과 대조하세요. - ❌ 대용량 파일 업로드 시 413 Request Entity Too Large 에러
왜 발생하는가: 인그레스 컨트롤러의 기본 업로드 용량 제한 때문이에요.
✅ 해결법: `nginx.ingress.kubernetes.io/proxy-body-size` 애노테이션을 사용하여 제한 용량을 늘려주세요. - ❌ Backend 서비스 타임아웃 문제
왜 발생하는가: API 응답이 길어지는데 인그레스의 기본 타임아웃 설정이 짧아서 연결을 끊어버려요.
✅ 해결법: `proxy-read-timeout`과 `proxy-send-timeout` 값을 서비스 특성에 맞게 늘려주세요. - ❌ IP 화이트리스트 설정 오류
왜 발생하는가: 특정 IP만 허용하려 할 때, LoadBalancer의 IP가 아닌 컨트롤러의 IP를 기준으로 설정하는 실수를 해요.
✅ 해결법: `use-forwarded-headers` 설정을 활성화하여 클라이언트의 실제 IP를 인지하도록 구성하세요.
자주 묻는 질문
Q. 인그레스와 게이트웨이 API(Gateway API)의 차이가 무엇인가요?
게이트웨이 API는 인그레스의 한계를 극복하기 위해 나온 차세대 표준이에요. 인그레스는 설정이 단순하지만 복잡한 트래픽 제어가 어렵다는 단점이 있는데, 게이트웨이 API는 역할(Role)을 분리하여 더 유연하고 확장성 있는 관리가 가능해요. 아직은 인그레스가 더 널리 쓰이지만, 점차 게이트웨이 API로 넘어가는 추세예요.
Q. 서비스가 여러 개인데 인그레스 하나로 다 관리할 수 있나요?
네, 가능해요! 인그레스 리소스 하나에 여러 개의 `rule`을 작성하거나, 여러 개의 인그레스 리소스를 만들어 하나의 컨트롤러에 연결하면 돼요. 도메인별로 나누거나 경로별로 나누어 관리하는 것이 일반적이에요.
Q. 인그레스 컨트롤러가 죽으면 어떻게 되나요?
인그레스 컨트롤러는 클러스터의 관문이기 때문에, 컨트롤러가 중단되면 모든 외부 트래픽이 차단돼요. 따라서 반드시 고가용성(HA)을 위해 컨트롤러를 여러 개의 복제본(Replica)으로 띄우고, 분산된 노드에서 실행되도록 설정해야 해요.
Q. 외부 로드밸런서와 인그레스의 차이는 뭔가요?
클라우드의 LoadBalancer는 보통 L4(IP와 포트 기반) 계층에서 작동하고, 인그레스는 L7(도메인과 경로 기반) 계층에서 작동해요. 보통 클라우드 로드밸런서가 인그레스 컨트롤러로 트래픽을 먼저 보내주고, 인그레스가 이를 다시 세부 서비스로 전달하는 계층 구조를 가져요.
