Kubernetes의 데이터베이스는 좋은 생각인가요?

오늘은 K8S에서 데이터베이스 조정의 장단점을 살펴보고 이것이 현명한 결정이 아닌 이유를 살펴보겠습니다.

Abstract

Kubernetes(k8s)는 개발자가 다양한 복잡한 상태 비저장 애플리케이션을 더 잘 관리할 수 있도록 돕기 위한 뛰어난 컨테이너 조정 도구입니다. 상태 저장 서비스(예: 데이터베이스)를 지원하기 위한 StatefulSet, PV, PVC 및 LocalhostPV와 같은 제품에도 불구하고 이러한 기능은 더 높은 안정성이 요구되는 프로덕션 수준 데이터베이스를 실행하기에는 여전히 부족합니다.

 

데이터베이스는 "소" 라기 보다는 " 애완동물 " 에 더 가깝고 세심한 관리가 필요합니다. K8S에서 데이터베이스를 "소"로 취급하는 것은 본질적으로 외부 디스크/파일 시스템/스토리지 서비스를 새로운 "데이터베이스 애완동물"로 바꾸는 것입니다. EBS/네트워크 스토리지에서 데이터베이스를 실행하면 안정성과 성능 면에서 상당한 단점이 있습니다. 그러나 고성능 로컬 NVMe 디스크를 사용하면 데이터베이스가 노드에 바인딩되고 예약할 수 없게 되어 K8S에 배치하려는 기본 목적이 무효화됩니다.

 

K8S에 데이터베이스를 배치하면 "패배" 상황이 발생합니다 . K8S는 상태 비저장의 단순성을 잃으며 순전히 상태 비저장 사용처럼 신속하게 재배치, 예약, 파괴 및 재구축할 수 있는 유연성이 부족합니다. 반면에 데이터베이스는 "탄력성"과 활용도가 제한된 대가로 안정성, 보안, 성능, 복잡성 비용이라는 몇 가지 중요한 특성을 안고 있습니다. 이러한 특성은 가상 머신에서도 달성할 수 있습니다. 퍼블릭 클라우드 벤더 외부 사용자의 경우 이점보다 단점이 훨씬 더 큽니다.

 

K8S로 대표되는 ' 클라우드 네이티브 열풍 '은 k8을 위해 k8을 채택하는 왜곡된 현상이 되었습니다. 엔지니어는 대체 불가능성을 높이기 위해 복잡성을 더하는 반면, 관리자는 업계에서 뒤쳐져 배포 경쟁에 휘말리는 것을 두려워합니다. 자전거로 할 수 있는 작업에 탱크를 사용하거나 경험을 쌓거나 자신을 증명하기 위해 문제에 "용을 죽이는" 기술이 필요한지 여부를 고려하지 않고 이러한 종류의 건축 저글링은 결국 불리한 결과를 초래할 것입니다.

 

네트워크 스토리지의 안정성과 성능이 로컬 스토리지를 능가할 때까지 K8S에 데이터베이스를 배치하는 것은 현명하지 못한 선택입니다. 베어 메탈 또는 베어 OS를 기반으로 하는 Pigsty 와 같은 RDS 및 오픈 소스 RDS 솔루션과 같이 데이터베이스 관리의 복잡성을 봉쇄하는 다른 방법이 있습니다 . 사용자는 자신의 상황과 요구 사항에 따라 장단점을 신중하게 고려하여 현명한 결정을 내려야 합니다.

 

The Status Quo

K8S는 상태 비저장 애플리케이션 서비스를 조정하는 데 탁월하지만 처음에는 상태 저장 서비스로 제한되었습니다. K8S와 Docker의 의도된 목적은 아니었음에도 불구하고 확장을 위한 커뮤니티의 열정은 멈출 수 없었습니다. 전도사들은 K8S를 차세대 클라우드 운영 체제로 묘사하며 데이터베이스가 필연적으로 Kubernetes 내에서 일반 애플리케이션이 될 것이라고 주장합니다. 상태 저장 서비스를 지원하기 위해 StatefulSet, PV, PVC 및 LocalhostPV와 같은 다양한 추상화가 등장했습니다.

 

수많은 클라우드 네이티브 애호가들이 기존 데이터베이스를 K8S로 마이그레이션하려고 시도했으며 그 결과 데이터베이스용 CRD 및 운영자가 급증했습니다. PostgreSQL을 예로 들면 PGO, StackGres, CloudNativePG, PostgresOperator, PerconaOperator, CYBERTEC-pg-operator, TemboOperator, Kubegres, KubeDB, KubeBlocks 등 이미 10개 이상의 다양한 K8S 배포 솔루션을 사용할 수 있습니다. CNCF 환경은 빠르게 확장되어 복잡성의 놀이터로 변모하고 있습니다.

 

