DevOps 솔루션으로 Self-Service 애플리케이션 제공

현대 시장은 민첩성, 유연성, 그리고 무엇보다도 속도를 요구합니다. 새로운 애플리케이션과 기능을 더 빨리 출시할수록 더 좋으며 기업들은 이를 주목하고 있습니다. 2018년 현재 기업의 72%가 내년 안에 DevOps 방법론을 구현할 계획이며 DevOps 시장은 2023년까지 94억 달러에 달할 것입니다.

그러나 조직이 DevOps 비전을 실행에 옮기면서 인프라팀은 개발팀과 같은 속도로 작업하여 복잡한 데이터 센터, 클라우드 및 가상화 환경에서 필요한 서비스와 정책을 제공해야 하는 새로운 개발 중심의 현실에 직면하고 있습니다.

목차

1. 인프라 병목 현상
2. Shadow IT
3. Self-Service는 DevOps가 안전하게 실행되도록 지원합니다.
4. Self-Service 애플리케이션의 세 가지 구성 요소
4-1. Self-Service 구성 요소 1: 경량 소프트웨어 기반 Load Balancer
4-2. Self-Service 구성 요소 2: 통합 웹 애플리케이션 방화벽
 4-3. Self-Service 구성요소 3: RBAC를 지원하는 애플리케이션 Centric 포털
5. NGINX Plus는 인프라팀이 DevOps에게 Self-Service를 제공할 수 있도록 지원합니다.
6. NGINX Plus DevOps 솔루션 시작

1. 인프라 병목 현상

많은 조직이 신속한 개발과 안정성, 확장성, 안정성 및 보안과 같은 운영 요구사항의 균형을 맞추는 데 어려움을 겪고 있습니다. 가상화 및 컨테이너화의 증가로 인프라팀의 Agility이 향상되어 NetOps 및 SecOps팀이 애플리케이션 개발 Lifecycle의 일부로 인프라를 자동화할 수 있게 되었습니다. 그러나 인프라팀은 DevOps 팀이 새로운 수준에 도달하더라도 여전히 병목 현상을 겪고 있습니다.

현실은 인프라가 여전히 느리다는 것입니다. Red Hat의 조사에 따르면 현재 전체 애플리케이션 인프라 구축의 절반 미만이 자동화되어 있습니다. 또한 인프라팀은 티켓 기반 접근 방식을 통해 서비스를 계속 제공하고 있습니다. DevOps 및 IT 전문가의 거의 절반은 인프라 액세스를 최대 한 달까지 기다리는 것으로 보고했으며, 나머지 24%는 한 달 이상 걸리는 경우도 있다고 답했습니다.

몇 주 또는 몇 달은 고사하고 며칠을 기다려서 이사하고 싶은 사람이 있습니까? 특히 시장의 기대에 따라 가능한 한 빨리 제공할 수 있는 개발자는 없습니다. 결과적으로, 이러한 병목 현상은 애플리케이션의 안정성과 보안뿐만 아니라 조직 전체에 심각한 위험을 초래할 수 있습니다.

2. Shadow IT

DevOps 의 기본은 자율성, 협업 및 반복을 통해 시장 출시 시간을 단축하고 온라인 경험을 개선하는 것입니다.

많은 DevOps 팀은 IT팀의 승인 여부에 관계없이 생산성을 위한 최선의 방법이 새로운 기술과 도구를 사용하는 것임을 깨닫고 있는 것 같습니다. 이는 인프라팀이 두려워하는 “Shadow IT”입니다. 예를 들어 Ansible 또는 Terraform과 같은 자동화 도구는 인프라를 코드로 배포하여 더 쉽게 만듭니다. 또는 DevOps 팀이 테스트 또는 애플리케이션 업데이트를 더 빠르게 만들고 기존 CI/CD 도구와 통합하는 GitHub의 프로젝트를 사용할 수 있습니다.

