9.7 용량 계획과 수요 예측

개요와 동기

모든 시스템에는 천장이 있습니다. 컴퓨트 코어가 바닥나고, 디스크가 차고, 연결 풀이 고갈되고, 아침에 비어 있던 큐가 점심에 넘칩니다. 용량 계획은 컴퓨트, 저장, 네트워크의 공급을 기대하는 수요에 맞추는 규율로, 정상적인 날은 천장 근처에도 가지 않고 나쁜 날은 파국적이 아니라 우아하게 실패할 만큼의 여유가 있게 합니다. 수요 예측은 나머지 절반입니다. 부하가 얼마나, 언제, 왜 오는지 예측해, 장애 뒤가 아니라 수요보다 먼저 공급이 도착하게 합니다.

이 장은 두 이웃 사이에 앉아 둘 다와 보완적으로 남습니다. 3.5장은 확장성을 아키텍처 속성으로 다룹니다. 무상태, 샤딩, 수평 확장을 통해 시스템이 자랄 수 있도록 어떻게 만들어지는가입니다. 9.1장은 용량이 지켜야 할 신뢰성 목표를 정하는 사이트 신뢰성 엔지니어링(SRE)을 다룹니다. 여기서는 아키텍처를 주어진 것으로, 목표를 고정된 것으로 보고 정량적 질문에 답합니다. 시스템이 예측된 수요와 예측하지 못한 급등을 거치며 서비스 수준 목표(SLO, 9.1장의 신뢰성 목표)를 충족하도록 모든 것을 얼마나 사고, 예약하고, 여유로 쥐고 있어야 하는가. 자동 확장과 성능 엔지니어링(2.16장)은 여기서 쓰는 도구이지만 계획의 대체물이 아니며, 그것들을 계획으로 혼동하는 것은 흔하고 비싼 실수입니다.

큰 팀에게 용량은 엔지니어가 유지하는 스프레드시트이기를 멈추고 많은 서비스가 의존하는 공유 모델이 됩니다. 수백 개의 서비스로 이루어진 플랫폼은 유한한 풀을 공유합니다. 데이터베이스 연결, 메시지 브로커 처리량, 클라우드 계정 할당량, 네트워크 송신입니다. 아무도 전체 그림을 쥐지 않으면 한 팀의 성장이 다른 팀을 굶길 수 있습니다. 기업 환경에서 용량 오류는 놀고 있는 인프라에 낭비된 수백만, 또는 가장 중요한 바로 그 순간의 난처한 장애로 나타납니다. 정부에서는 판돈이 더 날카로워집니다. 세금 마감, 급여 등록 기간, 공중 보건 등록 캠페인은 한 나라의 수요를 몇 시간에 집중시키고, 부하는 선택이 아니라 법으로 의무화되어 있으며, 대중은 스스로 정한 마감에 무너진 사이트를 기억합니다. 용량 계획은 그 약속을 지키는 방법입니다.

핵심 원칙

예측된 수요에 의도적인 여유를 더해 용량을 계획하십시오. 포화 근처에서 돌리지 마십시오.
용량 계획, 자동 확장, 성능 엔지니어링을 분리하십시오. 각각 다른 문제를 풉니다.
지난주만이 아니라 추세, 계절성, 알려진 이벤트, 비즈니스 성장으로 예측하십시오.
추측하거나 프로덕션이 찾을 때까지 기다리지 말고 부하 테스트와 벤치마킹으로 실제 한계를 찾으십시오.
포화 근처의 지연을 경사가 아닌 절벽으로 보십시오. 활용률 목표는 대기열 이론 때문에 존재합니다.
하드 병목을 아십시오. 연결 풀, 할당량, 단일 지점은 자동 확장되지 않습니다.
비용과 신뢰성의 균형을 의도적으로 맞추고, 인시던트 뒤가 아니라 정기 주기로 용량을 리뷰하십시오.

권장 사항

용량 계획, 자동 확장, 성능 엔지니어링을 분리한다

이 세 규율은 흔히 혼동되며, 혼동하면 잘못된 수정을 사게 됩니다. 용량 계획은 몇 주, 분기, 몇 해에 걸쳐 총자원을 얼마나 프로비저닝하고, 예약하고, 예산에 잡아야 하는지라는 중장기 질문입니다. 자동 확장은 분 단위로 부하를 따라 자원을 자동 조정하는 단기 작업입니다. 계획이 프로비저닝한 범위 안에서 움직이게 해 주지만, 예약한 적 없는 할당량을 불러내거나, 차가운 데이터베이스를 데우거나, 단일 인스턴스로만 도는 구성 요소를 확장할 수는 없습니다. 성능 엔지니어링(2.16장)은 작업 단위를 더 싸게 만들어 문제의 모양을 바꾸므로 같은 하드웨어가 더 많은 수요를 서비스합니다.

구별은 실용적입니다. 시스템이 부하 아래서 느릴 때, 자동 확장은 인스턴스를 더하고, 성능 엔지니어링은 각 인스턴스를 빠르게 하고, 용량 계획은 인스턴스를 감당할 수 있는지, 하류 데이터베이스가 그들이 열 연결을 받을 수 있는지 결정합니다. 자동 확장에만 손을 뻗는 팀은 계획한 적 없는 하드 한계에 부딪히고, 성능 엔지니어링에만 손을 뻗는 팀은 계정 할당량이 어차피 한계를 정하는 동안 코드를 최적화합니다. 셋 다 필요하며, 주어진 문제가 어느 것을 요구하는지 알아야 합니다.

