데이터베이스가 Kubernetes에 있습니까?

어찌됐든 역사적으로 IT 산업은 어떤 이유로든 '찬성'과 '반대'라는 두 개의 조건부 진영으로 나누어졌습니다. 더욱이 분쟁의 대상은 완전히 임의적일 수 있습니다. 어느 OS가 더 낫습니까? Win 또는 Linux? Android 또는 iOS 스마트폰을 사용하시나요? 모든 것을 클라우드에 저장해야 할까요, 아니면 콜드 RAID 스토리지에 넣고 나사를 금고에 넣어야 할까요? PHP 사람들은 프로그래머라고 불릴 권리가 있나요? 이러한 분쟁은 때때로 본질적으로 전적으로 실존적이며 스포츠적 이익 외에는 근거가 없습니다.

컨테이너와 docker 및 조건부 k8을 사용한 이 모든 인기 있는 요리가 등장하면서 백엔드의 다양한 영역에서 새로운 기능을 사용하는 것에 대한 "찬성"과 "반대" 논쟁이 시작되었습니다. (이 토론에서는 Kubernetes가 오케스트레이터로 가장 자주 표시되지만 이 특정 도구의 선택은 근본적으로 중요하지 않다는 점을 미리 예약해 두십시오. 대신 가장 편리하고 친숙해 보이는 다른 도구로 대체할 수 있습니다. .)

그리고 이것은 동전의 양면 사이의 단순한 분쟁인 것처럼 보입니다. 적절한 사람이 중간 어딘가에 존재하는 Win과 Linux의 영원한 대결만큼 무의미하고 무자비합니다. 그러나 컨테이너화의 경우 모든 것이 그렇게 간단하지는 않습니다. 일반적으로 이러한 분쟁에는 권리가 없지만 데이터베이스 저장을 위해 컨테이너를 "사용"하거나 "사용하지 않음"의 경우 모든 것이 뒤집어집니다. 어떤 의미에서는 이 접근법을 지지하는 사람과 반대하는 사람 모두 옳기 때문입니다.

밝은 면

라이트사이드의 주장은 “안녕하세요, 2k19가 창 밖에 있습니다!”라는 한 문장으로 간략하게 설명할 수 있습니다. 물론 포퓰리즘처럼 들리지만, 상황을 자세히 살펴보면 장점이 있다. 이제 정리해보자.

대규모 웹 프로젝트가 있다고 가정해 보겠습니다. 처음에는 마이크로서비스 접근 방식을 기반으로 구축되었을 수도 있고 어느 시점에서는 진화적인 경로를 통해 구현되었을 수도 있습니다. 사실 이는 그다지 중요하지 않습니다. 프로젝트를 별도의 마이크로서비스로 분산하고 오케스트레이션, 로드 밸런싱 및 확장을 설정했습니다. 그리고 이제 깨끗한 양심으로 하브라 효과 동안 쓰러진 서버를 키우는 대신 해먹에서 모히토를 홀짝입니다. 하지만 모든 행동에는 일관성이 있어야 합니다. 애플리케이션 자체(코드)만 컨테이너화되는 경우가 많습니다. 코드 외에 또 무엇이 있나요?

그렇죠, 데이터. 모든 프로젝트의 핵심은 데이터입니다. 이는 일반적인 DBMS(MySQL, Postgre, MongoDB)이거나 검색에 사용되는 저장소(ElasticSearch), 캐싱을 위한 키-값 저장소(예: Redis 등)일 수 있습니다. 잘못 작성된 쿼리로 인해 데이터베이스가 충돌할 때 비뚤어진 백엔드 구현 옵션에 대해 이야기하고 대신 클라이언트 로드 하에서 바로 이 데이터베이스의 내결함성을 보장하는 방법에 대해 이야기하겠습니다. 결국, 애플리케이션을 컨테이너화하고 들어오는 요청 수에 관계없이 자유롭게 확장할 수 있도록 허용하면 자연스럽게 데이터베이스의 로드가 증가합니다.

