Postgres 화요일 5번: “PostgreSQL과 Kubernetes. CI/CD. 테스트 자동화"

작년 말에는 러시아 PostgreSQL 커뮤니티의 또 다른 생방송이 진행되었습니다. #Ru포스트그레스, 공동 창립자인 Nikolai Samokhvalov는 Flant 기술 이사인 Dmitry Stolyarov와 Kubernetes의 맥락에서 이 DBMS에 대해 이야기했습니다.

우리는 이 토론의 주요 부분에 대한 기록을 출판하고 있습니다. 커뮤니티 YouTube 채널 게시된 전체 동영상:

데이터베이스와 Kubernetes

NS: 오늘은 VACUUM과 CHECKPOINT에 대해서는 이야기하지 않겠습니다. 우리는 Kubernetes에 대해 이야기하고 싶습니다. 나는 당신이 다년간의 경험을 가지고 있다는 것을 알고 있습니다. 나는 당신의 비디오를 보았고 그 중 일부를 다시 보기도 했습니다... 요점으로 바로 넘어가겠습니다: 왜 K8s에서 Postgres나 MySQL이 필요한가요?

DS: 이 질문에 대한 명확한 대답은 없으며, 그럴 수도 없습니다. 그러나 일반적으로 이것은 단순성과 편의성... 잠재력입니다. 누구나 관리형 서비스를 원합니다.

NS: 어떻게 RDS, 집에서만요?

DS: 예: RDS처럼 어디서나 가능합니다.

NS: '어디든지'가 좋은 지적이에요. 대기업에서는 모든 것이 다른 장소에 있습니다. 그렇다면 대기업이라면 기성 솔루션을 사용하지 않는 이유는 무엇입니까? 예를 들어 Nutanix에는 자체 개발이 있고 다른 회사(VMware...)에는 동일한 "RDS, only home"이 있습니다.

DS: 하지만 우리는 특정 조건에서만 작동하는 별도의 구현에 대해 이야기하고 있습니다. 그리고 Kubernetes에 관해 이야기하고 있다면 매우 다양한 인프라(K8에 있을 수 있음)가 있습니다. 본질적으로 이는 클라우드에 대한 API의 표준입니다.

NS: 그것도 무료예요!

DS: 별로 중요하지 않습니다. 시장의 규모가 크지 않은 부문에서는 자유도가 중요합니다. 다른 게 중요한데... 아마 보고서를 기억하실 겁니다.”데이터베이스와 Kubernetes? "

NS예.

DS: 매우 모호하게 받아들여졌음을 깨달았습니다. 어떤 사람들은 내가 “얘들아, 모든 데이터베이스를 쿠버네티스에 넣자!”라고 말하는 것이라고 생각했고, 다른 사람들은 이것들이 모두 끔찍한 자전거라고 결정했습니다. 하지만 저는 완전히 다른 말을 하고 싶었습니다. “무슨 일이 일어나고 있는지, 어떤 문제가 있는지, 어떻게 해결할 수 있는지 살펴보세요. 지금 Kubernetes 데이터베이스를 사용해야 할까요? 생산? 글쎄요, 당신이 좋아하는 경우에만...특정 일을 하는 거죠. 하지만 개발자 입장에서는 추천한다고 말씀드릴 수 있습니다. 개발자에게는 환경 생성/삭제의 역동성이 매우 중요합니다.”

NS: 개발자란 프로덕션이 아닌 모든 환경을 의미하나요? 스테이징, QA…

DS: 성능 스탠드에 대해 이야기하고 있다면 요구 사항이 구체적이기 때문에 그렇지 않을 수도 있습니다. 스테이징을 위해 매우 큰 데이터베이스가 필요한 특별한 경우에 대해 이야기하고 있다면 아마도 그렇지 않을 것입니다... 이것이 정적이며 수명이 긴 환경이라면 K8s에 데이터베이스를 배치하면 어떤 이점이 있습니까?

NS: 없음. 그러나 정적 환경은 어디에서 볼 수 있습니까? 정적 환경은 내일이면 더 이상 사용되지 않게 됩니다.

DS: 스테이징은 정적일 수 있습니다. 우리에겐 고객이 있습니다...

NS: 네, 저도 있어요. 10TB 데이터베이스와 200GB 스테이징이 있다면 큰 문제입니다...

DS: 나한테 아주 멋진 케이스가 있어! 준비 단계에는 변경 사항이 적용되는 제품 데이터베이스가 있습니다. 그리고 "프로덕션 출시" 버튼이 있습니다. 이러한 변경 사항(델타)은 프로덕션 환경에 추가됩니다(단순히 API를 통해 동기화되는 것 같습니다). 이것은 매우 이국적인 옵션입니다.

