안정적이고 탄력적인 클라우드 토폴로지 연습 정보
신뢰할 수 있는 애플리케이션:
- 복원력 있고 Failure로부터 정상적으로 Recovery되며, 전체 Recovery 전에 작동 중지 시간과 데이터 손실을 최소화하면서 계속 작동합니다.
- HA(고가용성)를 통해 상당한 다운타임 없이 정상 상태로 설계되었습니다.
- 우수한 DR(재해 복구) 설계를 통해 지역 장애로부터 보호
이러한 요소가 함께 작동하는 방식과 비용에 미치는 영향을 이해하는 것은 신뢰할 수 있는 애플리케이션을 구축하는 데 필수적입니다. 이를 통해 허용되는 작동 중지 시간, 비즈니스에 소요되는 잠재적 비용 및 복구 중에 필요한 기능을 확인할 수 있습니다.
신뢰성을 위한 설계자
클라우드 애플리케이션을 생성할 때 다음을 사용하여 안정성을 구축하십시오.
- 요구 사항을 정의합니다.
클라우드 및 비즈니스 요구사항에 적용할 워크로드를 기반으로 가용성 및 복구 요구사항을 정의합니다.
- 아키텍처 모범 사례를 적용합니다.
검증된 사례를 따르고, 아키텍처에서 가능한 실패 지점을 식별하고, 애플리케이션이 실패에 어떻게 반응할지 결정합니다.
- 시뮬레이션 및 강제 페일오버로 테스트합니다.
결함을 시뮬레이션하고, 강제 복구를 트리거하고, 이러한 장애로부터 감지 및 복구를 테스트합니다.
- 응용 프로그램을 일관되게 배치합니다.
안정적이고 반복 가능한 프로세스를 사용하여 프로덕션으로 릴리스하고 가능한 경우 자동화합니다.
- 응용 프로그램 상태를 모니터합니다.
Failure를 감지하고 잠재적인 Failure 표시기를 모니터하며 응용 프로그램의 상태를 측정합니다.
- Failure 및 Disaster 관리
Failure가 발생하는 시기를 식별하고 설정된 전략을 기반으로 Failure를 해결하는 방법을 결정합니다.
요구 사항 정의
클라우드 및 비즈니스 요구사항에 적용할 워크로드를 기반으로 가용성 및 복구 요구사항을 정의합니다.
비즈니스 요구 사항을 식별할 때 다음을 고려하고 신뢰성 계획을 일치시킵니다.
- 워크로드 및 요구사항 식별
작업 로드는 비즈니스 논리 및 데이터 저장 요구 사항 측면에서 다른 작업 로드와 논리적으로 분리된 고유한 기능 또는 작업입니다. 워크로드마다 가용성, 확장성, 데이터 일관성 및 재해 복구에 대한 요구 사항이 다릅니다.
- 사용량 패턴 결정
응용 프로그램이 사용되는 방식은 요구 사항에서 중요한 역할을 합니다. Critical 기간과 Non-critical 기간 중 요구 사항의 차이점을 식별합니다. 예를 들어 월말 처리를 처리하는 응용 프로그램은 월말에 실패할 수 없지만 다른 시간에 실패를 처리할 수 있습니다. 가동 시간을 보장하기 위해 중요한 기간 동안 추가 구성 요소 또는 중복성을 추가하고 더 이상 값을 추가하지 않을 때 제거할 수 있습니다.
- 주요 구성 요소 및 경로 식별
시스템의 모든 구성 요소가 다른 구성 요소만큼 중요하지는 않을 수 있습니다. 예를 들어, 증분 값을 추가하는 선택적 구성 요소가 있지만 필요한 경우 작업 로드가 실행되지 않을 수 있습니다. 이러한 구성 요소가 어디에 있는지, 그리고 반대로 작업 로드의 중요한 부분이 어디에 있는지 이해합니다. 이를 통해 가용성 및 신뢰성 측정지표의 범위를 지정하고 가장 중요도가 높은 구성요소의 우선순위를 지정하기 위한 복구 전략을 계획할 수 있습니다.
- 외부 종속성 및 다운스트림 Failure의 영향 식별
작업 로드가 외부 서비스에 의존하는 경우 이러한 종속성의 Failure가 작업 로드의 가용성에 부정적인 영향을 줄 수 있습니다. 통합을 분리하여 다운스트림 Failure에 대비하는 방법을 구현합니다.
- 작업 로드 가용성 요구 사항 결정
고가용성(HA)은 일반적으로 가동 시간 대상에 따라 정의됩니다. 예를 들어, 99% HA 대상은 특정 리소스를 1년에 3.65일 동안 사용할 수 없음을 의미합니다. Oracle Cloud Infrastructure(OCI)는 고가용성 환경을 제공하기 위해 설계되었습니다. OCI는 각 서비스에 대한 SLA(서비스 수준 계약)를 게시합니다. 이 계약은 해당 서비스에 대한 가동 시간 및 연결에 대한 Oracle의 약정을 설명하고 요구 사항과 어떻게 일치하는지 검토해야 합니다. OCI의 일부 서비스에는 높은 수준의 HA가 내장되어 있으며, 특히 자율운영 데이터베이스와 같은 Oracle 관리형 서비스가 있습니다. 애플리케이션 아키텍처가 비즈니스 요구사항을 충족하도록 하려면 외부 종속성을 포함하여 각 워크로드에 대한 대상 SLA를 정의합니다. 애플리케이션 종속성과 더불어 가용성 요구 사항을 충족하는 비용 및 복잡성을 고려합니다.
- RTO(복구 시간 목표) 및 RPO(복구 지점 목표)를 통해 복구 측정 단위 설정
RTO는 재해 발생 후 응용 프로그램을 사용할 수 없는 최대 허용 시간입니다.
RPO는 재해 발생 시 허용되는 최대 데이터 손실 기간입니다.
이러한 값을 도출하려면 위험 평가를 수행하고 조직에서 다운타임 또는 데이터 손실의 비용과 위험을 이해해야 합니다.
스토리지에 대한 증분 백업은 복구 지점을 통해 데이터 손실로부터 보안을 제공합니다. 각 백업 사이의 기간은 백업에서 복원한 후 손실되는 최대 데이터 양을 제한합니다.
예를 들어 OCI Block Volumes 스토리지에 대해 Oracle의 사전 정의된 백업 정책(Bronze, Silver, Gold) 중 하나를 사용할 수 있습니다. 각 백업 정책은 월별, 주별 또는 일별과 같이 증분 백업 빈도가 설정된 일정과 정의된 보존 기간으로 구성됩니다.
- 재해 정의
잘 문서화 된 재해 복구 계획 및 요구 사항을 갖는 것이 중요하지만 이러한 사건의 혼란스러운 성질은 혼란을 야기 할 수 있습니다. 비즈니스에 어떤 재해가 발생하는지 파악하고, 재해 발생 시 필요한 주요 역할을 파악하고, 재해 대응을 시작하기 위한 잘 정의된 커뮤니케이션 계획을 수립합니다.
- 비용 고려
FinOps 관점에서 다양한 신뢰성 전략의 비용 영향을 고려하십시오. 따라서 가용성 및 복구 요구 사항에 대한 정보를 선택할 수 있습니다.
아키텍처 모범 사례 적용
구조를 설계할 때는 업무 요구 사항을 충족하는 연습을 구현하고, Failure 지점을 식별하고, Failure 범위를 최소화하는 데 중점을 둡니다.
다음 모범 사례를 고려하십시오.
- Failure가 발생할 수 있는 위치 확인
아키텍처를 분석하여 애플리케이션에서 발생할 수 있는 장애 유형, 각각의 잠재적 영향 및 가능한 복구 전략을 식별합니다.
- HA 및 DR 요구 사항에 따라 필요한 중복성 레벨 결정
각 워크로드에 필요한 리던던시 수준은 비즈니스 요구 사항 및 애플리케이션의 전체 비용에 대한 요인에 따라 달라집니다.
- 확장성을 위한 설계
클라우드 애플리케이션은 사용량 변화에 맞춰 확장할 수 있어야 합니다. 개별 구성요소부터 시작하여 가능하면 로드 변경사항에 자동으로 응답하도록 애플리케이션을 설계합니다. 향후 쉽게 확장할 수 있도록 설계 중에 확장 제한을 염두에 두십시오.
- 로드 밸런싱을 사용하여 요청 분산
로드 밸런싱은 순환에서 비정상 인스턴스를 제거하여 애플리케이션의 요청을 정상 서비스 인스턴스로 분산시킵니다. 상태 정보를 외부화하면 백엔드 스케일링이 일반 사용자에게 투명해집니다. 세션에서 상태가 추적되면 고착성이 필요할 수 있습니다.
- 설계에 대한 가용성 및 복원성 요구사항 구축
복원성은 시스템이 실패로부터 복구하고 계속 작동할 수 있는 기능입니다. 가용성은 시스템이 작동하고 작동하는 시간의 비율입니다. 단일 장애 지점 방지, 서비스 수준 목표별 워크로드 분해 등 고가용성 모범 사례를 구현합니다. 애플리케이션 연속성 및 비동기 트랜잭션과 같은 데이터 계층의 표준 기능을 활용하여 가용성과 복원성을 모두 보장합니다.
- DR 구현
확인된 RTO 및 RPO 요구 사항을 충족하도록 솔루션을 설계합니다. RTO 내에서 DR 솔루션의 모든 구성 요소를 온라인으로 전환할 수 있는지 확인합니다. RPO를 충족할 수 있도록 데이터를 보호합니다. 데이터를 저장, 백업 및 복제하는 방법은 매우 중요합니다.
- 데이터 백업
완전히 복제된 DR 환경에서도 정기적인 백업이 여전히 중요합니다. 데이터를 정기적으로 백업 및 검증하고 단일 사용자 계정이 운영 및 백업 데이터에 모두 액세스할 수 없는지 확인합니다.
- 애플리케이션 데이터에 대한 복제 방법 선택
애플리케이션 데이터는 다양한 데이터 저장소에 저장되며 가용성 요구사항이 다를 수 있습니다. 각 데이터 저장소 유형에 대한 복제 방법 및 위치를 평가하여 HA 요구 사항 및 RPO를 충족하는지 확인합니다.
- 페일오버의 영향을 이해하고 재해 준비에 영향을 줍니다.
워크로드 요구 사항을 충족하기 위해 복제를 위해 다른 리전을 인스턴스화해야 합니까? 페일백 시 데이터 일관성에 대해 걱정해야 합니까?
- 페일오버 및 페일백 프로세스 문서화 및 테스트
새 데이터 저장소로 페일오버하는 지침을 명확히 문서화하고 정기적으로 테스트하여 정확하고 쉽게 따라갈 수 있도록 합니다.
- 데이터 복구 계획이 RTO를 충족하는지 확인
백업 및 복제 전략이 RTO 및 RPO를 충족하는 데이터 복구 시간을 제공하는지 확인합니다. 참조 데이터, 파일 및 데이터베이스를 포함하여 애플리케이션에서 사용하는 모든 유형의 데이터에 대한 계정입니다.
- 데이터 백업
시뮬레이션 및 강제 페일오버로 주기적으로 테스트
안정성을 테스트하려면 간헐적으로만 발생하는 Failure 조건에서 End-to-End 작업 로드가 수행되는 방식을 측정해야 합니다.
- 실제 Failure를 트리거하거나 시뮬레이트하여 일반적인 Failure 시나리오 테스트
결함 주입 테스트를 사용하여 일반적인 시나리오(실패 조합 포함) 및 복구 시간을 테스트합니다.
- 로드 시에만 발생하는 Failure 식별
가능한 한 운용 데이터와 가까운 운용 데이터 또는 합성 데이터를 사용하여 최대 로드를 테스트하여 실제 조건에서 응용 프로그램이 어떻게 작동하는지 확인합니다.
- 재해 복구 드릴 실행
Disaster Recovery 계획을 세우고 주기적으로 테스트하여 제대로 작동하는지 확인합니다.
- 페일오버 및 페일백 테스트 수행
애플리케이션의 종속 서비스가 페일오버되고 올바른 순서로 페일백되는지 확인합니다.
- 시뮬레이션 테스트 실행
실제 시나리오를 테스트하면 해결해야 하는 문제를 강조할 수 있습니다. 시나리오는 제어 가능해야 하며 업무 중단이 없어야 합니다. 시뮬레이션 테스트 계획 관리를 알립니다.
- 테스트 상태 검사
로드 밸런서 및 트래픽 관리자에 대한 건전성 프로브를 구성하여 중요한 시스템 구성요소를 확인합니다. 테스트하여 적절히 응답하는지 확인합니다.
- 테스트 모니터링 시스템
모니터링 시스템이 잠재적인 장애를 식별할 수 있도록 중요한 정보와 정확한 데이터를 안정적으로 보고하고 있는지 확인하십시오.
- 테스트 시나리오에 타사 서비스 포함
타사 서비스 중단으로 인한 가능한 장애 지점을 복구와 함께 테스트합니다.
- 테스트 중 발생한 문제에 대해 알아보기
테스트에서 문제 또는 격차가 드러나는 경우 모니터링을 추가하거나 운영 프로세스를 조정하여 문제를 식별하고 해결해야 합니다.
일관된 애플리케이션 배포
배포에는 OCI(Oracle Cloud Infrastructure) 서비스 및 리소스 프로비저닝, 애플리케이션 코드 배포, 구성 설정 적용이 포함됩니다. 업데이트에는 세 가지 작업 또는 세 가지 작업 중 일부가 포함될 수 있습니다.
- 애플리케이션 배포 프로세스 자동화
가능한 많은 프로세스를 자동화합니다. 가능하면 운영 환경에서 수동 배포를 제거해야 하지만 속도와 유연성을 높이기 위해 낮은 환경에서는 허용될 수 있습니다.
- 자동화를 활용하여 배포 전에 코드를 테스트합니다.
버그, 보안 취약점, 기능, 성능 및 통합에 대한 테스트는 최종 사용자가 발견하는 문제를 최소화하는 데 중요합니다. 테스트 실패는 코드가 프로덕션으로 릴리스되지 않도록 해야 합니다.
- 가용성 극대화를 위한 릴리스 프로세스 설계
릴리스 프로세스에서 배치 중 서비스가 오프라인으로 전환되어야 하는 경우 애플리케이션이 다시 온라인으로 전환될 때까지 사용할 수 없습니다. 플랫폼 스테이징 및 운용 기능을 활용합니다. 가능한 경우 사용자의 하위 세트에 새 배포를 릴리스하여 조기 실패를 모니터링합니다.
- 배치를 위한 롤백 계획이 있어야 합니다.
마지막으로 정상 작동이 확인된 버전으로 돌아가서 배치가 실패할 경우 작동 중지 시간을 최소화하도록 롤백 프로세스를 설계합니다. 배포 실패 시 롤백을 자동화하면 불필요한 다운타임을 방지할 수 있습니다.
- 배포 기록 및 감사
스테이지된 배치 기술을 사용하는 경우 둘 이상의 애플리케이션 버전이 운용 환경에서 실행되고 있습니다. 가능한 많은 버전별 정보를 캡처하는 강력한 로깅 전략을 구현합니다.
- 애플리케이션 릴리스 프로세스 문서화
릴리스 프로세스를 명확하게 정의 및 문서화하고 전체 운영 팀이 사용할 수 있도록 보장합니다.
애플리케이션 상태 모니터
Failure를 감지하고 운영자에게 경고하여 수정할 수 있도록 응용 프로그램에서 모니터 및 Alert에 대한 최적의 사용법(Best Practice)을 구현합니다.
- 서비스 호출 추적 구현
기준 성능 데이터는 사용자에게 영향을 미치기 전에 성능 문제를 사전에 식별하는 데 사용할 수 있는 추세 데이터를 제공하는 데 도움이 될 수 있습니다.
- 상태 검사 구현
응용 프로그램 외부에서 정기적으로 실행하여 응용 프로그램 상태 및 성능 저하를 식별합니다. 이러한 프로브는 정적 페이지 테스트 이상의 것이어야 하며 전체적인 응용 프로그램 상태를 반영해야 합니다.
- 장기 실행 워크플로우 확인
문제를 조기에 처리하면 전체 워크플로우를 롤백하거나 여러 보정 트랜잭션을 실행할 필요가 최소화됩니다.
- 시스템, 애플리케이션 및 감사 로그 유지 관리
중앙 집중식 로깅 서비스를 사용하여 로그를 저장합니다.
- 조기 경고 시스템 설정
일시적 예외 및 원격 호출 대기 시간과 같은 응용 프로그램 상태의 KPI(주요 성과 지표)를 식별하고 각 항목에 대해 적절한 임계값을 설정합니다. 임계값에 도달하면 작업에 Alert를 보냅니다.
- 여러 운영자에게 교육을 실시하여 애플리케이션 모니터링 및 수동 복구 단계 수행
항상 하나 이상의 훈련된 운영자가 활성 상태인지 확인하십시오.
Failure 및 Disaster 관리
Recovery 계획을 생성하고 이 계획이 데이터 복원, 네트워크 중단, 종속 서비스 Failure 및 지역 전체 서비스 중단을 포함하는지 확인합니다. 복구 전략에서 VM, 스토리지, 데이터베이스 및 기타 OCI 서비스를 고려하십시오.
- 장애 관리 계획
인시던트 관리에 대한 명확한 역할과 책임을 정의하여 서비스가 계속 실행되도록 하거나 가능한 한 빨리 복원합니다.
- Disaster Recovery 계획 문서화 및 테스트
응용 프로그램 Failure의 업무 영향을 반영하는 Disaster Recovery Plan을 작성합니다. 복구 프로세스를 최대한 자동화하고 수동 단계를 문서화합니다. 재해 복구 프로세스를 정기적으로 테스트하여 계획을 검증하고 개선합니다.
- DR 조정에 필요한 주요 역할 이해
DR 작업이 잘 조정되고 비즈니스 가치에 따라 응용 프로그램의 우선 순위가 결정되는지 확인합니다.
- 애플리케이션 오류 준비
자동으로 처리되는 오류, 기능이 저하되는 오류, 응용 프로그램을 사용할 수 없게 만드는 오류 등 다양한 Failure를 준비합니다. 응용 프로그램이 사용자에게 일시적인 문제를 알려야 합니다.
- 데이터 손상으로부터 Recovery
데이터 저장소에서 오류가 발생하면 저장소를 다시 사용할 수 있게 될 때, 특히 데이터가 복제된 경우 데이터 불일치를 확인합니다. 백업에서 손상된 데이터를 복원합니다.
- 네트워크 중단에서 복구
캐시된 데이터를 사용하여 응용 프로그램 기능을 줄여 로컬에서 실행할 수 있습니다. 그렇지 않은 경우 응용 프로그램 작동 중지 시간을 고려하거나 다른 영역으로 페일오버하십시오. 연결이 복원될 때까지 데이터를 다른 위치에 저장합니다.
- 종속 서비스 Failure로부터 Recovery
계속 사용할 수 있는 기능과 응용 프로그램이 어떻게 응답해야 하는지 확인합니다.
- 지역 전반의 서비스 중단에서 복구
지역 전반의 서비스 중단은 드물지만, 특히 중요한 애플리케이션의 경우 이를 해결하기 위한 전략이 있어야 합니다. 애플리케이션을 다른 영역에 재배치하거나 트래픽을 재분배할 수 있습니다.
- DR 테스트 학습 및 프로세스 개선
DR 테스트 중 발생한 문제를 캡처하고 이러한 문제를 해결하기 위한 계획은 향후 테스트 또는 페일오버 시 해결되어야 합니다.