Cloud의 시작-PC 서버에서 Data Center까지(2)

앞의 글에서 PC서버에서 Data Center로 가는 과정에서 벌어졌던 일을 설명 드렸습니다.

Cloud가 나오기 전에도 On-Prem의 단점을 해결하기 위한 노력이 없었던 것은 아니었습니다. 자원 낭비를 막기 위해서 가상화를 하기도 하고, 상면을 절약하고 관리를 효율화 하기 위해서 블레이드 서버를 도입하기도 했습니다.
가상화는 메인 프레임에서도 사용했던 자원을 나눠서 쓰는 방식입니다. 물리적으로는 하나의 서버이지만, 이것을 나눠서 마치 여러 대의 서버가 있는 것처럼 가상의 환경을 만들어서 사용하기 때문에 가상화라는 표현을 사용합니다. 메인 프레임이 사용하는 CPU나 메모리, 스토리지 등의 용량이 클 경우, 자원들을 나누어서 마치 별개의 시스템을 사용하듯이 여러 개의 각기 다른 시스템을 구축해서 사용하기도 했습니다. 실제로 몇 개의 회사들이 하나의 시스템을 나눠서 사용하기도 했는데 자원의 활용도를 높인다는 차원에서는 매우 효과적이었지만, 같은 서버를 사용하기 때문에 장애가 생길 경우 해당 서버를 사용하는 회사들이 모두 영향을 받는 문제가 있었습니다.

시장에서 많이 사용되던 메인 프레임이 Unix로, Unix가 Linux나 Windows 서버로 계속해서 전환되어 왔는데 Linux나 Widnows가 운영되는 H/W를 보통 x86서버라고 합니다. x86서버라고 부르는 이유는 서버에 장착되는 CPU가 예전에 인텔에서 개발한 CPU 시리즈인 386, 486, 586(펜티엄) 이기 때문에 그냥 앞자리만 빼고 x86서버라고 부르는 것입니다.

AWS의 Outpost용 Rack 및 서버

지금은 리눅스를 더 많이 사용하지만 과거 일반 기업에서는 리눅스 대신에 Windows를 많이 사용했습니다. x86서버에 MS Windows Server를 설치하고 그 위에 Application을 올려서 운영합니다. Application의 규모가 클 경우, 웹서버, WAS서버, DB서버 등 다양한 서버들을 운영하게 되고, Application의 규모가 작을 경우는 하나의 x86서버에 여러 개의 Application들을 운영하기도 합니다. 그러다 보니 장애가 생기거나, 특정 application에 부하가 클 경우 다른 application에 영향을 미쳐서 시스템 접속이나 품질 등이 문제가 되는 경우도 많습니다. 이러한 장애를 막기 위해서 Application마다 별도의 H/W를 구성하는 경우도 있지만 이럴 경우 비용이 문제가 되며, 자원이 남아도는 단점이 있습니다.

이러한 자원 부족을 해결하고 Application의 안정성을 높이고자 여러 대의 x86서버를 묶어서 가상화 한 후에 여러 개의 Application을 운영합니다. 그렇게 하면 특정 Application에 부하가 몰려도 여러 대의 서버로 부하를 분산 시킬 수도 있고, 특정 서버에 장애가 있더라도 다른 서버에서 받아줄 수 있기 때문에 여러모로 장점이 많았습니다. 문제가 생긴 서버는 유사한 서버로 교체해도 되니까 여러모로 장점이 많았습니다. 당시에도 대형 포털 등은 그런 방식으로 H/W를 구성해 놓고 부하나 장애를 해결하고 있었습니다.

H/W를 여러 대 엮어서 물리적으로 구성을 해 놓은 뒤 S/W로 가상화 환경을 관리해 줘야 하는데, 그러한 역할을 해주는 솔루션들 중에는 'VMware', 'MS HyperV' 등이 있었습니다. Application의 부하가 많은 곳으로 자동으로 자원을 할당해주는 동적인 방식도 있고, 수동으로 또는 스케줄에 따라서 자원을 할당하는 방식도 있습니다. 예를 들어 월말에 많이 사용하는 Application, 월 중에 많이 사용 하는 Application, 업무 시간 중, 또는 야간에 사용이 많은 Application 등은 해당 시간대에 자원을 많이 받을 수 있게 설정할 수 있습니다.

Application 운영에 필요한 서버가 8대라고 가정하면 2대를 여분으로 설치해서 8대 중에 장애가 발생하면 여분의 서버 2대가 받아주도록 설계를 해놓기도 합니다. 만일 초기 산정한 용량인 8대 보다 더 많은 자원이 필요할 경우 동일 서버를 추가로 구매해서 설치하면 되니까 확장이 용이하기도 합니다. 이렇게 옆으로 H/W를 추가로 확장하는 방식을 'Scale out' 이라고 합니다. 반대로 메인프레임을 운영하다가 자원이 부족해지면 CPU나 메모리를 증설하게 되는데 이러한 방식은 'Scale up'이라고 합니다. Scale out은 논리적으로는 무한대로 확장이 가능합니다만, Scale up은 해당 서버의 증설 가능한 공간(소켓 수 등)이 정해져 있기 때문에 확장에 제약이 있습니다. 현재 대부분의 클라우드 서비스는 x86 서버 기반으로 구성되어 있고 대부분 Linux나 Windows O/S를 사용하며, Scale out 방식으로 리소스를 확장합니다.

메인 프레임상의 가상화와 x86기반의 가상화를 비교해 보면, 메인 프레임은 주로 동일한 H/W의 자원을 나눠서 여러 환경, 여러 회사가 나누어 사용하는 경우가 많았고, x86은 동일한 H/W를 나누어 사용하는 경우도 있지만, 여러 대의 H/W 상에서 여러 개의 Application이 구동 되는 경우가 많습니다. 가격은 메인 프레임이 훨씬 비싸고, 향후 확장시에 Scale up 방식의 제약이 존재한다는 점이 큰 특징입니다.

아마존이 쇼핑몰을 운영하면서 자체 인프라를 x86으로 구성하고 가상화하면서 Scale out으로 확장하여 사용하다보니, 다른 기업에도 팔면 좋겠다는 생각을 하게 됩니다. 그래서 Amazon Web Service라는 회사를 설립하여 쇼핑몰과 별개의 사업을 하게 된 것이 바로 Public Cloud의 시작입니다. 구글도 검색, G메일 등을 비롯한 서비스를 운영하면서 쌓인 인프라 노하우를 구글 클라우드로 만든 것이고, MS, 네이버 등도 비슷한 경로로 사업을 시작하게 된 것입니다.

개별 기업의 가상화가 수백, 수천 만대의 H/W와 S/W로 구성된 엄청난 규모의 글로벌 가상화로 커지게 된 것입니다. H/W뿐만 아니라, DB, IoT, AI, Bigdata 등의 다양한 서비스로 확대된 것이 바로 Public Cloud인데, 빠른 납기, 안정된 서비스, DR(Disaster Recovery), 글로벌 네트워크 등의 이슈를 해결해 주면서 IT시장에 엄청난 파급력을 보여주고 있습니다.

다음에는 Public Cloud에 대해서 알아보겠습니다.

 

<제 유튜브 채널 '정해진tv'입니다. 도움이 되시길 바랍니다>

https://www.yes24.com/Product/Goods/129406282

넥스트 디지털 - 예스24

 

* 제 유튜브 채널입니다. 도움이 되시길 바랍니다.
https://www.youtube.com/@haejinjeongtv2990

Haejin Jeong TV