Google Cloud Datastore로 강력한 일관성과 최종 일관성 간에 균형 유지

일관적인 사용자 경험을 제공하고 최종 일관성 모델을 활용하여 대규모 데이터세트에 맞게 확장

이 문서에서는 만족스러운 사용자 경험을 위해 강력한 일관성을 달성하는 동시에, 대규모의 데이터와 사용자를 처리하기 위해 Google Cloud Datastore의 일관성 모델을 도입하는 방법을 설명합니다.

이 문서는 Cloud Datastore에서 솔루션을 빌드하고자 하는 소프트웨어 설계자와 엔지니어를 위해 마련되었습니다. Cloud Datastore와 같은 비관계형 시스템보다 관계형 데이터베이스에 좀 더 익숙한 개발자에게 도움을 주기 위해 이 문서는 관계형 데이터베이스와 유사한 개념에 대해서도 언급합니다. 이 문서에서는 개발자가 Cloud Datastore에 대한 기본 지식을 숙지하고 있다고 가정합니다. Cloud Datastore를 시작하는 가장 쉬운 방법은 지원 언어 중 하나를 사용하여 Google App Engine을 사용하는 것입니다. App Engine을 사용해 본 경험이 없다면 이러한 언어 중 하나에 해당하는 시작 가이드데이터 저장 섹션을 먼저 읽어보는 것이 좋습니다. 예제 코드 조각에 Python이 사용되었지만 이 문서를 이해하는 데 Python에 대한 전문 지식은 필요하지 않습니다.

참고: 이 문서의 코드 스니펫은 Cloud Datastore용 Python DB 클라이언트 라이브러리를 사용하지만 더 이상 권장되지 않습니다. 새로운 애플리케이션을 빌드하는 개발자에게는 NDB Client Library 사용을 적극 권장합니다. 기존 클라이언트 라이브러리에 비해 Memcache API를 통한 자동 항목 캐싱과 같은 여러 이점이 있습니다. 현재 기존 DB 클라이언트 라이브러리를 사용하는 중이라면 DB에서 NDB로의 마이그레이션 가이드를 참조하세요.

목차

NoSQL 및 최종 일관성
Cloud Datastore의 최종 일관성
상위 쿼리 및 항목 그룹
항목 그룹 및 상위 쿼리 제한사항
상위 쿼리 대안
완전한 일관성을 확보하기 위한 시간 최소화
결론
추가 리소스

NoSQL 및 최종 일관성

NoSQL 데이터베이스라고도 알려져 있는 비관계형 데이터베이스는 최근에 이르러 관계형 데이터베이스의 대안으로 떠오르고 있습니다. Cloud Datastore는 업계에서 가장 널리 사용되는 비관계형 데이터베이스 중 하나입니다. 2013년 기준 Cloud Datastore의 월별 트랜잭션 처리량은 4조 5천억 개에 달합니다(Google Cloud Platform 블로그 게시물). Cloud Datastore는 개발자가 데이터를 저장하고 데이터에 액세스할 수 있는 더욱 단순화된 방법을 제공합니다. 유연한 스키마는 객체 지향 스크립트 언어에 자연스럽게 매핑됩니다. 또한 Cloud Datastore는 초대형 규모에서 보장되는 고성능과 높은 확장성을 비롯하여, 관계형 데이터베이스에서 최적으로 제공할 수 없는 여러 가지 기능을 제공합니다.

관계형 데이터베이스에 좀 더 익숙한 개발자의 경우, 비관계형 데이터베이스의 일부 특성과 사례가 상대적으로 익숙하지 않아 비관계형 데이터베이스를 활용하는 시스템을 설계하는 것이 어려울 수도 있습니다. Cloud Datastore 프로그래밍 모델은 단순하지만 어떤 특성이 있는지 숙지하고 있어야 합니다. 최종 일관성이 바로 이러한 특성 중 하나에 해당하며, 최종 일관성을 위한 프로그래밍이 이 문서의 기본 주제가 됩니다.

최종 일관성이란?

최종 일관성은 항목이 새롭게 업데이트되지 않는다는 전제하에 항목의 모든 읽기 작업이 최종적으로는 마지막으로 업데이트된 값을 반환한다는 것을 이론적으로 보장합니다. 인터넷 DNS(도메인 이름 시스템)는 최종 일관성 모델이 사용된 시스템의 예로 잘 알려져 있습니다. DNS 서버는 꼭 최신 값을 반영할 필요가 없지만, 인터넷상의 수많은 디렉토리에서 값이 캐싱되고 복제됩니다. 수정된 값을 모든 DNS 클라이언트와 서버에 복제하려면 어느 정도의 시간이 소요됩니다. 하지만 DNS 시스템은 인터넷의 근간을 이루는 요소 중 하나가 된 매우 성공적인 시스템입니다. DNS는 가용성이 매우 높으며 엄청난 확장성이 증명되었고, 인터넷 전체에서 수천만 대 기기의 이름 조회를 가능하게 하고 있습니다.

그림 1은 최종 일관성을 지닌 복제의 개념을 보여줍니다. 이 다이어그램에서 복제본을 읽는 것은 언제든 가능하지만 일부 복제본은 특정 시점에 상위 노드에 쓰여진 값과 일치하지 않을 수 있음을 볼 수 있습니다. 다이어그램에서 노드 A는 상위 노드이며 노드 B와 C는 복제본입니다.

그림 1: 최종 일관성에서 복제의 개념적인 묘사

