쿠버네티스의 장점을 흡수한 오픈스택의 무한 변신

Red Hat OpenStack Services on OpenShift가 발표 소식을 들어 보셨나요? 이 소식은 좀 자세히 그 의미를 파악할 필요가 있습니다. 기업들이 오픈스택(OpenStack)을 배포하고 운영하는 방식에 큰 변화를 불러올 신호탄이기 때문입니다.

 

지금까지 Keystone, Glance, Nova, Neutron, RabbitMQ, Galera DB 같은 오픈스택의 주요 서비스를 물리 서버나 가상 머신(VM) 위에서 각각 독립된 컨테이너로 올려서 관리해 왔습니다. 이번에 Red Hat OpenStack Services on OpenShift 등장으로 컨트롤 플레인 자체를 Red Hat OpenShift 위의 Pod로 전환해 쿠버네티스(Kubernetes) 오케스트레이션 기능을 활용하도록 만든 것입니다. 이 변화가 왜 중요한지 그리고 실제로 기업 입장에서 어떤 이점을 얻게 되는지 알아보겠습니다.

이미지 출처 : Red Hat

 

 

컨트롤 플레인의 대변신

 

기존의 오픈스택 환경을 운영해본 분이라면 오픈스택 컨트롤 플레인 구성이 매우 복잡하고 어렵다는 것을 잘 알 것입니다. 물리 서버를 최소 세 대 준비하고, 이를 컨트롤러로 설정한 뒤, 각각 Keystone, Glance, Nova, Neutron 같은 서비스를 각각 다른 컨테이너나 프로세스로 올려야 합니다. 여기에서 네트워크 설정과 스토리지 설정, 장애복구 대비 구성이 뒤섞이면 운영이 한층 더 까다로워집니다.

 

그런데 이번에 등장한 Red Hat OpenStack Services on OpenShift는 말 그대로 오픈스택의 두뇌가 될 컨트롤 플레인을 Red Hat OpenShift 내부의 Pod로 전환하여 쿠버네티스가 직접 서비스의 스케줄링과 배포, 확장을 담당하도록 해 줍니다. 예전에는 물리 서버나 VM 위에 docker 컨테이너로 올려놓고 수작업 스크립트나 TripleO 같은 툴을 이용해 관리했다면, 이제는 쿠버네티스 API와 Red Hat OpenShift의 오퍼레이터를 통해 훨씬 현대적인 방식으로 오픈스택을 운용할 수 있게 된 것입니다.

 

레드햇은 왜 Red Hat OpenStack Services on OpenShift를 준비했을까요? 여러 이유가 있겠지만, 가장 큰 이유는 쿠버네티스가 이미 전 세계적으로 가장 안정적이고 널리 쓰이는 컨테이너 오케스트레이션 플랫폼이기 때문입니다. 쿠버네티스의 매력은 컨테이너 기반 애플리케이션을 어떻게 배포하고, 장애 상황에서 어떻게 재시작하고, 리소스를 어떻게 균형 있게 배분해야 할지에 대한 노하우가 산업계와 커뮤니티 생태계에 풍부하게 쌓였다는 것입니다. 이번 레드햇의 발표로 앞으로 오픈스택의 컨트롤 플레인도 쿠버네티스의 장점을 적극적으로 누릴 수 있게 될 것으로 보입니다.

 

스토리지 접근 방식의 변화

 

컨트롤 플레인이 Pod로 전환되었다는 것은 데이터를 어디에 어떻게 저장해야 하느냐라는 문제도 새롭게 떠오른다는 것을 의미하기도 합니다. 이전에는 물리 서버 3대를 컨트롤러로 쓰면서 각각의 로컬 디스크나 외부 SAN, NAS 같은 네트워크 스토리지에 직접 연결해 데이터베이스나 이미지를 저장하곤 했습니다. 하지만 Pod는 원칙적으로 휘발성(Ephemeral) 스토리지를 기본으로 씁니다. 그런데Galera 데이터베이스나 Glance 이미지 캐시, RabbitMQ 메시지 큐 같이 데이터가 사라져서는 안 되는 서비스에는 영구적인 저장소가 필요합니다.

 

바로 이 지점에서 Red Hat OpenShift가 지원하는 ‘Persistent Volume(PV)’과 ‘Persistent Volume Claim(PVC)’ 같은 쿠버네티스 표준 스토리지 개념이 등장합니다. Red Hat OpenShift는 컨테이너 스토리지 인터페이스(CSI)를 활용해 Ceph나 타사 SDS(Software Defined Storage), 혹은 NFS, iSCSI 등을 연결할 수 있습니다. 즉, 예전에 물리 서버의 디스크나 SAN을 직접 관리하던 것을 이제는 Red Hat OpenShift의 영구 볼륨이라는 형태로 추상화해서 붙이는 셈입니다.

 

이러한 추상화 덕분에 오픈스택 운영자가 새롭게 고민해야 할 부분도 있지만, 동시에 얻을 수 있는 이점도 분명합니다. 먼저 스토리지 백엔드를 선택하는 폭이 훨씬 넓어졌습니다. Ceph를 계속 쓰고 싶다면 Ceph CSI 드라이버를 통해 Red Hat OpenShift에서 바로 연결할 수 있고, 타사 스토리지를 이미 활용 중이라면 그 업체가 제공하는 CSI 드라이버를 통해 연계하면 됩니다. 다음으로 장애가 났을 때 Pod 재시작이나 다른 노드로의 재스케줄링이 한결 편해졌습니다. Pod가 옮겨 가더라도, 필요한 영구 데이터는 쿠버네티스가 PVC를 통해 매핑해주기 때문입니다.

 

