[개발] 클라우드에 대해 알아보기

안녕하세요. 지금은 클라우드네이티브 부서에 배치돼서 서버개발하고 있습니다.. 쉽게 말하면 EC2를 만드는 일이죠. 공부한거 정리할 겸 + 도메인지식 쌓을 겸 글 써 봅니다. 틀린점이 있다면 지적 환영합니다,, 클라우드 비즈니스의 히스토리 위주로 갈 것 같네요. 

전통적인 배포 방식

과거 선배 개발자들의 사례를 보면 application 배포를 할 때 서버를 직접 구매해서 설치하고 네트워크 설정하고 다 했다고 합니다. 이런 걸 on-premise방식이라고 하죠. 언뜻 보기엔 귀찮고 오래걸릴 작업이라고 생각하지만 장기적으로 봤을 때는 이득이 될 수도 있습니다. 초기비용만 크게 투자를 하고 설치와 세팅만 잘 끝낸다면 그 이후로는 전기료만 잘 낸다면 추가 비용이 들 일이 적죠. (지속적으로 비용을 지불하는 클라우드 서비스와 반대됩니다.) 

 

서비스가 작고 그런 장비를 필요로 하는 팀이 적다면 on-premise 방식은 유효합니다. 하지만 서비스가 커져도 똑같을까요? 갑자기 어느 팀이 "내일 티켓팅 이벤트가 있으니 추가 장비 부탁해요~"라고 요청을 하면 어떤 일이 일어날까요? 서버가 뚝딱하고 나오는 건 아닙니다.

• 인프라팀에 필요 리소스를 요청한다. (사유 포함)
• 필요한 만큼 서버를 구매한다.
• 서버를 설치하고 초기 세팅을 하고 사용한다.
• 다 쓴 서버는 반납한다.

그 하루를 위해서 이 절차를 진행해야합니다. 타이밍이라도 놓치면 이벤트를 적시에 못하게 될 수도 있고 그렇게 되면 비즈니스적으로 타격을 입게 되죠. 또한 다 쓴 서버를 반납하게 되면 그 서버는 유휴자원이 되고 회사입장에서는 불필요한 자원을 가지고 있으므로 손해를 보게 됩니다.

 

그리고 커진 서비스을 사용하는 트래픽을 감당하려면 유연하게 리소스를 늘리고 줄일 수 있어야합니다. 하지만 갑자기 들어오는 (예상치 못한) 트래픽을 위 절차를 거쳐서 실시간으로 감당하는 건 현실적으로 어렵죠.

 

이러한 문제를 해결하기 위해 가상화라는 개념이 도입됩니다.

 

가상화

사실 하드웨어 가상화는 꽤 오래전 1960년대부터 언급된 개념입니다. 그 때도 많이 쓰였는지는 모르겠지만 요즘 들어서는 위와 같은 문제를 해결하기 위해 많이 사용되곤 합니다. 핵심 컨셉은 이렇습니다.

장비를 물리적으로 제공하기보다는 soft하게 제공할 수 없을까?

리소스가 필요할 경우 직접 서버를 설치하는 것 보다는 서버는 서버실에 있고 필요한 cpu, ram정도만 제공하는겁니다. 그럼 이제 사용자는 리소스를 요청하면 직접 서버를 설치하는 것이 아닌 해당 리소스를 가진 서버에 원격으로 접속하여 사용하게 됩니다. 그 서버의 스펙이 원하는 스펙과 맞지 않을 경우, 예를 들면 서버는 4cpu 8gb인데 원하는 스펙은 2cpu 4gb라면 서버 하드웨어를 가상화하여 제공하게 됩니다. 그렇게 되면 나중에 2cpu 4gb를 원하는 사람이 추가로 들어오게 되면 한 서버로 두 사용자를 만족시키는 셈입니다. 

 

하지만 사용자들의 니즈는 다양할 수 있습니다. 누구는 1cpu 8gb, 누구는 2cpu 2gb이런식으로 요청한다면 자원을 관리하는데 비효율적이므로 가상서버를 제공하는 쪽에서 스펙을 미리 정해두게 되는데 이를 Flavor라고 합니다. AWS를 사용하신 분들이라면 t2.micro, c5.xlarge같은 스펙을 보신 적 있을겁니다. 그 스펙이 flavor입니다.

 

이제 우리는 회사 자산으로 존재하는 서버를 사용하다보니 특정 부서에서 나쁜 마음을 먹어 가장 좋은 flavor를 마구마구 신청하게 되면 다른 팀에서 사용을 못하게 됩니다. 그래서 그런 문제(다른 이유도 있지만)를 방지하기 위해 특정 부서에서 요청할 수 있는 총 자원량의 한도를 정해두게 되고 이를 Quota라고 합니다. 부서마다 Quota는 다를 수 있고 어떠한 이유로 리소스를 많이 필요로 한다면 Quota증설을 요청하게 됩니다.

 

그럼 사용자가 특정 flavor를 요청하면 인프라팀에서 가상화해서 서버를 제공을 해야할까요? Quota 증설도 인프라팀이 해야 할까요? 그렇게 되면 인프라팀은 인프라도 관리하고 가상화 코드까지 개발하는 업무를 맡게되어 피로도가 커질겁니다. 이를 위해 클라우드팀이 필요하게 됩니다. (제가 있는 팀입니다.)

 

