[IT-정보] 인그레스 운영 사례 분석: 실제 서비스 적용기와 개선 포인트 – 실무에서 겪은 트래픽 관리와 설정 노하우

인그레스 운영 사례 분석: 왜 도입이 시급했을까요

매달 날아오는 클라우드 비용 청구서를 보며 뒷목을 잡았던 기억이 있어요. 마이크로서비스 아키텍처(MSA)를 도입하면서 서비스가 30개로 늘어났는데, 각 서비스마다 LoadBalancer 타입의 서비스를 하나씩 생성했거든요. 클라우드 공급자가 제공하는 로드밸런서는 편리하지만, 서비스 개수만큼 비용이 정비례해서 늘어나는 구조였어요.

단순히 비용 문제만 있었던 것은 아니에요. 각 로드밸런서마다 별도의 공인 IP를 할당받아야 했고, SSL 인증서 적용이나 경로 기반 라우팅을 설정할 때마다 관리 포인트가 기하급수적으로 늘어났어요. 개발팀은 새로운 서비스를 배포할 때마다 인프라 팀에 로드밸런서 생성을 요청해야 했고, 이 과정에서 발생하는 병목 현상은 서비스 출시 속도를 늦추는 주범이 되었어요.

결국 우리는 하나의 진입점을 만들고, 그 안에서 똑똑하게 트래픽을 분산해 줄 인그레스(Ingress) 도입을 결정했어요. 이번 글에서는 실제 운영 환경에서 인그레스를 어떻게 구성했고, 어떤 기술적 난관을 극복하며 최적화했는지 그 생생한 과정을 공유하려고 해요.

이 글을 끝까지 읽고 나면 다음 내용을 확실히 이해하실 수 있어요.

• 기존 로드밸런서 방식과 인그레스 방식의 결정적인 차이점
• 실무에서 바로 쓰는 인그레스 컨트롤러 선택 기준
• SSL 인증서 자동화와 경로 기반 라우팅 설정 방법
• 운영 중 마주치는 흔한 오류와 해결 노하우

사전 준비: 인그레스 도입 전 체크리스트

인그레스를 무턱대고 설치한다고 모든 문제가 해결되지는 않아요. 우리 서비스의 트래픽 특성과 관리 가능한 예산, 그리고 운영 팀의 숙련도를 먼저 따져봐야 해요. 단순히 기능을 구현하는 것을 넘어, 유지보수가 가능한 구조인지 판단하는 것이 핵심이에요.

먼저 우리가 사용 중인 서비스가 어떤 방식으로 외부와 통신하고 있는지 파악해야 해요. 기존에 사용하던 NodePort 방식은 보안상 취약하고 포트 관리가 어렵다는 단점이 있고, LoadBalancer 방식은 비용 효율성이 낮다는 문제가 있어요. 인그레스는 이 사이에서 효율적인 ‘교통 정리원’ 역할을 수행하게 됩니다.

도입을 결정하기 전에 아래 비교 표를 통해 현재 상황과 비교해 보세요. 우리 팀에 어떤 방식이 가장 적합한지 판단하는 기준이 될 거예요.

준비 단계에서 가장 중요한 것은 현재 트래픽 패턴을 데이터로 증명하는 것이에요. 단순히 “비용이 많이 들 것 같아요”라는 추측보다는, “현재 50개의 서비스에 대해 50개의 로드밸런서를 사용 중이며, 이로 인해 매달 OO달러의 추가 비용이 발생하고 있습니다”라고 수치로 말해야 의사결정권자를 설득할 수 있어요. 또한, 인그레스 도입 시 발생할 수 있는 단일 장애점(SPOF) 문제를 해결하기 위해 컨트롤러의 고가용성(HA) 구성 계획도 미리 세워두어야 합니다.

인그레스 실전 적용: 구성부터 최적화까지

준비가 끝났다면 이제 실제 클러스터에 인그레스를 심을 차례예요. 저희는 수많은 선택지 중에서 가장 안정적이고 레퍼런스가 풍부한 Nginx Ingress Controller를 선택했어요. 설치부터 운영 최적화까지의 과정을 5단계로 나누어 설명해 드릴게요.

STEP 1. 인그레스 컨트롤러 설치 및 초기 환경 구축

가장 먼저 Helm을 사용하여 Nginx Ingress Controller를 설치했어요. 단순히 명령어를 입력하는 것이 아니라, 운영 환경에 맞게 가용성을 고려한 설정을 추가하는 것이 중요해요. 저희는 클라우드 환경의 로드밸런서와 연동될 수 있도록 Service Type을 LoadBalancer로 설정하여 컨트롤러 자체를 외부로 노출시켰어요.

