고가용성

3. 원칙

신뢰성 공학에는 시스템 설계를 통해 고가용성을 달성하는 데 도움이 되는 세 가지 원칙이 있다.

# 단일 실패 지점 제거. 이는 구성 요소의 실패가 전체 시스템의 실패를 의미하지 않도록 시스템에 중복성을 추가하거나 구축하는 것을 의미한다.

# 신뢰할 수 있는 전환. 중복성 (공학) 시스템에서 전환 지점 자체가 단일 실패 지점이 되는 경향이 있다. 신뢰할 수 있는 시스템은 신뢰할 수 있는 전환을 제공해야 한다.

# 오류 발생 시 감지. 위의 두 가지 원칙을 준수하면 사용자는 오류를 전혀 보지 못할 수 있지만, 유지 관리 활동은 오류를 감지해야 한다.

3. 1. 단일 실패 지점 제거

3. 2. 신뢰할 수 있는 전환

3. 3. 오류 감지

4. 가동 중단

예정된 가동 중단과 예정되지 않은 가동 중단을 구분할 수 있다. 일반적으로, 예정된 가동 중단은 시스템 운영에 지장을 주는 유지 보수의 결과이며, 현재 설치된 시스템 설계로는 피할 수 없다. 예정된 가동 중단에는 시스템 소프트웨어에 대한 재부팅이 필요한 패치 또는 재부팅 시에만 적용되는 시스템 구성 변경 등이 포함될 수 있다. 일반적으로 예정된 가동 중단은 논리적인 관리자가 시작한 이벤트의 결과이다. 예정되지 않은 가동 중단은 일반적으로 하드웨어나 소프트웨어 고장, 또는 환경 이상과 같은 물리적 이벤트로 인해 발생한다. 예정되지 않은 가동 중단의 예로는 정전, CPU 또는 RAM 구성 요소 고장 (또는 다른 하드웨어 구성 요소 고장 가능성), 과열 관련 종료, 논리적 또는 물리적으로 끊어진 네트워크 연결, 보안 침해, 또는 다양한 응용 프로그램, 미들웨어, 운영 체제 실패 등이 있다.

사용자가 예정된 가동 중단에 대해 경고를 받을 수 있다면 이러한 구분이 유용하다. 그러나 진정한 고가용성이 요구되는 경우, 가동 중단은 예정되었는지 여부에 관계없이 가동 중단이다.

많은 컴퓨팅 사이트는 가동 중단이 컴퓨팅 사용자 커뮤니티에 거의 또는 전혀 영향을 미치지 않는다고 가정하여 가용성 계산에서 예정된 가동 중단을 제외한다. 이렇게 함으로써 엄청나게 높은 가용성을 주장할 수 있으며, 이는 지속적인 가용성의 환상을 줄 수 있다. 진정으로 지속적인 가용성을 보이는 시스템은 비교적 드물고 가격이 더 비싸며, 대부분 단일 실패 지점을 제거하고 온라인 하드웨어, 네트워크, 운영 체제, 미들웨어 및 응용 프로그램 업그레이드, 패치 및 교체를 허용하는 특별한 설계를 신중하게 구현했다. 특정 시스템의 경우, 모든 사람이 밤에 퇴근한 후 사무실 건물에서의 시스템 가동 중단과 같이 예정된 가동 중단은 중요하지 않다.

4. 1. 예정된 가동 중단

4. 2. 예정되지 않은 가동 중단

5. 가용성 측정

가용성은 일반적으로 특정 연도의 가동 시간의 백분율로 표시된다. 다음 표는 시스템이 지속적으로 작동해야 한다고 가정할 때 특정 가용성 백분율에 대해 허용되는 중단 시간을 보여준다. 서비스 수준 협약은 월별 청구 주기에 맞춰 서비스 크레딧을 계산하기 위해 월별 중단 시간 또는 가용성을 참조하는 경우가 많다. 다음 표는 주어진 가용성 백분율을 시스템을 사용할 수 없는 해당 시간으로 변환한 것이다.

