이번 글은 가용성 아키텍처 전술에 대한 내용입니다. 가용성과 가용성 아키텍처 전술 정의 및 개념을 알아보고, 가용성 품질 속성 시나리오를 간략하게 세워보겠습니다. 마지막으로 가용성 아키텍처 전술 목록과 그 상세 내용을 정리해 보겠습니다.
이번 글의 순서는 아래와 같습니다.
- 가용성과 가용성 아키텍처 전술의 정의 및 기본 개념
- 가용성 아키텍처 전술 시나리오
- 가용성 아키텍처 전술 목록과 상세 내용
가용성(Availability)과 가용성 아키텍처 전술의 정의 및 기본 개념
가용성의 정의는 시스템이 전체 시간(정상 작동 시간 Uptime + 비정상 시간 Downtime) 중에서 정상적으로 작동하는 시간(Uptime)의 비율입니다. 주로 복원력을 양적으로 측정하는 지표로 사용됩니다.
가용성은 사용자가 필요로 할 때 작업을 기꺼이 수행하는 시스템의 특성으로 볼 수 있습니다.
대부분의 시스템은 내외부 요인에 의해 정상적으로 작동하지 않을 때가 있습니다. 이때 제공되지 않은 서비스가 일정 기간 내에 특정 값(수치)을 넘지 않고, 오류를 감추거나 정상으로 회복하는 시스템의 능력을 그 시스템의 가용성이라고 할 수 있습니다.
가용성은 시스템의 신뢰성과도 연관이 있습니다. 가용성의 기본 개념에는 시스템이 사용자가 원할 때 정상적으로 작동하는 신뢰성에 문제가 생겼을 때 스스로 복구하는 것이 포함됩니다.
이번 글의 주제인 가용성 아키텍처 전술은 가용성의 정의 및 기본 개념으로 부터 출발합니다. 가용성 아키텍처 전술은 시스템이 원하는 서비스를 더 이상 제공할 수 없는 상황이 발생했을 때, 이에 대처하는 방법 및 프로세스입니다.
가용성 아키텍처 전술 시나리오
가용성 아키텍처 전술 시나리오는 소프트웨어 시스템 다운 상황으로 서비스가 지속되기 힘들 때, 이를 대처하는 동작들로 구성됩니다.
가용성 품질 속성 시나리오의 구성 요소를 정리해 보면 다음과 같습니다.
| 시나리오 구성 요소 | 설명 | 예시 |
| 자극의 근원(Source) | 시스템의 내부, 시스템 외부 | 사용자, 운영자, 개발자, 시스템 관리자, 외부 시스템 |
| 자극(Stimulus) | 결함 발생 | 누락, 충돌, 타이밍, 응답 |
| 환경(Environment) | 정상 운영 환경, 비정상 운영 환경 | 정상 모드, Degrade 모드 |
| 대상(Artifact) | 가용성 대상 자원 | 프로세스, 통신채널, 저장소 |
| 응답(Response) | 가용성 적용 결과 | 기록, 알림, 무력화, 지속 |
| 응답 측정 (Response Measure) |
사용성의 비율 | 고장이 수리되는데 소요되는 시간 시스템이 사용가능해질 때까지 소요되는 시간 |
가용성 아키텍처 전술 목록과 상세 내용
주요 가용성 아키텍처 전술 목록에는 오류 감지, 오류 복구- 준비 및 수리, 오류 복구 - 재시작, 오류 예방 등이 있습니다. 각 아키텍처 전술 목록에 대한 상세 내용을 살펴보겠습니다.
1. 오류 감지 Detect Faults
오류 감지 방법은 Monitor, Ping/Echo, Heartbeat, Timestamp, Condition Monitoring, Sanity Checking, Voting, Exception Detection, Self-Test 등이 있습니다.
Monitor는 시스템의 다양한 건강 상태를 모니터링하는 컴포넌트를 두는 것입니다. 시스템의 실패 혹은 공유 자원의 소진 등을 모니터링해서 감지할 수 있습니다.
Ping/Echo는 노드 간에 비동기적으로 요청 및 반응하는 메시지를 주고받게 하는 것입니다. 컴포넌트가 살아있고 제대로 응답하는지 확인하는 방법입니다.
Heartbeat는 시스템 모니터와 모니터링되는 프로세스 사이에 주기적인 메시지를 교환해서 오류를 발견하는 것입니다. 모니터링 프로세스가 지속적으로 정상 작동 여부를 알려줍니다.
Timestamp로 분산 메시지 전살 시스템에서 잘못된 이벤트 순서를 발견할 수 있습니다. 이벤트가 발생한 이후에 즉시 이벤트에 로컬 시간 상태를 기록합니다.
Condition Monitoring으로 프로세스나 장치의 condition을 확인하고, 설계 단계에서 기술한 내용을 확인할 수 있습니다. 주로 checksum의 계산을 수행하며, 모니터링 자체는 오류가 없도록 간단해야 합니다.
Sanity Checking은 내부적인 설계, 시스템 상태, 정보 속성에 기반해서 컴포넌트의 특정 동작과 결과를 확인합니다. 인터페이스에서 자주 활용되며, 정보의 흐름을 조사할 수 있습니다.
Voting은 같은 입력을 서로 다른 노드들이 처리하고, 처리한 결과를 Voter에게 보냅니다. Voter는 투표 결과로부터 오류를 감지하는 것입니다.
Exception Detection은 실행의 정상 흐름을 변경하는 시스템의 조건을 발견하는데 초점을 맞춘 것입니다.
Self-Test는 컴포넌트가 스스로 정상 동작을 테스트하기 위해 절차를 수행하는 것입니다. 컴포넌트 자체 혹은 시스템 모니터에 의해 실행 가능합니다.
2. 오류 복구 - 준비 및 수리 Recover from Faults - Preparation and Repair
오류 복구(준비 및 수리) 방법에는 Active Redundancy, Passive Redundancy, Spare, Rollback, Exception Handling, Software Upgrade, Retry, Ignore Faulty Behavior, Degradation, Reconfiguration 등이 있습니다.
Active Redundancy는 모든 노드가 동시에 같은 입력을 받아 병행으로 처리하고, 오류 발생 시 밀리 세컨드 내로 회복하는 것입니다.
Passive Redundancy는 Active Node(instance, member)가 주로 입력을 받아 처리하고, non-Active Node는 주기적으로 상태만 업데이트하는 것입니다. Active Node의 오류 발생 시 non-Active Node가 입력을 받아 처리합니다.
Spare는 실패가 발생하기 전까지 관여하지 않고, 오류가 발생하면 중복된 나머지 노드가 오류 발생 노드를 대체하는 것입니다.
Rollback은 시스템의 오류를 발견했을 때, 이전의 좋은 상태로 돌아갈 수 있도록 허용하는 것입니다. 체크 포인트가 특정 저장소에 저장되고, 정해진 시간에 업데이트되어야 합니다.
Exception Handling은 예외 발생 시, 오류를 정정하는 방향으로 정보를 제공하는 것입니다. 오류 정보를 감추거나 수리/복구하는데 활용할 수 있습니다.
Software Upgrade는 서비스에 영향을 주지 않는 방법으로 서비스를 업그레이드하는 방법입니다. Function과 Class 수준에서 패치를 제공하고, 중복 Spare를 활용하는 방법도 있습니다.
Retry는 오류가 발생했을 때, 해당 오류를 일시적인 현상이라고 가정하고 해당 동작을 재시도하는 것입니다.
Ignore Faulty Behavior는 특정 리소스에서 오는 메시지 자체가 문제가 있다고 판단되면 이를 무시하는 것입니다.
Degration은 오류 발생 시 가장 핵심인 시스템의 기능만 유지하고, 나머지 기능들은 버리는 것입니다.
Reconfiguration은 현재 제약되는 자원이나 컴포넌트에 책임을 재할당해 실패로부터 회복하는 것입니다.
3. 오류 복구 - 재시작 Recover from Faults - Reintroduction
오류 복구(재시작)에는 Shadow, State Resynchronization, Escalating Restart, Non-stop Forwarding 등이 있습니다.
Shadow는 오류가 발생하거나 서비스를 업그레이드하는 컴포넌트를 'Shadow mode'로 일정 시간 두었다가 Active 상태로 정상화하는 것입니다. Shadow mode 기간 동안 행위가 정확한지 점검하고 상태를 정상화합니다.
State Resynchronization은 Active redundancy나 Passive redundancy에서 Active 혹은 standby 노드들의 상태 동기화 여부를 확인하기 위해 주기적으로 비교하는 것입니다. Checksum과 hash function 등을 사용합니다.
Escalating Restart는 서비스에 미치는 영향을 최소화하기 위해 재시작하는 기준을 정해서 재시작하는 방법입니다. 보통 재시작 기준을 Level로 표현해서 정합니다.
예를 들면, Level 0은 서비스에 미치는 영향이 적어서 무시, Level 1은 비보호 메모리를 모두 해제 및 초기화, Level 2는 모든 메모리 모두 해제 및 초기화, Level 3는 관련 이미지와 데이터 세그먼트 모두 다시 로딩 및 초기화처럼 정합니다.
Nons-stop Forwarding은 라우터 설계에 주로 사용합니다. 실패가 발생했을 때 알려진 경로로 패킷을 계속 보냅니다. 동시에 라우팅 정보를 회복해 확인합니다.
4. 오류 예방 Prevent Faults
오류 예방에는 Removal from Service, Transactions, Exception Prevention, Increase Competence Set, Predictive Model 등이 있습니다.
Removal from Service는 일시적으로 시스템 컴포넌트를 서비스 상태에서 제외해 잠재적인 시스템 실패를 완화하는 방법입니다. 예를 들면, 메모리 leak 현상이 발생하면, 해당 구성요소를 메모리에서 제거했다가 다시 적재하는 것입니다.
Transactions는 분산 컴포넌트 간에 교환하는 비동기적 메시지에 대해서 트랜잭션의 ACID 성질을 적용하는 방법입니다.(A : Atomic, C : Consistent, I : Isolated, D : Durable)
Exception Prevention은 시스템의 예외 발생을 사전에 예방하는 것입니다. 잘못된 포인터를 예방하기 위해 추상 데이터 타입으로 스마트 포인터를 구성하는 등 에러 정정 코드를 통해 예방합니다.
Increase Competence Set은 작동이 'Competent'한 상태들의 집합입니다. 예외 및 오류 발생 시 정상 운영이 가능하도록 가능한 많은 케이스를 다루도록 설계한 것입니다.
Predictive Model은 시스템의 건강상태를 모니터링하다가 임계점에 도달했을 때 예방 동작을 수행하는 것입니다. 서버에서의 세션 수립 비율, 메시지 큐 길이 통계 등을 활용합니다.
※ 함께 보면 좋은 글
1. 아키텍처 전술 : 변경 용이성(Modifiability) 정의, 개념, 시나리오, 전술 목록
아키텍처 전술 : 변경 용이성(Modifiability) 정의, 개념, 시나리오, 전술 목록
이번 글에서는 아키텍처 전술 중 하나인 변경 용이성 전술에 대해서 정리했습니다. 변경 용이성은 소프트웨어 아키텍처 주요 품질 속성 중 하나입니다. 변경 용이성의 정의와 기본 개념부터 품
mmp2022.tistory.com
2. 소프트웨어 아키텍처 전술과 적용시 고려할 설계 결정 항목
소프트웨어 아키텍처 전술과 적용할 때 고려해야 할 설계 결정 항목들
소프트웨어 아키텍처 전술은 품질 속성 반응에 영향을 주는 설계 결정이며, 품질 수준을 조절 가능한 상위 수준의 패턴을 결정하는 기법입니다. 이번 글에서는 품질 속성 시나리오와 아키텍처
mmp2022.tistory.com
3. 소프트웨어 아키텍처의 품질 속성 특징과 문제점, 그리고 품질 속성 시나리오
소프트웨어 아키텍처의 품질 속성 특징과 문제점, 시나리오(with 예시)
소프트웨어 아키텍처에서 품질 속성(Quality attribute)은 가장 중요한 요소입니다. 이번 글에서는 소프트웨어 아키텍처의 품질 속성 특징과 문제점, 그리고 문제점을 극복하기 위한 품질 속성 시나
mmp2022.tistory.com
'IT' 카테고리의 다른 글
| 배포 용이성(Deployability) 아키텍처 전술, 시나리오, 전술 목록 (0) | 2023.01.31 |
|---|---|
| 상호 운용성(Interoperability) 아키텍처 전술, 시나리오, 전술 목록 (0) | 2023.01.31 |
| 아키텍처 전술 : 변경 용이성(Modifiability) 정의, 개념, 시나리오, 전술 목록 (0) | 2023.01.26 |
| 소프트웨어 아키텍처 전술과 적용할 때 고려해야 할 설계 결정 항목들 (0) | 2023.01.25 |
| 소프트웨어 아키텍처의 품질 속성 특징과 문제점, 시나리오(with 예시) (0) | 2023.01.20 |
댓글