관계형 데이터베이스(RDBMS)는 수십 년간 엔터프라이즈 환경의 핵심이었습니다. 하지만 클라우드 시대로 넘어오면서 기존 RDBMS를 그대로 클라우드 환경(VM이나 컨테이너)에 올릴 경우 확장성, 고가용성, 그리고 무엇보다 네트워크 I/O 병목 현상이라는 근본적인 한계에 직면하게 되었습니다.
Amazon Aurora는 이러한 문제를 해결하기 위해 데이터베이스의 내부 구조를 밑바닥부터 재설계했습니다. 이들의 철학은 2017년 SIGMOD 논문에서 발표된 유명한 문장으로 요약됩니다. 바로 **"The Log Is The Database (로그가 곧 데이터베이스다)"**입니다. 지금부터 Aurora의 근본적인 설계 철학을 3가지 핵심 축으로 나누어 살펴보겠습니다.
첫 번째는 컴퓨팅과 스토리지의 철저한 분리입니다.
기존의 전통적인 데이터베이스(MySQL, PostgreSQL 등)는 쿼리를 처리하는 '컴퓨팅(연산)' 계층과 데이터를 디스크에 저장하는 '스토리지' 계층이 단일 서버 안에 강하게 결합되어 있었습니다. 이 구조에서는 저장 공간이 부족해질 때 불필요하게 컴퓨팅 자원(CPU, RAM)까지 함께 스케일 업(Scale-up)해야 하며, 장애 발생 시 복구에 막대한 시간이 소요됩니다.
이미지출처: https://dl.acm.org/doi/10.1145/3035918.3056101
Aurora의 철학은 이 둘을 완전히 분리하는 것에서 출발합니다.
이렇게 분리함으로써 컴퓨팅과 스토리지 리소스를 각각 독립적으로 확장(Scale-out/Scale-up)할 수 있게 되었습니다. 데이터베이스 엔진에 장애가 발생하더라도 스토리지는 안전하게 보존되므로, 새로운 컴퓨팅 노드를 실행하여 스토리지에 연결하기만 하면 순식간에 복구를 완료할 수 있습니다.
두 번째 핵심은 네트워크 I/O의 최소화입니다. 이른바 "로그만 넘겨라" 전략입니다.
이미지출처: https://dl.acm.org/doi/10.1145/3035918.3056101
클라우드 환경에서 분산 데이터베이스를 구축할 때 가장 큰 장애물은 '네트워크 대역폭'입니다. 전통적인 RDBMS 환경에서 데이터를 수정할 경우, 데이터 블록(Page), Redo 로그, Undo 로그, Binlog 등 수많은 데이터가 네트워크를 타고 전송되어야 합니다. 고가용성을 위해 복제본(Replica)을 구성한다면, 이 막대한 데이터가 네트워크를 통해 복제본 서버들로 계속 전송되어 심각한 네트워크 병목 현상(I/O Bottleneck)을 유발합니다.
이에 Aurora는 "스토리지 계층으로 Redo 로그(변경 이력)만 전송한다"는 철학을 채택했습니다. 컴퓨팅 노드는 데이터 페이지 전체를 기록하는 대신, '어떤 데이터가 어떻게 변했는지'만을 나타내는 매우 작은 용량의 Redo 로그를 생성하여 분산 스토리지 레이어로 비동기 전송합니다.
그렇다면 실제 데이터 페이지(Block)는 어떻게 생성될까요? 바로 **지능형 스토리지(Intelligent Storage)**가 그 역할을 수행합니다. 스토리지 노드가 로그를 수신한 뒤, 백그라운드에서 자체적으로 데이터를 조합하여 페이지를 생성(Materialization)합니다. 이러한 혁신적인 접근 덕분에 Aurora는 기존 데이터베이스 대비 네트워크 I/O를 획기적으로 절감하였으며, 이는 곧 비약적인 성능 향상으로 이어졌습니다.
세 번째는 장애를 기본값으로 가정하는 설계입니다.
클라우드 인프라에서는 하드웨어 고장이나 네트워크 단절이 '예외'가 아니라 '일상(Norm)'으로 간주됩니다. 따라서 Aurora는 초기 설계 단계부터 "장애는 무조건 발생한다"는 전제를 기반으로 구축되었습니다.