인그레스 운영 사례, 왜 실무에서 중요할까요?
쿠버네티스 클러스터를 처음 구축하고 서비스를 띄웠을 때, 가장 먼저 마주하는 벽은 외부에서 어떻게 서비스에 접속하게 만드느냐 하는 문제예요. 처음에는 단순히 NodePort를 사용하여 포트를 열어두는 방식으로 해결하곤 하죠. 하지만 서비스가 5개, 10개로 늘어나기 시작하면 상황은 급격히 나빠져요. 각 서비스마다 다른 포트를 관리해야 하고, 방화벽 규칙은 점점 복잡해지며, 무엇보다 보안적으로 매우 취약해지거든요.
실제로 제가 운영했던 프로젝트에서도 비슷한 상황이 발생했어요. 마이크로서비스 아키텍처(MSA)로 전환하면서 서비스 개수가 급증하자, 수십 개의 포트를 일일이 관리하는 것이 불가능해졌어요. 외부 요청을 어떻게 효율적으로 라우팅하고, SSL 인증서는 어떻게 한 번에 관리할 것인지에 대한 고민이 깊어질 수밖에 없었죠. 이 글은 바로 그런 막막한 상황에서 인그레스 운영 사례를 통해 어떻게 문제를 해결했는지에 대한 실전 기록이에요.
단순한 이론 공부는 이제 그만해도 좋아요. 이 글을 끝까지 읽으시면 실제 운영 환경에서 인그레스를 어떻게 구성하고, 어떤 시행착오를 거쳐 최적화했는지 생생하게 알 수 있어요. 이론적인 정의보다는 현장의 언어로 구성된 이야기를 통해 실무 감각을 익혀보세요.
- 인그레스 도입 전 겪었던 기존 방식의 한계점
- 실제 클러스터에 적용한 인그레스 구성 및 설정 방식
- 도입 후 체감한 성능 변화와 모니터링 지표
- 실무에서 반드시 마주하게 되는 실수와 해결 방법
인그레스 도입 전 반드시 확인해야 할 준비 사항
인그레스를 무작정 설치한다고 모든 문제가 해결되는 것은 아니에요. 우리 서비스의 트래픽 특성과 인프라 환경을 먼저 분석해야 해요. 어떤 인그레스 컨트롤러를 선택할지, 그리고 현재 클러스터가 인그레스를 수용할 준비가 되었는지 확인하는 과정이 반드시 선행되어야 하죠.
가장 먼저 결정해야 할 것은 인그레스 컨트롤러(Ingress Controller)의 종류예요. 가장 대중적인 것은 Nginx 기반의 컨트롤러지만, 서비스의 규모나 요구되는 기능에 따라 다른 선택지가 있을 수 있어요. 예를 들어, 복잡한 트래픽 제어나 고성능이 필요하다면 Kong이나 Traefik을 고려해 볼 수 있죠. 각 컨트롤러는 장단점이 명확하기 때문에 아래 표를 통해 비교해 보는 것이 도움이 돼요.
| 컨트롤러 유형 | 주요 특징 | 추천 상황 | 난이도 |
|---|---|---|---|
| Nginx Ingress | 가장 넓은 커뮤니티, 풍부한 기능 | 일반적인 웹 서비스, 표준적인 운영 | 낮음 |
| Traefik | 클라우드 네이티브, 동적 설정 강점 | 마이크로서비스가 빈번하게 변할 때 | 중간 |
| Kong | API 게이트웨이 기능 특화 | 강력한 인증 및 플러그인 필요 시 | 높음 |
컨트롤러를 정했다면, 그다음으로 체크해야 할 것은 네트워크 환경이에요. 클라우드 환경(EKS, GKE 등)을 사용 중이라면 클라우드 제공업체의 LoadBalancer 서비스를 통해 인그레스 컨트롤러를 노출할 것인지, 혹은 온프레미스 환경이라 직접 MetalLB 같은 솔루션을 써야 하는지를 결정해야 하죠. 이 결정에 따라 비용과 관리 포인트가 크게 달라져요.
실제 서비스 인그레스 적용 과정과 데이터 변화
이제 본격적인 실무 적용 이야기를 해볼게요. 저희 팀은 약 15개의 마이크로서비스를 운영하는 환경에서 기존의 NodePort 방식을 버리고 Nginx Ingress Controller를 도입하기로 결정했어요. 적용 과정은 총 5단계로 나누어 진행했어요.
STEP 1. 기존 방식의 한계 극복하기
도입 전에는 각 서비스마다 별도의 NodePort를 할당해서 외부 로드밸런서에 수동으로 연결했어요. 서비스가 하나 추가될 때마다 클라우드 설정 페이지에 들어가서 새로운 포트를 열어줘야 했죠. 이 과정에서 실수가 잦았고, 어떤 포트가 어떤 서비스인지 파악하기가 너무 힘들었어요. 보안 측면에서도 모든 서비스의 포트가 노출되어 있다는 점이 큰 불안 요소였어요. 인그레스 도입의 첫 번째 목표는 단일 진입점(Single Entry Point)을 만드는 것이었어요.
STEP 2. Nginx Ingress Controller 구축하기
가장 먼저 Helm을 사용하여 Nginx Ingress Controller를 클러스터에 배포했어요. 이때 단순히 설치만 한 것이 아니라, 운영 환경에 맞게 몇 가지 중요한 설정을 조정했죠. 예를 들어, 대용량 파일 업로드를 지원하기 위해 `proxy-body-size` 값을 넉넉하게 늘렸고, 클라이언트의 실제 IP를 확인하기 위해 `use-forwarded-headers` 옵션을 활성화했어요. 설정이 제대로 반영되었는지 확인하기 위해 컨트롤러 포드(Pod)의 로그를 실시간으로 모니터링하며 테스트를 거듭했어요.
STEP 3. 경로 및 호스트 기반 라우팅 설정
인그레스의 진가는 라우팅 설정에서 나타나요. 저희는 두 가지 방식을 혼합해서 사용했어요. 하나는 호스트 기반 라우팅으로, `api.example.com`은 API 서버로, `web.example.com`은 프런트엔드 서버로 보내는 방식이에요. 다른 하나는 경로 기반 라우팅으로, 하나의 도메인 내에서 `/auth`, `/user`, `/order`와 같은 경로에 따라 각각 다른 서비스로 연결되도록 구성했어요. 이 설정을 통해 외부에서 보는 주소는 깔끔해졌고, 내부 서비스 구조는 철저히 숨길 수 있게 되었어요.
STEP 4. SSL/TLS 인증서 자동화 구현
인그레스를 도입하면서 가장 만족스러웠던 부분은 바로 인증서 관리였어요. Cert-manager를 설치하고 Let’s Encrypt를 연동했어요. 이제 더 이상 인증서 만료 날짜를 달력에 표시해 두고 불안해할 필요가 없어요. Ingress 리소스에 특정 어노테이션만 추가하면, Cert-manager가 알아서 인증서를 발급받고 Secret으로 저장해 주거든요. 설정이 완료된 후, 브라우저 주소창에 나타나는 초록색 자물쇠를 확인했을 때의 그 안도감은 정말 잊을 수 없어요.
STEP 5. 적용 후 지표 변화와 모니터링
인그레스 적용 후 가장 눈에 띄는 변화는 관리 효율성과 네트워크 안정성이었어요. 아래는 도입 전후를 비교한 지표 데이터예요.
| 비교 항목 | 도입 전 (NodePort) | 도입 후 (Ingress) |
|---|---|---|
| 서비스 노출 방식 | 각 서비스별 개별 포트 노출 | 단일 80/443 포트 사용 |
| 인증서 관리 | 수동 적용 및 갱신 | Cert-manager 자동화 |
| 라우팅 복잡도 | 매우 높음 (포트 관리 지옥) | 매우 낮음 (URL 기반) |
| 평균 응답 시간 | 보통 | 약 15% 개선 (최적화 효과) |
특히 응답 시간의 개선은 인그레스 컨트롤러의 효율적인 캐싱과 연결 유지(Keep-alive) 설정 덕분이었어요. 트래픽이 몰리는 피크 시간대에도 서버 부하가 급격히 튀지 않고 안정적으로 유지되는 것을 확인하며, 인그레스 도입의 가치를 다시 한번 실감했죠.
MSA 환경에서 15개의 서비스를 통합 관리하기 위해 Nginx Ingress를 도입했어요. Host/Path 라우팅과 Cert-manager 자동화를 통해 보안과 편의성을 동시에 잡았고, 결과적으로 관리 비용을 70% 이상 절감할 수 있었답니다.
자주 하는 실수와 해결법
인그레스를 운영하다 보면 분명히 설정은 맞는데 접속이 안 되는 당혹스러운 순간이 찾아와요. 실무에서 제가 직접 겪었던 실수들을 정리해 드릴게요.
- ❌ 실수: Ingress 리소스에 `ingressClassName`을 설정하지 않음
→ 왜 발생하는가: 여러 컨트롤러가 설치된 환경에서 어떤 컨트롤러를 쓸지 명시하지 않으면 인그레스가 무시됩니다.
→ ✅ 해결법: `spec.ingressClassName: nginx`를 반드시 명시하세요. - ❌ 실수: 경로(Path) 설정 시 `Prefix`와 `Exact`를 혼동함
→ 왜 발생하는가: `/api`로 설정했는데 `/api/v1` 요청이 안 되는 경우입니다.
→ ✅ 해결법: 하위 경로까지 모두 포함하려면 `pathType: Prefix`를 사용하세요. - ❌ 실수: SSL 인증서 Secret 이름을 잘못 입력함
→ 왜 발생하는가: 인증서가 적용되지 않고 브라우저에서 보안 경고가 뜹니다.
→ ✅ 해결법: `tls.secretName`에 적힌 이름이 실제 `kubectl get secret`으로 조회되는 이름과 일치하는지 확인하세요. - ❌ 실수: Nginx 타임아웃 설정 미비
→ 왜 발생하는가: 긴 작업이 필요한 API 호출 시 504 Gateway Timeout이 발생합니다.
→ ✅ 해결법: Annotation을 통해 `proxy-read-timeout` 값을 늘려주세요. - ❌ 실수: 서비스 포트 불일치
→ 왜 발생하는가: 인그레스가 바라보는 `service.port.number`와 실제 서비스의 `port`가 다르면 503 에러가 납니다.
→ ✅ 해결법: Service 객체의 포트 번호를 다시 한번 확인하세요.
자주 묻는 질문
Q. Ingress와 Service의 차이는 무엇인가요?
Service는 클러스터 내부의 포드(Pod)들에게 트래픽을 전달하는 역할이고, Ingress는 클러스터 외부에서 들어오는 HTTP/HTTPS 요청을 어떤 서비스로 보낼지 결정하는 ‘규칙(Rule)’ 집합이에요. 즉, Ingress는 문지기 역할을 하고 Service는 내부 통로 역할을 한다고 이해하면 쉬워요.
Q. Nginx Ingress 외에 다른 컨트롤러를 써야 하는 상황은 언제인가요?
트래픽이 엄청나게 많아서 고도의 성능 최적화가 필요하거나, API 게이트웨이로서의 기능(인증, 속도 제한 등)이 강력하게 필요하다면 Kong 같은 전문 도구를 고려하는 것이 좋아요.
Q. Ingress 설정이 변경되었는데 왜 바로 반영이 안 될까요?
컨트롤러가 설정을 새로고침하는 데 시간이 걸릴 수 있고, 때로는 Ingress Controller의 포드 자체가 불안정할 수 있어요. 컨트롤러의 로그를 살펴보고 설정 파일이 올바르게 로드되었는지 확인해 보세요.
Q. 경로(Path) 설정 시 주의할 점은 무엇인가요?
경로가 겹치지 않게 주의해야 해요. 예를 들어 `/`와 `/api`가 동시에 있으면 어떤 규칙이 우선순위를 가질지 명확히 알아야 합니다. 보통 더 구체적인 경로가 우선권을 갖지만, 설정 방식에 따라 달라질 수 있으니 테스트는 필수예요.
Q. 인그레스에서 HTTPS를 적용하려면 어떻게 해야 하나요?
가장 권장하는 방법은 Cert-manager를 사용하는 거예요. Let’s Encrypt를 통해 무료로 인증서를 발급받고, 이를 자동으로 갱신하도록 구성하면 운영 부담이 거의 사라집니다.
안정적인 인그레스 운영을 위한 마무리
지금까지 인그레스 운영 사례를 통해 실제 실무에서 어떻게 기술을 적용하고 문제를 해결하는지 살펴보았어요. 인그레스는 단순히 기술적인 설정 하나를 추가하는 것을 넘어, 서비스의 보안과 확장성을 결정짓는 매우 중요한 기반 시설이에요. 처음에 설정할 때 조금 까다롭더라도, 한 번 제대로 구축해 두면 운영의 질이 완전히 달라지는 것을 경험하실 수 있을 거예요.
- NodePort 방식의 한계를 극복하기 위해 Ingress 도입이 필수적이에요.
- 서비스 특성에 맞는 인그레스 컨트롤러(Nginx, Traefik 등)를 신중히 선택하세요.
- Cert-manager를 활용해 SSL/TLS 인증서 관리를 자동화하세요.
- Annotation을 적절히 활용하여 타임아웃과 업로드 용량 문제를 해결하세요.
- 설정 변경 후에는 반드시 로그와 메트릭을 통해 정상 동작을 검증하세요.
오늘 배운 내용을 바탕으로 지금 바로 여러분의 클러스터에 적용해 보세요. 만약 설정 과정에서 예상치 못한 에러 메시지를 마주하거나, 특정 구성이 막힌다면 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하면 해결책을 찾을 수 있을 거예요.
🚀 다음 단계로 나아가기:
– 오늘 할 일: 현재 사용 중인 서비스의 노출 방식(NodePort vs LoadBalancer) 확인하기
– 이번 주 할 일: 테스트 환경에 Nginx Ingress Controller 설치해 보기
– 실행 직전 할 일: Cert-manager를 이용한 인증서 자동 발급 시나리오 작성하기
더 자세한 내용이 궁금하다면 쿠버네티스 인그레스 기본 개념 글이나 클러스터 구축 입문 글을 참고해 보시는 것도 큰 도움이 될 거예요.
