[IT-정보] 인그레스 운영 사례와 실전 적용 가이드 – 트래픽 관리 문제 해결부터 설정 최적화까지

인그레스, 왜 실무에서 선택이 아닌 필수일까요

클라우드 환경에서 쿠버네티스를 운영하다 보면 어느 순간 당황스러운 상황을 마주하게 돼요. 서비스가 늘어날수록 클라우드 콘솔에 생성되는 로드밸런서(LoadBalancer) 개수가 기하급수적으로 늘어나고, 그만큼 매달 청구되는 비용 고지서의 숫자가 무섭게 올라가거든요. 단순히 서비스를 외부에 노출하는 것이 목적이었다면, 개별 서비스마다 로드밸런서를 만드는 방식은 운영 효율과 비용 측면에서 큰 재앙이 될 수 있어요.

실제로 제가 처음 마이크로서비스 아키텍처(MSA)를 운영할 때 겪었던 문제예요. API 서버, 웹 프론트엔드, 관리자 페이지를 각각 별도의 로드밸런서로 연결했더니 관리 포인트가 너무 많아졌고, 네트워크 설정 하나를 바꿀 때마다 모든 로드밸런서를 확인해야 하는 번거로움이 있었어요. 이 문제를 해결해 준 것이 바로 인그레스(Ingress)였어요.

인그레스는 클러스터 외부에서 내부 서비스로 접속하는 HTTP와 HTTPS 경로를 효율적으로 관리해 주는 똑똑한 길잡이 역할을 해요. 하나의 IP 주소와 하나의 로드밸런서만 사용하면서도, 들어오는 요청의 도메인이나 경로(Path)에 따라 적절한 서비스로 트래픽을 배분할 수 있거든요. 이 글에서는 제가 직접 겪은 인그레스 운영 사례를 통해 어떻게 비용을 줄이고 운영을 단순화했는지 생생하게 들려드릴게요.

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

• 로드밸런서 과다 사용으로 인한 비용 문제를 해결하는 방법
• 인그레스 컨트롤러를 선택하고 설정하는 기준
• 실무에서 자주 발생하는 경로 설정 오류와 해결책
• 보안을 위한 TLS 인증서 적용 및 관리 노하우

인그레스 도입 전 꼭 알아야 할 기초 지식

인그레스를 바로 적용하기 전에, 우리가 기존에 사용하던 방식과 무엇이 다른지 명확히 이해해야 해요. 무작정 설정 파일을 만들기 시작하면 왜 트래픽이 목적지로 가지 않는지 이유조차 찾기 어려워지거든요. 가장 먼저 클러스터 내부에서 외부로 서비스를 노출하는 세 가지 대표적인 방식을 비교해 볼게요.

트래픽 노출 방식 비교

위 표에서 볼 수 있듯이, 인그레스는 단순히 트래픽을 전달하는 것을 넘어 도메인 기반 라우팅(Host-based)과 경로 기반 라우팅(Path-based)을 지원한다는 점이 가장 큰 매력이에요. 예를 들어, `api.example.com`으로 들어오면 API 서비스로, `example.com/web`으로 들어오면 프론트엔드 서비스로 보내는 작업을 단 하나의 로드밸런서로 처리할 수 있어요.

인그레스를 성공적으로 도입하기 위해 준비해야 할 체크리스트를 정리해 드릴게요. 이 항목들이 준비되지 않았다면 인그레스 설정은 시작조차 하기 어려워요.

• 인그레스 컨트롤러 설치 계획 (Nginx, Kong, Traefik 등)
• 사용할 외부 도메인 및 DNS 설정 권한
• SSL/TLS 인증서 발급 및 관리 도구 (Cert-manager 등)
• 애플리케이션 서비스들의 적절한 이름과 포트 정의

특히 컨트롤러를 무엇으로 선택하느냐에 따라 사용할 수 있는 기능과 설정 난이도가 완전히 달라지니, 우리 팀의 인프라 역량에 맞춰 신중하게 결정해야 해요.

실전 인그레스 구축 및 최적화 단계별 가이드

이제 본격적으로 인그레스를 실제 환경에 어떻게 적용했는지 단계별로 살펴볼게요. 저는 수십 개의 마이크로서비스가 돌아가는 운영 환경에서 인그레스를 도입하며 얻은 경험을 바탕으로 5단계 프로세스를 정리했어요.

STEP 1. 기존 서비스의 구조 분석 및 컨트롤러 선택

가장 먼저 해야 할 일은 현재 노출 중인 서비스들을 분류하는 것이에요. 모든 서비스를 로드밸런서로 뽑아낼지, 아니면 인그레스 뒤로 숨길지를 결정해야 하죠. 저는 Nginx Ingress Controller를 선택했어요. 커뮤니티가 워낙 방대해서 문제가 생겼을 때 구글링으로 해결하기 가장 쉽고, 애노테이션(Annotation)을 통한 미세한 설정이 가능하기 때문이에요.

