2022년 1월 25일 화요일

클라우드 환경에서의 데이터베이스 가용성

데이터베이스 가용성 (high availability1)은 수많은 미션 크리티컬 시스템을 구성하는데에 오랫동안 중요한 요건으로 꼽히고 있다. 특히 Transaction2의 개념이 추가가 되면 ACID (Atomicity, Consistency, Isolation, Durability) 3요건도 충족을 해야한다. 많은 데이터베이스 회사들이 Transaction을 지원하기 위해 제품 자체적으로 ACID 요건을 충족하고 있으나, 기본적으로 on-premises보다 장애가 많이 발생하는 클라우드 환경에서 Transaction과 함께 가용성도 같이 보장하기에 어려운 부분들이 존재한다. 이번 글에서는 여러 데이터베이스 회사들이 크게 어떤 방식으로 가용성을 보장하는지 살펴보고 이에 따르는 한계점도 살펴보고자 한다.

  1. Shared Nothing4에서 Replication (복제)를 이용한 가용성

대부분의 클라우드 네이티브 데이터베이스들은 shared nothing architecture와 유사한 architecture를 가지고 있다. 이는 한개의 컴퓨팅 노드가 특정 데이터를 관리하고 해당 특정 데이터를 다른 노드들이 접근 가능한 저장소로 복제를 하는 architecture이다. GCP Spanner, MongoDB 등 Transaction을 보장하는 클라우드 네이티브 데이터베이스들은 이 방식을 이용한다. 이때 데이터 자체를 복제하면 시간이 오래걸리기에 통상적으로 log 데이터나 변경된 데이터만 보내서 되도록이면 전송해야하는 데이터 양을 줄이려고 한다. 이런 방식을 이용해서 Transaction을 보장하는 동시에 어느 특정 노드가 문제가 발생하였을 경우, 다른 노드를 이용해서 가용성을 보장하게 된다. 지속적으로 노드들을 추가하면 horizontal scaling을 할 수 있기때문에 확장성에서는 아주 뛰어난 architecture이다.

하지만 이런 방식의 한계점은 성능과 Transaction 보장의 반비례가 발생한다. 예를 들어서 특정 레코드를 변경하고 commit을 했을 때에 마스터 노드로부터 synchronous하게 복제(replication)가 발생하고 (모든 transaction의 보장) 복제(replication)를 해야할 노드가 여러개라면 이 모든 노드들에게 해당 변경분이 적용되는 동안 transaction은 기다려야한다. 이는 높은 성능이 보장되어야하는 업무에서는 맞지 않는 구조일 가능성이 높다. 반대로 asynchronous하게 복제(replication)가 발생한다면, commit 후 미쳐 변경된 부분이 다른 노드들에 적용되기 전에 마스터 노드에 문제가 발생하였다면, 이는 commit된 데이터가 결과값에 보이지 않게 되고 심하면 데이터가 손실될 가능성이 있다.

물론 위와 같은 한계를 극복하기 위해서 여러가지 다른 방식으로 문제를 해결하기도 한다. 예를 들어서 특정 몇개의 노드들만 synchronous하게 복제(replication)을 한다던가 등등 많은 환경들을 지원할 수 있는 방법을 찾고 있으나, 근본적인 문제는 여전히 존재한다.

2. Shared Disk5에서의 가용성

여러 노드에서 cluster된 같은 Storage에 접근이 가능하게 하는 architecture가 shared disk architecture인데, 이는 Oracle Cloud Infrastructure Autonomous Database와 AWS Aurora가 사용하는 architecture이다. 이 architecture에서는 모든 노드들이 하나의 storage를 보기 때문에 Transaction의 보장도 쉽고, 특정 노드가 문제가 생겼을 때에 다른 노드에서도 작업이 가능함으로 높은 가용성을 보장한다.

하지만 storage가 문제가 생겼을 때를 대비해야해서 shared storage내의 데이터 복제(replication)가 중요하고 이 성능을 보장하기 위해서는 shared disk가 여러개의 데이터 센터에 분산되어있다면 모여있는 것보다는 성능에 문제가 될 수 있다. 또한 모든 노드나 여러 노드들에서 데이터의 추가나 변경이 가능하려면 각 노드들끼리 통신을 해야하는데 모든 transaction별로 통신을 하기에는 클라우드의 네트워크 환경에서 힘든 부분이 존재한다. 이 한계점들을 종합하면, 요즘 많이 화두가 되는 Global Database를 지원하면서 여러 노드에서 데이터 추가나 변경은 이 architecture의 한계점이다.

물론 이런 한계점을 극복하기 위해서 하나의 노드에서만 데이터 추가나 변경이 가능하게 하고 Global Database를 지원하기도 한다.

크게 이 두가지 architecture를 비교해서 각 업무의 특성에 맞는 architecture를 우선 결정한 후에, 그 architecture를 지원하는 클라우드 데이터베이스 서비스 혹은 제품을 선택하는 것이 추후 추가적인 요구사항들에 유연하게 대처할 수 있는 방법이라고 생각한다.

  1. Defining Database Availability
  2. Database transaction
  3. ACID
  4. Shared Nothing v.s. Shared Disk Architectures: An Independent View
  5. Shared Nothing v.s. Shared Disk Architectures: An Independent View

    Related Posts

    클라우드 서비스와 오픈소스 라이선싱
    ML 모델 도입을 위한 SageMaker의 효율성
    Cloud 환경에서의 효율적인 보안 및 인증 관리

    Leave a Reply