NS: RDS나 심지어 Heroku에 있는 스타트업을 밸리에서 본 적이 있습니다. 이것은 2~3년 전의 이야기입니다. 그리고 그들은 노트북에 덤프를 다운로드합니다. 데이터베이스는 여전히 80GB에 불과하고 노트북에 공간이 있기 때문입니다. 그런 다음 모든 사람을 위해 추가 디스크를 구입하여 서로 다른 개발을 수행할 수 있는 3개의 데이터베이스를 갖습니다. 이런 일도 일어납니다. 나는 또한 그들이 prod를 스테이징에 복사하는 것을 두려워하지 않는다는 것을 알았습니다. 이는 회사에 따라 크게 달라집니다. 그러나 나는 또한 그들이 매우 두려워하고 종종 시간과 손이 충분하지 않다는 것을 보았습니다. 하지만 이 주제로 넘어가기 전에 Kubernetes에 대해 듣고 싶습니다. 아직 아무도 prod에 참여하지 않았다는 것을 올바르게 이해하고 있습니까?

DS: 우리는 프로덕션에 작은 데이터베이스를 가지고 있습니다. 우리는 복제본을 만들기에는 너무 게으른 수십 기가바이트의 중요하지 않은 서비스와 중요하지 않은 서비스에 대해 이야기하고 있습니다. 그리고 Kubernetes 아래에 일반 스토리지가 있는 경우에 한합니다. 이 데이터베이스는 조건에 따라 스토리지 시스템 위에 있는 VMware의 가상 머신에서 작동했습니다. 우리는 그것을 넣었다 PV 이제 기계에서 기계로 전송할 수 있습니다.

NS: 이 크기의 데이터베이스(최대 100GB)는 좋은 디스크와 좋은 네트워크에서 몇 분 안에 롤아웃할 수 있습니다. 그렇죠? 초당 1GB의 속도는 더 이상 이국적이지 않습니다.

DS: 예, 선형 작동에서는 문제가 되지 않습니다.

NS: 좋아요, prod에 대해서만 생각하면 됩니다. 그리고 비프로덕션 환경을 위해 Kubernetes를 고려하고 있다면 어떻게 해야 할까요? 잘란도에서 본 것 같은데 연산자를 수행, 크런치에서 제재, 다른 옵션이 있습니다. 그리고 거기에 온그레스 - 이분은 스페인에서 온 우리의 좋은 친구 Alvaro입니다. 그들이 하는 일은 본질적으로 단순한 것이 아닙니다. 연산자, 그리고 전체 분포(StackGres), Postgres 자체 외에도 백업, Envoy 프록시를 넣기로 결정했습니다.

DS: 무슨 특사요? Postgres 트래픽의 균형을 구체적으로 조정하시나요?

NS: 예. 즉, 그들은 Linux 배포판과 커널을 사용하면 일반 PostgreSQL이 커널이고 클라우드 친화적이고 Kubernetes에서 실행되는 배포판을 만들고 싶어한다고 봅니다. 그들은 구성 요소(백업 등)를 함께 모으고 제대로 작동하도록 디버깅합니다.

DS: 아주 멋지네요! 본질적으로 이것은 자신만의 관리형 Postgres를 생성하는 소프트웨어입니다.

NS: Linux 배포판에는 모든 하드웨어가 지원되도록 드라이버를 만드는 방법이라는 영원한 문제가 있습니다. 그리고 그들은 Kubernetes에서 작동할 것이라는 생각을 가지고 있습니다. 최근 Zalando 운영자가 AWS에 연결되는 것을 확인했는데 이는 더 이상 좋지 않습니다. 특정 인프라와 연결되어서는 안 됩니다. 그렇다면 요점은 무엇입니까?

DS: 잘란도가 어떤 상황에 처했는지는 정확히 모르겠지만, 쿠버네티스에서는 이제 일반적인 방법으로는 디스크 백업이 불가능하도록 스토리지가 만들어졌습니다. 최근 표준 - 최신 버전 CSI 사양 — 스냅샷을 가능하게 만들었으나 어디에 구현되어 있나요? 솔직히 아직은 모든 ​​게 너무 생생해요... AWS, GCE, Azure, vSphere 위에서 CSI를 사용해 보고 있는데 막상 사용을 시작하면 아직 준비가 안 된 걸 알 수 있습니다.

NS: 그렇기 때문에 때로는 인프라에 의존해야 할 때도 있습니다. 아직 초기 단계인 성장통인 것 같아요. 질문: K8에서 PgSQL을 사용해 보고 싶은 초보자에게 어떤 조언을 해주고 싶나요? 아마도 어떤 운영자일까요?

