계획 세우기

모든 위기를 극복하는 것은 스트레스를 받는 일이며 재난 상황도 다르지 않습니다. 재해가 발생하면 비즈니스에 중요한 서비스를 신속하게 재시작해야 한다는 압박감에 시달려 실수가 발생할 수 있습니다. 재해가 발생하더라도 명확하게 정의된 계획이 있으면 예측 가능한 방식으로 비즈니스를 복구할 수 있어 스트레스를 완화하고 실수를 줄이는 데 도움이 됩니다. 재해 복구 계획을 만드는 방법에 대한 자세한 내용은 재해 복구 계획을 참조하세요.

우선순위 결정

재해 복구 계획을 만들 때는 조직에서 해당 계획을 승인하고 이해하며 자금을 지원할 수 있는지 확인하세요. 더 많은 이해관계자의 동의를 얻으면 재해 발생 시 비즈니스의 우선순위를 파악할 수 있습니다. 이렇게 하면 계획이 포괄적이면서도 비즈니스 기대치에 비례하는 계획을 세울 수 있습니다. 조직과 함께 계획을 정기적으로 검토하여 우선 순위의 변경 사항을 파악하고 필요에 따라 계획을 업데이트하세요.

구역 간 용량 균형 조정

한 리전 내의 여러 가용 영역에 워크로드를 분산 배치하면 가용성이 향상되지만, 특히 가용 영역 간 균형( IBM Cloud® Virtual Servers for Virtual Private Cloud, VSI)을 사용할 때는 가용 영역 간의 불균형에 주의해야 합니다. 워크로드가 여러 존에 분산되도록 하여, 특정 존에 장애가 발생하더라도 워크로드가 계속 실행될 수 있도록 하십시오. 또한 나머지 구역들이 전체 워크로드를 처리할 수 있는 충분한 용량을 갖추고 있는지 확인하십시오. 3개의 존에 걸쳐 배포할 경우, 존별 장애 발생 시 발생하는 33%의 용량 손실을 상쇄하기 위해 존당 약 17%의 추가 VSI 용량을 설계에 반영해야 합니다.

무엇이 재난에 해당하는지 이해

재해 복구 계획을 수립하려면 현재 겪고 있는 상황이 재해인지 확인해야 합니다. 계획에 재난에 해당하는 사항을 명확하게 표현하지 않으면 재난이 발생했을 때 잘못된 경보가 발생하거나 활동이 이루어지지 않을 위험이 있습니다. 재난을 구성하는 여러 가지 시나리오, 비즈니스가 재난에 대응할 수 있는 방법, 그리고 얼마나 빨리 대응할 수 있는지 정의합니다. 또한 영향의 범위도 고려하세요. 워크로드의 한 구성 요소에 장애가 발생하면 모든 구성 요소가 장애를 겪는 상황과 대응 방식이 다를까요?

커뮤니케이션이 핵심

재난 상황에서는 팀 간의 효과적인 커뮤니케이션이 중요합니다. 계획에 어떤 개인이 재난을 요청할 수 있는지 명확하게 명시하세요. 재해 복구 계획을 실행하는 데 필요한 조직 및 사람들과 소통하는 방법을 정의합니다. 중요한 메시지를 놓치지 않도록 전화나 이메일 등 커뮤니케이션 채널을 명확하게 명시하세요. 기본 채널이 영향을 받을 경우를 대비하여 백업 커뮤니케이션 채널에 대해 생각해 보세요. 또한 계획에는 상황 업데이트를 캡처하기 위해 반드시 진행해야 하는 특정 회의가 규정되어 있을 수도 있습니다.

요금제 테스트

실제 재난에 대응할 때는 계획을 처음으로 테스트하기에 이상적인 시기가 아닙니다. 정기적으로 계획을 테스트하여 계획이 제대로 작동하는지 확인하고 계획을 실행하는 데 걸리는 시간을 파악하세요. 다른 직원이 참여하는 경우 계획을 테스트하면 각자의 역할을 더 잘 이해할 수 있습니다. 테스트 후에는 배운 교훈을 계획에 반영해야 합니다. 재해 복구 계획 테스트에 대한 자세한 내용은 재해 복구 테스트를 참조하세요.

