서버리스 데이터베이스로 가는 길 - 방법과 이유

안녕하세요 여러분! 내 이름은 골로프 니콜라이입니다. 이전에는 Avito에서 근무하며 XNUMX년 동안 데이터 플랫폼을 관리했습니다. 즉, 분석(Vertica, ClickHouse), 스트리밍 및 OLTP(Redis, Tarantool, VoltDB, MongoDB, PostgreSQL) 등 모든 데이터베이스를 관리했습니다. 이 기간 동안 나는 매우 다르고 특이하며 비표준적인 사용 사례를 가진 수많은 데이터베이스를 다루었습니다.

저는 현재 ManyChat에서 일하고 있습니다. 본질적으로 이것은 새롭고 야심적이며 빠르게 성장하는 스타트업입니다. 그리고 처음 입사했을 때 “젊은 스타트업이 이제 DBMS와 데이터베이스 시장에서 무엇을 취해야 하는가?”라는 고전적인 질문이 떠올랐습니다.

이 기사에서는 내 보고서를 바탕으로 온라인 페스티벌 RIT++2020, 이 질문에 답하겠습니다. 보고서의 비디오 버전은 다음에서 볼 수 있습니다. 유튜브.

일반적으로 알려진 데이터베이스 2020

2020년이 되니 주위를 둘러보니 세 가지 종류의 데이터베이스가 보였습니다.

첫 번째 유형 - 클래식 OLTP 데이터베이스: PostgreSQL, SQL Server, Oracle, MySQL. 오래 전에 작성되었지만 개발자 커뮤니티에 매우 친숙하기 때문에 여전히 관련성이 있습니다.

두 번째 유형은 "XNUMX"의 염기. 그들은 내장된 샤딩 및 기타 매력적인 기능을 추가하여 SQL, 기존 구조 및 ACID를 포기함으로써 고전적인 패턴에서 벗어나려고 했습니다. 예를 들어 Cassandra, MongoDB, Redis 또는 Tarantool이 있습니다. 이러한 모든 솔루션은 시장에 근본적으로 새로운 것을 제공하기를 원했으며 특정 작업에 매우 편리한 것으로 판명되었기 때문에 틈새 시장을 점유했습니다. 저는 이러한 데이터베이스를 NOSQL이라는 포괄적인 용어로 표시하겠습니다.

"XNUMX"은 끝났고 우리는 NOSQL 데이터베이스에 익숙해졌으며 내 관점에서 볼 때 세상은 다음 단계를 밟았습니다. 관리되는 데이터베이스. 이러한 데이터베이스는 기존 OLTP 데이터베이스 또는 새로운 NoSQL 데이터베이스와 동일한 핵심을 가지고 있습니다. 하지만 DBA와 DevOps가 필요하지 않으며 클라우드의 관리형 하드웨어에서 실행됩니다. 개발자에게 이것은 어딘가에서 작동하는 "그냥 기반"이지만 서버에 어떻게 설치되는지, 누가 서버를 구성하고 누가 업데이트하는지 아무도 신경 쓰지 않습니다.

그러한 데이터베이스의 예:

• AWS RDS는 PostgreSQL/MySQL용 관리형 래퍼입니다.
• DynamoDB는 Redis 및 MongoDB와 유사한 문서 기반 데이터베이스의 AWS 아날로그입니다.
• Amazon Redshift는 관리형 분석 데이터베이스입니다.

이는 기본적으로 오래된 데이터베이스이지만 하드웨어를 사용할 필요 없이 관리되는 환경에서 생성됩니다.

메모. 예제는 AWS 환경을 기준으로 작성되었지만 Microsoft Azure, Google Cloud 또는 Yandex.Cloud에도 유사한 내용이 있습니다.

이것에 대한 새로운 점은 무엇입니까? 2020년에는 이 중 아무것도 없습니다.

서버리스 개념

2020년 시장에서 실제로 새로운 것은 서버리스 또는 서버리스 솔루션입니다.

