용량 계획
1) 용량 계획이 무엇이며 왜 필요한가
용량 계획은 최소한의 비용으로 목표 SLO를 달성하는 데 필요한 자원을 평가하고 확보하는 체계적인 프로세스입니다. 우리는 CPU/메모리뿐만 아니라 네트워크 대역폭, 스토리지, 데이터베이스/캐시, 대기열/이벤트 버스, 외부 제공 업체 (결제/CCM/사기 방지) 및 인적 자원 (통화 중, 지원) 에 대해서도 이야기하고 있습니다.).
목표:- 봉우리와 분해에서도 SLO/SLA를 수행하십시오.
- TCO 및 자본 초과 프로비저닝을 최소화하십시오.
- 사고로 인한 자원 부족 위험을 줄입니다 (채도 → p99/오류).
- 릴리스 및 캠페인 (마케팅, 토너먼트, 최고 경기) 의 예측 가능성을 확인하십시오.
2) 입력 및 진실의 원천
관찰 가능성: RPS/연결, p50/p95/p99, 오류율, 채도 (CPU, mem, 디스크 IOPS, 네트워크 pps/mbps), 큐 길이, 속도 제한.
비즈니스 이벤트: 캠페인 일정, 계절 (저녁/주말/메가 이벤트), 지역/관할 구역.
기술 부채/기능: 릴리스 로드맵, 아키텍처 변경 (예: 암호화, 새 로깅).
제공자: 지불 할당량 및 처리량/CUS/메일/사기 방지 서비스.
과거의 사건: 병목 현상은 어디에 있습니까 (데이터베이스, 캐시, L7 밸런서, 버스, CNC, 디스크).
3) 기본 개념 및 공식
헤드 룸 - 용량 마진: 'headroom = (max _ stable _ RPS-실제 _ RPS )/max _ stable _ RPS'.
임계 스트림의 경우 20-40% 피크를 목표로합니다.
포화-점유 된 자원과 사용 가능한 자원의 비율 (CPU%, 메모리/GC, 연결, 파일 디스크립터, IOPS, 큐 깊이).
처리량 안정-p99와 오류율이 오랫동안 SLO를 수행하는 속도 (일회성 버스트가 아님).
CU (Capacity Unit) - 서비스의 정규화 된 전력 단위 (예: 포드 vCPU 당 X RPS = 1, RAM = 2 GiB).
시스템 제한은 열화없이 최대입니다: 'N _ pods × CU'. 공유 종속성 (DB/캐시/버스) 을 고려하는 것이 중요합니다.
4) 수요 모델: 예측
통계 시리즈: 주간/일일 계절, 공휴일, 스포츠 결승, 지역 봉우리.
코호트: 국가 별, 지불 제공 업체, 장치, VIP 세그먼트.
이벤트 델타: 캠페인/푸치/릴리스/SEO의 영향.
"What if" (시나리오 계획): 19: 00-22: 00에 트래픽에 + 50%; 공급자 A → 재분배를 B로 떨어 뜨립니다 (+ 30% ~ 대기 시간).
실시간 조정: 현재 리드 메트릭 (세션 재 활성화, 경기 대기열, 바구니) 으로 캐스팅.
5) 공급 모델: 체인이 "파손" 된 곳
문의 컨베이어: Edge/CNC → L7 밸런서 → 애플리케이션 → 캐시 → DB → 외부 API → 턴/타이어 → 핸들러/ETL.
각 링크마다 수정합니다
용량 (CU/인스턴스), 확장 성 (수평선/정점), 한계 (연결, pps, IOPS), 지연.
실패 정책 (속도 제한, 회로 차단기, 저하).
SLO는 로컬이며 e2e-SLO에 기여합니다.
6) 오류 마진 및 예산
헤드 룸을 오류 예산에 묶습니다. 예산이 적거나 재고가 많습니다.
중요한 흐름 (지불/검증) 의 경우 (위의 헤드 룸, 보조 흐름의 경우) 아래입니다.
감기/따뜻한 매장량: 피크/사고시 활성화.
7) 스케일링: 전술
HPA (로드 메트릭 기준): RPS, 대기 시간, 대기열 길이, 사용자 SLI (CPU% 보다 우수).
VPA: 포담 자원의 수정 (상태 및 p99 GC에주의).
KEDA/어댑터: 외부 소스 별 스케일링 (Kafka lag, Redis 목록 길이, CloudQueue 깊이).
따뜻한 수영장/워밍업: 콜드 스타트를 피하기 위해 사전 제기 된 인스턴스.
"코드로드" 접근 방식: 자동 스케일/제한/타임 아웃/리트레이 정책이 다양하고 검토됩니다.
8) 대기열, 역압 및 테일 컨트롤
목표는 눈사태와 같은 p99의 성장을 방지하는 것입니다.
동시성 및 대기열 크기를 제한하고 시간 창을 입력하고 demmpotence를 입력합니다.
헤징/재시도 예산: 사용자와 시스템의 총 시간 예산을 제한합니다.
우수한 저하: 과부하시 보조 기능을 비활성화합니다.
9) DB, 캐시 및 스토리지
DB: 연결 제한, 로깅/FSync, 인덱스, 쿼리 계획, 레플리카 지연, 핫키/테이블, 트랜잭션에 대한 최대 TPS.
Keshi: 세그먼트 별 히트 비율, 릴리스/장애 중 "미스의 폭풍", 주요 배포.
스토리지: IOPS/처리량, 지연, 압축, TTL, 오래된 배치/스냅 샷 청소.
마이그레이션 체계: 정지 잠금없이 → 마이그레이션 → 계약을 확장
10) 이벤트 흐름 및 ETL
카프카/버스: 파티 처리량, 지연, ISR, 압축, 생산자/소비자 제한.
ETL/배치: 창문 시작, 런타임 예산, 스로틀 I/O
중요한 흐름 (지불/잔액) 에 대한 이념과 정확히 한 번의 유사.
11) 네트워크 및 주변
L4/L7 밸런서: 연결 제한, 신 백 로그, TLS 오프로드, 세션 재사용.
CNC/Edge: 원산지 부하를 줄이기위한 대역폭, 캐시 정책.
네트워크 내 한계: VPC/서브넷의 pps/mbps, 출구 비용 (FinOps).
12) 다중 지역, DR 및 관할 구역
전략: 액티브 액티브 액티브 (GSLB/애니 캐스트), 액티브 패시브 (핫/워밍/콜드 DR).
지역별 N + 1: SLO 코어 스트림을 유지하면서 AZ/지역의 손실 유지.
법적 현지화: 국가 별 트래픽/데이터 분할, 다른 제한 및 SLO를 공급자로 분할합니다.
DR 테스트: 실제로로드 전송이있는 정기적 인 게임 일.
13) 외부 제공 업체: 할당량 및 경로
결제/KYC/사기 방지/메일/SMS: TPS, 버스트 할당량, 일일 제한.
다중 공급자: 대기 시간/성공으로 라우팅, 공급자 당 SLO, 자동 페일러.
SLA 계약: e2e-SLO 준수, 에스컬레이션 채널, 상태 웹 후크.
14) FinOps: 비용과 효율성
TCO: 계산 + 스토리지 + 네트워크 탈출 + 라이센스/공급자 + 의무.
단위 경제학: 1k 요청/1 예금 거래/1 KYC 비용.
최적화: 올바른 크기, 스팟/접두사 할인, 캐시 히트 레이트, 로그/트레이스 dedup, 콜드 스토리지 레벨.
적재 시간: "야간" 창과 저렴한 지역의 중요하지 않은 배치.
15) 대시 보드 및보고 (최소 세트)
용량 개요:- 링크에서 전류로드 대 일정한 처리량.
- 서비스 및 지역 별 헤드 룸; 24/72 시간 예측.
- FinOps KPI: $/1k 요청, $/보증금.
- 상단 병목 현상 (p99, 채도, 지연), DR 마진.
- 공급자 성공/대기 시간 및 한계; 노선의 트래픽 비율.
- 업그레이드/인덱스/최적화 계획, 예상 저축/용량 증가.
16) 프로세스 및 역할
RACI: 플랫폼 (인프라/클러스터/밸런서), 데이터베이스/데이터 (인덱스, 복제), 서비스 명령 (프로파일 링/캐시), SRE (SLO, 알림), Sec/Compliance (암호화/로그), 재무 (예산).
리듬: 주간 용량 검토 (로드맵, 예측, 위험), 월간 FinOps 보고서, 분기 별 DR 테스트.
관리 변경: 주요 캠페인/릴리스는 용량 게이트로 이동합니다 (아래 체크리스트).
17) 용량 게이트
- 최대 부하 예측 및 "+ x% 비상 꼬리".
- 핵심 스트림 (결제/ACC/로그인) 에 사용 가능한 헤드 룸.
- 쿼타는 공급자에게 확인되었습니다. 대체 경로가 활성화되어 있습
- HPA/KEDA 임계 값 및 워머 풀이 구성됩니다.
- 대기열/제한 및 저하가 확인되었습니다 (플레이 북 준비).
- 카나리아 주식 및 자동 롤백이 활성화됩니다.
- 대시 보드/경고 (연소율, 채도, p99) 를 확인했습니다.
- DR 계획 및 에스컬레이션 연락처는 관련이 있습니다.
18) 반 패턴
"CPU <70% - 모든 것이 괜찮습니다": 의존성 제한 무시 (DB 연결, IOPS, 대기열).
링크 당 메트릭이없는 중앙 집중식 "블랙 박스" - 한계가 어디에 있는지 이해하는 것은 불가능합니다.
캐시 전략 부족-릴리스 누락으로 킬 원산지.
예산이없는 리트레이 제한 하드 코드는 요청의 폭풍입니다.
"하나의 결제 제공 업체" 는 최고점에서 실패 지점입니다.
따뜻한 매장량을 무시하는 것은 사건의 원인으로 콜드 스타트입니다.
정기적 인 DR 테스트가 없습니다. 필요할 때 계획이 작동하지 않습니다
19) 미니 비용 추정치 (예)
서비스 X: 포드 당 안정적인 350 RPS (vCPU = 1, RAM = 2 GiB). 목표는 5,000 RPS, 헤드 룸 25% 입니다.
전원 필요 = '5000/0. 75 = 6667 RPS '.
Podov = 'ceil (6667/350) = 20'. 따뜻한 수영장 15% → 3 개 이상의 포드.
DB: 12k TPS 한도, 9k TPS 현재 크레딧, 10 피크 예측. 5k TPS → 주식 1. 5k (14%). 8 개로 줄이려면 색인/샤딩/복제품 또는 캐싱이 필요합니다. 5k.
공급자 A (KYC): 쿼터 120 rps, 피크 95 rps, 캠페인 + 40% → 133 rps> 쿼터 → 라우팅 70% A/30% B.
20) 용량 계획 구현 템플릿
1. e2e 경로와 병목 현상을 설명하십시오.
2. CU를 입력하고 각 계층의 지속적인 처리량을 측정하십시오.
3. 모든 링크에서 채도 및 p99 메트릭을 설정합니다.
4. 이벤트/캠페인/릴리스 캘린더를 생성합니다.
5. 코호트 예측 및 What-if 시나리오를 구성하십시오.
6. 스레드 당 및 지역당 핀 헤드 룸 (오류 예산에 구속).
7. HPA/VPA/KEDA + 워머 풀, 제한/배송/대기열을 설정하십시오.
8. 공급자 할당량을 확인하고 다중 경로를 활성화하십시오.
9. 대시 보드 및 주간 리듬 용량 검토를 수집하십시오.
10. 분기 별-DR 연습 및 모델 개정.
21) 결론
용량 계획은 "CPU 추가" 가 아니라 관리 가능한 예측, 아키텍처 제약 및 비용 묶음입니다. "e2e 경로의 각 계층에 측정 용량이 있고 헤드 룸 및 저하 전략이 SLO 및 오류 예산과 관련이있는 경우 피크로드, 캠페인 및 사고는 놀라지 않습니다. 이 접근 방식은 사고의 위험을 줄이고 비즈니스 메트릭을 안정화하며 비용을 최적화합니다.