다음 프로젝트에 Cloud Spanner 사용을 고려해야 하는 3가지 이유

* 본 아티클의 원문은 2020년 8월 21일 Google Cloud 블로그(영문)에 게재되었습니다. 

데이터베이스는 거의 모든 애플리케이션 아키텍처의 핵심 구성요소입니다. 애플리케이션을 설계할 때는 애플리케이션 데이터를 오래 보관할 수 있는 방법을 강구해야 합니다. 공유 데이터베이스에서 데이터를 유지하지 않으면 애플리케이션을 확장하거나 기본 하드웨어를 업그레이드할 수 없습니다. 더 심각한 문제는 인프라 장애가 발생할 경우 모든 데이터가 즉시 손실된다는 점입니다.

하지만 안정적인 데이터베이스를 사용하면 애플리케이션 확장성을 사용 설정하고 데이터 내구성과 일관성, 서비스 가용성, 향상된 시스템 지원 가능성을 보장할 수 있습니다. 데이터베이스는 거의 모든 애플리케이션 아키텍처의 핵심 구성요소입니다.

Google Cloud의 Spanner 데이터베이스는 Google뿐 아니라 여러 클라우드 고객 제품의 구조화된 데이터 저장과 관련된 요구사항을 충족하도록 빌드되었습니다. Spanner는 Google의 핵심 인프라에 속해 있으며 Spanner를 사용하면 업계 또는 사용 사례에 관계없이 비즈니스를 안전하게 보호할 수 있습니다.

Spanner 이전에 Google 제품은 트랜잭션이 필요한 데이터베이스 사용 사례에 샤딩된 MySQL을 주로 사용했었습니다. Spanner 문서에서도 확인할 수 있듯, Spanner를 개발함으로써 복잡하고 변화하는 스키마를 가진 애플리케이션이나 광역 복제에 strong consistency가 필요한 애플리케이션에 적합한 데이터 스토리지 서비스를 만들고자 했습니다.

Spanner 사용을 고려할 때 가장 먼저 떠오르는 개념 중 하나는 대규모 데이터베이스로의 임의 확장이 가능하다는 것입니다. 실제로 Spanner는 수십억 명의 사용자에게 다양한 기능을 제공하는 Google 애플리케이션(예: Gmail 및 YouTube)을 지원하므로 최고 수준의 확장성을 갖춰야 합니다.

이 게시물에서는 Spanner가 어떻게 다양한 사용 사례에서 규모에 관계없이 모든 애플리케이션이 작동하도록 설계되었으며, 개발자의 진입 장벽을 낮추고, 총 소유 비용(TCO)을 줄일수 있는지 알아봅니다. 그럼, 관련 내용을 함께 살펴보겠습니다.

어디서든 시작하고 비즈니스 성장에 맞춰 규모 조정

Spanner는 데이터 볼륨을 대규모로 처리할 수 있으므로 대규모 애플리케이션뿐 아니라 다양한 크기의 애플리케이션에 유용합니다. 또한 조직은 RDBMS가 필요한 모든 워크로드를 단일 데이터베이스 엔진에서 표준화함으로써 이점을 누릴 수 있습니다. Spanner는 ANSI 2011 SQL, DML, 외래 키(Foreign Keys)와 같이 이미 익숙한 관계형 데이터베이스 관리 시스템(RDBMS) 기능은 물론 TrueTime을 통한 강력한 외부 일관성과 기본 동기식 복제를 통한 고가용성과 같은 고유한 기능을 조합하여 모든 종류의 애플리케이션을 위한 견고한 기반을 제공합니다.

'소규모'에 대해 어떻게 인식하고 있는지 잠시 생각해보겠습니다. 소규모 애플리케이션은 중요하지 않거나 가용성에 대한 원대한 목표나 트랜잭션 안정성에 대한 요구가 없다고 간주하기 쉽습니다. 그러나 소규모 애플리케이션이 대규모 애플리케이션보다 비즈니스와 관련해 중요도가 낮다는 것을 의미하지는 않습니다. 또한 특정 애플리케이션이 초기 출시 시점보다 더 높은 확장성을 요구하지 않는다는 의미도 아닙니다. 시작 단계에서는 애플리케이션의 사용자층과 트랜잭션 볼륨이 상대적으로 적을 수 있지만 Spanner의 확장성을 간과해서는 안 됩니다. Spanner의 백엔드에서 작동하도록 설계된 애플리케이션은 향후 데이터 볼륨이나 트랜잭션이 증가해도 재작성이나 어떤 유형의 데이터베이스 마이그레이션도 필요하지 않습니다. 

