[IT-정보] 인그레스 운영 사례 분석: 실제 서비스 적용기와 개선 포인트 – 실무에서 겪은 문제 상황과 설정 최적화 방법

인그레스 운영 사례를 찾는 이유

마이크로서비스 아키텍처를 운영하다 보면 어느 순간 벽에 부딪히는 시점이 찾아와요. 처음에는 서비스가 몇 개 없으니 각 서비스마다 로드밸런서(LoadBalancer)를 하나씩 할당해서 외부로 노출해도 큰 문제가 없어요. 하지만 서비스가 10개, 20개로 늘어나기 시작하면 이야기가 달라져요. 클라우드 비용은 기하급수적으로 올라가고, 각 서비스마다 서로 다른 공인 IP를 관리하는 작업은 관리자에게 엄청난 스트레스를 줘요.

실제로 제가 처음 실무에서 쿠버네티스를 운영할 때 겪었던 혼란이 바로 이거였어요. 서비스가 늘어날 때마다 생성되는 로드밸런서 비용 고지서를 보고 눈앞이 캄캄해졌거든요. 게다가 도메인 하나에 여러 서비스를 연결하고 싶은데, 매번 새로운 IP를 연결하는 과정에서 설정 실수도 잦았어요. 이런 비효율적인 구조를 해결하기 위해 도입한 것이 바로 인그레스(Ingress)였어요.

단순히 이론적인 개념만 안다고 해서 운영이 쉬워지는 건 아니에요. 실무에서는 트래픽이 몰릴 때의 타임아웃 설정, SSL 인증서의 자동 갱신, 그리고 경로 기반 라우팅 시 발생하는 미묘한 설정 오류 등 예상치 못한 변수가 정말 많거든요. 이번 글에서는 제가 직접 서비스를 운영하며 겪은 인그레스 운영 사례를 통해 시행착오와 최적화 방법을 가감 없이 공유하려고 해요.

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

• 기존 노드포트(NodePort)나 로드밸런서 방식의 한계점 파악
• Nginx 인그레스 컨트롤러를 활용한 효율적인 트래픽 관리법
• 실제 운영 환경에서 자주 발생하는 설정 오류와 해결 시나리오
• 도메인 및 SSL 인증서 관리를 자동화하는 실전 기술

인그레스 도입 전 반드시 점검할 사항

인그레스를 도입하기로 결정했다면, 먼저 우리가 현재 어떤 방식으로 외부 트래픽을 받고 있는지 냉정하게 분석해야 해요. 단순히 “인그레스가 좋다고 하니까”라는 이유만으로 도입했다가는 오히려 네트워크 구조만 복잡해지고 트러블슈팅만 어려워질 수 있거든요. 가장 먼저 확인해야 할 것은 현재 서비스의 확장성 요구사항이에요.

만약 서비스가 단 두 개뿐이고 앞으로 늘어날 계획도 전혀 없다면, 굳이 인그레스 컨트롤러를 설치하고 관리하는 리소스를 쓸 필요가 없어요. 하지만 우리가 다루는 환경처럼 서비스가 계속 추가되는 환경이라면 인그레스는 선택이 아닌 필수예요. 또한, 사용하는 클라우드 환경이 인그레스를 지원하는지, 혹은 자체 구축형(On-premise) 환경인지에 따라 인그레스 컨트롤러의 선택지가 완전히 달라져요.

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

결론적으로, 서비스가 늘어날수록 관리 비용을 줄이고 고도화된 라우팅 규칙을 적용하고 싶다면 인그레스 도입을 위한 준비를 시작해야 해요. 단순히 기술을 도입하는 게 아니라, 우리 서비스의 트래픽 패턴과 비용 구조를 먼저 이해하는 것이 첫걸음이에요.

실전 인그레스 구축과 운영 과정

본격적으로 저희 서비스에 인그레스를 적용했던 과정을 단계별로 설명해 드릴게요. 이론적인 설명보다는 제가 실제로 터미널에서 어떤 고민을 했고, 어떤 설정을 건드렸는지에 초점을 맞춰서 말씀드릴게요.

STEP 1. 기존 서비스 접근 방식의 한계 극복하기

저희는 처음에 각 마이크로서비스를 클라우드의 로드밸런서(LoadBalancer) 타입으로 생성해서 사용했어요. 처음엔 편했지만, 서비스가 15개로 늘어나자 한 달에 청구되는 로드밸런서 비용만 해도 상당한 금액이 되었죠. 게다가 서비스마다 별도의 도메인을 연결하는 것도 매우 번거로웠어요. 하나의 공인 IP를 공유하면서 도메인과 경로에 따라 트래픽을 분산할 수 있는 방법이 절실했어요. 그래서 저희는 가장 대중적이고 검증된 Nginx Ingress Controller를 도입하기로 결정했어요.

