데이터센터의 용량 산정(예측)과 용량 대응

기업의 데이터센터는 애플리케이션을 유지시켜 주기위해 존재하며, 오직 애플리케이션을 위해서만 존재합니다.

 

이를 위해 데이터센터 내부 인프라는,

애플리케이션이 요구하는 조건(기능/성능)을 지원할 수 있는 최적화된 아키텍처과 사이즈로 구성되어 있습니다.

하지만, 대부분의 기업 IT 운영환경에서 개발과 인프라 운영이 완벽히 분리되어 있기 때문에,

애플리케이션에서 요구되는 스펙을 받아서 딱 최소한으로만 구성하고 있는게 현실입니다.

즉, 여기서의 최적화라고 하는 것은 애플리케이션이 요구하는 성능을 제공할 수 있는 제일 저렴한 비용의 인프라입니다.

 

물론 데이터센터에도 기대하는 애플리케이션의 성능보다 훨씬 뛰어난, 더 비싸고 좋은 IT 인프라를 도입할 수 있습니다.

다만 기업이 추구하는 이윤 추구 활동에서 불필요한 지출이 많아진다면, 서비스품질에 영향을 미칠수 밖에 없습니다.

즉 무작정 높은 성능과 고비용의 장비보다, 정말 필요한 적절한 성능의 장비로 협의점이 찾아지는 것입니다.

 

하지만, 데이터센터에서 살고 있는 애플리케이션들은 언제나 동일하지 않습니다.

숨 바쁘게 변화하는 기업의 비지니스 환경 속에서 살아남기 위해 항상 변화합니다.

서비스의 비지니스적 요구사항에 따라 늘어나기도 하고, 줄어들기도 하고, 새로 태어나기도 해야합니다.

비지니스에 대한 신속한 변화만이 애플리케이션의 가치를 유지시켜주기 때문입니다.

그래서 일부 전문가들은 데이터센터는 살아있는 유기 생명체라고 표현하기도 합니다.

 

다시 말해, 데이터센터의 본질이 애플리케이션에 있는 만큼,

데이터센터의 IT 인프라는 애플리케이션이 요구하는 사항에 즉각 대응해야 합니다.

하지만, 데이터센터의 인프라들은 축소는 일부 가능하겠지만, 변화나 확장이 쉽지 않습니다.

애플리케이션이 변화한다고, 함께 변화할 수 없습니다.

인프라는 하드웨어입니다.

 

데이터센터의 인프라들은 한번 구축되면 잘 변하지 않습니다.

아키텍처는 물론이고, 물리적 자원의 재배치도 쉽지 않습니다.

애플리케이션과 인프라의 담당자도 다르고, 서로의 영역이 완전히 분리되어 있으며,

다양한 업무 이해관계자들이 복잡하게 얽혀 있기 때문에, 누군가 재배치를 원한다 하더라도 쉽게 반영되기 어렵습니다.

변하기 어려운 인프라와 쉽게 변하는 애플리케이션, 여기서 애플리케이션과 인프라 사이에 괴리감이 발생합니다.

 

일반적으로 무엇이 되었던 인프라를 도입한다 치면, 거쳐야 하는 과정이 많이 있습니다.

애플리케이션에서 필요하다고 즉시 도입이 가능하지 않습니다.

필요한 기능을 검증하고, 필요한 용량을 산정하고, 용량 기반의 예산 계획을 수립하고,

확인된 기능, 용량, 비용을 기반으로 제안이 진행됩니다.

제안이 진행되고 도입이 결정된다 하더라도 바로 사용이 가능한 인프라가 배송되는 것이 아닙니다.

대부분의 인프라가 해외에서 주문생산되기 때문인데요, 최소 발주내고 1달~2달정도는 소요됩니다.

CPU나 GPU, 메모리등 당시 상황에 따라 수급이 어려운 경우 그 일정은 더욱 길어집니다.

일반적인 하드웨어 벤더의 경우 국내 재고가 없는 이상 빨라도 4주 이상은 걸리는게 현실입니다.

최근에는 GPU와 CPU등에 공급이 원할하지 못해 2달 이상 지연되는 경우도 종종 있습니다.

그 사이 애플리케이션은 필요한 인프라를 제때 공급받지 못해 비지니스에 악영향을 미치고 있습니다.

 

데이터센터의 인프라들은 주로 기존의 IT 자산이 사용기한이 지났다던가, 새로운 서비스가 도입된다던가,

무엇인가 IT 인프라 구매를 위한 이유가 발생할때, 주로 패키지로 한번에 구매하게 됩니다.

사용 기한이 지났을 경우에는 기존 장비를 현재 사용량에 맞추어 다시 필요 인프라를 산정하고,

산정된 인프라를 최신의 기술과 최신의 사양으로 교체하는 주로 인프라 기반의 Scale-up 방식으로 이루어집니다.

신규 서비스를 위한 인프라 구매시에는, 예측되는 사용량에 맞추어 필요 인프라를 산정하고,

