keywords: HA: IBM Cloud Monitoring, DR: IBM Cloud Monitoring, IBM Cloud Monitoring 복구 시간 목표, IBM Cloud Monitoring 복구 지점 목표

subcollection: monitoring

IBM Cloud Monitoring에 대한 고가용성 및 재해 복구 이해

고가용성서비스 또는 작업 부하가 장애를 견디고 사전 정의된 서비스 수준에 따라 처리 기능을 계속 제공할 수 있는 능력. 서비스의 경우, 가용성은 서비스 수준 협약에 정의되어 있습니다. 가용성에는 유지보수, 고장, 재해 등 계획된 이벤트와 계획되지 않은 이벤트가 모두 포함됩니다. (HA)은 예기치 않은 장애가 발생하더라도 서비스가 계속 작동하고 액세스할 수 있는 기능입니다. 재해 복구는서비스 중단과 같은 드물지만 심각한 사고와 광범위한 장애로부터 복구할 수 있는 서비스 또는 작업량 능력. 여기에는 전체 지역에 영향을 미치는 물리적 재해, 데이터베이스 손상, 또는 작업 부하에 기여하는 서비스의 손실이 포함됩니다. 그 영향은 고가용성 설계가 처리할 수 있는 능력을 초과합니다. 서비스 인스턴스를 작동 상태로 복구하는 프로세스입니다.

IBM Cloud® Monitoring는 애플리케이션, 플랫폼 리소스 및 인프라를 모니터하기 위한 고가용성이며 다중 테넌트인 지역 서비스입니다.

사용 가능한 지역 및 데이터 센터 위치는 지역별 IBM Cloud Monitoring 문서에서 확인할 수 있습니다. 지역 서비스로서 IBM Cloud Monitoring 은 단계별 요금제를 통해 정의된 서비스 수준 목표(SLO) 를 충족합니다. SLO는 보증이 아니며, 목표를 달성하지 못한 경우에는 크레딧을 발행하지 않습니다.

고가용성 아키텍처

가용성 구역

가용성 구역은 데이터가 처리되고 호스팅되는 IBM Cloud 지역 내에서 논리적이며 물리적으로 격리되는 위치입니다.

가용성 구역에는 구역 간 단일 실패 지점을 피함으로써 결함 허용을 강화하도록 다른 구역에서 격리되는 독립적인 전기, 냉각 및 네트워크 인프라가 있습니다.
가용성 구역은 지역에서 높은 대역폭 및 짧은 구역 내 대기 시간을 제공합니다.

지역(위치)은 다른 지역에서 격리되는 독립적인 전기 및 네트워크 인프라가 있는 지리적이며 물리적으로 별도인 하나 이상의 가용성 구역 그룹입니다.

지역은 다른 지역과 공유된 단일 실패 지점을 제거하고 지역에서 짧은 구역 내 대기 시간을 보장하도록 설계되었습니다.
각 지역에는 중복성을 위해 서로 다른 세 개의 데이터 센터(DC)가 있습니다.

다음 표는 지역(위치)에 대한 고가용성(HA) 상태가 나열되어 있습니다. 여기서, IBM Cloud Monitoring 서비스는 사용 가능합니다.

서비스를 이용할 수 있는 위치 목록
지리적 위치	지역	HA 상태
`Asia Pacific`	시드니(`au-syd`)	`MZR`
`Asia Pacific`	도쿄(`jp-tok`)	`MZR`
`Asia Pacific`	오사카(`jp-osa`)	`MZR`
`Europe`	프랑크푸르트(`eu-de`)	`MZR`
`Europe`	런던(`eu-gb`)	`MZR`
`Europe`	마드리드 (`eu-es`)	`MZR`
`North America`	댈러스(`us-south`)	`MZR`
`North America`	워싱턴(`us-east`)	`MZR`
`North America`	몬트리올 (`ca-mon`)	`MZR`
`North America`	토론토(`ca-tor`)	`MZR`
`South America`	상 파울로 (`br-sao`)	`MZR`

여기서,

지리학은 하나 이상의 지역을 포함하는 지역 또는 지리적 영역입니다.
지역은 정의된 지리적 영역입니다.

지역은 특정 우편번호 영역, 구/군/시, 시/도, 시/도 그룹 또는 국가 그룹이 될 수 있습니다.

