잠깐! 클라우드 네이티브 사업에 HCI 서버를 검토하시나요?

클라우드 네이티브의 핵심은 필요에 따라 자원을 유동적으로 조절할 수 있는 환경을 구축하는 것입니다.
그렇다면 클라우드 네이티브 환경에서 기존처럼 고가의 HCI서버가 필요한지 알아보겠습니다.

클라우드 네이티브 사업을 하면서 HCI 도입이 말이 되나요?

클라우드 네이티브 사업에 HCI서버가 필요할까?

클라우드 네이티브(Cloud Native) 기술의 도입은 많은 기업들에게 혁신적인 변화를 가져다주고 있습니다. 기존의 IT 인프라를 클라우드 환경으로 전환함으로써, 더 높은 유연성과 확장성을 확보할 수 있게 되었고, 이를 통해 비즈니스의 민첩성 또한 크게 향상되고 있습니다. 하지만 이러한 클라우드 네이티브 환경에서 과연 고가의 하이퍼 컨버지드 인프라(HCI)를 도입하는 것이 과연 합리적인 선택일까요?

HCI는 강력한 성능과 안정성을 제공할 수 있지만, 클라우드 네이티브의 특성상 필요 이상의 비용을 지출하게 됩니다. 클라우드 네이티브의 핵심은 필요에 따라 자원을 유동적으로 조절할 수 있는 환경을 구축하는 데 있으며, 이는 서버의 물리적 인프라에 구애받지 않고 클라우드에서 제공하는 다양한 서비스를 활용하는 것을 의미합니다.

이런 맥락에서, 클라우드 네이티브 환경에서 굳이 고가의 HCI를 도입할 필요성이 있는지에 대해 다시 한 번 생각해 볼 필요가 있습니다. 이번 글에서는 클라우드 네이티브 비즈니스를 운영하면서 고가의 HCI 서버를 도입하는 것이 왜 불필요한지에 대해 알아 보겠습니다.

Kubernetes를 HCI 위에 올릴 수 있을까?

기술적으로는 Kubernetes를 HCI 서버 위에 올리는 것이 가능하지만, 클라우드 특유의 장점을 충분히 발휘할 수 없기 때문에 클라우드 네이티브 환경에 적합하지 않습니다.

HCI 나 OpenStack(IaaS) 위에 PaaS를 구성하는 것은 “옥상옥(屋上屋) – 지붕 위에 또 하나의 집” 즉 배 위의 배를 올려 컨테이너 환경을 구성하는 것입니다.

즉 HCI 서버는 자체로 구조가 충분히 복잡하거나 완전한 상태인데, 거기에 같은 역할을 하는 Kuberentes 를 올려 다시 불필요한 추가 요소를 덧붙여서 복잡성을 더하는 상황을 말합니다.

특히 클라우드 네이티브는 Kubernetes(PaaS) 만으로 완벽히 구축이 가능함에도 불구하고 추가적으로 HCI 나 IaaS 로 도입하는 것은 비용 뿐만이 아니라 향후 운영에 있어서도 큰 부담이 되는 것은 이미 국내 사례에서 입증되었습니다.

관련한 내용의 주요 토픽은 다음과 같습니다.

  • 가상화기술(오픈스택 ,HCI)로 클라우드 네이티브를 구축하면 안되는 이유?
  • PaaS(Kubernetes)를 물리서버(Baremetal) 에서 구축하는 이유?
  • HCI 위에 Kubernetes를 구성하면 안되는 이유?
  • HCI(가상화) 나 오픈스택 기술이 클라우드 네이티브에 포함되지 않는 이유?

요약하자면, HCI 에서 제공하는 가상화 기술에서 PaaS를 구축하면 이중 가상화로 인한 성능 저하와 복잡성 증가 등의 문제로 인해 클라우드 네이티브의 장점을 충분히 활용할 수 없습니다.

배 위에 배 – HCI 나 OpenStack(IaaS) 위에 PaaS 구조

HCI 나 OpenStack(IaaS) 위에 PaaS 구조

PaaS 위에 컨테이너 관리 구조

PaaS 위에 컨테이너 관리 구조

가상화기술(오픈스택, HCI)로 클라우드 네이티브를 구축하면 안되는 이유는

