작성자 |

가이드

클라우드 네이티브 환경에서 비즈니스의 대규모 반복에 따른 비용 압박이 증가하고 있습니다. 서버리스 개념에 따라 Baidu Feed의 백엔드 서비스에 대한 탄력성, 트래픽 및 용량의 관점에서 다차원 개인화 서비스 초상화를 구축하고 초상화를 기반으로 서비스를 탄력적으로 확장하고 적응적으로 조정합니다. 트래픽 변동에 따른 서비스 용량, 효과적으로 비즈니스 운영 비용을 줄이기 위해 이 기사에서는 위에서 언급한 관련 전략 및 실용적인 솔루션에 중점을 둡니다.

전체 텍스트는 6542단어이며, 예상 읽기 시간은 17분입니다.

01 배경

Baidu의 내부 제품 라인에서 클라우드 네이티브를 추진함에 따라 마이크로 서비스는 각 비즈니스 라인의 표준 구성이 되었습니다.검색, 추천 및 광고와 같은 전략적 컴퓨팅 비즈니스 시나리오에서 백엔드는 일반적으로 많은 마이크로 서비스로 구성됩니다.이러한 마이크로 서비스 서비스는 일반적으로 다음과 같은 특징이 있습니다.

다중 인스턴스 : 각 서비스는 다중 인스턴스로 구성되며 마이크로 서비스는 rpc를 통해 통신하며 서비스는 일반적으로 수평/수직 확장을 지원합니다.
무거운 계산 : 마이크로 서비스는 비교적 복잡한 비즈니스 로직을 포함합니다.일반적으로 일부 정책 사전은 복잡한 정책 계산을 수행하기 위해 서비스에 로컬로 로드됩니다.서비스 자체에는 더 많은 CPU 및 기타 리소스가 필요합니다.
7*24h : 서비스는 일반적으로 고정 용량을 사용하여 7*24h 온라인 서비스를 제공하며, 클라우드 네이티브 구성 요소는 중복 용량 복구와 같은 정기적인 용량 관리를 수행합니다.

바이두 앱 추천 서비스(줄여서 바이두 피드)는 전형적인 추천 비즈니스 시나리오입니다.백엔드에는 복잡한 전략과 무거운 계산을 가진 많은 마이크로 서비스가 포함되어 있습니다.이러한 백엔드 서비스는 일반적으로 고정 용량을 사용하여 수억 명의 사용자에게 7*24시간 정보 흐름을 제공합니다.추천 서비스. Baidu Feed 백엔드 서비스의 경우 사용자 트래픽에 전형적인 피크와 밸리가 있으며 트래픽의 최저 및 피크 기간에 동일한 용량을 사용하는 것은 리소스 낭비라는 데 의심의 여지가 없습니다. 백엔드 서비스에서 Baidu Feed의 서버리스, 서비스 초상화를 기반으로 하는 탄력적 확장의 기술 솔루션 및 구현에 대해 자세히 설명합니다.

02 아이디어와 목표

업계에서 서버리스의 대규모 관행은 FaaS 측면에 더 가깝고 일반적으로 인스턴스가 더 가볍고 컨테이너의 수명 주기가 상대적으로 짧습니다. 우리가 다루고 있는 것은 상대적으로 "무거운" 백엔드 서비스입니다. 이러한 서비스의 인스턴스 확장에는 일반적으로 다음 단계가 포함됩니다.

PaaS가 컨테이너 초기화 : PaaS는 인스턴스의 할당량 요구 사항(cpu, 메모리, 디스크 등)에 따라 컨테이너를 할당할 적절한 머신을 찾아 컨테이너를 초기화합니다.
바이너리 파일 및 사전 파일 준비 : 원격에서 로컬로 서비스의 바이너리 파일과 사전 파일을 다운로드하여 압축을 풉니다.
인스턴스 시작 : 인스턴스는 시작 스크립트에 따라 로컬에서 프로세스를 시작하고 인스턴스 정보를 서비스 검색에 등록합니다.

