기고 | AWS 람다를 최대로 이용하는 법

InfoWorld
클라우드 네이티브 애플리케이션 및 서비스를 구현하기 위한 여러 옵션이 있다. 서로 다른 플랫폼에서 많은 수의 애플리케이션과 서비스를 개발하고 다양한 컴플라이언스 요구사항을 가진 조직은 컨테이너와 CaaS를 고려할 가능성이 높다. 단순한 운영 경로를 찾는 개발 스택과 운영상의 제약이 거의 없는 다른 조직에서는 구성 및 기술상 전문 지식이 덜 필요하기 때문에 PaaS 옵션을 선택하는 경우가 많다.

그다음, 기본 인프라 설정과 구성을 추상화하고 코드를 배치하고 실행할 수 있는 간단한 메커니즘을 제공하는 FaaS, 즉 서비스로서의 기능(Functions as a Service)이 있다. 기능은 이벤트에 대응하여 코드를 실행하는 데 이상적으로 적합하며, 경량 마이크로서비스를 위한 인프라로 사용될 수 있다.
 
ⓒAWS

PaaS, CaaS, FaaS를 살펴본 이전 기사에서 필자는 클라우드 아키텍처를 선택할 때 고려해야 할 몇 가지 사항에 대해 아키텍트와 클라우드 전문가의 가이드라인을 공유했다. 이번 기사에서는 서버리스 기능을 사용하기 위한 보다 구체적인 요구 사항을 공유하고 몇 가지 사용 사례를 제시하겠다.

여기서 필자는 AWS 람다에 초점을 맞추고 있지만, 마이크로소프트 애저 펑션, 구글 클라우드 펑션, IBM 클라우드 펑션, 오라클 펑션 및 기타 FaaS 플랫폼을 사용하는 데에도 동일한 일반 원칙이 적용될 것이다.

AWS 람다 함수에 관한 기술 요건 
AWS 람다는 퍼블릭 클라우드에 서버리스 기능을 배치하기 위한 한 가지 옵션이다. 이러한 서비스를 구현하기 전에 주요 기술 요건을 고려하는 것이 중요하다.

AMS 람다 함수는 자바, 고(Go), 파워셸, 노드.js(Node.js), C#, 파이썬, 루비에서 개발할 수 있다. AWS는 아마존 API 게이트웨이를 통해 API 호출로 트리거 된 가장 간단한 함수들로 람다 함수를 트리거 할 수 있는 이벤트 리스트를 갖고 있다. 이벤트는 또한 코드 커밋, CI/CD 파이프라인, 키네시스 데이터 스트림, 클라우드 시스템 모니터, IoT 이벤트에 의해서도 트리거 될 수 있다. 클라우드왓치 이벤트를 사용하여 함수 실행을 예약할 수도 있다. 함수는 트리거 유형에 따라 동기식 또는 비동기식으로 작동한다.

AWS 람다 함수는 실행당 최대 15분까지 구동할 수 있다. 3GB의 메모리와 500MB까지 비영구 디스크에서 접근할 수 있도록 구성될 수 있다. 람다 함수는 스테이트리스 이어야 하고 인바운드 TCP/IP 연결은 제한되지만 환경 변수를 사용하여 스레드나 프로세스를 만들 수 있다. AWS 람다 FAQ에서 기술 성능과 제한에 관해 좀더 자세하게 알아볼 수 있다.

개발자는 AWS 서버리스 애플리케이션 모델을 갖춘 서버리스 애플리케이션뿐 아니라 개별 함수를 구성할 수 있다. 이것은 개발자가 애플리케이션으로 일괄적으로 운영되는 서비스 그룹을 간편하게 묶어서 배치하고 관리할 수 있게 해주는 옵션이다.

서버리스 함수와 서버리스 애플리케이션은 비용을 줄인다
필자는 노련한 클라우드 솔루션 아키텍트인 히테시 치탈리아와 AWS 람다를 사용하여 마이크로서비스 및 애플리케이션을 신속하게 개발하고 쉽게 지원하는 방법을 논의했다.

