왜 지금 인그레스 운영 사례에 주목해야 할까요
서비스 규모가 커지면서 갑자기 트래픽이 몰려오거나, 관리해야 할 도메인이 늘어날 때 당황한 적이 있나요? 처음에는 단순히 NodePort로 서비스를 외부로 노출하며 운영해도 큰 문제가 없었어요. 하지만 관리해야 할 마이크로서비스가 10개, 20개로 늘어나면서 각 서비스마다 별도의 로드밸런서를 할당하는 방식은 비용적으로나 관리 측면에서 감당하기 힘든 수준에 도달했어요.
매번 새로운 서비스를 띄울 때마다 클라우드 제공업체의 로드밸런서 비용이 청구되는 걸 보면 운영팀의 마음은 타들어 가기 마련이에요. 게다가 SSL 인증서를 각 서비스마다 개별적으로 적용하고 갱신하는 작업은 운영 리소스를 엄청나게 잡아먹는 주범이었죠. 결국 효율적인 트래픽 관리와 비용 절감을 위해 인그레스(Ingress) 도입은 선택이 아닌 필수였어요.
실제로 저희 팀에서도 인그레스를 도입하기 전까지는 서비스 하나를 추가할 때마다 인프라 설정이 뒤따라야 했고, 이 과정에서 설정 실수로 인해 서비스가 중단되는 아찔한 순간도 있었어요. 이번 글에서는 제가 현장에서 직접 겪은 인그레스 운영 사례를 바탕으로, 어떻게 설정을 최적화하고 예상치 못한 문제들을 해결했는지 생생하게 공유해 드릴게요.
이 글을 끝까지 읽고 나면 다음과 같은 것들을 확실히 얻어갈 수 있어요.
- 인그레스 도입이 왜 비용과 운영 효율을 높이는지 이해해요.
- 실제 운영 환경에서 사용하는 인그레스 구성 방식을 익혀요.
- 도입 과정에서 흔히 발생하는 트러블슈팅 경험을 내 것으로 만들어요.
- 효율적인 트래픽 라우팅을 위한 설정 팁을 배워요.
인그레스 도입 전 반드시 체크해야 할 기본 지식
인그레스를 무작정 설치한다고 해서 모든 문제가 해결되지는 않아요. 우리 서비스의 네트워크 구조가 어떤지, 현재 사용 중인 로드밸런싱 방식이 무엇인지 정확히 파악하는 것이 우선이에요. 단순히 ‘인그레스가 좋다더라’는 소문만 듣고 도입했다가는 오히려 트래픽 경로가 복잡해져서 디버깅만 더 힘들어질 수 있거든요.
가장 먼저 결정해야 할 것은 인그레스 컨트롤러(Ingress Controller)의 종류예요. 가장 대중적인 것은 Nginx 인그레스 컨트롤러이지만, 환경에 따라 HAProxy나 클라우드 전용 컨트롤러를 고려해야 할 때도 있어요. 어떤 컨트롤러를 선택하느냐에 따라 사용할 수 있는 기능과 설정 가능한 어노테이션(Annotation)의 종류가 완전히 달라지기 때문이에요.
인그레스는 규칙(Rule)을 정의하는 리소스이고, 실제로 그 규칙을 해석해서 트래픽을 전달하는 실체는 인그레스 컨트롤러라는 점을 명확히 구분해야 해요.
또한, 현재 운영 중인 서비스들의 도메인 구조를 미리 정리해 두어야 해요. 호스트 기반(Host-based)으로 나눌 것인지, 아니면 하나의 도메인 아래 경로(Path-based)로 구분할 것인지에 따라 인그레스 설정 파일의 복잡도가 크게 달라지거든요. 아래 표를 통해 현재 상황에 맞는 적절한 노출 방식을 비교해 보세요.
| 방식 | 주요 특징 | 추천 상황 | 비용 효율 |
|---|---|---|---|
| NodePort | 모든 노드의 특정 포트로 직접 접속 | 테스트 및 개발 환경 | 매우 높음 |
| LoadBalancer | 클라우드 제공 L4/L7 로드밸런서 사용 | 단일 서비스 운영 시 | 낮음 (서비스당 발생) |
| Ingress | 하나의 IP로 여러 도메인/경로 라우팅 | 마이크로서비스 운영 시 | 매우 높음 |
준비 단계에서 가장 간과하기 쉬운 점은 SSL/TLS 인증서 관리 계획이에요. 인그레스를 쓰면 인증서 관리가 편해지는 건 맞지만, 자동화(Cert-manager 등)를 고려하지 않고 수동으로 인증서를 업데이트하려 한다면 오히려 운영 지옥에 빠질 수 있어요. 따라서 도입 전 반드시 자동화 도구를 함께 검토해야 해요.
실전! 인그레스 구축부터 최적화까지의 단계별 과정
이제 본격적으로 저희 팀이 진행했던 인그레스 적용 과정을 단계별로 살펴볼게요. 단순히 명령어를 입력하는 것이 아니라, 왜 이런 설정을 선택했는지 그 이유에 집중해서 읽어주세요.
STEP 1. 인그레스 컨트롤러 설치 및 기본 환경 구성
저희는 가장 범용성이 높고 커뮤니티가 활발한 Nginx Ingress Controller를 선택했어요. 설치는 Helm을 사용하여 진행했는데, Helm을 쓰면 복잡한 설정값을 차트(Chart)를 통해 체계적으로 관리할 수 있어 매우 편리해요. 설치 시 가장 신경 쓴 부분은 컨트롤러 자체가 사용할 서비스 타입을 결정하는 것이었어요. 저희는 클라우드 환경이었기에 LoadBalancer 타입을 사용하여 컨트롤러에 외부 IP를 할당받았어요. 이렇게 하면 외부의 모든 트래픽이 하나의 로드밸런서를 거쳐 인그레스 컨트롤러로 들어오게 되고, 컨트롤러가 내부의 수많은 서비스로 트래픽을 쪼개주는 구조가 완성돼요.
STEP 2. Cert-manager를 이용한 SSL/TLS 자동화 구축
인그레스 도입의 가장 큰 목표 중 하나는 인증서 관리의 자동화였어요. 이를 위해 Cert-manager를 함께 설치했어요. Let’s Encrypt라는 무료 인증서 기관을 사용하도록 설정하고, HTTP-01 챌린지 방식을 선택해서 인증서 발급과 갱신이 사람의 손을 타지 않도록 만들었죠. 이제 인그레스 리소스에 `tls` 섹션만 적절히 정의해 주면, 컨트롤러가 알아서 인증서를 요청하고 갱신까지 완료해 줘요. 이 작업 하나만으로도 매년 돌아오는 인증서 만료 걱정에서 완전히 해방될 수 있었어요.
STEP 3. 정교한 경로 기반(Path-based) 라우팅 설정
저희 서비스는 하나의 메인 도메인을 사용하면서 기능별로 경로를 나누는 방식을 택했어요. 예를 들어, 메인 페이지는 `/`로, API 서버는 `/api`로, 정적 파일은 `/static`으로 나누는 식이죠. 이때 주의할 점은 경로 매칭 방식이에요. Nginx 인그레스에서는 `ImplementationSpecific`이나 `Prefix` 매칭을 주로 사용하는데, `/api`라고 설정했을 때 `/api/v1`까지 포함할 것인지 등을 꼼꼼히 테스트해야 해요. 설정 실수로 API 요청이 엉뚱한 곳으로 흘러가면 서비스 전체가 마비될 수 있으니까요.
STEP 4. 실무 운영을 위한 어노테이션(Annotation) 최적화
기본 설정만으로는 실전 트래픽을 감당하기 어려웠어요. 그래서 인그레스 리소스의 `metadata.annotations`를 적극적으로 활용했어요. 가장 효과적이었던 설정 몇 가지를 소개할게요.
- nginx.ingress.kubernetes.io/proxy-body-size: 클라이언트가 업로드하는 파일 크기 제한을 늘려줬어요. 기본값이 너무 작으면 이미지 업로드 시 413 Request Entity Too Large 에러가 발생하거든요.
- nginx.ingress.kubernetes.io/proxy-connect-timeout: 백엔드 서비스의 응답이 다소 늦어지는 경우를 대비해 타임아웃 시간을 적절히 늘려 연결 끊김을 방지했어요.
- nginx.ingress.kubernetes.io/enable-cors: 프론트엔드와 백엔드 도메인이 다를 때 발생하는 CORS 문제를 인그레스 레벨에서 쉽게 해결했어요.
이처럼 어노테이션을 잘 활용하면 애플리케이션 코드에 복잡한 로직을 넣지 않고도 인프라 계층에서 많은 문제를 해결할 수 있어요.
STEP 5. 모니터링 및 트래픽 가시성 확보
설정을 마쳤다면 이제 트래픽이 잘 흐르고 있는지 확인해야 해요. 저희는 Prometheus와 Grafana를 연결해서 인그레스 컨트롤러의 메트릭을 실시간으로 모니터링했어요. 초당 요청 수(RPS), 4xx/5xx 에러 발생 비율, 레이턴시(Latency) 등을 대시보드로 구성했죠. 갑자기 5xx 에러가 치솟는다면, 이는 인그레스 설정 문제인지 아니면 백엔드 파드(Pod)의 리소스 부족인지 즉시 판단할 수 있는 근거가 되었어요.
인그레스 설정 변경 후에는 반드시 `kubectl describe ingress [이름]` 명령어를 통해 이벤트 로그를 확인하세요. 설정 오류가 있다면 이곳에 상세한 이유가 기록됩니다.
실제 운영 시나리오를 예로 들어볼게요. 신규 API 버전인 `/v2`를 배포할 때, 저희는 기존 `/v1` 경로를 유지하면서 인그레스 리소스에 새로운 경로 규칙만 추가했어요. 테스트 환경에서 경로 매칭이 정확한지 확인한 뒤 적용하니, 사용자들에게 중단 없는 서비스 전환(Canary Deployment와 유사한 방식)이 가능했답니다.
자주 하는 실수와 해결법
인그레스를 운영하다 보면 누구나 한 번쯤은 겪게 되는 당혹스러운 순간들이 있어요. 저희 팀이 직접 겪고 해결했던 사례들을 정리해 드릴게요.
❌ 경로를 설정했는데 404 Not Found 에러가 떠요.
왜 발생하는가: 인그레스의 `path` 설정과 애플리케이션 내부의 컨텍스트 경로(Context Path)가 일치하지 않기 때문이에요. 예를 들어 인그레스는 `/api`로 요청을 보내는데, 앱은 `/`부터 시작하도록 만들어져 있다면 경로 불일치가 발생해요.
✅ 해결법: 인그레스 어노테이션 중 `rewrite-target`을 사용하여 경로를 재작성하거나, 애플리케이션의 베이스 경로를 인그레스 설정에 맞춰 수정하세요.
❌ 502 Bad Gateway 에러가 빈번하게 발생해요.
왜 발생하는가: 인그레스 컨트롤러가 백엔드 서비스(Pod)로 연결을 시도했으나, 서비스가 준비되지 않았거나 포트 번호가 잘못되었을 때 발생해요.
✅ 해결법: 서비스의 `targetPort`가 파드의 실제 포트와 일치하는지 확인하고, 파드의 Readiness Probe가 정상적으로 작동하여 트래픽을 받을 준비가 되었는지 점검하세요.
❌ SSL 인증서 적용 후 브라우저에서 보안 경고가 떠요.
왜 발생하는가: 인증서가 제대로 발급되지 않았거나, 인그레스 리소스의 `secretName`이 실제 생성된 인증서 Secret 이름과 다를 때 발생해요.
✅ 해결법: `kubectl get secret` 명령어로 인증서가 올바른 이름으로 존재하는지 확인하고, Cert-manager의 로그를 살펴 인증서 발급 과정에 오류가 없는지 체크하세요.
❌ 대용량 파일 업로드 시 요청이 끊겨요.
왜 발생하는가: Nginx 인그레스의 기본 `client_max_body_size` 설정값이 작기 때문이에요.
✅ 해결법: 어노테이션을 통해 `nginx.ingress.kubernetes.io/proxy-body-size` 값을 충분히 크게 설정하세요.
❌ 특정 요청만 응답 시간이 너무 길어요.
왜 발생하는가: 인그레스 컨트롤러와 백엔드 사이의 타임아웃 설정이 짧아서 연결이 먼저 끊기는 경우예요.
✅ 해결법: `proxy-connect-timeout`과 `proxy-read-timeout` 값을 늘려주세요.
자주 묻는 질문
Q. 인그레스와 로드밸런서(Service Type: LoadBalancer)의 차이는 무엇인가요?
로드밸런서는 클라우드에서 제공하는 개별적인 입구라고 생각하면 돼요. 반면 인그레스는 하나의 로드밸런서를 입구로 두고, 그 안에서 여러 개의 서비스로 길을 나누어주는 스마트한 안내원 역할을 해요. 비용 절감 측면에서 인그레스가 훨씬 유리합니다.
Q. Nginx 말고 다른 컨트롤러를 써도 괜찮을까요?
네, 물론이에요. 만약 클라우드 네이티브한 환경을 선호하거나 특수한 L7 기능이 필요하다면 Kong, Traefik, Istio Gateway 등을 고려해 볼 수 있어요. 다만, 초기 학습 곡선과 운영 난이도가 다르다는 점을 염те해야 해요.
Q. 인증서 갱신을 수동으로 해도 될까요?
소규모라면 가능하겠지만, 서비스가 커지면 절대 추천하지 않아요. 인증서 만료는 서비스 중단으로 직결되는 아주 위험한 사고이기 때문에, 반드시 Cert-manager 같은 도구를 통해 자동화하는 것이 실무의 정석이에요.
Q. 인그레스 하나에 너무 많은 서비스를 등록해도 성능에 문제가 없나요?
컨트롤러의 리소스(CPU, Memory)가 충분하다면 수십 개의 서비스도 거뜬해요. 다만, 설정 파일이 너무 거대해지면 반영 속도가 느려질 수 있으니, 필요하다면 인그레스 컨트롤러를 용도별로 분리하는 것도 방법이에요.
Q. 경로(Path) 설정 시 주의할 점이 있나요?
경로 매칭 우선순위를 꼭 확인해야 해요. 예를 들어 `/api`와 `/api/v1`이 동시에 있다면, 더 구체적인 경로가 먼저 매칭되도록 순서를 잘 관리하거나 정규표현식을 활용해야 합니다.
인그레스 운영, 이것만은 꼭 기억하세요
인그레스 도입은 단순한 기술적 변화를 넘어, 인프라 운영의 효율성을 극대화하는 전환점이에요. 비용은 줄이고, 관리는 자동화하며, 서비스 확장성은 높일 수 있으니까요. 하지만 그만큼 네트워크 경로가 복잡해지기 때문에 꼼꼼한 설계와 모니터링이 뒷받침되어야 한다는 점을 잊지 마세요.
- 인그레스 컨트롤러(Nginx 등)를 먼저 선정하고 설치하세요.
- 인증서 관리는 Cert-manager로 반드시 자동화하세요.
- 서비스 경로(Path) 설계 시 앱의 컨텍스트 경로와 일치시키세요.
- 어노테이션을 활용해 타임아웃과 파일 크기 제한을 최적화하세요.
- Prometheus/Grafana를 통해 트래픽 가시성을 확보하세요.
- 설정 변경 후에는 반드시 Ingress 리소스의 이벤트를 확인하세요.
오늘 바로 실무에 적용해 보고 싶다면, 다음 단계를 따라 해 보세요.
- 오늘 할 일: 현재 운영 중인 서비스의 로드밸런서 비용과 개수를 파악해 보세요.
- 이번 주 할 일: 테스트 클러스터에 Nginx Ingress Controller와 Cert-manager를 설치해 보세요.
- 실행 직전 할 일: 실제 도메인을 연결하기 전, 경로 기반 라우팅 테스트 시나리오를 작성해 보세요.
인그레스 설정 중에 예상치 못한 에러를 만나거나, 특정 환경에서 설정이 잘 안 풀린다면 혼자 고민하지 마세요. 댓글로 질문을 남겨 주시면 제가 아는 선에서 최대한 자세히 답변해 드릴게요. 함께 성장하는 개발자가 되었으면 좋겠습니다!
함께 읽으면 도움이 되는 글:
– 쿠버네티스 인그레스 기본 개념 글
– 클러스터 구축 입문 글