성능저하 가상화 환경에서는 이미 하드웨어 리소스를 추상화하고 그 위에 여러 가상 머신(VM)을 운영합니다.
이 상태에서 클라우드 네이티브 애플리케이션을 또 다른 추상화 계층인 컨테이너로 실행하면, 이중 가상화가 발생하여 성능 저하를 초래할 수 있습니다.
CPU, 메모리, 네트워크 등의 자원 사용 효율이 떨어질 수 있습니다.
복잡성 증가 가상화와 클라우드 네이티브 둘 다 각각의 관리 및 운영 도구를 필요로 합니다. 두 가지를 함께 사용하면 관리해야 할 요소가 늘어나고, 운영 환경이 더욱 복잡해집니다.
이는 문제가 발생했을 때 원인 분석을 더 어렵게 만들고, 운영 비용도 증가시킬 수 있습니다.
비효율적인 자원활용 클라우드 네이티브 애플리케이션은 일반적으로 컨테이너를 통해 필요한 자원을 동적으로 할당하고 관리합니다.
하지만 가상화된 환경에서는 VM 단위로 자원이 고정되기 때문에, 자원의 유연한 배치와 관리를 방해할 수 있습니다. 이는 클라우드 네이티브의 효율성을 저해합니다.
추가 관리 오버헤드 가상화 환경에서 클라우드 네이티브 인프라를 운영하려면 가상 머신과 컨테이너 오케스트레이션 시스템(Kubernetes 등)을 모두 관리해야 합니다.
두 가지 시스템을 동시에 관리하는 것은 운영의 복잡성과 오버헤드를 증가시킬 수 있습니다.
기술적 제약 일부 가상화 플랫폼은 컨테이너 오케스트레이션 시스템과 완전히 호환되지 않거나, 네트워크 및 스토리지 계층에서 추가적인 제약을 가질 수 있습니다.
이는 클라우드 네이티브 애플리케이션의 성능이나 기능을 제한할 수 있습니다.

결국, 가상화 환경(오픈스택, HCI) 에서 클라우드 네이티브를 구축하면 이중 가상화로 인한 성능 저하와 복잡성 증가 등의 문제로 인해 클라우드 네이티브의 장점을 충분히 누리기 어려울 수 있습니다.

PaaS(Kubernetes)를 물리서버(Baremetal)에서 구축하는 이유는?

  • 서비스 무정지 업그레이드를 위해서는 PaaS 로만 구성 해야 함 (IaaS 위에 PaaS는 불가)
    • Kubernetes 프로젝트의 특성과 빠르게 변화하는 클라우드 네이티브 환경에 대응하기 4개월 주기로 잦은 버전 업그레이드가 요구됨
    • OS를 비롯한 클라우드 네이티브 관련 버전 업그레이드, 패치, 기타 시스템 작업을 위해 서비스를 정지하게 된다면 서비스 운영 문제 발생
    • OTA(Over the Air) 기술 지원을 통한 클라우드 네이티브 플랫폼에 대한 서비스 무정지 업그레이드 지원은 운영 상에 필수
  • IaaS 위에 PaaS 에서는 자동확장, 자동 장애복구 등 확장성 제약 발생 
    • 클라우드 네이티브 애플리케이션은 자동 확장과 축소가 용이한 환경에서 설계
    • 가상화나 IaaS에서는 자원을 동적으로 할당하거나 쉽게 확장하기 어렵기 때문에 클라우드 네이티브의 장점을 제대로 활용할 수 없음
  • 가상화 위에 컨네이터는불필요한 자원 낭비
      • 컨테이너를 활용해 자원을 세밀하게 관리하고, 필요한 만큼만 사용하도록 설계
      • 가상화 기반으로 PaaS로 구성하면 이런 효율적인 자원 관리가 어렵고, 결국에는 리소스 낭비

    결국, 클라우드 네이티브는 가상화나 IaaS(오픈스택) 에 구축하면, 그 특유의 장점을 충분히 발휘할 수 없기 때문에 클라우드 네이티브 환경에 적합하지 않습니다.

HCI 서버나 OpenStack 위에 Kubernetes를 구성하면 안 되는 이유는?

  • 서로 다른 두 개의 관리 도구로 인한 복잡성 증가
    • HCI 서버, OpenStack(IaaS) 과 Kubernetes(Paas) 모두 독립적인 클라우드 관리도구
    • HCI, OpenStack 은 가상화 기반 클라우드, Kubernetes 는 컨테이너 기반 클라우드 관리도구
    • HCI, OpenStack 자체가 복잡한 인프라 플랫폼인데, 그 위에 Kubernetes를 추가하면 관리와 운영이 더 복잡해짐
    • 두 개의 복잡한 시스템을 동시에 관리해야 하기 때문에 운영의 부담 증가
  • 성격이 다른 두 개의 기술인 가상화와 컨테이너 기술을 중첩하여 치명적인 성능 저하 
    • HCI, OpenStack 위에 Kubernetes를 배포하면 이중 가상화 또는 중복된 네트워크 오버레이가 발생하여 성능에 치명적인 문제가 발생
    • 성능에 대한 부분은 이미 Red Hat 이나 VMWARE 의 자료들을 통하여 물리서버 ( Baremetal) 에서 바로 PaaS 를 구성하는 것이 우수한것으로 입증
  • HCI (가상화+스토리지)나 Opentstack(가상화 기반 클라우드) 모두 가상화 기술의 쇠퇴
    • 클라우드 네이티브 기반으로 시스템을 구축하려고 한다면 가상화 기술을 사용하지 않거나 필요한 부분에서만 사용해야 함. 클라우드 네이티브 기술이 급격히 확산하면서 VMWARE 매각이나 레드햇 RHV ( 레드햇 가상화) 제품 판매 중지 그리고 오픈스택 기술은 쇠퇴
  • 어려운 Kuberntes 에 더 어려운 오픈스택을 더해 유지보수와 기술지원의 어려움 증가
    • Kubernetes와 OpenStack은 각각의 커뮤니티와 생태계가 있기 때문에, 두 플랫폼 간의 호환성과 통합 문제에 대한 지원을 받기가 어려움 문제가 발생했을 때, 어디서 문제가 발생했는지를 파악하고 해결하는 데 시간이 더 많이 소요 특히 오픈스택은 분산화된 컴포넌트를 기반으로 하고 있어 너무 복잡한 구조로 유지보수가 더욱 어려움

