트래픽 관리가 막막한 개발자를 위한 인그레스 운영 사례
서비스 규모가 커지면서 매번 새로운 마이크로서비스를 배포할 때마다 클라우드의 로드밸런서(LoadBalancer)를 생성하고 있었나요? 서비스가 10개, 20개로 늘어날수록 관리해야 할 엔드포인트는 기하급수적으로 증가하고, 매달 청구되는 클라우드 비용 고지서를 보며 한숨을 내쉰 적이 분명히 있을 거예요. 단순히 서비스 노출을 위해 모든 서비스에 개별 로드밸런서를 할당하는 방식은 운영 효율과 비용 측면에서 매우 위험한 선택이에요.
실제로 저희 팀도 초기에는 각 서비스마다 독립적인 로드밸런서를 사용했어요. 하지만 이는 네트워크 인프라를 복잡하게 만들 뿐만 아니라, 도메인 관리와 SSL 인증서 적용 과정에서도 엄청난 병목 현상을 일으켰어요. 트래픽을 어디서 어떻게 제어해야 할지 몰라 헤매던 시기를 지나, 우리는 인그레스(Ingress)를 도입하며 운영 체계를 완전히 바꾸게 되었어요.
이 글은 단순히 이론적인 개념을 설명하는 글이 아니에요. 실제 운영 환경에서 겪었던 시행착오와 이를 어떻게 인그레스 설정으로 해결했는지에 대한 인그레스 운영 사례를 생생하게 담았어요. 쿠버네티스 환경에서 효율적인 트래픽 라우팅을 고민하는 백엔드 개발자라면 반드시 공감할 내용들이에요.
이 글을 읽고 나면 다음과 같은 내용을 완벽히 이해할 수 있어요.
- 인그레스 도입이 왜 비용과 운영 효율을 개선하는지
- 실무에서 사용하는 인그레스 컨트롤러의 선택 기준
- 호스트 기반 및 경로 기반 라우팅의 실제 적용 방법
- 운영 중 마주치는 흔한 네트워크 오류 해결법
인그레스 도입 전 반드시 체크해야 할 핵심 요소
인그레스를 도입하기로 마음먹었다면, 무턱대고 설치부터 해서는 안 돼요. 인그레스는 단순히 규칙을 정의하는 ‘리소스’일 뿐이고, 실제로 그 규칙을 해석해서 트래픽을 전달해 줄 인그레스 컨트롤러(Ingress Controller)가 반드시 필요하기 때문이에요. 어떤 컨트롤러를 선택하느냐에 따라 우리가 구현할 수 있는 기능의 범위가 완전히 달라져요.
먼저 우리 서비스의 요구사항이 무엇인지 명확히 해야 해요. 단순한 L7 라우팅만 필요한지, 아니면 복잡한 인증(Auth)이나 속도 제한(Rate Limiting) 기능까지 인그레스 계층에서 처리하고 싶은지를 결정해야 하죠. 또한, 현재 사용 중인 클라우드 환경이 인그레스 컨트롤러를 통해 외부 로드밸런서를 어떻게 생성하고 관리하는지도 미리 파악해 두어야 해요.
인그레스 리소스(Ingress Resource)는 ‘어떤 도메인으로 들어오면 어떤 서비스로 보내라’는 규칙이 적힌 문서와 같아요. 반면 인그레스 컨트롤러는 그 문서를 읽고 실제로 트래픽을 길을 안내하는 ‘교통경찰’ 역할을 수행하는 소프트웨어예요.
현업에서 가장 많이 고려하는 세 가지 컨트롤러를 비교해 드릴게요. 이 표를 통해 우리 팀에 맞는 선택지를 고민해 보세요.
| 컨트롤러 종류 | 주요 특징 | 장점 | 단점 |
|---|---|---|---|
| Nginx Ingress | 가장 대중적인 오픈소스 | 방대한 레퍼런스와 안정성 | 설정이 복잡해질 수 있음 |
| Traefik | 클라우드 네이티브 지향 | 동적 설정 및 대시보드 제공 | Nginx 대비 적은 커뮤니티 |
| Kong | API 게이트웨이 특화 | 강력한 플러그인 생태계 | 높은 리소스 점유율 |
선택을 돕기 위한 기준을 말씀드릴게요. 만약 우리 팀이 쿠버네티스를 이제 막 시작했고, 문제 발생 시 구글링으로 빠르게 해결하고 싶다면 Nginx Ingress를 추천해요. 하지만 서비스 규모가 매우 크고, API 인증이나 복잡한 트래픽 제어 로직을 코드 레벨이 아닌 인프라 레벨에서 처리하고 싶다면 Kong을 고려하는 것이 좋아요. 어떤 것을 선택하든, 초기 설정 시에는 컨트롤러가 사용하는 리소스 사용량(CPU/Memory)을 반드시 모니터링해야 한다는 점을 잊지 마세요.
실전 인그레스 구축 및 운영 5단계
이제 본격적인 인그레스 적용기를 시작해 볼게요. 저희 팀은 기존에 서비스마다 각각 할당되어 있던 15개의 로드밸런서를 단 하나의 인그레스 컨트롤러로 통합하는 작업을 진행했어요. 이 과정은 단순히 설정 하나를 바꾸는 것이 아니라, 전체 네트워크 흐름을 재설계하는 과정이었어요.
STEP 1. 기존 인프라 분석과 컨트롤러 배포 준비
가장 먼저 했던 일은 현재 운영 중인 서비스들의 도메인과 경로(Path)를 전수 조사하는 것이었어요. 어떤 서비스는 `api.example.com`처럼 서브도메인을 사용하고, 어떤 서비스는 `example.com/user`처럼 경로를 사용하고 있었거든요. 이 정보가 정확하지 않으면 인그레스 설정 시 트래픽이 엉뚱한 곳으로 흘러가는 대참사가 발생할 수 있어요.
분석을 마친 후, 저희는 헬름(Helm)을 사용하여 Nginx Ingress Controller를 배포했어요. 이때 단순히 기본 설정으로 설치하지 않고, 클라우드 환경의 로드밸런서와 연동되는 Annotation을 꼼꼼히 설정했어요. 예를 들어, AWS 환경이라면 LoadBalancer 타입의 서비스가 NLB(Network Load Balancer)를 생성하도록 지정하여 성능과 보안을 동시에 챙겼어요. 설치 직후에는 반드시 `kubectl get ingress` 명령어를 통해 컨트롤러가 정상적으로 외부 IP를 할당받았는지 확인하는 절차가 필요해요.
STEP 2. 호스트 및 경로 기반 라우팅 구현
컨트롤러가 준비되었다면, 이제 실제 트래픽이 흐를 수 있는 길을 만들어야 해요. 저희는 두 가지 전략을 혼합해서 사용했어요. 첫 번째는 서비스별로 독립된 도메인을 부여하는 호스트 기반 라우팅이고, 두 번째는 하나의 도메인 안에서 경로로 구분하는 경로 기반 라우팅이에요.
예를 들어, 결제 서비스는 `payment.example.com`으로, 사용자 서비스는 `example.com/user`로 접근하도록 설정했어요. YAML 파일을 작성할 때 주의할 점은 경로의 우선순위예요. `/api`라는 경로와 `/api/v1`이라는 경로가 동시에 존재할 경우, 더 구체적인 경로를 먼저 인식하도록 설정하지 않으면 `/api/v1`으로 들어온 요청이 `/api` 서비스로 잘못 전달될 수 있어요. 저희는 이 문제를 해결하기 위해 경로의 길이를 기준으로 정교하게 라우팅 규칙을 설계했어요.
STEP 3. SSL/TLS 인증서 자동화 적용
인그레스를 도입하면서 얻은 가장 큰 이득 중 하나는 바로 인증서 관리의 편의성이에요. 이전에는 각 서비스마다 인증서를 심어야 했지만, 이제는 인그레스 계층에서 한 번만 설정하면 모든 하위 서비스에 보안 연결(HTTPS)을 적용할 수 있어요. 저희는 이를 위해 Cert-manager를 함께 도입했어요.
Cert-manager를 설치하면 Let’s Encrypt와 같은 인증 기관으로부터 인증서를 자동으로 발급받고, 만료되기 전에 알아서 갱신까지 해줘요. 개발자가 일일이 인증서 만료일을 체크하며 밤을 지새울 필요가 없어진 것이죠. 다만, 이 과정에서 DNS-01 챌린지를 사용할 경우 DNS 설정 권한이 필요하므로, 인프라 팀과의 사전 협의가 필수적이에요.
인증서 자동화가 실패하면 서비스 전체에 404 에러나 SSL 보안 경고가 뜰 수 있어요. Cert-manager의 로그를 주기적으로 확인하여 인증서 발급 상태(Ready 상태)를 점검하는 습관을 들여야 해요.
STEP 4. 카나리(Canary) 배포를 통한 트래픽 제어
인그레스는 단순한 길잡이를 넘어, 안전한 배포를 돕는 강력한 도구가 될 수 있어요. 저희는 신규 버전의 서비스를 배포할 때 전체 트래픽의 5%만 먼저 새 버전으로 보내는 카나리 배포 방식을 활용했어요. Nginx Ingress의 Annotation 기능을 사용하면 아주 간단하게 구현할 수 있어요.
새로운 버전의 Pod를 배포하고, 인그레스 설정에 `nginx.ingress.kubernetes.io/canary: “true”`와 `nginx.ingress.kubernetes.io/canary-weight: “5”`라는 문구를 추가하기만 하면 돼요. 이렇게 하면 실제 사용자에게 큰 영향을 주지 않으면서도 신규 코드의 안정성을 테스트할 수 있어요. 테스트 결과가 좋으면 가중치를 서서히 높여 100%까지 전환하는 방식으로 운영하며 배포 실패의 공포에서 벗어날 수 있었어요.
STEP 5. 모니터링 및 지표 분석
마지막 단계는 우리가 구축한 인그레스가 잘 작동하고 있는지 확인하는 과정이에요. 인그레스 컨트롤러 자체의 로그를 보는 것도 중요하지만, 더 핵심은 트래픽 지표를 보는 것이에요. 저희는 Prometheus와 Grafana를 연동하여 요청 수(Request Rate), 에러율(Error Rate), 응답 시간(Latency)을 대시보드로 시각화했어요.
만약 특정 시간대에 5xx 에러가 급증한다면, 그것이 백엔드 서비스의 문제인지 아니면 인그레스의 타임아웃 설정 문제인지를 즉시 구분할 수 있어야 해요. 인그레스의 `proxy-connect-timeout`이나 `proxy-read-timeout` 값을 적절히 조정하는 것만으로도 많은 네트워크 오류를 해결할 수 있었어요. 이러한 데이터 기반의 운영은 서비스의 안정성을 비약적으로 높여주었답니다.
자주 하는 실수와 해결법 및 FAQ
자주 하는 실수와 해결법
인그레스 운영 중에 저희가 직접 겪었던, 혹은 동료들이 자주 했던 실수들을 정리했어요. 비슷한 상황에 처해 있다면 이 내용을 먼저 확인해 보세요.
- ❌ 인그레스 컨트롤러를 설치하지 않고 리소스만 생성함
왜 발생하는가: 인그레스 개념을 ‘자동으로 작동하는 기능’으로 오해하기 때문이에요.
✅ 해결법: 반드시 Nginx나 Traefik 같은 컨트롤러를 먼저 클러스터에 배포해야 해요. - ❌ 경로(Path) 우선순위 설정 오류
왜 발생하는가: `/`와 `/api`가 있을 때 어떤 것이 먼저 매칭될지 명확히 정의하지 않기 때문이에요.
✅ 해결법: 가장 구체적인 경로(가장 긴 경로)를 우선순위가 높도록 배치하거나, 인그레스 컨트롤러의 설정 값을 확인하세요. - ❌ TLS 인증서 Secret 이름 불일치
왜 발생하는가: YAML 파일에 적은 Secret 이름과 실제 생성된 Secret 이름이 다르기 때문이에요.
✅ 해결법: `kubectl get secret` 명령어로 정확한 이름을 확인하고 오타가 없는지 체크하세요. - ❌ 백엔드 서비스의 Readiness Probe 실패
왜 발생하는가: 인그레스는 서비스가 ‘준비됨’ 상태일 때만 트래픽을 보내는데, Pod가 준비되지 않았기 때문이에요.
✅ 해결법: 서비스의 Readiness Probe 설정을 점검하고 Pod가 정상적으로 Running 상태인지 확인하세요. - ❌ 클라이언트와 프록시 간의 타임아웃 불일치
왜 발생하는가: 대용량 파일을 업로드하거나 긴 처리가 필요한 요청 시 인그레스의 타임아웃이 먼저 끊기기 때문이에요.
✅ 해결법: 인그레스의 Annotation을 통해 `proxy-body-size`와 `proxy-read-timeout` 값을 늘려주세요.
자주 묻는 질문
Q. 인그레스와 로드밸런서(LoadBalancer)의 차이점이 정확히 무엇인가요?
로드밸런서는 클라우드 인프라 레벨에서 제공하는 단일 서비스 진입점이에요. 반면 인그레스는 쿠버네티스 내부에서 여러 개의 서비스를 하나의 로드밸런서로 묶어 관리할 수 있게 해주는 ‘규칙 집합’이라고 이해하시면 쉬워요. 즉, 로드밸런서 하나 뒤에 인그레스를 두고, 인그레스가 여러 서비스를 나누어 주는 구조예요.
Q. 인그레스를 쓰면 성능(Latency)이 떨어지지 않나요?
트래픽이 한 단계를 더 거치기 때문에 아주 미세한 지연은 발생할 수 있어요. 하지만 현대적인 인그레스 컨트롤러는 매우 최적화되어 있어 체감하기 어려울 정도예요. 오히려 수십 개의 개별 로드밸런서를 사용하는 것보다 네트워크 경로가 단순해져 관리 효율 면에서 이득이 훨씬 커요.
Q. 하나의 인그레스로 여러 도메인을 관리할 수 있나요?
네, 당연히 가능해요! 인그레스 리소스의 `host` 필드에 서로 다른 도메인을 지정하기만 하면, 하나의 컨트롤러가 각 도메인에 맞는 서비스로 트래픽을 정확히 분배해 줘요.
Q. 인증서 갱신을 놓치면 어떻게 되나요?
브라우저에서 ‘연결이 안전하지 않음’이라는 경고 창이 뜨면서 사용자의 접근이 차단돼요. 그래서 저희는 Cert-manager를 통해 자동 갱신 환경을 구축하는 것을 강력하게 권장해요.
Q. API 게이트웨이와 인그레스는 무엇이 다른가요?
인그레스는 주로 L7 계층의 라우팅에 집중하는 반면, API 게이트웨이는 인증, 권한 부여, 호출 제한, 데이터 변환 등 훨씬 더 복잡하고 비즈니스 로직에 가까운 기능을 제공해요. 단순 트래픽 분산이 목적이라면 인그레스가 가볍고 좋지만, 고도화된 API 관리가 필요하다면 API 게이트웨이를 고려해야 해요.