가동 시간과 가용성이라는 용어는 종종 같은 의미로 사용되지만 항상 동일한 것을 의미하지는 않는다. 예를 들어, 네트워크 중단의 경우 시스템이 서비스가 "가용"하지 않은 상태에서 "가동"될 수 있다. 또는 소프트웨어 유지 관리를 받고 있는 시스템은 시스템 관리자가 작업할 수 있도록 "가용"할 수 있지만 해당 서비스는 최종 사용자 또는 고객에게 "가동"되지 않은 것처럼 보일수 있다. 따라서 용어의 대상이 여기에서 중요하며, 논의의 초점이 서버 하드웨어, 서버 OS, 기능 서비스, 소프트웨어 서비스/프로세스 또는 이와 유사한 것이라면, 가동 시간과 가용성이라는 단어를 동의어로 사용할 수 있는 것은 논의의 대상이 단일하고 일관된 경우뿐이다.

가용성 측정은 어느 정도 해석의 여지가 있다. 윤년이 아닌 해에 365일 동안 가동된 시스템이 최고 사용량 기간 동안 9시간 동안 지속된 네트워크 오류로 인해 중단되었을 수 있다. 사용자 커뮤니티는 시스템을 사용할 수 없다고 생각할 것이지만, 시스템 관리자는 100% 가동 시간을 주장할 것이다. 그러나 가용성의 진정한 정의를 감안할 때, 시스템은 약 99.9%의 가용성을 가지며, 즉 "쓰리 나인"(윤년이 아닌 해에 8760시간 중 8751시간 가용)을 나타낸다. 또한, 시스템이 계속 작동하더라도 성능 문제가 발생하는 시스템은 사용자에 의해 부분적으로 또는 완전히 사용할 수 없는 것으로 간주되는 경우가 많다. 마찬가지로, 특정 애플리케이션 기능의 사용 불가 상태는 관리자가 알아차리지 못할 수 있지만 사용자에게는 치명적일 수 있다. 진정한 가용성 측정은 총체적이다.

가용성은 이를 결정하기 위해 측정되어야 하며, 이상적으로는 자체적으로 고가용성을 갖춘 포괄적인 모니터링 도구("계측")를 사용하여 측정해야 한다. 계측이 부족한 경우, 신용 카드 처리 시스템이나 전화 교환기와 같이 주야간 대량의 트랜잭션 처리를 지원하는 시스템은 최소한 사용자 스스로에 의해 주기적인 수요 감소를 경험하는 시스템보다 더 잘 모니터링되는 경향이 있다.

대안적인 지표는 고장 간 평균 시간(MTBF)이다.

5. 1. 백분율 계산

"n-나인" 가용성 백분율에 대한 허용된 가동 중단 시간 기간을 계산하는 또 다른 기억술은 하루에 $8.64\; \backslash times\; 10^\{4-n\}$초 공식을 사용하는 것이다.

예를 들어 90% ("1 나인")은 지수 $4\; -\; 1\; =\; 3$을 생성하므로 허용되는 가동 중단 시간은 하루에 $8.64\; \backslash times\; 10^3$초이다.

또한 99.999% ("5 나인")은 지수 $4\; -\; 5\; =\; -1$을 제공하므로 허용되는 가동 중단 시간은 하루에 $8.64\; \backslash times\; 10^\{-1\}$초이다.

5. 2. 나인(9) 표기법

5. 3. 가용성과 다운타임

가동 시간과 가용성이라는 용어는 종종 같은 의미로 사용되지만 항상 동일한 것을 의미하지는 않는다. 예를 들어, 네트워크 중단의 경우 시스템이 서비스가 "가용"하지 않은 상태에서 "가동"될 수 있다. 또는 소프트웨어 유지 관리를 받고 있는 시스템은 시스템 관리자가 작업할 수 있도록 "가용"할 수 있지만 해당 서비스는 최종 사용자 또는 고객에게 "가동"되지 않은 것처럼 보일수 있다. 따라서 용어의 대상이 여기에서 중요하며, 논의의 초점이 서버 하드웨어, 서버 OS, 기능 서비스, 소프트웨어 서비스/프로세스 또는 이와 유사한 것이라면, 가동 시간과 가용성이라는 단어를 동의어로 사용할 수 있는 것은 논의의 대상이 단일하고 일관된 경우뿐이다.

간단한 기억 보조 규칙에 따르면 ''5 나인''은 연간 약 5분의 다운타임을 허용한다. 10을 곱하거나 나누어 변형을 도출할 수 있다. 4 나인은 50분이고 3 나인은 500분이다. 반대 방향으로 6 나인은 0.5분 (30초)이고 7 나인은 3초이다.

