4. Infrastructure 설계 핵심 사항 (가용성 편)
1. 데이터 센터 다중화
: 복수의 가용 영역(AZ)에 걸쳐 인프라를 구성하는 것을 원칙으로 한다.
2. 장애 모니터링 및 자동 복구
: 클라우드 워치 서비스를 이용하여 장애를 탐지하고, 자동으로 복구한다.
3. 리전의 다중화
: DNS 서비스인 Route 53의 DNS 장애 복구 기능을 사용하여 장애 발생 시 Backup-site로 전환한다.
6. AWS Cloud
VPC
User
Seoul Region (Main-Site)
Cloud
Watch
AWS Cloud
ELB
Availability
Zone (A)
Availability
Zone (B)
EC2 EC2
S3
AWS Cloud
VPC
Availability
Zone (A)
Availability
Zone (B)
ELB
Tokyo Region (Backup-Site)
EC2 EC2
S3
RDS
Master Stanby Read
Replicas
Availability-Oriented Architecture
Route 53
RDS RDS
AWS Cloud다중 AZ에 AP 서버를 배
치, ELB로 로드밸런싱
클라우드 워치로 모니터
링, 장애 발생 시 자동 복
구 실시
마스터 장애 발생 시 스
탠바이로 교체
백업사이트로 데이터 동
기화
메인사이트 장애 발생 시
마스터로 승격
8. Availability Zone(AZ), 다중화가 기본이다.
▶ 가장 기본적이며, 저렴하고 효과가 큰 가용성 보장 방법?
: 복수의 가용 영역(AZ)에 걸쳐 인프라를 구성하는 것
Region
Availability
Zone (A)
Availability
Zone (B)
. . .
각 AZ 내에는 별도의
백본망과 전원이 존재
하나의 리전에는 최소 2
개의 AZ가 존재함.각 AZ는 서로에게 영향을 미치지 않음 !
10. SLA로 추산한 가용성 ??.?%
서비스 SLA 장애로 인정되는 경우 필요조건
EC2 99.95% 동일 리전 내에서, 사용자가 인스턴스를 실행하는 복수의 AZ에 대해 외부에서 접속이 안되는 경우
복수의 AZ에 리소스를 배치
EBS 99.95% 동일 리전 내에 사용자가 인스턴스를 실행하는 복수의 AZ에서 읽기/쓰기가 불가능한 경우
RDS 99.95% 멀티-AZ 인스턴스 실행을 요구하는 모든 접속이 1분간 실행되지 않는 경우
Route 53 100% DNS 쿼리 응답에 실패한 경우
=> AWS에서 추산한 가용성 99.90% !!
12. EC2 인스턴스 자동 복구 방법
Cloud Watch
-> 모니터링 서비스가 주력이지만, 자동 복구도 가능 !
Auto Recovery 기능을 이용 (일일 최대 3번까지)
* 자동 복구가 실패하는 경우도 있음.
주요 모니터링 지표 내용
EC2
StatusCheckFailed_System
StatusCheckFailed_Instance
CPUUtilization
호스트 하드웨어 레벨의 상태 체크 결과(0: 정상, 1: 이상)
인스턴스 레벨의 상태 체크 결과(0: 정상, 1 : 이상)
CPU 사용률(단위 : %)
ELB
HealthyHostCount
BackendConnectionErrors
HTTPCode_ELB_5XX
Latency
ELB에 연결된 정상적인 EC2 인스턴스 수
ELB로부터 EC2 인스턴스로의 커넥션 에러 수
HTTP(S) 요청에 대해 HTTP 500번대 에러가 발생한 횟수
ELB에 요청 도착 후 ELB로부터 응답이 반환되기까지의 평균 시간 (단위 : 초)
RDS
FreeStorageSpace
DatabaseConnections
CPUUtilization
이용 가능한 스토리지 용량(단위 : 바이트)
사용 중인 데이터베이스 접속 수
CPU 사용률(단위 : %)
Auto-Scaling의 트리거로도 사용가능 !
(EX.. EC2의 다운 / CPU 사용률 상승 / Request 증가)
14. 발생 빈도가 적은 대규모 장애에 대응하기
Region
Availability
Zone (A)
Availability
Zone (B)
. . .
희박하겠지만... 지진 등 대규모 재해 혹은 AWS 내부 인력의 실수 등
으로 인한 리전의 사용 불가능도 고려 대상 !
1) 장애 발생 시 자동으로 리전 전환하기
(다운타임이 짧지만, 고비용)
2) 백업 데이터로부터 복구용 서버를 만들기
(다운타임이 길지만, 저비용)
16. 백업 사이트로 자동 전환하기
Route 53
- AWS Route 53 서비스의 DNS 장애 조치(Failover)를 이용
- 기본(메인) 사이트의 ELB Health Check 진행, 인스턴스와 애플리케이션이 모두 다운되었
을 경우 백업 사이트로 연결 재설정
- 기본 사이트와 백업 사이트 간에 동일한 데이터가 있다는 것을 전제
17. 백업 사이트로 자동 전환하기 (데이터 동기화 방법)
- AWS EBS에는 실시간 복제 기능이 없음.
1) 정기적으로 스냅샷을 찍어 백업 사이트로 복사 (Ex. Copy-snapshot 명령어를 CLI에서 반
복 실행하게 설정)
Amazon Elastic Block
Store 2) EC2에서 실행되는 데이터 동기화 도구(Ex. Linux의 DRBD 등)을 이용하여 실시간 동기화
Amazon RDS
- Cross-Region Read Replicas (읽기 전용 복제본) 기능을 이용
1) 읽기 전용 복제본의 마스터 승격은 RDS의 API로 제공됨.
- Route 53 Failover 기능과 연동되지 않는 문제 발생 !
( 자동으로 시스템 다운을 감지하고, 마스터 승격을 위한 API 실행될 수 있도록 구성 필요 )
1) 클라우드 워치를 통해 감시하고, 경보를 통해 Lambda를 호출 후 명령을 실행
2) 자빅스(Zabbix)와 같은 도구와 연계하여 장애 탐지를 트리거로 하여 명령을 실행
18. 백업 사이트로 자동 전환하기 (데이터 동기화 방법)
Amazon S3
- Cross-Region Replication 기능을 이용
종합적으로, DNS 장애 조치에 몇 분 정도 소요됨.
그러나 온프레미스 환경과의 다운 타임을 비교하였을 때 훨씬 빠르게 복구 가능
20. AWS Cloud
VPC
Seoul Region (Main-Site)
AWS Cloud
ELB
Availability
Zone (A)
Availability
Zone (B)
EC2 EC2
AWS Cloud
VPC
Availability
Zone (A)
Availability
Zone (B)
ELB
Tokyo Region (Backup-Site)
EC2 EC2
RDS
Master Stanby Master
Availability-Oriented Architecture (저렴하게, HA 보장하기)
RDS RDS
AWS Cloud
최신 EC2 인스턴스로
AMI 작성
SnapShot
AMI
EBS와 RDS 스냅샷을 정
기적으로 작성
SnapShot
스냅샷을 백업 사이트에
복사
AMI를 백업 사이트에 복
사
평소에는 정지 상태로
두고, 사이트 전환 시에
AMI와 스냅샷으로 실행
S3는 크로스 리전 복제
기능을 그대로 이용
