가용성

가용성은 필요할 때 쓸 수 있는 상태에 있는 성질입니다. 고장이 얼마나 드문지를 보는 것이 아닙니다. 지금 요청을 받아낼 수 있는지를 봅니다. 그래서 보통 한 기간 중 쓸 수 있었던 시간의 비율로 잽니다.

상세

동네 편의점은 문을 하루 종일 열어 둡니다. 그래서 아무 때나 가도 살 수 있습니다. 자주 닫더라도 닫힌 시간이 짧으면 갔을 때 열려 있을 확률은 여전히 높습니다.

국제 표준은 가용성을 요구된 대로 수행할 수 있는 상태에 있는 능력으로 적습니다. IEC 60050-192 의 192-01-23 항목입니다. 수행할 수 있는 상태는 켜져 있는 상태와 다릅니다. 시스템은 켜져 있어도 요청을 못 받아낼 수 있습니다. 성질이지 값이 아닙니다. 몇 퍼센트라는 숫자는 이 성질을 재서 얻은 결과입니다.

같은 항목의 주석은 이 성질이 무엇에 달려 있는지를 적습니다. 신뢰성과 회복성, 보전성, 그리고 보전 지원 성능의 결합된 특성에 달려 있다고 적습니다. 고장이 덜 나는 성질 하나로 정해지지 않습니다. 고장 뒤에 돌아오는 성질까지 함께 정합니다.

표준은 정량화를 별도의 절로 미룹니다. 가용성은 192-08 절에 정의된 측도로 정량화할 수 있다고만 적습니다. 구글이 펴낸 사이트 신뢰성 엔지니어링 책은 산식을 두 갈래로 적습니다.

하나는 시간 기준입니다. 정한 기간 중 정상이었던 시간의 비율을 봅니다. 응답을 내주는 시스템에서는 전통적으로 이렇게 계산합니다. 이 값은 흔히 나인의 개수로 적습니다. 99.9% · 99.99% · 99.999% 처럼 씁니다. 나인이 하나 늘 때마다 100% 를 향해 한 자릿수만큼 다가갑니다.

다른 하나는 요청 기준입니다. 전체 요청 중 성공한 요청의 비율을 봅니다. 같은 책은 구글이 이쪽을 쓰는 이유를 적습니다. 구글은 전 세계에 흩어진 서비스를 함께 봅니다. 그래서 시간 기준 지표가 대체로 의미 있지 않다고 적습니다. 가동 시간 대신 요청 성공률로 가용성을 정의한다고 적습니다. 그 갈림이 실제로 어떤 숫자가 되는지는 아래 예시에 있습니다.

배경

부품과 시스템은 요구될 때 요구된 대로 동작해야 합니다. 그 능력을 하나로 묶은 이름이 신인성(dependability)입니다. IEC 60050-192 는 신인성을 요구될 때 요구된 대로 수행할 수 있는 능력으로 적습니다. 그리고 항목의 시간과 관련된 품질 특성을 아우르는 말로 씁니다.

묶어 두기만 하면 무엇이 모자란지 못 짚습니다. 그래서 표준은 신인성 아래에 성질을 갈라 둡니다. 가용성과 신뢰성, 회복성, 보전성, 보전 지원 성능이 그 자리에 나란히 들어갑니다. 경우에 따라 내구성과 안전, 보안까지 들어갑니다.

가용성은 그중 상태를 묻는 자리를 맡습니다. 얼마나 오래 고장 없이 버텼는지는 신뢰성이 답합니다. 고장 뒤에 얼마나 돌아왔는지는 회복성이 답합니다. 가용성은 그 결과로 지금 쓸 수 있는 상태에 있는지를 답합니다.

예시

나인과 연간 허용 정지 시간

구글이 펴낸 사이트 신뢰성 엔지니어링 책은 등급마다 허용되는 정지 시간을 표로 적어 둡니다. 계획된 정지가 없다고 볼 때의 값입니다.

나인이 하나 늘면 허용되는 정지 시간이 한 자릿수만큼 줄어듭니다. 같은 책은 가용성 목표를 99.99% 로 잡은 시스템이 한 해에 최대 52.56분까지 서 있어도 목표 안에 머문다고 적습니다.

