AWS 입문편

1. AWS - IAM

- 유저를 관리하고 접근 레벨 및 권한에 대한 관리

 

2. AWS - EC2

- EBS (Elastic Block Storage) : EC2를 사용하기 위해 EBS라는 디스크 볼륨을 요구한다.

    ㆍ저장 공간이 생성되어지며 EC2 인스턴스에 부착된다.

    ㆍ디스크 볼륨 위에 File System이 생성된다.

    ㆍEBS는 특정 Availablility Zone에 생성된다.

 

- ELB (Elastic Load Balancers) : 하나의 서버로 트래픽이 몰리는 병목현상 방지

    ㆍ수많은 서버의 흐름을 균형있게 흘려보내는데 중추적인 역할을 함

    ㆍ하나의 서버로 traffic이 몰리는 병목현상 방지

    ㆍTraffic의 흐름을 Unhealthy instance -> healthy instance 로

 

- Route53 : AWS에서 제공하는 DNS 서비스

 

3. AWS - RDS (Relational DB Service)

- Data Warehousing

    ㆍBusiness Intelligence

    ㆍ리포트 작성, 데이터 분석시 사용 ( Production Database -> Data Warehousing )

    ㆍ매우 방대한 분량의 데이터 로드시 사용

 

Database Back-ups

- Automated Backups(AB) - 자동 백업

    ㆍ1. Retention Period(1~35일) 안의 어떤 시간으로 돌아가게 할 수 있음

    ㆍ2. AB는 그날 생성된 스냅샷과 Transaction logs(TL)을 참고함

    ㆍ3. 디폴트로 AB기능이 설정되어 있으며 백업 정보는 S3에 저장

    ㆍ4. AB동안 약간의 I/O suspension이 존재할 수 있음 -> Latency

- DB Snapshot (데이터베이스 스냅샷)

    ㆍ1. 주로 사용자에 의해 실행됨

    ㆍ2. 원본 RDS Instance를 삭제해도 스냅샷은 존재함(vs AB)

 

- Read Replica

    ㆍProduction DB의 읽기 전용 복제본이 생성됨

    ㆍ주로 Read-Heavy DB작업시 효율성을 극대화를 위해 사용됨(Scaling)

    ㆍRead Replica의 Read Replica 생성 가능 (단 Latency 발생)

    ㆍ각각의 Read Replica는 자기만의 고유 Endpoint 존재

 

ElastiCache

    ㆍ클라우드 내에서 In-memory 캐시를 만들어줌

    ㆍ데이터베이스에서 데이터를 읽어오는 것이 아니라 캐시에서 빠른 속도로 데이터를 읽어옴

    ㆍRead-Heavy 어플리케이션에서 상당한 Latency 감소 효과를 누림

종류	설명	이럴 때 사용
Memcached	- Object 캐시 시스템으로 잘 알려져 있음 - ElastiCache는 Memcached의 프로토콜을 디폴트로 따름 - EC2 Auto Scaling처럼 크기가 커졌다 작아졌다 가능함 - 오픈소스	1. 가장 단순한 캐싱 모델 필요시 2. Object caching이 주된 목적 3. 캐시 크기를 마음대로 scaling시
Redis	- Key-Value, Set, List와 같은 형태의 데이터를 In-Memory에 저장 가능함 - 오픈소스 - Multi-AZ 지원	1. List, Set과 같은 데이터셋을 사용시 2. 리더보드처럼 데이터셋의 랭킹 정렬시 3. Multi AZ 기능 사용시

 

4. AWS - S3 (Simple Storage Service)

특징	S3 Object 구성요소	S3 Data Consistency Model
- 안전하고 가변적인 Object 저장공간을 제공 - 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있음 - 파일 크기는 0KB부터 5TB까지 지원 - 저장공간 무제한 - Bucket이라는 이름을 사용함 (디렉토리와 유사함) - Bucket은 보편적인 namespace를 사용함	- Key - Value - Version ID - Metadata - CORS   (Cross Origin Resource Sharing)	1. Read after Write Consistency(PUT)        : 결과를 바로 확인 가능 2. Eventual Consistency(UPDATE, DELETE)        : 결과가 바로 나타나지 않는다.

 

S3 스토리지

종류	특징
일반 S3	- 가장 보편적으로 사용되는 스토리지 타입 - 높은 내구성, 가용성
S3 - IA(Infrequent Access)	- 자주 접근되지는 않으나 접근시 빠른 접근이 요구되는 파일이 많을시 유용 - 일반 S3에 비해 비용은 저렴하나 접근시 추가 비용 발생 - 멀티 AZ를 통한 데이터 저장 (가용성 높음)
S3 - One Zone IA	- 단일 AZ를 통한 데이터 저장 - 단일 AZ에 의한 데이터 접근 제한 (조금 낮은 가용성) - 데이터 접근시 S3 - IA보다 20% 비용 저렴
Glacier	- 거의 접근하지 않을 데이터 저장 시 유용 - 매우 저렴한 비용 - 데이터 접근시 대략 4~5시간 소요
Intelligent Tiering	- 데이터 접근 주기가 불규칙할때 매우 유용 - 2가지 티어 존재 ( Frequent Tier[비용이 약간 더 높음], Inferquent Tier ) - 데이터 접근주기에 따라 두가지 티어중 하나로 선택됨 - 최고의 비용 절감 효율을 누릴 수 있음

 

