Category: Compute


AWS Lambda – 클라우드에서 코드 실행

AWS는 클라우드에서 실행되는 응용 프로그램의 실행을 더욱 쉽게 하여 개발자들이 코드에만 집중할 수 있게 될 뿐만 아니라 확장성, 신뢰성 및 런타임 효율이 충분히 높은 클라우드 중심의 개발 환경이 필요하다고 생각해 왔습니다.

이를 위해 AWS Lambda미리보기를 오늘 출시합니다. AWS Lambda는 클라우드에서 애플리케이션을 실행하는 새로운 플랫폼으로서 기존 프로그래밍 및 AWS 지식을 활용할 수 있습니다. Lambda를 이용하여 간단하게 Lambda function을 만들고 특정 AWS 리소스에 대한 권한을 주고 Lambda function을 AWS 리소스에 연결할 수 있습니다. Lambda는 Amazon Simple Storage Service (S3) 버킷에 업로드된 파일에 대한 변경이나 Amazon Kinesis 스트림에의 특정 데이터 처리, Amazon DynamoDB 테이블 업데이트 같은 이벤트를 통해 여러분이 미리 업로드한 코드를 자동으로 실행합니다.

Lambda는 전혀 관리가 필요 없는 컴퓨팅 플랫폼입니다. EC2 인스턴스를 만들고 설정할 필요가 없습니다. 운영 체제나 프로그래밍 개발 환경을 설치할 필요도 없습니다. 스케일과 탄력성을 고려할 필요도 없으며, 미리 용량을 요청하거나 확보할 필요도 없습니다. 새로 만들어진 Lambda function은 사용자 측에서 아무 것도 하지 않으면서도 높은 비용 효율에 따라 시간당 수백만 건의 요청을 처리 할 수​​ 있습니다.

좀 더 Lambda를 자세히 살펴 보겠습니다. 프로그래밍 모델 및 런타임 환경을 살펴 보고 나서 프로그래밍 예제를 실행 해 보겠습니다. 이 글을 읽음으로서 Lambda 로드맵에 많은 항목이 있다는 것을 아실 수 있고, 앞으로 계속 이어질 기능 추가를 위한 여행의 작은 첫 걸음입니다.

Lambda의 개념

Lambda의 가장 중요한 개념은 Lambda function입니다. Node.js ( JavaScript로 개발된 이벤트 기반 서버 구현)에서 Lambda function을 실행 할 수 있습니다.

JS 코드를 업로드하기 위해 Lambda function을 만드는 Amazon Lambda에 대한 컨텍스트 정보를 설정합니다. 컨텍스트 정보는 실행 환경(언어, 필요한 메모리 제한 기간이나 IAM role)을 지정하고 코드에서 수행할 함수를 지정합니다. 코드와 메타 데이터는 AWS에서 영구적으로 저장하고 나중에 이름과 ARN(Amazon Resource Name)에서 볼 수 있습니다. 필요한 타사 라이브러리도 업로드에 포함할 수 있습니다 (Lambda function마다 하나의 ZIP 파일 형식입니다).

업로드 후 자신의 Lambda function과 특정 AWS 리소스 (특정 S3 버킷, DynamoDB 테이블 또는 Kinesis 스트림)을 연결합니다. Lambda는 Lambda function에 이벤트 (일반적으로 자원이 변경된 경우 실행)을 함께 연결하도록 합니다.

자원에 변경이 있는 경우, Lambda는 그 자원에 연결된 Lambda function을 실행합니다. 수신 요청을 처리하기 위해 필요한 컴퓨팅 리소스(EC2 인스턴스)를 시작 및 관리합니다. Lambda가 여러분 대신 자원을 관리 할 수​​ 있으며, 더 이상 필요 없어지면 실행이 종료됩니다.

