DynamoDB + GUI 로컬 개발환경 세팅하기

---

테스트는 로컬환경에서 하자!

개발 환경

> Windows 10

> Node.js (with NPM)

데이터베이스 로직이 잘 동작하는지 확인하기 위해서는

실제 데이터베이스에 데이터를 주어가며 확인하는 것이 좋지만.

DynamoDB를 AWS 위에서 테스트를 한다면,

테스트 과정도 실사용량에 청구되는 것은 물론이고, 

테스트케이스 데이터를 매번 삭제하는 것도 귀찮은 작업입니다.

그럴때는 DynamoDB를 로컬에서 테스트하는 것을 고려할 수 있습니다.

데이터베이스를 싹다 날려버리는 것도 편하고,

로컬에서 이루어지므로 사용량도 청구되지 않기 때문이죠!

---

Local DynamoDB 설치하기

DynamoDB는 쿼리와 최적화가 어려울뿐이지 설치와 셋팅 자체는 어렵지 않습니다!

먼저 아래의 링크에서 자신의 환경에 맞는 DynamoDB를 다운로드 받습니다.

컴퓨터에서 DynamoDB(다운로드 가능 버전) - Amazon DynamoDB

 

압축파일을 풀고 DynamoDBLocal.jar이 있는 디렉터리에서 셸을 열고,

다음과 같이 입력하여 데이터베이스를 실행합니다.

이게 끝이에요.

java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb 

Attention!

위의 명령어는 Powershell이 아니라 CMD 기준입니다.

자주 쓰이는 옵션 모음

-port <port-no.>

주어진 포트번호로 인스턴스를 생성합니다.

기본값은 8000이며, 누가 사용중이라면 익셉션이 발생합니다.

-inMemory

인스턴스를 인메모리 모드로 작동시킵니다.

인메모리 모드에서 인스턴스가 종료되면 데이터는 버려집니다.

반대로 이 옵션을 붙이지 않는다면, 데이터는 파일로 저장되어 다음에 사용됩니다.

-dbPath <path>

기존의 데이터 파일이 있는 경로를 지정합니다.

-sharedDB

모든 인스턴스를 단일 인스턴스로써 동작하게 합니다.

DynamoDB는 한 포트당 하나의 인스턴스에 연결시킬 수 있고,

이렇게 만들어진 각각의 인스턴스는 자신만의 데이터파일을 갖지만,

이 옵션이 붙으면 모든 인스턴스는 단 하나의 데이터파일을 공유합니다.

아래는 인스턴스를 실행하는 배치파일입니다.

경로를 올바르게 바꾸고, 바탕화면에 두어 사용하세요.

cd C:\DynamoDB
java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb 
pause

---

로컬 DynamoDB에 연결하기

DynamoDB에 접속하기 위해서는

먼저 아마존 개발도구(aws-sdk)부터 설치해야 합니다.

npm install aws-sdk

또한 로컬로 접속하더라도 보안자격 증명이 필요하기 때문에,

아래의 정보를 미리 준비하셔야 합니다.

> access key

> private access key

보안자격 증명을 세팅하는 방법은 2가지가 있습니다.

컴퓨터에 키를 설정하거나,

프로그램 소스에 키를 삽입하거나.

컴퓨터에 키를 설정하는 방법은 여기를 참고해주세요.

아마존 명령행 인터페이스를 이용하여 설정하는 방법을 설명하고 있습니다.

공용 컴퓨터라 키를 설정할 수 없는 경우에는,

해당 서비스의 커넥션을 연결할 때 인자로써 넘겨줘야 합니다.

import AWS from "aws-sdk";

let conn = new AWS.DynamoDB({
    region: "ap-northeast-2",
    accessKeyId: "???",
    secretAccessKey: "???",
    endpoint: "http://localhost:8000"
});

---

DynamoDB를 GUI로 관리하기

테이블을 생성하거나 전체 데이터를 조회하는 과정을

스크립트로 짜서 관리하는건 너무 끔찍합니다.

RDB 때도 그렇게 안했는데 말이죠.

아래는 그래픽컬하게 DynamoDB를 관리할 수 있게 도와줍니다.

멘탈건강을 챙겨주는 아주 좋은 친구들이에요.

> AWS NoSQL WorkBench

> DynamoDB-Admin

같이 쓰는편이 좋지만,

굳이 장단점을 훑어보면 다음과 같습니다.

AWS NoSQL WorkBench

장점

1. 모델링을 어플리케이션 단위로 관리.

2. 모델링 결과를 파일로 저장하고, 인스턴스에 커밋(생성하라고 명령)할 수 있음.

3. 데이터 삽입 / 조회 가능.

단점

1. 테이블 삭제 불가능.

2. 테이블 추가는 모델링 커밋으로만 가능.

3. 모델링 커밋 중, 도중에 실패하면 불완전하게 실패함.

실패는 했는데... 어떤건 되있고, 어떤건 안되있고.

대표적인 실패 사유는 이름이 중복된 테이블이 있을 때.

DynamoDB-Admin

장점

1. 테이블 추가 / 삭제 가능.

2. 데이터 삽입 / 조회 가능.

단점

1.  모델링 불가능.