트래픽 폭증과 비용 문제, 왜 인그레스인가요?
클라우드 환경에서 쿠버네티스를 운영하다 보면 어느 순간 예상치 못한 비용 고지서를 마주하게 돼요. 특히 서비스 규모가 커지면서 각 마이크로서비스마다 LoadBalancer 타입을 사용하여 개별적인 외부 IP를 할당하기 시작하면 비용은 기하급수적으로 늘어나요. 서비스가 10개라면 10개의 로드밸런서 비용을 지불해야 하는 상황이 오는 것이죠.
처음에는 단순히 NodePort를 써서 해결해 보려고 했지만, 보안 문제와 포트 관리의 어려움 때문에 금방 한계에 부딪혔어요. 외부에서 들어오는 트래픽을 어떻게 하면 효율적으로 관리하면서도 비용을 아낄 수 있을지 고민하던 중, 드디어 인그레스 운영 사례를 실무에 적용하기로 결정했어요.
단순히 기술을 도입하는 것과 실제 운영 환경에서 안정적으로 트래픽을 받아내는 것은 완전히 다른 문제예요. 설정 파일 하나를 잘못 건드리면 전체 서비스가 먹통이 되는 아찔한 경험도 했으니까요. 이번 글에서는 제가 직접 겪은 인그레스 적용기를 통해 무엇이 문제였고, 어떻게 해결했는지 가감 없이 공유할게요.
이 글을 읽고 나면 다음과 같은 내용을 명확히 이해할 수 있어요.
- 인그레스 도입 전후의 네트워크 구조 변화
- 실무에서 가장 많이 사용하는 Nginx 인그레스 컨트롤러 설정법
- SSL 인증서 자동화와 경로 기반 라우팅 구현 방법
- 운영 중 마주치는 흔한 트러블슈팅 사례
인그레스 도입 전, 반드시 체크해야 할 준비물
무작정 인그레스를 설치한다고 해서 모든 문제가 해결되는 것은 아니에요. 오히려 잘못된 설계는 네트워크 복잡도만 높이고 디버깅을 어렵게 만들 수 있어요. 본격적인 구축에 앞서 우리 팀의 환경이 인그레스를 받아들일 준비가 되었는지 확인하는 과정이 꼭 필요해요.
핵심 개념과 용어 정리
인그레스를 이해하려면 먼저 인그레스 리소스와 인그레스 컨트롤러의 차이를 구분해야 해요. 리소스는 “어떤 경로로 들어온 요청을 어디로 보낼 것인가”라는 규칙을 담은 명세서이고, 컨트롤러는 그 규칙을 실제로 읽어서 트래픽을 전달해 주는 엔진이에요. 마치 메뉴판(리소스)과 요리사(컨트롤러)의 관계와 비슷하다고 생각하면 쉬워요.
인그레스는 L7(Application Layer) 계층에서 동작해요. 따라서 HTTP 헤더, 쿠키, 경로 등을 기준으로 정교한 라우팅이 가능하다는 점이 가장 큰 장점이에요.
네트워크 노출 방식 비교
우리가 기존에 사용하던 방식과 인그레스 방식이 어떻게 다른지 명확히 알아야 해요. 아래 표를 통해 각각의 특징을 비교해 보세요.
| 장점 | 단점 | 비용 효율성 | |
|---|---|---|---|
| NodePort | 추가 비용 없음 | 포트 관리 어려움, 보안 취약 | 매우 높음 |
| LoadBalancer | 설정이 매우 간편함 | 서비스 개수만큼 비용 발생 | 매우 낮음 |
| Ingress | 하나의 IP로 다중 서비스 운영 | 컨트롤러 관리 필요 | 높음 |
도입 전 체크리스트
실무에 적용하기 전에 다음 세 가지 질문에 답할 수 있어야 해요. 만약 하나라도 명확하지 않다면 도입을 조금 미루는 것이 좋아요.
- 도메인 관리 권한이 있는가: 인그레스는 도메인을 기반으로 라우팅을 수행하므로, DNS 설정과 도메인 소유권이 준비되어 있어야 해요.
- SSL 인증서 발급 방식이 결정되었는가: Let’s Encrypt를 통한 자동 발급을 쓸 것인지, 기존의 유료 인증서를 수동으로 등록할 것인지 정해야 해요.
- 트래픽 패턴을 파악하고 있는가: 특정 서비스로 트래픽이 몰리는지, 혹은 API 요청이 대부분인지에 따라 컨트롤러의 리소스 할당량이 달라져요.
인그레스 컨트롤러 자체가 단일 장애점(SPOF)이 될 수 있어요. 컨트롤러가 죽으면 클러스터 내의 모든 외부 서비스가 중단되므로, 반드시 고가용성(HA) 구성을 고려해야 해요.
실전 인그레스 구축 단계별 가이드
이제 본격적인 인그레스 사례를 살펴보겠습니다. 저희 팀은 약 15개의 마이크로서비스가 유기적으로 돌아가는 이커머스 플랫폼을 운영하고 있어요. 각 서비스는 결제, 상품, 주문, 사용자 관리 등으로 나뉘어 있었고, 이를 하나의 진입점으로 통합하는 과정을 5단계로 정리했어요.
STEP 1. 인그레스 컨트롤러 설치 및 최적화
저희는 가장 안정적이고 커뮤니티가 활발한 Nginx Ingress Controller를 선택했어요. Helm을 사용하여 설치하는 방식이 가장 깔끔하고 버전 관리가 용이했기 때문이에요. 단순히 설치만 하는 것이 아니라, 운영 환경에 맞게 ConfigMap을 수정하는 작업이 핵심이에요.
예를 들어, 클라이언트의 실제 IP를 확인하기 위해 `use-forwarded-headers` 옵션을 켜주어야 하고, 대규모 트래픽을 견디기 위해 `worker-connections` 값을 적절히 조절해야 해요. 저희 팀은 초기 설정 시 이 부분을 놓쳐서 특정 시간대에 접속이 끊기는 현상을 겪기도 했어요. 설치 직후에는 반드시 설정값이 반영되었는지 로그를 통해 확인하는 습관을 들여야 해요.
STEP 2. 경로 기반(Path-based) 라우팅 설계
모든 서비스를 하나의 도메인 아래에서 관리하기 위해 경로 기반 라우팅을 적용했어요. 예를 들어 `example.com/api/v1/order`로 들어오는 요청은 주문 서비스로, `example.com/api/v1/product`로 들어오는 요청은 상품 서비스로 보내는 식이죠.
이때 주의할 점은 경로 설정 시 Trailing Slash(/) 문제예요. `/api`로 설정했는지, `/api/`로 설정했는지에 따라 백엔드 서비스가 요청을 인식하지 못하는 경우가 빈번하게 발생해요. 저희는 모든 경로 설정을 명확히 하기 위해 인그레스 리소스 작성 시 항상 끝에 슬래시를 포함하는 규칙을 세웠어요.
STEP 3. 호스트 기반(Host-based) 라우팅 병행
경로만으로는 부족한 경우가 있어요. 관리자 페이지나 별도의 API 전용 도메인이 필요할 때가 있죠. 저희는 `admin.example.com`이라는 별도의 호스트를 사용하여 관리자 전용 트래픽을 분리했어요. 이렇게 하면 일반 사용자 트래픽과 관리자 트래픽의 경로가 완전히 분리되어 보안적으로도 훨씬 안전해져요.
호스트 기반 라우팅을 사용하면 인그레스 리소스 하나에 여러 개의 `host` 규칙을 정의할 수 있어요. 이는 관리 포인트를 줄여주면서도 서비스 간의 독립성을 유지하는 데 매우 효과적이에요. 실제 운영 중에는 API 서버와 웹 프론트엔드 서버의 도메인을 분리하여 관리하는 것을 추천해요.
STEP 4. Cert-manager를 이용한 SSL 자동화
보안은 선택이 아닌 필수예요. 모든 트래픽을 HTTPS로 강제하기 위해 Cert-manager를 도입했어요. Let’s Encrypt를 사용하면 별도의 비용 없이 무료로 인증서를 발급받을 수 있지만, 인증서가 만료되지 않도록 자동으로 갱신해 주는 프로세스가 반드시 구축되어 있어야 해요.
Cert-manager를 설치하고 ClusterIssuer를 설정한 뒤, 인그레스 리소스에 `tls` 섹션을 추가하기만 하면 모든 과정이 자동으로 진행돼요. 저희는 이 과정을 자동화함으로써 매번 3개월마다 인증서를 교체해야 하는 번거로움과 실수 가능성을 완전히 제거할 수 있었어요. 만약 인증서 갱신이 실패하면 서비스 전체가 ‘연결이 안전하지 않음’ 메시지를 띄우게 되니, 반드시 모니터링 알람을 설정해 두어야 해요.
STEP 5. 트래픽 제어 및 보안 강화
마지막 단계는 서비스의 안정성을 지키는 장치를 마련하는 것이에요. 특정 IP에서 과도한 요청을 보내는 것을 막기 위해 Rate Limiting 설정을 추가했어요. Nginx 인그레스의 Annotation 기능을 활용하면 매우 간단하게 구현할 수 있어요.
또한, 민감한 API 경로에는 특정 헤더가 포함되어야만 접근이 가능하도록 필터링을 걸어두었어요. 이는 웹 방화벽(WAF)의 기능을 일부 대신하는 효과를 주어, 기본적인 애플리케이션 공격으로부터 서비스를 보호하는 데 큰 도움이 되었어요. 실무에서는 단순히 트래픽을 넘겨주는 것을 넘어, 입구에서부터 불필요한 요청을 걸러내는 필터 역할을 인그레스에 기대게 됩니다.
운영 시나리오 예시
저희 팀의 실제 인그레스 설정 흐름을 간단한 시나리오로 보여드릴게요.
- 사용자 요청: `https://example.com/api/order/123`
- 인그레스 단계:
- HTTPS 연결 확인 (SSL 인증서 검증)
- 도메인 확인 (`example.com`)
- 경로 확인 (`/api/order`)
- 설정된 규칙에 따라 ‘주문 서비스’ Pod로 트래픽 전달
- 결과: 사용자는 지연 없이 주문 정보를 확인하고, 시스템은 하나의 엔드포인트로 모든 요청을 효율적으로 처리함
자주 하는 실수와 해결법
실무에서 인그레스를 운영하다 보면 정말 다양한 문제에 부딪히게 돼요. 제가 직접 겪고 해결했던 사례들을 정리했으니, 비슷한 상황이라면 꼭 참고해 보세요.
- ❌ 실수: Annotation 오타로 인한 설정 미적용
왜 발생하는가: 인그레스는 설정의 상당 부분을 Annotation(주석)을 통해 제어하는데, 키 값이 하나라도 틀리면 에러 없이 그냥 무시돼요.
✅ 해결법: 설정 후 반드시 인그레스 컨트롤러의 로그를 확인하여 설정이 제대로 로드되었는지 검증해야 해요. - ❌ 실수: 백엔드 서비스 타임아웃 발생
왜 발생하는가: API 요청 처리 시간이 긴 서비스의 경우, 인그레스의 기본 타임아웃 설정보다 응답이 늦어지면 연결이 끊겨요.
✅ 해결법: `nginx.ingress.kubernetes.io/proxy-read-timeout` 같은 설정을 통해 백엔드 특성에 맞게 타임아웃 시간을 늘려주세요. - ❌ 실수: SSL 인증서 불일치(Mismatch)
왜 발생하는가: 도메인 이름과 인증서에 등록된 이름이 다를 때 브라우저에서 경고가 발생해요.
✅ 해결법: Cert-manager가 올바른 도메인에 대해 인증서를 발급했는지, Secret 이름이 인그레스 설정과 일치하는지 확인하세요. - ❌ 실수: 경로 매칭 오류 (Path Matching)
왜 발생하는가: `/api`와 `/api/`를 다르게 인식하여 404 에러가 발생할 수 있어요.
✅ 해결법: 인그레스 규칙을 작성할 때 경로의 끝에 슬래시를 포함할지 여부를 팀 내에서 표준화하고, 테스트 시 이를 반드시 확인하세요. - ❌ 실수: 리소스 부족으로 인한 컨트롤러 다운
왜 발생하는가: 갑작스러운 트래픽 증가 시 인그레스 컨트롤러에 할당된 CPU/메모리가 부족해져 응답이 느려지거나 죽을 수 있어요.
✅ 해결법: HPA(Horizontal Pod Autoscaler)를 사용하여 트래픽에 따라 컨트롤러 Pod의 개수가 자동으로 늘어나도록 설정하세요.
자주 묻는 질문
Q. 인그레스와 API 게이트웨이의 차이점이 무엇인가요?
인그레스는 쿠버네티스 내부의 트래픽을 외부로 노출하는 기본적인 L7 규칙을 정의하는 데 집중해요. 반면 API 게이트웨이는 인증, 권한 부여, 복잡한 트래픽 변환 등 훨씬 더 고도화된 기능을 제공해요. 서비스 규모가 아주 크고 복잡한 기능이 필요하다면 API 게이트웨이를, 기본적인 라우팅과 SSL 관리가 목적이라면 인그레스를 사용하는 것이 경제적이에요.
Q. 인그레스 컨트롤러를 여러 개 운영해도 되나요?
네, 가능해요. 예를 들어 외부 사용자용 트래픽을 처리하는 인그레스와 내부 시스템 관리용 트래픽을 처리하는 인그레스를 분리하여 운영할 수 있어요. 이렇게 하면 보안 격리 측면에서 매우 유리해요.
Q. Nginx 말고 추천할 만한 컨트롤러가 있나요?
클라우드 환경이라면 AWS Load Balancer Controller를 사용하는 것도 좋은 방법이에요. 클라우드 네이티브한 기능을 더 쉽게 쓸 수 있다는 장점이 있어요. 하지만 범용성과 설정의 자유도는 여전히 Nginx가 가장 높아요.
Q. 인그레스 도입 시 비용 절감 효과는 어느 정도인가요?
서비스 개수가 늘어날수록 효과는 극대화돼요. 10개의 서비스를 각각 LoadBalancer로 운영할 때와 인그레스 하나로 운영할 때의 비용 차이는 보통 수 배 이상 날 수 있어요. 초기 설정 비용과 관리 공수는 들지만, 장기적인 운영 관점에서는 압도적으로 유리해요.
Q. 설정 변경 시 서비스 중단이 발생하나요?
인그레스 리소스를 수정하면 컨트롤러가 이를 감지하여 설정을 업데이트해요. Nginx의 경우 ‘Reload’ 과정을 거치는데, 이 과정이 매우 빨라서 보통은 중단 없이 반영돼요. 하지만 아주 큰 설정 변경은 주의가 필요해요.
성공적인 인그레스 운영을 위한 마무리
지금까지 실무에서 직접 겪은 인그레스 운영 사례를 통해 구축부터 트러블슈팅까지 자세히 살펴보았어요. 인그레스는 단순히 트래픽을 전달하는 도구가 아니라, 서비스의 보안과 비용, 그리고 확장성을 결정짓는 중요한 관문이에요. 처음에는 설정 하나하나가 어렵게 느껴질 수 있지만, 한 번 제대로 구축해 두면 운영의 난이도가 획기적으로 낮아지는 것을 경험하실 거예요.
- 비용 절감을 위해 개별 LoadBalancer 대신 인그레스를 적극 활용하세요.
- Nginx 인그레스 컨트롤러와 Cert-manager 조합은 실무에서 매우 강력해요.
- 경로(Path) 설정 시 슬래시(/) 유무를 반드시 표준화하세요.
- 컨트롤러 자체가 장애 지점이 되지 않도록 고가용성 구성을 잊지 마세요.
- Annotation을 통한 미세 조정(타임아웃, 레이트 리밋)이 운영의 핵심이에요.
이제 여러분의 클러스터에 인그레스를 적용해 볼 차례예요. 처음부터 완벽할 수는 없으니, 작은 서비스부터 하나씩 적용하며 감을 익혀보시길 권장해요.
다음 단계로 나아가기
- 오늘 할 일: 현재 운영 중인 서비스의 LoadBalancer 사용 현황을 파악하고 비용을 계산해 보세요.
- 이번 주 할 일: 스테이징 환경에 Nginx 인gress Controller와 Cert-manager를 설치해 보세요.
- 실행 직전 할 일: 실제 도메인을 연결하기 전, 경로 기반 라우팅이 의도대로 작동하는지 로컬 테스트를 완료하세요.
실습 과정에서 설정이 꼬이거나 예상치 못한 에러 메시지를 만난다면, 주저하지 말고 아래 댓글로 질문을 남겨 주세요. 함께 고민하고 해결해 나갔으면 좋겠어요!
관련하여 더 깊은 내용이 궁금하시다면 쿠버네티스 인그레스 기본 개념 글이나 클러스터 구축 입문 글도 함께 읽어보시면 큰 도움이 될 거예요.
