가용성·용량 관리 — 약속한 만큼 떠 있고, 모자라기 전에 늘린다 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Theoryitsm/availability-capacity

TRACK

ITSM

SLA

55분

LEVEL

중급

PHASES

3단계

ENV

local

INCOMING TICKET

“서비스책임자: "3월엔 새벽에 결제 서버가 1시간 멈췄는데 우리가 약속한 가용성이 몇 %였는지 아무도 답을 못 했고, 11월 블랙프라이데이엔 서버는 살아 있는데 트래픽에 눌려 주문이 40분 먹통이었어요. 이번 계약 갱신 전에 이 서비스는 가용성 몇 %를 약속하고 그 비용이 타당한지, 다가올 이벤트에 용량은 버티는지, 그리고 어디가 죽으면 전체가 죽는지를 숫자로 정리해 주세요."”

YOUR ROLE

IT 서비스 운영(SM)·서비스 관리자

안 하면 나중에

가용성 목표를 숫자로 못 박지 않으면 SLA 위반을 따질 수도 없고, 용량을 피크·추세로 예측하지 않으면 이벤트마다 포화로 매출이 새며, SPOF를 방치하면 앞단을 아무리 두껍게 만들어도 한 지점이 죽을 때 서비스 전체가 함께 멈춘다.

📋상황 브리핑

같은 쇼핑몰, 두 번의 다운.

3월 새벽 2시에 결제 서버가 멈췄고, 당직자가 알아채 재시작하기까지 1시간이 걸렸습니다. 한밤중이라 주문은 거의 없었지만, 사후 회의에서 누구도 "우리가 약속한 가용성이 몇 %였는지" 답하지 못했습니다. 11월 블랙프라이데이 정오에는 평소 5배 트래픽이 몰리자 주문 서비스가 응답을 멈췄습니다 — 서버는 살아 있는데 느린 것이었고, 급히 서버를 늘리려 했지만 반영에 40분이 걸리는 사이 매출이 빠져나갔습니다.

두 사건의 공통점은 기술 실패가 아니라 약속과 예측의 부재입니다. 첫 번째는 "얼마나 떠 있기로 했는가"(가용성)를 숫자로 정하지 않았고, 두 번째는 "얼마나 몰릴지"(용량)를 피크로 내다보지 않았습니다. 이 Lab은 가용성을 계산해 SLA·비용에 연결하고, 용량을 피크·추세로 예측해 장애 전에 늘리며, SPOF를 찾아 이중화로 천장을 올리는 세 가지를 규칙으로 확정합니다.

⏱ 55분📊 중급🔧 3단계#availability#capacity#sla#uptime

MISSION

가용성 지표로 SLA 목표 세우기 — 가동률·MTBF/MTTR을 비용에 건다

가용성을 가동/(가동+중단)과 MTBF/(MTBF+MTTR)로 계산하고, 목표 9의 개수가 허용 다운타임과 비용에 어떻게 걸리는지 저울질해 SLA 목표를 숫자로 확정한다.

용량 계획 — 피크로 예측하고, 장애 전에 늘린다

수요를 평균이 아니라 피크·추세로 예측하고, 성능 임계와 확장 트리거를 미리 정해 부족이 장애로 드러나기 전에 scale up/out으로 대비하는 용량 계획표를 작성한다.

SPOF 제거와 가용성·용량 문제 구분 — 약한 고리부터 이중화한다

구성도에서 단일장애점(SPOF)을 찾아 이중화·HA로 가용성 천장을 올리고, 눈앞의 증상이 가용성 문제(SPOF)인지 용량 문제(자원 부족)인지 구분해 옳은 처방(이중화 vs scale up/out)을 고른다.

📌 선수 지식

• [이론] itsm/availability-capacity

ℹ️ 실습 환경

환경: local

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

Pro로 업그레이드 →

>_ LAB TERMINAL↔ 너비 조절

NOTES