추세, 계절성, 이벤트, 비즈니스 성장으로 수요를 예측한다

지난주 평균에 기반한 예측은 모든 흥미로운 순간을 놓칩니다. 네 가지 별개의 구성 요소로 예측을 만드십시오. 추세는 기저의 방향입니다. 수요가 커지는가, 평평한가, 줄어드는가, 얼마나 빠르게? 계절성은 반복되는 패턴입니다. 오전 9시의 일일 피크, 주말의 주간 소강, 휴일 전의 연간 급증입니다. 이벤트 주도 급등은 일회성 집중입니다. 제품 출시, 마케팅 캠페인, 텔레비전 언급, 정부 신고 마감입니다. 비즈니스 주도 성장은 자신의 로드맵이 만드는 수요입니다. 새 시장, 큰 고객 온보딩, 세션당 요청을 세 배로 만드는 기능입니다.

각각에 맞는 기법을 쓰십시오. 추세와 계절성으로 분해한 과거 부하의 시계열은 안정적 수요에 대한 방어 가능한 기준선을 줍니다. 이벤트는 이력이 없으므로 이력에서 외삽할 수 없습니다. 비즈니스와 이야기하고, 로드맵을 읽고, 마케팅과 제품에 무엇을 출시하려는지 묻는 데서 나옵니다. 가장 해로운 용량 실패는 거의 항상 엔지니어링이 듣지 못한 이벤트입니다. 해법은 통계가 아니라 조직적입니다. 제품, 마케팅, 운영이 급등을 프로비저닝할 만큼 충분히 앞서 선언하는 상설 채널입니다.

활용률 목표를 정하고 대기열 이론의 절벽을 존중한다

비용을 아끼려고 인프라를 90퍼센트 활용률로 “뜨겁게” 돌리려는 본능은 덫이며, 그 이유는 11.3장에서 깊이 다루는 대기열 이론입니다. 자원이 완전한 활용률에 접근할수록 대기 시간은 부드럽게 선형으로 오르지 않고 폭발합니다. 50퍼센트 활용률의 서버는 편안한 여유가 있고, 같은 서버가 90퍼센트에서는 지연이 몇 배 나빠질 수 있으며, 95퍼센트에서는 큐가 완전히 폭주할 수 있습니다. 포화 근처의 지연은 경사가 아니라 절벽이며, 사용자는 자원이 기술적으로 “가득 차기” 한참 전에 그 절벽을 타임아웃, 재시도, 오류로 느낍니다.

그래서 용량 계획자는 활용률 목표를 100퍼센트보다 훨씬 낮게, 지연에 민감한 서비스에는 흔히 50퍼센트에서 70퍼센트 범위로, 대기를 견디는 처리량 중심 배치 작업에는 더 높게 정합니다. 목표는 낭비가 아니라 예측 가능한 지연의 대가입니다. SLO에서 목표를 고르십시오. 지연 목표가 엄격하면 활용률 상한이 낮아집니다. 대기열이 만드는 꼬리 지연이 정확히 SLO를 깨뜨리는 것이기 때문입니다. 여유와 안전 마진은 두 방향에서 본 같은 생각입니다. 여유는 정상 부하와 용량 사이의 간극이고, 안전 마진은 그 간극을 높게 나온 예측, 부하를 집중시키는 장애 조치, 보지 못한 급등에 대한 보험으로 표현한 것입니다.

부하 테스트와 벤치마킹으로 실제 한계를 찾는다

측정한 적 없는 한계를 둘러싸고 계획할 수는 없습니다. 부하 테스트는 합성되거나 재생된 트래픽을 시스템에 몰아 부하가 오를 때 지연, 처리량, 오류율이 어떻게 행동하고 어디서 깨지는지 관찰합니다. 벤치마킹은 구성 요소를 따로 측정해 그 천장을 확립합니다. 인스턴스당 초당 요청, 데이터베이스 노드당 초당 쓰기, 브로커 파티션당 초당 메시지입니다. 함께 계획이 필요로 하는 두 숫자를 알려 줍니다. 용량 한 단위가 얼마를 전달하는지, 전체 시스템이 어디서 쓰러지는지입니다.

여러 별개의 테스트를 돌리십시오. 부하 테스트는 예상 피크까지 올려 SLO가 여유와 함께 유지됨을 확인합니다. 스트레스 테스트는 깨지는 지점을 넘어 밀어 시스템이 어떻게 실패하는지 봅니다. 우아하게 저하되는 시스템은 붕괴하는 시스템과 매우 다르기 때문입니다. 소크 테스트는 몇 시간이나 며칠 동안 중간 부하를 유지해 시간이 지나야만 나타나는 메모리 누수, 연결 고갈, 디스크 가득 참 문제를 드러냅니다. 스파이크 테스트는 부하를 갑자기 내리꽂아 자동 확장과 버퍼가 사용자가 알아채기 전에 흡수하는지 확인합니다. 장난감 데이터셋에서 측정한 한계는 거짓말을 하므로 프로덕션과 비슷한 데이터와 토폴로지에 대해 테스트하십시오. 시스템이 바뀔 때 이 테스트를 다시 돌려, 숫자가 1년 전의 시스템이 아니라 지금 가진 시스템을 기술하게 하십시오.