STEP 2. Nginx Ingress Controller 설치와 초기 설정

가장 먼저 한 일은 헬름(Helm)을 사용하여 컨트롤러를 설치하는 것이었어요. 단순히 설치만 한다고 끝나는 게 아니에요. 저희는 운영 환경의 특성에 맞춰 컨트롤러 자체의 리소스 제한(Resource Limit)을 설정하는 데 공을 들였어요. 컨트롤러가 트래픽을 처리하다가 CPU나 메모리 부족으로 죽어버리면, 클러스터 전체 서비스가 먹통이 될 수 있기 때문이에요.

설치할 때 사용했던 주요 설정 값들은 다음과 같아요.

• Replica 수: 고가용성을 위해 최소 2개 이상의 Pod로 구성했어요.
• Resource Requests/Limits: CPU 500m, Memory 512Mi 정도로 시작해서 모니터링하며 조정했어요.
• Service Type: 클라우드 환경에 맞춰 LoadBalancer 타입으로 설정해 컨트롤러 자체에 접근할 수 있는 단일 IP를 확보했어요.

STEP 3. 도메인 및 경로 기반 라우팅 구현

이제 본격적으로 인그레스 리소스를 작성하기 시작했어요. 저희는 크게 두 가지 방식을 혼합해서 사용했어요. 첫 번째는 호스트 기반(Host-based) 라우팅이에요. 예를 들어, API 서비스는 api.example.com으로, 웹 프론트엔드는 www.example.com으로 접속하도록 설정했어요.

두 번째는 경로 기반(Path-based) 라우팅이에요. 하나의 도메인 안에서도 경로에 따라 다른 서비스로 연결했죠. 예를 들어, example.com/users로 들어오면 사용자 서비스로, example.com/orders로 들어오면 주문 서비스로 보내는 식이에요. 이때 주의할 점은 PathType 설정이에요. 저희는 대부분 Prefix 타입을 사용했는데, 이를 잘못 설정하면 경로 매칭이 꼬여서 404 에러가 빈번하게 발생했으니 꼭 주의해야 해요.

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

실무에서 인증서 관리는 정말 골칫덩어리에요. 인증서 만료 날짜를 체크하다가 실수로 놓치면 서비스 전체가 보안 경고를 띄우며 중단되거든요. 저희는 이 문제를 해결하기 위해 Cert-manager를 도입했어요. Let’s Encrypt를 활용해 인증서를 발급받고, 인그레스 리소스에 지정된 Secret을 통해 자동으로 갱신되도록 구성했어요. 이제 더 이상 인증서 만료를 걱정하며 밤을 지새우지 않아도 돼요.

STEP 5. 어노테이션(Annotation)을 활용한 고급 트래픽 제어

인그레스의 진정한 강력함은 어노테이션에서 나와요. 저희는 서비스 안정성을 높이기 위해 다음과 같은 설정들을 적극적으로 활용했어요.

• nginx.ingress.kubernetes.io/proxy-body-size: "50m": 대용량 파일 업로드를 위해 클라이언트 요청 본문 크기를 늘려줬어요.
• nginx.ingress.kubernetes.io/proxy-read-timeout: "60": 특정 API의 응답 시간이 길어질 때 발생하는 타임아웃 문제를 해결하기 위해 설정했어요.
• nginx.ingress.kubernetes.io/canary: "true": 새로운 버전을 배포할 때 트래픽의 일부만 먼저 흘려보내는 카나리 배포를 구현했어요.

이런 설정들을 하나씩 적용해 나가면서 저희 서비스의 네트워크 안정성은 몰라보게 좋아졌어요. 특히 트래픽이 갑자기 몰리는 이벤트 기간에도 인그레스 컨트롤러의 리소스만 적절히 확보되어 있다면 서비스 전체가 무너지는 일은 거의 없었죠.

자주 하는 실수와 해결법

인그레스를 운영하다 보면 이론과 실무 사이의 간극 때문에 당황스러운 순간이 정말 많아요. 제가 직접 겪었던 실수를 바탕으로 정리해 드릴게요.

• ❌ 경로 매칭 실패 (404 Not Found)
  왜 발생하는가: Ingress 설정 시 path 끝에 슬래시(/)를 붙였는지 안 붙였는지에 따라 매칭이 안 될 수 있어요.
  ✅ 해결법: pathType: Prefix를 사용하고, 애플리케이션 내부의 경로 구조와 인그레스의 경로가 정확히 일치하는지 확인하세요.