자신의 책임 이해

각 IBM Cloud 서비스에는 백업, 복구 및 재해와 관련된 책임을 포함하여 IBM® 책임, 고객 책임 및 공유 책임을 정의하는 역할 및 책임 매트릭스가 있습니다. 서비스 인스턴스를 성공적으로 복구하기 위한 조치를 결정하고 계획을 세우는 데 도움이 되므로 사용하는 각 서비스에 대한 책임 소유권을 완전히 이해해야 합니다.

데이터 복원력 및 데이터 보존 요구 사항 고려하기

데이터 복원력은 장애나 재해가 발생했을 때 데이터에 액세스하고 유지 관리하거나 신속하게 복구할 수 있는 기능을 말합니다. 이는 고가용성, 재해 복구 및 사이버 복원력의 개념과 관련이 있습니다. 데이터 복원력에 대한 자세한 내용은 IBM 잘 설계된 프레임워크 을 참조하세요.

고려해야 할 또 다른 중요한 측면은 프로덕션 환경뿐 아니라 백업 및 복구에 대한 데이터 상주 및 데이터의 물리적 위치에 대한 제한이나 요구 사항입니다.

워크로드에 HA 및 DR 설계

클라우드 배포 워크로드를 설계할 때는 요구 사항 수집 단계의 일부로 고가용성 및 재해 복구를 고려하세요. 설계 프로세스 초기에 워크로드의 복원력이 어떤 특성이 필요한지 이해하면 아키텍처에 영향을 미치는 결정을 내리고 복구를 더 쉽게 할 수 있습니다. 예를 들어 워크로드의 복구 시간 목표를 이해했다면 사용 가능한 서비스의 기능을 사용하여 해당 목표를 달성하기 위해 워크로드를 배포하는 방법을 결정할 수 있습니다. 마찬가지로 복구 지점 목표를 이해하면 데이터, 백업 방법 또는 복제 방법에 대해 더 나은 결정을 내릴 수 있습니다. 초기 단계에서 이를 설계하면 비즈니스에서 워크로드에 대한 운영 비용을 더 잘 이해할 수 있습니다.

애플리케이션 코드를 개발하여 재해 복구 사이트로 쉽게 전환할 수 있는 방법을 고려하세요. 예를 들어, 대체 리소스에 연결할 때 변경될 수 있는 연결 문자열이나 기타 구성을 하드코딩하지 마세요.

적절한 도구 선택

IBM Cloud 워크로드를 배포하고 실행하는 데 사용할 수 있는 도구 또는 서비스 세트가 있는 도구 상자로 생각하세요. 어떤 도구든 제대로 사용하려면 그 도구가 할 수 있는 일과 할 수 없는 일을 이해하고 올바른 도구를 선택해야 합니다. 도구가 설계되지 않은 작업에 도구를 사용하려고 하면 문제가 발생할 수 있습니다. 복원력 계획을 설계할 때는 워크로드가 사용하는 서비스, 해당 서비스의 기능 및 한계를 최대한 자세히 파악하세요. 서비스 수익이 RTO 또는 RPO 목표를 달성할 수 없다면 그 격차를 줄이는 데 도움이 될 수 있는 다른 서비스나 도구를 고려하세요. 또한 설정한 목표가 현실적인지, 아니면 사소한 이득만을 위해 솔루션에 과도한 복잡성과 비용을 도입하고 있는 것은 아닌지도 고려하세요.

변경하기 전에 백업하기

IT 시스템을 운영하는 것은 결코 위험이 없는 일이 아니며, 워크로드 환경에 변화를 도입하는 것은 위험이 증가하는 시점입니다. 변경 릴리스 계획과 백아웃 계획을 수립하여 환경에 대한 변경 사항을 관리하세요. 변경 사항 릴리스 계획의 첫 번째 단계 중 하나로 데이터 및 구성의 백업을 수행하세요. 릴리스 도중 또는 릴리스 직후에 문제가 발생하면 백업에서 복구할 수 있습니다.

사용자 지정 이미지 만들기