프로비저닝 전략을 의도적으로 고른다

클라우드 제공자는 같은 용량을 가격과 유연성을 맞바꾸는 방식으로 사게 해 주며, 이를 잘 섞는 데서 실제 돈이 절약됩니다. 온디맨드 용량은 유연하고 비쌉니다. 언제든 시작하고 멈출 수 있는 능력에 전체 요율을 치르며, 예측할 수 없고 수명이 짧은 부하에 맞습니다. 예약 용량(1년이나 3년 약정, 또는 절약 플랜)은 계속 쓰겠다는 약속의 대가로 단위당 더 싸며, 안정적 기본선에 맞습니다. 스팟 인스턴스는 남는 용량을 깊은 할인으로 팔지만 거의 예고 없이 회수될 수 있어, 배치 처리와 무상태 워커 같은 장애 허용적이고 중단 가능한 작업에 맞습니다.

통하는 패턴은 층을 이룹니다. 가장 낮은 단위 비용을 위해 안정적 기본선을 예약 용량으로 덮고, 일간과 주간 변동은 온디맨드 자동 확장으로 흡수하고, 할인을 거두려고 중단 가능한 배치 작업을 스팟으로 밀어 넣으십시오. 0에서 확장하는 콜드 스타트 지연을 견딜 수 없는 서비스를 위해 사전 프로비저닝된 용량의 따뜻한 버퍼 풀을 유지해, 갑작스러운 급등이 새 인스턴스가 부팅되는 동안의 큐가 아니라 준비된 용량을 만나게 하십시오. 올바른 배합은 포트폴리오 결정이며 수요 모양과 제공자 가격이 바뀜에 따라 이동하므로 다시 살피십시오.

자동 확장되지 않는 하드 병목을 지도화한다

자동 확장은 위험한 자신감을 키웁니다. 많은 한계가 확장되는 것의 하류에 있고 그것이 움직일 때 움직이지 않기 때문입니다. 데이터베이스 연결 풀이 고전적인 예입니다. 무상태 계층을 10개에서 100개 인스턴스로 확장하면 각각 같은 데이터베이스에 연결을 열고, 데이터베이스는 동시 연결에 하드 상한이 있어 새 연결을 거부하기 시작합니다. 클라우드 계정은 거의 모든 것에 할당량이 있습니다. 리전당 인스턴스, IP 주소, 초당 API 호출, 함수 동시성입니다. 아키텍처의 모든 단일 지점, 곧 주 데이터베이스, 리더 노드, 공유 캐시, 라이선스된 어플라이언스는 다른 곳의 수평 확장이 올릴 수 없는 천장입니다.

이를 명시적으로 만드십시오. 요청과 응답 사이의 모든 하드 한계의 서면 목록을 유지하십시오. 풀 크기, 할당량 값, 단일 인스턴스 구성 요소, 제3자 속도 제한, 라이선스 좌석 수입니다. 각각에 대해 현재 값, 현재 사용량, 한계가 걸리는 부하를 기록하십시오. 이 목록이 전체 시스템을 기술하는 용량 계획과, 연결 풀이 조용히 출시를 끝내기를 기다리는 동안 쉽고 탄력적인 부분만 기술하는 계획의 차이입니다. 제공자의 할당량 증가는 승인에 며칠이 걸릴 수 있으므로 필요보다 앞서 할당량을 올리십시오.

평균이 아니라 피크 이벤트에 맞춰 프로비저닝한다

평균은 중요한 순간을 숨깁니다. 평균 부하에 맞춰 크기를 정한 시스템은 피크에서 실패하며, 많은 조직에게 피크가 바로 요점입니다. 가장 큰 쇼핑일의 소매 급증, 라이브 결승의 스트리밍 급등, 신고 마감의 세금 포털, 등록이 열릴 때의 급여 사이트입니다. 이 명명된 이벤트를 개별적으로 계획하십시오. 비즈니스에서 피크를 추정하고(예상 동시 사용자, 세션당 요청, 보통 날에 대한 배수), 여유와 함께 그 피크에 맞춰 프로비저닝하고, 그 수준에서 부하 테스트하고, 이벤트 중에 허둥대는 대신 이벤트 전에 용량을 준비시키십시오.

출시나 마감을 런북이 있는 운영 이벤트로 다루십시오. 캐시와 버퍼 풀을 미리 데우고, 할당량을 미리 올리고, 그 기간 동안 위험한 배포를 동결하고, 예측이 낮게 나오면 행동할 수 있는 사람을 온콜에 두십시오. 이벤트 뒤에는 실제 피크와 한계에 얼마나 가까웠는지를 포착하십시오. 그 숫자가 내년 계획의 최고 입력이기 때문입니다. 정부 마감은 특별한 주의가 필요합니다. 스스로 부과하고, 공개적으로 알려져 있으며, 옮길 수 없으므로 놀랄 변명도 없고 놀랐을 때 숨을 길도 없습니다.

용량을 계측하고 주기적으로 리뷰한다

