Weekly I Learned Week03
👊 서버리스
- 말 그대로 '서버가 없다'는 뜻으로 애플리케이션의 확장을 관리 할 필요가 없는 클라우드 컴퓨팅 모델
실제로는 서버가 없는 구조는 아니다.
서버에서 처리하는 작업을 클라우드 기반의 서비스로 처리해서 서버 구축 및 관리 비용을 줄이는 구조
따라서, 개발 기간과 비용을 단축할 뿐만 아니라, 서버 운영과 유지 보수의 어려움을 크게 줄일 수 있다.- 개발자가 인프라(기반)는 대부분 무시하고 코드에 집중 할 수 있도록 도와준다.
서버 사양이 개발자에게 영향을 주지 않으므로 ‘서버리스’인 것
물론 물리적 서버는 여전히 존재하지만 클라우드 제공업체가 서비스 중 서버가 하는 관리한다는 점이
다르며 이 점이 개발자 및 서비스 환경이 서버에 신경을 쓰지 않아도 된다는 이점을 이끌어낸다.
👊 작동방식
이벤트를 실행할 애플리케이션 코드를 트리거(특정한 작용에 대응하여 자동으로 반작용이 실행되게끔 만드는 논리적 장치)하면 클라우드 제공업체는 해당 코드에 리소스(서버 자원)를 동적으로 할당하고, 사용자는 코드 실행이 끝나면 비용을 지불하지 않는다.
👍 장점
- 서버 관리가 필요 없다.
- 유연한 확장성: 애플리케이션을 활용하여 자유자재로 확장을 구현할 수 있다.
- 높은 가용성: 고정된 서버가 없음은 제한된 가용성이 아님을 의미합니다. 가용성을 위한 별도의 설계가 필요 없다.
- 유효 용량에 대한 비용: 사용하지 않는 것에 대해선 비용을 지불할 필요가 없다.
실행하지 않을 때는 비용이 발생하지 않는다. - 개발자 생산성을 높이고 운영 비용을 줄일 수 있다.
👎 단점
- 콜드스타트(Cold-Start): 빠른 응답이 필요한 제품(서비스)의 경우 서버리스로의 전환은 부적합할 수 있다.
이는 실행할 함수를 호출하기 위해 컨테이너가 실행되는 대기 시간이 존재하기 때문인데, 서버를 항시 가동하지 않는 서버리스의 특징에 기인한다. - 무상태(Stateless)적인 기능의 구현 불가: 작은 기능으로 잘게 나눠진 함수들은 요청마다 새로 기동하도록 호출되기 때문에 기동 전후의 상태를 공유할 수 없다. 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다.
- 벤더 종속의 문제: 함수가 사용할 수 있는 최대 메모리, 최대 처리 가능 시간 제약 등의 제약을 서버리스 서비스 벤더가 설정하며 서버리스 사용자 및 서버리스 기반의 서비스는 이에 종속된다. 이에 맞춰 벤더가 설정한 제약을 벗어나는 큰 기능은 잘게 나누어 구현해야한다.
경듀님