AWS DynamoDB 에는 RDB에서 처럼 Select COUNT(*) 와 같이 개수를 세는 API 가 따로 제공되지 않습니다. 그렇다보니 쿼리 결과에 따라 아이템 개수를 세려면 머리가 아플 수도 있습니다.

DynamoDB는 왜 카운팅이 어려운가

DynamoDB는 기본적으로 ‘분산형’ 데이터베이스 입니다. 이말인 즉, 데이터를 어느 한 곳에 몰아서 저장하지 않고 파티셔닝한 후 관리하고 있다는 뜻입니다. DynamoDB의 파티션키와 정렬키의 구조는 각 파티션내에서 빠르게 연산을 처리하도록 설계되어 있습니다. 여러 파티션의 결과를 모두 수집해야만 우리가 원하는 카운팅 작업을 비롯한 집계(Aggregate) 작업을 수행하는 것이 가능합니다. 그렇기 때문에 DynamoDB는 각기 여러 파티션에 분산된 모든 데이터를 집계하려면 성능적으로 손해를 볼 수밖에 없습니다.

물론 그럼에도 불구하고 DynamoDB를 사용하면서 카운팅을 필요로하는 경우는 있습니다. 가장 대표적인 경우가 오프셋(offset) 기반의 페이지네이션을 구현 하는 경우가 그렇습니다. 이 때는사용자에게 쿼리하는 전체 결과의 항목을 반환해줘야 합니다. 따라서 필요 상황에 어떻게 할지에 대한 나름의 고민들을 적어봤습니다.

쿼리결과 반복하기

카운팅을 직접 구현하는 간단한 방법은 그냥 쿼리를 끝까지 계속반복하는 것입니다. 이렇게 하는 이유는, DynamoDB는 쿼리 결과의 최대 크기를 1MB로 제한하고 있기 때문입니다. 그래서 Select를 ‘Count’로 지정하고 FilterExpression 을 활용해 최소한의 데이터만으로 최대한 많은 아이템을 가져오도록 구현합니다.

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB.DocumentClient();

const params = {
  TableName: 'Table',
  KeyConditionExpression: 'partitionKey = :pk',
  ExpressionAttributeValues: {
    ':pk': ''
	},
	FilterExpression: '' // 필요한 데이터만 가져옵시다
	Select: 'COUNT',
};

async function getAllItemsCount() {
  let results = 0;
  let items;

  do {
    const { Count: count } = await dynamoDB.query(params).promise();
    results += count; 
    params.ExclusiveStartKey = items.LastEvaluatedKey;
  } while (typeof items.LastEvaluatedKey !== 'undefined');

  return results;
}

위 방법은 가장 기본적(?)인 방식이지만, 카운팅을 위해 불필요한 쿼리를 계속해서 날려야 한다는 비효율이 있습니다. 위와 같은 쿼리가 빈번하면, 그만큼 RCU를 많이 잡아 먹게됩니다. 그리고 그만큼 돈을 더 지불하게 됩니다. 따라서 이 방식은 데이터 규모가 어느정도 커지면 재고해볼 필요가 있습니다.

카운팅 레코드 또는 테이블 만들기

방금 앞서 설명한 반복방식은 카운팅을 위해 매번 쿼리하고자 하는 아이템에 대해 카운팅을 레코드 또는 테이블 단위로 분리하여 기록하는 방법도 있습니다. 이렇게 하면 매번 쿼리 하지 않고 이미 기록된 항목을 가져오면 됩니다. 이때 카운팅 레코드 또는 테이블에 기록하기 위해 테이블에 행해지는 삭제나 생성 작업에 대해 매번 부가적으로 작업을 해줘야만 합니다.

그러나 이렇게 하면 아무래도 카운팅에 대한 연산을 놓치거나, 추적하지 못하는 케이스가 있을 수 있다는 것입니다. 가령 DB상에 직접 항목을 집어넣고 삭제하는 것 까지는 반영할 수가 없습니다. 항목 업데이트 과정에서는 트랜잭션 사용이 필수적입니다. DynamoDB는 업데이트에 대한 트랜잭션 고립 수준이 ‘Serializable’ 로 고정적입니다. 그렇다보니 성능적으로 그닥 좋진 않으며, 트랜잭션 업데이트 시도시 실패하는 경우가 있을 수 있습니다. 이 경우 재시도를 위한 별도의 작업을 처리해줘야 합니다. 물론 트랜잭션이 아니라면, SQS와 같은 것을 사용하는 대안도 있습니다. 대신 구현이 복잡해지겠죠.

Stream을 이용해 추적하기(+카운팅 레코드 또는 테이블)

DynamoDB에는 Stream 이라는 기능을 제공합니다. DynamoDB 에서 발생한는 변경사항 이벤트를 실시간으로 추적할 수 있게 해주는 기능입니다. 이를 활용하면 카운팅 레코드 또는 테이블 활용을 조금더 정확히 운영할 수 있습니다. DB 자체에서 스트림으로 이벤트를 보내주므로, 모든 변경사항에 대해 추적이 가능합니다. 다만 Stream은 공짜가 아니고 부가적으로 내야하는 비용이 있습니다.

