[AWS] 서버리스로 서버없이 간단한 웹 애플리케이션 만들기
지난 6월 19일에 AWS Builders Korea Program 기초과정으로 열리는 AWS 서버리스로 서버 없이 간단한 웹 애플리케이션 만들기 세션을 수강했다.
평소에 AWS에 관심이 많았고, 특히 AWS의 서버리스 서비스인 Lambda에 관심이 많았는데 좋은 기회로 실습까지 해볼 수 있어서 좋았다 :)
서버리스란?
AWS에서는 서버의 패러다임 전환을 다음과 같이 소개한다
1세대: Physical Machine (물리 머신)
2세대: Virtual Machine (가상 머신)
3세대: Containerization (컨테이너화)
4세대: Serverless (서버리스)
1세대인 물리머신에서는 한 대의 물리머신 위에 필요한 것들을 모두 배포하는 방식으로 이루어 졌다.
2세대 가상머신에 와서는 한 대의 물리 머신 위에 여러대의 가상머신을 띄워 마치 분리된 공간을 사용하는 것 처럼 사용할 수 있게 되었다. (여러개의 OS를 올려서 사용할 수 있게 된다.)
3세대 컨테이너를 사용하면서부터는 한대의 컨테이너 엔진위에 여러 컨테이너를 올려 사용할 수 있게 되었다.
이 과정에서 무거운 OS는 빠지게 되고 원하는 애플리케이션과 라이브러리들을 격리하여 포터블(Portable)하고 가볍게 사용하게 된다.
4세대 서버리스에서는 서버 없이 코드나 빌드된 결과만으로 애플리케이션이 어디선가 실행이 되도록 한다.
이후의 실습 과정을 보면 더 잘 이해될 것이다.
AWS 서버리스의 장점
- Auto Scaling: 서버리스는 트래픽에 따라 자동으로 서버가 스케일링되기 때문에 응답시간이 보장된다.
- 고가용성: AWS에서 이중화나 고가용성을 모두 보장하기 때문에 복잡한 구조를 설계할 필요가 없다.
- 비용: 24/7 가동되는 서버와 달리 서버리스는 사용되는 양 만큼만 과금된다.
- 보안책임(?): AWS에서 보안관리를 하기 때문에 보안수준이 높고, 고객이 신경 쓸 부분이 적어진다.
이러한 장점들을 토대로 AWS가 주장하는 핵심은 바로 다음과 같다.
서비스에 집중함으로써 빠르게 실패하고, 빠르게 실제에 접근하도록 한다.
즉 고가용성, 보안, 이중화, 배포 등 복잡한 요소들은 AWS에서 관리하고, 개발자는 서비스 자체에만 집중하는 환경을 제공하겠다는 것이다.
이를 통해 빠르게 실패하고 빠르게 보완하므로써 빠르게 실제에 도달하도록 돕는다는 것이 핵심인 듯 했다.
AWS 서버리스 서비스
AWS에서 제공하고 있는 서버리스 서비스는 다음과 같다고 한다.
이중에서 실습에서 사용한 서비스들은 Amazon API Gateway, AWS Lambda, Amazon DynamoDB이다.
Serverless 아키텍처
실습으로 만들어본 아키텍처는 다음과 같다.
- Lambda (Web Page): 웹페이지를 구성하는 html, css코드와 버튼을 통해 API를 호출하는 javascript 코드
* 실제 현업에서는 정적페이지를 lambda에 올리진 않고 주로 S3에 올린다고 한다.
- API Gateway: Web Page 버튼을 통해 호출되어 REST API의 GET 방식으로 Lambda (Service) 함수를 호출
- Lambda (Service): Member의 이름과 상태를 랜덤으로 생성하고, boto3 (AWS SDK)로 dynamoDB에 저장해주는 코드
- DynamoDB: Member의 이름과 상태를 Key-Value 형식으로 저장하는 NoSQL DB
Lambda Function - Web Page 생성
- 직접 lambda function을 작성할 예정이므로 Author from scratch 옵션을 선택한다.
- lambda function 이름은 simple-webpage로 지정해주었다.
- Runtime은 Python3.9로, Architecture은 인텔기반의 x86_64를 선택해주었다.
- 웹페이지(lambda function)에 URL로 접근할 수 있도록 Advanced Settings에서 Enable function URL을 활성화한다.
- 인증없이 바로 URL로 접속할 수 있도록 Auth type를 NONE으로 설정한다.
* lambda function은 일반적으로 http로 호출하기보다 이벤트에 의해 호출된다. 하지만 이번 테스트 환경에서는 URL로 호출하도록 열어둔다.
Lambda Function을 Deploy하면 위와 같이 생성이된다.
오른쪽 밑에 Function URL이 생성되는데, 해당 주소를 통해 lambda function을 호출(웹 페이지에 접근)할 수 있다.
주소로 접속하면 웹페이지에 접속할 수 있게 된다. (코드는 AWS에서 제공한 코드를 사용했다.)
Lambda Function - API service 생성
이번엔 API에서 호출되어 Dynamo DB에 데이터를 저장하는 Lambda Function을 생성해보자.
- 서비스 이름을 api-service-create로 생성한다.
- Dynamo DB에 접근해야하기 때문에 Change default execution role에 들어가서 Create a new role from AWS policy templates을 선택하여 새 role을 추가주었다.
- role의 종류는 Dynamo DB에 접근할 수 있는 Simple microservice permissions를 추가해준다.
- 해당 Lambda Function은 API Gateway를 통해 호출될 예정이기 때문에 URL을 따로 생성해주지 않아도 된다.
Dynamo DB 생성
Dynamo DB는 완전관리형 서비스이기 때문에 DBA가 없는 회사에서 실제로 많이 쓰이는 서비스라고 한다.
이때 key를 어떻게 설정하냐에 따라 성능이 갈리기 때문에, key 디자인이 매우 중요하다고 한다.
- Table이름은 hello-member로 준다. (Lambda Function (server)에서 boto3로 dynamoDB의 테이블 이름을 지정해 주어야 한다)
- Key로 name 을 가지도록 한다.
API Gateway 생성
- REST API로 생성해주었다.
- 생성하면 기본적으로 루트 메소드만 생성된다.
- GET 메소드를 추가한다. 이때 아까 생성한 api-service-create lambda function과 연결해준다.
API 테스트를 수행하면 새 Member 데이터가 생성되고 200 Status Code가 떨어진다.
DynamoDB 서비스에 데이터가 잘 들어갔는지 확인해보자.
API호출로 생성된 데이터가 DB에 잘 저장되어 있다!
API Gateway 추가설정 - CORS
CORS는 Cross-Origin Resource Sharing의 약자로, 어떤 도메인의 자원에서 다른 도메인의 자원에 접근하는 것을 의미한다.
AWS에서는 기본적으로 해킹방지를 위해 내 브라우저에서 보낸 URL이 아닌 곳에서 호출을 하면 에러가 나도록 설정되어 있다.
웹에서 버튼으로 API를 호출해야하기 때문에 CORS를 Enable해야한다.
Enable CORS로 이를 해지할 수 있다.
API 설정을 하고나서 Deploy하면 URL이 생성된다.
생성된 URL로 접속해보면 API Gateway를 통해 lambda 함수를 호출하고, DB까지 저장된다.
추가 연결
제일 처음 생성했던 lambda function (webpage)의 javascript 코드에서 버튼 클릭 시 호출되는 URL에 API URL을 작성해주면 아키텍처 연동이 완성된다!
시연
기존 DynamoDB에는 위의 데이터들이 존재한다.
웹에서 버튼을 클릭해 새 데이터를 생성해보자.
생성된 Satisfied Jone이 DynomoDB에 추가되어있는걸 확인할 수 있다.
AWS 웨비나 세션을 통해 서버리스 아키텍처를 구축해보았다.
확실히 실습을 통해 직접 구축해보니 연결 정보가 머리에 더 잘 들어오는 것 같다.
다음번엔 혼자서도 구축해볼 수 있지 않을까! ㅎㅎ
기초과정은 따로 크레딧이 주어지지 않기 때문에 실습 이후 자원을 모두 삭제했다.
Lambda 서비스와 API Gateway는 호출하는 횟수에 따라 과금되고 기본 요금은 따로 없기 때문에 그대로 두었다.
DynamoDB는 생성만 해도 기본적으로 요금이 과금되기 때문에 삭제했다.