DS: 문제는 Postgres가 우리에게 3%라는 것입니다. 또한 Kubernetes에는 매우 다양한 소프트웨어 목록이 있으므로 모든 것을 나열하지는 않겠습니다. 예를 들어, 엘라스틱서치. 많은 운영자가 있습니다. 일부는 적극적으로 개발 중이고 다른 일부는 그렇지 않습니다. 우리는 이를 진지하게 받아들이기 위해 운영자가 갖춰야 할 사항에 대한 요구 사항을 스스로 작성했습니다. "Amazon의 조건에서 작업을 수행하는 연산자"가 아닌 Kubernetes 전용 연산자에서... 사실 우리는 상당히 광범위하게(= 거의 모든 클라이언트) 단일 연산자를 사용합니다. Redis용 (우리는 곧 그에 관한 기사를 게시할 예정입니다).

NS: 그리고 MySQL에도 해당되지 않나요? Percona는 현재 MySQL, MongoDB 및 Postgres에서 작업하고 있으므로 모든 데이터베이스, 모든 클라우드 공급자를 위한 일종의 범용 솔루션을 만들어야 한다는 것을 알고 있습니다.

DS: MySQL의 연산자를 살펴볼 시간이 없었습니다. 이것은 지금 우리의 주요 초점이 아닙니다. MySQL은 독립 실행형에서 잘 작동합니다. 데이터베이스만 시작할 수 있는데 왜 연산자를 사용합니까? Postrges를 사용하여 Docker 컨테이너를 시작할 수도 있고 간단한 방법으로 시작할 수도 있습니다.

NS: 이에 대한 질문도 있었습니다. 운영자가 전혀 없나요?

DS: 네, 우리 중 100%는 연산자 없이 PostgreSQL을 실행하고 있습니다. 지금까지. 우리는 Prometheus 및 Redis에 연산자를 적극적으로 사용합니다. 우리는 Elasticsearch를 위한 운영자를 찾을 계획이 있습니다. 우리는 100% 경우에 Kubernetes에 설치하기를 원하기 때문에 가장 "불타오르는" 운영자입니다. MongoDB도 항상 Kubernetes에 설치되도록 하려는 것과 마찬가지입니다. 여기에는 특정 소원이 나타납니다. 이 경우 뭔가를 할 수 있다는 느낌이 있습니다. 그리고 우리는 Postgres도 보지 않았습니다. 물론 우리는 다양한 옵션이 있다는 것을 알고 있지만 실제로는 독립형 옵션도 있습니다.

Kubernetes에서 테스트용 DB

NS: 테스트 주제로 넘어 갑시다. DevOps 관점에서 데이터베이스에 변경 사항을 적용하는 방법. 마이크로서비스, 많은 데이터베이스가 있으며 항상 어딘가에서 무언가가 변화하고 있습니다. DBMS 관점에서 모든 것이 정돈되도록 정상적인 CI/CD를 보장하는 방법. 당신의 접근 방식은 무엇입니까?

DS: 답은 하나일 수 없습니다. 몇 가지 옵션이 있습니다. 첫 번째는 롤아웃하려는 베이스의 크기입니다. 당신은 기업들이 개발 및 단계에서 제품 데이터베이스 사본을 갖는 것에 대해 서로 다른 태도를 가지고 있다고 직접 언급했습니다.

NS: 그리고 GDPR의 조건 하에서 그들은 점점 더 조심하고 있는 것 같아요... 유럽에서는 이미 벌금을 부과하기 시작했다고 말할 수 있습니다.

DS: 그러나 종종 프로덕션에서 덤프를 가져와 난독화하는 소프트웨어를 작성할 수 있습니다. 프로덕션 데이터는 획득되지만(스냅샷, 덤프, 바이너리 복사본...) 익명으로 처리됩니다. 대신 생성 스크립트가 있을 수 있습니다. 이는 고정물일 수도 있고 대규모 데이터베이스를 생성하는 스크립트일 수도 있습니다. 문제는 기본 이미지를 생성하는 데 시간이 얼마나 걸리나요? 그리고 원하는 환경에 배포하는 데 시간이 얼마나 걸리나요?

우리는 클라이언트가 고정 데이터 세트(데이터베이스의 최소 버전)를 가지고 있다면 기본적으로 이를 사용한다는 계획을 세웠습니다. 검토 환경에 관해 이야기한다면 브랜치를 생성할 때 애플리케이션 인스턴스를 배포하고 거기에 작은 데이터베이스를 롤아웃합니다. 그런데 잘 나왔네요 вариант, 하루에 한 번(밤에) 프로덕션에서 덤프를 가져오고 이를 기반으로 로드된 데이터를 사용하여 PostgreSQL 및 MySQL로 Docker 컨테이너를 빌드합니다. 이 이미지에서 데이터베이스를 50배 확장해야 하는 경우 매우 간단하고 빠르게 수행됩니다.

NS: 단순 복사로?

DS: 데이터는 Docker 이미지에 직접 저장됩니다. 저것들. 비록 100GB이지만 기성 이미지가 있습니다. Docker의 레이어 덕분에 이 이미지를 필요한 만큼 빠르게 배포할 수 있습니다. 방법은 바보같지만 효과는 좋습니다.

