[IT-정보] 인그레스 운영 사례 분석: 실제 서비스 적용기와 개선 포인트 – 실무 개발자를 위한 설정 노하우와 트러블슈팅 가이드

인그레스 운영 사례 분석: 왜 우리는 새로운 길을 찾아야 했을까요

마이크로서비스 아키텍처(MSA)를 도입한 팀이라면 누구나 한 번쯤 겪는 지점이 있어요. 서비스 개수가 늘어날수록 클라우드 환경에서 관리해야 할 리소스도 함께 폭발적으로 증가하죠. 처음에는 서비스 하나당 로드밸런서 하나를 붙이는 방식이 가장 편하고 직관적이었어요. 하지만 서비스가 10개, 20개로 늘어나기 시작하자 예상치 못한 벽에 부딪히게 되었답니다.

가장 먼저 눈에 띈 문제는 비용의 급격한 상승이었어요. 클라우드 업체에서 제공하는 L4 로드밸런서는 편리하지만, 하나당 매달 고정 비용이 발생해요. 서비스가 늘어날수록 매달 청구되는 인프라 비용이 감당하기 어려운 수준으로 올라갔죠. 게다가 각 서비스마다 별도의 공인 IP를 할당해야 하니 도메인 관리와 DNS 설정도 엉망이 되기 일쑤였어요.

트래픽 제어 측면에서도 한계가 명확했어요. 단순한 포트 포워딩이나 L4 수준의 분산만으로는 HTTP 헤더를 읽거나 URL 경로(Path)에 따라 트래픽을 나누는 세밀한 작업이 불가능했거든요. L7 계층의 정교한 라우팅이 간절해지는 시점이 바로 이곳이에요. 이 글은 바로 그런 혼돈의 시기를 지나 인그레스(Ingress)를 통해 질서를 찾아가는 과정을 담고 있어요.

이 글을 끝까지 읽고 나면 다음과 같은 내용을 확실히 얻어갈 수 있어요.

• 기존 로드밸런서 방식과 인그레스 방식의 결정적 차이
• 실무에서 가장 많이 쓰이는 Nginx Ingress Controller 설정법
• SSL/TLS 인증서를 자동으로 관리하는 실전 노하우
• 운영 중 반드시 마주하게 되는 트러블슈팅 해결책

인그레스 도입 전 반드시 확인해야 할 준비 사항

무턱대고 인그레스를 설치한다고 모든 문제가 해결되는 건 아니에요. 우리 서비스의 트래픽 특성과 클라우드 환경을 먼저 분석해야 해요. 무거운 파일을 주고받는 서비스인지, 아니면 아주 가벼운 API 요청이 쉴 새 없이 쏟아지는 서비스인지에 따라 설정 방향이 완전히 달라지거든요.

서비스 노출 방식 비교

인그레스를 도입하기 전, 우리가 현재 사용 중인 방식과 비교해 보면 왜 인그레스가 필요한지 더 명확해져요. 아래 표를 통해 각각의 특징을 확인해 보세요.

우리가 선택해야 할 기준은 명확해요. 단순히 “새로운 기술이니까”라는 이유로 도입하는 게 아니라, 관리할 도메인이 많아지고 비용 최적화가 절실한 시점에 인그레스를 검토해야 해요.

도입 전 체크리스트

인그레스를 구축하기 전에 아래 세 가지 질문에 스스로 답해 보세요. 만약 하나라도 답변이 어렵다면, 아직은 인그레스 도입보다 기존 방식의 최적화가 더 시급할 수도 있어요.

• 우리 서비스는 URL 경로(Path)나 호스트(Host)에 따라 서로 다른 서비스로 요청을 보내야 하는가?
• 한 개의 공인 IP로 여러 개의 도메인을 운영하여 클라우드 비용을 줄여야 하는 상황인가?
• SSL/TLS 인증서를 각 서비스마다 개별적으로 관리하는 것이 부담스러운가?

이 모든 준비가 끝났다면, 이제 본격적으로 인그레스를 어떻게 구성하고 실제 서비스에 녹여낼지 단계별로 살펴볼 차례예요.

인그레스 실무 적용 단계: 혼돈에서 질서로 가는 5단계

실제 운영 환경에서 인그레스를 도입할 때는 단순히 명령어를 입력하는 것을 넘어, 서비스의 안정성과 확장성을 고려한 설계가 필요해요. 우리가 겪었던 실제 적용 과정을 5가지 핵심 단계로 나누어 상세히 설명해 드릴게요.

STEP 1. 기존 환경 분석 및 인그레스 컨트롤러 선정

가장 먼저 해야 할 일은 현재의 트래픽 흐름을 파악하는 것이에요. 저희 팀은 기존에 15개의 마이크로서비스가 각각 독립적인 로드밸런서를 사용하고 있었어요. 이로 인해 매달 약 800달러 이상의 불필요한 비용이 발생하고 있었죠. 이를 한데 묶어줄 컨트롤러를 선정하는 것이 첫 번째 과제였어요.