일반 서비스나 백엔드 애플리케이션의 예를 사용하여 이것이 무엇을 의미하는지 설명하려고 합니다.
일반 백엔드 애플리케이션을 배포하기 위해 우리는 서버를 구입하거나 임대하고, 서버에 코드를 복사하고, 엔드포인트를 외부에 게시하고 정기적으로 임대료, 전기 및 데이터 센터 서비스 비용을 지불합니다. 이것이 표준 구성표입니다.

다른 방법이 있나요? 서버리스 서비스를 사용하면 가능합니다.

이 접근 방식의 초점은 무엇입니까? 서버가 없으며 클라우드에 가상 인스턴스를 임대하지도 않습니다. 서비스를 배포하려면 코드(함수)를 리포지토리에 복사하고 엔드포인트에 게시하세요. 그런 다음 이 함수가 실행되는 하드웨어를 완전히 무시하고 이 함수를 호출할 때마다 비용을 지불합니다.

나는 이 접근법을 그림으로 설명하려고 노력할 것이다.


클래식 배포. 특정 부하를 가진 서비스가 있습니다. 물리적 서버 또는 AWS 인스턴스라는 두 가지 인스턴스를 생성합니다. 외부 요청은 이러한 인스턴스로 전송되어 처리됩니다.

사진에서 볼 수 있듯이 서버는 균등하게 배치되지 않습니다. 하나는 100% 활용되고, 두 개의 요청이 있으며, 하나는 부분적으로 유휴 상태인 50%입니다. 30개가 아닌 XNUMX개의 요청이 도착하면 전체 시스템이 로드를 처리할 수 없어 속도가 느려지기 시작합니다.

서버리스 배포. 서버리스 환경에서는 이러한 서비스에 인스턴스나 서버가 없습니다. 가열된 리소스 풀(배포된 기능 코드가 포함된 작은 준비된 Docker 컨테이너)이 있습니다. 시스템은 외부 요청을 수신하고 각 요청에 대해 서버리스 프레임워크는 코드가 포함된 작은 컨테이너를 생성합니다. 시스템은 이 특정 요청을 처리하고 컨테이너를 종료합니다.

요청 1000개 - 컨테이너 1000개, 요청 XNUMX개 - 컨테이너 XNUMX개. 그리고 하드웨어 서버에 대한 배포는 이미 클라우드 제공업체의 작업입니다. 이는 서버리스 프레임워크에 의해 완전히 숨겨져 있습니다. 이 개념에서는 모든 통화에 대해 비용을 지불합니다. 예를 들어, 하루에 한 통의 전화가 왔습니다. 우리는 한 통화에 대해 비용을 지불했고, 분당 백만 건의 전화가 왔습니다. 우리는 백만 건에 대해 지불했습니다. 아니면 잠시 후에 이런 일도 발생합니다.

서버리스 기능을 게시한다는 개념은 상태 비저장 서비스에 적합합니다. 그리고 (상태) 상태 저장 서비스가 필요한 경우 서비스에 데이터베이스를 추가합니다. 이 경우 상태 작업과 관련하여 각 상태 저장 함수는 단순히 데이터베이스에서 쓰고 읽습니다. 또한 기사 시작 부분에 설명된 세 가지 유형의 데이터베이스에서.

이러한 모든 데이터베이스의 일반적인 제한 사항은 무엇입니까? 이는 지속적으로 사용되는 클라우드 또는 하드웨어 서버(또는 여러 서버)의 비용입니다. 클래식 데이터베이스를 사용하든 관리형 데이터베이스를 사용하든, Devops와 관리자가 있든 없든 상관없이 우리는 여전히 하드웨어, 전기 및 데이터 센터 임대 비용을 연중무휴 24시간 지불합니다. 클래식 기반이 있으면 마스터와 슬레이브 비용을 지불합니다. 로드가 높은 샤딩된 데이터베이스인 경우 7, 10 또는 20개의 서버에 대한 비용을 지불하고 지속적으로 지불합니다.

비용 구조에서 영구적으로 예약된 서버의 존재는 이전에는 필요악으로 인식되었습니다. 기존 데이터베이스에는 연결 수 제한, 확장 제한, 지리적으로 분산된 합의와 같은 다른 어려움도 있습니다. 이러한 문제는 특정 데이터베이스에서 어떻게든 해결될 수 있지만 한꺼번에 해결되지는 않으며 이상적으로도 해결되지 않습니다.