그러나 복잡성에는 비용이 따릅니다. '원가절감'이 주류를 이루면서 반성의 목소리가 나오기 시작했다. 퍼블릭 클라우드에서 K8S를 깊이 활용했던 DHH와 같은 개척자들은 자체 호스팅 오픈 소스 솔루션 으로 전환하는 동안 과도한 복잡성으로 인해 K8S를 포기하고 대안으로 Docker와 Kamal이라는 Ruby 도구에만 의존했습니다. 많은 사람들이 데이터베이스와 같은 상태 저장 서비스가 Kubernetes에 적합한지 의문을 갖기 시작했습니다.

 

K8S 자체는 상태 저장 애플리케이션을 지원하려는 노력의 일환으로 컨테이너 오케스트레이션 플랫폼이라는 원래 의도에서 벗어나 점점 더 복잡해졌습니다. Kubernetes의 공동 창립자인 Tim Hockin도 올해 KubeCon에서 "K8s is Cannibalizing Itself!(K8s is Cannibalizing Itself!)" 에서 흔치 않은 우려를 표명했습니다. : “ Kubernetes는 너무 복잡해졌습니다. 자제력을 배워야 합니다. 그렇지 않으면 혁신을 멈추고 기반을 잃게 될 것입니다 .”

Lose-Lose Situation

클라우드 네이티브 영역에서는 상태 저장 서비스를 설명하기 위해 "애완동물"과 "가축"의 비유가 자주 사용됩니다. 데이터베이스와 같은 "애완동물"은 신중하고 개별적인 관리가 필요한 반면, "소"는 일회용, 상태 비저장 애플리케이션(일회성)을 나타냅니다.

 

클라우드 네이티브 애플리케이션 12가지 요소: 일회용

 

K8S의 주요 건축 목표 중 하나는 소로 취급될 수 있는 것을 소로 취급하는 것 입니다 . 데이터베이스에서 "스토리지와 계산을 분리"하려는 시도는 상태 저장 데이터베이스 서비스를 K8S 외부의 상태 스토리지와 K8S 내부의 순수 계산으로 분할하는 전략을 따릅니다. 상태는 EBS/클라우드 디스크/분산 스토리지 서비스에 저장되므로 "상태 비저장" 데이터베이스 부분을 K8S에서 자유롭게 생성, 삭제 및 예약할 수 있습니다.

 

불행하게도 데이터베이스, 특히 OLTP 데이터베이스는 디스크 하드웨어에 크게 의존하고 있으며 네트워크 스토리지의 신뢰성과 성능은 여전히 ​​로컬 디스크에 비해 몇 배나 뒤떨어져 있습니다 . 따라서 K8S는 LocalhostPV 옵션을 제공하여 컨테이너가 고성능/고신뢰성 로컬 NVMe 디스크 스토리지를 활용하여 호스트 운영 체제에 있는 데이터 볼륨을 직접 사용할 수 있도록 합니다.

 

그러나 이는 딜레마를 제시합니다. K8S의 예약 및 오케스트레이션 기능에 대해 수준 이하의 클라우드 디스크를 사용하고 열악한 데이터베이스 안정성/성능을 허용해야 합니까? 아니면 호스트 노드에 연결된 고성능 로컬 디스크를 사용하여 사실상 유연한 예약 기능을 모두 잃게 됩니까? 전자는 K8S의 작은 보트에 닻을 채워 전체적인 속도와 민첩성을 저하시키는 것과 같습니다. 후자는 배를 특정 지점에 고정하고 고정하는 것과 같습니다.

 

상태 비저장 K8S 클러스터를 실행하는 것은 물리적 머신의 기본 운영 체제에서 상태 저장 데이터베이스를 실행하는 것처럼 간단하고 안정적입니다. 그러나 이 두 가지를 혼합하면 패전 상황이 발생합니다 . K8S는 상태 비저장 유연성과 임시 예약 기능을 잃는 반면, 데이터베이스는 탄력성, 리소스 활용 및 Day1 전달을 대신하여 안정성, 보안, 효율성 및 단순성과 같은 핵심 속성을 희생합니다. 데이터베이스에 근본적으로 중요하지 않은 속도 .

 

