OpenStack 주마간산으로 살펴 보기

이번에는 조금 Classical한 기술을 살펴 보려고 한다. OpenStack은 Cloud를 운영할 수 있는 기술 Component의 집합체로 초기의 CloudStack에 밀려 힘을 못 쓰고 있었지만 현재는 VM(Virtual Machine)을 활용하는 Cloud Stack의 주류가 되었다. 하지만 Container 기술이 각광을 받으면서 VM 보다는 Linux Container를 활용한 서버 기술이 대세가 되면서 조금은 주춤한 모습이긴 하지만 여전히 Cloud를 서버에 Deploy하는데는 절대 강자임을 부인 할 수는 없을 것이다.

이번 포스팅은 OpenStack에 대해서 상세한 설명이나 모든 내용을 파악한다기 보다는 OpenStack이 어떤 Software이고 무엇을 할 수 있으며 관련된 링크, 논문 및 페이지등을 소개 하여 OpenStack에 관심 있는 사람들을 위한 여정표가 될 수 있는 101 페이지를 목적으로 한다. (자세한 기술 이야기가 없으니 너무 머리 아파 하지 말고 읽어도 된다는 이야기 임)

OpenStack is..

OpenStack의 정의는 OpenStack 자체가 더 잘 설명할 것 같으니 홈페이지에 있는 설명 내용을 살펴 보도록 하자.

"OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed and provisioned through APIs with common authentication mechanisms.
A dashboard is also available, giving administrators control while empowering their users to provision resources through a web interface.
Beyond standard infrastructure-as-a-service functionality, additional components provide orchestration, fault management and service management amongst other services to ensure high availability of user applications."
(출처: OpenStack 홈페이지 - https://www.openstack.org/software/)

홈페이지 설명을 잘 읽어 보면 OpenStack은 데이터센터 등에서 사용되는 Computing, Storage, Network 리소스에 대한 관리 및 인증/인가 관리 대시보드등 Cloud 운영 시스템을 Full Stack으로 제공하는 Open Source Project이다. 여러분들이 충분한 서버가 있고 이를 통해서 AWS와 같은 Cloud 서비스를 하거나 회사 내부적으로 또는 집 내부적(?)으로 Cloud 서비스를 운영하고자 한다면 OpenStack을 설치하여 운영할 수 있다는 이야기 이다.

Why OpenStack

AWS, Azure, GCP등 편리한 Cloud Provider Service가 있는 상황에서 이게 왜 필요한가 싶겠지만… Data Center에서 또는 서버를 구축할때 사용되는 용어 중에 CAPEX, OPEX라는 용어가 있는데 이 용어의 뜻을 잠깐 살펴 보겠음. 왜냐하면 이 용어로 설명하는것이 왜 OpenStack과 같은 Solution이 필요한지를 설명하는 가장 쉽고 빠른 방법이기 때문이다.

용어의 설명과 Cloud에서 왜 CAPEX, OPEX가 중요한지에 대해서 잘 설명한 itworld 기사가 있어서 링크를 걸어 본다.

https://www.itworld.co.kr/tags/41735/CAPEX/54471

내용을 읽어 보면 이해가 잘 되겠지만 용어에 대해서 설명해 보도록 한다. CAPEX는 Capital Expenditure의 약자로 투자되는 투자 비용을 말한다. Cloud에서는 서버 및 제반시설에 에 대한 투자 비용을 말한다. 그리고 OPEX는 Operation Expenditure의 약자로 운영에 필요한 비용을 말한다. 사업의 경우 영업비용을 포함하기도 한다. OpenStack을 통해서 Cloud를 구축 할 경우는 CAPEX가 엄청나가 들어 간다. 서버도 사야 하고 상면공간(서버가 위치할 서버실 서버랙, 전기, 공랭 시설등이 필요함)도 마련해야 하고 설치 비용들이 필요하다. 효용성을 떠나서 규모가 작은 Start-up이나 PoC(Proof of Concept)을 위해서는 집행할 수 없는 비용이다. Public Cloud의 경우 CAPEX는 거의 없다고 봐도 무방하다. Public Cloud의 가장 큰 Concept이 Pay-as-go이기 때문에 요청을 한 순간 부터 서비스를 종료 할때까지의 시간 만큼만 비용을 지불하면 된다. 바로 OPEX만 필요한 것이다.

이렇게 보면 Public Cloud를 사용해야 할 것 같지만 대규모 서비스를 지속적으로 제공한다고 하면 이야기가 매우 달라 진다. 가상의 그래프이지만 아래 그래프를 보도록 하자. 수치가 정확하지 않다고 딴지를 걸지 말고 추세(Trend)만 보도록 하자….

3년을 동일 서비스를 OpenStack과 Public Cloud로 운영한다고 가정하고 비용을 예시로 들어 봤다. Public Cloud의 단점은 초기 비용이 적지만 운영 비용이 꽤 크다는 것이다. 특히 규모의 경제가 이루어지지 않기 때문에(물론 대규모 사용의 경우 Discount가 된다. 이를 고려해도 운영 비용이 비싸다.) 그래서 Public Cloud의 운영비의 누적에 의한 총 소유 비용(Total Cost of Ownership)이 OpenStack의 TCO를 상회하는 시점이 발생한다. 이는 운영 규모에 따라서 바뀌기 때문에 어떤 서비스를 운영할 것인지 잘 고려해 봐야 한다.

그리고 OpenStack을 사용한다고 해서 꼭 서버를 직접 소용해야 하는 것은 아니다. Public Cloud를 통해서 OpenStack을 운영할 수도 있으니 이를 잘 활용한다면 TCO 관점에서 적절한 선택을 할 수 있다.

비용적인 장점 이외에 다른 장점도 살펴 보자. AWS, Azure, GCP를 사용한다는 것은 VM 단위의 서비스를 사용한다는 의미도 있겠지만 대부분 각 Cloud Provider들이 제공하는 Managed Service를 사용할 것이다. 각 Vender들에게 특화된 서비스는 초기 노력이 적고 오류가 적기 때문에 매력적인 서비스들이다. 하지만 밝음에는 늘 어두움이 함께 있으니 바로 Lock-in이다. 한 번 특정 Cloud Provider에게 Lock-in이 되면 그 서비스를 다른 Cloud로 옮기는 것은 매우 요원한 일이 된다. OPEX가 비싸져도 어쩔 도리가 없다. 눈물을 머금고 써야만 한다. OPEX가 적다고 생각하겠지만 GPU와 같이 특수 목적의 Computing이나 실시간 비디오 서비스 같은 Managed 서비스는 상상을 초월하는 가격을 지불해야만 사용할 수 있다. 언급한 서비스를 영원히 안 쓸 것이라고 누구도 장담 못할 것이다. 특수 서비스만 다른 Cloud를 사용할 수는 없기 때문이다. (방법이 없는건 아니지만 아예 고려하지 않는 편이 정신 건강에 이로울 것이다.)

서버를 직접 운영하는 경우에도 OpenStack을 사용하지 않고 직접 서버를 설정해 가면서 사용할 수 있다. 이럴 경우 성능 관점에서 큰 이점을 볼 수 있다. Virtualization이라는 것이 오버헤드를 반드시 동반 하기 때문이다. 하지만 이렇게 직접 서버를 설정해서 운영할 경우 유연성이 매우 떨어진다. Infrastructure as Code(IaC)라는 개념이 있는데 서버의 환경을 직접적인 설정이 아닌 자동화된 서비스를 이용하여 코드 레벨로 수정이 가능한 유연성을 확보 하는 개념이다. 이럴 경우에도 OpenStack이 큰 도움이 될 것이다. IaC는 OpenStack이외에도 Kubernetes나 다른 가상화 환경을 통해서 구현할 수 있다. (물론 OpenStack만 있다고 가능하지는 않다. 주요 Component라는 것이다.)

IaC에 대한 좋은 블로그를 소개 한다.

https://searchitoperations.techtarget.com/definition/Infrastructure-as-Code-IAC

OpenStack Release 정책

OpenStack은 1년에 2차례 정식 Release를 내놓고 있으며 2010년 1월 Austin을 시작으로 2021년 6월 Wallaby가 릴리즈 되었다. 버전이 릴리즈 될때 마다 알파벳이 하나씩 뒷쪽으로 바뀐다. 2021년 10월에는 X로 시작하는 Xena가 릴리즈될 예정이다. ‘Z’가 끝나면 어떻게 릴리즈 될지 귀추가 주목이 된다. 릴리즈 히스토리는 아래 링크에서 확인할 수 있다. 링크 누르기 귀찮은 독자를 위해 캡쳐도 함께 첨부 한다.

https://releases.openstack.org/index.html#release-series

OpenStack Services

서론이 꽤 길었다. OpenStack은 필요성을 인식하고 시작하지 않으면 워낙 복잡하고 어렵기 때문에 충분한 설명이 필요했다. 자 이제 OpenStack에서 공식적으로 제공하는 Service Component에 대해서 알아 보도록 하자. 공식 사이트에 친절하게 그려져 있는 그림을 살펴 보도록 하겠다.

정말 많은 서비스들이 존재 한다. 서비스들 구성에 대해서 하나씩 설명하는 것은 본 글의 취지에서 벗어나기도 하고 너무 어려운 내용이기 때문에 주요 서비스에 대해서 간략히 설명을 하는 것으로 마무리 하도록 하겠다.

기술적인 자세한 내용은 ‘OpenStack 한국 커뮤니티’를 방문하여 확인할 수 있다. https://www.facebook.com/groups/openstack.kr/

OpenStack Core Service

그림에서 보는 것처럼 굉장히 많은 서비스들이 존재 한다. OpenStack을 제대로 이해하고 사용하려면 전체를 다 이해해야 하겠지만 실제 운용이 목적이 아니니 그림 정 중앙에 빨갛게 되어 있는 왠지 중요해 보이는 서비스들을 살펴 보도록 하자.

※ OpenStack은 OpenSource Project이니 다음 Gerrit 사이트에가서 소스코드를 직접 다운로드 받을 수 있다. GitHub이 아니고 다른 서비스를 이용중이니 조금 생소할 수 있다. (https://opendev.org/openstack)

몇가지만 뽑았는데도 꽤나 많다. 간략하게 서비스별로 역활에 대해서 알아 보도록 하겠다.

1. Nova (Compute): OpenStack의 IaaS의 핵심으로 Cloud computing controller이다. 즉 VM을 시스템의 Hypervisor를 통해서 가상 환경을 만들고 이를 관리 하는 역할을 한다. AWS의 EC2와 같은 Instance를 만들어서 제공해 주는 Controller라고 생각하면 이해가 쉽다. OpenStack 초기 릴리즈 부터 지원되었던 기능이다.
2. Zun (Compute): OpenStack에서 Container로 Instance를 만들과 관리해주는 역할을 한다. Container 버전의 Nova라고 이해하면 되고 K8S와 닮아 있다고 볼 수 있다. OpenStack Pike 릴리즈 부터 지원되었다. 이전에는 Magnum을 통해서 Container를 관리 했었는데 API레벨에서 Container의 Life-cycle management까지 Zun은 담당하고 있다. Magnum은 Provisioning을 직접 담당
3. Swift (Storage): Object Storage 서비스를 위해서 개발된 서비스로 최근 다양한 클라우드 서비스의 Object Storage 인프라로 많이 사용되고 있다.
4. Cinder (Storage): Swift가 Object Storage를 담당하는 서비스라면 블록 스토리지를 담당하는 서비스는 바로 Cinder 이다. Nova와 Zun에서 사용할 Persistent Volume을 제공하는 역할을 하며 다양한 NAS/SAN, NFS, Ceph등의 Backend와 연결해서 동작할 수 있다.
5. Manila (Storage): Network share file system을 제공하기 위해서 사용되는 서비스 이다. NFS, CIFS, HDFS등의 Backend를 드라이버로 제공하고 다양한 토폴로지를 지원할 수 있다.
6. Neutron (Networking): OpenStack내부 네트워킹을 가상화 하여 지원합니다. SDN이라고 이해하면 빠르다. Network Slicing 등을 정의 하여 사용할 수 있다.
7. Octavia (Networking): 외부에서 들어 오는 Traffic을 내부의 적절한 인스턴스에 전달하는 Loadbalancer역할을 한다. 이중화로 여러 인스턴스가 존재 하거나 포트가 바뀌거나 하는 다양한 일들이 벌어지기 때문에 아주 유용한 서비스입니다. 오픈스택 코라이계의 스타이신 나래짱님의 포스팅을 참고하시면 이해가 쏙쏙
   https://naleejang.tistory.com/212
8. Designate (Networking): DNS… 끝…. 라고 하면 서운 할텐니… OpenStack으로 만들어진 수많은 인스턴스들이 도메인을 가질수도 있고, 서브 도메인을 가질 수도 있다. 이런 인스턴스를 외부에서 찾을 수 있도록 도와 주는 역할을 한다.
9. Ironic (Hardware Lifecycle): OpenStack은 OpenStacker Head node 또는 Controller 가 설치된 서버만을 제어할 수 있는 것이 아니라 물리적인 컴퓨터를 관리할 수 있도록 되어 있다. 그 서비스가 바로 Ironic!
10. Cyborg (Hardware Lifecycle): 요즘은 없어서는 안될 GPU를 2010년 초반에 나온 OpenStack을 2016년 정도까지 제대로 지원하지 못했다. 인스턴스에서 GPU를 사용하지 못하는게 아니라 가상화 GPU 지원이 안되었다. 하지만 Cyborg가 등장 한다면? . . . Cyborg에서는 vGPU, FPGA, DPDK등 다양한 Hardware Acceleorator 지원을 서비스 한다.

마치며…

아주 간략하게 OpenStack 서비스 소개를 마무리 하였다. 이외에도 인증/인가를 위한 Keystone, Deploy를 위한 Helm등 다양한 서비스가 있지만 빨간 주요 서비스를 소개로 마무리 하도록 하겠습니다. 🙂