엔터프라이즈 개발자들이 어두운 쪽으로 눈을 돌리는 이유는 무엇입니까? 그것은 그들이 코드를 빨리 릴리스하는 한 가지 최종 목표에 초점을 맞추고 있기 때문입니다. Mission‑Critical 애플리케이션을 다운시키거나 고객 데이터를 손상시킬 수 있는 도구 설계 및 구현 약점을 인식하는 데 필요한 전체적인 상황과 가시성이 부족한 경우가 많습니다. 인프라가 바로 그것입니다. 개발자들은 인프라로 인해 속도가 느려지는 것을 원하지 않을 수도 있지만, 문제가 발생하면 모두가 알아차립니다. 동시에 개발자의 자유를 제한하면 빠르게 움직일 수 있는 능력이 손상되어 시장 경쟁력과 수익에 영향을 미칠 수 있습니다.

3. Self-Service는 DevOps 가 안전하게 실행되도록 지원합니다.

조직에서 개발팀에게 필요한 자유를 제공하는 동시에 인프라팀이 작업을 수행할 수 있도록 보장하려면 어떻게 해야 합니까?

예를 들어, 한 회사에 50개의 개별 Microservices를 작업하는 30개의 서로 다른 개발팀이 있다고 가정합시다. 승인을 받기까지 6주를 기다리지 않고 서비스를 프로비저닝(Provisioning)하고, 새로운 기능을 테스트 및 배포하고, 새로운 코드에 대한 보안 변경 사항을 조정하도록 하려면 어떻게 해야 할까요? 바로 여기에서 Self-Service가 필요합니다.

DevOps 및 Shadow IT의 역사를 감안할 때 인프라팀은 Self-Service가 혼란을 초래할 뿐이라고 생각할 수 있습니다. 개발자가 전적으로 자신의 장치에 의존하고 Shadow IT를 채택하게 되면 때로는 높은 비용, 중복된 노력, 일관되지 않은 정책, 호환되지 않는 플랫폼 및 표준의 흔적을 남기기도 합니다.

많은 조직에서 인프라팀은 Scissors를 치우고 개발자를 걷게 하는 것을 자신의 책임으로 여기고 개발자는 결국 이에 대해 분개하게 됩니다. 이러한 마찰을 없애기 위해 인프라팀은 새로운 목표를 채택해야 합니다. 즉, 개발자의 실행을 중단하는 것이 아니라, 안전하게 실행할 수 있는 다양한 도구를 제공하는 것입니다.

인프라팀은 CI/CD 프레임워크에 통합되고 레거시 애플리케이션 및 클라우드 네이티브 Modern 애플리케이션과 원활하게 작동하는 애플리케이션 제공 및 보안 서비스를 제공해야 합니다. 이를 통해 개발자는 티켓을 제출하지 않고도 인프라 리소스와 보안 정책을 사용할 수 있습니다.

4. Self-Service 애플리케이션의 세 가지 구성 요소

Self-Service 애플리케이션 및 보안을 제공하려면 Load Balancer, 웹 애플리케이션 방화벽(Web Application Firewall, WAF) 및 Self-Service 포털의 세 가지 기본 구성 요소가 필요합니다. 세 가지 모두 서로 협력하여 코드형 인프라로 배포되어야 합니다. 대부분의 개발자가 여러 플랫폼에서 작업하는 경우 구성 요소는 인프라에 구애받지 않고 Bare Metal, 가상 머신 및 클라우드 플랫폼에 배포할 수 있어야 합니다.

다음은 Self-Service를 만드는 데 필요한 구성 요소의 특성에 대한 요약입니다.

4-1. Self-Service 구성 요소 1: 경량 소프트웨어 기반 Load Balancer

새로운 기능을 출시하거나 새로운 서비스를 배포할 때 애플리케이션팀은 코드를 테스트해야 합니다. 새 코드로 트래픽을 천천히 늘리고(Canary 테스트), 사용자가 새 코드와 이전 코드에 어떻게 반응하는지 테스트하고(A/B Testing), 새 코드로 Zero Down‑Time Rollover 제공(Blue‑Green 배포) 또는 새 코드가 원하는 대로 작동하지 않는 경우 장애 조치 메커니즘을 제공합니다(Circuit-Breaker 패턴).