반대로 기존의 관계형 데이터베이스는 즉각적 일관성으로도 불리는 강력한 일관성의 개념에 기반하여 설계되었습니다. 즉, 업데이트 즉시 조회된 데이터는 항목을 보는 모든 사용자에게 일관성 있게 표시됩니다. 이러한 특성은 관계형 데이터를 사용하는 많은 개발자에게 기본적인 전제가 되어 왔습니다. 하지만 강력한 일관성을 얻기 위해서는, 개발자가 애플리케이션의 확장성과 성능을 어느 정도 포기해야 합니다. 간단히 말해 업데이트 또는 복제 프로세스 도중에는 데이터를 잠금 설정하여 다른 프로세스에서 동일한 데이터를 업데이트하지 않도록 해야 합니다.

그림 2에는 강력한 일관성에서의 배포 토폴로지 및 복제 프로세스에 대한 개념적인 묘사가 나와 있습니다. 이 다이어그램에서는 복제본이 항상 상위 노드와 일치하는 값을 가지지만 업데이트가 완료되기 전까지 이 값에 액세스할 수 없다는 것을 확인할 수 있습니다.

그림 2: 강력한 일관성에서 복제의 개념적인 묘사

강력한 일관성과 최종 일관성 간 균형 유지

비관계형 데이터베이스는 최근에 와서 주목받고 있으며, 특히 높은 확장성과 높은 가용성을 갖춘 성능을 요구하는 웹 애플리케이션에서 자주 사용되고 있습니다. 비관계형 데이터베이스는 개발자가 각 애플리케이션에서 강력한 일관성과 최종 일관성 사이에서 최적의 균형을 맞출 수 있도록 해줍니다. 개발자는 이를 통해 두 일관성의 장점을 합할 수 있습니다. 예를 들어 '친구 목록에서 특정 시간에 온라인 상태인 사용자 확인하기' 또는 '게시물에서 몇 명의 사용자가 +1을 눌렀는지 확인하기'는 강력한 일관성을 필요로 하지 않는 사용 사례에 해당합니다. 이러한 사용 사례에서 최종 일관성을 활용하면 확장성과 성능을 확보할 수 있습니다. 강력한 일관성을 필요로 하는 사용 사례에는 '사용자가 결제 프로세스를 완료했는지' 또는 '게임 플레이어가 한 전투 세션 동안 획득한 포인트'와 같은 정보가 포함됩니다.

앞선 예를 일반화하면, 매우 많은 항목이 포함된 사용 사례에서는 보통 최종 일관성이 최적의 모델임을 알 수 있습니다. 쿼리가 대량의 결과를 반환하는 경우에는 특정 항목을 포함하거나 제외해도 사용자 경험에 영향을 미치지 않을 가능성이 높습니다. 반면에 항목 수가 적고 맥락이 제한된 사용 사례에서는 강력한 일관성이 필요하다는 것을 알 수 있습니다. 사용자가 맥락을 통해 포함하거나 제외할 항목을 알 수 있으므로 사용자 경험이 영향을 받게 됩니다.

따라서 개발자는 Cloud Datastore의 비관계적 특성을 이해해야 합니다. 다음 섹션에서는 최종 일관성과 강력한 일관성 모델을 조합하여 확장 가능하고 가용성과 성능이 뛰어난 애플리케이션을 제작하는 방법을 설명합니다. 이 과정에서 만족스러운 사용자 경험을 위한 일관성 요구사항 역시 충족시킬 수 있습니다.

Cloud Datastore의 최종 일관성

강력한 일관성으로 데이터를 보려는 경우 올바른 API를 선택해야 합니다. 표 1에는 다양한 Cloud Datastore 쿼리 API와 각 API에 해당하는 일관성 모델이 나와 있습니다.

Cloud Datastore API

항목 값 읽기

색인 읽기

전역 쿼리

최종 일관성

최종 일관성

키 전용 전역 쿼리

해당 없음

최종 일관성

상위 쿼리

강력한 일관성

강력한 일관성

키별 조회(get())

강력한 일관성

해당 없음

표 1: Cloud Datastore 쿼리/호출 가져오기 및 가능한 일관성 동작

상위 쿼리가 없는 Cloud Datastore 쿼리를 전역 쿼리라고 합니다. 이 쿼리는 최종 일관성 모델에서 작동하도록 설계되었습니다. 전역 쿼리는 강력한 일관성을 보장하지 않습니다. 키 전용 전역 쿼리는 항목의 속성 값이 아닌 쿼리와 일치하는 항목의 키만 반환하는 전역 쿼리입니다. 상위 쿼리는 상위 항목을 기준으로 쿼리를 찾습니다. 다음 섹션에서는 각 일관성 동작을 자세하게 다룹니다.

항목 값을 읽는 경우의 최종 일관성

상위 쿼리를 제외하고, 업데이트된 항목 값은 쿼리 실행 시 즉각적으로 표시되지 않을 수 있습니다. 항목 값을 읽는 경우 최종 일관성이 미치는 영향을 이해하려면 플레이어 항목에 점수 속성이 있는 시나리오를 생각해 보세요. 예를 들어 초기 점수 값이 100이라고 가정해 보겠습니다. 시간이 어느 정도 지난 후에는 점수 값이 200으로 업데이트됩니다. 전역 쿼리가 실행되고 결과에 동일한 플레이어 항목이 포함되는 경우 반환된 항목의 점수 속성 값이 변경되지 않고 100으로 표시될 가능성이 있습니다.