컴퓨트 노드 자동화

 

오픈스택이 실제 가상 머신을 구동하는 컴퓨트 노드는 여전히 물리 서버나 VM이 필요합니다. 여기서는 RHEL(Red Hat Enterprise Linux)을 기본 운영체제로 사용하지만, 이번에는 Metal3와 OpenShift Operator가 작동하여 서버를 자동 프로비저닝하게 바뀌었습니다. 참고로 Metal3는 베어메탈 서버를 쿠버네티스 클러스터에 노드로 등록하고 관리하는 역할을 하고, OpenShift Operator는 OpenStack 컴퓨트 노드를 배포하고 설정하는 역할을 합니다.

 

이번 변화에 따라 예전에 우리가 직접 PXE 부팅 환경을 만들거나, 이미지를 하나씩 설치하고 네트워크 설정을 일일이 잡아야 했다면, 앞으로는 Metal3와 Ansible이 뒤에서 돌아가면서 필요한 노드를 알아서 준비해 주는 방식으로 운영할 수 있게 됩니다.

 

이 역시 운영자를 한층 더 자유롭게 만들어줍니다. 단지 서버를 랙에 꽂고 전원을 켠 뒤, 네트워크만 연결해 두면 Metal3가 서버의 하드웨어 정보를 수집하고, 적절한 이미지를 배포해 RHEL을 설치한 뒤, OpenStack 컴퓨트 노드 역할을 부여하는 과정을 자동으로 처리할 수 있습니다. 이렇게 하면 대규모 환경에서 노드를 늘려야 할 때, 훨씬 빠른 속도로 확장하는 것이 가능합니다.

 

고민해야 할 부분

 

물론 Red Hat OpenStack Services on OpenShift가 예고하는 모든 변화가 마법 같이 운영 방식을 혁신하는 것은 아닙니다. 컨트롤 플레인이 Pod로 올라가려면 그만큼 Red Hat OpenShift 클러스터를 안정적으로 구성해 두어야 하고, 영구 스토리지 선택에도 신경 써야 합니다. 예를 들어 쿠버네티스 Pod가 쉽게 옮겨 다니면 좋은 점이 많지만, 동시에 데이터베이스나 메시지 큐 같은 데이터가 필요한 서비스라면 적절한 영구 볼륨(Persistent Volume) 설정을 미리 해두어야 합니다. 운영 환경에 따라 Ceph를 온전히 통합할지, 혹은 로컬 디스크를 쓰는지, 타사 스토리지 솔루션을 CSI 드라이버로 붙일지 등을 사전에 충분히 검토해야 합니다.

 

하지만 이러한 고민들은 대부분 이미 쿠버네티스 기반 애플리케이션을 운영해 본 분들께는 익숙한 주제입니다. 달리 말하자면 기존에는 오픈스택에 한정된 문제로 느껴졌던 스토리지·네트워크 구성 이슈가, 이제 좀 더 표준적인 쿠버네티스 방식으로 풀릴 수 있게 된 것입니다.

 

현대적인 인프라로의 전환

 

Red Hat OpenStack Services on OpenShift가 제시하는 이 새로운 아키텍처는 오픈스택이 이제 쿠버네티스의 장점을 전면적으로 받아들였다는 점에서 큰 의의가 있습니다.

 

기업 입장에서는 오픈스택과 쿠버네티스를 따로 분리해 두지 않고, 한 개의 통합된 운영 체계 아래서 관리하면서 DevOps, GitOps, Operator 등 현대적인 자동화 기법을 적용할 수 있습니다. 컨트롤 플레인의 신뢰성과 확장성이 높아지고, 스토리지 구성도 좀 더 유연해지며, 운영과 장애 대응 역시 간소화됩니다. 미래에 새로운 버전의 오픈스택이 나오거나, 하드웨어를 늘려야 할 때도 기존의 쿠버네티스 운영 방식을 그대로 확장하면 되므로 위험 부담이 줄어듭니다.

 

정리하자면 Red Hat OpenStack Services on OpenShift는 오픈스택 환경을 더 가볍고 유연하게 만들어주는 솔루션입니다. 물리 서버나 VM 위에 독립 컨테이너를 올리던 시절에는 만만치 않았던 운영 작업이, 이젠 쿠버네티스 표준 워크플로와 자동화 툴을 통해 훨씬 깔끔하고 현대적인 방식으로 진행됩니다. 바로 이것이 기업이 필요로 하는 ‘클라우드 네이티브 인프라’가 지향해야 하는 핵심 가치가 아닐까요?

 

새로운 IT 프로젝트를 시작하거나, 기존의 오픈스택 환경을 현대화하는 것을 고민 중이라면, Red Hat OpenStack Services on OpenShift가 몰고올 변화를 관심있게 봐야 합니다. “컨테이너 기반 워크로드와 VM 기반 워크로드를 어떻게 한데 묶고, 동시에 관리할 것인가?”라는 질문에 Red Hat OpenStack Services on OpenShift는 꽤나 현실적인 해답을 제시할 것입니다. 더 자세한 내용이 궁금하시면 락플레이스로 문의 바랍니다.