전자의 생생한 예는 KubeBlocks가 기여한 PostgreSQL@K8S 의 성능 최적화입니다. K8S 전문가들은 베어메탈/베어OS에서는 전혀 존재하지 않았던 성능 문제를 해결하기 위해 다양한 고급 방법을 사용했습니다. 후자의 새로운 사례는 재난을 저글링하는 Didi의 K8S 아키텍처 입니다 . K8S에 상태 저장 MySQL을 배치하지 않았다면 상태 비저장 K8S 클러스터를 다시 구축하고 애플리케이션을 재배포하는 데 복구하는 데 12시간이 걸리겠습니까?

장점과 단점

심각한 기술 결정에서 가장 중요한 측면은 장단점을 비교하는 것입니다. 여기서는 "품질, 보안, 성능, 비용"의 순서대로 K8S에 데이터베이스를 배치하는 것과 기존 베어메탈/VM 배포에 대한 기술적 장단점을 논의해 보겠습니다. 나는 모든 것을 포괄하는 포괄적인 논문을 쓰고 싶지 않습니다. 대신, 고려와 토론을 위해 몇 가지 구체적인 질문을 던질 것입니다.

 

품질

 

K8S는 물리적 배포에 비해 추가 장애 지점과 아키텍처 복잡성을 도입하여 폭발 반경을 늘리고 평균 장애 복구 시간을 크게 연장합니다. "데이터베이스를 Docker에 넣는 것이 좋은 아이디어인가요? " , 우리는 Kubernetes에도 적용할 수 있는 안정성에 대한 주장을 제공했습니다. K8S와 Docker는 데이터베이스에 추가적이고 불필요한 종속성과 실패 지점을 도입하여 커뮤니티 실패 지식 축적과 안정성 추적 기록(MTTR/MTBF)이 부족합니다.

 

클라우드 공급업체 분류 시스템에서 K8S는 PaaS에 속하고 RDS는 보다 근본적인 계층인 IaaS에 속합니다. 데이터베이스 서비스는 K8S보다 더 높은 신뢰성 요구사항을 갖습니다 . 예를 들어 많은 회사의 클라우드 관리 플랫폼은 추가 CMDB 데이터베이스에 의존합니다. 이 데이터베이스를 어디에 배치해야 합니까? K8S가 종속된 항목을 관리하도록 해서는 안 되며, 불필요한 추가 종속성을 추가해서도 안 됩니다. Alibaba Cloud의 글로벌 대실패 와 재해를 저글링하는 Didi의 K8S 아키텍처는 우리에게 이러한 교훈을 가르쳐 주었습니다. 더욱이 외부에 이미 데이터베이스 시스템이 있는 상황에서 K8S 내부에 별도의 데이터베이스 시스템을 유지하는 것은 더욱 정당화될 수 없습니다.

 

보안

 

멀티 테넌트 환경의 데이터베이스에는 공격 표면이 추가되어 더 높은 위험과 더 복잡한 감사 규정 준수 문제가 발생합니다. K8S가 데이터베이스를 더욱 안전하게 만들어 주나요? K8S 아키텍처 저글링의 복잡성으로 인해 K8S에 익숙하지 않은 스크립트 키디를 저지할 수도 있지만 실제 공격자에게는 더 많은 구성 요소와 종속성이 더 넓은 공격 표면을 의미하는 경우가 많습니다.

 

"BrokenSesame Alibaba Cloud PostgreSQL 취약점 기술 세부 사항" 에서 보안 담당자는 자체 PostgreSQL 컨테이너를 사용하여 K8S 호스트 노드로 탈출하여 K8S API와 다른 테넌트의 컨테이너 및 데이터에 액세스했습니다. 이는 분명히 K8S에만 해당되는 문제입니다. 위험이 현실이고 이러한 공격이 발생했으며 현지 클라우드 업계의 선두주자인 Alibaba Cloud도 손상되었습니다.

《공격자의 관점 — Alibaba Cloud 해킹을 통한 통찰

 

성능

 

"데이터베이스를 Docker에 넣는 것이 좋은 아이디어인가요?" 에서 언급한 바와 같습니다. , 추가 네트워크 오버헤드, Ingress 병목 현상, 성능이 저하된 클라우드 디스크 등 모두 데이터베이스 성능에 부정적인 영향을 미칩니다. 예를 들어, “PostgreSQL@K8s 성능 최적화” 에서 밝혀진 것처럼 K8S의 데이터베이스 성능이 베어메탈의 데이터베이스 성능과 거의 일치하도록 하려면 상당한 기술적 역량이 필요합니다.

 

