ExtendDB: 내 데이터베이스에서 DynamoDB API 실행하기

어떤 병원 기록 시스템이 건물 안에 머물러야 한다고 해봅시다. 환자 데이터는 절대 온프레미스 네트워크를 벗어날 수 없고, 감사관이 모든 의존성을 검토해 승인하며, 개발용 노트북에는 인터넷이 전혀 없습니다. 팀은 이미 애플리케이션을 DynamoDB API에 맞춰 작성했고 그것을 마음에 들어 합니다. 한 자릿수 밀리초의 키 조회, 깔끔한 항목 모델, 돌볼 스키마 마이그레이션이 없다는 점이죠. 하지만 관리형 DynamoDB는 클라우드 서비스이고, 여기서 "데이터를 AWS로 보낸다"는 것은 받아들일 수 없는 일입니다.

ExtendDB는 정확히 그 간극을 위해 만들어졌습니다. DynamoDB 와이어 프로토콜을 구사하되, 데이터는 여러분이 운영하는 데이터베이스에 저장합니다.

ExtendDB란

ExtendDB는 AWS의 오픈소스 어댑터로, AWS DynamoDB 엔지니어들이 작성했으며 AWS Database Blog에서 발표되었습니다. DynamoDB JSON 와이어 프로토콜을 Rust로 구현한 것입니다. 관리형 서비스와 동일한 HTTP API에 응답하기 때문에, 기존 AWS SDK와 AWS CLI가 변경 없이 동작합니다. 바뀌는 것은 endpoint URL뿐입니다. 코드 재작성도, 새 클라이언트 라이브러리도 필요 없습니다.

흥미로운 부분은 그 API 뒤에 무엇이 자리 잡고 있는가입니다. ExtendDB는 플러그형 스토리지 백엔드를 가집니다. PostgreSQL이 참조 구현이고, Cassandra가 또 다른 가능한 백엔드로 언급됩니다. 새 백엔드는 코어를 수정하지 않고 구현되므로, DynamoDB 호환 계층과 스토리지 계층이 독립적으로 발전합니다.

따라서 요청은 다음과 같이 흐릅니다:

지원하는 것과 지원하지 않는 것

시작하기 문서와 발표 내용에 따르면, ExtendDB(v0.1)는 대부분의 애플리케이션이 실제로 호출하는 작업을 다룹니다:

• 테이블 — Create, Delete, Describe, List, Update.
• 항목 — Put, Get, Delete, Update(SET / REMOVE / ADD / DELETE 업데이트 작업 포함).
• Query와 Scan — 키 조건, 필터 표현식, 프로젝션, 페이지네이션, 그리고 보조 인덱스.
• Batch — BatchGetItem과 BatchWriteItem.
• 트랜잭션 — TransactGetItems와 TransactWriteItems.
• Streams, TTL, Import/Export, 그리고 Tags.

의도적으로 구현하지 않는 것은 DynamoDB 고유의 관리형 기능 집합으로, 가장 대표적으로 Global Tables와 리전 간 복제입니다. 이들은 관리형 서비스의 글로벌 인프라 속성이지 API 표면의 속성이 아니므로, 직접 호스팅하는 어댑터로는 이어지지 않습니다.

DynamoDB Local과 비교

여러분은 이미 오프라인 개발에 DynamoDB Local을 사용하고 있을 수 있습니다. 그것은 한 머신에서의 단위 테스트를 위한 단일 JAR(또는 amazon/dynamodb-local Docker 이미지)입니다. ExtendDB는 그 단일 프로세스 도구보다 더 넓은 범위를 지향합니다. 로컬 개발, 온프레미스 배포, 엣지 및 에어갭 환경, 그리고 DynamoDB API를 원하지만 데이터는 여러분이 통제하는 인프라에 두려는 하이브리드 / 멀티 클라우드 구성을 겨냥합니다.

관리형 DynamoDB와 비교

이것이 AWS가 명시적으로 긋는 선이며, 중요합니다:

ExtendDB는 DynamoDB가 아닙니다. 관리형 서비스의 대체재가 아니라 호환 구현입니다. 성능 특성, 확장 동작, 운영 속성이 다릅니다.

구체적으로, ExtendDB를 운영할 때는:

• 데이터베이스의 가용성과 백업은 여러분의 책임입니다. 관리형 다중 AZ 내구성이나 특정 시점 복구를 대신 해주는 것은 없습니다. 그것은 여러분과 여러분의 PostgreSQL 운영에 달려 있습니다.
• endpoint에서 TLS는 필수입니다.
• 자격 증명은 IAM과 유사하지만 AWS IAM과는 별개입니다. ExtendDB는 자체 자격 증명 모델을 가지며, 여러분의 AWS 계정에 대해 인증하지 않습니다.

