할 수 있다고 해서 해야 한다는 뜻은 아닙니다

이 개념은 가상화에 관한 논의에서 항상 등장합니다. 이것은 더 광범위하고 일반적인 개념이지만, 가상화는 많은 IT 조직이 직면한 '핫한 신기술'이며 현재 '할 수 있다고 해서 해야 한다는 뜻은 아니다'라는 문제가 가장 두드러지게 나타나는 분야인 것 같습니다. IT의 모든 것과 마찬가지로, 우리가 왜 특정 선택을 하는지 이해하기 위해 모든 기술적 결정을 비즈니스 맥락에 두는 것이 중요합니다. 인기 있는 배포 방법론이나 더 나쁘게는 미신에 기반하여 맹목적으로 결정을 내려서는 안 됩니다.

가상화 자체에 대해서는, 오늘날 x64 컴퓨팅 공간에서 작업하는 분들에게 기본 결정이 되어야 한다고 생각합니다. 특정 하드웨어 요구사항이나 지연 시간에 민감한 애플리케이션 등 명확하고 분명한 필요성이 존재하는 경우에만 가상화 없이 시스템을 배포해야 합니다. 특별한 요구사항이 없다면 가상화는 많은 벤더로부터 무료로 구현할 수 있으며, 현재는 물론 미래에도 환경을 안전하게 보호하는 많은 이점을 제공합니다.

그렇다고는 하지만, 오늘날 제가 자주 목격하는 것은 기업들이 가상화를 모범 사례로서가 아니라 모든 인식된 IT 문제에 대한 만병통치약으로 배포하는 것입니다. 가상화는 분명 그런 것이 아닙니다. 가상화는 IT 툴박스에 있어야 할 매우 중요한 도구이며, 우리가 자주 활용하게 될 도구이지만, 모든 문제를 해결하지는 않으며 우리가 보유한 다른 모든 도구와 마찬가지로 적절할 때만 사용해야 합니다.

가상화가 주제로 올라올 때 저는 몇 가지 반복적인 현상을 목격합니다. 오늘날 많은 기업들이 비즈니스 필요성을 파악해서가 아니라 현재 트렌드이기 때문에 가상화로 이동하고 있으며, 가상화를 구현하지 않으면 어떻게든 뒤처지거나 어떤 신화 같은 기능을 놓칠 것이라고 느낍니다. 이것은 가상화 도입을 촉진한다는 점에서 일반적으로 좋은 일이지만, 좋은 IT 및 비즈니스 의사결정 프로세스가 우회되고 있다는 점에서 나쁜 일입니다. 가상화 열풍 속에서 IT 부서는 가상화 자체를 구현해야 할 뿐만 아니라 해당 비즈니스에 적합하지 않을 수 있는 방식으로 구현해야 한다고 느끼는 경우가 많습니다.

가상화와 자주 연결되어 있고, 특정 비즈니스 환경에서 의미 있는지 여부에 관계없이 가상화 요구사항으로 받아들여지는 네 가지 사항이 있습니다. 바로 서버 통합, 블레이드 서버, SAN 스토리지, 고가용성 또는 라이브 페일오버입니다.

통합은 가상화의 이점으로 너무 자주 칭송되어 대부분의 IT 부서가 가상화를 구현하는 다른 중요한 이유가 있다는 것을 잊는다고 생각합니다. 분명히 통합은 거의 모든 배포(물론 상황에 따라 다를 수 있음)에 큰 이점이며, 기존 리소스를 더 잘 활용함으로써 거의 항상 달성 가능합니다. 단일 물리 서버 이상을 운영하면서 제한적인 통합을 통해 어느 정도의 비용을 절감할 수 없는 기업은 매우 드물며, 대규모 조직에서는 데이터센터 공간이 크게 줄어드는 경우도 드물지 않습니다.

그러나 극단적인 경우, 통합이 불가능한 것으로 판명된다고 해서 가상화 프로젝트를 포기할 필요는 없습니다. 이런 경우는 활용률이 높은 시스템을 가진 기업이나 선제적 통합 투자를 위한 예산이 부족한 기업에 해당합니다. 하지만 이런 사업장들도 1대1 기준으로 '현재 위치'에서 시스템을 가상화하여 현재 가상화의 다른 이점을 얻을 수 있으며, 하드웨어를 교체해야 할 내일이나 더 크고 강력한 서버가 더 비용 효율적이 될 미래에 통합을 검토할 수 있습니다. 가장 널리 알려진 이점이 현재 환경에서 적용되지 않는다고 해서 가상화를 배제하지 않는 것이 중요합니다.

블레이드 서버는 종종 가상화 환경을 위한 최선의 선택으로 여겨집니다. 블레이드는 더 전통적인 컴퓨팅 워크로드보다 표준 가상화 환경에서 더 잘 작동할 수 있지만, 이것은 매우 논쟁의 여지가 있으며 반드시 적용 가능한 데이터가 아닙니다. 블레이드에게 좋은 시나리오라고 해서 비즈니스에도 좋은 시나리오가 되는 것은 아닙니다. 이런 방식으로 사용할 때 블레이드가 일반적인 것보다 더 잘 수행한다고 해서 기존 서버보다 더 잘 수행한다는 의미는 아닙니다. 단지 잠재적으로 격차를 좁혔을 뿐입니다.

