kaonmir
시리즈
SAA
DOP
System Design Interview
Linux
ETC
Share
Sign In
Home
Kaonmir (손성훈)
Copy & Translate
시리즈
SAA
후기
시험 소개 & 꿀팁
Terminology
Region & Availability Zone
Budget
IAM
EC2 - Fundamentals
EC2 - SAA Level
EC2 Storage
ELB & ASG
RDS / Aurora / ElastiCache
S3
CloudFront & Global Accelerator
Route 53
Storage Extras
Decoupling
Container
Serverless
Database
Monitoring, Troubleshooting & Audit
IAM Advanced
Security & Encryption
VPC
Disaster Recovery & Migrations
Ohter Services
기술 백서 총 모음
기술 백서(White paper)
DOP
CodeCommit, CodeBuild, CodeDeploy
CodePipeline, CodeStar, Jenkins
CloudFormation - Fundamentals
CloudFormation - DOP Level
Elastic Beanstalk
Lambda & Step Function & API Gateway
ECS & ECR & OpsWorks
Kinesis
CloudWatch
CloudTrail & X-Ray & ElasticSearch & Tagging
SSM & Config & Service Catalog & Inspector
Other Services
Auto Scaling Group (ASG)
DynamoDB & S3
Multi AZ & Multi Region & Multi Account
AWS Organizations & On-Premise Strategy
Disaster Recovery (DR)
서비스별 기본 배포 전략 비교
CodeDeploy appspec hook
System Design Interview
사용자 수에 따른 규모 확장성
개략적인 규모 추정
시스템 설계 면접 공략법
처리율 제한 장치
안정 해시
키-값 저장소
분산 시스템을 위한 유일 ID 생성기
URL 단축기
웹 크롤러
알림 시스템
뉴스 피드 시스템
채팅 시스템
검색어 자동완성 시스템
유튜브
구글 드라이브
Linux
ETC
AI를 더 잘 쓰기 위한 IT 용어
Serverless
우리는 더이상 서버를 관리할 필요가 없습니다. 알아서 늘어났다 줄었다 합니다.
서버리스(serverless)란?
서버리스(serverless)란 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델입니다.
redhat.com
1. AWS Lambda
EC2를 생각해 보자
클라우드에 있는 가상 서버이고
RAM/CPU에 제약이 있으며
정지/종료하기 전까지 계속 돌아간다. (비용 발생)
확장은 EC2의 개수를 조절하는 것이다.
Lambda는
가상 함수이다.
최대 15분까지 실행할 수 있다.
안쓰면 함수가 돌지 않고 비용이 없다.
알아서 자동으로 확장한다.
장점
요청의 수와 연산 시간만큼 내기 때문에 계산이 쉽다. 그리고 꽤 싸다.
모든 AWS 서비스, 많은 프로그래밍 언어와 연동이 가능하다.
CloudWatch를 쓰면 쉽게 모니터링할 수 있다.
함수당 최대 10GB의 램까지 쉽게 확장할 수 있다. (수동)
램이 증가하면, 자동으로 CPU와 네트워크도 좋아진다.
람다 컨테이너 이미지
Lambda Runtime API로 구현된 컨테이너 이미지를 말한다.
람다에서는 함수처럼 돌아가고, ECS와 Fargate에서는 도커 이미지처럼 돌아간다.
한계(실행)
램 - 128MB ~ 10GB
실행시간 - 최대 15분
환경 변수 - 최대 4KB
임시 파일 - 최대 512MB
병렬 실행 - 기본 1000
한계(배포)
배포 용량(압축) - 최대 50MB
배포 + 코드 용량(비압축) - 최대 250MB
시작할 때 /tmp 경로에서 파일 읽을 수 있음
환경 변수 - 최대 4KB
Lambda@Edge
람다 함수를 CloudFront CDN 서비스에 올리고,
요청을 필터링
할 수 있게 도와주는 서비스.
CloudFront는 유저의 요청(Viwer Request)를 오리진에게 전달(Origin Request)하는 역할을 한다.
또한, 오리진을 거치지 않고 바로 응답할 수도 있다.
2. Dynamo DB
완전 관리되고, 복제를 통해 높은 가용성을 보장하는 NoSQL 데이터베이스
Multi AZ이며 서버리스이기 때문에 가용성이 높다.
DynamoDB Stream을 통해
이벤트 주도 개발
이 가능하다
자동 확장하며 IAM과 연동이 가능하다.
기초
Item
=
Row = Record = 행 = 가로줄
DynamoDB는 Primary Key를 가진 테이블을 제공한다.
각 테이블은 무한히 많은 Item(row)을 추가할 수 있고, 속성(column)을 계속 바꿀 수 있다.
Item의 최대 크기는 400KB이다.
Scalar Types, Document Types(List, Map), Set Types를 지원한다.
읽기/쓰기 용량 모드
프로비전 모드 (기본)
- 초당 읽고 쓰는 속도를
지정
하고 매월 지정한만큼 낸다. Auto-Scaling 모드를 추가해 수도 있다.
RCU
(읽기 용량 유닛) - 4KB 요청을 초당 1회 처리
WCU
(쓰기 용량 유닛) - 1KB 요청을 초당 1회 처리. 트랜젝션 요청은 2배가 필요
온디맨드 모드
- 알아서 확장하고 청구한다. 좀 더 유연하고 비싸다.
DynamoDB Accelerator (DAX)
다이나모 DB를 위한 완전 관리, 높은 가용성을 가진 인메모리 캐시이다.
읽기 혼잡(Read Congestion)을 줄이는 걸 돕는다. 어플리케이션의 논리 구조를 바꿀 필요 없으며 기본 5분동안 캐싱이 유지 된다.
DynamoDB Streams
아이템이 수정(Create/Update/Delete)되었을 때, 시간 흐름에 따라 로그를 최대 24시간 동안 저장한다.
이 스트림은 Kinesis Data Streams로 보낼 수 있고, Lambda와 Kinesis Clinet Library applications에 의해 읽힐 수 있다.
DynamoDB Global Table
여러 리전에 테이블 복제를 두고 변경이 발생할 때마다 갱신한다. 어플리케이션은 적은 레이턴시로 아무 테이블이나 접근해 읽고 쓸 수 있다. DynamoDB Streams를 먼저 활성화해야 한다.
DynamoDB - Time to Live (TTL)
우리는 각 아이템마다 TTL을 설정할 수 있다. TTL이 지나면 아이템은 곧 지워질 것이라고 마킹되고, 조금 있다 지워진다.
DynamoDB - Indexes
Global Secondary Indexes (GSI)와 Local Secondary Indexes (LSI)가 있다.
이 둘의 차이는 AWS SAA 수준에서는 알 필요가 없다. 어쨌든 Primary Key 말고도 인덱스를 걸어 쿼리할 수 있다는 것만 알자
DynamoDB - Transactions
DynamoDB는 한 트렌젝션으로 여러 테이블을 쿼리할 수 있다. 예를 들어, 한 테이블을 업데이트하면 다른 테이블도 업데이트가 되어야 한다고 하면 두 쿼리를 한 트렌젝션에 담을 수 있다.
3. API Gateway
클라이언트와 REST API로 소통하며, 요청을 서비스에 프록시하는 서버리스 서비스이다.
람다 함수, HTTP, 그리고 다른 AWS 서비스로 요청을 넘겨주는 역할을 한다.
웹소켓 프로토콜을 지원한다.
API 버전(v1, v2, ...)과 스테이지(dev, test, prod)을 만들 수 있다.
인증과 권한 할당을 다룰 수 있다.
Swagger나 OpenAPI에서 정의한 API를 가져올 수 있다.
API 응답을 캐싱할 수 있고, API Key를 만들 수 있다.
Endpoint Types
엣지-최적화(기본)
- API Gateway는 한 리전에 있지만, CloudFront Edge location을 통해 빠르게 전세계로 접근이 가능하다.
리전
- 클라이언트가 무조건 같은 리전에 있으면 좀 더 다양한 캐싱 정책을 써서 요청을 넘긴다.
프라이빗
- 리소스 정책이나 VPC endpoint를 통해 접근을 제어한다.
Security
IAM Permission
IAM을 사용하므로 AWS
내부적
으로만 사용 가능하다. 공짜다
1.
먼저 IAM 정책 권한을 생성해, 유저와 역할에 붙인다.
2.
그러면 유저는 IAM Credential이 담긴
서명 버전 4(Sig v4)
를 헤더에 넣어 API Gateway로 보낸다.
3.
API Gateway는 IAM을 호출해 Sig v4가 타당한지 판단한다.
4.
타당하면 해당 요청을 백엔드로 넘긴다.
Lambda Authorizer (Custom Authorizer)
람다를 호출해서 권한을 확인한다. 호출 수 만큼 비용을 지불한다.
1.
API Gateway에 요청이 들어오면 API Gateway는 Lambda한테 클라이언트가 타당한지 물어본다.
2.
Lambda는 OAuth, SAML이나 서드 파티 인증 절차를 통해 해당 클라이언트를 인증한다.
3.
Lambda는 인증된 유저의 IAM 정책을 API Gateway에게 반환한다.
4.
API Gateway는 그 IAM 정책을 보고 타당한지 판단한다.
Cognito User Pools
Cognito는 완전 관리된 유저 수명주기 서비스이다. API Gateway는 자동으로 AWS Cognito를 통해 유저를 식별하고 인증한다. 단,
인증
(Authentication)하되
권한을 부여
(Authorization)하지는 않는다.
4. AWS Cognito
Cognito User Pool -
API Gateway와 연동되어 유저 로그인 기능을 제공할 수 있다.
Cognito Identity Pools -
AWS 리소스에 직접적으로 접근하고 싶을 때, AWS Credential을 제공한다. Cognito User Pool과 연동해
식별자 제공자
(Identity Provider) 역할을 한다.
Cognito Sync
- 기긱와 Cognito를 동기화한다.
AWS Cognito User Pools (CUP)
간단하게 로그인 정보를 주면 JWT 토큰을 반환하는 서버리스 데이터베이스 서비스이다.
ID/PW, 이메일/휴대폰이나 MFA 인증도 지원하고 Federated Identity (구글, 네이버 로그인)도 지원한다.
API Gateway와 연동할 수 있다.
AWS Cognito Federated Identity Pools (FIP)
클라이언트가 직접적으로 AWS 리소스에 접근할 수 있도록 해주는 서비스이다.
1.
클라이언트는 식별자 제공자 (CUP, 구글, ...)에서 토큰을 받아와 Federated Identity로 넘긴다.
2.
Federated Identity는 식별자 제공자를 통해 토큰이 타당한지 검증한다.
3.
타당하면 Federated Identity는 STS 서비스로부터 AWS credential을 받아온다.
4.
AWS credentials를 클라이언트에게 준다.
5.
그럼 클라이언트는 이제 특정 AWS 리소스에 접근할 수 있다.
Cognito Sync
이제 AWS AppSync를 쓰지만 시험에는 나온다. Cognito Sync는 어플리케이션의 속성, 구성, 상태를 클라우드에 저장해 동기화할 수 있게 해주는 서비스이다.
오프라인에 있다가도 다시 온라인으로 돌아오면 바로 동기화된다.
Federated Identity Pool
이 꼭 필요하다.
최대 1MB의 dataset을 최대 20개까지 동기화할 수 있다.
5. AWS Serverless Application Model (SAM)
서버리스 어플리케이션을 배포하는 프레임워크이다.
람다, DynamoDB, API Gateway, Cognito User Pools를 모두 YAML 코드를 통해 구성하고, CodeDeploy로 배포할 수 있다.
로컬에서 람다, API Gateway와 DynamoDB를 실행시킬 수 있어 디버깅하기 좋다.
Made with SlashPage