용량 계획은 데이터로 돌아가며, 데이터는 9.2장의 관측 가능성에서 옵니다. 모든 제약된 자원(CPU, 메모리, 디스크, 네트워크, 연결 풀, 큐 깊이)의 활용률을 그 한계에 대해 추적해, 여유가 사라지기 전에 줄어드는 것을 볼 수 있게 하십시오. 포화 신호를 직접 지켜보십시오. 큐 길이, 대기 시간, 거부율이 대기열 절벽이 다가오는 것을 드러냅니다. 몇 주에 걸쳐 이를 추세로 보아 현재 성장률에서 자원이 천장에 닿을 때를 예측하고, 현재 값만이 아니라 예측에 알림을 걸어 벽에서가 아니라 벽 전에 프로비저닝하십시오.

용량 리뷰를 인시던트 뒤에만이 아니라 월간이나 분기별의 정기 주기로 여십시오. 각 리뷰에서 예측과 실제 수요를 비교해 모델을 바로잡고, 하드 한계 목록을 훑어 각각에 대해 여유를 확인하고, 다가오는 이벤트와 비즈니스 계획을 보고, 무엇을 예약하고, 올리고, 퇴역시킬지 결정하십시오. 살아 있는 용량 모델을 유지하십시오. 수요 동인을 자원 필요에 매핑하는 단순한 문서나 스프레드시트로, 누구든 “트래픽이 두 배가 되면 데이터베이스는 어떻게 되는가”를 물으면 장애가 아니라 모델에서 답을 얻을 수 있게 합니다. 모델은 결코 완벽하지 않지만, 서면으로 정기적으로 바로잡히는 모델이 언제나 직관을 이깁니다.

장단점

접근	장점	단점
높은 활용률 목표	단위당 더 낮은 비용. 더 적은 놀고 있는 용량	포화 근처에서 지연이 폭발. 급등이나 장애 조치의 여유 없음
넉넉한 여유	예측 가능한 지연. 급등과 장애 조치를 흡수	더 높은 정상 비용. 비효율을 숨길 수 있음
예약 용량	안정적 기본선의 가장 낮은 단가	수요가 줄거나 이동하면 약정 위험
온디맨드 용량	유연. 분 단위로 가변 부하에 맞춤	가장 높은 단가. 예산을 놀라게 할 수 있음
스팟 인스턴스	중단 가능한 작업에 깊은 할인	예고 없이 회수됨. 상태 있거나 지연에 핵심인 작업에 부적합
자동 확장	범위 안에서 부하를 자동으로 따라감	예약된 할당량을 넘을 수 없음. 콜드 스타트. 하류 한계를 가림
버퍼 풀 (따뜻한 용량)	갑작스러운 급등을 즉시 흡수	급등 사이에 놀고 있는 용량에 값을 치름

중심 긴장은 비용 대 신뢰성이며, 둘 다 최적화하는 설정은 없습니다. 날씬하게 돌리면 급등이 포화된 자원을 만나 지연이 대기열 절벽에서 떨어지는 날까지 돈을 아낍니다. 넉넉하게 돌리면 대부분의 시간 놀고 있는 여유에 값을 치르며 편히 잡니다. 두려움이나 인색함이 아니라 SLO로 긴장을 해결하십시오. 예측된 피크에 마진을 더해 신뢰성 목표를 충족할 만큼의 여유를 프로비저닝하고 그 이상은 아니며, 그다음 FinOps(클라우드 지출을 위한 재무 운영, 9.4장)가 SLO를 지키지 않는 낭비를 사냥하게 하십시오. 목표는 의도적인 균형입니다. 여유에 쓴 모든 돈은 알려진 양의 신뢰성을 사려고 의도적으로 샀고, 모든 낭비는 아무것도 사지 않으므로 의도적으로 제거합니다.

팀과 논의할 질문

