Query Hash, Range key로 설정한 애들로 indexing 처리가 되어있기 때문에 전체 데이터를 살펴보지않고도 두 key를 이용해서 데이터를 찾을 수 있다.
Range key는 이름답게 ==이 아닌 대교비교도 가능하다. (내부적으로 Hash + Btree 로 indexing을 하고있을 것 같다)
3. GSI, LSI
테이블을 위와같이 만들면 WHERE key1=A AND key2=B 같은 쿼리는 가능하겠지만 WHERE key3=A 같은 쿼리는 불가능하다. 그럼 또 맨땅에 헤딩식인 Scan을 써야하는데 그게 싫다면 Secondary Index을 쓰면 된다. 종류는 두 가지가 있다.
Local Secondary Index 기본 Hash Key에 *Range Key 조합을 더 두는 방식이다. 테이블을 생성할 때만 세팅이 가능하기 때문에 처음부터 잘 설계해야한다. 나중에 LSI를 추가하고싶어지면 기존 테이블을 삭제하면서 마이그레이션 하는 방법 밖에 없다.
key1 * key2 이외에도 key1 * key3 혹은 key1 * key4 로 인덱싱을 하나 더 하겠다는 뜻이다. 테이블 자체의 기본 Hash Key(key1)에 공생하는 range key를 하나 더 파서 인덱싱한다 해서 Local이라는 이름이 붙은것 같다.
보조 인덱스를 추가할때 (테이블 Hash key== 보조인덱스 Hash key) && Range key 선택 이여야만 LSI로 만들기 checkbox가 활성화 된다.
Global Secondary Index 테이블 자체의 기본 Hash Key에 공생하지 않고 새로운 Hash Key (+Range Key)를 둬서 인덱싱을 하겠다는 뜻이다. GSI는 테이블 생성 후에도 설정가능하고 추후 변경, 삭제가 가능하다. key3 key3*key4 key4*key3
위처럼 인덱싱이 가능하다. LSI에서처럼 key1*key2를 해도 상관없다. 어차피 새로운 Hash Key를 둬서 인덱싱하는 것이기 때문에 같던 말던 dynamoDB는 상관 안한다. 어? Hash key이름이 key1인데 LSI로 하고 싶으면 체크해라 아니면 그냥 GSI로 한다 ~~ 라고 체크박스를 표시해준다.
GSI를 추가하고 난 뒤 해당 key를 이용해 쿼리를 날릴 수 있게 되었다.
Secondary Index 의 Hash*Range는 고유할 필요 없다. 기본 테이블의 Hash*Range만 고유하면 된다.
front-end nuxt 프로젝트 빌드 -> html+script로 전부 변환 -> 정적 리소스가 되어 S3버킷에 올라감 웹브라우저에서 정적리소스 (웹페이지) 요청 https://dev.myapp.cloud -> Route53 -> CloudFront -> S3
-Route53 : DNS기능, 가비아같은놈 -S3 : 저장소, 실제 nuxt 빌드된 프로젝트가 저장되어있음 -CloudFront : CDN, S3 캐싱기능 ex) 브라우저 : 한국, S3버킷 : 미국 - 멀리있을때 a) CloudFront에 리소스 있는지 조회 b) 없으면 S3가서 갖고옴. 처음엔 오래걸림. c) CloudFront에 캐싱 d) 다음요청때부턴 CloudFront에서 빠르게 가져올수있음
backeend 1에서는 껍데기만있는 페이지를 받음. 내용은 없는상태 axios로 api호출해서 비동기로 내용채워넣음 ex) GET : dev-api.myapp.cloud/users/1259012 -> Route53 -> API Gateway -> lambda -API Gateway : HTTP Request 라우팅기능, 람다 함수에 매핑하는기능 -lamba : 직접 작성한 함수
lambda 요청을 받았으면 db에 연결해서 리턴해주던 저장하던 처리를 해야함 controller(핸들러, 라우팅), service(비즈니스 로직), repository(DB CRUD)로 분류 dynamoDB와 연결 : aws-sdk 이용, 이때 credential 필요 AWS 리소스(S3, dynamoDB, lambda 등)을 sdk로 이용하려면 credential 있어야함. IAM에서 발급가능
offline <-> AWS serverless framework : offline에서 개발하고 실행해서 테스트하고 deploy해서 AWS에 동기화 가능 resource.yml : dynamoDB 관련 설정파일 functions.yml : API Gateway 관련 설정파일 functions/*.ts: lambda 코드 작성 serverless.yml : 프로젝트 전체 설정파일 (lambda가 갖는 권한, S3 권한 등) ex) lambda에서 cloudwatch에 로그를 찍을수있는 권한이 있어야 로그출력 가능 ex) S3버킷 getObject를 하기위해선 sdk로 S3 connection을 open하는 credential도 있어야하지만, S3 CRUD를 실행하는 lambda가 실행권한도 있어야함
Cloud Watch lambda -> 모니터링 -> cloud watch에서 보기 : 람다함수내에 console.log 해논애들이 여기 전부 찍힘 한줄한줄이 다 돈임
s3버킷이름, path를 지정해서 download받을수있는 signed url을 제공받는 방식
Cloud Front
AWS console에서 Cloud Front 설정을 해준다.
route53
cloudfront
목적지
cloudfront.test
a1b2c3d4.cloudfront.net
S3-mybuket
위와 같이 설정하면 cloudfront CDN기능을 사용할수있게 된다.
S3 버킷은 아무 브라우저에서나 접근할 수 없게 해야하기 때문에 쿠키를 만들어 넘겨줘야한다.
비대칭키 한 쌍을 만든다.
-----BEGIN RSA PRIVATE KEY-----
1289uQWh9128HQhu912.....
-----END RSA PRIVATE KEY-----
-----BEGIN RSA PUBLIC KEY-----
6HA1Z5911289uQWh9122.....
-----END RSA PUBLIC KEY-----
AWS console S3 - keys에 접속한다.
public key를 import 한다. 그럼 key-pair-id가 생성된다.
A2BCH5S0WXGYFE
aws-sdk CloudFront를 사용해서 signer를 생성한다. ex) const signer = new CloudFront.Signer(key_pair_id, private_key); private_key는 비대칭키 한쌍을 만들 때 생성된 private key이다.
