당신이 수백만 명의 사람들이 동시에 책을 빌리고, 읽고, 다시 쓰는 거대하고 혼란스러운 도서관을 정리하려고 노력하고 있다고 상상해 보십시오. 컴퓨터 과학의 세계에서 이것은 데이터베이스라는 과제, 즉 애플리케이션이 정보를 즉시 찾고 변경할 수 있도록 정보를 저장하는 시스템에 관한 문제입니다. 수십 년 동안의 큰 질문은 어떻게 하면 이 도서관들이 무너지지 않고 전체 인터넷을 감당할 수 있을 만큼 성장하게 만들 것인가였습니다. 기존 방식은 모든 책에 도장을 찍어야 하는 단 한 명의 사서가 있는 것과 같아서, 줄이 길어지면 속도가 느려졌습니다. 더 새로운 방식인 "최종 일관성(eventual consistency)"은 사람들이 책의 내용을 추측하게 두고 나중에 실수를 바로잡는 방식이었는데, 이는 빠르지만 지금 당장 진실이 필요할 때는 위험할 수 있습니다. 현대적인 데이터베이스 엔지니어링의 목표는 이 추측 방식만큼 빠르면서도 도장을 찍는 방식만큼 신뢰할 수 있고, 아무도 수동으로 선반을 관리할 필요 없이 초당 수백만 건의 트랜잭션을 처리할 수 있는 시스템을 구축하는 것입니다.

이 논문은 바로 이 문제를 해결하기 위해 Amazon Web Services가 설계한 새로운 종류의 데이터베이스인 Aurora DSQL을 소개합니다. 이것을 방문객 수에 따라 즉각적으로 확장하거나 축소할 수 있는 초스마트 자율 주행 도서관이라고 생각하십시오. 저자들은 "생각하는 것"(SQL 코드 실행)과 "저장하는 것"(책 보관), 그리고 "규칙"(두 사람이 동시에 같은 페이지를 수정하지 못하게 하는 것)을 분리하여 시스템을 구축했습니다. 변화가 일어날 때마다 기록되는 영구적이고 변경 불가능한 일기 역할을 하는 특별한 "저널(Journal)"을 사용함으로써, DSQL은 시스템의 각 부분이 독립적으로 작동할 수 있게 합니다. 이 논문은 이러한 설계 덕분에 데이터베이스가 제로(0) 명의 사용자에서 초당 수백만 건의 트랜잭션까지 확장할 수 있고, 속도가 느려지지 않고도 여러 대륙에 걸쳐 작동하며, 누군가 책을 새로 쓰고 있는 동안에도 그 책을 읽어야 할까 봐 걱정할 필요 없이 데이터를 완벽하게 일관되게 유지할 수 있음을 보여줍니다.

분리된 도서관의 마법

Aurora DSQL이 어떻게 작동하는지 이해하려면, 사서와 책장, 그리고 규칙 준수자들이 모두 서로 다른 건물에 있고 초고속 전보로 연결된 거대한 도서관을 상상해 보십시오. 이전의 시스템에서는 이 부분들이 서로 붙어 있었습니다. 즉, 책장이 가득 차면 도서관 전체가 멈춰서 재정리해야 했습니다. DSQL은 이들을 분리합니다.

첫째, **쿼리 프로세서(Query Processors)**가 있습니다. 이들은 당신과 대화하는 사서들입니다. 당신이 책을 요청할 때, 그들은 무거운 책을 직접 옮기지 않습니다. 대신 그들은 Firecracker MicroVM이라 불리는 작고 안전한 가상 공간 안에서 실행됩니다. 이 공간들은 매우 효율적이어서 눈 깜짝할 사이에 생성되거나 파괴될 수 있습니다. 갑자기 방문객이 몰리면 시스템은 즉시 더 많은 방을 만듭니다. 방문객이 줄어들면 빈 공간에 대한 비용을 지불하지 않도록 그 방들을 허뭅니다. 이것이 "서버리스(serverless)" 부분입니다. 당신은 사서를 관리하지 않습니다. 그들은 당신이 필요할 때 그냥 나타납니다.