백엔드 서비스 인스턴스의 확장 시간은 보통 분 단위로 사전 파일 다운로드 및 압축 해제가 전체 확장 시간의 70% 이상을 차지하며, 사전이 큰 인스턴스의 경우 더 많은 시간이 소요됩니다. 안정적인 용량을 보장하기 위해 매우 짧은 시간(예: 초)에 확장할 수 없습니다. 그러나 이러한 백엔드 서비스의 트래픽은 일반적으로 주기적으로 변동하고 명백한 조수 특성을 가지고 있습니다.서비스 트래픽에 대해 보다 정확한 예측을 할 수 있다면 사전에 용량을 적절하게 확장하여 증가에 직면한 용량을 보장할 수 있습니다. 트래픽 흐름을 줄이기 위해 일정량의 용량 감소를 수행하여 리소스 비용을 절감하고 리소스의 온디맨드 사용을 실현할 수 있습니다.

전체적으로 클라우드 네이티브 구성 요소를 기반으로 탄력성, 용량 및 트래픽 차원을 포함하여 각 서비스에 대한 다차원 개인화 서비스 초상화를 만들고 서비스 안정성 보장을 전제로 트래픽 양에 따라 변동하는 서비스 용량을 실현합니다. 조정. 구현 효과는 아래 그림과 같습니다.왼쪽 그림에서 일반 모드에서 서비스가 소비하는 자원의 양은 고정되어 있으며 트래픽 변동에 따라 변하지 않습니다(자원의 양은 최대 트래픽이 요구하는 용량을 충족해야 함). ).오른쪽 그림에서 서버리스 모드에서 서비스가 소비하는 리소스 양 리소스 양은 트래픽 변동에 따라 동적으로 조정됩니다.

03 전체 구조

전반적인 탄력적 확장 아키텍처는 다음과 같습니다.

서비스 초상화 : 다양한 차원에서 서비스의 개인화된 특성을 나타내는 탄성 초상화, 교통 초상화 및 용량 초상화를 포함합니다.
탄력성 전략 : 예측 탄력성, 부하 피드백 탄력성, 타이밍 탄력성 등 다양한 시나리오에 대한 확장 전략은 서버리스 구현을 위한 기본 핵심 전략입니다.
클라우드 네이티브 구성 요소 : PaaS 및 ALM(앱 수명 주기 관리자)을 포함합니다. 여기서 PaaS는 서비스 확장 작업을 수행하고 ALM은 서비스와 관련된 모든 데이터 및 정책을 관리합니다.
리소스 : 그룹 클라우드와 퍼블릭 클라우드의 두 가지 탄력적 리소스를 포함하여 Serverless는 두 가지 클라우드 리소스와 관련된 서비스 확장을 지원합니다.
안정성 보장 : 탄력적 검사, 용량 검사, 상태 검사, 원클릭 개입 등 탄력적 확장의 안정성을 보장하기 위한 다양한 메커니즘.
확장 가능한 플랫폼 : 리소스 사전 확인, 프로세스 오케스트레이션, 상태 순환 및 이벤트 엔진과 같은 기본 메커니즘을 포함하여 전체 전략을 구현하기 위한 지원 플랫폼입니다.

다음으로 서비스 초상화, 탄력적 전략 및 안정성 보장을 포함한 핵심 전략 및 사례를 소개합니다.

04 서비스 초상화

Baidu 피드의 백엔드에는 많은 서비스가 포함되어 있습니다.각 서비스의 사전 파일 크기가 다릅니다.일부 서비스는 CPU 계산이 더 많고 다른 서비스는 IO가 더 많습니다.각 서비스는 확장성, 트래픽 변동 및 로드 용량이 다릅니다. 따라서 서비스의 온라인 운영 데이터를 중심으로 탄력성, 교통량, 부하의 차원에서 개인화 탄력 초상화, 교통 초상화, 용량 초상화를 구성하고 각 서비스의 개인화 특성을 다차원으로 기술한다.

4.1 탄력적인 초상화

목표: 확장성 관점에서 서비스의 확장성을 설명합니다. 서비스의 탄력성을 설명하는 클라우드 네이티브 지표, 서비스 인스턴스 사양, 인스턴스 배포 및 마이그레이션 시간, 리소스 종속성 및 기타 차원을 기반으로 비즈니스의 서비스는 다음 세 가지 범주로 나뉩니다.

