서버리스와 재무 운영의 만남: 경제적인 서버리스

초록: 본 논문은 서버리스 분야에서 FunctionGraph의 FinOps 탐색 및 실습을 기반으로 업계 최초의 서버리스 기능 총 비용 추정 모델을 제안합니다.
历川:华为云Serverless研发专家
平山:华为云中间件Serverless负责人
冯嘉:华为云中间件首席专家

주요 내용:

1) 서버리스의 급속한 발전이 광범위하고 심도 있는 관심을 끌었지만, 서버리스 기능의 총 비용에 대한 사전 추정은 여전히 ​​효과적인 이론적 지침이 부족합니다. FinOps 탐색 및 서버리스 분야의 FunctionGraph 실습을 기반으로 본 논문은 업계 최초의 서버리스 기능 총 비용 추정 모델을 제안합니다.

2) 비용 모델의 핵심 요소 분석을 기반으로 기능의 운영 비용에 대한 5가지 최적화 방법을 제안함과 동시에 사용자가 비용을 절감하고 효율성을 높일 수 있도록 HUAWEI CLOUD는 투명하고, 효율적인 원클릭 "사용자 기능" 최초. Cost Research Center".

문제 소개

Serverless의 밀리초 단위 정확한 종량제 모델은 사용자가 자원의 유휴 시간에 대해 비용을 지불할 필요가 없도록 합니다. 그러나, 주어진 응용 기능에 대해 과금 비용에 영향을 미치는 요소가 고유하지 않기 때문에 사용자가 기능 실행 기간 동안 총 과금을 정확하게 추정하는 것은 어려운 작업이 됩니다 .

기존 클라우드 자원의 주기적 임대 모델을 예로 들면, 주기 수에 주기 단가를 곱하면 클라우드 플랫폼이 계층화를 채택하더라도 사용자는 임대 기간의 총 비용을 쉽게 추정하고 명확한 심리적 계정 기대치를 형성 할 수 있습니다. 가격 책정 또는 가격 차별 전략의 경우 총 임대 비용을 계산하는 것은 어렵지 않습니다.

그러나 서버리스 시나리오에서는 기능의 총 비용을 미리 예측하기 위한 효과적인 이론적 지침이 아직 없습니다. 한편 으로, 함수 과금에 영향을 미치는 핵심 요소 는 함수 메모리 사양, 단일 인스턴스 동시성, 함수 실행 시간 등과 같이 고유하지 않으며 "종량 과금제"가 더 큰 불확실성을 가지고 있습니다 .

물론 기능 청구를 찾기 위한 이론적 지침은 주로 사용자가 기능의 총 비용을 평가할 수 있는 효과적인 기반을 제공하지만 더 중요한 것은 사용자가 응용 프로그램 기능과 구성 선택을 최적화하도록 돕기 위해 추정 모델을 추가로 사용하는 방법입니다 . 사용자 기능의 총 비용을 크게 절감 비용은 서버리스 분야의 FinOps에게 시급한 문제입니다.

FinOps는 클라우드 자원 관리 및 비용 최적화에 중점을 두고 기술, 비즈니스, 금융 전문가를 유기적으로 연결하여 사용자, 기업, 조직의 클라우드 자원 비용을 최적화하고 클라우드 비즈니스의 입출력 비율을 향상시킵니다[1]. 본 논문은 서버리스 분야 에서 HUAWEI CLOUD FunctionGraph 의 FinOps 탐색 및 실습을 기반 으로 서버리스 시나리오에서 기능 과금 모델과 주요 영향 요인을 분석하고 기능 운영 중 총 과금을 미리 추정하기 위한 모델 프레임워크를 소개합니다. , 이 모델은 사용자가 총 기능 운영 비용을 최적화하고, 사용자 클라우드에서 서버리스 리소스 관리의 성능을 개선하며, 경제적인 서버리스를 달성하도록 돕는 효과적인 기반을 제공합니다 . 

1. 용어 및 배경지식

먼저, 표 1에 나열된 몇 가지 개념에 대한 간략한 설명이 제공됩니다.

표 1: 서버리스 기능의 일반 명사

메모리 사양(메모리) : 함수 사양 및 함수 인스턴스 사양이라고도 하는 메모리 사양은 서버리스 플랫폼이 함수의 단일 인스턴스에 할당한 리소스 크기를 나타내며 일반적으로 함수가 사용할 수 있는 메모리 크기로 표시됩니다. 인스턴스가 공유를 사용할 수 있는 CPU는 메모리 크기에 비례합니다. 서버리스 클라우드 플랫폼은 일반적으로 사용자가 선택할 수 있는 다양한 사양을 제공하는데, FunctionGraph를 예로 들면 사용자는 그림 1과 같이 15가지 기능 사양 중에서 선택할 수 있습니다.

