1. 관리의 문제:EC2를 직접 관리해 줘야 해서 부담이 있음
2. 확장의 유연성: 운영 중인 서비스에서 갑자기 트래픽이 몰리면 서비스 정상화에 상당한 시간이 걸림
3. 요금에 대한 문제: 인프라 관리가 효율적이지만, 과금이 많이 듬
서버리스(Serverless)
BaaS (Backend as a Service) : Firebase(구글에 인수됨) …
AND
FaaS (Function as a Service) : AWS Lambda, Azure Functions, Google Cloud Functions …
비용 : 필요할 때만 함수를 호출하고, 그만큼만 비용이 드므로 절약된다.
인프라 관리 : 인프라 구성 및 보안 등 신경써야 할 것이 줄어든다.
확장성 : 확장을 위해 AWS Auto Scaling같은 기술도 필요 없다. 그냥 많이 쓰면 확장…
자원의 제한 : 메모리와 처리 시간에 한계가 있다.
로컬 데이터 사용 불가능 : 함수들은 stateless하므로 로컬 데이터를 사용할 수 없다.
불편함 : 디버깅이나 테스팅에 불편함이 있다.
Lambda는 S3처럼 백엔드를 서버리스(Serverless)로 운영할 수 있는 서비스.
S3가 별도의 서버, 관리 없이도 프론트 페이지를 운영할 수 있는 것처럼,
백엔드도 인프라를 신경쓰지 않고 운영할 수 있는 서비스.
S3와 Lambda의 역할은 비슷함.
- 비용절감 - 필요할때만 함수가 호출되고 비용이 부과되는 방식.
- 인프라 관리 부담의 효율 - 관리를 할 필요가 없다.
- 효율 - 특정 기간 또는 특정 주기로 코드를 실행시킬 수 있음
서버 띄우지 않고 간단한 코드를 실행시킬 수 있음
- 리소스 제한 - 메모리(최대 10GB), 처리시간(최대 900초, 15분)
- ColdStart - 오랜만에 실행하게 되면 딜레이가 발생한다.
- 동시성 제약 - 동시에 처리할 수 있는 요청의 수가 리전별로 1000개로 제한되어 있다.
- 지연시간 - 처음 함수 호출시 Cold Start를 하게되고 초기 지연시간이 발생한다.
가상 네트워크로 AWS 리소스를 관리할 수 있게 하는 것
원래라면 서버를 만들고 네트워크에 서버를 연결하고, 데이터베이스를 구축하고 데이터베이스랑 서버를 연결하고 아주 복잡한 작업을 해야하지만 AWS의 VPC는 이런 복잡한 작업들을 미리 다 해두고 네트워크 전문가를 부를 필요없이 우리같은 서버 개발자들이 손쉽게 필요한 네트워크를 전부 가져다 쓸 수 있게 만들어 놨다
내부의 네트워크를 만드는 것 이걸 통해서 안전하게 데이터베이스를 묶거나 할 때 사용함
AWS의 네트워크 서비스
HTTP 통신을 할 수 있게 HTTP URL, METHOD(GET, POST..)를 만들어주어 API 엔드 포인트 역할을 해줌
URL 이나 어떤 메소드로 오는지 보고 연결시켜줌
특정한 api url 이오면 함수를 실행시켜줌
1. HTTP URL(Uniform Resource Identifier)을 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
2. 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URL를 부여한다.
Create : 생성(POST)
Read : 조회(GET)
UPdate : 수정(PUT)
Delete : 삭제(DELETE)
HEAD : header 정보 조회(HEAD)
COLIN'S BLOG(서버리스 아키텍처란?)
HANAMON (REST API)
[AWS] 10. AWS_VPC 개념