[week21] DynamoDB

review/week19/지선의.md

@@ -0,0 +1,174 @@
+# 서버리스
+
+클라우드 네이티브
+
+- 소프트웨어 설계
+
+인스턴스 패칭 적용
+
+- 실행중에 변경 가능
+- 블루 그린 배포? 무중단 인스턴스 배포 가능
+
+아마존에서 오토스케일링이 안되는 것도 많은데 왜 오토스케일링이 서버리스의 장점인가?
+
+- 로드벨런서를 안 붙여도 되니까 서버리스에서의 장점이 되지 않을까
+
+패칭
+
+- 람다를 킨다는게 기계를 빌리는게 아닌 컨테이너 관리
+
+서비리스의 가장 큰 장점은?
+
+- 빠른 배포, 비용 절감
+
+# 람다
+
+이벤트를 통해 다른 동작을 불러와줌
+
+변경에 의해서만 이벤트가 발생하나?(get 요청 빠지나?)
+
+- Get 도 받음
+- http 메서드랑 같이 이벤트를 받을 수 있음
+- 람다는 실제 로직이 돌아가는 부분이고 http 처리해주는 로직은 api gateway를 통해
+
+람다는 호출될때만 비용 발생
+
+람다와 게이트 웨이 api 는 따로 청구됨
+
+람다 특징
+
+- 런타임
+ - 최대 300초 런타임만 허용
+- 공간
+ - 최대 512MB
+ - Lambda함수가 구동할 때 가상 컨테이너를 통해 가상 공간이 만들어짐
+ - 도커와 같음
+ - /tmp/
+- 허용 패키지
+ - 50MB 패키지 허용 가능
+ - 초과시 S3 버킷 사용
+ - 애초에 50MB 초과하면 서비리스를 사용하는게 아니라 인스턴스를 사용하는게 좋지 않을까
+
+도커
+
+- 프로세스 격리된 기술을 사용한 컨테이너
+- 어느 환경에서도 똑같은 코드로 돌아가게 할 수 있도록 해줌
+- 애플리케이션과 그 종속성을 다른 환경에서도 동일하게 작동하게 함
+- VM -> AWS의 EC2 기본 엔진
+ - 높은 수준의 격리와 보안이 중요할때
+- 컨테이너
+ - OS가 없음
+ - 느린 가상화방식을 해결할 수 있는 프로세스 격리 방안
+ - 종속성만 가져가면 됨
+ - 경량, 빠른시작, 리소스 효율성이 필요한 경우
+
+람다 사용 사례
+
+- S3 버킷 파일 업로드
+- 아두이노 활용
+ - 온도 데이터 수집을 총해 데이터 전처리
+
+람다 함수는 즉 중간다리 역할
+
+이벤트에 의해 실행되서 스스로 동작하는 것이 아니라 전제 조건이 만족되어야 실행됨
+
+람다의 조심
+
+- 리스폰스 형태를 그대로 맞춰줘야 함
+- Api gatway랑 항상 붙어서 동작하는데 안붙여도 할 수 있는데 붙이는게 처리나 보안면에서 추천
+
+계정 동시성
+
+- 람다가 많이 콜되면 비용이 많이 들 수 도 있고 해서 일부로 막아둠
+- 이 숫자 안에서 오토스케일링이 일어남
+
+디비커넥션을 관리해주는 서비스가 있음
+
+# 로드밸런싱
+
+로딩 분산
+
+트래픽이나 요청 부하를 균등하게 분할하는 기법
+
+예시로 은행에서 번호표를 뽑는 것과 같음
+
+그래서 로드밸런싱 왜 하나?
+
+- 슈퍼컴퓨터가 있다면 이 컴퓨터 하나에서 모든걸 할 수 있고 관리도 쉬울수도 있지만 실제로는 이게 안되니까
+- 컴퓨터를 여러대로 쪼개개 됨
+- 이러면 어떠한 컴퓨터에게 어떻게 적절하게 분배를 하게 되나가 문제가 됨
+ - 스케일 아웃 업의 한계때문에 스케일 아웃이 필요하게 되었고 이를 위해 로드밸런싱이 필수적이게 됨
+
+로드밸런서
+
+- 프록시의 사용 예시 중 하나
+
+클라이언트 -> 포워트 프록시 -> 인터넷 -> 리버스 프록시 -> 서버
+
+포워트 프록시
+
+- 대표적으로 캐시, CDN
+ - 사이트에 접속한다고 하면 광고가 들어있음
+- VPN
+- 요약하면 클라이언트 정보를 숨길 수 있고 캐싱할 수 있음
+
+리버스 프록스
+
+- 캐싱, 보안, 로드밸런싱
+- nginx를 떠올리면 쉬움
+- 클라이언트의 주소도 숨길 수 있음
+- 서버와 인터넷 사이에 있어서 서버에 넘어가기 전에 한 번 거치는 것
+
+그래서 프록시란?
+
+- 클라이언트, 인터넷, 서버 사이에 있으면 다 프록시가 됨
+- 어떻게 쓰느냐에 따라 달라진다는 것
+- 그래서 로드밸런서 또한 인터넷 -> 서버 사이에 존재함
+
+로드밸런서가 로드밸런싱을 위해 하는 일
+
+- 헬스체크
+ - 핵심은 주기
+ - 얼마나 짧게 할 건지 길게 할건지
+- NAT
+ - 사실 <-> 공인 아이피 변환 진행
+- DSR
+ - 클라이언트 -> 인터넷 -> 서버 진행 방향에서 다시 서버에서 클라이언트로 넘어갈 때 서버에서 인터넷으로 로드밸런서를 통해서 지나가면 무리가 있으니 바로 클라이언트에게 넘겨줄 수 있게 하는 것
+- 터널링
+
+로드밸런싱은 어떻게 하나?
+
+- 알고리즘의 종류
+ - 라운드 로빈
+ - 순서대로 요청을 전달
+ - 단점
+ - 요청의 종류를 알 수 없음
+ - 균등하게 배분했지만 만약 어느 한 인스턴스가 긴 요청을 받았을 경우 그 요청을 받은 인스턴스는 고통받을 수 밖에 없음
+ - 라운드 로빈 알고리즘으로 로드밸런서를 쓰면 좋은 경우
+ - 최소 연결 방식
+ - 현재 연결된 세션 수가 가장 적은 서버에 요청을 할당하는 방식
+ - 예시로 가게에 줄이 가장 짧은 순서로 요청을 보내줌
+ - 하지만 이것도 각 요청이 긴지 짧은지 모른다는 점이 있음
+ - 리소스 기반 방식
+ - 헬스체크를 통해 각 서버에서 동작중인 에이전트로부터 서버의 현재 리소스 현황를 전송받고 이를 기반으로 가장 리소스가 여유있는 서버에게 요청 전단
+ - 오버헤드 발생 가능성 있음
+
+로드밸런서의 종류
+
+- L4 로드밸런서
+ - Transport layer
+ - 간단하고 빠르고 쌈
+- L7 로드밸런서
+ - Application layer
+ - 느리고 비싸지만 자세함
+
+# **VPC Reachability AnalyzerVPC Reachability Analyzer**
+
+Aws 버전 traceroute
+
+- 네트워크 트레이스 용 도구로 내 AWS 인스턴스간의 네트워크 연결 방식을 트레이싱하고 분석하는 것을 도와주는 도구
+- 인스턴스 접근 가능 여부를 확인 할 수 있음
+
+로드벨런서가 SSL/TLS를 해주냐?
+
+- 그냥 로드밸런서가 해줌