• ❌ 502 Bad Gateway 에러
  왜 발생하는가: 인그레스 컨트롤러가 목적지 Pod로 연결하려고 할 때, Pod가 아직 준비되지 않았거나(Unready) 서비스 포트 설정이 잘못되었을 때 발생해요.
  ✅ 해결법: kubectl get pods로 Pod 상태를 확인하고, Service의 targetPort가 Pod의 실제 포트와 일치하는지 반드시 대조해 보세요.
• ❌ SSL 인증서 적용 실패
  왜 발생하는가: TLS Secret 이름이 Ingress 설정의 secretName과 다르거나, 인증서가 해당 네임스페이스에 존재하지 않을 때 발생해요.
  ✅ 해결법: Secret이 Ingress 리소스와 동일한 네임스페이스에 있는지 확인하고, 이름 오타를 체크하세요.
• ❌ 업로드 용량 초과 에러 (413 Request Entity Too Large)
  왜 발생하는가: Nginx의 기본 클라이언트 요청 본문 크기 제한 때문이에요.
  ✅ 해결법: 어노테이션으로 proxy-body-size 값을 필요한 만큼 키워주세요.
• ❌ 컨트롤러 성능 저하
  왜 발생하는가: 트래픽이 급증하는데 인그레스 컨트롤러에 할당된 CPU/메모리 리소스가 부족할 때 발생해요.
  ✅ 해결법: 컨트롤러의 HPA(Horizontal Pod Autoscaler)를 설정하거나, 리소스 Request/Limit 값을 상향 조정하세요.

자주 묻는 질문

Q. 인그레스 컨트롤러와 인그레스 리소스의 차이가 무엇인가요?

인그레스 리소스는 “이런 경로로 들어오면 저 서비스로 보내줘”라는 규칙이 적힌 설정 문서라고 생각하시면 돼요. 반면 인그레스 컨트롤러는 그 문서를 읽고 실제로 트래픽을 전달하는 실제 엔진(Nginx, HAProxy 등)이에요. 설계도와 실제 시공업자의 차이라고 이해하시면 쉬워요.

Q. 왜 서비스 타입을 LoadBalancer로 쓰지 않고 인그레스를 쓰나요?

가장 큰 이유는 비용과 효율성 때문이에요. 서비스마다 로드밸런서를 만들면 IP와 비용이 계속 늘어나지만, 인그레스를 쓰면 하나의 로드밸런서로 수십 개의 서비스를 하나의 IP로 관리할 수 있어요. 또한 L7 계층의 세밀한 라우팅 기능도 인그레스가 훨씬 강력해요.

Q. SSL 인증서를 수동으로 관리해도 괜찮을까요?

규모가 아주 작다면 가능하겠지만, 실무에서는 권장하지 않아요. 인증서 만료는 서비스 중단으로 이어지는 치명적인 실수이기 때문이에요. 가급적 Cert-manager 같은 도구를 써서 자동화하는 환경을 구축하는 것이 정신 건강에 이로워요.

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

네, 가능해요. 용도에 따라 나누어 설치할 수 있어요. 예를 들어, 외부 사용자용 트래픽을 처리하는 컨트롤러와 내부 관리용 트래픽을 처리하는 컨트롤러를 분리해서 운영하면 보안과 관리 측면에서 매우 유리해요.

Q. Nginx 외에 다른 컨트롤러를 써도 되나요?

물론이에요. 트래픽 패턴에 따라 Kong, Traefik, Istio Gateway 등을 선택할 수 있어요. API 게이트웨이 기능이 많이 필요하다면 Kong을, 서비스 메쉬 환경이라면 Istio를 고려해 보는 것이 좋아요.

인그레스 운영을 마치며

지금까지 제가 실제 현장에서 겪은 인그레스 운영 사례와 그 과정에서의 해결책들을 정리해 드렸어요. 처음에는 설정 하나하나가 어렵고 에러 메시지가 무섭게 느껴질 수 있지만, 하나씩 해결하다 보면 쿠버네티스 네트워크의 흐름을 이해하는 큰 재미를 느끼실 수 있을 거예요.

오늘 배운 내용을 바탕으로 당장 무엇을 해야 할까요? 우선 현재 운영 중인 서비스들의 트래픽 패턴을 파악하고, 어떤 서비스들이 인그레스 도입 시 가장 큰 비용 절감 효과를 줄지 리스트를 작성해 보세요. 그 다음, 스테이징 환경에서 먼저 컨트롤러를 설치하고 간단한 테스트 서비스를 올려보는 것부터 시작하시길 바라요.

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

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