서버리스 데이터베이스 - 이론

2020년 질문: 데이터베이스를 서버리스로 만드는 것도 가능합니까? 다들 서버리스 백엔드에 대해 들어보셨을 텐데요. 데이터베이스를 서버리스로 만들어 볼까요?

데이터베이스는 상태 저장 서비스이고 서버리스 인프라에는 적합하지 않기 때문에 이상하게 들립니다. 동시에 데이터베이스 상태는 기가바이트, 테라바이트, 분석 데이터베이스에서는 페타바이트까지 매우 큽니다. 경량 Docker 컨테이너에서 키우는 것은 그리 쉽지 않습니다.

반면, 거의 모든 최신 데이터베이스에는 트랜잭션, 무결성 조정, 절차, 관계 종속성 및 많은 논리와 같은 엄청난 양의 논리와 구성 요소가 포함되어 있습니다. 상당히 많은 데이터베이스 논리의 경우 작은 상태이면 충분합니다. 기가바이트 및 테라바이트는 쿼리를 직접 실행하는 데 관련된 데이터베이스 논리의 작은 부분에서만 직접 사용됩니다.

따라서 논리의 일부가 상태 비저장 실행을 허용하는 경우 기본을 상태 저장 부분과 상태 비저장 부분으로 분할하는 것이 어떻겠습니까?

OLAP 솔루션을 위한 서버리스

실제 사례를 사용하여 데이터베이스를 Stateful 및 Stateless 부분으로 나누는 것이 어떤 모습인지 살펴보겠습니다.

예를 들어 분석 데이터베이스가 있습니다.: 외부 데이터(왼쪽의 빨간색 원통), 데이터를 데이터베이스에 로드하는 ETL 프로세스, 데이터베이스에 SQL 쿼리를 보내는 분석가입니다. 이는 전형적인 데이터 웨어하우스 운영 방식입니다.

이 방식에서는 ETL이 조건부로 한 번만 수행됩니다. 그런 다음 쿼리를 보낼 대상이 있도록 ETL로 채워진 데이터로 데이터베이스가 실행되는 서버에 대한 비용을 지속적으로 지불해야 합니다.

AWS Athena Serverless에 구현된 대체 접근 방식을 살펴보겠습니다. 다운로드한 데이터가 저장되는 영구적인 전용 하드웨어는 없습니다. 대신에:

• 사용자가 Athena에 SQL 쿼리를 제출합니다. Athena 최적화 프로그램은 SQL 쿼리를 분석하고 메타데이터 저장소(메타데이터)에서 쿼리 실행에 필요한 특정 데이터를 검색합니다.
• 옵티마이저는 수집된 데이터를 기반으로 외부 소스에서 필요한 데이터를 임시 저장소(임시 데이터베이스)로 다운로드합니다.
• 사용자의 SQL 쿼리는 임시 저장소에서 실행되고 그 결과가 사용자에게 반환됩니다.
• 임시 저장소가 지워지고 리소스가 해제됩니다.

이 아키텍처에서는 요청을 실행하는 프로세스에 대해서만 비용을 지불합니다. 요청 없음 - 비용이 발생하지 않습니다.

이는 효과적인 접근 방식이며 Athena Serverless뿐만 아니라 Redshift Spectrum(AWS)에서도 구현됩니다.

Athena 예는 서버리스 데이터베이스가 수십, 수백 테라바이트의 데이터를 사용하는 실제 쿼리에서 작동한다는 것을 보여줍니다. 수백 테라바이트에는 수백 대의 서버가 필요하지만 우리는 이에 대한 비용을 지불할 필요가 없습니다. 요청에 대한 비용만 지불하면 됩니다. 각 요청의 속도는 Vertica와 같은 전문 분석 데이터베이스에 비해 (매우) 느리지만 가동 중지 시간에 대해서는 비용을 지불하지 않습니다.