하루치 요청으로 잰 가용률

요청 기준으로 재면 같은 목표가 오류 개수로 바뀝니다. 하루에 250만 건을 처리하는 시스템이 일간 가용성 목표를 99.99% 로 잡았다고 합니다. 이 시스템은 그날 오류를 250건까지 내고도 그날의 목표를 맞춥니다. 이 지표는 하루 길이의 이동 창에서 성공한 요청의 비율로 계산합니다.

Amazon EC2 의 월간 가동률

서비스 수준 계약(SLA, Service Level Agreement)은 가용성을 계약서의 숫자로 적습니다. AWS(Amazon Web Services)는 Amazon EC2 를 리전마다 월간 가동률 99.99% 이상으로 제공하겠다고 적습니다. 상업적으로 합리적인 노력을 다하겠다는 말이 그 앞에 붙습니다. 개별 인스턴스 하나에 대한 약속은 99.5% 입니다.

산식도 계약서가 정합니다. 월간 가동률은 100% 에서 그 달 중 Amazon EC2 가 이용 불가 상태였던 분의 비율을 뺀 값입니다.

계약서는 약속을 못 지킨 경우를 따로 적습니다. Amazon EC2 가 리전 단위 약속을 못 지키면 아래 표대로 서비스 크레딧을 받을 자격이 생긴다고 적습니다.

PostgreSQL 의 서버 묶기

제품 문서에서는 가용성이 서버를 여럿 묶는 이야기로 나타납니다. PostgreSQL 문서는 데이터베이스 서버들이 함께 일해 기본 서버가 죽으면 두 번째 서버가 빠르게 넘겨받게 하는 것을 고가용성이라고 부릅니다. 여러 대가 같은 데이터를 서비스하게 하는 것은 부하 분산이라고 부릅니다.

같은 문단이 대가도 적습니다. 읽기 전용 데이터는 서버마다 한 번만 놓으면 됩니다. 쓰기는 다릅니다. 어느 서버에 쓴 것이든 모든 서버로 전파해야 이후의 읽기가 일관된 결과를 냅니다. 이 동기화 문제가 서버들이 함께 일할 때의 근본적인 어려움입니다.

경계

자주 고장 나지만 즉시 복구되는 시스템은 가용성이 높은가. 그렇습니다. 다만 신뢰성은 낮습니다.

두 낱말의 표준 정의를 나란히 두면 갈리는 자리가 보입니다. 가용성은 요구된 대로 수행할 수 있는 상태에 있는 능력입니다. 신뢰성은 주어진 조건에서 주어진 시간 구간 동안 고장 없이 요구된 대로 수행하는 능력입니다. 시간 구간과 고장 없이라는 말은 신뢰성 쪽에만 붙어 있습니다.

stateDiagram-v2
    [*] --> 정상
    정상 --> 고장: 고장 발생
    고장 --> 정상: 복구

신뢰성은 정상 구간이 얼마나 이어지는지를 봅니다. 가용성은 전체 시간 중 정상에 있던 비율을 봅니다. 고장이 잦아도 복구가 즉시 끝나면 정상에 있던 비율은 그대로 남습니다. 그래서 두 값이 반대 방향으로 나올 수 있습니다.

가용성 정의의 주석이 이 자리를 못 박습니다. 가용성은 신뢰성만이 아니라 회복성과 보전성, 보전 지원 성능의 결합된 특성에 달려 있습니다.

관련 항목

신인성 아래 함께 있는 성질

신인성 · 신뢰성 · 회복성 · 보전성 · 보전 지원 성능 · 내구성

가용성을 재는 지표

가동률 · 다운타임 · 나인

가용성 목표를 정하는 계약과 예산

서비스 수준 계약 · 서비스 수준 목표 · 오류 예산

가용성을 올리는 수단

다중화 · 복제 · 스트리밍 복제 · 동기 복제 · 복제 슬롯 · 캐스케이딩 복제 · 장애 조치 · 핫 스탠바이 · 부하 분산

가용성과 헷갈리는 이웃

CAP(Consistency, Availability, Partition tolerance) · 고가용성 · 신뢰성

가용성을 정의하거나 구현하는 표준·제품

IEC 60050-192 · AWS · Amazon EC2 · PostgreSQL