높은 탄력성 : 완전한 상태 비저장 서비스로 손실 없이 마음대로 확장할 수 있으며 확장 속도가 빠릅니다.

중간 탄력성 : 어느 정도의 확장성은 있지만 서비스 상태를 복원하는 데 시간이 오래 걸리고 확장 속도는 평균입니다.

낮은 탄력성 : 확장성이 거의 없고 서비스 상태를 복구하는데 많은 비용이 소요되며 확장 속도가 느리다.

탄력적인 세로 구성 :

각 서비스에 대해 PaaS에서 여러 개의 최근 인스턴스 확장 기록을 가져와 인스턴스 확장 시간을 얻고 중앙값을 서비스의 인스턴스 배포 시간으로 취하고 서비스의 인스턴스 할당량(cpu, 메모리, 디스크)을 결합합니다. 존재 여부 외부 종속성, 간단한 규칙을 사용하여 모든 서비스를 높음, 중간 및 낮음 탄력적 기능으로 분류함과 동시에 표준화된 컨테이너 변환 및 스토리지와 컴퓨팅의 분리를 통해 서비스를 촉진하여 서비스 탄력성을 향상시킵니다.

탄력성 증가 :

표준화된 컨테이너 변환: Baidu 피드 비즈니스의 대부분의 서비스 인스턴스는 이전에 비표준화된 컨테이너였으며 포트 격리 및 리소스 혼합에 결함이 있었고 스토리지와 컴퓨팅의 분리를 지원할 수 없었기 때문에 전체 배포 및 마이그레이션 효율성에 영향을 미쳤습니다. 서비스의 표준화된 컨테이너 변환을 촉진함으로써 각 서비스는 이미 교차 리소스 풀 및 교차 클라우드 스케줄링 배포를 지원하여 각 리소스 풀의 조각난 리소스를 최대한 활용하고 리소스 전달 효율성 및 혼합 배포 기능을 향상시키고 효율적으로 사용할 수 있습니다. 서비스의 탄력적 확장성 향상
스토리지와 컴퓨팅의 분리: 대용량 사전 파일이 있는 백엔드 서비스의 경우 시간이 많이 소요되는 서비스 확장은 사전 파일 다운로드 및 압축 해제에 집중됩니다.이 유형의 서비스를 클라우드 디스크 공유 볼륨에 연결하고 사전 콘텐츠를 연결하도록 권장합니다. 서비스 인스턴스 배포 시 원격으로 읽을 수 있음 메모리에 로드되어 사전 파일의 다운로드 및 압축 해제 시간을 줄여 서비스 배포 및 인스턴스 마이그레이션 시간을 크게 개선하고 서비스의 탄력적 확장성을 효과적으로 향상

4.2 트래픽 프로필

표적:

서비스의 트래픽 변화 추이를 기술하고, 미래 특정 시점의 트래픽을 예측한 후, 트래픽에 따라 해당 용량을 구성합니다.

트래픽 프로필 구성:

CPU 사용량: 트래픽 프로필은 과거 트래픽 데이터를 기반으로 미래 트래픽 데이터를 예측하지만 qps 데이터를 직접 수집하지 않고 qps 대신 cpu 사용량을 사용합니다. 주된 이유는 일반적으로 백엔드 서비스에 여러 개의 rpc/http 인터페이스가 있고 서로 다른 서비스의 인터페이스 수가 다르며 서비스의 서로 다른 인터페이스의 qps 및 성능이 다르고 단일 인터페이스의 qps 인덱스가 반영할 수 없기 때문입니다. 서비스의 전체 리소스 소비 이로 인해 qps 데이터의 리소스 소비와 다중 인터페이스를 사용하는 서비스 간의 매핑을 설정하는 데 어려움이 있습니다. 백엔드 서비스의 주요 리소스 오버헤드는 cpu이며 서비스의 cpu 사용량은 각 서비스에 대한 단일 일반 지표이며 여러 인터페이스 요청을 처리할 때 서비스의 전체 리소스 오버헤드를 직접 반영하므로 이 지표는 보다 정확할 수 있습니다. qps 서비스의 용량 요구 사항을 직접 특성화합니다.
타임 슬라이스: 백엔드 서비스의 트래픽은 일반적으로 24시간 동안 주기적으로 변동합니다. 우리는 하루 24시간을 여러 타임 슬라이스로 나누고 각 서비스에 대해 기록 데이터를 계산합니다(예: 각 타임 슬라이스에서 지난 N일 동안 해당 트래픽 데이터) 과거 데이터를 기반으로 미래의 특정 시간대의 교통 상황을 예측합니다. 예를 들어 24시간을 24개의 타임 슬라이스로 나누고 각 타임 슬라이스가 1시간에 해당하는 경우 해당 타임 슬라이스에서 오후 2시부터 오후 3시까지 특정 서비스의 트래픽 상황을 예측하고자 합니다. to the last 7 days (N=7 ) 이 서비스는 오후 2시부터 3시까지의 교통 데이터를 예측합니다. 그 중 Time Slice의 크기는 설정 가능하며, Time Slice 구성이 작을수록 해당 시간 범위가 작아지며, 단위 시간당 트래픽 변화가 큰 서비스는 작은 Time Slice, 트래픽이 적은 서비스는 작게 설정 가능 변동이 있을 경우 더 작은 타임 슬라이스를 구성할 수 있습니다.
모니터링 수집: 각 서비스에 대해 주기적으로 모든 인스턴스의 부하 데이터(CPU 사용량 등 포함)를 수집하여 서비스 데이터로 집계하고 해당 시간 창(창 크기는 구성 가능)에서 데이터를 평활화합니다. 예를 들어, 인스턴스의 CPU 사용량을 10초마다 수집하여 서비스의 CPU 사용량으로 집계하고, 1분이라는 시간 창에서 서비스의 CPU 사용량 평균값을 해당 데이터로 사용합니다. 시간 창. 모니터링 수집 및 데이터 처리 과정에서 절대 중간 차이 알고리즘을 사용하여 모든 종류의 비정상 및 이상 데이터 포인트를 제거합니다.
세로 구성: 각 서비스에 대해 지난 N일 동안 각 타임 슬라이스의 각 타임 윈도우에 해당하는 CPU 사용량을 계산합니다. 타임 슬라이스의 경우 슬라이딩 윈도우를 사용하여 가장 큰 K 윈도우 데이터의 평균값을 타임 슬라이스로 사용합니다. cpu 사용량, 지난 N일 동안 각 타임 슬라이스에서 각 서비스의 CPU 사용량 데이터를 얻을 수 있도록 동시에 인접한 두 타임 슬라이스의 트래픽 증가율, 즉 (다음 타임 슬라이스 트래픽 - 현재 타임 슬라이스 트래픽)/현재 타임 슬라이스 트래픽. 후속 예측 탄력성에서는 미래 특정 시간대의 트래픽을 시간대 트래픽과 트래픽 증가율을 기반으로 예측합니다.

4.3 용량 초상화

표적:

서비스의 용량 요구 사항을 특성화하기 위해 일반적으로 서비스의 최대 CPU 사용률로 대체됩니다. 예를 들어 서비스가 안정적일 때 최대 CPU 사용률이 60%인 경우 안정성을 보장하기 위해 서비스에 CPU 버퍼의 40% 이상이 예약되어 있음을 의미합니다.

용량 세로 구성:

용량 및 지연: 서비스 처리량과 트래픽이 일정하다고 가정하면 서비스 지연은 종종 남은 CPU 버퍼에 반비례합니다. 즉, 남은 CPU 버퍼가 적을수록 지연이 더 많이 증가합니다. Baidu 피드 비즈니스 라인에서 비코어 링크의 서비스 지연이 약간 증가하더라도 시스템 출구 지연에 직접적인 영향을 미치지 않으므로 코어 링크와 비교하여 비코어 링크의 서비스는 -코어 링크를 예약할 수 있습니다. CPU 버퍼가 적습니다.
전체 방법: 서로 다른 서비스의 제한 처리량과 해당 최대 CPU 사용률이 다릅니다.전반적으로 기계 학습 방법을 사용하여 각 서비스에 대한 성능 곡선을 구성하여 각 서비스에 대한 적절한 cpu 버퍼 양을 설명합니다.전체적인 방법은 다음과 같습니다. 아래 그림에 나와 있습니다.
기능 획득: 인스턴스 모니터링 및 수집 + 인스턴스 전환 압력 측정을 통해 다양한 부하에서 서비스의 지연 데이터를 얻습니다.
모델 구성: 일련의 컨테이너 및 시스템 모니터링 지표와 서비스 qps, CPU 사용률 및 시스템 로드와 같은 서비스 지연 간의 관계를 모델링합니다. f(qps, X)=대기 시간입니다.
프로필 계산: 지연 모델을 기반으로 허용 가능한 지연 범위 내에서 각 서비스의 궁극적인 처리량 및 해당 CPU 사용률을 평가합니다(핵심 서비스의 지연은 증가할 수 없으며 비핵심 서비스의 지연은 증가할 수 있음). 특정 임계값에 의해).