버켓 생성시 알아야 할 것들

S3 요금	S3 사용 용례	최초 S3 버켓 생성 시 비공개(PRIVATE)
- GB당 - PUT, GET, COPY 요청 횟수당 - 데이터 다운로드시 / 다른 리소스로 전송시 - Metadata(object tag)	- 파일 저장소   (로그, 다양한 파일들(이미지, 비디오, 압축파일 등) - 웹사이트 호스팅 - CORS	1. 버켓 정책 변경 2. 접근 제어 리스트 변경

 

S3 암호화

- [1] 파일 업로드/다운로드시 - SSL / TLS
- [2] 가만히 있을시 - SEE-S3, SSE-KMS, SSE-C

 

5. AWS - CloudWatch

특징	모니터링 종류
- AWS 리소스 사용의 실시간 모니터링 기능 지원 - 다양한 이벤트들을 수집하여 로그파일로 저장 - 이벤트&알람 설정을 통해 SNS, AWS Lambda로 전송 가능 - [CloudWatch 사용 가능 서비스들] : EC2, RDS, S3, ELB 등등	1. Basic Monitoring     ㆍ무료     ㆍ5분 간격으로 최소의 Metrics 제공 2. Detailed Monitoring     ㆍ유료     ㆍ1분 간격으로 자세한 Metrics 제공

 

사용 용례

- Use Case : 매일 얼마나 많은 사용자들이 모바일 앱을 사용하는지 알고 싶음 - Potential Issue : 특정날에 수많은 traffic이 몰릴 수 있어 병목현상이 생길 수 있음 - Solution : 매일 traffic rate과 특정 버튼의 유저 클릭 횟수를 분석하여 더 효율적인 앱개발을 할 수 있는 통찰력을 얻을 수 있음

- Use Case : 특정 시간대에 웹서버 상태를 점검하여 비용 절감 목표 - Potential Issue : 똑같은 비용을 내며 AWS 리소스들을 사용하지만 낮시간대와 밤시간대에 필요한 서버의 성능이 달라질 수 있기 때문에                                금전적 손실이 생길 수 있음 (주로 밤시간대가 낮시간대보다 서버가 오랫동안 idle) - Solution : 알람 설정을 통하여 특정 threshold에 도달했을때 개발자에게 상황을 보고해줌으로서 서버 management를 할 수 있음

 

- Alarm State

    ㆍAlarm

    ㆍInsufficient

    ㆍOK

 

 

6. AWS - Lambda

특징	비용	기타
- Serverless의 주축을 담당 - Events를 통하여 Lambda를 실행시킴 - NodeJS, Python, Java, Go 등 다양한 언어 지원 - Lambda Function	- Lambda Function이 실행될때만 돈 지불 - 매달 1,000,000 함수 호출 시 무료	- 최대 300초(5분) 런타임 시간 허용 - 512MB의 일시적인 디스크 공간 제공 - 최대 50MB Deployment Package 허용

 

7. AWS - CloudFront

특징	용어 정리
- 정적, 동적, 실시간 웹사이트 컨텐츠를 유저들에게 전달 - Edge Location을 사용 - 컨텐트 딜리버리 네트워크 Content Delivery Network(CDN) - 분산 네트워크(Distributed Network)	- Edge Location(엣지 지역) : 컨텐츠들이 캐시에 보관되어지는 장소 - Origin : 원래 컨텐츠들이 들어있는 곳, 웹서버 호스팅이 되어지는 곳                  S3, EC2 인스턴스가 오리진이 될 수 있음 - Distribution(분산) : CDN에서 사용되어지며 Edge Location들을 묶고 있다는 개념

 

8. AWS - DynamoDB

특징

- NoSQL 데이터베이스 - 매우 빠른 쿼리 속도 - Auto-Scaling 기능 탑재 - Key-Value 데이터 모델 지원 - 테이블 생성시 스키마 생성 필요 없음 - 모바일, 웹, IoT 데이터 사용시 추천됨 - SSD 스토리지 사용

 

 - DynamoDB - Primary Keys

파티션키(Partition Key)	복합키(Composite Key)
- 고유 특징(Unique Attribute) - 실제 데이터가 들어가는 위치를 결정해줌 - 파티션키 사용시 동일한 두개의 데이터가 같은 위치에 저장될 수 없음!	- 파티션키(Partition Key) + 정렬키(Sort Key) - 예시 : 똑같은 고객이 다른 날짜에 다른 물건을 구매 - 파티션키 : 고객아이디 / 정렬키 : 날짜(Timestamp) - 같은 파이션키의 데이터들은 같은 장소에 보관,     그 다음 정렬키에 의해 데이터가 정렬됨.

 

- DynamoDB - Index

특징

- 특정 컬럼만을 사용하여 쿼리 - 테이블 전체가 아닌 기준점(pivot)을 사용해 쿼리가 이루어짐 - 매우 큰 쿼리 성능 효과 - 두가지의 Index 유형 존재     ㆍLocal Secondary Index     ㆍGlobal Secondary Index

Local Secondary Index(LSI)	Global Secondary Index(GSI)
- 테이블 생성시에만 정의해줄 수 있음 - 따라서 테이블 생성 후 변경, 삭제가 불가능 - 똑같은 파티션키 사용, 그러나 다른 정렬키 사용	- 테이블 생성후에도 추가, 변경, 삭제 가능 - 다른 파티션키, 정렬키 사용

 

- DynamoDB - Query VS Scan

Query	Scan
- Primary Key를 사용하여 데이터 검색 - Query 사용시 모든 데이터(컬럼) 반환 - ProjectionExpression 파라미터	- 모든 데이터를 불러옴 (primary key 사용 X) - ProjectionExpression 파라미터
- Query가 Scan보다 훨씬 효율적임 - 따라서 Query 사용 추천

 

 

- DynamoDB - DAX (DynamoDB Accelerator)

DAX란?	DAX의 원리
- 클러스터 In-memory 캐시 - 10배 이상의 속도 향상 - 읽기 요청만 해당사항 (X 쓰기요청) - Ex) Black Friday날 쇼핑 웹사이트 운영(수많은 읽기 요청 예상)	- DAX 캐싱 시스템     → 테이블에 데이터 삽입 & 업데이트 시 DAX에도 반영 - 읽기 요청에 맞는 데이터가 DAX에 들어있을시    DAX 데이터 즉시 반환 (Cache Hit) ↔ (Cache Miss)
DAX의 단점
- 쓰기 요청이 많은 어플리케이션에는 부적절함 - 읽기 요청이 많지 않은 어플리케이션에 부적절함 - 아직 모든 지역에서 제공하지 않음

 