예를 들어 획기적인 차세대 게임을 개발하는 게임 회사라면 게임 출시와 동시에 엄청난 성공을 거두는 상황에 대비하여 사용자층 확대에 대응할 방안이 마련되어 있어야 합니다.

Spanner를 선택할 경우 애플리케이션의 규모에 관계없이 트랜잭션 지원, 고가용성 보장, 읽기 전용 복제본, 손쉬운 확장 등의 강력한 이점을 누릴 수 있습니다.

트랜잭션 지원 및 강력한 외부 일관성

Spanner는 TrueTime을 통해 외부 일관성을 보장합니다. Spanner는 완전히 중복된 원자 시계 시스템을 사용하여 가상의 분산 글로벌 시계의 타임스탬프를 얻을 수 있습니다. Spanner는 전역적으로 합의된 소스의 타임스탬프를 커밋되는 모든 트랜잭션에 적용할 수 있으므로 트랜잭션 커밋 순서가 명확합니다. 외부 일관성을 갖추려면 모든 트랜잭션이 순차적으로 실행되어야 하며, Spanner는 이 strong consistency를 갖도록 보장합니다. 

strong consistency는 많은 애플리케이션 유형, 특히 상품이나 통화의 수량이 유지되는 경우와 eventual consistency(최종 일관성)가 적합하지 않는 경우에 필요합니다. 여기에는 공급망 관리, 소매업체 가격 및 인벤토리 관리, 뱅킹, 무역, 원장 등을 포함해 다양한 유형의 애플리케이션이 있습니다.

데이터베이스에 strong consistency가 없으면 트랜잭션을 여러 개의 별도 작업으로 분할해야 합니다. 원자적 트랜잭션이 아닌 경우에는 트랜잭션 일부가 실패할 수 있습니다. 저녁 식사 비용을 친구와 나누어 내기 위해 디지털 지갑을 사용한다고 가정해보겠습니다. strong consistency 기반의 트랜잭션에서 송금이 이루어지지 않았다면 트랜잭션 중 50%가 실패하며 송금된 돈은 내 지갑에서나 친구의 지갑에서도 찾을 수 없습니다.

eventual consistency의 바람직하지 않은 특성은 이름에서 드러납니다. 데이터베이스 작업 직후에는 전체 데이터베이스 상태가 비일관적이며, 변경사항은 마지막에 가서야 모든 요청자에게 제공됩니다. 그 사이에 각 클라이언트 요청은 서로 다른 결과를 반환할 수 있습니다. 예를 들어 소셜 미디어 서비스를 사용하는 경우 버튼을 눌러 사진을 게시한 후 이미지가 타임라인에 표시될 때까지 지연 시간이 발생할 가능성이 있습니다. Pokemon GO를 개발한 Niantic은 특히 소셜 애플리케이션에서 발생하는 이러한 유형의 비일관성을 차단하기 위해 Spanner를 선택했습니다.

고가용성 보장

Spanner는 계획된 유지보수 및 스키마 변경을 위해 다운타임 없이 최대 99.999%의 가용성을 제공합니다. Spanner는 완전 관리형 서비스이므로 유지보수를 수행할 필요가 없으며, 자동 소프트웨어 업데이트와 인스턴스 최적화는 백그라운드에서 실행됩니다. 이를 위한 별도의 유지보수 기간은 필요하지 않습니다. 또한 하드웨어 오류가 발생한 경우에도 다운타임없이 원활하게 데이터베이스가 복구됩니다.

Spanner 인스턴스는 리전 인스턴스의 경우 단일 클라우드 리전 내 독립 영역에 있는 3개의 복제본 간, 멀티 리전 인스턴스의 경우 두 클라우드 리전의 독립 영역에 있는 4개 이상의 복제본 간에 동기식 복제를 통해 고가용성을 보장합니다. Spanner 리전 인스턴스는 아시아 태평양, 미주, 유럽, 중동, 아프리카 지역의 여러 리전에서 사용할 수 있으며 멀티 리전 인스턴스는 전 세계 여러 멀티 리전 구성에서 제공됩니다.