각 하드 병목이 걸리는 부하를 실제로 알고 있습니까, 아니면 자동 확장이 구해 주리라 가정하고 있습니까? 대부분의 팀은 인스턴스가 자동 확장된다고 말할 수 있고, 대부분은 주 데이터베이스의 동시 연결 한계, 가장 중요한 제3자의 API 속도 제한, 함수 동시성을 한정하는 계정 할당량은 말하지 못합니다. 그것이 출시를 끝내는 한계이며, 무상태 계층이 확장될 때 움직이지 않습니다. 있다면 하드 한계의 서면 목록을 가져오고, 없다면 그 부재가 발견입니다. 각 한계에 대해 세 숫자가 필요합니다. 천장, 오늘의 사용량, 둘이 만나는 수요 수준입니다. 세 가지를 다 내놓을 수 없는 곳은 어디든 희망으로 관리하는 병목입니다.
마지막으로 다가오는 최악의 피크 수준까지 프로덕션과 비슷한 데이터로 부하 테스트한 것은 언제이며, SLO가 여유와 함께 유지되었습니까? 용량 계획은 시스템이 부하 아래서 어떻게 행동하는지에 대한 주장의 집합이고, 테스트되지 않은 주장은 정장을 입은 짐작입니다. 중요한 피크는 지난달 평균이 아니라 다음 출시, 휴일, 마감이며, 테스트는 데이터와 토폴로지가 프로덕션을 닮을 때만 의미가 있습니다. 장난감 데이터셋에서 측정한 한계는 거짓말을 하기 때문입니다. 가장 최근의 스트레스 및 소크 테스트의 결과를 시스템이 어디서 깨졌고 깨질 때 어떻게 실패했는지와 함께 가져오십시오. 정직한 답이 시스템을 일부러 깨지는 지점까지 몰아 본 적이 없다는 것이라면, 그 지점을 프로덕션에서, 최악의 때에, 사용자가 지켜보는 가운데 발견하게 될 것입니다.
제품, 마케팅, 운영은 급등이 일어나기 전에 엔지니어링에 어떻게, 얼마나 앞서 알립니까? 가장 비싼 용량 실패는 모델링 오류가 아닙니다. 트래픽이 도착할 때까지 엔지니어링이 듣지 못한 이벤트입니다. 예측은 이력에서 추세와 계절성을 외삽할 수 있지만 이벤트에는 이력이 없으므로 그것을 계획하는 사람들에게서만 나올 수 있습니다. 최근 세 번의 수요 급등을 가져와 각각에 대해 엔지니어링이 며칠의 경고를 받았는지, 용량을 예약하고 부하 테스트하기에 충분했는지 물으십시오. 원하는 증거는 프로비저닝할 만큼 긴 리드 타임이 있는 상설 채널입니다. 클라우드 할당량 증가만으로도 며칠이 걸릴 수 있기 때문입니다. 채널이 없다면 용량 계획은 그것이 지키려고 존재하는 바로 그 순간에 눈이 먼 것입니다.
지연에 민감한 각 서비스는 실제로 어떤 활용률 목표로 돌아가며, 그 숫자를 비용 목표가 아니라 SLO까지 추적할 수 있습니까? 이것이 중요한 이유는 인프라를 뜨겁게 돌리라는 압력이 끊임없고 청구서는 보지만 대기열 절벽은 보지 못하는 조직의 일부에서 오기 때문이며, 그러므로 목표가 지연 목표에서 적히고 정당화되지 않으면 급등이 가장자리를 찾을 때까지 위로 표류합니다. 경쟁하는 고려는 한쪽의 실제 돈과 다른 쪽의 꼬리 지연이며, 정직한 입장은 100퍼센트 아래의 여유가 잘라 낼 낭비가 아니라 예측 가능한 지연의 대가라는 것입니다. 방이 본능이 아니라 증거로 논쟁하도록 상위 몇 서비스의 현재 활용률, 각각이 지키는 SLO, 부하 아래 그 활용률에서 측정한 지연을 가져오십시오. 하나의 공유 풀이 많은 서비스를 받치는 기업이나 정부 플랫폼에서는 목표를 중앙에서 합의하고 누가 바꿀 수 있는지 기록하십시오. 한 팀이 조용히 자기 상한을 올리면 다른 팀이 의존하는 자원을 모두를 위해 절벽 너머로 밀 수 있기 때문입니다.
예약, 온디맨드, 스팟 용량의 배합은 무엇이며, 마지막으로 다시 살핀 것은 언제이고, 여전히 수요의 모양에 맞습니까? 이 배합이 가장 큰 지속적 절감과 가장 큰 지속적 낭비가 모두 숨는 곳입니다. 온디맨드 요율로 치르는 안정적 기본선은 매시간 돈을 태우고, 과도하게 약정한 예약 포지션은 수요가 이후 넘어서거나 밑으로 줄어든 용량에 값을 치르기 때문입니다. 긴장은 비용 대 유연성과 약정 위험입니다. 예약 용량은 단위당 가장 싸지만 가두고, 스팟은 더 싸지만 예고 없이 회수될 수 있고, 온디맨드는 프리미엄으로 자유를 삽니다. 비용별 현재 배분, 그것이 덮으려는 수요 곡선, 모든 스팟 워크로드의 회수율과 피해 범위를 가져와, 방이 중단 가능한 작업이 정말 중단 가능한지 볼 수 있게 하십시오. 기업과 정부 환경에서는 예약 약정을 조달과 예산 주기에 묶으십시오. 다년 약정과 절약 플랜은 재무와 감사가 지난 분기의 편의가 아니라 예측된 수요에 대해 정당화하기를 원할 재무적 의무이기 때문입니다.
명명된 피크 이벤트가 다가올 때, 사전 데우기, 할당량 상향, 배포 동결, 진행/중단 결정은 누가 소유하며, 연습한 런북으로 적혀 있습니까? 피크 이벤트는 용량 계획이 지키려고 존재하는 순간이며, 계획이 틀려서가 아니라 그날 압박 아래서 그것을 실행할 책임이 아무에게도 없어서 가장 자주 실패합니다. 여기서 경쟁하는 고려는 속도와 자율 대 조율입니다. 팀은 계속 출하하고 싶지만 급증 기간의 위험한 배포는 몇 달의 프로비저닝을 무효로 만들 수 있으므로, 누군가 동결하고 출시를 멈출 권한을 쥐어야 합니다. 다음 큰 이벤트의 런북, 할당량 증가와 버퍼 풀 데우기의 리드 타임, 지난번에 각 역할을 누가 쥐었고 인계가 유지되었는지의 기록을 가져오십시오. 스스로 부과하고, 공개적으로 알려져 있고, 옮길 수 없는 정부 마감에서는 책임 있는 소유자와 에스컬레이션 경로의 이름을 명시적으로 정하십시오. 부하를 덜어 내거나 시민에게 나중에 다시 오라고 요청할 선택지가 없고, 아무도 소유하지 않는 피크는 도착했을 때 아무도 방어하지 않을 피크이기 때문입니다.