역시 산정된 인프라를 최신의 기술과 최신의 사양 기반으로 가격 경쟁력 있는 인프라로 구축합니다.

 

실제 확장이나 변경이 결정되고 나면, 얼마나 필요한지 용량을 설계/예측하고 실제 구매를 위한 예산을 산정합니다.

여기서의 용량이라함은 컴퓨팅, 스토리지, 네트워크 등 다양한 하드웨어 기반의 구성요소에 대한 스펙을 뜻합니다.

앞서 얘기한대로, 도입 후 쉽게 변경이나 추가되기 어려운 부분이기 때문에 초기부터 정확한 산정 활동이 필요합니다.

이를 대비해, 추후 확장될 용량까지도 아직 사용하진 않지만, 미리 구입하는 경우가 꽤 많습니다.

하지만, 이 역시 비용입니다.

 

다시 말해, 프로젝트 설계 단계에서 서비스의 성능 상태를 예측하여, 인프라 자원의 수량 및 스펙을 산정하고 있습니다.

즉, 데이터센터 인프라 도입에 있어 용량 산정은 정확한 데이터를 기반으로 할 수 없으며,

그동안의 경험과 하드웨어 성능의 향상을 수치적으로 두고, 기업별 특성에 맞추어 계산되는 예측 행위입니다.

현실적으로 누구도 실제 서비스 도입 이후의 애플리케이션의 필요 용량/성능을 정확히 예측할 수는 없습니다.

기존의 사용량과 기존의 데이터/레퍼런스를 기반으로 어렴풋이 추정할 뿐이이지요.

물론 대부분은 경우 산정된 물량의 인프라 안에서 해결됩니다.

그 이유는 설계 당시부터 최대한 보수적인 용량 선정 방식을 적용했기 때문입니다.

 

용량 산정 단계를 통해 정확한 예측 기반의 설계를 하고,

대부분의 인프라를 가상화를 통해 설계할 경우 일부 가상머신을 늘릴 수는 있겠지만,

근본적인 하드웨어 자원의 성능은 제약은 여전히 남아 있습니다.

그래서 대부분의 인프라 프로젝트는 설계 단계에 용량 산정을 중요시하지만, 정확한 예측은 어렵습니다.

데이터센터 환경에서 인프라 도입시에 용량 산정은 빠질 수 없는 단계입니다.

하지만, 애플리케이션의 현실과 맞지 않는 용량 산정은 의미가 없습니다.

 

이에 반해, 클라우드는 필요한만큼 사용하고, 사용한만큼 지불하는 체계입니다.

일단 정확한 사용량을 기반으로 합리적인 비용을 지불합니다.

사전에 대략적인 규모는 설계하겠지만, 정확한 규모가 설계될 필요는 없습니다.

사용하면서 모자르면 즉시 확장하면 되고, 남으면 줄이면 됩니다.

줄였다고 남는 자원을 그대로 비용지불할 필요도 없고, 늘렸다고 시간을 기다릴 필요도 없습니다.

애플리케이션 변화 요구에 즉시 대응합니다.

 

기존 데이터센터 환경이 '용량 산정' 기반이라면, 클라우드는 '용량 대응'입니다.

언제든지 변화하는 애플리케이션 요구사항에 맞추어 용량을 변화합니다.

커질수도 작아질수도, 생길수도 없어질수도 있습니다. 

 

이러한 용량 대응은 퍼블릭클라우드에만 국한되는 것이 아닙니다.

기업의 데이터센터에 있는 프라이빗클라우드에서도 용량 대응이 가능해야 합니다.

서비스 별로 테넌트를 만들어 분리하고, 모든 서비스를 가상화기반으로 구축하고,

필요할때 언제나 확장할 수 있는 인프라 구조를 만들어야 합니다.

물론 물리적인 인프라를 기반으로 하기 때문에, 언제나 무한의 확장을 할 수는 없습니다.

다만, 기존의 Scale-up 방식 대신에, Scale-out 방식의 인프라를 고민하고 도입해야 합니다.

가상화 기반의 SDDC를 구축하고, 애플리케이션 중심의 인프라가 구성되야 합니다.

 

물론 이 역시 초기 용량 산정이 잘못될 수도 있습니다. 그럴땐 즉시 추가적인 인프라를 붙혀

성능을 늘리고, 서비스의 품질을 높힐 수 있는 즉시 대응 가능한 인프라가 되어야 합니다.

기업 데이터센터 환경에서는 네트워크의 Leaf-Spine 아키텍처가, 컴퓨팅/스토리지에는 HCI가

용량 대응을 위한 Scale-out의 대표적인 인프라 구조라고 할 수 있겠습니다.

 

결론적으로, 이제 기업의 애플리케이션을 위한 데이터센터 인프라 환경은

기존의 용량 산정을 통해 예측 기반의 IT 환경을 구매하는 것이 아니라,

늘어나는 용량에 즉시 대응함으로써, 애플리케이션의 연속성과 성능을 보장시켜주어야 한다는 것입니다.

 

이제, IT 인프라는 용량 산정이 아니라 용량 대응의 시대입니다.