검수요청.png검수요청.png

"가용성"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
잔글 (→‎같이 보기)
 
(사용자 2명의 중간 판 11개는 보이지 않습니다)
2번째 줄: 2번째 줄:
  
 
==개요==
 
==개요==
−
가용성은 가동률과 비슷한 의미로, 수식으로 표현하면 사용 시간(Uptime)을 전체 사용 시간(Uptime+Downtime)으로 나눈 값을 말한다. 가용성은 사용자가 시스템에 접속하거나, 새로운 작업을 제출하거나, 이전 작업의 결과를 수집하는 능력의 정도를 말한다.
+
가용성은 가동률과 비슷한 의미로, 서비스가 다운되지 않고 정상적으로 유지된 시간을 의미한다. 수식으로 표현하면 사용 시간(Uptime)을 전체 사용 시간(Uptime + Downtime)으로 나눈 값을 말한다. 가용성은 사용자가 시스템에 접속하거나, 새로운 작업을 제출하거나, 이전 작업의 결과를 수집하는 능력의 정도를 말한다. 비즈니스 프로세스와 [[데이터베이스]] 솔루션 측면에서 가용성이란 사용자 [[애플리케이션]]의 [[트랜잭션]]을 적절한 시간 내에 처리하는 데이터베이스의 능력에 대한 측정값을 가리킨다. 데이터베이스 솔루션의 가용성 요구사항은 비즈니스 요구에 의해 결정된다. 예를 들어 데이터베이스 솔루션이 오전 9시에서 오후 5시까지 영업하는 상점에서 사용되는 경우 데이터베이스는 매일 밤 오후 5시 1분부터 오전 8시 59분까지 오프라인일 수 있지만, 가용성은 여전히 높은 것으로 간주된다. 반면에 같은 데이터베이스 솔루션을 여러 시간대에 걸쳐있는 상점의 체인에서 사용하는 경우 가능한 가동 중지 시간은 적어지게 될 것이다. 또 이 데이터베이스 솔루션을 매일 24시간 고객에게 서비스를 제공해야 하는 온라인 비즈니스에 사용하는 경우 데이터베이스가 오프라인이 되면 고객에게 영향을 줄 수밖에 없음으로 가용성은 매우 중요한 사안이 된다. 이 값이 높으면 높을수록 "가용성이 높다"라고 표현하며, 가용성이 높은 것을 [[고가용성]]이라고 한다.<ref name="위키백과 고가용성">High availability wikipedia - https://en.wikipedia.org/wiki/High_availability</ref><ref>한국데이터산업진흥원, 〈[https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=135&dbnum=128493&mode=detail&type=techreport 가용성 향상(계획된 다운타임 최소화) 방안, Part 1: DB 시스템의 가용성이란?]〉</ref>
  
−
비즈니스 프로세스와 데이터베이스 솔루션 측면에서 가용성이란 사용자 애플리케이션의 트랜잭션을 적절한 시간 내에 처리하는 데이터베이스의 능력에 대한 측정값을 가리킨다.
+
==특징==
 +
===관련 용어===
 +
*'''업 타임'''(Uptime) : 시스템 신뢰성의 척도로, 일반적으로 컴퓨터가 작동하고 사용 가능한 시간의 백분율로 표현된다. 가동 시간은 다운 타임과 반대다. 업타임은 컴퓨터가 고장 나지 않고 놔둘 수 있는 시간이나 유지 및 보수를 위해 재부팅을 해야 하는 시간을 나타낸다. 이 덕분에 업타임은 컴퓨터 운영체제의 신뢰성이나 안정성을 측정하는 척도로 자주 사용된다. 하지만, 일부 중요한 업데이트는 이부 플랫폼에서 재부팅을 요구할 수도 있어 긴 가동 시간이 좋은 것 만은 아니다. 업타임은 윈도우즈, 프리도스(FreeDOS), 리눅스, BSD, OpenVMS에서 사용할 수 있다.<ref>wikipedia Uptime - https://en.wikipedia.org/wiki/Uptime</ref>
 +
*'''다운 타임'''(Downtime) : 시스템을 사용할 수 없는 기간을 나타내기 위해 사용된다. 다운타임은 시스템이 주요 기능을 제공하거나 수행하지 못하는 기간은 나타내는데, 이는 신뢰성, 가용성, 복구 및 사용 불가가 관련된 개념이다. 여기서 사용 불가란 시스템을 사용할 수 없거나 오프라인 상태인 시간 범위의 비율이다. 이는 보통 시스템이 계획되지 않은 사건이나 일상적인 유지 및 보수로 인해 작동하지 못한 결과로 나타난다.<ref>Downtime wikipedia - https://en.wikipedia.org/wiki/Downtime</ref>
  
−
데이터베이스 솔루션의 가용성 요구사항은 비즈니스 요구에 의해 결정된다. 예를 들어 데이터베이스 솔루션이 오전 9시에서 오후 5시까지 영업하는 상점에서 사용되는 경우 데이터베이스는 매일 밤 오후 5시 1분부터 오전 8시 59분까지 오프라인일 수 있지만 가용성은 여전히 높은 것으로 간주된다. 반면에 같은 데이터베이스 솔루션을 여러 시간대에 걸쳐있는 상점의 체인에서 사용하는 경우 가능한 가동 중지 시간은 적어지게 될 것이다. 또 이 데이터베이스 솔루션을 매일 24시간 고객에게 서비스를 제공해야 하는 온라인 비즈니스에 사용하는 경우 데이터베이스가 오프라인이 되면 고객에게 영향을 줄 수 밖에 없으므로 가용성은 매우 중요한 사안이 된다.
+
===논리적 계산===
−
이 값이 높으면 높을수록 "가용성이 높다"라고 표현하며, 가용성이 높은 것을 [[고가용성]]이라고 한다.<ref name="위키백과 고가용성">위키백과 High availability - https://en.wikipedia.org/wiki/High_availability</ref><ref>한국데이터산업진흥원, 〈[https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=135&dbnum=128493&mode=detail&type=techreport 가용성 향상(계획된 다운타임 최소화) 방안, Part 1: DB 시스템의 가용성이란?]〉</ref>
+
다음은 가용성의 식이다. 사용 시간(Uptime)을 전체 사용 시간(Uptime + Downtime)으로 나눈 값을 말한다. 이때, 가용성으로 나올 수 있는 값은 0~1 사이의 숫자로 소수자리를 포함한다. 값이 높을수록 가용성이 높다는 의미이며 주로 백분율화하여 곱하기 100을 하여 표기한다.
 +
<math>Availability=\frac{Uptime}{Uptime+Downtime}</math>
  
−
==용어==
+
이에 대해 "사이트 신뢰성 엔지니어링"은 더 섬세하게 정의한다.
−
===업 타임===
 
−
업타임은 시스템 신뢰성의 척도로, 일반적으로 컴퓨터가 작동하고 사용 가능한 시간의 백분율로 표현된다. 가동 시간은 다운 타임과 반대다. 업타임은 컴퓨터가 고장 나지 않고 놔둘 수 있는 시간이나 유지 및 보수를 위해 재부팅을 해야 하는 시간을 나타낸다. 이 덕분에 업타임은 컴퓨터 운영체제의 신뢰성이나 안정성을 측정하는 척도로 자주 사용된다.
 
−
하지만, 일부 중요한 업데이트는 이부 플랫폼에서 재부팅을 요구할 수도 있어 긴 가동 시간이 좋은 것 만은 아니다. 업타임은 윈도우즈, 프리도스(FreeDOS), 리눅스, BSD, OpenVMS에서 사용할 수 있다.<ref>위키백과 Uptime - https://en.wikipedia.org/wiki/Uptime</ref>
 
−
===다운 타임===
 
