1분 안에 에센스에 대한 간략한 개요
수만 대의 서버가 사용률이 낮다는 것은 엄청난 낭비를 의미합니다. 좋은 용량 관리는 일부 "마지막 순간"의 일시적 긴급 블라인드 또는 과잉 구매를 제거하는 데 도움이 될 수 있습니다. 합리적인 비용 제어 외에도 용량 관리는 고객에게 영향을 미칠 수 있는 비즈니스 개발 및 위험 변경을 예측해야 합니다.
B국은 비용 절감과 효율성 증대를 배경으로 비즈니스 관점에서 전체 용량을 시각적으로 관리하고 있습니다.
저자 
소개 Bilibili의 선임 SRE 전문가 Zhang He
타킨톡스 커뮤니티 전문가 그룹 멤버로 2020년 B국에 합류하여 주국/생방송/OGV/프로모션 검색 관련 SRE 업무를 담당했습니다. 다중 활성, 활동 보증, 카오스 엔지니어링 및 용량 관리 관련 구축에 심층적으로 참여하고 용량 관리 플랫폼 및 카오스 플랫폼의 아키텍처 설계 및 구현을 주도했습니다. Bilibili S 대회의 인프라 보장 업무, 신년 전야회, 신년 인사 등 관련 활동을 담당했으며, 현재는 주로 검색 사업의 안정성 구축과 PaaS 거버넌스 추진을 담당하고 있다.
알림: 이 기사는 약 4,500단어이며 읽는 데 9분이 소요될 것으로 예상됩니다.
독자 교환 그룹에 들어가려면 백그라운드에서 "통신"이라고 회신하고 코스웨어 정보를 얻으려면 "2252"라고 회신하십시오.
배경
B 스테이션의 가장 큰 세 가지 활동은 S 경쟁, 새해 인사, B 스테이션에서의 새해 전야 파티입니다. 사용자 증가 뒤에 SRE 팀은 멀티 액티브, 카오스 엔지니어링 등과 같은 비즈니스 연속성을 보장하기 위해 많은 작업을 수행했습니다.
오늘은 다른 각도에서 "용량 관리"에 대해 이야기해 보겠습니다. 스테이션 B에 용량 관리 플랫폼이 필요한 이유는 무엇입니까? 용량 관리 시스템은 어떻게 설계되었습니까? 플랫폼 측면과 비즈니스 측면에서 어떻게 운영하고 작업을 "시각적"으로 만드나요? 또한 S12 경쟁에서 용량 관리 플랫폼의 실제 적용을 기반으로 "임파워링 비즈니스" 경험을 공유하겠습니다.
1. 스테이션 B에 용량 관리가 필요한 이유는 무엇입니까?
용량 관리를 수행하기 전에 스테이션 B는 아래 그림과 같이 몇 가지 명백한 문제점에 직면했습니다.
알려지지 않은 용량 위험을 해결하는 것 외에도 "비용 절감 및 효율성 증가"를 옹호하는 배경에서 리소스 활용을 개선하고 합리적이고 데이터 지원 예산 결정을 공식화하는 것도 매우 중요합니다.
이전에는 S9, S10 등과 같은 대규모 활동에서 Station B가 내린 용량 결정은 시스템 자체의 용량이 충분한지, 필요한지 여부 등 S12가 참조할 관련 데이터를 축적하지 않았습니다. 얼마나 확장해야 하는지 등 용량 데이터 지원이 적습니다. 또한 연간예산 편성에도 기준용량 자료가 절실히 필요하다.
2. 스테이션 B의 용량 시스템은 어떻게 설계되었습니까?
2.1 다양한 역할의 요구
위의 페인 포인트를 기반으로 서로 다른 역할이 서로 다른 트래픽 지표에 주의를 기울이는 전체 용량 시스템을 설계할 계획입니다. 예를 들어:
R&D 부서: 확장 및 출시를 위한 충분한 리소스가 있는지에 중점을 둡니다. 상대적으로 높은 수준의 R&D 리더는 부서 전체의 자원 활용률과 부서 비용이 합리적인지 등에 더 많은 관심을 기울일 수 있습니다.
플랫폼: 플랫폼의 판매율, 리소스 버퍼, 리소스 활용률 및 기타 작업에 더 많은 관심을 기울여 비용을 줄이고 효율성을 높입니다.
SRE: 핵심 초점은 안정성에 있으며 비용 절감 및 효율성 증가라는 큰 목표를 달성하기 위해 전체 자원의 활용률을 개선하는 것도 필요합니다.
비용 부서: 청구서, 비용, 예산, 리소스 사용 등에 더 많은 주의를 기울여 전체 비용을 절감합니다.
2.2 능력체계의 전반적인 설계
아래에서 위로 맨 아래 계층은 주로 클라우드의 맨 아래 계층으로 편향된 머신, 리소스 풀 등과 같은 기본 데이터(기본 용량)입니다. SRE와 플랫폼은 클러스터의 용량과 리소스 풀의 용량을 더 잘 인식해야 합니다.리소스 풀이 어떻게 초과 판매되거나 규제되는지에 관계없이 전제는 전반적인 기본 리소스 사용이 안전한 수준이어야 한다는 것입니다.
기본 용량을 기반으로 VPA 기반 확장 전략 세트와 인스턴스의 HPA 기반 탄력적 확장을 구축했습니다. 우리는 또한 비즈니스의 리소스 풀과 병합했는데, 풀이 병합된 후 큰 풀에서 각 비즈니스 당사자가 사용하는 리소스를 어떻게 제어할 것인가 하는 문제에 직면할 수 있습니다. 이때 비즈니스에 따라 할당량 관리, 즉 각 비즈니스에서 사용할 수 있는 리소스의 양을 제어해야 합니다.
더 높은 수준에서 우리는 비즈니스를 지원하고 비즈니스 팀의 효율성을 향상시키기 위해 일련의 용량 시각화 및 운영 데이터를 제공합니다. be different 부서의 사용률을 공개 순위로 매기고 데이터를 기반으로 최적화 제안을 제공합니다.이 부분은 나중에 자세히 소개하겠습니다.
3. 용량 운영 및 시각화는 기업이 문제를 해결하는 데 어떻게 도움이 됩니까?
3.1 기본 용량
기본 용량은 전체 용량 시스템의 기초이며 위에서 언급한 바와 같이 클러스터, 리소스 풀, 노드 및 일부 응용 프로그램 차원의 용량 보고서에 더 많은 주의를 기울입니다.
클러스터: 클러스터 용량 수위 및 과매도율에 주의하십시오.
자원 풀: 자원 풀 용량 수위, 초과 판매율 및 자원 중복에 주의하십시오. 자원 사용량은 기계를 적시에 구입해야 하는지 여부를 결정하고 기계가 더 많은 비즈니스를 수행할 수 있는지 여부를 판단합니다.
노드: 노드 리소스 수위와 노드 과매도 비율에 주의하십시오. 과매도는 핫스팟에서 압력을 가져오므로 노드 사용과 관련된 보고서가 작성됩니다.
적용: 사용량, 사용률, 인스턴스 수, 단일 인스턴스 컨테이너 수 등에 중점을 둡니다. 비즈니스는 응용 프로그램 수준의 데이터에 더 많은 주의를 기울입니다. 예를 들어 서비스가 단일 지점인지 여부는 단일 지점은 물리적 시스템이 중단되고 서비스가 이 물리적 시스템에 있는 경우 서비스가 중단됨을 의미하기 때문입니다. 현재 일시적으로 사용할 수 없습니다. 핵심 비즈니스를 위해 허용되지 않는다고 말했습니다.
이러한 지표를 바탕으로 몇 가지 시각적인 인터페이스를 만들었습니다.기본적으로 2주 동안 데이터를 저장하는 외부 모니터링 시스템인 Grafana와 달리 우리 전체 용량 플랫폼의 데이터는 지속적으로 저장됩니다.현재 거의 2년 동안 데이터를 저장하고 있습니다.
3.2 사업 조직 능력
비용을 줄이고 효율성을 높이는 맥락에서 기업이 문제를 해결하도록 돕는 방법은 무엇입니까? 일반적으로 비즈니스 측면에서는 어떤 서비스가 더 많은 용량을 차지하는지, 어떤 비즈니스가 자원 사용률이 상대적으로 낮고 축소가 가능한지, 어떤 비즈니스가 비용이나 사용량의 급격한 증가를 초래했는지, 그리고 비즈니스 거버넌스 또는 아키텍처 이후에 무엇을 찾을 것인지에 더 많은 관심을 기울입니다. 통합 거버넌스가 얼마나 효과적인지 등 전반적인 상황을 이해하는 데 도움이 되는 보다 직관적인 인터페이스가 필요합니다.
그래서 위의 사항을 바탕으로 아래 그림과 같이 비즈니스 조직을 기반으로 한 용량 보고서를 만들었습니다.
B국의 생방송 사업을 예로 들자면, 생방송은 규모가 큰 부서이기 때문에 전체 용량 활용률을 40%로 가정하고, 선물 증정, 추첨 등의 서비스는 자원이 많고 이용률이 낮다고 판단되면, 사업팀은 Visual Report의 정보를 바탕으로 미리 관리하여 더 많은 혜택을 얻을 수 있습니다.
동시에 트렌드 그래프를 기반으로 신규 비즈니스 시나리오, 연구 개발, 갑작스러운 비즈니스 확장 등 생방송 비즈니스에서 갑자기 큰 용량을 차지하는 비즈니스를 확인하고 데이터 드릴을 지원합니다. 아래로 내려가면 수익 비즈니스로 드릴다운하여 알아낼 수 있습니다. 경품 행사인지 선물 제공 비즈니스로 인한 변화인지.
3.3 용량 이벤트
이벤트 소스 관점에서 릴리스 플랫폼/HPA 변경 플랫폼/노드 관리 등 용량 변경을 유발할 수 있는 이벤트가 많으며, 릴리스 플랫폼에서 R&D는 용량을 확장하거나 새로운 서비스를 추가하고 용량 구성을 수정할 수 있습니다. 용량 변경. 또한 HPA의 확장 및 축소, 노드 물리적 머신의 추가 또는 삭제 등도 용량 변경으로 이어집니다.
따라서 다양한 용량 변경 플랫폼을 내부적으로 연결하여 용량 이벤트 관련 기능을 구축하였으며, 기업이 전체 리소스 사용량이 많이 변경된 것을 발견하면 용량 이벤트를 통해 이벤트의 원인을 신속하게 찾고 용량 위험을 적시에 감지할 수 있습니다. 방식 및 추적 용량 변경 근본 원인.
3.4 용량 주간 보고서
용량은 매주 변경되므로 플랫폼은 주간 보고서를 분석합니다.비용, 효율성 및 위험의 세 가지 핵심에서 시작하여 비즈니스 부서와 플랫폼 측의 주간 보고서의 초점은 상당히 다릅니다.
3.4.1 부서 용량 주간 보고서(비즈니스 측면)
비즈니스 측 주간 보고서는 다음 네 가지 사항에 중점을 둡니다.——
** 전체 리소스 용량 및 리소스 사용률이 지난 주와 변경되었습니다. **즉, 지난 주와 비교하여 리소스 사용량이 얼마나 증가 또는 감소했는지입니다.
신청인원 Top . 즉, 어떤 응용 프로그램이 더 많은 자원을 차지하여 기업이 대량 자원을 빠르게 인식하고 비용 절감 및 최적화의 효율성을 향상시킬 수 있습니다.
**상위 위험 애플리케이션(L0/L1 애플리케이션이 먼저 표시됨). **이 부서에 위험도가 높은 애플리케이션이 있는지 여부와 활용도가 높은 핵심 서비스가 있는 경우 사전에 용량을 확장할 수 있습니다.
**1주 볼륨 변경 적용 Top. **즉, 어떤 서비스가 추가되었는지, 어떤 서비스가 확장 및 축소되었는지, 어떤 서비스가 오프라인 상태가 되었는지 등을 한눈에 알 수 있도록 합니다.
(외부 주간 보고서 표시--부서 메인의 전체 자원 활용률)
3.4.2 내부 주간 보고서(플랫폼 측)
플랫폼 측 주간 보고서는 다음 두 가지 사항에 중점을 둡니다.
부서 자원 활용도 및 순위, 부서 능력 최고, 부서 자원 유휴율 최고(5000개 이상의 핵심 부서).
공개 순위를 통해 거버넌스가 취약한 기업을 파악하고 거버넌스의 우선 순위를 정합니다. 동시에 자원 사용량이 많기 때문에 거버넌스에서 우선 순위를 부여해야 하며 플랫폼은 더 큰 거버넌스 이점을 얻을 수 있습니다. 
(내부 주간 보고서 표시-전체 리소스 활용)
3.5 용량 검사
활동 추진이든 일상적인 경영 안정 보장이든 전반적인 역량이 위태로운지 여부에 세심한 주의가 필요하기 때문에 역량 점검 시스템을 갖추고 있습니다.
3.5.1 영업점검
비즈니스 측에서 주목하는 두 가지 측면인 애플리케이션 용량 검사와 할당량 검사에 따라 시각적 표시를 만들었습니다.
최대 사용률이 높은 애플리케이션은 안정성 위험이 있으므로 긴급 확장을 고려해야 하며, 사용률이 낮은 애플리케이션은 리소스 절약을 위해 축소할 수 있는지 여부를 고려해야 합니다.
앞서 언급한 바와 같이 풀을 병합하였기 때문에 풀 병합 후 할당량 사용률이 너무 높은 상황에 주의하여 후속 확장이나 만족스럽지 못한 신규 사업을 피하고 리스크를 사전에 발견하여 그들을 관리하십시오.
3.5.2 플랫폼 검사
플랫폼은 기본 사용률, 예약 가능한 인스턴스 수가 후속 비즈니스 요구를 충족하는지 여부, 리소스 풀이 단일 노드인지 여부 등에 더 많은 관심을 기울입니다. 동시에 플랫폼이 VPA를 다루기 때문에 VPA 조정 후 실패율도 플랫폼과 더 관련이 있습니다.
이를 바탕으로 플랫폼 점검, 리소스 풀 점검 관리, VPA 점검 관리 등을 수행했습니다. 검사 패널에는 상위 위험 리소스 풀/유휴 리소스 풀, 상위 위험 애플리케이션 및 상위 위험 할당량이 그에 따라 표시됩니다.
3.6 용량 관리의 비즈니스 가치
용량 관리를 구현한 후 전체 작업이 비즈니스에 가져오는 도움을 직관적으로 볼 수 있습니다.예를 들어 용량 리소스로 인한 릴리스 문제가 80% 감소하고 용량 문제로 인한 온라인 장애가 90% 감소했습니다. %. 이러한 관점에서 비즈니스 부서는 용량 관리에서 플랫폼과 협력하는 것이 아니라 용량 관리가 구현된 후 비즈니스 요구 사항에 더 빠르고 안정적으로 응답할 수 있도록 하는 궁극적인 비즈니스 목표를 위해 모두가 협력하고 있습니다. 달성할 수 있습니다.
4. 용량 관리는 S12 이벤트를 어떻게 지원합니까?
앞에서 우리는 플랫폼 측면의 기능과 비즈니스 측면의 요구 사항에 대해 이야기했습니다. 다음으로 스테이션 B에서 지난 대규모 이벤트 S12를 예로 들어 특정 비즈니스 시나리오에서 용량 관리 플랫폼의 적용에 대해 자세히 설명하겠습니다. .
4.1 S12 활동 리듬
4.2 S12의 사전 경기 용량 추정
S12 게임 전 용량 추정은 크게 3단계로 나뉜다.
첫 번째 단계는 과거 기본 용량 데이터를 참조하여 용량 델타를 계산하는 것입니다.
S 이벤트나 신년 전야제와 상관없이 B국의 대규모 활동은 몇 년 동안 참고할 수 있는 일부 과거 데이터를 축적했으며 증분은 과거 데이터를 기반으로 계산할 수 있습니다.
예를 들어, S11은 11월에 요약 경기를 개최했고 활동 보장은 8월에 시작되었습니다. 8월의 사용량 a와 S11의 피크 사용량 b를 비교하고 델타 = 1 + (ba) / a를 기준으로 S11을 계산합니다 증분 계수 1.3, 1.5 등과 같은 올해의
두 번째 단계, S12 새 장면, 예상 증분
S12에 원래 기반을 기반으로 몇 가지 새로운 시나리오가 있을 것이라는 점을 고려하면, 이때 비즈니스 목표가 명확해진 후 기술 목표로 변환된 다음 기술 목표가 용량 요구 사항으로 변환되어 예상 증분 d를 얻습니다. .
세 번째 단계는 S12의 용량을 추정하고 자원 격차를 얻는 것입니다.
리소스 준비에서 추가 버퍼는 일반적으로 10% ~ 20%입니다. 예상 총 용량은 8월 S12의 현재 사용량 e와 버퍼를 기준으로 계산할 수 있으며 공식은 다음과 같습니다.
용량 추정치 = (e * 델타 + d ) * (1 + 버퍼 )
예상 용량에서 현재 총 자원 재고를 뺀 이 부분은 전체 자원 격차를 얻을 수 있으며 이를 기반으로 용량을 조정할 수 있습니다.
4.3 S12의 PaaS 풀
4.3.1 풀링 전후 비교
풀링 전 각 물리적 자원 풀은 상대적으로 독립적이며, 아래 그림과 같이 만화 사업의 전체 자원 활용률이 가장 낮고 생방송이 포화 상태에 가까울 수 있습니다. 완전히 독립적인 물리적 리소스 풀, 만화 및 전자 상거래 비즈니스의 유휴 리소스를 활용할 수 없습니다. S11 기간과 같은 이전에는 전체 활동을 지원하기 위해 리소스를 구매하거나 클라우드에서 일시적으로 리소스를 추가해야 했습니다.
S12 경쟁 이전에 만화, 전자 상거래, 라이브 방송과 같은 온라인 마이크로 서비스를 풀링한 후 기업은 더 이상 전체 물리적 리소스 풀에 신경 쓸 필요가 없습니다. 기본 할당 또는 사용률이 아닌 자체 비즈니스 논리 할당량입니다. 물리적 수준에는 온라인 통합 물리적 자원 풀이 있으며 기본 할당 비율과 활용률은 SRE와 플랫폼에서 완전히 보장됩니다.
4.3.2 풀 풀링의 잠재적 위험
풀링 후 일부 불안정한 요소가 있을 수 있습니다.예를 들어, 다른 리소스 풀 또는 다른 비즈니스는 커널 버전이 다를 수 있습니다.따라서 우리는 전체 물리 계층을 표준화하고 커널을 통합하며 de-CPUSET 기본 VPA 정책을 통해 동적으로 전체 리소스 사용량을 조정합니다.
4.4 S12의 할당량 관리
풀링 후 각 사업체는 자원 풀을 공유하므로 각 사업체의 자원 할당량을 세분화하여 관리하여 자원이 무제한 사용되지 않도록 해야 합니다. 여기서는 용량 관리 플랫폼을 통해 관리하며 용량 할당량을 발행하는 논리는 아래 그림과 같습니다.
할당량은 조직의 수에 따라 발행됩니다.예를 들어 조직에서 사용할 수 있는 할당량은 몇 개입니까?정책이 발행된 후 규칙 엔진에 적용됩니다.게시 전과 같이 비즈니스가 변경되면 해당 비즈니스는 규칙 플랫폼에서 학습됩니다 할당량이 충분한지 확인하여 리소스가 충분하지 않으면 할당량이 부족함을 알려줍니다.이 경우 SRE에 문의하여 할당량을 조정하거나 할당량을 수행해야 합니다. 관리. 이러한 방식으로 할당량 제어를 달성하고 전체 리소스 풀이 무분별하게 사용되지 않도록 할 수 있습니다.
4.5 S12의 용량 지원
전체 S12 이벤트 동안 용량 지원은 아래 그림과 같이 HPA, VPA, 탄력적 클라우드 마이그레이션 및 용량 검사의 네 가지 측면으로 크게 나눌 수 있습니다.
4.6 S12 용량 모니터링 패널
S12 이벤트 보증의 경우 전반적인 관심의 핵심 지표는 비즈니스 지표, SLO 및 리소스 포화도이며, 용량 모니터링 패널은 잠재적인 위험 지점을 더 빠르게 찾고 핵심 지표를 기반으로 빠른 의사 결정을 할 수 있도록 도와줍니다.
첫 번째는 비즈니스 지표입니다.S12에서는 1,000만 명, 2,000만 명 이상 등 라이브 방송실의 온라인 사용자 수에 더 많은 관심을 기울입니다. 이벤트 기간 동안 전체 트래픽이 증가하면 온디맨드 비즈니스에도 영향을 미치므로 온라인 온디맨드 수도 우리가 주목하는 비즈니스 지표 중 하나입니다.
SLO에 이어 SRE 팀은 코어 인터페이스의 QPS와 처리량, 지연, 오류율 등에 더 많은 관심을 기울일 것입니다.
마지막은 핵심 서비스 포화, 핵심 미들웨어 포화 등을 포함한 리소스 포화입니다.
5. 향후 계획
5.1 용량 위험 관리
우리는 일부 서비스의 용량 변경 운영에 대한 근거가 없다는 것을 발견했습니다. 예를 들어, 용량 축소를 당연하게 여기고, 프롬프트 또는 검증할 지표 없이 서비스 실패로 이어질 수 있습니다. 따라서 용량 변경 위험 제어를 달성하기 위해 용량 초상화 및 애플리케이션 그룹 패키지를 기반으로 용량 위험 제어 관련 차단 전략을 수행할 것입니다.
5.2 탄력적 확장
첫 번째 블록은 시분할 스케줄링입니다. 기본적으로 밤에 약 1시간의 트래픽이 가장 많은 만화 비즈니스와 다른 시간대의 정상적인 트래픽과 같은 스테이션 B에는 약간의 작은 활동이 있습니다. 밤 0-1시 활동과 같은 시분할 일정을 추가한 후 23시 이전에 미리 용량을 확장하고 이벤트가 끝난 후 용량 축소를 완료할 수 있습니다. 두 번째 블록은 탄력적 예측입니다. 한편으로는 정기적인 유동 압력을 예측하고 용량을 미리 확장할 수 있으며, 다른 한편으로는 모니터링 시스템이 다운된 경우 탄력적 예측 데이터를 모니터링 데이터의 결론으로 사용할 수도 있습니다.
5.3 핫스팟 분리
우리는 소프트 리미트를 기반으로 스케줄링하고 있으며 소프트 리미트도 VPA를 기반으로 조정되지만 여전히 일부 서비스는 물리적 머신에 핫스팟이 있을 수 있으므로 물리적 머신을 기반으로 보조 스케줄링을 수행합니다. (전문)
보조 아가씨(shulie888)를 추가하고 위의 모든 정보를 스크린샷과 함께 무료로 받으세요
그리고 "타킨톡스 독자교류회"에 무료로 가입하세요
면책 조항: 이 글은 원래 공개 계정 "TakinTalks Stability Community" 및 커뮤니티 전문가가 작성한 글입니다. 재인쇄가 필요한 경우 백그라운드에서 "재인쇄"라고 회신하여 승인을 받으세요.
이 기사는 블로깅을 위한 다중 게시물 플랫폼 인 OpenWrite 에서 게시합니다 !