05 유연한 전략

다양한 비즈니스 확장 시나리오에 대처하기 위해 비즈니스 탄력적 확장을 지원하기 위해 다음 세 가지 유형의 탄력적 정책을 구성합니다.

예측 탄력성 : 탄력성이 낮은 서비스에 대해서는 시간대별 트래픽 변동에 따라 향후 트래픽을 예측하고 서비스 용량을 미리 계획하고 조정합니다.

부하 피드백 탄력성 : 탄력성이 높은 서비스의 경우 실시간에 가까운 서비스 부하 변화에 따라 서비스 용량을 적시에 확장하여 서비스 안정성을 보장합니다.

타이밍 유연성 : 일부 서비스는 트래픽 피크 시간대에 크게 변경되지만 오프 피크 기간에는 덜 변경됩니다 피크 기간에는 안정성을 보장하기 위해 최대 용량을 제공해야 합니다 오프 피크 기간에는 용량을 자주 조정할 필요가 없습니다 피크 기간에는 타이밍 유연성이 제공됩니다. 피크 기간 전에 확장하고 피크 기간 후에 축소하고 피크 및 오프 피크 기간 동안 동일한 용량을 유지합니다.

5.1 예측 탄력성

표적:

서비스가 구성한 타임 슬라이스에 따라 현재 타임 슬라이스 내에서 미래 타임 슬라이스의 트래픽을 예측하고 예측된 트래픽에 따라 서비스를 미리 확장하고 용량을 지연시켜 다양한 트래픽 변화에 대처한다.

트래픽 예측:

현재 시간의 경우 트래픽 프로파일에서 이전 타임 슬라이스 트래픽, 현재 타임 슬라이스 트래픽, 다음 타임 슬라이스 트래픽을 합산하여 계산하며, 여기서 이전 타임 슬라이스 트래픽, 현재 타임 슬라이스 트래픽, 다음 시간 슬라이스 트래픽은 모두 지난 N일에 해당합니다. 각각 prev, cur 및 next로 기록된 타임 슬라이스의 최대 트래픽입니다.
prev, cur, next의 관계에 따라 Flow Trend는 아래 그림과 같이 4가지 경우로 나뉩니다.

case-1: prev < cur < next, 전체 트래픽은 상승 추세, 현재는 다음 타임 슬라이스의 트래픽 증가에 대비하고 사전에 용량을 확장해야 함
case-2: prev > cur < next, 전체 트래픽이 하락세에서 상승세로 역전, 현시점에서는 다음 시간대의 트래픽 증가에 대비하여 선제적으로 확장해야 함
case-3: prev < cur > next, 전체 트래픽이 상승 추세에서 하락 추세로 역전되었으며, 현재 타임 슬라이스가 피크 트래픽 상태에 있고 아무런 조치도 취하지 않음
case-4: prev > cur > next, 전체 트래픽이 감소 추세에 있고 스케일링 작업 수행

팽창/수축 전략:

조정이 필요한 시나리오(예: 위의 사례-1, 사례-2 및 사례-4)의 경우 대상 트래픽을 계산합니다. 여기서 대상 트래픽 = 최대(대상 트래픽 1, 대상 트래픽 2)입니다.
목표 용량 1은 위의 네 가지 사례 유형의 트래픽을 기반으로 계산됩니다.
case-1 및 case-2의 경우 대상 트래픽 1은 다음과 같습니다(미리 확장에 해당).
case-4의 경우 대상 트래픽 1은 현재와 같습니다(이는 다음 타임 슬라이스의 트래픽에 따라 축소되지 않음, 그렇지 않으면 용량이 현재 타임 슬라이스를 지원하지 못할 수 있음, 여기서는 다음에 따라 축소만 함) 지연 축소와 동일한 현재 타임 슬라이스 트래픽).
대상 트래픽 2 = 현재 트래픽 * (지난 N일 동안 현재 시간 조각과 다음 시간 조각 사이의 최대 증가율), 여기서 현재 트래픽은 최신 K 시간 창에 해당하는 CPU 사용량을 수집합니다.
목표 트래픽과 서비스의 용량 프로파일(즉, 서비스가 예약해야 하는 CPU 버퍼의 양)을 기반으로 목표 용량을 계산하고, 목표 용량을 기반으로 서비스의 목표 인스턴스 수를 계산하고 PaaS를 연결합니다. 서비스를 수평으로 확장합니다.

5.2 부하 피드백 탄력성

표적:

실시간에 가까운 서비스 부하 상황에 따라 갑작스러운 트래픽 변화에 대처할 수 있도록 서비스 용량을 적시에 조정합니다.

팽창/수축 전략:

데이터 수집:
일반 모니터링: CPU 사용량, CPU 사용량 등 서비스의 일반 부하를 거의 실시간으로 수집합니다.
맞춤형 모니터링: Prometheus 메트릭 모드에서 서비스 지연 지표, 처리량 지표 등과 같은 맞춤형 비즈니스 모니터링 지표를 지원합니다.
수집 기간은 설정이 가능하며 모니터링 지표를 집계하여 판단하기 위해 슬라이딩 윈도우 방식을 주로 사용합니다.
확장/축소 결정: 서비스의 일반 로드 데이터 및 사용자 지정 로드 데이터에 따라 서비스의 용량 초상화와 결합하여 서비스에 필요한 목표 인스턴스 수를 계산하고 수평 확장 및 축소 작업을 수행합니다.

5.3 타이밍 유연성

표적:

일부 서비스의 트래픽은 비수기 동안 덜 변동합니다. 빈번한 용량 조정이 필요하지 않으며, 피크 및 비수기 기간에는 고정되지만 다른 용량이 예상됩니다.

팽창/수축 전략:

트래픽 프로파일에서 피크 기간과 비 피크 기간 동안 해당 타임 슬라이스의 최대 흐름을 계산합니다.
최대 트래픽 및 용량 프로필을 기반으로 서비스의 피크 및 오프 피크 기간에 해당하는 목표 용량을 계산합니다.
목표 용량에 따라 피크 기간 이전에 정기적으로 확장 동작(수평 확장)을 트리거하고 피크 기간 이후 정기적으로 스케일링 작업(수평 확장)을 트리거하며 전체적인 효과는 아래 그림과 같습니다.

5.4 탄력성 관행

