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