블레이드는 가상화 시에도 그렇지 않을 때와 동일한 엄격한 기준으로 평가되어야 하며, 매우 자주 더 유연한 대안보다 필요한 장기적 비즈니스 가치를 제공하지 못하는 것으로 판명될 것입니다. 블레이드는 가상화에 필수적이라는 것과는 거리가 멀며, 제 생각에는 종종 매우 좋지 않은 선택입니다.

가장 일반적인 오해 중 하나는 가상화로 이동하면 SAN과 같은 공유 스토리지로도 이동해야 한다는 것입니다. 이 사고방식은 SAN이 필요하지 않더라도 SAN의 혜택을 크게 받는 가상화의 다른 이점을 달성하려는 욕구에서 비롯된 명백한 반응입니다. 시스템 간에 로드 밸런싱 또는 페일오버를 수행하는 능력은 공유 스토리지 백엔드가 있으면 크게 용이해집니다. 이것이 절대적인 요구사항이라는 것은 미신이지만, 복제된 로컬 스토리지는 자체적인 복잡성과 제한이 있습니다.

하지만 공유 스토리지는 가상화 자체의 필수 요소와는 거리가 멀며, 다른 모든 것과 마찬가지로 독자적으로 평가되어야 합니다. 가상화가 환경에 적합하지만 SAN이 필요한 기능이 없다면 공유 스토리지 없이 가상화하십시오. 로컬 스토리지 기반 가상화가 이상적인 배포 시나리오가 되는 경우도 많습니다. 이 접근 방식에 대해 진지하게 고려하기 전에 무시할 필요가 없습니다.

가상화의 마지막 주요 필수 기능으로 가정되는 것은 운영 체제에 대한 시스템 레벨 고가용성 또는 즉각적인 페일오버입니다. 의심할 여지 없이 시스템 레이어에서의 고가용성은 가상화가 우리에게 가져다주는 놀라운 이점입니다. 하지만 가상화를 구현하기 전에 이 레벨의 고가용성을 필요로 하는 기업은 거의 없었으며, 가상화로 이를 구현하는 데 필요한 인프라 및 소프트웨어의 비용은 정당화하기에는 너무 비쌀 때가 많습니다.

고가용성 시스템은 복잡하고 종종 과도합니다. 가장 중요한 시스템에서도 투명한 페일오버가 필요한 비즈니스 시스템은 매우 드물며, 그런 요구사항이 있는 기업은 이미 페일오버 프로세스를 갖추고 있을 것입니다. 가상화를 검토할 때 고가용성 쪽으로 이동하는 기업들을 자주 보는데, 벤더가 원래 요구사항을 크게 과장 판매할 기회를 포착했기 때문입니다. 고가용성의 비용은 관련 다운타임 감소로 인한 잠재적 수익 손실에 의해 거의 정당화되지 않습니다. 고가용성이 아닌 가상화에서 하드웨어 장치 장애로 인한 다운타임은 백업이 잘 처리된 경우 몇 분 만에 측정될 수 있습니다. 이것은 고가용성이 연간 몇 분의 계획되지 않은 다운타임을 잠재적으로 제거하는 것에서 시스템 복잡성 증가로 인해 추가된 모든 위험을 빼고 그 비용을 정당화해야 한다는 것을 의미합니다. 가장 큰 조직에서도 대규모로 이것이 거의 정당화되지 않으며, 중간 규모의 기업에서는 전혀 드문 일입니다. 하지만 오늘날 우리는 마케팅 문헌이 그 개념을 홍보했다는 이유만으로 최소한의 재정적 손실로 며칠 동안 중단을 겪어도 상관없는 시스템에 극도로 높은 비용으로 고가용성 시스템을 구현하는 소규모 기업들을 많이 발견합니다.

다른 모든 것과 마찬가지로, 가상화와 그것이 제공하는 모든 관련 가능성은 이를 고려하는 조직의 맥락에서 개별적으로 평가되어야 합니다. 개별 기능이 비즈니스에 맞지 않는다면 그 기능을 구매하거나 구현해야 한다고 가정하지 마십시오. 많은 조직이 가상화를 구현하지만 이런 '가정된' 기능 중 일부만 사용하거나 전혀 사용하지 않습니다. 가상화를 블랙박스로 보지 말고, 각 부분을 살펴보고 다른 기술 프로젝트를 고려하는 것처럼 고려하십시오.

종종 눈덩이 효과가 발생합니다. 적절한 비즈니스 평가 없이 하나의 기능, 아마도 고가용성이 필요한 것으로 가정됩니다. 그런 다음 고가용성에 필요하다고 흔히 가정되는 공유 스토리지 시스템이 또 다른 가정 비용으로 추가됩니다. 고가용성 기능을 구매하지 않더라도 SAN을 사용하기로 한 결정은 이미 내려져 있을 수 있으며, 계획이 변경된 후에도 재검토되지 못할 수 있습니다. 제 경험상, 이런 성격의 프로젝트에서 총 지출의 50% 이상이 구매자가 구매 이유조차 설명할 수 없는 제품에 사용되는 경우가 매우 흔합니다.

이 개념은 가상화에서 그치지 않습니다. 여러분이 하는 모든 것에 이를 확대 적용하십시오. IT를 비즈니스 관점에서 유지하고, 하나의 기술을 선택하면 그것과 인기 있게 연결된 다른 기술도 자동으로 채택해야 한다고 가정하지 마십시오.