−
다운 타임은 시스템을 사용할 수 없는 기간을 나타내기 위해 사용된다. 다운타임은 시스템이 주요 기능을 제공하거나 수행하지 못하는 기간은 나타내는데, 이는 신뢰성, 가용성, 복구 및 사용 불가가 관련된 개념이다. 여기서 사용 불가란 시스템을 사용할 수 없거나 오프라인 상태인 시간 범위의 비율이다. 이는 보통 시스템이 계획되지 않은 사건이나 일상적인 유지 및 보수로 인해 작동하지 못한 결과로 나타난다.<ref>위키백과 Downtime - https://en.wikipedia.org/wiki/Downtime</ref>
 
  
−
==논리적 계산==
+
<math>Availability=\frac{MTRF}{Uptime+(unplanned)Downtime}</math>
−
<math>Availability=\frac{Uptime}{Uptime+Downtime}</math>
 
  
−
이 식은 가용성의 식이다.
+
다음은 트랜잭션 처리의 원리에서 정의하는 가용성은 또 다르다. TP 시스템에 필요한 중요한 요구사항은 시스템이 항상 가동상태를 유지해야 한다는 것이다. 이것은 가용성이 매우 높은 시스템이어야 한다는 뜻이다. 그런 시스템을 흔히 24X365라고도 하는데, 매일 24시간 연간 365일, 즉 연중무휴로 가동하는 시스템이라는 의미이다. 가용성은 두 가지 요인에 의해서 감소하는데, 그중 한 요인은 시스템에 장애가 발생하는 비율이다. 장애라는 말은 시스템이 잘못 응답하거나 응답을 하지 않음을 의미한다. 시스템의 다른 조건이 같을 때 장애가 자주 발생한다면 그 시스템은 가용성이 낮다고 말한다. 다른 요인 하나는 복구 시간이다. 시스템의 다른 조건이 같을 때 장애가 발생한 이후에 시스템을 복구하는 데 걸리는 시간이 길어질수록 시스템의 가용성은 낮아진다. 이런 개념은 평균가동시간(mean time between failure,MTBF)과 평균 복구 시간(mean time to repair,MTTR)으로 표현된다. 평균가동시간은 장애가 발생하기 전에 시스템이 가동되는 평균가동시간이다. 평균 복구 시간은 장애가 발생한 이후에 시스템을 수리하거나 복구하는 데 걸리는 시간을 뜻한다. 이 두 척도를 이용하여 가용성을 다음과 같이 정의할 수 있다. 그러므로 가용성은 신뢰성이 증가하고, 복구 시간이 감소할수록 향상된다.
  
−
이것에 대해 "사이트 신뢰성 엔지니어링"은 더 섬세하게 정의한다.
+
<math>Availability=\frac{MTBF}{MTBF+MTTR}</math>
  
−
<math>Availability=\frac{MTRF}{Uptime+(unplanned)Downtime}</math>
 
  
−
다음은 "트랜잭션 처리의 원리"에서 말하는 것이다.
+
"사이트 신뢰성 엔지니어링"에서는 시간 기준의 가용성을 대안으로 요청 성공률에 기초한 가용성을 정의한다. 그러나 구글에서는 시간 기준의 가용성 지표는 그다지 의미가 없다. 그 이유는 우리는 전 세계에 분산된 서비스를 운영하기 때문이다. 구글이 채택하고 있는 장애 분리(fault isolation) 방식 덕분에 우리는 특정 서비스의 트래픽 중 일부를 주어진 시간 동안 세계의 어느 한 지역에 제공하고 있는 셈이다. 다시 말하면, 전체 시간 중 최소 일부는 '정상 동작 중인' 상태다. 그래서 우리는 업타임과 관련된 지표들 대신 요청 성공률(request success rate)에 기초한 가용성을 정의한다. 아래의 식은 특정한 운영 시간 대비 성공률에 기반한 지표들을 계산하는 수식이다."
−
"TP 시스템에 필요한 중요한 요구사항은 시스템이 항상 가동상태를 유지해야 한다는 것이다. 이것은 가용성이 매우 높은 시스템이어야 한다는 뜻이다. 그런 시스템을 흔히 24X365라고도 하는데, 매일 24시간 연간 365일, 즉 연중무휴로 가동하는 시스템이라는 의미이다. 가용성은 두 가지 요인에 의해서 감소하는데, 그중 한 요인은 시스템에 장애가 발생하는 비율이다. 장애라는 말은 시스템이 잘못 응답하거나 응답을 하지 않음을 의미한다. 시스템의 다른 조건이 같을 때 장애가 자주 발생한다면 그 시스템은 가용성이 낮다고 말한다. 다른 요인 하나는 복구 시간이다. 시스템의 다른 조건이 같을 때 장애가 발생한 이후에 시스템을 복구하는 데 걸리는 시간이 길어질수록 시스템의 가용성은 낮아진다. 이런 개념은 평균가동시간(mean time between failure,MTBF)과 평균 복구 시간(mean time to repair,MTTR)으로 표현된다. 평균가동시간은 장애가 발생하기 전에 시스템이 가동되는 평균가동시간이다. 평균가동시간은 시스템이 가진 신뢰성의 척도를 대표한다. 평균 복구 시간은 장애가 발생한 이후에 시스템을 수리하거나 복구하는 데 걸리는 시간을 뜻한다. 이 두 척도를 이용하여 가용성을<math>\frac{MTBF}{MTBF+MTTR}</math>로 정의할 수 있다. 그러므로 가용성은 신뢰성이 증가할수록, 복구 시간이 감소할수록 향상된다."
 
  
−
<math>Availability=\frac{MTBF}{MTBF+MTTR}</math>
+
가용성 = 성공한 요청 수 / 전체 요청 수
−
===요청 성공률을 기초로 한 가용성===
 
−
"사이트 신뢰성 엔지니어링"에서는 시간 기준의 가용성을 대안으로 요청 성공률에 기초한 가용성을 정의한다.
 
−
"그러나 구글에서는 시간 기준의 가용성 지표는 그다지 의미가 없다. 그 이유는 우리는 전 세계에 분산된 서비스를 운영하기 때문이다. 구글이 채택하고 있는 장애 분리(fault isolation) 방식 덕분에 우리는 특정 서비스의 트래픽 중 일부를 주어진 시간 동안 세계의 어느 한 지역에 제공하고 있는 셈이다(다시 말하면, 우리는 전체 시간 중 최소 일부는 '정상 동작 중인' 상태다). 그래서 우리는 업타임과 관련된 지표들 대신 요청 성공률(request success rate)에 기초한 가용성을 정의한다. 아래의 식은 특정한 운영 시간 대비 성공률에 기반한 지표들을 계산하는 수식이다."
 
−
 
 
−
가용성=성공한 요청 수 / 전체 요청 수
 
  
 
