고성능 MySQL, 제 4판

부록 B. Kubernetes의 MySQL

지난 5년 동안 기술 분야에서 일해 보셨다면 Kubernetes에 대해 들어보셨거나, Kubernetes를 실행하는 팀과 함께 일해 보셨거나, 컨퍼런스 강연을 많이 보셨거나, Kubernetes를 설명하는 블로그 게시물을 많이 읽으셨을 것입니다. 조직에서 자체 Kubernetes 클러스터를 실행하는 경우, 어느 시점에서 클러스터에서 MySQL도 실행하는 것이 좋은 생각인지 질문을 받게 될 것입니다. 표면적으로는 합리적인 선택처럼 보입니다. 많은 Kubernetes 클러스터를 관리하는 것은 일반적으로 전담 인력이 필요한 복잡한 작업이며, 조직에서 이러한 전문 지식을 상태 비저장 워크로드에만 활용하고자 하는 것은 합리적입니다. 그러나 Kubernetes에서 MySQL을 실행해야 하는 좋은 이유와 그렇지 않은 이유가 있습니다. 여기서는 Kubernetes에서 MySQL을 실행하는 것과 관련된 몇 가지 FUD(두려움, 불확실성, 의심)를 설명해 보겠습니다.

Kubernetes로 리소스 프로비저닝하기

Kubernetes가 최고의 기술 인기를 누리기 전에는 많은 기업이 가상 머신과 베어메탈 서버를 프로비저닝하고 관리하기 위해 완전히 맞춤형 기술 스택을 구축하거나 리소스 수명 주기의 작은 부분을 수행하는 오픈 소스 프로젝트를 함께 붙였습니다. 그러다가 컴퓨팅과 스토리지 리소스를 모두 관리할 수 있는 보다 완벽한 에코시스템으로 Kubernetes가 등장했고, 이를 프로비저닝 스택으로 사용하여 이 모든 것을 관리할 수 있다는 전망이 점점 더 매력적으로 다가왔습니다. 그러나 "컨테이너에서는 데이터베이스를 실행할 수 없다"는 통념 때문에 MySQL과 같은 스테이트풀 로드는 그 부가가치에서 제외되어 뒤처져 있었습니다.

신중한 목표 범위 설정

명심해야 할 중요한 점은 "여기서 어떤 구체적인 가치를 얻고자 하는가?"입니다. Kubernetes는 컴퓨팅 리소스의 탄력성과 효율성을 제공하기 때문에 상태 비저장 로딩에 강력합니다. 그러나 통합 프로비저닝 스택을 살펴볼 때는 "데이터베이스 리소스에 대한 시스템 프로비저닝 및 구성에만 Kubernetes를 사용하고자 한다"로 범위를 좁히는 것이 합리적입니다. 즉, Kubernetes로 프로비저닝할 데이터베이스 워크로드는 상태 비저장 워크로드와 별도로 관리되고, 다른 운영자 기술 세트가 필요하며, 컨테이너 장애를 다르게 처리할 것임을 미리 명확히 해야 합니다.

제어 평면 선택

현재 다양한 MySQL 운영자가 시중에 나와 있지만, 어떤 것이 가장 좋은지는 대부분 Kubernetes 관리 범위를 어떻게 결정하느냐에 따라 달라집니다. 프로비저닝, 장애 조치, 데이터베이스 연결 관리 등 모든 작업을 수행하는 운영자가 필요하시나요? 아니면 단순히 프로비저닝 스택으로 Kubernetes를 사용하고 데이터베이스가 서비스된 후에는 다른 수단을 사용해 관리하시겠습니까? 컨트롤 플레인에서 기대하는 것이 무엇인지 미리 결정해야 세부적인 운영상의 많은 부분을 결정할 수 있습니다.

세부 사항 ...