지역에는 해당 지역의 로컬 액세스, 짧은 지연 시간 및 보안 요구 사항을 충족하기 위한 여러 가용성 영역이 포함되어 있습니다.
N/A는 기능이 해당 지역에는 해당되지 않음을 의미합니다.
MZR은 다중 구역 지역을 의미합니다. 자세히 보기

Monitoring 인스턴스의 가용성

Monitoring 인스턴스를 프로비저닝할 때 인스턴스가 생성되는 MZR(위치)을 선택합니다. 지역은 모니터링 데이터가 처리되고 데이터가 호스팅되는 위치를 결정합니다.

다중 구역 지역(MZR)은 단일 실패 이벤트가 단일 구역에만 영향을 주도록 서로 독립적인 세 개 이상의 가용성 구역으로 구성됩니다.

기본적으로, 각 모니터링 인스턴스는 세 개의 구역 즉, 한 개의 기본 구역과 두 개의 보조 구역으로 구성됩니다.

각 구역은 지역 내 다른 데이터 센터에 위치합니다.
기본 구역의 데이터는 대기 시간이 짧은 보조 구역에 자동으로 복제됩니다. 복제가 가능하도록 하기 위해 아무 조치도 수행할 필요가 없습니다.
기본 구역이 실패하면 서비스 인스턴스가 영향을 받지 않도록 보조 구역이 기본으로 선택됩니다.
두 영역에서 동시에 장애가 발생하면 서비스를 사용할 수 없습니다.

MZR 아키텍처는 2개의 영역 간에 자동 장애 조치와 리전 내의 Monitoring 인스턴스에 대한 고가용성을 제공합니다.

고가용성 기능

IBM Cloud Monitoring 는 다음과 같은 고가용성 기능을 지원합니다:

다음용 HA 기능 IBM Cloud Monitoring
기능	설명
다중 영역 지역 배포	IBM Cloud Monitoring 는 다중 영역 영역(MZR)에 배포되며, MZR 내에서 데이터 플레인은 세 영역 모두에 걸쳐 있으므로 한 영역이 손실되더라도 서비스 가용성에 영향을 미치지 않습니다.
영역 간 플랫폼 메트릭 복제	IBM Cloud Monitoring 에 수집된 메트릭은 MZR 내의 세 영역에 걸쳐 복제됩니다.
라이브/준비 상태 모니터링	모든 마이크로서비스는 Kubernetes 활성도 및 준비 상태 프로브를 통해 모니터링됩니다.

재해 복구 아키텍처

단일 영역 장애: IBM Cloud Monitoring 는 HA이며 단일 영역 또는 시스템 장애 시에도 계속 작동할 수 있습니다.

지역 장애: IBM Cloud Monitoring 는 플랫폼 서비스입니다. 자동 지역 간 장애 조치 또는 지역 간 재해 복구는 없습니다. 지역의 모든 가용 영역에 장애가 발생하면 해당 지역에서 IBM Cloud Monitoring 을 사용할 수 없게 됩니다.

데이터베이스 백업 및 복원: IBM Cloud Monitoring 데이터베이스는 주기적으로 백업되며 재해 복구 시나리오에서는 특정 시점 복구를 생성하여 데이터를 복원할 수 있습니다.

재해 복구 기능

IBM Cloud Monitoring 는 다음과 같은 재해 복구 기능을 지원합니다:

다음을 위한 DR 기능 IBM Cloud Monitoring
기능	설명	고려사항
구성 가능한 여러 대상	고객이 사용 가능한 지역에 연결할 수 있는 세부 정보를 확인할 수 있습니다	구성은 고객이 직접 구현해야 합니다.

DR 계획 수립

DR 단계는 정기적으로 실행해야 합니다. 계획을 수립할 때 다음과 같은 실패 시나리오와 해결 방법을 고려하세요.

다음 대상에 대한 DR 시나리오 IBM Cloud Monitoring
실패	분석
하드웨어 장애(단일 지점)	IBM 는 영역 내 단일 하드웨어 장애 지점으로부터 복원력을 갖춘 데이터베이스를 제공하며, 별도의 구성이 필요하지 않습니다.
구역 장애	구성이 필요하지 않습니다
데이터 손상	IBM 는 데이터베이스를 자주 백업하고 데이터 손상 시 IBM Cloud Monitoring 서비스는 지역 데이터베이스의 특정 시점 백업을 사용하여 복원을 시도합니다.
지역별 실패	HA 및 DR에 대한 귀하의 책임 아래의 단계를 따르세요.

