NGINX Controller를 활용한 더 안전한 구성 관리

Brian Ehlert제품 관리 이사

지난 1년간 고객들과 대화를 나누면서, 고객들이 다음과 같은 몇 가지 공통된 이유로 NGINX Controller와 같은 오케스트레이션 제품을 검토한다는 사실을 알게 되었습니다:

• 복잡성 – 서로 다른 소스에서 가져온 수많은 개별 구성 객체를 관리, 유지 보수, 검증 및 적용하는 일은 쉽지 않습니다.
• 취약성 – 규모 확장은 특정 사건에 대응하여 빠르게 이루어지는 경우가 많습니다. 때로는 전략적으로 진행되기도 하지만, 모든 운영 부서에서 흔히 그렇듯 계획 없이 자연스럽게 이루어지기도 합니다.
• 안전성 – 오류를 방지하고 프로덕션에 배포하기 전에 문제를 발견하는 것은 애자일 방법론의 핵심 원칙입니다. 이는 복잡성과 취약성을 완화하는 데도 도움이 됩니다.

이러한 문제는 일반적으로 고객이 애플리케이션을 처음 배포할 때 겪는 것이 아닙니다. 오히려 시간이 지나 애플리케이션이 성공을 거두고 확장해야 할 필요가 생기면서 나타납니다. 저희가 파악한 바로는 확장, 더 정확히 말하면 계획되지 않은 확장이 위에 나열된 문제들의 공통된 근본 원인입니다.

다행히 NGINX Controller 구성 객체 모델은 이 세 가지 문제를 모두 해결합니다:

• 특정 복잡성을 줄입니다. 특정 NGINX Plus 인스턴스 집합에 영향을 줄 수 있는 모든 구성 요소를 한곳에 모아 배포 복잡성을 줄입니다.
• 팀이 구성을 프로덕션에 적용하기 전에 검증하고 테스트할 수 있도록 하여 취약성을 줄이고, 문제를 조기에 발견하기 쉽게 하며, 프로덕션 사용자 트래픽이 중단 없이 계속 흐르도록 보장합니다.
• 높은 유연성을 바탕으로 안전성을 강화합니다. 모델에 맞춰 프로세스를 조정하도록 강요하는 대신, 구성 객체 모델은 비즈니스 워크플로 및 책임 분담 체계에 부합하도록 설계되어 있어 필요에 따라 여러 사업 부문에 구성 요소에 대한 적절한 소유권을 부여할 수 있습니다.

컨트롤러 구성 객체

Controller 모델의 작동 방식을 더 잘 이해할 수 있도록 몇 가지 주요 구성 객체를 좀 더 자세히 살펴보겠습니다.

환경

대부분의 조직에서 소프트웨어는 릴리스 전에 개발, 사용자 인수 테스트, 사전 프로덕션, 프로덕션 및 기타 품질 검사 등 여러 단계를 거칩니다. 이러한 단계는 Environment라는 NGINX Controller 객체에 해당합니다.

환경은 Controller 내 구성 요소를 위한 격리 영역입니다. 일반적으로 역할 기반 액세스 제어(RBAC)가 정의되는 수준입니다. 환경은 여러 단계를 거치면서 동일한 구성 아티팩트를 유지하되, 대상 서버, 데이터 센터 및 환경마다 일반적으로 달라지는 기타 인프라 개체와 같은 항목만 최소한으로 변경할 수 있습니다.

게이트웨이

게이트웨이는 환경 내의 구성 객체로, 애플리케이션을 고객에게 제공하는 방식을 정의하는 최상위 수준에서 주로 사용됩니다. 여기에는 호스트 이름, 프로토콜, TLS/SSL 동작 등의 설정이 포함되지만, 이러한 설정은 하위 수준에서도 지정할 수 있습니다. 실제로 게이트웨이 객체는 에지 네트워크 어플라이언스나 DMZ를 관리하는 네트워크 운영(NetOps) 팀이 소유하는 경우가 가장 많습니다. 또한 게이트웨이는 구성을 수신하여 실제 작업을 수행하는 NGINX Plus 인스턴스와 Controller를 연결하는 방식인 ‘배치(Placement)’ 개념을 사용합니다.

앱

그다음 하위 수준은 App 구성 객체로, 여기서 애플리케이션을 모델링하고 트래픽 조정 동작을 그룹화하기 시작합니다. 조직의 요구 사항에 따라 필요한 만큼 App을 사용할 수 있습니다. 유일한 요구 사항은 하나의 Environment 내에서 각 App이 고유해야 한다는 것입니다.

구성 요소

앱 내에서 구성 요소는 해당 앱에 원하는 트래픽 조정 동작을 정의합니다. 가장 간단한 경우에는 특정 경로 이름으로 들어오는 모든 트래픽이 동일한 서버 그룹으로 전송됩니다. 하지만 구성 요소를 통해 헤더 조작, URL 재작성, 백엔드 부하 분산 동작, 쿠키 처리 및 기타 설정과 같은 고급 트래픽 조정도 제어할 수 있습니다. 호스트 이름 및 TLS/SSL 동작도 이 수준에서 정의할 수 있습니다.

종합하기

다음은 구성 객체 간의 관계를 시각적으로 나타낸 것입니다:

Controller와 상호 작용하는 그룹은 두 개뿐이며, 이 경우 두 개발 팀인 Referral 및 Transfers입니다. 실제로 애플리케이션 제공 및 보안에 관여하는 인원은 네트워킹 및 보안(Platform Ops), DevOps, 애플리케이션 개발 등 훨씬 더 광범위할 가능성이 큽니다. 전문 지식이 가장 풍부한 팀은 모범 사례에 부합하는 정책을 설정하고 셀프서비스 워크플로를 구축하여, 조직의 동부 및 서부 데이터 센터 위치에 걸쳐 있는 “Dev” 환경 내에서 Apps, Components 및 Gateways를 다루는 팀에 가드레일을 제공할 수 있습니다.

이를 조금 다른 관점, 즉 사업 부문(LOB)의 관점에서 살펴보겠습니다. 최신 앱과 관련된 의사 결정에서 사업 부문 책임자의 역할이 점점 커지고 있습니다.

다음 다이어그램은 다양한 LOB 팀과 모든 인증서 갱신을 관리하는 담당자인 Shawn을 비롯해 훨씬 더 많은 사용자가 포함된, 보다 현실적인 시나리오를 보여 줍니다.

이제 더 많은 개별 주체와 파이프라인이 최종 데이터 흐름에 영향을 미칩니다.

각 개별 파이프라인이 소스 제어 시스템(예: GitHub)에서 Controller로 전달되는 과정에서 다양한 객체 변경 사항을 거치면, 구성 객체가 Controller 측에서 검증된 후 관련 객체와 결합되고, 변경 사항이 NGINX Plus 인스턴스로 푸시됩니다.

Controller는 최신 변경 사항이 이전 설정 및 다른 애플리케이션과 LOB 소유자의 설정과 호환되는지 확인함으로써 구성 관리를 더욱 안전하게 수행할 수 있도록 지원합니다.

실제로 단일 NGINX Plus 인스턴스에 적용되는 모든 구성을 함께 사용할 수 있어야 하지만, 설정이 서로 충돌하거나 중복되어서는 안 됩니다. 또한 충돌을 사전에 감지하여 각 개별 구성 요소의 구성을 제공하는 담당자에게 알리는 것이 중요합니다.

위의 예에서 추천 컴포넌트가 이체 컴포넌트에서 이미 구현한 것과 동일한 정규식 패턴을 사용하려고 하면 경로 충돌이 즉시 감지되므로, 추천 팀은 이 구성을 프로덕션에 배포하기 훨씬 전에 알림을 받을 수 있으며 잘못된 구성으로 인한 수많은 골칫거리를 피할 수 있습니다.

인증서와 관련해서는 Controller의 RBAC 기능을 통해 Shawn이 인증서 변경 사항을 즉시 적용할 수 있습니다. Gateway 및 Component 유지 관리자는 올바른 인증서를 참조하기만 하면 되며, Shawn은 각 인증서의 수명 주기에 맞춰 안심하고 관리할 수 있습니다. Shawn이 Controller에서 인증서를 업데이트하면 해당 인증서가 올바른 인스턴스에 배포되므로 인증서 만료로 인해 다급하게 대응할 필요가 없습니다.

이제 NGINX Controller에 모든 구성 객체가 있고 하나 이상의 NGINX Plus 인스턴스에 대한 Placement 연결이 설정되었으므로, 마지막 단계인 구성 적용을 수행할 수 있습니다.

실무에서의 안전성

궁극적으로 Controller를 사용한 구성 관리의 목표는 올바른 위치에 있는 올바른 NGINX Plus 인스턴스에 올바른 구성을 적용하는 것입니다. 앱, 구성 요소, 게이트웨이 및 이와 관련된 모든 인증서와 인스턴스가 올바르게 구성되도록 하면 더욱 안전하고 확장성 높은 배포를 구현할 수 있습니다.

이 최종 검증은 Controller가 더 쉽고 안전하게 만들어 주는 구성 관리 프로세스의 마지막 단계입니다. 프록시로 배포된 NGINX Plus의 웹 워크로드 그룹에서 세션 지속성이 변경되는 경우처럼 관련 객체가 변경된 NGINX Plus 인스턴스에 전체 구성을 적용하면서, 해당 인스턴스가 원하는 구성과 호환되는지 검증합니다. 이 조건이 충족되면 구성이 적용됩니다. 마지막 안전장치로, 구성을 적용하는 동안 문제가 발생하면 Controller가 이전 구성으로 되돌립니다.

Controller는 구성이 검증을 통과하도록 보장할 뿐만 아니라, 새 구성이 적용될 때 세션 드레이닝과 같은 NGINX의 고급 기능도 활용하여 변경 중에도 사이트의 가용성과 성능을 유지할 수 있습니다.

운영 팀의 관점에서 위에 설명한 개념과 워크플로 설계는 NGINX Controller가 구성 관리에 제공하는 안전성을 강화합니다. 이러한 보호 장치는 워크플로와 최신 앱을 다루는 여러 팀 간의 조율을 돕는 동시에 비즈니스 요구 사항도 지원합니다.

NGINX Controller를 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Brian Ehlert제품 관리 이사

Brian Ehlert의 다른 블로그 게시물