실제로 데이터베이스에 액세스하기 위한 채널과 데이터베이스가 실행되는 서버는 컨테이너화된 아름다운 백엔드의 핵심이 됩니다. 동시에, 컨테이너 가상화의 주요 동기는 구조의 이동성과 유연성입니다. 이를 통해 우리는 가능한 한 효율적으로 전체 인프라에 걸쳐 최대 부하 분산을 구성할 수 있습니다. 즉, 시스템의 모든 기존 요소를 클러스터 전체에 컨테이너화하고 롤아웃하지 않으면 매우 심각한 실수를 저지르는 것입니다.

애플리케이션 자체뿐만 아니라 데이터 저장을 담당하는 서비스도 클러스터링하는 것이 훨씬 더 논리적입니다. k8s에서 독립적으로 작동하고 부하를 분산시키는 웹 서버를 클러스터링 및 배포함으로써 우리는 이미 데이터 동기화 문제를 해결하고 있습니다. 일부 미디어나 블로그 플랫폼을 예로 들면 게시물에 대한 동일한 댓글입니다. 어떤 경우든 우리는 클러스터 내, 심지어는 가상의 데이터베이스 표현을 외부 서비스로 갖고 있습니다. 문제는 데이터베이스 자체가 아직 클러스터되지 않았다는 것입니다. 큐브에 배포된 웹 서버는 별도로 회전하는 정적 전투 데이터베이스에서 변경 사항에 대한 정보를 가져옵니다.

뭔가 걸리는 느낌이 드나요? 우리는 로드를 분산하고 기본 웹 서버 충돌을 방지하기 위해 k8s 또는 Swarm을 사용하지만 데이터베이스에 대해서는 이 작업을 수행하지 않습니다. 그러나 데이터베이스가 충돌하면 전체 클러스터 인프라가 의미가 없습니다. 데이터베이스 액세스 오류를 반환하는 빈 웹 페이지가 무슨 소용이 있습니까?

그렇기 때문에 일반적으로 수행되는 웹 서버뿐만 아니라 데이터베이스 인프라도 클러스터링해야 합니다. 이런 방식으로만 우리는 한 팀에서 완벽하게 작동하면서도 동시에 서로 독립적인 구조를 보장할 수 있습니다. 더욱이, 백엔드의 절반이 로드 중에 "붕괴"되더라도 나머지는 살아남을 것이며, 클러스터 내에서 데이터베이스를 서로 동기화하는 시스템과 새로운 클러스터를 끝없이 확장하고 배포하는 기능은 필요한 용량에 빠르게 도달하는 데 도움이 될 것입니다. 데이터 센터에 랙만 있었다면 말이죠.

또한 클러스터에 분산된 데이터베이스 모델을 사용하면 바로 이 데이터베이스를 필요한 곳으로 가져갈 수 있습니다. 글로벌 서비스에 관해 이야기하고 있다면 샌프란시스코 지역 어딘가에 웹 클러스터를 가동하고 동시에 모스크바 지역의 데이터베이스에 액세스할 때 패킷을 보내는 것은 매우 비논리적입니다.

또한 데이터베이스 컨테이너화를 통해 동일한 추상화 수준에서 시스템의 모든 요소를 ​​구축할 수 있습니다. 결과적으로 관리자의 적극적인 개입 없이 개발자가 코드에서 직접 이 시스템을 관리할 수 있습니다. 개발자들은 새로운 하위 프로젝트를 위해 별도의 DBMS가 필요하다고 생각했습니다. 쉽습니다! yaml 파일을 작성하여 클러스터에 업로드하면 완료됩니다.

물론 내부 작업도 크게 단순화됩니다. 새로운 팀원이 업무를 위해 전투 데이터베이스에 손을 넣을 때 몇 번이나 눈을 감았습니까? 실제로 당신이 가지고 있고 지금 회전하고 있는 유일한 것은 무엇입니까? 물론, 우리는 모두 여기 있는 성인이고, 어딘가에 새로운 백업이 있고, 더 멀리 떨어진 곳에 할머니의 오이와 낡은 스키가 있는 선반 뒤에 또 다른 백업이 있습니다. 아마도 사무실에 이미 불이 났기 때문일 수도 있습니다. 그러나 그럼에도 불구하고 전투 인프라와 전투 데이터베이스에 액세스할 수 있는 새로운 팀원을 소개할 때마다 주변의 모든 사람을 위한 유효돌 양동이가 됩니다. 글쎄요, 초보자인 그를 아는 사람이 있을까요? 무섭습니다. 동의하실 겁니다.