이렇게 하면 리전 인스턴스 구성의 인프라 및 영역 장애, 멀티 리전 인스턴스 구성의 리전 장애로부터 애플리케이션을 보호할 수 있습니다.

읽기 전용 복제본

소량의 데이터 비활성화가 허용되는 읽기 요청을 처리하는 경우 이러한 복제본이 제공하는 컴퓨팅 성능을 효율적으로 활용하면 평균 읽기 지연 시간이 더 짧은 결과가 반환됩니다. 애플리케이션 클라이언트와 지리적으로 가까운 위치에 복제본이 있는 멀티 리전 인스턴스 구성을 사용할 경우 지연 시간 감소 폭이 커질 수 있습니다.

이 제약조건이 허용되는 쿼리의 복제본은 읽기-쓰기 복제본(분할 리더)을 참조하지 않고도 비활성 읽기 쿼리에 직접 응답할 수 있습니다. 멀티 리전 인스턴스 구성의 경우 복제본이 애플리케이션 클라이언트와 지리적으로 훨씬 더 가까울 수 있으므로 읽기 성능이 크게 향상됩니다.

이 기능은 기존 RDBMS 토폴로지를 비동기식 읽기 복제본으로 배포할 때 달성되는 수평 확장 기능과 비슷합니다. 그러나 Spanner는 일반적인 관계형 데이터베이스와 달리 추가 운영 오버헤드 또는 관리 오버헤드 없이 이 기능을 제공할 수 있습니다.

손쉬운 수평 확장 및 축소

Spanner는 데이터 스토리지에서 컴퓨팅 리소스를 분리하여 기본 스토리지를 변경하지 않고도 처리 리소스 풀을 늘리거나 줄이거나 재할당할 수 있습니다. 단, 기존의 오픈소스 또는 클라우드 기반 관계형 데이터베이스 엔진에서는 불가능합니다.

즉, 클릭 한 번 또는 API 호출 한 번으로 수평 확장이 가능하므로 데이터 처리량이 낮은 경우에도 애플리케이션에 필요한 초당 용량을 더 많이 제공할 수 있습니다. 또한 추가된 컴퓨팅 리소스는 읽기와 쓰기 모두를 처리할 수 있습니다.

축소도 간단합니다. Spanner는 버튼 한 번으로 이 기능을 제공합니다. 요구사항의 변화에 따라 인스턴스 노드를 쉽게 추가하거나 삭제할 수 있고 이러한 변경사항은 단 몇 초 만에 적용됩니다.

관계형 및 NoSQL과 같은 다른 데이터베이스의 경우에는 쓰기 용량을 추가하기 위해 클러스터를 수평으로 확장하는 데 상당한 노력이 필요합니다. 게다가 추가된 용량을 삭제하는 작업은 간단하지 않을 수 있으며 경우에 따라 불가능할 수도 있습니다.

범용 데이터베이스로서 두각을 나타내는 Spanner

관계형 데이터베이스는 에드거 F. 커드가 1970년 작성한 논문에 요약된 개념을 기반으로 합니다. RDBMS는 가장 오래된 데이터베이스 기술임에도 불구하고 새로운 프로젝트 대부분에 사용되는 데이터베이스로서 그 위치를 확고히 하고 있습니다.

관계형 데이터베이스는 신뢰할 수 있는 기술이며 성공을 이룬 많은 기업들이 초기에 MySQL 또는 PostgreSQL을 선택한 이유에 대한 정보를 게시했습니다. 개발자가 SQL에 익숙하고 관계형 모델은 제품 개발 프로세스 중에 유연하게 활용할 수 있다는 근거로 여러 기업에서 관계형 데이터베이스를 선택했습니다. (앞서 언급한 바와 같이 데이터 볼륨이 관리 가능한 수준을 넘어서면 관계형 데이터베이스와 관련된 과도한 관리 업무를 논의하기 위해 이러한 근원적 이야기가 계속 이어지는 경우가 대부분입니다.)

물론 Spanner에는 추상적인 개념이 더 많이 포함되어 있습니다. Spanner는 분산형 데이터베이스이며 서버 랙에 위치한 중복 로컬 시계와 GPS 신호를 통해 사용할 수 있는 원격 원자 시계가 포함된 강력한 시스템을 통해 강력한 외부 일관성이 제공됩니다. 그러나 이미 익숙한 ANSI SQL과 호환되는 관계형 데이터베이스 인터페이스도 계속 제공합니다. 그 결과 애플리케이션 개발자는 빠르게 숙련도를 갖출 수 있습니다.

