서버리스 란 무엇입니까? 서버리스 컴퓨팅 설명

개발자는 코드로 비즈니스 문제를 해결하는 데 수많은 시간을 보냅니다. 그런 다음 운영 팀이 셀 수없이 많은 시간을 보낼 차례입니다. 먼저 개발자가 사용 가능한 모든 컴퓨터에서 코드를 작성하고 실행하는 방법을 파악하고, 두 번째로 해당 컴퓨터가 원활하게 작동하는지 확인합니다. 두 번째 부분은 진정으로 끝나지 않는 작업입니다. 그 부분을 다른 사람에게 맡기지 않겠습니까?

지난 20 년 동안 가상 머신, 클라우드 컴퓨팅, 컨테이너 등 IT 분야의 많은 혁신은 코드가 실행되는 기본 물리적 머신에 대해 많이 생각할 필요가 없도록하는 데 초점을 맞춰 왔습니다. 서버를 사용하지 않는 컴퓨팅이 논리적 인 결론이 욕망을 취하는 점점 인기 패러다임 : 서버를 사용하지 않는 컴퓨팅, 당신은 알 필요가 없습니다 아무것도 당신을 위해 모두 알아서는 서비스 제공 업체의로, 하드웨어 또는에 OS 코드 실행에 대한을 .

서버리스 컴퓨팅이란 무엇입니까?

서버리스 컴퓨팅은 클라우드 공급자가 특정 코드를 실행하는 데 필요한 컴퓨팅 리소스와 스토리지 만 동적으로 할당 한 다음 사용자에게 비용을 청구하는 클라우드의 실행 모델입니다. 당연히 서버가 여전히 관련되어 있지만 프로비저닝 및 유지 관리는 전적으로 공급자가 처리합니다. Amazon의 서버리스 지지자 인 Chris Munns는 2017 년 컨퍼런스에서 코드를 작성하고 배포하는 팀의 관점에서“관리하거나 프로비저닝 할 서버가 전혀 없습니다. 여기에는 베어 메탈, 가상, 컨테이너가 포함되지 않습니다. 호스트 관리, 호스트 패치 또는 운영 체제 수준의 모든 작업과 관련된 모든 작업은 서버리스 세상.” 

개발자 Mike Roberts가 설명했듯이이 용어는 모바일 앱이 완전히 클라우드에서 호스팅되는 백엔드 서버에 연결되는 소위 서비스로서의 백엔드 시나리오에 사용되었습니다. 그러나 오늘날 사람들이 서버리스 컴퓨팅 또는 서버리스 아키텍처 에 대해 이야기 할 때 이는 고객이 비즈니스 로직 다루는 코드를 작성 하고이를 제공 업체에 업로드하는 서비스로서의 기능 을 의미 합니다 . 이 공급자는 모든 하드웨어 프로비저닝, 가상 머신 및 컨테이너 관리는 물론 애플리케이션 코드에 내장 된 멀티 스레딩과 같은 작업까지 처리합니다.

서버리스 함수는 이벤트 기반이므로 요청에 의해 트리거 될 때만 코드가 호출됩니다. 공급자는 물리적 또는 가상 서버를 유지하기위한 월 고정 요금이 아니라 해당 실행에 사용 된 컴퓨팅 시간에 대해서만 요금을 부과합니다. 이러한 함수를 함께 연결하여 처리 파이프 라인을 만들거나 컨테이너 또는 기존 서버에서 실행되는 다른 코드와 상호 작용하여 더 큰 응용 프로그램의 구성 요소로 사용할 수 있습니다.

서버리스 컴퓨팅의 장단점

이 설명에서 서버리스 컴퓨팅의 가장 큰 두 가지 이점은 분명해야합니다. 개발자는 인프라 질문보다는 자신이 작성한 코드의 비즈니스 목표에 집중할 수 있습니다. 조직은 실제 하드웨어를 구입하거나 대부분 유휴 상태 인 클라우드 인스턴스를 임대하는 대신 매우 세분화 된 방식으로 실제로 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불합니다.