HA 및 DR에 대한 책임

재해 복구는 단일 위치에서 치명적인 실패 또는 가용성 손상을 극복하는 것입니다.

IBM Cloud Monitoring 재난 이벤트 계획 및 복구에 대한 IBM Cloud 요구 사항을 따릅니다.

지역 재해가 발생하면 다음 정보를 고려하십시오.

다른 위치에서 지역 사이트를 다시 빌드하고 서비스를 복원하기 위한 예상 복구 시간은 24시간입니다.
새 위치의 수집 엔드포인트를 가리키도록 애플리케이션 및 모니터링 에이전트의 엔드포인트를 업데이트해야 합니다.
백업으로부터 서비스 인스턴스의 메타데이터 즉, 대시보드 및 경보 정의를 복원해야 합니다.

히스토리 데이터는 재해 중에 유실될 수 있습니다. 감사 목적으로 히스토리 메트릭이 필요한 경우 서비스에서 메트릭을 조회하고 원격 백업 사이트에서 메트릭을 저장하여 정기적으로 메트릭을 백업하십시오. 자세한 정보는 API를 사용하여 Monitoring 인스턴스에서 메트릭 추출 을 참조하십시오.

서비스 수동 복구

지역 재해가 발생하면 서비스의 복구 시간은 지역의 복구 시간에 따라 달라집니다. 서비스의 작동 중단 시간과 비즈니스에 미치는 영향을 최소화하기 위해 지역이 복원되는 동안 다른 지역으로 전환하도록 수동 장애 복구를 구현할 수 있습니다. 새 위치에서 가동되고 실행되는 시간을 줄이려면 서비스에 대한 작업 권한을 관리하고 각 인스턴스의 모니터링 메타데이터를 백업하도록 액세스 그룹 사용을 고려해보십시오. 정기적으로 경보, 알림 대시보드 및 팀 정의를 백업해야 합니다.

DR 사이트가 다시 빌드되는 동안 작업을 계속하려면 어떻게 해야 합니까?

모니터링 인스턴스를 통해 모니터하는 애플리케이션 및 서비스가 동일한 지역에 모두 위치하는 경우 지역이 비즈니스를 위해 다시 사용 가능하게 될 때까지 기다려야 합니다.

시스템에 모니터링 에이전트를 배치하고 해당 시스템이 지역 실패의 영향을 받지 않는 경우 메트릭을 다른 지역에 있는 모니터링의 다른 인스턴스로 경로를 재지정하도록 선택할 수 있습니다. 메트릭 데이터를 경로 재지정하려면 다음 단계를 완료하십시오.

모니터링 인스턴스 프로비저닝
각 시스템의 모니터링 에이전트를 다시 구성하십시오. 에이전트 구성에서 액세스 키와 수집 엔드포인트를 변경하십시오.
새 모니터링 인스턴스에 대해 작업하도록 IAM 권한을 정의하십시오.

액세스 그룹을 사용하여 모니터링 인스턴스에 대한 작업 권한을 관리하면 새 인스턴스로 작업할 올바른 정책과 사용자를 설정하기 위해 수행해야 할 작업의 양이 줄어듭니다. 액세스 그룹에 대한 정보는 지역이 아닌 글로벌을 기준으로 합니다.
모니터링 인스턴스를 실행하고 경보, 알림, 팀 및 대시보드를 가져와서 애플리케이션 및 시스템을 모니터하십시오.

IBM Cloud Monitoring 사용에 대한 회원님과 IBM Cloud 간의 책임 소유권에 대해 자세히 알아보려면 IBM Cloud Monitoring 사용 시 회원님의 책임 이해하기를 참조하세요.

복구 시간 목표(RTO) 및 복구 지점 목표(RPO)

다음 표는 DR 상황 발생 시 예상되는 복구 시간을 나타냅니다.

DR의 복구 목표
DR에 대한 복구 목표	예상 시간
최대 허용 가능한 작동 중단 시간(MTD)/복구 시간 목표(RTO)	최대 24시간
RPO(Recovery Point Objective)	최대 24시간

변경 관리

변경 관리에는 업그레이드, 구성 변경 및 삭제와 같은 작업이 포함됩니다.

사용자와 프로세스에 업무에 필요한 최소한의 권한으로 IAM 역할 및 작업을 부여하는 것이 좋습니다. 실수로 서비스가 삭제되는 것을 방지하려면 어떻게 해야 하나요?