Lambda는 AWS Management Console, AWS SDKAWS Command Line Interface (CLI)에서 접근할 수 있습니다. Lambda API는 모든 문서화되어 있으며 기존 코드 편집기 및 기타 개발 도구를 Lambda에 연결하는 데 사용할 수 있습니다.

Lambda 프로그래밍 모델
Lambda function 연결된 AWS 서비스의 자원이 변경될 때 활성화됩니다. 즉, 지정된 Node.js의 함수 실행이 시작되고 거기에서 작업 처리가 진행됩니다. 함수는 (POST와 함께 전달 된 매개 변수를 통해) JSON 형식의 데이터 구조에 접근합니다. 이 데이터 구조는 Lambda function이 활성화되는 계기가 되는 변경(또는 기타 이벤트)에 대한 자세한 정보를 포함합니다.

Lambda는 자원 변경 속도에 뒤쳐지지 않도록 필요에 따라 Lambda function의 추가 복사본을 활성화합니다. Lambda function은 컴퓨팅 인스턴스에 영구적인 상태를 저장할 수 없기 때문에, 대신 S3 또는 DynamoDB를 사용해야 합니다.

여러분의 코드는 Node.js 및 Linux 환경에서 내재된 기능을 사용할 수 있습니다. 다른 AWS 서비스를 호출하기 위해 AWS SDK for JavaScript in Node.js 를 이용할 수도 있습니다.

Lambda의 실행 환경
각 Lambda function에 지정된 컨텍스트 정보는 함수의 최대 실행 시간을 지정합니다. 일반적으로 짧게 설정되어 있지만 (몇 초 정도에 대부분 실행 가능) 필요에 따라 최대 60초까지 지정할 수 있습니다.

Lambda는 여러 IAM role을 사용하여 Lambda function에 대한 접근과 AWS 리소스를 관리합니다. Invocation role은 Lambda에서 특정 Lambda function을 수행할 권한을 부여합니다. Execution role은 Lambda function의 특정 AWS 리소스에 대한 접근 권한을 부여합니다. 세분화 되어 있는 권한의 조합을 이루기 위해 각각 기능에 대해 별도의 IAM role을 사용할 수 있습니다.

Lambda는 각 Lambda function의 실행을 감시하고 요청 수, 지연 시간, 가용성 및 오류 비율 통계를 Amazon CloudWatch 에 저장합니다. 30 일 동안 보관되며 콘솔에서도 볼 수 있습니다.

이제 Lambda를 사용하시려고 할 때 고려해야 할 몇 가지 사항을 알려드립니다.

  • Lambda function 컨텍스트 정보는 실행에 필요한 메모리 양을 지정합니다. 128MB에서 1​​GB까지 원하는 값을 지정할 수 있습니다. 메모리 설정에 따라 Lambda function이 사용 가능한 인스턴스의 CPU 능력, 네트워크 대역폭, IO 대역폭이 결정됩니다.
  • 각 Lambda function의 시작은 최대 256 프로세스 또는 스레드를 사용할 수 있습니다. 최대 512MB의 로컬 스토리지와 102개 이상의 파일 디스크립터도 사용할 수 있습니다. 또한, 최대 10개의 동시 아웃 바운드 연결을 생성합니다.
  • Lambda는 각 AWS 계정에서 일련의 관리 상의 제한을 부과합니다. 미리보기 기간 동안 동시 실행 요청을 25개까지 처리 할 수​​ 있습니다.

Lambda 소개
이제 관리 콘솔을 사용하여 간단한 Lambda function을 만드는 과정을 살펴 보겠습니다. 앞서 말한대로 SDKCLI 에서 실행할 수 있습니다.

아래 화면은 콘솔에서 내 전체 Lambda function을 표시하고 있습니다.

이제 “Create a Lambda function”을 클릭합니다. 자세한 내용을 모두 입력합니다.

아래와 같이 자신의 Lambda function에 이름을 붙이고 설명 사항을 추가합니다.

JS 코드를 직접 입력하거나 ZIP 파일을 업로드합니다. 콘솔에서 시작할 수 있도록 샘플 코드를 선택할 수 있습니다.