이러한 동작은 Cloud Datastore 서버 간 복제에 의해 발생합니다. 복제는 Cloud Datastore의 기반 기술인 Cloud Bigtable과 Megastore에 의해 관리됩니다(Cloud Bigtable 및 Megastore에 대한 자세한 내용은 추가 리소스 참조). 복제는 Paxos 알고리즘으로 실행되며, 이 알고리즘에서는 복제본 대다수가 업데이트 요청을 인식할 때까지 동기식으로 대기합니다. 복제본은 일정 기간이 지난 후에 요청의 데이터로 업데이트됩니다. 이 기간은 보통 짧지만 실제 어느 정도인지 알 수는 없습니다. 업데이트가 완료되기 전에 쿼리가 실행되는 경우 쿼리에서 오래된 데이터를 읽어 올 수 있습니다.

대부분의 경우 모든 복제본에서 업데이트가 매우 빠르게 적용됩니다. 하지만 복합적으로 작용하는 경우 일관성을 확보하는 시간을 늘리는 몇 가지 요인이 있습니다. 이러한 요인에는 데이터 센터 간에 다수의 서버 전환 작업을 수반하는 모든 데이터 센터 전반의 이슈가 포함됩니다. 이러한 요인이 다양하다는 점을 고려한다면, 완전한 일관성을 얻는 데 요구되는 확정적인 시간을 제공하는 것은 불가능하다고 할 수 있습니다.

쿼리가 최신 값을 반환하는 데 필요한 시간은 일반적으로 매우 짧습니다. 하지만 복제 지연 시간이 증가하는 드문 경우, 소요 시간이 더 길어질 수 있습니다. Cloud Datastore 전역 쿼리를 사용하는 애플리케이션은 이러한 경우를 원활하게 처리할 수 있도록 유의해서 설계해야 합니다.

항목 값 읽기에서의 최종 일관성은 키 전용 쿼리, 상위 쿼리 또는 키별 조회(get() 메소드)를 사용하여 피할 수 있습니다. 이러한 여러 유형의 쿼리는 아래에서 더욱 자세하게 다루도록 하겠습니다.

색인 읽기에서의 최종 일관성

전역 쿼리 실행 시 색인이 업데이트된 상태가 아닐 수 있습니다. 즉, 항목의 최신 속성 값을 읽을 수 있다 하더라도 쿼리 결과에 포함된 '항목 목록'이 기존 색인 값에 따라 필터링될 수 있습니다.

색인을 읽는 경우에서 최종 일관성의 영향을 이해하려면 새 항목 플레이어가 Cloud Datastore에 삽입되는 경우를 가정해 보세요. 항목에 초기 값이 300인 점수 속성이 있습니다. 항목을 삽입한 직후, 키 전용 쿼리를 실행하여 0보다 큰 점수 값이 포함된 모든 항목을 가져옵니다. 이때 최근에 삽입된 플레이어 항목이 쿼리 결과에 표시되리라 예상할 것입니다. 하지만 예상 외로 플레이어 항목이 결과에 표시되지 않는 것을 확인할 수 있습니다. 이러한 상황은 쿼리 실행 시 점수 속성의 색인 표가 새로 삽입한 값으로 업데이트되지 않았을 경우에 발생할 수 있습니다.

Cloud Datastore의 모든 쿼리는 색인 테이블을 기준으로 실행되지만 색인 테이블의 업데이트는 비동기식으로 진행됩니다. 모든 항목 업데이트는 기본적으로 두 단계로 이뤄집니다. 첫 단계인 커밋 단계에서는 트랜잭션 로그에 쓰기가 수행됩니다. 두 번째 단계에서는 데이터가 기록되고 색인이 업데이트됩니다. 커밋 단계가 성공하면 쓰기 단계 또한 성공이 보장되지만, 즉시 수행되지는 않습니다. 색인이 업데이트되기 전에 항목을 쿼리하면 일관성이 충족되지 않은 데이터가 표시될 수 있습니다.

이러한 2단계 프로세스로 인해 항목의 최신 업데이트가 전역 쿼리에 표시되기까지 시간 지연이 있게 됩니다. 항목 값 최종 일관성과 마찬가지로 지연 시간은 보통 짧지만 좀 더 오래 걸릴 수도 있습니다(예외적인 상황에서는 수분 이상이 소요될 수도 있음).

업데이트 후에도 동일한 상황이 발생할 수 있습니다. 예를 들어 기존 항목 플레이어를 새 점수 속성 값인 0으로 업데이트한 다음 동일한 쿼리를 즉시 실행했다고 가정해 보겠습니다. 새 점수 값인 0으로 인해 이 항목이 제외되므로 쿼리 결과에 나타나지 않으리라고 예상할 것입니다. 하지만 동일한 비동기 색인 업데이트 동작으로 인해 항목이 결과에 계속 포함될 수도 있습니다.

색인 읽기에서의 최종 일관성은 상위 쿼리 또는 키별 조회 메소드를 사용하는 경우에만 피할 수 있습니다. 키 전용 쿼리로는 이 동작을 피할 수 없습니다.

항목 값 및 색인을 읽는 경우의 강력한 일관성

Cloud Datastore에서 항목 값 및 색인 읽기에 강력한 일관성으로 보기를 제공하는 API는 (1) 키별 조회 메소드 및 (2) 상위 쿼리 두 가지가 있습니다. 애플리케이션 로직에서 강력한 일관성을 요구하는 경우 개발자는 두 메소드 중 하나를 사용하여 Cloud Datastore의 항목을 읽어야 합니다.

