가상화에서 규모에 대해 배울 수 있는 것

가상화가 확산되기 시작하면서 성공을 측정하기 위한 다양한 지표가 제안되었습니다. 통합 비율, 관리자 대 가상 머신 비율, 프로비저닝 시간, 가상화된 서버 비율은 가상화 프로젝트의 성공을 측정하고 평가하는 데 가장 일반적으로 사용되는 요소입니다.

오늘날 우리는 DevOps가 급부상하는 모습을 지켜보고 있으며, 이와 유사한 지표가 성공을 측정하기 위해 제안되고 있습니다. 출시 시간, 복구 평균 시간, 변경 리드 타임, 배포 빈도는 DevOps의 CAMS(문화, 자동화, 측정, 공유) 정의에서 "M"에 초점을 맞출 때 일반적으로 논의되는 측정 항목입니다.

이것들은 좋고 필요한 것이지만 DevOps의 이점(사용 사례라고도 할 수 있음)이 있는데, 이는 거의 논의되지 않지만 똑같이 중요합니다. 바로 운영 규모입니다.

SDN이 운영화를 통해 "네트워크 내에서" 해결하려는 동일한 문제입니다. 기술을 통해 팀의 규모를 원하는 성장률에 맞추고 모바일 및 웹 애플리케이션의 빠른 성장 덕분에 비즈니스에서 경험하게 되는 것입니다. 이는 데이터 증가로 인해 IT 비용(운송, 처리, 저장)이 급증하는 반면 수익은 최소한으로만 증가하기 때문에 발생하는 전형적인 "30/30/3" 문제입니다. 이 문제를 해결하려면 우리가 통제할 수 있는 방정식의 한 부분, 즉 더 높은 IT 비용에 집중해야 합니다. 그러니 SDN이라고 부르고 싶다면 그렇게 하세요. 네트워크를 위한 DevOps라고 부르고 싶다면 그렇게 하세요. SDDC라고 부르고 싶다면, 왜 안 되겠어요. 클라우드라고 부르셔도 괜찮습니다. 이들 모두는 공통적인 전제를 가지고 있습니다. 성장을 위해서는 신속한 운영 확장이 중요하다는 것입니다.

이는 하드웨어와 소프트웨어 리소스에 대한 것만이 아닙니다. 이러한 리소스를 어떻게 프로비저닝하고 관리하는지에 대한 것도 있습니다. 애플리케이션을 배포하고 제공하는 데 필요한 리소스 세트(하드웨어 및 소프트웨어)를 관리하는 데 필요한 노력의 양을 줄여야 합니다.

여기서 "자동화"를 의미하는 "A"는 성장 방정식을 변경하고 더 큰 비즈니스 성장을 지원하기 위한 규모를 구축하는 데 필요한 IT 비용을 줄이는 데 효과적입니다. 

하지만 우리에게 필요한 것은 자동화에 대한 피상적인 관점만이 아닙니다. 자동화(스크립트와 오케스트레이션을 사용하여 프로비저닝과 관리, 서비스와 앱을 배포하는 데 필요한 운영 프로세스를 추진)가 중요하지만, "코드로서의 인프라"가 수행하는 중요한 역할을 잊지 말아야 합니다.

우리는 웨이백 머신을 통해 가상화가 컴퓨팅 리소스의 확장 관리를 성공적으로 수행한 과정을 살펴보면서 부분적으로 이를 수행할 수 있습니다(적지 않은 부분이 있지만) 그 인프라를 "코드"로 처리한 덕분입니다.

알아요, 알아요. 사실 그것은 스크립트나 구성 파일이나 "코드"처럼 보이는 어떤 것도 아니었기 때문에 사실상 코드가 아니었어요. 하지만 우리는 서버를 빠르게 프로비저닝하고 구성하기 위해 "골든 이미지"의 중앙 저장소를 사용했다는 의미에서 "코드"로 처리했습니다. 웹 서버, 앱 서버, 데이터 서버. 다양한 종류의 서버는 운영자가 확장할 수 있도록 하는 사전 정의된 "이미지"에 의해 이상화되었습니다.