Spanner는 Google 내외부의 수많은 크고 작은 애플리케이션에서 그 가치가 입증되었습니다. Spanner는 개발자를 위해 진입 장벽을 낮춤으로써 새로운 아이디어를 자유롭게 시도해 볼 수 있는 기초 기술로서 확고하게 자리 잡았습니다. 

Google의 사용자층이 매우 크고 일부 제품 애플리케이션의 경우 트랜잭션 볼륨이 예외적으로 크지만 훨씬 더 작은 규모의 사용자 집단에 서비스를 제공하고 사용 빈도가 낮은 애플리케이션도 있습니다. Spanner는 두 애플리케이션 카테고리 모두에서 백엔드 데이터 스토리지 서비스 역할을 합니다.

환경을 간소화하고 TCO를 낮춰주는 Spanner

총 소유 비용(TCO)을 고려할 때 Spanner의 운영 비용은 저렴한 편입니다. 또한 기회 비용을 고려하면 투자수익(ROI)이 더 많을 수 있습니다. 시간당 가격을 사용하여 Spanner의 운영 비용을 평가하기 전에 대체 옵션의 다양한 비용과 Spanner에서 제공하는 가치를 전체적으로 대조하여 다른 데이터베이스 옵션과 비교하세요.

먼저 프로덕션급 데이터베이스 실행 비용을 고려해 보세요. 비용 카테고리에는 리소스, 운영, 기회의 세 가지가 있습니다. 리소스 비용은 게시된 정가를 기반으로 하므로 계산이 비교적 간단합니다. 운영 비용은 다양한 작업을 완료하는 데 필요한 팀 구성원 수에 비례하므로 이 비용은 계산하기가 다소 어렵습니다. 기회 비용 계산이 명확하지는 않지만 무시해서는 안 됩니다. 돈이든 시간이든 조직 예산을 하나의 카테고리에 지출하면 다른 기회에 사용할 수 있는 예산이 줄어듭니다.

이 연습에서는 먼저 가상 머신에서 실행되는 자체 관리형 오픈소스 데이터베이스의 정가와 Spanner의 정가를 비교하여 리소스 비용을 설명합니다. 그런 다음 동일한 환경의 운영 부담과 비용을 비교합니다. 마지막으로 Spanner가 제공하는 몇 가지 기회의 가치에 대해 살펴봅니다.

먼저 소규모 가상 머신에서 실행되는 단일 데이터베이스 엔진을 고려할 때 Spanner는 비용이 많이 드는 것처럼 보일 수 있습니다. 그러나 단일 컴퓨팅 노드에서는 프로덕션 데이터베이스를 실행하지 않는 것이 좋습니다. 데이터베이스는 메모리가 충분하고 단기 또는 중기의 성장에 대비해 충분한 여유 공간이 프로비저닝된 영구 디스크가 연결된 중간 크기의 가상 머신에서 실행될 가능성이 높습니다.

그리고 프로덕션 가상 머신과 사양이 동일한 온라인 데이터베이스 복제본이 포함된 고가용성 데이터베이스 토폴로지를 프로비저닝하게 될 가능성이 큽니다. 또한 읽기 전용 워크로드를 위해 추가된 복제본 데이터베이스를 유지할 수도 있습니다.

이 경우 Spanner에서 제공한 것과 동등한 조건의 컴퓨팅 및 스토리지 토폴로지가 준비됩니다. 데이터 복사본 3개와 실행 중인 가상 머신 3개 즉, 쓰기를 관리하는 가상 머신 1개, 고가용성을 위한 복제본 1개, 읽기 전용 워크로드를 제공하는 가상 머신 1개가 있습니다. 여기에는 고가용성을 보장하기 위해 3개 이상의 복제본으로 작업해야 한다는 Spanner의 핵심 원칙이 반영되어 있습니다.

이제 Compute Engine에서 실행되는 데이터베이스 정가와 Spanner의 정가를 비교해 보겠습니다. Spanner 데이터베이스 스토리지의 정가는 영역 영구 디스크 정가의 약 2배입니다.그러나 영구 디스크에 3개의 데이터 복사본을 저장하기 때문에 총 비용은 더 커집니다.

