인그레스 운영 사례: 왜 지금 도입을 고민해야 할까요?
클러스터 내부에 마이크로서비스가 10개, 20개로 늘어나기 시작하면 갑자기 머리가 아파오는 순간이 찾아와요. 예전에는 각 서비스마다 LoadBalancer 타입의 서비스를 하나씩 생성해서 외부로 노출하면 그만이었죠. 하지만 서비스가 늘어날수록 클라우드 비용은 기하급수적으로 치솟고, 관리해야 할 엔드포인트 주소는 통제 불능 상태가 되었어요.
어느 날 갑자기 운영 팀에서 “외부 접속 주소를 하나로 통합할 수 없나요?”라는 요청을 받았을 때, 그 막막함은 이루 말할 수 없었답니다. 단순히 주소를 합치는 문제가 아니라, 각 요청이 어떤 서비스로 가야 하는지 결정하는 라우팅 규칙과 보안 인증서 관리까지 한꺼번에 해결해야 했거든요. 이런 복잡한 상황을 해결하지 못하면 클러스터 운영 비용은 물론 운영팀의 업무 부하도 감당할 수 없는 수준에 이르게 돼요.
그래서 많은 팀이 인그레스(Ingress) 도입을 결정하지만, 막상 설정하려고 하면 경로 매칭 문제나 인증서 적용 오류 때문에 며칠 밤을 지새우기도 해요. 인그레스는 단순히 문을 열어주는 도구가 아니라, 클러스터의 입구를 지키는 아주 똑똑한 안내 데스크와 같기 때문이에요.
이번 글에서는 제가 실제 서비스 환경에서 겪었던 인그레스 운영 사례를 바탕으로, 도입 전의 문제점부터 실제 적용 과정, 그리고 운영 중에 마주친 뼈아픈 실수들을 아주 상세하게 공유해 드릴게요. 이 글을 끝까지 읽고 나면 다음과 같은 내용을 확실히 얻어 가실 수 있어요.
- 기존 서비스 노출 방식의 한계와 인그레스 도입의 필요성
- 실제 운영 환경에서 사용하는 인그레스 컨트롤러 구성 전략
- 도메인 기반과 경로 기반 라우팅을 설정하는 구체적인 방법
- 운영 중 자주 발생하는 트러블슈팅 사례와 해결책
사전 준비: 인그레스 도입 전 반드시 알아야 할 것들
인그레스를 설치하기 전에 가장 먼저 해야 할 일은 현재 우리 서비스가 외부와 어떻게 통신하고 있는지를 냉정하게 분석하는 일이에요. 무턱대고 인그레스 컨트롤러부터 설치한다고 해서 모든 문제가 해결되지는 않거든요. 먼저 인그레스 컨트롤러(Ingress Controller)와 인그레스 리소스(Ingress Resource)의 차이를 명확히 이해해야 해요. 컨트롤러는 실제 요청을 처리하는 엔진이고, 리소스는 어떤 요청을 어디로 보낼지 적어둔 규칙서라고 생각하면 쉬워요.
또한, 어떤 컨트롤러를 선택할지도 매우 중요한 결정 사항이에요. 가장 대중적인 것은 NGINX Ingress Controller이지만, 서비스의 규모나 요구되는 특수 기능에 따라 Kong이나 Traefik이 더 나은 선택지가 될 수도 있답니다. 각 도구마다 제공하는 기능과 리소스 소모량이 다르기 때문에 우리 팀의 상황에 맞게 골라야 해요.
인그레스는 L7(Application Layer) 계층에서 동작해요. 즉, HTTP 헤더, 경로, 호스트 이름을 보고 요청을 분류할 수 있다는 뜻이죠. 반면 서비스의 LoadBalancer는 보통 L4 계층에서 동작한다는 점을 기억하세요.
도입을 결정했다면 아래 표를 참고해서 현재 우리 팀이 처한 상황이 어떤 노출 방식에 적합한지 판단해 보세요.
| 노출 방식 | 주요 특징 | 장점 | 단점 |
|---|---|---|---|
| NodePort | 모든 노드의 특정 포트를 개방 | 설정이 매우 단순함 | 포트 범위 제한, 보안 취약 |
| LoadBalancer | 클라우드 제공 LB 사용 | 관리 부담이 적음 | 서비스당 비용 발생, 관리 복잡 |
| Ingress | L7 규칙 기반 라우팅 | 비용 절감, 경로 제어 유연함 | 컨트롤러 관리 필요, 설정 복잡 |
만약 서비스 개수가 5개 미만이라면 굳이 인그레스를 도입하지 않고 LoadBalancer를 쓰는 게 더 편할 수도 있어요. 하지만 서비스가 늘어나면서 비용이 부담되거나, 하나의 도메인 아래에서 여러 경로(path)를 사용해야 한다면 인그레스 도입은 선택이 아닌 필수 단계예요.
핵심 본문: 단계별 인그레스 구축 및 운영 실전
실제 운영 환경에서는 단순히 명령어를 입력하는 것보다, 어떤 아키텍처로 구성할지가 훨씬 중요해요. 제가 경험했던 이커머스 플랫폼의 구축 사례를 바탕으로 5단계의 프로세스를 상세히 설명해 드릴게요.
STEP 1. 서비스 구조 분석과 라우팅 전략 수립
가장 먼저 해야 할 일은 외부에서 들어오는 요청이 어떤 패턴을 보이는지 파악하는 거예요. 저희 팀은 크게 세 가지 유형의 트래픽을 처리해야 했어요. 첫째는 사용자 화면을 보여주는 웹 서비스, 둘째는 데이터를 처리하는 API 서비스, 셋째는 관리자 전용 페이지였죠. 이를 위해 호스트 기반(Host-based)과 경로 기반(Path-based) 라우팅을 혼합하여 사용하기로 결정했어요.
예를 들어, api.example.com은 API 서버로, example.com/static은 정적 파일 서버로 보내는 식이죠. 이렇게 전략을 미리 세우지 않으면 나중에 경로가 겹치거나 우선순위 문제로 인해 요청이 엉뚱한 곳으로 튀는 대참사가 일어날 수 있어요. 설계 단계에서 각 경로의 우선순위를 명확히 정의하는 것이 성공의 핵심이에요.
STEP 2. NGINX Ingress Controller 설치 및 최적화
전략을 세웠다면 이제 실제 엔진을 설치해야 해요. 저희는 가장 검증된 NGINX Ingress Controller를 선택했어요. 설치할 때는 Helm 차트를 사용하는 것이 가장 깔끔하고 관리하기 편해요. 하지만 단순히 설치만 한다고 끝이 아니에요. 실제 트래픽을 견디기 위해서는 리소스 제한(Resource Limits)과 HPA(Horizontal Pod Autoscaler) 설정이 반드시 병행되어야 해요.
인그레스 컨트롤러는 모든 트래픽이 통과하는 병목 지점이 될 수 있거든요. 컨트롤러의 CPU나 메모리가 부족해지면 클러스터 전체 서비스가 마비될 수 있어요. 그래서 저희는 트래픽 급증을 대비해 컨트롤러 자체의 복제본(Replica) 수를 유동적으로 늘릴 수 있도록 설정했어요. 또한, 대용량 파일 업로드가 필요한 서비스를 위해 client-max-body-size 같은 어노테이션(Annotation) 값을 미리 조정해 두는 작업도 잊지 않았답니다.
STEP 3. 도메인 및 경로 규칙(Ingress Resource) 적용
이제 실제로 규칙서를 작성할 차례예요. 이 단계가 실무에서 가장 많은 시간이 소요되는 부분 중 하나죠. 저희는 다음과 같은 시나리오로 규칙을 구성했어요.
1. 메인 웹 서비스: example.com으로 들어오는 모든 요청을 웹 프론트엔드 서비스로 전달.
2. API 서비스: example.com/api 경로로 들어오는 요청을 백엔드 API 서비스로 전달.
3. 관리자 페이지: admin.example.com이라는 별도 서브도메인을 사용하여 관리자 서비스로 전달.
여기서 아주 중요한 주의점이 있어요. 경로를 설정할 때 끝에 슬래시(/)를 붙일지 말지에 따라 매칭 결과가 완전히 달라져요. 예를 들어, /api와 /api/는 서로 다르게 동작할 수 있으므로, 서비스가 기대하는 경로 형식을 반드시 확인하고 규칙을 작성해야 해요. 저희 팀도 초기에 이 문제 때문에 API 호출이 404 오류를 뱉는 바람에 한 시간을 허비한 적이 있답니다.
STEP 4. SSL/TLS 인증서 자동화와 보안 강화
운영 환경에서 HTTPS 적용은 이제 선택이 아닌 필수예요. 하지만 모든 도메인마다 인증서를 수동으로 발급받고 업데이트하는 것은 불가능에 가깝죠. 그래서 저희는 Cert-manager을 도입하여 Let’s Encrypt 인증서를 자동으로 발급하고 갱신하는 체계를 구축했어요.
인그레스 리소스에 tls 섹션을 추가하고, Cert-manager가 생성한 Secret 이름을 지정하기만 하면 끝나요. 이렇게 하면 인증서 만료로 인해 사이트 접속이 차단되는 불상사를 원천적으로 차단할 수 있어요. 보안을 위해 HTTP 요청을 HTTPS로 강제 리다이렉트하는 설정도 어노테이션을 통해 반드시 적용해야 해요.
STEP 5. 모니터링 및 트래픽 관찰
모든 설정이 끝났다면 이제 실제로 트래픽이 잘 흐르는지 감시해야 해요. 저희는 Prometheus와 Grafana를 연동하여 인그레스 컨트롤러의 메트릭을 실시간으로 관찰했어요. 초당 요청 수(RPS), 응답 지연 시간(Latency), 4xx/5xx 에러율 등을 대시보드로 구성했죠.
특히 5xx 에러가 갑자기 튀어 오를 때, 그것이 백엔드 서비스의 문제인지 아니면 인그레스 컨트롤러의 설정 문제인지를 빠르게 판단하는 것이 운영의 핵심이에요. 예를 들어, 특정 경로에서만 에러가 발생한다면 인그레스 규칙의 매칭 오류일 가능성이 높고, 모든 경로에서 에러가 발생한다면 컨트롤러 자체의 리소스 부족이나 네트워크 문제를 의심해 볼 수 있어요. 이러한 모니터링 체계가 갖춰져야 진정한 의미의 운영이 시작된다고 할 수 있어요.
인그레스 설정을 변경할 때는 반드시 스테이징 환경에서 먼저 테스트하세요. 작은 오타 하나가 서비스 전체의 입구를 막아버릴 수 있습니다.
자주 하는 실수와 해결법
인그레스를 운영하다 보면 누구나 한 번쯤은 당황스러운 상황을 마주하게 돼요. 제가 직접 겪고 팀원들이 자주 실수했던 사례들을 정리해 드릴게요.
- ❌ 실수: 경로 매칭 오류로 인해 404 에러 발생
→ 왜 발생하는가:/api와/api/사이의 슬래시 유무 차이 혹은 정규표현식 설정 미흡
✅ 해결법: Ingress의 pathType을 Prefix로 설정하고, 서비스 애플리케이션이 기대하는 베이스 경로를 정확히 일치시키세요. - ❌ 실수: 대용량 파일 업로드 시 413 Request Entity Too Large 발생
→ 왜 발생하는가: NGINX의 기본 업로드 제한 용량이 너무 작게 설정되어 있음
✅ 해결법: Ingress 리소스의 어노테이션에nginx.ingress.kubernetes.io/proxy-body-size값을 적절하게 늘려주세요. - ❌ 실수: 인증서 적용 후에도 “연결이 안전하지 않음” 메시지 출력
→ 왜 발생하는가: TLS Secret 이름이 잘못되었거나, Ingress 리소스의 TLS 섹션 설정 누락
✅ 해결법: Cert-manager가 생성한 Secret이 존재하는지 확인하고, Ingress 설정 내 tls: 항목에 해당 Secret 이름을 정확히 기입하세요. - ❌ 실수: 인그레스 컨트롤러의 리소스 부족으로 인한 전체 장애
→ 왜 발생하는가: 트래픽 급증 시 컨트롤러 파드의 CPU/메모리가 고갈됨
✅ 해결법: 컨트롤러에 Resource Requests/Limits를 명시하고, HPA를 통해 파드 수를 자동으로 조절하도록 구성하세요. - ❌ 실수: 특정 호스트에 대해 리다이렉트가 작동하지 않음
→ 왜 발생하는가: SSL On 어노테이션이 누락되었거나 기존 HTTP 설정과 충돌함
✅ 해결법:nginx.ingress.kubernetes.io/ssl-redirect: "true"어노테이션을 사용하여 명시적으로 설정하세요.
자주 묻는 질문
Q. 인그레스와 API 게이트웨이는 무엇이 다른가요?
인그레스는 쿠버네티스 클러스터로 들어오는 HTTP/HTTPS 트래픽의 진입로를 관리하는 비교적 가벼운 기능이에요. 반면 API 게이트웨이는 인증, 인가, 속도 제한(Rate Limiting), 요청 변환 등 훨씬 더 복잡하고 정교한 비즈니스 로직을 처리하는 데 특화되어 있어요. 단순 라우팅이 목적이라면 인그레스가 훨씬 경제적이고 효율적이에요.
Q. 서비스가 너무 많은데 인그레스 하나로 다 감당할 수 있을까요?
이론적으로는 가능하지만, 인그레스 컨트롤러 하나에 너무 많은 규칙이 몰리면 설정 파일이 무거워지고 성능 저하가 발생할 수 있어요. 서비스의 성격이 완전히 다르다면(예: 외부 사용자용 vs 내부 관리용), 인그레스 컨트롤러를 물리적으로 분리하여 운영하는 것이 성능과 보안 측면에서 훨씬 유리해요.
Q. 도메인을 여러 개 써야 하는데 설정이 복잡하지 않나요?
전혀 그렇지 않아요. 인그레스 리소스 내의 tls 항목과 rules 항목에 각각 다른 호스트 이름을 적어주기만 하면 됩니다. Cert-manager를 함께 사용하면 도메인이 늘어나도 인증서 관리는 자동으로 처리되니 걱정하지 않으셔도 돼요.
Q. 인그레스 컨트롤러를 교체하고 싶을 때는 어떻게 하나요?
새로운 컨트롤러를 설치한 뒤, 기존 인그레스 리소스의 설정들을 새 컨트롤러의 어노테이션 규격에 맞춰 업데이트해야 해요. 컨트롤러마다 사용하는 어노테이션 형식이 다르기 때문에 이 작업은 반드시 테스트 환경에서 검증을 마친 후 진행해야 합니다.
인그레스 운영을 위한 최종 점검
인그레스 도입은 단순히 기술적인 변화를 넘어, 서비스의 확장성과 비용 효율성을 결정짓는 중요한 전환점이에요. 처음에는 설정 하나하나가 어렵게 느껴지겠지만, 체계적인 전략을 가지고 접근한다면 클러스터 운영의 난이도를 획기적으로 낮출 수 있답니다.
- 서비스 노출 방식(NodePort, LB, Ingress)의 비용과 관리 효율을 비교할 것
- 라우팅 규칙(호스트/경로) 설계 시 슬래시(/) 처리에 주의할 것
- NGINX 컨트롤러의 리소스 제한과 오토스케일링을 반드시 설정할 것
- Cert-manager를 활용해 SSL/TLS 인증서를 자동화할 것
- 모니터링을 통해 트래픽 패턴과 에러율을 상시 관찰할 것
오늘 내용을 바탕으로 바로 실행에 옮겨보시는 건 어떨까요? 당장 모든 것을 바꿀 필요는 없어요. 작은 테스트 환경에서 인그레스 규칙 하나를 만들어보는 것부터 시작해 보세요.
🚀 지금 바로 실행해 보세요
- 오늘 할 일: 현재 운영 중인 서비스의 외부 노출 방식과 월간 클라우드 LB 비용 계산해 보기
- 이번 주 할 일: 스테이징 클러스터에 NGINX Ingress Controller 설치하고 간단한 경로 테스트하기
- 실행 직전 할 일: 도메인 연결을 위한 DNS 설정과 SSL 인증서 자동화 시나리오 검토하기
실습 환경에서 직접 적용해 보시고, 설정 과정에서 예상치 못한 에러가 발생하거나 막히는 부분이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하며 해결해 나가는 과정이 가장 큰 공부가 된답니다. 여러분의 안정적인 클러스터 운영을 응원해요!
함께 읽으면 좋은 글:
• 쿠버네티스 인그레스 기본 개념 글
• 클러스터 구축 입문 글
