IAM
루트 사용자로서, 일반 사용자들이 여러 AWS 서비스에 접근하는 권한과 범위, 역할 등을 지정&관리할 수 있음
EC2
지불방식
on-demand : 할인율이 적음. 시간 단위로 가격 측정. 즉 단기간 사용할 때 유용함. 특히 개발 초기에 deploy할 때 유용함
reserved : 한정된 용량 사용 가능, 1~3년동안 시간별 할인 적용 받을 수 있음 (개발의 시작과 끝을 미리 알 수 있을 때, 안정적이고 예상 가능한 workload시 유용함). 선불로 지불하면 컴퓨티 비용 대폭 감소
spot : 할인율이 가장 크다. 경매 방식으로 씀. 낙찰한 가격 이상으로 올라가면 끊기는거임. 이로 인해 인스턴스의 시작과 끝이 불규칙적이기에, 시작과 끝기간이 중요하지 않을 때 매우 유용함
EC2 실습
putty
ssh를 활용하여 다른 서버에 접속할 수 있게 해주는 오픈소스 터미널 애플리케이션
putty : ssh를 활용하여 원격 접속
puttygen : EC2 인스턴스를 만들 때 주어지는 pem 파일을 ppk 파일로 변환해줌 (putty는 ppk 파일만 인식하므로 변환 필요)
ElastiCache
- Memcached
- Object 캐시 시스템으로 저명함
- AWS의 ElastiCache는 맴캐시드가 디폴트임
- EC2마냥 캐시 크기를 Auto Scailing 함
- 오픈소스라 공짜임
| 유스케이스
- 가장 단순한 캐싱 모델이 필요할 때
- list, set처럼 advanced data type이 아닌, object를 caching하는게 주 목적일 때
- 캐시 크기를 마음대로 scailing하길 원할 때
- Redis
- Key-Value, Set, List와 같은 형태의 데이터를 In-memory에 저장 가능
- 오픈 소스
- multi-AZ를 지원함
- 비관계형 DBMS임 (NoSQL)
| 유스케이스
- List, Set과 같은 데이터셋을 사용할 때
- 리더보드처럼 데이터셋의 랭킹을 정렬하는 작업이 필요할 때
- Multi AZ 기능이 필요할 때
RDS
EC2에 phpmysqlnd 설치 후 RDS에 접근.
보안 인바운드 규칙도 적절히 설정해둬야함 (ssh랑 http 등)
S3
구글 클라우드 느낌의 클라우드 스토리지. 디렉토리같은거를 버켓이라고 명칭함
암호화, 공개 범위 등을 적용 가능 (버킷 정책, 암호화 설정 활용)
CloudWatch
실시간 모니터링, 각종 이벤트들 로그 남겨 줌
EC2, RDS, ELB, S3 등 꽤 많은 AWS 다른 서비스들에 활용이 지원됨
종류
- basic monitoring : 무료, 5분 간격 최소한의 metrics 제공
- Detailed Monitoring : 유료, 1분 간격으로 자세한 metrics 제공
사용 용례
-
1번 용례 케이스
use case : 매일 얼마나 많은 사용자들이 모바일 앱을 사용하는지 알고 싶음
potential issue : 특정 날에 수많은 traffic이 몰릴 수 있어 병목 현상이 생길 수 있음
solution : 매일 traffic rate와 특정 버튼의 유저 클릭 횟수를 분석하여, 더 효율적인 앱 개발을 할 수 있는 통찰력을 얻을 수 있음 -
2번 용례 케이스
use case : 특정 시간대에 웹 서버 상태를 점검하여 비용 절감 목표
potential issue : 똑같은 비용을 내며 AWS 리소스들을 사용하지만, 낮 시간대와 밤 시간대에 필요한 서버의 성능은 달라질 수 있기 때문에, 금전적 손실이 생길 수 있음 (주로 밤 시간대에 서버가 오랫동안 idle).
solution : 알람 설정을 통하여 특정 threshold에 도달했을 때, 개발자에게 상황을 보고해줌으로써 서버 management를 할 수 있음.
Alarm
-
Alarm State
Alarm : 특정 threshold에 도달해서 알람이 울리는 상태
Insufficient : 알람 설정은 돼있는데 대상 EC2가 없다거나 그럴 때 이 상태로 진입함
OK : 특정 threshold에 도달하지 않은, 아직 안정된 상태 -
Billing Alarm
지정해놓은 알람 서비스 지출값 초과하면 SNS로 개발자에게 알려줌 (이 기능은 N.virginia(us-east-1) 지역에서만 지원됨)
Lambda
-
serverless의 주축을 담당하는 AWS 서비스 중 하나
serverless : 클라우드가 서버를 돌리고 생성하고 리소스들을 서버 사용량에 따라 직접 할당해줌. 즉 사람이 직접 관여하는 부분이 적어지고 문제점도 덜 발생
-
event를 통하여 lambda를 실행시킴
-
NodeJS, Python, Java, GO 등 다양한 언어 지원
-
Lambda Function
람다 함수 호출 후 다른 서비스를 호출할 수 있음. 그래서 AWS 아키텍처에서 중간 중간에 들어가있는 경우가 많음
비용
-
람다 함수가 실행될때만 비용 지불
-
매달 백만 번 함수 호출까지는 무료 (그 후로는 유료)
기타
-
최대 300초 런타임 시간 허용
-
512MB의 일시적인 디스크 공간 제공 (/tmp/)
-
최대 50MB Deployment Package 허용 (로컬에서 코딩한 내용을 압축 후 람다에 deploy)
-> 50MB가 초과되면 S3 버켓에 담고 람다와 연결 가능
유스케이스
-
S3에 putObject -> lambda 에서 데이터 변환, 불필요한 데이터 삭제 -> 최종적으로 DB에 올라감
lambda는 중간다리같은 역할을 함
-
IoT에서 Topic으로 이벤트 감지하고 lambda 호출(자동차 과속 이벤트 감지 시 속도 데이터 보냄) -> lambda에서, 운전자가 미국인이면 km를 다른 유닛으로 형변환 해줌 -> SNS로 사용자에게 실시간으로 경보를 줌
이들을 매우 간단한 serverless architecture로 보면 됨.
CloudFront
-
edge location을 사용하여 정적, 동적, 실시간 웹사이트 컨텐츠를 유저에게 전달
-
컨텐츠 딜리버리 네트워크 (CDN)
-
분산 네트워크 (DN)
edge location
전 세계에 설치되어 있는 서버의 collection 개념. 길거리에 ATM 기기같은 느낌. 이걸로 유저와 서버의 거리에 따른 latency 해소
서버에서 컨텐츠를 edge location 캐시에 넣고, 이 캐시에서 유저에게 컨텐츠 제공
origin
원래 컨텐츠들이 들어있는 곳. 웹 서버 호스팅이 되어지는 곳. S3, EC2 인스턴스가 오리진이 될 수 있음
Distribution
CDN에서 사용되어지며, edge location들을 하나로 묶어 통칭하는 개념
DynamoDB
특징
- NoSQL(Not Only SQL) 데이터베이스
- 매우 빠른 쿼리 속도
- Auto-Scaling 기능 탑재 (테이블 크기 오토 스케일링 -> 비용적 이점)
- key-Value 데이터 모델 지원
- 테이블 생성 시 스키마 생성 필요 없음 (알아서 스키마 생성해줌, 실시간으로 데이터가 들어오는 경우 매우 유용)
- 모바일, 웹, IoT 데이터 사용시 추천됨
- SSD 스토리지 사용
구조
- 테이블
- 아이템 (행과 개념 비슷)
- 특징 (Attributes, 열과 개념 비슷)
- Key-Value (Key : 데이터의 이름, Value : 데이터 자신)
- 예시) JSON, XML
Primary Keys (PK)
-
PK를 사용하여 데이터 쿼리
-
DynamoDB에는 두 가지의 PK 유형이 있음
-
파티션 키 (Partition Key)
- 고유 특징 (Unique Attribute)
- 실제 데이터가 들어가는 위치를 결정해줌 (해시 함수)
- 파티션 키 사용 시 동일한 두 개의 데이터가 같은 위치에 저장될 수 없음!
-
복합 키 (Composite Key)
- 파티션 키 + 정렬 키
- 예시 : 똑같은 고객이 다른 날짜에 다른 물건을 구매
- 파티션 키 : 고객 아이디, 정렬 키 : 날짜 (Timestamp)
- 같은 파티션 키의 데이터들은 같은 장소에 보관, 그 다음 정렬 키에 의해 데이터가 정렬됨
-
데이터 접근 관리
- AWS IAM으로 관리할 수 있음
- 테이블 생성과 접근 권한을 부여할 수 있음
- 특정 테이블만, 특정 데이터만 접근 가능케 해주는 특별한 IAM 역할 존재
Index
- 특정 컬럼만을 사용하여 쿼리
- 테이블 전체가 아닌 기준점(pivot)을 사용해 쿼리가 이루어짐
- 매우 큰 쿼리 성능 효과
- 두 가지의 Index 유형 존재
- Local Secondary Index
- Global Secondary Index
Local Secondary Index (LSI)
- 테이블 생성 시에만 정의해줄 수 있음
- 따라서 테이블 생성 후 변경, 삭제가 불가능
- 똑같은 파티션키 사용, 그러나 다른 정렬키 사용
Global Secondary Index (GSI)
- 테이블 생성 후에도 추가, 변경, 삭제 가능
- 다른 파티션키, 정렬키 사용
- 새로운 뷰를 생성 (테이블의 데이터가 조작되면 뷰에도 자동 업뎃됨)
Query vs Scan
query가 scan보다 훨씬 효율적임. query 사용 추천
Query
- Primary Key를 사용하여 데이터 검색
- Query 사용 시 아이템의 모든 컬럼 반환
- 정렬키 활용하여 아이템 필터링 더 가능
- ProjectionExpression 파라미터를 사용하면 골라내어진 아이템 중에 보고 싶은 컬럼만 선별하여 조회도 가능하긴 함
Scan
- 모든 데이터를 불러옴. (primary key 사용 X) 이 후에 필터링 따로 적용 가능
- ProjectionExpression 파라미터 (원하는 컬럼만 보기)
- 테이블 크기가 작고 primary key가 딱히 필요 없는 lookup용 테이블인 경우 scan 활용할만함
DAX (DynamoDB Accelerator)
- 클러스터 In-memory 캐시임.
- 10배 이상의 속도 향상
- 읽기 요청만 해당사항 (쓰기 요청은 예외). 즉 읽기 요청이 매우 많거나 크기가 클 때 유용함
- Ex) Black Friday날 쇼핑 웹사이트 운영 (수많은 읽기 요청 예상)
원리
- DAX 캐싱 시스템 : 테이블에 데이터 삽입 & 업데이트 시 DAX에도 반영
- 읽기 요청에 맞는 데이터가 DAX에 들어있다면, DAX에서 데이터 즉시 반환 (Cache Hit. 반대 용어는 Cache Miss)
단점
- 쓰기 요청이 많은 어플리케이션에서는 부적절함
- 읽기 요청이 많지 않은 어플리케이션에서 부적절함
- 아직 모든 지역에서 제공하지 않음
DynamoDB Stream
- DynamoDB 테이블에서 일어나는 일들(삽입, 수정, 삭제 등)이 일어날 시 시간적 순서에 맞게 Streams에 기록
- Log는 즉각 암호화가 일어나며 24시간동안 보관됨
- 주로 이벤트를 기록하고 이벤트 발생을 외부로 알리는 용도 (예시 : Lambda Function)
- 이번트 전&후에 대한 상황 보관
API Gateway
API
Application Programming Interface
유저의 리퀘스트 -> API -> 서버에서 요청받은 데이터 싣기 -> API -> 유저에게 제공
RESTful API
representational state transfer
-
상태 변화를 위한 클라이언트의 요청
-
CREATE(post), READ(get), UPDATE(put), DELETE(delete)
-
JSON 형태로 요청을 받고 해결함
API Gateway
<배경>
-
대부분의 어플리케이션은 RESTful API 기반으로 운용됨
-
매우 힘든 RESTful API 관리
- Authentication(특정 혜택에 대한 API 요청 권한 관리) & Authorization(로그인해야만 API 요청 가능 등)
- API 요청을 모니터링 해야함 (유저가 재고가 5개인 제품을 10개를 넣으려할 때 등)
- 더 나은 성능을 위해 API 요청 캐시 시스템 필요
<정의>
- 뛰어난 확장성 제공 및 API를 만들고 운영하고 모니터링 가능
- Back-end 서비스(웹 어플리케이션, EC2)에 들어있는 데이터 접근 허용
- Pay As You Go (API 요청 사용량, 데이터 처리량, 처리 시간에 따라 비용 책정 및 지불함. 따라서 비용적 측면에서 이점이 있음)
CI / CD
Continuous Integration / Continuous Deployment
장점
- 사용자들의 앱 사용에 악영향을 주지 않으면서 버그 패치 적용
- 자동화 시스템 (Automation) - 테스트
- Incremental Change (특정 기능을 버그 픽스&구현하기 위해, 단계적으로 코드 구현과 테스트 반복)
github에 중앙 레포에 올리면서, CI/CD 도입해서 테스팅 자동화도 가능(메인 브랜치에 병합 전 테스팅), 테스팅 후 배포 준비 (코드 병합 패키지 생성 등도 CI/CD로 자동화). 물론 소비자 컴플레인 들어와서 특정 기능을 고치거나 롤백시키는 등 사람이 개입해서 해야할 때도 있긴 함
AWS : Code Commit
-
파일들을 보관하는 저장 장소 (Repository) - Github과 매우 유사
- 코드, 사진, 라이브러리 등
-
많은 사람들이 동시에 저장 장소 접근 및 업데이트 가능
-
버전 컨트롤 기능 제공
- 예) 언제 어떻게 누가 저장 장소 내용을 변경하였는지
-
code commit에는 main branch와 더불어 develop branch가 있는데 보통 여기서 충돌 해결 및 코드 확정짓고나서 메인 브랜치에 업뎃함
AWS : Code Deploy
장점
- 새로운 기능들의 빠른 배포
- 소프트웨어 & 서버 다운타임이 없음
- Manual 에러가 없음 (자동으로 해주기 때문)
방식
-
Rolling 배포
프로덕션의 모든 기능을 100퍼로 잡았을 때, 개발자가 25퍼 정도를 기능 개선해서 이걸 배포하고, 다음 배포 때 또 다른 25퍼 비중의 기능을 구현 후 배포하고 이런 식으로 점진적인 느낌
ex) ELB가 3개의 서버 인스턴스를 관리하고 있다고 치고, 첫 번째 인스턴스를 비활성화 후, 업그레이드가 되고나면 다음 버전 인스턴스를 다시 활성화시켜 ELB에 연결. 이런 식으로 하나하나 다 해서 결과적으로는 모두 버전2의 인스턴스로 업글된 상태
만약 버전2 업글 후 버그 발생하면, 롤링 배포 방식에서는 한번에 버전1로 돌아가기는 힘듦. 똑같은 방식으로 버전0으로 교체해줘야함. blue/green 배포에서는 한번에 돌아가기 가능
-
Blue/Green 배포 (blue : 현재 가동중인 프로덕션, Green : 새로 배포할 것)
blue의 트래픽을 천천히 줄이면서 green으로 옮기면서, 개발자는 green에 새로운 기능을 추가함. 궁극적으로는 blue를 완전히 셧다운시키고 green으로 완전히 옮기는 것
ex) ELB가 인스턴스 v0 3개를 관리하고 있고, 여기서 기능이 추가된 v1 인스턴스 3개를 생성 후 ELB에 연결함. 이제 트래픽 양을 v0 3개(blue)로 가는 트래픽을 조금씩 줄이고, v1 3개(green)로 가는 트래픽을 조금씩 늘려서, 궁극적으로는 blue에 트래픽이 아예 안가고, green에만 가게 되도록 함.
이전 버전으로 돌리고 싶다면, ELB 셋팅만 똑같은 방식으로 다시 blue쪽으로 트래픽을 옮기면 됨. (물론 이전 버전 인스턴스를 삭제하지 않았다는 가정 하에)
맨 처음 배포할 때는 rolling 배포로 빠르게 배포하고, 그 뒤에는 blue/green 배포 방식 사용하면 됨. (참고로 blue/green 배포는 추가 비용 발생)
AWS : Code Pipeline
CI/CD의 끝판왕!
앞서 배운 code commit, code deploy를 자동화해줌
하는 일
-
빌드, 테스트, 배포 과정을 관리
- 코드 변경 시 Code Pipeline은 이를 감지할 수 있음
-
소프트웨어 및 어플리케이션 출시 자동화 가능
- 빠르고 쉬운 디버깅을 가능케 해줌
배포 vs 출시
배포와 출시를 동일시하는 회사도 있음
배포는 모든 기능이 적용된, 최종본
그리고 이를 출시하면 사용자가 사용 가능
작동 방법
-
workflow 정의 (code pipeline)
-
코드 저장소에서 코드 변경 (code commit)
-
컴파일, 테스트, 패키지 생성 (code build)
-
staging 혹은 production 배포 (code deploy)