Lambda function을 실행하거나 실행시 어떤 IAM role을 사용할지 여부를 지정합니다.

메모리 요구 사항 조정과 실행 시간 제한도 설정할 수 있습니다.

Lambda function을 만든 후 콘솔에서 반복 편집 테스트 할 수 있습니다. 왼쪽 창에는 Lambda function에 전달 된 JSON 데이터 샘플이 표시되어 있습니다.

Lambda function이 예상대로 실행 되고 있다면, Amazon S3 event notification 같은 이벤트 소스를 연결할 수 있습니다. Lambda function의 시작을 위해 필요한 권한을 S3에 제공하기 때문에 Invocation role을 지정합니다.

앞에서 이야기한 대로 Lambda는 각 Lambda function마다 통계 정보를 수집하고 이를 Amazon CloudWatch에 보냅니다. 콘솔에서 통계를 볼 수 있습니다.

로드맵
앞으로 Lambda에 대한 로드맵을 가지고 있으며, 오늘 그 모든 것을 말씀 드릴 수는 없지만 새로운 AWS 서비스 이벤트에 추가 지원 및 프로그래밍 언어 지원을 추가 할 예정임을 알려드립니다. 언제나 마찬가지로 우리는 고객의 의견을 매우 소중히 생각하고 있습니다. 꼭 Lambda Forum에 의견을 남겨주세요.

이용 가격 및 가능한 지역

마지막으로 요금에 대해 이야기 해보면, Lambda는 차별화 된 요금 체계로 되어 있습니다. 100밀리 초 단위의 컴퓨팅 시간과 개별 요청에 대해서만 지불이 됩니다. Lambda 무료 이용은 한달 100만 요청과 한달 최대 320만 초 컴퓨팅 처리 시간을 포함합니다. 컴퓨팅 처리 시간은 Lambda function마다 할당된 메모리의 총량에 따라 다릅니다. Lambda는 오늘부터 US East (Northern Virginia), US West (Oregon), 그리고 Europe (Ireland) 지역에 한정 미리보기가 가능합니다.

– Jeff;

이 글은 AWS Lambda – Run Code in the Cloud의 한국어 번역입니다.

저가 T2 인스턴스 출시 – 급격한 트래픽 처리 가능

저의 자동차는 최대 시속 240km까지 속도를 낼 수 있지만 항상 그런 속도로 운전하는 것은 아닙니다. 그러나, 아우토반과 같이 장소에 따라서는 그런 옵션이 있는 것이 좋을 수도 있습니다. 그러나 대부분 경우, 사용 가능한 성능의 일부만 사용 가능합니다.

대부분 컴퓨팅 워크 로드도 이와 비슷한 패턴을 따릅니다. 즉, 평소에는 컴퓨터 파워를 그다지 필요로 하지 않지만 가끔 넉넉하게 컴퓨터 리소스가 필요할 때가 있습니다. 예를 들어, 원격 데스크톱 개발 환경(빌드 서버 포함)이나 트래픽이 적은 웹 사이트와 데이터베이스 서비스를 하는 경우 등이 여기에 해당됩니다.

이러한 경우, 대부분 모든 CPU 코어를 소비할 수 있는 업무를 계속 하면 서버가 중단되게 됩니다. 또한, 이러한 워크로드는 비용을 중시하는 경향도 있습니다. 수백 대, 수천 대의 원격 데스크톱을 배포하거나 환경을 구축하는 기업의 경우 각 배치의 비용을 절감함으로써 전체 비용을 맞추고 있습니다. 트래픽이 적은 웹 사이트 및 테스트 환경에서도 경비를 절감할 수 있으면, 글로벌 환경에서 잠재적인 수익성에 큰 영향을 미칠 수 있습니다.

