소개
이미 많은 기업이 퍼블릭 클라우드에서 애플리케이션을 실행함으로써 비용을 절감하고 온디맨드 IT 리소스 사용을 통해 민첩성을 개선하는 등 이점을 얻고 있다. 애플리케이션 유형과 산업에 걸친 여러 연구에서 기존 애플리케이션 아키텍처를 클라우드로 마이그레이션하면 총 소유 비용(TCO)이 절감되고 출시 시간이 단축된다는 사실이 입증되었다.
사내 및 프라이빗 클라우드 솔루션에 비해 퍼블릭 클라우드는 서버 및 서버에서 실행되는 애플리케이션을 구축, 배포 및 관리하는 작업을 훨씬 단순화한다. 그러나 오늘날 기업들은 퍼블릭 클라우드를 활용하기 위해 기존의 서버 또는 VM 기반 아키텍처를 뛰어넘는 추가 옵션을 가지고 있다. 클라우드는 기업이 자체 하드웨어를 구입하고 유지 관리할 필요가 없으나, 서버 기반 아키텍처는 여전히 확장성과 안정성을 위한 설계를 해야 한다. 또한, 기업은 애플리케이션이 발전함에 따라 이러한 서버 제품군에 패치를 적용하고 배포해야 하는 과제를 소유해야 한다. 더욱이, 그들은 최대 부하를 감안하여 그들의 서버 플렛을 확장한 다음, 비용을 낮추기 위해 가능한 한 언제 어디에서 스케일 다운을 시도해야 한다. 이 모든 것은 최종 사용자의 경험과 내부 시스템의 무결성을 보호해야 한다. 유휴, 활용도가 낮은 서버는 비용이 많이 들고 낭비가 심하다. 분석가들은 실제로 서버의 85%가 용량을 과소평가했다고 추정한다.
AWS Lambda와 같은 서버리스 컴퓨팅 서비스는 기업들이 애플리케이션 설계에 접근하는 다른 방법을 제공함으로써 이러한 과제를 해결하도록 설계되었으며, 애플리케이션 설계는 기본적으로 비용이 절감되고 출시 시간이 단축된다. AWS 람다는 모든 기술 스택 수준에서 서버를 처리하는 복잡성을 없애고, 유휴 컴퓨팅 용량에서 더 이상 비용이 발생하지 않는 요청별 요금 청구 모델을 도입한다. 또한 람다 함수는 조직이 마이크로 서비스 아키텍처를 쉽게 채택할 수 있도록 한다. 인프라를 제거하고 람다 모델로 전환하면 다음과 같은 이중 경제적 이점을 얻을 수 있다.
- 유휴 서버와 같은 문제들을 경제적인 결과와 함께 쉽게 없앨 수 있다. AWS Lambda와 같은 서버리스 컴퓨팅 서비스는 유용한 작업이 수행될 때만 요금이 부과되기 때문에 결코 "콜드" 상태가 아니다.
- 플릿 관리(서버의 보안 패치, 배포 및 모니터링 포함)는 더 이상 필요하지 않다. 즉, 24x7 서버 플릿 가동 시간을 지원하는 데 필요한 관련 툴, 프로세스 및 당직 순환을 유지할 필요가 없다는 것이다. 마이크로 서비스를 구축하기 위해 람다를 사용하는 것은 조직이 보다 민첩하게 대처할 수 있도록 돕는다. 서버 관리에 대한 부담 없이 기업은 부족한 IT 리소스를 중요한 것, 즉 비즈니스에 집중할 수 있다.
인프라 비용을 크게 절감하고, 보다 민첩하고 집중적인 팀과 출시 시간을 단축함으로써, 이미 서버리스 접근 방식을 채택한 기업들이 경쟁업체보다 중요한 우위를 점하고 있다.
서버리스 애플리케이션 이해
위에서 인용한 서버리스 접근방식의 장점은 매력적이지만, 실제 구현을 위한 고려사항은 무엇인가? 서버리스 앱과 기존 서버 기반 앱을 구분하는 것은?
서버리스 애플리케이션은 개발자들이 자신의 핵심 역량에 집중하여 실제 비즈니스 로직을 작성할 수 있도록 설계된다. 웹서버 등 앱의 보일러플레이트 부품 다수와 신뢰성, 스케일링 처리 소프트웨어 등 차별화되지 않은 무거운 리프팅은 모두 개발자로부터 완전히 추상화된다. 남은 것은 메시지를 보내는 모바일 사용자, 클라우드에 업로드된 이미지, 스트림에서 도착하는 기록 등 필요한 경우에만 비즈니스 로직이 촉발되는 깨끗하고 기능적인 접근법이다. 애플리케이션 설계에 대한 비동기식 이벤트 기반 접근법은 필요하지는 않지만 서버리스 애플리케이션에서 매우 일반적이다. 왜냐하면 그것은 해야 할 일이 있을 때만 실행되는 코드(그리고 비용이 발생함)의 개념과 완벽하게 부합하기 때문이다.
AWS 람다 등의 서비스에서 서버리스 애플리케이션이 퍼블릭 클라우드에서 실행되는데, 이 서비스는 이벤트나 클라이언트 호출 수신을 담당한 다음 코드를 인스턴스화하여 실행한다. 이 모델은 기존의 서버 기반 애플리케이션 설계에 비해 다음과 같은 많은 이점을 제공한다.
- 서버를 프로비저닝, 배포, 업데이트, 모니터링 또는 다른 방법으로 관리할 필요가 없다. 실제 하드웨어 및 서버 소프트웨어는 모두 클라우드 제공자가 처리한다.
- 애플리케이션의 실제 사용에 따라 크기가 자동으로 조정됨. 이는 최대 부하에 맞춰 확장하기 위해 리시버 플릿과 명시적 용량 관리가 필요한 기존 애플리케이션과는 본질적으로 다르다.
- 확장 외에도 가용성 및 내결함성이 내장되어 있다. 이러한 기능의 이점을 얻기 위해 코딩, 구성 또는 관리가 필요하지 않다.
- 유휴 용량에 대한 요금 없이 없다. 용량을 사전 프로비저닝하거나 초과 프로비저닝할 필요(사실상 능력 없음)가 없다. 대신, 청구는 요청당 지불이며 코드를 실행하는 데 걸리는 기간을 기준으로 한다.
서버리스 애플리케이션 사용 사례
서버리스 애플리케이션 모델은 일반적이며, 스타트업의 웹 앱에서 포춘 100대 기업의 주식 거래 분석 플랫폼에 이르기까지 거의 모든 유형의 애플리케이션에 적용된다. 여기 몇 가지 예가 있다.
- 웹 앱 및 웹 사이트 – 서버를 제거하면 트래픽이 없을 때 거의 비용이 들지 않는 웹 앱을 만들 수 있으며, 동시에 최대 부하, 예기치 않은 부하를 처리할 수 있도록 확장할 수 있다.
- 모바일 백엔드 – 서버리스 모바일 백엔드는 클라이언트 개발에 집중하는 개발자들이 분산 시스템 설계 전문가가 되지 않고도 안전하고, 가용성이 높고, 완벽하게 확장 가능한 백엔드를 쉽게 만들 수 있는 방법을 제공한다.
- 미디어 및 로그 처리 – 서버리스 접근 방식은 다중 스레드 시스템을 구축하거나 컴퓨팅 플렛을 수동으로 확장하는 복잡성 없이 컴퓨팅 집약적인 워크로드를 보다 간편하게 처리할 수 있는 자연스러운 병렬화 기능을 제공한다.
- IT 자동화 – 서버리스 기능을 알람 및 모니터에 부착하여 필요에 따라 맞춤화할 수 있음. 크론 작업 및 기타 IT 인프라 요구사항은 특히 이러한 작업과 요구사항이 드물거나 본질적으로 가변적인 경우, 서버를 사용하고 유지관리해야 하는 요구사항을 제거함으로써 구현이 상당히 더 간단해진다.
- IoT 백엔드 – 네이티브 라이브러리를 포함한 모든 코드를 가져올 수 있는 기능으로 기기별 알고리즘을 구현할 수 있는 클라우드 기반 시스템 생성 프로세스가 단순화된다.
- Chatbots(음성 지원 보조기 포함) 및 기타 웹 후크 기반 시스템 – 서버리스 접근법은 챗봇과 같은 웹 후크 기반 시스템에 완벽하게 적합하다. 필요한 경우에만(예: 사용자가 챗봇에 정보를 요청할 때) 작업을 수행할 수 있는 능력은 이러한 아키텍처에 대해 간단하고 일반적으로 더 저렴한 접근방식을 만들어 준다. 예를 들어, Amazon Echo에 대한 Alexa Skills의 대다수는 AWS 람다를 사용하여 구현된다.
- 클릭 스트림 및 기타 실시간에 가까운 스트리밍 데이터 프로세스
– 서버리스 솔루션은 데이터 흐름에 따라 확장 및 축소할 수 있는 유연성을 제공하므로 각 애플리케이션에 대해 확장 가능한 컴퓨팅 시스템을 구축하는 복잡성 없이 처리량 요구 사항에 맞출 수 있다. AWS 람다는 Amazon Kinesis 같은 기술과 결합하면 클릭스트림 분석, NoSQL 데이터 트리거, 주식 거래 정보 등을 위한 레코드의 고속 처리를 제공할 수 있다.
앞서 논의한 고도로 채택된 사용 사례 외에도, 기업은 다음과 같은 도메인에 대해 서버리스 접근법을 적용하고 있다.
- 빅데이터, 지도 축소 문제, 고속 영상 트랜스코딩, 주식 거래 분석, 대출 애플리케이션용 컴퓨팅 집약적인 몬테카를로 시뮬레이션 등. 개발자들은 특히 이벤트를 통해 트리거되는 경우 서버리스 접근방식과 병렬화하는 것이 훨씬 쉽다는 것을 발견했으며, 이로 인해 인프라 관리 없이 광범위한 빅데이터 문제에 서버리스 기술을 점점 더 많이 적용할 수 있게 되었다.
- 짧은 대기 시간, 콘텐츠 제공 네트워크를 통해 제공되는 웹 애플리케이션 및 자산에 대한 . 사용자 지정 처리 인터넷 가장자리로 서버리스 이벤트를 이동시킴으로써 개발자들은 더 낮은 지연 시간을 활용할 수 있고, 검색과 콘텐츠 가져오기를 쉽게 사용자 정의할 수 있다. 이를 통해 고객의 위치에 따라 지연 시간에 최적화되는 새로운 범위의 사용 사례가 가능하다.
- 연결된 장치, AWS 람다 함수와 같은 서버리스 기능을 상업용, 주거용 및 휴대용 사물인터넷(IoT) 장치 내부에서 실행할 수 있도록 한다. 람다 함수와 같은 서버리스 솔루션은 기본 물리적(및 가상적) 하드웨어에서 자연스러운 추상화를 제공하여 프로그래밍 모델을 중단하지 않고 데이터 센터에서 가장자리로, 하드웨어 아키텍처 간에 보다 쉽게 전환할 수 있다.
- AWS Snowball Edge와 같은 사내 어플라이언스의 사용자 로직 및 데이터 처리. 비즈니스 로직을 실행 환경의 세부사항과 분리하기 때문에 서버리스 애플리케이션은 어플라이언스를 포함한 다양한 환경에서 쉽게 작동할 수 있다.
일반적으로 서버리스 애플리케이션은 애플리케이션이 별개의 작업을 수행하는 독립적 구성요소로 분리되는 마이크로 서비스 아키텍처를 사용하여 구축된다. API, 메시지 큐, 데이터베이스 및 기타 구성요소와 함께 개별 람다 함수로 구성된 이러한 구성요소는 독립적으로 배포, 테스트 및 확장할 수 있다. 사실 서버리스 애플리케이션은 기능 기반 모델 때문에 마이크로 서비스에 자연스럽게 적합하다. 획일적인 설계와 아키텍처를 피함으로써, 개발자들은 점진적으로 배포하고 필요할 경우 데이터베이스 계층과 같은 개별 구성요소를 교체하거나 업그레이드할 수 있기 때문에 조직은 더욱 민첩해질 수 있다.
많은 경우에, 단순히 애플리케이션의 비즈니스 로직를 분리하는 것이 그것을 서버리스 앱으로 변환하는데 필요한 전부다. AWS 람다와 같은 서비스는 인기 있는 프로그래밍 언어를 지원하고 사용자 지정 라이브러리를 사용할 수 있도록 한다. 장시간 실행되는 작업은 합리적인 시간 내에 작동하는 개별 기능으로 구성된 워크플로우로 표현되며, 시스템이 필요에 따라 개별 연산 단위를 재시작하거나 병렬화할 수 있다.
서버리스가 항상 적합한가?
거의 모든 최신 애플리케이션은 성공적으로 실행되도록 수정될 수 있으며, 대부분의 경우 서버리스 플랫폼에서 보다 경제적이고 확장 가능한 방식으로 수정될 수 있다.
그러나 서버리스 것이 최선의 선택이 아닌 경우가 몇 가지 있다.
- 애플리케이션을 변경하지 않는 것이 목표일 때.
- 특정 운영 체제 패치를 지정하거나 낮은 수준의 네트워킹 작업에 액세스하는 등 환경에 대한 세밀한 제어가 필요한 경우
- 사내 애플리케이션이 퍼블릭 클라우드로 마이그레이션되지 않은 경우
클라우드 공급업체의 서버리스 플랫폼 평가
서버리스 애플리케이션을 설계할 때, 회사와 조직은 앱의 코드를 실행하는 서버리스 컴퓨팅 기능 이상을 고려할 필요가 있다. 완벽한 서버리스 애플리케이션에는 스토리지, 메시징, 진단 등을 포괄하는 광범위한 서비스, 툴 및 기능이 필요하다. 클라우드 공급업체에서 제공하는 불완전하거나 단편화된 서버리스 포트폴리오가 일관된 추상화 수준에서 성공적으로 코드화할 수 없는 경우 서버 기반 아키텍처로 돌아가야 하는 서버리스 개발자에게 문제가 될 수 있다.
서버리스 플랫폼은 컴퓨팅 및 스토리지 구성요소와 같은 서버리스 앱을 구성하는 서비스 집합과 서버리스 앱을 작성, 구축, 배포 및 진단하는 데 필요한 도구로 구성된다. 서버리스 애플리케이션을 프로덕션에서 실행하려면 소규모 스타트업 부터 글로벌 기업에 대한 요구를 처리할 수 있는 신뢰할 수 있고 유연하며 신뢰할 수 있는 플랫폼이 필요하다. 플랫폼은 애플리케이션의 모든 요소를 확장하고 엔드 투 엔드 신뢰성을 제공해야 한다. 기존의 앱과 마찬가지로 개발자들이 서버리스 솔루션을 만들고 제공하는 데 성공하도록 돕는 것은 다차원적인 도전이다. 다양한 산업에 걸쳐 대규모 기업의 요구를 충족시키기 위해, 서버리스 플랫폼은 다음 그림의 기능을 제공해야 한다.
- 확장 가능하고 안정적인 고성능 클라우드 로직 계층
- 제1자 이벤트 및 데이터 소스에 대응하고 제3자 시스템에 대한 간단한 연결
- 개발자가 쉽게 시작하고, 새로운 패턴을 기존 솔루션에 빠르고 안전하게 추가할 수 있는 통합 라이브러리
- 개발자가 다양한 도메인에서 솔루션을 발견하고 적용할 수 있도록 지원하는 활기찬 개발자 에코시스템 및 다양한 타사 시스템 및 사용 사례.
- 목적에 맞는 애플리케이션 모델링 프레임워크 모음입니다.
- 오케스트레이션 오퍼링 상태 및 워크플로우 관리
- 보증 프로그램 인증을 포함하는 글로벌 규모 및 광범위한 범위
- 어떤 규모의 용량도 프로비저닝할 필요 없이 내장된 신뢰성 및 규모에 맞는 성능 제공
- 기본 제공 보안 및 제1자 및 제3자 리소스 및 서비스에 대한 유연한 액세스 제어
서버리스 플랫폼의 핵심은 비즈니스 로직을 대표하는 기능을 실행하는 클라우드 로직 계층이다. 이러한 기능은 종종 이벤트에 대응하여 실행되기 때문에, 솔루션을 쉽게 표현하고 다양한 워크로드에 대응하여 자동으로 확장할 수 있도록 하기 위해서는 제1자 및 제3자 이벤트 소스와의 단순한 통합이 필수적이다. 예를 들어, 서버리스 기능은 오브젝트 저장소에 오브젝트가 작성될 때마다 또는 서버리스 NoSQL 데이터베이스에 작성된 각 업데이트에 대해 실행해야 할 수 있다.
서버리스 아키텍처는 이러한 시스템을 통합하는 데 일반적으로 필요한 모든 확장 및 관리 코드를 제거하여 운영 부담을 클라우드 공급업체로 이동시킨다.
서버리스 플랫폼에서 성공적으로 개발하려면 기업이 제1자 또는 제3자 서비스를 포함하든 공통의 사용 사례를 위한 기성 템플릿을 찾는 등 쉽게 시작할 수 있어야 한다. 이러한 통합 라이브러리는 기록의 스트림 처리나 웹 후크 구현과 같은 성공적인 패턴을 전달하기 위해 필수적이며, 특히 개발자들이 서버 기반 구조에서 서버리스 아키텍처로 마이그레이션하는 기간 동안에 그러하다. 핵심 플랫폼을 둘러싼 광범위하고 다양한 생태계가 밀접하게 연관되어 있다. 크고 활기찬 생태계는 개발자들이 지역사회의 솔루션을 쉽게 발견하고 사용할 수 있도록 도와주고 새로운 아이디어와 접근법을 쉽게 기여하도록 해준다. 애플리케이션 라이프사이클 관리에 사용되는 다양한 툴 체인을 고려할 때, 모든 언어, IDE 및 엔터프라이즈 빌드 기술이 서버리스 애플리케이션의 구축 및 배포를 기존 접근 방식에 통합하는 데 필요한 런타임, 플러그인 및 오픈 소스 솔루션을 갖도록 하기 위한 건강한 생태계도 필요하다. 서버리스 앱이 익스프레스와 플라스크와 같은 프레임워크에 대한 개발자의 지식과 인기 있는 프로그래밍 언어를 포함한 기존 투자를 활용하는 것도 중요하다. 넓은 생태계는 도메인 전체에 걸쳐 중요한 가속을 제공하며 개발자가 서버리스 아키텍처에서 기존 코드를 보다 쉽게 용도 변경할 수 있도록 한다.
개방형 규격 AWS SAM과 같은 애플리케이션 모델링 프레임워크는 개발자가 서버리스 앱을 구성하는 구성요소를 표현하고, 이러한 애플리케이션을 구축, 배포 및 모니터링하는 데 필요한 툴과 워크플로우를 가능하게 한다. 서버리스 플랫폼의 성공에 중요한 또 다른 프레임워크는 조정과 국가 관리다. 서버리스 컴퓨팅의 대부분 상태 비저장 특성은 장기간 실행되는 워크플로우를 활성화하기 위한 보완 메커니즘을 필요로 한다. 조정 솔루션은 개발자들이 서버리스 애플리케이션에서 일반적인 여러 관련 애플리케이션 구성요소를 조정할 수 있도록 하는 동시에, 그러한 애플리케이션은 소수와 단명 함수로 구성될 수 있도록 한다. 또한 조정 서비스는 오류 처리를 단순화하고 기존 시스템 및 워크플로우와의 통합을 제공하며, 여기에는 일반적으로 서버리스 기능 자체가 허용하는 것보다 오래 실행되는 시스템 및 워크플로우가 포함된다.
글로벌 진출 다국적 기업을 포함한 전 세계 고객을 지원하기 위해 서버리스 플랫폼은 전 세계에 위치한 데이터 센터와 에지 로케이션 등 글로벌 규모를 제공해야 한다. 에지 위치는 대기 시간이 짧은 서버리스 컴퓨팅을 최종 사용자에게 가까이 제공하는 핵심 요소다. 애플리케이션 개발자가 아닌 플랫폼이 서버리스 애플리케이션의 확장성과 고가용성을 제공하는 역할을 하기 때문에 그 본질적인 신뢰성이 매우 중요하다.
내장된 재시도 및 처리되지 않은 이벤트의 데드 문자 대기열과 같은 기능은 개발자들이 서버리스 접근방식을 사용하여 엔드 투 엔드 신뢰성을 갖춘 강력한 시스템을 구축할 수 있도록 돕는다. 서버리스 앱에서 언어 런타임과 고객 코드가 요청 시 인스턴스화된다는 점을 감안할 때 성능도 마찬가지로 중요하며, 특히 지연 시간이 짧다(오버헤드).
마지막으로, 플랫폼은 가상 사설망 지원, 역할 기반 및 액세스 기반 권한 지원, API 기반 인증 및 액세스 제어 메커니즘(제3자 및 레거시 시스템 포함), 환경 변수 설정과 같은 애플리케이션 요소 암호화 지원 등 광범위한 보안 및 액세스 제어 기능을 갖추어야 한다.
서버리스 시스템은 설계상 다음과 같은 이유로 본질적으로 더 높은 수준의 보안과 제어를 제공한다.
- 보안 패치를 포함한 1급 플릿 관리 – AWS Lambda와 같은 시스템에서는 요청을 실행하는 서버를 지속적으로 모니터링하고 사이클링하며 보안을 검사한다. 패치 및 업데이트에 대한 SLA를 훨씬 느슨하게 할 수 있는 많은 엔터프라이즈 컴퓨팅 플렛과 달리 주요 보안 업데이트 가용성의 몇 시간 내에 패치를 적용할 수 있다.
- 서버 수명 제한 – AWS Lambda에서 고객 코드를 실행하는 모든 기계는 매일 여러 번 사이클링하여 공격에 대한 노출을 제한하고 지속적으로 최신 운영 체제와 보안 패치를 보장한다.
- 요청별 인증, 액세스 제어 및 감사 – AWS Lambda에서 실행되는 모든 컴퓨팅 요청은 소스에 관계없이 개별적으로 인증되고 지정된 리소스에 액세스할 수 있는 권한이 부여되며 완전히 감사된다. Amazon API Gateway를 통해 AWS 데이터 센터 외부에서 들어오는 요청은 DoS 공격 방어 등 인터넷 대면 방어 시스템을 추가로 제공한다. 서버리스 아키텍처로 마이그레이션하는 기업은 AWS CloudTrail을 사용하여 어떤 사용자가 어떤 시스템에 어떤 권한을 가지고 액세스하고 있는지 자세히 파악할 수 있으며, AWS Lambda를 사용하여 감사 기록을 프로그래밍 방식으로 처리할 수 있다.
AWS Serverless 플랫폼
AWS는 2014년 람다 도입 이후 완벽한 서버리스 플랫폼을 만들었다. 이것은 조직이 다른 AWS 서비스 및 타사 서비스와 완벽하게 통합할 수 있는 서버리스 앱을 만들 수 있도록 지원하는 완전 관리형 서비스 모음이다. 그림 2는 AWS 서버리스 플랫폼의 구성요소 부분 집합과 그 관계를 보여준다.
AWS 서버리스 플랫폼 기능
AWS는 이전 섹션에서 파악한 모든 핵심 기능을 완전한 서버리스 플랫폼의 요구 사항으로 제공한다. 클라우드 로직 레이어는 함수를 기반으로 한, 프로비저닝이 필요 없는 대규모 서버리스 컴퓨팅 오퍼링인 AWS Lambda에 의해 제공된다. AWS Lambda는 에지 최적화 라우팅을 이용해 초저지연 람다 함수를 실행하는 데 비슷한 지원을 제공하는 AWS Lambda@Edge와 AWS Snowball 등 어플라이언스를 비롯한 연결된 기기에서 람다 함수를 실행할 수 있는 AWS Greengrass가 보완했다.
* AWS IoT Greengrass : 클라우드 기능을 로컬 디바이스로 확장하는 소프트웨어AWS IoT Greengrass는 커넥티드 디바이스에서 로컬 컴퓨팅, 메시징, 관리, 동기화 및 ML 추론 기능을 안전한 방식으로 실행할 수 있는 소프트웨어
람다 함수는 다양한 제 1자 및 제 3자 이벤트에 의해 쉽게 트리거될 수 있어 개발자가 기존의 인프라 설정 및 관리 번거로움 없이 사후 대응적인 이벤트 중심 시스템(그림 3 참조)을 구축할 수 있다. 동시 이벤트가 여러 개일 경우 람다는 단순하게 각 개별 트리거에 대응하여 함수의 더 많은 복사본을 병렬로 실행한다. 람다 함수는 개별 요청에 따라 워크로드 크기에 따라 정확하게 확장된다. 그 결과 유휴 서버나 컨테이너의 가능성이 없다. 람다 함수를 사용하는 아키텍처에서 인프라 지출의 낭비 문제는 설계에 의해 제거된다.
FaaS(Function as a Service)는 배포와 실행의 단위로서 함수에 의존하는 이벤트 중심 컴퓨팅 시스템을 구축하는 하나의 접근방식이다. 서버리스 FaaS는 프로그래밍 모델에 가상 머신이나 컨테이너가 없고 벤더가 프로비저닝 없는 확장성과 내장 신뢰성을 제공하는 FaaS의 일종이다.
람다가 제공하는 AWS 서버리스 컴퓨팅 기능은 AWS가 제공하는 다음과 같은 관리형 서비스의 핵심 요소로서, 모두 서로 원활하게 통합된다.
- Amazon API Gateway – 전체 API 프록시 및 API 관리 기능을 포함한 람다 함수를 위한 HTTP 엔드포인트.
- Amazon S3 – 람다 함수는 객체를 생성, 복사 또는 삭제할 때 자동 이벤트 트리거로 사용할 수 있다.
- Amazon DynamoDB – Lambda 함수를 사용하여 데이터베이스 테이블에 대한 변경사항의 일부 또는 전부를 처리할 수 있다.
- Amazon SNS – 메시지를 Lambda 함수로 라우팅하여 처리하고, 게시된 콘텐츠에 동적으로 대응할 수 있는 기능을 추가한다.
- Amazon SQS – 대기열의 메시지를 람다 함수로 쉽게 처리할 수 있다.
- Amazon Kinesis Streams – 람다 함수로 스트리밍 데이터의 주문형 레코드 처리가 제공되어 거의 실시간에 가까운 분석 엔진을 쉽게 구축할 수 있다.
- Amazon Kinesis Firehose – Firehose가 수집하는 레코드에 람다 함수를 자동으로 적용할 수 있어 데이터 스트림에 변환, 필터링, 분석 기능을 쉽게 추가할 수 있다.
- Amazon Athena –Lambda 함수는 쿼리의 결과 집합에 있는 각 객체에 대해 자동으로 트리거될 수 있다.
- AWS Step Functions – 다양한 람다 함수를 조정하여 사람 중심 프로세스와 자동화된 프로세스 모두에 대해 장기간 실행되는 워크플로우를 만들 수 있다.
- Amazon CloudWatch Events – Lambda 함수를 사용하여 타사 이벤트를 포함한 이벤트에 자동으로 대응할 수 있다.
- Amazon Ourora – 데이터베이스 트리거는 람다 함수로 기록할 수 있다.
* Amazon Kinesis Data Firehose : 스트리밍 데이터를 데이터 레이크, 데이터 스토어 및 분석 도구에 가장 쉽고 안정적으로 로드하는 방법
* Amazon Athena : 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스
람다는 슬랙, 알고리즘, 트윌리오, 로그글리, Splunk, SmoLogic, Box 등 다양한 제3자 서비스에 대한 청사진을 갖춘 통합 라이브러리를 제공하여 개발자가 불과 몇 줄의 코드만으로 분석, 고급 알고리즘, 통신 등을 포함하는 응답형 애플리케이션을 구축할 수 있도록 한다. 익스프레스(NodeJS 애플리케이션용)와 플라스크(Python 애플리케이션용)를 포함한 다양한 웹 애플리케이션 프레임워크가 람다 함수와 잘 작동하도록 개선되었다. 오픈 소스 웹 애플리케이션 프로젝트에는 서버리스 프레임워크, 스파르타, 찰리체 등이 포함된다.
서버리스 앱은 일반적으로 하나 이상의 함수, Amazon DynamoDB와 같은 서버리스 데이터베이스, 클라이언트가 호출할 수 있는 API 또는 앱을 트리거하는 이벤트 소스 등 몇가지 조각들로구성된다. 이러한 조각들을 정리하기 위해, AWS는 오픈 사양인 Serverless Application Model(SAM)을 사용한다. SAM을 통해 개발자는 기능, API, 이벤트 소스, 데이터베이스 테이블 및 서버리스 앱의 다른 부분을 쉽게 설명할 수 있다. 또한 SAM을 사용하면 개발자가 소프트웨어 개발 라이프사이클의 모든 단계를 관리할 수 있으며, AWS는 다양한 도구와 서비스를 제공한다. 여기에는 SAM Local을 통해(또는 명령줄을 통해) IDE에서 로컬 테스트 및 디버깅에 대한 기본 지원, AWS CloudFormation을 사용한 SAM 앱 구축 지원, AWS CodeBuild에 SAM 앱을 구축하기 위한 지원, AWS CodePipeLine에 내장된 SAM 앱에 대한 GitHub 기반 CI/CD 지원 등이 포함된다. 제1자 지원 외에도 다수의 오픈 소스 프레임워크, CI/CD 제공자, 성능 관리 벤더가 서버리스 프레임워크, 클라우디아, 클라우드베어스, 데이터독 등을 포함한 SAM 및 람다 함수를 지원한다. 자세한 예는 서버리스 애플리케이션 개발자 도구를 참조하십시오.
람다 함수(또는 SAM 앱의 경우 여러 람다 함수가 함께 작동할 가능성이 있음)가 생성된 후 개발자는 Amazon CloudWatch 및 CloudWatch Logs에서 자동으로 생성된 메트릭과 로그를 사용하여 쉽게 모니터링할 수 있다. AWS는 개발자가 개별 기능 및 자신이 처리하는 이벤트의 작동과 행동을 추적할 수 있는 교차 서비스 요청 추적 및 성능 분석 솔루션인 AWS X-Ray도 제공한다.
AWS 서버리스 플랫폼 제품은 사실상 모든 AWS 전 세계 지역에서 AWS Lambda 및 Amazon API Gateway에 대한 지원을 통해 전 세계적인 범위를 가지고 있다. Lambda@Edge는 모든 에지 위치에서 사용할 수 있다. 람다는 비동기 및 순서 이벤트에 대한 자동 재시도, 애플리케이션에 의해 성공적으로 처리되지 못한 이벤트를 캡처하기 위한 데드 문자 대기열 등 고객이 애플리케이션의 신뢰성을 향상시키는 데 도움이 되는 다양한 기능을 제공한다. Amazon Virtual Private Cloud(Amazon VPC)와의 긴밀한 통합과 AWS Lambda가 제공하는 유연한 인증 및 액세스 제어 기능을 통해 조직은 최소한의 특권 원칙과 같은 모범 사례를 준수하는 안전한 애플리케이션을 만들 수 있다. 최종 사용자 보안과 관리도 마찬가지로 쉽다 – Amazon Cognito는 Amazon API Gateway 및 AWS Lambda와 쉽게 결합할 수 있는 인증과 인증을 제공하여 Facebook 및 기업 디렉토리 같은 소셜 제공자와의 통합을 포함한 서버리스 사용자 등록 및 로그인 기능을 가능하게 한다.
사례 연구
기업들은 서버리스 아키텍처를 적용하여 주식 거래 검증부터 전자상거래 웹사이트 구축, 자연어 처리까지 사례를 활용했다. AWS Lambda와 나머지 AWS 서버리스 포트폴리오는 PCI 또는 HIPAA 컴플라이언스와 같은 보증 프로그램을 필요로 하는 애플리케이션을 포함하여 광범위한 애플리케이션을 만들 수 있는 유연성을 제공한다. 다음 절은 가장 일반적인 사용 사례 중 일부를 설명하지만 포괄적인 목록은 아니다. 고객 레퍼런스 및 사용 사례 설명서의 전체 목록은 서버리스 컴퓨팅을 참조하십시오.
1. 서버리스 웹 사이트, 웹 앱 및 모바일 백엔드
서버리스 접근방식은 로드가 동적으로 변화할 수 있는 애플리케이션에 이상적이다. 서버리스 접근법을 사용한다는 것은 최종 사용자 트래픽이 없을 때 컴퓨팅 비용이 발생하지 않는다는 것을 의미하며, 전자상거래 사이트에서 플래시 세일이나 갑작스런 트래픽 파장을 일으키는 소셜 미디어 언급과 같은 높은 수요를 충족시키기 위해 즉각적인 확장성을 여전히 제공한다. 기존의 인프라 접근방식에 비해, 웹이나 모바일 백엔드를 서버리스 방식으로 설계했을 때 개발, 제공 및 운영하는 비용도 현저히 덜 드는 경우가 많다.
AWS는 개발자가 이러한 애플리케이션을 신속하게 구축하는 데 필요한 서비스를 제공한다.
- Amazon S3는 정적인 콘텐츠를 위한 간단한 호스팅 솔루션을 제공한다.
- AWS Lambda는 Amazon API Gateway와 연계해 기능을 활용한 동적 API 요청 지원
- Amazon DynamoDB는 세션 및 사용자별 상태를 위한 간단한 스토리지 솔루션을 제공한다.
- Amazon Cognito는 최종 사용자 등록, 인증, 자원 액세스 제어를 손쉽게 처리할 수 있는 방법을 제공한다.
- AWS SAM은 개발자가 애플리케이션의 다양한 요소를 설명하는 데 사용할 수 있다.
- AWS CodeStar 클릭 몇 번만으로 CI/CD 툴체인 설정 가능
자세한 내용은 서버리스 웹 애플리케이션을 구축하기 위한 패턴에 대한 자세한 내용을 제공하는 백서 AWS Serverless Multi-Tier Architectures를 참조하십시오.7 전체 참조 아키텍처에 대해서는 웹 애플리케이션8을 생성하는 서버리스 참조 아키텍처 및 GitHub에서 모바일 백엔드9를 생성하는 서버리스 참조 아키텍처를 참조하십시오.
고객 사례 –Bustle.com
Bustle.com은 여성을 위한 뉴스, 엔터테인먼트, 라이프스타일, 패션 웹사이트다. AWS 람다와 아마존 API 게이트웨이를 기반으로 한 서버리스 아키텍처로 이동함으로써 약 84%의 비용 절감을 경험했다.
Bustle의 엔지니어들은 인프라 관리 및 확장을 처리하는 대신 새로운 제품 기능 구축에 집중할 수 있도록 지원하여 민첩성을 추가로 확보했다. 버슬의 팀은 이제 더 효율적이 되어 버슬의 규모에 맞는 사이트를 만들고 운영하는 데 필요한 인원의 절반을 사용하고 있다. 또한 Bustle의 서버리스 백엔드는 두 개의 웹 속성(Bustle과 Romper)을 위한 iOS 앱을 지원한다. 자세한 내용은 Bustle 사례 연구를 참조하십시오.
2. IoT 백엔드
서버리스 아키텍처가 웹 및 모바일 앱에 제공하는 이점은 IoT 백엔드와 기기 수에 따라 원활하게 확장되는 기기 기반 분석 처리 시스템을 쉽게 구축할 수 있게 해준다.
고객 사례 – iRobot
룸바 청소로봇 등 로봇을 만드는 아이로봇은 AWS IoT 서비스와 연계해 AWS 람다를 사용해 IoT 플랫폼용 서버리스 백엔드를 만든다. 서버리스 아키텍처를 사용함으로써, iRobot의 엔지니어링 팀은 인프라 관리나 가용성 및 확장을 처리하기 위한 코드를 수동으로 작성할 필요가 없다. 이를 통해 고객은 더 빠르게 혁신을 이루고 고객에 집중할 수 있다.
* AWS IoT : 인터넷 연결 제품(센서, 액추에이터, 내장형 마이크로 컨트롤러, 스마트 애플리케이션 등)과 AWS 클라우드 간에 안전한 양방향 통신을 제공
3. 데이터 처리
가장 큰 서버리스 애플리케이션은 대량의 데이터를 실시간으로 처리하며, 전형적인 서버리스 데이터 처리 아키텍처는 Amazon Kinesis와 AWS 람다의 조합을 사용하여 스트리밍 데이터를 처리하거나 Amazon S3와 AWS 람다를 결합하여 객체 생성이나 업데이트 이벤트에 대응하여 계산을 트리거한다. 워크로드가 단순한 트리거보다 더 복잡한 오케스트레이션이 필요한 경우 개발자는 AWS Step Functions를 사용하여 진행하면서 하나 이상의 람다 함수를 호출하는 상태 저장 또는 장기 실행 워크플로우를 만들 수 있다.
- 실시간 스트림 처리를 위한 서버리스 레퍼런스 아키텍처
- 실시간 파일 처리를 위한 서버리스 참조 아키텍처
- 이미지 인식 및 처리 백엔드 참조 아키텍처
고객 사례 – FINRA
금융산업규제당국(FINRA)은 AWS 람다를 활용해 매일 370억 건의 주식시장 행사에서 5조 건의 데이터 검증을 수행할 수 있는 서버리스 데이터 처리 솔루션을 구축했다. AWS re에서의 강연:FINRA의 수석 이사인 Tim Griesbach는 "The State of Serverless Computing (SVR311)"이라는 제목의 2016 발명품을 통해 "람바가 이 서버리스 클라우드 솔루션을 위한 최고의 솔루션을 제공할 것이라는 것을 발견했다. 람다와 함께, 이 시스템은 더 빠르고, 더 저렴하고, 더 확장 가능했다. 그래서 결국 비용을 50% 이상 줄였고 매일, 심지어 매시간이라도 추적할 수 있게 되었다."
고객 사례 – Thomson Reuters
미디어 및 정보 기업 Thomson Reuters는 자사 제품 팀이 제품 사용 데이터를 쉽게 분석할 수 있는 서버리스 비즈니스 분석 솔루션을 구축했다. 이 솔루션은 AWS 람다, 아마존 키네시스 스트림, 아마존 키네시스 파이어호스를 결합해 분석을 위한 스트리밍 이벤트 데이터를 수집하고 처리한다. '프로덕트 인사이트'로 불리는 이 결과는 예정보다 두 달 먼저 출시돼 기술적 기대치를 넘어섰다.
안데르스 프리츠 톰슨 로이터 제품혁신담당 상무는 "초당 2000개의 이벤트를 수용하는 것이 당초 목표였다"고 말했다. 우리의 테스트에 따르면 Product Insight on AWS는 초당 최대 4,000개의 이벤트를 처리할 수 있으며, 1년 이내에 이를 초당 10,000개 이상의 이벤트로 늘릴 것으로 예상된다." 이 수치는 매달 250억 건 이상의 사건을 나타낸다. 이 높은 처리량에도 불구하고, 시스템은 그것의 시작 이후 어떤 데이터도 잃지 않았다. 프리츠는 "AWS의 강력한 페일오버 아키텍처와 기술적 능력 때문에 데이터 수집을 시작한 이후 단 한 번의 이벤트도 잃지 않았다"고 말했다.
4. 빅 데이터
AWS Lambda는 많은 양의 병렬 처리 워크로드에 완벽하게 매치된다.
고객 사례 – Fannie Mae
모기지 대부업체의 대표적인 자금 조달처인 패니 메이는 AWS 람다를 이용해 금융 모델링을 위해 "당혹스러울 정도로 평행한" 워크로드를 운영하고 있다. Fannie Mae는 몬테카를로 시뮬레이션 프로세스를 사용하여 모기지 리스크를 관리하는 데 도움이 되는 주택담보대출의 미래 현금흐름을 예측한다. 그 회사는 기존의 HPC 그리드가 증가하는 비즈니스 요구를 더 이상 충족시키지 못한다는 것을 발견했다. 패니 메이는 람다에 새로운 플랫폼을 구축했고, 시스템은 테스트 중 최대 15,000개의 동시 기능 실행까지 성공적으로 확장했다. 새 제도는 2시간 만에 완공된 2000만 채의 주택담보대출에 대해 1회 시뮬레이션을 실시했는데, 이는 기존 제도보다 3배 빠른 속도다. 서버리스 아키텍처를 사용하여, Fannie Mae는 유휴 컴퓨팅 리소스에 대한 비용을 지불하지 않기 때문에 대규모 몬테카를로 시뮬레이션을 비용 효율적으로 실행할 수 있다. 또한 다수의 람다 함수를 동시에 실행함으로써 연산 속도를 높일 수 있다. Fannie Mae는 또한 이전에 애플리케이션 확장 및 신뢰성 관리에 필요한 복잡한 코드를 많이 제거할 수 있는 능력과 함께 서버 관리 및 모니터링을 생략할 수 있었기 때문에 일반적인 출시 시간보다 짧은 시간을 경험했다.
5. IT 자동화
서버리스 접근 방식은 서버 관리의 오버헤드를 제거하여 프로비저닝, 구성, 관리, 경보/모니터 및 시간 지정 크론 작업을 비롯한 대부분의 인프라 작업을 훨씬 쉽게 만들고 관리할 수 있도록 한다.
고객 사례 – 오토데스크 3D 설계 및 엔지니어링
소프트웨어를 만드는 오토데스크는 AWS Lambda를 사용하여 엔지니어링 조직 전반에 걸쳐 AWS 계정 생성 및 관리 프로세스를 자동화한다. Autodesk는 98%의 비용 절감 효과를 실현했다고 추정한다(프로비저닝 계정에서 사용된 노동 시간의 예상 절감 효과). 이제 이전 인프라 기반 프로세스로 프로비저닝하는 데 10시간이 걸리는 대신 단 10분 만에 계정을 프로비저닝할 수 있다. 서버리스 솔루션을 통해 오토데스크는 자동화를 통해 계정을 자동으로 프로비저닝하고, 표준을 구성 및 적용하며, 감사를 실행할 수 있으며, 자동화와 수동 접점 수를 줄일 수 있다.
6. 추가 사용 사례
앞 절에서 설명한 사용 사례는 람다 및 다른 AWS 서버리스 제품에서 가능한 것의 표면만 긁는다. 그 밖에 Amazon Lex와 AWS 람다를 이용해 구축한 챗봇을 통한 강력한 휴먼 언어 이해, Amazon CloudFront가 탑재된 Lambda@Edge를 이용한 저지연 글로벌 에지 컴퓨팅, AWS Snowball 내부에 람다 함수를 탑재한 강력한 사내 파일 처리 등이 이용 사례로 꼽힌다. 이것들은 이 다재다능한 접근법의 흥미로운 능력들 중 일부일 뿐이다. 자세한 내용은 AWS Lambda를 참조하십시오.
* Amazon Lex : Amazon Lex는 음성 및 텍스트를 사용하는 애플리케이션에 대화형 인터페이스를 구축하기 위한 AWS 서비스
* Lambda@Edge : Lambda@Edge는 Amazon CloudFront의 기능 중 하나로서 애플리케이션의 사용자에게 더 가까운 위치에서 코드를 실행하여 성능을 개선하고 지연 시간을 단축할 수 있게 해준다
* Amazon Snowball : 안전한 어플라이언스를 사용하여 AWS 클라우드에서 대용량 데이터를 송수신하는 페타바이트 규모의 데이터 전송 솔루션
결론
서버리스 접근방식은 두 가지 고전적인 IT 관리 문제를 해결하기 위해 고안되었다: 가치 제공 없이 회사 대차대조표를 삭제하는 유휴 서버와 차별화된 고객 가치를 창출하는 비즈니스를 방해하고 저해하는 서버 및 서버 소프트웨어의 구축 및 운영 비용. AWS 람다 및 기타 AWS 서버리스 오퍼링은 프로그래밍 및 청구 모델에서 서버, 컨테이너, 디스크 및 기타 인프라 수준 리소스를 제거함으로써 이러한 오랜 문제를 해결한다. 결과적으로, 개발자들은 그들이 더 빨리 제공할 수 있도록 도와주는 깨끗한 애플리케이션 모델과 함께 일할 수 있고 조직은 유용한 작업에 대해서만 비용을 지불한다. 사후 대응적인 이벤트 기반 시스템을 설계하고 클라우드 네이티브 마이크로 서비스를 제공하는 가장 쉽고 빠른 방법은 서버리스 아키텍처를 사용하는 것이다. 관련 항목에 대한 자세한 내용과 백서를 보려면 서버리스 컴퓨팅 및 애플리케이션을 참조하십시오.
출처 : d1.awsstatic.com/whitepapers/optimizing-enterprise-economics-serverless-architectures.pdf