다음은 **스토리지 노드(Storage Nodes)**입니다. 이것은 책장입니다. 이들은 도서관 전체를 보유하지 않습니다. 대신 "샤드 키(shard key)"(예: 저자의 이름 첫 글자로 책을 분류하는 것)에 따라 특정 섹션의 책만을 보유합니다. 사서와 책장이 분리되어 있기 때문에, 사서들은 책장이 따라잡기를 기다리지 않고도 자신들의 업무를 수행할 수 있습니다. 사서들은 자신의 지역(가용 영역, Availability Zone)에 있는 가장 가까운 책장에서 책을 읽으므로 읽기 속도가 매우 빠릅니다.

마지막으로, **심판관(Adjudicators)**과 **저널(Journal)**이 있습니다. 심판관은 변화가 허용되는지 결정하는 규칙 준수자들입니다. 저널은 마스터 일기입니다. 당신이 책을 바꾸고 싶을 때(하나의 "쓰기" 작업), 사서는 종이에 변경 사항을 적지만 아직 책장에 넣지는 않습니다. 대신 그것을 규칙 준수자에게 보냅니다. 규칙 준수자는 다른 누군가가 동시에 그 책을 바꾸려고 시도하는지 확인합니다. 만약 문제가 없다면, 규칙 준수자는 그 변경 사항을 저널에 기록합니다. 이 저널은 가장 중요한 부분입니다. 그것은 지금까지 일어난 모든 변화에 대한 영구적이고 순서가 정해진 목록입니다. 일단 저널에 기록되면, 설령 책장이나 사서가 사라지더라도 그 내용은 영원히 안전합니다.

"기다림 없는" 읽기 기술

이 논문에서 가장 멋진 기술 중 하나는 읽기를 처리하는 방식입니다. 많은 데이터베이스에서는 책을 읽고 싶을 때 사서가 누군가 그 책에 글을 쓰고 있는지 확인될 때까지 기다려야 합니다. 이는 줄을 세우고 지연을 발생시킵니다. DSQL은 **다중 버전 동시성 제어(Multi-Version Concurrency Control, MVCC)**라는 영리한 시간 여행 기술을 사용합니다.

이미지 상으로, 책이 바뀔 때마다 도서관은 예전 버전을 지우는 것이 아니라, 타임스탬프가 찍힌 새 복사본을 만듭니다. 당신이 책을 요청할 때, 당신은 단순히 "그 책"을 요청하는 것이 아니라 "오후 2시 당시의 그 책"을 요청하는 것입니다. 그러면 시스템은 2시 당시에 유효했던 버전을 찾아냅니다. 시스템은 초 마이크로초 단위까지 정확한 초정밀 시계를 사용하므로, 어떤 버전을 보여줘야 할지 정확히 알고 있습니다. 이는 누군가 새로운 내용을 쓰고 있는 동안에도 당신은 책을 읽을 수 있으며, 상대방의 엉망이 된 미완성 변경 사항을 보지 않게 된다는 것을 의미합니다. 당신은 과거의 완벽하고 고정된 스냅샷을 보게 됩니다. 이를 통해 수백만 명이 서로를 방해하지 않고 동시에 읽을 수 있습니다.

멀티 리전(Multi-Region)의 초능력

이 논문은 거리 문제도 다룹니다. 보통 뉴욕에 도서관이 하나 있고 런던에 하나 있다면, 빛의 속도 때문에 이 둘을 동기화하는 데 시간이 걸립니다. 만약 두 곳에서 동시에 책을 업데이트하려고 하면, 메시지가 대양을 건너가기를 기다려야 하며, 이는 모든 것을 느리게 만듭니다.

DSQL은 액티브-액티브(active-active) 방식으로 이 문제를 해결합니다. 이는 뉴욕에도 도서관이 있고 런던에도 도서한이 있으며, 두 곳 모두 동시에 정상 영업을 할 수 있음을 의미합니다. 당신이 뉴욕에서 변경을 수행하면, 시스템은 이를 저널에 기록합니다. 그러면 저널은 런던으로 복사본을 보냅니다. 마법 같은 점은, 이 과정이 당신이 "커밋(commit)"(트랜잭션 완료)을 누르는 바로 그 순간에 딱 한 번만 일어난다는 것입니다. 메시지가 이동하는 동안 시스템은 당신의 읽기나 쓰기를 막지 않습니다. 시스템은 "쿼럼(quorum)" 체계를 사용하여, 세 개의 지역 중 두 곳에서만 변경 사항을 확인하면 안전하다고 간주합니다.