부팅 볼륨에서 사용자 지정 이미지를 생성하고 사전 설치된 애플리케이션 및 구성이 포함된 골든 이미지로 사용하여 DR 사이트의 IBM Cloud® Virtual Servers for Virtual Private Cloud 인스턴스에 대한 프로비저닝 시간을 줄이세요. 사용자 지정 이미지를 생성하려면 부팅 볼륨을 중지된 가상 서버 인스턴스(VSI)에 연결해야 합니다.

서브넷에 호스트 이름 사용

IP 주소 대신 호스트 이름과 DNS를 사용하여 DR 사이트에서 애플리케이션을 재배포하는 데 필요한 변경 사항을 최소화하세요. 특히 VSI를 포함한 VPC 인스턴스의 경우 더욱 그렇습니다. 서브넷은 영역별로 다르며 영역 간에 확장되지 않습니다. 새로운 서비스 인스턴스에는 새로운 IP 주소가 할당되며, 이로 인해 보안 규칙이나 애플리케이션 구성 파일과 같은 기존 구성이 손상될 수 있습니다.

재해 복구를 위한 키 관리 서비스 구성

Key Protect 경우, 지역 서비스 중단이 발생하는 경우 Key Protect 요청의 자동 경로 변경을 사용하도록 DR 지역의 장애 조치와 함께 기본 사이트의 서비스를 구성합니다. 재해 복구 절차의 일부로 Key Protect 서비스, 특히 Internet Protocol (IP) 주소에 액세스할 수 있도록 VPE(가상 사설 엔드포인트) 설정을 업데이트하는 스크립트를 만듭니다.

HPCS의 경우 DR 영역에서 장애 조치 암호화 장치를 구성합니다. 재해가 발생하기 전에 운영 중인 암호화 장치와 동일하게 장애 복구 암호화 장치를 초기화하고 구성하여 지역 정전이 발생하더라도 사용할 수 있도록 합니다

관찰 가능성에 투자하기

관찰성에는 IBM Cloud Logs 및 IBM Cloud Monitoring 과 같은 도구가 포함되어 있으며, 이를 통해 시스템에서 무슨 일이 일어나고 있는지 파악하고, 서비스가 중단되거나 저하되는 경우 근본 원인을 신속하게 식별, 완화 및 해결하는 데 도움이 됩니다. 이는 장애를 피할 수 없고 구성 요소 간의 종속성을 추적하거나 상호 연관성을 파악하기 매우 어려운 복잡한 분산 시스템에 특히 필요합니다. 또한 Activity Tracker 이벤트 라우팅 서비스를 사용하면 이벤트를 감사하고 시스템 변경 사항을 기록 및 모니터링할 수 있습니다 Flow Logs for VPC 는 VPC 내의 네트워크 인터페이스를 오가는 IP 트래픽에 대한 가시성을 제공하며 다른 방법으로는 관찰하기 어려운 네트워킹 및 연결 문제를 해결할 수 있게 해줍니다.

클라우드용으로 구축된 탄력적인 애플리케이션과 이를 지원하는 프로세스는 이러한 기능을 효과적으로 활용해야 합니다. 예를 들어 애플리케이션은 구성 요소와 해당 하위 시스템의 상태에 대한 메트릭을 노출해야 합니다. 모든 IBM Cloud 서비스는 플랫폼 메트릭 수집을 지원하며 로드밸런서에 대해 이와 같이 개별적으로 문서화된 세부 메트릭을 노출합니다. 이를 지원하기 위해 구축된 애플리케이션과 대시보드는 이러한 메트릭을 활용하여 운영 효율성을 개선해야 합니다.

IBM Cloud Logs는 애플리케이션에서 생성된 로그를 보강, 쿼리 및 경고하는 고급 기능을 제공하는 동시에 로그의 양과 비용을 관리합니다. 다양한 알림 유형을 통해 보다 정교한 기능으로 시스템을 효과적으로 모니터링할 수 있습니다.

IBM Cloud 알림으로 최신 정보 받기

IBM Cloud 서비스 또는 지역에 영향을 미치는 재해가 발생하면 계정 또는 이메일로 IBM Cloud 에서 알림을 받게 됩니다. 알림 보기를 검토하여 내 계정의 알림을 신청하세요. IBM Cloud 상태 개요 페이지에서도 확인할 수 있습니다.