새로운 T2 인스턴스
오늘 Amazon EC2의 새로운 T2 인스턴스를 출시했습니다. T2 인스턴스는 CPU를 갑자기 써야 하는 환경에서도 이점을 얻을 수 있고, 실행하는 응용 프로그램의 비용을 획기적으로 줄일 수 있습니다. 이 인스턴스는 세 가지 크기 (micro, small, medium)를 사용할 수 있으며, 온 디멘드 요금에서 시간당 $0.013 (매달 $9.50)에서 이용하실 수 있습니다. 두개의 t2.micro 인스턴스 (하나는 Linux에서 다른 하나는 Windows)를 AWS 무료 이용 범위를 통해 무료 사용이 가능합니다.

T2의 인스턴스는 더 많은 컴퓨팅 파워를 필요로 할 때 자동으로 최대 코어까지 확장하는 기능이 결합되어 처리 능력을 보증 하는 프로세서 배분 모델로 구축되어 있습니다. 작은 크기와 비용의 인스턴스를 배포하면서도 CPU의 피크 수요를 처리하기 위한 적절한 컴퓨팅 파워를 가질 수 있습니다.

고객의 워크 로드가 이러한 범주에 해당하는 경우, T2 인스턴스는 매력적인 가격에 필요한 충분한 성능을 제공합니다. CPU 및 메모리 요구 사항에 따라 적절한 크기를 선택하면, 나머지는 T2 인스턴스에서 문제 없이 처리 가능합니다. 많은 응용 프로그램은 기본 성능을 필요하지 않으므로 응용 프로그램이 갑자기 높은 성능을 필요로 할 때, 쓸 수 있는 CPU 크레딧을 계속 충전합니다. 물론 자세한 정보도 이용 가능하므로 그 정보를 바탕으로 필요에 가장 적합한 인스턴스의 종류와 크기를 결정할 수 있습니다.

결론: T2 인스턴스의 등장으로 보다 저렴한 방법으로 작게 시작하고 컴퓨팅 파워에 대한 끊임없이 변화하는 수요에 대응하여, 모든 AWS 서비스를 최대한 활용할 수 있습니다.

스펙은 다음과 같습니다. (요금은 미국 동부 (버지니아 북부)의 온 디맨드 인스턴스입니다.) :

이름 vCPUs 기본 성능 RAM (GiB) 시간당 CPU 크레딧 시간당 요금 요금/월간
t2.micro 1 10 % 1.0 6 $ 0.013 $ 9.50
t2.small 1 20 % 2.0 12 $ 0.026 $ 19.00
t2.medium 2 40 % 4.0 24 $ 0.052 $ 38.00

‘기본 성능’은 인스턴스에 할당된 실제 CPU 싱글 코어 성능 비율을 나타냅니다. 예를 들어, t2.small 인스턴스는 2.5 GHz (터보 모드에서 최대 3.3GHz)의 Intel Xeon 프로세서의 싱글 코어의 20%를 사용할 수 있습니다. t2.medium 는 싱글 코어 성능의 40%를 사용할 수 있습니다. 수요에 따라 두 코어를 사용할 수 있습니다.

‘시간당 CPU 크레딧’은 T2 인스턴스가 한 시간 마다 받는 CPU 크레딧 비율을 보여줍니다. CPU 크레딧은 인스턴스가 CPU를 많이 사용하지 않는 경우 모아지며, 인스턴스가 활성 상태 일 때 소비됩니다. 사용하지 않는 CPU 크레딧은 최대 24시간 저장됩니다.

CPU 크레딧
위의 표와 같이 각 T2 인스턴스는 인스턴스의 크기에 의해 결정되는 비율로 CPU 크레딧을 받습니다. 하나의 크레딧(1 Credit)은 1CPU의 분당 전체 CPU 코어의 성능을 제공합니다.

