[CloudFront 소개 및 구축]
[Origin Domain Name]은 만든 bucket중에서 실질적으로 적용할 것을 지정한다. Client에서 CloudFront를 적용하게 된다. Origin Path는 시작점을 정할 수 있다. bucket 아래에 있는 /로 하려면 빈공간으로 두면 된다
[Oirign ID]는 내가 설정하고 싶은 이름을 쓰면 된다. PUBLIC ACCESS는 모두 접근이 열려있기 때문에 [Restrict Bucket Access]는 YES를 누른다. Origin Access identity는 Use an Existing Identity를 사용한다. (미리 있는 경우이다.)
[Grant Read Permission]은 꼭 Yes를 해야한다. 만약에 새로운 권한 버킷정책이 바뀌면 해당 내용을 반영하겠다는 의미이다. Object에 직접 요청을하면 get비용이 발생하기 떄문에 실제 서비스에서는 엔드포인트에 바로 접근하지 못하도록 막는다.
보통 HTTPS를 이용하거나 HTTP and HTTPS를 사용하여 REDIRECT를 한다. 허용되는 HTTP Methods는 GET, HEAD를 넣어준다. [Cache Base on Selected Request Headers]는 특정 header값을 통해서 해당을 기준으로 구분지을 수 있다. ALL은 캐싱이 거의 안된다고 보면 된다.
[Object Caching]은 메타데이터로 캐쉬를 설정할 경우 Origin이 있는 것을 사용할 것인가(메타 데이터를 사용할 것인가) 정한다. TTL 규칙은 공식문서에 자세하게 나와있으므로 전략에 따라서 잘 확인하고 사용한다.
[Query String Forwarding and Caching]으로 구분자를 다르게 할 수 있으므로 버전마다 요청을 pause시킬 수 있다. None으로 해두고 가끔 사용한다.
[Compress Objects]는 압축을하는지 안하는지 정할 수 있다. 따라서 파일크기가 작아지고 다운로드 속도가 빨라진다. 용량은 약 1/4로 줄어들게 된다. Yes를 하고 사용하면, Encoding타입은 gzip을 해야한다. 그렇지 않으면 해당 파일들을 압축하지 않는다. 따라서 압축 확장자명을 잘 확인한다.
[Lambda Edge]는 람다함수를 추가할 수 있다. 람다함수 4가지를 할 수 있다.Client로부터 cache에 요청을 받고 Originserver에 넘길때, OriginServer 응답을 Client에 넘길 때 총 4번이다.
[DefaultRoot Object]로 정상적으로 원하는 경로로 리다이렉팅이 된다. 대부분 index.html로 한다.
[DynamoDB 소개 및 구축]
NoSQL 데이터베이스이다. 테이블을 생성하기위해 테이블 이름, 기본키를 정한다. (book, book_id) 만들어진 테이블 항목을 눌러서 원하는 칼럼을 추가할 수 있다. 일반적인 RDS와 다르다. docker에서 run으로 MYSQL을 실행하고, exec로 MYSQL 안으로 접근해서 컨테이너 안에 있는 터미널을 이용한다. MYSQL은 서버를 할당해야하는데, NoSQL은 서버 할당이 불필요하다. MYSQL도 기본키를 생성하는데 mysql의 경우 auto_increment를 사용해서 자동으로 테이블의 행이 생성될 떄마다 1이 증가하도록 한다. 그러면, id에 null을 넣어도 계속 1이 증가한 형태로 행이 저장된다. 또한 정의되어있지 않은 필드값을 넣을려고하면 오류가 난다. 하지만, NoSql은 필드값이 아무것이나 들어와도 괜찮다.
DynamoDB는 ACID 트랜잭션을 지원한다. RDS가 아니지만, RDS의 특징인 ACID를 지원한다. DynamoDB는 기본설정을 제외하면 온디맨드 방식으로 만들 수 있다. 하지만 굉장히 비용이 많이 필요하다. 읽기 일관성은 최종적 일관된 읽기 혹은 강력한 일관된 읽기가 있다. 가용영역이 서울에 3개인데, DynamoDB에서 정합성을 위해 저장한다. 그런데, 쓰기 도중에 데이터를 지우면 없는 상태로 리턴받는다. 이게 최종적 일관된 읽기이다. 하지만 모든 데이터가 정말 똑같은 상태에서 동일한 데이터를 가질 때 데이터를 리턴해주는 특징이 있다. 정합성이 맞는만큼 속도가 느려질 수 있다.
프로비저닝은 3년동안 180달러정도 한다. 예약용량으로 Auto-scale을 하면 적정가격으로 이득을 볼 수 있다. 기본키는 유니크해야된다. 만약에 작가가 착을 낸다고하면 작가는 복수의 책을 낼 수 있으므로 작가이름을 유니크한 프라이머리키로 만들면안된다. 복합키로 만들어주어야 하는데 BOOK과 AUTHOR를 한데 묶어서 기본키를 만들어준다. 그렇다면 작가는 A책만 아니라 B책도 저장을 성공적으로 끝낼 수 있다. String 뿐만 아니라 다양한 리턴타입을 넣을 수 있다.
[SNS로 관리형 메세지 만들기]
Lambda작성 준비를 끝내는 SNS를 알아본다. 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리이다. 서버리스는 단점이 무상태 기능을 구현해야 하는 것이다. 람다끼리 전달할 때 메모리에 데이터를 공유할 수 없고 변화를 알 수 없기 때문에 중간에 SNS로 중재해야 한다. 병렬 프로세싱을 위해 대규모 구독자의 엔드포인트로 메세지를 팬아웃할 수 있다. 게시자가 토픽에 특정 메세지를 보내면 구독하고있는 다양한 구독자들이 주제를 기반으로 메세지를 자신의 것을 찾아서 이용한다. 팬아웃은 깔때기처럼 나가는 것을 의미한다. 쉽게 다양한 서비스들을 구독형태로 서비스할 수 있다. SNS 특정 주제를 구독하고 있는 구독자들을 선택할 수 있다.
필수 링크 확인
본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.
'회고 > aws&docker fastcampus' 카테고리의 다른 글
AWS/Docker 클라우드 패스트캠퍼스 챌린지 29일차 (0) | 2021.10.04 |
---|---|
AWS/Docker 클라우드 패스트캠퍼스 챌린지 28일차 (0) | 2021.10.03 |
AWS/Docker 클라우드 패스트캠퍼스 챌린지 26일차 (0) | 2021.10.01 |
AWS/Docker 클라우드 패스트캠퍼스 챌린지 25일차 (0) | 2021.09.30 |
AWS/Docker 클라우드 패스트캠퍼스 챌린지 24일차 (0) | 2021.09.29 |