위의 세 가지 유형의 탄력적 정책은 구성에 따라 독립적으로 사용하거나 필요에 따라 조합하여 사용할 수 있습니다.
탄력성이 높은 기능적 컴퓨팅의 경우 로드 피드백 탄력성을 사용하여 FaaS 효과를 얻을 수 있으며 탄력성이 낮은 백엔드 재계산 서비스의 경우 세 가지 유형의 탄력성을 조합하여 사용할 수 있습니다.
세 가지 전략을 조합하여 사용하면 모두 서비스 인스턴스 수를 조정하고 동시에 적용되므로 세 가지 전략 중 타이밍 탄력성 > 예측 탄력성 > 부하 피드백 탄력성의 우선 순위가 있습니다.
부하 피드백 탄력성이 예측 탄력성 또는 타이밍 탄력성과 함께 사용되는 경우 부하 피드백 탄력성은 확장 작업만 수행할 수 있으며 용량을 축소할 수 없으며 용량 확장은 예측 탄력성 또는 타이밍 탄력성에 의해 수행됩니다. 서비스의 CPU 부하가 상대적으로 낮을 때 다음 타임 슬라이스의 트래픽을 미리 대비하기 위해 예측된 탄력성의 확장으로 인해 발생할 수 있기 때문에 부하에 따라 용량을 축소할 수 없습니다. 피드백 탄력성, 타이밍 탄력성도 마찬가지입니다.
재시도 메커니즘:
예측 탄력성과 타이밍 탄력성의 실행 빈도는 낮고 일부 정책 계산을 포함하고 서비스 인스턴스 수를 수정하기 위해 PaaS를 호출합니다.전체 작업은 원자적이지 않으며 재시도 메커니즘이 필요합니다.
부하 피드백은 고주파로 탄력적으로 실행되며 서비스 요구 사항에 따라 요청 시 재시도할 수 있습니다.
대상 용량 검증: 서비스 대상 인스턴스 수를 수정하려면 위의 각 탄력적 정책을 검증해야 합니다.
합리적인 범위 내에서 대상 인스턴스 수를 제한합니다. 대상 인스턴스 수를 각 서비스 용량 프로필에 구성된 인스턴스의 상한 및 하한과 비교하고 초과할 경우 상한 및 하한 임계값으로 평활화합니다.
단일 확장 및 축소의 단계 크기 제한: 목표 인스턴스 수와 현재 인스턴스 수를 비교하고, 각 확장 및 축소의 비율을 제한하고, 단일 확장으로 인해 리소스 부족이 발생하지 않도록 하고, 축소가 너무 많이 발생하여 리소스가 부족해지는 것을 방지합니다. 급증할 단일 인스턴스 트래픽 메모리 옴이 나타납니다.

06 안정성 보장

서비스 용량을 대규모로 자주 동적으로 조정하면서 서비스 안정성을 확보하는 것이 매우 중요한데 점검 및 개입 정지손실 관점에서 해당 안정성 역량을 구축하고 점검을 통해 문제가 발생하기 전에 예방하고 원스톱으로 신속하게 차단합니다. 클릭 개입 손상.

탄력성 검사 : 주기적으로 서비스 인스턴스 마이그레이션을 트리거하고 서비스의 탄력성을 테스트하며 사전 파일 종속성 예외로 인한 스케일링 실패를 미리 노출합니다.

용량 점검 : 다양한 서비스에 대한 경보 정책을 설정하고, 각 서비스의 자원 용량을 주기적으로 점검하여 용량이 부족할 경우 경보 또는 원클릭 계획을 실행합니다.

상태 점검 : 비정상적인 서비스 상태를 방지하기 위해 각 서비스의 상태가 정상적으로 회전하는지 확인합니다.

원클릭 개입 : 서버리스 계획에서 원클릭 종료, 원클릭 인스턴스 소프트 및 하드 제한 계획 열기/닫기 등을 포함하여 용량 저하를 방지하기 위한 빠른 중지 손실 기능, 정기적인 온라인 훈련을 제공합니다.

07 요약

전반적인 작업은 Serverless를 중심으로 이루어지며 탄력성, 트래픽, 용량의 서비스 포트레이트를 통해 각 서비스의 개인화 특성을 설명하고 이를 기반으로 여러 유형의 탄력적 정책을 구성하여 다양한 서비스 확장 시나리오에 맞게 효과적으로 구현합니다. 서비스 리소스의 주문형 사용. 현재 서버리스는 100,000 서비스 인스턴스 규모의 Baidu Feed 비즈니스 라인에 상륙하여 비즈니스 운영 비용을 효과적으로 절감합니다.

다음으로 서버리스는 핫 이벤트에 대한 용량 보장과 트래픽 프로필 예측의 정확성을 개선하기 위한 머신 러닝 적용, 그리고 비즈니스를 위한 가치 창출을 위한 대규모 서비스에 대한 지속적인 액세스라는 두 가지 방향에 초점을 맞출 것입니다!

--끝--

서버리스: 개인화된 서비스 초상화를 기반으로 한 유연한 확장 사례

01 배경

02 아이디어와 목표

03 전체 구조

04 서비스 초상화

4.1 탄력적인 초상화

4.2 트래픽 프로필

4.3 용량 초상화

05 유연한 전략

5.1 예측 탄력성

5.2 부하 피드백 탄력성

5.3 타이밍 유연성

5.4 탄력성 관행

06 안정성 보장

07 요약

Acho que você gosta