예를 들어 하루에 250만 개의 요청을 처리하는 시스템의 경우 하루에 발생하는 에러가 250개 이내라면 일일 가용성 목표치 99.99%를 달성할 수 있다.<ref name="티스토리">기계인간 John Grib , 〈[https://johngrib.github.io/wiki/availability/#fn:high-availability 가용성(Availability)시스템이 다운되지 않고 정상 운영되는 시간의 비율]〉, 《티스토리》, 2020-07-13</ref>
 
예를 들어 하루에 250만 개의 요청을 처리하는 시스템의 경우 하루에 발생하는 에러가 250개 이내라면 일일 가용성 목표치 99.99%를 달성할 수 있다.<ref name="티스토리">기계인간 John Grib , 〈[https://johngrib.github.io/wiki/availability/#fn:high-availability 가용성(Availability)시스템이 다운되지 않고 정상 운영되는 시간의 비율]〉, 《티스토리》, 2020-07-13</ref>
  
−
==고가용성==
+
===고가용성===
 
고가용성은 일반적인 가용성보다 더 높은 수준의 성능을 보장하는 것이 목표인 시스템이다. 현대화로 인하여 고가용성에 대한 의존도가 증가하였는데, 대표적으로 병원과 데이터센터가 있다. 이 두 곳은 그들의 업무를 위해 시스템에 대한 높은 가용성을 요구하기 때문에 고가용성을 필요로 한다.<ref name="위키백과 고가용성"></ref>
 
고가용성은 일반적인 가용성보다 더 높은 수준의 성능을 보장하는 것이 목표인 시스템이다. 현대화로 인하여 고가용성에 대한 의존도가 증가하였는데, 대표적으로 병원과 데이터센터가 있다. 이 두 곳은 그들의 업무를 위해 시스템에 대한 높은 가용성을 요구하기 때문에 고가용성을 필요로 한다.<ref name="위키백과 고가용성"></ref>
−
===원리===
 
 
신뢰성이 높은 시스템이 고가용성을 달성하는 데 도움이 되는 세 가지 원칙이 있다.
 
신뢰성이 높은 시스템이 고가용성을 달성하는 데 도움이 되는 세 가지 원칙이 있다.
 
#단일 고장 지점 제거 : 구성요소 중 하나가 고장이 났을 때 이것이 전체 시스템에 문제를 일으키지 않도록 시스템 내에 중복성을 추가하는 것을 말한다.
 
#단일 고장 지점 제거 : 구성요소 중 하나가 고장이 났을 때 이것이 전체 시스템에 문제를 일으키지 않도록 시스템 내에 중복성을 추가하는 것을 말한다.
45번째 줄: 35번째 줄:
 
#위의 두 가지 원칙을 준수한다면 보통의 경우 고장이 일어나지 않지만, 유지 관리 활동을 반드시 해주어야 한다.<ref name="위키백과 고가용성"></ref>
 
#위의 두 가지 원칙을 준수한다면 보통의 경우 고장이 일어나지 않지만, 유지 관리 활동을 반드시 해주어야 한다.<ref name="위키백과 고가용성"></ref>
  
−
===예약된 다운타임 및 예약되지 않은 다운타임===
+
* '''예약된 다운 타임 및 예약되지 않은 다운 타임''' : 예정된 것과 예정되지 않은 다운 타임이 있다. 보통, 예정된 다운 타임은 시스템 작동에 영향을 주는 유지보수의 결과이다. 일반적으로 현재 설치된 시스템 설계로는 피할 수 없는데, 이는 재부팅이 필요한 시점을 설정하여 해결할 수 있다. 그리고 예정되지 않은 다운 타임은 보통 하드웨어나 소프트웨어 오류 등 여러 물리적 문제에서 발생한다. 이에 대한 예시로는 정전, CPU 또는 RAM 구성요소의 고장, 미들웨어 및 운영체제 장애 등이 있다.<ref name="위키백과 고가용성"></ref>
−
예정된 것과 예정되지 않은 다운 타임이 있다. 보통, 예정된 다운 타임은 시스템 작동에 영향을 주는 유지보수의 결과이다. 일반적으로 현재 설치된 시스템 설계로는 피할 수 없는데, 이는 재부팅이 필요한 시점을 설정하여 해결할 수 있다.
+
 
−
그리고 예정되지 않은 다운 타임은 보통 하드웨어나 소프트웨어 오류 등 여러 물리적 문제에서 발생한다. 이에 대한 예시로는 정전, CPU 또는 RAM 구성요소의 고장, 미들웨어 및 운영체제 장애 등이 있다.<ref name="위키백과 고가용성"></ref>
+
* '''백분율 계산''' : 가용성은 보통 특정 시간의 가동 시간 백분율로 표현된다. 아래의 표는 시스템이 연속적으로 작동해야 한다고 가정할 때의 특정 가용성이 가진 비율에 대해 허용되는 다운 타임을 보여준다. 업타임과 가용성은 조건에 한해 동의어로 사용될 수 있다. 즉, 시스템은 가동될 수 있으나, 네트워크가 중단되는 경우처럼 그 시스템을 갑작스럽게 이용하지 못할 수도 있다. 이것들은 가용성 있는 시스템으로 보일 수 있지만, 이 서비스들은 기능적 관점까지는 올라가지 않는다.<ref name="위키백과 고가용성"></ref>
  
−
===백분율 계산===
+
<table border="1" align="center" tdalign="center" style="text-align:right;  width=750>
−
가용성은 보통 특정 시간의 가동 시간 백분율로 표현된다. 아래의 표는 시스템이 연속적으로 작동해야 한다고 가정할 때의 특정 가용성이 가진 비율에 대해 허용되는 다운 타임을 보여준다.<table border="1" align="center" tdalign="center" style="text-align:right;  width=750>
 
 
<caption side:top;><font size=5><b>가용성 백분율</b></font></caption>
 
<caption side:top;><font size=5><b>가용성 백분율</b></font></caption>
 
<caption style="text-align:right; caption-side:bottom;"><b>다운타임 : 시스템을 사용할 수 없는 기간</b></caption>
 
<caption style="text-align:right; caption-side:bottom;"><b>다운타임 : 시스템을 사용할 수 없는 기간</b></caption>
92번째 줄: 81번째 줄:
 
<td style="text-align:left;">99.9999999%("9 아홉 개")<td>31.56㎳<td>2.63㎳<td>604.80㎲<td>86.40㎲</tr>
 
<td style="text-align:left;">99.9999999%("9 아홉 개")<td>31.56㎳<td>2.63㎳<td>604.80㎲<td>86.40㎲</tr>
 
</table>
 
</table>
−
업타임과 가용성은 조건에 한해 동의어로 사용될 수 있다. 즉, 시스템은 가동될 수 있으나, 네트워크가 중단되는 경우처럼 그 시스템을 갑작스럽게 이용하지 못할 수도 있다. 이것들은 가용성 있는 시스템으로 보일 수 있지만, 이 서비스들은 기능적 관점까지는 올라가지 않는다.<ref name="위키백과 고가용성"></ref>
 
  
−
===고가용성 관련 밀접 개념===
+
* '''고가용성 관련 밀접 개념''' : 복구 시간 목표(RTO)라고도 하는 복구 시간(예상 수리 시간)은 가용성과 밀접한 관련이 있다. 이 시간은 계획된 운영 중단에 필요한 총 시간 또는 계획되지 않은 운영 중단에서 완전히 복구하는 데 걸리는 시간이다. 또 다른 지표로는 평균 복구 시간(MTTR)이 있는데, 복구 시간은 특정 시스템 설계 및 고장 시 무한정 길어질 수 있다. 즉 완전한 복구가 불가능 할 수도 있다는 의미이다. 그러한 예로는 2차 재해 복구 데이터 센터가 없을 때 데이터 센터와 그 시스템을 파괴하는 화재나 홍수가 있다.
−
복구 시간 목표(RTO)라고도 하는 복구 시간(예상 수리 시간)은 가용성과 밀접한 관련이 있다. 이 시간은 계획된 운영 중단에 필요한 총 시간 또는 계획되지 않은 운영 중단에서 완전히 복구하는 데 걸리는 시간이다. 또 다른 지표로는 평균 복구 시간(MTTR)이 있는데, 복구 시간은 특정 시스템 설계 및 고장 시 무한정 길어질 수 있다. 즉 완전한 복구가 불가능 할 수도 있다는 의미이다. 그러한 예로는 2차 재해 복구 데이터 센터가 없을 때 데이터 센터와 그 시스템을 파괴하는 화재나 홍수가 있다.
+
:또 다른 관련 개념은 데이터 가용성인데, 그것은 데이터베이스와 다른 정보 스토리지 시스템이 시스템 거래를 충실히 기록하고 보고하는 시스템이다. 정보 관리는 자주 발생하는 다양한 장애 문제에서 허용되는 데이터 손실을 결정하기 위해 데이터 가용성 또는 복구 지점 목표에 별도로 초점을 맞춘다.<ref name="위키백과 고가용성"></ref>
−
또 다른 관련 개념은 데이터 가용성인데, 그것은 데이터베이스와 다른 정보 스토리지 시스템이 시스템 거래를 충실히 기록하고 보고하는 시스템이다. 정보 관리는 자주 발생하는 다양한 장애 문제에서 허용되는 데이터 손실을 결정하기 위해 데이터 가용성 또는 복구 지점 목표에 별도로 초점을 맞춘다.<ref name="위키백과 고가용성"></ref>
 
  
−
===시스템 설계===
+
* '''시스템 설계''' : 전체 시스템 설계에 더 많은 구성요소를 추가하면 복잡한 시스템은 본질적으로 더 많은 잠재적 오류 지점을 가지고 있으며, 정확하게 구현하기가 힘들기 때문에 고가용성을 달성하려는 노력을 어렵게 할 수도 있다. 일부 분석가는 가장 가용성이 높은 시스템이 단순한 물리적 시스템을 고수한다는 이론을 내세울 수 있지만, 이 물리적 시스템은 패치 및 운영체제를 위해 전체 시스템을 축소해야 한다는 요구로 인해 어려움을 겪는다. 진보된 시스템 설계를 통해 서비스 가용성에 영향을 주지 않으면서 시스템을 패치하고 업그레이드 할 수 있다. 고가용성은 복잡한 시스템에서의 운영을 복원하기 위해 사람의 수고가 비교적 적은 편이다. 이러한 이유가 있어 가동이 중단되는 가장 흔한 원인은 사람의 실수 때문이다. 중복성이 높은 수준의 가용성이 있는 시스템을 만드는 데 이 고가용성이 사용된다. 이 경우에 높은 수준의 고장 검출성과 공통원인 고장의 회피가 요구된다. 이중화의 두 종류는 수동적 중복과 능동적 중복이다.<ref name="위키백과 고가용성"></ref>
−
전체 시스템 설계에 더 많은 구성요소를 추가하면 복잡한 시스템은 본질적으로 더 많은 잠재적 오류 지점을 가지고 있으며, 정확하게 구현하기가 힘들기 때문에 고가용성을 달성하려는 노력을 어렵게 할 수도 있다. 일부 분석가는 가장 가용성이 높은 시스템이 단순한 물리적 시스템을 고수한다는 이론을 내세울 수 있지만, 이 물리적 시스템은 패치 및 운영체제를 위해 전체 시스템을 축소해야 한다는 요구로 인해 어려움을 겪는다. 진보된 시스템 설계를 통해 서비스 가용성에 영향을 주지 않으면서 시스템을 패치하고 업그레이드 할 수 있다.
 
  
−
고가용성은 복잡한 시스템에서의 운영을 복원하기 위해 사람의 수고가 비교적 적은 편이다. 이러한 이유가 있어 가동이 중단되는 가장 흔한 원인은 사람의 실수 때문이다.
+
===가용성 향상 방법===
 +
* '''목표 수준 설정''' : 구글에서는 다음을 기준으로 목표 가용성 수준(target level of availability)을 결정한다고 한다.
 +
# 사용자는 어느 정도 수준의 서비스를 기대하는가?
 +
# 이 서비스가 수익과 직접적으로 연관이 있는가? (구글의 수익 혹은 고객의 수익?)
 +
# 유료 서비스인가 아니면 무료 서비스인가?
 +
# 시장에 경쟁자가 있다면 그 경쟁자는 어느 정도 수준의 가용성을 제공하는가?
 +
# 이 서비스는 개인 사용자를 위한 서비스인가 기업 사용자를 위한 서비스인가?
  
−
중복성이 높은 수준의 가용성이 있는 시스템을 만드는 데 이 고가용성이 사용된다. 이 경우에 높은 수준의 고장 검출성과 공통원인 고장의 회피가 요구된다. 이중화의 두 종류는 수동적 중복과 능동적 중복이다.<ref name="위키백과 고가용성"></ref>
+
* '''에러 예산''' : 기본적으로 모든 것에 대해 신뢰성 목표 지수를 100%로 설정하는 것은 잘못된 목표 설정이라는 관찰 결과에서 유래한 것이다. 사업부나 제품 담당 부서는 시스템의 목표 가용성을 반드시 설정해야 한다. 일단 목표가 설정되면 에러 예산은 1에서 목표 가용성을 뺀 값이 된다. 즉, 서비스의 목표 가용성이 99.99%라면 불가용한 상태인 경우는 0.01%에 해당한다. 이렇게 필연적으로 발생할 수밖에 없는 0.01%의 불가용성이 서비스의 에러예산(error budget)이다. SRE(Site Reliability Engineering)팀은 이 에러 예산을 초과하지 않는 범위 내에서 얼마든지 자유롭게 예산을 활용할 수 있다.
  
−
==가용성 향상 방법==
+
:*에러 예산의 활용 : 개발팀이 새로운 기능을 빠르게 출시하기 위해 감수해야 할 위험을 처리하는 데 에러 예산을 투입한다. 새로운 기능의 단계적 출시나 일부 사용자를 대상으로 한 실험 기능 출시 같은 전략 등을 예로 들 수 있다. 에러 예산을 도입하면 개발팀과 SRE의 동기(incentives)에서 발생하는 구조적 충돌 역시 해소할 수 있다. 에러 예산이 도입되면 SRE들은 더 이상 '무정지 시스템'과 같은 목표를 세우지 않는다. 그 대신 SRE팀과 제품 개발팀이 기능의 출시 속도를 극대화하기 위해 에러 예산을 활용하는 것에 집중하게 된다. 이런 변화는 모든 것을 바꿀 수 있다. 시스템이 정지하더라도 더 이상 상황을 장애 상황이라고만 생각하지 않고 혁신의 과정에서 어쩔 수 없이 발생하는 예측 가능한 상황이 되며, 이런 상황이 발생하면 개발팀과 SRE팀은 올바르게 대응하게 된다.<ref name="티스토리"></ref>
−
===목표 수준 설정===
 
−
구글에서는 다음을 기준으로 목표 가용성 수준(target level of availability)을 결정한다고 한다.
 
−
*사용자는 어느 정도 수준의 서비스를 기대하는가?
 
−
*이 서비스가 수익과 직접적으로 연관이 있는가? (구글의 수익 혹은 고객의 수익?)
 
−
*유료 서비스인가 아니면 무료 서비스인가?
 
−
*시장에 경쟁자가 있다면 그 경쟁자는 어느 정도 수준의 가용성을 제공하는가?
 
−
*이 서비스는 개인 사용자를 위한 서비스인가 기업 사용자를 위한 서비스인가?
 
  
−
===에러 예산===
+
===가용성 가동률===
−
에러 예산은 기본적으로 모든 것에 대해 신뢰성 목표 지수를 100%로 설정하는 것은 잘못된 목표 설정이라는 관찰 결과에서 유래한 것이다.
+
가용성 가동률은 시스템 엔지니어링의 가용성 가동률은 시스템이 사용할 수 있어야 했던 시간과 비교했을 때, 사용 가능한 시간을 측정한 것이다. 진단 중단 시간, 임계 지수, 고장 격리 다운 타임, 물류 지연 다운 타임, 고장 수리 중단 시간들을 평가하는 관리의 개념으로, 만약 위의 항목들을 관리하지 않는다면 작동 장애가 발생한다. 그래서 위의 기준은 이러한 것들에 대한 위험을 평가하는 데 사용된다. 만약, 관리하지 않는 경우 자본 장비 손실, 부상 또는 사망, 작업 수행에 대한 지속적인 실패와 같은 상황이 발생할 수 있는데 이는 일어나서는 안 되는 일이다.<ref name="위키백과 가용성 가동률">Operational availability wikipedia - https://en.wikipedia.org/wiki/Operational_availability</ref>
  
−
사업부나 제품 담당 부서는 시스템의 목표 가용성을 반드시 설정해야 한다. 일단 목표가 설정되면 에러 예산은 1에서 목표 가용성을 뺀 값이 된다. 즉, 서비스의 목표 가용성이 99.99%라면 불가용한 상태인 경우는 0.01%에 해당한다. 이렇게 필연적으로 발생할 수밖에 없는 0.01%의 불가용성이 서비스의 에러예산(error budget)이다. SRE(Site Reliability Engineering)팀은 이 에러 예산을 초과하지 않는 범위 내에서 얼마든지 자유롭게 예산을 활용할 수 있다.
+
==다른 의미의 가용성==
−
*에러 예산의 활용
+
가용성은 요구 기능을 요구 시간 동안 올바르게 수행할 수 있는 능력을 말한다. 유지 관점에서는 서비스가 중단되지 않고 성능을 유지하는 능력, 접근 관점에서는 언제든지 서비스에 대한 접근/접속 및 사용 가능한 능력을 의미한다. 가용성은 전산/보안/정보보호, 신뢰성 공학 등에서 다른 의미로 작용한다.
−
**개발팀이 새로운 기능을 빠르게 출시하기 위해 감수해야 할 위험을 처리하는 데 에러 예산을 투입한다.
 
−
**예: 새로운 기능의 단계적 출시나 일부 사용자를 대상으로 한 실험 기능 출시 같은 전략 등
 
−
에러 예산을 도입하면 개발팀과 SRE의 동기(incentives)에서 발생하는 구조적 충돌 역시 해소할 수 있다. 에러 예산이 도입되면 SRE들은 더 이상 '무정지 시스템'과 같은 목표를 세우지 않는다. 그 대신 SRE팀과 제품 개발팀이 기능의 출시 속도를 극대화하기 위해 에러 예산을 활용하는 것에 집중하게 된다. 이런 변화는 모든 것을 바꿀 수 있다. 시스템이 정지하더라도 더 이상 상황을 장애 상황이라고만 생각하지 않고 혁신의 과정에서 어쩔 수 없이 발생하는 예측 가능한 상황이 되며, 이런 상황이 발생하면 개발팀과 SRE팀은 올바르게 대응하게 된다.<ref name="티스토리"></ref>
 
  
−
==가용성 가동률==
+
; 전산/보안/정보보호
−
시스템 엔지니어링의 가용성 가동률은 시스템이 사용할 수 있어야 했던 시간과 비교했을 때, 사용 가능한 시간을 측정한 것이다.
+
사용자가 시스템의 데이터 또는 자원을 필요로 할 때, 지체없이 원하는 객체 또는 자원에 접근 및 사용할 수 있는 성질이다. 즉, 데이터와 정보 및 정보 시스템이 요구된 방법으로, 적시에 접근이 가능하며, 인가된 사용자는 필요한 정보를 항상 사용이 가능하다는 뜻이다.
−
===정의===
 
−
가용성 가동률은 다음을 평가하는 관리의 개념이다.
 
−
*진단 중단 시간
 
−
*임계 지수
 
−
*고장 격리 다운 타임
 
−
*물류 지연 다운 타임
 
−
*고장 수리 중단 시간
 
−
만약 위의 항목들을 관리하지 않는다면 작동 장애가 발생한다. 그래서 위의 기준은 이러한 것들에 대한 위험을 평가하는 데 사용된다. 만약, 관리하지 않는 경우 다음과 같은 상황이 발생할 수 있는데 이는 일어나서는 안 되는 일이다.
 
−
*자본 장비 손실
 
−
*부상 또는 사망
 
−
*작업 수행에 대한 지속적 실패<ref name="위키백과 가용성 가동률">위키백과 Operational availability - https://en.wikipedia.org/wiki/Operational_availability</ref>
 
  
−
==다른 의미의 가용성==
+
;신뢰성 공학
−
===가용성===
+
신뢰성 공학에서 가용성 정량화 척도는 가용도, 가동률과 동일한 의미를 갖는다.
−
유지 관점 : 서비스가 중단되지 않고 성능을 유지하는 능력을 말한다.
+
 
−
접근 관점 : 언제든지 서비스에 대한 접근 및 접속을 이용할 수 있는 능력을 말한다.
+
*정상 동작 비율 : 시간 <math>t</math>에 대한 함수적 의존성을 가진다. 어떤 기간 중에 제 기능을 발휘할 시간 비율 또는 확률을 뜻한다.
−
===전산/보안/정보보호===
+
*가용도 = 신뢰도 + 보전도
−
사용자가 시스템의 데이터 또는 자원을 필요로 할 때, 지체없이 원하는 객체 또는 자원에 접근 및 사용할 수 있는 성질이다. 즉, 데이터와 정보 및 정보 시스템이 요구된 방법으로, 적시에 접근이 가능하며, 인가된 사용자는 필요한 정보를 항상 사용이 가능하다는 뜻이다.
+
# 수리 불가능계(Nonrepairable) : 고장 나지 않고 남게 되는 잔존율을 뜻한다. 시간 <math>t</math>까지 제품 중 몇 %가 고장 나지 않고 남게 되는 잔존율은 <math>A(t)</math>가 된다. 이때, 가용도는 신뢰도와 같다.
−
===신뢰성 공학===
+
# 수리 가능계(Repairable) : 수리 시간까지 고려한 가동률을 뜻한다. 시간 <math>t</math>에서 가동 확률은 <math>A(t)</math>로, 이때 가용도는 신뢰도에 보전도를 합한 값과 같다.<ref>정보통신기술용어해설, 〈[http://www.ktword.co.kr/abbr_view.php?m_temp1=1100 Availability  가용성, 가용도, 가용률, 가동률, 가용시간]〉2020-04-04</ref>
−
가용성 정량화 척도
 
−
*정상 동작 비율 : 시간 t에 대한 함수적 의존성을 가진다. (어떤 기간 중에 제 기능을 발휘할 시간 비율 또는 확률을 뜻한다.)
 
−
*수리 불가능계(Nonrepairable) : 고장 나지 않고 남게 되는 잔존율을 뜻한다. (시간 t까지 제품 중 몇 %가 고장 나지 않고 남게되는 잔존율-A(t)) -> 가용도 = 신뢰도
 
−
**수리 가능계(Repairable) : 수리 시간까지 고려한 가동률을 뜻한다. (시간 t에서 가동 확률-A(t)) -> 가용도 = 신뢰도 + 보전도<ref>정보통신기술용어해설, 〈[http://www.ktword.co.kr/abbr_view.php?m_temp1=1100 Availability  가용성, 가용도, 가용률, 가동률, 가용시간]〉2020-04-04</ref>
 
  
 
{{각주}}
 
{{각주}}
  
 
==참고 자료==
 
==참고 자료==
−
*위키백과 High availability - https://en.wikipedia.org/wiki/High_availability
+
*High availability wikipedia - https://en.wikipedia.org/wiki/High_availability
−
*위키백과 Uptime - https://en.wikipedia.org/wiki/Uptime
+
*Uptime wikipedia - https://en.wikipedia.org/wiki/Uptime
−
*위키백과 Downtime - https://en.wikipedia.org/wiki/Downtime
+
*Downtime wikipedia - https://en.wikipedia.org/wiki/Downtime
−
*위키백과 Operational availability - https://en.wikipedia.org/wiki/Operational_availability
+
*Operational availability wikipedia - https://en.wikipedia.org/wiki/Operational_availability
 
*한국데이터산업진흥원, 〈[https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=135&dbnum=128493&mode=detail&type=techreport 가용성 향상(계획된 다운타임 최소화) 방안, Part 1: DB 시스템의 가용성이란?]〉
 
*한국데이터산업진흥원, 〈[https://www.kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=135&dbnum=128493&mode=detail&type=techreport 가용성 향상(계획된 다운타임 최소화) 방안, Part 1: DB 시스템의 가용성이란?]〉
 
*정보통신기술용어해설, 〈[http://www.ktword.co.kr/abbr_view.php?m_temp1=1100 Availability  가용성, 가용도, 가용률, 가동률, 가용시간]〉2020-04-04
 
*정보통신기술용어해설, 〈[http://www.ktword.co.kr/abbr_view.php?m_temp1=1100 Availability  가용성, 가용도, 가용률, 가동률, 가용시간]〉2020-04-04

2020년 8월 5일 (수) 20:08 기준 최신판

가용성(Availability)이란 물질이 용매에 잘 녹는 성질이라는 뜻이다. 정보기술에서는 서버 및 네트워크 등의 시스템이 장애 없이 정상적으로 서비스를 수행할 수 있는 정도를 말한다.

개요[편집]

가용성은 가동률과 비슷한 의미로, 서비스가 다운되지 않고 정상적으로 유지된 시간을 의미한다. 수식으로 표현하면 사용 시간(Uptime)을 전체 사용 시간(Uptime + Downtime)으로 나눈 값을 말한다. 가용성은 사용자가 시스템에 접속하거나, 새로운 작업을 제출하거나, 이전 작업의 결과를 수집하는 능력의 정도를 말한다. 비즈니스 프로세스와 데이터베이스 솔루션 측면에서 가용성이란 사용자 애플리케이션의 트랜잭션을 적절한 시간 내에 처리하는 데이터베이스의 능력에 대한 측정값을 가리킨다. 데이터베이스 솔루션의 가용성 요구사항은 비즈니스 요구에 의해 결정된다. 예를 들어 데이터베이스 솔루션이 오전 9시에서 오후 5시까지 영업하는 상점에서 사용되는 경우 데이터베이스는 매일 밤 오후 5시 1분부터 오전 8시 59분까지 오프라인일 수 있지만, 가용성은 여전히 높은 것으로 간주된다. 반면에 같은 데이터베이스 솔루션을 여러 시간대에 걸쳐있는 상점의 체인에서 사용하는 경우 가능한 가동 중지 시간은 적어지게 될 것이다. 또 이 데이터베이스 솔루션을 매일 24시간 고객에게 서비스를 제공해야 하는 온라인 비즈니스에 사용하는 경우 데이터베이스가 오프라인이 되면 고객에게 영향을 줄 수밖에 없음으로 가용성은 매우 중요한 사안이 된다. 이 값이 높으면 높을수록 "가용성이 높다"라고 표현하며, 가용성이 높은 것을 고가용성이라고 한다.[1][2]

특징[편집]

관련 용어[편집]

  • 업 타임(Uptime) : 시스템 신뢰성의 척도로, 일반적으로 컴퓨터가 작동하고 사용 가능한 시간의 백분율로 표현된다. 가동 시간은 다운 타임과 반대다. 업타임은 컴퓨터가 고장 나지 않고 놔둘 수 있는 시간이나 유지 및 보수를 위해 재부팅을 해야 하는 시간을 나타낸다. 이 덕분에 업타임은 컴퓨터 운영체제의 신뢰성이나 안정성을 측정하는 척도로 자주 사용된다. 하지만, 일부 중요한 업데이트는 이부 플랫폼에서 재부팅을 요구할 수도 있어 긴 가동 시간이 좋은 것 만은 아니다. 업타임은 윈도우즈, 프리도스(FreeDOS), 리눅스, BSD, OpenVMS에서 사용할 수 있다.[3]
  • 다운 타임(Downtime) : 시스템을 사용할 수 없는 기간을 나타내기 위해 사용된다. 다운타임은 시스템이 주요 기능을 제공하거나 수행하지 못하는 기간은 나타내는데, 이는 신뢰성, 가용성, 복구 및 사용 불가가 관련된 개념이다. 여기서 사용 불가란 시스템을 사용할 수 없거나 오프라인 상태인 시간 범위의 비율이다. 이는 보통 시스템이 계획되지 않은 사건이나 일상적인 유지 및 보수로 인해 작동하지 못한 결과로 나타난다.[4]

논리적 계산[편집]

다음은 가용성의 식이다. 사용 시간(Uptime)을 전체 사용 시간(Uptime + Downtime)으로 나눈 값을 말한다. 이때, 가용성으로 나올 수 있는 값은 0~1 사이의 숫자로 소수자리를 포함한다. 값이 높을수록 가용성이 높다는 의미이며 주로 백분율화하여 곱하기 100을 하여 표기한다.

이에 대해 "사이트 신뢰성 엔지니어링"은 더 섬세하게 정의한다.

다음은 트랜잭션 처리의 원리에서 정의하는 가용성은 또 다르다. TP 시스템에 필요한 중요한 요구사항은 시스템이 항상 가동상태를 유지해야 한다는 것이다. 이것은 가용성이 매우 높은 시스템이어야 한다는 뜻이다. 그런 시스템을 흔히 24X365라고도 하는데, 매일 24시간 연간 365일, 즉 연중무휴로 가동하는 시스템이라는 의미이다. 가용성은 두 가지 요인에 의해서 감소하는데, 그중 한 요인은 시스템에 장애가 발생하는 비율이다. 장애라는 말은 시스템이 잘못 응답하거나 응답을 하지 않음을 의미한다. 시스템의 다른 조건이 같을 때 장애가 자주 발생한다면 그 시스템은 가용성이 낮다고 말한다. 다른 요인 하나는 복구 시간이다. 시스템의 다른 조건이 같을 때 장애가 발생한 이후에 시스템을 복구하는 데 걸리는 시간이 길어질수록 시스템의 가용성은 낮아진다. 이런 개념은 평균가동시간(mean time between failure,MTBF)과 평균 복구 시간(mean time to repair,MTTR)으로 표현된다. 평균가동시간은 장애가 발생하기 전에 시스템이 가동되는 평균가동시간이다. 평균 복구 시간은 장애가 발생한 이후에 시스템을 수리하거나 복구하는 데 걸리는 시간을 뜻한다. 이 두 척도를 이용하여 가용성을 다음과 같이 정의할 수 있다. 그러므로 가용성은 신뢰성이 증가하고, 복구 시간이 감소할수록 향상된다.


"사이트 신뢰성 엔지니어링"에서는 시간 기준의 가용성을 대안으로 요청 성공률에 기초한 가용성을 정의한다. 그러나 구글에서는 시간 기준의 가용성 지표는 그다지 의미가 없다. 그 이유는 우리는 전 세계에 분산된 서비스를 운영하기 때문이다. 구글이 채택하고 있는 장애 분리(fault isolation) 방식 덕분에 우리는 특정 서비스의 트래픽 중 일부를 주어진 시간 동안 세계의 어느 한 지역에 제공하고 있는 셈이다. 다시 말하면, 전체 시간 중 최소 일부는 '정상 동작 중인' 상태다. 그래서 우리는 업타임과 관련된 지표들 대신 요청 성공률(request success rate)에 기초한 가용성을 정의한다. 아래의 식은 특정한 운영 시간 대비 성공률에 기반한 지표들을 계산하는 수식이다." 

가용성 = 성공한 요청 수 / 전체 요청 수

예를 들어 하루에 250만 개의 요청을 처리하는 시스템의 경우 하루에 발생하는 에러가 250개 이내라면 일일 가용성 목표치 99.99%를 달성할 수 있다.[5]

고가용성[편집]

고가용성은 일반적인 가용성보다 더 높은 수준의 성능을 보장하는 것이 목표인 시스템이다. 현대화로 인하여 고가용성에 대한 의존도가 증가하였는데, 대표적으로 병원과 데이터센터가 있다. 이 두 곳은 그들의 업무를 위해 시스템에 대한 높은 가용성을 요구하기 때문에 고가용성을 필요로 한다.[1] 신뢰성이 높은 시스템이 고가용성을 달성하는 데 도움이 되는 세 가지 원칙이 있다.

  1. 단일 고장 지점 제거 : 구성요소 중 하나가 고장이 났을 때 이것이 전체 시스템에 문제를 일으키지 않도록 시스템 내에 중복성을 추가하는 것을 말한다.
  2. 신뢰할만한 교차점 : 중복 시스템에서 교차점은 단일 고장 지점이 되는 경향이 있기 때문에 신뢰할 수 있는 시스템에는 신뢰할 수 있는 교차점을 제공해야 한다.
  3. 위의 두 가지 원칙을 준수한다면 보통의 경우 고장이 일어나지 않지만, 유지 관리 활동을 반드시 해주어야 한다.[1]
  • 예약된 다운 타임 및 예약되지 않은 다운 타임 : 예정된 것과 예정되지 않은 다운 타임이 있다. 보통, 예정된 다운 타임은 시스템 작동에 영향을 주는 유지보수의 결과이다. 일반적으로 현재 설치된 시스템 설계로는 피할 수 없는데, 이는 재부팅이 필요한 시점을 설정하여 해결할 수 있다. 그리고 예정되지 않은 다운 타임은 보통 하드웨어나 소프트웨어 오류 등 여러 물리적 문제에서 발생한다. 이에 대한 예시로는 정전, CPU 또는 RAM 구성요소의 고장, 미들웨어 및 운영체제 장애 등이 있다.[1]
  • 백분율 계산 : 가용성은 보통 특정 시간의 가동 시간 백분율로 표현된다. 아래의 표는 시스템이 연속적으로 작동해야 한다고 가정할 때의 특정 가용성이 가진 비율에 대해 허용되는 다운 타임을 보여준다. 업타임과 가용성은 조건에 한해 동의어로 사용될 수 있다. 즉, 시스템은 가동될 수 있으나, 네트워크가 중단되는 경우처럼 그 시스템을 갑작스럽게 이용하지 못할 수도 있다. 이것들은 가용성 있는 시스템으로 보일 수 있지만, 이 서비스들은 기능적 관점까지는 올라가지 않는다.[1]
가용성 백분율 다운타임 : 시스템을 사용할 수 없는 기간 μ
가용성%연간 다운 타임한달 다운 타임주당 다운 타임일일 다운 타임
55.5555555%("5 아홉 개")162.33일13.53일74.92일10.67일
90%("9 한개")36.53일73.05시간16.80시간2.40시간
95%18.26일36.53시간8.40시간1.20시간
97%10.96일21.92시간5.04시간43.20분
98%7.31일14.61시간3.36시간28.80분
99%("9 두 개")3.65일7.31시간1.68시간14.40분
99.5%1.83일3.65시간50.40분7.20분
99.8%17.53시간87.66분20.16분2.88분
99.9%("9 세 개")8.77시간43.83분10.08분1.44분
99.95%4.38시간21.92분5.04분43.20초
99.99%("9 네 개")52.60분4.38분1.01분8.64초
99.995%26.30분2.19분30.24초4.32초
99.999%("9 다섯 개")5.26분26.30초6.05초864㎳
99.9999%("9 여섯 개")31.56초2.63초604.80㎳86.40㎳
99.99999%("9 일곱 개")3.16초262.98㎳60.48㎳8.64㎳
99.999999%("9 여덟 개")315.58㎳26.30㎳6.05㎳864㎲
99.9999999%("9 아홉 개")31.56㎳2.63㎳604.80㎲86.40㎲
  • 고가용성 관련 밀접 개념 : 복구 시간 목표(RTO)라고도 하는 복구 시간(예상 수리 시간)은 가용성과 밀접한 관련이 있다. 이 시간은 계획된 운영 중단에 필요한 총 시간 또는 계획되지 않은 운영 중단에서 완전히 복구하는 데 걸리는 시간이다. 또 다른 지표로는 평균 복구 시간(MTTR)이 있는데, 복구 시간은 특정 시스템 설계 및 고장 시 무한정 길어질 수 있다. 즉 완전한 복구가 불가능 할 수도 있다는 의미이다. 그러한 예로는 2차 재해 복구 데이터 센터가 없을 때 데이터 센터와 그 시스템을 파괴하는 화재나 홍수가 있다.
또 다른 관련 개념은 데이터 가용성인데, 그것은 데이터베이스와 다른 정보 스토리지 시스템이 시스템 거래를 충실히 기록하고 보고하는 시스템이다. 정보 관리는 자주 발생하는 다양한 장애 문제에서 허용되는 데이터 손실을 결정하기 위해 데이터 가용성 또는 복구 지점 목표에 별도로 초점을 맞춘다.[1]
  • 시스템 설계 : 전체 시스템 설계에 더 많은 구성요소를 추가하면 복잡한 시스템은 본질적으로 더 많은 잠재적 오류 지점을 가지고 있으며, 정확하게 구현하기가 힘들기 때문에 고가용성을 달성하려는 노력을 어렵게 할 수도 있다. 일부 분석가는 가장 가용성이 높은 시스템이 단순한 물리적 시스템을 고수한다는 이론을 내세울 수 있지만, 이 물리적 시스템은 패치 및 운영체제를 위해 전체 시스템을 축소해야 한다는 요구로 인해 어려움을 겪는다. 진보된 시스템 설계를 통해 서비스 가용성에 영향을 주지 않으면서 시스템을 패치하고 업그레이드 할 수 있다. 고가용성은 복잡한 시스템에서의 운영을 복원하기 위해 사람의 수고가 비교적 적은 편이다. 이러한 이유가 있어 가동이 중단되는 가장 흔한 원인은 사람의 실수 때문이다. 중복성이 높은 수준의 가용성이 있는 시스템을 만드는 데 이 고가용성이 사용된다. 이 경우에 높은 수준의 고장 검출성과 공통원인 고장의 회피가 요구된다. 이중화의 두 종류는 수동적 중복과 능동적 중복이다.[1]

가용성 향상 방법[편집]

  • 목표 수준 설정 : 구글에서는 다음을 기준으로 목표 가용성 수준(target level of availability)을 결정한다고 한다.
  1. 사용자는 어느 정도 수준의 서비스를 기대하는가?
  2. 이 서비스가 수익과 직접적으로 연관이 있는가? (구글의 수익 혹은 고객의 수익?)
  3. 유료 서비스인가 아니면 무료 서비스인가?
  4. 시장에 경쟁자가 있다면 그 경쟁자는 어느 정도 수준의 가용성을 제공하는가?
  5. 이 서비스는 개인 사용자를 위한 서비스인가 기업 사용자를 위한 서비스인가?
  • 에러 예산 : 기본적으로 모든 것에 대해 신뢰성 목표 지수를 100%로 설정하는 것은 잘못된 목표 설정이라는 관찰 결과에서 유래한 것이다. 사업부나 제품 담당 부서는 시스템의 목표 가용성을 반드시 설정해야 한다. 일단 목표가 설정되면 에러 예산은 1에서 목표 가용성을 뺀 값이 된다. 즉, 서비스의 목표 가용성이 99.99%라면 불가용한 상태인 경우는 0.01%에 해당한다. 이렇게 필연적으로 발생할 수밖에 없는 0.01%의 불가용성이 서비스의 에러예산(error budget)이다. SRE(Site Reliability Engineering)팀은 이 에러 예산을 초과하지 않는 범위 내에서 얼마든지 자유롭게 예산을 활용할 수 있다.
  • 에러 예산의 활용 : 개발팀이 새로운 기능을 빠르게 출시하기 위해 감수해야 할 위험을 처리하는 데 에러 예산을 투입한다. 새로운 기능의 단계적 출시나 일부 사용자를 대상으로 한 실험 기능 출시 같은 전략 등을 예로 들 수 있다. 에러 예산을 도입하면 개발팀과 SRE의 동기(incentives)에서 발생하는 구조적 충돌 역시 해소할 수 있다. 에러 예산이 도입되면 SRE들은 더 이상 '무정지 시스템'과 같은 목표를 세우지 않는다. 그 대신 SRE팀과 제품 개발팀이 기능의 출시 속도를 극대화하기 위해 에러 예산을 활용하는 것에 집중하게 된다. 이런 변화는 모든 것을 바꿀 수 있다. 시스템이 정지하더라도 더 이상 상황을 장애 상황이라고만 생각하지 않고 혁신의 과정에서 어쩔 수 없이 발생하는 예측 가능한 상황이 되며, 이런 상황이 발생하면 개발팀과 SRE팀은 올바르게 대응하게 된다.[5]

가용성 가동률[편집]

가용성 가동률은 시스템 엔지니어링의 가용성 가동률은 시스템이 사용할 수 있어야 했던 시간과 비교했을 때, 사용 가능한 시간을 측정한 것이다. 진단 중단 시간, 임계 지수, 고장 격리 다운 타임, 물류 지연 다운 타임, 고장 수리 중단 시간들을 평가하는 관리의 개념으로, 만약 위의 항목들을 관리하지 않는다면 작동 장애가 발생한다. 그래서 위의 기준은 이러한 것들에 대한 위험을 평가하는 데 사용된다. 만약, 관리하지 않는 경우 자본 장비 손실, 부상 또는 사망, 작업 수행에 대한 지속적인 실패와 같은 상황이 발생할 수 있는데 이는 일어나서는 안 되는 일이다.[6]

다른 의미의 가용성[편집]

가용성은 요구 기능을 요구 시간 동안 올바르게 수행할 수 있는 능력을 말한다. 유지 관점에서는 서비스가 중단되지 않고 성능을 유지하는 능력, 접근 관점에서는 언제든지 서비스에 대한 접근/접속 및 사용 가능한 능력을 의미한다. 가용성은 전산/보안/정보보호, 신뢰성 공학 등에서 다른 의미로 작용한다.

전산/보안/정보보호

사용자가 시스템의 데이터 또는 자원을 필요로 할 때, 지체없이 원하는 객체 또는 자원에 접근 및 사용할 수 있는 성질이다. 즉, 데이터와 정보 및 정보 시스템이 요구된 방법으로, 적시에 접근이 가능하며, 인가된 사용자는 필요한 정보를 항상 사용이 가능하다는 뜻이다.

신뢰성 공학

신뢰성 공학에서 가용성 정량화 척도는 가용도, 가동률과 동일한 의미를 갖는다.

  • 정상 동작 비율 : 시간 에 대한 함수적 의존성을 가진다. 어떤 기간 중에 제 기능을 발휘할 시간 비율 또는 확률을 뜻한다.
  • 가용도 = 신뢰도 + 보전도
  1. 수리 불가능계(Nonrepairable) : 고장 나지 않고 남게 되는 잔존율을 뜻한다. 시간 까지 제품 중 몇 %가 고장 나지 않고 남게 되는 잔존율은 가 된다. 이때, 가용도는 신뢰도와 같다.
  2. 수리 가능계(Repairable) : 수리 시간까지 고려한 가동률을 뜻한다. 시간 에서 가동 확률은 로, 이때 가용도는 신뢰도에 보전도를 합한 값과 같다.[7]

각주[편집]

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 High availability wikipedia - https://en.wikipedia.org/wiki/High_availability
  2. ↑ 한국데이터산업진흥원, 〈가용성 향상(계획된 다운타임 최소화) 방안, Part 1: DB 시스템의 가용성이란?〉
  3. ↑ wikipedia Uptime - https://en.wikipedia.org/wiki/Uptime
  4. ↑ Downtime wikipedia - https://en.wikipedia.org/wiki/Downtime
  5. ↑ 5.0 5.1 기계인간 John Grib , 〈가용성(Availability)시스템이 다운되지 않고 정상 운영되는 시간의 비율〉, 《티스토리》, 2020-07-13
  6. ↑ Operational availability wikipedia - https://en.wikipedia.org/wiki/Operational_availability
  7. ↑ 정보통신기술용어해설, 〈Availability 가용성, 가용도, 가용률, 가동률, 가용시간〉2020-04-04

참고 자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 가용성 문서는 하드웨어에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.  

개발 : 프로그래밍, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어 □■⊕, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인
하드웨어 L2 스위치 • L3 스위치 • L4 스위치 • L7 스위치 • PTL • VTL • 가상 인터넷데이터센터(VIDC) • 나스(NAS) • 네트워크 스위치 • 다스(DAS) • 라우터 • 랙 • 맥주소 • 모뎀 • 방화벽 • 백본 • 백업장비 • 부대시설 • 브릿지 • 브릿지 테이블 • 샌 • 서버 • 스토리지 • 웹방화벽 • 웹스토리지 • 유니버설 플래시 스토리지 • 유피에스(UPS) • 이더넷 • 인터넷데이터센터(IDC) • 인프라 • 전산실 • 캐리어 이더넷 • 컴퓨터 클러스터 • 컴프레서 • 케이블 • 케이지 • 클라우드 스토리지 • 파이버 채널 • 펌웨어 • 하드웨어 • 항온항습기
하드웨어 관리 CDC • CDN • 가상머신 • 가상화 • 가용성 • 고가용성(HA) • 대역폭 • 라우팅 • 랙 • 레이드 • 레플리케이션 • 로드밸런싱 • 마스터 • 마스터-슬레이브 • 미러링 • 미러사이트 • 백업 • 백업사이트 • 복구 • 볼팅 • 부하 • 비즈니스 연속성(BC) • 서버 가상화 • 소산백업 • 스탠바이 • 스토리지 가상화 • 슬레이브 • 액티브 • 액티브-스탠바이 • 액티브-액티브 • 오프라인 백업 • 웜사이트 • 장애 • 장애복구 • 재해복구(DR) • 재해복구센터 • 지속적 데이터 보호(CDP) • 콜드사이트 • 페일오버 • 프로비저닝 • 프록시 • 핫사이트 • 핫스왑
네트워크 ADSL • AP • DSL • VPN • 게이트웨이 • 경로 • 공유기 • 네트워크 • 네트워크 가상화 • 네트워크 관리 시스템(NMS) • 네트워크 기기 • 네트워크 모니터링 • 네트워크 인터페이스 • 네트워크 장비 • 네트워크 케이블 • 네트워크 트래픽 • 네트워크 트래픽 모니터링 장비 • 라우터 • 랜(LAN) • 랜카드 • 리피터 • 망 • 무선 • 무선공유기 • 무선네트워크 • 무선랜 • 무선랜카드 • 무선브릿지 • 브릿지 • 수동 광통신망 • 아이피(IP) • 왠(WAN) • 유선 • 유선랜 • 유무선 • 인터넷공유기 • 전산망 • 전용회선 • 정보통신망 • 최단경로 • 컴퓨터 네트워크 • 터미널 • 통신 네트워크 • 통신회선 • 허브 • 호스트 • 홉 • 회선
통신 1세대 이동통신 • 2세대 이동통신 • 3세대 이동통신 • 4G(4세대 이동통신) • 5G(5세대 이동통신) • 6G • CDMA • GSM • IMT2000 • LTE • PC통신 • WCDMA • 공중전화 • 광선 • 광섬유 • 광케이블 • 기지국 • 디지털 • 모스부호 • 무선단말기 • 무선전화 • 무선통신 • 문자메시지 • 방송 • 방송통신 • 변조 • 보이스톡 • 브로드밴드 • 비디오폰 • 송신기 • 수신기 • 스마트폰 • 스타링크 • 아날로그 • 영상통화 • 와이맥스 • 와이브로 • 와이파이 • 유무선통신 • 유선전화 • 유선통신 • 음성 • 음성통화 • 이동통신 • 일반전화 • 전기통신번호 • 전기통신사업 • 전달 매개체 • 전신 • 전파 • 전화 • 전화기 • 점대점 통신 • 주파수 • 주파수 간섭 • 채널 • 초고속 인터넷 • 카폰 • 커버리지 • 통신 • 통신장비 • 페이스톡 • 프로토콜 • 헤르츠 • 휴대전화
위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반
원본 주소 "http://wiki1.kr/index.php?title=가용성&oldid=334606"