NGINX Gateway Fabric 프로젝트 탄생 배경
이번 포스트에서는 NGINX Gateway Fabric 프로젝트를 시작한 이유에 대해서 살펴보겠습니다.
Kubernetes Ingress Controller의 세계에서 NGINX는 매우 성공적인 운영을 해왔습니다. NGINX Ingress Controller는 상용 Kubernetes 프로덕션 사용 사례에 널리 배포되는 동시에 오픈 소스 버전으로 개발 및 유지 관리되고 있습니다. 따라서 Kubernetes 네트워킹에 Gateway API 라는 큰 개선이 이루어졌을 때, 기존 Ingress 제품에 이 좋은 기능을 구현할 것이라고 생각할 수도 있습니다.
대신, 우리는 다른 길을 선택했습니다. 새로운 Gateway API의 놀라운 가능성과 쿠버네티스에서 연결을 처리하는 방법을 완전히 재구상할 수 있는 기회를 보면서, 기존 Ingress 제품에 Gateway API 구현을 끼워 넣는 것은 이 무한한 미래를 제한할 수 있다는 것을 깨달았습니다.
이것이 바로 자체 Gateway API 프로젝트인 NGINX Gateway Fabric 을 시작하기로 결정한 이유입니다. 이 프로젝트는 오픈 소스이며 투명하고 협력적으로 운영될 것입니다. 외부 기여자들과 함께 일하고 다른 사람들과 이 여정을 공유하며 특별하고 독특한 무언가를 만들 수 있기를 기대합니다.
목차
1. Gateway API 결정에 도달한 방법
2. NGINX Gateway Fabric 목표
3. Gateway API 여정에 동참하세요.
1. Gateway API 결정에 도달한 방법
Gateway API를 중심으로 완전히 새로운 프로젝트를 만들기로 한 결정은 낙관적이고 흥분된 마음에서 비롯된 것이지만, 이는 건전한 비즈니스 및 제품 전략 논리에 기반을 두고 있습니다.
오랫동안 Kubernetes를 사용해 온 사용자라면 이미 NGINX Ingress Controller의 오픈 소스 및 상용 버전에 대해 알고 있을 것입니다. 두 버전 모두 NGINX Plus와 NGINX 오픈 소스 리버스 프록시에서 실행되는 동일한 전투 테스트를 거친 NGINX Data Plane을 배포합니다. Kubernetes 이전에도 NGINX의 Data Plane은 로드 밸런싱과 리버스 프록시에 이미 훌륭하게 작동했습니다. Kubernetes에서 Ingress Controller는 동일한 유형의 중요한 요청 라우팅 및 애플리케이션 전송 작업을 수행합니다.
NGINX는 가볍고, 고성능이며, 충분한 테스트를 거쳤고, 까다로운 환경에서도 사용할 수 있는 상용 제품을 구축하는 데 자부심을 가지고 있습니다. 따라서 Kubernetes Ingress Control을 위한 제품 전략은 리버스 프록시에 대한 제품 전략과 유사합니다. 간단한 사용 사례를 위한 강력한 오픈 소스 제품을 만들고, 비즈니스에 중요한 애플리케이션 환경에서 프로덕션 Ingress Control을 위한 추가 기능과 성능을 갖춘 상용 제품을 만드는 것이죠. 이러한 전략은 Ingress Control의 세계에서 부분적으로 효과가 있었는데, 그 이유는 Ingress Control이 표준화가 부족하고 로드 밸런싱 및 리버스 프록시와 같은 고급 기능을 제공하기 위해 상당한 사용자 정의 리소스 정의(CRD)가 필요했기 때문에 개발자와 아키텍트는 Kubernetes 외부의 네트워킹 제품에서 즐겨 사용했습니다.
고객들은 NGINX Ingress Controller를 신뢰하고 의지하고 있으며, 상용 버전에는 이미 Gateway API가 해결하도록 설계된 주요 고급 기능이 다수 포함되어 있습니다. 또한, NGINX는 초기부터 Gateway API 프로젝트에 참여해 왔으며, Gateway API 생태계가 완전히 성숙하는 데 몇 년이 걸릴 것이라는 것을 알고 있었습니다. (실제로 Service Mesh와 더 잘 통합될 수 있도록 하는 GAMMA 사양과 같이 Gateway API의 많은 사양이 계속해서 발전하고 있습니다.)
하지만 베타 수준의 Gateway API 사양을 NGINX Ingress Controller에 적용하는 것은 성숙한 엔터프라이즈급 Ingress Controller에 불필요한 불확실성과 복잡성을 야기할 수 있다고 판단했습니다. 우리가 상업적으로 판매하는 모든 것은 안정적이고 신뢰할 수 있으며, 100% 프로덕션 준비가 되어 있어야 합니다. Gateway API 솔루션도 그렇게 될 것이지만, 그 과정은 아직 시작 단계에 불과합니다.
2. NGINX Gateway Fabric 목표
NGINX Gateway Fabric 을 통해 우리의 목표는 NGINX Plus와 NGINX 오픈 소스처럼 시간이 지나도 견딜 수 있는 제품을 만드는 것입니다. Gateway API 프로젝트에 “미래에도 사용할 수 있는” 이라는 이름을 붙일 수 있을 정도로 발전하려면 Data 및 Control Plane에 대한 아키텍처 선택에 대한 실험이 필요하다는 것을 깨달았습니다. 예를 들어, Layer 4와 Layer 7 연결을 관리하거나 외부 의존성을 최소화하는 다양한 방법을 모색해야 할 수도 있습니다. 이러한 실험은 과거의 선례와 요구 사항이 없는 백지상태에서 수행하는 것이 가장 좋습니다. 검증된 NGINX Data Plane을 NGINX Gateway Fabric 의 기본 구성 요소로 사용하고 있지만, 그 이상의 새로운 아이디어에도 열려 있습니다.
또한, Gateway API 리소스에 대해 공급업체에 구애받지 않는 포괄적인 구성 상호 운용성을 제공하고자 했습니다. 기존 Kubernetes Ingress 패러다임에 비해 Gateway API의 가장 큰 개선점 중 하나는 서비스 네트워킹의 많은 요소를 표준화한다는 것입니다. 이러한 표준화는 이론적으로 많은 Gateway API 리소스가 쉽게 상호 작용하고 연결할 수 있는 더 나은 미래로 이어져야 합니다.
3. Gateway API 여정에 동참하세요.
아직은 초기 단계입니다. 소수의 프로젝트와 제품만이 Gateway API 사양을 구현했으며, 대부분은 기존 프로젝트와 제품에 이를 포함하기로 결정했습니다.
즉, 지금이 새로운 프로젝트를 시작하기에 가장 좋은 기회의 시기라는 뜻입니다. 우리는 투명한 의사 결정과 프로젝트 거버넌스를 통해 완전히 공개적으로 NGINX Gateway Fabric 프로젝트를 운영하고 있습니다. 이 프로젝트는 Go로 작성되었기 때문에 대규모 Gopher 커뮤니티를 초대하여 제안을 하고, PR을 시작하고, 아이디어를 문의할 수 있습니다.
Gateway API가 전체 Kubernetes 환경을 변화시킬 가능성이 있습니다. 전체 제품 클래스가 더 이상 필요하지 않을 수도 있고 새로운 제품이 등장할 수도 있습니다. Gateway API는 워낙 풍부한 가능성을 제공하기 때문에 솔직히 어디까지 발전할지 모르겠지만, 저희는 그 여정이 정말 기대됩니다. 즐거운 여정이 될 것입니다!
다음과 같이 시작할 수 있습니다:
- 기여자로 프로젝트에 참여하기
- 실험실에서 구현 시도하기
- 테스트 및 피드백 제공
프로젝트에 참여하려면 GitHub의 NGINX Gateway Fabric을 방문하세요.
NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.
NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.
