RTO, RPO
동기적/비동기적 디커플링
1교시
어제는 고가용성을 위해 CloudWatch, AutoScaling 수업
다른 가용 영역에 복구 - 오토스케일링을 활용하여 장애가 발생한 가상 서버 복구
- 복구 시간 목표(RTO)
시스템이 오류를 복구하는데 걸리는 시간(= 시스템 중단 후 서비스를 다시 제공하기까지 걸린 시간). 서버 장애 이후 새로운 서버가 시작되고, 내용물이 설치되고 실행되기까지의 시간
- 복구 지점 목표(RPO)
오류 발생 시 수용할 수 있는 데이터 손실 기간. 데이터 손실의 양은 시간으로 측정된다(오전 10시에 장애 발생 후 오전 9시의 스냅숏으로 시스템을 복구한다면 데이터 손실의 시간 범위는 1시간).
어제 한 실습에서는 yml 템플릿을 배포, EC2 인스턴스를 오토스케일링으로 배포했다.
-> 배포된 젠킨스 EC2 인스턴스 종료 후 새롭게 생성된 젠킨스 EC2 인스턴스 확인
이 방식에는 2가지 문제가 있다.
1. 젠킨스 서버는 데이터를 디스크에 저장하는데, 새로운 가상 서버가 시작되면 디스크가 생성되기에 이전 데이터는 손실된다.
-> 여러 가용 영역을 사용하는 관리 서비스 사용(RDS, DynamoDB, S3)
-> EBS 볼륨의 스냅샷을 생성하고 가상 서버를 다른 가용 영역에서 복구할 때 이 스냅숏 사용(EBS 스냅숏은 여러 가용 영역에서 사용할 수 있도록 S3에 저장되어 있다)
-> 분산 서드파티 스토리지 솔루션 사용(GlusterFS, DRBD 등)
※ 젠킨스는 디스크에 데이터를 직접 저장하기에 RDS, DynamoDB, S3 사용 불가. 블록 수준 스토리지를 대신 사용해야 한다.
2. 복구를 위해 새로운 가상 서버가 시작되면 젠킨스 서버의 공용/사설 IP 주소가 바뀐다. 엔드포인트가 변경된다.
-> EIP를 사용하면 해결
-> ELB를 정적 엔드포인트로 사용한다.
2교시
받은 템플릿으로 스택 구축
AutoScaling 시작 그룹의 설정에 의해 생성된 인스턴스 종료 후 새롭게 생성된 인스턴스 확인
-> 탄력적 IP 주소 다시 할당되었는지 확인
RPO를 줄이겠다고 백업을 너무 자주 하면 시스템 성능이 떨어질 수 있다. 데이터 중요도에 따라 RPO를 조절
- Cloud Native
클라우드를 적극적으로 활용하는 것.
| RTO | RPO | 가용성 | |
| 가상 서버가 CloudWatch 알람에 의해 Trigger되어 복구되는 경우 | 약 10분 | 데이터 손실 없음 | 가상 서버의 오류는 복구되지만, 전체 가용 영역의 장애로부터의 복구는 불가 |
| 가상 서버가 AutoScaling으로 복구되는 경우 | 약 10분 | 마지막 스냅샷 이후의 모든 데이터 손실. 스냅샷을 다시 찍을 수 있는 간격은 30분 ~ 24시간 | 가상 서버의 오류도 복구되고, 전체 가용 영역의 장애로부터의 복구 가능 |
- 고가용성 요약
기반 HW와 SW에서 오류가 발생하면 가상 서버에도 오류가 발생한다.
CloudWatch 알람을 활용하여 장애가 발생한 가상 서버를 복구할 수 있다.
-> 동일한 가용 영역 안에서.
AWS 리전은 가용 영역이라는 격리된 데이터센터들로 구성된다.
여러 가용 영역을 사용하면 데이터센터에 장애가 발생해도 복구할 수 있다.
몇몇 AWS 서비스는 기본적으로 여러 가용 영역을 사용하지만, 가상 서버는 단일 가용 영역에서 실행된다.
가용 영역 장애가 발생하는 경우라도 Auto Scaling을 사용해서 단일 가상 서버가 항상 실행되도록 보장할 수 있다.
데이터를 RDS, S3, DynamoDB 같은 관리형 스토리지 서비스 대신 EBS 볼륨에 저장하면 다른 가용 영역에서 복구하기 까다롭다.
- 동기(Synchronous)
동시에 일어난다는 뜻. 요청과 그 결과가 동시에 일어난다.
요청을 하면 시간이 얼마가 걸리던 요청한 자리에서 결과가 주어져야 한다.
-> 설계가 간단하고 직관적이지만, 결과가 주어질 때까지 대기해야 한다.
- 비동기(Asynchronous)
동시에 일어나지 않는다는 뜻. 요청과 결과가 동시에 일어나지 않는다.
요청한 그 자리에서 결과가 주어지지 않으며, 노드 사이의 작업 처리 단위를 동시에 맞출 필요 없다.
-> 동기보다 복잡하지만 결과가 주어지는데 시간이 걸리더라도 작업 중 다른 작업을 할 수 있다.
- 인프라 디커플링 개요
회의를 한다고 치면 만족해야 할 조건들이 있다.
같은 위치, 같은 시간, 회의를 할 상대
-> 회의는 '위치'라는 조건에 연결(Coupled)되어 있다.
화상 회의를 한다면 '같은 위치' 조건을 삭제할 수 있다.
-> 회의를 '위치'라는 조건으로부터 연결 해제(Decoupling)
이메일로 대체한다면 '같은 시간', '같은 위치' 조건을 삭제할 수 있다.
시스템에서도 커플링된 요소들이 있다.
1. 웹 서버에 요청을 하려면 해당 서버의 공인 IP 주소를 알아야 하고, 서버가 그 주소에 연결되어 있어야 한다.
회의 장소 = 공인 IP 주소
-> EIP를 할당한 Auto Scaling 그룹으로 연결된 ELB를 통해 접근 = 장소(주소) 조건 삭제됨
2. 웹 서버에 요청을 하려면 해당 시점에 웹 서버가 온라인 상태여야 한다.
회의 시간 = 특정 시점에 온라인 상태
-> Auto Scaling을 통한 가용성 확보
위 2가지 문제는 동기적 디커플링 방법인 ELB로 해결 가능.
ELB는 동기적 디커플링 방법
비동기적 디커플링을 위해서는 SQS(Somple Queue Service), SNS(Simple Notification Service) 사용
- SNS
Topic(Publisher/Subscriptor)
Push : 사용자에게 메시지 전송
Fanout : 같은 메시지를 여러 방향으로 발행
메시지를 받는 사용자가 없으면 몇 번 시도하다가 삭제된다(동기식).
하나의 메시지를 사용자들이 각각 다른 방식으로 활용
- SQS
Queue
Pull : 사용자가 메시지를 가져온다
Decouple : 여러 서비스로 분리하여 병렬식 비동기 처리
메시지는 일정 기간동안 유지된다.
하나의 메시지를 사용자들이 동일한 방식으로 활용
(대충 이메일같은 방식이라고 생각하자)
외부에 웹 서버를 노출하면 종속성이 하나 생긴다.
-> EC2 인스턴스의 공인 IP 주소에 대한 종속성.
= 클라이언트들이 이 주소로 요청을 보낼 것이기에 공인 IP를 변경하기 어렵다.
-> 새로운 서버를 추가해 부하를 분산하려 해도 클라이언트들은 새로운 서버의 주소를 모르고 계속 기존 주소로 요청을 보낸다.
DNS를 사용할 수도 있지만, 이러면 다른 문제가 발생할 수 있으니 배제하고 생각하자.
가장 좋은 해결 방법은 로드 밸런서를 사용하는 것.
-> 동기식 디커플링에 활용 가능 : 로드 밸런서가 요청을 받고, 로드 밸런서는 응답이 가능한 웹 서버에게 요청을 넘기고 응답을 받아서 클라이언트에게 응답
4교시
그동안 실습에서 HTTP를 사용했는데, 이러면 암호화 문제로 탈취당할 수 있다.
-> HTTPS를 사용해야 한다.
-> 사용하려면 인증서를 만들어야 한다.
-> 인증서가 ELB에도 설정되어 있어야 한다.
CMK, ACM, KMS - 키나 인증서까지도 클라우드에서 관리(Cloud Native)
5교시
로드 밸런서로 동기 디커플링 하기 - ELB와 Auto Scaling의 연동
오토 스케일링 그룹의 앞단을 ELB로 묶는다.
오토 스케일링 그룹은 항시 2대 이상의 서버가 실행되고 있고, 여기서 시작되는 서버는 자동으로 ELB에 등록된다.
과거에는 ELB-리스너-타겟 그룹을 만들고, 여기에 미리 생성한 EC2 인스턴스 ID를 입력해 연결했다.
-> TargetGroups 타입에 Targets 지시자에 인스턴스 ID를 작성했었다.
오토 스케일링 시작 구성 설정 - 인스턴스 2대로 시작해서, 최소 1대, 최대 4대 가동하도록 설정
-> 오토 스케일링 시작 구성이 관리하는 EC2의 주소는 동적이기에 예전처럼 인스턴스 ID로 연동 불가.
TargetGroup은 ELB TargetGroup 타입의 작업명이다.
위 코드를 보면 예전에는 Targets 지시자가 있었는데, 여기에는 없다.
기존에는 EC2로 대상을 찍었는데, 이제는 AutoScaling Group을 대상으로 찍어서 그룹 안에서 인스턴스가 늘어나든 말든 알아서 하라고 내버려두는 것.
6~7교시
받은 템플릿에 에러가 많아서 종일 고쳤다.
오토 스케일링 그룹에서 프라이빗 서브넷을 연결했는데, 이러면 시작 구성을 통해 시작되는 인스턴스들이 프라이빗 인스턴스가 된다.
-> 프라이빗을 그대로 두면 외부 통신이 안되서 패키지가 설치 안됨. NAT 게이트웨이, 프라이빗 라우팅 테이블 생성
-> NAT 게이트웨이로의 라우팅 경로 생성 및 프라이빗 서브넷에 프라이빗 라우팅 테이블 연결
AWS::AutoScaling::LaunchConfiguration 타입(시작 구성)은 수정할 수 없는 리소스라 업데이트가 안된다.
-> 이 부분에 수정 사항이 있다면 스택을 삭제 후 재생성할 것.
어쨌건 완성한 스택의 작동을 확인
시작하면 2개의 인스턴스가 가동되고 있다.
-> ELB 도메인으로 접속해서 부하 발생시키면 인스턴스가 4개까지 늘어난다
8교시
그런데 늘어난 인스턴스가 다시 줄어드는데는 시간이 꽤 걸리는 것 같다.
-> 어디서인지는 몰라도 요청이 주기적으로 들어오고 있다.
뒤져보니 인스턴스 중 하나가 계속 CPU 사용량이 99 퍼였다.
-> 해당 인스턴스로 들어가 httpd를 종료시키던가, 인스턴스를 종료시키던가
3교시(11:30 ~ 11:50) 동기/비동기 설명 다시 듣기
4교시(12:30~12:45)
'교육' 카테고리의 다른 글
| [72일 차] 21.11.04 : DevOps 13 (0) | 2021.11.04 |
|---|---|
| [71일 차] 21.11.03 : DevOps 12 (0) | 2021.11.03 |
| [69일 차] 21.11.01 : DevOps 10 (0) | 2021.11.01 |
| [68일 차] 21.10.29 : DevOps 9 (0) | 2021.10.29 |
| [67일 차] 21.10.28 : DevOps 8 (0) | 2021.10.28 |
댓글