예를 들어, t2.micro 인스턴스는 1시간마다 6 CPU 크레딧을 지속적으로 받습니다. 이 기능은 CPU 코어의 10%에 해당하는 기준 성능을 제공합니다. 부여 받은 크레딧이 필요하지 않는 경우에는 최대 24 시간까지 CPU 크레딧 잔량에 저장됩니다. 인스턴스가 기본 CPU를 10시간 사용하지 않으면 t2.micro 인스턴스는 거의 1시간 전체 코어 성능을 수행 할 수 있는 충분한 크레딧을 저장할 수 있습니다. (10시간 x 6CPU 크레딧/시간 = 60 CPU 크레딧)

각 리전에서 시간대 별로 업무의 시작과 끝에 CPU 파워를 더 필요로 하는 비즈니스 프로세스가 있다고 가정하면, 이 과정을 T2 인스턴스에 배치하여 기존에 축적 된 CPU 크레딧을 사용하여 신속하고 비용 효율적으로 컴퓨팅 부하를 처리 할 수​​ 있습니다.

다른 예로서 외부 뉴스 기사 링크를 통한 갑작스런 트래픽 유입 등의 영향으로 때때로 예측할 수 없는 트래픽 초과가 일어나는 동적 웹 사이트를 생각해 봅시다. T2 인스턴스에서 이러한 사이트를 호스팅하여 이러한 갑작스런 트래픽을 처리할 수 있는 효과적인 솔루션입니다.

인스턴스가 CPU 크레딧을 모두 사용하게 되면 성능은 서서히 기준 레벨로 돌아갑니다. 이러한 전환 과정은 사용자에게 서서히 좋은 경험을 제공하기 위해 15분 동안 진행됩니다.

크레딧을 사용하지 않는 경우, 기본적으로 저장되는 내용의 하루 분 정도를 모으게 됩니다.:

  • t2.micro – 144 – (6 CPU 분 / 시간 * 24 시간)
  • t2.small – 288 (12 CPU 분 / 시간 * 24 시간)
  • t2.medium – 576 (24 CPU 분 / 시간 * 24 시간)

인스턴스가 이 수준에 도달하면 더 이상 크레딧을 모으지 않습니다. 일반적으로 T2 인스턴스에 적합한 워크로드는 보통 크기의 크레딧을 유지합니다. 계속 크레딧이 쌓여있다면, 더 작은 인스턴스 크기로 옮겨서 비용 절감을 고려하는 것이 좋습니다.

갑작스런 트래픽 또는 필요에 따라 한 번에 모아진 크레딧을 소비할 수 있습니다. 그러나, 인스턴스를 stop/start하거나 예기치 않게 terminate 되는 경우 크레딧이 손실될 수 있습니다. 인스턴스 별로 리포트 되는 2개의 새로운 CloudWatch 메트릭을 살펴보면, 크레딧 축적 여부 및 지불 여부를 추적 할 수 있습니다.:

  • CPUCreditUsage – 시간에 따른 크레딧 지불 추적
  • CPUCreditBalance – 시간에 따른 크레딧 저장 추적

새로 출시된 인스턴스는 전체 코어 속도로 시작할 수 있도록 초기 CPU 크레딧이 할당됩니다. 이 초기 크레딧은 새로운 SSD 기반의 Elastic Block Storage가 제공하는 IOPS의 “부트 버스트”와 결합하여 보다 빠르게 T2 인스턴스를 시작할 수 있게 됩니다.

T2 in Action
제가 개발 과정에서 테스트로 t2.small을 사용해 보도록 하겠습니다 어떻게 CPU 크레딧이 축적되고 소비되는 지를 보여 드릴 것입니다. (이 결과를 공식 벤치마크라고 생각하지 마십시오.)

이제 인스턴스를 시작하고, 100 GB의 General Purpose (SSD) EBS 볼륨을 만들고 포맷해서 마운트하고 ncurses-develgcc 패키지를 설치하고 Kernel.org에서 Linux 커널 소스를 다운로드했습니다 . 그리고 menuconfig 실행하고 모든 기본 값을 사용하고 .config 파일을 저장한 후 커널을 빌드했습니다.:

보시다시피 전체 커널은 23분만에 빌드 되었습니다.점심을 Nosh the Truck에 점심을 사러 갔다 오기에 충분한 시간입니다. 피쉬 앤 칩스를 사서 돌아 오면 빌드가 완료되었습니다. AWS 관리 콘솔을 열고 빌드가 CPU 크레딧에 어떤 영향을 주었는지를 확인하기 위해 CloudWatch 메트릭을 보면 다음과 같습니다.

주황색 라인은 구축 과정을 통해 CPU 크레딧 이용료(1 분 단위)를 보여줍니다. 파란색 라인은 인스턴스의 CPU 크레딧 잔량(1 분 단위)를 보여줍니다. 보시다시피 잔량은 빌드를 시작하기 전에는 상승세였습니다 (인스턴스는 유휴 상태 였다는 것입니다). 빌드 중에 크레딧을 소비하고 있으며, 완전히 빌드가 끝난 직후에도 충분한 크레딧이 남아 있으며, 그 숫자가 15 이하는 되지 않았습니다. 빌드가 완료된 후에는 크레딧을 다시 모으기 시작하여, 1시간 이내에 16부터 25까지 상승했습니다.

빌드 중인 CPU 부하 CloudWatch 메트릭은 여기서 보실 수 있습니다 :

장기적으로 CPU 크레딧을 더 소비하도록 여러번 커널 빌드를 실행했습니다. (동시에 3개의 각 소스 트리의 여러 복사본에 대해 make -j 2를 실행했습니다. 보시다시피 충분한 성능을 보여줍니다 :

결론
개인적인 실험을 해 본 결과, T2는 매우 다양한 유즈케이스에 적합하다고 확신할 수 있었습니다. 여러분의 피드백을 기다리겠습니다!

비교가 반드시 정확한 것은 아니지만, 다음과 같이 이전 세대의 EC2 인스턴스를 T2 인스턴스로 대체하는 것이 좋을 것 같습니다.

  • t1.microt2.micro로 변경
  • m1.smallt2.small로 변경
  • m1.mediumt2.medium로 변경

이전 세대의 인스턴스를 같은 T2 인스턴스에 변경하면 지금까지 요금의 절반 비용으로 극적으로 좋은 성과를 얻을 수 있습니다. 변경 하는 경우, T2 인스턴스는 로컬 (인스턴스) 스토리지를 가지고 있지 않기 때문에, 하나 이상의 EBS 볼륨을 사용할 필요가 있다는 점에 유의하십시오.

T2 인스턴스는 기본이 되는 CPU에서 최상의 성능을 얻기 위해 Hardware Virtualization (HVM)를 사용하고 있기 때문에 HVM AMI를 사용해야 합니다.

가용성 및 요금
T2 인스턴스는 오늘부터 다음 AWS 지역에서 이용 가능하며, 바로 사용해 보실 수 있습니다 :

  • 미국 동부 (버지니아 북부)
  • 미국 서부 (오레곤)
  • EU (아일랜드)
  • 아시아 태평양 (싱가포르)
  • 아시아 태평양 (도쿄)
  • 아시아 태평양 (시드니)
  • 남미 (상파울루)

T2 인스턴스는 미국 서부 (캘리포니아 북부), 중국 (베이징), AWS GovCoud (미국)도 조만간 출시 예정입니다.

가격은 미국 동부 (버지니아 북부) 지역에서 주문형 t2.micro 인스턴스가 시간당 $0.013에서 이용하실 수 있습니다. T2 인스턴스를 사용하면 정말 매력적인 가격으로 작게 시작해서 필요에 따라 확장하고 모든 AWS 서비스를 사용할 수 있습니다! 자세한 정보는 EC2 요금 페이지를 참조하십시오.

Jeff ;

이 글은 New Low Cost EC2 Instances with Burstable Performance의 한국어 번역입니다.