NS: 그럼 테스트를 하면 Docker 내부에서 바로 바뀌죠? Docker 내부의 Copy-on-Write - 버리고 다시 사용하면 모든 것이 정상입니다. 수업! 그리고 당신은 이미 그것을 최대한 활용하고 있습니까?

DS: 오랫동안.

NS: 우리는 매우 유사한 일을 하고 있습니다. 우리는 Docker의 Copy-On-Write를 사용하지 않고 다른 것을 사용합니다.

DS: 일반적인 것은 아닙니다. Docker는 어디에서나 작동합니다.

NS: 이론적으로는 그렇습니다. 하지만 거기에는 모듈도 있으므로 다양한 모듈을 만들고 다양한 파일 시스템으로 작업할 수 있습니다. 정말 순간이군요. Postgres 측에서는 이 모든 것을 다르게 봅니다. 이제 Docker 측면에서 살펴보니 모든 것이 잘 작동하는 것으로 나타났습니다. 그러나 데이터베이스가 1TB와 같이 크다면 이 모든 작업에 오랜 시간이 걸립니다. 밤에 작업하고 모든 것을 Docker에 채우는 작업... 그리고 5TB를 Docker에 채우는 경우... 아니면 모든 것이 괜찮습니까?

DS: 차이점은 무엇입니까? 이것은 단지 비트와 바이트일 뿐인 얼룩입니다.

NS: 차이점은 다음과 같습니다. 덤프 및 복원을 통해 수행합니까?

DS: 전혀 필요하지 않습니다. 이 이미지를 생성하는 방법은 다를 수 있습니다.

NS: 일부 클라이언트의 경우 기본 이미지를 정기적으로 생성하지 않고 지속적으로 최신 상태로 유지하도록 만들었습니다. 본질적으로 복제본이지만 마스터로부터 직접 데이터를 받지 않고 아카이브를 통해 데이터를 받습니다. WAL이 매일 다운로드되고 백업이 수행되는 바이너리 아카이브... 이러한 WAL은 약간의 지연(문자 그대로 1-2초) 후에 기본 이미지에 도달합니다. 어떤 방식으로든 복제합니다. 이제 기본적으로 ZFS가 있습니다.

DS: 그러나 ZFS에서는 하나의 노드로 제한됩니다.

NS: 예. 하지만 ZFS에는 마법 같은 기능도 있습니다. 보내다: 이를 사용하면 스냅샷을 보낼 수 있고 심지어 (아직 실제로 테스트하지는 않았지만...) 둘 사이에 델타를 보낼 수도 있습니다. PGDATA. 실제로 이러한 작업을 위해 실제로 고려하지 않은 또 다른 도구가 있습니다. PostgreSQL에는 pg_rewind, "스마트" rsync처럼 작동하며, 아무것도 변경되지 않았기 때문에 시청할 필요가 없는 많은 항목을 건너뜁니다. 두 서버 간에 빠른 동기화를 수행하고 동일한 방식으로 되감을 수 있습니다.

따라서 더 많은 DBA 측면에서 우리는 귀하가 말한 것과 동일한 작업을 수행할 수 있는 도구를 만들려고 노력하고 있습니다. 데이터베이스는 하나이지만 거의 동시에 50번 테스트하려고 합니다.

DS: 50번은 스팟 인스턴스 50개를 주문해야 함을 의미합니다.

NS: 아니요, 우리는 하나의 기계에서 모든 작업을 수행합니다.

DS: 그런데 이 데이터베이스 하나가 가령 테라바이트라면 어떻게 50배로 확장할 수 있을까요? 조건부 256GB RAM이 필요할 가능성이 가장 높습니까?

NS: 예, 때로는 많은 메모리가 필요할 때도 있습니다. 이는 정상입니다. 그러나 이것은 삶의 예입니다. 생산 머신에는 96개의 코어와 600GB가 있습니다. 동시에 데이터베이스에는 32개 코어(현재는 16개 코어도 있음)와 100-120GB의 메모리가 사용됩니다.

DS: 그리고 거기에 50장이 들어가나요?

NS: 그럼 복사본이 하나만 있으면 ZFS(Copy-On-Write)가 작동하는군요... 자세히 말씀드리겠습니다.

예를 들어 10TB 데이터베이스가 있습니다. 그들은 이를 위한 디스크를 만들었고 ZFS도 크기를 30-40% 줄였습니다. 우리는 로드 테스트를 하지 않기 때문에 정확한 응답 시간은 중요하지 않습니다. 최대 2배 정도 느리게 놔두어도 괜찮습니다.