Cloud Datastore는 이러한 API에 강력한 일관성을 제공하도록 특별히 설계되었습니다. 두 API 중 하나를 호출할 때 Cloud Datastore는 복제본과 색인 표 중 하나에서 대기 중인 모든 업데이트를 지운 다음 조회 또는 상위 쿼리를 실행합니다. 그러면 업데이트된 색인 표에 따라 최신 항목 값이 항상 최신 업데이트를 따른 값으로 반환됩니다.

키별 조회 호출은 쿼리와 반대로, 키 또는 키 모음에 의해 지정된 단일 항목이나 항목 모음만을 반환합니다. 즉, Cloud Datastore에서는 상위 쿼리만이 필터링 요구사항과 함께 강력한 일관성 요구사항을 충족시킬 수 있는 유일한 방법이 됩니다. 하지만 항목 그룹을 지정하지 않으면 상위 쿼리가 작동하지 않습니다.

상위 쿼리 및 항목 그룹

문서 초반에 설명한 것처럼, Cloud Datastore의 장점 중 하나는 개발자가 강력한 일관성과 최종 일관성 간에 최적의 균형을 찾을 수 있다는 점입니다. Cloud Datastore에서 항목 그룹은 강력한 일관성, 트랜잭션 특성 및 집약성을 갖춘 단위입니다. 개발자는 항목 그룹을 활용하여 애플리케이션 내 항목에서 강력한 일관성의 범위를 정의할 수 있습니다. 이러한 방식을 통해 애플리케이션은 항목 그룹 내에서 일관성을 유지할 수 있는 한편, 동시에 완전한 시스템으로서의 높은 확장성, 가용성 및 성능을 확보할 수 있습니다.

항목 그룹은 루트 항목과 그 하위 항목 또는 후속 항목에 의해 형성되는 계층구조입니다.[1] 항목 그룹을 생성하려면 개발자는 상위 경로를 지정해야 하며, 이는 기본적으로 하위 키 앞에 붙는 일련의 상위 키입니다. 그림 3은 항목 그룹의 개념을 보여줍니다. 이 경우에서 'ateam' 키가 있는 루트 항목에는 'ateam/098745' 및 'ateam/098746' 키가 있는 두 개의 하위 항목이 있습니다.

그림 3: 항목 그룹 개념의 도식적인 보기

항목 그룹 내에서는 다음과 같은 특성이 보장됩니다.

  • 강력한 일관성
    • 항목 그룹의 상위 쿼리는 강력한 일관성으로 결과를 반환합니다. 이러한 방식으로, 항목 그룹은 최신 색인 상태에 의해 필터링된 최신 항목 값을 반영합니다.
  • 트랜잭션 특성
    • 트랜잭션을 프로그램 방식으로 구분함으로써 항목 그룹은 트랜잭션에 ACID(Atomicity(개별성), Consistency(일관성), Isolation(격리성) 및 Durability(지속성)) 특성을 제공합니다.
  • 지역
    • 항목 그룹의 항목은 물리적으로 Cloud Datastore 서버와 근접한 위치에 저장됩니다. 이는 모든 항목이 키의 사전식 순서에 따라 정렬 및 저장되기 때문입니다. 따라서 상위 쿼리는 최소한의 I/O로 항목 그룹을 빠르게 스캔할 수 있습니다.

상위 쿼리는 지정된 항목 그룹에 대해서만 실행되는 특수한 형식의 쿼리이며, 강력한 일관성으로 실행됩니다. 백그라운드에서 Cloud Datastore는 대기 중인 모든 복제 및 색인 업데이트가 쿼리를 실행하기 전에 적용된다고 가정합니다.

상위 쿼리 예제

이 섹션에서는 항목 그룹과 상위 쿼리를 실제로 사용하는 방법을 설명합니다. 다음 예제에서는 사용자의 데이터 기록을 관리하는 문제를 고민해 볼 것입니다. 특정한 종류의 항목을 추가하고 바로 뒤에 이 종류에 대한 쿼리가 나오는 코드가 있다고 가정해 보겠습니다. 아래의 예제 Python 코드가 이러한 개념을 보여줍니다.

# Define the Person entity
class Person(db.Model):
    given_name = db.StringProperty()
    surname = db.StringProperty()
    organization = db.StringProperty()
# Add a person and retrieve the list of all people
class MainPage(webapp2.RequestHandler):
    def post(self):
        person = Person(given_name='GI', surname='Joe', organization='ATeam')
        person.put()
        q = db.GqlQuery("SELECT * FROM Person")
        people = []
        for p in q.run():
            people.append({'given_name': p.given_name,
                        'surname': p.surname,
                        'organization': p.organization})

대부분의 경우 이 코드의 문제는 위의 구문에서 추가된 항목이 쿼리에 의해 반환되지 않는 데 있습니다. 삽입 바로 뒤에 오는 행에 쿼리가 있으므로 쿼리가 실행될 때 색인이 업데이트되지 않습니다. 또한 이 사용 사례의 유효성에도 문제가 있습니다. 굳이 맥락 없이 한 페이지에 모든 사용자 목록을 반환해야 할 이유가 있을까요? 사용자 수가 백만 명일 경우에는 어떻게 될까요? 페이지를 반환하는 데 너무 많은 시간이 소요될 것입니다.

사용 사례의 특성을 통해 맥락을 어느 정도 제공하여 쿼리의 범위를 좁혀야 한다는 것을 알 수 있습니다. 다음 예제에서는 조직을 맥락으로 사용해 보겠습니다. 그러면 조직을 항목 그룹으로 사용하고 상위 쿼리를 실행하여 일관성 문제를 해결할 수 있습니다. 아래의 Python 코드가 이러한 사례를 보여줍니다.