컨테이너화와 실제로 프로젝트 데이터베이스의 분산된 물리적 토폴로지는 이러한 검증 순간을 피하는 데 도움이 됩니다. 초보자를 믿지 못하시나요? 좋아요! 그에게 작업할 자신의 클러스터를 제공하고 다른 클러스터에서 데이터베이스의 연결을 끊도록 하겠습니다. 수동 푸시로만 동기화하고 두 키(하나는 팀 리더용, 다른 하나는 관리자용)의 동기 순환을 수행합니다. 그리고 모두가 행복합니다.

이제 데이터베이스 클러스터링의 반대자로 변해야 할 때입니다.

어두운면

데이터베이스를 컨테이너화하고 하나의 중앙 서버에서 계속 실행할 가치가 없는 이유를 주장하면서 우리는 "할아버지가 하드웨어에서 데이터베이스를 실행했으니 우리도 그럴 것입니다!"와 같은 정통적인 수사에 굴복하지 않을 것입니다. 대신 컨테이너화가 실제로 실질적인 이익을 얻을 수 있는 상황을 생각해 보겠습니다.

컨테이너에 베이스가 꼭 필요한 프로젝트는 최고의 밀링 머신 작업자가 아니더라도 한 손에 꼽을 정도입니다. 대부분의 경우 k8s 또는 Docker Swarm 자체의 사용도 중복됩니다. 기술에 대한 일반적인 과대 광고와 성별에 따른 "전능자"의 태도로 인해 이러한 도구가 사용되는 경우가 많습니다. 클라우드와 컨테이너. 글쎄, 지금은 유행이고 모두가 그렇게하기 때문입니다.

최소한 절반 이상의 경우에는 프로젝트에서 Kubernetis 또는 Docker만 사용하는 것이 중복됩니다. 문제는 고객의 인프라를 유지하기 위해 고용된 모든 팀이나 아웃소싱 회사가 이를 인식하고 있지 않다는 것입니다. 컨테이너가 부과되면 클라이언트에게 일정 금액의 코인이 필요하기 때문에 상황은 더 나쁩니다.

일반적으로 도커/큐브 마피아가 이러한 인프라 문제를 아웃소싱하는 고객을 어리석게 짓밟고 있다는 의견이 있습니다. 결국 클러스터 작업을 수행하려면 이를 수행할 수 있고 구현된 솔루션의 아키텍처를 전반적으로 이해하는 엔지니어가 필요합니다. 우리는 이미 Republic 간행물을 통해 우리 사례를 설명한 적이 있습니다. 거기서 우리는 고객 팀이 Kubernetis의 현실에서 작업하도록 교육했고 모두가 만족했습니다. 그리고 그것은 괜찮았습니다. 종종 k8s "구현자"는 클라이언트의 인프라를 인질로 삼습니다. 이제 kXNUMXs "구현자"만이 모든 것이 어떻게 작동하는지 이해하고 클라이언트 측에는 전문가가 없기 때문입니다.

이제 이런 방식으로 웹 서버 부분뿐만 아니라 데이터베이스 유지 관리도 아웃소싱한다고 상상해 보세요. 우리는 BD가 심장이고 심장의 상실은 모든 생명체에게 치명적이라고 말했습니다. 간단히 말해서, 전망은 최고가 아닙니다. 따라서 Kubernetis를 과대평가하는 대신, 많은 프로젝트는 AWS에 대한 일반적인 요금에 신경쓰지 않아야 합니다. 그러면 사이트/프로젝트의 부하와 관련된 모든 문제가 해결될 것입니다. 그러나 AWS는 더 이상 유행하지 않으며 과시가 돈보다 더 가치가 있습니다. 불행하게도 IT 환경에서도 마찬가지입니다.

