Palantir에서 근무하는 동안 저는 클라우드 환경에서 소프트웨어를 배포하는 데 상당한 시간을 보냈고, 온프레미스(onprem) 환경에서 소프트웨어를 배포하는 데도 상당한 시간을 보냈습니다(그 일을 하는 팀을 시작한 것도 포함). 클라우드 배포에 대한 일반적인 선호도에도 불구하고 온프레미스 배포에는 여전히 장점이 있다는 것을 알게 되었습니다.
온프레미스에서 클라우드 컴퓨팅으로의 전환
최근 몇 년 동안 IT 환경은 Infrastructure-as-a-Service(IaaS) 및 Platform-as-a-Service(PaaS) 제공의 유연성에 힘입어 클라우드 컴퓨팅을 점점 더 선호해 왔습니다. 글로벌 클라우드 컴퓨팅 시장은 2010년 246억 3,000만 달러에서 2020년 1,564억 달러로 성장했으며, 이러한 추세는 계속되고 있으며 2028년까지 1조 달러를 넘어설 것으로 예상됩니다. 이러한 급격한 상승은 전 세계의 새로운 컴퓨팅 수요와 온프레미스 워크플로의 클라우드로의 마이그레이션에 의해 촉진되었습니다.
이러한 변화에는 타당한 이유가 있습니다. 클라우드는 리소스의 신속한 프로비저닝, 지리적 중복성, 자본 지출(CapEx)에서 운영 지출(OpEx)로의 전환을 가능하게 합니다. 그러나 저는 특히 결정적 지연, 하드웨어 수준 제어, 엄격한 보안 조치와 같은 특정 기술 요구 사항이 가장 중요한 특정 시나리오가 있다고 생각합니다.
클라우드 설정과 온프레미스 설정을 비교하는 본론에 들어가기에 앞서, 각각의 배포가 일반적으로 어떻게 설정되는지 살펴보는 시간을 가져보겠습니다.
Canonical 온프레미스 설정
일반적인 온프레미스 설정에는 기업이 기술 스택의 모든 계층을 관리하는 완전히 제어되는 환경이 포함됩니다. 여기에는 다음이 포함됩니다.
물리적 계층 : 서버, 스토리지 어레이(SAN/NAS), 네트워킹 장비(라우터, 스위치, 방화벽)와 같은 하드웨어. 서버를 운영할 데이터 센터도 필요합니다.
가상화 계층 : 종종 VMware vSphere, Microsoft Hyper-V와 같은 하이퍼바이저나 KVM과 같은 오픈 소스 대안을 사용하여 구현되어 가상화된 리소스와 격리를 제공합니다.
저장 및 컴퓨팅 : 직접 관리되며, 종종 사용자 정의 구성(예: RAID 레벨, 캐싱 메커니즘)을 통해 특정 작업 부하에 맞게 최적화됩니다.
네트워킹 : 네트워킹 프로토콜, 라우팅, 보안 정책에 대한 완벽한 제어를 통해 미세 조정된 QoS(서비스 품질)를 구현하고 지연 시간을 최소화합니다.
Canonical Cloud 설정
일반적인 클라우드 설정에서 인프라는 클라우드 제공자에 의해 추상화되고 관리되며 다음을 제공합니다.
가상화된 인프라 : 컴퓨팅 인스턴스, 가상 네트워크 및 스토리지는 API를 통해 프로비저닝됩니다. Kubernetes 및 서버리스 아키텍처와 같은 클라우드 네이티브 기술은 오케스트레이션 및 확장을 위해 활용됩니다.
관리형 서비스 : 데이터베이스(예: Amazon RDS, Google Cloud SQL), 데이터 레이크, AI/ML 서비스 및 기타 고급 분석 도구가 관리형 서비스로 제공되므로 운영 오버헤드가 줄어듭니다.
다중 테넌트 아키텍처 : 리소스는 종종 여러 테넌트 간에 공유되며, 가상화와 컨테이너화를 통해 격리가 제공됩니다.
비교
규모와 속도 : 클라우드는 자동 확장 그룹 및 서버리스 기능과 같은 수평적 확장 메커니즘을 통해 탄력적 확장에 뛰어납니다. 온프레미스 인프라는 신중한 용량 계획과 물리적 하드웨어에 대한 투자가 필요하며, 종종 수직적 확장이 필요합니다. 새로운 컴퓨팅을 위해 9개월을 기다릴 수 없는 스타트업이라면 클라우드가 최선의 선택입니다. 그러나 내년의 컴퓨팅 부하를 예측할 수 있는 대기업이라면 온프레미스가 실행 가능한 옵션이 될 수 있습니다.
대기 시간: 온프레미스 설정은 서버의 근접성과 네트워크 경로에 대한 직접 제어로 인해 결정적 저지연을 달성할 수 있습니다. 지연에 민감한 애플리케이션(예: 고빈도 거래, 실시간 분석)의 경우 이는 중요할 수 있습니다. 클라우드 환경은 AWS Direct Connect 또는 Google Cloud Interconnect와 같은 기능을 통해 저지연에 최적화되었지만 네트워크 혼잡(잡음이 많은 이웃 문제) 및 가상화 오버헤드와 같은 요인으로 인해 가변적인 지연이 발생할 수 있습니다. 따라서 예측 가능한 지연 시간과 저지연 워크플로가 비즈니스에 중요한 경우 온프레미스 설정이 나쁘지 않을 수 있습니다!
비용: 클라우드 가격 책정 모델(종량제, 예약 인스턴스)은 유연성을 제공하지만, 특히 높은 데이터 유출 비용과 함께 지속적이고 대량의 워크로드에는 비용이 많이 들 수 있습니다. 온프레미스 솔루션은 하드웨어 인수에 상당한 초기 CapEx가 필요하지만, 특히 예측 가능하고 활용도가 높은 워크로드의 경우 시간이 지남에 따라 총 소유 비용(TCO) 을 낮출 수 있습니다. 클라우드 모델은 비쌀 수 있으며, Dropbox는 2016년에 대부분의 스토리지를 AWS에서 자체 데이터 센터로 옮겼을 때 1,680만 달러를 절약했습니다. 온프레미스가 어떻게 비용을 절감 할 수 있는지 자세히 설명하는 기사가 있습니다.
전문성: 온프레미스 환경은 하드웨어 유지 관리, 네트워크 엔지니어링 및 시스템 관리에 대한 심층적인 전문성을 요구합니다. 반대로 클라우드 환경은 인프라 관리의 대부분을 공급자에게 위임하여 팀이 애플리케이션 개발 및 배포에 집중할 수 있도록 하며, 종종 DevOps 관행과 Terraform 또는 CloudFormation과 같은 Infrastructure as Code(IaC) 도구를 사용합니다. SRE와 시스템 관리자는 요즘 보기 드문 종류이며, 온프레미스 설정을 유지 관리하고 운영하기 위해 이들로 구성된 팀을 고용하려면 상당한 양의 컴퓨팅이 필요할 것입니다(그리고 지속 가능한 온콜 로테이션이 필요하다는 것을 잊지 마세요!)
보안: 온프레미스 설정은 물리적 보안 조치에서 세분화된 네트워크 세분화 및 암호화 프로토콜에 이르기까지 보안 구성에 대한 완벽한 제어를 제공합니다. 이러한 제어는 특정 규정 준수 표준(예: PCI-DSS, HIPAA)을 충족하는 데 필수적입니다. 반면 클라우드 환경은 공급자의 보안 조치에 대한 신뢰가 필요하지만 Virtual Private Clouds(VPC), 전용 하드웨어(예: AWS Outposts) 및 고객 관리 암호화 키와 같은 기능은 일부 우려 사항을 완화할 수 있습니다. 이러한 보안 제어 및 프로토콜이 필요한 워크플로를 실행하는 경우 온프레미스를 배포하는 것이 유일한 방법일 수 있습니다. 그렇지 않은 경우 보안을 강화하는 것이 고려 사항일 수 있습니다! 그러나 현재 클라우드 공급자가 적응하고 이러한 표준 중 일부를 충족하는 제품을 제공하고 있다고 생각합니다(예: AWS GovCloud ).
결론
클라우드 컴퓨팅은 타의 추종을 불허하는 유연성, 확장성 및 고급 관리 서비스에 대한 액세스를 제공하지만, 온프레미스 솔루션은 낮은 대기 시간, 높은 보안 및 하드웨어 및 소프트웨어 구성에 대한 완전한 제어가 필요한 시나리오에서 여전히 필수적입니다. IT 환경이 진화함에 따라 클라우드와 온프레미스 간의 결정은 특정 기술 및 비즈니스 요구 사항에 따라 이루어져야 하며, 선택한 인프라가 조직의 전략적 목표와 일치해야 하며, 위의 요소와 비교를 사용하여 어떤 설정이 더 나은지 더 정보에 입각하여 선택할 수 있습니다! 행운을 빕니다!