copyright: years: 2017, 2026 lastupdated: "2026-05-11"
keywords: App ID HA, App ID DR, App ID 고가용성, App ID 재해 복구, App ID 장애 복구
subcollection: appid
App ID의 고가용성과 재해 복구 이해
고가용성서비스 또는 작업 부하가 장애를 견디고 사전 정의된 서비스 수준에 따라 처리 기능을 계속 제공할 수 있는 능력. 서비스의 경우, 가용성은 서비스 수준 협약에 정의되어 있습니다. 가용성에는 유지보수, 고장, 재해 등 계획된 이벤트와 계획되지 않은 이벤트가 모두 포함됩니다. (HA)은 예기치 않은 장애가 발생하더라도 서비스가 계속 작동하고 액세스할 수 있는 기능입니다. 재해 복구는서비스 중단과 같은 드물지만 심각한 사고와 광범위한 장애로부터 복구할 수 있는 서비스 또는 작업량 능력. 여기에는 전체 지역에 영향을 미치는 물리적 재해, 데이터베이스 손상, 또는 작업 부하에 기여하는 서비스의 손실이 포함됩니다. 이 영향은 고가용성 설계가 처리할 수 있는 능력을 초과합니다. 서비스 인스턴스를 작동 상태로 복구하는 프로세스입니다.
IBM Cloud® App ID 는 표준 요금제로 정의된 서비스 수준 목표(SLO)를 충족하는 지역 서비스입니다. 사용 가능한 IBM Cloud 지역 및 데이터 센터에 대한 자세한 내용은 App ID, 위치별 서비스 및 인프라 가용성을 참조하세요.
고가용성 아키텍처
App ID 서비스 인스턴스는 단일 장애 지점 없이 다중 영역 지역의 여러 영역에 걸쳐 프로비저닝됩니다. 인스턴스 노드 또는 가용성 영역에 장애가 발생하는 경우, 글로벌 로드 밸런서를 통해 살아남은 고가용성 인스턴스 노드로 API 요청이 라우팅되어 서비스가 계속 실행됩니다. 중단과 글로벌 로드 밸런서가 장애를 인식하는 데 짧은 시간(초)이 걸릴 수 있으며, 이 시간 동안 장애가 발생한 인스턴스로 요청이 전송될 수 있습니다. 프로그래밍 방식으로 서비스 인스턴스에 액세스하는 워크로드는 가용성을 유지하기 위해 클라이언트 가용성 재시도 로직을 따라야 합니다. 영역 장애가 발생하는 동안 눈에 띄는 서비스 성능 저하는 없습니다.
재해 복구 아키텍처
서비스 인스턴스 중단으로부터 복구하려면 복구 리전에서 복구 서비스 인스턴스를 크래팅해야 합니다. 일반적으로 복구 서비스 인스턴스는 소스 서비스 인스턴스와 동일한 데이터로 구성해야 합니다. 잠재적인 재해가 발생하기 전에 복구 지역에 백업 인스턴스를 생성하고 정기적으로 유지 관리하여 소스 인스턴스와 동기화되도록 해야 합니다.
재해 복구 기능
복구 지역으로의 복구를 계획합니다. 복구 인스턴스는 IBM Cloud 내의 워크로드 재해 복구 접근 방식과 일치해야 합니다. 복구 인스턴스는 비밀번호 정책, 사용자 및 SAML 구성을 포함한 데이터에 대한 기본 서비스 인스턴스의 데이터 변경 사항을 추적해야 합니다.
인스턴스 백업 및 복원
지역 간 가용성을 보장하기 위해 App ID 인스턴스를 백업하고 복원하려면 몇 가지 기본 단계가 필요합니다. 다음을 수행해야 합니다.
-
App ID 인스턴스의 백업 스토리지를 구성하기 위한 정책을 정의하십시오. 이 구성에는 사용자 프로파일 및 Cloud Directory 사용자와 같은 데이터가 인스턴스의 백업에 저장되는 방법에 대한 계획이 포함됩니다.
기본 위치에서 가동 중단 인시던트가 발생하기 전에 백업 시스템을 작성하십시오. 권장된 대로 지속적인 보호를 유지하려면 프로세스를 자동화하여 백업을 생성하고 주기적으로 실행하십시오.
-
다른 지역에서 App ID 인스턴스를 만들고 구성합니다.
-
백업을 저장하고 이를 보조 위치에 있는 App ID 인스턴스에 복원하는 프로세스를 설정하십시오.
API를 사용하여 인스턴스 백업
관리 API를 사용하여 App ID 인스턴스를 백업하려면 App ID API에 요청을 보내 App ID 인스턴스에 대한 설정 정보가 포함된 파일을 생성하는 스크립트를 작성하세요. 이러한 파일은 보조 리젼에서 App ID 인스턴스를 복원하는 데 필요하므로 안전한 위치에 저장하십시오.
App ID 인스턴스의 설정 (예: 유스 케이스에 필요한 사항) 을 기반으로 백업 설정을 정의하십시오. 예를 들어, 다음 시나리오에서는 다음 설정으로 App ID 인스턴스를 구성합니다.
- 암호 정책 (예: 사용자가 세 번 연속으로 잘못된 암호를 입력하는 경우 60분 동안 사용자 프로파일 잠금)
- SAML 구성
관리 API를 사용하여 이러한 사용자 설정을 검색하려면 다음을 전송하십시오.
- 엔드포인트에 GET 요청을 보내면
/management/v4/<tenantId>/config/cloud_directory/advanced_password_management엔드포인트에 요청하여 고급 비밀번호 관리의 구성을 가져옵니다.
curl -X 'GET' \
'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/cloud_directory/advanced_password_management' \
--header 'accept: application/json' \
--header 'Authorization: Bearer <IAM_Token>'
- 엔드포인트에 GET 요청을 보내면
/management/v4/<tenantId>/config/idps/saml엔드포인트에 요청하여 상태 및 자격 증명을 포함하는 SAML ID 공급자 구성을 가져옵니다.
curl -X 'GET' \
'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/idps/saml' \
--header 'accept: application/json' \
--header 'Authorization: Bearer <IAM_Token>'
App ID 인스턴스의 구성 설정 백업을 보존하는 것 외에도 Cloud Directory 사용자 및 사용자 프로파일의 백업을 생성해야 합니다. 이 태스크를 수행하려면 관리 API를 사용하는 것이 좋습니다.
- Cloud Directory 사용자를 내보내려면 cloud_directory/export/all API 엔드포인트를 사용하십시오. 내보내기를 다운로드하려면 cloud_directory/export/download API를 사용하십시오. 관리 API를 사용하여 Cloud Directory 사용자를 내보내는 방법에 대한 자세한 정보는 모든 사용자 내보내기 문서를 참조하십시오.
- 사용자 프로파일을 내보내려면 users/export 엔드포인트를 사용하십시오.
- 이러한 두 개의 내보내기 API는 두 개의 백업 파일을 생성합니다. 이 백업 파일은 나중에 복원 프로세스에서 사용하기 위해 안전하게 저장해야 합니다.
Terraform및 API를 사용하여 인스턴스 백업
Terraform을 사용하여 App ID 설정을 백업하기 위해 Terraform 스크립트를 작성하여 App ID 인스턴스에 대한 설정 정보를 포함하는 파일을 생성할 수 있습니다. 이러한 파일을 사용하여 보조 리젼에서 App ID 인스턴스를 복원해야 하므로 안전한 위치에 저장하십시오.
App ID 인스턴스의 설정 (예: 유스 케이스에 필요한 사항) 을 기반으로 백업 설정을 정의하십시오. 예를 들어, 다음 시나리오에서는 다음 설정으로 App ID 인스턴스를 구성합니다.
- 암호 정책 (예: 사용자가 세 번 연속으로 잘못된 암호를 입력하는 경우 60분 동안 사용자 프로파일 잠금)
- SAML 구성
다음 테라폼 스크립트를 사용하여 현재 구성을 검색하고 이를 파일에 저장할 수 있습니다.
terraform {
required_providers {
ibm = {
source = "IBM-Cloud/ibm"
version = ">= 1.12.0"
}
}
}
variable "tenant_id" {
type = string
default = "<<YOUR TENANT ID>>"
}
variable "region" {
type = string
default = "<<THE REGION YOUR TENANT IS LOCATED>>"
}
provider "ibm" {
region = var.region
ibmcloud_api_key = "<<API KEY TO ACCESS APP ID INSTANCE>>"
}
##### ---------- Getting the configuration from your App ID instance ---------- #####
# Get Settigs about Password's rules
data "ibm_appid_apm" "app" {
tenant_id = var.tenant_id
}
# Get SAML config
data "ibm_appid_idp_saml" "saml" {
tenant_id = var.tenant_id
}
##### ---------- Saving the App ID configuration to files ---------- #####
resource "local_file" "app_config" {
content = jsonencode(data.ibm_appid_apm.app)
filename = "${path.module}/backup_configurations/app_config.json"
}
resource "local_file" "saml_config" {
content = jsonencode(data.ibm_appid_idp_saml.saml)
filename = "${path.module}/backup_configurations/saml_config.json"
}
이전 시나리오에서 백업을 포함하는 파일은 로컬로 저장됩니다. 그러나 다음과 같이 원하는 다른 저장 위치에 저장할 수 있습니다 IBM Cloud Object Storage.
Cloud Directory 사용자 및 사용자 프로파일의 백업을 생성하려면 관리 API를 사용하는 것이 좋습니다.
- Cloud Directory 사용자를 내보내려면 cloud_directory/export/all API 엔드포인트를 사용하십시오. 내보내기를 다운로드하려면 cloud_directory/export/download API를 사용하십시오. 관리 API를 사용하여 Cloud Directory 사용자를 내보내는 방법에 대한 자세한 정보는 모든 사용자 내보내기 를 참조하십시오.
- 사용자 프로파일을 내보내려면 users/export 엔드포인트를 사용하십시오.
- 이러한 두 개의 내보내기 API는 두 개의 백업 파일을 생성하며, 이 파일은 나중에 복원 프로세스에서 사용하기 위해 저장해야 합니다.
API를 사용하여 App ID 인스턴스 복원
먼저 보조 리젼에서 App ID 의 새 인스턴스를 수동으로 프로비저닝해야 합니다. 그런 다음 백업 파일을 읽고 관리 API 요청을 사용하여 보조 리젼에서 App ID 인스턴스를 설정하여 App ID 설정을 복원할 수 있습니다.
백업 섹션에 포함된 시나리오를 계속 진행하면서 다음을 관리 API로 전송하여 SAML 구성 및 비밀번호 정책을 복원할 수 있습니다:
- 엔드포인트에 PUT 요청을 보내
/management/v4/<tenantId>/config/cloud_directory/advanced_password_management엔드포인트에 PUT 요청을 보내 고급 비밀번호 관리 구성을 업데이트합니다. 백업에 저장된 데이터를 HTTP 요청 본문으로 전달합니다.
curl -X 'PUT' \
'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/cloud_directory/advanced_password_management' \
--header 'accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <IAM_Token>' \
-d '<Data_from_your_backup_file>'
- 엔드포인트에 PUT 요청을 보내
/management/v4/<tenantId>/config/idps/saml엔드포인트에 PUT 요청을 보내 SAML IdP 구성을 업데이트합니다. 백업에 저장된 데이터를 HTTP 요청 본문으로 전달합니다.
curl -X 'PUT' \
'https://<region>.appid.cloud.ibm.com/management/v4/<tenantId>/config/idps/saml' \
--header 'accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <IAM_Token>' \
-d '<Data_from_your_backup_file>'
사용 가능한 경우 Cloud Directory 사용자 및 해당 프로파일의 백업을 복원하려면 관리 API를 사용하는 것이 좋습니다.
- Cloud Directory 사용자를 가져오려면 cloud_directory/import/all API 엔드포인트를 사용하십시오. 관리 API를 사용하여 Cloud Directory 사용자를 가져오는 방법에 대한 자세한 정보는 모든 사용자 가져오기 문서를 참조하십시오.
- 사용자 프로파일을 가져오려면 users/import 엔드포인트를 사용하십시오.
Terraform및 API를 사용하여 App ID 인스턴스 복원
Terraform및 관리 API의 조합을 사용하여 App ID 인스턴스를 복원하는 경우 첫 번째 단계는 보조 리젼에서 App ID 의 새 인스턴스를 프로비저닝하기 위해 Terraform 스크립트를 작성하는 것입니다. 그런 다음 백업 파일을 읽고 terraform 명령을 사용하여 보조 리젼에서 App ID 인스턴스를 설정하여 App ID 설정을 복원할 수 있습니다.
백업 섹션에 포함된 시나리오를 계속 진행하면서 다음 스크립트를 사용하여 SAML 구성 및 비밀번호 정책을 복원할 수 있습니다:
terraform {
required_providers {
ibm = {
source = "IBM-Cloud/ibm"
version = ">= 1.12.0"
}
}
}
variable "backup_region" {
type = string
default = "<<REGION WHERE TO CREATE THE NEW APPID INSTANCE>>"
}
variable "backup_appid_instance_name" {
type = string
default = "<<THE NAME OF THE NEW APPID INSTANCE>>"
}
provider "ibm" {
region = var.backup_region
ibmcloud_api_key = "<<API KEY TO ACCESS APP ID INSTANCE>>"
}
##### ---------- Creating an AppID instance in a secondary location ---------- #####
data "ibm_resource_group" "group" {
name = "Default"
}
resource "ibm_resource_instance" "backup_appid_instance" {
name = var.backup_appid_instance_name
service = "appid"
plan = "graduated-tier"
location = var.backup_region
resource_group_id = data.ibm_resource_group.group.id
tags = ["backup_instance", "backup_of_appid_from_primary_region"]
}
##### ---------- Getting the configuration from the local backups ---------- #####
locals {
app_config = jsondecode(file("${path.module}/backup_configurations/app_config.json"))
saml_config = jsondecode(file("${path.module}/backup_configurations/saml_config.json"))
}
##### ---------- Restoring the App ID configuration into the new App ID instance ---------- #####
# Setting SAML config in the new App ID Instance
resource "ibm_appid_idp_saml" "saml" {
tenant_id = resource.ibm_resource_instance.backup_appid_instance.guid
is_active = local.saml_config.is_active
config {
entity_id = local.saml_config.config[0].entity_id
sign_in_url = local.saml_config.config[0].sign_in_url
display_name = local.saml_config.config[0].display_name
encrypt_response = local.saml_config.config[0].encrypt_response
sign_request = local.saml_config.config[0].sign_request
certificates = [local.saml_config.config[0].certificates[0]]
}
}
# Setting password policies config in the new App ID Instance
resource "ibm_appid_apm" "apm" {
tenant_id = resource.ibm_resource_instance.backup_appid_instance.guid
enabled = local.app_config.enabled
prevent_password_with_username = local.app_config.prevent_password_with_username
password_reuse {
enabled = local.app_config.password_reuse[0].enabled
max_password_reuse = local.app_config.password_reuse[0].max_password_reuse
}
password_expiration {
enabled = local.app_config.password_expiration[0].enabled
days_to_expire = local.app_config.password_expiration[0].days_to_expire
}
lockout_policy {
enabled = local.app_config.lockout_policy[0].enabled
lockout_time_sec = local.app_config.lockout_policy[0].lockout_time_sec
num_of_attempts = local.app_config.lockout_policy[0].num_of_attempts
}
min_password_change_interval {
enabled = local.app_config.min_password_change_interval[0].enabled
min_hours_to_change_password = local.app_config.min_password_change_interval[0].min_hours_to_change_password
}
}
Cloud Directory 사용자 및 사용자 프로파일을 복원하려면 관리 API를 사용하는 것이 좋습니다.
- Cloud Directory 사용자를 가져오려면 cloud_directory/import/all API 엔드포인트를 사용하십시오. 관리 API를 사용하여 Cloud Directory 사용자를 가져오는 방법에 대한 자세한 정보는 모든 사용자 가져오기 를 참조하십시오.
- 사용자 프로파일을 가져오려면 users/import 엔드포인트를 사용하십시오.
HA 및 DR에 대한 책임
다음 정보는 HA 및 DR 계획을 수립하고 지속적으로 실천하는 데 도움이 될 수 있습니다. 재해 복구 단계는 정기적으로 연습해야 합니다. 계획을 수립할 때 다음과 같은 실패 시나리오와 해결 방법을 고려하세요.
BYOK 손실로부터 고객 복구
IBM® Key Protect for IBM Cloud® 또는 Hyper Protect Crypto Services 에서 루트 키를 사용하여 서비스 인스턴스를 프로비저닝했는데 실수로 루트 키를 삭제한 경우 해당 서비스에 대한 지원 케이스를 열고 다음 정보를 포함하세요:
- 서비스 인스턴스의 CRN
- 백업 Key Protect 또는 HPCS 인스턴스의 CRN
- 새로운 Key Protect 또는 HPCS 루트 키 ID
- 원본 Key Protect 또는 HPCS 인스턴스의 CRN 및 키 ID(사용 가능한 경우)
인증에 대한 실수로 키 분실 시 복구하기 문서를 참조하세요 Key Protect 및 HPCS 문서를 참조하세요.
변경 관리
변경 관리에는 업그레이드, 구성 변경 및 삭제와 같은 작업이 포함됩니다.
사용자와 프로세스에 업무에 필요한 최소한의 권한으로 IAM 역할 및 작업을 부여하는 것이 좋습니다. 예를 들어 프로덕션 리소스를 삭제할 수 있는 기능을 제한합니다.
IBM® 재해 복구에 도움이 되는 방법
IBM® 재해 발생 시 구체적인 복구 조치를 취합니다.
IBM® 영역 장애에서 복구하는 방법
영역 장애 발생 시 IBM Cloud 은 영역 중단을 해결하고 영역이 다시 온라인 상태가 되면 글로벌 로드 밸런서가 고객 조치 없이도 복원된 인스턴스 노드로 API 요청 전송을 재개합니다.
IBM® 지역 장애에서 복구하는 방법
장애 후 리전이 복원되면 IBM 은 리전 상태에서 서비스 인스턴스를 복원하려고 시도하므로 데이터 손실이 없고 동일한 연결 문자열로 복원된 서비스 인스턴스를 사용할 수 있습니다.
지역 상태가 손상된 경우 서비스는 마지막 내부 백업 상태로 복원됩니다. 서비스와 관련된 모든 데이터는 서비스에서 관리하는 지역 간 Cloud Object Storage 버킷에 매일 두 번 백업됩니다. 24시간 분량의 데이터가 손실될 가능성이 있습니다. 이러한 백업은 고객 관리형 재해 복구에는 사용할 수 없습니다. 서비스가 백업에서 복구되면 인스턴스 ID도 복원되므로 엔드포인트를 사용하는 클라이언트는 새 연결 문자열로 업데이트할 필요가 없습니다.
- RTO = 4시간
- RPO = 최대 12시간
IBM 에서 서비스 인스턴스를 복원할 수 없는 경우 고객은 재해 복구 섹션에 설명된 대로 복원해야 합니다.
IBM® 서비스 유지 관리 방법
모든 업그레이드는 IBM® 서비스 모범 사례를 따르며 복구 계획과 롤백 프로세스가 마련되어 있습니다. 새로운 기능 및 유지보수를 위한 정기적인 업그레이드는 정상적인 운영의 일부로 이루어집니다. 이러한 유지 관리로 인해 클라이언트 가용성 재시도 로직에 의해 처리되는 짧은 중단 간격이 발생할 수 있습니다. 변경 사항은 지역별로, 그리고 한 지역 내에서 구역별로 순차적으로 적용됩니다. 결함이 처음 발견되면 업데이트가 백업됩니다.
복잡한 변경 사항은 기능 플래그를 통해 활성화 및 비활성화하여 노출을 제어합니다.
고객 워크로드에 영향을 미치는 변경 사항은 알림에 자세히 설명되어 있습니다. 자세한 내용은 이 서비스에 영향을 미치는 계획된 유지 관리, 공지사항 및 릴리스 노트에 대한 모니터링 알림 및 상태를 참조하세요.