- DynamoDB - Streams

설명

- DynamoDB 테이블에서 일어나는 일들(삽입, 수정, 삭제 등)이 일어날 시 시간적 순서에 맞게 Streams에 기록 - Log는 즉각 암호화가 일어나며 24시간동안 보관됨 - 주로 이벤트를 기록하고 이벤트 발생을 외부로 알리는 용도 (예시 : Lambda Function) - 이벤트 전&후에 대한 상황 보관

 

9. AWS - API Gateway

- API (Application Programming Interface)

RESTful API

- API 종류들 중 하나 - REpresentational Sate Transfer - CREATE(post), READ(get), UPDATE(put), DELETE(delete) - JSON 형태로 요청을 받고 해결함 - ex) { "customer_id" : "phm_01", "category" : "car" }

 

- API Gateway

설명

- 뛰어난 확장성 제공 및 API를 만들고 운영하고 모니터링 가능 - Back-end 서비스 (웹 어플리케이션, EC2)에 들어있는 데이터 접근 허용 - Pay As You Go (API 사용, API 시간 및 데이터량에 따라 요금부과)

 

10. AWS - Code Commit & Code Deploy & Code Pipeline

- CI / CD

CI :Continuous Integration(지속적인 통합)	CD : Continuous Deployment(지속적인 배포)
- 자동화 시스템(Automation) - 테스트 - Incremental Change

 

- Code Commit

설명

- 파일들을 보관하는 저장 장소(Repository) - Github과 매우 유사     ㆍ코드, 사진, 라이브러리, 등등 - 동시에 많은 사람들이 저장 장소 접근 및 업데이트 가능 - 버전 컨트롤 기능 제공     ㆍ예) 언제 어떻게 누가 저장 장소 내용을 변경하였는지

 

- Code Deploy : 자동 배포 (Automated Deployment)

장점
- 새로운 기능들의 빠른 배포 - 소프트웨어 & 서버 다운 타임 X - Manual 에러 X
Rolling 배포	Blue/Green 배포
- 서버 하나씩 순차적으로 적용시키는 배포	- Blue : 기존 버전 - Green : 새로운 버전 - 점차적으로 Blue에서 Green으로 트래픽을 옮겨준다. - 이전 버전으로의 스위치가 쉽다. - 두 환경을 만드는 만큼 비용이 들지만, 배포가 복잡해질수록 장점이 크다.

 

- Code Pipeline

Code Pipeline이 하는 일은?	Code Pipeline 작동 방법
- 빌드, 테스트, 배포 과정을 관리     ㆍ코드 변경시 Code Pipeline은 이를 감지할 수 있음 - 소프트웨어 및 어플리케이션 출시 자동화 가능     ㆍ빠르고 쉬운 디버깅을 가능케 해줌	1. Workflow 정의 (Code Pipeline) 2. 코드 저장소에서 코드 변경 (Code Commit) 3. 컴파일, 테스트, 패키지 생성 (Code Build) 4. staging 혹은 production 배포 (Code Deploy)