review/week20/지선의.md

@@ -0,0 +1,75 @@
+# CloudFront
+
+CDN
+
+- 네트워크 설계로 인해 발생하는 통신 지연을 줄이기 위한 것
+- 다른 리전에서 접근할때의 지연 시간을 줄이기 위해
+- 우리나라에만 4개의 데이터 센터 존재
+- 제공 방법
+ - 객체에 대한 요청을 보냄
+ - 사용자 입장에서 가장 가까운 클라우드프론트로 리다이렉팅(DNS에서 가장 가까운 클라우드 프론트 정보를 가지고 있음)
+ - 다음부터는 캐시서버랑 똑같이 요청된 객체가 있으면 사용자에게 반환
+
+클라우드 프론트는 캐시를 두 단계로 나눠서 관리
+
+- 전역 엣지 로케이션인 POP은 사용자에게 가장 가까운 위치
+- 리전 엣지 캐시는 리전내에 위치하며 POP을 도와줌
+
+사용 사례
+
+- 클라우드 프론트를 효과적으로 사용할 수 있는 것 중 하나는 라이브 스트리밍
+- 유튜브는 일본 트패픽으로 사용
+- 라이브 스트리밍은 초당으로 파일일 계속 업데이트 시키면서 가져옴
+- 그래서 이 딜레이를 줄이는게 핵심. 그래서 CDN 사용하거나 각 국에 캐시서버를 둬서 관리하는 것
+- 보안에 있어서도 쉽게 처리 가능(접속 차단)
+- 데이터 백업 용도로도 사용 가능
+
+정책
+
+- 정책도 지정 가능해서 사용자가 미리 지정해줄 수도 있고 프록시 역할도 해줌
+
+장점
+
+- 지연 시간을 줄일 수 있음
+- 보안 관리 용이(DDos)
+- 인증서 관리와 자동 갱신 제공
+
+요금
+
+- 데이터를 전송할때만 청구
+- 하지만 비쌈
+- 대부분 동영상이나 대규모 파이를 보낼때 사용하기 때문에 비쌀 수 밖에 없음
+
+기타
+
+- 캐시 기능으로 인해 원본 업데이트가 안될 수 있음(수정할때)
+ - 이럴때 무효화 기능을 총해 수정된 파일이 캐시로 바로 반영하도록 설정할 수 있음
+
+Q. 클라우드 프론트를 사용하면 프록시처럼 헤더 붙여서 보낼 수 있나?
+A. 가능. 리다이렉트 가능
+
+# CIDR
+
+클래스 없는 도매인 간 라우팅 기법
+
+서브넷팅은 CIDR의 서브셋
+
+표기법
+
+- A.B.C.D/N
+- 분리된 4개의 네트워크와 각 62개의 호스트를 가진 네트워크를 사용한다는 것을 의미
+
+AWS CIDR
+
+관리형 접두사 목록
+
+- 하나 이상의 CIDR 블록 세트
+- 접두사 목록을 사용해서 보안 그룹과 라우팅 테이블을 보다 쉽게 구성하고 유지관리 가능
+
+SSH를 허용하는 IP주소가 많아지게 되면? 관리가 어려워짐
+
+이를 위해 관리형 접두사 목록을 사용함
+
+문제 : 대부분 작동 시간 중에는 다른 리전의 가상 데스크톱에서 액세스하지만 테스트 기간에는 집 PC에서 접근해야 gka
+
+해결 : AWS가 제공하는 IP 주소 범위 목록을 사용해 해당 리전의 WorkSpces 게이트웨이의 CIDR 범위 목록을 포함하는 관리형 접두사 목록을 각각 만들어 보안 그룹에 연결한다. 테스트를 위해서는 임시로 집의 IP 주소를 접두사 목록에 추가했다가 테스트 종료 시 IP 주소를 삭제한다.