랙 위의 서버리스

서버리스는 서버가 물리적으로 없다는 의미가 아닙니다. 이는 컨테이너 킬러나 일시적인 추세가 아닙니다. 이는 클라우드에서 시스템을 구축하는 새로운 접근 방식입니다. 오늘 기사에서는 서버리스 애플리케이션의 아키텍처에 대해 다루고, 서버리스 서비스 제공업체와 오픈 소스 프로젝트가 어떤 역할을 하는지 살펴보겠습니다. 마지막으로 Serverless 사용에 따른 문제에 대해 이야기해 보겠습니다.

애플리케이션(또는 온라인 상점)의 서버 부분을 작성하고 싶습니다. 이는 채팅, 콘텐츠 게시 서비스 또는 로드 밸런서일 수 있습니다. 어쨌든 골치 아픈 일이 많을 것입니다. 인프라를 준비하고, 애플리케이션 종속성을 결정하고, 호스트 운영 체제에 대해 생각해야 합니다. 그런 다음 나머지 모놀리스의 작동에 영향을 주지 않는 작은 구성 요소를 업데이트해야 합니다. 음, 부하가 걸린 상태에서 확장하는 것을 잊지 말자.

필요한 종속성이 이미 사전 설치되어 있고 컨테이너 자체가 서로 격리되어 있고 호스트 OS로부터 격리되어 있는 임시 컨테이너를 사용한다면 어떻게 될까요? 우리는 모놀리스를 마이크로서비스로 나눌 것이며, 각 마이크로서비스는 서로 독립적으로 업데이트되고 확장될 수 있습니다. 이러한 컨테이너에 코드를 배치하면 모든 인프라에서 실행할 수 있습니다. 이미 더 좋습니다.

컨테이너를 구성하고 싶지 않다면 어떻게 하나요? 애플리케이션 확장에 대해서는 생각하고 싶지 않습니다. 서비스 부하가 최소화될 때 유휴 실행 컨테이너에 대한 비용을 지불하고 싶지 않습니다. 코드를 작성하고 싶습니다. 비즈니스 논리에 집중하고 빛의 속도로 제품을 시장에 출시하세요.

그러한 생각이 나를 서버리스 컴퓨팅으로 이끌었습니다. 이 경우 서버리스는 다음을 의미합니다. 서버가 물리적으로 없는 것이 아니라 인프라 관리 문제가 없다는 것입니다.

아이디어는 애플리케이션 로직이 독립적인 기능으로 분류된다는 것입니다. 이벤트 구조를 가지고 있습니다. 각 기능은 하나의 "마이크로 작업"을 수행합니다. 개발자에게 필요한 것은 클라우드 공급자가 제공하는 콘솔에 기능을 로드하고 이를 이벤트 소스와 연관시키는 것뿐입니다. 코드는 자동으로 준비된 컨테이너에서 요청 시 실행되며 실행 시간에 대해서만 비용을 지불합니다.

이제 애플리케이션 개발 프로세스가 어떤 모습일지 살펴보겠습니다.

개발자 측에서

앞서 우리는 온라인 상점 애플리케이션에 대해 이야기하기 시작했습니다. 전통적인 접근 방식에서는 시스템의 기본 논리가 모놀리식 애플리케이션에 의해 수행됩니다. 그리고 애플리케이션이 있는 서버는 부하가 없더라도 지속적으로 실행됩니다.

서버리스로 전환하기 위해 애플리케이션을 마이크로 작업으로 나눕니다. 우리는 각각에 대해 고유한 기능을 작성합니다. 함수는 서로 독립적이며 상태 정보를 저장하지 않습니다(상태 비저장). 심지어 다른 언어로 작성될 수도 있습니다. 그 중 하나가 "떨어져도" 전체 응용 프로그램이 중지되지 않습니다. 애플리케이션 아키텍처는 다음과 같습니다.

서버리스의 기능 구분은 마이크로서비스 작업과 유사합니다. 그러나 마이크로서비스는 여러 작업을 수행할 수 있으며, 이상적으로는 함수가 하나를 수행해야 합니다. 통계를 수집하고 사용자의 요청에 따라 표시하는 것이 작업이라고 가정해 보겠습니다. 마이크로서비스 접근 방식에서는 쓰기와 읽기라는 두 가지 진입점이 있는 하나의 서비스에서 작업이 수행됩니다. 서버리스 컴퓨팅에서는 서로 관련되지 않은 두 가지 다른 기능이 있습니다. 예를 들어, 통계가 다운로드되는 것보다 더 자주 업데이트되는 경우 개발자는 컴퓨팅 리소스를 절약합니다.

서버리스 기능은 서비스 제공자가 정한 짧은 시간(타임아웃) 내에 실행되어야 합니다. 예를 들어 AWS의 경우 제한 시간은 15분입니다. 이는 수명이 긴 기능을 요구 사항에 맞게 변경해야 함을 의미합니다. 이것이 서버리스가 오늘날 널리 사용되는 다른 기술(컨테이너 및 서비스로서의 플랫폼)과 구별되는 점입니다.

각 기능에 이벤트를 할당합니다. 이벤트는 작업의 트리거입니다.

행사
함수가 수행하는 작업

제품 이미지가 저장소에 업로드되었습니다.
이미지를 압축하여 디렉토리에 업로드

실제 매장 주소가 데이터베이스에 업데이트되었습니다.
지도에 새 위치 로드

고객이 상품 대금을 지불합니다.
결제 처리 시작

이벤트는 HTTP 요청, 스트리밍 데이터, 메시지 대기열 등이 될 수 있습니다. 이벤트 소스는 데이터의 변경 또는 발생입니다. 또한 타이머로 기능을 실행할 수도 있습니다.

아키텍처가 완성되었고 애플리케이션은 거의 서버리스 상태가 되었습니다. 다음으로 서비스 제공업체로 이동합니다.

공급자 측에서

일반적으로 서버리스 컴퓨팅은 클라우드 서비스 공급자가 제공합니다. Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions 등 다르게 호출됩니다.

우리는 공급자의 콘솔이나 개인 계정을 통해 서비스를 사용합니다. 기능 코드는 다음 방법 중 하나로 다운로드할 수 있습니다.

• 웹 콘솔을 통해 내장 편집기에 코드를 작성하고,
• 코드가 포함된 아카이브를 다운로드하고,
• 공개 또는 비공개 Git 저장소로 작업합니다.

여기서는 함수를 호출하는 이벤트를 설정합니다. 이벤트 세트는 제공자마다 다를 수 있습니다.

공급자는 인프라에 FaaS(Function as a Service) 시스템을 구축하고 자동화했습니다.

1. 함수 코드는 공급자 측 저장소에 보관됩니다.
2. 이벤트가 발생하면 준비된 환경을 갖춘 컨테이너가 서버에 자동으로 배포됩니다. 각 함수 인스턴스에는 자체 격리된 컨테이너가 있습니다.
3. 저장소에서 함수가 컨테이너로 전송되어 계산되고 결과가 반환됩니다.
4. 병렬 이벤트 수가 증가하고 있으며 컨테이너 수가 증가하고 있습니다. 시스템이 자동으로 확장됩니다. 사용자가 해당 기능에 액세스하지 않으면 비활성화됩니다.
5. 공급자는 컨테이너의 유휴 시간을 설정합니다. 이 시간 동안 함수가 컨테이너에 표시되지 않으면 해당 컨테이너는 파기됩니다.

이런 방식으로 우리는 서버리스를 즉시 사용할 수 있습니다. 우리는 종량제 모델을 사용하여 사용한 기능에 대해서만, 사용한 시간에 대해서만 서비스 비용을 지불합니다.

개발자에게 서비스를 소개하기 위해 공급자는 최대 12개월의 무료 테스트를 제공하지만 총 계산 시간, 월별 요청 수, 자금 또는 전력 소비를 제한합니다.

공급자와 협력할 때의 주요 이점은 인프라(서버, 가상 머신, 컨테이너)에 대해 걱정할 필요가 없다는 것입니다. 공급자는 자체 개발 및 오픈 소스 도구를 사용하여 FaaS를 구현할 수 있습니다. 그들에 대해 더 이야기합시다.

오픈소스 측면에서

오픈 소스 커뮤니티는 지난 몇 년 동안 서버리스 도구에 대해 적극적으로 작업해 왔습니다. 가장 큰 시장 참여자들도 서버리스 플랫폼 개발에 기여합니다.

• 구글 개발자에게 오픈 소스 도구를 제공합니다. 원어민. IBM, RedHat, Pivotal 및 SAP가 개발에 참여했습니다.
• IBM 서버리스 플랫폼에서 근무 오픈위스크, 이후 Apache Foundation의 프로젝트가 되었습니다.
• Microsoft 플랫폼 코드를 부분적으로 열었습니다 하늘빛 함수.

서버리스 프레임워크 방향으로의 개발도 진행 중입니다. 큐브리스 и 분열 사전 준비된 Kubernetes 클러스터 내에 배포됩니다. 오픈FaaS Kubernetes와 Docker Swarm 모두에서 작동합니다. 프레임워크는 일종의 컨트롤러 역할을 합니다. 요청 시 클러스터 내부에 런타임 환경을 준비한 다음 거기서 기능을 시작합니다.

프레임워크는 필요에 맞게 도구를 구성할 수 있는 여지를 남겨둡니다. 따라서 Kubeless에서는 개발자가 함수 실행 제한 시간(기본값은 180초)을 구성할 수 있습니다. Fission은 콜드 스타트 ​​문제를 해결하기 위해 일부 컨테이너를 항상 실행하도록 제안합니다(이렇게 하면 리소스 가동 중지 시간 비용이 발생하지만). 그리고 OpenFaaS는 HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT 등 모든 취향과 색상에 맞는 트리거 세트를 제공합니다.

시작하기 위한 지침은 프레임워크의 공식 문서에서 찾을 수 있습니다. 이들과 함께 작업하려면 공급자와 작업할 때보다 약간 더 많은 기술이 필요합니다. 이는 최소한 CLI를 통해 Kubernetes 클러스터를 시작하는 능력입니다. 기껏해야 다른 오픈 소스 도구(예: Kafka 큐 관리자)를 포함하십시오.

공급자를 통해 또는 오픈 소스를 사용하여 서버리스로 작업하는 방식에 관계없이 서버리스 접근 방식의 여러 가지 장점과 단점을 얻게 됩니다.

장점과 단점의 관점에서

서버리스는 팀이 하나의 플랫폼에 얽매이지 않고 다국어 모드로 작업할 수 있는 컨테이너 인프라 및 마이크로서비스 접근 방식에 대한 아이디어를 개발합니다. 시스템 구축이 단순화되고 오류 수정이 더 쉬워집니다. 마이크로서비스 아키텍처를 사용하면 모놀리식 애플리케이션의 경우보다 훨씬 빠르게 시스템에 새로운 기능을 추가할 수 있습니다.

서버리스는 개발 시간을 더욱 단축합니다. 개발자는 애플리케이션의 비즈니스 로직과 코딩에만 집중할 수 있습니다. 결과적으로, 개발을 위한 시장 출시 시간이 단축됩니다.

보너스로 로드에 대한 자동 확장 기능이 제공됩니다. 그리고 우리는 사용한 리소스에 대해서만, 그리고 리소스가 사용된 시점에만 비용을 지불합니다.

다른 기술과 마찬가지로 서버리스에도 단점이 있습니다.

예를 들어, 이러한 단점은 콜드 스타트 ​​시간(JavaScript, Python, Go, Java, Ruby와 같은 언어의 경우 평균 최대 1초)일 수 있습니다.

한편, 실제로 콜드 스타트 ​​시간은 함수가 작성된 언어, 라이브러리 수, 코드 양, 추가 리소스(동일한 데이터베이스 또는 인증 서버)와의 통신 등 다양한 변수에 따라 달라집니다. 개발자가 이러한 변수를 제어하므로 시작 시간을 줄일 수 있습니다. 그러나 반면에 개발자는 컨테이너의 시작 시간을 제어할 수 없습니다. 이는 모두 공급자에 따라 다릅니다.

함수가 이전 이벤트에 의해 시작된 컨테이너를 재사용하면 콜드 스타트가 웜 스타트로 바뀔 수 있습니다. 이 상황은 세 가지 경우에 발생합니다.

• 클라이언트가 서비스를 자주 사용하고 해당 기능에 대한 호출 수가 증가하는 경우
• 공급자, 플랫폼 또는 프레임워크에서 일부 컨테이너를 항상 실행하도록 허용하는 경우
• 개발자가 타이머에 따라 기능을 실행하는 경우(예: 3분마다)

많은 애플리케이션의 경우 콜드 스타트는 문제가 되지 않습니다. 여기서는 서비스 유형과 작업을 기반으로 구축해야 합니다. XNUMX초의 시작 지연은 비즈니스 애플리케이션에 항상 중요한 것은 아니지만 의료 서비스에는 매우 중요할 수 있습니다. 이 경우 서버리스 접근 방식은 더 이상 적합하지 않을 수 있습니다.

서버리스의 다음 단점은 함수의 수명이 짧다는 것입니다(함수가 실행되어야 하는 시간 초과).

그러나 수명이 긴 작업을 수행해야 하는 경우 서버리스와 다른 기술을 결합하는 하이브리드 아키텍처를 사용할 수 있습니다.

모든 시스템이 서버리스 구성표를 사용하여 작동할 수 있는 것은 아닙니다.

일부 응용 프로그램은 실행 중에도 데이터와 상태를 저장합니다. 일부 아키텍처는 모놀리식으로 유지되고 일부 기능은 오래 지속됩니다. 그러나 (클라우드 기술과 컨테이너처럼) 서버리스는 훌륭한 미래를 가진 기술입니다.

이러한 맥락에서 저는 서버리스 접근 방식을 사용하는 문제를 원활하게 진행하고 싶습니다.

애플리케이션 측면에서

2018년 서버리스 사용량 비율 XNUMX배 성장했다. 이미 서비스에 기술을 구현한 회사 중에는 Twitter, PayPal, Netflix, T-Mobile, Coca-Cola와 같은 거대 시장 기업이 있습니다. 동시에 서버리스가 만병통치약이 아니라 특정 범위의 문제를 해결하기 위한 도구라는 점을 이해해야 합니다.

• 리소스 가동 중지 시간을 줄입니다. 호출 횟수가 적은 서비스를 위해 지속적으로 가상 머신을 유지할 필요가 없습니다.
• 즉시 데이터를 처리합니다. 사진을 압축하고, 배경을 잘라내고, 비디오 인코딩을 변경하고, IoT 센서로 작업하고, 수학 연산을 수행합니다.
• 다른 서비스를 함께 "접착"합니다. 내부 프로그램이 포함된 Git 저장소, Jira 및 캘린더가 포함된 Slack의 채팅 봇.
• 부하의 균형을 맞추십시오. 여기서 좀 더 자세히 살펴보겠습니다.

50명을 끌어들이는 서비스가 있다고 가정해 보겠습니다. 그 아래에는 하드웨어가 약한 가상 머신이 있습니다. 때때로 서비스 부하가 크게 증가합니다. 그러면 약한 하드웨어는 대처할 수 없습니다.

예를 들어 세 개의 가상 머신에 로드를 분산하는 밸런서를 시스템에 포함할 수 있습니다. 이 단계에서는 부하를 정확하게 예측할 수 없으므로 일정량의 리소스를 "예비"로 실행합니다. 그리고 우리는 가동 중지 시간에 대해 초과 비용을 지불합니다.

이러한 상황에서는 하이브리드 접근 방식을 통해 시스템을 최적화할 수 있습니다. 로드 밸런서 뒤에 하나의 가상 머신을 남겨두고 기능이 있는 서버리스 엔드포인트에 대한 링크를 배치합니다. 로드가 임계값을 초과하면 밸런서는 요청 처리의 일부를 대신하는 함수 인스턴스를 시작합니다.

따라서 서버리스는 많은 수의 요청을 너무 자주 처리하지 않고 집중적으로 처리해야 하는 경우에 사용할 수 있습니다. 이 경우 15분 동안 여러 기능을 실행하는 것이 가상 머신이나 서버를 항상 유지하는 것보다 수익성이 높습니다.

서버리스 컴퓨팅의 모든 장점을 활용하려면 구현하기 전에 먼저 애플리케이션 로직을 평가하고 특정 사례에서 서버리스가 어떤 문제를 해결할 수 있는지 이해해야 합니다.

서버리스 및 Selectel

Selectel에서는 이미 Kubernetes를 사용한 단순화된 작업 우리 제어판을 통해. 이제 우리는 자체 FaaS 플랫폼을 구축하고 있습니다. 우리는 개발자가 편리하고 유연한 인터페이스를 통해 서버리스를 사용하여 문제를 해결할 수 있기를 바랍니다.

이상적인 FaaS 플랫폼이 무엇인지, 프로젝트에서 서버리스를 어떻게 사용하고 싶은지에 대한 아이디어가 있다면 댓글로 공유해 주세요. 우리는 플랫폼을 개발할 때 귀하의 희망 사항을 고려할 것입니다.
 
기사에 사용된 자료:

• 서버리스 사용량 비율이 XNUMX배 증가했습니다(전체 RightScale 보고서).
• 콜드 스타트 ​​시간은 애플리케이션 언어에 따라 다릅니다.

출처 : habr.com