NetOps를 위한 최소 기능 배포가 있을까요?

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

네트워크 자동화는 정말 전부 아니면 전무일까요?

프로덕션 파이프라인에 DevOps를 적용하는 네트워크 자동화는 이미 상당수의 조직에서 활용되고 있습니다. 전면적으로 도입한 조직은 극소수이지만, 대다수(최신 애플리케이션 딜리버리 현황에 따르면 77%)는 프로덕션 환경에서 자동화를 시범 운영하거나 부분적으로 사용하고 있습니다.

DevOps와 밀접하게 연관되어 있으며, 따라서 NetOps와도 자주 연결되는 개념 중 하나가 최소 기능 제품(MVP)입니다.

이는 애자일 방법론의 일부로, 개발 주기를 단축하고 솔루션을 더 빠르게 시장에 출시하기 위한 방식입니다. 이는 ‘네트워크’에 절실히 필요한 부분입니다. 이전 블로그에서 언급한 Appian 설문조사를 기억하실지도 모르겠습니다. 이 조사에서는 응답자의 72%가 비즈니스 요구에 맞춰 확장할 수 있는 IT의 역량을 신뢰하지 않는다는 충격적인 결과가 나왔습니다.

이런. IT 분야에서 자동화가 상당히 광범위하게 활용되고 있음에도 불구하고, 개발자와 비즈니스 이해관계자들은 여전히 우리가 일을 제대로 해낼 수 있을지 확신하지 못하고 있습니다.

따라서 더 스마트하게 확장하여 속도를 높이기 위해 DevOps의 도구, 기술, 방법론을 도입하는 것은 그리 터무니없는 일이 아닙니다. 하지만 MVP를 네트워크에 적용하는 방법을 알아내려면 먼저 MVP가 무엇인지 이해해야 합니다. DevOps, 애자일 또는 MVP가 생소한 분들을 위해 Agile Alliance에서 제시한 명확한 정의를 소개합니다.

이 글에서 짚고 넘어갈 점은 DevOps(및 이와 관련된 기술과 방법론)의 여러 개념이 NetOps 이니셔티브에 적용될 때 항상 잘 맞아떨어지는 것은 아니라는 사실입니다. 네트워크 변경을 논의할 때 IT 엔지니어, 아키텍트 또는 경영진은 ‘실험’이라는 용어를 사용하지 않습니다.

문제 발생 시 영향 범위가 워낙 넓고 막대하기 때문입니다. 대부분의 조직이 운영상의 위험을 감수하려 하지 않는 데에는 그럴 만한 이유가 있습니다. 서비스 중단은 실제로 막대한 비용을 초래하며, 때로는 일자리까지 잃게 만듭니다. 네트워크는 실험하기에 적합한 곳이 아닙니다.

그렇다고 해서 NetOps를 위한 최소 실행 가능 배포(MVD)가 존재하지 않는다는 뜻은 아닙니다.

NetOps를 위한 MVD 정의

오늘날의 프로덕션 파이프라인은 스위치, 라우터, DNS, 멀티클라우드 라우팅(GSLB)과 같은 공유 리소스뿐만 아니라 로드 밸런서, WAF, 애플리케이션 액세스 제어와 같은 앱별 애플리케이션 서비스로 구성됩니다.

흥미롭게도 공유 리소스의 변경 빈도를 살펴보면 상당히 낮다는 것을 알 수 있습니다. 즉, 변경이 자주 발생하지 않습니다. 이는 바람직한 특성입니다. 공유 리소스는 중단에 대한 허용 범위도 낮기 때문입니다. 반면 앱별 리소스는 변경 빈도가 더 높고 중단에 대한 허용 범위도 더 큽니다.

결국 이것이 앱별 아키텍처의 장점 중 하나입니다. 데이터 경로를 격리하여 문제가 발생하더라도 다른 앱이 영향을 받지 않도록 보호할 수 있습니다.

해당 데이터 경로에는 조직이 애플리케이션을 제공하고 보호하기 위해 사용하는 것으로 조사된 평균 16개의 서로 다른 애플리케이션 서비스가 있습니다. 네트워크 방화벽과 DNS 같은 일부 서비스는 공유 리소스입니다. 그 밖의 서비스는 그렇지 않으며, 적어도 공유 리소스일 필요는 없습니다. 현재는 공유 플랫폼에 배포되어 있을 수 있지만, 타당한 이유가 있다면 자체 데이터 경로를 갖도록 설계할 수 있습니다.

