인그레스 운영 사례가 왜 실무에서 핵심일까요
클러스터에 서비스가 하나둘 늘어나면서 갑자기 클라우드 비용 청구서가 무섭게 올라오는 경험을 해본 적 있나요? 처음에는 각 서비스마다 LoadBalancer 타입을 사용해서 외부로 노출하는 게 가장 속 편해요. 하지만 서비스가 10개, 20개로 늘어나면 이야기가 완전히 달라져요. 클라우드 업체에서 제공하는 로드밸런서 하나당 매달 지불해야 하는 비용은 생각보다 만만치 않거든요.
단순히 비용 문제뿐만이 아니에요. 도메인 하나에 여러 서비스를 연결하거나, 특정 경로(Path)에 따라 다른 서비스로 트래픽을 보내야 하는 요구사항이 생기면 기존 방식으로는 한계에 부딪혀요. 설정은 복잡해지고 관리 포인트는 기하급수적으로 늘어나죠. 인그레스 운영 사례를 살펴보는 이유는 바로 이런 복잡성을 어떻게 기술적으로 우아하게 해결했는지 배우기 위해서예요.
이 글에서는 단순히 이론적인 개념을 나열하지 않을게요. 실제 서비스 운영 환경에서 인그레스를 어떻게 도입했고, 어떤 과정을 거쳐 설정을 최적화했는지 그 생생한 이야기를 들려드릴게요. 네트워크 구조를 설계할 때 겪을 수 있는 시행착오를 줄이는 데 큰 도움이 될 거예요.
이 글에서 함께 나눌 내용들
- 로드밸런서 비용 폭탄을 막기 위한 인그레스 도입 배경
- 현업에서 가장 많이 쓰이는 인그레스 컨트롤러 선택 기준
- 실제 서비스에 적용한 단계별 설정과 고급 라우팅 기법
- 운영 중 마주친 트러블슈팅 사례와 자주 묻는 질문들
인그레스를 도입하기 전 꼭 체크해야 할 사항들
인그레스를 무턱대고 설치한다고 모든 문제가 해결되지는 않아요. 우리 팀의 현재 서비스 규모와 트래픽 특성을 먼저 파악하는 게 순서예요. 만약 서비스가 단 두 개뿐이고 트래픽도 거의 없다면, 굳이 인그레스를 도입해서 운영 복잡도를 높이는 게 오히려 손해일 수도 있거든요.
먼저 우리가 현재 어떤 방식으로 서비스를 외부로 노출하고 있는지 정리해봐요. 기존에 사용하던 방식과 인그레스 방식의 차이를 명확히 알아야 도입의 당위성을 팀원들에게 설명할 수 있어요. 아래 표를 통해 각 방식의 특징을 비교해봤어요.
| 방식 | 장점 | 단점 | 추천 상황 |
|---|---|---|---|
| NodePort | 설정이 매우 단순하고 별도 비용 없음 | 보안에 취약하고 포트 관리가 어려움 | 테스트 환경, 로컬 개발 |
| LoadBalancer | 클라우드 인프라와 연동되어 안정적임 | 서비스당 비용 발생, 관리 포인트 증가 | 소규모 서비스, 단순 구조 |
| Ingress | 경로 기반 라우팅, 비용 절감, SSL 통합 관리 | 컨트롤러 설치 및 추가 학습 필요 | 다수의 서비스 운영, 실서비스 환경 |
인그레스를 성공적으로 안착시키기 위해서는 몇 가지 준비물이 필요해요. 클러스터 내에 Ingress Controller가 설치되어 있어야 하고, 도메인을 연결할 수 있는 DNS 설정 권한도 있어야 하죠. 특히 보안을 위해 TLS 인증서 관리 자동화를 고려하고 있다면, cert-manager 같은 도구를 미리 검토하는 것이 좋아요.
인그레스는 그 자체로 트래픽을 처리하는 엔진이 아니에요. 인그레스 설정값(리소스)을 읽어서 실제로 트래픽을 전달해주는 역할을 수행하는 별도의 프로세스인 ‘인그레스 컨트롤러’가 반드시 필요하다는 점을 잊지 마세요.
준비가 끝났다면 이제 본격적으로 인그레스가 실제 운영 환경에서 어떻게 적용되는지 그 과정을 단계별로 살펴볼게요.
실전 인그레스 적용기: 설계부터 고급 라우팅까지
저희 팀은 마이크로서비스 아키텍처(MSA)로 전환하면서 관리해야 할 API 서버와 프론트엔드 서비스가 15개 이상으로 늘어났어요. 기존에는 각 서비스마다 클라우드 로드밸런서를 붙여서 썼는데, 이로 인해 매달 발생하는 비용이 서비스 운영비의 상당 부분을 차지하게 되었죠. 그래서 결심했어요. 단 하나의 로드밸런서만 사용하고, 그 뒤에서 인그레스가 트래픽을 분배하도록 구조를 바꾸기로요.
STEP 1. 인그레스 컨트롤러 선정과 설치
가장 먼저 고민한 것은 어떤 컨트롤러를 쓸 것인가였어요. 시장에는 Nginx, Traefik, Kong 등 다양한 선택지가 있었죠. 저희는 가장 커뮤니티가 활발하고 레퍼런스가 풍부한 Nginx Ingress Controller를 선택했어요. 설정 옵션이 매우 방대해서 요구사항을 맞추기에 가장 유리했거든요.
설치는 Helm을 사용해서 진행했어요. 복잡한 명령어를 일일이 입력하는 대신, Helm 차트를 이용하면 필요한 설정값(values.yaml)만 수정해서 깔끔하게 배포할 수 있어요. 설치 시 주의할 점은 클라우드 제공업체의 로드밸런서 설정과 컨트롤러의 서비스 타입이 잘 맞물려야 한다는 거예요. 저희는 AWS EKS 환경에서 사용 중이었기에, 컨트롤러를 설치하면 자동으로 NLB(Network Load Balancer)가 생성되도록 구성했어요.
STEP 2. 경로 기반 라우팅(Path-based Routing) 설정
이제 본격적으로 인그레스 리소스를 생성해서 트래픽을 배분해볼 차례예요. 예를 들어, `api.example.com/users`로 들어오는 요청은 사용자 서비스로, `api.example.com/orders`로 들어오는 요청은 주문 서비스로 보내야 해요. 아래는 저희가 실제 사용한 설정 예시예요.
설정 파일(YAML)을 작성할 때는 경로 매칭 규칙을 아주 정밀하게 짜야 해요. 만약 `/` 경로를 너무 넓게 잡아버리면 다른 특정 경로로 가는 트래픽까지 모두 가로챌 수 있거든요.
인그레스 설정에서 `pathType: Prefix`를 사용하면 해당 경로로 시작하는 모든 요청을 포함하지만, `Exact`를 사용하면 정확히 일치하는 경로만 매칭돼요. 서비스의 특성에 맞춰 신중하게 골라야 해요.
STEP 3. SSL/TLS 인증서 통합 관리
실무에서 보안은 타협할 수 없는 요소예요. 모든 서비스에 HTTPS를 적용해야 하는데, 서비스가 늘어날 때마다 인증서를 수동으로 업데이트하는 건 불가능에 가까워요. 그래서 저희는 cert-manager를 도입했어요. Let’s Encrypt를 통해 인증서를 발급받고, 인그레스 리소스에 설정만 해두면 자동으로 갱신까지 이루어지도록 구성했죠.
이렇게 하면 개발자가 인그레스 설정 파일에 `tls` 섹션만 추가하면 끝나요. 인증서가 만료되어 서비스가 중단되는 대참사를 막을 수 있는 아주 강력한 방법이에요. 설치 후에는 실제로 브라우저에서 자물쇠 아이콘이 잘 뜨는지, 인증서 만료일이 적절하게 잡혀있는지 꼭 확인해야 해요.
STEP 4. 카나리(Canary) 배포를 통한 리스크 최소화
인그레스의 진짜 강력함은 단순한 라우팅을 넘어선 고급 기능에서 나타나요. 저희는 신규 버전의 API를 배포할 때 사용자 전체에게 바로 적용하지 않고, 일부 트래픽만 먼저 흘려보내는 Canary 배포 방식을 사용했어요. Nginx 인그레스 컨트롤러가 제공하는 Annotation 기능을 활용하면 아주 쉽게 구현할 수 있어요.
예를 들어, 새로운 버전의 서비스를 ‘canary’라는 이름의 인그레스 리소스로 하나 더 만들고, `nginx.ingress.kubernetes.io/canary: “true”`라는 어노테이션을 추가해요. 그리고 `canary-weight: “10”`이라고 설정하면, 전체 트래픽 중 딱 10%만 신규 버전으로 전달돼요. 만약 모니터링 결과에 문제가 없다면 점진적으로 이 비중을 높여나가면 되는 거죠. 이 방식 덕분에 배포 시 발생하는 불안감을 획기적으로 줄일 수 있었어요.
STEP 5. 실시간 모니터링과 지표 확인
설정을 마쳤다면 이제 잘 작동하는지 감시해야 해요. 인그레스로 들어오는 트래픽 양, 응답 시간(Latency), 에러율(4xx, 5xx)을 실시간으로 확인하는 게 필수예요. 저희는 Prometheus와 Grafana를 연동해서 대시보드를 구축했어요.
인그레스 컨트롤러에서 제공하는 메트릭을 가져오면, 특정 API 경로에서 유독 에러가 많이 발생하는지, 혹은 특정 시간대에 트래픽이 몰려 응답이 느려지는지를 한눈에 파악할 수 있어요. 인그레스 운영 사례를 통해 얻은 가장 큰 교훈은, 눈에 보이지 않는 네트워크 트래픽을 데이터로 시각화하는 것이 운영 안정성의 시작이라는 점이에요.
설정 변경 후에는 반드시 실제 트래픽이 의도한 대로 흐르는지 테스트 환경에서 검증해야 해요. 아주 작은 오타 하나가 전체 서비스의 연결을 끊어버릴 수 있으니까요.
자주 하는 실수와 해결법 및 자주 묻는 질문
인그레스를 운영하다 보면 예상치 못한 에러 메시지를 마주하게 될 때가 많아요. 당황하지 말고 아래의 대표적인 실수 사례들을 참고해서 문제를 해결해 보세요.
자주 하는 실수와 해결법
- ❌ 404 Not Found 에러가 발생해요
왜 발생할까요? 인그레스의 `path` 설정과 실제 서비스의 엔드포인트가 일치하지 않거나, `pathType`을 잘못 설정했을 가능성이 높아요.
✅ 해결법: `pathType`이 `Prefix`인지 `Exact`인지 다시 확인하고, 서비스의 경로가 인그레스 설정과 정확히 일치하는지 점검하세요. - ❌ 502 Bad Gateway 에러가 떠요
왜 발생할까요? 인그레스 컨트롤러가 트래픽을 전달할 대상 서비스(Backend Service)를 찾지 못하거나, 서비스의 포트 설정이 잘못되었을 때 나타나요.
✅ 해결법: 인그레스가 가리키는 `serviceName`과 `servicePort`가 실제 서비스 객체의 정보와 정확히 일치하는지 확인하세요. - ❌ HTTPS 접속 시 인증서 경고가 떠요
왜 발생할까요? TLS Secret이 올바르게 생성되지 않았거나, 인그레스 설정에서 `tls` 섹션을 누락했을 때 발생해요.
✅ 해결법: `kubectl get secret` 명령어로 인증서가 존재하는지 확인하고, 인그레스 YAML 파일에 해당 Secret 이름이 정확히 적혀 있는지 체크하세요. - ❌ 특정 요청이 중간에 끊겨요(Timeout)
왜 발생할까요? 대용량 파일 업로드나 긴 시간이 소요되는 API 호출 시 인그레스 컨트롤러의 기본 타임아웃 설정보다 요청 시간이 길어지면 연결이 끊겨요.
✅ 해결법: 인그레스의 어노테이션을 통해 `proxy-body-size`나 `proxy-read-timeout` 값을 적절하게 늘려주세요. - ❌ 설정한 Annotation이 적용되지 않아요
왜 발생할까요? 오타가 있거나, 사용 중인 인그레스 컨트롤러가 해당 어노테이션을 지원하지 않는 경우예요.
✅ 해결법, 인그레스 컨트롤러의 공식 문서를 확인하여 지원하는 어노테이션 목록과 정확한 키 이름을 다시 한번 대조해 보세요.
자주 묻는 질문
Q. 인그레스와 로드밸런서(LoadBalancer 타입 서비스)의 차이점은 무엇인가요?
로드밸런서는 클라우드 인프라 수준에서 제공하는 물리적/가상 장치로, 서비스 하나당 하나를 생성하면 비용이 많이 들어요. 반면 인그레스는 하나의 로드밸런서 뒤에서 소프트웨어적으로 경로에 따라 여러 서비스를 나누어주는 역할을 해요. 비용 효율성과 세밀한 제어 측면에서 인그레스가 훨씬 유리해요.
Q. 하나의 클러스터에 여러 개의 인그레스 컨트롤러를 쓸 수 있나요?
네, 가능해요. 각 컨트롤러에 서로 다른 `ingressClassName`을 부여하면 됩니다. 예를 들어, 외부 트래픽용 Nginx 컨트롤러와 내부 통신용 컨트롤러를 분리해서 운영할 수 있어 보안과 관리 측면에서 매우 권장되는 방식이에요.
Q. 인증서 관리를 위해 반드시 cert-manager를 써야 하나요?
필수는 아니지만, 실무에서는 거의 필수라고 봐도 무방해요. 수동으로 인증서를 관리하면 갱신 시점을 놓치기 쉽고, 이는 곧 서비스 장애로 이어지기 때문이에요. 자동화 도구를 사용하는 것이 정신 건강에 훨씬 이롭답니다.
Q. API Gateway와 인그레스는 어떻게 다른가요?
인그레스는 쿠버네티스 내의 L7 라우팅에 특화된 가벼운 도구예요. 반면 API Gateway는 인증, 인가, 속도 제한(Rate Limiting), 사용자별 할당량 관리 등 훨씬 더 복잡하고 비즈니스 로직에 밀접한 기능을 제공해요. 단순 라우팅이 목적이라면 인그레스로 충분하고, 더 복잡한 기능이 필요하다면 API Gateway 도입을 고려하세요.
성공적인 인그레스 운영을 위한 마지막 정리
인그레스는 쿠버네티스 운영의 꽃이라고 할 수 있을 만큼 강력하지만, 그만큼 세밀한 관리가 필요한 영역이에요. 오늘 살펴본 내용을 바탕으로 여러분의 클러스터 환경을 한 단계 업그레이드해 보시길 바라요.
- 비용 절감과 경로 기반 라우팅을 위해 인그레스 도입은 필수예요.
- Nginx Ingress Controller는 가장 검증된 선택지 중 하나예요.
- cert-manager를 활용해 TLS 인증서 관리를 자동화하세요.
- Annotation을 사용해 카나리 배포와 같은 고급 기능을 적극 활용하세요.
- 모니터링 도구를 통해 트래픽 패턴과 에러율을 실시간으로 감시하세요.
지금 바로 여러분의 환경에서 적용해 볼 수 있는 단계별 할 일을 제안해 드릴게요.
- 오늘 할 일: 현재 사용 중인 서비스들의 LoadBalancer 비용을 산출해보고 인그레스 도입 시의 예상 절감액 계산해보기
- 이번 주 할 일: 개발 환경에 Nginx Ingress Controller와 cert-manager를 설치하고 테스트 도메인 연결해보기
- 실행 직전 할 일: 실제 운영 환경에 적용하기 전, 카나리 배포 시나리오를 작성하고 트래픽 분산 테스트 수행하기
인그레스 설정 과정에서 막히는 부분이 있거나, 여러분만의 독특한 운영 노하우가 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하고 해결해 나갔으면 좋겠어요!
더 깊이 있는 쿠버네티스 운영 지식이 궁금하다면, 이전에 작성한 쿠버네티스 인그레스 기본 개념 글이나 클러스터 구축 입문 글도 함께 읽어보시는 것을 추천드려요.