정리하면 사용자는 flavor를 클라우드팀에게 요청하면 클라우드팀이 가지고 있는 서버를 가상화하여 제공하게 됩니다. 가상화할 서버가 부족하다면? 인프라팀에게 서버 증설 요청을 보내면 됩니다! 이제 사용자는 인프라팀과 소통할 일이 크게 줄었습니다. 또한 인프라팀은 물리 장비만 잘 관리하면 되고 클라우드는 그 물리장비를 잘 제공하면 되므로 역할이 명확히 분리됐습니다.

 

클라우드 API

이제 잘 생각해보면 사용자가 Quota 증설이나 가상서버 생성 요청 같은 작업들은 사람이 할 필요가 없을 것 같습니다. 요구하는 스펙은 Flavor로 통일 돼 있고 요구하는 행위도 명확합니다. 이럴 때 API라는 사용하기 좋은 도구가 있습니다! 클라우드팀은 요청이 들어오면 손수 가상화 코드를 돌려서 제공하고 특정 부서의 Quota가 얼마인지 직접 기록할 필요 없이 API로 요청을 처리하고 데이터베이스에 기록하면 됩니다. 즉, API만 잘 작성하면 됩니다. (제가 하는 일입니다.)

 

그럼 또 API 만들기 막막하죠. 가상서버가 cpu, ram만 있다고 만들어지는 건 아니고 스토리지, 네트워크, OS같은 것들도 다 필요하고 설정돼야하니까요. 그래서 유명한 오픈소스인 오픈스택이 있습니다. 가장 큰 오픈소스로도 알려져있는 이 오픈스택은 컴포넌트들로 구성돼있고 각 컴포넌트마다 가상서버, 네트워크, 스토리지, OS이미지 관리 하는 등 역할이 있습니다. 컴포넌트를 적절히 조합하여 API를 개발하면 비교적 쉽게 개발할 수 있습니다.

 

결국 클라우드팀은 오픈스택을 활용하여 API를 만들어 가상서버를 잘 제공하는 것이 목적이 됩니다!

 

현대적인 배포 방식

오픈스택이 어디에 쓰이는진 알겠는데 입문하기 위해 책을 구하려고보면 대부분이 절판되어 있습니다.(;;) 왜일까요?

 

요즘은 컨테이너형식의 배포방식을 많이 사용하는 추세입니다. 그래서 이런 컨테이너를 잘 관리하는 오케스트레이션 도구인 쿠버네티스가 대두되고 있는데 쿠버네티스의 노드로 VM을 사용할 뿐 쌩 VM에 배포하는 경우는 거의 없습니다. EC2에 직접 배포하는 것이 아닌 EKS나 ECS를 많이 사용하죠. 그렇다면 Openstack은 이제 필요가 없을까요?

 

쿠버네티스를 사용하는 방식에 따라 다릅니다. 회사에서 쿠버네티스를 사용할 경우 크게 두 가지 방식으로 사용할 수 있습니다. One Big Cluster방식과 분산 클러스터 방식입니다. one big cluster방식은 회사에서 하나의 큰 쿠버네티스 클러스터만 사용하고 A부서는 A namespace, B부서는 B namespace를 사용하는 형식으로 soft하게 나눠 사용하는 방식입니다. 반대로 분산 클러스터 방식은 A부서는 A클러스터, B부서는 B클러스터를 사용하는 형식으로 부서마다 클러스터를 소유하여 사용하는 방식입니다.

 

One Big Cluster의 사례를 먼저 보면 이 경우는 VM이 필요하지 않습니다! 그냥 가상화할 필요 없이 서버를 통채로 노드로 사용하면 되기 때문이죠. VM이 필요 없기 때문에 Openstack도 사용할 필요가 없어 이런 방식을 사용한다면 클라우드 팀이 없어도 될 것 같습니다. 하지만 클러스터가 하나이기 때문에 마스터노드도 하나입니다. 그렇게 되면 서비스가 많은 기업이라면 한 클러스터의 수많은 Pod들을 관리하는 마스터노드의 부담이 커지게 됩니다! 수많은 Pod의 헬스체크를 하고 Etcd에 저장되는 클러스터 정보들도 엄청 많기 때문에 데이터베이스도 조회 등에서 성능이 떨어지게 되죠. 그렇다고 사용을 못하는 건 아니고 적절한 관리를 해준다면 사용할 수 있습니다. 예를들어 etcd를 샤딩한다면 데이터베이스에 저장되는 정보들을 분산할 수 있습니다. 결국 One Big Cluster는 VM이 필요없다는 장점이 있지만 마스터노드의 부하를 조절할 관리가 필요하게 됩니다.

 

분산 클러스터는 반대입니다. 4cpu 8gb서버에 클러스터가 두 개 뜰 수 있으므로 가상화를 하여 자원을 나눌 필요가 있습니다. 각 클러스터마다 마스터노드가 존재하므로 부하는 상대적으로 신경 쓸 필요가 없지만(그래도 존재할 수 있습니다.) VM이 여전히 필요하다는 점이 있습니다.

 

AWS의 사례

AWS의 사례를 보면 위와 비슷합니다. 원래는 온라인 쇼핑을 서비스하는 Amazon에서 블랙프라이데이 등으로 큰 규모 트래픽을 감당할 일이 생깁니다. 그래서 그 날을 위해 많은 장비를 준비하게 되죠. 하지만 블랙프라이데이가 끝난다면 트래픽은 원래대로 돌아가게 되고 준비한 장비들은 유휴자원이 됩니다. 이제 이 유휴자원을 어떻게 처리할까 고민하다가 "돈받고 자원을 팔아보자!"하며 나온게 AWS이고 이게 비즈니스적으로 성공해서 이 서비스도 주력으로 밀게된 것으로 알려져 있습니다.