물론, 바로 그것을 지금부터 알려드리겠습니다.

그럴 만한 이유는 애플리케이션을 위한 MVD를 효과적으로 개발할 수 있기 때문입니다. 단, 우선 해당 앱과 긴밀하게 결합된 애플리케이션 서비스에 앱별 아키텍처를 채택해야 합니다.

MVP의 정의에서 알 수 있듯이, ‘제품’(이 경우에는 앱 배포)을 완전히 자동화할 필요는 없습니다. 위험성이 가장 높고 오류 허용 범위가 가장 좁은 리소스는 계속 수동으로 구성하고 검증해야 한다는 전제하에 운영하더라도 여전히 진전을 이룰 수 있습니다. 방화벽과 DNS 같은 핵심 서비스는 변경 빈도가 매우 낮으므로, 수동 방식이 배포 일정에 큰 영향을 미치지는 않을 것이라고 볼 수 있습니다. 앱별 애플리케이션 서비스의 대부분을 자동화하면 운영자와 엔지니어가 필요할 때 수동 변경 작업을 수행할 시간을 확보할 수 있으므로 더욱 그렇습니다.

핵심(공유) 서비스와 앱별 애플리케이션 서비스의 비율이 약 1대 3*이라고 가정하면, 일반적인 조직에서는 수동으로 관리해야 할 공유 리소스가 최소 4개이고 자동화해야 할 앱별 리소스가 12개라는 의미입니다.

광범위한 애플리케이션 서비스 목록을 살펴보면(현재 30개의 서로 다른 서비스를 추적하고 있습니다) 그중 일부는 애플리케이션을 제공하거나 보호하는 데 필수적이며 (DDoS, WAF, 확장성을 위한 부하 분산, 애플리케이션 액세스), 나머지는 말하자면 개선 기능에 가깝다는 것을 알 수 있습니다. 여기에는 성능을 높이는 가속 옵션이나 생산성을 향상하는 싱글 사인온(SSO) 같은 애플리케이션 서비스가 포함됩니다.

따라서 MVD 구현을 고려한다면 애자일 접근 방식을 채택하여 첫날부터 애플리케이션을 제공하고 보호하는 데 필수적인 애플리케이션 서비스에 집중할 수 있습니다. 그렇다고 개선 기능을 무시한다는 뜻은 아닙니다. 우선 핵심 서비스에 집중해 자동화하겠다는 의미입니다. 생산성이나 성능을 향상하는 서비스는 계속 수동으로 관리할 수 있지만, MVD에서는 수익에 영향을 미치는 서비스에 초점을 맞춰야 합니다.

애자일 네트워크를 위한 MVD 접근 방식

MVD를 정의하고 제공하려는 목표로 자동화에 접근하면 더 빠르게 움직일 수 있고(즉, 더 애자일해지고), 분기가 아닌 주 단위로 진행되는 각 스프린트마다 자동화를 반복적으로 개선하고 확장하여 견고하고 지속 가능한 제품(자동화된 배포)을 완성할 수 있습니다.

자동화에 MVD 기반 전략을 도입하려면 아키텍처뿐만 아니라 애플리케이션에 중점을 둔 접근 방식과 태도에도 전념해야 합니다. 이러한 접근 방식을 적용하려면 운영 및 비즈니스 관점 모두에서 애플리케이션과 그 요구 사항을 이해해야 하기 때문입니다. 한 애플리케이션의 MVD가 다른 애플리케이션의 MVD와 일치하지 않을 수도 있습니다. 고정된 수동 네트워크에서 민첩한 자동화 파이프라인으로 전환할 때 애플리케이션별 아키텍처가 매우 중요한 구성 요소인 이유 중 하나가 바로 이것입니다.

결국 NetOps에도 최소 실행 가능 배포(MVD)가 있다는 뜻입니다. 즉, 네트워크 자동화에 애자일 방식을 적용할 수 있으며, 애자일 네트워크 이니셔티브의 일환으로 애플리케이션별 아키텍처로 전환하면 그 속도와 안전성을 크게 높일 수 있습니다.

(거의) 모든 네트워크 작업을 자동화하세요.

*이는 전적으로 해당 목록과 제 경험, 그리고 제 (강한) 의견을 바탕으로 한 대략적인 추정치입니다. 실제 결과와 정의는 사람마다 다를 수 있습니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물