비용 : 고정된 수량의 서버를(EC2 같은) 임대 할 필요가 없으므로 비용효율적일 수 있다. 기본적으로 코드를 실행하기 위해 할당된 시간과 메모리를 기반으로 요금이 부과되기 때문이다. 서버를 사용 할 경우 유휴시간에 대한 비용이 발생하지만, 서버리스라면 그럴 걱정이 없다. 업무시간에만 작동하면 되는 코드와 같이 유휴시간이 긴 작업의 경우 특히 비용절감 효과가 크다.
확장성과 유연성 : 서버리스 아키텍처는 개발자와 운영자가 확장 정책을 세우기 위해서 고민 할 필요가 없다. 클라우드 제공자가 알아서 확장을 해주기 때문이다. 운영자가 없는 소규모팀이라면, 엔지니어링 팀에 의존하지 않고 직접 코드를 실행 할 수 있을 것이다. 물론 이론적으로 그렇다는 것이고, 실제로는 개발자에게 서버리스가 익숙한 환경은 아니기 때문에(그리고 클라우드라는게 생각처럼 만만한 시스템이 아니다.) 어느 정도의 학습은 필요하다. 이러한 학습과 적응은 개발팀이 자연스럽게 DevOps 문화에 적응 할 수 있게 한다.
생산성 : 서버리스에서 개발단위는 하나의 업무를 처리하는 단일 함수다. 멀티스레딩이나 HTTP 요청에 대한 처리를 신경쓸 필요가 없다. 이로인해 백앤드 소프트웨어 개발이 단순해진다.
물론 단점도 있다.(마법의 은탄환은 없는 법이라서)
성능 : 가끔 사용하는 서버리스 코드는 응답대기 시간이 길어질 수 있다. 클라우드 서비스 제공자가 "코드의 유휴기간이 길어지면 코드를 스핀다운" 해버리기 때문이다. 자바같은 경우 대기시간이 더 길어질 수 있다. 스핀다운 유휴시간을 조절할 수 있으니, 서비스 특징에 맞춰서 최적화해줘야 한다.
보안 : 관리해야 할 자원이 없으니 기존 아키텍처보다 더 안전하다고 생각 할 수 있겠다. 하지만 꼭 그런건 아니다. 기존 방식의 경우 접점에 운영체제가 있기 때문에, 보안담당자는 운영체제에 여러가지 보안장치들을 추가 구성 할 수 있다. 로드밸런서와 서버 앞단에도 보안조치를 할 수 있다. 서버리스에서는 함수가 인터넷에 바로 노출되기 때문에 추가적인 보안조치를 할 수가 없다. 서버리스 아키텍처를 적용할 경우, 기존과 달라진 보안환경에 의해서 다른 종류의 보안위협에 노출될 수 있으므로 보안담당자와 긴밀하게 협업해서 문제를 해결해야 한다.
프라이버시 : 람다 코드가 인터넷에 바로 노출되면서 데이터베이스같은 주요 자원들도 함께 노출될 수 있다. 클라우드 서비스 제공자도 놀고 있는게 아니라서 VPC에 연결할 수 있는 등의 기능을 계속 개발하고 있어서, 지금은 큰 문제는 아니다.
AWS Lambda
AWS Lambda는 AWS에서 제공하는 컴퓨팅 관련 서버리스 서비스다. 서버리스라는게 개념은 아주 예쁘지만 "서버가 없고" 많은 기능들이 추상화 돼 있기 때문에 개발 & 테스트 환경을 만들기가 애매모호한 단점이 있다. 해서 AWS 에서 제공하는 서버리스 프레임워크인 SAM 혹은 serverless.com 같은 회사의 serverless 프레임워크를 이용해서 개발을 한다.
이들 프레임워크를 이용하면 개발이 수월해지기는 하지만, 기존에 사용하는 IDE와 통합이 되지 않으며 때문에 버전관리나 디버깅, 테스트, 배포가 분리되는 불편한 점은 여전히 남는다. 클라우드 포메이션, 외부 솔류션 학습이 필요하다는 것도 불편한 점이다.
Visual Studio code를 위한 AWS Toolkit
AWS는 서버리스 개발을 지원하기 위한 Visual Studio code용 AWS Toolkit을 2019년 7월 11일 정식으로 배포했다. 이 툴킷은 Node.js, Python, .NET을 지원한다. 내 주력언어인 golang이 빠져있어서 안타깝기는 한데, 뭐 조만간 지원할 거라고 기대하고 있다.
기본 환경 설정
우분루 리눅스 19.04 운영체제에 설치했다. Python 버전은 3.7.3 이다. 나는 virtualenv로 python 개발환경을 꾸렸다.
AWS API를 호출하기 위해서 aws credentials 설정이 필요하다. 나는 개인 AWS 루트 계정으로 Credentials를 추가했다. Credentials의 access key와 secret key를 이용해서 aws 환경을 설정했다.
AWS 기반으로 애플리케이션 개발을 할 생각이라면, 이번 기회에 aws cli를 설치하자.
AWS Toolkit는 SAM을 이용한다. sam을 설치하자.
# pip install aws-sam-cli
# sam --version
SAM CLI, version 0.18.0
AWS SAM은 도커 컨테이너 기반으로 개발 & 테스트 환경을 구성한다. 도커 컨테이너도 설치하자. 내 환경은 아래와 같다.
docker version
Client:
Version: 18.06.1-ce
API version: 1.38
Go version: go1.10.4
Git commit: e68fc7a
Built: Tue May 7 17:57:34 2019
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.4
Git commit: e68fc7a
Built: Tue May 7 17:57:34 2019
OS/Arch: linux/amd64
Experimental: false
AWS Toolkit 설치
VS Code를 실행하고 Extensions를 클릭한다.
aws toolkit로 검색하자. AWS Toolkit for Visual Studio Code를 설치한다.
Command Palette(Ctrl+Alt+P)상태에서 AWS: Connect to AWS를 입력, AWS에 연결한다. AWS Credentials 설정을 잘 했다면, AWS EXPLORER 창을 볼 수 있을 것이다.
나는 4개의 프로파일을 가지고 있다. 그 중 default(루트권한을 가지고 있다)를 선택했다.
SAM Project
Command Palette > Create New SAM Application를 이용해서 새로운 SAM 애플리케이션을 만들 수 있다.
애플리케이션 런타임(Runtime)를 선택한다. 나는 python 3.7을 선택했다. 프로젝트 폴더와 이름을 입력하면 아래와 같이 샘 애플리케이션이 만들어진다.
lambda_handler에 원하는 코드를 넣으면 된다.
로컬에서 실행
코드를 보면 5~6째줄 사이에 "Run Locally|Debug Locally|Configure"가 보인다. 마우스로 클릭하는 것으로 원하는 행동을 할 수 있다. Run Locally를 클릭하면 로컬에서 람다코드를 실행한다.
Contents
서버리스 아키텍처
- 비용 : 고정된 수량의 서버를(EC2 같은) 임대 할 필요가 없으므로 비용효율적일 수 있다. 기본적으로 코드를 실행하기 위해 할당된 시간과 메모리를 기반으로 요금이 부과되기 때문이다. 서버를 사용 할 경우 유휴시간에 대한 비용이 발생하지만, 서버리스라면 그럴 걱정이 없다. 업무시간에만 작동하면 되는 코드와 같이 유휴시간이 긴 작업의 경우 특히 비용절감 효과가 크다.
- 확장성과 유연성 : 서버리스 아키텍처는 개발자와 운영자가 확장 정책을 세우기 위해서 고민 할 필요가 없다. 클라우드 제공자가 알아서 확장을 해주기 때문이다. 운영자가 없는 소규모팀이라면, 엔지니어링 팀에 의존하지 않고 직접 코드를 실행 할 수 있을 것이다. 물론 이론적으로 그렇다는 것이고, 실제로는 개발자에게 서버리스가 익숙한 환경은 아니기 때문에(그리고 클라우드라는게 생각처럼 만만한 시스템이 아니다.) 어느 정도의 학습은 필요하다. 이러한 학습과 적응은 개발팀이 자연스럽게 DevOps 문화에 적응 할 수 있게 한다.
- 생산성 : 서버리스에서 개발단위는 하나의 업무를 처리하는 단일 함수다. 멀티스레딩이나 HTTP 요청에 대한 처리를 신경쓸 필요가 없다. 이로인해 백앤드 소프트웨어 개발이 단순해진다.
물론 단점도 있다.(마법의 은탄환은 없는 법이라서)AWS Lambda
Visual Studio code를 위한 AWS Toolkit
기본 환경 설정
AWS Toolkit 설치
SAM Project
로컬에서 실행
Recent Posts
Archive Posts
Tags