분야별 관점

스타트업. 가장 희소한 자원은 엔지니어링의 주의이므로 용량 계획을 싸고 날씬하게 유지하고, 일간 변동은 클라우드 제공자의 탄력성에 기대십시오. 건너뛸 수 없는 한 가지는 자동 확장되지 않는 하드 한계의 서면 목록입니다. 주 데이터베이스 연결 한도, 가장 중요한 제3자 속도 제한, 갑작스러운 기능이나 언론 급등에서 부딪힐 계정 할당량입니다. 첫 실제 급증 전에 프로덕션 크기의 데이터로 정상 피크의 몇 배까지 부하 테스트하십시오. 자동 확장이 주는 취약한 자신감이 바로 데이터베이스가 연결을 거부할 때 깨지는 것이기 때문입니다.

소기업. 용량 전문가도 빠듯한 예산도 없으니 이것을 모델링 프로젝트가 아니라 구매하고 구성하는 문제로 다루십시오. 확장을 대신 흡수하는 관리형 서비스를 선호하고, 폭주하는 청구서나 포화되는 자원이 일찍 보이도록 지출 알림과 단순한 활용률 대시보드를 설정하고, 한 해를 정의할 소수의 명명된 이벤트(계절 성수기, 큰 고객의 가동)를 아십시오. 청구서를 줄이려고 안정적 기본선에는 용량을 예약하고, 수요 모양이 거의 바뀌지 않을 때 유지할 수 없는 예측 기계를 만들지 마십시오.

대기업. 문제는 수백 개 서비스 뒤의 공유되고 유한한 풀이므로 용량은 포트폴리오 거버넌스가 됩니다. 유지되는 하드 한계 목록, SLO에서 중앙에서 도출한 활용률 목표, 실시간 가격에 대해 다시 살피는 예약, 온디맨드, 스팟 용량의 의도적 배합입니다. 모든 팀이 프로덕션과 비슷한 데이터로 같은 방식으로 측정하도록 부하, 스트레스, 소크, 스파이크 테스트를 표준화하고, 사고 전에 줄어드는 여유를 잡는 주기로 용량 리뷰를 돌리십시오. 아무도 전체 모델을 쥐지 않으면 한 팀의 성장이 다른 팀을 굶길 수 있으므로 조율에 명시적으로 예산을 잡으십시오.

정부. 수요가 흔히 법적으로 옮길 수 없고 공개적으로 알려진 마감에 집중되므로, 그 명명된 피크를 특정해 계획하고 넓은 안전 마진으로 프로비저닝하십시오. 부하를 덜어 내거나 시민에게 나중에 다시 오라고 요청할 수 없기 때문입니다. 조달 규칙이 프로비저닝을 형성합니다. 다년 예약 약정과 벤더 할당량 협약은 예측된 수요에 대해 정당화되고 감사를 견뎌야 하므로, 예측, 부하 테스트 증거, 하드 한계 목록을 문서화하고 방어 가능하게 유지하십시오. 가능한 곳에서는 현실적인 기대를 공표하고, 기간 한참 전에 제공자 한도를 올리고, 매 주기 실제 피크를 기록하십시오. 공적 책임은 스스로 정한 마감에 무너지는 포털이 나라 전체가 보는 실패라는 뜻이기 때문입니다.

사례

스타트업. 열 명의 스타트업이 자동 확장 클라우드 인프라에서 소비자 앱을 운영하며 인스턴스 수가 부하와 함께 자라므로 안전하다고 느낍니다. 첫 텔레비전 소개가 한 시간 만에 트래픽을 세 배로 만들고, 무상태 계층은 아름답게 확장되지만 앱은 어쨌든 쓰러집니다. 모든 새 인스턴스가 데이터베이스가 연결 한도에 닿아 거부하기 시작할 때까지 연결을 열었기 때문입니다. 교훈이 실천을 바꿉니다. 데이터베이스 앞에 연결 풀러를 더하고, 요청과 응답 사이의 모든 하드 한계를 적고, 프로덕션 크기의 데이터셋에서 정상 피크의 몇 배까지 부하 테스트합니다. 할인을 위해 안정적 기본선을 예약 용량 약정으로 덮고 다음 급등이 큐가 아니라 준비된 용량을 만나도록 작은 따뜻한 버퍼 풀을 유지합니다. 변경에는 일주일이 들고 그들의 취약한 자신감을 방어할 수 있는 계획으로 바꿉니다.

