*서버리스 아키텍쳐가 나타기까지 배경
1) On-premise 전통적인 방식
네트워크-스토리지-서버-가상화-운영체제-미들웨어-런타임-데이터-앱까지 직접 관리
시스템이 커지면 전산실이나 데이터센터가 커져야됨
- 우리가 할 일 : 전부 관리/구축
그래서 비용이 많이 듦
2) Iaas(Infrastructure as a Service) : 인프라 가상화
시스템에서 필요한 모든 인프라자원까지(네트워크,스토리지,서버)을 가상화한 방식
IaaS서비스로 가상머신 만들고,여기에 하드웨어/네트워크/os설치해서 앱구동
무엇인가(서비스)를 만들기 위해서 필요한 리소스들 제공 -->비유 : 재료
- 클라우드가 해주는 일 : 인프라 리소스 관리
- 우리가 할일 : 인프라는 구축 신경 X, 서비스가 돌아갈 개발/운영 환경관리+서비스개발
대표적으로 Amazon web service의 ec2서비스(서버), S3(스토리지),VPC(네트워크)
서버자원, 네트워크, 보안장비를 직접 구축할 비용을 줄여줌
그래도 비용이 여전히 많이 든다.
3) PasS(Platform as a Service) : 개발환경 가상화
시스템에 필요한 인프라자원 위에 올라 가는 서비스의 개발/운영환경(OS/미들웨어/런타임)까지 가상화한 방식
재료들을 한번에 제공하긴 하지만, 플랫폼처럼 어떻게 사용하는지는 사용자 마음 --> 비유 : 중간가공상품
- 클라우드가 해주는 일 : 인프라 리소스관리 + 앱 실행 및 개발 환경관리
- 우리가 할일 : 서비스 개발+ 환경에 배포
대표적으로 Amazon web service의 RDS,BeanStalk,Codeploy,아미,람다 또는 Docker(도커)
서비스들마다 다른 여러가지 환경에서 서비스를 개발/운영 할 수 있게댐
여기에서 더 간소화해서 Flask,Django,Spring 같은 서버 애플리케이션만 배포하면 서비스가능
그래도 비용이 여전히 많이 든다.
*Iaas VS Paas
Iaas는 서버,네트워크,보안부분을 클라우드 사업자가 다 함. 그래서 구축/운영이 쉬움
Paas는 내부에 들어가는 서버나 미들웨어를 직접 지정하기 어려움
4) SaaS(Software as a Service) : 소프트웨어 가상화
소프트웨어 자체까지 가상화된 서비스로 제공
플랫폼화된걸 넘어서 운영하고 가공하는 방식은 사용자 마음대로 --> 비유 : 완제품
- 클라우드가 해주는 일 : 인프라 리소스관리 + 서비스가 돌아갈 개발/운영 환경관리 + 서비스 배포
- 우리가 할일 : 서비스 개발
대표적으로 Amazon web service의 API Gateway, Cloud9 또는 Ms office 365
어플리케이션의 프로토콜을 규정을 따라서 서비스를 개발하기만 하면됨
그래도 비용이 여전히 많이 든다.
5) Serverlss
서버를 신경쓸 필요가 없는 클라드 컴퓨팅 모델
즉, 서버가 어떤 사양으로 돌아가고 있는지, 어떻게 늘려야할지, 어떤 네트워크를 사용할지 고민할 필요가 없음함수
함수기반으로 돌아가는 그 자체를 서버로 쓰자!
- 클라우드가 해주는 일 : 서버를 올리고, 런타임을 구성하고, 코드를 배포해서 실행하는 과정
- 우리가 할일 : 원하는 로직을 함수로 등록
즉, 이벤트(트리거)기반으로 코드가 실행 될때만 사용료를 지불하는 클라우드방식
서버의 존재를 신경 쓰지 않은 채 서비스 개발/운영할 수 있음
*Paas vs Serverless
Paas는 전체 앱을 배포하면 서버에서 앱이 24시간 돌아가고있음
Serverless는 특정 이벤트가 발생했을때만 함수가 실행되고 작업을 마치면 종료됨(비용절감)
*Serverlss 특징
- 저렴한 비용 : 24시간 Run이 아니라 함수를 수행하고 있는 동안만 비용
- 뛰어난 확장성 : 서버를 관리할 필요가 없다, 특정 조건 없이 오토 스케일링
- Stateless(무상태적)
Client의 상태정보를 따로 저장하고 관리하지 않음 ex) 로그인 세션 저장 불가
따라서, 세션으 보존해야하는 경우 메모리가 아니라 추가적인 db에 저장해야함 - 리소스 한계 : AWS 1500MB 메모리 사용가능, 처리시간 최대 300초
- Cold Start : 서버가 다시 구동되기까지 딜레이 시간이 있음
서버리스 컴퓨팅은 자원을 효율적으로 사용하기 위해서 행위가 없으면 컴퓨팅 파워를 꺼두고 있다.
그래서 갑자기 함수가 호출되면 다시 켜지고, 부수적인 세팅을 준비하는데 시간이 걸림
이러한 지연시간이 애플리케이션의 성능에 영향을 줄 수도 있음
5-1) Bass (Backend as a Service)
backend기능을 (db,sns연동, 파일시스템 등) API서비스로 재공
개발자들이 서버개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현할 수 있는 서비스
- 장점 : 리소스 설정이 필요없음, 사용한 만큼 비용이 부과, 자동확장가능
- 단점 : 복잡한 기능설계 불가능,어느정도 스토리지가 차면 비용이 비싸다
대표적으로 Google Firebase
Andoird 앱개발 구현시 파이어베이스에서 제공하는 sdk코드를 넣기만 하면 연동이 되었서 편함,
하지만, 데이터베이스의 스키마를 직접 설계 수 없는 한계가 있었다.
5-2) Faas(Function as a Service
프로젝트를 여러 개의 함수로 쪼개서, 비즈니스 로직을 수행하는 함수를 만들고
그 함수들이 실행되는 횟수와 시간만큼 비용을 내는 방식
- 장점 : 서버가 내것이 아니라서 최대 호출할 수 있는 양이 정해져있다.
- 단점 : 웹소켓불가능, 함수들은 무상태적(stateless)
대표적으로 Amazon web service의 Lambda
함수를 수행하고 있는 동안만 비용이 발생됨
'🌴 DevOps > Architecture' 카테고리의 다른 글
Serverless아키텍쳐 구성4 - Lambda(람다) 특징 및 한계 (0) | 2020.03.25 |
---|---|
Serverless아키텍쳐 구성3 - Lambda(람다)& API Gateway (0) | 2020.03.24 |
Serverless아키텍쳐 구성2 - 3티어/서버리스아키텍쳐 비교 (0) | 2020.03.23 |
3tier아키텍쳐 구성9 - 전체 요약 및 총정리 (0) | 2020.02.24 |
3tier아키텍쳐 구성8 - 미들웨어 구성 및 테스트(4.WAS-DB연동) (1) | 2020.02.16 |
3tier아키텍쳐 구성7 - 미들웨어 구성 및 테스트(3.WEB-WAS연동) (2) | 2020.02.15 |