https://www.youtube.com/watch?v=tLLs7fKts2o
위 영상을 보고 정리한 글입니다.
DR
RTO 및 RPO
RTO
- 복구 시간 목표
- 재해 발생 시 얼마나 오래 오프라인 상태 유지 가능한지
- 서비스가 복구되는 데 걸릴 수 있는 시간
- 재해 발생 후 복구까지의 시간
RPO
- 복구 시점 목표
- 재해 발생 시 데이터 손실을 얼마나 감당할 수 있는 지
- 마지막 백업 또는 스냅샷 이후 재해 발생 시까지 경과한 시간
- ex) PRO가 1시간이면 데이터 베이스를 1시간마다 백업해야 함.
- 짧을수록 힘들고 비싸짐
💡
PTO, PRO가 짧을수록 복구 솔루션의 복잡성과 비용이 증가함.
PTO, PRO가 길수록 복구 솔루션이 더 저렴하고 간단해지지만 더 많은 데이터가 손실되고 서비스가 오래 중단됨.
3가지 재해 복구 전략과 아키텍쳐
Backup and Restore
- RTO, RPO가 ‘시간’ 기준일 경우 사용할 수 있는 전략
- 저렴하고 심플
서버 하나만 사용
- 서비스가 몇시간 오프라인 되어도 상관없을 때 사용
- 재해가 발생하면 백업자료로 서비스를 복구
Active/Passive 전략
- RTO, RPO가 ‘분’ 기준일 경우 사용할 수 있는 전략
- 리소스의 ‘active’ 버전 보유
- 리소스의 액티브 버전 공유 실패하면 대기상태의 리소스를 ‘passive’버전으로 보유
- 메인서버, 메인 데이터베이스 : ‘active’ 버전
- 서버와 데이터베이스의 동일한 복사본이 성능이 약간 낮은 시스템에서 대기 상태로 존재
- ‘active’ 데이터베이스를 ‘passive’데이터베이스에 동기화 시켜놓음
- ‘active’ 서버나 데이터베이스가 중지되면 빠르게 ‘passive’ 서버와 데이터베이스로 전환 가능
- 그 사이에 ‘active’ 서버나 데이터베이스를 고치거나 ‘passive’서버에 더 많은 리소스 제공
active/active 전략
- 더 비싸고 복잡하지만 가장 표준적인 전략
- RTO, RPO가 거의 ‘실시간’에 가까울 경우 사용할 수 있는 전략
- 동일한 서버의 여러 복사본을 나란히 실행하고 서버와 유저 사이에 ‘Load Balancer’ 배치
- Load Balancer : 사용자로부터 요청을 받아 사용 가능한 서버로 전달하는 역할
- 만약 서버가 죽으면 Load Balancer는 죽은 서버를 무시하고 해당 요청을 처리할 수 있는 서버로 전달
- Load Balancer가 고장나지 않도록 잘 모니터링 해야 함
추가
Terraform
- HashiCorp사가 만든 오픈 소스 "코드형 인프라" 툴
- Terraform을 사용하는 이유
- 개방형 소스
- Terraform은 플랫폼에 플러그인을 빌드하는 유통사의 대규모 커뮤니티를 지원
- 사용하는 클라우드 공급자에 관계없이 플러그인, 확장, 전문 지원을 쉽게 찾을 수 있음
- 플랫폼 애그노스틱
- 모든 클라우드 서비스 공급자와 함께 사용할 수 있음
- 변경 불가 인프라
- 대부분의 코드형 인프라는 변경 가능 인프라를 생성
- 변경 가능한 인프라는 인프라가 미들웨어 업그레이드 또는 새 스토리지 서버와 같은 변경을 수용하도록 변화할 수 있음
- 변경 내용이 쌓이면서 다른 서버 또는 기타 인프라 요소의 실제 프로비저닝이 원래 구성에서 더 멀리 '드리프트'되어 버그 또는 성능 문제를 진단하고 정정하기 어렵기 때문에 변경 가능한 인프라는구성 드리프트의 위험을 내포
- Terraform은 변경 불가 인프라를 프로비저닝하며, 이는 환경에 대한 모든 변경사항에 대해 현재 구성이 변경을 기술하는 새로운 구성으로 대체되고 인프라가 다시 프로비저닝됨을 의미
- 장점으로 이전 구성은 필요하거나 원할 경우 롤백이 가능한 버전으로 유지 가능
- 대부분의 코드형 인프라는 변경 가능 인프라를 생성
- 개방형 소스
카오스 몽키
- 서비스를 공급하는 인스턴스에 일부러 랜덤으로 장애를 일으키는 것
- 목적
- 가장 약한 부분이 어디인지 파악하여 엔지니어가 문제에 대처하는 자동화된 트리거를 성정
- 지역 단위의 중단을 시뮬레이션하는 실험을 정기적으로 실행해 조기에 모든 시스템 약점을 파악해 수정 가능
- 카오스 몽키의 종류
- Latency monkey : RESTful 클라이언트-서버 통신 계층에 인공적인 지연 유발
- Conformity monkey : 최상의 조건이 아닌 인스턴스를 찾아 종료 (예:자동 스케이링 그룹에 속하지 않은 인스턴스를 찾아 재시작)
- Doctor monkey : 인스턴스들의 상태를 점검하고 CPU 부하율 등의 정보들을 모니터링하여 불안정한 인스턴스를 탐지하여 제거
- Janitoy monkey : 클라우드 환경이 잡음으나 낭비 없이 작동하도록 보장, 사용되지 않는 리소스들을 찾아 제거
- Security monkey : Conformity monkey의 확장으로 보안에 위배되거나 최약점을 찾고 공격하는 인스턴스 종료
- 10-18 monkey : 다양한 언어와 문자를 사용하여 여러 지역에서 고객에서 서비스를 제공할 경우 설정 및 런타임 문제 감지
- monkey : AWS의 가용성 영역을 전체적으로 중단
Uploaded by Notion2Tistory v1.1.0