지난 글에서 DynamoDB를 지탱하는 큰 축인 Dynamo 시스템에 대해서 알아봤다. Dynamo 시스템은 DynamoDB가 등장하기 한참 전에 설계되었지만 이름에서 쉽게 알 수 있듯 굉장히 깊은 부분을 공유하고 있다. 그러나 DynamoDB는 관리형 인프라 서비스로 제공되는 만큼 사람들이 더 쉽고 범용적으로 사용할 수 있게 설계되었다. 구체적으로 어떻게 어떤 점이 다른지 알아보자.

아마존은 지구 규모 스케일 서비스를 운영하면서 자신들의 요구와 가장 잘 들어맞는 범용적인 분산 스토리지 시스템을 만들어냈는데 이 시스템이 바로 Dynamo이다. 시스템을 만들고 운영한 경험을 논문으로 발표했고, 이 논문은 분산 스토리지 시스템 생태계에 큰 영향을 주었다. 이 논문에 영향을 받아 오픈소스에서는 Cassandra가 개발되었고 AWS 서비스의 SimpleDB, DynamoDB를 만드는 기초가 되었다. DynamoDB의 구조가 완전히 Dynamo와 같지는 않지만, 뿌리가 되는 Dynamo 시스템에 대해 먼저 알아보자.

NoSQL 종류 중 하나인 DyanamoDB는 일반적인 SQL 테이블과 다르게, query를 할 때 조건을 설정할 수 있는 대상이 Partition Key (이하 PK)와 Sort Key (이하 SK) 그리고 추가적으로는 Global Secondary Index (이하 GSI)와 Local Secondary Index(이하 LSI)로 구분되는 Secondary Index로 한정된다. 다른 속성 필드에 대해서는 쿼리 조건을 설정할 수 없다. 만약 다른 속성에 대해 결과를 보려면 scan을 사용해야 한다. scan은 테이블의 모든 데이터를 조회하기 때문에 성능면에서 좋지 않은 모습을 보여준다. 이러한 특성이 있어서, DynamoDB 테이블은 일반적으로 SQL 테이블을 만들듯 만들면 안 된다. 이 글은 AWS에서 공식적으로 추천하고 있는 Single Table 구조로 설계하는 방법에 대해서 다루고 있다.

서버리스에서 VPC 내부로 배포하는 방법에 대해서 알아보려고 한다. 현재 진행 중인 프로젝트는 빠르고 간단하게 홍보용으로 만들고 있는 프로젝트라, 별다른 옵션 없이 퍼블릭하게 오픈된 API를 만들어놓고 개발 중이다. 그런데, 개발 서버를 분리해서 일정 기간동안 유지 보수 하면서 배포도 몇 번 더 해야 할 필요가 있어서 내부 VPC에 배포하는 방법을 확인해보려고 한다. 추가적으로, VPC 내부로 배포하게 되면 S3와 DynamoDB에 접근하기 위해 NAT Gateway 또는 VPC Endpoint를 만들어줘야 한다. 이번 글에서는 NAT Gateway를 설정해주는 걸 해볼 것이다.

현재 진행하고 있는 프로젝트에서는 크로나 현황을 간단하게 보여주는 섹션이 존재하는데, 이 부분을 누군가가 (API 형식으로다가?) 제공해주고 있는 것으로 알고 있었다. 그렇지만 아직 나온 건 없었고, 어쩔 수 없이 간단한 크롤러를 만들고 업데이트 해주기로 했다. 현재 프로젝트가 서버리스로 돌고 있기도 하고, Scheduled 된 작업을 돌리기 위해서는 람다가 적합하지 않을라나 싶어서 같은 서버리스 프로젝트에서 크론잡을 돌리는 함수를 만들어보기로 했다.