"n-나인" 가용성 백분율에 대한 허용된 가동 중단 시간 기간을 계산하는 또 다른 기억술은 하루에 $8.64\; \backslash times\; 10^\{4-n\}$초 공식을 사용하는 것이다.

예를 들어 90% ("1 나인")은 지수 $4\; -\; 1\; =\; 3$을 생성하므로 허용되는 가동 중단 시간은 하루에 $8.64\; \backslash times\; 10^3$초이다.

또한 99.999% ("5 나인")은 지수 $4\; -\; 5\; =\; -1$을 제공하므로 허용되는 가동 중단 시간은 하루에 $8.64\; \backslash times\; 10^\{-1\}$초이다.

6. 관련 개념

복구 시간 (또는 예상 수리 시간 (ETR), 복구 시간 목표(RTO)라고도 함)은 가용성과 밀접하게 관련되어 있으며, 계획된 중단에 필요한 총 시간 또는 계획되지 않은 중단으로부터 완전히 복구하는 데 필요한 시간이다. 또 다른 지표는 평균 복구 시간(MTTR)이다. 특정 시스템 설계 및 장애의 경우 복구 시간은 무한대가 될 수 있다. 즉, 완전한 복구가 불가능하다. 이러한 예로는 보조 재해 복구 데이터 센터가 없을 때 데이터 센터와 시스템을 파괴하는 화재 또는 홍수가 있다.

또 다른 관련 개념은 데이터 가용성으로, 데이터베이스 및 기타 정보 저장 시스템이 시스템 트랜잭션을 충실하게 기록하고 보고하는 정도이다. 정보 관리는 종종 다양한 장애 이벤트에서 허용 가능한 (또는 실제) 데이터 손실을 결정하기 위해 데이터 가용성 또는 복구 시점 목표에 별도로 초점을 맞춘다. 일부 사용자는 애플리케이션 서비스 중단을 견딜 수 있지만 데이터 손실은 견딜 수 없다.

서비스 수준 계약(SLA)은 조직의 가용성 목표 및 요구 사항을 공식화한다.

HA의 개념은 앞서 언급한 "높은 가용성을 자랑하는 것"이며, 이를 실현한 시스템을 HA 구성 또는 HA 서버, HA 클러스터 등으로 칭한다. HA를 실현하기 위한 수단으로는 몇 가지 방식이 있지만, 기본적으로 시스템적인 이중화가 이루어진 구성을 HA 구성이라고 부르는 것이 일반적이다.

6. 1. 복원력 (Resilience)

6. 2. 복구 시간 목표 (RTO)

6. 3. 평균 복구 시간 (MTTR)

6. 4. 데이터 가용성

7. 고가용성 구성 방식

중복성은 높은 수준의 가용성을 가진 시스템을 만드는 데 사용될 수 있다. (예: 인기 있는 전자 상거래 웹사이트). 이 경우 높은 수준의 고장 감지 능력과 공통 원인 고장 회피가 필요하다.^[22][23]

만약 중복 부품이 병렬로 사용되고 독립적으로 고장나는 경우(예: 동일한 데이터 센터 내에 있지 않음으로써), 가용성을 기하급수적으로 증가시키고 전체 시스템을 고가용성으로 만들 수 있다. N개의 병렬 구성 요소가 각각 X의 가용성을 갖는 경우 다음 공식을 사용할 수 있다.

:병렬 구성 요소의 가용성 = 1 - (1 - X)^ N

7. 1. 콜드 스탠바이 (Cold Standby) 구성

7. 2. 핫 스탠바이 (Hot Standby) 구성

7. 3. 부하 분산 (Load Balancing) 구성

7. 4. 재해 복구 (Disaster Recovery) 구성

8. 가용성 저해 요인

2010년 학계의 가용성 전문가들을 대상으로 한 설문 조사에서 기업 IT 시스템의 가용성 저하 요인들이 순위가 매겨졌다. 모든 요인은 각 분야에서 '''최적의 관행을 따르지 않음'''을 의미한다(중요도 순).^[25]

# 관련 구성 요소의 모니터링

# 요구 사항 및 조달

# 운영

# 네트워크 장애 회피

