DB를 k8s에서 쓰는게 좋은 생각인가?

https://medium.com/@fengruohang/database-in-kubernetes-is-that-a-good-idea-daf5775b5c1f

Database in Kubernetes: Is that a good idea?

 

 

요약

• Kubernetes와 데이터베이스의 성격 차이
  • Kubernetes는 원래 무상태(stateless) 애플리케이션, 즉 컨테이너를 빠르게 배포하고 스케일 아웃하는 데 최적화되어 있습니다.
  • 반면, 데이터베이스와 같은 상태(stateful) 애플리케이션은 데이터의 영속성, 안정성, 성능 보장이 핵심이므로 운영 방식과 요구사항이 다릅니다.
• 운영상의 도전 과제
  • 데이터 영속성 관리:
    컨테이너는 기본적으로 일시적인 특성을 가지므로, 데이터베이스의 데이터를 안전하게 보존하기 위해 스토리지 클래스, 퍼시스턴트 볼륨(PV), 퍼시스턴트 볼륨 클레임(PVC) 등을 적절히 구성해야 합니다.
  • 네트워크 및 성능 이슈:
    Kubernetes의 네트워크 추상화 계층이나 스토리지 오버헤드가 데이터베이스 성능에 영향을 줄 수 있으며, 복잡한 네트워크 구성과 레이턴시 관리가 필요합니다.
  • 복잡한 클러스터 운영:
    데이터베이스 클러스터를 Kubernetes 위에 구축하는 경우, 복제, 백업, 장애 조치(failover) 등의 작업이 기존 전용 솔루션에 비해 추가적인 복잡성을 띨 수 있습니다.
• 실제 운영 사례와 접근 방법
  • 글에서는 일부 사용자들이 Kubernetes에서 데이터베이스를 운영하는 사례도 언급하지만, 이들이 보통은 “운영 편의성”보다는 인프라 통합, 자원 관리의 일원화 같은 이점을 추구하며, 그에 따른 트레이드오프(trade-off)를 감수한다고 설명합니다.
  • 또한, 데이터베이스 전용 운영 도구나 클라우드 제공 서비스(Managed Database)를 고려하는 것이 더 나은 선택일 수 있다는 의견도 제시합니다.
• 결론 및 권고 사항
  • 데이터베이스를 Kubernetes에서 운영하는 것은 가능하지만, 단순히 컨테이너화된 애플리케이션처럼 다루면 안 되고, 상태ful 워크로드의 특성을 고려한 세밀한 설정과 모니터링, 백업 및 장애 복구 전략이 필수적입니다.
  • 만약 데이터베이스 운영에 익숙하지 않거나, 복잡한 관리 부담을 줄이고 싶다면, 전통적인 방식이나 클라우드 매니지드 데이터베이스 서비스를 사용하는 것이 더 나을 수 있다는 점을 강조합니다.

 

번역

 

데이터베이스를 Kubernetes나 Docker에 탑재하는 문제는 여전히 많은 논란을 일으키고 있습니다. Kubernetes(k8s)는 무상태 애플리케이션 관리에 뛰어나지만, PostgreSQL이나 MySQL과 같은 상태ful 서비스, 특히 데이터베이스를 운영하는 데는 근본적인 한계가 있습니다.

이전에 “Docker에서의 데이터베이스: 좋은가, 나쁜가”라는 글에서 데이터베이스를 컨테이너화하는 장단점에 대해 논의한 바 있습니다. 오늘은 K8s에서 데이터베이스를 오케스트레이션할 때의 트레이드오프를 깊이 파헤치며, 왜 이것이 현명한 선택이 아닌지를 살펴보겠습니다.

개요

Kubernetes는 복잡한 무상태 애플리케이션들을 더 효율적으로 관리하기 위해 설계된 뛰어난 컨테이너 오케스트레이션 도구입니다. 비록 StatefulSet, PV, PVC, LocalhostPV와 같이 상태ful 서비스를 지원하는 기능들을 제공하지만, 이러한 기능들만으로는 높은 신뢰성이 요구되는 프로덕션급 데이터베이스를 운영하기에 부족합니다.

데이터베이스는 ‘가축(cattle)’보다는 ‘반려동물(pets)’에 가깝기 때문에 세심한 관리와 돌봄이 필요합니다. Kubernetes에서 데이터베이스를 마치 가축처럼 다루면, 외부의 디스크, 파일 시스템, 스토리지 서비스들이 새로운 “데이터베이스 반려동물”로 전락하게 됩니다. EBS나 네트워크 스토리지 위에서 데이터베이스를 운영하면 신뢰성과 성능 측면에서 큰 단점을 가지게 되지만, 고성능의 로컬 NVMe 디스크를 사용하면 데이터베이스가 특정 노드에 묶여 스케줄링이 어려워져 K8s에 탑재하는 본래의 목적을 상쇄시킵니다.

