1. Lambda
-인프라 걱정 없이 애플리케이션 코드를 실행할 수 있는 데이터 처리 서비스
-클라이언트로부터의 액세스에 대해서 데이터를 등록하는 단순한 처리를 EC2 인스턴스에 실행시키고 있으면 Lambda로 대체하여 서버리스로 실행 처리하는 것이 가능
-특징:
실행 기반은 모두 AWS가 관리
AWS 서비스와 연계하여 간단하게 이벤트 기반 애플리케이션 구현 가능
Node.js/Java로 쓰인 코드 실행가능
100밀리초 단위로 코드 실행 시간을 기준으로 과금
오토스케일
-사용례:
이미지의 업로드를 트리거로 하여
어플리케이션 내의 실행 처리를 트리거로 하여
웹 사이트를 클릭을 트리거로 하여
접속 장치에서 출력이 발생하는 것을 트리거로 하여
-Lambda는 Push 모델과 Pull 모델에 의해 실행됨
-Push 모델:
S3/Cognito/SNS등 AWS 서비스와 커스텀 이벤트가 직접 실행함으로써 기동하는 Lambda 함수
서비스 혹은 앱이 직접 실행함/순서 상관안함/3회까지 Re-try
-Pull 모델:
DynamoDB와 Kinesis 등의 데이터 처리는 Lambda에 대해 직접적으로 이벤트 발행을 하지 않기 때문에 Lambda가 그것들에 폴링을 하여 스스로 이벤트를 취득한다
스트림에 들어온 순서대로 처리된다.
이벤트 소스로서 등록한 스트림에 대해서 Lambda가 자동적으로 데이터 취득등의 함수를 실행한다.
이벤트별로 복수 레코드 취득 가능
데이터가 기한이 만료될 때까지 Re-try
2. Lambda처리 타이밍
-다른 AWS 서비스나 SDK를 이용한 모바일 또는 웹 앱에서 호출 가능
-비동기적: 리퀘스트가 정상적으로 접수되었다는 리스폰스 내용이 되돌아오다
-동기적: 실행 완료 시 Lambda 함수 내에서 세팅한 리스폰스가 돌아온다.
-스케쥴기능: 특정시각을 트리거로 하여 Lambda 함수를 실시할 수 있다.
3. Lambda의 권한
-Lambda기능 생성 시 Lambda측에서 자동으로 생성하거나 크로스 어카운트 액세스도 설정 가능
-Execution: Lambda 함수 AWS 리소스에 어떤 액션을 실시하게 할지를 결정한다. 지정된 IAM 역할에 따라 AWS리소스에 접근이 허가됨
-Invocation: Lambda 함수을 어떤 리소스가 실행할 수 있는지를 결정함
4. 버져닝
-버저닝 기능으로 기능 일시점을 기록 관리하는 것이 가능
-에일리어스(특정 버전에 대한 포인터)를 설정하여 특정 시점에 표시할 수 있음
-에일리어스를 작성하여 버전 번호를 파악하지 않고도 지정 버전을 호출할 수 있음
5. Lambda엣지
-CloudFront와 Lambda를 통합
-엣지 로케이션에서 코드를 실행할 수 있음
-이벤트에 연동되어 Lambda 함수가 엣지로케이션에서 실행되고 실행 결과를 보내옴.
6. API Gateway
-API(Application programming interface)는 시스템과 시스템을 연결하는 기능
-최대 수십만개의 API를 동시에 호출할수 있음
-액세스제어 관리
-DDoS공격방어등올 백엔드 보호
-EC2/Lambda/임의의 웹 어플의 워크로드 처리를 담당
-사용례:
API Gateway를 연계고리로 하여 외부 앱과의 연계를 실현할때
EC2 중심의 웹 애플리케이션 구축을 서버리스화 하고 싶을때
7. SQS
-큐를 모아놨다가 폴링처리를 실행하는 서비스
-기본적으로 256K까지의 가벼운 데이터만 이용할수 있고, 60초에서 14일간만 메시지를 저장할 수 있다
-Request큐와 Response큐를 사용해 송수신 큐잉을 구현
-여러개의 서버, 데이터센터에 큐를 저장하는 고가용성 서비스
-여러 사용자가 쓸수 있는 유연함
-메세징이 증가해도 높은 스루풋을 유지함
-고비용효율
-큐의 종류
표준큐:순서대로 처리하는 것과 1번은 반드시 처리하는 것을 되도록 한번은 실시함.
FIFO:큐에 들어온 순서대로 처리
8. SQS의 특성
-메세지 사이즈: 최대 메시지 사이즈는 256KB. Extended Client Library를 이용하면 2GB까지의 메시지 송수신 가능
-메세지 보존기간: 삭제되지 않은 메시지는 기본값으로 4일간 보존. 유지 기간은 60초에서 14일 사이에 변경 가능
-In Flight메세지: 큐당 최대 120,000 In Flight (받은 메시지 & Visibility Timeout내) 메시지
9. SQS의 추가기능
-Short Poling:큐가 빈 경우에도 즉시 리턴
-Long Poling:큐가 비어 있을 경우에는 타임아웃까지 기다림
-데드 레터 큐:계속 남은 메시지를 별도 큐로 이동하여 정상적으로 처리하지 못한 메시지를 격리가능
-Visibility timeout:새 메시지를 지정된 시간 동안 보이지 않게 함. Visibility timeout을 설정함으로써 우선적으로 처리하고 싶은 수신 인스턴스를 지정할 수 있음.
10. Amazon Simple Email Service(SES)
-풀 관리형/서버리스형 비용효율이 뛰어난 이메일 서비스
-확장 가능한 구성으로 신뢰성이 높음
-메일발송 : 트랜잭션 메일 등 고품질 콘텐츠 고객 발송 가능
-메일 수신 : 수신된 메일을 트리거로 S3나 Lambda 등 실행 가능
-바운스 처리 : 메일을 보낼 수 없는 경우의 처리 규정
11. SES의 메일송신방법
-HTTP REST API:
SendEmail API: From/To/Subject/Body만 있으면 SES측에서 메시지를 생성하고 송신할 수 있음
SendRawEmail API:메시지 전체를 애플리케이션 측에서 생성하고 송신함
인증:AWS액세스 키와 비밀 엑세스 키를 사용
-SMTP엔드 포인트:
생성된 Email 메시지를 받아 SES의 SMTP 엔드포인트를 경유하여 메일을 송신함. SMTP를 전제로 프로그램에서 직접 이용하는 경우 등에 이용할수 있음.
TLS ( Transport Layer Security ) 필요
인증: 전용 IAM유저를 생성하여 해당 자격 인증서 사용
12. 서버리스
-디커플링:컴포넌트간의 상호의존을 줄인 구성으로 각각의 컴포넌트 변경이나 장애의 영향을 줄인다.
-서버리스 설계에 의해 디커플링 설계가 가속화되고, 마이크로서비스화된 애플리케이션을 구축할 수 있다
-옛날부터 있던 SOA 방식에서 보다 작은 프로세스 단위의 서비스를 API로 연계한 마이크로 서비스로 설계할수 있음
-SOA 방식:
한 가지 기능을 갖춘 큰 서비스 단위로 컴포넌트를 분할하는 설계 방식
애플리케이션을 컴포넌트화하여 통신 프로토콜을 통한 연계로 다른 컴포넌트에 서비스를 제공하는 아키텍처 설계
-마이크로 서비스:
SOA보다 더 작은 기능 단위의 프로세스로 서비스화한 구성
각 프로세스에서는 1개의 작은 태스크를 서비스로 제공하고 프로세스 간 통신은 API를 이용한다.
13. 디커플링 관련 서비스
-ELB:서버간 트래픽 조절과 연계를 ELB기점으로 하여 디커플링 실현
-SQS:큐잉을 이용한 통신으로 인스턴트간 연계
-SNS:어플리케이션간 통신으로 인스턴트간 연계를 실현
-Lambda:인스턴트가 아닌 람다에 의한 트리거 처리로 연계
14. 디커플링 설계 주의사항
-유저인증은 IAM등으로
-되도록 Lambda를 이용한 어플리케이션의 구현
-어플리케이션간의 연계는 SQS등으로
-동적 웹시스템은 VPC밖에 있는 S3에 보존
#제 돈 주고산 유료강의를 듣고 정리한 요약노트입니다. #AWS비슷비슷한 서비스, 기능들 위주로 요약했습니다. #일본거주자라 일본어강의여서 가끔 단어가 이상할 수 있습니다. |
'AWS SAA-C02' 카테고리의 다른 글
AWS SAA-C02개념정리::보안/운용 (0) | 2021.06.18 |
---|---|
AWS SAA-C02개념정리::자동화 (0) | 2021.06.18 |
AWS SAA-C02개념정리::캐싱(ElastiCache,CloudFront) (0) | 2021.06.17 |
AWS SAA-C02개념정리::대량 데이터 처리(Kinesis,Redshift등) (0) | 2021.06.17 |
AWS SAA-C02개념정리::EFS(Elastic File System) (0) | 2021.06.17 |
댓글