선택 과정에서 고려해야 할 점은 단순히 ‘유명한가’가 아니에요. 우리 서비스가 L7 계층의 복잡한 규칙(예: 쿠키 기반 세션 유지, 특정 헤더 조건 라우팅)을 자주 사용하는지, 아니면 단순한 경로 매칭만 필요한지를 따져봐야 해요. 만약 고성능 API 게이트웨이 기능이 더 필요하다면 Kong이나 Envoy 기반의 컨트롤러를 고려하는 것이 훨씬 현명한 선택이에요.

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

컨트롤러 설치가 끝났다면 이제 실제 트래픽 길을 만들어 줄 리소스를 작성해야 해요. 여기서 가장 많이 하는 실수가 경로 매칭 규칙이에요. 제가 운영했던 사례를 예로 들어볼게요. API 서비스와 웹 서비스를 하나의 도메인 아래 두기로 했어요.

예를 들어, `example.com/api`로 들어오는 요청은 `api-service`로 보내고, 나머지는 모두 `web-service`로 보내고 싶을 때 어떻게 설정할까요? 단순하게 작성하면 `/api` 경로가 웹 서비스의 경로와 겹쳐서 엉뚱한 곳으로 트래픽이 튀는 경우가 많아요. 이를 방지하기 위해 rewrite-target 애노테이션을 아주 정밀하게 사용해야 해요.

설정 파일 예시를 텍스트로 묘사하자면, 인그레스 설정의 `pathType`을 `Prefix`로 설정하고, Nginx의 특정 애노테이션을 사용해 `/api/v1/users`라는 요청이 들어왔을 때 백엔드 서비스에는 `/v1/users`로 전달되도록 경로를 재작성하는 작업이 필요해요. 이 과정이 없으면 백엔드 서버는 `/api`라는 경로를 이해하지 못해 404 에러를 뱉어내게 돼요.

STEP 3. TLS 인증서를 통한 보안 연결 적용

실무 환경에서 HTTP만 사용하는 서비스는 거의 없다고 봐도 무방해요. 모든 통신은 HTTPS로 암호화되어야 하죠. 인그레스의 장점 중 하나는 하나의 인그레스 컨트롤러에서 여러 도메인의 SSL 인증서를 한꺼번에 관리할 수 있다는 점이에요.

저는 cert-manager를 사용하여 Let’s Encrypt 인증서를 자동으로 발급받고 갱신하도록 구축했어요. 인그레스 리소스에 `tls` 섹션을 추가하고, 발급된 `Secret` 이름을 적어주기만 하면 끝나요. 이렇게 하면 인증서 만료 날짜를 매번 체크하며 가슴 졸일 필요가 없어요. 인증서가 만료되어 사이트 접속이 차단되는 사고는 운영자에게 가장 뼈아픈 실책 중 하나니까요.

STEP 4. 트래픽 제어와 카나리 배포 환경 구축

서비스가 안정화되면 단순히 길을 열어주는 것을 넘어, 트래픽을 조절하는 단계로 넘어가야 해요. 인그레스는 강력한 트래픽 쉐이핑(Traffic Shaping) 기능을 제공해요. 특정 사용자가 너무 많은 요청을 보내 서버를 마비시키는 것을 방지하기 위해 ‘Rate Limiting’을 설정할 수 있죠.

또한, 새로운 버전의 서비스를 배포할 때 모든 사용자에게 한 번에 적용하는 것이 아니라, 전체 트래픽의 5%만 새로운 버전으로 보내보는 카나리(Canary) 배포도 인그레스 설정만으로 가능해요. Nginx Ingress의 경우 `nginx.ingress.kubernetes.io/canary` 애노테이션을 사용하면, 특정 가중치에 따라 트래픽을 분산시켜 신규 버전의 안정성을 검증할 수 있어요. 이 기능 덕분에 배포 실패로 인한 전체 서비스 장애 리스크를 획기적으로 줄일 수 있었어요.

STEP 5. 모니터링과 로그 분석을 통한 검증

설정을 마쳤다면 이제 제대로 작동하는지 확인해야 해요. 단순히 브라우저에서 접속해 보는 것만으로는 부족해요. 인그레스 컨트롤러에서 발생하는 로그를 실시간으로 관찰하며, 4xx나 5xx 에러가 발생하는 패턴을 찾아내야 하죠.

저는 Prometheus와 Grafana를 연결해 인그레스의 요청당 응답 시간(Latency)과 **초당 요청 수(RPS)**를 시각화했어요. 특정 경로에서 갑자기 응답 시간이 길어진다면, 그 경로를 담당하는 백엔드 서비스의 부하를 즉시 감지할 수 있거든요. 이렇게 데이터에 기반한 모니터링 체계를 갖추는 것이 운영의 핵심이에요.

자주 하는 실수와 해결법

인그레스를 운영하다 보면 정말 별것 아닌 설정 하나 때문에 몇 시간 동안 삽질을 하게 되는 경우가 많아요. 제가 직접 겪었던 대표적인 사례들을 정리했으니, 비슷한 상황에 처해 있다면 꼭 확인해 보세요.