이러한 데이터베이스는 드문 분석 임시 쿼리에 적용 가능합니다. 예를 들어, 우리가 자발적으로 엄청난 양의 데이터에 대한 가설을 테스트하기로 결정한 경우입니다. Athena는 이러한 경우에 적합합니다. 정기적인 요청의 경우 이러한 시스템은 비용이 많이 듭니다. 이 경우 일부 특수 솔루션에서 데이터를 캐시하십시오.

OLTP 솔루션을 위한 서버리스

이전 예에서는 OLAP(분석) 작업을 살펴보았습니다. 이제 OLTP 작업을 살펴보겠습니다.

확장 가능한 PostgreSQL 또는 MySQL을 상상해 봅시다. 최소한의 리소스로 일반 관리형 인스턴스 PostgreSQL 또는 MySQL을 키워보겠습니다. 인스턴스가 더 많은 로드를 받으면 읽기 로드의 일부를 분산할 추가 복제본을 연결합니다. 요청이나 로드가 없으면 복제본을 끕니다. 첫 번째 인스턴스는 마스터이고 나머지는 복제본입니다.

이 아이디어는 Aurora Serverless AWS라는 데이터베이스에서 구현됩니다. 원칙은 간단합니다. 외부 애플리케이션의 요청은 프록시 플릿에서 수락됩니다. 로드가 증가하는 것을 확인하고 미리 워밍업된 최소 인스턴스에서 컴퓨팅 리소스를 할당합니다. 연결은 가능한 한 빨리 이루어집니다. 인스턴스 비활성화도 같은 방식으로 발생합니다.

Aurora에는 ACU라는 Aurora 용량 단위라는 개념이 있습니다. 이것은 (조건부로) 인스턴스(서버)입니다. 각 특정 ACU는 마스터 또는 슬레이브가 될 수 있습니다. 각 용량 단위에는 자체 RAM, 프로세서 및 최소 디스크가 있습니다. 따라서 하나는 마스터이고 나머지는 읽기 전용 복제본입니다.

실행 중인 Aurora 용량 단위의 수는 구성 가능한 매개변수입니다. 최소 수량은 XNUMX 또는 XNUMX일 수 있습니다(이 경우 요청이 없으면 데이터베이스가 작동하지 않습니다).

베이스가 요청을 받으면 프록시 플릿은 Aurora 용량 단위를 높여 시스템의 성능 리소스를 늘립니다. 리소스를 늘리거나 줄이는 기능을 통해 시스템은 리소스를 "조정"할 수 있습니다. 즉, 개별 ACU를 자동으로 표시하고(새 ACU로 교체) 철회된 리소스에 대한 모든 현재 업데이트를 롤아웃할 수 있습니다.

Aurora Serverless 기반은 읽기 로드를 확장할 수 있습니다. 그러나 문서에는 이에 대해 직접적으로 언급되어 있지 않습니다. 다중 마스터를 들어 올릴 수 있는 것처럼 느껴질 수도 있습니다. 마법은 없습니다.

이 데이터베이스는 예측할 수 없는 액세스가 가능한 시스템에 막대한 비용을 지출하는 것을 방지하는 데 매우 적합합니다. 예를 들어 MVP나 마케팅 명함 사이트를 만들 때 일반적으로 안정적인 로드를 기대하지 않습니다. 따라서 접속이 없을 경우 인스턴스 비용을 지불하지 않습니다. 예를 들어 컨퍼런스나 광고 캠페인 이후 예상치 못한 로드가 발생하고 많은 사람들이 사이트를 방문하여 로드가 급격히 증가하면 Aurora Serverless는 자동으로 이 로드를 처리하고 누락된 리소스(ACU)를 신속하게 연결합니다. 그런 다음 컨퍼런스가 통과되고 모두가 프로토타입에 대해 잊어버리고 서버(ACU)가 어두워지고 비용이 XNUMX으로 떨어지므로 편리합니다.

이 솔루션은 쓰기 부하를 확장하지 않기 때문에 안정적인 고부하에는 적합하지 않습니다. 이러한 모든 리소스 연결 및 연결 끊김은 소위 "확장 지점"(데이터베이스가 트랜잭션이나 임시 테이블에서 지원되지 않는 시점)에서 발생합니다. 예를 들어 일주일 이내에 확장 지점이 발생하지 않을 수 있으며 기반은 동일한 리소스에서 작동하므로 확장하거나 축소할 수 없습니다.