따라서 Kubernetes를 HCI 서버, OpenStack 위에 올리는 것이 가능하지만, 위와 같은 이유로 인해서 꼭 필요하지 않다면 피해야 합니다.

가상화나 오픈스택 기술이 클라우드 네이티브에 포함되지 않는 이유?

  • 가상화는 클라우드 네이티브와 다른 개념이기 때문에 그렇게 부르지 않습니다.
    • OpenStack은 클라우드 인프라스트럭처 플랫폼으로 주로 가상 머신, 네트워크, 스토리지 등의 자원을 관리하는 IaaS(Infrastructure as a Service) 솔루션으로 사용
    • OpenStack은 클라우드 인프라를 제공하는 플랫폼이지만, 클라우드 네이티브의 핵심 요소인 컨테이너 기반의 애플리케이션 오케스트레이션이나 마이크로서비스 아키텍처를 직접적으로 지원하는 않음
  • 가상화기술은 IaaS 이고 클라우드 네이티브는 PaaS 
    • 클라우드 네이티브는 클라우드 환경에서 최적화된 애플리케이션 아키텍처와 개발 방식을 의미
    • 주로 컨테이너, 마이크로서비스, DevOps, CI/CD 등이 포함
  • HCI 나 오픈스택의 가상화 기술은 기존 방식
    • 물리적인 하드웨어 리소스를 추상화하여 여러 가상 머신(VM)으로 분할하는 기술
    • 이 기술은 인프라의 유연성을 제공하지만, 여전히 애플리케이션은 VM 내부에서 전통적인 방식으로 운영
    • 기존 개발과 운영 방식의 변화 없이 전통적인 방식으로 구축할 수 있지만 클라우드 네이티브가 아니기 때문에 클라우드의 장점을 포기해야 함
  • 클라우드 네이티브 구현을 위한 PaaS
    • 클라우드 네이티브는 컨테이너를 활용하여 경량화된 환경에서 운영되며, 클라우드의 자원 효율성을 극대화
    • 이러한 애플리케이션은 자동 확장, 자가 복구, 무중단 배포와 같은 클라우드의 특성을 활용할 수 있게 설계

요약하자면, 가상화는 하드웨어를 추상화하는 기술이고, 클라우드 네이티브는 클라우드 환경에 특화된 애플리케이션 개발 및 운영 방식을 의미하기 때문에 둘을 구분해서 사용합니다.

마무리하며

결국, 클라우드 네이티브 환경에서는 고가의 HCI 서버보다는 Baremetal 서버가 더 적합하고 최적화된 선택입니다.
Baremetal 서버는 클라우드 네이티브의 유연성과 확장성을 충분히 지원하면서도 불필요한 비용을 절감할 수 있는 효율적인 솔루션입니다.

반면, HCI를 도입하는 것은 이러한 클라우드 네이티브의 이점을 제대로 이해하지 못한 선택일 수 있습니다.
클라우드 네이티브 환경에서 고가의 HCI를 도입하는 것은 자원을 낭비하는 비효율적인 결정이며, 이는 사실상 현명하지 못한 선택임을 분명히 할 필요가 있습니다.

궁극적으로, 클라우드 네이티브 비즈니스에서는 더 합리적이고 최적화된 인프라를 선택하는 것이 성공의 열쇠가 될 것입니다.

클라우드 네이티브 도입을 앞두고 더 궁금한 사항이 있다면 언제든 연락주세요!

📞 02-469-5426 | ✉️  sales@opennaru.com

Reference

오픈마루

04778 서울시 성동구 뚝섬로1길 31 906 호
(성수동1가, 서울숲M타워)
Tel : 02-469-5426 | Fax : 02-469-7247
Email : sales@openmaru.io

오픈마루 뉴스레터 19호 | 브로드컴의 VMware 인수, 그에 따른...오픈마루 뉴스레터 | 뉴스레터로 알아보는 클라우드 네이티브 주간 브리핑오픈마루 뉴스레터 | 뉴스레터로 알아보는 클라우드 네이티브 주간 브리핑오픈마루 뉴스레터 20호 | 잠깐! 클라우드 네이티브 사업에...