서버리스 컴퓨팅은 서버 관리 및 프로비저닝 작업을 클라우드 공급자에게 오프로드하는 데 도움이 되며 대부분의 기술 팀에 빠르게 적용되고 있습니다. AWS Lambda는 많은 기술 팀에서 사용하는 일종의 서버리스 기술입니다. AWS Lambda는 NodeJS, Java, Python 및 Ruby를 포함한 대부분의 핵심 프로그래밍 언어를 지원합니다. 핵심 프로그래밍 언어가 지원되지만 이러한 언어로 구축된 프레임워크의 일부인 기능에 따라 서버리스 기능을 실행하려는 경우가 있습니다. 이 게시물에서는 AWS Lambda에서 Rails 애플리케이션을 실행하는 방법을 살펴보겠습니다. 이 게시물은 귀하가 서버리스 컴퓨팅 및 AWS Lambda에 익숙하고 AWS Lambda에서 Rails를 실행하는 방법을 알고 싶어한다고 가정합니다. Lamby라는 도구를 사용하면 AWS Lambda에서 Rails를 거의 쉽게 실행할 수 있으며, Lamby를 사용하여 Rails를 빌드하고 Lambda에 배포하는 방법을 다룰 것입니다. 저는 이것을 "Rails on Lambda"라고 부르겠습니다.
램비가 무엇인가요?
Lambda를 사용하면 서버를 유지 관리할 필요 없이 코드를 배포하고 규모에 상관없이 실행할 수 있습니다. 코드를 AWS에 업로드하기만 하면 됩니다. 사용자가 웹 페이지에 작업을 요청하는 것과 같은 이벤트에 의해 트리거될 때마다 실행됩니다.
Lambda는 코드가 특정 방식으로 구조화되기를 기대합니다. 따라서 Rails 앱과 같은 것을 호스팅하는 데 사용하려면 Lamby와 같은 어댑터를 사용해야 합니다.
Lamby는 간단한 랙 어댑터입니다. Rails 앱과 AWS Lambda 사이에 위치하며 API 게이트웨이 또는 애플리케이션 로드 밸런서와 같은 다양한 AWS 소스의 Lambda 호출 이벤트를 Rails 앱이 수신할 수 있는 Rack 이벤트로 변환합니다.
Rails Lambda 아키텍처 소스:Lamby Docs
Lamby는 Docker 및 AWS SAM을 활용하여 Rails 앱을 빌드, 패키징 및 Lambda에 배포합니다.
<블록 인용>AWS 서버리스 애플리케이션 모델(AWS SAM)은 AWS에서 서버리스 애플리케이션을 구축하는 데 사용할 수 있는 오픈 소스 프레임워크입니다. 서버리스 애플리케이션은 작업을 수행하기 위해 함께 작동하는 Lambda 함수, 이벤트 소스 및 기타 리소스의 조합입니다. 서버리스 애플리케이션은 단순한 Lambda 함수 이상입니다. 여기에는 API, 데이터베이스 및 이벤트 소스 매핑과 같은 추가 리소스가 포함될 수 있습니다.-- AWS SAM 문서
Lamby를 시작하려면 Docker를 설치하고 AWS 계정을 만들고 AWS 계정에 대한 프로그래밍 방식 액세스를 구성해야 합니다.
도커 설치
AWS SAM은 Docker를 사용하여 Lambda 런타임 환경을 시뮬레이션합니다. 또한 Docker는 Python에 의존하는 AWS CLI 및 SAM CLI 설치의 복잡성을 줄여줍니다. Docker가 아직 설치되어 있지 않은 경우 공식 웹 사이트에서 다운로드하여 설치할 수 있으므로 Docker를 설치하는 것은 매우 쉽습니다. Docker가 설치되었는지 확인하려면 터미널에서 아래 명령어를 실행하세요. Docker가 설치된 경우 아래 표시된 것과 유사한 버전 번호와 빌드가 표시됩니다.
$ docker --version
Docker 설치 확인
AWS 계정 설정
아직 AWS 계정이 없는 경우 계정을 설정해야 합니다. Amazon에는 Lambda에서 Rails 앱 생성 및 테스트와 AWS 계정 생성 및 활성화 방법에 대한 가이드가 포함된 프리 티어 플랜이 있습니다. 가이드에 따라 계정을 설정하세요.
AWS 프로그래밍 방식 액세스 설정
이제 AWS 계정이 있으므로 계정의 AWS 액세스 키 ID 및 AWS 보안 액세스 키를 사용하여 프로그래밍 방식 액세스를 구성해야 합니다. 아직 없는 경우 다음을 수행하여 만들 수 있습니다.
- AWS 계정에 로그인합니다.
- AWS Management Console의 도구 모음에서 "서비스"를 클릭합니다.
- "IAM"을 검색하고 선택합니다.
- 왼쪽 탐색 메뉴에서 "사용자"를 클릭합니다.
- "IAM"이 이미 있는 경우 사용자 이름을 선택하십시오.
- '보안 자격 증명' 탭을 클릭합니다.
- '액세스 키 만들기' 버튼을 클릭합니다.
- 키 ID와 비밀을 안전한 장소에 복사합니다.
- "IAM" 사용자가 없으면
- '사용자 추가'를 클릭합니다.
- 사용자 이름을 추가하고 "프로그래매틱 액세스" 옵션을 선택합니다.
- 안내에 따라 절차를 완료하세요.
Docker를 사용하여 CLI 프로그래밍 방식 액세스를 구성해 보겠습니다. 아래 코드를 터미널에 복사하십시오. AWS 액세스 키 ID 및 AWS 보안 액세스 키를 입력하라는 메시지가 표시됩니다. 이전 단계의 키를 입력하십시오.
$ docker run \
--interactive \
--tty \
--rm \
--volume "${HOME}/.aws:/root/.aws" \
"amazon/aws-cli" \
configure
새 Rails 애플리케이션 만들기
우리는 SAM CLI를 사용하여 Rails 프로젝트를 부트스트랩할 것입니다. AWS SAM CLI를 사용하면 일반적으로 cookiecutter라고 하는 GitHub 리포지토리 템플릿에서 새 프로젝트를 초기화할 수 있습니다. 새 SAM 프로젝트를 시작하기 위해 Docker 컨테이너를 사용하여 sam init
를 실행합니다. , Lamby Cookiecutter 프로젝트 템플릿을 활용하여 새 프로젝트 폴더를 시작합니다. 프로젝트 이름을 입력하라는 메시지가 표시되지만 저는 "rails_on_lambda"를 사용했습니다.
$ docker run \
--rm \
--interactive \
--volume "${PWD}:/var/task:delegated" \
lambci/lambda:build-ruby2.7 \
sam init --location "gh:customink/lamby-cookiecutter"
새 SAM 프로젝트 폴더에는 새 Rails on Lambda 프로젝트에 필요한 모든 것이 있습니다. 더 높은 수준에서 새 프로젝트에서 생성된 내용은 다음과 같습니다.
- Dockerfile과 docker-compose를 모두 사용한 Docker 설정
- lib 디렉토리, 번들러 및 테스트가 있는 작동하는 Ruby 프로젝트
- SAM
template.yaml
파일.
설정 및 배포
이제 새 Rails 앱을 생성했으므로 Lambda 배포를 위해 설정해야 합니다. 아래의 두 명령은 Docker 개발 이미지와 번들 gem을 빌드하는 스크립트를 실행합니다. bootstrap
명령은 일회성 프로세스인 반면 setup
새 프로젝트 종속성을 추가할 때마다 명령이 실행됩니다.
$ ./bin/bootstrap
$ ./bin/setup
이전 명령을 성공적으로 실행하면 프로젝트가 SAM을 통해 배포할 준비가 된 것입니다. 배포는 Rails 애플리케이션을 빌드, 패키지 및 배포하는 Lamby 스크립트를 사용하여 수행됩니다.
./bin/deploy
deploy
명령은 현재 프로젝트 디렉토리를 로컬 .lamby
에 복제하는 Lamby 빌드 스크립트를 실행합니다. 디렉토리를 만들고 애플리케이션을 배포하는 데 필요한 세 가지 SAM 명령을 실행합니다.
- 샘 빌드
- 샘 패키지
- 샘 배포
스크립트가 예상대로 실행되면 다음과 같이 끝나는 SAM의 CloudFormation 배포 작업에 대한 출력이 표시되어야 합니다.
또한 터미널 출력의 일부로 URL이 표시되어야 합니다. URL은 Rack을 사용하여 Rails 애플리케이션을 호출하는 API Gateway HTTP API 엔드포인트입니다. 브라우저에서 열면 친숙한 "Rails에 오신 것을 환영합니다" 화면이 표시됩니다.
AWS 콘솔에서 Rails 앱 호출
Lambda 대시보드에서 앱을 테스트할 수도 있습니다. AWS Management 콘솔에 로그인:
- 도구 모음에서 "서비스"를 클릭하십시오.
- 서비스 찾기 필드에 "Lambda"를 입력하고 선택합니다.
이 페이지에서 새로 배포된 "RailsOnLambda" 프로젝트를 볼 수 있습니다.
- "RailsOnLambda" 기능을 엽니다.
- 오른쪽 상단의 "테스트" 버튼을 클릭하십시오.
- "Amazon API Gateway Proxy" 이벤트 템플릿을 사용합니다(아래 JSON 템플릿을 사용하여 해당 필드 업데이트).
- "RailsOnLambdaTest"라는 이름을 지정합니다.
- '만들기' 버튼을 클릭합니다.
- "테스트" 버튼을 클릭하여 Lambda를 호출합니다.
{
"body": "",
"path": "/",
"httpMethod": "GET",
"queryStringParameters": {},
"multiValueQueryStringParameters": {},
"pathParameters": {
"proxy": "/"
},
"stageVariables": {},
"requestContext": {
"path": "/",
"httpMethod": "GET"
}
}
모든 것이 순조롭게 진행되었다고 가정하면 아래와 유사한 출력이 표시되어야 합니다.
축하합니다! 이제 Lambda의 Rails 애플리케이션이 여전히 일반 Rails 애플리케이션이지만, 이제 Rails on Lambda가 있습니다. 유일한 차이점은 Lamby gem이 API Gateway HTTP API, API Gateway REST API 및 애플리케이션 로드 밸런서 대상 이벤트를 Rack 호환 env
로 변환한다는 것입니다. 객체를 가져와 Rails로 보냅니다. 그런 다음 Rails는 이벤트 결과를 프로젝트에 정의된 Lambda 핸들러로 다시 전달합니다.
def handler(event:, context:)
Lamby.handler $app, event, context
end
Rails on Lambda의 성능은 어느 정도입니까?
Rails on Lambda는 배포 후 첫 번째 요청에 대해 느린 응답 시간을 경험합니다. 이 현상을 "콜드 스타트"라고 합니다. 그러나 첫 번째 요청 이후에는 성능이 우수하여 EC2를 충족하거나 능가할 수 있습니다. 첫 번째 요청 이후에 후속 요청이 없으면 Rails 앱을 제공하는 서버 리소스는 약 5-7분 후에 다른 Lambda 함수에 동적으로 할당됩니다. 이로 인해 새 요청에 대한 콜드 스타트가 발생합니다. 콜드 스타트를 피하고 Rails 앱을 따뜻하게 유지하는 몇 가지 방법이 있습니다.
CloudWatch 타이머
1분마다 Rails on Lambda 함수를 ping하여 따뜻하게 유지하는 시간을 설정할 수 있습니다. AWS 콘솔을 열고 CloudWatch를 검색합니다. 거기에서 이벤트로 이동하여 규칙 만들기를 클릭합니다. 이벤트 유형을 일정으로 설정하면 이 이벤트가 1분마다 실행됩니다.
프로비저닝된 동시성
프로비저닝된 동시성은 AWS가 사용하지 않는 컨테이너를 항상 실행하도록 하기 위해 더 많은 비용을 지불하도록 전환하고 동의할 수 있는 AWS 기능입니다. Rails 앱에 대해 프로비저닝된 통화를 구성하려면 AWS 콘솔을 열고 Lambda 서비스 페이지를 엽니다.
- 함수(rails-on-lambda)를 선택합니다.
- 구성을 선택한 다음 동시성을 선택합니다.
- 프로비저닝된 동시성 구성에서 구성 추가를 클릭합니다.
- 별칭 또는 버전을 선택합니다.
- 할당할 프로비저닝된 동시성의 양(예:500)을 입력합니다.
- 변경 사항을 저장합니다. 프로비저닝된 통화는 다음 명령을 사용하여 AWS CLI를 통해 구성할 수도 있습니다.
aws lambda put-provisioned-concurrency-config --function-name my-function \
--qualifier BLUE --provisioned-concurrent-executions 100
AWS에서 Lambda 비용은 얼마입니까?
AWS Lambda를 사용하면 사용한 만큼만 비용을 지불하면 됩니다. 비용은 요청 수와 코드 실행 기간의 조합입니다. 기간 가격은 함수에 할당하는 메모리 양에 따라 다릅니다. 메모리 크기의 범위는 128MB에서 10,240MB이며 필요에 따라 함수에 메모리 양을 할당할 수 있습니다. 아래는 다양한 시간 동안 Lambda 함수를 100,000번 호출하는 비용을 보여주는 차트입니다.
람다 비용
람다에서 Rails를 실행하면 안 되는 경우
AWS Lambda에서 Rails 앱을 실행할 수 있음을 확인했지만 모든 Rails 애플리케이션을 Lambda에서 실행해야 합니까? Rails는 애플리케이션이 서버리스가 아닌 기존 서버에서 실행되고 있다고 가정합니다. 기존 Rails 서버 앱에서 쉽게 작동하는 특정 작업은 서버를 사용하지 않고 작동하지 않을 수 있습니다. 예를 들어, 앱이 영구 파일 시스템에 액세스할 수 없기 때문에 파일 또는 이미지 업로드는 Lambda on Lambda 앱에서 작동하지 않습니다. 또한 WebSocket 통신은 요청이 없을 때 서버가 존재하지 않기 때문에 Lambda에서 작동하지 않습니다.
결론
기본 Rails 애플리케이션을 배포하는 방법만 보여줬지만 대규모 애플리케이션에 대해서도 동일한 프로세스를 따릅니다. 자유롭게 컨트롤러와 경로를 추가하고 콘솔에서 또는 Postman 및 기타 HTTP 클라이언트를 통해 테스트하세요.