치탈리아는 “마이크로서비스나 간단한 운영유지 업무를 지원할 때 인프라에 대한 집중을 줄이기 때문에 필자는 람다를 사용하는 것을 좋아한다. 단계적 함수를 통해 배치(batch) 작업을 조정하고 ETL을 실행하며 완전한 기능을 갖춘 웹 애플리케이션을 실행할 수 있을 정도로 이제는 성숙해졌다”라고 답했다.

치탈리아는 전용 아마존 EC2 서버에서 서버리스 함수와 애플리케이션으로 애플리케이션을 마이그레이션함으로써 비용 절감에 성공했다. 특히 사용 패턴이 간헐적인 애플리케이션과 서비스의 경우 비용 절감이 상당할 수 있다.

치탈리아는 구체적인 사례를 공유했다.

FaaS의 비용 구조도 매력적인 옵션으로 꼽힌다. 인프라 오버헤드 감소와 함께 그것의 사용량별 지불 방식은 기업이 제품 활용에 근거하여 비용을 면밀히 추적할 수 있게 한다. 기본적인 예는 이전 회사의 API가 2개의 소규모 EC2 인스턴스에서 람다로 마이그레이션되어 90%의 비용이 절감된 것이다. 사용량이 증가함에 따라 람다는 늘어난 사용량을 지원하기 위해 자동으로 확장된다. 통화량이 약 6배 증가하면서 이에 따라 람다 서비스 비용이 2배 증가했다.

치탈리아는 개발 고려사항의 일부도 공유했다. 그는 “FaaS는 더 작고 더 짧은 실행 함수가 효과적이어야 하기 때문에 코드를 다시 작성해 장점을 활용해야 할 것이다. 한동안 유휴 상태에 있던 함수에 대한 첫 번째 호출이 반응하는 데 몇 초가 걸릴 수 있는 콜드 스타트 문제도 있다”라고 말했다.

서버리스 함수와 서버리스 애플리케이션의 예시
개발자들이 서버리스 함수와 애플리케이션을 어떻게 사용하는지 더 잘 이해하기 위해, 필자는 아마존의 서버리스 애플리케이션 디렉토리 및 다른 소스들을 살펴 몇 가지 일반적인 사용 사례를 확인했다. 이것들은 코딩 예시 역할을 할 수 있고 쉬운 첫 번째 프로젝트가 있는 영역을 보여준다.

● ‘방법’ 함수는 종종 2개 이상의 다른 아마존 또는 다른 외부 웹 서비스를 연결하는 방법을 보여준다. 파이썬과 노드.js는 이러한 예에서 가장 많이 사용되는 2가지 개발 언어다. 몇몇 예시들은 S3, 다이나모DB, API 게이트웨이, SNS 및 클라우드프론트를 연결한다. 
● 알렉사 API에 연결되는 알렉사 스킬 카트리지와 다른 예들은 디렉토리에서 가장 자주 다운로드되는 서비스들이다.
● 시스템 관리자는 서버리스 함수를 사용하여 로그 파일을 처리하고, S3 버킷의 파일을 압축하며, 웹 서비스를 모니터하고, 웹 서버 리디렉션을 처리한다.
● 이미지와 다른 미디어 파일들을 조작하는 것은 웹 애플리케이션에서 일반적인 필요 사항이다. 몇 가지 예들은 이미지매직과 다른 이미지 및 미디어 유틸리티를 사용하여 파일 형식을 변환하고 이미지 크기를 조정하고 갤러리를 만들고 이미지 파일을 압축한다.
● 슬랙, 엘라스틱서치, 스모 로직, 셀레니움을 비롯하여 SaaS 애플리케이션, 벤더 API 및 기타 서비스 등에 접속하는 여러 예들이 있다.
● 디렉토리에는 데이터 처리와 머신러닝 서비스도 만연해 있다. 아마존 키네시스를 입출력 데이터 스트림에 연결한 사례와 음성 및 자연어 처리에 아마존 렉스를 사용한 사례 등이 있다. 데이터 과학자들은 텐서플로우와 시키트-런을 위한 서비스도 찾을 것이다.
● 데브옵스의 예로는 개발을 트리거 하거나 이벤트 정보를 캡처하여 다른 툴에 푸시하기 위한 CI/CD 파이프라인과의 통합을 들 수 있다.

