컨테이너 오케스트레이션 영역에서 OpenShift를 통한 Red Hat의 리더십은 컨테이너화된 데이터베이스 영역에서 Autonomous Operator를 통한 Couchbase의 리더십을 반영합니다. 이 사실이 바로 Red Hat과 Couchbase 파트너십의 토대입니다. 저는 지난 2년 동안 개인적으로 이 파트너십을 위해 노력해 왔습니다. 이 자리를 빌려 지금이 Red Hat OpenShift에서 Couchbase를 실행하기에 좋은 시기인 이유에 대해 말씀드리고 싶었습니다.
쿠버네티스의 현재 "상태"
Couchbase에 입사하기 전에는 SaaS 모니터링 회사에서 근무했습니다. 모니터링 회사에서 일하면 고객이 어떤 기술을 사용하고 있는지에 대한 독특한 인사이트를 얻을 수 있습니다. 2017년에는 고객들의 모니터링 대시보드에서 Kubernetes와 OpenShift의 티핑 포인트를 확인할 수 있었습니다. 대기업들 사이에서 컨테이너 오케스트레이션 전쟁에서 레드햇 오픈시프트가 승리하고 있는 것은 분명했습니다. 하지만 한 가지 확실히 보이지 않는 것이 있었습니다. 바로 Kubernetes의 데이터베이스였습니다. 특히 프로덕션 환경에서요. 사실, Kubernetes에서 "상태 저장" 워크로드를 실행하는 것은 위험한 것으로 간주되었습니다. 일반적인 아키텍처는 상태 비저장 워크로드는 Kubernetes 또는 OpenShift에서 실행하고 데이터베이스를 다른 곳에서 실행하는 것이었습니다.
데이터베이스 엔지니어라면 누구나 알겠지만, 데이터베이스에서 상태를 관리하는 것은 분산 애플리케이션 는 어렵습니다. 여러 계층의 추상화와 탄력적 확장을 혼합하면 훨씬 더 어려워집니다. Kubernetes는 컴퓨팅과 메모리 리소스를 관리하는 데는 훌륭했지만, 스토리지는 Kubernetes가 직접 관리하는 것이 아니었습니다. 다시 말해, Kubernetes와 OpenShift는 상태 비저장 워크로드를 관리하는 데는 훌륭했지만, 일부 용감한 사람들만이 감히 Kubernetes에서 직접 상태 저장, 지속적 애플리케이션(예: 데이터베이스)을 실행하려고 했습니다. 일반적인 패턴은 데이터베이스를 다른 곳에서 호스팅하는 것이었습니다(아래 다이어그램의 "그때" 참조).
스토리지 - 영구 볼륨
커뮤니티는 이 문제를 해결하고자 했습니다. 영구 볼륨 는 주요 구성 요소였습니다.. 퍼시스턴트 볼륨(PV)은 스토리지 관리 및 격리에 대한 솔루션을 다른 여러 스토리지 클래스 를 실행 중인 파드에 추가합니다. PV는 개별 파드와 독립적인 수명 주기를 가지므로 파드가 파괴된 후에도 데이터를 유지할 수 있습니다. 즉, 재해 시나리오에서 데이터베이스나 OpenShift 노드가 손실되더라도 데이터 손실에 대해 걱정할 필요가 없습니다.
클라우드 공급업체와 동료 Red Hat 파트너를 포함해 여러 스토리지 공급업체가 퍼시스턴트 볼륨 API를 통해 Kubernetes에 대한 지원을 추가했습니다, Portworx. 즉, 스토리지를 선택할 때 선택권이 있다는 뜻입니다. 이는 올바른 스토리지를 선택하는 것이 성능과 안정성에 큰 영향을 미칠 수 있는 데이터베이스 공급업체의 관점에서 볼 때 매우 중요합니다.
오퍼레이터 프레임워크
두 번째 주요 혁신이자 Couchbase가 OpenShift에서 NoSQL 데이터베이스의 리더가 될 수 있게 해준 혁신은 다음과 같습니다. 의 운영자 프레임워크. Couchbase는 Operator 개발에 진지하게 투자한 최초의 NoSQL 데이터베이스 회사입니다("운영자 역량 모델 전반에서 발전하는 상위 쿠버네티스 운영자"). 우리는 운영자 프레임워크 개발 초기에 CoreOS 팀과 협력했습니다. 오늘날 Couchbase 고객은 배포, 확장, 재해 복구, 롤링 업그레이드 등을 포함한 많은 클러스터 운영을 관리하기 위해 Couchbase Autonomous Operator를 사용할 수 있습니다. 이는 Couchbase 고객에게 엄청난 가치를 제공하며 OpenShift 채택을 촉진하는 데도 도움이 되고 있습니다.
그렇다면 오퍼레이터란 무엇일까요? Red Hat CoreOS 팀의 이 인용문은 이를 가장 잘 요약하고 있습니다:
"개념적으로, 운영자는 인간의 운영 지식을 소프트웨어로 인코딩하여 보다 쉽게 패키징하고 소비자와 공유할 수 있습니다.. 오퍼레이터는 소프트웨어 공급업체의 엔지니어링 팀의 확장으로, Kubernetes 환경을 감시하고 현재 상태를 사용하여 밀리초 단위로 의사 결정을 내리는 역할을 한다고 생각하면 됩니다. 오퍼레이터는 기본 기능부터 애플리케이션에 대한 특정 로직 보유까지 다양한 성숙도 모델을 따릅니다. 고급 운영자는 업그레이드를 원활하게 처리하고, 장애에 자동으로 대응하며, 시간을 절약하기 위해 소프트웨어 백업 프로세스를 건너뛰는 등의 지름길을 택하지 않도록 설계되었습니다."
https://coreos.com/blog/introducing-operator-framework
분산 상태 관리가 어렵고 시스템마다 매우 구체적인 구현 세부 사항에 따라 상태를 다르게 관리한다는 점을 고려할 때, 모든 상태 저장 애플리케이션이 직면할 수 있는 모든 가능한 시나리오에 대해 Kubernetes 커뮤니티가 코딩하기를 기대하는 것은 결코 합리적이지 않았습니다. 오퍼레이터 프레임워크를 통해 개발자는 이러한 격차를 해소할 수 있으며, 이는 쿠버네티스 패러다임에 부합하는 방식으로 이루어집니다. 예를 들어: 재해 시나리오에서 Couchbase 파드를 실행하는 OpenShift 노드가 다운되면, Couchbase 자율 운영자가 자동으로 정상적으로 클러스터를 복원하고 Couchbase를 사용하는 서비스에 대한 중단 없이 데이터 밸런스를 재조정합니다. 또한 퍼시스턴트 볼륨을 사용하는 경우, 손실된 포드의 볼륨을 새 Couchbase 포드에 다시 연결하여 데이터 재밸런싱에 걸리는 시간을 크게 단축할 수 있습니다.
운영자 라이프사이클 관리자
운영자가 성숙해짐에 따라 주변 도구도 함께 발전했습니다. 가장 좋은 예는 운영자 수명 주기 관리자(OLM). OLM은 OpenShift 3.11부터 기술 프리뷰 버전이었습니다. OpenShift 4부터는 공식적으로 지원되는 기능입니다. 일반적으로 Operator를 설치하려면 클러스터 관리자 권한이 필요하며, 다음과 같은 몇 가지 수동 단계를 거쳐야 합니다. 사용자 지정 리소스 정의. OLM은 설치 작업을 자동화하며 클러스터 관리자 권한이 없어도 업데이트를 관리할 수 있습니다. OLM은 오퍼레이터 허브 즉, 새로운 운영자 업데이트가 푸시되면 해당 업데이트가 OperatorHub 카탈로그에 표시되고 OLM을 통해 설치할 수 있게 됩니다. 따라서 사용자는 몇 번의 클릭만으로 필요한 오퍼레이터를 찾아 설치할 수 있습니다.
이 기능의 주요 이점 중 하나는 개발자의 생산성입니다. 개발자는 OpenShift 개발 환경 내에서 "서비스형 운영자"를 사용할 수 있습니다.
왜 카우치베이스인가요?
최근 몇 년 동안 "클라우드 네이티브"라는 용어는 기술 업계에서 흔히 사용되는 용어가 되었습니다. 특히 Kubernetes와 OpenShift에 대한 논의의 맥락에서 자주 등장합니다. Kubernetes는 종종 클라우드 네이티브 애플리케이션을 위한 플랫폼으로 자리매김하고 있습니다. 클라우드 네이티브는 클라우드 컴퓨팅 모델을 활용하도록 설계된 소프트웨어를 의미합니다. 실제로 이는 모놀리식 아키텍처와 달리 마이크로서비스 및 서비스 지향 아키텍처 패턴에 더 적합하고, 수직적 확장과 달리 수평적 확장을 목표로 하며, 상대적으로 가벼운 컨테이너에서 실행할 수 있는 애플리케이션을 의미합니다. 이는 모놀리식 패턴을 매우 많이 따르고 Couchbase와 같은 방식으로 수평적으로 확장하도록 설계되지 않은 기존의 관계형(및 일부 NoSQL) 데이터베이스에 문제가 될 수 있습니다.
이 점이 다른 옵션에 비해 Couchbase가 빛나는 부분입니다. Couchbase는 설립 초기에 최대 사용자들로부터 클라우드 환경에서 웹 스케일 워크로드를 지원해야 한다는 압박과 도전을 받았습니다. Couchbase는 처음부터 현재 우리가 클라우드 네이티브라고 부르는 것과 유사한 아키텍처를 채택했습니다. Couchbase에서는 이러한 점이 다음과 같은 다차원 스케일링 기능을 사용할 수 있습니다. 다차원 확장을 사용하면 온라인에서 트래픽을 처리하는 동안 Couchbase의 각 서비스(데이터, 인덱스, 쿼리, 분석, 전체 텍스트 검색, 이벤트)를 독립적으로 확장할 수 있습니다. 이것이 바로 클라우드 네이티브를 염두에 두고 애플리케이션을 설계하는 방법입니다.
다차원 확장 외에도 자동 샤딩 및 강력한 기본 제공 관리 인터페이스와 같은 다른 Couchbase 기능은 OpenShift에서 NoSQL 워크로드를 원활하게 관리할 수 있도록 도와줍니다.
앞으로 나아갈 방향
카우치베이스 자율 운영자 2.0 베타 버전
저희는 운영자와 함께 클러스터를 실행하는 데 필요한 모든 Couchbase 운영 모범 사례를 자동화하는 것을 목표로 합니다. 궁극적인 목표는 우리 고객과 Red Hat의 고객이 클라우드, 온프레미스 또는 두 가지 모두에서 모든 OpenShift 환경에서 실행되는 자체 Couchbase DBaaS를 효율적으로 운영할 수 있도록 하는 것입니다. Couchbase의 자체 DBaaS 제품조차도 Couchbase Autonomous Operator에 크게 의존하고 있습니다.
저희는 최근 카우치베이스 자율 운영자 2.0 베타 버전. 운영자 자체에 새로운 기능을 계속 추가하고 있지만, Couchbase는 인프라의 한 부분일 뿐이라는 점을 잘 알고 있습니다. 실제로는 여러 인프라에 걸쳐 있는 메트릭 및 로그 모니터링, 보안과 같은 다른 기능들이 있습니다. Operator 2.0에는 Couchbase Server 메트릭을 수집하고 노출하기 위한 Couchbase Prometheus Exporter와의 기본 통합 기능이 포함되어 있습니다. 즉, Ret Hat OpenShift 환경 내에서 다른 애플리케이션과 함께 Couchbase를 모니터링할 수 있습니다.
멀티 및 하이브리드 클라우드 워크로드 지원
Couchbase의 또 다른 주요 기능에 대해 언급하지 않는다면 실례가 될 것입니다. 데이터 센터 간 복제(XDCR). XDCR은 항상 Couchbase의 인기 있는 기능입니다. 이 맥락에서 중요한 이유는 OpenShift에서 멀티 및 하이브리드 클라우드 상태 저장 워크로드를 활성화하는 데 있어 그 역할이 중요하기 때문입니다. OpenShift는 이미 다양한 클라우드와 온프레미스에 애플리케이션을 쉽게 배포할 수 있도록 지원합니다. XDCR을 사용하면 OpenShift 클러스터 간에 데이터 복제를 달성할 수도 있습니다. 앞으로 몇 주 동안 저희(Red Had와 Couchbase)는 이 주제에 대해 구체적으로 더 많은 콘텐츠와 업데이트를 제공할 계획입니다. 기대해 주세요!
리소스
- 레드햇 오픈시프트 블로그: 운영자 역량 모델 전반에서 발전하는 최고의 Kubernetes 운영자
- 카우치베이스 자율 운영자 2.0 베타 발표
- 레드햇 오픈시프트에 카우치베이스 자율 운영자 설치하기
- 카우치베이스의 Red Hat 파트너 페이지