프로그래머, QA, DBA 등에게 기회를 제공합니다. 1~2개의 스레드에서 테스트를 수행합니다. 예를 들어 일종의 마이그레이션을 실행할 수 있습니다. 한 번에 10개의 코어가 필요하지 않습니다. 1개의 Postgres 백엔드, 1개의 코어가 필요합니다. 마이그레이션이 시작됩니다. 아마도 자동 진공화 계속 시작되면 두 번째 코어가 사용됩니다. 16~32개의 코어가 할당되어 있으므로 10명이 동시에 작업할 수 있습니다. 문제 없습니다.

왜냐면 육체적으로 PGDATA 마찬가지로 우리는 실제로 Postgres를 속이고 있다는 것이 밝혀졌습니다. 비결은 다음과 같습니다. 예를 들어 10개의 Postgres가 동시에 시작됩니다. 보통 무슨 문제가 있나요? 그들은 넣어 공유 버퍼, 25%라고 가정해 보겠습니다. 따라서 이것은 200GB입니다. 메모리가 부족해지기 때문에 이 중 XNUMX개 이상을 실행할 수 없습니다.

그러나 어느 시점에서 우리는 이것이 필요하지 않다는 것을 깨달았습니다. ​​shared_buffers를 2GB로 설정했습니다. PostgreSQL에는 효과적인 _ 캐시 _ 크기, 실제로는 영향을 미치는 유일한 것입니다. 계획. 0,5TB로 설정했습니다. 그리고 그것이 실제로 존재하지 않는 것도 중요하지 않습니다. 그는 마치 그것이 존재하는 것처럼 계획을 세웁니다.

따라서 일종의 마이그레이션을 테스트할 때 모든 계획을 수집할 수 있으며 프로덕션에서 어떻게 진행되는지 살펴보겠습니다. 초는 다르지만(느리게) 실제로 읽은 데이터와 계획 자체(JOIN이 무엇인지 등)는 프로덕션 환경과 정확히 동일합니다. 그리고 하나의 시스템에서 이러한 여러 검사를 병렬로 실행할 수 있습니다.

DS: 여기에 몇 가지 문제가 있다고 생각하지 않나요? 첫 번째는 PostgreSQL에서만 작동하는 솔루션입니다. 이 접근 방식은 매우 개인적이며 일반적이지 않습니다. 두 번째는 Kubernetes(및 현재 클라우드 기술에 적용되는 모든 것)에는 많은 노드가 포함되며 이러한 노드는 일시적이라는 것입니다. 귀하의 경우 이는 상태를 저장하는 영구 노드입니다. 이런 것들이 나를 갈등하게 만든다.

NS: 첫째, 이것은 순전히 Postgres 이야기라는 점에 동의합니다. 내 생각에 우리가 거의 모든 메모리에 대한 일종의 직접 IO와 버퍼 풀을 갖고 있다면 이 접근 방식은 작동하지 않을 것입니다. 계획은 달라질 것입니다. 하지만 지금은 Postgres로만 작업하고 다른 것에 대해서는 생각하지 않습니다.

쿠버네티스에 대하여. 당신은 우리가 영구 데이터베이스를 가지고 있다고 모든 곳에서 우리에게 말했습니다. 인스턴스가 실패하면 가장 중요한 것은 디스크를 저장하는 것입니다. 여기에는 Kubernetes의 전체 플랫폼도 있으며 Postgres가 포함된 구성 요소는 별도입니다(언젠가는 있을 예정임). 따라서 모든 것이 다음과 같습니다. 인스턴스가 떨어졌지만 PV를 저장하고 아무 일도 없었던 것처럼 다른 (새) 인스턴스에 연결했습니다.

DS: 내 관점에서는 Kubernetes에서 Pod를 생성합니다. K8s - 탄성: 매듭은 필요에 따라 주문됩니다. 임무는 단순히 포드를 생성하고 X만큼의 리소스가 필요하다고 말하면 K8이 스스로 알아내는 것입니다. 그러나 Kubernetes의 스토리지 지원은 여전히 ​​불안정합니다. 1.16에 1.17 (이 릴리스가 출시되었습니다. недели 이전) 이러한 기능은 베타로만 제공됩니다.

XNUMX개월에서 XNUMX년이 지나면 다소 안정되거나 적어도 그렇게 선언될 것입니다. 그런 다음 스냅샷 및 크기 조정 기능을 사용하면 문제가 완전히 해결됩니다. 기반이 있기 때문이죠. 예, 매우 빠르지는 않을 수 있지만 속도는 "내부"에 따라 달라집니다. 일부 구현에서는 디스크 하위 시스템 수준에서 복사 및 쓰기 시 복사가 가능하기 때문입니다.

NS: 이 버전을 지원하려면 모든 엔진(Amazon, Google...)이 필요합니다. 이 역시 시간이 걸립니다.

DS: 아직은 사용하지 않습니다. 우리는 우리 것을 사용합니다.

Kubernetes를 위한 로컬 개발