지연 시간은 µs 가 아닌 ms 단위로 측정됩니다.

 

효율성에 대한 또 다른 오해는 자원 활용입니다. 오프라인 분석 비즈니스와 달리 중요한 온라인 OLTP 데이터베이스는 리소스 활용도를 높이는 것이 아니라 시스템 안정성과 사용자 경험을 향상시키기 위해 의도적으로 리소스 활용도를 낮추는 것을 목표로 해야 합니다. 분산된 기업이 많은 경우 PDB/공유 데이터베이스 클러스터를 통해 자원 활용도를 높일 수 있습니다. K8S가 주장하는 탄력성 효율성은 K8S에만 국한된 것이 아닙니다. KVM/EC2도 이 문제를 효과적으로 해결할 수 있습니다.

 

비용 측면에서 K8S와 다양한 운영자는 데이터베이스 관리의 복잡성 중 일부를 캡슐화하여 DBA가 없는 팀에 매력적인 적절한 추상화를 제공합니다. 그러나 K8S 자체를 사용하여 발생하는 복잡성에 비해 데이터베이스를 관리하는 데 이를 사용함으로써 감소된 복잡성은 미미합니다. 예를 들어 무작위 IP 주소 드리프트 및 자동 포드 재시작은 상태 비저장 애플리케이션에서는 큰 문제가 아닐 수 있지만 데이터베이스의 경우에는 용납할 수 없습니다. 많은 회사에서는 이러한 동작을 피하기 위해 kubelet을 수정하려고 시도해야 했으며 이로 인해 복잡성과 유지 관리 비용이 더 많이 발생했습니다. .

 

"비용 및 웃음 감소에서 비용 및 효율성 감소까지" "복잡성 비용 감소" 섹션 에 명시된 바와 같이 지적 능력은 공간적으로 축적하기 어렵습니다 . 데이터베이스에 문제가 발생하면 이를 해결하기 위해 데이터베이스 전문가가 필요합니다. Kubernetes에 문제가 있으면 K8S 전문가가 이를 조사해야 합니다. 그러나 Kubernetes에 데이터베이스를 넣으면 복잡성이 결합되고 상태 공간이 폭발하지만 개별 데이터베이스 전문가와 K8S 전문가의 지적 대역폭은 쌓이기 어렵습니다. 문제를 해결하려면 이중 전문가가 필요하며 그러한 전문가는 의심할 여지 없이 훨씬 많습니다. 순수 데이터베이스 전문가보다 더 드물고 비용도 더 많이 듭니다. 이러한 아키텍처 저글링은 장애가 발생할 경우 최고의 퍼블릭 클라우드/대기업을 포함한 대부분의 팀에 큰 차질을 야기하기에 충분합니다.

 

클라우드 네이티브 열풍

흥미로운 질문이 생깁니다. K8S가 상태 저장 데이터베이스에 적합하지 않은 경우 왜 대기업을 포함하여 그렇게 많은 회사가 이를 서두르고 있습니까? 그 이유는 기술적인 것이 아닙니다.

 

Google은 내부 Borg 우주선을 모델로 한 K8S 전함을 오픈소스로 공개했고, 관리자들은 뒤처질 것을 두려워하여 K8S를 사용하면 Google과 동등한 수준이 될 것이라고 생각하여 서둘러 채택했습니다. 아이러니하게도 Google은 K8S를 사용하지 않습니다. AWS를 방해하고 업계를 오도할 가능성이 더 높았습니다. 하지만 대부분의 기업에는 구글처럼 이런 전함을 운용할 인력이 없다. 더 중요한 것은 그들의 문제에는 간단한 용기가 필요할 수도 있다는 것입니다. 베어메탈에서 MySQL + PHP, PostgreSQL + Go/Python을 실행하면 이미 많은 회사가 IPO에 성공했습니다.

 

최신 하드웨어 조건 에서는 수명주기 전반에 걸쳐 대부분의 애플리케이션이 복잡하기 때문에 K8S를 사용하는 것이 정당화되지 않습니다. 그러나 K8S로 대표되는 "클라우드 네이티브" 열풍은 단지 k8을 위해 k8을 채택하는 왜곡된 현상이 되었습니다. 일부 엔지니어들은 이직이나 승진과 같은 개인적인 목표를 달성하기 위해 또는 복잡성을 추가하여 직업 안정성을 높이기 위해 대기업에서 사용하는 "고급" 및 "멋진" 기술을 찾고 있습니다. 그들의 문제를 해결합니다.

 