그림 1: FunctionGraph는 다양한 기능 메모리 사양을 제공합니다.

함수 실행 시간 : 호출 요청 응답을 완료하는 과정에서 함수 자체의 실행에 소요되는 시간을 말하며 주로 함수 코드 로직에 의해 결정됩니다. 일반적으로 CPU를 많이 사용하는 기능의 경우 기능 리소스 사양(memory-CPU Share)을 높이면 기능 실행 지연을 크게 줄일 수 있습니다. 그러나 네트워크 IO 및 기타 작업에 대부분의 시간을 소비하는 기능의 경우 리소스 사양을 높이면 실행 대기 시간이 매우 제한적으로 향상됩니다.

인스턴스당 최대 요청 수: 함수의 단일 인스턴스가 동시에 처리할 수 있는 최대 요청 수로, 주로 데이터베이스 액세스 작업과 같이 함수 실행 중에 다운스트림 서비스의 반환을 기다리는 데 상당한 시간이 걸리는 시나리오에 적합합니다. 또는 디스크 IO 등 . 동일한 트래픽 부하에 대해 함수의 단일 인스턴스 동시성을 늘리면 미터당 인스턴스 수를 줄이고 사용자 요금을 절약하며 함수 호출 요청의 콜드 스타트 ​​비율을 줄일 수 있습니다. 

기능당 최대 인스턴스 수 : 동시에 실행되는 동일한 기능의 인스턴스 수의 상한을 나타냅니다. 사용자의 경우 최대 인스턴스 수로 비정상 트래픽 피크 또는 기능 장애 시 클라우드 플랫폼의 과도한 확장으로 인한 비용 통제 불능을 방지할 수 있으며, 클라우드 플랫폼의 경우 최대 인스턴스 수로 인해 플랫폼 리소스가 부분적으로 중단되는 것을 방지할 수 있습니다. 비정상적인 조건에서 사용되는 빛을 소비하므로 다른 기능 간의 성능 격리를 보장합니다. 

2. 기능 과금 및 비용 모델

단일 인스턴스 관점의 함수 과금 추정 모델은 [2]를 참조하십시오. 실제 프로덕션 환경에서 서버리스 클라우드 플랫폼은 비동기 기능 외에도 일반적으로 FCFS(선착순 서비스)를 사용하여 호출 요청에 응답합니다.기능 트래픽의 조수 변동에 대해 플랫폼은 인스턴스의 자동 확장을 통해 적응하고 시간에 따른 동시 인스턴스 수의 변화는 그림 2와 같이 조각별 상수 선형 함수로 완전히 특성화될 수 있습니다.

그림 2: 확장 프로세스에 따라 함수의 동시 인스턴스 수 변경

서로 다른 서버리스 클라우드 공급업체 간에 청구 방법에 차이가 있지만 기능 청구에는 일반적으로 다음과 같이 기능에서 사용하는 리소스에 대한 청구와 요청 수에 대한 청구의 두 부분이 포함됩니다 .

후반부는 함수 호출 트래픽 및 함수 구성과 무관하게 클라우드 플랫폼에서 제공하는 무료 과금 총액을 나타냅니다.

3. 비용최적화 방안 논의

기능 비용의 추정 모델을 사용하여 사용자 비용에 영향을 미치는 주요 요소를 논의할 수 있습니다. 추정식 (1)에서 클라우드 플랫폼에서 제공하는 총 무료 요금을 무시하고 함수의 월별 총 비용 구조는 다음과 같습니다.

포인트 1: 함수 실행 지연을 줄이기 위해 함수 코드 로직 자체를 최적화 

동일한 기능의 트래픽 부하에 대해 실행 지연 시간을 줄이면 사용자가 더 많은 청구 비용을 절약할 수 있습니다. 사용자 비즈니스 논리를 전제로 하는 소프트웨어 엔지니어링의 자연스러운 요구 사항은 기능 코드를 지속적으로 최적화하고 기능 실행 효율성을 향상시키는 것이지만 서버리스 시나리오에서는 더욱 시급합니다.
구체적으로, Python, Nodejs와 같은 경량 프로그래밍 언어를 사용하여 함수 초기화 구성에서 불필요한 항목을 줄이고, 데이터베이스 등의 다른 서비스를 연결하는 작업을 함수 실행 진입 전 초기화 단계로 최대한 이동하여 단순화합니다. 코드 로직 등

또한 FunctionGraph는 사용자가 함수의 실행 상태를 파악할 수 있도록 응용 함수에 대한 심층 시각화 및 관찰 가능성을 제공하고 호출 횟수, 오류 횟수, 실행 횟수 등 풍부한 관찰 지표 구성을 지원합니다. 기능 실행 시간은 그림 3과 같습니다. 모니터링 예.

그림 3: FunctionGraph 함수 런타임 모니터링의 예