• ❌ 경로 매칭 오류 (404 Not Found)
  왜 발생하는가: 인그레스의 경로 설정(Path)과 백엔드 서비스의 실제 API 경로가 일치하지 않기 때문이에요. 예를 들어 인그레스는 `/api`로 요청을 받는데, 백엔드 서비스는 `/`부터 시작하는 경로를 기다리고 있을 때 발생해요.
  ✅ 해결법: Nginx의 `rewrite-target` 애노테이션을 사용하여 경로를 적절히 재작성해 주세요.
• ❌ TLS 인증서 적용 실패
  왜 발생하는가: 인증서가 저장된 Secret의 이름이 인그레스 설정과 다르거나, 인증서가 해당 네임스페이스에 존재하지 않을 때 발생해요.
  ✅ 해결법: `kubectl get secret`으로 정확한 이름을 확인하고, 인그레스와 동일한 네임스페이스에 Secret이 있는지 체크하세요.
• ❌ 대용량 파일 업로드 제한
  왜 발생하는가: Nginx 인그레스 컨트롤러의 기본 클라이언트 바디 크기(client-max-body-size)가 작게 설정되어 있기 때문이에요.
  ✅ 해결법: `nginx.ingress.kubernetes.io/proxy-body-size` 애노테이션을 사용하여 허용 용량을 늘려주세요.
• ❌ 헤더 크기 제한으로 인한 오류
  왜 발생하는가: 인증 토큰(JWT)이 너무 길어 요청 헤더가 설정된 제한을 초과할 때 발생해요.
  ✅ 해결법: `proxy-buffer-size`와 `proxy-buffers` 관련 애노테이션을 조절하여 버퍼 크기를 키워야 해요.
• ❌ 서비스 포트 불일치
  왜 발생하는가: 인그레스 리소스에 작성한 `service.port.number`가 실제 Service 객체의 `port`와 다를 때 발생해요.
  ✅ 해결법: 인그레스 설정과 Service 설정을 다시 한번 대조해 보세요.

자주 묻는 질문

Q. 인그레스(Ingress)와 로드밸런서(LoadBalancer) 서비스는 완전히 다른 건가요?

완전히 다른 것은 아니지만 역할이 달라요. 로드밸런서는 클라우드 인프라 수준에서 트래픽을 클러스터로 들여보내는 통로를 만드는 것이고, 인그레스는 그 통로로 들어온 트래픽을 어떤 서비스로 보낼지 결정하는 규칙 세트라고 이해하면 쉬워요. 보통 로드밸런서 하나를 인그레스 컨트롤러에 연결해서 사용해요.

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

네, 가능해요. 예를 들어 외부 트래픽용 Nginx 컨트롤러와 내부 통신용 다른 컨트롤러를 분리하여 운영할 수 있어요. 다만, 관리 복잡도가 올라가므로 명확한 목적이 있을 때만 권장해요.

Q. 인그레스 설정이 변경되면 서비스가 중단되나요?

일반적으로는 중단되지 않아요. 인그레스 컨트롤러가 설정을 동적으로 다시 불러오기(Reload)하기 때문이에요. 하지만 설정 오류가 심각하거나 컨트롤러 자체가 재시작되는 상황에서는 아주 짧은 순간 끊김이 발생할 수 있으니 주의해야 해요.

Q. 하나의 인그레스 리소스로 여러 도메인을 관리할 수 있나요?

네, 인그레스 리소스의 `rules` 섹션에 서로 다른 `host` 값을 나열하면 하나의 컨트롤러로 여러 도메인을 운영할 수 있어요. 비용 절감에 아주 효과적인 방법이에요.

성공적인 인그레스 운영을 위한 마무리

인그레스는 쿠버네티스 운영의 복잡도를 낮추고 비용을 획기적으로 줄여주는 핵심 도구예요. 하지만 강력한 기능만큼이나 설정 하나하나에 신경을 써야 하는 정교함도 요구하죠. 제가 정리한 내용을 바탕으로 여러분의 클러스터도 효율적으로 최적화해 보길 바라요.

오늘 배운 내용을 바탕으로 당장 무엇부터 해야 할지 막막하다면, 다음 단계를 따라 해 보세요.

• 오늘 할 일: 현재 사용 중인 클라우드 로드밸런서 리스트를 뽑아보고, 인그레스로 통합 가능한 서비스가 있는지 분류해 보세요.
• 이번 주 할 일: 테스트 환경에 Nginx Ingress Controller를 설치하고, 간단한 웹 서비스를 경로 기반으로 연결해 보세요.
• 실행 직전 할 일: TLS 인증서 자동 발급을 위한 `cert-manager` 설치 가이드를 숙지해 두세요.

인그레스 설정 과정에서 예상치 못한 에러가 발생하거나, 우리 환경에 어떤 컨트롤러가 맞을지 고민된다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하고 해결책을 찾아볼게요! 실습 환경에서 직접 적용해 보면서 손에 익히는 것이 가장 빠른 지름길이라는 점, 잊지 마세요.

관련해서 더 깊이 있는 내용이 궁금하다면 쿠버네티스 인그레스 기본 개념 글이나 클러스터 구축 입문 글을 함께 읽어보시는 것을 추천해요.