class Organization(db.Model):
    name = db.StringProperty()
class Person(db.Model):
    given_name = db.StringProperty()
    surname = db.StringProperty()
class MainPage(webapp2.RequestHandler):
    def post(self):
        org = Organization.get_or_insert('ateam', name='ATeam')
        person = Person(parent=org)
        person.given_name='GI'
        person.surname='Joe'
        person.put()
        q = db.GqlQuery("SELECT * FROM Person WHERE ANCESTOR IS :1 ", org)
        people = []
        for p in q.run():
            people.append({'given_name': p.given_name,
                        'surname': p.surname})

이번에는 GqlQuery에 상위 조직이 지정되었고, 쿼리에서 방금 삽입된 항목을 반환합니다. 이 예제를 확대 적용해 보면, 쿼리의 일부로 상위 항목과 함께 사용자 이름을 쿼리하여 개별 사용자까지 상세하게 찾을 수도 있습니다. 또는 항목 키를 저장한 다음 키별 조회로 상세하게 찾는 데 이를 사용하여 동일한 작업을 수행할 수도 있습니다.

Memcache 및 Cloud Datastore 간에 일관성 유지

항목 그룹은 Memcache 및 Cloud Datastore 항목 간에 일관성을 유지하기 위한 단위로 사용할 수도 있습니다. 예를 들어 각 팀의 사용자 수를 계산하여 Memcache에 저장한다고 가정해 보겠습니다. 캐싱된 데이터가 Cloud Datastore의 최신 값과 일치하도록 하려면 항목 그룹 메타데이터를 사용합니다. 메타데이터에서 지정된 항목 그룹의 수를 최신 버전으로 반환하므로 이 버전의 수와 Memcache에 저장된 수를 비교할 수 있습니다. 이 방식을 사용하면 그룹의 모든 개별 항목을 스캔하는 대신, 메타데이터 모음 하나를 읽어 전체 항목 그룹에 있는 모든 항목의 변경사항을 감지할 수 있습니다.

항목 그룹 및 상위 쿼리 제한사항

항목 그룹과 상위 쿼리를 사용한다고 해서 모든 것이 해결되지는 않습니다. 아래에 나와 있는 것처럼, 실제로 이 기술을 일반적으로 적용하기 어렵게 하는 두 가지 문제가 있습니다.

  1. 각 항목 그룹에서 업데이트 쓰기 횟수가 초당 1회로 제한됩니다.
  2. 항목 생성 후에는 항목 그룹 관계를 변경할 수 없습니다.

쓰기 한도

한 가지 중요한 문제는 각 항목 그룹에 업데이트 또는 트랜잭션 횟수가 포함되도록 시스템을 설계해야 한다는 것입니다. 제한으로 인해 항목 그룹별로 초당 1회의 업데이트만 지원됩니다.[2] 업데이트 수가 한도를 초과해야 하는 경우에는 항목 그룹에서 성능 병목 현상이 발생할 수 있습니다.

위의 예제에서 각 조직은 조직 내 사용자의 기록을 업데이트해야 할 수도 있습니다. 'ateam'에 1,000명의 사용자가 있고, 각 사용자가 모든 속성에서 초당 1회의 업데이트를 수행한다고 가정해 보겠습니다. 그러면 항목 그룹에 초당 최대 1,000회의 업데이트가 발생할 수 있습니다. 하지만 업데이트 제한이 있기 때문에 이러한 결과를 얻을 수 없습니다. 이는 성능 요구사항을 고려하여 적절한 항목 그룹 디자인을 선택하는 것이 중요하다는 것을 알려줍니다. 이러한 점이 최종 일관성과 강력한 일관성 간에 최적의 균형을 찾기가 어려운 이유 중 하나입니다.

항목 그룹 관계의 불변성

두 번째 문제는 항목 그룹 관계를 변경할 수 없다는 데 있습니다. 항목 그룹 관계는 키 이름 지정 방식에 따라 정적으로 형성되며, 항목을 생성한 후에는 변경할 수 없습니다. 관계를 변경할 수 있는 유일한 방법은 항목 그룹의 항목을 삭제하고 다시 생성하는 것입니다. 이러한 문제로 인해 항목 그룹을 사용하여 일관성의 범위를 즉석에서 정의하거나 트랜잭션 특성을 동적으로 정의할 수 없습니다. 대신 일관성 및 트랜잭션 특성 범위는 설계 시 정의된 정적 항목 그룹과 밀접하게 연결됩니다.

예를 들어 두 은행 계좌 간에 송금을 구현하고자 하는 시나리오를 가정해 보겠습니다. 이 비즈니스 시나리오에서는 강력한 일관성과 트랜잭션 특성이 요구됩니다. 하지만 두 계좌를 마지막 순간에 한 항목 그룹으로 그룹화하거나, 전역적 상위 항목에 기반할 수 없습니다. 이러한 항목 그룹이 있는 경우 전체 시스템에 병목 현상을 야기해 다른 송금 요청의 실행에 지장을 주기 때문입니다. 따라서 이러한 방식으로는 항목 그룹을 사용할 수 없습니다.

확장성과 가용성이 높은 방식으로 송금을 구현할 수 있는 대안이 있습니다. 모든 계좌를 하나의 항목 그룹에 배치하는 대신 각 계좌별로 항목 그룹을 생성하는 것입니다. 이렇게 하면 두 은행 계좌 모두에 ACID 업데이트를 보장하는 트랜잭션을 사용할 수 있습니다. 트랜잭션은 최대 25개의 항목 그룹에 ACID 특성을 갖춘 작업 집합을 생성하는 Cloud Datastore 기능입니다. 트랜잭션 중에는 키별 조회 및 상위 쿼리처럼 일관성이 강력한 쿼리를 사용해야 합니다. 트랜잭션 제한 사항에 대한 자세한 내용은 트랜잭션 및 항목 그룹을 참조하세요.