정기적으로 경보, 알림 대시보드 및 팀 정의를 백업해야 합니다. IBM Cloud Monitoring 의 새 버전으로 업그레이드하기 전에 수동 백업을 만드는 것이 좋습니다.

IBM® 재해 복구 계획을 지원하는 방법

IBM® 재해 발생 시 구체적인 복구 조치를 취합니다.

IBM 는 매년 다양한 재해 시나리오에 대한 테스트를 수행하고 이러한 테스트에서 발견한 결과를 바탕으로 복구 문서를 지속적으로 개선하고 있습니다.
재해 발생 시 지원을 위해 대기 중인 IBM® 주제별 전문가를 통해 연중무휴 24시간 글로벌 지원을 받을 수 있습니다.
모든 IBM 주제별 전문가는 매년 비즈니스 연속성 및 재해 복구 정책과 절차에 대한 교육을 받아 재해 발생 시 대비할 수 있도록 합니다.
다중 영역 영역(MZR)은 단일 장애 메트릭이 단일 영역에만 영향을 미치도록 서로 독립적인 3개 이상의 가용 영역으로 구성됩니다.

기본적으로 IBM Cloud Monitoring 은 3개의 영역에 배포됩니다. 각 영역은 활성/활성/활성 상태로 설정됩니다:

각 구역은 지역 내 다른 데이터 센터에 위치합니다.
각 영역의 플랫폼 지표는 지연 시간이 짧은 다른 영역으로 자동으로 복제됩니다. 복제가 가능하도록 하기 위해 아무 조치도 수행할 필요가 없습니다.
이 서비스는 중단 없이 단일 구역 실패를 견디도록 디자인되었습니다.
MZR 아키텍처는 리전 내 영역 간 자동 장애 조치와 리전 내 인스턴스에 대한 고가용성을 제공합니다.
IBM Cloud Monitoring 데이터는 주기적으로 백업되며 재해 발생 시 특정 시점 복구를 사용하여 복원할 수 있습니다.

IBM 영역 장애에서 복구하는 방법

영역 장애가 발생한 경우 IBM Cloud 에서 영역 장애를 해결합니다. 서비스는 한 지역의 세 구역 모두에 걸쳐 제공되므로 MZR 내의 서비스 가용성에는 영향을 미치지 않습니다. 영역이 복구되면 이벤트 및 API 요청이 복구된 영역으로 전송이 재개됩니다. 현재로서는 고객의 조치가 필요하지 않습니다.

IBM 지역 장애에서 복구하는 방법

장애 후 리전이 복원되면 IBM 은 데이터 손실 없이 동일한 연결 문자열을 사용하여 리전 상태에서 서비스 인스턴스를 복원하려고 시도합니다.

지역 상태가 손상된 경우 서비스가 마지막 내부 백업 상태로 복원됩니다. 서비스와 관련된 모든 데이터는 서비스에서 매일 한 번씩 백업합니다. 24시간 분량의 데이터가 손실될 가능성이 있습니다. 동일한 연결 문자열을 사용하여 백업에서 서비스를 복구하는 경우. 대시보드, 알림 및 알림을 포함한 고객 데이터의 경우 고객은 데이터를 복원할 책임이 있습니다.

IBM 에서 서비스 인스턴스를 복원할 수 없는 경우 고객은 서비스 수동 복구에 설명된 대로 복원하거나 리디렉션해야 합니다.

IBM 서비스 유지 관리 방법

모든 업그레이드는 IBM 서비스 모범 사례를 따르며 복구 계획과 롤백 프로세스가 마련되어 있습니다. 새로운 기능 및 유지보수를 위한 정기적인 업그레이드는 정상적인 운영의 일부로 이루어집니다. 이러한 유지 관리로 인해 클라이언트 가용성 재시도 로직에 의해 처리되는 짧은 중단 간격이 발생할 수 있습니다. 변경 사항은 지역별로, 그리고 한 지역 내에서 구역별로 순차적으로 적용됩니다. 결함이 처음 발견되면 업데이트가 백업됩니다.

복잡한 변경 사항은 기능 플래그를 통해 활성화 및 비활성화하여 노출을 제어합니다.
고객 워크로드에 영향을 미치는 변경 사항은 알림에 자세히 설명되어 있습니다. 자세한 내용은 이 서비스에 영향을 미치는 계획된 유지보수, 공지사항 및 릴리즈 노트에 대한 모니터링 알림 및 상태를 참조하세요.