가용성
- 시스템이 서비스를 정상적으로 제공할 수 있는 상태
- 항상 서비스할 수 있는 시스템을 가용성이 높은 시스템이라고 한다.
가용성을 하락시키는 요인
1. 네트워크 장애
2. 전원장애
3. 하드웨어 장애
4. 소프트웨어 장애
5. 점검기간 (하드웨어 교체 , 소프트웨어 업데이트 , 미들웨어 업데이트)
6. 고부하에 따른 요청 타임아웃
높은 가용성을 가진 시스템 설계방법
1. 시스템 이중화
- 단일 장애점을 없애는 방법(대체 시스템을 구축한다)
- 시스템의 일부분을 사용할 수 없게 되어도 다른 시스템을 이용하여 서비스를 계속해서 제공하는 것
* 대체 시스템은 원래의 시스템과 독립적이어야 한다.!
* 단일 장애점
- 그 지점에 장애가 발생하면 서비스를 제공할 수 없는 지점
*데이터베이스 이중화
- 데이터베이스는 하드웨어 뿐 아니라 데이터베이스의 내용까지 이중화를 해야하므로 어렵다
1) 여러대의 데이터베이스에 같은 데이터를 저장하고 참고한다
=> 읽기 쓰기 시간에 대한 속도 저하가 온다.
2) 한쪽의 데이터를 저장하고 자동으로 반대쪽으로 동기화를 한다
=> 데이터 동기화가 어렵다
sync는 동기화중 처리 지연에 따른 성능저하가 발생한다
async는 데이터베이스간 데이터 무결성 문제가 발생한다
리던던시
- 같은 장비를 병렬로 배열한 대수를 리던던시라고 한다.
2. 시스템 확장
- 사용자의 요청이 많아져 현재의 인프라로 요청을 처리 할 수 없는 경우가 발생해도 가용성이 저하된다.
1) 스케일 업/다운
*스케일 업 - 시스템의 리소스 처리 능력을 올리는 방법
- 스케일업을 하는 도중에는 서비스를 제공할 수 없어(다운타임 발생) 가용성이 떨어진다.
*스케일 다운 - 시스템의 리소스 처리 능력을 내리는 방법
2) 스케일 아웃/인 ( AWS - ELB를 이용하여 동적으로 가능 )
*스케일 아웃 - 시스템의 처리능력을 향상 시키기위해 시스템의 개수를 늘리는 방법
- 스케일 아웃/인을 실시 하는 경우에는 다운타임이 발생하지 않는 경우가 많다.
*스케일 인 - 시스템의 개수를 줄이는 것
고가용성 요구사항
1. 복구 목표 시간(RTO)
- 시스템이 얼마나 빨리 복구되어야 하는지
- 장애가 일어난 직후 바로 복구를 하는것이 이상적
2. 복구 목표 지점(RPO)
- 데이터 손실을 얼마나 감당할 수 있는지
- 내가 필요한 지점으로 완전히 복구하는것이 이상적
1) Complete Recovery
- 완벽한 복구
2) InComplete Recovery
- 불안전하지만 특정지점으로 복구
- 특정 지점이후에 장애가 일어나거나 흐름이 잘못되었을 경우 그지점의 이전 지점으로 돌아가야할 때 사용한다
내결함성
- 어플리케이션 구성요소의 기본적인 중복성을 말함
복구성
- 재해 발생후 서비스 복구와 관련된 프로세스 정책 및 절차
확정성
- 어플리케이션의 설계변경이 없이 확장을 수용하는 능력
'Infra' 카테고리의 다른 글
서버운영 - JMeter 웹 부하테스팅 (0) | 2019.01.08 |
---|---|
서버운영 - 부하발생기 JMeter 설치방법 (0) | 2019.01.08 |
서버운영 - AWS EC2 부하 테스트 실습 (동시 접속자) (0) | 2019.01.01 |
물리적 하드웨어 트러블 슈팅 (0) | 2018.11.08 |
시스템과 인프라 기초지식 (0) | 2018.11.06 |