상위 쿼리 대안

Cloud Datastore에 저장된 다수의 항목이 포함된 기존 애플리케이션을 보유한 경우 이후에 리팩토링 단계에서 항목 그룹을 통합하는 것이 어려울 수도 있습니다. 이를 수행하려면 모든 항목을 삭제한 후 항목 그룹 관계 내에 추가해야 합니다. 따라서 Cloud Datastore의 데이터 모델링에서는 애플리케이션 디자인 초기 단계에서 항목 그룹 디자인을 결정하는 것이 중요합니다. 그렇지 않으면 리팩토링에서 특정 수준의 일관성을 확보하는 데 다른 대안(예: 키별 조회 이후의 키 전용 쿼리 또는 Memcache 사용)으로 제한될 수 있습니다.

키 전용 전역 쿼리 이후의 키별 조회

키 전용 전역 쿼리는 항목의 속성 값이 없는 키만 반환하는 특수한 유형의 전역 쿼리입니다. 값으로 키만 반환되기 때문에 쿼리는 일관성 문제의 소지가 있는 항목 값을 포함하지 않습니다. 키 전용, 전역 쿼리를 조회 메소드와 조합하면 최신 항목 값을 읽을 수 있습니다. 하지만 키 전용 전역 쿼리는 쿼리 시 색인에서 일관성을 확보할 수 없어 항목이 전혀 검색되지 않을 가능성이 있다는 점에 유의하세요. 쿼리 결과는 이전 색인 값의 필터링을 기반으로 생성될 수도 있습니다. 요약하자면 애플리케이션 요구사항에서 쿼리 시 색인 값의 일관성이 확보되지 않아도 된다는 점을 허용하는 경우에만 개발자는 키 전용 전역 쿼리 이후의 키별 조회를 사용할 수 있습니다.

Memcache 사용

Memcache 서비스는 변수가 많지만 강력한 일관성을 제공합니다. 따라서 Memcache 조회와 Cloud Datastore 쿼리를 조합하면 대부분의 상황에서 일관성 문제를 최소화할 수 있는 시스템을 구축할 수 있습니다.

예를 들어 각각 점수가 0보다 큰 플레이어 항목 목록을 유지관리하는 게임 애플리케이션이 있다고 가정해 보겠습니다.

  • 삽입 또는 업데이트 요청의 경우, Memcache뿐만 아니라 Cloud Datastore의 플레이어 항목 목록에도 요청을 적용합니다.
  • 쿼리 요청의 경우, Memcache에서 플레이어 항목 목록을 읽고, Memcache에 목록이 없는 경우 Cloud Datastore에서 키 전용 쿼리를 실행합니다.

반환된 목록은 Memcache에 캐싱된 목록이 있을 때는 항상 일관성을 가지게 됩니다. 항목이 삭제되었거나 Memcache 서비스를 일시적으로 사용할 수 없는 경우, 시스템에서는 일관성이 없는 결과를 반환할 수도 있는 Cloud Datastore 쿼리에서 값을 읽어야 합니다. 이 기술은 일관성이 없는 것을 조금 허용하는 애플리케이션에 적용할 수 있습니다.

Memcache를 Cloud Datastore의 캐싱 레이어로 사용하는 경우 다음과 같은 몇 가지 권장사항을 확인해 주세요.

  • Memcache 예외 및 오류를 감지하여 Memcache 값과 Cloud Datastore 값의 일관성을 유지합니다. Memcache에서 항목을 업데이트할 때 예외가 표시되면 Memcache의 이전 항목을 무효화해야 합니다. 그렇지 않으면 한 항목이 다른 값을 가질 수 있습니다(Memcache에는 이전 값, Cloud Datastore에는 새 값).
  • Memcache 항목에 만료 기간을 설정합니다. 각 항목의 만료 기간을 짧게 설정하여 Memcache 예외 발생 시 일관성 문제의 가능성을 최소화하는 것이 좋습니다.
  • 동시 실행 제어를 위해 항목을 업데이트하는 경우 비교 및 설정 기능을 사용합니다. 그러면 동일한 항목을 동시에 업데이트하는 경우 서로 간에 충돌이 발생하지 않도록 하는 데 도움이 됩니다.

항목 그룹으로의 점진적인 마이그레이션

이전 섹션의 제안사항은 일관성이 없는 동작의 가능성을 완화할 뿐입니다. 강력한 일관성이 필요한 경우에는 항목 그룹과 상위 쿼리를 기반으로 애플리케이션을 설계하는 것이 좋습니다. 하지만 기존 데이터 모델과 애플리케이션 로직을 전역 쿼리에서 상위 쿼리로 변경해야 할 수도 있는 기존 애플리케이션의 경우, 마이그레이션하기에 적합하지 않을 수도 있습니다. 마이그레이션을 달성하기 위한 한 가지 방법은 다음과 같은 점진적인 전환 과정을 거치는 것입니다.

  1. 애플리케이션에서 강력한 일관성을 요구하는 기능을 파악하고 우선순위를 정합니다.
  2. 기존 로직을 대체하는 대신, 항목 그룹을 사용하여 기존 로직에 insert() 또는 update() 함수의 새 로직을 작성합니다. 그러면 새 항목 그룹과 이전 항목의 새로운 삽입 또는 업데이트가 적절한 함수에 의해 처리될 수 있습니다.
  3. 읽기를 위한 기존 로직을 수정하지 않으면, 요청에 새 항목 그룹이 있는 경우 쿼리 함수 상위 쿼리가 먼저 실행됩니다. 항목 그룹이 없는 경우에는 이전 전역 쿼리를 대체 로직으로 실행합니다.