DynamoDB의 Stream 을 활용해 이러한 예시를 실제 구현한 예시가 있는데 다음 아티클을 참조하면 자세한 내용을 확인 할 수 있습니다.

Select Count(*) from DynamoDB Group By with Streams

How to keep accurate counts in DynamoDB

근사 개수 구하기

정확한 개수를 세는 것이 아니라, 대략적인 개수만 세는 경우라면 DynamoDB가 제공하는 describeTable 함수를 활용하면 됩니다. 물론 이러한 근사개수만을 필요로하는 유스케이스가 얼마나 있을지는 모르겠지만, 경우에 따라서는 나름 괜찮은 대안일 수 있습니다. 참고로 항목에 대한 업데이트수를 실시간으로 반영하지는 못하기 때문에 말그대로 ‘근사적’인 추정만 가능합니다. 다음은 근사 개수를 구하는 예시 코드입니다.

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB();

const params = {
  TableName: 'TABLE_NAME',
};

dynamoDB.describeTable(params, (err, data) => {
  if (err) {
    console.log(err, err.stack);
  } else {
    console.log(data.Table.ItemCount);
  }
});

위의 코드를 가지고 실제로 제가 운영중인 DynamoDB에 적용해보면 다음과 같은 결과가 나옵니다. 여기서는 근사치가 아닌 정확한 숫자를 반환합니다. 일반적으로 파티션이 커지고 데이터양이 많아지면, 근사치에 가까워집니다.

아래는 콘솔에서 반환된 항목 결과입니다.

한계점

쓰기 연산은 비싸다

이는 종류를 불문하고 대부분의 데이터 베이스에서 그렇지만, 대체로 읽기 연산 보다 쓰기 연산이 비용이 더 많이 들어갑니다. DynamoDB는 크게 두가지 모드로 나뉘는데 ‘프로비저닝’과 ‘온디맨드’ 입니다. ‘프로비저닝’ 모드에서는 읽기 용량(RCU)와 쓰기 용량(WCU)가 정해져있지만, 온디맨드 모드에서는 무제한으로 주어지는 대신 요금도 2.5배나 비쌉니다. DynamoDB Stream을 이용해 카운팅 레코드를 운용하거나 하는 방식은 상황에 따라 다르겠지만, 항목의 생성과 삭제가 빈번한 경우라면, 그만큼 많은 양의 WCU를 요구할 수도 있습니다. 여기서의 비용은 단순히 금전적 비용만을 포함하지는 않습니다. 부가적으로 카운팅하는 항목에 대해 관리와 트랜잭션에 대한 실패처리와 같은 공수도 생각해야합니다.

관리 요소가 늘어난다.

카운팅 레코드나 테이블을 관리해야하기 때문에 신경써야하는 부분이 늘어납니다. Stream을 사용하지 않는다면 매번 생성과 삭제때마다 이를 기록해줘야 합니다. Stream 을 사용한다 하더라도, 이를 위해 별도의 관리 코드를 작성해야합니다. 그리고 DynamoDB Stream 의 경우 Failover 에 대한 처리를 제대로 하지 않으면 무한실행되기도 하는데, 이러한 예외케이스들에 대해 좀 더 고민해봐합니다. 분명히 관리형 DB를 쓰는데, 관리해야하는 요소가 더 늘어나는 아이러니함이 생긴다고 봐야할 것 같습니다.

필터링 문제

카운팅 테이블에서 카운팅하는 대상이 전체 항목인 경우가 아닌 경우도 있을 겁니다. 가령 사용자의 친구수중 생일이 3월인 사람만 가져온다고 생각해봅시다. 사용자의 전체 친구를 대상으로 카운팅한 경우에는, 카운팅 테이블이 큰 의미가 없습니다. 이럴 때는 필터링 조건에 따른 카운팅 결과를 차라리 캐시처럼 사용하도록 하는게 나을 수도 있습니다.

대안

DynamoDB는 기본적으로 통계적 연산에 취약합니다. 그래서 AWS에서도 이를 위해 Amazon EMR의 Apache Hive나 AWS RedShift를 사용하는 것을 권장하기도 합니다. 물론 DW를 필요로 할 정도로의 큰 규모의 데이터가 아닌경우면, 사실 저 두개를 도입하는 건 오버엔지니어링에 가깝습니다. 비슷한 분산형 NoSQL 데이터베이스 중에는 Cassandra나 Couchbase 그리고 MongoDB의 경우 Count 연산을 직접 제공하기는 합니다. 마찬가지로 성능 이슈는 역시 존재하지만(Cassandra의 경우), MongoDB나 Couchbase 의 경우 DynamoDB 보다는 이러한 집계 연산을 잘 지원합니다.

결론

DynamoDB 가 초점을 맞추는 부분은 일관성있는 강력한 읽기 성능을 기반으로 하는 데이터 규모의 무관한 일정한 처리 속도입니다. 또한 Redis와 비슷한 Key-Value 기반의 DB입니다. 만약 카운팅과 같은 집계 연산이 빈번하다면 DynamoDB 사용에대해 한 번 고민해볼 필요가 있습니다.

댓글