NS: 한 머신에 모든 포드를 설치하고 이렇게 작은 테스트를 수행해야 할 때 그런 희망 사항을 발견하셨나요? 개념 증명을 신속하게 얻으려면 많은 머신을 전용으로 사용하지 않고도 애플리케이션이 Kubernetes에서 실행되는지 확인하세요. Minikube가 있죠?

DS: 한 노드에 배포된 이 사례는 전적으로 로컬 개발에 관한 것 같습니다. 또는 그러한 패턴의 일부 표현. 먹다 미니쿠베그곳에 k3s, 종류. 우리는 Kubernetes IN Docker를 사용하는 방향으로 나아가고 있습니다. 이제 우리는 테스트를 위해 작업을 시작했습니다.

NS: 저는 이것이 모든 Pod를 하나의 Docker 이미지로 포장하려는 시도라고 생각했습니다. 그러나 이것은 완전히 다른 것에 관한 것으로 밝혀졌습니다. 어쨌든 Docker에는 별도의 컨테이너, 별도의 포드가 있습니다.

DS: 예. 그리고 다소 우스꽝스러운 모방이 만들어졌는데 그 의미는 이렇습니다... 우리는 배포를 위한 유틸리티를 가지고 있습니다 - 워프. 조건부 모드로 만들고 싶습니다. werf up: "로컬 Kubernetes를 가져오세요." 그런 다음 거기에서 조건문을 실행하십시오. werf follow. 그런 다음 개발자는 IDE를 편집할 수 있으며 변경 사항을 확인하고 이미지를 다시 빌드하여 로컬 K8에 재배포하는 프로세스가 시스템에서 시작됩니다. 이것이 우리가 지역 발전 문제를 해결하려고 노력하는 방법입니다.

K8s 현실의 스냅샷 및 데이터베이스 복제

NS: 기록 중 복사로 돌아가는 경우. 나는 구름에도 스냅샷이 있다는 것을 알아차렸습니다. 그들은 다르게 작동합니다. 예를 들어 GCP에는 미국 동부 해안에 수 테라바이트 규모의 인스턴스가 있습니다. 정기적으로 스냅샷을 찍습니다. 스냅샷에서 서해안의 디스크 복사본을 선택합니다. 몇 분 안에 모든 것이 준비되고 매우 빠르게 작동하며 캐시만 메모리에 채워지면 됩니다. 그러나 이러한 클론(스냅샷)은 새 볼륨을 '프로비저닝'하기 위한 것입니다. 많은 인스턴스를 생성해야 할 때 유용합니다.

그러나 테스트를 위해 Docker에서 이야기하거나 ZFS, btrfs, 심지어 LVM에서 이야기하는 스냅샷을 사용하면 하나의 시스템에서 실제로 새로운 데이터를 생성할 수 없는 것 같습니다. 클라우드에서는 매번 비용을 지불하고 몇 초가 아닌 몇 분만 기다리게 됩니다. 게으른 로드, 아마도 시계).

대신, 이 데이터를 XNUMX~XNUMX초 안에 가져와서 테스트를 실행하고 버릴 수 있습니다. 이러한 스냅샷은 다양한 문제를 해결합니다. 첫 번째 경우에는 확장하여 새 복제본을 얻고 두 번째 경우에는 테스트용입니다.

DS: 동의하지 않습니다. 볼륨 복제가 제대로 작동하도록 만드는 것은 클라우드의 작업입니다. 구현을 살펴보진 않았지만 하드웨어에서 어떻게 구현하는지 알고 있습니다. Ceph가 있는데, 이는 모든 물리적 볼륨(RBD) 말하다 복제 수십 밀리초 안에 동일한 특성을 가진 두 번째 볼륨을 얻습니다. IOPS'아미 등등 내부에 까다로운 Copy-On-Write가 있다는 것을 이해해야 합니다. 클라우드도 같은 일을 하면 안 되는 이유는 무엇입니까? 나는 그들이 어떤 식으로든 이것을 하려고 노력하고 있다고 확신합니다.

NS: 하지만 인스턴스를 발생시키고 Docker를 가져오는 데는 여전히 몇 초, 수십 초가 걸립니다.

DS: 전체 인스턴스를 키워야 하는 이유는 무엇입니까? 우리는 32개의 코어, 16개...를 가진 인스턴스를 가지고 있으며 여기에 들어갈 수 있습니다(예: XNUMX개). 다섯 번째를 주문하면 인스턴스가 이미 생성된 후 삭제됩니다.

NS: 네, 흥미롭습니다. Kubernetes는 다른 이야기로 밝혀졌습니다. 우리 데이터베이스는 K8s에 없으며 인스턴스가 하나 있습니다. 그러나 멀티테라바이트 규모의 데이터베이스를 복제하는 데는 XNUMX초도 걸리지 않습니다.