클라우드 네이티브 환경은 멋진 프로젝트로 가득 차 있습니다. 모든 새로운 개발 팀은 오늘은 Helm, 내일은 Kubevela라는 새로운 것을 소개하고 싶어합니다. 그들은 밝은 미래와 최고의 효율성에 대해 거창하게 이야기하지만 실제로는 "YAML Boys"를 위한 수많은 아키텍처 복잡성과 놀이터를 만듭니다. 즉, 최신 기술을 다루고, 개념을 발명하고, 이를 감수하는 사용자를 희생하여 경험과 명성을 얻습니다. 복잡성과 유지 관리 비용.

CNCF 조경

 

클라우드 네이티브 운동의 철학은 설득력이 있습니다. 즉, 모든 사용자를 위해 퍼블릭 클라우드의 탄력적인 예약 기능을 민주화하는 것입니다. K8S는 실제로 상태 비저장 애플리케이션에서 탁월합니다. 그러나 과도한 열정으로 인해 K8S는 원래 의도와 방향에서 벗어나게 되었습니다. 즉, 상태 저장 애플리케이션에 대한 잘못된 지원으로 인해 부담을 안고 상태 비저장 애플리케이션을 조정하는 데만 능숙했습니다.

현명한 결정을 내리기

몇 년 전 K8S를 처음 접했을 때 나 역시 열광했다. — — 탄탄(TanTan)에서였다. 우리는 2만 개가 넘는 코어와 수백 개의 데이터베이스 클러스터를 보유하고 있었고, 저는 Kubernetes에 데이터베이스를 배치하고 사용 가능한 모든 Operator를 테스트해보고 싶었습니다. 그러나 2~3년간의 광범위한 연구와 건축설계 끝에 나는 마음을 진정시키고 이 광기를 버렸다. 대신 저는 베어메탈/운영 체제를 기반으로 데이터베이스 서비스를 설계했습니다. 우리에게 있어 K8S가 데이터베이스에 가져온 이점은 K8S가 가져온 문제와 번거로움에 비해 미미했습니다.

 

데이터베이스를 K8S에 넣어야 합니까? 상황에 따라 다릅니다. 리소스를 과도하게 판매하는 퍼블릭 클라우드 공급업체의 경우 탄력성과 활용도가 매우 중요하며 이는 수익과 이익에 직접적으로 연결됩니다. 신뢰성과 성능은 뒷자리에 있지만 결국 99.999% 미만의 가용성은 매월 25%의 보상을 의미합니다. 신용 거래 . 그러나 우리를 포함한 대부분의 사용자에게는 이러한 절충안이 다릅니다. 일회성 Day1 설정, 탄력성 및 리소스 활용은 주요 관심사가 아닙니다. 안정성, 성능, Day2 운영 비용 등 핵심 데이터베이스 속성이 가장 중요합니다.

 

우리는 즉시 사용 가능한 PostgreSQL 배포판과 로컬 우선 RDS 대안인 Pigsty 등 데이터베이스 서비스 아키텍처를 오픈 소스화했습니다 . 우리는 K8S와 Docker의 소위 "한 번 빌드하면 어디서나 실행" 접근 방식을 선택하지 않았습니다. 대신 우리는 다양한 OS 배포판 및 주요 버전에 적응하고 Ansible을 사용하여 K8S CRD IaC와 유사한 API를 달성하여 관리 복잡성을 해결했습니다. 이것은 힘든 일이었지만 옳은 일이었습니다. 세상은 PostgreSQL을 K8S에 넣는 또 다른 서투른 시도를 필요로 하지 않습니다. 그러나 하드웨어 성능과 안정성을 최대화하는 프로덕션 데이터베이스 서비스 아키텍처는 필요합니다.

 

Pigsty 대 StackGres

 

아마도 언젠가 분산 네트워크 스토리지의 신뢰성과 성능이 로컬 스토리지를 능가하고 주류 데이터베이스가 스토리지-컴퓨팅 분리를 기본적으로 지원하게 되면 상황이 다시 바뀔 수도 있습니다. 즉, K8S가 데이터베이스에 적합해질 수도 있습니다. 그러나 현재로서는 심각한 프로덕션 OLTP 데이터베이스를 K8S에 넣는 것은 미숙하고 부적절하다고 생각합니다. 이 문제에 대해 현명한 선택을 하시길 바랍니다.