# 내부 애플리케이션 장애 회피

# 실패하는 외부 서비스 회피

# 물리적 환경

# 네트워크 중복성

# 백업의 기술적 솔루션

# 백업의 프로세스 솔루션

# 물리적 위치

# 인프라 중복성

# 스토리지 아키텍처 중복성

요인 자체에 관한 책이 2003년에 출판되었다.^[26]

9. 군사 제어 시스템

고가용성은 무인 차량 및 자율 해상 선박의 제어 시스템에 대한 주요 요구 사항 중 하나이다. 제어 시스템을 사용할 수 없게 되면 지상 전투 차량(GCV) 또는 대잠 지속 추적 무인 선박(ACTUV)을 잃게 된다.

10. 시스템 설계

복잡한 시스템은 본질적으로 더 많은 잠재적 오류 지점을 가지며 올바르게 구현하기가 더 어렵기 때문에, 전체 시스템 설계에 더 많은 구성 요소를 추가하는 것은 고가용성 달성을 위한 노력을 약화시킬 수 있다. 일부 분석가들은 가장 높은 가용성을 가진 시스템이 단순한 아키텍처(포괄적인 내부 하드웨어 중복성을 갖춘 단일의 고품질, 다목적 물리 시스템)를 따른다는 이론을 제시하지만, 이 아키텍처는 패치 및 운영 체제 업그레이드를 위해 전체 시스템을 중단해야 한다는 요구 사항의 영향을 받는다.^[21] 보다 진보된 시스템 설계는 서비스 가용성을 저해하지 않으면서 시스템을 패치하고 업그레이드할 수 있도록 한다( 로드 밸런싱 및 장애 조치 참조). 고가용성은 복잡한 시스템에서 작동을 복원하기 위해 인간의 개입을 덜 필요로 하는데, 그 이유는 중단의 가장 흔한 원인이 인적 오류이기 때문이다.^[21]

==== 중복성을 통한 고가용성 확보 ====

중복성은 높은 수준의 가용성을 가진 시스템을 만드는 데 사용될 수 있다. 예를 들어 인기 있는 전자 상거래 웹사이트와 같은 경우가 이에 해당한다. 이 경우 높은 수준의 고장 감지 능력과 공통 원인 고장 회피가 필요하다.^[22][23]

만약 중복 부품이 병렬로 사용되고 독립적으로 고장나는 경우(예: 동일한 데이터 센터 내에 있지 않음으로써), 가용성을 기하급수적으로 증가시키고 전체 시스템을 고가용성으로 만들 수 있다. N개의 병렬 구성 요소가 각각 X의 가용성을 갖는 경우 다음 공식을 사용할 수 있다.^[22][23]

: 병렬 구성 요소의 가용성 = 1 - (1 - X)^ N

예를 들어, 각 구성 요소가 50%의 가용성만 갖는 경우, 10개의 구성 요소를 병렬로 사용하면 99.9023%의 가용성을 달성할 수 있다.

중복성의 두 가지 종류는 수동 중복성과 능동 중복성이다. 수동 중복성은 성능 저하를 수용할 수 있도록 설계에 충분한 초과 용량을 포함시켜 고가용성을 달성하는 데 사용된다. 가장 간단한 예는 두 개의 별도 엔진이 두 개의 별도 프로펠러를 구동하는 보트이다. 보트는 하나의 엔진 또는 프로펠러가 고장나도 목적지를 향해 계속 나아간다. 더 복잡한 예는 전력 전송을 포함하는 대규모 시스템 내의 여러 중복 발전 시설이다.

능동 중복성은 성능 저하 없이 고가용성을 달성하기 위해 복잡한 시스템에서 사용된다. 동일한 종류의 여러 항목이 고장을 감지하고 투표 방식을 사용하여 고장난 항목을 자동으로 우회하도록 시스템을 재구성하는 방법을 포함하는 설계에 통합된다. 인터넷 라우팅은 이 분야에서 Birman과 Joseph의 초기 작업에서 파생되었다.^[24]

무중단 시스템 설계는 모델링 및 시뮬레이션을 통해 평균 고장 간격 시간이 계획된 유지 관리, 업그레이드 이벤트 또는 시스템 수명보다 훨씬 길다는 것을 의미한다. GPS는 무중단 시스템의 한 예이다.