K8s에 데이터베이스를 올리면 ‘윈-윈’ 상황이 아니라 ‘lose-lose’ 상황이 발생합니다. K8s는 무상태의 단순성을 잃게 되어, 순수 무상태 애플리케이션처럼 빠르게 이동, 스케줄, 삭제, 재구축할 수 있는 유연성이 떨어지고, 반면 데이터베이스는 신뢰성, 보안, 성능 및 복잡성 측면에서 큰 손해를 보게 됩니다. 결국 제한된 “탄력성”과 활용도를 얻는 대가로 이러한 중요한 속성들을 잃게 되는데, 이는 가상 머신으로도 충분히 달성할 수 있는 수준입니다. 특히 퍼블릭 클라우드 벤더 외부의 사용자들에게는 단점이 이점보다 훨씬 크게 작용합니다.

“K8s 열풍”이라고 불리는 클라우드 네이티브 열풍은 K8s를 무조건 도입하자는 왜곡된 현상이 되었습니다. 엔지니어들은 자신들의 대체 불가능성을 높이기 위해 불필요하게 복잡한 구조를 추가하고, 관리자들은 산업의 흐름에 뒤처지지 않기 위해 배포 경쟁에 휘말립니다. 문제 해결에 꼭 ‘용을 베는(dragon-slaying)’ 기술이 필요한지 고려하지 않고, 자전거로도 충분한 작업에 전차(탱크)를 사용하는 것과 같은 건, 결국 부정적인 결과로 이어지게 마련입니다.

네트워크 스토리지의 신뢰성과 성능이 로컬 스토리지를 능가하기 전까지, K8s에 데이터베이스를 탑재하는 것은 현명한 선택이 아닙니다. 데이터베이스 관리의 복잡성을 줄일 수 있는 다른 방법들도 존재하는데, 예를 들어 RDS나 Pigsty와 같이 베어메탈 또는 베어 OS를 기반으로 하는 오픈소스 RDS 솔루션 등이 그것입니다. 사용자들은 자신의 상황과 필요에 따라 신중하게 장단점을 저울질하고 현명한 결정을 내려야 합니다.

현 상황

K8s는 무상태 애플리케이션 서비스를 오케스트레이션하는 데는 탁월하지만, 원래 의도와 달리 상태ful 서비스 지원에 제한적이었습니다. 그러나 커뮤니티의 확장 열풍은 멈추지 않았고, K8s를 차세대 클라우드 운영체제로 포장하며 데이터베이스 역시 언젠가는 K8s 내의 일반 애플리케이션이 될 것이라고 주장하는 목소리가 있습니다. 이에 따라 StatefulSet, PV, PVC, LocalhostPV 등 다양한 추상화 계층이 등장했습니다.

수많은 클라우드 네이티브 열풍 주창자들이 기존 데이터베이스를 K8s로 이전하려 시도하면서, PostgreSQL의 경우 이미 PGO, StackGres, CloudNativePG, PostgresOperator, PerconaOperator, CYBERTEC-pg-operator, TemboOperator, Kubegres, KubeDB, KubeBlocks 등 10가지가 넘는 다양한 K8s 배포 솔루션이 등장했습니다. CNCF 환경은 빠르게 확장되며 복잡성의 놀이터로 변해가고 있습니다.

하지만 복잡성은 결국 비용입니다. “비용 절감”이 주류가 되면서, 이제 반성과 회의의 목소리도 나오기 시작했습니다. 공용 클라우드에서 K8s를 깊이 활용했던 DHH와 같은 Could-Exit 선구자들은, 과도한 복잡성 때문에 자가 호스팅 오픈소스 솔루션으로 전환하면서 Docker와 Kamal이라는 Ruby 도구만을 대안으로 사용하게 되었습니다. 많은 이들이 상태ful 서비스인 데이터베이스가 정말 K8s에 적합한지 의문을 제기하기 시작했습니다.

K8s 자체도 상태ful 애플리케이션을 지원하려는 노력 속에서 점점 복잡해지며, 원래의 컨테이너 오케스트레이션 플랫폼으로서의 의도에서 벗어나고 있습니다. Kubernetes의 공동 창립자인 Tim Hockin도 올해 KubeCon에서 “K8s는 스스로를 잡아먹고 있다(K8s is Cannibalizing Itself!)”는 주제로 드물게 우려를 표명하며 “Kubernetes는 너무 복잡해졌다. 자제력을 배워야 혁신을 계속할 수 있고, 기반을 잃지 않을 것이다.”라고 말했습니다.