이 토폴로지에서는 동일한 규모의 애플리케이션 데이터에 대해 Spanner 데이터베이스 스토리지 가격은 기존 데이터베이스 스토리지 가격보다 약 3분의 1 저렴합니다. 또한 Spanner를 사용하면 사용한 만큼만 비용을 지불하면 되며 초기에 사용하지 않은 공간을 미리 프로비저닝할 필요가 없으므로 비용이 절감됩니다. 또한 기존 데이터베이스와 달리 데이터 규모가 감소하면 스토리지 비용을 절감하기 위해 마이그레이션할 필요가 없습니다.

성능은 워크로드에 따라 달라지므로 컴퓨팅 리소스 가격 비교는 조금 더 복잡합니다. 프로덕션급 가상 머신에서 3방향으로 복제된 기존 RDBMS의 가격을 동일한 수의 Spanner 노드 수와 비교하여 상대적인 가격을 파악할 수 있습니다.

그러나 여기서 끝이 아닙니다. 아시다시피 자체 데이터베이스를 관리하는 데 드는 운영 비용을 대수롭지 않게 여겨서는 안 됩니다. 또한 모든 운영 작업은 시스템 업타임에 위험을 가중할 수 있습니다. Spanner는 낮은 수준의 운영 오버헤드로 높은 수준의 서비스를 제공하도록 설계되었습니다.

일반적으로 Spanner의 운영 비용은 0에 가깝습니다. 우선 Spanner는 데이터베이스 백업을 가져와 보관하는 데 필요한 운영 부담을 줄여줍니다. Spanner는 유지보수 기간이나 계획된 다운타임이 필요하지 않습니다. 수동으로 문제를 해결하거나 Spanner를 통해 색인을 새로 생성할 필요도 없습니다. 또한 데이터베이스에 사용할 수 있는 스토리지 크기를 늘리기 위한 어떤 노력도 필요하지 않습니다. (인스턴스 노드 수를 늘리기 위해 버튼을 클릭하는 일은 '노력'이라고 할 수 없죠.) 가장 중요한 것은 Spanner는 동적 데이터 재샤딩 및 데이터 복제를 자동으로 수행하기 때문에 수평 또는 수직 확장을 달성하기 위해 어떤 노력(단, 버튼을 클릭하는 수고는 제외)도 필요하지 않다는 점입니다.

Enterprise Strategy Group은 Google Cloud Spanner 관계형 데이터베이스 서비스의 경제적 이점 분석보고서에서 Spanner 사용에 따른 총 소유 비용(TCO) 절감액을 수량화했습니다. Enterprise Strategy Group에 따르면 인터뷰에 참여한 모든 고객이 TCO 절감은 물론 향상된 유연성과 혁신에 따른 이점을 근거로 다른 데이터베이스 옵션보다 Spanner를 선호하는 것으로 나타났습니다. Spanner의 총 소유 비용은 온프레미스 데이터베이스보다 78%, 다른 클라우도 옵션보다 37% 낮습니다. 이렇게 운영 부담이 줄어들면서 보다 수익성 높은 다른 중요한 업무에 집중할 수 있게 되었습니다. 이것이 바로 Spanner가 제공하는 기회 가치입니다.

시작하기

Spanner는 뛰어난 성능을 발휘하며 작동도 매우 간편합니다. Spanner는 Google의 철저한 검증을 거쳤으며 고객에게 이 기술을 제공하게 된 것을 자랑스럽게 생각합니다. 워크로드 범위나 크기에 관계없이 다음 프로젝트에 Spanner를 사용해야 하는 확실한 이유가 있습니다. Google은 Cloud Storage의 객체 나열을 보장하기 위해 Google Cloud에서 Spanner를 사용하기로 결정했으며 Colopl과 같은 고객사도 Dragon Quest Walk 서비스를 제공하는 데 도움이 되는 Spanner를 선택했습니다. Spanner는 이미 익숙한 관계형 시맨틱스 및 쿼리 언어를 제공할 뿐만 아니라 탁월한 유연성으로 관계형 데이터베이스를 데이터 스토리지를 위한 최상의 선택으로 만들어냈습니다. 애플리케이션의 크기나 비즈니스 목표에 관계없이 Spanner는 귀사에게도 훌륭한 선택이 될 것입니다.

자세히 알아보기