DevOps

서버리스 (Serverless)

궁금한게 많은 개발자 2024. 9. 17. 12:11

서버 리스

서버 리스를 직역하면 서버가 없다는 의미이지만, 실제 의미는 서버가 없는 것이 아닌 서버를 개발자가 직접 관리하고 운영하지 않아도 된다는 의미를 뜻합니다. 즉, 서버는 존재하지만 추상화 되어 있어서 CSP가 서버 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 작업을 처리하고 개발자는 배포를 위해 코드를 컨테이너화 하면 됩니다.

 

서버리스는 CSP가 클라우드 인프라와 애플리케이션의 스케일링을 모두 관리한다는 점에서 다른 클라우드 컴퓨팅 모델과 차이를 가집니다. 서버리스 애플리케이션의 경우 온디맨드로 자동 시작되는 컨테이너에 배포되며 필요한 경우에만 클라우드 인프라 리소스가 할당되며 종료 시 제거됩니다. 동적으로 리소스를 할당하기에 비용 측면에서도 이점이 있습니다.
비용과 효율성이라는 이점 외에도 스케일링 및 서버 프로비저닝과 같은 사소한 테스크에서의 개발자 부담을 덜어줍니다. 

대표적인 서버 리스 (AWS Lambda)

 

반면, 서비스로서의 인프라(Infrastructure as a Service, IaaS) 클라우드 컴퓨팅 모델에서 사용자는 컴퓨팅 리소스 용량 단위를 사전 구매하게 됩니다. 즉, 애플리케이션을 구동하기 위해 CSP에 사전 구매한 리소스에 대한 비용을 상시 지불해야 합니다. 물론 AWS 스팟 인스턴스를 사용하여 비용을 줄일 수 있지만, 가용성을 보장하기 힘들 수 있습니다.

수요가 많을 때 서버를 스케일링 업하고 적을 때 다운하는 것도 사용자의 몫이며 설정에 의해 동작하게 해야 하며, 애플리케이션이 동작하지 않을 때에도 인프라 비용은 지불 됩니다.

 

이처럼 서버리스의 장점을 확인할 수 있는데, 서버리스 모델에는 BaaS, FaaS가 있습니다.

BaaS(Backend as a Service)에 대해 설명하면, 일반적으로 우리가 모바일 혹인 웹 애플리케이션을 개발 할 때 데이터를 저장하고, 다른 기기에서 접근 및 공유하기 위해 백엔드 서버 개발을 하게 됩니다.

하지만 서버 개발을 하다 보면 트래픽에 따라 서버 확장 및 보안 등 다양한 측면을 고려해야 합니다. BaaS 시스템은 앱 개발에 있어서 다양하게 필요한 기능(DB, SNS연동, 파일 시스템)을 API로 제공해 줌으로써 개발자들이 서버 개발을 하지 않고도 필요한 기능을 쉽고 빠르게 구현할 수 있게 해주고 비용은 API 사용한 만큼 발생하는 원리입니다.

즉, CSP가 백엔드 개발 환경까지 제공해 준다고 보면 됩니다. 서버의 이용자가 늘어나도 알아서 확장이 됩니다.

구글의 Firebase가 가장 대표적인 BaaS라고 할 수 있습니다.

  • 애플리케이션 개발 시 요구되는 복잡한 백엔드 기능들을 개발자가 직접 개발하지 않고 
    클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현 하는 것
  • 서비스 제공자로부터 미리 만들어진 백엔드 API를 제공받아 사용하는 형태.

 

일반적으로 더 자주 사용되는 서버리스 모델은 FaaS입니다. 대표적으로 AWS Lambda, Azure의 Azure Functions이 있으며 함수를 서비스로 제공한다는 의미입니다.

사용자는 REST API와 같은 HTTP요청을 통해 함수를 호출하고 원하는 파라미터를전달하여 함수가 리턴하는 값이 있다면 받거나 함수의 시작 이벤트를 발생시킬 수 있습니다. 만약 DB 읽기/쓰기 등을 위한 함수 구문을 클라우드에 업로드 해둔다면, 어느 프로그램에서도 단순히 함수 호출을 통해 데이터베이스로부터 입출력이 가능할 수 있습니다.

    • 개발자가 사용자 정의 서버 측 로직을 작성하지만 클라우드 제공 업체가 관리를 전담하는 서버 컨테이너에서 실행 되는 서비스 기능
    • 서버에서 수행될 기능들을 개발자가 직접 코드로 작성하여 등록한다.
    • 실행 가능한 코드(함수)를 미리 등록해놓았다가 특정 이벤트(트리거)가 발생하면 알아서 호출 및 종료되도록 한다.

 

 

결론적으로 SW개발자가 프로그래밍 로직에만 집중할 수 있도록 하는 것이 바로 FaaS, 서버리스의 주요 개념입니다.

하지만 이러한 서버리스에도 장단점이 있기에 적절한 환경에 맞게 사용해야 합니다. 장단점을 정리해보고자 합니다.

 

 

 

장점

1. 비용 절감

- 기존 IaaS나 PaaS에 비해 실제 사용량에 대해서만 비용이 청구 되므로 경제적

- 이벤트 기반의 비용으로, 일정 주기, 조건 등에 함수를 호출하므로 리소스 낭비하지 않음

- 자체 서버를 실행하고 관리하는 대신 필요한 만큼 컴퓨팅 시간에 대해 비용 지불

2. 애플리케이션 품질에 집중 가능

3. 높은 가용성과 유연한 확장

- 요청이 들어올때만 실행되고 동적으로 자원을 할당하기 때문에 가용성이 높고, 스케일링 신경X

- 애플리케이션은 자동 확장될 수 있고, 개별 서버 단위가 아닌 리소스 사용단위를 설정/해제하여 용량 조절 가능

- 단기간 이벤트성 트래픽 감당하는 경우 효과적

4. 빠른 개발 배포

- 간단한 패키징 및 배포, 릴리즈 주기 감소, 높은 생산성, 유지보수 및 기능 추가 효율적

 

 

 

단점

1. Cold Start

- 서버리스의 함수들은 수면 상태에 있다가 요청이 오면 함수를 깨우고 실행하는데 아무래도 시간이 걸릴 수 있음
  이에 따라 아주 미세한 지연도 허용하기 힘든 서비스의 경우에는 적합하지 않음, 항시 대기 아니므로 지연 발생

2. 장시간 요하는 작업에 불리

- 단순 작업에는 적합하지만, 긴 시간을 요하는 동영상 업로드, 데이터 백업 등에는 굉장히 비효율적

- 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제약이 있기에 큰 기능을 잘게 나누어 구현 필요

3. Stateless (로컬 데이터를 사용할 수 없음), Ephemeral (일시적으로 배포)

- 서버리스는 stateless적인 기능으로 구현되어야 함

- 하나의 작은 기능으로 나뉘어진 함수는 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없음

- 또한 변수와 데이터의 공유가 불가능하며 데이터를 로컬 스토리지에서 읽고 쓸 수 없음

4. CSP에 심하게 종속적

- 기존 IaaS나 PaaS는 CSP를 바꾸는 것이 어렵지 않지만 서버리스는 애플리케이션 구조 자체를 바꾸기 때문에
  다른 플랫폼으로 변경하는 것이 쉽지 않다. 이는 곧 CSP의 정책, 서비스 변경에도 민감

 

 

위 내용을 바탕으로 적절한 환경에서 서버리스를 활용하면 이점을 얻을 수 있을 것 같습니다. 감사합니다.

 

 

 

저작자표시