Bernard Golden이 지적했듯이 후자의 점은 이벤트 중심 애플리케이션에 특히 유용합니다. 예를 들어, 대부분의 시간 동안 유휴 상태이지만 특정 조건에서 한 번에 많은 이벤트 요청을 처리해야하는 애플리케이션이있을 수 있습니다. 또는 인터넷 연결이 제한적이거나 간헐적 인 IoT 장치에서 전송 된 데이터를 처리하는 애플리케이션이있을 수 있습니다. 두 경우 모두 기존의 접근 방식은 최대 작업 용량을 처리 할 수있는 강력한 서버를 프로비저닝해야하지만 해당 서버는 대부분의 경우 사용률이 낮습니다. 서버리스 아키텍처에서는 실제로 사용하는 서버 리소스에 대해서만 비용을 지불하면됩니다. 서버리스 컴퓨팅은 특정 종류의 일괄 처리에도 좋습니다.서버리스 아키텍처 사용 사례의 표준 예 중 하나는 일련의 개별 이미지 파일을 업로드 및 처리하고이를 애플리케이션의 다른 부분으로 전송하는 서비스입니다.

서버리스 기능의 가장 명백한 단점은 의도적으로 일시적이고 AlexSoft가 말했듯이 "장기 작업에는 적합하지 않다"는 것입니다. 대부분의 서버리스 공급자는 코드가 몇 분 이상 실행되도록 허용하지 않으며 함수를 가동 할 때 이전에 실행 된 인스턴스의 상태 저장 데이터를 유지하지 않습니다. 관련 문제는 서버리스 코드가 가동되는 데 몇 초 정도 걸릴 수 있다는 것입니다. 많은 사용 사례에서는 문제가되지 않지만 애플리케이션에 낮은 지연 시간이 필요한 경우 경고를받습니다.

Rohit Akiwatkar와 Gary Arora가 지적한 다른 많은 단점은 벤더 종속과 관련이 있습니다. 오픈 소스 옵션을 사용할 수 있지만 서버리스 시장은 잠시 후 논의 하겠지만 대형 상용 클라우드 제공 업체가 지배합니다. 즉, 개발자는 종종 공급 업체의 도구를 사용하기 때문에 불만족스러워지면 전환하기가 어렵습니다. 그리고 정의상 공급 업체의 인프라에서 서버리스 컴퓨팅이 너무 많이 발생하기 때문에 서버리스 코드를 사내 개발 및 테스트 파이프 라인에 통합하기가 어려울 수 있습니다.

서버리스 공급 업체 : AWS Lambda, Azure Functions 및 Google Cloud Functions

서버리스 컴퓨팅의 현대 시대는 2014 년 Amazon의 클라우드 서비스 기반 플랫폼 인 AWS Lambda의 출시로 시작되었습니다. Microsoft는 2016 년 Azure Functions를 따랐습니다. 2017 년부터 베타 버전이었던 Google Cloud Functions가 마침내 프로덕션 상태에 도달했습니다. 세 가지 서비스에는 제한 사항, 장점, 지원되는 언어 및 작업 방법이 약간 다릅니다. Rohit Akiwatkar는 세 가지 차이점에 대해 훌륭하고 자세한 요약을 제공합니다. 또한 오픈 소스 Apache OpenWhisk 플랫폼을 기반으로하는 IBM Cloud Functions도 실행 중입니다.

모든 서버리스 컴퓨팅 플랫폼 중에서 AWS Lambda는 가장 눈에 띄며 진화하고 성숙 할 시간이 가장 많았습니다. 지난 1 년 동안 AWS Lambda에 추가 된 업데이트 및 새로운 기능을 포함합니다.

서버리스 스택

많은 소프트웨어 영역에서와 마찬가지로 서버리스 세계는 서버리스 애플리케이션을 구축하는 데 필요한 다양한 구성 요소를 결합하는 소프트웨어 스택 의 진화를 보았습니다 . 각 스택은 코드를 작성할 프로그래밍 언어 , 코드 구조를 제공 하는 애플리케이션 프레임 워크 , 플랫폼이 이해하고 코드 실행을 시작하는 데 사용할 트리거 세트로 구성 됩니다 .

이러한 각 범주에서 서로 다른 특정 오퍼링을 혼합하고 일치시킬 수 있지만 사용하는 공급 업체에 따라 제한이 있으며 일부 중복됩니다. 예를 들어 언어의 경우 AWS Lambda에서 Node.js, Java, Go, C # 및 Python을 사용할 수 있지만 JavaScript, C # 및 F # 만 기본적으로 Azure 함수에서 작동합니다. 트리거와 관련하여 AWS Lambda는 가장 긴 목록을 가지고 있지만 그 중 다수는 Amazon Simple Email Service 및 AWS CodeCommit과 같은 AWS 플랫폼에만 해당됩니다. 한편 Google Cloud Functions는 일반 HTTP 요청에 의해 트리거 될 수 있습니다. Paul Jaworski는 세 가지 주요 서비스 각각의 스택을 심층적으로 살펴 봅니다.

