21세기 SQL 데이터베이스에서 살아남는 방법: 클라우드, Kubernetes 및 PostgreSQL 멀티마스터

안녕하세요, 하브로프스크 주민 여러분. 오늘부터 첫 번째 그룹 수업이 시작됩니다 "포스트그레SQL". 이에 본 강좌의 공개 웨비나가 어떻게 진행되었는지 알려드리고자 합니다.

В 다음 공개 수업 우리는 클라우드와 Kubernetes 시대에 SQL 데이터베이스가 직면한 과제에 대해 이야기했습니다. 동시에 우리는 SQL 데이터베이스가 이러한 과제의 영향을 받아 어떻게 적응하고 변형되는지 살펴보았습니다.

웨비나가 개최되었습니다 발레리 베즈루코프, EPAM Systems의 Google Cloud Practice 제공 관리자입니다.

나무가 작았던 시절..

먼저 지난 세기말 DBMS의 선택이 어떻게 시작되었는지 기억해보자. 하지만 이는 당시 DBMS의 선택이 시작되고 끝났기 때문에 어렵지 않을 것이다. 신탁.

90년대 후반과 2년대 초반에는 산업용으로 확장 가능한 데이터베이스에 관해서는 본질적으로 선택의 여지가 없었습니다. 예, IBM DBXNUMX, Sybase 및 기타 데이터베이스가 왔다 갔다 했지만 일반적으로 Oracle의 배경에 비해 그다지 눈에 띄지 않았습니다. 따라서 당시 엔지니어의 기술은 존재하는 유일한 선택과 어떻게든 연결되어 있었습니다.

Oracle DBA는 다음을 수행할 수 있어야 했습니다.

• 배포 키트에서 Oracle Server를 설치합니다.
• Oracle 서버를 구성합니다.

• init.ora;
• 리스너.ora;

- 만들다:

• 테이블스페이스;
• 계획;
• 사용자;

— 백업 및 복원을 수행합니다.
- 모니터링을 수행한다.
— 최적이 아닌 요청을 처리합니다.

동시에 Oracle DBA에서는 특별한 요구 사항도 없었습니다.

• 데이터 저장 및 처리를 위한 최적의 DBMS 또는 기타 기술을 선택할 수 있습니다.
• 고가용성과 수평적 확장성을 제공합니다(항상 DBA 문제는 아니었습니다).
• 주제 영역, 인프라, 애플리케이션 아키텍처, OS에 대한 풍부한 지식
• 데이터 로드 및 언로드, 서로 다른 DBMS 간에 데이터 마이그레이션.

일반적으로 당시 선택에 대해 이야기하면 80년대 후반 소련 상점의 선택과 유사합니다.

우리 시대

물론 그 이후로 나무도 자라고, 세상도 바뀌었고, 다음과 같이 변했습니다.

Gartner의 최신 보고서에서 분명히 알 수 있듯이 DBMS 시장도 변화했습니다.

그리고 여기서 인기가 높아지고 있는 클라우드가 틈새 시장을 점유하고 있다는 점에 주목해야 합니다. 동일한 Gartner 보고서를 읽으면 다음과 같은 결론을 얻을 수 있습니다.

1. 많은 고객이 애플리케이션을 클라우드로 이동하는 과정에 있습니다.
2. 새로운 기술은 클라우드에 처음 등장하며, 이러한 기술이 클라우드가 아닌 인프라로 이동한다는 것은 사실이 아닙니다.
3. 종량제 가격 책정 모델이 일반화되었습니다. 모든 사람은 자신이 사용한 만큼만 비용을 지불하기를 원하며 이는 추세가 아니라 단순히 사실에 대한 설명입니다.

지금 뭐야?

오늘날 우리는 모두 클라우드에 있습니다. 그리고 우리에게 발생하는 질문은 선택의 질문입니다. 온프레미스 형식의 DBMS 기술 선택에 대해서만 이야기하더라도 그 규모는 엄청납니다. 또한 관리형 서비스와 SaaS도 있습니다. 따라서 선택은 매년 더욱 어려워집니다.

선택의 질문과 함께 제한 요인:

• 가격. 많은 기술에는 여전히 비용이 듭니다.
• 기술. 자유 소프트웨어에 관해 이야기한다면 기술에 대한 문제가 제기됩니다. 왜냐하면 자유 소프트웨어는 그것을 배포하고 운영하는 사람들의 충분한 역량을 요구하기 때문입니다.
• 기능의. 클라우드에서 사용 가능하고 동일한 Postgres에 구축된 모든 서비스가 Postgres On-Premise와 동일한 기능을 갖는 것은 아닙니다. 이는 반드시 알고 이해해야 할 필수 요소입니다. 더욱이 이 요소는 단일 DBMS의 일부 숨겨진 기능에 대한 지식보다 더 중요해집니다.

현재 DA/DE에서 기대되는 사항은 다음과 같습니다.

• 주제 영역과 애플리케이션 아키텍처에 대한 좋은 이해
• 현재 작업을 고려하여 적절한 DBMS 기술을 올바르게 선택하는 능력
• 기존 제한 사항의 맥락에서 선택한 기술을 구현하기 위한 최적의 방법을 선택하는 능력
• 데이터 전송 및 마이그레이션을 수행하는 능력;
• 선택된 솔루션을 구현하고 운영하는 능력.

아래 예 GCP 기반 데이터 작업을 위한 하나 또는 다른 기술의 선택이 구조에 따라 어떻게 작동하는지 보여줍니다.

PostgreSQL은 스키마에 포함되어 있지 않으며 이는 용어 아래에 숨겨져 있기 때문입니다. 클라우드 SQL. 그리고 Cloud SQL에 도달하면 다시 선택해야 합니다.

이 선택이 항상 명확한 것은 아니므로 애플리케이션 개발자는 종종 직관에 따라 안내된다는 점에 유의해야 합니다.

총계 :

1. 더 멀리 갈수록 선택의 문제는 더욱 시급해집니다. 그리고 GCP, 관리형 서비스, SaaS만 보더라도 RDBMS에 대한 언급은 4단계에서만 나타납니다(그리고 Spanner가 근처에 있습니다). 게다가 5단계에 PostgreSQL의 선택이 나오며, 그 옆에는 MySQL과 SQL Server도 있습니다. 모든 것이 많지만 선택해야합니다.
2. 유혹의 배경에 대한 제한을 잊어서는 안됩니다. 기본적으로 모든 사람이 Spanner를 원하지만 비용이 많이 듭니다. 결과적으로 일반적인 요청은 다음과 같습니다. “저희에게 Spanner를 만들어 주세요. 하지만 Cloud SQL의 가격을 생각한다면 당신은 전문가입니다!”

무엇을해야합니까?

궁극적인 진실이라고 주장하지 않고 다음과 같이 말해보자.

우리는 학습에 대한 접근 방식을 바꿔야 합니다.

• 이전에 DBA를 가르쳤던 방식을 가르치는 것은 의미가 없습니다.
• 하나의 제품에 대한 지식만으로는 더 이상 충분하지 않습니다.
• 그러나 한 사람의 수준에서 수십 사람을 아는 것은 불가능합니다.

제품의 가격뿐만 아니라 다음 사항도 알아야 합니다.

• 애플리케이션의 사용 사례
• 다양한 배포 방법;
• 각 방법의 장점과 단점;
• 항상 친숙한 제품을 선호하는 것은 아니지만 정보에 입각한 최적의 선택을 하기 위해 유사 및 대체 제품을 사용합니다.

또한 데이터를 마이그레이션하고 ETL과의 통합에 대한 기본 원칙을 이해할 수 있어야 합니다.

실제 사례