이러한 모든 테스트 패턴에는 개발자가 원하는 결과에 따라 사용자와 트래픽을 안내하는 Load Balancer가 필요합니다. Self-Service 환경에서 애플리케이션팀은 인프라팀에 티켓을 제출하는 대신 서비스 포털 또는 구성 API를 사용하여 실시간으로 애플리케이션별 Load Balancer를 구성합니다. 새 코드의 효율성을 테스트하기 위해 몇 시간, 며칠 또는 몇 주를 기다릴 필요가 없습니다.

Self-Service Load Balancer는 기본 네트워크 기반 Load Balancer 뒤의 자체 전용 계층에 있습니다. 또한 각 애플리케이션(서비스 또는 Microservice)은 이 계층에서 자체 전용 Load Balancer 인스턴스를 얻습니다. 이렇게 하면 각 구성 변경이 다른 모든 애플리케이션에 대해 재귀 테스트할 필요가 없습니다.

4-2. Self-Service 구성 요소 2: 통합 웹 애플리케이션 방화벽

Self-Service Load Balancer는 새 코드 릴리스를 지연시키는 프로세스를 제거하여 개발자 생산성을 높입니다. 그러나 기업이 이 새로운 코드에서 악용 위험을 최소화하려면 WAF가 필요합니다. 그러나 문제가 있습니다. WAF는 구성하기가 쉬운 것은 아닙니다. 실제로 많은 애플리케이션팀은 WAF를 오히려 피하고 싶은 장애물로 보고 있습니다.

Load Balancer와 마찬가지로 기업에는 소프트웨어 Load Balancer와 동일한 인스턴스 또는 근처에서 실행되는 애플리에키션에 더 가까이 위치할 수 있는 경량의 소프트웨어 기반 WAF가 필요합니다. 애플리케이션을 집안의 방으로 생각하십시오. Self-Service Load Balancer는 이러한 각 방의 문입니다. WAF는 해당 문의 잠금 장치입니다. 오늘날의 Zero‑Trust 환경에서는 각 방문에 자체 잠금 장치가 필요합니다. 기업은 더 이상 집 전체에 대한 단일 보안 제어에 의존할 수 없습니다.

Self-Service WAF는 보안팀이 개발자의 작업에 방해가 되지 않는 세분화된 보안 제어로 각 WAF를 구성할 수 있는 곳입니다. Canary, A/B, Blue-Green 및 Circuit-Breaker 패턴을 지원하는 동일한 CI/CD Pipeline 및 Infrastructure-as-Code 자동화를 통해 알려진 공격, 서비스 거부 공격 및 Bot 공격으로부터 새 코드를 보호하는 데 필요한 보안 정책을 구성할 수 있습니다.

4-3. Self-Service 구성요소 3: RBAC를 지원하는 애플리케이션 Centric 포털

경량 소프트웨어 기반 Load Balancer 및 WAF는 Data Plane에서 무거운 작업을 수행합니다. 그러나 Self-Service 환경에서 이러한 기능을 제대로 작동하려면 포털과 Role‑Based Access Control(RBAC)를 통해 이러한 기능을 Expose하는 방법이 필요합니다. 이를 위해서는 Data Plane 위에 계층화된 제어 및 관리 Plane 기술이 추가로 필요합니다.

특히 Control Plane은 추가 구성 및 오케스트레이션 기능을 제공합니다. 이를 통해 Load Balancer 및 WAF의 새 인스턴스를 필요에 따라 가동 및 중지하고 빠른 구성 변경이 가능하도록 하여 인프라를 Self-Service할 수 있습니다. 이 모든 것은 CI/CD Pipeline에 자동화되고 통합될 수 있도록 API를 통해 Expose 되어야 합니다.

