왜 우리는 인그레스 도입을 고민해야 할까요
매일 아침 출근해서 가장 먼저 확인하는 것이 서비스 접속 여부였어요. 하지만 마이크로서비스 아키텍처(MSA)로 전환하면서 서비스 개수가 늘어날수록 관리해야 할 IP와 포트 번호가 기하급수적으로 늘어나는 것을 보며 앞이 캄캄해졌어요. 서비스 하나를 추가할 때마다 새로운 로드밸런서를 생성하고, 각각의 고유한 주소를 할당하는 과정은 정말 고통스러웠어요.
단순히 서비스가 늘어나는 문제뿐만이 아니었어요. 각 서비스마다 보안 설정을 따로 하고, SSL 인증서를 일일이 관리하다 보니 운영 팀의 업무 부하가 한계에 다다랐어요. 비용 문제도 무시할 수 없었어요. 클라우드 환경에서 로드밸런서 하나를 생성할 때마다 발생하는 비용이 쌓여서 한 달 고정 비용이 예상 범위를 훌쩍 넘겨버렸거든요.
이러한 혼란을 해결하기 위해 우리가 선택한 방법이 바로 인그레스였어요. 인그레스는 단순히 트래픽을 전달하는 통로를 넘어, 클러스터 입구에서 모든 교통 정리를 담당하는 똑똑한 관리자 역할을 해줘요. 이 글을 통해 제가 직접 겪은 인그레스 운영 사례를 바탕으로, 어떤 문제를 어떻게 해결했는지 생생하게 들려드릴게요.
이 글을 끝까지 읽고 나면 다음과 같은 내용을 얻어갈 수 있어요.
- 기존 네트워크 구조의 한계와 인그레스의 필요성
- 인그레스 컨트롤러 선정 기준과 설정 방법
- 실제 서비스 적용 시 발생하는 보안 및 라우팅 최적화 기법
- 운영 중 겪었던 실수와 이를 방지하는 해결책
성공적인 적용을 위한 사전 준비와 선택 기준
인그레스를 무작정 설치한다고 해서 모든 문제가 해결되는 것은 아니에요. 우리 환경에 가장 잘 맞는 구성을 선택하기 위해서는 현재 클러스터의 상태와 요구되는 트래픽 특성을 먼저 파악해야 해요. 준비 없이 도입했다가는 오히려 트래픽 병목 현상이 발생하거나 설정 오류로 서비스가 중단되는 낭패를 볼 수 있어요.
필수로 체크해야 할 준비물
먼저 안정적인 쿠버네티스 클러스터가 운영 중이어야 해요. 그리고 도메인 네임을 관리할 수 있는 DNS 설정 권한이 필요해요. 인그레스는 기본적으로 도메인 기반의 라우팅을 수행하기 때문이에요. 또한, 인증서 관리를 자동화하기 위해 Cert-manager 같은 도구를 미리 검토해 두는 것이 정신 건강에 이로워요.
인그레스 컨트롤러는 인그레스 규칙을 실제로 해석하고 실행하는 소프트웨어예요. 가장 대중적인 것은 Nginx 컨트롤러이지만, 환경에 따라 Traefik이나 Kong을 선택할 수도 있어요.
트래픽 노출 방식 비교
인그레스를 도입하기 전에 우리가 기존에 사용하던 방식과 비교해 보면 왜 인그레스가 필요한지 명확해져요. 아래 표를 통해 각 방식의 차이점을 확인해 보세요.
| 구분 | NodePort | LoadBalancer | Ingress |
|---|---|---|---|
| 비용 | 매우 낮음 | 서비스당 발생 (높음) | 매우 낮음 (통합 관리) |
| 관리 편의성 | 매우 낮음 (포트 관리 어려움) | 보통 | 매우 높음 (도메인 기반) |
| 보안 기능 | 거의 없음 | 기본 제공 | 매우 강력 (L7 제어 가능) |
| 주요 용도 | 테스트용 | 단일 서비스 노출 | 다수 서비스 통합 관리 |
표에서 볼 수 있듯이 서비스가 늘어날수록 Ingress가 가장 경제적이고 효율적인 선택지가 돼요. 단순히 비용만 아끼는 것이 아니라, 도메인 하나에 여러 서비스를 묶어서 관리할 수 있다는 점이 운영 측면에서 가장 큰 장점이에요.
인그레스 실전 적용: 단계별 구축과 최적화 과정
이제 본격적으로 인그레스를 어떻게 실제 서비스에 녹여냈는지 그 과정을 단계별로 설명해 드릴게요. 단순히 설치하는 것에 그치지 않고, 실제 운영 환경에서 마주하는 복잡한 요구사항들을 어떻게 해결했는지에 집중해서 봐 주세요.
STEP 1. 기존 네트워크 구조의 한계와 문제 파악
도입 전 우리의 모습은 처참했어요. 각 마이크로서비스(User, Order, Payment, Product 등)마다 개별적인 LoadBalancer를 할당받았거든요. 서비스가 15개였으니, 클라우드 콘솔에는 15개의 로드밸런서가 떠 있었고 매달 청구되는 비용은 눈덩이처럼 불어났어요.
게다가 보안 문제도 심각했어요. 각 서비스의 엔드포인트가 외부에 직접 노출되다 보니, 공격자들이 각 서비스의 IP를 직접 타격할 수 있는 구조였어요. 모든 서비스에 동일한 보안 정책을 적용하기가 매우 까다로웠고, 인증서 갱신 시점도 제각각이라 관리가 불가능한 수준이었죠. 우리는 이 모든 것을 하나의 ‘관문’으로 통합해야 한다는 결론을 내렸어요.
STEP 2. Nginx Ingress Controller 선정 및 설치
다양한 컨트롤러를 검토했지만, 결국 Nginx Ingress Controller를 선택했어요. 이유는 명확했어요. 가장 커뮤니티가 활발하고, 우리가 필요로 하는 복잡한 라우팅 규칙(Annotation)을 가장 풍부하게 지원하기 때문이에요. 설치 과정은 Helm을 이용해 비교적 간단하게 진행했어요.
설치 시 가장 신경 썼던 부분은 리소스 제한(Resource Quota) 설정이었어요. 인그레스 컨트롤러는 클러스터의 모든 트래픽을 처리하는 핵심 엔진이기 때문에, 컨트롤러 자체가 CPU나 메모리 부족으로 죽어버리면 전체 서비스가 마비되는 대참사가 발생해요. 따라서 컨트롤러의 Pod에 적절한 requests와 limits를 설정하는 것이 무엇보다 중요해요.
STEP 3. 도메인 기반 라우팅 및 세부 설정 최적화
이제 설치된 컨트롤러에 규칙을 부여할 차례예요. 우리는 하나의 도메인을 사용하면서 경로(Path)에 따라 서비스를 분리하는 방식을 택했어요. 예를 들어, `example.com/api/user`로 들어오면 User 서비스로, `example.com/api/order`로 들어오면 Order 서비스로 보내주는 식이죠.
이 과정에서 단순히 경로만 나누는 것이 아니라, 애노테이션(Annotation)을 활용한 세부 제어가 핵심이었어요. 예를 들어, 특정 서비스에만 더 긴 타임아웃을 설정하거나, 클라이언트의 IP를 백엔드까지 전달하기 위한 `X-Forwarded-For` 설정을 추가했어요.
Ingress 리소스를 작성할 때 `pathType`을 `ImplementationSpecific`이 아닌 `Prefix`나 `Exact`로 명확히 지정해야 의도치 않은 라우팅 오류를 방지할 수 있어요.
STEP 4. 보안 강화를 위한 SSL/TLS 자동화 적용
보안을 위해 모든 트래픽을 HTTPS로 강제하기로 했어요. 하지만 수많은 서비스의 인증서를 수동으로 관리하는 것은 불가능에 가까워요. 그래서 우리는 Cert-manager와 Let’s Encrypt를 조합하여 인증서 발급 및 갱신을 완전히 자동화했어요.
이제 새로운 서비스가 추가되어 인그레스 규칙을 만들면, Cert-manager가 이를 감지하고 자동으로 인증서를 발급받아 Secret 객체로 생성해 줘요. 운영자는 인증서 만료 날짜를 신경 쓸 필요 없이 오직 비즈니스 로직에만 집중할 수 있게 되었죠. 이는 운영 효율성을 극적으로 높여준 결정적인 한 수였어요.
STEP 5. 트래픽 제어를 통한 카나리 배포 실현
마지막으로, 인그레스의 강력한 기능 중 하나인 카나리(Canary) 배포를 구현했어요. 새로운 버전의 서비스를 배포할 때, 바로 모든 사용자에게 적용하는 것이 아니라 트래픽의 5% 정도만 먼저 새 버전으로 보내 테스트하는 방식이에요.
Nginx 인그레스의 카나리 애노테이션을 사용하면 매우 쉽게 설정할 수 있어요. `nginx.ingress.kubernetes.io/canary: “true”`와 `nginx.ingress.kubernetes.io/canary-weight: “5”`와 같은 설정을 통해 트래픽 비율을 정밀하게 조정할 수 있었죠. 덕분에 배포 시 발생하는 리스크를 획기적으로 줄일 수 있었어요.
실제 운영 적용 시나리오 예시
우리가 구성한 최종적인 트래픽 흐름을 요약하면 다음과 같아요.
- 사용자가 `https://api.example.com/orders` 접속
- L4 로드밸런서(Cloud Provider 제공)가 Ingress Controller의 NodePort로 트래픽 전달
- Ingress Controller가 도메인과 경로를 분석하여 ‘Order Service’를 타겟으로 결정
- SSL 인증서를 확인하여 암호화 통신 유지
- Order Service Pod로 트래픽 전달
자주 하는 실수와 해결법 및 자주 묻는 질문
인그레스를 운영하다 보면 예상치 못한 변수들로 인해 서비스가 중단되는 상황이 종종 발생해요. 제가 직접 겪었던 시행착오들을 정리해 드릴 테니, 비슷한 문제를 겪고 있다면 꼭 참고해 보세요.
자주 하는 실수와 해결법
❌ 실수: 경로(Path) 설정 시 마지막 슬래시(/) 누락
왜 발생하는가: `/api`와 `/api/`는 서로 다른 경로로 인식될 수 있어요.
✅ 해결법: `pathType: Prefix`를 사용하고, 애플리케이션의 요구사항에 맞춰 경로 규칙을 엄격하게 정의해야 해요.
❌ 실수: SSL 인증서 Secret 이름 불일치
왜 발생하는가: Ingress 설정에 적은 `tls.secretName`과 실제 생성된 Secret의 이름이 다르면 HTTPS 접속이 안 돼요.
✅ 해결법: Cert-manager가 생성한 Secret 이름을 주기적으로 확인하고, Ingress YAML 파일과 일치하는지 검증하는 프로세스를 갖춰야 해요.
❌ 실수: Ingress Controller의 리소스 부족
왜 발생하는가: 트래픽이 갑자기 몰릴 때 컨트롤러 Pod의 CPU 사용량이 치솟으며 응답 지연이 발생해요.
✅ 해결법: 모니터링 도구(Prometheus/Grafana)를 통해 컨트롤러의 자원 사용량을 관찰하고, HPA(Horizontal Pod Autoscaler)를 설정하여 Pod 개수를 자동으로 늘려줘야 해요.
❌ 실수: 백엔드 서비스 타임아웃 설정 미비
왜 발생하는가: 대용량 파일 업로드나 긴 쿼리 처리 시, Ingress의 기본 타임아웃보다 서비스 처리 시간이 길면 연결이 끊겨요.
✅ 해결법: `nginx.ingress.kubernetes.io/proxy-read-timeout` 같은 애노테이션을 사용하여 서비스 특성에 맞게 타임아웃을 늘려줘야 해요.
❌ 실수: 잘못된 Annotations 사용
왜 발생하는가: 오타가 있거나 존재하지 않는 애노테이션을 넣으면 무시되거나 에러가 발생해요.
✅ 해결법: 공식 문서를 항상 옆에 두고, 설정 변경 후에는 반드시 컨트롤러의 로그를 확인해야 해요.
자주 묻는 질문
Q. 인그레스와 로드밸런서(Service Type: LoadBalancer)의 차이는 무엇인가요?
로드밸런서는 클라우드에서 제공하는 L4 계층의 서비스로, 각 서비스마다 개별적인 IP와 비용이 발생해요. 반면 인그레스는 L7 계층에서 동작하며, 하나의 로드밸런서(또는 컨트롤러)를 통해 여러 서비스를 도메인과 경로로 구분하여 관리할 수 있는 스마트한 규칙 모음이라고 이해하시면 돼요.
Q. 인그레스 컨트롤러를 여러 개 운영할 수 있나요?
네, 가능해요. 용도에 따라 분리하는 것이 오히려 권장되기도 해요. 예를 들어, 외부 사용자용 트래픽을 처리하는 인그레스와 내부 관리자용 트래픽을 처리하는 인그레스를 별도의 컨트롤러로 나누면 보안과 안정성을 동시에 챙길 수 있어요.
Q. Nginx 인그레스 말고 다른 것도 쓸만한가요?
물론이에요. 가볍고 설정이 쉬운 것을 원한다면 Traefik이 좋은 대안이 될 수 있고, API 게이트웨이 기능이 강력한 것이 필요하다면 Kong이나 Ambassador를 고려해 보세요. 하지만 처음 시작하신다면 자료가 가장 많은 Nginx를 추천해요.
Q. 인증서 갱신이 안 될 때는 어떻게 확인하나요?
가장 먼저 Cert-manager의 로그를 확인해 보세요. `kubectl describe certificate [이름]` 명령어를 통해 왜 갱신이 실패했는지 에러 메시지를 상세히 볼 수 있어요. 대부분 DNS 설정 문제나 Let’s Encrypt의 Rate Limit 문제인 경우가 많아요.