기업. 한 글로벌 소매업체가 가장 큰 세일 날을 한 해의 용량 이벤트로 다룹니다. 몇 달 앞서 부서 간 팀이 이전 해의 추세와 계절성에 상품 기획을 더해 수요 예측을 만들고, 용량 모델을 통해 예측을 자원 필요로 옮기고, 후한 여유로 예상 피크에 맞춰 프로비저닝합니다. 프로덕션과 비슷한 데이터로 전체 경로를 부하, 스트레스, 소크, 스파이크 테스트하고, 모든 관련 클라우드 할당량을 몇 주 앞서 올리고, 캐시와 버퍼 풀을 미리 데우고, 주변 기간의 위험한 배포를 동결합니다. 예약 용량이 안정적 기본선을 비용을 위해 덮고, 온디맨드 자동 확장이 일간 곡선을 흡수하고, 중단 가능한 배치 작업은 스팟에서 돕니다. 관측 가능성이 이벤트 중 모든 제약된 자원을 한계에 대해 실시간으로 추적하며, 현재 값이 아니라 예측된 포화에 알림을 둡니다. 그날은 소동 없이 지나가며, 이것이 바로 계획이 산 성과입니다.

정부. 한 국세청이 온 나라가 한꺼번에 신고하는 옮길 수 없는 마감 며칠 전에 법적으로 수요가 집중되는 신고 포털을 운영합니다. 기관은 의미 없을 연평균이 아니라 그 피크를 특정해 계획합니다. 이전 해와 인구 데이터에서 동시 신고자를 추정하고, 부하를 덜어 내거나 시민에게 나중에 다시 오라고 요청할 선택지가 없으므로 넓은 안전 마진으로 그 피크에 맞춰 프로비저닝하고, 현실적인 데이터로 예측된 동시성까지 부하 테스트합니다. 팀은 모든 할당량과 단일 장애 지점의 서면 목록을 유지하고, 기간 한참 전에 제공자와 한도를 올리고, 대기열 절벽이 마감 급증에서 멀리 있도록 활용률 목표를 충분히 낮게 정합니다. 신고 시즌마다 실제 피크와 남은 여유를 기록해 다음 해 모델에 공급합니다. 대중은 설계된 바로 그날 서 있는 포털을 보며, 이것이 기관 약속의 요점 전체입니다.

비즈니스 사례: 동기, ROI, TCO

용량 계획의 수익은 반대 방향으로 당기는 두 개의 피한 비용으로 나타나며, 이것이 이 규율을 가치 있게 만듭니다. 과소 프로비저닝은 장애 비용을 치르고, 피크 이벤트 중의 장애가 가장 비쌉니다. 잃은 매출, 잃은 거래, 청중이 가장 클 때의 평판 손상입니다. 가장 큰 날에 내려간 소매 사이트나 신고 마감에 무너진 정부 포털은 단 한 시간의 나쁜 시간으로 수년의 계획 비용을 치릅니다. 과잉 프로비저닝은 반대로 놀고 있는 용량의 클라우드 청구서로 비용을 치르며, 기업 규모에서 단말 군단 전반의 몇 퍼센트 만성 과잉 프로비저닝은 해마다 수백만 달러에 이릅니다. 용량 계획은 의도적인 중간, 곧 피크를 거치며 SLO를 지킬 만큼 충분하고 그 이상은 아닌 것을 찾는 실천입니다.

도입 비용은 도구보다 규율입니다. 수요 예측을 만들고, 하드 한계를 적고, 주기적으로 부하 테스트를 돌리고, 프로비저닝 전략을 섞고, 정기 용량 리뷰를 엽니다. 총소유비용(TCO)은 양쪽에서 동시에 개선됩니다. 더 적은 용량 주도 인시던트가 다운타임과 긴급 대응의 비용을 낮추고, 지속적 크기 조정과 합리적인 예약-스팟 배합이 정상 인프라 청구서를 낮춥니다. 리더십을 설득하려면 용량을 그들이 이미 지켜보는 숫자에 연결하십시오. 과소 프로비저닝을 피크 다운타임 시간당 잃은 매출과 계약상 위약금이 있는 SLO 위반에 묶고, 과잉 프로비저닝을 9.4장의 FinOps 낭비 보고서에 묶으십시오. 논거는 추상적 신중함이 아닙니다. 의도적으로 맞출 수 있는 다이얼의 양쪽에 있는 돈입니다.

안티패턴과 함정

계획으로서의 자동 확장: 데이터베이스 연결 풀, 계정 할당량, 단일 지점이 조용히 시스템 전체를 한정하는 동안 탄력적 인스턴스를 신뢰하는 것.
돈을 아끼려고 뜨겁게 돌리기: 90퍼센트 이상의 활용률을 목표로 해서 지연이 폭발하고 SLO가 깨지는 대기열 절벽을 만나는 것.
피크 대신 평균: 평균 부하에 맞춰 크기를 정해 시스템을 짓게 한 바로 그 피크 이벤트에서 실패하는 것.
이력만으로 예측: 엔지니어링이 듣지 못한 출시나 캠페인을 놓치면서 추세와 계절성을 외삽하는 것.
테스트되지 않은 한계: 아무도 측정하지 않은 깨지는 지점을 둘러싸고 계획한 뒤 최악의 순간에 프로덕션에서 발견하는 것.
장난감 데이터 부하 테스트: 비현실적인 데이터와 토폴로지에서 용량을 측정해 실제 시스템에 대해 거짓말하는 숫자를 만드는 것.
하드 한계 목록 없음: 할당량, 풀, 단일 지점을 서면으로 유지되는 목록이 아니라 기억과 희망으로 관리하는 것.
전부 예약 또는 전혀 예약 안 함: 수요가 넘어서거나 밑으로 줄어드는 예약 용량에 과도하게 약정하거나, 안정적 기본선에 전체 온디맨드 요율을 치르는 것.
인시던트 뒤에만 용량 리뷰: 필요보다 앞서 프로비저닝하는 정기 주기 대신, 계획을 반응적 불 끄기로 다루는 것.