이 단계에서 주의할 점은 컨트롤러가 돌아가는 Pod의 리소스 제한을 명확히 하는 것이에요. 인그레스 컨트롤러는 클러스터의 모든 외부 트래픽을 처리하는 관문이기 때문에, 여기서 리소스 부족이 발생하면 클러스터 전체 서비스가 마비될 수 있어요. 저희는 CPU와 메모리의 Request 및 Limit 값을 여유 있게 설정하고, 부하에 따라 자동으로 늘어날 수 있도록 HPA(Horizontal Pod Autoscaler)를 함께 구성했어요.

STEP 2. 경로 기반 라우팅 규칙 정의하기

이제 본격적으로 트래픽을 어디로 보낼지 규칙을 작성해야 해요. 저희 서비스 구조는 다음과 같았어요.

• api.example.com/auth → 인증 서비스 (Auth Service)
• api.example.com/order → 주문 서비스 (Order Service)
• api.example.com/user → 사용자 서비스 (User Service)

이 규칙을 적용하기 위해 인그레스 리소스(Ingress Resource) YAML 파일을 작성했어요. 여기서 핵심은 pathType 설정이에요. 과거에는 Prefix와 ImplementationSpecific 사이에서 혼란이 많았지만, 최신 쿠버네티스 버전에서는 Prefix를 사용하여 경로의 일치 여부를 명확히 판단하도록 설정하는 것을 권장해요.

STEP 3. SSL/TLS 인증서 자동화 적용

보안은 타협할 수 없는 영역이죠. 모든 API 통신은 HTTPS로 이루어져야 해요. 예전에는 인증서를 수동으로 발급받아 Secret으로 만들어 관리했지만, 이제는 cert-manager를 사용하여 자동화했어요.

Let’s Encrypt를 연동하면 인증서 만료 걱정 없이 자동으로 갱신 프로세스가 돌아가요. 인그레스 설정 파일에 tls 섹션을 추가하고, 생성된 인증서 Secret 이름을 지정하기만 하면 끝이에요. 이 과정을 통해 운영 팀의 단순 반복 업무가 90% 이상 줄어드는 놀라운 경험을 할 수 있었어요.

STEP 4. 어노테이션을 활용한 세밀한 트래픽 제어

단순히 전달만 하는 것을 넘어, 인그레스 컨트롤러는 강력한 기능들을 제공해요. 저희는 Nginx의 Annotation 기능을 적극 활용했어요.

대표적인 사례로 Rate Limiting이 있어요. 특정 IP에서 과도한 요청이 들어와 서버를 공격하는 것을 방지하기 위해 nginx.ingress.kubernetes.io/limit-rps 설정을 사용하여 초당 요청 수를 제한했어요. 또한, 대용량 파일 업로드가 필요한 서비스에는 proxy-body-size 값을 조정하여 413 Payload Too Large 에러를 방지했죠.

실제 적용된 설정 예시는 다음과 같아요.

# 예시: 요청 제한 및 파일 크기 설정 어노테이션
annotations:
  nginx.ingress.kubernetes.io/limit-rps: "5"
  nginx.ingress.kubernetes.io/proxy-body-size: "50m"

STEP 5. 카나리 배포(Canary Deployment)를 통한 안정적 운영

새로운 버전의 서비스를 배포할 때 모든 사용자에게 한꺼번에 노출하는 것은 너무 위험해요. 저희는 인그레스의 카나리 기능을 활용해 트래픽의 5%만 신규 버전으로 보내는 실험을 수행했어요.

인그레스 컨트롤러에 특정 어노테이션을 추가하면, 기존 서비스와 신규 서비스를 가중치(Weight) 기반으로 나눌 수 있어요. 신규 버전에서 에러율이 올라가지 않는 것을 확인한 뒤, 점진적으로 비중을 10%, 30%, 50%로 늘려가는 방식이에요. 이 전략 덕분에 배포 중 발생할 수 있는 장애 범위를 최소화하고, 사용자 경험을 안정적으로 유지할 수 있었어요.

자주 하는 실수와 해결법

인그레스를 운영하다 보면 예상치 못한 에러 메시지를 마주하게 돼요. 저희가 실제로 겪었던 사례들을 정리했어요.

• ❌ 404 Not Found 에러가 발생해요
  왜 발생하는가: 인그레스의 path 설정과 실제 서비스의 경로가 일치하지 않거나, pathType을 잘못 설정했을 때 발생해요.
  ✅ 해결법: pathType: Prefix를 사용하고, 서비스의 엔드포인트 경로를 다시 한번 확인하세요.
• ❌ SSL 연결이 끊기거나 핸드쉐이크 에러가 나요
  왜 발생하는가: 인증서 Secret이 생성되지 않았거나, 인그레스가 참조하는 이름이 틀렸을 때 발생해요.
  ✅ 해결법: kubectl get secret 명령어로 인증서가 정상적으로 존재하는지, 그리고 이름이 YAML 파일과 정확히 일치하는지 확인하세요.
• ❌ 대용량 파일 업로드 시 413 에러가 떠요
  왜 발생하는가: Nginx의 기본 클라이언트 바디 크기 제한(보통 1MB)에 걸렸기 때문이에요.
  ✅ 해결법: 어노테이션에 nginx.ingress.kubernetes.io/proxy-body-size 값을 충분히 크게 설정하세요.
• ❌ 헤더 정보(X-Forwarded-For 등)가 사라져요
  왜 발생하는가: 프록시 설정이 누락되어 클라이언트의 원본 IP를 전달하지 못하고 있기 때문이에요.
  ✅ 해결법: 인그레스 컨트롤러의 ConfigMap 설정을 통해 헤더 전달 옵션을 활성화하세요.
• ❌ 서비스 배포 후 트래픽이 전달되지 않아요
  왜 발생하는가: 인그레스가 바라보는 서비스의 포트(Port)와 실제 컨테이너의 포트가 맞지 않는 경우예요.
  ✅ 해결법: 인그레스의 service.port.number 값이 서비스 리소스의 port와 일치하는지 확인하세요.

자주 묻는 질문

Q. 인그레스 컨트롤러를 여러 개 두어도 괜찮나요?
네, 가능해요. 예를 들어 외부 트래픽용 컨트롤러와 내부 관리용 컨트롤러를 분리하여 운영하면 보안 측면에서 훨씬 유리해요. 다만 리소스 소모가 늘어난다는 점을 고려해야 해요.

Q. 클라우드 업체가 제공하는 로드밸런서와 무엇이 다른가요?
클라우드 로드밸런서는 주로 L4(IP/Port 기반) 계층에서 작동하지만, 인그레스는 L7(HTTP/HTTPS 경로 기반) 계층에서 작동해요. 즉, 인그레스는 훨씬 더 정교하고 똑똑한 라우팅이 가능해요.

Q. 인그레스 도입 시 비용이 정말 절감되나요?
네, 서비스 개수가 많아질수록 효과가 커져요. 서비스마다 로드밸런서를 하나씩 만드는 대신, 하나의 로드밸런서에 인그레스를 얹어 사용하기 때문에 클라우드 비용을 획기적으로 줄일 수 있어요.

Q. Nginx 말고 다른 컨트롤러를 써도 되나요?
물론이에요. 트래픽량이 매우 많거나 특수한 기능이 필요하다면 Kong, Traefik, Istio Gateway 같은 대안을 고려할 수 있어요. 다만 각 컨트롤러마다 학습 곡선이 다르다는 점을 기억하세요.

Q. 인그레스 설정이 잘못되면 서비스 전체가 죽나요?
인그레스 컨트롤러 자체의 설정 오류라면 모든 서비스에 영향을 줄 수 있어요. 그래서 항상 스테이징 환경에서 먼저 검증하고, 배포 전 YAML 문법 검사를 철저히 하는 습관이 중요해요.

인그레스 운영을 위한 마지막 조언

인그레스 도입은 단순히 기술 하나를 추가하는 것이 아니라, 우리 인프라의 관리 효율성을 한 단계 높이는 중요한 전환점이에요. 처음에는 설정 하나하나가 까다롭고 에러가 발생할 때마다 당혹스럽겠지만, 한 번 제대로 구축해두면 운영의 자유도가 놀라울 정도로 높아질 거예요.

오늘 바로 실천할 수 있는 액션 플랜을 제안해 드릴게요.

• 오늘 할 일: 현재 클러스터에서 사용 중인 로드밸런서 개수와 비용을 리스트업 해보세요.
• 이번 주 할 일: 스테이징 환경에 Nginx Ingress Controller를 설치하고 간단한 테스트 서비스를 연결해 보세요.
• 실행 직전 할 일: 실제 운영 환경에 적용하기 전, 인증서 자동 갱신(cert-manager)이 잘 작동하는지 꼭 체크하세요.

실습 환경에서 직접 적용해 보시고, 설정 과정에서 막히는 부분이 있다면 주저하지 말고 아래 댓글로 질문을 남겨 주세요. 함께 고민하고 해결해 봐요!

함께 읽으면 좋은 글: 쿠버네티스 인그레스 기본 개념 글, 클러스터 구축 입문 글