이러한 방식을 사용하면 최종 일관성으로 인해 발생하는 문제의 위험을 최소화하는 항목 그룹을 기준으로, 기존 데이터 모델에서 새 데이터 모델로 점진적인 마이그레이션을 진행할 수 있습니다. 실질적으로 이러한 접근 방식을 실제 시스템에 적용하는 것은 특정한 사용 사례와 요구사항에 달려 있습니다.

디그레이드 모드로 대체

현재로서는 애플리케이션에서 일관성이 저하되는 경우 이러한 상황을 프로그래매틱 방식으로 감지하는 것이 어렵습니다. 그러나 애플리케이션에서 일관성이 저하된 사실을 다른 방법으로 알게 된 경우, 켜거나 끄는 방식으로 강력한 일관성을 요구하는 애플리케이션 로직의 일부 영역을 사용 중지하는 디그레이드 모드를 구현할 수도 있습니다. 예를 들어 일관성이 없는 쿼리 결과를 결제 보고서 화면에 표시하는 대신 화면에 유지관리 메시지를 대신 표시할 수 있습니다. 그러면 애플리케이션의 다른 서비스를 계속해서 제공할 수 있으며, 사용자 경험에 미치는 영향을 줄일 수 있게 됩니다.

완전한 일관성을 확보하기 위한 시간 최소화

수백만 명의 사용자 또는 테라바이트 단위의 Cloud Datastore 항목이 있는 대규모 애플리케이션에서는 Cloud Datastore를 잘못 사용할 경우 일관성 저하가 발생할 수 있습니다. 다음과 같은 경우가 잘못 사용하는 습관에 해당합니다.

  • 항목 키의 순차적 번호 지정
  • 과도한 색인

이러한 습관은 소규모 애플리케이션에 영향을 미치지 않습니다. 하지만 애플리케이션이 대규모로 확장되면 이러한 습관이 일관성 확보를 위해 필요한 시간을 더 길어지게 할 수 있습니다. 따라서 애플리케이션 설계 초기 단계에 이러한 습관을 버리는 것이 좋습니다.

피해야 할 패턴 1: 항목 키의 순차적 번호 지정

App Engine SDK 1.8.1 출시 이전에는 Cloud Datastore에서 일반적으로 연속적인 패턴을 가지는 일련의 작은 정수 ID를 자동 생성된 기본 키 이름으로 사용했습니다. 몇몇 문서에서는 이를 애플리케이션에서 지정한 키 이름이 없는 항목을 생성하기 위한 '기존 정책'이라고 불렀습니다. 이 기존 정책은 순차적인 번호 지정 방식(예: 1000, 1001, 1002)으로 항목의 키 이름을 생성했습니다. 하지만 앞서 설명한 것처럼 Cloud Datastore에서는 키 이름의 사전순으로 항목을 저장하므로 이러한 항목이 동일한 Cloud Datastore 서버에 저장될 가능성이 높습니다. 애플리케이션에 매우 많은 트래픽이 몰리면 이러한 순차적인 번호 지정 방식으로 인해 작업이 특정 서버에 집중될 수 있으며, 그 결과 일관성에서 지연 시간이 더욱 길어질 수 있습니다.

App Engine SDK 1.8.1에서는 분산형 ID를 사용하는 기본 정책을 포함한 새로운 ID 번호 지정 방식이 Cloud Datastore에 도입되었습니다(참조 문서 확인). 이 기본 정책은 거의 균일하게 분산되는 최대 16자리 ID를 임의의 순서로 생성합니다. 이 정책을 사용하면 대규모 애플리케이션의 트래픽이 Cloud Datastore 서버 집합에서 더 원활히 분산되므로 일관성에 소요되는 시간이 줄어들 가능성이 높아집니다. 애플리케이션에서 특별히 기존 정책과 호환되어야 하지 않는 이상 기본 정책을 사용하는 것이 좋습니다.

항목에 키 이름을 명시적으로 설정하는 경우 전체 키 네임스페이스에서 항목에 균등하게 액세스할 수 있도록 이름 지정 방식을 정해야 합니다. 즉, 키 이름의 사전적 순서에 따라 항목 액세스가 정렬되므로 특정 범위에 액세스를 집중해서는 안 됩니다. 그렇지 않으면 순차적 번호 지정과 동일한 문제가 발생할 수 있습니다.

키스페이스에서의 균등하지 않은 액세스 분배를 이해하려면 다음 코드에 나와 있는 것처럼 항목이 순차적 키 이름으로 생성된 경우를 생각해 보시기 바랍니다.

p1 = Person(key_name='0001')
p2 = Person(key_name='0002')
p3 = Person(key_name='0003')
...

애플리케이션 액세스 패턴은 키 이름의 특정 범위에서 '핫스팟'을 생성할 수 있습니다. 예를 들어 최근 생성된 Person 항목에 액세스가 몰리는 경우가 이에 해당합니다. 이 경우 자주 액세스되는 키는 모두 높은 ID 값을 가지게 되고, 그러면 로드가 특정 Cloud Datastore 서버에 집중됩니다.