성숙도 모델

1단계, 시작: 용량이 반응적이고 즉흥적입니다. 팀은 자원이 바닥난 뒤에 더하고, 자동 확장이 모든 것을 처리하리라 신뢰하며, 예측도 하드 한계 목록도 부하 테스트도 없습니다. 피크 이벤트는 희망으로 맞이하고, 출시와 마감 중의 장애는 불운으로 다뤄집니다.
2단계, 발전: 기본 실천이 나타나지만 팀마다 다릅니다. 일부 모니터링이 활용률을 보이고, 큰 이벤트 전에 일부 부하 테스트가 이루어지고, 주요 할당량이 알려져 있고, 일부 곳에 대략적인 예측이 있지만, 모델은 유지되지 않고, 하류 병목이 흔히 놓치며, 여유는 SLO가 아니라 경험칙으로 정해집니다.
3단계, 표준화: 용량 계획이 문서화되어 조직 전체에 시행되는 규율입니다. 수요 예측이 추세, 계절성, 이벤트, 비즈니스 성장을 결합하고, 서면 하드 한계 목록이 유지되며, 활용률 목표가 SLO에서 도출되고, 부하, 스트레스, 소크, 스파이크 테스트가 프로덕션과 비슷한 데이터에 대해 주기적으로 돌며, 프로비저닝이 예약, 온디맨드, 스팟을 의도적으로 섞습니다. 상설 채널이 제품과 마케팅에서 엔지니어링으로 이벤트 경고를 나릅니다.
4단계, 관리: 용량이 기준선에 대해 측정되고 통제됩니다. 예측이 매 주기 실제 수요와 비교되어 오차가 추적되고 줄어들고, 활용률, 포화 신호, 모든 하드 한계에 대한 여유가 추세로 보이고 현재 값이 아니라 예측에 알림이 걸리며, 피크 이벤트는 사후에 실제 관찰된 피크에 대해 리뷰되고, 프로비저닝 배합, 예약 약정 커버리지, SLO당 비용이 진행 또는 중단 결정을 관문 통제하는 지표로 보고됩니다. 직관이 아니라 데이터가 무엇을 예약하고, 올리고, 퇴역시킬지 결정합니다.
5단계, 오케스트레이션: 용량 계획이 조직 전체에서 지속적으로 개선되고 통합됩니다. 예측이 자동으로 검증되고 다듬어지고, 포화가 도착하기 전에 예측되어 프로비저닝되고, 프로비저닝 배합이 실시간 가격에 대해 최적화되고, 피크 이벤트는 예행연습된 런북으로 돌고, 비용과 신뢰성이 플랫폼 전체에서 SLO에 대해 의도적으로 균형을 이룹니다. 용량 모델은 수요 모양과 제공자 가격이 이동함에 따라 단말 군단을 재균형하는 공유되고 적응하는 자산입니다.

논의를 위한 아이디어

지연에 민감한 서비스의 현재 활용률 목표는 얼마이며, 돈을 아끼려는 바람이 아니라 SLO와 대기열 행동에서 정당화할 수 있습니까?
어떤 구성 요소가 전혀 자동 확장되지 않으며, 그중 하나가 포화되면 나머지 시스템은 어떻게 됩니까?
다음 분기에 트래픽이 두 배가 되면 어떤 자원이 먼저 천장에 닿으며, 올리려면 며칠의 리드 타임이 필요합니까?
예약, 온디맨드, 스팟 용량의 배합을 어떻게 결정하며, 마지막으로 실제 수요 모양에 대해 다시 살핀 것은 언제입니까?
피크 이벤트가 다가올 때 사전 데우기, 할당량 상향, 진행/중단 결정은 누가 소유하며, 런북으로 적혀 있습니까?
용량 알림이 몇 주 앞서 예측된 포화에 발동합니까, 아니면 벽이 이미 가까울 때의 현재 활용률에만 발동합니까?

핵심 요점

용량 계획은 의도적인 여유와 함께 공급을 예측된 수요에 맞춥니다. 자동 확장(단기, 범위 안)과 성능 엔지니어링(더 싼 작업 단위)과 구별됩니다.
추세, 계절성, 알려진 이벤트, 비즈니스 성장으로 예측하고, 이벤트에는 외삽할 이력이 없으므로 제품과 마케팅에서 이벤트 경고를 받으십시오.
대기열 이론의 절벽(11.3장)을 존중하십시오. 포화 근처에서 지연이 폭발하므로, SLO에서 활용률 목표를 정하고 실제 여유를 쥐십시오.
프로덕션과 비슷한 데이터로 부하, 스트레스, 소크, 스파이크 테스트를 통해 한계를 찾고, 자동 확장되지 않는 하드 병목의 서면 목록을 유지하십시오.
예약, 온디맨드, 스팟 용량을 따뜻한 버퍼 풀과 배합하고, 명명된 피크 이벤트를 개별적으로 계획하고, 장애 뒤가 아니라 주기로 용량을 리뷰하십시오.

참고 문헌과 더 읽을거리

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management