고장 계측은 제한된 중복성을 가진 시스템에서 고가용성을 달성하는 데 사용할 수 있다. 유지 관리 작업은 고장 표시기가 활성화된 후에만 짧은 기간의 가동 중지 시간 동안 발생한다.

모델링 및 시뮬레이션은 대규모 시스템의 이론적 신뢰성을 평가하는 데 사용된다. 이러한 종류의 모델의 결과는 다양한 설계 옵션을 평가하는 데 사용된다. 중복 시뮬레이션에는 N-x 기준이 포함된다. N은 시스템의 총 구성 요소 수를 나타내고 x는 시스템에 부하를 주기 위해 사용되는 구성 요소의 수이다.

10. 1. 중복성을 통한 고가용성 확보

참조

_[1] 웹사이트 high availability (HA) https://www.techtarg[...] 2024-04-01
_[2] 서적 High Availability: Design, Techniques, and Processes https://books.google[...] Prentice Hall
_[3] 웹사이트 Definitions - ResiliNetsWiki https://resilinets.o[...]
_[4] 웹사이트 Webarchiv ETHZ / Webarchive ETH https://webarchiv.et[...]
_[5] 간행물 Network resilience: a systematic approach https://ieeexplore.i[...] 2011-07-03
_[6] 웹사이트 operational resilience {{!}} telcos {{!}} accesstel {{!}} risk {{!}} crisis https://accesstel.co[...] 2023-05-08
_[7] 웹사이트 The CERCES project - Center for Resilient Critical Infrastructures at KTH Royal Institute of Technology. https://www.kth.se/a[...] 2023-08-26
_[8] 간행물 A Benders Decomposition Approach for Resilient Placement of Virtual Process Control Functions in Mobile Edge Clouds https://ieeexplore.i[...] 2018-12-03
_[9] 보고서 Castet J., Saleh J. Survivability and Resiliency of Spacecraft and Space-Based Networks: a Framework for Characterization and Analysis https://smartech.gat[...] American Institute of Aeronautics and Astronautics, AIAA Technical Report 2008-7707. Conference on Network Protocols (ICNP 2006) 2006-11-01
_[10] 문서 Lecture Notes http://www.cs.kent.e[...] M. Nesterenko, Kent State University
_[11] 문서 Introduction to the new mainframe: Large scale commercial computing Chapter 5 Availability http://comet.lehman.[...] 2006-01-01
_[12] Youtube IBM zEnterprise EC12 Business Value Video https://www.youtube.[...]
_[13] 서적 Precious metals, Volume 4 Pergamon Press
_[14] 서적 PVD for Microelectronics: Sputter Desposition to Semiconductor Manufacturing
_[15] 서적 Site Reliability Engineering: How Google Runs Production Systems
_[16] 웹사이트 Nines of Nines http://www.joshdepre[...] 2016-05-31
_[17] 문서 The myth of the nines http://searchstorage[...]
_[18] 간행물 Crying Wolf: False alarms hide attacks https://books.google[...] 2019-03-15
_[19] 웹사이트 After 35 years of technology crusades, Bob Metcalfe rides off into the sunset https://www.itworld.[...] 2019-03-15
_[20] 웹사이트 Goodbye Five 9s https://www.seeclear[...] Clearfield, Inc. 2019-03-15
_[21] 웹사이트 What is network downtime? https://www.techtarg[...] 2023-12-27
_[22] 서적 Reliability and Availability Engineering: Modeling, Analysis, and Applications Cambridge University Press
_[23] 서적 System Sustainment: Acquisition And Engineering Processes For The Sustainment Of Critical And Legacy Systems (World Scientific Series On Emerging Technologies: Avram Bar-cohen Memorial Series) World Scientific
_[24] IETF RFC "992"
_[25] 문서 Availability of enterprise IT systems – an expert-based Bayesian model http://www.kth.se/ee[...] Proc. Fourth International Workshop on Software Quality and Maintainability (WSQM 2010), Madrid
_[26] 서적 Blueprints for high availability John Wiley & Sons
_[27] 문서 Improving systems availability http://www.dis.uniro[...] IBM Global Services
_[28] 문서 HACMP는 High Availability Clustering Multiprocessing의 약자로서 고가용성 솔루션이라는 뜻이다.