625. SLA (Service Level Agreement) 하드웨어 가용성

핵심 인사이트 (3줄 요약)

1. 본질: 서비스 수준 협약 (SLA, Service Level Agreement)은 시스템이 얼마나 오래 살아 있어야 하는지를 숫자로 약속한 계약이며, 하드웨어 가용성 (Availability)을 설계 목표로 바꿔 준다.
2. 가치: 가용성은 평균 고장 간격 (MTBF, Mean Time Between Failures)을 늘리고 평균 수리 시간 (MTTR, Mean Time To Repair)을 줄일수록 올라가며, 9가 하나 늘어날수록 허용 다운타임은 급격히 짧아진다.
3. 판단 포인트: 99.999% 같은 높은 SLA는 좋은 서버 한 대로는 달성되지 않으며, 이중화·자동 절체·지리적 분산·무중단 정비를 함께 설계해야 현실성이 생긴다.

Ⅰ. 개요 및 필요성

서비스 수준 협약 (SLA, Service Level Agreement)은 공급자와 고객이 "이 서비스는 어느 정도까지 멈추지 않아야 하는가"를 수치로 합의한 계약이다. 여기서 핵심 지표인 가용성 (Availability)은 전체 시간 중 실제로 서비스를 이용할 수 있었던 비율을 뜻한다. 즉 SLA는 단순한 홍보 문구가 아니라, 하드웨어 팀과 운영 팀에게 허용 가능한 다운타임 상한을 강제로 제시하는 경영 약속이다.

이 개념이 중요한 이유는 서버가 언젠가는 반드시 고장 나기 때문이다. 디스크, 전원공급장치, 네트워크 인터페이스 카드 (NIC, Network Interface Card), 냉각팬은 각각 고장 확률이 다르고, 데이터센터 자체도 정전·화재·통신 장애를 겪을 수 있다. 따라서 "고장 나지 않게 만들자"만으로는 부족하고, "고장이 나도 서비스가 얼마나 덜 멈추게 할 것인가"까지 함께 설계해야 한다.

SLA가 없으면 고객은 서비스가 몇 시간 멈춰도 기준을 따지기 어렵고, 공급자는 단순 부품 품질만 강조하기 쉽다. 반대로 SLA가 명확하면 설계자는 단일 장애점 (SPOF, Single Point of Failure)을 제거하고, 유지보수 중단 시간까지 포함해 전체 시스템을 바라보게 된다. 결국 SLA는 하드웨어 신뢰성을 비즈니스 손실과 연결하는 공통 언어다.

• 📢 섹션 요약 비유: SLA는 병원이 "응급실은 24시간 절대 멈추지 않는다"고 약속하는 것과 같다. 의사 한 명이 건강한지만 보는 게 아니라, 예비 인력과 비상 발전기까지 준비돼 있어야 그 약속이 지켜진다.

Ⅱ. 아키텍처 및 핵심 원리

가용성은 보통 다음 식으로 이해한다.

$$ Availability = \frac{MTBF}{MTBF + MTTR} $$

즉 고장 사이 간격을 길게 만들수록, 그리고 고장 후 복구 시간을 짧게 만들수록 가용성은 올라간다. 여기서 중요한 점은 비싼 부품만 넣는다고 끝나지 않는다는 것이다. MTBF를 높이는 활동은 좋은 부품, 온도 관리, 예지 정비와 관련이 있고, MTTR를 낮추는 활동은 핫스왑 (Hot Swap), 자동 장애 감지, 클러스터 절체와 연결된다.

아래 그림은 SLA를 높이는 두 축이 무엇인지 보여준다.

┌──────────────────────────────────────────────────────────────────────────┐
│          Availability grows by reducing failures and shrinking repair    │
├──────────────────────────────────────────────────────────────────────────┤
│ Better components / cooling / monitoring  ───────────────▶  MTBF ↑       │
│ Redundancy / failover / hot-swap / automation ───────────▶  MTTR ↓       │
│                                                                          │
│ Result: more uptime under the same business service                      │
└──────────────────────────────────────────────────────────────────────────┘

하드웨어 아키텍처 관점에서는 보통 세 층으로 접근한다. 첫째, 서버 내부에서 전원공급장치·팬·디스크를 N+1 구조로 이중화한다. 둘째, 서버 단위를 넘어 클러스터와 가상 IP 절체로 노드 장애를 숨긴다. 셋째, 데이터센터 단위로는 멀티 AZ (Availability Zone) 또는 원격 재해 복구 센터를 두어 건물 장애까지 흡수한다. 높은 SLA는 결국 부품 → 시스템 → 사이트의 다층 방어로 만들어진다.

• 📢 섹션 요약 비유: SLA를 높이는 일은 튼튼한 타이어만 다는 게 아니라, 예비 타이어와 긴급 출동 서비스까지 함께 준비하는 것과 같다. 고장이 안 나는 차보다, 고장 나도 바로 계속 달릴 수 있는 차가 더 높은 점수를 받는다.

Ⅲ. 비교 및 연결

SLA를 이해할 때 가장 자주 헷갈리는 개념은 신뢰성 (Reliability), 가용성 (Availability), 내결함성 (Fault Tolerance)이다. 셋은 비슷해 보이지만 설계 질문이 다르다.