Point 2: 함수 코드 패키지, 의존성 패키지, 이미지 사이즈 최적화

함수 호출이 콜드 스타트를 트리거하면 청구의 관점에서 콜드 스타트 ​​지연이 실행 지연에 포함되어 함께 청구되는 반면 콜드 스타트 ​​지연의 상당 부분은 타사 스토리지 서비스의 클라우드 플랫폼에서 소비됩니다. (예: HUAWEI CLOUD Object Storage Service(OBS)에서 사용자의 코드 패키지 및 종속성 패키지를 다운로드하거나 그림 4와 같이 이미지 리포지토리 서비스에서 사용자의 애플리케이션 이미지를 가져옵니다. 대부분의 클라우드 플랫폼은 현재 콜드 스타트 ​​성능을 최적화하기 위해 사용자 코드와 이미지를 사전 캐싱하는 다양한 캐싱 메커니즘을 사용하지만 인스턴스 시작 중 사용자 코드 로드 지연은 여전히 ​​매우 중요 합니다. 따라서 과금 시간을 줄이기 위해 종속 패키지 및 이미지를 줄이는 등 기능 코드 패키지의 크기를 최대한 최적화해야 합니다.

그림 4: 핫 스타트 및 콜드 스타트 ​​시 청구 시간 및 최적화 지점

포인트 3: 기능 중심의 경량 함수 작성 

서버리스 프로그래밍 프레임워크에서 함수는 가능한 한 가볍고 기능 중심적인 프로그램 코드로 작성되어야 합니다 . a 한편으로는 하나의 기능을 가진 기능의 실행 지연이 목표 방식으로 최적화하기가 더 쉽고, 다른 한편으로 한 기능에서 여러 기능이 동시에 구현되는 경우 모든 기능이 기능이 동시에 성능이 저하되므로 기능 실행 기간 동안의 총 청구 금액이 증가하게 됩니다.

그림 5: HUAWEI CLOUD FunctionGraph 함수 흐름의 예

응용 기능이 실제로 여러 기능을 제공해야 하는 경우 그림 5의 FunctionGraph 기능 흐름 기능과 같이 큰 기능을 여러 개의 작은 기능으로 분해한 다음 기능 배열을 통해 전체 논리를 구현할 수 있습니다. 대규모 함수 분해는 또한 사용자가 서버리스 컴퓨팅에서 시간 초과와 같은 비정상적인 시나리오를 처리하기 위한 모범 사례 중 하나입니다[4].

Point 4: 비즈니스 모델 지원을 전제로 단일 인스턴스 다중 동시성 채택 

공식 (2)의 함수 비용 구조를 보면 사용자의 비즈니스 모델을 전제로 특정 단일 인스턴스 동시성을 구성 하면 함수의 총 월간 비용을 효과적으로 줄일 수 있음을 알 수 있습니다 . , 클라우드 플랫폼의 기본값은 일반적으로 1, 즉 단일 인스턴스가 동시에 하나의 요청만 처리할 수 있으므로 함수가 동시에 호출될 때 플랫폼이 응답하기 위해 여러 인스턴스를 시작하므로 증가합니다. 그림 6과 같이 청구 인스턴스의 수, 다중 동시성이 있는 단일 인스턴스를 사용하면 대기 상태에서 호출 요청의 꼬리 지연을 개선할 수도 있습니다. 

그림 6: 단일 인스턴스 동시성: 청구 시간 관점 및 인스턴스 수 관점

물론 단일 인스턴스의 동시성은 높을수록 좋으며, 예를 들어 지나치게 높은 동시성 설정은 함수 인스턴스의 여러 스레드 간의 리소스 경쟁(예: CPU 경합)을 심화시켜 함수 응답을 저하시킵니다. 성능 및 사용자 애플리케이션 성능에 영향 QoS 표시기 등 동시에 이 기사의 배경 지식에서 언급했듯이 모든 응용 프로그램 기능이 단일 인스턴스 다중 동시성을 설정하는 데 적합한 것은 아닙니다. 단일 인스턴스 다중 동시성은 주로 다운스트림 서비스의 반환을 기다리는 함수 실행 과정에서 상당한 부분의 지연이 소비되는 시나리오에 적합합니다. 이러한 시나리오에서 CPU와 같은 인스턴스 리소스의 상당 부분이 유휴 상태이고 데이터베이스 및 메시지 대기열 액세스와 같은 대기 및 기타 미들웨어 또는 디스크 IO, 네트워크 IO 등 단일 인스턴스 다중 동시성은 또한 사용자가 함수 코드에서 전역 공유 변수의 오류 캡처(예: 요청 수준 오류 캡처 세분성 고려) 및 스레드 안전성(예: 잠금 보호)을 조정해야 합니다.

포인트 5: 기능 리소스 사양의 선택은 실행 지연에 대한 영향을 고려해야 합니다. 

마지막으로 기능 자원 사양의 선택에 대해 논의합니다. 식 (2)를 보면 인스턴스 메모리의 사양이 클수록 과금 비용이 높아진다는 것을 알 수 있습니다. 그러나 메모리 사양의 선택은 기능의 실행 지연에 대한 영향을 동시에 고려해야 합니다. 사용자 함수의 관점에서 함수 실행 지연은 코드 자체의 비즈니스 로직에 의해 결정될 뿐만 아니라 인스턴스가 실행 중일 때 사용 가능한 리소스의 크기에도 영향을 받습니다. 인스턴스 크기가 클수록 사용 가능한 메모리와 CPU 공유가 많아 메모리가 많이 사용되거나 CPU를 많이 사용하는 기능의 실행 성능이 크게 향상되고 실행 지연 시간 줄어들 수 있습니다 . 리소스 사양을 초과하면 그림 7의 점선으로 표시된 것처럼 리소스 증가가 기능 실행 지연을 줄이는 데 미치는 영향은 거의 무시할 수 있습니다. 위의 사실은 주어진 사용자 기능에 대해 총 과금 비용을 줄이기 위해서는 그림 7의 실선과 같이 최대한 최소값을 달성할 수 있도록 합리적인 인스턴스 크기를 구성할 필요가 있음을 보여줍니다.

그림 7: 기능 사양 선택 시 비용과 실행 지연 모두에 대한 영향을 고려해야 합니다.

그림 8: 기능 과금 비용의 주요 요인 분석

4. 서버리스 기능 비용 연구 센터

사용자를 위한 비용 절감 및 효율성 증대는 FunctionGraph의 핵심 개념입니다. 위에서 분석한 5가지 함수 비용 최적화 방법은 사용자의 관점에서 논의되었지만 이러한 문제는 사용자가 고려해야 할 범위와 거리가 멀다고 생각합니다 . 서버리스 분야 최고의 재무 운영 효과를 달성하기 위해 사용자는 경제적인 서버리스의 이점을 진정으로 누릴 수 있습니다 . , 투명하고 효율적인 원클릭 기능 자원 관리 및 비용 최적화 서비스를 사용자에게 제공합니다.

그림 9. 온라인 리소스 소비 인식 및 동적 사양 권장 사항

이를 위해 FunctionGraph는 내부 관행을 기반으로 가까운 시일 내에 " 사용자 기능 비용 연구 센터  – 비용 분석 및 최적화 센터"를 시작하여 사용자에게 오프라인 전력 조정, 온라인 리소스 소비 인식 및 최적화를 제공할 예정입니다. 여러 헤비급 기능 서비스, 온라인 리소스 추천(그림 9와 같은 온라인 리소스 추천), 예측적 Auto-scaling 미리보기 등을 포함 하여 사용자가 FinOps 기능을 구현하기 위한 기술적 문턱을 최소화합니다 .

V. 요약 및 전망

이 논문은 주로 서버리스 컴퓨팅 시나리오에서 FinOps 문제를 논의하고 업계 최초의 사용자 기능 총 비용 추정 모델을 제공하며 이 모델을 기반으로 사용자가 응용 프로그램 기능을 최적화하고 서버리스 리소스 관리 효율성을 개선하며 에 따라 총 비용.

새로운 기술 분야의 부상으로 가장 먼저 답해야 할 질문은 "Why & Value"입니다. Huawei Yuanrong이 지원하는 차세대 서버리스 기능 컴퓨팅 및 오케스트레이션 서비스인 FunctionGraph는 FinOps 및 기타 기술 개념과 결합하여, 경제적인 서버리스 서비스를 지속적으로 제공하고 있습니다. 후속편에서는 범용 풀 시나리오 서버리스에 대한 더 많은 첨단 이론과 사례 사례를 공유하고 마이크로 서비스 서버리스에서 FunctionGraph의 실제 경험을 포함하여 커뮤니티에 환원할 것입니다.

참조:

[1] 재무 운영이란 무엇입니까: https://www.finops.org/introduction/what-is-finops/ 

[2] Lambda 함수를 더 빠르고 저렴하게 실행: https://levelup.gitconnected.com/running-lambda-functions-faster-and-cheaper-416260fbc375?gi=4370e4c57684 

[3] AWS Lambda 비용 최적화 전략이 효과적입니다. https://dashbird.io/blog/aws-lambda-cost-optimization-strategies/ 

[4] 시간 초과 모범 사례. https://lumigo.io/learn/aws-lambda-timeout-best-practices/ 

 

HUAWEI CLOUD의 새로운 기술에 대해 처음으로 알아보려면 팔로우를 클릭하세요~

{{o.name}}
{{m.name}}

рекомендация

отmy.oschina.net/u/4526289/blog/5580247