Control Plane 위에는 Self-Service 포털을 생성하고 RBAC 정책을 시행할 수 있는 Control Plane이 있습니다. 이러한 방식으로 특정 애플리케이션팀은 구성 권한이 있는 인프라만 볼 수 있습니다. 이러한 포털은 팀이 해당 애플리케이션과 관련된 정책, Workflow 및 트래픽 관리에 집중할 수 있도록 애플리케이션 중심이어야 합니다.

5. NGINX Plus는 인프라팀이 DevOps 에게 Self-Service를 제공할 수 있도록 지원합니다.

인프라팀이 최고 수준의 개발자 경험을 제공하는 서비스와 도구를 제공하는 것으로 시작한다면 DevOps 동료의 눈에는 악당이 아닌 영웅이 될 수 있습니다. NGINX Plus Self-Service는 CI/CD 친화적인 도구와 Self-Service 애플리케이션 관리를 제공하여 DevOps , NetOps 및 SecOps 간의 마찰을 제거합니다.

이유는 다음과 같습니다.

  • NGINX Plus는 DevOps가 사용하고자 하는 표준입니다. NGINX Plus는 Open Source에 깊은 뿌리를 두고 있으며 이미 우리 제품을 사랑하고 사용하는 기업은 강력한 커뮤니티의 지원을 받고 있습니다. 또한 인프라팀을 만족시킬 수 있는 안정성과 성능을 제공하는 입증된 Production‑Ready 플랫폼을 기반으로 합니다. 개발팀이 스스로 선택하는 경우가 많은 도구를 제공하면 개발자가 자신의 손으로 일을 처리하고 악의적으로 행동할 가능성을 줄이는 데 도움이 됩니다.
  • NGINX Plus는 인프라 가드레일(Guardrail)과 개발 자율성의 균형을 맞춥니다. NGINX Plus를 통해 인프라팀은 개발자가 Canary, A/B Testing, Blue-Green 배포, Circuit‑Breaker 패턴과 같은 기능에 필요한 애플리케이션 제공 및 보안 기술을 출시할 수 있습니다. 동시에 인프라팀은 Production 애플리케이션이 일관되고 안정적이며 안전한 상태를 유지하도록 보장하는 가드레일(guardrail)을 설정할 수 있는 권한을 유지합니다.
  • NGINX Plus는 Self-Service를 자동화하고 CI/CD Pipeline에 통합합니다. NGINX Plus 인프라의 확장성을 보장하는 선언적 API 덕분에 Red Hat Ansible 역할 모음을 사용하여 인프라 기능을 CI/CD Pipeline 및 자동화 도구에 쉽게 통합할 수 있습니다. 또한 개발팀이 자체 NGINX Plus 지침을 구성하기 위해 직접 액세스할 수 있도록 Self-Service 포털 및 RBAC를 제공합니다. 퍼블릭 클라우드 공급자처럼 간단하게 인프라 프로비저닝을 수행할 수 있도록 서비스 카탈로그를 제공한다고 생각하십시오.
  • NGINX Plus는 내부 WAF-as-a-service로 보안을 강화합니다. NGINX Plus는 NGINX App Protect를 기본 WAF로 제공하여 Self-Service 기능과 분석을 제공하여 보안팀이 개발자 생산성을 저하시키지 않고 더 많은 제어를 할 수 있도록 합니다. NGINX Plus는 NGINX App Protect의 강력한 기능을 Self-Service 환경에 제공하는 보안 프로비저닝 추가 기능을 제공합니다. 동일한 선언적 API, Self-Service 포털 및 RBAC Control을 통해 이제 보안팀은 CI/CD Pipeline에 완전히 통합된 제어를 배포할 수 있습니다.

6. NGINX Plus DevOps 솔루션 시작

NGINX Plus로 DevOps Self-Service 애플리케이션 및 보안 인프라 통합을 테스트 및 사용해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.