이것은 v0.1이며 Apache 2.0으로 라이선스됩니다. 초기 단계 소프트웨어로 다루세요. 위의 환경들에는 훌륭하지만, 프로덕션 규모의 관리형 DynamoDB를 그대로 대체하는 용도는 아닙니다.

설정

ExtendDB는 Linux와 macOS에서 실행되며 Rust 1.85+와 PostgreSQL 14+가 필요합니다. 흐름은 두 개의 명령입니다:

extenddb init
extenddb serve

init은 PostgreSQL 데이터베이스에 schema를 프로비저닝하고, serve는 와이어 프로토콜 서버를 시작하는데, 이 서버는 https://127.0.0.1:8000 같은 endpoint에서 수신 대기합니다(TLS가 필수이므로 https).

다른 사용자 정의 endpoint와 마찬가지로 AWS SDK를 여기에 가리키게 하세요. 바뀌는 것은 URL과 자격 증명뿐입니다:

import {DynamoDBClient} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({
  endpoint: 'https://127.0.0.1:8000',
  region: 'local',
  credentials: {accessKeyId: '<extenddb-key>', secretAccessKey: '<extenddb-secret>'}
});

클라이언트 설정 이후의 모든 것, 즉 PutItem, Query, TransactWriteItems는 관리형 DynamoDB에 대해 작성하는 코드와 동일합니다. 싱글 테이블 항목 레이아웃도 클라우드에서와 정확히 똑같이 동작합니다:

DynoTable로 해보기

ExtendDB가 DynamoDB 와이어 프로토콜을 구사하기 때문에, 별도의 관리 도구가 필요 없습니다. DynoTable을 DynamoDB Local에 연결할 때와 똑같은 방식으로 ExtendDB endpoint에 가리키게 하세요. ExtendDB 포트와 임시 자격 증명으로 오프라인(로컬) 프로필을 만들면, DynoTable이 항목을 둘러보고, 쿼리하고, 편집합니다. 다만 이제는 JAR의 인메모리 저장소가 아니라 여러분 자신의 디스크에 있는 PostgreSQL이 그 항목을 뒷받침합니다.

이것이 와이어 프로토콜 호환성의 결실입니다. SQL 워크벤치, 시각적 쿼리 빌더, 그리고 항목 편집이 모두 ExtendDB에 대해 변경 없이 동작하므로, scan 스크립트를 작성하지 않고도 직접 호스팅한 데이터 위에 진짜 GUI를 얻습니다.

계획에 넣어둘 한 가지 유의점: ExtendDB의 endpoint는 HTTPS 전용인 반면, DynoTable의 오프라인 프로필은(대부분의 DynamoDB Local 구성처럼) 루프백 host:port를 대상으로 합니다. 클라이언트나 도구가 평문 루프백 리스너를 필요로 한다면, ExtendDB 앞에서 TLS를 종료하거나(또는 로컬 리버스 프록시를 실행하거나) GUI를 거기에 가리키게 하세요. 와이어 상의 프로토콜은 어느 쪽이든 여전히 DynamoDB JSON입니다.

함정

• v0.1을 프로덕션 DynamoDB처럼 다루지 마세요. 확장성, 지연 시간, 내구성은 AWS의 것이 아니라 여러분 PostgreSQL의 것입니다. 의존하기 전에 여러분의 워크로드에 대해 벤치마크하세요.
• Global Tables / 리전 간 복제 없음. 설계가 다중 리전 액티브-액티브에 의존한다면 ExtendDB는 그 경로가 아닙니다. 그것은 관리형 서비스 기능입니다.
• 기반 데이터베이스는 직접 백업하세요. 관리형 PITR이 없습니다. 삭제된 PostgreSQL 볼륨은 사라집니다. 다른 PostgreSQL과 마찬가지로 pg_dump / WAL 아카이빙을 구성하세요.
• 자격 증명은 ExtendDB 자체의 것이지 AWS IAM이 아닙니다. IAM 정책, 역할, 조건 키가 액세스를 통제할 것이라 기대하지 마세요. 그 권한 부여 모델은 이어지지 않습니다.

다음 단계

• 액세스 패턴을 먼저 모델링하세요. 백엔드가 DynamoDB든 PostgreSQL-via-ExtendDB든, 동일한 싱글 테이블 디자인 원칙이 적용됩니다.
• DynamoDB Expression Builder로 읽기와 쓰기를 만들고 점검한 다음, DynamoDB-JSON 변환기로 픽스처를 일반 JSON과 와이어 형식 사이에서 변환하세요.
• 실제 ExtendDB 인스턴스를 들여다볼 준비가 되면, DynoTable을 연결해 다른 테이블처럼 둘러보세요.