들어가며
대규모 트래픽을 고려하며 가용성과 보안성을 준수하는 올리브영 Public Cloud(AWS) 인프라 아키텍처 구축이라는 프로젝트를 진행하며 고가용성을 목적으로 운영 환경에서 모든 이중화를 마치고 리전에 대한 이중화도 필요하다고 생각했다.
아무래도 최근 CSP(Cloud Service Provider) 외부 원인일지라도 특정 클라우드 업체에 장애가 나는 경우가 있기에 멀티 클라우드로 해결하면 좋겠지만 우리는 정해진 CSP인 AWS를 기반으로 멀티 리전을 통해 해결하려고 했다.
또한 재해 복구 대상을 분석하고 전략 별 RPO 및 RTO에 따른 적절한 재해 복구 전략을 선택했다.
재해 복구 대상 분석
클라이언트 요청 흐름
Client REST API→ ALB→ EKS(Node Cluster) → Pod(Container) → Code(Application) → Cache DB→ DB에 대한 클라이언트의 모든 요청에 멀티 리전에서도 이중화를 하여 고가용성을 달성하는 것이 목표이다.
기술 블로그 분석
클라우드 환경에서 재해 복구에 대한 공식 기술 블로그
Disaster recovery options in the cloud - Disaster Recovery of Workloads on AWS: Recovery in the Cloud
Disaster recovery options in the cloud Disaster recovery strategies available to you within AWS can be broadly categorized into four approaches, ranging from the low cost and low complexity of making backups to more complex strategies using multiple active
docs.aws.amazon.com
AWS 기반 재해 복구(DR) 아키텍처, 1부: 클라우드에서의 재해 복구 전략 | Amazon Web Services
이 글은 AWS Architecture Blog에 게시된 Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud을 한국어로 번역 및 편집하였습니다. 필자는 AWS Well-Architected 신뢰성 원칙의 수석 솔루션 설
aws.amazon.com
AWS 기반 재해 복구(DR) 아키텍처, 2부: 신속한 복구를 위한 백업 및 복원 | Amazon Web Services
이 글은 AWS Architecture Blog에 게시된 Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery by Seth Eliot 을 한국어로 번역 및 편집하였습니다. 이전 1부 게시글에서는 네 가지의 AWS
aws.amazon.com
AWS 기반 재해 복구(DR) 아키텍처, 3부: 파일럿 라이트 및 웜 스탠바이 | Amazon Web Services
이 글은 AWS Architecture Blog에 게시된 Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby by Seth Eliot을 한국어로 번역 및 편집하였습니다. 이 블로그 게시물에서는, 자연 재해, 기술 오류,
aws.amazon.com
RPO 및 RTO
RPO(Recovery Point Objective): 마지막 데이터 복구 가능한 시점 이후에 장애시 데이터 손실을 허용 할수 있는 최대 시간이며 허용 가능한 데이터 손실을 결정한다. 간단하게 데이터 손실 허용 범위라고 볼 수 있을 것 같다.
RTO(Recovery Time Objective): 서비스 중단과 서비스 복원 사이의 최대로 허용 되는 지연시간이며 이에 따라 서비스 다운타임의 허용 가능한 기간이 결정된다. 간단하게 복구 소요 시간이라고 볼 수 있을 것 같다.
재해 복구(Disaster Recovery) 전략
재해(Disaster)의 발생 후 성공적인 복구를 위해서 재해 상황의 인지(Detect), 복구 리전에서 인프라의 복원 및 확장(Restore), 그리고 복구 리전으로 트래픽을 전달하기 위한 장애 조치(Failover)의 과정이 필요하다.
재해 복구(Disaster Recovery) 전략은 시스템이 재해 상황에서도 안정적이고 지속적으로 운영될 수 있도록 준비하는 방안을 말하며 각 전략은 비용, 복구 소요 시간 , 데이터 손실 허용 범위 등의 요소에 따라 적절한 상황에서 사용된다.
백업 및 복구 전략
가장 기본적인 재해 복구 전략으로, 주기적으로 데이터를 백업해두고 재해 발생 시 데이터를 복원하는 방식이다. 데이터 백업은 주로 물리적 디스크, 클라우드 스토리지 등을 활용해 수행된다. 서버나 데이터베이스의 장애, 데이터 손상, 랜섬웨어 공격 등으로 인한 데이터 유실 시 사용되는데 비용이 제한적인 소규모 기업이나 복구 시간(RTO, Recovery Time Objective)에 크게 민감하지 않은 서비스에 적합하다.
파일럿 라이트 전략
최소한의 리소스만 활성화된 상태로 유지하고, 재해 발생 시 빠르게 전체 시스템을 활성화하는 전략이다. 중요한 서비스나 데이터베이스를 미리 설정해 두고, 재해가 발생하면 필요한 나머지 자원을 신속하게 스케일링한다.
웜 스탠바이 전략
주요 시스템의 축소된 버전을 상시 운영하면서, 재해 발생 시 전체 시스템으로 확장하는 방식이다. 파일럿 라이트 전략보다 더 많은 리소스가 활성화되어 있어, 재해 시 빠른 복구가 가능다.
멀티 사이트 액티브/액티브 전략
여러 데이터 센터나 클라우드 리전에 걸쳐 모든 서비스가 항상 활성화된 상태로 운영되는 전략이다. 각 사이트가 동일한 작업을 수행하고, 하나의 사이트에서 장애가 발생해도 다른 사이트가 즉시 서비스를 제공할 수 있다.
실제 운영 사례
딜리버스의 AWS 기반 재해 복구(DR)
딜러버스의 AWS 기반 DR(Disaster Recovery) 전략과 아키텍처, 프로세스에 대한 글입니다. DR 자체에 대한 세부 내용은 글의 참조 자료로 대체합니다.
medium.com
최종 전략 선택
웜 스탠바이 전략(멀티 리전 액티브/패시브) 선택
우리 프로젝트는 주요 서비스의 연속성이 매우 중요하다. 웜 스탠바이 전략을 사용하면 주요 시스템의 축소된 버전을 상시 운영하여 재해 발생 시 신속하게 전체 시스템으로 확장할 수 있다. 이는 빠른 복구와 높은 가용성을 유지하면서도, 파일럿 라이트 전략보다 더 많은 리소스를 미리 준비하여 서비스의 중단 시간을 최소화하는 데 효과적이다. 비용과 리소스가 파일럿 라이트 전략보다는 소모되더라도 중요한 서비스의 연속성을 보장할 수 있다.
웜 스탠바이(멀티 리전 액티브/패시브) 전략 적용
Detect(재해 탐지)
KPI(Key Performance Indicator, 핵심 성과 지표): 워크로드 상태를 이해하기 위해 사용할 수 있는 최상의 지표중의 하나로 워크로드가 의도한 대로 수행되어, 고객 요구 사항을 충족하는지 여부를 나타낸다.
우리 프로젝트에서 워크로드는 올리브영 웹 사이트에서의 주문이므로 속도를 확인하는 것을 KPI로 정의 할 수 있다.
모니터링 시스템 설정: Aurora 클러스터의 모든 리전에서 장애와 성능 저하를 모니터링한다. CloudWatch 또는 기타 모니터링 도구를 사용하여 리전 간 복제본의 상태를 실시간으로 감시한다.
알림 및 경고: 장애가 감지되면 자동으로 경고를 발생시키고, 운영팀에 신속하게 알린다.
Restore(리소스 복구)
멀티 리전 액티브/패시브 전략에 대한 공식 기술 블로그
Deploy multi-Region Amazon Aurora applications with a failover blueprint | Amazon Web Services
Certain organizations require multi-Region redundancy for their workloads to achieve disaster recovery and business continuity. Disaster recovery is an important part of resiliency strategy and concerns how a workload responds when a disaster strikes. The
aws.amazon.com
Scale applications using multi-Region Amazon EKS and Amazon Aurora Global Database: Part 2 | Amazon Web Services
This is the second in a two-part series about scaling applications globally using multi-Region Amazon Elastic Kubernetes Service (Amazon EKS) and Amazon Aurora Global Database. In Part 1, you learned the architecture patterns and foundational pillars of a
aws.amazon.com
Disaster Recovery Solutions with AWS managed services, Part 3: Multi-Site Active/Passive | Amazon Web Services
Welcome to the third post of a multi-part series that addresses disaster recovery (DR) strategies with the use of AWS-managed services to align with customer requirements of performance, cost, and compliance. In part two of this series, we introduced a DR
aws.amazon.com
약한 인스턴스 타입으로의 운영: 재해 발생 후, 기존 리전의 워커 노드보다 약한 인스턴스 타입으로 운영 중인 시스템이 활성화된다. 이 단계에서 시스템의 축소된 버전이 복구 작업을 지원하며, 필요한 리소스가 제공된다.
SQS를 이용한 느슨한 결합: SQS를 통해 시스템 구성 요소 간의 결합도를 낮추어, 재해 복구 시 시스템의 각 부분이 독립적으로 복구 작업을 수행할 수 있도록 한다. 서비스 간의 의존성을 줄이고 복구 작업의 안정성을 높일 수 있다. 이를 통해 비동기적 처리와 리소스의 유연한 할당이 가능해져 재해 상황에서도 시스템 복구가 신속하게 이루어질 수 있다.
미리 운영 중인 ElastiCache: ElastiCache를 미리 운영하여 캐시 데이터의 복구를 빠르게 진행할 수 있도록 한다. ElastiCache는 성능을 개선하고, 재해 복구 시 데이터 접근 속도를 높이는 데 도움이 된다.
읽기 전용 복제본의 승격: 재해 발생 시, 현재 운영 중인 리전에서 읽기 전용 복제본을 주 인스턴스로 승격시킨다. 이를 통해 읽기 전용 복제본을 쓰기 가능한 주 인스턴스로 변경하고, 데이터베이스 서비스를 복구한다.
Fail Over(장애 조치)
트래픽 전환: 읽기 전용 복제본이 승격된 후, 트래픽을 자동으로 새로운 주 인스턴스로 전환한다. 이를 통해 서비스의 중단 없이 정상적인 운영을 지속할 수 있다.
서비스 안정성 확인: Fail Over 이후, 새 주 인스턴스에서 모든 서비스가 정상적으로 작동하는지 확인한다.
성능 모니터링: 새로 승격된 인스턴스의 성능을 지속적으로 모니터링하고, 필요에 따라 리소스를 조정하여 최적의 성능을 유지한니다.
후속 조치: Fail Over 과정에서 발생한 문제를 기록하고, 향후 유사한 상황에서 개선점을 반영한다.
최종 Disaster Recovery Architecture
'클라우드 환경 구축 프로젝트 > AWS' 카테고리의 다른 글
| [AWS] Elasticache를 배치할 Subnet에 대한 명확한 기준 설정 (0) | 2024.11.08 |
|---|---|
| [AWS] Spring Cloud for AWS 기반 Spring Boot 3.3.3에 S3 서비스 연동하기 (1) | 2024.10.16 |