최근에는 모바일 애플리케이션용 백엔드를 생성해야 했습니다. 작업이 시작되었을 때 백엔드는 이미 개발되어 구현 준비가 되어 있었으며 개발 팀은 이 프로젝트에 약 XNUMX년을 투자했습니다. 다음 작업이 설정되었습니다.

• CI/CD 구축
• 아키텍처를 검토합니다.
• 모든 것을 실행에 옮기십시오.

애플리케이션 자체는 마이크로서비스였으며 Python/Django 코드는 처음부터 GCP에서 직접 개발되었습니다. 대상은 미국과 유럽 두 지역으로 가정하고, 트래픽은 Global Load Balancer를 통해 분산하였다. 모든 작업 부하와 컴퓨팅 작업 부하가 Google Kubernetes Engine에서 실행되었습니다.

데이터의 구조는 3가지였습니다.

• 클라우드 스토리지;
• 데이터스토어;
• 클라우드 SQL(PostgreSQL).

Cloud SQL을 선택한 이유가 궁금할 수도 있습니다. 사실, 이러한 질문은 최근 몇 년 동안 일종의 어색한 일시 중지를 야기했습니다. 사람들이 관계형 데이터베이스에 대해 부끄러워한다는 느낌이 있지만 그럼에도 불구하고 계속해서 적극적으로 사용합니다 ;-).

우리의 경우 다음과 같은 이유로 Cloud SQL을 선택했습니다.

1. 앞서 언급한 대로 애플리케이션은 Django를 사용하여 개발되었으며 SQL 데이터베이스의 영구 데이터를 Python 개체(Django ORM)에 매핑하는 모델이 있습니다.
2. 프레임워크 자체는 상당히 한정된 DBMS 목록을 지원했습니다.

• 포스트그레SQL;
• 마리아DB;
• MySQL;
• 신탁;
• SQLite는.

따라서 PostgreSQL은 이 목록에서 다소 직관적으로 선택되었습니다(사실 Oracle을 선택하는 것은 아닙니다).

누락된 내용:

• 애플리케이션은 2개 지역에만 배포되었으며 세 번째 애플리케이션은 계획(아시아)에 나타났습니다.
• 데이터베이스는 북미 지역(아이오와)에 위치했습니다.
• 고객 측에서는 가능한지 우려했습니다. 액세스 지연 유럽과 아시아 출신 그리고 방해 서비스 중 DBMS 다운타임이 발생한 경우.

Django 자체는 여러 데이터베이스를 병렬로 작업하고 읽기와 쓰기로 나눌 수 있다는 사실에도 불구하고 애플리케이션에서 쓰기가 그리 많지 않았습니다(90% 이상이 읽기). 그리고 일반적으로, 그리고 일반적으로 가능하다면 유럽과 아시아의 주요 기지의 읽기 복제본, 이것은 절충안 솔루션이 될 것입니다. 글쎄, 뭐가 그렇게 복잡해?

어려운 점은 고객이 관리형 서비스와 Cloud SQL 사용을 포기하고 싶지 않다는 점이었습니다. 그리고 Cloud SQL의 기능은 현재 제한되어 있습니다. Cloud SQL은 고가용성(HA)과 읽기 복제본(RR)을 지원하지만 동일한 RR은 한 지역에서만 지원됩니다. 미국 지역에서 데이터베이스를 만든 후에는 Cloud SQL을 사용하여 유럽 지역에서 읽기 복제본을 만들 수 없습니다. 하지만 Postgres 자체에서는 이를 방지하지 못합니다. Google 직원과의 서신은 아무 성과도 없었으며 "우리는 문제를 알고 있으며 노력 중입니다. 언젠가 문제가 해결될 것입니다"라는 스타일의 약속으로 끝났습니다.

Cloud SQL의 기능을 간략하게 나열하면 다음과 같습니다.

1. 고가용성(HA):

• 한 지역 내에서;
• 디스크 복제를 통해;
• PostgreSQL 엔진은 사용되지 않습니다.
• 자동 및 수동 제어 가능 - 장애 조치/장애 복구;
• 전환 시 몇 분 동안 DBMS를 사용할 수 없습니다.

2. 읽기 복제본(RR):

• 한 지역 내에서;
• 핫 대기;
• PostgreSQL 스트리밍 복제.

또한, 관례대로 기술을 선택할 때 항상 몇 가지 문제에 직면하게 됩니다. 제한:

• 고객은 GKE를 통하는 경우를 제외하고 엔터티를 생성하고 IaaS를 사용하기를 원하지 않았습니다.
• 고객은 셀프 서비스 PostgreSQL/MySQL 배포를 원하지 않습니다.
• 글쎄, 일반적으로 Google Spanner는 가격이 아니라면 꽤 적합할 것입니다. 그러나 Django ORM은 사용할 수 없지만 좋은 것입니다.

상황을 고려하여 고객은 후속 질문을 받았습니다. "Google Spanner와 비슷하면서도 Django ORM과도 작동하도록 비슷한 작업을 수행할 수 있나요?"

솔루션 옵션 No. 0

가장 먼저 떠오른 것:

• CloudSQL 내에 머무르세요.
• 어떤 형태로든 지역 간에 기본 제공 복제가 없습니다.
• PostgreSQL을 통해 기존 Cloud SQL에 복제본을 연결해 보세요.
• PostgreSQL 인스턴스를 어딘가에서 어떻게든 시작하되 적어도 마스터는 건드리지 마세요.

아아, 호스트(완전히 다른 프로젝트에 있음)(pg_hba 등)에 대한 액세스 권한이 없고 슈퍼유저 아래에도 액세스할 수 없기 때문에 이 작업을 수행할 수 없다는 것이 밝혀졌습니다.

솔루션 옵션 No. 1

더 깊이 생각하고 이전 상황을 고려한 후에 생각의 흐름이 다소 바뀌었습니다.

• 우리는 여전히 CloudSQL을 유지하려고 노력하고 있지만 MySQL의 Cloud SQL에는 다음과 같은 외부 마스터가 있기 때문에 MySQL로 전환하고 있습니다.

— 외부 MySQL을 위한 프록시입니다.
- MySQL 인스턴스처럼 보입니다.
- 다른 클라우드 또는 온프레미스에서 데이터를 마이그레이션하기 위해 개발되었습니다.

MySQL 복제를 설정하는 데에는 호스트에 대한 액세스가 필요하지 않기 때문에 원칙적으로 모든 것이 작동했지만 매우 불안정하고 불편했습니다. 더 나아가서 전체 구조를 테라폼으로 배포했는데 갑자기 외부 마스터가 테라폼에서 지원되지 않는다는 사실이 밝혀졌기 때문에 완전히 무서워졌습니다. 예, Google에는 CLI가 있지만 어떤 이유로 여기에서는 모든 것이 가끔씩 작동했습니다. 때로는 생성되기도 하고 생성되지 않기도 합니다. 아마도 CLI가 복제본이 아닌 외부 데이터 마이그레이션을 위해 개발되었기 때문일 것입니다.

사실 이 시점에서 Cloud SQL이 전혀 적합하지 않다는 것이 분명해졌습니다. 그들이 말했듯이 우리는 할 수 있는 모든 일을 했습니다.

솔루션 옵션 No. 2

Cloud SQL 프레임워크 내에 머무는 것이 불가능했기 때문에 절충 솔루션에 대한 요구 사항을 공식화하려고 노력했습니다. 요구 사항은 다음과 같습니다.

