[Udemy][day-52,53] Section22 : AWS 서버리스 : DynamoDB - 2
#AWS Certified Developer Associate
321. DynamoDB PartiQL
PartiQL 을 통해 SQL 형식의 구문을 사용해 DynamoDB 테이블을 조작할 수 있음
INSERT, UPDATE, SELECT, DELETE 사용 가능
SQL 에 익숙한 사람들이 DynamoDB 에서도 원할한 작업을 할 수 있도록 해주는 기능
필요한 경우 배치 연산도 지원
왼쪽 테이블 목록에서 테이블을 스캔하면
자동으로 sql 명령문이 입력되고 실행해보면
결과를 위와 같이 반환해준다
json 뷰로 결과를 볼 수 있고 csv 로 가져올 수도 있다
테이블 쿼리를 하게되면 위와 같이 파티션 키를 기준으로 select 명령을 실행할 수있다
where 절 뒤에 and 로 정렬 키를 사용할 수 있는데 필수는 아니기 때문에 지금은 지워준 모습
편집기 기능과 같이 항목 업데이트 혹은 삭제도 가능하다
322. DynamoDB 낙관적 잠금
DynamoDB Optimistic Locking
dynamoDB 에서 조건부 쓰기(Conditional Writes)를 하는 것
업데이트하거나 삭제하기 전에 항목이 변경되지 않게 하는 것
원리
항목들의 속성이 버전 번호 역할을 하게 됨
- 이 버전 번호에서 동일 조건을 확인하게 됨
만약 위 항목에 first_name 을 업데이트 하기 위해 2명의 클라이언트가 접근한다고 할때
기존 version 의 값이 1일때 라는 조건부를 달고 update 를 하게 되면
동시에 요청이 들어와도 먼저 온 요청을 처리한 후 version 값이 업데이트 되기 때문에
이후에 들어온 비슷한 다른 요청은 처리되지 않는 것
323. DynamoDB Accelerator (DAX)
DAX 는 DynamoDB 를 위한 완전 관리형, 고가용성, 무결절성인 메모리 캐시 이다.
가장 인기 있는 데이터를 캐시 한다면 캐시 된 읽기와 쿼리에 마이크로 초의 지연 시간이 생김
- 이는 애플리케이션 로직에 어떠한 변경을 요청하지 않음
- 기존 dynamoDB API 와 호환됨
'Hot Key' problem 해결 가능
5분 TTL for cache (default)
DAX 클러스터는 노드로 구성되어있고 미리 프로비저닝 해야함
- 클러스터에는 최대 10개의 노드를 가질 수 있음
노드가 최소 3개 이상인 다중 AZ 설정을 사용하는 것이 프로덕션 권장 사항임
완벽한 보안 제공, 미사용시 암호화, IAM 애플리케이션과 VPC 보안, CloudTrail 통합 등 지원
DynamoDB Accelerator (DAX) vs ElastiCache
두 캐시 노드를 결합해서 사용 할 수 있음
DAX 는 쿼리, 스캔이나 혹은 개별 객체에 관한 캐시를 갖게 됨
ElastiCache 는 애플리케이션 로직 측면에서 작업을 하는 경우 - 스캔, SUM 등의 연산 사용, 데이터 필터링 등
323. DynamoDB Accelerator (DAX)
DAX 는 프리티어가 없기때문에 비용이 발생한다고 함
클러스터 이름 설정
노드 패밀리 탭에서 실행할 노드 유형을 선택할 수 있다
t 형과 r 형이 있는데 실습에선 t2.small 로 진행했다
클러스터 노드 수는 3개가 권장되고 이는 multi-az 를 사용하기 위함이다
그 이하로 설정하면 가용성 저하 경고문이 나오게 되지만 일단 실습에선 1개로 하고 진행
클러스터는 서브넷 그룹 안에 포함되어있어야 하며 없을 경우 생성해준다
vpc 안에서 실행되며 여러개의 서브넷은 다중 az 를 의미한다
보안그룹으로 포트 8111 과 암호화 사용 시 9111을 열어줘야 한다고 한다
지금은 그냥 기본 vpc 선택해서 진행
az 를 자동 할당할 수도 있고 직접 az 를 지정할 수도 있다
지금은 그냥 자동으로 진행
dynamoDB 테이블에 액세스 할 때 노드에서 접근하기 위한 권한을 생성해 준다
아래에서 새로 생성해 줄 수 있고
정책 옵션이나 접근할 수 있는 테이블을 특별히 지정할 수도 있다
암호화는 모두 켜놓고
다음
파라미터 그룹을 지정하거나 새로 생성할 수 있다
클러스터의 모든 노드에 적용되는 구성 세트 라고 한다
파라미터는 항목에 대한 ttl 과 쿼리에 대한 ttl 을 설정할 수 있다
멀티 az 사용 시 노드 소프트웨어 업데이트 및 패치 시 사용되는 기능이다
실습에서는 기본 설정 없음으로 하고 진행했다
클러스터 생성
위에서 확인할 수 있는 클러스터 앤드포인트는 애플리케이션이 활용할 DAX 기능이다
노드를 새로 추가할 수 있지만 노드 유형은 변경할 수 없다
DAX 는 비용이 청구되기 때문에 실습 후 바로 삭제해 줬다
(2.10 끝)
(2.12 시작)
325. DynamoDB 스트림
스트림은 테이블에서 발생하는 생성, 업데이트, 삭제와 같은 항목 수준 수정의 정렬된 목록
- 항목을 편집할때마다 수정 사항을 스트림에서 확인할 수 있음
- 스트림은 테이블의 전체 수정 사항 목록을 나타냄
스트림 데이터는 여러 곳으로 보내지게 됨
- KDS (Kinesis Data Streams)
- AWS Lambda
- KCL (Kinesis Client Library applications)
스트림의 데이터 보존 주기는 최대 24시간
- 보존성이 좋은 다른 스토리지에 저장하는 편이 좋음
use cases :
dynamoDB 테이블에서 발생하는 실시간 변경 사항에 대응할 때 (사용자에게 보내는 환영 메세지 등)
데이터 분석
스트림을 변경할 때
dynamoDB 에서 파생 테이블을 생성할 때
일래스틱서치에 데이터를 보낼 때 (인덱싱 + dynamoDB 에 검색기능 제공)
글로벌 테이블과 cross-resion replication 구현을 위해
스트림에서는 표시할 정보를 선택할 수 있는 기능이 있음
- KEY_ONLY 는 수정된 모든 키 속성의 리스트를 보여줌
- NEW_IMAGE 는 수정된 새 항목을 나타냄
- OLD_IMAGE 는 수정 전의 모든 항목을 나타냄
- NEW_AND_OLD_IMAGES 는 전체 정보를 얻을 수 있음
dynamoDB 스트림은 샤드로 구성되어 있음 - kinesis data stream 과 유사함
- dynamoDB 의 어떤 사드도 프로비저닝이 필요하지 않음 - aws 가 자동 실행해줌
레코드는 스트림에서 소급해서 보낼 수 없음
스트림을 활성화하면 dynamoDB 테이블에 나타나는 변경 사항을 기반으로 한 업데이트를 받게 됨
dynamoDB Streams & AWS Lambda
dynamoDB Streams 에서 읽기 위해 이벤트 소스 매핑을 정의해야 함
람다 함수가 DynamoDB Streams 에서 폴링 할 수 있는 적합한 권한이 있는지 확인 해야함
326. DynamoDB 스트림 - 실습
이전에 만들었던 UserPosts 테이블에서 스트림을 활성화 한다고 함
테이블 메뉴에서 '내보내기 및 스트림' 항목의 맨 아리로 가서 스트림을 활성화 해줌
최대한 많은 정보를 얻기 위해 new_and_old_images 로 스트림 활성화
이후 스트림에서 사용할 트리거를 생성해준다
트리거에 연결되는 lambda 함수를 생성해준다
블루프린트로 이미 작성된 python 함수를 사용하고
역할은 기본 lambda 권한을 가진 새 역할을 생성해주도록 했다
테이블을 선택해주고 배치 크기와 시작 위치를 선택해주고
함수 생성
그러면 오류가 발생하는데
권한이 제대로 설정되지 않았기 때문이다
함수 메뉴의 configuration 의 permissions 탭에 보면
실행 역할에 dynamoDB 에서 읽기할때 필요한 권한을 부여해준다
위 선택한 두 권한 중에 lambda 에서 dynamoDB 를 읽을 권한이 있을꺼니까 2개 다 선택해줬다고 한다
정확히 모르는듯?
json 읽어보면 되겠지만 그냥 두개 다 선택해준다
권한 상 문제는 없기 때문
트리거 생성
이제 dynamoDB Streams 가 람다 함수를 트리거 하게 됨
이제 테이블의 편집 사항들을 lambda 함수 모니터링에서 확인할 수 있는데
이를 위해 테이블에서 몇가지 편집을 한 후
확인해보면
람다 함수의 cloudwatch logs 의 로그 스트림이 있고 그 안에서 MODIFY, INSERT, REMOVE 등으로 로그를 확인할 수 있다
실습이 끝난 후 람다 함수에서 트리거를 제거해줬다
비용이 청구되나봄
327. DynamoDB TTL
TTL 을 사용하면 타임 스탬프 만료 이후에 자동으로 아이템을 삭제할 수 있음
TTL 만료 삭제 시 WCU 는 소모되지 않음 - 추가 비용 발생 X
타임스탬프 값은 Unix Epoch 타임 스탬프의 값을 나타내는 숫자여야 함
TTL 이 만료된 아이템은 즉시 삭제되는것은 아니고 만료 후 48시간 이내 삭제되도록 보장하고 있음
- 테이블 쿼리 시 TTL 이 만료됬지만 48시간이 지나지 않아 삭제되지 않은 항목이 같이 검색될 수 있음
- 클라이언트 측 필터링으로 거를 수 있음
USER_ID, Session_ID 의 만료를 ttl 로 설정해서 세션 만료를 컨트롤 할 수 있음
아이템이 삭제될 때는 인덱스에서도 삭제됨 - both LSIs and GSIs
만료된 각 아이템 삭제 작업은 DynamoDB Streams 에 들어감 - TTL 만료로 인해 삭제된 아이템은 모두 스트림에 있기 때문에 원할 때 복구 할 수 있음
use cases :
현재 항목만을 유지하여 저장된 데이터를 줄이거나 규제 의무를 지키려는 경우
- SessionData, 회원 정보 등
실습
실습을 위해 테이블을 새로 만들어줬다
이름은 DemoTTL 이고 파티션 키는 user_id 로 하고 정렬키는 없이 했다
테이블 유형은 사용자 설정으로 하고 테이블 클래스는 스탠다드
RCU/WCU 는 각각 1로 설정해줬고 오토스케일링은 OFF 하고 테이블 생성
테이블에 몇가지 데이터를 삽입한다고 함
그 전에 만료 날자는 unix epoch 시간을 따르는데
구글에 검색하면 이렇게 변환기가 나옴
활용하거나 따로 코딩해서 사용할 수 있다
현재 시간 기준 5분 후 만료 데이터 1
현재 시간 기준 1시간 후 만료 데이터 2
dynamoDB 메뉴 중 추가 설정 에 들어가서 ttl 설정 탭에 들어가서 설정할 수 있다
시뮬레이트된 날자 및 시간으로 평가판을 실행하면 삭제될 항목들을 미리 확인할 수 있다