현재 서버리스 함수와 애플리케이션의 디렉토리가 부족하지만, 다른 곳에서 검토할 수 있는 좋은 예가 많다. 당신은 전체 서버리스 청구서 애플리케이션을 검토할 수도 있고, 자바스크립트 함수를 시작하기 위한 가이드를 이해할 수도 있거나 이러한 파이썬 예시, 가이드, 퀵스타트를 확인할 수도 있다.

서버리스 컴퓨팅의 약속
서버리스 컴퓨팅은 기술적 한계나 컴플라이언스와 보안 제약의 혼합으로 사용 사례가 틈새 분야로 한정된다는 학파가 있다. 서버리스 함수는 클라우드 제공업체에게 인프라 설정, 구성, 관리 및 제어 권한을 넘겨주는 컨테이너에서 호스팅 된다. 규제 대상 기업의 경우 퍼블릭 클라우드에서 실행되는 서버리스 기능은 선택사항이 아닐 수 있다.

컨테이너를 사용하거나 PaaS와 함께 대규모 애플리케이션과 서비스를 설정해야 하는 다른 조직들은 함수를 위한 별도의 호스팅 서비스를 갖는 것의 이점에 대해 논의할 수도 있다. 이러한 그룹의 경우, 인프라를 코드로 사용하고 최적으로 선택된 인프라에 직접 함수를 배치하는 것이 그만큼 쉬울 수 있다.

그러나 기업 소프트웨어 개발의 주류에 서버리스 함수를 두는 또 다른 학파가 있다. 첫째로, 개발자들은 인프라를 계획하고 구현하는 단계 없이 함수를 배치하는 단순함에 대해 흥분할 것이다. 최소한 서버리스 함수는 개발 단계에서 사용될 수 있으며 필요할 때만 PaaS 또는 컨테이너 옵션으로 포팅될 수 있다.

둘째로, 개발자들은 소프트웨어 라이브러리 선택과 코드 재사용을 크게 단순화할 수 있는 서버리스 함수의 가능성에 대해 흥분할 것이다. 개발자들은 종종 그들의 애플리케이션에서 활용될 수 있는 코드 라이브러리, 개발 키트 및 기타 코드 샘플을 위해 깃허브와 다른 개방 저장소를 조사한다. 일단 구성요소가 발견되고, 그 기능에 대해 테스트되고, 성능 고려사항을 검토하고, 보안 문제에 대해 검증되면, 개발자는 코드를 그들의 애플리케이션에 통합하는 과제를 떠맡게 된다.

통합은 코딩 플랫폼, 애플리케이션 아키텍처, 개발 최적화에 대한 철학, 배치 고려사항에 따라 몇 가지 다른 방법으로 수행될 수 있다.

그러나 이러한 코드 라이브러리를 서버리스 함수로 배치할 수 있을 때 개발자는 자신의 기능을 활용하기 위해 훨씬 적은 작업을 수행해야 한다. 또한 이 옵션은 시스템 엔지니어가 소비 및 처리 요구사항에 따라 서비스의 규모를 정하고 확장할 수 있도록 한다. 이것은 마이크로서비스 약속의 일부분이다.

서버리스 함수를 바탕으로 미래를 생각하는 것은 흥미롭다. 개발자들은 깃허브에서 코드 샘플을 검색하는 대신 서버리스 함수의 디렉토리를 검색할 것이다. 많은 개발팀을 보유한 조직은 용도 변경 가능한 서버리스 함수 및 기타 마이크로서비스의 내부 디렉터리를 생성할 수도 있다.

클라우드 제공업체가 인프라 및 구축 옵션을 계속 단순화함에 따라 서버리스 컴퓨팅 제품을 통해 개발자가 함수의 용도를 변경하고, 기능을 더 빠르게 구현하며, 클라우드 운영을 통해 비용을 최적화할 수 있는 새로운 방법을 개발할 수 있을 것으로 예상할 수 있다.

* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr