코드를 바꾸지 않아도 전면적으로 Serverless화할 수 있다. 아리의 중간부품은 어떻게 이 난제를 풀 수 있습니까?

아리매 안내: Serverless의 화제는 범위가 매우 넓고 코드 관리, 테스트, 발표, 운영과 용량 확대 등 응용 생명주기와 관련된 모든 부분을 포함한다.온라인 응용 프로그램은 어떻게 코드를 바꾸지 않고도 Serverless 구조로 옮길 수 있습니까?오늘 우리는 알리바바의 수천 수만의 온라인 응용 프로그램의 Serverless 진전 과정을 폭로한다.
AWS Lambda는 Serverless 분야의 대표적인 제품이지만 핵심 비즈니스에 적용할 경우 다음과 같은 문제가 발생할 수 있습니다.

사용자가 Function 단위로 개발하고 새로운 개발 구조를 요구하며 클라우드 제조업체가 강하게 연결되고 지역사회 주류 기술 창고 이전 원가가 높다.

Function 시작 속도가 충분하고 밀리초급 또는 초급이어야 한다. 이 제한은 적용 장면에 강한 제약이 있다.

Function 간 호출은 API Gateway를 통해 더 오래 응답합니다.

Cloud Service Engine 클라우드 서비스 엔진(이하 CSE)은 AWS Lambda의 다양한 장점을 갖춰 AWS Lambda를 사용할 때 겪는 난제를 해결할 수 있도록 알리 클라우드 중간부품 팀이 개발한 범용 Serverless 컴퓨팅을 위한 중간부품 제품이다.

Serverless란 무엇입니까?

AWS는 Serverless에 대해 다음과 같이 정의합니다. (AWS 홈페이지에서 발췌)
AWS 서버 플랫폼이 제공하는 기능 없음: (AWS 홈페이지에서 발췌)
AWS의 전체 Serverless 방안은 매우 완벽하지만 메모리 응용이 어떻게 Serverless 구조로 이동하는지에 대한 문제를 해결하지 못했다.단지 새로 개발된 응용 프로그램에 대해faaS 방식으로 개발하는 것을 권장해야만 Serverless 구조로 전환할 수 있다.필자는 Serverless 구조를 대규모로 보급하려면 반드시 저장량 업무에 대한 해결 방안이 있어야 한다고 생각한다.

Serverless의 클라우드 컴퓨팅에 대한 가치

클라우드 컴퓨팅은 결국 일종의 IT 서비스 제공 모델이다. 공공 클라우드든 전문 클라우드(IT 설비의 귀속과 다른 분류)든 그 본질은 IT의 최종 사용자가 언제 어디서나 간편하고 신속하게 IT 서비스를 얻도록 돕는 것이다. 현재 Iaas, PaaS는 모두 수요에 따라 비용을 지불했고 PaaS는 심지어 요구에 따라 비용을 지불했다. 예를 들어 DB, CACHE, MQ 등이다.그러나 Iaas의 비용 지불 입도는 여전히 시간 차원으로 가장 빨리 시간에 따라 비용을 지불하고 분으로 지불한다.
따라서 현재의 클라우드 컴퓨팅 장면에서 응용된 개발 유지보수 방식은 전통적인 IDC 시대의 개발 유지보수에 비해 차이가 크지 않다.그러나 AWS Lambda는 새로운 개발 유지보수 방식을 제공했다. 사용자는 업무 코드를 잘 써서 클라우드에 제출하면 모든 기계 용량, 가용성, 기계 단위의 운영 업무를 클라우드 플랫폼에 맡길 수 있다. 이런 모델은 클라우드의 탄력적인 가치를 크게 방출하고 수요에 따라 비용을 지불할 수 있다.
CSE는 AWS Lambda처럼 클라우드의 탄력적인 가치를 한층 더 방출하고 메모리 응용을 원활하게 이전할 수 있는 보다 규모화된 해결 방안을 제공하려고 한다.

저장량 온라인 비즈니스에서 Serverless 구조를 실현하는 데 있어서의 도전

스텁 온라인 애플리케이션의 특징은 다음과 같습니다.

리소스 할당 속도 = 분 단위

어플리케이션 시작 속도 = 10분 +

상기 객관적인 조건을 바탕으로 일반적인 방법은 기계의 수량을 미리 정하여 임의의 시간의 유량 최고치에 대응하는 것이다. 상기 기술 파라미터가 밀리초급으로 변한다고 가정하면 응용 프로그램 구조를 아래 그림과 같은 방식으로 변화시킬 기회가 있다.
위의 그림에서 서비스 A는 서비스 B를 호출할 때 B의 용량이 충분하면 호출에 성공했다.만약에 B의 용량이 부족하면 만약에 스레드가 가득 차면 제한 밸브 값을 직접 터치하면 A는 오류 코드를 받은 다음에 자원 제어 시스템을 직접 호출한다. 자원 제어 시스템은 새로운 서비스 B 실례를 분배한다. 이 분배 속도는 매우 빠르고 몇 십 밀리초가 걸린다. 동시에 B의 서비스 주소를 A에게 직접 되돌려준다. A는 이전에 완성하지 못한 요청을 새로 만든 서비스 B로 보낼 것이다.
이 절차는 개발자에게 다음과 같은 가치를 제공합니다.

가치 1: 서버를 관리할 필요가 없으며 용량 평가가 필요하지 않습니다.용량 평가는 응용 담당자들에게 매우 어려운 문제였다. 왜냐하면 우리는 미래의 최고치가 무엇인지 예측하기 어려웠기 때문이다.

가치 2: 지속적인 확장;이전의 방법은 모든 응용 프로그램이 일정 수량의 자원을 독점하는 것이다. 만약에 Serverless 모드가 된다면 모든 응용 프로그램은 자원 풀을 공유할 수 있고 모든 응용 프로그램은 거의 무한히 확장할 수 있다.

가치 3: 요구에 따라 비용을 계산한다.모든 실례의 가동 시간은faaS의 함수 가동 시간보다 빠르기 때문에faaS처럼 원가를 계산할 수 있고 원가는 다음과 같은 요소와만 관련이 있다.

요청 수량(QPS)

요청 당 CPU 실행 시간(예: 100ms

인스턴스당 메모리 사양

앞에서 말한 바와 같이 상기 기술한 분포식 구조를 실현하기 위해 관건적인 기술은 응용 시작 속도에 있다. 이곳의 응용 시작 속도는 응용이 데이터를 정상적으로 처리할 수 있을 때까지 하는 것을 말한다.

어떻게 응용 프로그램의 시작 속도를 밀리초급으로 높입니까?

응용 프로그램은 시작 과정에서 보통 여러 개의 구성 요소를 초기화합니다. 예를 들어 각종 중간부품, 데이터 구조, 그리고 네트워크 호출 외부 서비스 등입니다.알리 내부에서 SOA와 마이크로 서비스를 광범위하게 사용하는 상황에서 앱은 시작 과정에서 공유 업무인 SDK를 대량으로 탑재하고 시작 과정이 10분량급에 이르는 경우가 있어 개별 앱은 더 길어질 수 있다.따라서 이 시작 과정은 반드시 앞당겨 완성해야만'임진마총'의 방식으로 새로운 실례를 만들 수 있다.
방안 1: 냉각 시작 자원 압축 방안 적용
L1 탄력성은 한 대의 물리적 기기나 큰 규격의 ECS에 같은 응용을 배치한 여러 가지 실례를 말한다. 운영체제와 JVM의 최적화를 통해 4G 메모리를 차지하는 응용 프로그램은 10개를 배치하더라도 2.2G RAM만 차지한다.
L1은 총괄적으로 보면 고밀도 배치 방식이다. 응용이 미리 시작되고 용기를 동결했기 때문에 이 응용 실례의 CPU 점용률은 0이고 RAM 점용은 이전의 1/20에 해당하지만 밀리초급 탄력성을 갖추었다.L1의 특징은 가동 속도가 매우 빠르지만 자원을 소모해야 하고 수직 탄력성만 있을 수 있다는 것이다.
L2는 응용 프로그램을 시작한 후 램에 있는 지령과 데이터 구조를 디스크 파일로 dump함으로써 기계 사이에서 파일을 복사하기만 하면 가로로 탄력적인 능력을 얻을 수 있다. 이 시간 소모는 주로 데이터의 네트워크 전송 시간 + 메모리 복사 시간으로 약 5초 정도면 완성할 수 있다.L2의 비용 지출은 네트워크 디스크 용량만 있고 지출이 매우 낮기 때문에 무시할 수 없다.
L2의 모든 SNAOSHOT는 실행 가능한 실례에 대응한다. 예를 들어 한 응용 프로그램이 최대 100개의 실례를 시작해야 할 것으로 예상되면 100개의 SNAOSHOT를 미리 생성하고 각 SNAOSHOT는 실행 실례에 대응하며 시작해야 할 때 원격 디스크에서 이 SNAPSHOT를 불러와야 한다.
이 방안은 L1과 L2의 조합을 통해 응용 시작을 가속화하는 목적을 달성하고 일정한 유량의 펄스 능력을 지원하는 상황에서 최대 50ms 이내에 임의의 응용을 시작하여 평균 10ms 이내에 완성할 수 있다.
시나리오 2: 핫 클로닝 시작 가속 시나리오 적용
L1은 fork 피드 프로세스를 통해 빠른 시작 효과를 얻었고 운영체제팀은 이를 위해 fork2 기술을 개발했다. Linux Native fork와 관건적인 차이점은 PID를 지정하여 하나의 프로세스를 fork할 수 있다는 것이다.
L2의 단일 SNAPSHOT은 여러 프로세스, 일대다 관계를 생성할 수 있습니다.

두 가지 자체 연구 방안의 대비

시나리오1: UUID 문제는 없지만 각 언어의 VM은 개별적으로 맞춤형으로 만들어야 하기 때문에 시나리오에 비해 비용 효과가 약간 떨어진다.

방안2: UUID 문제가 존재할 수 있다. 만약에 개발자가 응용하고자 하는 모든 실례가 시작될 때 하나의 UUID를 정적 변수에 부여하지만 fork를 통해 모든 실례의 이 정적 변수가 똑같을 수 있다. 이것은 개발자가 예상한 것과 일치하지 않는다.방안 2의 장점은 실현하기 쉽고 언어와 무관하며 원가 효과가 우수하다는 것이다.faaS, NBF와 같은 장면이나 개발자가 스스로 정의한 개발 구조에 적합하고 UUID의 문제를 피할 수 있다.

전체적으로 보면 방안 1의 적용 장면이 더욱 넓지만 실현 원가가 높고 방안 2는FaaS, NBF와 같은 장면에 적합하다.

AWS Lambda와 비교

Lambda는 용량을 빠르게 확장하기 위해 사용자의 응용 프로그램이 Function 단위로 개발되도록 요구하고, Lambda Runtime는 Function을 동적으로 불러와 실례를 빠르게 늘린다.
CSE는 한 응용 프로그램의 여러 실례를 시작한 후 같은 명령 데이터를 공유하여 서로 다른 명령 데이터를 추출하고 매번 시작할 때마다 여러 사례의 차이 부분만 불러옵니다.따라서 Spring Boot, PHP/Java/Python/Node와 같은 커뮤니티 주요 기술 스택을 투명하게 호환할 수 있습니다.JS 등.

CSE의 비용 이점

이론 모델:
Serverless 방식은 응용 프로그램이 차지하는 실례 수가 수시로 변화하기 때문에 여러 응용 프로그램이 같은 기계를 사용할 수 있다.
양적 분석:
Serverless의 원가 우위는 CPU Share & 온라인 혼합 등 스케줄링 기술의 원가 우위와 중첩되어 최종 사용자에게 더욱 좋은 전체 원가를 줄 수 있다.

CSE 코드 예제

HSF demo

package com.test.pandora.hsf;

import com.alibaba.boot.hsf.annotation.HSFProvider;

@HSFProvider(serviceInterface = HelloWorldService.class)
public class HelloWorldServiceImpl implements HelloWorldService {
    @Override
    public String sayHello(String name) {
        return "hello : " + name;
    }
}

Spring Boot demo

package com.example.java.gettingstarted;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class HelloworldApplication {
  @RequestMapping("/")
  public String home() {
    return "Hello World!";
  }

  @RequestMapping("/health")
  public String healthy() {
    // Message body required though ignored
    return "Still surviving.";
  }

  public static void main(String[] args) {
    SpringApplication.run(HelloworldApplication.class, args);
  }
}

CSE의 생산 실천
모 전자상거래 업무 A:Serverless화 후 기계의 수량은 11대에서 2대(2~10대 사이의 변동)로 낮아졌다. 모 판촉절에서 서비스 데이터의 최고치가 수천 순간에서 10여만 개로 급증했고 CSE는 순식간에 탄력적으로 용량을 확대했다. 2대-->5대-->10대에서 유량의 최고치가 떨어진 후에 2대로 용량을 축소했다.
모 전자상거래 업무 B:Serverless화 후 기계의 수량은 4대에서 2대(2~10대 사이)에서 변동한다.
모 전자상거래 업무 C: 이전에 4대의 기계를 고정시켰는데 Serverless화가 완성된 후에 기계의 수량은 1대(1~4대 사이의 파동)로 변했고 예발은 0~1대의 실례 사이의 파동을 실현할 수 있다.
이 문서의 작성자:
왕소서: 화명서가, 알리바바의 베테랑 기술 전문가, Apache Rocket MQ 창시자 &Chair, 최근에 알리바바의 온라인 업무가 Serverless 구조로 발전하는 것을 추진하고 메시지 중간부품 제품 라인의 클라우드 컴퓨팅 방향을 담당하는 알리바바 중간부품 혁신 프로젝트 실험실 & 메시지 중간부품 팀의 책임자입니다.
서가
원문을 읽다
본고는 운서 지역사회 합작 파트너인'아리 기술'에서 나온 것으로 전재하려면 원작자에게 연락하십시오.