시중에는 Nginx, Kong, Traefik 등 다양한 컨트롤러가 존재해요. 저희는 가장 커뮤니티가 활성화되어 있고 레퍼런스가 풍부한 Nginx Ingress Controller를 선택했어요. Nginx는 설정이 직관적이고, 무엇보다 우리가 이미 익숙한 설정 문법을 많이 활용할 수 있다는 장점이 있었거든요. 컨트롤러를 선정할 때는 단순히 유명한 것을 고르기보다, 우리 팀의 운영 역량과 서비스의 요구사항(예: gRPC 지원 여부, 고성능 처리 능력)을 반드시 대조해 봐야 해요.

STEP 2. 인그레스 리소스 정의와 경로 기반 라우팅 구현

컨트롤러를 설치했다면, 이제 어떤 트래픽을 어디로 보낼지 규칙을 정해야 해요. 이것이 바로 인그레스 리소스(Ingress Resource)를 작성하는 과정이에요. 저희는 하나의 도메인 아래에서 서비스별로 경로를 나누는 방식을 채택했어요.

예를 들어, `api.example.com/users`로 들어오는 요청은 사용자 관리 서비스로, `api.example.com/orders`로 들어오는 요청은 주문 서비스로 보내는 식이죠. 이때 주의할 점은 경로 매칭 방식(Path Type)이에요. `Prefix` 방식을 사용할지, 정확히 일치해야 하는 `Exact` 방식을 사용할지에 따라 라우팅 결과가 달라지거든요. 잘못 설정하면 엉뚱한 서비스로 요청이 흘러가 404 에러를 유발할 수 있어요.

STEP 3. SSL/TLS 인증서 자동화 시스템 구축

실무에서 보안은 타협할 수 없는 요소예요. 모든 서비스에 HTTPS를 적용해야 하는데, 서비스가 늘어날 때마다 인증서를 수동으로 갱신하는 것은 불가능에 가까워요. 그래서 저희는 Cert-manager를 함께 도입했어요.

Cert-manager를 설치하면 Let’s Encrypt와 같은 인증 기관(CA)과 연동하여, 인증서 발급부터 만료 전 자동 갱신까지 전 과정을 자동화할 수 있어요. 개발자가 인그레스 설정 파일에 인증서 이름만 명시해두면, 나머지는 시스템이 알아서 처리해 주죠. 이 과정이 구축된 후에는 더 이상 “인증서 만료로 인한 서비스 중단”을 걱정하지 않아도 되었답니다. 이는 운영 리소스를 줄이는 데 결정적인 역할을 했어요.

STEP 4. 카나리(Canary) 배포를 통한 트래픽 제어 실습

인그레스의 진정한 강력함은 트래픽을 아주 미세하게 조정할 수 있다는 점에 있어요. 새로운 버전의 서비스를 배포할 때, 모든 사용자에게 바로 노출하는 것은 위험해요. 저희는 인그레스의 기능을 활용해 카나리 배포 환경을 구성했어요.

새로운 버전의 서비스를 ‘v2’라고 한다면, 전체 트래픽의 5%만 v2로 보내고 나머지 95%는 안정적인 ‘v1’으로 유지하는 식이죠. 이를 위해 별도의 인그레스 리소스를 하나 더 만들고, 어노테이션을 통해 가중치를 설정했어요. 만약 v2에서 에러율이 높아지는 것을 모니터링으로 발견하면 즉시 트래픽을 0%로 돌려 문제를 최소화할 수 있었죠. 이러한 방식은 서비스의 가동 시간을 극대화하는 데 매우 효과적이었어요.

STEP 5. 모니터링 및 성능 최적화

마지막 단계는 구축된 시스템이 잘 돌아가고 있는지 감시하는 거예요. 인그레스 컨트롤러의 로그만 봐서는 전체적인 흐름을 파악하기 어려워요. 저희는 Prometheus와 Grafana를 연동하여 인그레스 계층에서의 요청 수, 응답 시간, 에러 코드 분포를 시각화했어요.

특히 5xx 에러가 갑자기 치솟는다면, 그것이 백엔드 서비스의 문제인지, 아니면 인그레스의 설정(예: Timeout 설정) 문제인지를 빠르게 구분해내는 것이 핵심이에요. 또한, 트래픽이 몰리는 시간대에 컨트롤러의 CPU와 메모리 사용량을 확인하며 적절한 오토스케일링(HPA) 정책을 수립하는 과정도 잊지 말아야 해요.

이러한 5단계를 거치며 저희 팀은 단순히 비용을 줄인 것을 넘어, 훨씬 더 안정적이고 유연한 네트워크 구조를 갖출 수 있었답니다.

자주 하는 실수와 해결법

인그레스를 운영하다 보면 이론과는 다른 예상치 못한 문제들에 직면하게 돼요. 저희가 실제로 겪었던 사례들을 바탕으로 정리해 보았어요.

• ❌ 경로 매칭 오류로 인한 404 발생
  왜 발생하는가: `Prefix`와 `Exact` 매칭의 차이를 간과하거나, 서비스 경로의 마지막 슬래시(/) 유무를 잘못 설정했기 때문이에요.
  ✅ 해결법: 사용하는 프레임워크의 라우팅 규칙과 인그레스의 매칭 타입을 반드시 대조해 보세요.
• ❌ 413 Request Entity Too Large 에러
  왜 발생하는가: 대용량 파일 업로드를 시도할 때 Nginx의 기본 클라이언트 바디 크기 제한에 걸린 경우예요.
  ✅ 해결법: 인그레스 어노테이션에 `nginx.ingress.kubernetes.io/proxy-body-size` 값을 적절히 키워주세요.
• ❌ 504 Gateway Timeout 발생
  왜 발생하는가: 백엔드 서비스의 처리 시간이 인그레스의 대기 시간보다 길어서 연결이 끊긴 거예요.
  ✅ 해결법: `proxy-read-timeout`이나 `proxy-send-timeout` 설러를 늘려 서비스 특성에 맞게 조정하세요.
• ❌ SSL 핸드셰이크 실패
  왜 발생하는가: Cert-manager가 인증서를 제대로 발급받지 못했거나, Secret 객체가 인그레스와 연결되지 않았을 때 발생해요.
  ✅ 해결법: `kubectl get certificate` 명령어로 인증서 상태를 확인하고 Secret 이름을 재점검하세요.
• ❌ 클라이언트 실제 IP가 아닌 컨트롤러 IP만 보이는 문제
  왜 발생하는가: 로드밸런서에서 전달된 헤더를 인그레스가 제대로 읽지 못하도록 설정되어 있기 때문이에요.
  ✅ 해결법: `use-forwarded-headers` 설정을 활성화하여 X-Forwarded-For 헤더를 신뢰하도록 구성하세요.

자주 묻는 질문

Q. 인그레스 컨트롤러를 여러 개 운영할 수 있나요?

네, 가능해요. 용도에 따라 분리하는 것이 오히려 권장되기도 해요. 예를 들어, 외부 사용자용 트래픽을 처리하는 컨트롤러와 내부 서비스 간 통신을 위한 컨트롤러를 별도로 구성하면 보안과 관리 측면에서 유리해요.

Q. Nginx 말고 다른 컨트롤러를 추천하신다면 무엇인가요?
클라우드 네이티브한 환경을 선호한다면 Kong을, 설정이 매우 간편하고 쿠버네티스 자체 기능에 충실한 것을 원한다면 Istio와 같은 서비스 메시(Service Mesh) 기반의 솔루션을 고려해 보세요.

Q. 인그레스 도입 시 비용이 정말로 줄어드나요?
네, 확실히 줄어들어요. 개별 서비스마다 로드밸런서를 생성하는 대신, 하나의 로드밸런서에 여러 도메인과 경로를 담기 때문에 클라우드 인프라 비용을 획기적으로 절감할 수 있어요.

Q. 인증서 자동 갱신이 실패하면 어떻게 하나요?
Cert-manager의 로그를 확인하는 것이 가장 빨라요. 주로 DNS 설정 문제나 인증 기관의 API 제한 때문에 실패하곤 하는데, 이를 모니터링 도구로 알람을 설정해두면 사고를 미연에 방지할 수 있어요.

Q. 인그레스는 L4 로드밸런서와 무엇이 다른가요?
L4는 IP와 포트 번호만 보고 트래픽을 넘겨주지만, 인그레스는 HTTP 헤더, 쿠키, URL 경로 같은 L7 정보를 보고 똑똑하게 길을 찾아준다는 점이 가장 큰 차이점이에요.

인그레스 운영을 위한 마지막 정리

인그레스 도입은 단순히 기술적인 변화를 넘어, 인프라 관리 방식의 패러다임을 바꾸는 과정이에요. 초기 설정과 학습에는 시간이 걸리겠지만, 한 번 제대로 구축해 두면 서비스 규모가 커져도 흔들리지 않는 튼튼한 기반이 되어줄 거예요.

오늘 바로 무엇을 해야 할지 막막하다면, 다음 단계를 따라 해 보세요.

• 오늘 할 일: 현재 사용 중인 로드밸런서 비용을 산출하고 인그레스 도입 시의 예상 절감액 계산해 보기
• 이번 주 할 일: 로컬 환경(Minikube 또는 Kind)에 Nginx Ingress Controller를 설치하고 간단한 서비스 연결해 보기
• 실행 직전 할 일: 운영 환경의 트래픽 패턴을 분석하여 적절한 Timeout 및 Body Size 값을 미리 정의해 두기

실습 환경에서 직접 적용해 보다가 막히는 부분이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민해 드릴게요!

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