인그레스 운영 사례를 통해 본 트래픽 관리의 전환점
새로운 마이크로서비스를 하나 배포할 때마다 클라우드 콘솔에 접속해서 로드밸런서를 생성하는 작업, 익숙하신가요? 처음에는 서비스가 몇 개 없어서 큰 문제가 안 될 수도 있어요. 하지만 서비스가 10개, 20개로 늘어나기 시작하면 상황은 완전히 달라져요. 매번 생성되는 고가의 로드밸런서 비용은 고스란히 팀의 예산 압박으로 다가오고, 관리해야 할 엔드포인트는 기하급수적으로 복잡해져요.
실제로 저희 팀에서도 비슷한 문제를 겪었어요. 서비스마다 개별적인 LoadBalancer 타입을 사용하다 보니, 한 달에 지불하는 네트워크 비용이 예상을 훨씬 뛰어넘었거든요. 단순히 비용 문제뿐만 아니라, 서비스마다 다른 도메인을 연결하고 SSL 인증서를 각각 관리하는 과정에서 운영팀의 피로도도 극에 달했어요. 이런 비효율을 해결하기 위해 선택한 것이 바로 인그레스(Ingress)였어요.
인그레스는 단순히 트래픽을 전달하는 통로가 아니에요. 하나의 진입점을 만들어 놓고, 들어오는 요청의 경로(Path)나 호스트(Host)에 따라 적절한 서비스로 길을 안내해 주는 똑똑한 교통 경찰과 같아요. 이번 글에서는 저희가 실제로 인그레스 운영 사례를 구축하며 겪었던 기술적 도전과 이를 통해 얻은 최적화 노하우를 아주 구체적으로 들려드릴게요.
이 글을 다 읽고 나면 다음과 같은 것들을 확실히 얻어 가실 수 있어요.
- 기존 로드밸런서 방식과 인그레스 방식의 결정적인 차이점
- 실무에서 바로 적용 가능한 인그레스 구성 단계
- 도입 과정에서 반드시 마주하게 되는 트러블슈팅 포인트
- 효율적인 트래픽 라우팅을 위한 설정 전략
성공적인 인그레스 도입을 위한 사전 준비 사항
무턱대고 인그레스를 설치한다고 모든 문제가 해결되지는 않아요. 인그레스는 그 자체로 동작하는 것이 아니라, 실제 트래픽을 처리할 Ingress Controller가 클러스터 안에 살아 있어야 하거든요. 따라서 도입 전에 우리 서비스의 규모와 요구사항이 어떤 유형에 속하는지 먼저 파악하는 과정이 꼭 필요해요.
가장 먼저 결정해야 할 것은 어떤 컨트롤러를 사용할 것인가예요. 가장 대중적인 것은 NGINX 인그레스 컨트롤러이지만, 서비스의 특성에 따라 Kong이나 Traefik 같은 대안을 고려해야 할 때도 있어요. 예를 들어, API 게이트웨이 기능이 강력하게 필요하다면 Kong이 유리할 수 있고, 가볍고 빠른 설정을 원한다면 NGINX가 적합해요.
서비스 노출 방식 비교 분석
인그레스를 도입하기 전, 우리가 현재 사용 중인 방식과 비교해 보면 왜 인그레스가 필요한지 더 명확해져요. 아래 표를 통해 각 방식의 특징을 확인해 보세요.
| 노출 방식 | 주요 특징 | 장점 | 단점 |
|---|---|---|---|
| NodePort | 모든 노드의 특정 포트를 개방 | 구조가 단순하고 추가 비용 없음 | 보안에 취약하고 포트 관리가 어려움 |
| LoadBalancer | 클라우드 제공 로드밸런서 사용 | 설정이 매우 간편하고 안정적임 | 서비스마다 비용이 발생하여 매우 비쌈 |
| Ingress | L7 계층의 라우팅 규칙 적용 | 비용 절감 및 도메인/경로 관리 용이 | 컨트롤러 관리 및 설정 복잡도 증가 |
인그레스는 L4(Transport Layer)가 아닌 L7(Application Layer)에서 동작해요. 즉, IP 주소와 포트 번호뿐만 아니라 HTTP 헤더, 쿠키, URL 경로 등을 보고 트래픽을 분산할 수 있다는 뜻이에요.
준비 단계에서 놓치지 말아야 할 체크리스트도 있어요. 도메인 관리 권한이 있는지, SSL/TLS 인증서를 어떻게 발급받아 자동화할 것인지(예: Cert-manager 사용 여부), 그리고 클러스터 내부에서 컨트롤러가 사용할 충분한 리소스(CPU/Memory)가 확보되었는지를 반드시 점검해야 해요. 이 과정이 소홀하면 실제 적용 단계에서 예상치 못한 네트워크 지연이나 인증서 만료 문제가 발생할 수 있어요.
실전! 인그레스 구축부터 최적화까지 단계별 실행 가이드
이제 이론적인 준비를 마쳤다면, 실제로 트래픽을 받아낼 수 있는 구조를 만들어 볼 차례예요. 저희 팀이 진행했던 실제 프로세스를 5단계로 나누어 상세히 설명해 드릴게요. 이 과정을 그대로 따라오시면 기본적인 인그레스 환경을 구축하실 수 있어요.
STEP 1. 기존 서비스 구조 진단과 인그레스 설계
가장 먼저 해야 할 일은 현재 운영 중인 서비스들을 분류하는 작업이에요. 모든 서비스를 한꺼번에 인그레스로 옮기려고 하면 리스크가 너무 커요. 따라서 공통 도메인을 사용할 서비스들과, 별도의 도메인이 꼭 필요한 핵심 서비스를 나누는 설계 작업이 우선이에요.
예를 들어, `api.example.com`은 모든 마이크로서비스가 공유하는 경로로 잡고, `admin.example.com`은 별도의 보안 설정이 필요한 관리자용 도메인으로 분리하는 식이죠. 이렇게 경로 기반(Path-based)과 호스트 기반(Host-based) 라우팅 전략을 미리 세워두어야 나중에 인그레스 리소스(Ingress Resource)를 작성할 때 혼란을 방지할 수 있어요.
STEP 2. NGINX Ingress Controller 설치 및 안정화
저희는 가장 검증된 NGINX Ingress Controller를 선택했어요. 설치는 Helm을 사용하는 것이 가장 깔끔하고 관리하기 편해요. 단순히 설치만 하는 것이 아니라, 운영 환경에 맞게 `values.yaml` 파일을 세밀하게 조정하는 것이 핵심이에요.
설치 시 주의할 점은 컨트롤러가 구동될 Pod의 리소스 제한(Resource Limits)을 설정하는 것이에요. 트래픽이 갑자기 몰릴 때 컨트롤러가 자원을 다 써버리면 클러스터 전체의 네트워크가 마비될 수 있거든요. 저희는 초기 설정 시 CPU는 500m, 메모리는 512Mi 정도로 시작해서 모니터링을 통해 점진적으로 늘려갔어요. 또한, 외부 트래픽을 받기 위해 컨트롤러 자체는 `LoadBalancer` 타입으로 배포하여 클라우드의 로드밸런서 하나만 딱 사용하도록 구성했어요.
STEP 3. Cert-manager를 이용한 SSL 인증서 자동화
인그레스를 도입하는 큰 이유 중 하나가 바로 HTTPS 적용이에요. 서비스가 늘어날 때마다 인증서를 수동으로 발급하고 Secret으로 등록하는 건 불가능에 가까워요. 그래서 저희는 Cert-manager를 도입하여 Let’s Encrypt 인증서를 자동으로 발급받고 갱신하는 체계를 만들었어요.
이 과정은 생각보다 까다로울 수 있어요. Ingress 리소스의 `annotations` 부분에 `cert-manager.io/cluster-issuer`를 정확히 기입해야 하고, 도메인의 DNS 설정이 클러스터의 Ingress IP를 정확히 가리키고 있어야 해요. 설정이 제대로 되었다면, 인그레스 리소스를 생성하자마자 Cert-manager가 알아서 인증서를 가져오고, 쿠버네티스 Secret으로 등록해 주는 마법 같은 경험을 할 수 있어요.
STEP 4. 경로 및 호스트 기반 라우팅 구성하기
이제 본격적으로 트래픽을 나누는 규칙을 작성해 봐요. 아래는 저희가 실제로 사용했던 인그레스 설정의 논리적 구조를 설명하는 예시예요. (실제 YAML 문법은 생략하지만 흐름을 이해해 보세요.)
먼저, `example.com`이라는 호스트로 들어오는 요청을 처리하도록 설정해요. 만약 사용자가 `example.com/user`로 접속하면 `user-service`로, `example.com/order`로 접속하면 `order-service`로 연결되도록 경로(Path)를 지정해요. 이때 반드시 주의해야 할 점은 경로의 우선순위예요. `/`와 같이 광범위한 경로를 먼저 정의하면, 구체적인 경로인 `/user`로 들어오는 요청이 제대로 전달되지 않을 수 있으니, 가장 구체적인 경로부터 위에서 아래로 배치해야 해요.
STEP 5. 카나리(Canary) 배포를 통한 안정적인 업데이트
마지막 단계는 운영의 묘미인 카나리 배포예요. 인그레스 컨트롤러는 트래픽의 일정 비율을 특정 버전의 서비스로 보내는 기능을 지원해요. 예를 들어, 새로운 버전의 `order-service`를 배포했을 때, 전체 트래픽의 5%만 신규 버전으로 보내보고 문제가 없는지 확인하는 거죠.
이 작업은 별도의 `Ingress` 리소스를 하나 더 만들고, `nginx.ingress.kubernetes.io/canary: “true”`라는 어노테이션을 추가하는 것만으로 가능해요. 저희는 이 기능을 통해 업데이트 시 발생하는 장애를 획기적으로 줄일 수 있었고, 개발 팀에서도 훨씬 자신 있게 배포할 수 있는 환경이 구축되었어요.
인그레스 설정 변경 후에는 반드시 `kubectl describe ingress` 명령어를 통해 이벤트 로그를 확인하세요. 설정 오류로 인해 트래픽이 유실되는 경우, 가장 먼저 확인해야 할 곳은 인그레스 컨트롤러의 로그와 인그레스 리소스의 상태입니다.
자주 하는 실수와 해결법 및 자주 묻는 질문
실무에서 인그레스를 운영하다 보면 이론과는 다른 당황스러운 상황들이 자주 발생해요. 저희가 직접 겪었던 사례를 바탕으로 실수와 해결법을 정리해 보았어요.
자주 하는 실수와 해결법
- ❌ 실수: 인그레스 리소스를 생성했는데 404 Not Found 에러가 발생해요.
이유: 인그레스 컨트롤러가 해당 인그레스 리소스를 인식하지 못했거나, 서비스의 이름(Service Name) 또는 포트(Port)가 잘못 지정된 경우가 많아요.
✅ 해결법: `kubectl get ingress`로 리소스가 정상 생성되었는지 확인하고, `kubectl describe ingress`를 통해 엔드포인트(Endpoints)가 실제 파드(Pod)의 IP를 제대로 가리키고 있는지 점검하세요. - ❌ 실수: SSL 인증서가 적용되지 않고 계속 HTTP로 연결돼요.
이유: Ingress 리소스의 `tls` 섹션 설정이 누락되었거나, 지정한 Secret 이름이 실제 인증서 Secret과 일치하지 않기 때문이에요.
✅ 해결법: `kubectl get secret`으로 인증서 이름이 맞는지 확인하고, Ingress 설정 파일에 호스트와 Secret 이름이 정확히 매칭되어 있는지 다시 한번 살펴보세요. - ❌ 실수: 특정 경로로 접속하면 503 Service Unavailable이 떠요.
이유: 인그레스 컨트롤러가 요청을 전달할 백엔드 서비스(Pod)를 찾지 못했거나, 서비스의 셀렉터(Selector)가 잘못되었을 때 발생해요.
✅ 해결법: 서비스(Service)와 파드(Pod) 사이의 라벨 매칭이 정확한지, 그리고 서비스가 올바른 포트를 열어두고 있는지 확인하세요. - ❌ 실수: 대용량 파일 업로드 시 요청이 끊겨요.
이유: NGINX 인그레스 컨트롤러의 기본 클라이언트 바디 크기(client_max_body_size) 제한 때문이에요.
✅ 해결법: 인그레스 리소스의 어노테이션에 `nginx.ingress.kubernetes.io/proxy-body-size: “50m”`와 같이 크기를 명시적으로 늘려주어야 해요. - ❌ 실수: 경로 기반 라우팅이 제대로 작동하지 않고 엉뚱한 서비스로 연결돼요.
이유: 경로 우선순위(Path Priority) 설정이 잘못되었기 때문이에요.
✅ 해결법: 더 구체적인 경로(예: `/api/v1/users`)를 더 짧은 경로(예: `/api`)보다 먼저 정의하거나, 정규표현식 사용 시 우선순위를 고려해야 해요.
자주 묻는 질문
Q. 인그레스와 로드밸런서(Service Type: LoadBalancer)의 차이가 정확히 무엇인가요?
로드밸런서는 클라우드에서 제공하는 L4 레벨의 장치로, 단순히 IP와 포트를 기반으로 트래픽을 넘겨줘요. 반면 인그레스는 L7 레벨에서 동작하며 URL 경로, 호스트 이름, 쿠키 등을 분석해 아주 세밀한 라우팅 규칙을 적용할 수 있어요. 인그레스는 하나의 로드밸런서 뒤에서 수많은 서비스를 관리할 수 있게 해주는 ‘관리자’ 역할을 한다고 보시면 돼요.
Q. 인그레스 컨트롤러를 꼭 NGINX로 써야 하나요?
그렇지는 않아요. 하지만 NGINX는 가장 레퍼런스가 많고 커뮤니티가 활성화되어 있어 초보자가 시작하기에 가장 좋아요. 만약 트래픽 양이 어마어마하게 많고 고성능 API 게이트웨이 기능이 핵심이라면 Kong을, 쿠버네티스 네이티브한 설정을 선호한다면 Traefik을 고려해 보세요.
Q. 인그레스 설정이 바뀌면 트래픽이 끊기나요?
일반적으로 NGINX 인그레스 컨트롤러는 핫 리로딩(Hot Reloading)을 지원하기 때문에 설정이 변경되어도 기존 연결이 끊기지 않고 자연스럽게 새로운 규칙이 적용돼요. 하지만 설정 오류가 포함된 채로 적용하면 즉시 장애로 이어질 수 있으니 주의가 필요해요.
Q. 인증서를 자동으로 갱신하는 방법이 정말 안전한가요?
네, Cert-manager를 사용하면 사람이 개입하지 않아도 만료 전 자동으로 갱신 프로세스가 진행되므로 매우 안전하고 효율적이에요. 다만, 갱신 과정에서 DNS 설정(Challenge 방식 사용 시)이 올바르게 유지되고 있는지는 주기적으로 모니터링해야 해요.
Q. Gateway API는 인그레스를 대체하는 건가요?
Gateway API는 인그레스의 한계를 극복하기 위해 나온 차세대 표준이에요. 인그레스보다 더 구조화되고 역할 분담(Infrastructure 관리자 vs 애플리케이션 개발자)이 명확하게 되어 있죠. 지금 당장은 인그레스가 주류지만, 장기적으로는 Gateway API로 넘어가는 추세라는 점을 알아두면 좋아요.
인그레스 운영을 마치며: 지속 가능한 트래픽 관리를 위하여
지금까지 인그레스 도입부터 구축, 그리고 운영 중 마주하는 문제들까지 실무적인 관점에서 자세히 살펴보았어요. 인그레스를 도입한다는 것은 단순히 기술 하나를 추가하는 것이 아니라, 우리 서비스의 네트워크 구조를 더 체계적이고 비용 효율적으로 재설계한다는 의미예요.
처음에는 설정 하나하나가 어렵게 느껴질 수 있지만, 한 번 제대로 구축해 놓으면 서비스가 늘어날수록 그 진가가 발휘될 거예요. 트래픽 관리의 자동화는 결국 개발자와 운영자가 더 가치 있는 비즈니스 로직에 집중할 수 있는 시간을 벌어다 주니까요.
- 서비스 규모에 맞는 인그레스 컨트롤러(NGINX, Kong 등)를 먼저 선택하세요.
- 클라우드 비용 절감을 위해 서비스마다 LoadBalancer를 만드는 습관을 버리세요.
- SSL 인증서는 Cert-manager를 통해 반드시 자동화하세요.
- 경로(Path) 설정 시에는 항상 구체적인 경로를 우선순위 상단에 두세요.
- 카나리 배포 기능을 활용해 업데이트 리스크를 최소화하세요.
- 설정 변경 후에는 반드시 컨트롤러의 로그와 엔드포인트를 확인하세요.
오늘 배운 내용을 바탕으로 지금 바로 진행 중인 프로젝트의 네트워크 구조를 점검해 보세요. 작은 설정 하나를 바꾸는 것만으로도 운영의 질이 달라질 수 있어요.
🚀 다음 단계로 나아가기
- 오늘 할 일: 현재 클러스터의 서비스 노출 방식(NodePort/LB) 리스트업하기
- 이번 주 할 일: 테스트 환경에 NGINX 인그레스 컨트롤러 설치해 보기
- 실행 직전 할 일: 도메인과 SSL 인증서 자동화 시나리오 설계하기
실습 환경에서 직접 적용해 보다가 막히는 부분이 있다면 언제든 댓글로 질문을 남겨 주세요. 함께 고민하며 해결해 나가면 좋겠습니다. 더 깊이 있는 쿠버네티스 지식이 궁금하시다면 쿠버네티스 인그레스 기본 개념 글이나 클러스터 구축 입문 글도 함께 읽어 보시는 것을 추천해요.