좋아요. 프로젝트에 실제로 클러스터링이 필요할 수도 있지만 상태 비저장 애플리케이션으로 모든 것이 명확하다면 클러스터된 데이터베이스에 대한 적절한 네트워크 연결을 어떻게 구성할 수 있습니까?

k8s로의 전환인 원활한 엔지니어링 솔루션에 대해 이야기하고 있다면 가장 큰 골칫거리는 클러스터형 데이터베이스의 데이터 복제입니다. 일부 DBMS는 처음에는 개별 인스턴스 간의 데이터 배포에 매우 충실합니다. 다른 많은 사람들은 그다지 환영받지 못합니다. 그리고 우리 프로젝트에 DBMS를 선택할 때 가장 중요한 이유는 최소한의 리소스와 엔지니어링 비용으로 복제할 수 있는 능력이 아니기 때문입니다. 특히 프로젝트가 처음에 마이크로서비스로 계획되지 않았지만 단순히 이 방향으로 발전한 경우에는 더욱 그렇습니다.

우리는 네트워크 드라이브의 속도에 대해 말할 필요가 없다고 생각합니다. 속도가 느립니다. 저것들. 어떤 일이 발생하더라도 프로세서 성능이나 여유 RAM 등 더 많은 곳에서 DBMS 인스턴스를 다시 시작할 수 있는 실제 기회는 아직 없습니다. 우리는 가상화된 디스크 하위 시스템의 성능을 매우 빠르게 살펴보겠습니다. 따라서 DBMS는 가까이에 위치한 자체 개인용 기계 세트에 고정되어야 합니다. 또는 예상 매장량에 대해 충분히 빠른 데이터 동기화를 별도로 냉각해야 합니다.

가상 파일 시스템에 대한 주제를 계속하자면, 불행하게도 Docker 볼륨에는 문제가 없습니다. 일반적으로 장기적으로 신뢰할 수 있는 데이터 저장과 같은 문제에서는 기술적으로 가장 간단한 방식을 사용하고 싶습니다. 그리고 컨테이너의 FS에서 상위 호스트의 FS로 새로운 추상화 계층을 추가하는 것 자체가 위험합니다. 그러나 컨테이너화 지원 시스템의 운영 시 이러한 계층 간 데이터 전송에 어려움을 겪게 되면 이는 정말 재앙이 됩니다. 현재 진보적인 인류에게 알려진 문제들은 대부분 근절된 것 같습니다. 그러나 메커니즘이 복잡할수록 파손되기 쉽다는 것을 이해합니다.

이러한 모든 "모험"을 고려하면 데이터베이스를 한 곳에 유지하는 것이 훨씬 더 수익성이 높고 쉽습니다. 애플리케이션을 컨테이너화해야 하는 경우에도 자체적으로 실행하고 배포 게이트웨이를 통해 한 곳에서 한 번만 읽고 쓸 수 있는 데이터베이스입니다. 이 접근 방식은 오류 및 비동기화 가능성을 최소한으로 줄여줍니다.

우리는 무엇을 이끌고 있습니까? 또한 데이터베이스 컨테이너화는 실제로 필요한 경우에 적합합니다. 전체 앱 데이터베이스를 채워서 마치 XNUMX개의 마이크로서비스가 있는 것처럼 회전시킬 수는 없습니다. 그런 식으로 작동하지 않습니다. 그리고 이것은 분명히 이해되어야 한다.

출력 대신

"데이터베이스를 가상화할지 여부"에 대한 명확한 결론을 기다리고 있다면 실망스러울 것입니다. 여기에는 없을 것입니다. 인프라 솔루션을 만들 때는 유행과 진보가 아닌 우선 상식을 따라야 하기 때문입니다.

Kubernetis와 함께 제공되는 원칙과 도구가 완벽하게 들어맞는 프로젝트가 있으며, 그러한 프로젝트에는 적어도 백엔드 영역에는 평화가 있습니다. 그리고 컨테이너화가 필요하지 않지만 일반 서버 인프라가 필요한 프로젝트도 있습니다. 왜냐하면 근본적으로 마이크로서비스 클러스터 모델로 재확장할 수 없기 때문입니다.

출처 : habr.com