DS: 정말 좋아요. 그러나 나의 초기 요점은 이것이 일반적인 솔루션이 아니라는 것입니다. 예, 좋습니다. 하지만 Postgres와 하나의 노드에만 적합합니다.

NS: 이것은 Postgres에만 적합한 것이 아닙니다. 제가 설명한 대로 이 계획은 Postgres에서만 작동합니다. 하지만 계획에 신경 쓰지 않고 기능 테스트를 위한 모든 데이터만 필요하다면 이는 모든 DBMS에 적합합니다.

DS: 몇 년 전에 우리는 LVM 스냅샷에서 비슷한 작업을 수행했습니다. 이것은 고전입니다. 이 접근 방식은 매우 적극적으로 사용되었습니다. 상태 저장 노드는 고통스러울 뿐입니다. 떨어뜨리면 안 되니까 늘 기억해야지...

NS: 여기서 하이브리드의 가능성이 있다고 보시나요? 상태 저장이 일종의 포드라고 가정해 보겠습니다. 이는 여러 사람(많은 테스터)에게 작동합니다. 볼륨은 하나이지만 파일 시스템 덕분에 복제본은 로컬입니다. 포드가 떨어졌지만 디스크는 남아 있으면 포드가 올라가서 모든 클론에 대한 정보를 계산하고 모든 것을 다시 집어 들고 다음과 같이 말합니다. "여기 이 포트에서 실행 중인 클론이 있습니다. 계속 작업하세요."

DS: 기술적으로 이것은 Kubernetes 내에서 많은 Postgres를 실행하는 하나의 포드라는 것을 의미합니다.

NS: 예. 그에게는 한계가 있습니다. 동시에 그와 함께 일할 수 있는 사람은 10명 이하라고 가정해 보겠습니다. 20개가 필요한 경우 두 번째 포드를 출시하겠습니다. 두 번째 전체 볼륨을 수신하면 이를 완전히 복제할 것이며 동일한 10개의 "씬" 클론을 갖게 됩니다. 이런 기회가 보이지 않나요?

DS: 여기에 보안 문제를 추가해야 합니다. 이러한 유형의 조직은 이 포드가 파일 시스템에서 비표준 작업을 수행할 수 있기 때문에 높은 권한(기능)을 가지고 있음을 의미합니다... 하지만 반복합니다. 중기적으로는 그들이 Kubernetes의 스토리지를 고칠 것이라고 믿습니다. 구름은 전체 이야기를 볼륨으로 고칠 것입니다. 모든 것이 "그냥 작동"할 것입니다. 크기 조정, 복제... 볼륨이 있습니다. "이를 기반으로 새 볼륨을 만듭니다."라고 말하고 XNUMX초 반 후에 필요한 것을 얻습니다.

NS: 나는 수 테라바이트에 대해 2초라는 것을 믿지 않습니다. Ceph에서는 직접 수행하지만 클라우드에 대해 이야기합니다. 클라우드로 이동하여 ECXNUMX에서 멀티 테라바이트 EBS 볼륨의 복제본을 만들고 성능이 어떤지 확인하세요. 몇 초도 걸리지 않습니다. 언제 이 수준에 도달할지 매우 궁금합니다. 나는 당신이 말하는 것을 이해합니다. 그러나 나는 다르게 간청합니다.

DS: 네, 그런데 단기가 아니라 중기라고 말씀드렸는데요. 몇 년 동안.

Zalando의 PostgreSQL 연산자 정보

이 회의 중간에 Zalando의 전 개발자인 Alexey Klyukin도 합류하여 PostgreSQL 운영자의 역사에 대해 이야기했습니다.

Postgres와 Kubernetes 모두에서 이 주제를 전반적으로 다룬다는 것은 좋은 일입니다. 2017년 Zalando에서 이 작업을 시작했을 때 모두가 하고 싶어하는 주제였지만 아무도 하지 않았습니다. 누구나 이미 Kubernetes를 갖고 있지만 데이터베이스로 무엇을 해야 하는지 물으면 다음과 같은 사람들도 마찬가지입니다. 켈시 하이타워K8s를 설교한 분은 이렇게 말씀하셨습니다.

“관리형 서비스로 이동하여 사용하세요. Kubernetes에서 데이터베이스를 실행하지 마세요. 그렇지 않으면 예를 들어 K8이 업그레이드를 결정하고 모든 노드를 끄면 데이터가 아주 멀리 날아갈 것입니다.”

우리는 이 조언과는 반대로 Kubernetes에서 Postgres 데이터베이스를 시작할 운영자를 만들기로 결정했습니다. 그리고 우리에게는 그럴만한 이유가 있었습니다 - 패트로니. 이는 PostgreSQL에 대한 자동 장애 조치이며 올바르게 수행됩니다. etcd, consul 또는 ZooKeeper를 클러스터에 대한 정보 저장소로 사용합니다. 예를 들어, 현재 리더가 누구인지 묻는 모든 사람에게 동일한 정보를 제공하는 저장소는 모든 것이 분산되어 있음에도 불구하고 분할된 두뇌가 없도록 합니다. 게다가 우리는 도커 이미지 그를 위해.

