Amazon QLDB(Quantum Ledger Database)는 애플리케이션 데이터에 적용된 모든 변경 사항에 대한 완전하고 암호로 확인할 수 있는 기록을 제공하도록 특별히 구축된 원장 데이터베이스입니다.
기존 데이터베이스는 데이터의 덮어쓰기 또는 삭제를 허용합니다. 따라서 개발자가 감사 테이블 및 감사 트레일과 같은 기법을 사용하여 데이터 계보 추적을 도울 수 있습니다. 이러한 접근 방식이 성공적일 수는 있지만 사용자 지정 개발이 필요하고, 확장이 어려울 수 있으며, 올바른 데이터가 기록되는지를 개발자가 책임지고 확인해야 합니다. Amazon QLDB에 있는 데이터는 추가 전용 저널에 기록되어 개발자에게 전체 데이터 계보를 제공합니다. 또한 Amazon QLDB의 저널에 있는 데이터는 변경이 불가능하고 검증이 가능하므로 사용자가 원장에 있는 데이터를 신뢰할 수 있습니다.
Amazon QLDB의 기능은 데이터 무결성, 완전성 및 검증 가능성이 중요한 기록 시스템 애플리케이션에 적합합니다. 예를 들어 공급망 및 물류 영역에서 Amazon QLDB를 기반으로 빌드된 애플리케이션은 배송업체 간 및 국경 간 이동과 같은 전체적인 변경 이력을 확보하고 이에 대한 쿼리 및 분석이 가능합니다. 재무 분야에서 기록 시스템 애플리케이션은 신용 및 차변 거래와 같은 중요 데이터를 추적합니다. 은행은 복잡한 기록 유지 기능을 애플리케이션 내에 빌드하는 대신 QLDB를 사용하여 모든 재무 거래에 대한 영구적이면서 완전한 기록을 손쉽게 저장할 수 있습니다.
Amazon QLDB는 블록체인 또는 분산형 원장 기술이 아닙니다. 블록체인 및 분산형 원장 기술은 여러 당사자가 개입하는 분산화된 애플리케이션의 문제 해결에 집중합니다. 이 경우 단일 엔터티가 애플리케이션을 소유하지 않고, 당사자가 반드시 서로를 완전히 신뢰하는 것은 아닙니다. 반대로 QLDB는 소유한 애플리케이션의 데이터 변경 이력을 완전하고 검증 가능한 상태로 유지 관리해야 하는 고객을 위한 원장 데이터베이스입니다. Amazon QLDB는 완전관리형 AWS 데이터베이스의 익숙함, 확장성 및 사용 편의성에 이력, 불변성 및 검증 가능성을 결합해 줍니다. 애플리케이션에서 분산이 필요하고 신뢰하지 않는 여러 당사자가 개입하는 경우에는 블록체인 솔루션이 적합할 수 있습니다. 애플리케이션에서 완전하고 검증 가능한 모든 애플리케이션 데이터 변경 이력이 필요하지만 신뢰하지 않는 여러 당사자가 개입하는 것이 아니라면 Amazon QLDB가 적합합니다. 분산형 원장 또는 블록체인에 대한 사용 사례가 있는 경우 Amazon Managed Blockchain을 참조하세요.
완전하고 검증 가능한 애플리케이션 데이터 변경 이력 제공 외에도 Amazon QLDB는 ACID 의미 체계를 통한 트랜잭션, 유연한 문서 데이터 모델 및 익숙한 유사 SQL API를 지원합니다. QLDB는 또한 완전관리형이고 크기가 자동으로 조정되어 프로비저닝 없이도 애플리케이션 요구 사항을 충족합니다.
Amazon QLDB에 연결하고 원장의 데이터와 거래하려면 AWS가 제공하는 QLDB 드라이버를 사용해야 합니다. 이 링크의 단계에 따라 드라이버를 다운로드하고 연결을 구성합니다.
Amazon QLDB는 관리할 서버나 프로비저닝할 용량이 없으므로 간단하게 시작할 수 있습니다. AWS Management Console, AWS Command Line Interface(CLI), AWS CloudFormation 템플릿을 사용하거나 QLDB API를 호출하여 몇 분 안에 새로운 원장을 생성할 수 있습니다.
Amazon QLDB는 일반적인 블록체인 프레임워크에서 원장보다 2~3배 더 많은 트랜잭션을 실행 할 수 있습니다. 블록체인 프레임워크는 분산화되어 트랜잭션을 실행하므로, 네트워크 구성원 다수가 트랜잭션 유효성에 대해 합의해야 트랜잭션이 완료됩니다. 반면, QLDB는 중앙 집중식으로 설계되었으므로 다자간의 합의가 없어도 트랜잭션을 실행할 수 있습니다.
Amazon QLDB를 사용하면 PartiQL을 사용하여 데이터에 액세스하고 조작할 수 있습니다. PartiQL은 특정 데이터 소스와 독립적으로 유지하면서 반 구조적 및 중첩된 데이터를 포함하는 QLDB의 문서 지향 데이터 모델에 대한 SQL 호환 액세스를 지원하는 새로운 개방형 표준 쿼리 언어입니다. PartiQL에 대한 자세히 내용은 여기를 참조하세요.
Amazon QLDB 요금은 요금 페이지를 참조하세요.
Amazon QLDB는 미국 동부(버지니아 북부, 오하이오), 미국 서부(오레곤), EU(아일랜드, 프랑크푸르트) 및 아시아 태평양(싱가포르, 시드니, 서울, 도쿄) AWS 리전에서 사용할 수 있으며, 조만간 리전이 추가될 예정입니다.
Amazon QLDB를 사용하면 용량을 프로비저닝하거나 읽기 및 쓰기 제한을 구성하는 문제를 걱정하지 않아도 됩니다. 사용자가 원장을 만들고, 테이블을 정의하면, QLDB는 애플리케이션 요구에 맞게 자동으로 확장됩니다.
AWS 서비스 한도 페이지에서 Amazon QLDB와 관련된 제한을 볼 수 있습니다.
Amazon QLDB는 현재 백업 및 복원 기능을 지원하지 않습니다. 현재 S3 기능으로 내보내기가 가능합니다. 이 기능을 사용하면 QLDB 저널의 내용을 S3으로 내보낼 수 있습니다.
현재 Amazon QLDB는 특정 시점 복원 기능을 지원하지 않습니다.
Amazon QLDB의 원장은 AZ 당 다양한 복사본으로 여러 AZ에 배포됩니다. 리전 내에서 중복성을 유지하고 가용 영역 장애로부터 완전 복구를 보장합니다. 쓰기는 여러 AZ의 내구성 있는 스토리지에 쓰여진 후에만 승인되므로 QLDB는 내구성이 뛰어납니다.
Amazon QLDB는 고가용성 서비스입니다. 기본적으로 QLDB 원장의 여러 복사본이 한 지역의 여러 가용 영역으로 복제됩니다. 따라서 한 영역에서 장애가 발생해도 QLDB를 계속 작동할 수 있습니다.
현재 Amazon QLDB는 교차 지역 복제를 지원하지 않습니다. QLDB의 S3로 내보내기 기능을 통해 고객은 QLDB 저널의 내용을 S3 버킷으로 내보낼 수 있습니다. 교차 지역 복제를 위해 S3 버킷을 구성할 수 있습니다.
Amazon QLDB는 AWS Private Link와 통합됩니다. 고객은 VPC 엔드포인트를 생성하여 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결 없이도 PrivateLink 기반으로 지원되는 AWS 서비스에 VPC를 비공개로 연결할 수 있습니다.
Amazon QLDB는 다른 AWS 서비스와 동일한 인증 메커니즘을 사용합니다. 이 메커니즘을 사용하려면 요청 서명을 HTTP 요청(헤더 또는 쿼리 문자열)에 첨부해야 합니다. 서명은 다른 요청 필드와 AWS 자격 증명(액세스 키 ID 및 보안 액세스 키)을 사용하여 계산됩니다.
기본적으로 전송 중 데이터와 저장 데이터가 모두 암호화됩니다. Amazon QLDB는 2021년 7월 22일에 고객 관리형 AWS KMS 키에 대한 지원을 시작했습니다. 그 전에 생성된 모든 원장은 기본적으로 AWS 소유 키로 보호되며, 현재는 고객 관리형 키를 사용하여 저장 데이터를 암호화할 수 없습니다. 원장 생성 시간은 QLDB 콘솔에서 확인할 수 있습니다.
1/ Amazon Kinesis 데이터 스트림(KDS) 생성: 고객이 Amazon Kinesis 콘솔 또는 AWS SDK를 사용하여 KDS 스트림을 생성합니다. 기존 스트림을 사용해도 됩니다.
2/ Amazon QLDB 스트림 생성: 고객이 Amazon QLDB 콘솔 또는 AWS SDK를 사용하여 Amazon QLDB 스트림을 생성합니다. 스트림을 생성하려면 다음과 같은 주요 측면을 구성해야 합니다.
3/ KDS 스트림 사용: 고객이 Kinesis Data Firehose 및 Kinesis Data Analytics 같은 Kinesis 서비스를 통해 Kinesis 애플리케이션을 작성하여 스트림을 사용하고 처리할 수 있습니다. 고객은 AWS Lambda를 사용하여 Kinesis 데이터 스트림 레코드를 사용할 수도 있습니다.
Amazon QLDB 스트리밍 기능은 최소 1회 전달을 보장합니다. QLDB 스트림을 통해 저널에서 생성되는 각각의 제어 기능, 블록 요약 및 개정 세부 정보는 Amazon Kinesis로 1회 이상 스트리밍됩니다. 경우에 따라 Kinesis 스트림에 중복된 레코드가 나타날 수 있기 때문에 고객은 애플리케이션에서 필요한 경우 애플리케이션 계층에 중복 제거 로직을 두어야 합니다. 이전 블록 및 개정은 Kinesis 스트림에서 순서에 관계없이 게시될 수 있으므로 정렬은 보장되지 않습니다.