저자들은 이를 측정하였으며, 버지니아와 오리건 사이의 거리(왕복 약 62밀리초)가 있더라도 시스템은 트랜잭션당 단 한 번의 "거리 세금"만을 지불한다는 것을 발견했습니다. 읽기의 경우, 로컬 도서관에서 읽기 때문에 훨씬 더 빠릅니다. 저자들은 이 설계 덕분에 데이터베이스가 재난으로 인해 특정 지역(도시 전체 등)이 오프라인이 되더라도 빠르고 일관되게 유지될 수 있음을 보여줍니다.

게임의 규칙

저자들은 자신들이 약속한 바에 대해 매우 신중했습니다. 그들은 트랜잭션이 어떻게 작동하는지에 대한 특정 규칙 세트인 **스냅샷 격리(Snapshot Isolation)**를 선택했습니다. 이것은 "당신은 읽기를 시작했을 때의 책을 읽을 수 있고, 읽기를 마쳤을 때 책을 수정할 수 있지만, 그 사이에 누군가 책을 수정했다면 다시 시도해야 한다"라고 말하는 것과 같습니다. 이는 당신이 잠금(lock)을 위해 기다리도록 강제하는 더 엄격한 규칙들과 다르며, 이는 속도를 늦춥니다.

이 논문은 모든 것을 관리하는 단일 "리더(leader)"가 필요하다는 생각을 명시적으로 배제합니다. 많은 시스템에서는 한 대의 컴퓨터가 대장이며, 그 컴퓨터가 고장 나면 모든 것이 멈춥니다. DSQL에는 단일 대장이 없습니다. 모든 부분은 확장하거나 축소될 수 있으며, 한 부분이 실패하더라도 다른 부분들은 계속 작동합니다. 또한 이 논문은 당신이 하드웨어를 직접 관리할 필요가 없다는 아이디어도 배제합니다. 시스템은 "열기"(어느 부분이 너무 바쁜지)를 자동으로 처리합니다. 만약 도서관의 특정 섹션이 너무 붐비게 되면, 컨트롤 플레인(도서관 관리자)은 당신이 아무것도 하지 않아도 자동으로 해당 섹션을 두 개의 작은 섹션으로 나누고 일부 책을 새 책장으로 옮깁니다.

이론 검증

저자들은 단순히 이것이 작동할 것이라고 추측만 한 것이 아니라, 철저하게 테스트했습니다. 그들은 수백만 건의 오류, 네트워크 지연, 충돌을 순식간에 시뮬레이션할 수 있는 컴퓨터 프로그램 내에서 시스템을 실행하는 결정론적 시뮬레이션(deterministic simulation) 기법을 사용했습니다. 그들은 시스템이 데이터 손실이나 혼란 없이 이러한 오류들을 처리할 수 있음을 발견했습니다.

그들은 또한 실제 환경과 유사한 테스트(바쁜 상점을 시뮬레이션하는 TPC-C 벤치마크 등)를 수행했습니다. 결과는 DSQL이 콜드 스타트(자원이 거의 없는 상태)에서 시작하여 분당 수백만 건의 연산을 처리할 수 있음을 보여주었습니다. 완전히 비어 있는 상태에서 풀 스피드로 올라가는 데 약 25분이 걸렸지만, 일단 예열된 후에는 믿을 수 없을 정도로 빨랐습니다. 논문은 이러한 결과에 대해 매우 확신하고 있지만, 외래 키(테이블을 연결하는 기능)나 저장 프로시저(stored procedures)와 같은 더 많은 기능을 추가하기 위해 여전히 작업 중이라고 언급했습니다.

핵심 요약

Aurora DSQL는 당신이 원하는 것을 모두 가질 수 있다는 증거입니다. 즉, 단순한 서비스처럼 관리할 것이 없는(서버리스) 쉬운 사용성을 가지면서도, 거대한 글로벌 시스템만큼 강력한 데이터베이스를 가질 수 있다는 것입니다. 생각하는 것, 저장하는 것, 그리고 규칙을 분리하고, 시간을 추적하기 위해 영구적인 저널을 사용함으로써, 이 시스템은 애플리케이션이 부하 없이 제로에서 수백만 건의 트랜잭션까지 성장할 수 있게 합니다. 이것은 변화가 빠르고, 재난이 발생하며, 당신이 읽고 있는 정보가 지금 당장의 절대적인 진실임을 알아야 하는 세상을 위해 설계된 시스템입니다.