일반적으로 회사의 자동 장애 조치(failover)에 대한 필요성은 내부 하드웨어 데이터 센터에서 클라우드로 마이그레이션한 후에 나타났습니다. 클라우드는 독점적인 PaaS(Platform-as-a-Service) 솔루션을 기반으로 했습니다. 오픈 소스이지만 이를 시작하고 실행하는 데 많은 작업이 필요했습니다. 그것은 불렸다 스텁.

처음에는 Kubernetes가 없었습니다. 더 정확히 말하면, 자체 솔루션을 도입할 당시 K8은 이미 존재했지만, 너무 조잡해서 생산에 적합하지 않았습니다. 내 생각엔 2015년인가 2016년이었던 것 같다. 2017년까지 Kubernetes는 다소 성숙해졌으며 그곳으로 마이그레이션할 필요가 있었습니다.

그리고 우리는 이미 Docker 컨테이너를 갖고 있었습니다. Docker를 사용한 PaaS가 있었습니다. K8을 시험해 보는 것은 어떨까요? 자신만의 연산자를 작성해 보는 것은 어떨까요? Avito에서 우리에게 온 Murat Kabilov는 자신의 주도로 "놀이"라는 프로젝트로 이것을 시작했고 프로젝트는 "시작되었습니다."

하지만 전반적으로 AWS에 대해 이야기하고 싶었습니다. 과거 AWS 관련 코드가 있었던 이유는...

Kubernetes에서 무언가를 실행할 때 K8s가 진행 중인 작업이라는 점을 이해해야 합니다. 끊임없이 발전하고, 개선되고, 때로는 무너지기까지 합니다. Kubernetes의 모든 변경 사항을 면밀히 관찰해야 하며, 어떤 일이 발생하면 이를 자세히 살펴보고 그것이 어떻게 작동하는지 자세히 배울 준비가 되어 있어야 합니다. 어쩌면 원하는 것 이상일 수도 있습니다. 이는 원칙적으로 데이터베이스를 실행하는 모든 플랫폼에 적용됩니다.

따라서 우리가 성명서를 작성했을 때 Postgres는 외부 볼륨(이 경우 AWS에서 작업 중이었기 때문에 EBS)에서 실행 중이었습니다. 데이터베이스가 커져서 어떤 시점에서는 크기를 조정해야 했습니다. 예를 들어 EBS의 초기 크기는 100TB였고, 데이터베이스도 그 정도로 늘어났습니다. 이제 EBS를 200TB로 만들고 싶습니다. 어떻게? 새 인스턴스에서 덤프/복원을 수행할 수 있지만 시간이 오래 걸리고 가동 중지 시간이 발생한다고 가정해 보겠습니다.

따라서 저는 EBS 파티션을 확대한 다음 파일 시스템에 새 공간을 사용하도록 지시하는 크기 조정을 원했습니다. 우리는 그렇게 했지만 당시 Kubernetes에는 크기 조정 작업을 위한 API가 없었습니다. 우리는 AWS에서 일한 이후로 API용 코드를 작성했습니다.

다른 플랫폼에서도 동일한 작업을 수행하는 것을 아무도 막을 수 없습니다. 설명에는 AWS에서만 실행할 수 있으며 다른 모든 것에서는 작동하지 않는다는 힌트가 없습니다. 일반적으로 이것은 오픈 소스 프로젝트입니다. 누구든지 새로운 API 사용의 출현 속도를 높이고 싶다면 환영합니다. 먹다 GitHub의, 끌어오기 요청 - Zalando 팀은 매우 신속하게 이에 응답하고 운영자를 승격시키려고 노력합니다. 내가 아는 한, 그 프로젝트는 참여한 Google Summer of Code 및 기타 유사한 이니셔티브에서. Zalando는 이에 대해 매우 적극적으로 노력하고 있습니다.

PS 보너스!

PostgreSQL과 Kubernetes 주제에 관심이 있으시다면 다음 Postgres 화요일이 지난주에 열렸으며 제가 Nikolai와 이야기를 나눴다는 점도 참고하시기 바랍니다. Zalando의 Alexander Kukushkin. 해당 동영상을 볼 수 있습니다. 여기에.

PPS

블로그에서도 읽어보세요.

• «데이터베이스 및 Kubernetes(개요 및 동영상 보고서)";
• «Cassandra를 Kubernetes로 마이그레이션: 기능 및 솔루션";
• «MongoDB를 Kubernetes로 원활하게 마이그레이션";
• «RabbitMQ를 Kubernetes로 원활하게 마이그레이션".

출처 : habr.com