그리고 제가 규모라고 말할 때는 규모를 뜻합니다. 숫자가 많이 엇갈리기는 하지만 2011년까지만 해도 관리자:가상 서버 비율이 1:350인 조직을 찾는 것은 드문 일이 아니었습니다. 어떤 사람들은 1:500에서 1:1000 이상을 주장했지만, 조직의 규모에 눌려 1:100 또는 1:150만 주장하는 사람들도 있었습니다. 여러 IT 벤치마크 보고서의 데이터를 분석한 2012년 보고서에서는 관리자:서버 비율이 1이라고 언급했습니다. 물리적 서버의 경우 50-75, 가상 서버의 경우 1:185-450입니다.

규모 면에서 보면 정말 놀랍죠. 이는 일반적으로 보완적인 높은 IT 비용 없이도 성장을 가능하게 합니다.

이제 모든 규모의 기업에서 엔지니어:장비 비율의 중간값이 약 1:36이라고 생각해 보세요. 그 자체로 흥미로운 것 같지 않나요? 사업이 성장함에 따라 비율은 변하지 않는 것으로 보입니다. 이는 나쁜 일이며 30/30/3 문제를 악화시킬 뿐입니다.

하지만 엔지니어당 장치 수를 두 배로 늘리는 등 어떤 식으로든 바꿀 수 있다면, 성장 비용을 절감 하고 전체 네트워크를 더 잘 확장할 수 있을 것입니다.  그러기 위해서는 가상화의 성공을 본받아야 합니다. 꼭 가상화를 사용하는 것이 아니라, 관리자와 서버의 놀라울 정도로 큰 비율을 지원할 수 있게 해주는 개념, 즉 코드로서의 인프라와 자동화를 사용하는 것입니다.

우리가 스위치와 로드 밸런서 및 조직에서 애플리케이션을 제공하고 보호하기 위해 사용하는 20개 이상의 다른 L4-7 앱 서비스에 대한 골든 이미지를 그냥 만들 수 없는 이유는 모든 구성이 고유하고 앱 중심적이기 때문입니다. 즉, 소프트웨어(가상)로 이동하여 해당 서비스 중 하나에 대한 골든 기본 이미지를 배포할 수는 있지만 구성을 담당할 사람이 여전히 필요합니다. 그리고 그것은 간단한 구성이 아닙니다.

Exchange에 대한 일부 앱 서비스를 구성하고 있나요? 가용성, 성능, 보안을 확보하려면 80개가 넘는 다양한 객체를 생성, 구성하고 올바르게 연결해야 합니다.

이것은 확실히 "네트워크에서" 시간(및 관련 비용)이 발생하는 곳입니다.

바로 여기서 우리는 확장을 해야 합니다. 우리는 인프라를 "코드"로 취급해야 합니다.

이것이 DevOps의 자동화 구성 요소인 "A"에 템플릿이 포함되는 이유입니다. 템플릿을 사용하면 net(및 sec) ops가 공통 구성을 중앙 저장소에서 관리할 수 있는 "코드"로 처리할 수 있습니다. 템플릿은 앱 서비스가 프로비저닝되고 구성되는 "골든 이미지"가 됩니다. 이러한 접근 방식은 가상 머신 프로비저닝과 유사한 자동화 및 오케스트레이션을 가능하게 하며 조직이 비즈니스 성장을 이루는 데 필요한 운영 확장성의 기반을 제공합니다.

DevOps, SDN, SDDC, 심지어 클라우드도 단순히 제품 출시 시간을 단축하거나 운영 비용을 절감하는 데만 국한되지 않습니다. 또한, 이는 사업 성장을 방해하는 것이 아니라 가능하게 하는 효율적인 규모를 만드는 데도 중요합니다. 데이터 센터 전체(컴퓨팅, 네트워크, 보안, 스토리지)에서 증가하는 리소스를 관리하기 위해 더 많은 운영자나 엔지니어를 추가하는 데 드는 비용은 그 규모에서 발생하는 성장을 삼켜버릴 것입니다. 자동화를 활용해 보다 효율적으로 확장하고 인프라를 코드로 처리하는 것은 기업이 원하는 성장을 지원하는 데 필요한 규모를 관리하는 한 가지 방법이 될 수 있습니다.