인그레스 도입이 절실했던 결정적 순간
매달 날아오는 클라우드 비용 청구서를 보고 눈을 의심했던 경험이 있으신가요? 서비스 규모가 커지면서 각 마이크로서비스마다 개별적인 로드밸런서를 할당하다 보니, 어느덧 비용은 감당하기 힘든 수준으로 치솟았어요. 게다가 서비스가 늘어날수록 관리해야 할 엔드포인트와 인증서 개수도 기하급수적으로 늘어나 운영팀의 피로도는 극에 달했지요.
단순히 서비스 하나를 띄우는 단계라면 로드밸런서(LoadBalancer) 타입의 서비스만으로도 충분했을 거예요. 하지만 수십 개의 서비스를 운영해야 하는 환경에서는 이야기가 달라져요. 각 서비스마다 공인 IP를 할당하고 개별적인 L4 장비를 사용하는 것은 자원 낭비일 뿐만 아니라, 네트워크 구성의 복잡도를 높여 장애 대응을 어렵게 만들어요.
이런 상황에서 인그레스 운영 사례를 찾아 헤매던 저희 팀은 결국 인그레스(Ingress)를 도입하기로 결심했어요. 인그레스는 클러스터 내부의 여러 서비스로 트래픽을 효율적으로 라우팅해주는 똑똑한 문지기 역할을 해주거든요. 비용 절감은 물론, 하나의 IP로 여러 도메인을 관리할 수 있다는 강력한 장점이 있어요.
이 글에서는 이론적인 설명보다는 실제 현장에서 겪었던 시행착오와 구체적인 적용 과정을 중심으로 이야기를 풀어보려고 해요. 인그레스를 도입하기 전 어떤 고민을 했는지, 실제로 어떤 설정을 거쳐 안정화했는지 궁금해하실 분들에게 실질적인 도움이 되길 바라요.
- 로드밸런서와 인그레스의 비용 및 운영 효율성 비교
- Nginx 인그레스 컨트롤러를 활용한 실전 구성 단계
- SSL/TLS 인증서 자동화와 트래픽 제어 기법
- 운영 중 마주한 흔한 실수와 해결 방안
성공적인 도입을 위한 사전 준비와 판단 기준
인그레스를 도입하기로 마음먹었다면, 무작정 설치 버튼부터 누르기보다는 현재 우리 클러스터의 상황을 냉정하게 진단해야 해요. 단순히 ‘유행하니까’ 혹은 ‘남들이 쓰니까’라는 이유로 도입했다가는 오히려 트래픽 제어가 복잡해지거나 컨트롤러 자체가 병목 구간이 되어 서비스 전체가 중단되는 불상사를 겪을 수 있어요.
가장 먼저 결정해야 할 것은 어떤 인그레스 컨트롤러를 사용할 것인가 하는 문제예요. 가장 대중적인 선택지는 Nginx 인그레스 컨트롤러이지만, 클라우드 환경에 따라 AWS의 ALB Ingress Controller나 Google Cloud의 GCLB를 사용하는 것이 더 유리할 때도 있어요. 각 컨트롤러마다 제공하는 기능과 설정 방식이 다르기 때문이지요.
또한, 인그레스를 운영하기 위해서는 몇 가지 필수적인 구성 요소들이 준비되어 있어야 해요. 단순히 라우팅 규칙만 만든다고 끝나는 것이 아니라, 인증서를 자동으로 갱신해 줄 Cert-manager나, 트래픽을 모니터링할 프로메테우스(Prometheus) 같은 도구들이 유기적으로 연결되어야 비로소 실무 수준의 운영이 가능해져요.
우리 팀의 상황에 인그레스가 정말 적합한지 판단하기 어렵다면, 아래 비교 표를 참고해 보세요. 현재 직면한 문제와 비교해 보면 답이 보일 거예요.
| 비교 항목 | LoadBalancer 서비스 | Ingress 컨트롤러 |
|---|---|---|
| 클라우드 비용 | 서비스당 IP/LB 할당 (높음) | 단일 LB로 다수 서비스 수용 (낮음) |
| 라우팅 복잡도 | L4 계층 기반 (단순함) | L7 계층 기반 (Path, Host 등 정교함) |
| 인증서 관리 | 서비스마다 개별 설정 필요 | 중앙 집중식 관리 및 자동화 용이 |
| 운영 난이도 | 매우 낮음 | 중간 (컨트롤러 관리 필요) |
만약 현재 서비스가 5개 미만이고 트래픽 변화가 거의 없다면, 오히려 로드밸런서 서비스를 그대로 유지하는 것이 운영 공수를 줄이는 길일 수 있어요. 하지만 서비스가 늘어날 가능성이 높고, 도메인별로 다른 경로를 지정해야 하거나, 보안을 위해 SSL을 세밀하게 제어해야 한다면 인그레스 도입은 선택이 아닌 필수라고 말씀드리고 싶어요.
인그레스는 그 자체로 트래픽을 전달하는 장치가 아니에요. 인그레스는 ‘규칙(Rule)’을 정의하는 리소스일 뿐이며, 실제로 그 규칙을 읽어서 트래픽을 넘겨주는 실체는 ‘인그레스 컨트롤러’라는 별도의 소프트웨어예요. 이 차이를 명확히 이해하는 것이 첫걸음이에요.
실전 인그레스 구축 및 운영 단계별 가이드
이제 본격적으로 저희 팀이 인그레스를 어떻게 구축하고 운영했는지 그 과정을 단계별로 자세히 설명해 드릴게요. 이 과정은 단순히 기술적인 설정법을 나열하는 것이 아니라, 실제 서비스 환경에서 고려해야 했던 의사결정의 흐름을 담고 있어요.
STEP 1. Nginx 인그레스 컨트롤러 설치와 기본 구성
저희는 가장 많은 레퍼런스를 보유한 Nginx 인그레스 컨트롤러를 선택했어요. 설치는 클라우드 환경의 복잡성을 피하기 위해 Helm을 사용했어요. Helm을 사용하면 복잡한 설정값들을 차트(Chart)라는 단위로 관리할 수 있어서 매우 편리하거든요. 설치할 때 가장 신경 썼던 부분은 컨트롤러가 사용할 리소스의 제한(Resource Limits)을 설정하는 것이었어요. 컨트롤러가 클러스터의 자원을 독점하다가 다른 핵심 서비스에 영향을 주면 안 되기 때문이죠.
설치 직후에는 반드시 컨트롤러가 정상적으로 실행 중인지, 그리고 클라우드에서 제공하는 로드밸런서와 잘 연결되었는지 확인해야 해요. 보통 `kubectl get svc -n ingress-nginx` 명령어를 통해 외부 IP가 할당되었는지 체크하는 것으로 시작해요. 이때 할당된 IP가 우리가 서비스할 도메인과 연결될 준비가 되었는지 확인하는 과정이 꼭 필요해요.
STEP 2. 호스트 및 경로 기반의 정교한 라우팅 설정
컨트롤러가 준비되었다면 이제 실제 서비스들을 연결할 차례예요. 인그레스의 진가는 바로 L7 라우팅에서 나타나요. 저희는 하나의 도메인을 사용하면서도 경로(Path)에 따라 다른 마이크로서비스로 연결하는 방식을 채택했어요.
예를 들어, `example.com/api`로 들어오는 요청은 결제 서비스로, `example.com/web`으로 들어오는 요청은 프론트엔드 서비스로 보내는 식이죠. 이때 주의할 점은 경로 매칭 방식이에요. Nginx 인그레스에서는 `Prefix` 매칭과 `Exact` 매칭을 구분해서 사용해야 하는데, 이 설정을 잘못하면 의도치 않은 경로로 트래픽이 흘러가서 404 오류를 유발할 수 있어요. 저희 팀은 초기 설정 시 `/api`와 `/api/` 사이의 슬래시 유무로 인해 요청이 누락되는 문제를 겪기도 했답니다.
또한, 호스트 기반 라우팅을 통해 `api.example.com`과 `admin.example.com`처럼 완전히 다른 도메인을 하나의 인그레스 컨트롤러로 관리할 수도 있어요. 이렇게 하면 도메인이 늘어나도 비용은 거의 늘어나지 않으면서도 깔끔하게 관리가 가능해져요.
STEP 3. Cert-manager를 이용한 SSL/TLS 자동화
현대 웹 서비스에서 HTTPS 적용은 선택이 아닌 필수예요. 하지만 수십 개의 서비스에 일일이 인증서를 발급하고 갱신하는 작업은 운영팀에게는 재앙과도 같죠. 저희는 이 문제를 해결하기 위해 Cert-manager를 도입했어요. Cert-manager는 Let’s Encrypt와 같은 인증 기관과 연동하여 인증서 발급부터 갱신까지의 전 과정을 자동화해 줘요.
인그레스 설정 파일에 간단한 어노테이션(Annotation)만 추가하면, Cert-manager가 이를 감지하고 자동으로 인증서를 생성하여 시크릿(Secret)으로 저장해 줘요. 인그레스 리소스에서는 이 시크릿을 참조하기만 하면 끝이죠. 이 시스템을 구축하고 나서는 인증서 만료로 인해 서비스가 중단될 걱정을 완전히 덜 수 있었어요. 다만, 처음 구축할 때 DNS-01 챌린지 방식을 사용할지, HTTP-01 챌린지 방식을 사용할지 결정하는 과정이 필요해요. 저희는 자동화가 간편한 HTTP-01 방식을 선택했어요.
STEP 4. 카나리(Canary) 배포를 통한 안정적인 트래픽 제어
새로운 버전의 서비스를 배포할 때 모든 사용자에게 한 번에 공개하는 것은 매우 위험해요. 저희는 인그레스의 카나리 배포 기능을 활용해 위험을 최소화했어요. Nginx 인그레스는 특정 비율의 트래픽만 새로운 버전의 서비스로 보내는 기능을 어노테이션을 통해 아주 쉽게 지원해요.
예를 들어, 기존 버전(v1)이 운영 중인 상태에서 새로운 버전(v2)을 배포하고, 인그레스 설정에 `nginx.ingress.kubernetes.io/canary: “true”`와 `nginx.ingress.kubernetes.io/canary-weight: “10”`이라는 설정을 추가하면 전체 트래픽의 10%만 v2로 흘러가게 돼요. 이 10%의 사용자 데이터와 에러 로그를 모니터링하며 문제가 없다고 판단되면 서서히 비중을 높여가는 방식이죠. 이 기능을 통해 저희는 배포 시 발생하는 심리적 압박감을 획기적으로 줄일 수 있었어요.
STEP 5. 프로메테우스 연동을 통한 가시성 확보
마지막으로, 인그레스가 트래픽을 잘 처리하고 있는지 눈으로 확인해야 해요. 컨트롤러 자체에서 제공하는 메트릭을 프로메테우스로 수집하고, 그라파나(Grafana) 대시보드로 시각화하는 작업을 진행했어요. 요청 수, 응답 시간(Latency), 4xx/5xx 에러 발생률 등을 실시간으로 모니터링함으로써, 특정 서비스에 트래픽이 몰리거나 갑작스러운 에러가 발생할 때 즉시 인지하고 대응할 수 있는 체계를 갖췄어요.
인그레스 컨트롤러는 클러스터의 단일 장애점(SPOF)이 될 수 있어요. 컨트롤러가 죽으면 모든 서비스의 외부 접근이 차단됩니다. 따라서 반드시 컨트롤러를 고가용성(HA) 구성으로 배치하고, 리소스 관리를 철저히 해야 해요.
이처럼 인그레스는 단순한 라우팅 도구를 넘어, 서비스의 안정성과 운영 효율성을 결정짓는 핵심 인프라예요. 단계별로 차근차근 구축해 나간다면 여러분의 클러스터 운영 환경도 훨씬 쾌적해질 거예요.
자주 하는 실수와 해결법 및 FAQ
실무에서 인그레스를 운영하다 보면 예상치 못한 변수들이 정말 많이 발생해요. 저희 팀이 겪었던 실질적인 사례들을 바탕으로, 여러분이 같은 실수를 반복하지 않도록 정리해 드릴게요.
자주 하는 실수와 해결법
❌ 서비스 경로 매칭 오류
왜 발생하는가: `/api` 경로로 설정했는데, 실제 요청은 `/api/v1`으로 오거나 슬래시(/) 하나 차이로 경로를 찾지 못하는 경우예요.
✅ 해결법: 인그레스의 `pathType`을 정확히 이해하고 사용하세요. 최근 쿠버네티스에서는 `ImplementationSpecific`, `Exact`, `Prefix` 세 가지를 제공하는데, 대부분의 경우 `Prefix`를 사용하되 경로 끝의 슬래시 처리에 주의해야 해요.
❌ 인증서(SSL) 적용 실패
왜 발생하는가: Cert-manager가 인증서를 발급받았음에도 인그레스에서 적용되지 않는 경우예요. 보통 인그레스 설정에 명시한 시크릿(Secret) 이름과 Cert-manager가 생성한 시크릿 이름이 다르기 때문에 발생해요.
✅ 해결법: `kubectl get secret` 명령어로 실제 생성된 인증서 이름이 무엇인지 확인하고, 인그레스 YAML 파일의 `tls.secretName` 부분과 일치시키세요.
❌ 어노테이션(Annotation) 오타
왜 발생하는가: Nginx 인그레스의 특수 기능을 쓰기 위해 어노테이션을 넣을 때, 키 값을 잘못 입력하면 아무런 효과가 나타나지 않아요.
✅ 해결법: 공식 문서를 옆에 띄워두고 복사해서 사용하세요. 특히 `nginx.ingress.kubernetes.io/` 접두사를 빼먹지 않았는지 꼭 확인해야 해요.
❌ 클래스(IngressClass) 미지정
왜 발생하는가: 클러스터에 여러 개의 인그레스 컨트롤러가 있을 때, 내가 만든 인그레스가 어떤 컨트롤러를 통해야 하는지 모르는 상황이에요.
✅ 해결법: 인그레스 설정에 `spec.ingressClassName: nginx`와 같이 사용할 클래스를 명시해 주세요.
❌ 대용량 파일 업로드 차단
왜 발생하는가: 기본 설정된 클라이언트 바디 크기 제한 때문에 큰 파일을 올릴 때 413 Request Entity Too Large 에러가 발생해요.
✅ 해결법: `nginx.ingress.kubernetes.io/proxy-body-size` 어노테이션을 사용해 허용 용량을 늘려주세요.
자주 묻는 질문
Q. 인그레스와 로드밸런서 서비스의 가장 큰 차이가 무엇인가요?
로드밸런서 서비스는 L4 계층에서 작동하며, IP 하나당 하나의 서비스만 연결하는 것이 일반적이에요. 반면 인그레스는 L7 계층에서 작동하여 하나의 IP(하나의 로드밸런서)로 여러 도메인과 경로를 세밀하게 분기할 수 있다는 점이 가장 큰 차이점이에요.
Q. Nginx 인그레스 컨트롤러 외에 다른 대안은 없나요?
가장 대표적인 대안은 Kong이나 Traefik이에요. Kong은 API 게이트웨이 기능이 매우 강력하고, Traefik은 설정이 유연하며 클라우드 네이티브 환경에 아주 최적화되어 있어요. 용도에 따라 선택하면 됩니다.
Q. SSL 인증서 갱신이 안 되면 어떻게 하나요?
가장 먼저 Cert-manager의 로그를 확인해 보세요. DNS 설정 문제나 Let’s Encrypt의 제한에 걸린 경우가 많아요. `kubectl describe certificate [인증서이름]` 명령어로 어떤 단계에서 멈춰 있는지 확인하는 것이 가장 빨라요.
Q. 인그레스 하나에 너무 많은 서비스를 넣어도 괜찮을까요?
물론 가능하지만, 컨트롤러 하나가 관리하는 규칙이 너무 많아지면 설정 변경 시 반영 속도가 느려질 수 있어요. 서비스 규모가 정말 커진다면 인그레스 컨트롤러 자체를 논리적으로 분리하는 것을 고려해 보세요.
Q. 카나리 배포 시 트래픽 비율을 어떻게 정하는 게 좋을까요?
처음에는 1%나 5%처럼 아주 작은 비율로 시작하는 걸 추천해요. 에러 로그나 모니터링 지표를 충분히 지켜본 뒤에 10%, 25%, 50% 식으로 단계적으로 올리는 것이 가장 안전해요.
지속 가능한 인그레스 운영을 위한 마무리
인그레스 도입은 단순히 기술적인 설정을 넘어, 우리 팀의 운영 비용을 줄이고 서비스의 안정성을 높이는 중요한 전환점이에요. 처음에는 설정 하나하나가 어렵고 복잡하게 느껴질 수 있지만, 한 번 제대로 구축해 놓으면 그 효율성은 상상 이상으로 커진답니다.
무엇보다 중요한 것은 가시성(Observability)을 확보하는 것이에요. 눈에 보이지 않는 트래픽은 제어할 수 없기 때문이죠. 모니터링 도구와 연동하여 언제든 트래픽의 흐름을 파악할 수 있는 환경을 만드는 데 공을 들여보세요.
- 비용 절감이 필요하다면 로드밸런서 대신 인그레스 도입을 검토하세요.
- Nginx 인그레스 컨트롤러는 가장 안정적이고 강력한 선택지예요.
- Cert-manager를 활용해 SSL 인증서 관리를 자동화하세요.
- 카나리 배포 기능을 통해 신규 버전 배포의 위험을 낮추세요.
- 모니터링 도구를 연동해 트래픽 상태를 실시간으로 관찰하세요.
오늘 바로 시작할 수 있는 다음 단계들을 제안해 드릴게요. 지금 당장 클러스터의 비용 청구서를 확인해 보고, 인그레스 도입이 필요한 시점인지 계산해 보세요. 만약 결정했다면, 테스트 환경에서 Nginx 컨트롤러를 Helm으로 설치하는 것부터 시작해 보시는 건 어떨까요? 직접 설정해 보면서 겪는 작은 오류들이 여러분을 진정한 전문가로 만들어 줄 거예요.
실습 환경에서 직접 적용해 보다가 막히는 부분이 있다면, 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하며 해결해 나가는 과정이 가장 큰 공부가 될 거예요!
함께 읽어보면 좋은 글: 쿠버네티스 인그레스 기본 개념 정리, 클러스터 구축 입문 가이드