서버리스 프레임 워크

응용 프로그램을 빌드하는 방법에 대해 많은 것을 정의 할 것이기 때문에 방정식 의 프레임 워크 부분에 약간 머물러있는 것이 좋습니다. Amazon에는 자체 기본 제품인 오픈 소스 SAM (Serverless Application Model)이 있지만 대부분이 크로스 플랫폼이며 오픈 소스 인 다른 제품도 있습니다. 가장 인기있는 것 중 하나는 일반적으로 서버리스라고하며 지원되는 각 플랫폼 (예 : AWS Lambda, Azure Functions, Google Cloud Functions 및 IBM OpenWhisk)에서 동일한 경험을 제공한다는 점을 강조합니다. 또 다른 인기있는 제품은 Apex로, 특정 제공 업체에서 사용할 수없는 일부 언어를 경쟁에 몰아 넣는 데 도움이 될 수 있습니다.

서버리스 데이터베이스

위에서 언급했듯이 서버리스 코드로 작업 할 때의 한 가지 단점은 영구 상태가 없다는 것입니다. 즉, 로컬 변수의 값이 인스턴스화간에 지속되지 않는다는 의미입니다. 코드에서 액세스해야하는 영구 데이터는 다른 곳에 저장해야하며 주요 공급 업체의 스택에서 사용할 수있는 트리거에는 모두 함수가 상호 작용할 수있는 데이터베이스가 포함됩니다.

이러한 데이터베이스 중 일부는 자체적으로 서버리스 라고합니다 . 즉, 데이터가 무기한 저장된다는 명백한 예외를 제외하고는이 기사에서 논의한 다른 서버리스 기능과 매우 유사하게 작동합니다. 그러나 데이터베이스 프로비저닝 및 유지 관리와 관련된 많은 관리 오버 헤드는 제쳐두고 있습니다. 개발자 Jeremy Daly는 "클러스터를 구성하기 만하면 모든 유지 관리, 패치, 백업, 복제 및 확장이 자동으로 처리됩니다."라고 말합니다. FaaS (Function-as-a-Service) 오퍼링과 마찬가지로 실제로 사용하는 컴퓨팅 시간에 대해서만 비용을 지불하고 수요에 맞춰 리소스를 필요에 따라 가동 및 축소합니다.

3 대 서버리스 제공 업체는 각각 자체 서버리스 데이터베이스를 제공합니다. Amazon에는 Aurora Serverless 및 DynamoDB, Microsoft에는 Azure Cosmos DB, Google에는 Cloud Firestore가 있습니다. 그러나 이것들이 사용 가능한 유일한 데이터베이스는 아닙니다. Nemanja Novkovic은 더 많은 제품에 대한 정보를 제공합니다.

서버리스 컴퓨팅 및 Kubernetes

컨테이너는 내부적으로 서버리스 기술을 강화하는 데 도움이되지만 관리 오버 헤드는 공급 업체가 처리하므로 사용자에게는 보이지 않습니다. 많은 사람들은 서버리스 컴퓨팅을 복잡성을 처리하지 않고도 컨테이너화 된 마이크로 서비스의 많은 이점을 얻을 수있는 방법으로보고 있으며 컨테이너 이후의 세계에 대해 이야기하기 시작했습니다.

사실 컨테이너와 서버리스 컴퓨팅은 앞으로 수년 동안 거의 확실히 공존 할 것이며 실제로 서버리스 기능은 컨테이너화 된 마이크로 서비스와 동일한 애플리케이션에 존재할 수 있습니다. 가장 인기있는 컨테이너 오케스트레이션 플랫폼 인 Kubernetes는 서버리스 인프라도 관리 할 수 ​​있습니다. 실제로 Kubernetes를 사용하면 단일 클러스터에 다양한 유형의 서비스를 통합 할 수 있습니다.  

서버리스 오프라인

서버리스 컴퓨팅을 시작할 가능성이 약간 겁이 날 수도 있습니다. 공급 업체에 가입하여 작동 방식을 확인해야 할 것 같기 때문입니다. 하지만 걱정하지 마세요. 로컬 하드웨어에서 오프라인으로 서버리스 코드를 실행할 수있는 방법이 있습니다. 예를 들어 AWS SAM은 Lambda 코드를 오프라인으로 테스트 할 수있는 로컬 기능을 제공합니다. 서버리스 애플리케이션 프레임 워크를 사용하는 경우 로컬에서 코드를 실행할 수있는 플러그인 인 서버리스 오프라인을 확인하세요. 행복한 실험!