마법은 없습니다. 일반 PostgreSQL입니다. 그러나 기계를 추가하고 연결을 끊는 과정은 부분적으로 자동화되어 있습니다.

서버리스 설계

Aurora Serverless는 Serverless의 일부 이점을 활용하기 위해 클라우드용으로 재작성된 오래된 데이터베이스입니다. 이제 원래 클라우드용으로 작성된 서버리스 접근 방식인 Serverless-by-design에 대해 설명하겠습니다. 물리적 서버에서 실행된다는 가정 없이 바로 개발되었습니다.

이 베이스의 이름은 Snowflake입니다. 세 개의 핵심 블록이 있습니다.

첫 번째는 메타데이터 블록입니다. 이는 보안, 메타데이터, 트랜잭션 및 쿼리 최적화와 관련된 문제를 해결하는 빠른 인메모리 서비스입니다(왼쪽 그림 참조).

두 번째 블록은 계산을 위한 가상 컴퓨팅 클러스터 세트입니다(그림에는 파란색 원 세트가 있음).

세 번째 블록은 S3 기반의 데이터 저장 시스템이다. S3는 AWS의 무차원 객체 스토리지로, 일종의 비즈니스용 Dropbox와 같습니다.

콜드 스타트를 가정하여 Snowflake가 어떻게 작동하는지 살펴보겠습니다. 즉, 데이터베이스가 있고 데이터가 로드되어 있으며 실행 중인 쿼리가 없습니다. 따라서 데이터베이스에 대한 요청이 없으면 빠른 인메모리 메타데이터 서비스(첫 번째 블록)를 높였습니다. 그리고 테이블 데이터가 저장되는 S3 스토리지가 소위 마이크로 파티션으로 나누어져 있습니다. 단순화를 위해 테이블에 트랜잭션이 포함된 경우 마이크로 파티션은 트랜잭션 날짜입니다. 매일은 별도의 마이크로파티션, 별도의 파일입니다. 데이터베이스가 이 모드로 작동하면 데이터가 차지하는 공간에 대해서만 비용을 지불하면 됩니다. 게다가 좌석당 요금도 매우 낮습니다(특히 상당한 압축률을 고려하면). 메타데이터 서비스도 지속적으로 작동하지만 쿼리를 최적화하는 데 많은 리소스가 필요하지 않으며 서비스는 셰어웨어로 간주될 수 있습니다.

이제 사용자가 데이터베이스에 와서 SQL 쿼리를 보냈다고 가정해 보겠습니다. SQL 쿼리는 처리를 위해 즉시 메타데이터 서비스로 전송됩니다. 따라서 요청을 받으면 이 서비스는 요청, 사용 가능한 데이터, 사용자 권한을 분석하고 모든 것이 정상인 경우 요청 처리 계획을 세웁니다.

다음으로 서비스는 컴퓨팅 클러스터의 시작을 시작합니다. 컴퓨팅 클러스터는 계산을 수행하는 서버 클러스터입니다. 즉, 1개 서버, 2개 서버, 4, 8, 16, 32개 등 원하는 만큼 포함할 수 있는 클러스터입니다. 요청을 하면 이 클러스터의 시작이 즉시 시작됩니다. 정말 몇 초가 걸립니다.

다음으로, 클러스터가 시작된 후 요청을 처리하는 데 필요한 마이크로 파티션이 S3에서 클러스터로 복사되기 시작합니다. 즉, SQL 쿼리를 실행하려면 한 테이블에 두 개의 파티션이 필요하고 두 번째 테이블에 하나의 파티션이 필요하다고 가정해 보겠습니다. 이 경우 필요한 세 개의 파티션만 클러스터에 복사되고 모든 테이블이 완전히 복사되는 것은 아닙니다. 그렇기 때문에 모든 것이 하나의 데이터 센터 내에 있고 매우 빠른 채널로 연결되어 있기 때문에 전체 전송 프로세스가 매우 빠르게 발생합니다. 몇 초 안에, 아주 드물게는 몇 분 안에 일부 엄청난 요청에 대해 이야기하지 않는 한 . 따라서 마이크로파티션은 컴퓨팅 클러스터에 복사되고, 완료되면 이 컴퓨팅 클러스터에서 SQL 쿼리가 실행됩니다. 이 요청의 결과는 한 줄, 여러 줄 또는 테이블일 수 있습니다. 이러한 결과는 사용자가 다운로드하거나 BI 도구에 표시하거나 다른 방식으로 사용할 수 있도록 외부로 사용자에게 전송됩니다.

각 SQL 쿼리는 이전에 로드된 데이터에서 집계를 읽을 수 있을 뿐만 아니라 데이터베이스에서 새 데이터를 로드/생성할 수도 있습니다. 즉, 예를 들어 새 레코드를 다른 테이블에 삽입하여 컴퓨팅 클러스터에 새 파티션이 나타나고 단일 S3 스토리지에 자동으로 저장되는 쿼리일 수 있습니다.

위에서 설명한 시나리오는 사용자 도착부터 클러스터 생성, 데이터 로딩, 쿼리 실행, 결과 획득까지 가상 컴퓨팅 클러스터, 가상 창고를 사용하는 분당 요금으로 지불됩니다. 요금은 AWS 영역 및 클러스터 크기에 따라 다르지만 평균적으로 시간당 몇 달러입니다. 16개의 머신으로 구성된 클러스터는 32개의 머신으로 구성된 클러스터보다 두 배 더 비싸고, 5개의 머신으로 구성된 클러스터는 여전히 두 배 더 비쌉니다. 요청의 복잡성에 따라 10, XNUMX대의 기계 옵션을 사용할 수 있습니다. 그러나 클러스터가 실제로 실행되는 동안의 시간에 대해서만 비용을 지불합니다. 요청이 없으면 손을 떼고 XNUMX~XNUMX분 동안 기다린 후(구성 가능한 매개변수) 자체적으로 종료되기 때문입니다. 자원을 확보하고 자유로워지세요.

완전히 현실적인 시나리오는 요청을 보낼 때 상대적으로 클러스터가 팝업되고 XNUMX분 후에 다시 XNUMX분을 계산한 다음 XNUMX분 동안 종료하고 결국 이 클러스터의 XNUMX분 작업에 대한 비용을 지불하게 되는 것입니다. 몇 달, 몇 년 동안은 아닙니다.

단일 사용자 설정에서 Snowflake를 사용하여 설명한 첫 번째 시나리오입니다. 이제 실제 시나리오에 더 가까운 사용자가 많다고 상상해 봅시다.

수많은 간단한 분석 SQL 쿼리로 데이터베이스를 지속적으로 공격하는 많은 분석가와 Tableau 보고서가 있다고 가정해 보겠습니다.

또한, 데이터로 엄청난 일을 하고, 수십 테라바이트로 작업하고, 수십억, 수조 행의 데이터를 분석하려는 창의적인 데이터 과학자가 있다고 가정해 보겠습니다.

위에서 설명한 두 가지 유형의 작업 부하에 대해 Snowflake를 사용하면 용량이 서로 다른 여러 개의 독립적인 컴퓨팅 클러스터를 구축할 수 있습니다. 또한 이러한 컴퓨팅 클러스터는 독립적으로 작동하지만 일관된 공통 데이터를 사용합니다.

가벼운 쿼리 수가 많은 경우 각각 대략 2대의 머신으로 구성된 3~2개의 작은 클러스터를 생성할 수 있습니다. 이 동작은 무엇보다도 자동 설정을 사용하여 구현할 수 있습니다. 그래서 당신은 “눈송이야, 작은 클러스터를 키워라. 부하가 특정 매개변수 이상으로 증가하면 유사한 두 번째, 세 번째 매개변수를 발생시킵니다. 부하가 가라앉기 시작하면 초과분을 끄십시오.” 따라서 얼마나 많은 분석가가 와서 보고서를 살펴보더라도 모두가 충분한 리소스를 가질 수 있습니다.

동시에 분석가가 잠들어 있고 보고서를 보는 사람이 없다면 클러스터가 완전히 어두워질 수 있으며 이에 대한 비용 지불이 중단됩니다.

동시에 데이터 과학자의 쿼리가 많은 경우 32개 시스템에 대해 매우 큰 클러스터 하나를 생성할 수 있습니다. 또한 이 클러스터는 대규모 요청이 실행되는 분과 시간에 대해서만 비용을 지불합니다.

위에서 설명한 기회를 통해 2개뿐만 아니라 더 많은 유형의 워크로드를 클러스터(ETL, 모니터링, 보고서 구체화 등)로 나눌 수 있습니다.

Snowflake를 요약해 보겠습니다. 기본은 아름다운 아이디어와 실행 가능한 구현을 결합합니다. ManyChat에서는 Snowflake를 사용하여 보유한 모든 데이터를 분석합니다. 예시와 같이 5개의 클러스터가 없지만 크기가 다른 9~16개의 클러스터가 있습니다. 우리는 일부 작업에 대해 기존의 2 머신, 1 머신, 초소형 XNUMX 머신을 보유하고 있습니다. 이는 부하를 성공적으로 분산시켜 많은 비용을 절약할 수 있게 해줍니다.

데이터베이스가 읽기 및 쓰기 로드를 성공적으로 확장했습니다. 이는 읽기 부하만 전달했던 동일한 "오로라"와 비교하면 엄청난 차이이자 엄청난 혁신입니다. Snowflake를 사용하면 이러한 컴퓨팅 클러스터를 통해 쓰기 작업량을 확장할 수 있습니다. 즉, 아까 말했듯이 ManyChat에서는 여러 개의 클러스터를 사용하는데, 소규모 및 초소형 클러스터는 주로 ETL, 데이터 로딩에 사용됩니다. 그리고 분석가들은 이미 ETL 로드의 영향을 전혀 받지 않는 중간 규모 클러스터에 거주하고 있으므로 작업 속도가 매우 빠릅니다.

따라서 데이터베이스는 OLAP 작업에 매우 적합합니다. 그러나 안타깝게도 아직 OLTP 워크로드에는 적용할 수 없습니다. 첫째, 이 데이터베이스는 모든 후속 결과를 포함하는 원주형 데이터베이스입니다. 둘째, 각 요청에 대해 필요한 경우 컴퓨팅 클러스터를 생성하고 여기에 데이터를 넘치게 하는 접근 방식 자체는 불행히도 아직 OLTP 로드에 충분히 빠르지 않습니다. OLAP 작업의 경우 몇 초 동안 기다리는 것이 정상이지만 OLTP 작업의 경우 허용되지 않습니다. 100ms가 더 좋고 10ms가 더 좋습니다.

합계

데이터베이스를 Stateless 부분과 Stateful 부분으로 나누어 서버리스 데이터베이스가 가능합니다. 위의 모든 예에서 Stateful 부분은 상대적으로 S3에 마이크로 파티션을 저장하는 것이며 Stateless는 메타데이터를 사용하여 독립적인 경량 Stateless 서비스로 발생할 수 있는 보안 문제를 처리하는 최적화 프로그램이라는 것을 알 수 있습니다.

SQL 쿼리 실행은 Snowflake 컴퓨팅 클러스터와 같이 서버리스 모드에서 팝업되어 필요한 데이터만 다운로드하고 쿼리를 실행한 후 "외출"할 수 있는 간단한 상태 서비스로 인식될 수도 있습니다.

서버리스 프로덕션 수준 데이터베이스는 이미 사용할 수 있으며 작동 중입니다. 이러한 서버리스 데이터베이스는 이미 OLAP 작업을 처리할 준비가 되어 있습니다. 불행하게도 OLTP 작업에는 한계가 있기 때문에 미묘한 차이로 사용됩니다. 한편으로 이것은 마이너스입니다. 그러나 한편으로는 이것이 기회이다. 아마도 독자 중 한 명은 Aurora의 제한 없이 OLTP 데이터베이스를 완전히 서버리스로 만드는 방법을 찾을 것입니다.

흥미로웠기를 바랍니다. 서버리스가 미래입니다 :)

출처 : habr.com