쿠버네티스 커뮤니티는 Ingress NGINX가 2026년 3월에 은퇴할 것이라고 발표했습니다. 그 이후에는 업데이트, 버그 수정, 보안 패치가 더 이상 없을 것입니다. 이 결정은 수년간 1-2명의 개발자만이 밤과 주말에 일하며 프로젝트를 유지해왔고, 올해 초 심각한 보안 문제(IngressNightmare CVE-2025-1974)로 인해 프로젝트가 더 많은 자원이 필요하다는 점이 분명해진 후에 내려졌습니다.
기존 배포는 계속 작동하지만, 보안 업데이트 없이 실행되는 것은 위험하며 추가 기능 개발은 없을 것입니다.
선택지(그리고 NGINX OSS를 고려해 주시길 바라는 이유)
Traefik, HAProxy, Kong, Envoy 기반 옵션, 게이트웨이 API 구현 등 여러 좋은 Ingress 컨트롤러가 있습니다. Kubernetes 문서에는 많은 이들이 나열되어 있고, 각각이 강점이 있습니다.
여러분 중 일부는 F5가 OSS를 허용 라이선스 받은 NGINX 인그레스 컨트롤러를 유지하고 있다는 것을 알고 계실 겁니다. 이 프로젝트는 오픈 소스이며 Apache 2.0 라이선스를 받았으며 앞으로도 그럴 것입니다. 이 프로젝트에는 전담 엔지니어 팀이 있으며, 앞으로 여러 업그레이드가 예정되어 있습니다. 이미 NGINX에 익숙하고 큰 문제 없이 작동하는 무언가를 원한다면, Kubernetes용 F5 NGINX Ingress Controller가 가장 원활한 선택이라고 믿습니다.
우리가 실제로 좋아할 거라고 생각하는 이유는 다음과 같습니다:
진정한 오픈 소스: Apache 2.0은 F5뿐만 아니라 다양한 조직의 150+ 기여자들과 라이선스를 받았습니다. 모든 개발은 GitHub에서 공개적으로 이루어지며, F5는 이를 영원히 오픈 소스로 유지하겠다고 약속했습니다. 게다가 2주마다 커뮤니티 콜도 있습니다.
학습 곡선 최소화: 이미 알고 계신 동일한 NGINX 엔진을 사용합니다. 대부분의 Ingress NGINX 주석은 직접적인 대응 함수를 제공하며, 마이그레이션 가이드는 기존 구성에 대한 명확한 매핑을 제공합니다.
지속 가능한 유지보수: F5의 전담 전담 팀이 정기적인 보안 업데이트, 버그 수정, 기능 개발을 보장합니다.
대규모 프로덕션 테스트: 약 40%의 Kubernetes Ingress 배포를 구동하며 1,000만 건 이상의 다운로드를 지원합니다. 실제 제작 환경에서 검증된 제품입니다.
Kubernetes 네이티브 설계: 커스텀 리소스 정의(VirtualServer, Policy, TransportServer)는 주석 과부하보다 더 깔끔한 구성을 제공하며, 오류를 방지하기 위한 내장 검증 기능을 제공합니다.
필요할 때 사용할 수 있는 고급 기능: 캐너리 배포 지원, A/B 테스트, 트래픽 분할, JWT 검증, 속도 제한, mTLS 등 오픈 소스 버전에서 이용 가능합니다.
미래 지향적인 아키텍처: NGINX 게이트웨이 패브릭의 적극적인 개발은 게이트웨이 API로 전환할 준비가 되었을 때 명확한 마이그레이션 경로를 제공합니다.
선택적 상업적 지원: OSS 버전은 견고하지만, NGINX Plus 통합은 적극적인 건강 점검, 동적 재구성, 고급 세션 지속성 및 상업용 지원이 필요한 기업을 위해 제공됩니다.
NGINX 인그레스 컨트롤러로 전환하기
대략적인 이주 가이드를 소개합니다. 또한 저희 문서 사이트에서 더 자세한 마이그레이션 가이드를 확인하실 수 있습니다.
1단계: 점검
현재 사용 중인 내용을 확인하세요: 현재 Ingress 리소스, Annotation, ConfigMaps 문서를 문서화하세요 스니펫 확인: 주석을 식별하세요 nginx.ingress.kubernetes.io/configuration-snippet 사용 중인지 확인하세요: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 설정하기: 현재 설정을 유지하면서 NGINX Ingress Controller를 별도의 네임스페이스에 설치하세요
2단계: 설정 변환
Annotation 변환: 기존 주석 대부분은 NGINX Ingress Controller에 대응하는 항목들이 있습니다 VirtualServer 리소스 고려: 이 커스텀 리소스는 Annotation이 많은 Ingress보다 더 깔끔하고 더 많은 제어권을 제공하지만, 선택은 본인에게 달려 있습니다 또는 Ingress를 계속 사용하세요: 최소한의 변경만 원한다면 표준 Kubernetes Ingress 리소스와 잘 작동합니다 예외 처리: 직접 매핑되지 않는 경우에는 스니펫이나 정책 리소스를 사용할 수 있습니다
3단계: 모든 것을 시험하기
테스트 앱으로 시도해 보세요: NGINX Ingress 컨트롤러를 가리키는 테스트 Ingress 규칙을 만들어 보세요 두 컨트롤러를 나란히 운영하기: 두 컨트롤러를 계속 작동시키고 테스트 트래픽은 새 컨트롤러를 통해 라우팅하세요 기능 확인: 라우팅, SSL, 속도 제한, CORS, 인증 등 사용 중인 모든 것을 확인하세요 성능 점검: 트래픽을 원하는 방식으로 처리하는지 확인하세요
4단계: 점진적으로 이동하기
작게 시작하세요: 덜 중요한 애플리케이션부터 마이그레이션하세요 트래픽을 천천히 이동시키기: DNS와 라우팅을 조금씩 업데이트하세요 주의 깊게 지켜보세요: 진행하면서 로그와 지표를 주시하세요 RollBack 준비 : 문제가 생기면 롤백할 수 있도록 하세요
5단계: 마무리
마이그레이션 완료: 남은 Ingresss 를 이전 오래된 컨트롤러 정리하기: 모든 것이 이동한 후 커뮤니티 인그레스 NGINX를 제거하세요 정리하기: 더 이상 필요하지 않은 오래된 ConfigMap과 리소스를 제거하세요
NGINX 인그레스 컨트롤러가 왜 합리적인가 (요약)
사실 오픈 소스입니다 Apache 2.0 하에서 완전 오픈 소스로 전환하며, 독점 시스템에 얽매이지 않습니다 여러 조직에서 온 150명 이상의 기여자들(F5 직원뿐만 아니라) 모든 개발은 GitHub에서 공개적으로 이루어집니다 F5는 오픈 소스를 유지하는 데 전념하고 있으며, 이는 우리 비즈니스 모델의 핵심입니다 이 프로젝트는 F5의 지속 가능한 지원과 투자를 받고 있습니다
익숙한 영역이에요 이미 알고 계신 것과 같은 NGINX 엔진이 아래에 들어가 있습니다 Ingress NGINX를 사용해보셨다면 이미 Ingress Controller가 하는 대부분의 기능을 이해하실 겁니다 마이그레이션 문서에는 기존 설정 대부분에 대한 직접 매핑이 나와 있습니다 완전히 새로운 것을 배우는 게 아니에요
적극적으로 유지보수되고 있습니다
F5 NGINX의 전담 엔지니어들 정기 업데이트 및 보안 패치 쿠버네티스 배포의 약 40%가 이를 사용하므로 충분히 검증된 상태입니다 필요하다면 상업용 지원도 가능합니다
오늘부터 내일로 가는 길을 도와주세요
원활한 전환을 위해 방대한 이주 가이드를 준비해 두었습니다 상업용 버전으로 전환해야 한다면, 주석 및 기타 맞춤화 기능을 NGINX로 번역하는 데 도움을 드릴 수 있습니다 NGINX 팀은 게이트웨이 API 구현인 NGINX 게이트웨이 패브릭 솔루션도 보유하고 있습니다
다른 선택지는 어떤가요? 게이트웨이 API는 미래이지만 아직 성숙해지고 있습니다. Traefik, HAProxy, Kong은 모두 괜찮지만, 이미 NGINX를 사용 중이고 가장 원활한 Ingress 를 원한다면 NGINX Ingress Controller가 최선의 선택이라고 생각합니다.
대부분의 조직에서 컨테이너화된 워크로드를 배포하고 관리하기 위해 쿠버네티스를 선택하는 플랫폼입니다. 하지만 AI 워크로드는 기존 마이크로서비스보다 훨씬 더 일관되고 예측 가능하며, 복잡성이 더욱 높아집니다. 조직이 이러한 과제를 인지하지 못한다면 비용 초과, 낮은 리소스 활용도, 보안 취약성으로 인해 AI 속도가 저하되고 가치가 감소하며 위험이 증폭될 수 있습니다. 투자를 보호하기 위해 조직은 AI에 쿠버네티스를 사용하는 방식에 대해 더욱 지능적인 접근 방식을 취해야 합니다.
AI에 쿠버네티스를 사용할 때의 과제
AI는 기존 워크로드와 다릅니다. 프롬프트는 간단한 텍스트 쿼리부터 멀티미디어 기반 분석까지 다양할 수 있으며, 이로 인해 GPU 리소스에 대한 요구량이 가변적입니다. 컨테이너 인그레스 컨트롤러는 GPU 가용성을 파악하는 데 어려움을 겪기 때문에 기본 라운드 로빈 배포 방식은 일부 GPU를 혼잡하게 만들고 다른 GPU는 활용도가 낮게 만듭니다.
또한 AI는 관리하기 어려운 복잡한 분산 서비스와 API 웹에 의존하며, 공격 표면이 더 넓어 보안이 더욱 어렵습니다. AI는 이러한 복잡성 때문에 매력적인 공격 대상이 되었으며, 사이버 범죄자들은 AI 모델 자체를 공격 벡터로 사용하고 있습니다. 즉각적인 주입 및 모델 조작과 같은 기법은 기존 보안 메커니즘을 우회하여 AI에서 민감한 데이터를 추출하고, 공격자는 AI에 잘못된 프롬프트를 대량으로 전송하여 모델의 응답성을 저하시키고 리소스를 더욱 고갈시킬 수 있습니다. 기존의 쿠버네티스 보안은 이러한 유형의 공격을 방어하도록 설계되지 않았습니다.
쿠버네티스에서 진정으로 동적이고 효율적이며 안전한 AI를 구현하려면 AI별 요구 사항을 충족하고 그에 따라 워크로드를 할당하는 트래픽 관리가 필요합니다. 여기에는 요청 복잡성 및 GPU 가용성을 인식하고 리소스와 AI 처리량 간의 비선형 관계를 고려하는 것이 포함됩니다. 컨테이너 기반 보안 제어는 AI 모델을 보호하고 무단 사용 및 악용 전략의 접근 지점이 되는 것을 방지하는 데 필수적입니다.
쿠버네티스에서 안전하고 최적화된 AI 제공
F5 솔루션은 운영, 보안 및 성능 격차를 해소하여 Amazon Elastic Kubernetes Service(EKS) 배포를 보완합니다.
F5 NGINX Ingress Controller는 AI 인식 인그레스 및 로드 밸런싱을 제공하며, 수요 급증 및 파드 장애 발생 시에도 가동 시간을 유지하기 위한 동적 재구성을 지원합니다. 또한 블루-그린 및 카나리아 릴리스 전략과 원활한 배포 및 최적화를 위한 A/B 테스트를 지원하는 도구도 제공합니다.
F5 NGINX App Protect는 경량 웹 애플리케이션 방화벽(WAF), 레이어 7 분산 서비스 거부(DDoS) 보호, API 보안을 제공합니다. 이 제품은 NGINX Ingress Controller와 함께 F5 NGINX Plus에 포함되어 제공되며 쿠버네티스 클러스터로 원활하게 확장됩니다.
F5는 Amazon EKS에 AI 인식 트래픽 관리 및 보호 기능을 제공합니다.
F5는 Amazon EKS에 AI 인식 트래픽 관리 및 보호 기능을 제공합니다.
분산형 AI를 위한 쿠버네티스 활용
F5 AI Gateway는 하이브리드 멀티클라우드 환경에서 쿠버네티스의 AI 서비스를 원활하게 지원하는 또 다른 옵션입니다. 시맨틱 캐싱을 포함한 AI 인식 트래픽 관리 기능을 활용하면 중복 처리를 최소화하고 토큰을 절약할 수 있습니다.
다층적인 보호 기능은 고유한 AI 위협으로부터 보호하여 OWASP Top 10 for LLMs를 충족하는 동시에 아웃바운드 응답에서 민감한 데이터 유출 및 환각 현상을 방지합니다. AI Gateway는 OpenAI, Anthropic, Ollama를 포함한 주요 AI 플랫폼과 HTTP 기반 언어 모델을 지원하여 배포 위치에 관계없이 일관된 보호 기능을 제공합니다.
F5 AI Gateway는 하이브리드 멀티클라우드 환경에서 AI 제공을 간소화합니다.
AI 인식 접근 방식으로 더 나은 성과 달성
F5 솔루션을 Amazon EKS와 함께 구현하면 더 빠른 모델 응답 시간과 AI 관련 위협으로부터 보호하는 지능형 트래픽 관리 기능을 구현할 수 있습니다. 다음과 같은 이점이 있습니다.
AI 인식 워크로드 분산. 최소 시간 로드 밸런싱 및 활성 상태 확인을 통해 AI 요청을 가장 응답성이 높은 서비스로 전달합니다.
포괄적인 관측 가능성. F5 솔루션은 프롬프트 볼륨, 토큰 사용량, 추론 지연 시간, 모델 성능 통계와 같은 주요 지표를 제공하여 최적화 노력을 가속화합니다.
트래픽 보호. 속도 제한은 리소스 남용을 방지하고, 회로 차단은 장애를 격리하며, 요청 버퍼링은 트래픽 급증에 대처하는 데 도움이 됩니다.
AI 관련 위협 완화. 내장된 보안 기능은 AI 모델 공격을 차단하는 동시에 민감한 데이터 유출을 방지합니다.
ID 관리 및 액세스 제어. JSON 웹 토큰, OpenID Connect, 역할 기반 액세스 제어(RBAC)를 지원하여 권한이 있는 사용자와 서비스만 AI 엔드포인트에 액세스할 수 있도록 합니다.
지금 바로 쿠버네티스에서 AI 워크로드를 최적화하세요
AI에 있어서 어떤 최적화도 간과할 수 없습니다. F5 솔루션은 AWS, 온프레미스, 하이브리드 멀티클라우드 등 모든 환경에서 일관되게 작동하며 쿠버네티스에서 AI의 고유한 과제를 해결합니다.
AI가 원활하고 안정적으로 실행되도록 지원하며, 현재와 미래의 위협으로부터 더욱 강화된 보호 기능을 제공합니다. 확보할 수 있는 모든 이점은 경쟁이 치열하고 끊임없이 변화하는 이 환경에서 AI 프로젝트의 성공을 실현하는 데 한 걸음 더 다가가게 합니다.
위 내용과 같이 NGINX Ingress Controller 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
Kubernetes 커뮤니티가 Gateway API의 일반 가용성을 공식적으로 발표한 지 거의 1년 반이 지났습니다. 이는 Kubernetes 클러스터에서 네트워킹 및 트래픽 관리가 처리되는 방식을 재정의한 이정표입니다. 이는 단순한 증분적 업데이트 이상이었습니다. 이는 클라우드 네이티브 환경의 네트워킹에서 근본적인 변화를 나타내며 연결을 관리하기 위한 강력하고 확장 가능하며 표현력이 뛰어난 프레임워크를 제공합니다.
Gateway API는 Ingress API의 제한된 기능을 역할 중심 설계, 표준화된 리소스 및 확장성으로 대체합니다. 고급 트래픽 라우팅 및 분할을 도입하는 것부터 역할 중심 설계로 멀티 테넌시를 활성화하는 것까지 Gateway API는 이전에 처리하기 어려웠던 복잡한 사용 사례를 잠금 해제합니다. F5를 포함한 공급업체가 Kubernetes 네트워킹의 미래를 형성할 수 있는 잠재력을 인식함에 따라 이러한 변화가 업계 전반에 걸쳐 광범위한 혁신을 촉진한 것은 놀라운 일이 아닙니다.
그러나 이와 같은 새로운 표준을 채택하는 것은 하룻밤 사이에 이루어지지 않습니다. Gateway API는 명확한 이점을 제공하지만 많은 조직은 여전히 신중합니다. 그들은 Gateway API의 표준화되고 유연한 라우팅 구성에 비해 마이그레이션과 기존 Ingress 툴링의 복잡성을 신중하게 평가하고 있습니다. 그리고 채택을 결정한 것은 기술적 한계에 의해서만 이루어진 것이 아니라 상쇄에 대한 것입니다. 전환에 따른 시간, 노력 및 위험은 네트워킹 기능에 대한 의미 있고 실질적인 개선으로 상쇄되어야 합니다.
업계 전체에서 채택 속도가 느린 것은 이러한 신중한 접근 방식을 반영합니다. Gateway API가 Kubernetes 네트워킹의 미래로 널리 알려져 있지만, 많은 조직이 본격적인 채택을 하기 전에 여전히 그 기능을 탐색하거나 상쇄 효과를 평가하고 있습니다. Kubernetes 커뮤니티의 보고서에 따르면 Gateway API에 대한 실험이 꾸준히 증가하고 있습니다. 조기 채택자는 간단한 HTTP 라우팅에서 고급 멀티 테넌트 아키텍처에 이르기까지 다양한 사용 사례에 이를 활용하고 있습니다. 이는 많은 팀이 기다리고 보는 접근 방식을 취하고 있음에도 불구하고 Gateway API의 가능성에 대한 관심이 커지고 있음을 보여줍니다.
F5에서 우리는 비슷한 역학 관계를 관찰했습니다. 많은 고객이 즉각적인 도약을 미루고 있습니다. 이는 관심이 부족해서가 아니라, 성숙한 Ingress 솔루션이 제공하는 운영적 확실성과 혁신의 균형을 맞추는 데 집중하고 있기 때문입니다. 그렇기 때문에 Gateway API로의 여정은 서두를 필요가 없다고 생각합니다. 그저 전략적이어야 합니다.
분석해 보겠습니다. Gateway API로 이동하는 데 따른 몇 가지 과제는 다음과 같습니다.
복잡한 인프라 개편: 마이그레이션에는 자동화를 다시 작성하고 기존 애플리케이션 파이프라인을 변경해야 할 수 있습니다.
생태계 지원 격차: 전체 도구 및 컨트롤러 지원은 아직 발전 중입니다.
시간과 전문성 부족: 학습 곡선과 리팩토링에 전담 시간이 필요합니다.
위험 회피: 팀은 이미 잘 되고 있는 일을 방해하는 것을 꺼립니다.
하지만 상당한 이점도 있습니다.
역할 중심 설계: Gateway API 리소스는 조직 역할에 따라 구분됩니다. 이를 통해 개발자는 다른 팀을 방해하지 않는 변경을 할 수 있습니다.
표준화된 트래픽 정책: 많은 공통 트래픽 정책이 API 자체에 긴밀하게 통합되어 있어 구현 전반에서 구성을 보편적으로 적용할 수 있으며 Ingress 주석보다 훨씬 관리하기 쉽습니다.
확장성: 확장 포인트를 사용하면 구현 시 Gateway API를 확장하여 API 프레임워크에서 사용자 정의 기능을 제공할 수 있습니다.
앱 제공과 인프라에 대해 우리가 아는 것이 있다면, 그것은 이것입니다. 변화에는 시간과 회사 전체의 설득이 필요합니다. 전환을 시작하는 데도 지속적인 지원, 지침, 혁신이 필수적입니다.
Gateway API 도입에 대한 대처: F5의 통찰력
F5에서 우리는 쿠버네티스 네트워킹의 개발과 진화에 깊이 관여했습니다. 우리는 직접 도전에 참여하여 팀이 이를 극복하도록 도왔습니다.
저희의 경험은 한 가지 핵심 진실을 확인시켜 줍니다. Gateway API를 성공적으로 도입하는 것은 단순히 새로운 표준을 구현하는 것이 아닙니다. 미래의 성공을 위한 기반을 구축하는 것입니다. 이를 위해 조직은 단순성, 성능, 유연성 및 견고한 지원을 우선시하는 솔루션이 필요합니다. 이러한 원칙이 어떻게 원활한 전환을 위한 길을 만들고 장기적 가치를 위한 무대를 마련하는지 살펴보겠습니다.
클린 슬레이트 접근 방식을 통한 단순성: Gateway API로 마이그레이션하려면 기술적 변화 이상이 필요합니다. 문화적, 운영적 변화입니다. 클린 슬레이트를 사용하면 Ingress의 모든 페인트 포인트를 해결하고 단일 인터페이스인 Gateway API를 통해 우수한 네트워킹 경험을 얻을 수 있습니다. 이를 위해 더 많은 사전 노력이 필요할 수 있지만, 간소화된 프로세스, 감소된 오버헤드, 더 빠른 결과와 같은 장기적인 이점이 과제보다 훨씬 더 중요합니다.
기반으로서의 성능: 네트워크 성능은 특히 대규모 Kubernetes 환경에서 매우 중요합니다. Lean Gateway API 구현은 아키텍처 오버헤드를 최소화하기 위해 노력하는 데이터 플레인에 의존해야 하며, 이는 지연 시간, 리소스 효율성 및 확장성을 개선합니다. 솔루션은 Gateway API의 유연성과 기본적으로 높은 성능을 결합하여 팀이 속도나 안정성을 손상시키지 않고 전환할 수 있도록 해야 합니다.
모듈식 설계를 통한 유연성: Kubernetes 환경은 기본 라우팅 요구 사항에서 복잡한 아키텍처에 이르기까지 매우 다양합니다. 모듈식 Gateway API 솔루션을 사용하면 팀이 서비스 메시와 같은 다른 솔루션과 함께 기능을 채택하여 복잡성을 추가하지 않고도 환경의 요구 사항에 맞출 수 있습니다. 이러한 접근 방식은 실험을 촉진하고 솔루션이 확장 가능하고 적응 가능한 상태를 유지하도록 보장합니다.
성공 촉매로서의 지원: Gateway API를 채택할 때 전문가의 안내가 큰 도움이 될 수 있습니다. 포괄적인 문서, 신뢰할 수 있는 리소스, 실무 지원은 Ingress에서 전환하는 데 따른 마찰을 줄여줍니다. 신뢰할 수 있는 파트너와 커뮤니티 참여는 마이그레이션을 극적으로 단순화하여 어려운 전환을 원활하고 효율적인 프로세스로 전환합니다.
미래는 Gateway API입니다... 당신의 속도에 맞춰서
우리는 18개월이라는 시간이 그렇게 긴 시간이 아니라는 것을 알고 있습니다. 그리고 Gateway API가 수많은 가능성을 열었다고 해서 모든 조직이 당장 이를 도입할 준비가 되었다는 것은 아니라는 것도 알고 있습니다.
많은 팀에게 Ingress API는 유능한 솔루션일 뿐만 아니라 기존 인프라의 중요한 구성 요소이기도 합니다. Ingress API는 수년간 Kubernetes 네트워킹의 중추 역할을 해왔습니다. 잘 정립된 환경을 갖춘 조직은 안정적이고 성공적인 솔루션을 포기해야 한다고 느낄 필요가 없습니다.
F5에서는 이러한 현실을 깊이 인식하고 있기 때문에 Ingress API를 포기하지 않습니다. F5 NGINX Ingress Controller 개발에 계속 투자하여 현대적 사용 사례에 적합하고, 견고하고, 안전하고, 관련성이 있는 혁신과 기능을 제공합니다.
Ingress에 머물고자 하는 조직의 경우, 우리는 그것이 오늘날의 Kubernetes 워크로드를 자신 있게 구동하는 고가치 솔루션으로 유지되도록 하는 데 전념합니다. Gateway API를 탐색하는 팀의 경우, 우리의 목적에 맞게 구축된 F5 NGINX Gateway Fabric은 현대적인 단순성, 성능 및 유연성을 결합하여 조직이 자신 있게 표준을 채택할 수 있도록 돕습니다.
Gateway API로 전환하기 로 한 결정은 하룻밤 사이에 일어날 수 있는 중대한 변화일 필요는 없습니다. 그러나 궁극적으로 전환하는 조직은 성장과 혁신을 위해 스스로를 위치시키는 동시에 Kubernetes 네트워킹의 미래를 형성할 현대적이고 확장 가능하며 상호 운용 가능한 시스템으로 미래의 성공을 위한 기반을 마련하게 됩니다.
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
처음으로 Kubernetes를 설정하는 많은 조직은 Kubernetes 커뮤니티에서 개발하고 유지 관리하는 NGINX Ingress 컨트롤러( kubernetes/ingress-nginx )로 시작합니다. 그러나 Kubernetes 배포가 성숙해짐에 따라 일부 조직은 NGINX를 데이터 플레인으로 유지하면서 고급 기능이 필요하거나 상업적 지원을 원한다는 것을 알게 됩니다.
한 가지 옵션은 F5 NGINX( nginxinc/kubernetes-ingress ) 가 개발하고 유지 관리하는 NGINX Ingress Controller로 마이그레이션하는 것입니다 . 여기서는 두 프로젝트 간의 차이로 인해 발생할 수 있는 몇 가지 복잡한 문제를 피할 수 있도록 전체적인 지침을 제공합니다.
이러한 옵션이 어떻게 다른지 잘 모르시겠습니까? 저희 블로그에서 Ingress Controller 선택 가이드, 4부: NGINX Ingress Controller 옵션을 읽어보세요.
이 게시물의 나머지 부분에서 두 프로젝트를 구별하기 위해 Kubernetes 커뮤니티( kubernetes/ingress-nginx )에서 유지 관리하는 NGINX Ingress Controller를 "커뮤니티 Ingress 컨트롤러"라고 하고 F5 NGINX( nginxinc/kubernetes-ingress )에서 유지 관리하는 NGINX Ingress 컨트롤러를 "NGINX Ingress 컨트롤러"라고 합니다.
커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 방법에는 두 가지가 있습니다.
옵션 1: NGINX Ingress 리소스를 사용하여 마이그레이션하기 이는 최적의 솔루션입니다. NGINX Ingress 리소스는 프로덕션 등급 Kubernetes 환경에 필요한 광범위한 Ingress 네트워킹 기능을 지원하기 때문입니다. NGINX Ingress 리소스에 대한 자세한 내용은 NGINX Ingress Controlle r을 사용한 고급 Kubernetes 배포 웨비나를 시청하세요 .
옵션 2: Kubernetes Ingress 리소스를 사용하여 마이그레이션 이 옵션은 표준 Kubernetes Ingress 리소스를 사용하여 Ingress 부하 분산 규칙을 정의하려는 경우 권장됩니다.
옵션 1: NGINX Ingress 리소스를 사용하여 마이그레이션
이 마이그레이션 옵션을 사용하면 표준 Kubernetes Ingress 리소스를 사용하여 루트 기능을 설정하고 NGINX Ingress 리소스를 사용 하여 구성을 개선하여 기능을 향상시키고 사용 편의성을 높일 수 있습니다.
NGINX Ingress 리소스( VirtualServer, VirtualServerRoute , TransportServer , GlobalConfiguration 및 Policy ) 에 대한 사용자 정의 리소스 정의(CRD)를 사용하면 구성의 다양한 부분에 대한 제어를 다양한 팀(예: AppDev 및 보안 팀)에 쉽게 위임할 수 있으며, 구성 안전성과 유효성 검사도 더욱 강화할 수 있습니다.
SSL 종료 및 HTTP 경로 기반 라우팅 구성
spec이 표는 표준 Kubernetes Ingress 리소스의 필드 에 있는 SSL 종료 및 Layer 7 경로 기반 라우팅 구성을 specNGINX VirtualServer 리소스의 필드와 매핑합니다. 두 리소스의 구문과 들여쓰기는 약간 다르지만 동일한 기본 Ingress 기능을 수행합니다.
커뮤니티 Ingress 컨트롤러를 사용하면 Kubernetes ConfigMap API 객체가 TCP 및 UDP 서비스를 노출하는 유일한 방법 입니다 .
NGINX Ingress Controller를 사용하면 TransportServer 리소스는 TCP/UDP 및 TLS Passthrough 로드 밸런싱을 위한 광범위한 옵션을 정의합니다. TransportServer 리소스는 GlobalConfiguration 리소스와 함께 사용되어 인바운드 및 아웃바운드 연결을 제어합니다.
자세한 내용은 블로그의 NGINX Ingress 리소스에서 TCP, UDP 및 TLS 패스스루 서비스 지원을 참조하세요.
커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 리소스로 변환
프로덕션 수준의 Kubernetes 배포에서는 카나리아 및 블루그린 배포, 트래픽 제한, 인그레스-이그레스 트래픽 조작 등을 포함한 고급 사용 사례를 구현하기 위해 기본 Ingress 규칙을 확장해야 하는 경우가 많습니다.
커뮤니티 Ingress 컨트롤러는 Kubernetes 주석 으로 이러한 사용 사례 중 많은 부분을 구현합니다 . 그러나 이러한 주석 중 많은 부분은 매우 구체적인 NGINX Ingress 리소스 정의와 관련된 사용자 지정 Lua 확장으로 빌드되었으며 결과적으로 안정적이고 지원되는 프로덕션 환경에서 고급 기능을 구현하는 데 적합하지 않습니다.
다음 섹션에서는 커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 컨트롤러 리소스로 변환하는 방법을 보여줍니다.
카나리아 배포
교통 통제
헤더 조작
프록싱 및 로드 밸런싱
mTLS 인증
세션 지속성(NGINX Plus 전용)
카나리아 배포
프로덕션 컨테이너 워크로드에 빈번한 코드 변경을 푸시하더라도 기존 사용자에게는 계속 서비스를 제공해야 합니다. Canary 및 Blue‑Green 배포를 통해 이를 수행할 수 있으며, NGINX Ingress Controller 데이터 플레인에서 이를 수행하여 프로덕션 등급 Kubernetes 환경에서 안정적이고 예측 가능한 업데이트를 달성할 수 있습니다.
이 표는 카나리아 배포를 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .
커뮤니티 Ingress 컨트롤러는 다음 우선순위에 따라 카나리아 주석을 평가합니다.
nginx.ingress.kubernetes.io/canary-by-header
nginx.ingress.kubernetes.io/canary-by-cookie
nginx.ingress.kubernetes.io/canary-by-weight
NGINX Ingress Controller가 이를 동일한 방식으로 평가하려면 NGINX VirtualServer 또는 VirtualServerRoute 매니페스트에 해당 순서대로 나타나야 합니다
애플리케이션이 본질적으로 일시적이어서 오류 응답을 반환할 가능성이 더 높은 마이크로서비스 환경에서 DevOps 팀은 회로 차단 및 속도 및 연결 제한과 같은 트래픽 제어 정책을 광범위하게 사용하여 애플리케이션이 정상적이지 않거나 예상대로 작동하지 않을 때 오류 조건이 발생하지 않도록 합니다.
이 표에서는 속도 제한 , 사용자 정의 HTTP 오류 , 사용자 정의 기본 백엔드 및 URI 재작성을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .
표에 표시된 대로, 이 글을 쓰는 시점에서 NGINX Ingress 리소스에는 다음 네 가지 커뮤니티 Ingress 컨트롤러 주석을 직접 변환하는 필드가 포함되어 있지 않으며, 스니펫을 사용해야 합니다. Policy 리소스를 사용하여 네 가지 주석에 대한 직접 지원은 NGINX Ingress Controller의 향후 릴리스에서 계획되어 있습니다.
nginx.ingress.kubernetes.io/limit-connections
nginx.ingress.kubernetes.io/limit-rate
nginx.ingress.kubernetes.io/limit-rate-after
nginx.ingress.kubernetes.io/limit-whitelist
헤더 조작
HTTP 헤더를 조작하는 것은 많은 사용 사례에서 유용합니다. 왜냐하면 HTTP 트랜잭션에 관련된 시스템에 중요하고 관련성 있는 추가 정보가 포함되어 있기 때문입니다. 예를 들어, 커뮤니티 Ingress 컨트롤러는 AJAX 애플리케이션에서 사용되는 CORS( 크로스 오리진 리소스 공유 ) 헤더를 활성화하고 설정하는 것을 지원하는데, 여기서 브라우저의 프런트엔드 JavaScript 코드가 백엔드 앱이나 웹 서버에 연결됩니다.
이 표는 헤더 조작을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .
특정 사용 사례에 따라 NGINX Ingress Controller에서 구성하고 싶을 수 있는 다른 프록싱 및 로드 밸런싱 기능이 있습니다. 이러한 기능에는 프록시 연결에 대한 로드 밸런싱 알고리즘 설정과 타임아웃 및 버퍼링 설정이 포함됩니다.
이 표에서는 사용자 정의 NGINX 부하 분산 , 프록시 시간 초과 , 프록시 버퍼링 , 서비스의 클러스터 IP 주소 및 포트에 대한 라우팅 연결upstream 에 대한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 필드의 명령문을 보여줍니다 .
커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 두 번째 옵션은 표준 Kubernetes Ingress 리소스에서 주석 과 ConfigMap 만 사용 하고 잠재적으로 마스터/미니언 "‑스타일 처리에 의존하는 것입니다. 이렇게 하면 모든 구성이 Ingress 객체에 유지됩니다.
참고:spec 이 방법을 사용하는 경우 Ingress 리소스의 필드를 변경하지 마세요 .
주석이 있는 고급 구성
다음 표는 NGINX Ingress Controller에서 지원하는 주석에 직접 해당하는 커뮤니티 Ingress 컨트롤러 주석을 간략하게 설명합니다.
참고: NGINX Plus 기반의 NGINX Ingress Controller에는 커뮤니티 Ingress 컨트롤러가 전혀 지원하지 않는 기능( 활성 상태 확인 , JSON 웹 토큰(JWT)을 사용한 인증 등)에 대한 추가 주석이 있습니다 .
ConfigMaps를 사용한 글로벌 구성
다음 표는 커뮤니티 Ingress 컨트롤러 ConfigMap 키를 직접 대응하는 NGINX Ingress 컨트롤러 ConfigMap 키에 매핑합니다. 소수의 ConfigMap 키 이름이 동일하다는 점에 유의하세요. 또한, 커뮤니티 Ingress 컨트롤러와 NGINX Ingress 컨트롤러는 모두 다른 컨트롤러에 없는 ConfigMaps 키를 가지고 있습니다(표에 표시되지 않음).
사용자 지정 NGINX Ingress 리소스 또는 주석 및 ConfigMaps가 있는 표준 Kubernetes Ingress 리소스를 사용하여 커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션할 수 있습니다. 이전 옵션은 더 광범위한 네트워킹 기능을 지원하므로 프로덕션 등급 Kubernetes 환경에 더 적합합니다.
마이크로서비스는 현재 많은 주목을 받고 있습니다. 기사, 블로그, 소셜 미디어 토론, 컨퍼런스 프레젠테이션. 이들은 Gartner Hype cycle 에서 과장된 기대의 정점으로 빠르게 향하고 있습니다 . 동시에, 소프트웨어 커뮤니티에는 마이크로서비스를 새로운 것이 아니라고 일축하는 회의론자들이 있습니다. 반대론자들은 이 아이디어가 SOA의 리브랜딩일 뿐이라고 주장합니다. 그러나 과대광고와 회의론에도 불구하고, 마이크로서비스 아키텍처 패턴은 상당한 이점을 가지고 있습니다 . 특히 복잡한 엔터프라이즈 애플리케이션의 민첩한 개발과 제공을 가능하게 하는 데 있어서 그렇습니다.
이 블로그 게시물은 마이크로서비스 설계, 구축 및 배포에 대한 7부작 시리즈의 첫 번째입니다 . 접근 방식과 보다 전통적인 모놀리식 아키텍처 패턴 과의 비교에 대해 알아봅니다 . 이 시리즈에서는 마이크로서비스 아키텍처의 다양한 요소를 설명합니다. 마이크로서비스 아키텍처 패턴의 이점과 단점, 프로젝트에 적합한지 여부, 적용 방법에 대해 알아봅니다.
먼저 마이크로서비스를 사용해야 하는 이유를 살펴보겠습니다.
모놀리식 애플리케이션 구축
Uber와 Hailo와 경쟁하기 위한 새로운 택시 호출 애플리케이션을 빌드하기 시작했다고 가정해 보겠습니다. 몇 가지 예비 회의와 요구 사항 수집 후 Rails, Spring Boot, Play 또는 Maven과 함께 제공되는 생성기를 사용하거나 수동으로 새 프로젝트를 만듭니다. 이 새 애플리케이션은 다음 다이어그램과 같이 모듈 식 육각형 아키텍처를 갖습니다.
애플리케이션의 핵심은 서비스, 도메인 객체 및 이벤트를 정의하는 모듈에 의해 구현되는 비즈니스 로직입니다. 핵심을 둘러싼 것은 외부 세계와 인터페이스하는 어댑터입니다. 어댑터의 예로는 데이터베이스 액세스 구성 요소, 메시지를 생성하고 사용하는 메시징 구성 요소, API를 노출하거나 UI를 구현하는 웹 구성 요소가 있습니다.
논리적으로 모듈식 아키텍처를 가지고 있음에도 불구하고, 애플리케이션은 모놀리스로 패키징되고 배포됩니다. 실제 형식은 애플리케이션의 언어와 프레임워크에 따라 달라집니다. 예를 들어, 많은 Java 애플리케이션은 WAR 파일로 패키징되어 Tomcat이나 Jetty와 같은 애플리케이션 서버에 배포됩니다. 다른 Java 애플리케이션은 자체 포함 실행 파일 JAR로 패키징됩니다. 마찬가지로 Rails 및 Node.js 애플리케이션은 디렉토리 계층으로 패키징됩니다.
이 스타일로 작성된 애플리케이션은 매우 일반적입니다. IDE와 다른 도구는 단일 애플리케이션을 빌드하는 데 중점을 두고 있기 때문에 개발하기 쉽습니다. 이러한 종류의 애플리케이션은 테스트하기도 간단합니다. 애플리케이션을 실행하고 Selenium으로 UI를 테스트하기만 하면 엔드투엔드 테스트를 구현할 수 있습니다. 모놀리식 애플리케이션도 배포하기 쉽습니다. 패키지된 애플리케이션을 서버에 복사하기만 하면 됩니다. 로드 밸런서 뒤에서 여러 복사본을 실행하여 애플리케이션을 확장할 수도 있습니다. 프로젝트의 초기 단계에서는 잘 작동합니다.
거대한 지옥을 향해 행진하다
불행히도, 이 간단한 접근 방식에는 엄청난 한계가 있습니다. 성공적인 애플리케이션은 시간이 지남에 따라 커지고 결국 거대해지는 경향이 있습니다. 각 스프린트 동안 개발팀은 몇 개의 스토리를 더 구현하는데, 물론 이는 많은 줄의 코드를 추가한다는 것을 의미합니다. 몇 년 후에는 작고 간단한 애플리케이션이 괴물 같은 모놀리스 로 성장할 것입니다 . 극단적인 예를 들자면, 저는 최근 수백만 줄의 코드(LOC) 애플리케이션에서 수천 개의 JAR 간의 종속성을 분석하는 도구를 작성하고 있던 개발자와 이야기를 나누었습니다. 저는 그러한 괴물을 만들기 위해 수년에 걸쳐 많은 개발자가 협력했을 것이라고 확신합니다.
애플리케이션이 크고 복잡한 모놀리스가 되면 개발 조직은 아마도 엄청난 고통에 빠질 것입니다. 애자일 개발 및 제공을 시도하면 좌초될 것입니다. 가장 큰 문제 중 하나는 애플리케이션이 엄청나게 복잡하다는 것입니다. 한 명의 개발자가 완전히 이해하기에는 너무 큽니다. 결과적으로 버그를 수정하고 새로운 기능을 올바르게 구현하는 것이 어렵고 시간이 많이 걸립니다. 게다가 이것은 하향 나선이 되는 경향이 있습니다. 코드베이스를 이해하기 어려우면 변경 사항이 올바르게 적용되지 않습니다. 결국 괴물 같고 이해할 수 없는 큰 진흙덩어리가 생깁니다 .
애플리케이션의 엄청난 크기도 개발 속도를 늦출 것입니다. 애플리케이션이 클수록 시작 시간이 길어집니다. 예를 들어, 최근 설문 조사에서 일부 개발자는 시작 시간이 12분에 달한다고 보고했습니다. 애플리케이션이 시작하는 데 40분이나 걸린다는 일화도 들었습니다. 개발자가 애플리케이션 서버를 정기적으로 다시 시작해야 한다면 하루 중 많은 시간을 기다리는 데 보내게 되고 생산성이 저하됩니다.
대규모 복잡한 모놀리스 애플리케이션의 또 다른 문제는 지속적인 배포에 대한 장애물이라는 것입니다. 오늘날 SaaS 애플리케이션의 최첨단 기술은 하루에 여러 번 변경 사항을 프로덕션에 푸시하는 것입니다. 복잡한 모놀리스에서는 전체 애플리케이션을 다시 배포하여 어느 한 부분을 업데이트해야 하기 때문에 이를 수행하기가 매우 어렵습니다. 앞서 언급한 긴 시작 시간도 도움이 되지 않습니다. 또한 변경의 영향은 일반적으로 잘 이해되지 않기 때문에 광범위한 수동 테스트를 수행해야 할 가능성이 높습니다. 결과적으로 지속적인 배포는 거의 불가능합니다.
모놀리식 애플리케이션은 서로 다른 모듈에 상충되는 리소스 요구 사항이 있는 경우에도 확장하기 어려울 수 있습니다. 예를 들어, 한 모듈은 CPU 집약적 이미지 처리 로직을 구현할 수 있으며 이상적으로는 Amazon EC2 Compute Optimized 인스턴스 에 배포될 수 있습니다 . 다른 모듈은 메모리 내 데이터베이스일 수 있으며 EC2 Memory-optimized 인스턴스 에 가장 적합할 수 있습니다 . 그러나 이러한 모듈은 함께 배포되므로 하드웨어 선택에 타협해야 합니다.
모놀리식 애플리케이션의 또 다른 문제는 안정성입니다. 모든 모듈이 동일한 프로세스 내에서 실행되기 때문에 메모리 누수와 같은 모든 모듈의 버그가 잠재적으로 전체 프로세스를 중단시킬 수 있습니다. 게다가 애플리케이션의 모든 인스턴스가 동일하기 때문에 해당 버그는 전체 애플리케이션의 가용성에 영향을 미칩니다.
마지막으로, 모놀리식 애플리케이션은 새로운 프레임워크와 언어를 채택하는 것을 극도로 어렵게 만듭니다. 예를 들어, XYZ 프레임워크를 사용하여 작성된 200만 줄의 코드가 있다고 가정해 보겠습니다. 새로운 ABC 프레임워크를 사용하도록 전체 애플리케이션을 다시 작성하는 것은 (시간과 비용 측면에서) 매우 비쌉니다. 해당 프레임워크가 상당히 더 뛰어나더라도 말입니다. 결과적으로 새로운 기술을 채택하는 데 큰 장벽이 생깁니다. 프로젝트를 시작할 때 선택한 기술에 얽매이게 됩니다.
요약하자면, 성공적인 비즈니스에 중요한 애플리케이션이 있는데, 개발자가 거의 없거나 전혀 이해하지 못하는 괴물 같은 모놀리스로 성장했습니다. 재능 있는 개발자를 고용하기 어렵게 만드는 쓸모없고 비생산적인 기술을 사용하여 작성되었습니다. 애플리케이션은 확장하기 어렵고 신뢰할 수 없습니다. 결과적으로 민첩한 애플리케이션 개발 및 제공이 불가능합니다.
그러면 이에 대해 무엇을 할 수 있을까요?
마이크로서비스 - 복잡성 해결
Amazon, eBay, Netflix 와 같은 많은 조직은 현재 마이크로서비스 아키텍처 패턴 으로 알려진 것을 채택하여 이 문제를 해결했습니다 . 단일의 괴물 같은 모놀리식 애플리케이션을 빌드하는 대신, 애플리케이션을 더 작고 상호 연결된 서비스 세트로 분할하는 것이 아이디어입니다.
서비스는 일반적으로 주문 관리, 고객 관리 등과 같은 고유한 기능이나 기능을 구현합니다. 각 마이크로서비스는 비즈니스 로직과 다양한 어댑터로 구성된 자체 육각형 아키텍처를 갖춘 미니 애플리케이션입니다. 일부 마이크로서비스는 다른 마이크로서비스나 애플리케이션의 클라이언트에서 사용하는 API를 노출합니다. 다른 마이크로서비스는 웹 UI를 구현할 수 있습니다. 런타임에 각 인스턴스는 종종 클라우드 VM 또는 Docker 컨테이너입니다.
예를 들어, 앞서 설명한 시스템의 가능한 분해는 다음 다이어그램에 표시되어 있습니다.
이제 애플리케이션의 각 기능 영역은 자체 마이크로서비스로 구현됩니다. 게다가 웹 애플리케이션은 더 간단한 웹 애플리케이션 세트(예: 택시 호출 예에서 승객용과 운전자용)로 분할됩니다. 이를 통해 특정 사용자, 장치 또는 특수 사용 사례에 대해 고유한 경험을 배포하기가 더 쉬워집니다.
각 백엔드 서비스는 REST API를 노출하고 대부분의 서비스는 다른 서비스에서 제공하는 API를 사용합니다. 예를 들어, Driver Management는 Notification 서버를 사용하여 이용 가능한 운전자에게 잠재적인 여행에 대해 알립니다. UI 서비스는 웹 페이지를 렌더링하기 위해 다른 서비스를 호출합니다. 서비스는 비동기 메시지 기반 통신을 사용할 수도 있습니다. 서비스 간 통신은 이 시리즈의 후반부에서 더 자세히 다룹니다.
일부 REST API는 운전자와 승객이 사용하는 모바일 앱에도 노출됩니다. 그러나 앱은 백엔드 서비스에 직접 액세스할 수 없습니다. 대신 API Gateway 라는 중개자를 통해 통신이 중재됩니다 . API Gateway는 로드 밸런싱, 캐싱, 액세스 제어, API 측정 및 모니터링과 같은 작업을 담당하며 NGINX를 사용하여 효과적으로 구현할 수 있습니다 . 이 시리즈의 후속 기사에서는 API Gateway에 대해 다룹니다 .
마이크로서비스 아키텍처 패턴은 The Art of Scalability라는 훌륭한 책에서 확장성의 3D 모델인 Scale Cube 의 Y축 확장에 해당합니다 . 다른 두 가지 확장 축은 로드 밸런서 뒤에서 애플리케이션의 여러 동일한 사본을 실행하는 것으로 구성된 X축 확장과 요청의 속성(예: 행의 기본 키 또는 고객의 ID)을 사용하여 요청을 특정 서버로 라우팅하는 Z축 확장(또는 데이터 분할)입니다.
애플리케이션은 일반적으로 세 가지 유형의 확장을 함께 사용합니다. Y축 확장은 이 섹션의 첫 번째 그림에서 위에 표시된 대로 애플리케이션을 마이크로서비스로 분해합니다. 런타임에 X축 확장은 처리량과 가용성을 위해 로드 밸런서 뒤에서 각 서비스의 여러 인스턴스를 실행합니다. 일부 애플리케이션은 Z축 확장을 사용하여 서비스를 분할할 수도 있습니다. 다음 다이어그램은 Trip Management 서비스가 Amazon EC2에서 실행되는 Docker와 함께 배포될 수 있는 방법을 보여줍니다.
런타임 시 Trip Management 서비스는 여러 서비스 인스턴스로 구성됩니다. 각 서비스 인스턴스는 Docker 컨테이너입니다. 고가용성을 위해 컨테이너는 여러 Cloud VM에서 실행됩니다. 서비스 인스턴스 앞에는 요청을 인스턴스에 분산하는 NGINX와 같은 로드 밸런서가 있습니다 . 로드 밸런서는 캐싱 , 액세스 제어 , API 미터링 및 모니터링 과 같은 다른 문제도 처리할 수 있습니다 .
마이크로서비스 아키텍처 패턴은 애플리케이션과 데이터베이스 간의 관계에 상당한 영향을 미칩니다. 다른 서비스와 단일 데이터베이스 스키마를 공유하는 대신 각 서비스에는 자체 데이터베이스 스키마가 있습니다. 한편으로 이 접근 방식은 엔터프라이즈 전체 데이터 모델이라는 개념과 맞지 않습니다. 또한 종종 일부 데이터가 중복됩니다. 그러나 마이크로서비스의 이점을 얻으려면 서비스당 데이터베이스 스키마가 있어야 하며, 느슨한 결합을 보장하기 때문입니다. 다음 다이어그램은 예제 애플리케이션의 데이터베이스 아키텍처를 보여줍니다.
각 서비스에는 자체 데이터베이스가 있습니다. 게다가 서비스는 필요에 가장 적합한 데이터베이스 유형인 소위 폴리글롯 지속성 아키텍처를 사용할 수 있습니다. 예를 들어, 잠재적 승객과 가까운 운전자를 찾는 운전자 관리에서는 효율적인 지오쿼리를 지원하는 데이터베이스를 사용해야 합니다.
표면적으로 마이크로서비스 아키텍처 패턴은 SOA와 유사합니다. 두 접근 방식 모두 아키텍처는 일련의 서비스로 구성됩니다. 그러나 마이크로서비스 아키텍처 패턴에 대해 생각하는 한 가지 방법은 웹 서비스 사양 (WS-*)과 엔터프라이즈 서비스 버스(ESB)의 상용화 및 인식된 짐이 없는 SOA라는 것입니다. 마이크로서비스 기반 애플리케이션은 WS-*보다는 REST와 같은 더 간단하고 가벼운 프로토콜을 선호합니다. 또한 ESB 사용을 매우 피하고 대신 마이크로서비스 자체에 ESB와 유사한 기능을 구현합니다. 마이크로서비스 아키텍처 패턴은 또한 정식 스키마 개념과 같은 SOA의 다른 부분을 거부합니다.
마이크로서비스의 이점
마이크로서비스 아키텍처 패턴은 여러 가지 중요한 이점이 있습니다. 첫째, 복잡성 문제를 해결합니다. 그렇지 않으면 괴물 같은 모놀리식 애플리케이션을 일련의 서비스로 분해합니다. 기능의 총량은 변경되지 않지만 애플리케이션은 관리 가능한 청크 또는 서비스로 분할됩니다. 각 서비스에는 RPC 또는 메시지 구동 API 형태의 잘 정의된 경계가 있습니다. 마이크로서비스 아키텍처 패턴은 실제로 모놀리식 코드 기반으로는 달성하기 매우 어려운 수준의 모듈성을 적용합니다. 결과적으로 개별 서비스는 개발 속도가 훨씬 빠르고 이해하고 유지 관리하기가 훨씬 쉽습니다.
둘째, 이 아키텍처는 각 서비스가 해당 서비스에 집중하는 팀에 의해 독립적으로 개발될 수 있도록 합니다. 개발자는 서비스가 API 계약을 준수하는 한, 의미 있는 기술을 자유롭게 선택할 수 있습니다. 물론 대부분의 조직은 완전한 무정부 상태를 피하고 기술 옵션을 제한하고 싶어할 것입니다. 그러나 이러한 자유는 개발자가 더 이상 새 프로젝트를 시작할 때 존재했던 쓸모없는 기술을 사용할 의무가 없다는 것을 의미합니다. 새 서비스를 작성할 때 현재 기술을 사용할 수 있는 옵션이 있습니다. 게다가 서비스가 비교적 작기 때문에 현재 기술을 사용하여 오래된 서비스를 다시 작성하는 것이 가능해집니다.
셋째, 마이크로서비스 아키텍처 패턴은 각 마이크로서비스를 독립적으로 배포할 수 있도록 합니다. 개발자는 자신의 서비스에 로컬한 변경 사항의 배포를 조정할 필요가 없습니다. 이러한 종류의 변경 사항은 테스트가 완료되는 즉시 배포할 수 있습니다. 예를 들어 UI 팀은 A/B 테스트를 수행하고 UI 변경 사항을 빠르게 반복할 수 있습니다. 마이크로서비스 아키텍처 패턴은 지속적인 배포를 가능하게 합니다.
마지막으로, 마이크로서비스 아키텍처 패턴은 각 서비스를 독립적으로 확장할 수 있도록 합니다. 각 서비스의 용량 및 가용성 제약 조건을 충족하는 인스턴스 수만 배포할 수 있습니다. 게다가 서비스의 리소스 요구 사항에 가장 잘 맞는 하드웨어를 사용할 수 있습니다. 예를 들어, EC2 Compute Optimized 인스턴스에 CPU 집약적 이미지 처리 서비스를 배포하고 EC2 Memory-optimized 인스턴스에 인메모리 데이터베이스 서비스를 배포할 수 있습니다.
마이크로서비스의 단점
프레드 브룩스가 거의 30년 전에 썼듯이, 만병통치약은 없습니다. 다른 모든 기술과 마찬가지로 마이크로서비스 아키텍처에는 단점이 있습니다. 단점 중 하나는 이름 자체입니다. 마이크로서비스 라는 용어는 서비스 크기에 지나치게 중점을 둡니다. 사실, 일부 개발자는 매우 세분화된 10~100 LOC 서비스를 구축하는 것을 옹호합니다. 작은 서비스가 더 바람직하지만, 이는 목적을 달성하기 위한 수단이지 주요 목표가 아니라는 점을 기억하는 것이 중요합니다. 마이크로서비스의 목표는 민첩한 애플리케이션 개발 및 배포를 용이하게 하기 위해 애플리케이션을 충분히 분해하는 것입니다.
마이크로서비스의 또 다른 주요 단점은 마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 발생하는 복잡성입니다. 개발자는 메시징 또는 RPC를 기반으로 프로세스 간 통신 메커니즘을 선택하고 구현해야 합니다. 게다가 요청의 대상이 느리거나 사용할 수 없을 수 있으므로 부분적 실패를 처리하는 코드도 작성해야 합니다. 이 모든 것이 로켓 과학은 아니지만 모듈이 언어 수준의 메서드/프로시저 호출을 통해 서로를 호출하는 모놀리식 애플리케이션보다 훨씬 더 복잡합니다.
마이크로서비스의 또 다른 과제는 분할된 데이터베이스 아키텍처입니다. 여러 비즈니스 엔터티를 업데이트하는 비즈니스 트랜잭션은 꽤 일반적입니다. 이러한 종류의 트랜잭션은 단일 데이터베이스가 있기 때문에 모놀리식 애플리케이션에서 구현하기가 쉽습니다. 그러나 마이크로서비스 기반 애플리케이션에서는 서로 다른 서비스가 소유한 여러 데이터베이스를 업데이트해야 합니다. 분산 트랜잭션을 사용하는 것은 일반적으로 옵션이 아니며, CAP 정리 때문만은 아닙니다 . 오늘날의 확장성이 뛰어난 많은 NoSQL 데이터베이스와 메시징 브로커에서 지원되지 않습니다. 결국 개발자에게 더 어려운 이벤트적 일관성 기반 접근 방식을 사용해야 합니다.
마이크로서비스 애플리케이션을 테스트하는 것도 훨씬 더 복잡합니다. 예를 들어, Spring Boot와 같은 최신 프레임워크를 사용하면 모놀리식 웹 애플리케이션을 시작하고 REST API를 테스트하는 테스트 클래스를 작성하는 것이 간단합니다. 반면, 서비스에 대한 유사한 테스트 클래스는 해당 서비스와 해당 서비스에 종속된 모든 서비스를 시작해야 합니다(또는 최소한 해당 서비스에 대한 스텁을 구성해야 합니다). 다시 말하지만, 이는 로켓 과학이 아니지만 이를 수행하는 것의 복잡성을 과소평가하지 않는 것이 중요합니다.
마이크로서비스 아키텍처 패턴의 또 다른 주요 과제는 여러 서비스에 걸쳐 변경 사항을 구현하는 것입니다. 예를 들어, A, B, C 서비스에 대한 변경이 필요한 스토리를 구현한다고 가정해 보겠습니다. 여기서 A는 B에 종속되고 B는 C에 종속됩니다. 모놀리식 애플리케이션에서는 해당 모듈을 변경하고 변경 사항을 통합한 다음 한 번에 배포할 수 있습니다. 반면, 마이크로서비스 아키텍처 패턴에서는 각 서비스에 대한 변경 사항의 롤아웃을 신중하게 계획하고 조정해야 합니다. 예를 들어, 서비스 C를 업데이트한 다음 서비스 B를 업데이트하고 마지막으로 서비스 A를 업데이트해야 합니다. 다행히도 대부분의 변경 사항은 일반적으로 하나의 서비스에만 영향을 미치고 조정이 필요한 여러 서비스 변경은 비교적 드뭅니다.
마이크로서비스 기반 애플리케이션을 배포하는 것도 훨씬 더 복잡합니다. 모놀리식 애플리케이션은 단순히 기존 로드 밸런서 뒤에 있는 동일한 서버 세트에 배포됩니다. 각 애플리케이션 인스턴스는 데이터베이스 및 메시지 브로커와 같은 인프라 서비스의 위치(호스트 및 포트)로 구성됩니다. 반면, 마이크로서비스 애플리케이션은 일반적으로 많은 수의 서비스로 구성됩니다. 예를 들어, Hailo에는 160개의 다양한 서비스가 있고 Netflix에는 600개가 넘는 서비스가 있습니다( Adrian Cockcroft [편집자 - Hailo는 MyTaxi에 인수되었습니다.]) . 각 서비스에는 여러 개의 런타임 인스턴스가 있습니다. 구성, 배포, 확장 및 모니터링해야 하는 움직이는 부분이 훨씬 더 많습니다. 또한 서비스가 통신해야 하는 다른 서비스의 위치(호스트 및 포트)를 검색할 수 있도록 하는 서비스 검색 메커니즘(나중 게시물에서 논의)도 구현해야 합니다. 기존의 문제 티켓 기반 및 수동 운영 방식은 이 수준의 복잡성으로 확장할 수 없습니다. 결과적으로, 마이크로서비스 애플리케이션을 성공적으로 배포하려면 개발자가 배포 방법을 더 잘 제어하고 높은 수준의 자동화가 필요합니다.
자동화에 대한 한 가지 접근 방식은 Cloud Foundry 와 같은 기성형 PaaS를 사용하는 것입니다 . PaaS는 개발자에게 마이크로서비스를 배포하고 관리할 수 있는 쉬운 방법을 제공합니다. IT 리소스 조달 및 구성과 같은 우려 사항으로부터 개발자를 보호합니다. 동시에 PaaS를 구성하는 시스템 및 네트워크 전문가는 모범 사례와 회사 정책을 준수하도록 할 수 있습니다. 마이크로서비스 배포를 자동화하는 또 다른 방법은 본질적으로 자체 PaaS를 개발하는 것입니다. 일반적인 시작점 중 하나는 Docker와 같은 기술과 함께 Kubernetes 와 같은 클러스터링 솔루션을 사용하는 것입니다. 이 시리즈의 후반부에서는 캐싱, 액세스 제어, API 측정 및 마이크로서비스 수준에서 모니터링을 쉽게 처리하는 NGINX Plus와 같은 소프트웨어 기반 애플리케이션 제공 접근 방식이 이 문제를 해결하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다.
요약
복잡한 애플리케이션을 구축하는 것은 본질적으로 어렵습니다. 모놀리식 아키텍처는 단순하고 가벼운 애플리케이션에만 적합합니다. 복잡한 애플리케이션에 사용하면 엄청난 고통을 겪게 될 것입니다. 마이크로서비스 아키텍처 패턴은 단점과 구현 과제에도 불구하고 복잡하고 진화하는 애플리케이션에 더 나은 선택입니다.
이후 블로그 게시물에서는 마이크로서비스 아키텍처 패턴의 다양한 측면에 대한 세부 사항을 살펴보고 서비스 검색, 서비스 배포 옵션, 모놀리식 애플리케이션을 서비스로 리팩토링하는 전략과 같은 주제를 논의하겠습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
최신 앱은 현재 평균 앱 포트폴리오의 절반을 조금 넘는 수준인데, 2020년에는 29%에 불과했습니다. 1 이러한 앱은 보다 빠른 배포와 자동 확장을 위해 컨테이너에서 실행되는 경우가 많으며, 컨테이너 자체도 여러 환경에서 실행될 가능성이 높은데, 대부분 조직(88%)이 최소 두 가지 앱 배포 모델을 사용하고 약 40%가 여섯 가지를 사용하기 때문입니다. 2 그러나 최신 앱을 점점 더 다양한 환경에서 실행하면 안정적인 보안과 연결성이 복잡해집니다.
쿠버네티스 오케스트레이션의 장단점
Kubernetes는 가장 인기 있는 컨테이너 오케스트레이션 시스템으로, 84%의 조직이 사용하거나 평가 중이며 66%가 프로덕션에서 사용하고 있습니다. 3 Amazon Elastic Kubernetes Service(EKS)는 설문 조사에 참여한 조직의 절반 이상이 사용하는 가장 인기 있는 컨테이너 오케스트레이션 플랫폼입니다. 4
EKS는 AWS 서비스와의 기본 통합, 자동 확장 및 리소스 프로비저닝을 통한 비용 효율성, Kubernetes 제어 평면의 자동 패치를 제공하는 관리형 서비스로, AWS나 온프레미스 데이터 센터에서 Kubernetes를 쉽게 실행할 수 있습니다.
쿠버네티스 오케스트레이션은 수많은 이점을 제공하지만, 어려움이 없는 것은 아닙니다. Red Hat의 연구에 따르면 많은 조직이 컨테이너 기반 쿠버네티스 환경을 보호하는 복잡성에 여전히 어려움을 겪고 있으며, 89%가 지난 12개월 동안 적어도 하나의 관련 보안 사고를 보고했습니다. 5 조직의 3분의 2 이상이 쿠버네티스 보안 문제로 인해 배포가 지연되거나 느려졌다고 보고했습니다. 6 쿠버네티스 환경이 여러 클라우드 또는 온프레미스 위치에 걸쳐 있는 경우 보안과 일관성을 유지하기 어렵습니다. Amazon EKS에서 실행하든 다른 환경에서 실행하든 컨테이너화된 앱을 일관되게 보호할 수 있는 솔루션이 필요합니다.
Kubernetes 연결 및 보안을 간소화합니다.
F5 NGINX를 사용하여 Amazon EKS를 포함한 모든 환경에서 Kubernetes 앱과 마이크로서비스를 확장, 관리 및 보호합니다. 온프레미스와 여러 클라우드에서 일관된 연결성과 보안을 제공하여 복잡성을 줄이는 동시에 실시간 가시성을 제공합니다.
Amazon EKS의 Ingress Controller로 NGINX를 사용하면 클러스터 간에 앱 연결을 관리할 수 있습니다. NGINX는 로드 밸런싱, 자동 확장, AWS Lambda와 같은 AWS 서비스와도 통합되어 AWS 환경에 원활하게 추가할 수 있습니다. 또한 AWS가 인프라를 보호하는 동안 앱과 데이터에 대한 보안을 제공하여 공유 책임 모델의 일부를 충족하는 데 도움이 됩니다.
NGINX는 부하 분산 및 SSL 종료를 통해 Kubernetes 배포를 프로덕션 수준으로 만들어 성능을 개선하고, 가동 시간을 늘리고, 보안을 강화합니다. 지속적인 인증 및 권한 부여, 액세스 제어, 종단 간 암호화, 계층 7 OWASP 및 DoS 보호, 실행 가능한 통찰력을 통해 엣지에서 클라우드까지 위협을 완화합니다. NGINX를 사용하여 Kubernetes 앱에 대한 제로 트러스트 보안을 활성화할 수도 있습니다.
NGINX는 보안 문제 및 출시 시간과 같이 일반적으로 보고된 여러 Kubernetes 과제를 해결합니다. 셀프 서비스 기능을 통해 개발팀은 보안 위험을 추가하지 않고도 앱을 더 빠르게 출시할 수 있습니다. Kubernetes 앱과 함께 NGINX를 사용하면 도구 확산을 줄이고 일관성을 높이며 앱 상태와 성능에 대한 더 나은 통찰력을 제공하여 여러 환경에서 복잡성을 완화할 수도 있습니다.
어디에서나 Kubernetes를 간소화하고 보안하세요
Amazon EKS에서 Kubernetes 배포와 함께 NGINX를 사용하면(그리고 다른 곳에서 실행하는 경우) 안전하고 간소화된 앱 연결로 운영을 간소화하고 가동 시간을 늘릴 수 있습니다. AWS Marketplace 에서 NGINX를 30일 동안 무료로 사용해 보거나 AWS에서 사용할 수 있는 다른 많은 F5 솔루션을 알아보세요.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
Kubernetes 생태계에서 애플리케이션 연결을 진화시키는 획기적인 제품인 NGINX Gateway Fabric 1.3.0의 출시를 발표하게 되어 기쁩니다. NGINX Gateway Fabric은 앱, 서비스 및 API 연결을 간소화하고 단순화하도록 설계된 통합 애플리케이션 제공 패브릭인 Kubernetes 도구의 새로운 범주를 개척합니다. 이 도구는 Kubernetes 클러스터에서, Kubernetes 클러스터로, Kubernetes 클러스터 내에서 앱 및 서비스 연결을 지원하도록 설계되어 가장 인기 있는 Ingress 컨트롤러 및 서비스 메시 사용 사례를 하나의 통합 도구로 효과적으로 결합하는 동시에 복잡성을 줄이고 가용성을 개선하며 대규모로 보안과 가시성을 제공합니다. 이번 출시를 통해 오픈 소스 모델에서 Kubernetes 스택 번들에 포함될 완벽하게 지원되는 상용 버전으로 전환합니다.
NGINX Gateway Fabric 1.3.0은 애플리케이션 성능을 최적화하고 시스템 동작에 대한 심층적인 통찰력을 제공하도록 설계된 다양한 강력한 기능을 도입합니다.
NGINX Gateway Fabric 1.3.0의 주요 기능은 다음과 같습니다.
1. GRPCRoute 지원: 애플리케이션에 대한 효율적이고 저지연 gRPC 통신을 지원하여 기존 HTTP REST API와 함께 gRPC 트래픽을 원활하게 관리할 수 있습니다.
2. OpenTelemetry 추적: 애플리케이션 성능에 대한 가시성을 높이기 위한 내장형 추적 지원을 제공합니다. 특정 경로에 대한 추적을 쉽게 구성하고 활성화할 수 있어 시스템을 압도하지 않고도 귀중한 통찰력을 수집할 수 있습니다.
3. 클라이언트 설정 정책: 바디 크기 제한, 타임아웃, keepalive 설정과 같은 클라이언트 설정에 대한 사용자 친화적인 정책을 통해 NGINX 동작에 대한 세부적인 제어를 제공합니다. 게이트웨이 수준에서 적절한 기본값을 설정하는 동시에 애플리케이션별 요구 사항에 대한 경로 수준 재정의를 허용합니다.
NGINX의 입증된 데이터 플레인을 Gateway API 프레임워크에 통합함으로써 NGINX Gateway Fabric은 빠르고 안정적이며 안전한 Kubernetes 앱 및 서비스 연결을 보장합니다. NGINX Gateway Fabric 1.3.0의 기능과 이점에 대해 자세히 알아보려면 F5 DevCentral의 기술 릴리스 블로그를 읽어보세요 .
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
F5 NGINX의 NGINX Ingress Controller는 Prometheus operator ServiceMonitorCRD와 결합되어 Helm을 사용하여 NGINX Ingress Controller 배포에서 메트릭을 훨씬 더 쉽고 빠르게 수집할 수 있습니다. NGINX Ingress Controller helm 차트는 이제 기존 Prometheus 및 prometheus-operator 인프라를 즉시 활용할 수 있는 기능을 지원하여 NIC를 배포하고 메트릭을 바로 활용할 수 있습니다 Prometheus ServiceMonitor. 이 문서에서는 NGINX Ingress Controller helm 차트가 무엇 ServiceMonitor인지, 어떻게 설치하는지, 그리고 이러한 특정 설정을 정의하기 위해 NGINX Ingress Controller helm 차트를 어떻게 사용할 수 있는지 안내합니다.
프로메테우스 서비스 모니터
Prometheus ServiceMonitor 사용자 정의 리소스 정의(CRD)를 사용하면 동적 서비스 집합을 모니터링하는 방법을 선언적으로 정의할 수 있습니다. 모니터링되는 서비스는 Kubernetes 레이블 선택기를 사용하여 정의됩니다. 이를 통해 조직은 메트릭이 노출되는 방식을 제어하는 규칙을 도입할 수 있습니다. 이러한 규칙에 따라 새 서비스가 자동으로 검색되고 Prometheus는 시스템을 재구성할 필요 없이 메트릭을 수집하기 시작합니다. ServiceMonitorPrometheus Operator의 일부입니다. 이러한 리소스는 Prometheus에서 스크래핑할 모니터링 대상을 설명하고 관리합니다. Prometheus 리소스는 필드를 ServiceMonitor사용하여 에 연결됩니다 ServiceMonitor Selector. Prometheus는 스크래핑을 위해 표시된 대상을 쉽게 식별할 수 있습니다. 이를 통해 ServiceMonitorKubernetes 클러스터의 리소스를 활용하여 NGINX Ingress Controller와 같은 솔루션을 모니터링할 수 있는 제어력과 유연성이 향상됩니다. 작업을 더 쉽게 하고 NGINX Ingress Controller에 대한 기본 제공 메트릭을 제공하기 위해 최근에 Prometheus ServiceMonitor헬름 차트에 사용할 수 있는 기능을 추가했습니다. 이를 통해 NGINX Ingress Controller를 배포한 직후에 Prometheus가 스크래핑을 시작할 수 있도록 메트릭을 활성화하는 것이 매우 쉽습니다. 이 기능을 사용하려면 메트릭 수집을 위해 특별히 만든 두 번째 서비스를 추가해야 합니다 ServiceMonitor. 이 서비스는 "첨부"됩니다. 이를 통해 Prometheus 운영자에게 어떤 서비스를 모니터링해야 하는지(메타데이터의 레이블 사용) 알려서 무엇을 어디에서 스크래핑해야 하는지 알 수 있습니다. 배포 또는 헬름 파일의 일부인 경우 NGINX Ingress Controller에 대한 서비스가 어떻게 보일지에 대한 예:
위의 내용은 배포의 일부가 될 것입니다. 라벨, 앱:은 Prometheus 메트릭 스크래핑 nginx-ingress-servicemonitor을 위해 "연결"합니다 . 아래는 위의 서비스로 연결되는 serviceMonitor샘플입니다 .serviceMonitornginx-ingress-servicemonitor
Prometheus 리소스를 만들어야 하는데, 이 리소스는 리소스를 찾도록 구성되어 serviceMonitorPrometheus가 메트릭을 위해 스크래핑할 엔드포인트를 빠르고 쉽게 알 수 있도록 합니다. 아래 예에서 이 리소스는 Prometheus에 사양에 따라 모니터링할 항목을 알려줍니다. 아래에서 를 모니터링하고 있습니다 spec.serviceMonitorSelector.matchLabels:. Prometheus가 모든 네임스페이스에서 matchLabels를 찾고 있음을 알 수 있습니다 . 이는 NGINX Ingress Controller helm 차트 및 Helm에서 배포할 리소스 app.nginx-ingress-servicemonitor와 일치합니다 .serviceMonitor
전체 배포를 설치하기 위해 를 사용할 것입니다 prometheus-community/kube-prometheus-stack. 이렇게 하면 prometheus, prometheus-operator 및 Grafana가 설치됩니다. 또한 격리를 위해 모니터링 네임스페이스에 설치하도록 지정할 것입니다. helm으로 설치하는 방법은 다음과 같습니다.helm install metrics01 prometheus-community/kube-prometheus-stack -n monitoring --create-namespace
Prometheus 리소스 생성 및 설치
Prometheus와 Prometheus CRD가 클러스터에 설치되면 Prometheus 리소스를 만들 수 있습니다. 이를 미리 배포하면 Helm 차트에서 사용할 레이블로 Prometheus 설정을 "사전 배관"할 수 있습니다. 이 접근 방식을 사용하면 Prometheus가 자동으로 NGINX Ingress Controller를 찾고 메트릭을 스크래핑하도록 할 수 있습니다. Prometheus 리소스는 NGINX Ingress Controller를 설치하기 전에 배포됩니다. 이렇게 하면 prometheus-operator배포 후 NGINX Ingress Controller를 자동으로 선택하고 스크래핑하여 메트릭을 빠르게 제공할 수 있습니다.
위의 예는 기본적인 예입니다. 핵심 부분은 spec.serviceMonitorSelector.matchLabels우리가 지정한 값입니다. 이 값은 우리가 helm 차트로 NGINX Ingress 컨트롤러를 배포할 때 사용할 것입니다. 우리는 Prometheus 메트릭을 바로 제공하고 싶습니다. 그렇게 하기 위해 NGINX Ingress 컨트롤러 helm 차트를 사용할 것입니다.
NGINX Ingress Controller 헬름 values.yaml변경
values.yamlHelm 차트에 대한 파일을 검토할 수 있습니다 . Prometheus를 활성화하고, 필요한 서비스를 만들고, serviceMonitor리소스를 만드는 데 필요한 필수 요소가 있으므로 집중하고 싶은 Prometheus 섹션이 있습니다. Prometheus 섹션에서 여러 설정을 볼 수 있습니다. prometheus.service prometheus.serviceMonitorHelm 차트를 사용할 때 필요한 서비스와 serviceMonitor를 생성하기 위해 위의 두 설정을 모두 활성화할 것입니다. 다음은 서비스를 활성화하고, enable하고 serviceMonitor, 섹션에서 레이블을 정의하는 특정 섹션입니다 serviceMonitor.
`servicemonitor` support was recently added to the NGINX Ingress controller helm chart.
prometheus:
## Expose NGINX or NGINX Plus metrics in the Prometheus format.
create: true
## Configures the port to scrape the metrics.
port: 9113
secret: ""
## Configures the HTTP scheme used.
scheme: http
service:
## Requires prometheus.create=true
create: true
serviceMonitor:
create: true
labels: { app: nginx-ingress-servicemonitor }
위의 값들을 분리해보면 다음과 같습니다.
prometheus:
## Expose NGINX or NGINX Plus metrics in the Prometheus format.
create: true
Helm에 NIC Prometheus 엔드포인트를 활성화할 것을 알립니다. 필요한 경우 포트, 스킴 및 비밀을 추가로 정의할 수 있습니다. 값을 prometheus.service.createtrue로 설정하면 Helm이 NIC ServiceMonitor 서비스를 자동으로 생성합니다.
service:
## Creates a ClusterIP Service to expose Prometheus metrics internally
## Requires prometheus.create=true
create: true
마지막으로 .을 만들어야 합니다 serviceMonitor. 이를 true로 설정하고 올바른 레이블을 추가하면 Prometheus 리소스와 일치하는 레이블이 생성되어 추가됩니다.
serviceMonitor:
## Creates a serviceMonitor to expose statistics on the kubernetes pods.
create: true
## Kubernetes object labels to attach to the serviceMonitor object.
labels: { app: nginx-ingress-servicemonitor }
레이블은 서비스 이름으로 다시 연결됩니다 { app: nginx-ingress-servicemointor }. 레이블: 요약하자면 Prometheus를 활성화하면 NIC의 Prometheus 익스포터 기능이 노출됩니다. 서비스 객체를 정의합니다. 이것이 Prometheus ServiceMonitor가 NIC Prometheus 익스포터 엔드포인트를 검색하는 방법입니다. serviceMonitor 객체를 정의합니다. 이것은 Prometheus ServiceMonitor에 이것을 모니터링하라고 말합니다.
이제 NGINX Ingress Controller를 설치할 수 있습니다 helm.
를 수정한 후에 values.yaml는 NGINX Ingress 컨트롤러를 설치할 수 있습니다. helm install nic01 -n nginx-ingress --create-namespace -f values.yaml .NGINX Ingress 컨트롤러를 배포한 후에는 Prometheus 대시보드를 열고 상태 메뉴로 이동할 수 있습니다. 거기에서 대상 및 서비스 검색 뷰로 이동할 수 있습니다. Prometheus가 새 ServiceMonitor 리소스를 찾으면 엔드포인트를 스크래핑하고 Prometheus 대시보드에서 즉시 수집되는 메트릭을 수집하기 시작합니다.
그림 2: Prometheus 서비스 검색
그림 3: 프로메테우스 타겟
그림 4: Prometheus NGINX 쿼리
helm과 Prometheus와 같은 네이티브 Kubernetes 도구를 사용하면 NGINX Ingress Controller가 배포 시작 시 메트릭 수집을 훨씬 더 쉽게 만들어 "즉시 사용 가능한 메트릭"을 제공할 수 있음을 알 수 있습니다. prometheus-operator를 설치하는 데 대한 참조 문서는 다음과 같습니다 . https://prometheus-operator.dev/ https://github.com/prometheus-operator/prometheus-operator
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
Kubernetes Gateway API의 준수 구현인 NGINX Gateway Fabric에 대한 최신 소식을 공유하게 되어 기쁩니다. 최근 여러 가지 흥미로운 새로운 기능과 개선 사항이 포함된 1.2.0 버전으로 업데이트했습니다. 이 릴리스는 플랫폼의 기능을 향상하고 사용자의 요구 사항을 충족하는 데 중점을 두고 있습니다. F5 NGINX Plus 지원을 포함하고 가장 수요가 많은 사용 사례를 포괄하도록 API 표면을 확장했습니다. 이러한 개선 사항이 모든 사용자에게 더 나은 경험을 제공하고 사용자가 목표를 보다 효율적으로 달성하는 데 도움이 될 것이라고 믿습니다.
그림 1: NGINX Gateway Fabric의 설계 및 아키텍처 개요
NGINX Gateway Fabric 1.2.0 개요:
NGINX Plus 지원 – NGINX Gateway Fabric은 이제 데이터 평면에 대해 NGINX Plus를 지원하여 가용성이 개선되고 자세한 측정항목과 실시간 관찰 대시보드가 제공됩니다.
BackendTLSPolicy – TLS 검증을 통해 NGINX Gateway Fabric은 백엔드 애플리케이션의 신원을 확인하여 악성 애플리케이션에 의한 연결 하이재킹 가능성을 방지합니다. 또한 TLS는 클러스터 내의 트래픽을 암호화하여 클라이언트와 백엔드 애플리케이션 간의 안전한 통신을 보장합니다.
URLRewrite – NGINX Gateway Fabric은 이제 Route 객체에서 URL 재작성을 지원합니다. 이 기능을 사용하면 원래 요청 URL을 쉽게 수정하고 더 적절한 대상으로 리디렉션할 수 있습니다. 이렇게 하면 백엔드 애플리케이션이 API 변경을 거치더라도 클라이언트에 노출하는 API를 일관되게 유지할 수 있습니다.
제품 원격 측정 – 이제 NGINX Gateway Fabric에 제품 원격 측정이 제공되므로, 환경에서 제품을 사용하는 방법에 대해 알아가면서 인프라의 운영 효율성을 더욱 개선하는 데 도움을 줄 수 있습니다. 또한, 회의 중에 커뮤니티와 이러한 통찰력을 정기적으로 공유할 계획입니다.
아래에서 새로운 기능을 자세히 살펴보겠습니다.
NGINX Gateway Fabric 1.2.0의 새로운 기능은 무엇입니까?
NGINX 플러스 지원
NGINX Gateway Fabric 버전 1.2.0이 NGINX Plus를 지원하여 출시되어 사용자에게 많은 새로운 이점을 제공합니다. 새로운 업그레이드를 통해 사용자는 이제 추가 Prometheus 메트릭, 동적 업스트림 재로드 및 NGINX Plus 대시보드를 포함하여 배포에서 NGINX Plus의 고급 기능을 활용할 수 있습니다. 이 업그레이드를 통해 환경에 대한 NGINX에서 직접 지원을 받을 수 있는 옵션도 제공됩니다.
추가 Prometheus 메트릭
NGINX Plus를 데이터 플레인으로 사용하는 동안 NGINX Open Source에서 일반적으로 얻는 메트릭과 함께 추가적인 고급 메트릭이 내보내집니다. 몇 가지 주요 내용으로는 http 요청, 스트림, 연결 등에 대한 메트릭이 있습니다. 전체 목록은 NGINX의 Prometheus 내보내기 도구를 확인하여 편리한 목록을 볼 수 있지만 내보내기 도구는 NGINX Gateway Fabric에 꼭 필요한 것은 아닙니다. Prometheus 또는 Prometheus 호환 스크래퍼를 설치하면 이러한 메트릭을 관찰 스택으로 스크래핑하고 아키텍처 내에서 일관된 계층을 사용하여 대시보드와 알림을 빌드할 수 있습니다. Prometheus 메트릭은 HTTP 포트 9113을 통해 NGINX Gateway Fabric에서 자동으로 사용할 수 있습니다. Pod 템플릿을 업데이트하여 기본 포트를 변경할 수도 있습니다. 간단한 설정을 원하시면 GitHub 페이지를 방문하여 Prometheus를 배포하고 구성하여 수집을 시작하는 방법에 대한 자세한 내용을 확인할 수 있습니다. 또는 메트릭만 보고 설정을 건너뛰고 싶다면 다음 섹션에서 설명하는 NGINX Plus 대시보드를 사용할 수 있습니다. 클러스터에 Prometheus를 설치한 후 백그라운드에서 포트 포워딩을 실행하여 대시보드에 액세스할 수 있습니다.kubectl -n monitoring port-forward svc/prometheus-server 9090:80
그림 2: NGINX Gateway Fabric 연결이 수락된 것을 보여주는 Prometheus 그래프
위의 설정은 기본 NGINX Open Source를 데이터 플레인으로 사용하는 경우에도 작동합니다! 그러나 NGINX Plus가 제공하는 추가 메트릭은 볼 수 없습니다. 클러스터의 크기와 범위가 커짐에 따라 NGINX Plus 메트릭이 용량 계획 문제, 인시던트, 심지어 백엔드 애플리케이션 오류를 신속하게 해결하는 데 어떻게 도움이 될 수 있는지 살펴보는 것이 좋습니다.
동적 업스트림 리로드
NGINX Plus와 함께 설치 시 NGINX Gateway Fabric에서 자동으로 활성화되는 동적 업스트림 다시 로드를 통해 NGINX Gateway Fabric은 NGINX 다시 로드 없이 NGINX 구성을 업데이트할 수 있습니다. 전통적으로 NGINX 다시 로드가 발생하면 기존 연결은 이전 작업자 프로세스에서 처리하는 반면 새로 구성된 작업자는 새 연결을 처리합니다. 모든 이전 연결이 완료되면 이전 작업자가 중지되고 NGINX는 새로 구성된 작업자만 사용하여 계속 진행합니다. 이런 방식으로 NGINX 오픈 소스에서도 구성 변경이 우아하게 처리됩니다. 그러나 NGINX에 부하가 많이 걸리는 경우 이전 작업자와 새 작업자를 모두 유지하면 리소스 오버헤드가 생성되어 특히 NGINX Gateway Fabric을 최대한 간소하게 실행하려는 경우 문제가 발생할 수 있습니다. NGINX Plus에서 제공하는 동적 업스트림 다시 로드는 NGINX Gateway Fabric에서 자동으로 사용할 구성 변경에 대한 API 엔드포인트를 제공하여 다시 로드 프로세스 중에 이전 작업자와 새 작업자를 처리하기 위한 추가 리소스 오버헤드의 필요성을 줄임으로써 이 문제를 우회합니다. NGINX Gateway Fabric을 더 자주 변경하기 시작하면 재로드가 더 자주 발생합니다. 현재 NGF 설치에서 재로드가 얼마나 자주 또는 언제 발생하는지 궁금하다면 Prometheus 메트릭을 살펴보세요 nginx_gateway_fabric_nginx_reloads_total. 문제에 대한 전체적이고 심층적인 내용은 Nick Shadrin의 기사를 여기에서 확인하세요 ! 다음은 Prometheus 대시보드에서 NGINX Gateway Fabric을 두 번 배포한 환경에서 메트릭의 예입니다.
그림 3: NGINX Gateway Fabric 재로드 총량을 보여주는 Prometheus 그래프
NGINX 플러스 대시보드
이전에 언급했듯이 Prometheus 설치 또는 관찰 스택 없이 NGINX Plus 메트릭을 빠르게 볼 수 있는 방법을 찾고 있다면 NGINX Plus 대시보드는 인시던트를 해결하고 리소스 용량을 주시하는 데 사용할 수 있는 성능 메트릭을 실시간으로 모니터링합니다.대시보드는 NGINX Plus에서 바로 제공하는 모든 메트릭에 대한 다양한 보기를 제공하며 내부 포트에서 쉽게 액세스할 수 있습니다.대시보드 기능이 어떤지 직접 빠르게 살펴보려면 demo.nginx.com에서 대시보드 데모 사이트를 확인하세요.NGINX Gateway Fabric 설치에서 NGINX Plus 대시보드에 액세스하려면 포트 포워딩을 통해 로컬 머신의 포트 8765로 연결을 전달할 수 있습니다. kubectl port-forward -n nginx-gateway 8765:8765그런 다음 선호하는 브라우저를 열고 주소창에 http://localhost:8765/dashboard.html을 입력합니다.
그림 4: NGINX Plus 대시보드 개요
백엔드TLSPolicy
이 릴리스에는 오랫동안 기다려온 BackendTLSPolicy 지원이 추가되었습니다 . BackendTLSPolicy는 NGINX Gateway Fabric과 애플리케이션 간에 암호화된 TLS 통신을 도입하여 통신 채널의 보안을 크게 향상시킵니다. 다음은 신뢰할 수 있는 인증 기관(CA)에 대해 서버 인증서를 검증할 때 TLS 암호 및 프로토콜과 같은 설정을 지정하여 정책을 적용하는 방법을 보여주는 예입니다. BackendTLSPolicy를 사용하면 사용자가 NGF와 백엔드 간의 트래픽을 보호할 수 있습니다. 최소 TLS 버전과 암호 제품군을 설정할 수도 있습니다. 이를 통해 악성 애플리케이션이 연결을 하이재킹하는 것을 방지하고 클러스터 내의 트래픽을 암호화합니다. 백엔드 TLS 종료를 구성하려면 먼저 사용하려는 CA 인증으로 ConfigMap 을 만듭니다. 내부 Kubernetes 인증서 관리에 대한 도움말은 이 가이드를 확인하세요 .
URLRewrite 필터를 사용하면 들어오는 요청의 원래 URL을 수정하여 성능에 전혀 영향을 미치지 않고 다른 URL로 리디렉션할 수 있습니다. 이 기능은 백엔드 애플리케이션이 노출된 API를 변경하지만 기존 클라이언트에 대한 이전 버전과의 호환성을 유지하려는 경우에 특히 유용합니다. 또한 이 기능을 사용하여 클라이언트에 일관된 API URL을 노출하는 동시에 다른 API URL을 사용하여 요청을 다른 애플리케이션으로 리디렉션하여 클라이언트의 편의성과 성능을 위해 여러 다른 API의 기능을 결합한 "경험" API를 제공할 수 있습니다. 시작하려면 NGINX 게이트웨이 패브릭에 대한 게이트웨이를 만들어 보겠습니다. 이를 통해 HTTP 리스너를 정의하고 최적의 성능을 위해 포트 80을 구성할 수 있습니다.
HTTPRoute 리소스를 만들고 요청 필터를 구성하여 /coffee에 대한 모든 요청을 /beans로 다시 작성해 보겠습니다. 백엔드가 처리할 /latte 접두사를 포함하도록 다시 작성된 /latte 엔드포인트를 제공할 수도 있습니다("/latte/126"이 "/126"이 됨).
HTTP 재작성 기능은 클라이언트 측의 엔드포인트와 백엔드와 매핑되는 방식 간의 유연성을 보장하는 데 도움이 됩니다. 또한 한 URL에서 다른 URL로 트래픽을 리디렉션할 수 있어 특히 콘텐츠를 새 웹사이트나 API 트래픽으로 마이그레이션할 때 유용합니다. NGINX Gateway Fabric은 경로 기반 재작성을 지원하지만 현재는 경로 기반 리디렉션을 지원하지 않습니다. 이 기능이 환경에 필요한지 알려주세요 .
제품 원격 측정 (Telemetry)
우리는 1.2 릴리스의 일부로 수동적으로 피드백을 수집하는 메커니즘으로 제품 원격 측정을 포함하기로 결정했습니다. 이 기능은 환경에서 다양한 메트릭을 수집하여 24시간마다 데이터 수집 플랫폼으로 전송합니다. PII는 수집되지 않으며 수집되는 전체 목록은 여기 에서 확인할 수 있습니다 . 우리는 원격 측정 기능에 대한 완전한 투명성을 제공하기 위해 최선을 다하고 있습니다. 수집하는 모든 필드를 문서화하고 코드로 수집하는 내용을 검증할 수 있지만, 항상 완전히 비활성화할 수 있는 옵션이 있습니다. 커뮤니티 회의 에서 커뮤니티와 함께 수집한 통계를 기반으로 흥미로운 관찰 결과를 정기적으로 검토할 계획 이므로 꼭 들러주세요!
자원
NGINX Gateway Fabric 1.2.0의 전체 변경 사항은 릴리스 노트를 참조하세요 . NGINX Plus로 Kubernetes용 NGINX Gateway Fabric을 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의하세요 . 참여하고 싶거나, 앞으로 나올 내용을 보고 싶거나, NGINX Gateway Fabric의 소스 코드를 보고 싶다면 GitHub 에서 저희 리포지토리를 확인하세요 ! 월요일 오전 9시 태평양/오후 5시 GMT에 2주마다 커뮤니티 회의가 있습니다. 회의 링크, 업데이트, 일정 및 메모는 NGINX Gateway Fabric 회의 일정 에 있습니다 . 링크는 항상 GitHub readme에서도 사용할 수 있습니다.
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
쿠버네티스에서 인공 지능(AI) 및 머신 러닝(ML) 워크로드를 실행하는 주요 이점 중 하나는 Ingress Controller를 통해 들어오는 모든 요청에 대한 중앙 제어 지점을 갖는 것입니다. 로드 밸런서 및 API 게이트웨이 역할을 하는 다재다능한 모듈로, 쿠버네티스 환경에서 AI/ML 애플리케이션을 보호하기 위한 견고한 기반을 제공합니다.
통합 도구인 Ingress Controller는 보안 및 성능 측정을 적용하고, 활동을 모니터링하고, 규정 준수를 의무화하는 데 편리한 터치포인트입니다. 더 구체적으로, Kubernetes 환경에서 Ingress Controller에서 AI/ML 애플리케이션을 보호하면 이 블로그에서 살펴보는 몇 가지 전략적 이점이 있습니다.
중앙 집중식 보안 및 규정 준수 제어
Ingress Controller는 Kubernetes 클러스터에 대한 게이트웨이 역할을 하므로 MLOps 및 플랫폼 엔지니어링 팀이 보안 정책을 시행하기 위한 중앙 집중식 지점을 구현할 수 있습니다. 이를 통해 포드별 또는 서비스별로 보안 설정을 구성하는 복잡성이 줄어듭니다. Ingress 수준에서 보안 제어를 중앙 집중화하면 규정 준수 프로세스가 간소화되고 규정 준수 상태를 관리하고 모니터링하기가 더 쉬워집니다.
통합 인증 및 권한 부여
Ingress Controller는 모든 AI/ML 애플리케이션에 대한 액세스에 대한 인증 및 승인을 구현하고 시행하는 논리적인 위치이기도 합니다. 강력한 인증 기관 관리를 추가함으로써 Ingress Controller는 Kubernetes를 위한 제로 트러스트(ZT) 아키텍처를 구축하는 핵심이기도 합니다. ZT는 매우 귀중한 독점 데이터에서 실행되는 민감한 AI 애플리케이션의 지속적인 보안 및 규정 준수를 보장하는 데 필수적입니다.
속도 제한 및 액세스 제어
Ingress Controller는 속도 제한을 시행하여 DDoS 공격이나 과도한 API 호출과 같은 남용으로부터 애플리케이션을 보호하기에 이상적인 곳으로, 이는 공개 AI/ML API에 필수적입니다. 모델 도난 및 데이터 유출과 같은 새로운 AI 위협이 증가함에 따라 속도 제한 및 액세스 제어를 시행하는 것이 무차별 대입 공격으로부터 보호하는 데 더욱 중요해지고 있습니다. 또한 적대자가 비즈니스 로직을 남용하거나 가드레일을 탈옥하여 데이터를 추출하고 학습을 모델링하거나 정보에 가중치를 두는 것을 방지하는 데 도움이 됩니다.
웹 애플리케이션 방화벽(WAF) 통합
많은 Ingress Controller는 노출된 애플리케이션과 서비스를 보호하기 위한 기본 요소인 WAF와의 통합을 지원합니다. WAF는 OWASP 10과 같은 일반적인 웹 취약성과 공격에 대한 추가 보안 계층을 제공합니다. 더욱 중요한 점은 적절하게 조정하면 WAF가 AI/ML 애플리케이션을 겨냥한 보다 집중적인 공격으로부터 보호한다는 것입니다. 지연 시간과 성능이 중요한 AI/ML 앱의 주요 고려 사항은 WAF로 인해 발생할 수 있는 잠재적인 오버헤드입니다. 또한 AI/ML 앱에서 효과적이려면 WAF를 모니터링 및 관찰 대시보드와 알림 구조를 위해 Ingress Controller에 긴밀하게 통합해야 합니다. WAF와 Ingress Controller가 공통 데이터 플레인을 공유할 수 있다면 이상적입니다.
결론: AI/ML 아키텍처 계획 초기에 Ingress Controller 포함
Ingress Controller는 AI/ML 앱을 위한 Kubernetes 애플리케이션 배포에서 매우 중요한 위치를 차지하기 때문에 AI/ML 애플리케이션을 설계하는 과정에서 해당 기능을 포함하는 것이 가장 좋습니다. 이를 통해 기능 중복을 완화하고 AI/ML 애플리케이션 요구 사항에 따라 확장 및 성장할 Ingress Controller에 대한 더 나은 결정을 내릴 수 있습니다. MLOps 팀의 경우 Ingress Controller는 보안을 최우선 순위로 두고 많은 중요한 플랫폼 및 운영 기능에 대한 중앙 제어 지점이 됩니다.
NGINX 시작하기
NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성, 관찰성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
쿠버네티스 커뮤니티는 Ingress NGINX가 2026년 3월에 은퇴할 것이라고 발표했습니다. 그 이후에는 업데이트, 버그 수정, 보안 패치가 더 이상 없을 것입니다. 이 결정은 수년간 1-2명의 개발자만이 밤과 주말에 일하며 프로젝트를 유지해왔고, 올해 초 심각한 보안 문제(IngressNightmare CVE-2025-1974)로 인해 프로젝트가 더 많은 자원이 필요하다는 점이 분명해진 후에 내려졌습니다.
기존 배포는 계속 작동하지만, 보안 업데이트 없이 실행되는 것은 위험하며 추가 기능 개발은 없을 것입니다.
선택지(그리고 NGINX OSS를 고려해 주시길 바라는 이유)
Traefik, HAProxy, Kong, Envoy 기반 옵션, 게이트웨이 API 구현 등 여러 좋은 Ingress 컨트롤러가 있습니다.
Kubernetes 문서에는 많은 이들이 나열되어 있고, 각각이 강점이 있습니다.
여러분 중 일부는 F5가 OSS를 허용 라이선스 받은 NGINX 인그레스 컨트롤러를 유지하고 있다는 것을 알고 계실 겁니다.
이 프로젝트는 오픈 소스이며 Apache 2.0 라이선스를 받았으며 앞으로도 그럴 것입니다. 이 프로젝트에는 전담 엔지니어 팀이 있으며,
앞으로 여러 업그레이드가 예정되어 있습니다.
이미 NGINX에 익숙하고 큰 문제 없이 작동하는 무언가를 원한다면, Kubernetes용 F5 NGINX Ingress Controller가 가장 원활한 선택이라고 믿습니다.
우리가 실제로 좋아할 거라고 생각하는 이유는 다음과 같습니다:
진정한 오픈 소스: Apache 2.0은 F5뿐만 아니라 다양한 조직의 150+ 기여자들과 라이선스를 받았습니다. 모든 개발은 GitHub에서 공개적으로 이루어지며, F5는 이를 영원히 오픈 소스로 유지하겠다고 약속했습니다. 게다가 2주마다 커뮤니티 콜도 있습니다.
학습 곡선 최소화: 이미 알고 계신 동일한 NGINX 엔진을 사용합니다. 대부분의 Ingress NGINX 주석은 직접적인 대응 함수를 제공하며, 마이그레이션 가이드는 기존 구성에 대한 명확한 매핑을 제공합니다.
지속 가능한 유지보수: F5의 전담 전담 팀이 정기적인 보안 업데이트, 버그 수정, 기능 개발을 보장합니다.
대규모 프로덕션 테스트: 약 40%의 Kubernetes Ingress 배포를 구동하며 1,000만 건 이상의 다운로드를 지원합니다. 실제 제작 환경에서 검증된 제품입니다.
Kubernetes 네이티브 설계: 커스텀 리소스 정의(VirtualServer, Policy, TransportServer)는 주석 과부하보다 더 깔끔한 구성을 제공하며, 오류를 방지하기 위한 내장 검증 기능을 제공합니다.
필요할 때 사용할 수 있는 고급 기능: 캐너리 배포 지원, A/B 테스트, 트래픽 분할, JWT 검증, 속도 제한, mTLS 등 오픈 소스 버전에서 이용 가능합니다.
미래 지향적인 아키텍처: NGINX 게이트웨이 패브릭의 적극적인 개발은 게이트웨이 API로 전환할 준비가 되었을 때 명확한 마이그레이션 경로를 제공합니다.
선택적 상업적 지원: OSS 버전은 견고하지만, NGINX Plus 통합은 적극적인 건강 점검, 동적 재구성, 고급 세션 지속성 및 상업용 지원이 필요한 기업을 위해 제공됩니다.
NGINX 인그레스 컨트롤러로 전환하기
대략적인 이주 가이드를 소개합니다. 또한 저희 문서 사이트에서 더 자세한 마이그레이션 가이드를 확인하실 수 있습니다.
1단계: 점검
현재 사용 중인 내용을 확인하세요: 현재 Ingress 리소스, Annotation, ConfigMaps 문서를 문서화하세요
스니펫 확인: 주석을 식별하세요 nginx.ingress.kubernetes.io/configuration-snippet
사용 중인지 확인하세요: kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
설정하기: 현재 설정을 유지하면서 NGINX Ingress Controller를 별도의 네임스페이스에 설치하세요
2단계: 설정 변환
Annotation 변환: 기존 주석 대부분은 NGINX Ingress Controller에 대응하는 항목들이 있습니다
VirtualServer 리소스 고려: 이 커스텀 리소스는 Annotation이 많은 Ingress보다 더 깔끔하고 더 많은 제어권을 제공하지만, 선택은 본인에게 달려 있습니다
또는 Ingress를 계속 사용하세요: 최소한의 변경만 원한다면 표준 Kubernetes Ingress 리소스와 잘 작동합니다
예외 처리: 직접 매핑되지 않는 경우에는 스니펫이나 정책 리소스를 사용할 수 있습니다
3단계: 모든 것을 시험하기
테스트 앱으로 시도해 보세요: NGINX Ingress 컨트롤러를 가리키는 테스트 Ingress 규칙을 만들어 보세요
두 컨트롤러를 나란히 운영하기: 두 컨트롤러를 계속 작동시키고 테스트 트래픽은 새 컨트롤러를 통해 라우팅하세요
기능 확인: 라우팅, SSL, 속도 제한, CORS, 인증 등 사용 중인 모든 것을 확인하세요
성능 점검: 트래픽을 원하는 방식으로 처리하는지 확인하세요
4단계: 점진적으로 이동하기
작게 시작하세요: 덜 중요한 애플리케이션부터 마이그레이션하세요
트래픽을 천천히 이동시키기: DNS와 라우팅을 조금씩 업데이트하세요
주의 깊게 지켜보세요: 진행하면서 로그와 지표를 주시하세요
RollBack 준비 : 문제가 생기면 롤백할 수 있도록 하세요
5단계: 마무리
마이그레이션 완료: 남은 Ingresss 를 이전
오래된 컨트롤러 정리하기: 모든 것이 이동한 후 커뮤니티 인그레스 NGINX를 제거하세요
정리하기: 더 이상 필요하지 않은 오래된 ConfigMap과 리소스를 제거하세요
NGINX 인그레스 컨트롤러가 왜 합리적인가 (요약)
사실 오픈 소스입니다
Apache 2.0 하에서 완전 오픈 소스로 전환하며, 독점 시스템에 얽매이지 않습니다
여러 조직에서 온 150명 이상의 기여자들(F5 직원뿐만 아니라)
모든 개발은 GitHub에서 공개적으로 이루어집니다
F5는 오픈 소스를 유지하는 데 전념하고 있으며, 이는 우리 비즈니스 모델의 핵심입니다
이 프로젝트는 F5의 지속 가능한 지원과 투자를 받고 있습니다
익숙한 영역이에요
이미 알고 계신 것과 같은 NGINX 엔진이 아래에 들어가 있습니다
Ingress NGINX를 사용해보셨다면 이미 Ingress Controller가 하는 대부분의 기능을 이해하실 겁니다
마이그레이션 문서에는 기존 설정 대부분에 대한 직접 매핑이 나와 있습니다
완전히 새로운 것을 배우는 게 아니에요
적극적으로 유지보수되고 있습니다
F5 NGINX의 전담 엔지니어들
정기 업데이트 및 보안 패치
쿠버네티스 배포의 약 40%가 이를 사용하므로 충분히 검증된 상태입니다
필요하다면 상업용 지원도 가능합니다
오늘부터 내일로 가는 길을 도와주세요
원활한 전환을 위해 방대한 이주 가이드를 준비해 두었습니다
상업용 버전으로 전환해야 한다면, 주석 및 기타 맞춤화 기능을 NGINX로 번역하는 데 도움을 드릴 수 있습니다
NGINX 팀은 게이트웨이 API 구현인 NGINX 게이트웨이 패브릭 솔루션도 보유하고 있습니다
다른 선택지는 어떤가요? 게이트웨이 API는 미래이지만 아직 성숙해지고 있습니다.
Traefik, HAProxy, Kong은 모두 괜찮지만, 이미 NGINX를 사용 중이고 가장 원활한 Ingress 를 원한다면 NGINX Ingress Controller가 최선의 선택이라고 생각합니다.
대부분의 조직에서 컨테이너화된 워크로드를 배포하고 관리하기 위해 쿠버네티스를 선택하는 플랫폼입니다. 하지만 AI 워크로드는 기존 마이크로서비스보다 훨씬 더 일관되고 예측 가능하며, 복잡성이 더욱 높아집니다. 조직이 이러한 과제를 인지하지 못한다면 비용 초과, 낮은 리소스 활용도, 보안 취약성으로 인해 AI 속도가 저하되고 가치가 감소하며 위험이 증폭될 수 있습니다. 투자를 보호하기 위해 조직은 AI에 쿠버네티스를 사용하는 방식에 대해 더욱 지능적인 접근 방식을 취해야 합니다.
AI에 쿠버네티스를 사용할 때의 과제
AI는 기존 워크로드와 다릅니다. 프롬프트는 간단한 텍스트 쿼리부터 멀티미디어 기반 분석까지 다양할 수 있으며, 이로 인해 GPU 리소스에 대한 요구량이 가변적입니다. 컨테이너 인그레스 컨트롤러는 GPU 가용성을 파악하는 데 어려움을 겪기 때문에 기본 라운드 로빈 배포 방식은 일부 GPU를 혼잡하게 만들고 다른 GPU는 활용도가 낮게 만듭니다.
또한 AI는 관리하기 어려운 복잡한 분산 서비스와 API 웹에 의존하며, 공격 표면이 더 넓어 보안이 더욱 어렵습니다. AI는 이러한 복잡성 때문에 매력적인 공격 대상이 되었으며, 사이버 범죄자들은 AI 모델 자체를 공격 벡터로 사용하고 있습니다. 즉각적인 주입 및 모델 조작과 같은 기법은 기존 보안 메커니즘을 우회하여 AI에서 민감한 데이터를 추출하고, 공격자는 AI에 잘못된 프롬프트를 대량으로 전송하여 모델의 응답성을 저하시키고 리소스를 더욱 고갈시킬 수 있습니다. 기존의 쿠버네티스 보안은 이러한 유형의 공격을 방어하도록 설계되지 않았습니다.
쿠버네티스에서 진정으로 동적이고 효율적이며 안전한 AI를 구현하려면 AI별 요구 사항을 충족하고 그에 따라 워크로드를 할당하는 트래픽 관리가 필요합니다. 여기에는 요청 복잡성 및 GPU 가용성을 인식하고 리소스와 AI 처리량 간의 비선형 관계를 고려하는 것이 포함됩니다. 컨테이너 기반 보안 제어는 AI 모델을 보호하고 무단 사용 및 악용 전략의 접근 지점이 되는 것을 방지하는 데 필수적입니다.
쿠버네티스에서 안전하고 최적화된 AI 제공
F5 솔루션은 운영, 보안 및 성능 격차를 해소하여 Amazon Elastic Kubernetes Service(EKS) 배포를 보완합니다.
F5 NGINX Ingress Controller는 AI 인식 인그레스 및 로드 밸런싱을 제공하며, 수요 급증 및 파드 장애 발생 시에도 가동 시간을 유지하기 위한 동적 재구성을 지원합니다. 또한 블루-그린 및 카나리아 릴리스 전략과 원활한 배포 및 최적화를 위한 A/B 테스트를 지원하는 도구도 제공합니다.
F5 NGINX App Protect는 경량 웹 애플리케이션 방화벽(WAF), 레이어 7 분산 서비스 거부(DDoS) 보호, API 보안을 제공합니다. 이 제품은 NGINX Ingress Controller와 함께 F5 NGINX Plus에 포함되어 제공되며 쿠버네티스 클러스터로 원활하게 확장됩니다.
F5는 Amazon EKS에 AI 인식 트래픽 관리 및 보호 기능을 제공합니다.
F5는 Amazon EKS에 AI 인식 트래픽 관리 및 보호 기능을 제공합니다.
분산형 AI를 위한 쿠버네티스 활용
F5 AI Gateway는 하이브리드 멀티클라우드 환경에서 쿠버네티스의 AI 서비스를 원활하게 지원하는 또 다른 옵션입니다. 시맨틱 캐싱을 포함한 AI 인식 트래픽 관리 기능을 활용하면 중복 처리를 최소화하고 토큰을 절약할 수 있습니다.
다층적인 보호 기능은 고유한 AI 위협으로부터 보호하여 OWASP Top 10 for LLMs를 충족하는 동시에 아웃바운드 응답에서 민감한 데이터 유출 및 환각 현상을 방지합니다. AI Gateway는 OpenAI, Anthropic, Ollama를 포함한 주요 AI 플랫폼과 HTTP 기반 언어 모델을 지원하여 배포 위치에 관계없이 일관된 보호 기능을 제공합니다.
F5 AI Gateway는 하이브리드 멀티클라우드 환경에서 AI 제공을 간소화합니다.
AI 인식 접근 방식으로 더 나은 성과 달성
F5 솔루션을 Amazon EKS와 함께 구현하면 더 빠른 모델 응답 시간과 AI 관련 위협으로부터 보호하는 지능형 트래픽 관리 기능을 구현할 수 있습니다. 다음과 같은 이점이 있습니다.
AI 인식 워크로드 분산. 최소 시간 로드 밸런싱 및 활성 상태 확인을 통해 AI 요청을 가장 응답성이 높은 서비스로 전달합니다.
포괄적인 관측 가능성. F5 솔루션은 프롬프트 볼륨, 토큰 사용량, 추론 지연 시간, 모델 성능 통계와 같은 주요 지표를 제공하여 최적화 노력을 가속화합니다.
트래픽 보호. 속도 제한은 리소스 남용을 방지하고, 회로 차단은 장애를 격리하며, 요청 버퍼링은 트래픽 급증에 대처하는 데 도움이 됩니다.
AI 관련 위협 완화. 내장된 보안 기능은 AI 모델 공격을 차단하는 동시에 민감한 데이터 유출을 방지합니다.
ID 관리 및 액세스 제어. JSON 웹 토큰, OpenID Connect, 역할 기반 액세스 제어(RBAC)를 지원하여 권한이 있는 사용자와 서비스만 AI 엔드포인트에 액세스할 수 있도록 합니다.
지금 바로 쿠버네티스에서 AI 워크로드를 최적화하세요
AI에 있어서 어떤 최적화도 간과할 수 없습니다. F5 솔루션은 AWS, 온프레미스, 하이브리드 멀티클라우드 등 모든 환경에서 일관되게 작동하며 쿠버네티스에서 AI의 고유한 과제를 해결합니다.
AI가 원활하고 안정적으로 실행되도록 지원하며, 현재와 미래의 위협으로부터 더욱 강화된 보호 기능을 제공합니다. 확보할 수 있는 모든 이점은 경쟁이 치열하고 끊임없이 변화하는 이 환경에서 AI 프로젝트의 성공을 실현하는 데 한 걸음 더 다가가게 합니다.
위 내용과 같이 NGINX Ingress Controller 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
Kubernetes 커뮤니티가 Gateway API의 일반 가용성을 공식적으로 발표한 지 거의 1년 반이 지났습니다. 이는 Kubernetes 클러스터에서 네트워킹 및 트래픽 관리가 처리되는 방식을 재정의한 이정표입니다. 이는 단순한 증분적 업데이트 이상이었습니다. 이는 클라우드 네이티브 환경의 네트워킹에서 근본적인 변화를 나타내며 연결을 관리하기 위한 강력하고 확장 가능하며 표현력이 뛰어난 프레임워크를 제공합니다.
Gateway API는 Ingress API의 제한된 기능을 역할 중심 설계, 표준화된 리소스 및 확장성으로 대체합니다. 고급 트래픽 라우팅 및 분할을 도입하는 것부터 역할 중심 설계로 멀티 테넌시를 활성화하는 것까지 Gateway API는 이전에 처리하기 어려웠던 복잡한 사용 사례를 잠금 해제합니다. F5를 포함한 공급업체가 Kubernetes 네트워킹의 미래를 형성할 수 있는 잠재력을 인식함에 따라 이러한 변화가 업계 전반에 걸쳐 광범위한 혁신을 촉진한 것은 놀라운 일이 아닙니다.
그러나 이와 같은 새로운 표준을 채택하는 것은 하룻밤 사이에 이루어지지 않습니다. Gateway API는 명확한 이점을 제공하지만 많은 조직은 여전히 신중합니다. 그들은 Gateway API의 표준화되고 유연한 라우팅 구성에 비해 마이그레이션과 기존 Ingress 툴링의 복잡성을 신중하게 평가하고 있습니다. 그리고 채택을 결정한 것은 기술적 한계에 의해서만 이루어진 것이 아니라 상쇄에 대한 것입니다. 전환에 따른 시간, 노력 및 위험은 네트워킹 기능에 대한 의미 있고 실질적인 개선으로 상쇄되어야 합니다.
업계 전체에서 채택 속도가 느린 것은 이러한 신중한 접근 방식을 반영합니다. Gateway API가 Kubernetes 네트워킹의 미래로 널리 알려져 있지만, 많은 조직이 본격적인 채택을 하기 전에 여전히 그 기능을 탐색하거나 상쇄 효과를 평가하고 있습니다. Kubernetes 커뮤니티의 보고서에 따르면 Gateway API에 대한 실험이 꾸준히 증가하고 있습니다. 조기 채택자는 간단한 HTTP 라우팅에서 고급 멀티 테넌트 아키텍처에 이르기까지 다양한 사용 사례에 이를 활용하고 있습니다. 이는 많은 팀이 기다리고 보는 접근 방식을 취하고 있음에도 불구하고 Gateway API의 가능성에 대한 관심이 커지고 있음을 보여줍니다.
F5에서 우리는 비슷한 역학 관계를 관찰했습니다. 많은 고객이 즉각적인 도약을 미루고 있습니다. 이는 관심이 부족해서가 아니라, 성숙한 Ingress 솔루션이 제공하는 운영적 확실성과 혁신의 균형을 맞추는 데 집중하고 있기 때문입니다. 그렇기 때문에 Gateway API로의 여정은 서두를 필요가 없다고 생각합니다. 그저 전략적이어야 합니다.
분석해 보겠습니다. Gateway API로 이동하는 데 따른 몇 가지 과제는 다음과 같습니다.
하지만 상당한 이점도 있습니다.
앱 제공과 인프라에 대해 우리가 아는 것이 있다면, 그것은 이것입니다. 변화에는 시간과 회사 전체의 설득이 필요합니다. 전환을 시작하는 데도 지속적인 지원, 지침, 혁신이 필수적입니다.
Gateway API 도입에 대한 대처: F5의 통찰력
F5에서 우리는 쿠버네티스 네트워킹의 개발과 진화에 깊이 관여했습니다. 우리는 직접 도전에 참여하여 팀이 이를 극복하도록 도왔습니다.
저희의 경험은 한 가지 핵심 진실을 확인시켜 줍니다. Gateway API를 성공적으로 도입하는 것은 단순히 새로운 표준을 구현하는 것이 아닙니다. 미래의 성공을 위한 기반을 구축하는 것입니다. 이를 위해 조직은 단순성, 성능, 유연성 및 견고한 지원을 우선시하는 솔루션이 필요합니다. 이러한 원칙이 어떻게 원활한 전환을 위한 길을 만들고 장기적 가치를 위한 무대를 마련하는지 살펴보겠습니다.
미래는 Gateway API입니다... 당신의 속도에 맞춰서
우리는 18개월이라는 시간이 그렇게 긴 시간이 아니라는 것을 알고 있습니다. 그리고 Gateway API가 수많은 가능성을 열었다고 해서 모든 조직이 당장 이를 도입할 준비가 되었다는 것은 아니라는 것도 알고 있습니다.
많은 팀에게 Ingress API는 유능한 솔루션일 뿐만 아니라 기존 인프라의 중요한 구성 요소이기도 합니다. Ingress API는 수년간 Kubernetes 네트워킹의 중추 역할을 해왔습니다. 잘 정립된 환경을 갖춘 조직은 안정적이고 성공적인 솔루션을 포기해야 한다고 느낄 필요가 없습니다.
F5에서는 이러한 현실을 깊이 인식하고 있기 때문에 Ingress API를 포기하지 않습니다. F5 NGINX Ingress Controller 개발에 계속 투자하여 현대적 사용 사례에 적합하고, 견고하고, 안전하고, 관련성이 있는 혁신과 기능을 제공합니다.
Ingress에 머물고자 하는 조직의 경우, 우리는 그것이 오늘날의 Kubernetes 워크로드를 자신 있게 구동하는 고가치 솔루션으로 유지되도록 하는 데 전념합니다. Gateway API를 탐색하는 팀의 경우, 우리의 목적에 맞게 구축된 F5 NGINX Gateway Fabric은 현대적인 단순성, 성능 및 유연성을 결합하여 조직이 자신 있게 표준을 채택할 수 있도록 돕습니다.
Gateway API로 전환하기 로 한 결정은 하룻밤 사이에 일어날 수 있는 중대한 변화일 필요는 없습니다. 그러나 궁극적으로 전환하는 조직은 성장과 혁신을 위해 스스로를 위치시키는 동시에 Kubernetes 네트워킹의 미래를 형성할 현대적이고 확장 가능하며 상호 운용 가능한 시스템으로 미래의 성공을 위한 기반을 마련하게 됩니다.
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
처음으로 Kubernetes를 설정하는 많은 조직은 Kubernetes 커뮤니티에서 개발하고 유지 관리하는 NGINX Ingress 컨트롤러( kubernetes/ingress-nginx )로 시작합니다. 그러나 Kubernetes 배포가 성숙해짐에 따라 일부 조직은 NGINX를 데이터 플레인으로 유지하면서 고급 기능이 필요하거나 상업적 지원을 원한다는 것을 알게 됩니다.
한 가지 옵션은 F5 NGINX( nginxinc/kubernetes-ingress ) 가 개발하고 유지 관리하는 NGINX Ingress Controller로 마이그레이션하는 것입니다 . 여기서는 두 프로젝트 간의 차이로 인해 발생할 수 있는 몇 가지 복잡한 문제를 피할 수 있도록 전체적인 지침을 제공합니다.
이러한 옵션이 어떻게 다른지 잘 모르시겠습니까? 저희 블로그에서 Ingress Controller 선택 가이드, 4부: NGINX Ingress Controller 옵션을 읽어보세요.
이 게시물의 나머지 부분에서 두 프로젝트를 구별하기 위해 Kubernetes 커뮤니티( kubernetes/ingress-nginx )에서 유지 관리하는 NGINX Ingress Controller를 "커뮤니티 Ingress 컨트롤러"라고 하고 F5 NGINX( nginxinc/kubernetes-ingress )에서 유지 관리하는 NGINX Ingress 컨트롤러를 "NGINX Ingress 컨트롤러"라고 합니다.
커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 방법에는 두 가지가 있습니다.
이는 최적의 솔루션입니다. NGINX Ingress 리소스는 프로덕션 등급 Kubernetes 환경에 필요한 광범위한 Ingress 네트워킹 기능을 지원하기 때문입니다. NGINX Ingress 리소스에 대한 자세한 내용은 NGINX Ingress Controlle r을 사용한 고급 Kubernetes 배포 웨비나를 시청하세요 .
이 옵션은 표준 Kubernetes Ingress 리소스를 사용하여 Ingress 부하 분산 규칙을 정의하려는 경우 권장됩니다.
옵션 1: NGINX Ingress 리소스를 사용하여 마이그레이션
이 마이그레이션 옵션을 사용하면 표준 Kubernetes Ingress 리소스를 사용하여 루트 기능을 설정하고 NGINX Ingress 리소스를 사용 하여 구성을 개선하여 기능을 향상시키고 사용 편의성을 높일 수 있습니다.
NGINX Ingress 리소스( VirtualServer, VirtualServerRoute , TransportServer , GlobalConfiguration 및 Policy ) 에 대한 사용자 정의 리소스 정의(CRD)를 사용하면 구성의 다양한 부분에 대한 제어를 다양한 팀(예: AppDev 및 보안 팀)에 쉽게 위임할 수 있으며, 구성 안전성과 유효성 검사도 더욱 강화할 수 있습니다.
SSL 종료 및 HTTP 경로 기반 라우팅 구성
spec이 표는 표준 Kubernetes Ingress 리소스의 필드 에 있는 SSL 종료 및 Layer 7 경로 기반 라우팅 구성을 specNGINX VirtualServer 리소스의 필드와 매핑합니다. 두 리소스의 구문과 들여쓰기는 약간 다르지만 동일한 기본 Ingress 기능을 수행합니다.
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
apiVersion: networking.k8s.io/v1kind: Ingress metadata: name: nginx-test spec: tls: - hosts: - foo.bar.com secretName: tls-secret rules: - host: foo.bar.com http: paths: - path: /login backend: serviceName: login-svc servicePort: 80 - path: /billing serviceName: billing-svc servicePort: 80apiVersion: networking.k8s.io/v1kind: VirtualServer metadata: name: nginx-test spec: host: foo.bar.com tls: secret: tls-secret upstreams: - name: login service: login-svc port: 80 - name: billing service: billing-svc port: 80 routes: - path: /login action: pass: login - path: /billing action: pass: billingTCP/UDP 부하 분산 및 TLS 패스스루 구성
커뮤니티 Ingress 컨트롤러를 사용하면 Kubernetes ConfigMap API 객체가 TCP 및 UDP 서비스를 노출하는 유일한 방법 입니다 .
NGINX Ingress Controller를 사용하면 TransportServer 리소스는 TCP/UDP 및 TLS Passthrough 로드 밸런싱을 위한 광범위한 옵션을 정의합니다. TransportServer 리소스는 GlobalConfiguration 리소스와 함께 사용되어 인바운드 및 아웃바운드 연결을 제어합니다.
자세한 내용은 블로그의 NGINX Ingress 리소스에서 TCP, UDP 및 TLS 패스스루 서비스 지원을 참조하세요.
커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 리소스로 변환
프로덕션 수준의 Kubernetes 배포에서는 카나리아 및 블루그린 배포, 트래픽 제한, 인그레스-이그레스 트래픽 조작 등을 포함한 고급 사용 사례를 구현하기 위해 기본 Ingress 규칙을 확장해야 하는 경우가 많습니다.
커뮤니티 Ingress 컨트롤러는 Kubernetes 주석 으로 이러한 사용 사례 중 많은 부분을 구현합니다 . 그러나 이러한 주석 중 많은 부분은 매우 구체적인 NGINX Ingress 리소스 정의와 관련된 사용자 지정 Lua 확장으로 빌드되었으며 결과적으로 안정적이고 지원되는 프로덕션 환경에서 고급 기능을 구현하는 데 적합하지 않습니다.
다음 섹션에서는 커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 컨트롤러 리소스로 변환하는 방법을 보여줍니다.
카나리아 배포
프로덕션 컨테이너 워크로드에 빈번한 코드 변경을 푸시하더라도 기존 사용자에게는 계속 서비스를 제공해야 합니다. Canary 및 Blue‑Green 배포를 통해 이를 수행할 수 있으며, NGINX Ingress Controller 데이터 플레인에서 이를 수행하여 프로덕션 등급 Kubernetes 환경에서 안정적이고 예측 가능한 업데이트를 달성할 수 있습니다.
이 표는 카나리아 배포를 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .
커뮤니티 Ingress 컨트롤러는 다음 우선순위에 따라 카나리아 주석을 평가합니다.
NGINX Ingress Controller가 이를 동일한 방식으로 평가하려면 NGINX VirtualServer 또는 VirtualServerRoute 매니페스트에 해당 순서대로 나타나야 합니다
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"matches:- conditions: - header: httpHeader value: never action: pass: echo - header: httpHeader value: always action: pass: echo-canary action: pass: echonginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader" nginx.ingress.kubernetes.io/canary-by-header-value: "my-value"matches:- conditions: - header: httpHeader value: my-value action: pass: echo-canary action: pass: echonginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName"matches:- conditions: - cookie: cookieName value: never action: pass: echo - cookie: cookieName value: always action: pass: echo-canary action: pass: echonginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "10"splits:- weight: 90 action: pass: echo - weight: 10 action: pass: echo-canary교통 통제
애플리케이션이 본질적으로 일시적이어서 오류 응답을 반환할 가능성이 더 높은 마이크로서비스 환경에서 DevOps 팀은 회로 차단 및 속도 및 연결 제한과 같은 트래픽 제어 정책을 광범위하게 사용하여 애플리케이션이 정상적이지 않거나 예상대로 작동하지 않을 때 오류 조건이 발생하지 않도록 합니다.
이 표에서는 속도 제한 , 사용자 정의 HTTP 오류 , 사용자 정의 기본 백엔드 및 URI 재작성을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
nginx.ingress.kubernetes.io/custom-http-errors: "code" nginx.ingress.kubernetes.io/default-backend: "default-svc"errorPages:- codes: [code] redirect: code: 301 url: default-svcnginx.ingress.kubernetes.io/limit-connections: "number"http-snippets: | limit_conn_zone $binary_remote_addr zone=zone_name:size; routes: - path: /path location-snippets: | limit_conn zone_name number;nginx.ingress.kubernetes.io/limit-rate: "number" nginx.ingress.kubernetes.io/limit-rate-after: "number"location-snippets: | limit_rate number; limit_rate_after number;nginx.ingress.kubernetes.io/limit-rpm: "number" nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"rateLimit: rate: numberr/m burst: number * multiplier key: ${binary_remote_addr} zoneSize: sizenginx.ingress.kubernetes.io/limit-rps: "number" nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"rateLimit: rate: numberr/s burst: number * multiplier key: ${binary_remote_addr} zoneSize: sizenginx.ingress.kubernetes.io/limit-whitelist: "CIDR"http-snippets: | server-snippets: |nginx.ingress.kubernetes.io/rewrite-target: "URI"rewritePath: "URI"표에 표시된 대로, 이 글을 쓰는 시점에서 NGINX Ingress 리소스에는 다음 네 가지 커뮤니티 Ingress 컨트롤러 주석을 직접 변환하는 필드가 포함되어 있지 않으며, 스니펫을 사용해야 합니다. Policy 리소스를 사용하여 네 가지 주석에 대한 직접 지원은 NGINX Ingress Controller의 향후 릴리스에서 계획되어 있습니다.
헤더 조작
HTTP 헤더를 조작하는 것은 많은 사용 사례에서 유용합니다. 왜냐하면 HTTP 트랜잭션에 관련된 시스템에 중요하고 관련성 있는 추가 정보가 포함되어 있기 때문입니다. 예를 들어, 커뮤니티 Ingress 컨트롤러는 AJAX 애플리케이션에서 사용되는 CORS( 크로스 오리진 리소스 공유 ) 헤더를 활성화하고 설정하는 것을 지원하는데, 여기서 브라우저의 프런트엔드 JavaScript 코드가 백엔드 앱이나 웹 서버에 연결됩니다.
이 표는 헤더 조작을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 의 필드를 보여줍니다 .
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
nginx.ingress.kubernetes.io/enable-cors: "true"nginx.ingress.kubernetes.io/cors-allow-credentials: "true" nginx.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For" nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS" nginx.ingress.kubernetes.io/cors-allow-origin: "*" nginx.ingress.kubernetes.io/cors-max-age: "seconds"responseHeaders: add: - name: Access-Control-Allow-Credentials value: "true" - name: Access-Control-Allow-Headers value: "X-Forwarded-For" - name: Access-Control-Allow-Methods value: "PUT, GET, POST, OPTIONS" - name: Access-Control-Allow-Origin value: "*" - name: Access-Control-Max-Age value: "seconds"프록싱 및 로드 밸런싱
특정 사용 사례에 따라 NGINX Ingress Controller에서 구성하고 싶을 수 있는 다른 프록싱 및 로드 밸런싱 기능이 있습니다. 이러한 기능에는 프록시 연결에 대한 로드 밸런싱 알고리즘 설정과 타임아웃 및 버퍼링 설정이 포함됩니다.
이 표에서는 사용자 정의 NGINX 부하 분산 , 프록시 시간 초과 , 프록시 버퍼링 , 서비스의 클러스터 IP 주소 및 포트에 대한 라우팅 연결upstream 에 대한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스 필드의 명령문을 보여줍니다 .
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
nginx.ingress.kubernetes.io/load-balancelb-methodnginx.ingress.kubernetes.io/proxy-bufferingbufferingnginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-sizebuffersnginx.ingress.kubernetes.io/proxy-connect-timeoutconnect-timeoutnginx.ingress.kubernetes.io/proxy-next-upstreamnext-upstreamnginx.ingress.kubernetes.io/proxy-next-upstream-timeoutnext-upstream-timeoutnginx.ingress.kubernetes.io/proxy-read-timeoutread-timeoutnginx.ingress.kubernetes.io/proxy-send-timeoutsend-timeoutnginx.ingress.kubernetes.io/service-upstreamuse-cluster-ipmTLS 인증
서비스 메시는 클러스터 내부의 분산 애플리케이션이 상호 인증을 통해 안전하게 통신하는 엄격한 제로 트러스트 환경에서 특히 유용합니다. 클러스터에 들어오고 나가는 트래픽(북-남 트래픽)에 동일한 수준의 보안을 적용해야 하는 경우는 어떨까요?
외부 연결의 최종 시스템이 유효한 인증서를 제시하여 서로를 인증할 수 있도록 Ingress Controller 계층에서 mTLS 인증을 구성할 수 있습니다.
이 표는 클라이언트 인증서 인증 과 백엔드 인증서 인증을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX 정책 리소스 의 필드를 보여줍니다 .
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
nginx.ingress.kubernetes.io/auth-tls-secret: secretName nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"ingressMTLS: clientCertSecret: secretName verifyClient: "on" verifyDepth: 1nginx.ingress.kubernetes.io/proxy-ssl-secret: "secretName" nginx.ingress.kubernetes.io/proxy-ssl-verify: "on|off" nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "1" nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2" nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "DEFAULT" nginx.ingress.kubernetes.io/proxy-ssl-name: "server-name" nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on|off"egressMTLS: tlsSecret: secretName verifyServer: true|false verifyDepth: 1 protocols: TLSv1.2 ciphers: DEFAULT sslName: server-name serverName: true|false세션 지속성(NGINX Plus 전용)
이 표는 NGINX Plus 기반 NGINX Ingress Controller에서만 사용되는 NGINX 정책 리소스 의 필드를 보여주며 , 세션 지속성 (친화성)을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당합니다.
커뮤니티 인그레스 컨트롤러NGINX Ingress 컨트롤러nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "cookieName" nginx.ingress.kubernetes.io/session-cookie-expires: "x" nginx.ingress.kubernetes.io/session-cookie-path: "/route" nginx.ingress.kubernetes.io/session-cookie-secure: "true"sessionCookie: enable: true name: cookieName expires: xh path: /route secure: true옵션 2: Kubernetes Ingress 리소스를 사용하여 마이그레이션
커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 두 번째 옵션은 표준 Kubernetes Ingress 리소스에서 주석 과 ConfigMap 만 사용 하고 잠재적으로 마스터/미니언 "‑스타일 처리에 의존하는 것입니다. 이렇게 하면 모든 구성이 Ingress 객체에 유지됩니다.
참고:spec 이 방법을 사용하는 경우 Ingress 리소스의 필드를 변경하지 마세요 .
주석이 있는 고급 구성
다음 표는 NGINX Ingress Controller에서 지원하는 주석에 직접 해당하는 커뮤니티 Ingress 컨트롤러 주석을 간략하게 설명합니다.
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
nginx.ingress.kubernetes.io/configuration-snippet: |nginx.org/location-snippets: |nginx.ingress.kubernetes.io/load-balance1nginx.org/lb-methodrandom two least_connnginx.ingress.kubernetes.io/proxy-buffering: "on|off"nginx.org/proxy-buffering: "True|False"proxy_bufferingnginx.ingress.kubernetes.io/proxy-buffers-number: "number"nginx.ingress.kubernetes.io/proxy-buffer-size: "xk"nginx.org/proxy-buffers: "number 4k|8k"nginx.org/proxy-buffer-size: "4k|8k"proxy_buffers proxy_buffer_sizenginx.ingress.kubernetes.io/proxy-connect-timeout: "seconds"nginx.org/proxy-connect-timeout: : "secondss"proxy_connect_timeoutnginx.ingress.kubernetes.io/proxy-read-timeout: "seconds"nginx.org/proxy-read-timeout: "secondss"proxy_read_timeoutnginx.ingress.kubernetes.io/proxy-send-timeout: "seconds"nginx.org/proxy-send-timeout: "secondss"proxy_send_timeoutnginx.ingress.kubernetes.io/rewrite-target: "URI"nginx.org/rewrites: "serviceName=svc rewrite=URI"rewritenginx.ingress.kubernetes.io/server-snippet: |nginx.ingress.kubernetes.io/ssl-redirect: "true|false"ingress.kubernetes.io/ssl-redirect: "True|False"1 커뮤니티 Ingress 컨트롤러는 Lua를 사용하여 일부 부하 분산 알고리즘을 구현합니다. NGINX Ingress 컨트롤러는 모든 것에 대한 동등한 것이 없습니다.
2 HTTP 트래픽을 HTTPS로 리디렉션합니다. 커뮤니티 Ingress 컨트롤러는 Lua 코드로 이를 구현하는 반면 NGINX Ingress 컨트롤러는 기본 NGINX if조건을 사용합니다.
다음 표는 NGINX Plus 기반 NGINX Ingress Controller에서 지원하는 주석에 직접 해당하는 커뮤니티 Ingress 컨트롤러 주석을 간략하게 설명합니다.
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name" nginx.ingress.kubernetes.io/session-cookie-expires: "seconds" nginx.ingress.kubernetes.io/session-cookie-path: "/route"nginx.com/sticky-cookie-services: "serviceName=example-svc cookie_name expires=time path=/route"참고: NGINX Plus 기반의 NGINX Ingress Controller에는 커뮤니티 Ingress 컨트롤러가 전혀 지원하지 않는 기능( 활성 상태 확인 , JSON 웹 토큰(JWT)을 사용한 인증 등)에 대한 추가 주석이 있습니다 .
ConfigMaps를 사용한 글로벌 구성
다음 표는 커뮤니티 Ingress 컨트롤러 ConfigMap 키를 직접 대응하는 NGINX Ingress 컨트롤러 ConfigMap 키에 매핑합니다. 소수의 ConfigMap 키 이름이 동일하다는 점에 유의하세요. 또한, 커뮤니티 Ingress 컨트롤러와 NGINX Ingress 컨트롤러는 모두 다른 컨트롤러에 없는 ConfigMaps 키를 가지고 있습니다(표에 표시되지 않음).
* 표 내용
- 쿠버네티스 인그레스 리소스 / NGINX VirtualServer 리소스
disable-access-logaccess-log-offerror-log-levelerror-log-levelhstshstshsts-include-subdomainshsts-include-subdomainshsts-max-agehsts-max-agehttp-snippethttp-snippetskeep-alivekeepalive-timeoutkeep-alive-requestskeepalive-requestsload-balancelb-methodlocation-snippetlocation-snippetslog-format-escape-json: "true"log-format-escaping: "json"log-format-streamstream-log-formatlog-format-upstreamlog-formatmain-snippetmain-snippetsmax-worker-connectionsworker-connectionsmax-worker-open-filesworker-rlimit-nofileproxy-body-sizeclient-max-body-sizeproxy-bufferingproxy-bufferingproxy-buffers-number: "number" proxy-buffer-size: "size"proxy-buffers: number sizeproxy-connect-timeoutproxy-connect-timeoutproxy-read-timeoutproxy-read-timeoutproxy-send-timeoutproxy-send-timeoutserver-name-hash-bucket-sizeserver-names-hash-bucket-sizeserver-name-hash-max-sizeserver-names-hash-max-sizeserver-snippetserver-snippetsserver-tokensserver-tokensssl-ciphersssl-ciphersssl-dh-paramssl-dhparam-filessl-protocolsssl-protocolsssl-redirectssl-redirectupstream-keepalive-connectionskeepaliveuse-http2http2use-proxy-protocolproxy-protocolvariables-hash-bucket-sizevariables-hash-bucket-sizeworker-cpu-affinityworker-cpu-affinityworker-processesworker-processesworker-shutdown-timeoutworker-shutdown-timeout요약
사용자 지정 NGINX Ingress 리소스 또는 주석 및 ConfigMaps가 있는 표준 Kubernetes Ingress 리소스를 사용하여 커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션할 수 있습니다. 이전 옵션은 더 광범위한 네트워킹 기능을 지원하므로 프로덕션 등급 Kubernetes 환경에 더 적합합니다.
마이크로서비스는 현재 많은 주목을 받고 있습니다. 기사, 블로그, 소셜 미디어 토론, 컨퍼런스 프레젠테이션. 이들은 Gartner Hype cycle 에서 과장된 기대의 정점으로 빠르게 향하고 있습니다 . 동시에, 소프트웨어 커뮤니티에는 마이크로서비스를 새로운 것이 아니라고 일축하는 회의론자들이 있습니다. 반대론자들은 이 아이디어가 SOA의 리브랜딩일 뿐이라고 주장합니다. 그러나 과대광고와 회의론에도 불구하고, 마이크로서비스 아키텍처 패턴은 상당한 이점을 가지고 있습니다 . 특히 복잡한 엔터프라이즈 애플리케이션의 민첩한 개발과 제공을 가능하게 하는 데 있어서 그렇습니다.
이 블로그 게시물은 마이크로서비스 설계, 구축 및 배포에 대한 7부작 시리즈의 첫 번째입니다 . 접근 방식과 보다 전통적인 모놀리식 아키텍처 패턴 과의 비교에 대해 알아봅니다 . 이 시리즈에서는 마이크로서비스 아키텍처의 다양한 요소를 설명합니다. 마이크로서비스 아키텍처 패턴의 이점과 단점, 프로젝트에 적합한지 여부, 적용 방법에 대해 알아봅니다.
먼저 마이크로서비스를 사용해야 하는 이유를 살펴보겠습니다.
모놀리식 애플리케이션 구축
Uber와 Hailo와 경쟁하기 위한 새로운 택시 호출 애플리케이션을 빌드하기 시작했다고 가정해 보겠습니다. 몇 가지 예비 회의와 요구 사항 수집 후 Rails, Spring Boot, Play 또는 Maven과 함께 제공되는 생성기를 사용하거나 수동으로 새 프로젝트를 만듭니다. 이 새 애플리케이션은 다음 다이어그램과 같이 모듈 식 육각형 아키텍처를 갖습니다.
애플리케이션의 핵심은 서비스, 도메인 객체 및 이벤트를 정의하는 모듈에 의해 구현되는 비즈니스 로직입니다. 핵심을 둘러싼 것은 외부 세계와 인터페이스하는 어댑터입니다. 어댑터의 예로는 데이터베이스 액세스 구성 요소, 메시지를 생성하고 사용하는 메시징 구성 요소, API를 노출하거나 UI를 구현하는 웹 구성 요소가 있습니다.
논리적으로 모듈식 아키텍처를 가지고 있음에도 불구하고, 애플리케이션은 모놀리스로 패키징되고 배포됩니다. 실제 형식은 애플리케이션의 언어와 프레임워크에 따라 달라집니다. 예를 들어, 많은 Java 애플리케이션은 WAR 파일로 패키징되어 Tomcat이나 Jetty와 같은 애플리케이션 서버에 배포됩니다. 다른 Java 애플리케이션은 자체 포함 실행 파일 JAR로 패키징됩니다. 마찬가지로 Rails 및 Node.js 애플리케이션은 디렉토리 계층으로 패키징됩니다.
이 스타일로 작성된 애플리케이션은 매우 일반적입니다. IDE와 다른 도구는 단일 애플리케이션을 빌드하는 데 중점을 두고 있기 때문에 개발하기 쉽습니다. 이러한 종류의 애플리케이션은 테스트하기도 간단합니다. 애플리케이션을 실행하고 Selenium으로 UI를 테스트하기만 하면 엔드투엔드 테스트를 구현할 수 있습니다. 모놀리식 애플리케이션도 배포하기 쉽습니다. 패키지된 애플리케이션을 서버에 복사하기만 하면 됩니다. 로드 밸런서 뒤에서 여러 복사본을 실행하여 애플리케이션을 확장할 수도 있습니다. 프로젝트의 초기 단계에서는 잘 작동합니다.
거대한 지옥을 향해 행진하다
불행히도, 이 간단한 접근 방식에는 엄청난 한계가 있습니다. 성공적인 애플리케이션은 시간이 지남에 따라 커지고 결국 거대해지는 경향이 있습니다. 각 스프린트 동안 개발팀은 몇 개의 스토리를 더 구현하는데, 물론 이는 많은 줄의 코드를 추가한다는 것을 의미합니다. 몇 년 후에는 작고 간단한 애플리케이션이 괴물 같은 모놀리스 로 성장할 것입니다 . 극단적인 예를 들자면, 저는 최근 수백만 줄의 코드(LOC) 애플리케이션에서 수천 개의 JAR 간의 종속성을 분석하는 도구를 작성하고 있던 개발자와 이야기를 나누었습니다. 저는 그러한 괴물을 만들기 위해 수년에 걸쳐 많은 개발자가 협력했을 것이라고 확신합니다.
애플리케이션이 크고 복잡한 모놀리스가 되면 개발 조직은 아마도 엄청난 고통에 빠질 것입니다. 애자일 개발 및 제공을 시도하면 좌초될 것입니다. 가장 큰 문제 중 하나는 애플리케이션이 엄청나게 복잡하다는 것입니다. 한 명의 개발자가 완전히 이해하기에는 너무 큽니다. 결과적으로 버그를 수정하고 새로운 기능을 올바르게 구현하는 것이 어렵고 시간이 많이 걸립니다. 게다가 이것은 하향 나선이 되는 경향이 있습니다. 코드베이스를 이해하기 어려우면 변경 사항이 올바르게 적용되지 않습니다. 결국 괴물 같고 이해할 수 없는 큰 진흙덩어리가 생깁니다 .
애플리케이션의 엄청난 크기도 개발 속도를 늦출 것입니다. 애플리케이션이 클수록 시작 시간이 길어집니다. 예를 들어, 최근 설문 조사에서 일부 개발자는 시작 시간이 12분에 달한다고 보고했습니다. 애플리케이션이 시작하는 데 40분이나 걸린다는 일화도 들었습니다. 개발자가 애플리케이션 서버를 정기적으로 다시 시작해야 한다면 하루 중 많은 시간을 기다리는 데 보내게 되고 생산성이 저하됩니다.
대규모 복잡한 모놀리스 애플리케이션의 또 다른 문제는 지속적인 배포에 대한 장애물이라는 것입니다. 오늘날 SaaS 애플리케이션의 최첨단 기술은 하루에 여러 번 변경 사항을 프로덕션에 푸시하는 것입니다. 복잡한 모놀리스에서는 전체 애플리케이션을 다시 배포하여 어느 한 부분을 업데이트해야 하기 때문에 이를 수행하기가 매우 어렵습니다. 앞서 언급한 긴 시작 시간도 도움이 되지 않습니다. 또한 변경의 영향은 일반적으로 잘 이해되지 않기 때문에 광범위한 수동 테스트를 수행해야 할 가능성이 높습니다. 결과적으로 지속적인 배포는 거의 불가능합니다.
모놀리식 애플리케이션은 서로 다른 모듈에 상충되는 리소스 요구 사항이 있는 경우에도 확장하기 어려울 수 있습니다. 예를 들어, 한 모듈은 CPU 집약적 이미지 처리 로직을 구현할 수 있으며 이상적으로는 Amazon EC2 Compute Optimized 인스턴스 에 배포될 수 있습니다 . 다른 모듈은 메모리 내 데이터베이스일 수 있으며 EC2 Memory-optimized 인스턴스 에 가장 적합할 수 있습니다 . 그러나 이러한 모듈은 함께 배포되므로 하드웨어 선택에 타협해야 합니다.
모놀리식 애플리케이션의 또 다른 문제는 안정성입니다. 모든 모듈이 동일한 프로세스 내에서 실행되기 때문에 메모리 누수와 같은 모든 모듈의 버그가 잠재적으로 전체 프로세스를 중단시킬 수 있습니다. 게다가 애플리케이션의 모든 인스턴스가 동일하기 때문에 해당 버그는 전체 애플리케이션의 가용성에 영향을 미칩니다.
마지막으로, 모놀리식 애플리케이션은 새로운 프레임워크와 언어를 채택하는 것을 극도로 어렵게 만듭니다. 예를 들어, XYZ 프레임워크를 사용하여 작성된 200만 줄의 코드가 있다고 가정해 보겠습니다. 새로운 ABC 프레임워크를 사용하도록 전체 애플리케이션을 다시 작성하는 것은 (시간과 비용 측면에서) 매우 비쌉니다. 해당 프레임워크가 상당히 더 뛰어나더라도 말입니다. 결과적으로 새로운 기술을 채택하는 데 큰 장벽이 생깁니다. 프로젝트를 시작할 때 선택한 기술에 얽매이게 됩니다.
요약하자면, 성공적인 비즈니스에 중요한 애플리케이션이 있는데, 개발자가 거의 없거나 전혀 이해하지 못하는 괴물 같은 모놀리스로 성장했습니다. 재능 있는 개발자를 고용하기 어렵게 만드는 쓸모없고 비생산적인 기술을 사용하여 작성되었습니다. 애플리케이션은 확장하기 어렵고 신뢰할 수 없습니다. 결과적으로 민첩한 애플리케이션 개발 및 제공이 불가능합니다.
그러면 이에 대해 무엇을 할 수 있을까요?
마이크로서비스 - 복잡성 해결
Amazon, eBay, Netflix 와 같은 많은 조직은 현재 마이크로서비스 아키텍처 패턴 으로 알려진 것을 채택하여 이 문제를 해결했습니다 . 단일의 괴물 같은 모놀리식 애플리케이션을 빌드하는 대신, 애플리케이션을 더 작고 상호 연결된 서비스 세트로 분할하는 것이 아이디어입니다.
서비스는 일반적으로 주문 관리, 고객 관리 등과 같은 고유한 기능이나 기능을 구현합니다. 각 마이크로서비스는 비즈니스 로직과 다양한 어댑터로 구성된 자체 육각형 아키텍처를 갖춘 미니 애플리케이션입니다. 일부 마이크로서비스는 다른 마이크로서비스나 애플리케이션의 클라이언트에서 사용하는 API를 노출합니다. 다른 마이크로서비스는 웹 UI를 구현할 수 있습니다. 런타임에 각 인스턴스는 종종 클라우드 VM 또는 Docker 컨테이너입니다.
예를 들어, 앞서 설명한 시스템의 가능한 분해는 다음 다이어그램에 표시되어 있습니다.
이제 애플리케이션의 각 기능 영역은 자체 마이크로서비스로 구현됩니다. 게다가 웹 애플리케이션은 더 간단한 웹 애플리케이션 세트(예: 택시 호출 예에서 승객용과 운전자용)로 분할됩니다. 이를 통해 특정 사용자, 장치 또는 특수 사용 사례에 대해 고유한 경험을 배포하기가 더 쉬워집니다.
각 백엔드 서비스는 REST API를 노출하고 대부분의 서비스는 다른 서비스에서 제공하는 API를 사용합니다. 예를 들어, Driver Management는 Notification 서버를 사용하여 이용 가능한 운전자에게 잠재적인 여행에 대해 알립니다. UI 서비스는 웹 페이지를 렌더링하기 위해 다른 서비스를 호출합니다. 서비스는 비동기 메시지 기반 통신을 사용할 수도 있습니다. 서비스 간 통신은 이 시리즈의 후반부에서 더 자세히 다룹니다.
일부 REST API는 운전자와 승객이 사용하는 모바일 앱에도 노출됩니다. 그러나 앱은 백엔드 서비스에 직접 액세스할 수 없습니다. 대신 API Gateway 라는 중개자를 통해 통신이 중재됩니다 . API Gateway는 로드 밸런싱, 캐싱, 액세스 제어, API 측정 및 모니터링과 같은 작업을 담당하며 NGINX를 사용하여 효과적으로 구현할 수 있습니다 . 이 시리즈의 후속 기사에서는 API Gateway에 대해 다룹니다 .
마이크로서비스 아키텍처 패턴은 The Art of Scalability라는 훌륭한 책에서 확장성의 3D 모델인 Scale Cube 의 Y축 확장에 해당합니다 . 다른 두 가지 확장 축은 로드 밸런서 뒤에서 애플리케이션의 여러 동일한 사본을 실행하는 것으로 구성된 X축 확장과 요청의 속성(예: 행의 기본 키 또는 고객의 ID)을 사용하여 요청을 특정 서버로 라우팅하는 Z축 확장(또는 데이터 분할)입니다.
애플리케이션은 일반적으로 세 가지 유형의 확장을 함께 사용합니다. Y축 확장은 이 섹션의 첫 번째 그림에서 위에 표시된 대로 애플리케이션을 마이크로서비스로 분해합니다. 런타임에 X축 확장은 처리량과 가용성을 위해 로드 밸런서 뒤에서 각 서비스의 여러 인스턴스를 실행합니다. 일부 애플리케이션은 Z축 확장을 사용하여 서비스를 분할할 수도 있습니다. 다음 다이어그램은 Trip Management 서비스가 Amazon EC2에서 실행되는 Docker와 함께 배포될 수 있는 방법을 보여줍니다.
런타임 시 Trip Management 서비스는 여러 서비스 인스턴스로 구성됩니다. 각 서비스 인스턴스는 Docker 컨테이너입니다. 고가용성을 위해 컨테이너는 여러 Cloud VM에서 실행됩니다. 서비스 인스턴스 앞에는 요청을 인스턴스에 분산하는 NGINX와 같은 로드 밸런서가 있습니다 . 로드 밸런서는 캐싱 , 액세스 제어 , API 미터링 및 모니터링 과 같은 다른 문제도 처리할 수 있습니다 .
마이크로서비스 아키텍처 패턴은 애플리케이션과 데이터베이스 간의 관계에 상당한 영향을 미칩니다. 다른 서비스와 단일 데이터베이스 스키마를 공유하는 대신 각 서비스에는 자체 데이터베이스 스키마가 있습니다. 한편으로 이 접근 방식은 엔터프라이즈 전체 데이터 모델이라는 개념과 맞지 않습니다. 또한 종종 일부 데이터가 중복됩니다. 그러나 마이크로서비스의 이점을 얻으려면 서비스당 데이터베이스 스키마가 있어야 하며, 느슨한 결합을 보장하기 때문입니다. 다음 다이어그램은 예제 애플리케이션의 데이터베이스 아키텍처를 보여줍니다.
각 서비스에는 자체 데이터베이스가 있습니다. 게다가 서비스는 필요에 가장 적합한 데이터베이스 유형인 소위 폴리글롯 지속성 아키텍처를 사용할 수 있습니다. 예를 들어, 잠재적 승객과 가까운 운전자를 찾는 운전자 관리에서는 효율적인 지오쿼리를 지원하는 데이터베이스를 사용해야 합니다.
표면적으로 마이크로서비스 아키텍처 패턴은 SOA와 유사합니다. 두 접근 방식 모두 아키텍처는 일련의 서비스로 구성됩니다. 그러나 마이크로서비스 아키텍처 패턴에 대해 생각하는 한 가지 방법은 웹 서비스 사양 (WS-*)과 엔터프라이즈 서비스 버스(ESB)의 상용화 및 인식된 짐이 없는 SOA라는 것입니다. 마이크로서비스 기반 애플리케이션은 WS-*보다는 REST와 같은 더 간단하고 가벼운 프로토콜을 선호합니다. 또한 ESB 사용을 매우 피하고 대신 마이크로서비스 자체에 ESB와 유사한 기능을 구현합니다. 마이크로서비스 아키텍처 패턴은 또한 정식 스키마 개념과 같은 SOA의 다른 부분을 거부합니다.
마이크로서비스의 이점
마이크로서비스 아키텍처 패턴은 여러 가지 중요한 이점이 있습니다. 첫째, 복잡성 문제를 해결합니다. 그렇지 않으면 괴물 같은 모놀리식 애플리케이션을 일련의 서비스로 분해합니다. 기능의 총량은 변경되지 않지만 애플리케이션은 관리 가능한 청크 또는 서비스로 분할됩니다. 각 서비스에는 RPC 또는 메시지 구동 API 형태의 잘 정의된 경계가 있습니다. 마이크로서비스 아키텍처 패턴은 실제로 모놀리식 코드 기반으로는 달성하기 매우 어려운 수준의 모듈성을 적용합니다. 결과적으로 개별 서비스는 개발 속도가 훨씬 빠르고 이해하고 유지 관리하기가 훨씬 쉽습니다.
둘째, 이 아키텍처는 각 서비스가 해당 서비스에 집중하는 팀에 의해 독립적으로 개발될 수 있도록 합니다. 개발자는 서비스가 API 계약을 준수하는 한, 의미 있는 기술을 자유롭게 선택할 수 있습니다. 물론 대부분의 조직은 완전한 무정부 상태를 피하고 기술 옵션을 제한하고 싶어할 것입니다. 그러나 이러한 자유는 개발자가 더 이상 새 프로젝트를 시작할 때 존재했던 쓸모없는 기술을 사용할 의무가 없다는 것을 의미합니다. 새 서비스를 작성할 때 현재 기술을 사용할 수 있는 옵션이 있습니다. 게다가 서비스가 비교적 작기 때문에 현재 기술을 사용하여 오래된 서비스를 다시 작성하는 것이 가능해집니다.
셋째, 마이크로서비스 아키텍처 패턴은 각 마이크로서비스를 독립적으로 배포할 수 있도록 합니다. 개발자는 자신의 서비스에 로컬한 변경 사항의 배포를 조정할 필요가 없습니다. 이러한 종류의 변경 사항은 테스트가 완료되는 즉시 배포할 수 있습니다. 예를 들어 UI 팀은 A/B 테스트를 수행하고 UI 변경 사항을 빠르게 반복할 수 있습니다. 마이크로서비스 아키텍처 패턴은 지속적인 배포를 가능하게 합니다.
마지막으로, 마이크로서비스 아키텍처 패턴은 각 서비스를 독립적으로 확장할 수 있도록 합니다. 각 서비스의 용량 및 가용성 제약 조건을 충족하는 인스턴스 수만 배포할 수 있습니다. 게다가 서비스의 리소스 요구 사항에 가장 잘 맞는 하드웨어를 사용할 수 있습니다. 예를 들어, EC2 Compute Optimized 인스턴스에 CPU 집약적 이미지 처리 서비스를 배포하고 EC2 Memory-optimized 인스턴스에 인메모리 데이터베이스 서비스를 배포할 수 있습니다.
마이크로서비스의 단점
프레드 브룩스가 거의 30년 전에 썼듯이, 만병통치약은 없습니다. 다른 모든 기술과 마찬가지로 마이크로서비스 아키텍처에는 단점이 있습니다. 단점 중 하나는 이름 자체입니다. 마이크로서비스 라는 용어는 서비스 크기에 지나치게 중점을 둡니다. 사실, 일부 개발자는 매우 세분화된 10~100 LOC 서비스를 구축하는 것을 옹호합니다. 작은 서비스가 더 바람직하지만, 이는 목적을 달성하기 위한 수단이지 주요 목표가 아니라는 점을 기억하는 것이 중요합니다. 마이크로서비스의 목표는 민첩한 애플리케이션 개발 및 배포를 용이하게 하기 위해 애플리케이션을 충분히 분해하는 것입니다.
마이크로서비스의 또 다른 주요 단점은 마이크로서비스 애플리케이션이 분산 시스템이라는 사실에서 발생하는 복잡성입니다. 개발자는 메시징 또는 RPC를 기반으로 프로세스 간 통신 메커니즘을 선택하고 구현해야 합니다. 게다가 요청의 대상이 느리거나 사용할 수 없을 수 있으므로 부분적 실패를 처리하는 코드도 작성해야 합니다. 이 모든 것이 로켓 과학은 아니지만 모듈이 언어 수준의 메서드/프로시저 호출을 통해 서로를 호출하는 모놀리식 애플리케이션보다 훨씬 더 복잡합니다.
마이크로서비스의 또 다른 과제는 분할된 데이터베이스 아키텍처입니다. 여러 비즈니스 엔터티를 업데이트하는 비즈니스 트랜잭션은 꽤 일반적입니다. 이러한 종류의 트랜잭션은 단일 데이터베이스가 있기 때문에 모놀리식 애플리케이션에서 구현하기가 쉽습니다. 그러나 마이크로서비스 기반 애플리케이션에서는 서로 다른 서비스가 소유한 여러 데이터베이스를 업데이트해야 합니다. 분산 트랜잭션을 사용하는 것은 일반적으로 옵션이 아니며, CAP 정리 때문만은 아닙니다 . 오늘날의 확장성이 뛰어난 많은 NoSQL 데이터베이스와 메시징 브로커에서 지원되지 않습니다. 결국 개발자에게 더 어려운 이벤트적 일관성 기반 접근 방식을 사용해야 합니다.
마이크로서비스 애플리케이션을 테스트하는 것도 훨씬 더 복잡합니다. 예를 들어, Spring Boot와 같은 최신 프레임워크를 사용하면 모놀리식 웹 애플리케이션을 시작하고 REST API를 테스트하는 테스트 클래스를 작성하는 것이 간단합니다. 반면, 서비스에 대한 유사한 테스트 클래스는 해당 서비스와 해당 서비스에 종속된 모든 서비스를 시작해야 합니다(또는 최소한 해당 서비스에 대한 스텁을 구성해야 합니다). 다시 말하지만, 이는 로켓 과학이 아니지만 이를 수행하는 것의 복잡성을 과소평가하지 않는 것이 중요합니다.
마이크로서비스 아키텍처 패턴의 또 다른 주요 과제는 여러 서비스에 걸쳐 변경 사항을 구현하는 것입니다. 예를 들어, A, B, C 서비스에 대한 변경이 필요한 스토리를 구현한다고 가정해 보겠습니다. 여기서 A는 B에 종속되고 B는 C에 종속됩니다. 모놀리식 애플리케이션에서는 해당 모듈을 변경하고 변경 사항을 통합한 다음 한 번에 배포할 수 있습니다. 반면, 마이크로서비스 아키텍처 패턴에서는 각 서비스에 대한 변경 사항의 롤아웃을 신중하게 계획하고 조정해야 합니다. 예를 들어, 서비스 C를 업데이트한 다음 서비스 B를 업데이트하고 마지막으로 서비스 A를 업데이트해야 합니다. 다행히도 대부분의 변경 사항은 일반적으로 하나의 서비스에만 영향을 미치고 조정이 필요한 여러 서비스 변경은 비교적 드뭅니다.
마이크로서비스 기반 애플리케이션을 배포하는 것도 훨씬 더 복잡합니다. 모놀리식 애플리케이션은 단순히 기존 로드 밸런서 뒤에 있는 동일한 서버 세트에 배포됩니다. 각 애플리케이션 인스턴스는 데이터베이스 및 메시지 브로커와 같은 인프라 서비스의 위치(호스트 및 포트)로 구성됩니다. 반면, 마이크로서비스 애플리케이션은 일반적으로 많은 수의 서비스로 구성됩니다. 예를 들어, Hailo에는 160개의 다양한 서비스가 있고 Netflix에는 600개가 넘는 서비스가 있습니다( Adrian Cockcroft [편집자 - Hailo는 MyTaxi에 인수되었습니다.]) . 각 서비스에는 여러 개의 런타임 인스턴스가 있습니다. 구성, 배포, 확장 및 모니터링해야 하는 움직이는 부분이 훨씬 더 많습니다. 또한 서비스가 통신해야 하는 다른 서비스의 위치(호스트 및 포트)를 검색할 수 있도록 하는 서비스 검색 메커니즘(나중 게시물에서 논의)도 구현해야 합니다. 기존의 문제 티켓 기반 및 수동 운영 방식은 이 수준의 복잡성으로 확장할 수 없습니다. 결과적으로, 마이크로서비스 애플리케이션을 성공적으로 배포하려면 개발자가 배포 방법을 더 잘 제어하고 높은 수준의 자동화가 필요합니다.
자동화에 대한 한 가지 접근 방식은 Cloud Foundry 와 같은 기성형 PaaS를 사용하는 것입니다 . PaaS는 개발자에게 마이크로서비스를 배포하고 관리할 수 있는 쉬운 방법을 제공합니다. IT 리소스 조달 및 구성과 같은 우려 사항으로부터 개발자를 보호합니다. 동시에 PaaS를 구성하는 시스템 및 네트워크 전문가는 모범 사례와 회사 정책을 준수하도록 할 수 있습니다. 마이크로서비스 배포를 자동화하는 또 다른 방법은 본질적으로 자체 PaaS를 개발하는 것입니다. 일반적인 시작점 중 하나는 Docker와 같은 기술과 함께 Kubernetes 와 같은 클러스터링 솔루션을 사용하는 것입니다. 이 시리즈의 후반부에서는 캐싱, 액세스 제어, API 측정 및 마이크로서비스 수준에서 모니터링을 쉽게 처리하는 NGINX Plus와 같은 소프트웨어 기반 애플리케이션 제공 접근 방식이 이 문제를 해결하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다.
요약
복잡한 애플리케이션을 구축하는 것은 본질적으로 어렵습니다. 모놀리식 아키텍처는 단순하고 가벼운 애플리케이션에만 적합합니다. 복잡한 애플리케이션에 사용하면 엄청난 고통을 겪게 될 것입니다. 마이크로서비스 아키텍처 패턴은 단점과 구현 과제에도 불구하고 복잡하고 진화하는 애플리케이션에 더 나은 선택입니다.
이후 블로그 게시물에서는 마이크로서비스 아키텍처 패턴의 다양한 측면에 대한 세부 사항을 살펴보고 서비스 검색, 서비스 배포 옵션, 모놀리식 애플리케이션을 서비스로 리팩토링하는 전략과 같은 주제를 논의하겠습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
최신 앱은 현재 평균 앱 포트폴리오의 절반을 조금 넘는 수준인데, 2020년에는 29%에 불과했습니다. 1 이러한 앱은 보다 빠른 배포와 자동 확장을 위해 컨테이너에서 실행되는 경우가 많으며, 컨테이너 자체도 여러 환경에서 실행될 가능성이 높은데, 대부분 조직(88%)이 최소 두 가지 앱 배포 모델을 사용하고 약 40%가 여섯 가지를 사용하기 때문입니다. 2 그러나 최신 앱을 점점 더 다양한 환경에서 실행하면 안정적인 보안과 연결성이 복잡해집니다.
쿠버네티스 오케스트레이션의 장단점
Kubernetes는 가장 인기 있는 컨테이너 오케스트레이션 시스템으로, 84%의 조직이 사용하거나 평가 중이며 66%가 프로덕션에서 사용하고 있습니다. 3 Amazon Elastic Kubernetes Service(EKS)는 설문 조사에 참여한 조직의 절반 이상이 사용하는 가장 인기 있는 컨테이너 오케스트레이션 플랫폼입니다. 4
EKS는 AWS 서비스와의 기본 통합, 자동 확장 및 리소스 프로비저닝을 통한 비용 효율성, Kubernetes 제어 평면의 자동 패치를 제공하는 관리형 서비스로, AWS나 온프레미스 데이터 센터에서 Kubernetes를 쉽게 실행할 수 있습니다.
쿠버네티스 오케스트레이션은 수많은 이점을 제공하지만, 어려움이 없는 것은 아닙니다. Red Hat의 연구에 따르면 많은 조직이 컨테이너 기반 쿠버네티스 환경을 보호하는 복잡성에 여전히 어려움을 겪고 있으며, 89%가 지난 12개월 동안 적어도 하나의 관련 보안 사고를 보고했습니다. 5 조직의 3분의 2 이상이 쿠버네티스 보안 문제로 인해 배포가 지연되거나 느려졌다고 보고했습니다. 6 쿠버네티스 환경이 여러 클라우드 또는 온프레미스 위치에 걸쳐 있는 경우 보안과 일관성을 유지하기 어렵습니다. Amazon EKS에서 실행하든 다른 환경에서 실행하든 컨테이너화된 앱을 일관되게 보호할 수 있는 솔루션이 필요합니다.
Kubernetes 연결 및 보안을 간소화합니다.
F5 NGINX를 사용하여 Amazon EKS를 포함한 모든 환경에서 Kubernetes 앱과 마이크로서비스를 확장, 관리 및 보호합니다. 온프레미스와 여러 클라우드에서 일관된 연결성과 보안을 제공하여 복잡성을 줄이는 동시에 실시간 가시성을 제공합니다.
Amazon EKS의 Ingress Controller로 NGINX를 사용하면 클러스터 간에 앱 연결을 관리할 수 있습니다. NGINX는 로드 밸런싱, 자동 확장, AWS Lambda와 같은 AWS 서비스와도 통합되어 AWS 환경에 원활하게 추가할 수 있습니다. 또한 AWS가 인프라를 보호하는 동안 앱과 데이터에 대한 보안을 제공하여 공유 책임 모델의 일부를 충족하는 데 도움이 됩니다.
NGINX는 부하 분산 및 SSL 종료를 통해 Kubernetes 배포를 프로덕션 수준으로 만들어 성능을 개선하고, 가동 시간을 늘리고, 보안을 강화합니다. 지속적인 인증 및 권한 부여, 액세스 제어, 종단 간 암호화, 계층 7 OWASP 및 DoS 보호, 실행 가능한 통찰력을 통해 엣지에서 클라우드까지 위협을 완화합니다. NGINX를 사용하여 Kubernetes 앱에 대한 제로 트러스트 보안을 활성화할 수도 있습니다.
NGINX는 보안 문제 및 출시 시간과 같이 일반적으로 보고된 여러 Kubernetes 과제를 해결합니다. 셀프 서비스 기능을 통해 개발팀은 보안 위험을 추가하지 않고도 앱을 더 빠르게 출시할 수 있습니다. Kubernetes 앱과 함께 NGINX를 사용하면 도구 확산을 줄이고 일관성을 높이며 앱 상태와 성능에 대한 더 나은 통찰력을 제공하여 여러 환경에서 복잡성을 완화할 수도 있습니다.
어디에서나 Kubernetes를 간소화하고 보안하세요
Amazon EKS에서 Kubernetes 배포와 함께 NGINX를 사용하면(그리고 다른 곳에서 실행하는 경우) 안전하고 간소화된 앱 연결로 운영을 간소화하고 가동 시간을 늘릴 수 있습니다. AWS Marketplace 에서 NGINX를 30일 동안 무료로 사용해 보거나 AWS에서 사용할 수 있는 다른 많은 F5 솔루션을 알아보세요.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
Kubernetes 생태계에서 애플리케이션 연결을 진화시키는 획기적인 제품인 NGINX Gateway Fabric 1.3.0의 출시를 발표하게 되어 기쁩니다. NGINX Gateway Fabric은 앱, 서비스 및 API 연결을 간소화하고 단순화하도록 설계된 통합 애플리케이션 제공 패브릭인 Kubernetes 도구의 새로운 범주를 개척합니다. 이 도구는 Kubernetes 클러스터에서, Kubernetes 클러스터로, Kubernetes 클러스터 내에서 앱 및 서비스 연결을 지원하도록 설계되어 가장 인기 있는 Ingress 컨트롤러 및 서비스 메시 사용 사례를 하나의 통합 도구로 효과적으로 결합하는 동시에 복잡성을 줄이고 가용성을 개선하며 대규모로 보안과 가시성을 제공합니다. 이번 출시를 통해 오픈 소스 모델에서 Kubernetes 스택 번들에 포함될 완벽하게 지원되는 상용 버전으로 전환합니다.
NGINX Gateway Fabric 1.3.0은 애플리케이션 성능을 최적화하고 시스템 동작에 대한 심층적인 통찰력을 제공하도록 설계된 다양한 강력한 기능을 도입합니다.
NGINX Gateway Fabric 1.3.0의 주요 기능은 다음과 같습니다.
1. GRPCRoute 지원: 애플리케이션에 대한 효율적이고 저지연 gRPC 통신을 지원하여 기존 HTTP REST API와 함께 gRPC 트래픽을 원활하게 관리할 수 있습니다.
2. OpenTelemetry 추적: 애플리케이션 성능에 대한 가시성을 높이기 위한 내장형 추적 지원을 제공합니다. 특정 경로에 대한 추적을 쉽게 구성하고 활성화할 수 있어 시스템을 압도하지 않고도 귀중한 통찰력을 수집할 수 있습니다.
3. 클라이언트 설정 정책: 바디 크기 제한, 타임아웃, keepalive 설정과 같은 클라이언트 설정에 대한 사용자 친화적인 정책을 통해 NGINX 동작에 대한 세부적인 제어를 제공합니다. 게이트웨이 수준에서 적절한 기본값을 설정하는 동시에 애플리케이션별 요구 사항에 대한 경로 수준 재정의를 허용합니다.
NGINX의 입증된 데이터 플레인을 Gateway API 프레임워크에 통합함으로써 NGINX Gateway Fabric은 빠르고 안정적이며 안전한 Kubernetes 앱 및 서비스 연결을 보장합니다. NGINX Gateway Fabric 1.3.0의 기능과 이점에 대해 자세히 알아보려면 F5 DevCentral의 기술 릴리스 블로그를 읽어보세요 .
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
F5 NGINX의 NGINX Ingress Controller는 Prometheus operator ServiceMonitorCRD와 결합되어 Helm을 사용하여 NGINX Ingress Controller 배포에서 메트릭을 훨씬 더 쉽고 빠르게 수집할 수 있습니다. NGINX Ingress Controller helm 차트는 이제 기존 Prometheus 및 prometheus-operator 인프라를 즉시 활용할 수 있는 기능을 지원하여 NIC를 배포하고 메트릭을 바로 활용할 수 있습니다 Prometheus ServiceMonitor. 이 문서에서는 NGINX Ingress Controller helm 차트가 무엇 ServiceMonitor인지, 어떻게 설치하는지, 그리고 이러한 특정 설정을 정의하기 위해 NGINX Ingress Controller helm 차트를 어떻게 사용할 수 있는지 안내합니다.
프로메테우스 서비스 모니터
Prometheus ServiceMonitor 사용자 정의 리소스 정의(CRD)를 사용하면 동적 서비스 집합을 모니터링하는 방법을 선언적으로 정의할 수 있습니다. 모니터링되는 서비스는 Kubernetes 레이블 선택기를 사용하여 정의됩니다. 이를 통해 조직은 메트릭이 노출되는 방식을 제어하는 규칙을 도입할 수 있습니다. 이러한 규칙에 따라 새 서비스가 자동으로 검색되고 Prometheus는 시스템을 재구성할 필요 없이 메트릭을 수집하기 시작합니다. ServiceMonitorPrometheus Operator의 일부입니다. 이러한 리소스는 Prometheus에서 스크래핑할 모니터링 대상을 설명하고 관리합니다. Prometheus 리소스는 필드를 ServiceMonitor사용하여 에 연결됩니다 ServiceMonitor Selector. Prometheus는 스크래핑을 위해 표시된 대상을 쉽게 식별할 수 있습니다. 이를 통해 ServiceMonitorKubernetes 클러스터의 리소스를 활용하여 NGINX Ingress Controller와 같은 솔루션을 모니터링할 수 있는 제어력과 유연성이 향상됩니다. 작업을 더 쉽게 하고 NGINX Ingress Controller에 대한 기본 제공 메트릭을 제공하기 위해 최근에 Prometheus ServiceMonitor헬름 차트에 사용할 수 있는 기능을 추가했습니다. 이를 통해 NGINX Ingress Controller를 배포한 직후에 Prometheus가 스크래핑을 시작할 수 있도록 메트릭을 활성화하는 것이 매우 쉽습니다. 이 기능을 사용하려면 메트릭 수집을 위해 특별히 만든 두 번째 서비스를 추가해야 합니다 ServiceMonitor. 이 서비스는 "첨부"됩니다. 이를 통해 Prometheus 운영자에게 어떤 서비스를 모니터링해야 하는지(메타데이터의 레이블 사용) 알려서 무엇을 어디에서 스크래핑해야 하는지 알 수 있습니다. 배포 또는 헬름 파일의 일부인 경우 NGINX Ingress Controller에 대한 서비스가 어떻게 보일지에 대한 예:
apiVersion: v1 kind: Service metadata: name: nginx-ingress-servicemonitor labels: app: nginx-ingress-servicemonitor spec: ports: - name: prometheus protocol: TCP port: 9113 targetPort: 9113 selector: app: nginx-ingress위의 내용은 배포의 일부가 될 것입니다. 라벨, 앱:은 Prometheus 메트릭 스크래핑 nginx-ingress-servicemonitor을 위해 "연결"합니다 . 아래는 위의 서비스로 연결되는 serviceMonitor샘플입니다 .serviceMonitornginx-ingress-servicemonitor
apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: nginx-ingress-servicemonitor labels: app: nginx-ingress-servicemonitor spec: selector: matchLabels: app: nginx-ingress-servicemonitor endpoints: - port: prometheusPrometheus 리소스를 만들어야 하는데, 이 리소스는 리소스를 찾도록 구성되어 serviceMonitorPrometheus가 메트릭을 위해 스크래핑할 엔드포인트를 빠르고 쉽게 알 수 있도록 합니다. 아래 예에서 이 리소스는 Prometheus에 사양에 따라 모니터링할 항목을 알려줍니다. 아래에서 를 모니터링하고 있습니다 spec.serviceMonitorSelector.matchLabels:. Prometheus가 모든 네임스페이스에서 matchLabels를 찾고 있음을 알 수 있습니다 . 이는 NGINX Ingress Controller helm 차트 및 Helm에서 배포할 리소스 app.nginx-ingress-servicemonitor와 일치합니다 .serviceMonitor
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: prometheus labels: prometheus: prometheus spec: replicas: 1 serviceAccountName: prometheus serviceMonitorNamespaceSelector: {} serviceMonitorSelector: matchLabels: app: nginx-ingress-servicemonitor resources: requests: memory: 500Mi다음은 다양한 부분을 연결하는 다이어그램입니다.
그림 1: 서비스-모니터 개체 관계
Prometheus, prometheus-operator 및 Grafana 설치
전체 배포를 설치하기 위해 를 사용할 것입니다 prometheus-community/kube-prometheus-stack. 이렇게 하면 prometheus, prometheus-operator 및 Grafana가 설치됩니다. 또한 격리를 위해 모니터링 네임스페이스에 설치하도록 지정할 것입니다. helm으로 설치하는 방법은 다음과 같습니다.helm install metrics01 prometheus-community/kube-prometheus-stack -n monitoring --create-namespace
Prometheus 리소스 생성 및 설치
Prometheus와 Prometheus CRD가 클러스터에 설치되면 Prometheus 리소스를 만들 수 있습니다. 이를 미리 배포하면 Helm 차트에서 사용할 레이블로 Prometheus 설정을 "사전 배관"할 수 있습니다. 이 접근 방식을 사용하면 Prometheus가 자동으로 NGINX Ingress Controller를 찾고 메트릭을 스크래핑하도록 할 수 있습니다. Prometheus 리소스는 NGINX Ingress Controller를 설치하기 전에 배포됩니다. 이렇게 하면 prometheus-operator배포 후 NGINX Ingress Controller를 자동으로 선택하고 스크래핑하여 메트릭을 빠르게 제공할 수 있습니다.
apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: prometheus namespace: default labels: prometheus: monitoring spec: replicas: 1 serviceAccountName: prometheus serviceMonitorNamespaceSelector: {} serviceMonitorSelector: matchLabels: app: nginx-ingress-servicemonitor resources: requests: memory: 500Mi위의 예는 기본적인 예입니다. 핵심 부분은 spec.serviceMonitorSelector.matchLabels우리가 지정한 값입니다. 이 값은 우리가 helm 차트로 NGINX Ingress 컨트롤러를 배포할 때 사용할 것입니다. 우리는 Prometheus 메트릭을 바로 제공하고 싶습니다. 그렇게 하기 위해 NGINX Ingress 컨트롤러 helm 차트를 사용할 것입니다.
NGINX Ingress Controller 헬름 values.yaml변경
values.yamlHelm 차트에 대한 파일을 검토할 수 있습니다 . Prometheus를 활성화하고, 필요한 서비스를 만들고, serviceMonitor리소스를 만드는 데 필요한 필수 요소가 있으므로 집중하고 싶은 Prometheus 섹션이 있습니다. Prometheus 섹션에서 여러 설정을 볼 수 있습니다. prometheus.service prometheus.serviceMonitorHelm 차트를 사용할 때 필요한 서비스와 serviceMonitor를 생성하기 위해 위의 두 설정을 모두 활성화할 것입니다. 다음은 서비스를 활성화하고, enable하고 serviceMonitor, 섹션에서 레이블을 정의하는 특정 섹션입니다 serviceMonitor.
`servicemonitor` support was recently added to the NGINX Ingress controller helm chart. prometheus: ## Expose NGINX or NGINX Plus metrics in the Prometheus format. create: true ## Configures the port to scrape the metrics. port: 9113 secret: "" ## Configures the HTTP scheme used. scheme: http service: ## Requires prometheus.create=true create: true serviceMonitor: create: true labels: { app: nginx-ingress-servicemonitor }위의 값들을 분리해보면 다음과 같습니다.
prometheus: ## Expose NGINX or NGINX Plus metrics in the Prometheus format. create: trueHelm에 NIC Prometheus 엔드포인트를 활성화할 것을 알립니다. 필요한 경우 포트, 스킴 및 비밀을 추가로 정의할 수 있습니다. 값을 prometheus.service.createtrue로 설정하면 Helm이 NIC ServiceMonitor 서비스를 자동으로 생성합니다.
service: ## Creates a ClusterIP Service to expose Prometheus metrics internally ## Requires prometheus.create=true create: true마지막으로 .을 만들어야 합니다 serviceMonitor. 이를 true로 설정하고 올바른 레이블을 추가하면 Prometheus 리소스와 일치하는 레이블이 생성되어 추가됩니다.
serviceMonitor: ## Creates a serviceMonitor to expose statistics on the kubernetes pods. create: true ## Kubernetes object labels to attach to the serviceMonitor object. labels: { app: nginx-ingress-servicemonitor }레이블은 서비스 이름으로 다시 연결됩니다 { app: nginx-ingress-servicemointor }. 레이블: 요약하자면 Prometheus를 활성화하면 NIC의 Prometheus 익스포터 기능이 노출됩니다. 서비스 객체를 정의합니다. 이것이 Prometheus ServiceMonitor가 NIC Prometheus 익스포터 엔드포인트를 검색하는 방법입니다. serviceMonitor 객체를 정의합니다. 이것은 Prometheus ServiceMonitor에 이것을 모니터링하라고 말합니다.
이제 NGINX Ingress Controller를 설치할 수 있습니다 helm.
를 수정한 후에 values.yaml는 NGINX Ingress 컨트롤러를 설치할 수 있습니다. helm install nic01 -n nginx-ingress --create-namespace -f values.yaml .NGINX Ingress 컨트롤러를 배포한 후에는 Prometheus 대시보드를 열고 상태 메뉴로 이동할 수 있습니다. 거기에서 대상 및 서비스 검색 뷰로 이동할 수 있습니다. Prometheus가 새 ServiceMonitor 리소스를 찾으면 엔드포인트를 스크래핑하고 Prometheus 대시보드에서 즉시 수집되는 메트릭을 수집하기 시작합니다.
helm과 Prometheus와 같은 네이티브 Kubernetes 도구를 사용하면 NGINX Ingress Controller가 배포 시작 시 메트릭 수집을 훨씬 더 쉽게 만들어 "즉시 사용 가능한 메트릭"을 제공할 수 있음을 알 수 있습니다. prometheus-operator를 설치하는 데 대한 참조 문서는 다음과 같습니다 . https://prometheus-operator.dev/ https://github.com/prometheus-operator/prometheus-operator
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
Kubernetes Gateway API의 준수 구현인 NGINX Gateway Fabric에 대한 최신 소식을 공유하게 되어 기쁩니다. 최근 여러 가지 흥미로운 새로운 기능과 개선 사항이 포함된 1.2.0 버전으로 업데이트했습니다. 이 릴리스는 플랫폼의 기능을 향상하고 사용자의 요구 사항을 충족하는 데 중점을 두고 있습니다. F5 NGINX Plus 지원을 포함하고 가장 수요가 많은 사용 사례를 포괄하도록 API 표면을 확장했습니다. 이러한 개선 사항이 모든 사용자에게 더 나은 경험을 제공하고 사용자가 목표를 보다 효율적으로 달성하는 데 도움이 될 것이라고 믿습니다.
그림 1: NGINX Gateway Fabric의 설계 및 아키텍처 개요
NGINX Gateway Fabric 1.2.0 개요:
아래에서 새로운 기능을 자세히 살펴보겠습니다.
NGINX Gateway Fabric 1.2.0의 새로운 기능은 무엇입니까?
NGINX 플러스 지원
NGINX Gateway Fabric 버전 1.2.0이 NGINX Plus를 지원하여 출시되어 사용자에게 많은 새로운 이점을 제공합니다. 새로운 업그레이드를 통해 사용자는 이제 추가 Prometheus 메트릭, 동적 업스트림 재로드 및 NGINX Plus 대시보드를 포함하여 배포에서 NGINX Plus의 고급 기능을 활용할 수 있습니다. 이 업그레이드를 통해 환경에 대한 NGINX에서 직접 지원을 받을 수 있는 옵션도 제공됩니다.
추가 Prometheus 메트릭
NGINX Plus를 데이터 플레인으로 사용하는 동안 NGINX Open Source에서 일반적으로 얻는 메트릭과 함께 추가적인 고급 메트릭이 내보내집니다. 몇 가지 주요 내용으로는 http 요청, 스트림, 연결 등에 대한 메트릭이 있습니다. 전체 목록은 NGINX의 Prometheus 내보내기 도구를 확인하여 편리한 목록을 볼 수 있지만 내보내기 도구는 NGINX Gateway Fabric에 꼭 필요한 것은 아닙니다. Prometheus 또는 Prometheus 호환 스크래퍼를 설치하면 이러한 메트릭을 관찰 스택으로 스크래핑하고 아키텍처 내에서 일관된 계층을 사용하여 대시보드와 알림을 빌드할 수 있습니다. Prometheus 메트릭은 HTTP 포트 9113을 통해 NGINX Gateway Fabric에서 자동으로 사용할 수 있습니다. Pod 템플릿을 업데이트하여 기본 포트를 변경할 수도 있습니다. 간단한 설정을 원하시면 GitHub 페이지를 방문하여 Prometheus를 배포하고 구성하여 수집을 시작하는 방법에 대한 자세한 내용을 확인할 수 있습니다. 또는 메트릭만 보고 설정을 건너뛰고 싶다면 다음 섹션에서 설명하는 NGINX Plus 대시보드를 사용할 수 있습니다. 클러스터에 Prometheus를 설치한 후 백그라운드에서 포트 포워딩을 실행하여 대시보드에 액세스할 수 있습니다.kubectl -n monitoring port-forward svc/prometheus-server 9090:80
그림 2: NGINX Gateway Fabric 연결이 수락된 것을 보여주는 Prometheus 그래프
위의 설정은 기본 NGINX Open Source를 데이터 플레인으로 사용하는 경우에도 작동합니다! 그러나 NGINX Plus가 제공하는 추가 메트릭은 볼 수 없습니다. 클러스터의 크기와 범위가 커짐에 따라 NGINX Plus 메트릭이 용량 계획 문제, 인시던트, 심지어 백엔드 애플리케이션 오류를 신속하게 해결하는 데 어떻게 도움이 될 수 있는지 살펴보는 것이 좋습니다.
동적 업스트림 리로드
NGINX Plus와 함께 설치 시 NGINX Gateway Fabric에서 자동으로 활성화되는 동적 업스트림 다시 로드를 통해 NGINX Gateway Fabric은 NGINX 다시 로드 없이 NGINX 구성을 업데이트할 수 있습니다. 전통적으로 NGINX 다시 로드가 발생하면 기존 연결은 이전 작업자 프로세스에서 처리하는 반면 새로 구성된 작업자는 새 연결을 처리합니다. 모든 이전 연결이 완료되면 이전 작업자가 중지되고 NGINX는 새로 구성된 작업자만 사용하여 계속 진행합니다. 이런 방식으로 NGINX 오픈 소스에서도 구성 변경이 우아하게 처리됩니다. 그러나 NGINX에 부하가 많이 걸리는 경우 이전 작업자와 새 작업자를 모두 유지하면 리소스 오버헤드가 생성되어 특히 NGINX Gateway Fabric을 최대한 간소하게 실행하려는 경우 문제가 발생할 수 있습니다. NGINX Plus에서 제공하는 동적 업스트림 다시 로드는 NGINX Gateway Fabric에서 자동으로 사용할 구성 변경에 대한 API 엔드포인트를 제공하여 다시 로드 프로세스 중에 이전 작업자와 새 작업자를 처리하기 위한 추가 리소스 오버헤드의 필요성을 줄임으로써 이 문제를 우회합니다. NGINX Gateway Fabric을 더 자주 변경하기 시작하면 재로드가 더 자주 발생합니다. 현재 NGF 설치에서 재로드가 얼마나 자주 또는 언제 발생하는지 궁금하다면 Prometheus 메트릭을 살펴보세요 nginx_gateway_fabric_nginx_reloads_total. 문제에 대한 전체적이고 심층적인 내용은 Nick Shadrin의 기사를 여기에서 확인하세요 ! 다음은 Prometheus 대시보드에서 NGINX Gateway Fabric을 두 번 배포한 환경에서 메트릭의 예입니다.
그림 3: NGINX Gateway Fabric 재로드 총량을 보여주는 Prometheus 그래프
NGINX 플러스 대시보드
이전에 언급했듯이 Prometheus 설치 또는 관찰 스택 없이 NGINX Plus 메트릭을 빠르게 볼 수 있는 방법을 찾고 있다면 NGINX Plus 대시보드는 인시던트를 해결하고 리소스 용량을 주시하는 데 사용할 수 있는 성능 메트릭을 실시간으로 모니터링합니다.대시보드는 NGINX Plus에서 바로 제공하는 모든 메트릭에 대한 다양한 보기를 제공하며 내부 포트에서 쉽게 액세스할 수 있습니다.대시보드 기능이 어떤지 직접 빠르게 살펴보려면 demo.nginx.com에서 대시보드 데모 사이트를 확인하세요.NGINX Gateway Fabric 설치에서 NGINX Plus 대시보드에 액세스하려면 포트 포워딩을 통해 로컬 머신의 포트 8765로 연결을 전달할 수 있습니다. kubectl port-forward -n nginx-gateway 8765:8765그런 다음 선호하는 브라우저를 열고 주소창에 http://localhost:8765/dashboard.html을 입력합니다.
그림 4: NGINX Plus 대시보드 개요
백엔드TLSPolicy
이 릴리스에는 오랫동안 기다려온 BackendTLSPolicy 지원이 추가되었습니다 . BackendTLSPolicy는 NGINX Gateway Fabric과 애플리케이션 간에 암호화된 TLS 통신을 도입하여 통신 채널의 보안을 크게 향상시킵니다. 다음은 신뢰할 수 있는 인증 기관(CA)에 대해 서버 인증서를 검증할 때 TLS 암호 및 프로토콜과 같은 설정을 지정하여 정책을 적용하는 방법을 보여주는 예입니다. BackendTLSPolicy를 사용하면 사용자가 NGF와 백엔드 간의 트래픽을 보호할 수 있습니다. 최소 TLS 버전과 암호 제품군을 설정할 수도 있습니다. 이를 통해 악성 애플리케이션이 연결을 하이재킹하는 것을 방지하고 클러스터 내의 트래픽을 암호화합니다. 백엔드 TLS 종료를 구성하려면 먼저 사용하려는 CA 인증으로 ConfigMap 을 만듭니다. 내부 Kubernetes 인증서 관리에 대한 도움말은 이 가이드를 확인하세요 .
kind: ConfigMap apiVersion: v1 metadata: name: backend-cert data: ca.crt: < -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- >secure-app다음으로, 서비스를 타겟으로 하고 이전 단계에서 만든 ConfigMap을 참조하는 BackendTLSPolicy를 만듭니다 .
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: BackendTLSPolicy metadata: name: backend-tls spec: targetRef: group: '' kind: Service name: secure-app namespace: default tls: caCertRefs: - name: backend-cert group: '' kind: ConfigMap hostname: secure-app.example.comURL 다시 쓰기
URLRewrite 필터를 사용하면 들어오는 요청의 원래 URL을 수정하여 성능에 전혀 영향을 미치지 않고 다른 URL로 리디렉션할 수 있습니다. 이 기능은 백엔드 애플리케이션이 노출된 API를 변경하지만 기존 클라이언트에 대한 이전 버전과의 호환성을 유지하려는 경우에 특히 유용합니다. 또한 이 기능을 사용하여 클라이언트에 일관된 API URL을 노출하는 동시에 다른 API URL을 사용하여 요청을 다른 애플리케이션으로 리디렉션하여 클라이언트의 편의성과 성능을 위해 여러 다른 API의 기능을 결합한 "경험" API를 제공할 수 있습니다. 시작하려면 NGINX 게이트웨이 패브릭에 대한 게이트웨이를 만들어 보겠습니다. 이를 통해 HTTP 리스너를 정의하고 최적의 성능을 위해 포트 80을 구성할 수 있습니다.
apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: cafe spec: gatewayClassName: nginx listeners: - name: http port: 80 protocol: HTTPHTTPRoute 리소스를 만들고 요청 필터를 구성하여 /coffee에 대한 모든 요청을 /beans로 다시 작성해 보겠습니다. 백엔드가 처리할 /latte 접두사를 포함하도록 다시 작성된 /latte 엔드포인트를 제공할 수도 있습니다("/latte/126"이 "/126"이 됨).
apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: coffee spec: parentRefs: - name: cafe sectionName: http hostnames: - "cafe.example.com" rules: - matches: - path: type: PathPrefix value: /coffee filters: - type: URLRewrite urlRewrite: path: type: ReplaceFullPath replaceFullPath: /beans backendRefs: - name: coffee port: 80 - matches: - path: type: PathPrefix value: /latte filters: - type: URLRewrite urlRewrite: path: type: ReplacePrefixMatch replacePrefixMatch: / backendRefs: - name: coffee port: 80HTTP 재작성 기능은 클라이언트 측의 엔드포인트와 백엔드와 매핑되는 방식 간의 유연성을 보장하는 데 도움이 됩니다. 또한 한 URL에서 다른 URL로 트래픽을 리디렉션할 수 있어 특히 콘텐츠를 새 웹사이트나 API 트래픽으로 마이그레이션할 때 유용합니다. NGINX Gateway Fabric은 경로 기반 재작성을 지원하지만 현재는 경로 기반 리디렉션을 지원하지 않습니다. 이 기능이 환경에 필요한지 알려주세요 .
제품 원격 측정 (Telemetry)
우리는 1.2 릴리스의 일부로 수동적으로 피드백을 수집하는 메커니즘으로 제품 원격 측정을 포함하기로 결정했습니다. 이 기능은 환경에서 다양한 메트릭을 수집하여 24시간마다 데이터 수집 플랫폼으로 전송합니다. PII는 수집되지 않으며 수집되는 전체 목록은 여기 에서 확인할 수 있습니다 . 우리는 원격 측정 기능에 대한 완전한 투명성을 제공하기 위해 최선을 다하고 있습니다. 수집하는 모든 필드를 문서화하고 코드로 수집하는 내용을 검증할 수 있지만, 항상 완전히 비활성화할 수 있는 옵션이 있습니다. 커뮤니티 회의 에서 커뮤니티와 함께 수집한 통계를 기반으로 흥미로운 관찰 결과를 정기적으로 검토할 계획 이므로 꼭 들러주세요!
자원
NGINX Gateway Fabric 1.2.0의 전체 변경 사항은 릴리스 노트를 참조하세요 . NGINX Plus로 Kubernetes용 NGINX Gateway Fabric을 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의하세요 . 참여하고 싶거나, 앞으로 나올 내용을 보고 싶거나, NGINX Gateway Fabric의 소스 코드를 보고 싶다면 GitHub 에서 저희 리포지토리를 확인하세요 ! 월요일 오전 9시 태평양/오후 5시 GMT에 2주마다 커뮤니티 회의가 있습니다. 회의 링크, 업데이트, 일정 및 메모는 NGINX Gateway Fabric 회의 일정 에 있습니다 . 링크는 항상 GitHub readme에서도 사용할 수 있습니다.
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
쿠버네티스에서 인공 지능(AI) 및 머신 러닝(ML) 워크로드를 실행하는 주요 이점 중 하나는 Ingress Controller를 통해 들어오는 모든 요청에 대한 중앙 제어 지점을 갖는 것입니다. 로드 밸런서 및 API 게이트웨이 역할을 하는 다재다능한 모듈로, 쿠버네티스 환경에서 AI/ML 애플리케이션을 보호하기 위한 견고한 기반을 제공합니다.
통합 도구인 Ingress Controller는 보안 및 성능 측정을 적용하고, 활동을 모니터링하고, 규정 준수를 의무화하는 데 편리한 터치포인트입니다. 더 구체적으로, Kubernetes 환경에서 Ingress Controller에서 AI/ML 애플리케이션을 보호하면 이 블로그에서 살펴보는 몇 가지 전략적 이점이 있습니다.
중앙 집중식 보안 및 규정 준수 제어
Ingress Controller는 Kubernetes 클러스터에 대한 게이트웨이 역할을 하므로 MLOps 및 플랫폼 엔지니어링 팀이 보안 정책을 시행하기 위한 중앙 집중식 지점을 구현할 수 있습니다. 이를 통해 포드별 또는 서비스별로 보안 설정을 구성하는 복잡성이 줄어듭니다. Ingress 수준에서 보안 제어를 중앙 집중화하면 규정 준수 프로세스가 간소화되고 규정 준수 상태를 관리하고 모니터링하기가 더 쉬워집니다.
통합 인증 및 권한 부여
Ingress Controller는 모든 AI/ML 애플리케이션에 대한 액세스에 대한 인증 및 승인을 구현하고 시행하는 논리적인 위치이기도 합니다. 강력한 인증 기관 관리를 추가함으로써 Ingress Controller는 Kubernetes를 위한 제로 트러스트(ZT) 아키텍처를 구축하는 핵심이기도 합니다. ZT는 매우 귀중한 독점 데이터에서 실행되는 민감한 AI 애플리케이션의 지속적인 보안 및 규정 준수를 보장하는 데 필수적입니다.
속도 제한 및 액세스 제어
Ingress Controller는 속도 제한을 시행하여 DDoS 공격이나 과도한 API 호출과 같은 남용으로부터 애플리케이션을 보호하기에 이상적인 곳으로, 이는 공개 AI/ML API에 필수적입니다. 모델 도난 및 데이터 유출과 같은 새로운 AI 위협이 증가함에 따라 속도 제한 및 액세스 제어를 시행하는 것이 무차별 대입 공격으로부터 보호하는 데 더욱 중요해지고 있습니다. 또한 적대자가 비즈니스 로직을 남용하거나 가드레일을 탈옥하여 데이터를 추출하고 학습을 모델링하거나 정보에 가중치를 두는 것을 방지하는 데 도움이 됩니다.
웹 애플리케이션 방화벽(WAF) 통합
많은 Ingress Controller는 노출된 애플리케이션과 서비스를 보호하기 위한 기본 요소인 WAF와의 통합을 지원합니다. WAF는 OWASP 10과 같은 일반적인 웹 취약성과 공격에 대한 추가 보안 계층을 제공합니다. 더욱 중요한 점은 적절하게 조정하면 WAF가 AI/ML 애플리케이션을 겨냥한 보다 집중적인 공격으로부터 보호한다는 것입니다. 지연 시간과 성능이 중요한 AI/ML 앱의 주요 고려 사항은 WAF로 인해 발생할 수 있는 잠재적인 오버헤드입니다. 또한 AI/ML 앱에서 효과적이려면 WAF를 모니터링 및 관찰 대시보드와 알림 구조를 위해 Ingress Controller에 긴밀하게 통합해야 합니다. WAF와 Ingress Controller가 공통 데이터 플레인을 공유할 수 있다면 이상적입니다.
결론: AI/ML 아키텍처 계획 초기에 Ingress Controller 포함
Ingress Controller는 AI/ML 앱을 위한 Kubernetes 애플리케이션 배포에서 매우 중요한 위치를 차지하기 때문에 AI/ML 애플리케이션을 설계하는 과정에서 해당 기능을 포함하는 것이 가장 좋습니다. 이를 통해 기능 중복을 완화하고 AI/ML 애플리케이션 요구 사항에 따라 확장 및 성장할 Ingress Controller에 대한 더 나은 결정을 내릴 수 있습니다. MLOps 팀의 경우 Ingress Controller는 보안을 최우선 순위로 두고 많은 중요한 플랫폼 및 운영 기능에 대한 중앙 제어 지점이 됩니다.
NGINX 시작하기
NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성, 관찰성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기