• Kubernetes에서 작업하고 Kubernetes(DCS, ...) 및 GCP(LB, ...)의 리소스와 기능을 최대한 활용합니다.
• HA 프록시와 같은 클라우드의 불필요한 것들로 인해 안정기가 부족합니다.
• 기본 HA 지역에서 PostgreSQL 또는 MySQL을 실행하는 기능 다른 지역 - 기본 지역의 RR에 있는 HA와 해당 복사본(신뢰성을 위해)
• 멀티 마스터 (연락하고 싶지 않았지만 그다지 중요한 내용은 아니었습니다)

.
이러한 요구의 결과로, p적합한 DBMS 및 바인딩 옵션:

• MySQL 갈레라;
• 바퀴벌레DB;
• PostgreSQL 도구

:
- pgpool-II;
— 패트로니.

MySQL 갈레라

MySQL Galera 기술은 Codership에서 개발되었으며 InnoDB용 플러그인입니다. 특징:

• 다중 마스터;
• 동기 복제;
• 모든 노드에서 읽기;
• 모든 노드에 기록;
• 내장형 HA 메커니즘;
• Bitnami의 Helm 차트가 있습니다.

바퀴벌레 DB

설명에 따르면 이 문제는 정말 폭탄이며 Go로 작성된 오픈 소스 프로젝트입니다. 주요 참가자는 Cockroach Labs(Google 사람들이 설립한)입니다. 이 관계형 DBMS는 원래 분산형(기본적으로 수평 확장 포함) 및 내결함성을 갖도록 설계되었습니다. 회사의 저자는 "SQL 기능의 풍부함과 NoSQL 솔루션에 익숙한 수평적 접근성을 결합"하는 목표를 설명했습니다.

좋은 보너스는 post-gress 연결 프로토콜을 지원한다는 것입니다.

Pgpool

이것은 실제로 모든 연결을 인계받아 처리하는 새로운 엔터티인 PostgreSQL의 추가 기능입니다. BSD 라이선스에 따라 라이선스가 부여된 자체 로드 밸런서와 파서가 있습니다. 충분한 기회를 제공하지만, 새로운 존재의 존재가 추가적인 모험의 원천이 될 수 있기 때문에 다소 무섭게 보입니다.

패트로니

이것이 내 눈이 떨어진 마지막 일이었고 결과적으로 헛되지 않았습니다. Patroni는 다양한 유형의 복제 및 자동 역할 전환을 통해 PostgreSQL 클러스터를 자동으로 유지 관리할 수 있게 해주는 본질적으로 Python 데몬인 오픈 소스 유틸리티입니다. 이는 큐버와 잘 통합되고 새로운 엔터티를 도입하지 않기 때문에 매우 흥미로운 것으로 나타났습니다.

결국 무엇을 선택하셨나요?

선택은 쉽지 않았습니다.

1. 바퀴벌레 DB - 불이지만 어둡습니다.
2. MySQL 갈레라 - 또한 나쁘지 않습니다. 여러 곳에서 사용되지만 MySQL입니다.
3. Pgpool — 불필요한 엔터티가 많아 클라우드 및 K8과 통합됩니다.
4. 패트로니 - 불필요한 엔터티가 없는 K8s와의 탁월한 통합, GCP LB와 잘 통합됩니다.

따라서 선택은 Patroni에게 떨어졌습니다.

조사 결과

간략하게 요약해 보는 시간입니다. 그렇습니다. IT 인프라의 세계는 크게 변화했으며 이는 시작에 불과합니다. 그리고 이전에는 클라우드가 단지 또 다른 유형의 인프라였다면 이제는 모든 것이 달라졌습니다. 더욱이 클라우드의 혁신은 지속적으로 나타나고 있으며 아마도 클라우드에만 나타날 것이며 그 후에야 스타트업의 노력에 의해 온프레미스로 이전될 것입니다.

SQL의 경우 SQL이 유지됩니다. 즉, PostgreSQL과 MySQL을 알아야 하고 이들로 작업할 수 있어야 하지만 더 중요한 것은 이들을 올바르게 사용할 수 있다는 것입니다.

출처 : habr.com