인그레스 운영 사례 분석: 왜 지금 도입을 고민해야 할까요
새로운 마이크로서비스를 배포할 때마다 클라우드 콘솔을 열어 LoadBalancer 타입의 서비스를 생성하고 계신가요? 서비스가 열 개, 스무 개로 늘어날수록 매달 청구되는 네트워크 비용 고지서를 보며 한숨을 내쉬는 개발자분들을 정말 많이 만났어요. 단순히 비용 문제뿐만 아니라, 서비스마다 각각 다른 공인 IP를 관리하고 DNS 설정을 반복하는 과정은 운영 팀에게 엄청난 피로감을 주곤 해요.
실제로 저희 팀이 처음 쿠버네티스를 도입했을 때는 모든 서비스에 개별적으로 로드밸런서를 붙여서 사용했어요. 초기에는 구조가 단순해서 문제가 없었지만, 트래픽이 늘어나고 도메인이 분리되면서 관리 포인트가 기하급수적으로 증가했죠. IP 주소 하나를 새로 할당받을 때마다 발생하는 비용과 설정 시간은 팀의 생산성을 갉아먹는 주범이었어요.
이런 혼란을 잠재우기 위해 도입한 것이 바로 인그레스(Ingress)예요. 인그레스는 클러스터 외부에서 내부 서비스로 들어오는 HTTP/HTTPS 요청을 하나로 묶어 효율적으로 전달해 주는 스마트한 입구 역할을 수행해요. 단 하나의 로드밸런서만 사용하여 수십 개의 서비스를 도메인이나 경로에 따라 나누어 전달할 수 있기 때문에 운영 효율성이 완전히 달라져요.
이 글에서는 단순히 이론적인 정의를 나열하는 대신, 저희가 직접 겪은 실제 인그레스 운영 사례를 중심으로 이야기를 풀어가려고 해요. 인그레스 도입 전 어떤 지옥 같은 상황이었는지, 그리고 도입 후에 무엇이 어떻게 바뀌었는지 생생하게 담았습니다.
인그레스는 단순한 리소스가 아니에요. 실제 트래픽을 처리하려면 반드시 Nginx나 HAProxy 같은 인그레스 컨트롤러(Ingress Controller)가 클러스터 내에 설치되어 있어야 작동해요.
이번 글을 통해 확인하실 수 있는 내용은 다음과 같아요.
- 인그레스 도입 전의 비효율적인 네트워크 구조와 비용 문제
- 실제 환경에 적용한 인그레스 구성 및 상세 설정 방법
- 도입 후 트래픽 관리와 비용 측면에서 나타난 변화
- 운영 중 마주쳤던 실수와 이를 해결한 실전 경험
사전 준비: 인그레스 도입 전 꼭 체크해야 할 것들
인그레스를 도입하기로 마음먹었다면, 무작정 YAML 파일을 작성하기 전에 우리 클러스터 환경이 준비되었는지 확인해야 해요. 인그레스는 마법의 도구가 아니라, 기존의 네트워크 구조를 재설계하는 과정이기 때문이에요. 준비 없이 도입했다가는 오히려 트래픽 경로가 꼬여 서비스 장애로 이어질 수 있어요.
반드시 갖춰야 할 전제 조건
가장 먼저 확인해야 할 것은 인그레스 컨트롤러의 선택이에요. 가장 대중적인 것은 Nginx Ingress Controller이지만, 최근에는 Traefik이나 Kong 같은 옵션도 많이 쓰여요. 서비스의 특성에 따라 어떤 컨트롤러가 적합할지 미리 고민해 두어야 해요. 또한, 도메인을 관리할 수 있는 DNS 권한과 SSL/TLS 인증서를 발급받을 수 있는 환경(예: Cert-manager 설정)이 준비되어 있어야 해요.
다음으로 고려해야 할 점은 현재 사용 중인 서비스의 프로토콜이에요. 인그레스는 기본적으로 HTTP와 HTTPS 프로토콜에 최적화되어 있어요. 만약 TCP나 UDP 기반의 특수한 프로토콜을 사용하는 서비스가 있다면, 인그레스만으로는 처리가 어려울 수 있으니 별도의 해결책을 찾아야 해요.
서비스 유형별 선택 기준 비교
우리가 기존에 사용하던 방식과 인그레스를 사용하는 방식 중 무엇이 유리할지 판단하는 기준을 표로 정리해 보았어요.
| 비교 항목 | Service (LoadBalancer) | Ingress 방식 |
|---|---|---|
| 비용 효율성 | 낮음 (서비스마다 IP 할당) | 높음 (공유 로드밸런서 사용) |
| 도메인 관리 | 복잡함 (각 IP마다 DNS 설정) | 간편함 (하나의 IP로 경로 분기) |
| SSL 인증서 적용 | 각 서비스마다 개별 적용 | 인그레스 계층에서 통합 관리 |
| 설정 난이도 | 매우 낮음 (단순함) | 보통 (컨트롤러 설정 필요) |
위 표를 보면 알 수 있듯이, 서비스의 개수가 적고 단순한 환경이라면 기존의 LoadBalancer 방식이 오히려 속 편할 수 있어요. 하지만 마이크로서비스 아키텍처(MSA)를 지향하며 서비스가 계속 늘어날 예정이라면, 인그레스 도입은 선택이 아닌 필수라고 말씀드리고 싶어요.
인그레스 컨트롤러 자체에 장애가 발생하면 클러스터 내의 모든 외부 트래픽이 끊길 수 있어요. 따라서 컨트롤러의 가용성을 높이기 위해 고가용성(HA) 구성을 반드시 고려해야 해요.
마지막으로 체크리스트를 확인해 보세요. 사용할 컨트롤러를 정했나요? 인증서 자동화 도구를 검토했나요? 트래픽 분산 규칙을 설계했나요? 이 질문들에 모두 답할 수 있다면 이제 본격적인 적용 단계로 넘어갈 준비가 된 거예요.
인그레스 적용기: 문제 해결부터 실제 구성까지
이제 저희 팀이 겪었던 실제 상황을 바탕으로 인그레스를 어떻게 적용했는지 단계별로 설명해 드릴게요. 단순히 코드를 복사해서 붙여넣는 것이 아니라, 어떤 고민을 거쳐 설정이 완성되었는지를 중점적으로 봐 주세요.
STEP 1. 기존 구조의 한계와 문제 상황 파악
저희는 이커머스 서비스를 운영하고 있었어요. 처음에는 프론트엔드, 주문, 상품, 유저라는 네 개의 핵심 서비스로 시작했죠. 초기에는 각 서비스마다 Service Type: LoadBalancer를 사용하여 외부로 노출했어요. 클라우드 환경에서 각 서비스는 고유한 공인 IP를 가졌고, 도메인 역시 order.example.com, product.example.com처럼 각각 따로 설정해야 했어요.
문제는 서비스가 늘어날수록 눈덩이처럼 불어나는 비용이었어요. 서비스 하나가 추가될 때마다 클라우드 업체에 지불해야 하는 로드밸런서 비용이 추가되었고, 운영팀은 매번 새로운 IP를 확인하고 DNS 레코드를 업데이트하는 단순 반복 작업에 시간을 뺏겼죠. 무엇보다 통합적인 트래픽 제어가 불가능하다는 점이 가장 뼈아팠어요. 특정 서비스에 갑자기 트래픽이 몰릴 때 전체적인 네트워크 흐름을 한눈에 파악하기가 매우 힘들었거든요.
STEP 2. Nginx Ingress Controller 도입 및 설치
저희는 수많은 대안 중 가장 커뮤니티가 활성화되어 있고 기능이 강력한 Nginx Ingress Controller를 선택했어요. 설치는 Helm을 사용하여 진행했는데요, 설정이 까다로운 편은 아니었지만 클러스터의 리소스를 사용하는 만큼 Resource Limit(CPU, Memory)을 사전에 정의하는 것이 중요했어요.
설치 직후, 하나의 공인 IP를 가진 거대한 입구가 만들어졌어요. 이제 모든 서비스는 이 단 하나의 IP를 통해 접근할 수 있게 되었죠. 이 단계에서 저희는 기존의 개별 로드밸런서들을 하나씩 제거하며 트래픽을 인그레스 쪽으로 점진적으로 옮기는 전략을 세웠어요. 한 번에 모든 것을 바꾸는 것은 너무 위험하니까요.
STEP 3. 경로(Path) 및 호스트(Host) 기반 라우팅 설정
인그레스의 진정한 매력은 바로 라우팅 규칙을 자유자재로 설정할 수 있다는 점이에요. 저희는 두 가지 방식을 혼합해서 사용했어요. 첫 번째는 호스트 기반 라우팅으로, 서비스의 성격에 따라 완전히 다른 도메인을 부여하는 방식이에요. 두 번째는 경로 기반 라우팅으로, 하나의 도메인 아래에서 URL 경로에 따라 서비스를 나누는 방식이죠.
예를 들어 다음과 같은 구조를 설계했어요.
- api.example.com → 주문 및 상품 API 서비스로 연결
- admin.example.com → 내부 관리자 페이지로 연결
- example.com/static/* → 정적 콘텐츠 서비스로 연결
이렇게 설정하면 사용자 입장에서는 하나의 웹사이트처럼 보이지만, 내부적으로는 트래픽이 각기 다른 마이크로서비스로 정확하게 배달되는 구조가 완성돼요. 설정 파일(YAML)을 작성할 때는 pathType을 지정할 때 주의해야 해요. Prefix를 사용할지, 아니면 정확히 일치하는 Exact를 사용할지에 따라 라우팅 결과가 완전히 달라지거든요. 저희는 대부분의 경우 하위 경로를 모두 포함하는 Prefix 방식을 선택했어요.
STEP 4. SSL/TLS 인증서 통합 관리와 보안 강화
서비스가 커지면서 모든 통신을 HTTPS로 암호화하는 것은 필수였어요. 예전에는 각 서비스마다 인증서를 관리하느라 번거로웠지만, 인그레스 도입 후에는 TLS Secret 하나만 잘 관리하면 돼요. 저희는 Cert-manager를 함께 사용하여 Let’s Encrypt 인증서를 자동으로 발급받고 갱신하도록 설정했어요.
인그레스 설정 파일에 tls 섹션을 추가하기만 하면, 인그레스 컨트롤러가 알아서 인증서를 적용하고 HTTPS 통신을 처리해 줘요. 백엔드 서비스들은 복잡한 인증서 로직을 신경 쓸 필요 없이 단순한 HTTP 통신만 하면 되기 때문에 개발 생산성도 크게 올라갔죠.
STEP 5. 어노테이션(Annotation)을 활용한 고급 트래픽 제어
마지막으로 인그레스의 꽃이라고 할 수 있는 Annotation 활용법이에요. Nginx Ingress Controller는 수많은 어노테이션을 제공하는데, 이를 통해 서버 설정을 코드 수준에서 제어할 수 있어요. 저희가 실무에서 가장 유용하게 썼던 기능들을 정리해 드릴게요.
- client-max-body-size: 이미지 업로드가 많은 서비스에서 파일 용량 제한을 늘릴 때 필수예요. 기본값이 너무 작으면 413 Error가 발생하거든요.
- proxy-connect-timeout: 백엔드 서비스의 응답이 다소 느린 경우, 연결 끊김을 방지하기 위해 타임아웃 시간을 조정할 때 사용해요.
- enable-cors: 서로 다른 도메인 간에 API 호출이 필요한 경우, CORS 설정을 인그레스 계층에서 한 번에 처리할 수 있어요.
이런 설정들을 통해 인프라 엔지니어가 직접 애플리케이션 코드의 수정 없이도 네트워크 환경을 유연하게 튜닝할 수 있게 되었어요. 마치 전문적인 네트워크 장비를 소프트웨어로 다루는 듯한 경험을 할 수 있었죠.
인그레스 설정 변경 후에는 반드시 kubectl describe ingress 명령어로 설정이 의도한 대로 반영되었는지, 이벤트 로그에 오류는 없는지 확인하는 습관을 가져야 해요.
자주 하는 실수와 해결법 + FAQ
인그레스를 운영하다 보면 이론과는 다른 예상치 못한 변수들을 마주하게 돼요. 저희 팀이 실제로 겪었던 당황스러운 순간들과 그 해결책을 공유할게요.
자주 하는 실수와 해결법
❌ 경로 매칭 오류 (Trailing Slash 문제)
사용자가 /api로 요청했는데 서버는 /api/ 형태의 경로만 기다리는 경우예요. 이로 인해 404 Not Found가 빈번하게 발생하곤 해요.
✅ 해결법: rewrite-target 어노테이션을 사용하여 인그레스가 요청을 받은 뒤 백엔드 서비스로 전달할 때 경로를 자동으로 재작성하도록 설정하세요.
❌ 업로드 용량 제한 (413 Request Entity Too Large)
이미지나 대용량 파일을 업로드할 때 갑자기 에러가 발생하는 경우예요. Nginx의 기본 설정이 너무 작아서 발생하는 문제죠.
✅ 해결법: 인그레스 리소스에 nginx.ingress.kubernetes.io/proxy-body-size 어노테이션을 추가하여 허용 용량을 늘려주세요.
❌ SSL 인증서 적용 실패
HTTPS로 접속했는데 ‘연결이 비공개로 설정되어 있지 않습니다’라는 경고가 뜨는 상황이에요. 주로 Secret 이름이 틀렸거나 인증서가 만료되었을 때 발생해요.
✅ 해결법: kubectl get secret 명령어로 인증서가 정상적으로 존재하는지 확인하고, 인그레스 설정의 tls.secretName과 일치하는지 대조해 보세요.
❌ 백엔드 타임아웃 (504 Gateway Timeout)
데이터 처리가 오래 걸리는 API 요청이 중간에 끊기는 현상이에요.
✅ 해결법: proxy-read-timeout과 proxy-send-timeout 어노테이션 값을 서비스의 처리 시간에 맞춰 충분히 늘려주어야 해요.
❌ 인그레스 컨트롤러 자원 부족
트래픽이 급증할 때 인그레스 자체가 응답을 못 하는 상황이에요.
✅ 해결법: 컨트롤러 Pod에 할당된 CPU와 Memory의 Resource Limit을 상향하고, HPA(Horizontal Pod Autoscaler)를 설정하여 트래픽에 따라 컨트롤러 개수가 자동으로 늘어나도록 구성하세요.
자주 묻는 질문
Q. 인그레스와 로드밸런서 서비스(Type: LoadBalancer)의 차이점은 무엇인가요?
로드밸런서 서비스는 클라우드 업체가 제공하는 실제 물리적(또는 가상) 로드밸런서를 직접 하나씩 생성하는 방식이고, 인그레스는 하나의 로드밸런서 뒤에 소프트웨어(컨트롤러)를 두어 경로에 따라 트래픽을 나누는 방식이에요. 비용과 관리 효율성 면에서 인그레스가 훨씬 유리해요.
Q. Nginx 인그레스 컨트롤러 말고 다른 건 안 쓰나요?
물론이에요. 트래픽이 매우 복잡하거나 서비스 메쉬(Service Mesh) 기능이 필요하다면 Istio나 Linkerd를 고려할 수 있고, 가볍고 설정이 쉬운 것을 원한다면 Traefik도 아주 좋은 선택지예요.
Q. 인그레스 하나에 여러 개의 SSL 인증서를 넣을 수 있나요?
네, 가능해요. 인그레스 설정의 tls 배열 안에 여러 개의 호스트와 각각의 Secret을 정의하면, 도메인에 맞는 인증서를 자동으로 골라서 적용해 줘요.
Q. 인그레스 도입 시 보안상 주의할 점은 무엇인가요?
인그레스가 모든 트래픽의 관문이기 때문에, 컨트롤러 자체가 공격 대상이 될 수 있어요. 따라서 컨트롤러에 대한 네트워크 정책(Network Policy)을 설정하여 접근을 제한하고, 항상 최신 보안 패치가 적용된 버전을 사용해야 해요.
Q. 경로 기반 라우팅을 쓸 때 주의할 점이 있나요?
경로의 우선순위가 중요해요. 예를 들어 /api/user와 /api가 있을 때, 어떤 규칙이 먼저 적용될지 명확히 알고 있어야 해요. 일반적으로 더 구체적인 경로가 우선권을 갖지만, 설정 실수로 의도치 않은 서비스로 연결되는 경우가 많으니 테스트가 필수예요.
마치며: 안정적인 운영을 위한 다음 단계
지금까지 인그레스 운영 사례를 통해 실제 서비스에 어떻게 적용하고, 어떤 문제를 해결했는지 살펴보았어요. 인그레스는 단순히 비용을 아끼는 도구를 넘어, 복잡한 마이크로서비스 환경을 질서 있게 만들어주는 네트워크의 지휘자 역할을 해요.
- 서비스가 늘어나면 LoadBalancer 대신 인그레스를 도입하여 비용을 절감하세요.
- Nginx 인gress Controller는 가장 검증된 선택지 중 하나입니다.
- 호스트 기반과 경로 기반 라우팅을 적절히 혼합하여 설계하세요.
- SSL 인증서는 Cert-manager를 통해 자동화하는 것이 운영상 매우 편리해요.
- 어노테이션을 적극 활용하여 타임아웃과 업로드 용량 문제를 해결하세요.
- 인그레스 컨트롤러 자체의 가용성과 자원 관리에 신경 써야 합니다.
오늘 바로 실행해 볼 수 있는 단계들을 제안해 드릴게요. 우선 현재 운영 중인 클러스터에서 LoadBalancer 타입의 서비스 중 통합 가능한 것이 있는지 리스트를 만들어 보세요. 그 다음, 테스트 환경에 Nginx 인그레스 컨트롤러를 설치하고 간단한 경로 기반 라우팅을 직접 구현해 보는 것부터 시작해 보세요.
실습 환경에서 직접 적용해 보시다가 설정이 꼬이거나 이해가 안 되는 부분이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하고 답을 찾아가겠습니다!
관련해서 더 깊이 있는 내용이 궁금하시다면 아래 글들도 함께 읽어보시는 것을 추천해요.
- 쿠버네티스 인그레스 기본 개념 완벽 정리
- 클러스터 구축 입문: 첫 번째 노드 띄우기