신뢰성이 높은 장비가 항상 높은 SLA를 만드는 것은 아니다. 예를 들어 서버가 아주 드물게 고장 나더라도, 한 번 고장 났을 때 교체에 6시간이 걸리면 가용성은 급격히 떨어진다. 반대로 고장이 조금 더 자주 나더라도, 핫스왑과 자동 절체가 잘 설계돼 MTTR가 매우 짧다면 더 높은 SLA를 달성할 수 있다.

또한 SLA는 목표 복구 시점 (RPO, Recovery Point Objective), 목표 복구 시간 (RTO, Recovery Time Objective)과도 연결된다. SLA는 서비스 전체의 가동 약속이고, RPO는 데이터 손실 허용치, RTO는 복구 소요 시간 목표다. 즉 SLA가 "얼마나 안 멈출 것인가"를 말한다면, RPO/RTO는 "멈췄을 때 데이터를 얼마나 잃고 얼마나 빨리 돌아올 것인가"를 보완 설명한다.

• 📢 섹션 요약 비유: 신뢰성은 선수가 얼마나 자주 다치는지, 가용성은 시즌 내내 실제 출전한 시간, 내결함성은 주전이 쓰러져도 교체 선수가 즉시 뛰어 경기를 끊지 않는 능력과 같다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 모든 시스템에 5 Nines를 요구하면 비용이 폭발한다. 따라서 먼저 "1분 다운될 때 돈과 신뢰를 얼마나 잃는가"를 계산해 등급을 나누는 것이 중요하다. 예를 들어 사내 게시판은 99.9%면 충분할 수 있지만, 결제 시스템·통신 코어·항공 예약 시스템은 99.99% 이상을 요구할 수 있다.

기술사 답안이나 설계 면접에서는 다음 판단이 핵심이다.

1. 단일 장애점 제거 여부: 전원, NIC, 스위치, 스토리지 경로, 관리자 인증 서버까지 한 군데라도 단일 장애점이 남아 있는가?
2. 정비 시간 포함 여부: 패치, 펌웨어 업그레이드, 스토리지 교체가 서비스 중단 없이 가능한가?
3. 자동 절체 검증 여부: 클러스터가 있다고 끝이 아니라, 실제로 절체 시간이 SLA 예산 안에 들어오는가?
4. 사이트 장애 대응 여부: 랙 장애만 막는 수준인지, 데이터센터 전체 장애까지 고려한 구조인지?

흔한 안티패턴은 "5 Nines가 필요하다"고 말하면서 실제 운영은 수동 복구에 의존하는 경우다. 또 하나는 서비스 크레딧만 보고 안심하는 것이다. SLA 위반 시 환불을 받더라도, 실제 매출 손실과 고객 이탈은 돈 몇 퍼센트로 회복되지 않는다. 따라서 높은 SLA는 계약서 문구보다 구조와 훈련의 문제로 봐야 한다.

• 📢 섹션 요약 비유: 가게 문을 매일 꼭 열어야 한다면, 자물쇠만 튼튼한 것으로는 부족하다. 정전 때 켜질 비상등, 아플 때 대신 나올 직원, 고장 난 POS를 바꿀 예비 장비까지 함께 준비해야 진짜 영업 약속이 된다.

Ⅴ. 기대효과 및 결론

SLA를 기준으로 시스템을 설계하면 장애 대응이 감각이 아니라 수치가 된다. 투자 우선순위가 분명해지고, 어떤 계층에 이중화를 넣어야 하는지, 어느 정도 자동화를 해야 하는지 판단하기 쉬워진다. 또한 고객과 공급자가 같은 다운타임 숫자를 기준으로 대화하므로 책임 경계도 선명해진다.

다만 SLA는 절대 무오류 선언이 아니다. 네트워크 사업자, 전력 인입, 소프트웨어 결함, 인적 실수처럼 하드웨어 밖의 요인도 전체 가용성을 깎을 수 있다. 앞으로는 예지 정비, 텔레메트리 기반 장애 감지, 소프트웨어 정의 인프라가 결합되면서 MTTR를 더 줄이는 방향으로 진화하겠지만, 여전히 핵심은 "어떤 수준의 중단을 비즈니스가 감당할 수 있는가"라는 질문이다.

결국 이 주제는 SLA를 숫자 표가 아니라 비즈니스 약속을 하드웨어 토폴로지로 번역한 결과물로 기억하는 것이 가장 정확하다.

• 📢 섹션 요약 비유: SLA는 "절대 늦지 않겠습니다"라는 선언이 아니라, 늦지 않기 위해 차선 도로·예비 차량·실시간 내비게이션까지 준비해 둔 통학 버스 운영 계획과 같다.

📌 관련 개념 맵

📈 관련 키워드 및 발전 흐름도

단일 서버 안정성 확보
    │
    ▼
부품 이중화 (PSU / NIC / RAID)
    │
    ▼
클러스터 기반 자동 절체
    │
    ▼
멀티 AZ · 원격 재해 복구
    │
    ▼
예지 정비 · 자동화 기반 고가용성 운영

이 흐름은 가용성 설계가 "튼튼한 서버"에서 "장애를 숨기는 서비스 구조"로 확장되는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

1. SLA는 컴퓨터가 "얼마나 오래 안 쉬고 일할 수 있는지" 약속하는 시간표예요.
2. 약속을 지키려면 부품이 고장 나도 바로 바꿔 끼우거나 다른 컴퓨터가 대신 일해야 해요.
3. 그래서 높은 SLA는 좋은 컴퓨터 한 대보다, 서로 도와주는 컴퓨터 여러 대가 더 중요하답니다.