또는 키스페이스에서의 균등한 분배를 이해하려면 키 이름에 긴 임의 문자열을 사용하는 경우를 생각해 보시기 바랍니다. 이는 다음 예제에서 확인할 수 있습니다.

p1 = Person(key_name='t9P776g5kAecChuKW4JKCnh44uRvBDhU')
p2 = Person(key_name='hCdVjL2jCzLqRnPdNNcPCAN8Rinug9kq')
p3 = Person(key_name='PaV9fsXCdra7zCMkt7UX3THvFmu6xsUd')
...

이제 최근에 생성한 Person 항목이 키스페이스와 여러 서버에 분산됩니다. 이는 충분한 수의 Person 항목이 존재한다는 가정 하에 이루어집니다.

피해야 할 패턴 2: 과도한 색인

Cloud Datastore에서 한 항목을 업데이트하면 이 항목 종류에 대해 정의된 모든 색인이 업데이트됩니다(자세한 내용은 Datastore 쓰기 과정 참조). 애플리케이션에서 많은 커스텀 색인을 사용하면 1회의 업데이트가 색인 표에서는 수십, 수백 또는 수천 회의 업데이트로 이어질 수 있습니다. 대규모 애플리케이션에서 과도한 수의 커스텀 색인을 사용하면 서버 부하가 증가할 수 있으며, 일관성 확보를 위한 지연 시간이 늘어날 수 있습니다.

대부분의 경우 커스텀 색인은 고객지원, 문제해결 또는 데이터 분석 작업과 같은 지원 요구사항에 추가됩니다. BigQuery는 사전 작성된 색인 없이 대규모 데이터세트에서 즉석 쿼리를 실행할 수 있는 대규모로 확장 가능한 쿼리 엔진으로서, Cloud Datastore보다 복잡한 쿼리가 필요한 고객지원, 문제해결 또는 데이터 분석과 같은 사용 사례에 더 적합합니다.

두 서비스를 모두 활용하는 한 가지 방식은 Cloud Datastore와 BigQuery를 조합하여 다양한 비즈니스 요구사항을 충족시키는 것입니다. 핵심 애플리케이션 로직에 필요한 OLTP(온라인 트랜잭션 처리)에는 Cloud Datastore를, 백엔드 작업을 위한 OLAP(온라인 분석 처리)에는 BigQuery를 사용하세요. 관련 쿼리에 필요한 데이터를 이동하기 위해 Cloud Datastore에서 BigQuery로 데이터를 지속적으로 내보내는 플로를 구현해야 할 수도 있습니다.

커스텀 색인을 위한 대안을 구현하는 것 외에도 색인화되지 않은 속성을 명시적으로 지정하는 방법을 사용할 수도 있습니다(자세한 내용은 참조 문서의 속성 옵션 참조). 기본적으로 Cloud Datastore에서는 항목 종류의 색인할 수 있는 각 속성에 대해 서로 다른 색인 표를 생성합니다. 종류에 100개의 속성이 있는 경우 이 종류에 대해 100개의 색인 표가 생성되며, 항목 하나가 업데이트될 때마다 100개의 추가 업데이트가 생성됩니다. 따라서 가장 좋은 방식은 쿼리 조건에 필요 없는 경우 가능한 속성을 색인화하지 않은 상태로 설정하는 것입니다.

이렇게 색인을 최적화하면 일관성 확보 시간이 늘어나는 가능성을 줄이는 것 외에도 색인을 아주 많이 사용하는 대규모 애플리케이션에서 발생하는 Cloud Datastore 저장 비용을 크게 줄일 수 있습니다.

결론

최종 일관성은 개발자가 확장성, 성능 및 일관성 사이에서 최적의 균형을 찾을 수 있게 해주는 비관계형 데이터베이스의 핵심 요소입니다. 따라서 애플리케이션에 최적화된 데이터 모델을 설계하기 위해서는 최종 일관성과 강력한 일관성 간의 균형을 처리하는 방법을 이해하는 것이 중요합니다. Cloud Datastore에서는 항목 그룹과 상위 쿼리를 사용하는 것이 항목의 범위에서 강력한 일관성을 보장할 수 있는 가장 좋은 방법입니다. 앞서 설명한 제한사항으로 인해 애플리케이션에 항목 그룹을 통합할 수 없는 경우 키 전용 쿼리나 Memcache 사용과 같은 다른 옵션을 고려해 볼 수 있습니다. 대규모 애플리케이션의 경우, 분산된 ID 및 색인화 축소 사용과 같은 권장사항을 적용하여 일관성에 필요한 시간을 줄일 수 있습니다. 또한 Cloud Datastore와 BigQuery를 조합하여 복잡한 쿼리를 위한 비즈니스 요구사항을 충족시키고 Cloud Datastore 색인의 사용을 최소화하는 것도 중요합니다.

추가 리소스

다음 리소스는 이 문서에서 다룬 주제에 대한 자세한 정보를 제공합니다.




[1] 항목 그룹 함수가 모두 키 사이의 관계를 기반하여 구현되므로, 루트 또는 상위 항목의 실제 항목을 저장하지 않고 루트 또는 상위 항목의 키 하나만 지정하여 항목 그룹을 형성할 수도 있습니다.

[2] 제한으로 인해 항목 그룹별로 초당 1회의 업데이트(트랜잭션 이외) 또는 항목 그룹별로 초당 1건의 트랜잭션만 지원됩니다. 한 트랜잭션으로 여러 업데이트를 합하는 경우 최대 트랜잭션 크기가 10MB로, 속도는 Datastore 서버의 최대 쓰기 속도로 제한됩니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Cloud Datastore 문서