DevOps vs Network: 제어 문제를 관리하는 방법
제 안의 엔지니어는 이 모든 것이 흥미롭다고 생각하지만, 기술 관리자는 이러한 빠른 발전이 가져오는 도전과 그에 따른 기대치를 잘 알고 있습니다. 이러한 도전 과제 중 가장 중요한 것은 제어 문제입니다. 우리는 레거시 인프라를 보다 유연한 웹 아키텍처로 전환하는 데 큰 진전을 이루었지만, 여전히 레거시 규칙을 사용하여 누가 무엇을 제어할지 위임하고 있습니다. 그렇기 때문에 오늘날 많은 기업에서 애플리케이션을 구축하고 성능을 가속화하는 데 가장 큰 책임이 있는 DevOps 엔지니어가 아닌 네트워크 팀이 여전히 애플리케이션 전송을 제어하고 있습니다. 말할 필요도 없이 이는 문제가 될 수 있습니다.
수년 동안 기술과 인프라가 극적으로 변화했다는 사실에는 이견이 없습니다. 웹 사이트는 “파일과 스크립트만 나열된” 형태에서 재사용 가능한 코드 구성 요소로 이루어진 복잡한 모듈형 애플리케이션으로 진화한 지 오래되었으며, 이 모든 것이 인터넷 통신의 주요 프로토콜로 자리 잡은 HTTP를 사용합니다. 그리고 이러한 웹 애플리케이션은 이제 사람들의 삶을 운영합니다. 사용자는 즉각적인 응답, 완벽한 동작, 모든 디바이스에서 원활하게 작동하는 앱을 기대합니다.
목차
1. 경쟁적인 우선순위와 복잡성으로 인해 팀 성과와 효율성이 저하됩니다.
2. Sofetware-Based Solution: 새로운 희망
3. DevOps Tool로 제어 권한 강화
1. 경쟁적인 우선순위와 복잡성으로 인해 팀 성과와 효율성이 저하됩니다.
다음과 같은 어려움이 익숙하게 느껴지시나요? 조직 내에서 이러한 상황을 목격한 적이 있을 것입니다. 그렇다면 제어와 책임의 불균형으로 인한 긴장과 갈등을 어떻게 해결할지 고민해 볼 때입니다.
개발자의 경우 보호 기능을 강화하기 위해 application-level access-control(ACL)을 추가하거나 변경하고 싶을 수도 있습니다. 또는 대기 애플리케이션 서버로 트래픽을 일시적으로 리다이렉션하고 싶을 수도 있습니다. 하지만 이러한 작업을 직접 처리하는 대신 네트워크 운영팀에 요청을 신중하게 작성하고(조직 전체에서 요청이 많으므로) 요청을 처리할 여유 시간이 생길 때까지 기다려야 합니다.
결국, 충분히 버그를 잡으면 다른 (훨씬 더 중요한) 업무를 처리하기 위해 이러한 간단한 제어 중 일부를 기꺼이 위임할 수도 있습니다. 그러나 일이 잘못되어 서비스 중단이 발생하면 책임을 져야 할 사람은 바로 여러분입니다. 공급업체의 ACL 기본값이 “implicit deny”인 특정 트래픽을 명시적으로 허용하는 것을 잊었거나, “reverse wildcard masks”를 엉망으로 만들었거나, 잘못된 인터페이스에 ACL을 적용했기 때문일 수도 있습니다. 어느 쪽이든 이길 수 없으며 양쪽 모두 시간을 잡아먹고 있습니다.
기업에서 하드웨어 기반 application delivery controller(ADC)를 사용하기 때문에 네트워크팀이 애플리케이션 전송에 대한 제어권을 유지하는 경우가 많습니다. 이러한 중앙 집중식 application deliver solution은 이미 단일 장애 지점으로 취약합니다. 이러한 위험과 애플리케이션을 신속하게 구축하고 배포하려는 조직에서 과중한 업무에 시달리는 네트워크 인프라팀의 관리를 결합하면 심각한 도박을 하는 것과 같습니다.
애플리케이션 개발자의 수가 네트워크 인프라 인력보다 훨씬 많은 경우가 많습니다. 수천 개의 가상화된 인스턴스, 수십 개의 애플리케이션, 수백 명의 DevOps 인력을 보유한 기업에서 private cloud의 대규모 application delivery controller 박스를 관리하는 네트워크 엔지니어는 단 두 명에 불과하다는 이야기는 흔하게 들을 수 있습니다. 네트워크팀은 web acceleration layer를 동시에 많이 변경하는 것에 대해 불안해하지만, 애플리케이션 로직이 네트워크로 이동하는 것에 대해서도 똑같이 당황스러워합니다.
하지만 빠른 네트워크가 항상 빠른 애플리케이션을 의미하는 것은 아니라는 점을 기억하세요. 잠재적으로 충돌할 수 있는 구성 라인이나 네트워킹 상자에 있는 막연한 스크립트가 이를 바꾸지는 못합니다. 실제로 네트워킹팀에 끝없이 많은 구성 변경 사항을 보내서 얻을 수 있는 것은 불만뿐입니다.
또 다른 불화의 원인은 오늘날 애플리케이션 시스템 엔지니어가 사용하는 현대적인 애자일 개발 프로세스에 있습니다. 엔지니어는 더 이상 제품을 빌드한 다음 다른 사람에게 배포 및 운영을 맡길 수 없으며, 반복을 빌드하고 배포하고 이 사이클을 반복해야 합니다. 그리고 이 주기에는 HTTP의 “heavy lifting”과 관련된 성능 및 확장성 문제에 대한 완전한 end-to-end 제어가 필요합니다. 누가 무엇을 제어할지 협의하면서 이를 관리해야 하면 엔지니어의 작업 속도가 느려지고 성능을 강화하는 변경을 수행하기 어려워질 수 있습니다.
2. Sofetware-Based Solution: 새로운 희망
그렇다면 DevOps 엔지니어는 무엇을 해야 할까요? 조직의 성능 및 보안 요구 사항을 준수하면서 웹 가속 및 애플리케이션 성능 작업에 중요한 복잡한 기능을 제어할 수 있는 실행 가능한 방법을 찾아야 합니다.
안타깝게도 10년 또는 15년 전에 시장에 출시된 툴을 사용할 수는 없습니다. 이러한 툴은 오래된 대규모 모놀리식 애플리케이션(소비자 및 엔터프라이즈 모두)을 위해 구축되었기 때문에 오늘날에는 분산되고 느슨하게 결합되며 구성 가능한 최신 애플리케이션에는 적합하지 않습니다. 또한 오늘날 네트워크 엔지니어는 애플리케이션 엔지니어가 HTTP의 복잡성을 극복하는 데 도움을 줄 수 있는 일이 많지 않습니다. 이들은 여전히 애플리케이션이 아닌 패킷에 초점을 맞춘 하드웨어 네트워킹 어플라이언스를 주로 담당하고 있습니다.
마지막으로, 대부분의 애플리케이션 프레임워크는 동시성 처리, 보안, 접속 제어 등 HTTP에 내재된 복잡성뿐만 아니라 일반적으로 Layer 7 트래픽 관리를 빠르고 쉽게 처리할 수 있는 좋은 방법을 제공하지도 않습니다.
그렇다면 해답은 무엇일까요? “네트워크”나 애플리케이션 프레임워크가 end-to-end 웹 가속에 큰 도움이 되지 않는다면, 이러한 긴장을 해소하고 DevOps에서 절실히 필요한 공감을 완전히 구현할 수 있는 소프트웨어 툴이 있을까요?
다행히도 대답은 “예”입니다. 많은 DevOps 환경에서 성공을 거둔 HAProxy, NGINX Plus, Varnish, Apache Traffic Server 등 매우 유용한 툴이 몇 가지 있습니다. 이러한 툴은 모든 일반 운영체제에 적합한 컴팩트한 소프트웨어 전용 패키지의 우아함과 편리함을 웹 가속 툴의 기능과 결합한 것입니다. 또한 모든 물리적 또는 가상 서버 인스턴스에 단 몇 초 만에 배포할 수 있습니다.
이러한 툴 중 일부는 server load balancing 또는 SSL termination과 같은 웹 가속 기술의 하위 집합에만 특화되어 있는 반면, 다른 툴(예: NGINX Plus)는 Layer 7 로드 밸런싱, 요청 라우팅, 애플리케이션 및 콘텐츠 전송, 웹 캐싱, SSL termination, on-the-fly 압축, 프로토콜 최적화 등과 같은 모든 주요 기능을 다룹니다.
이러한 DevOps 툴은 “애플리케이션 스타일” 구성을 따르며, Puppet이나 Docker와 같은 다른 툴을 사용한 자동화에 가장 적합합니다. 또한 가상화된 환경에서 매우 효율적으로 실행되고, 클라우드 환경에 쉽게 배포할 수 있으며, 애플리케이션과 쉽게 함께 배치할 수 있고, 마지막으로 애플리케이션 자체로도 사용할 수 있습니다. 동시에 이러한 제품은 이제 하드웨어 기반 네트워킹 어플라이언스의 성능과 동등하거나 능가하며, 훨씬 적은 비용으로 처리량에 제한이 없습니다.
마지막으로, 가장 중요한 것은 DevOps팀이 오랫동안 기다려온 HTTP 성능과 확장성에 대한 end-to-end 제어 기능을 제공한다는 점입니다.
3. DevOps Tool로 제어 권한 강화
따라서 DevOps 툴을 도입하는 것이 평화로운 공감을 실현할 수 있는 방법입니다. 패킷 이동, QoS 제어 및 기타 기존 네트워크 관련 기능은 네트워크 인프라팀에 맡기고, DevOps팀이 전적으로 구축하고 관리하는 소프트웨어 기반의 scale-out layer에서 Layer 7 기능을 구현하면 DevOps와 네트워크 인프라팀이 행복하게 공존하며 보다 효과적으로 협력할 수 있습니다.
누가 혜택을 받나요? 모두가 혜택을 받습니다. 엔지니어링 조직은 보다 원활한 운영, 빠른 배포 및 구성, 간소화된 애플리케이션 개발의 이점을 누릴 수 있습니다. 네트워크팀은 업무 부담이 줄어들고 필요한 경우 제어권을 유지하면서 본연의 업무에 집중할 수 있습니다. 사용자는 더 나은 애플리케이션 경험의 혜택을 누릴 수 있습니다. 그리고 궁극적으로 기업은 시장의 기대치를 충족하는 고성능 애플리케이션을 효율적으로 제공할 수 있는 이점을 누릴 수 있습니다.
이 소프트웨어 기반 접근 방식을 직접 사용해 보고 팀이 얼마나 빠르고, 효율적이며, 행복해질 수 있는지 확인해 보시기 바랍니다. 하드웨어 기반 application delivery controller를 대체할 수 있는 NGINX Plus 30일 무료 체험판을 지금 바로 시작하시거나, NGINX STORE에 연락하여 NGINX가 어떻게 성능, 보안, 안정성, 확장성을 갖춘 애플리케이션을 DevOps 친화적인 방식으로 전송하는 데 도움이 되는지 자세히 알아보시기 바랍니다.
NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.
