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 )を満たす地域サービスである。 App ID で利用可能な IBM Cloud リージョンとデータセンターの詳細については、 ロケーション別のサービスとインフラの可用性を 参照してください。

高可用性アーキテクチャ

App ID サービス・インスタンスは、単一障害点のないマルチゾーン・リージョンの複数のゾーンにまたがってプロビジョニングされる。 インスタンス・ノードやアベイラビリティ・ゾーンに障害が発生した場合でも、APIリクエストはグローバルなロードバランサーを経由して、生き残った可用性の高いインスタンス・ノードにルーティングされ、サービスは実行され続ける。 障害が発生してからグローバルロードバランサが障害を認識するまでに短い時間(数秒)があり、その間に障害が発生したインスタンスにリクエストが送られることがあります。 プログラムでサービスインスタンスにアクセスするワークロードは、可用性を維持するために、 クライアントの可用性再試行ロジックに従う 必要がある。 ゾーン障害時の顕著なサービス低下はない。

災害復旧アーキテクチャ

サービス・インスタンスの停止から回復するには、回復サービス・インスタンスを回復リージョンで構築する必要がある。 一般に、リカバリ・サービス・インスタンスは、ソース・サービス・インスタンスと同じデータで構成されるべきである。 災害が発生する可能性がある前にリカバリ・リージョンにバックアップ・インスタンスを作成し、ソース・インスタンスと同期していることを確認するために定期的にメンテナンスするようにしてください。

ディザスターリカバリー機能

回復地域への回復を計画する。 リカバリー・インスタンスは 、 IBM Cloud 内のワークロード災害復旧アプローチと一致する必要があります。 リカバリ・インスタンスは、パスワード・ポリシー、ユーザー、 SAML 構成を含むデータについて、プライマリ・サービス・インスタンスへのデータ変更を追跡する必要がある。

インスタンスのバックアップとリストア

地域間の可用性を確保するために App ID インスタンスをバックアップおよびリストアするには、いくつかの基本的な手順を実行する必要があります。 以下を実行する必要があります。

  1. App ID インスタンスのバックアップのストレージを構成するためのポリシーを定義します。 この構成には、ユーザー・プロファイルやクラウド・ディレクトリー・ユーザーなどのデータをインスタンスのバックアップに保管する方法の計画が含まれます。

    1 次ロケーションで障害インシデントが発生する前に、バックアップ・システムを作成します。 推奨どおりに継続的な保護を維持するには、バックアップを生成して定期的に実行するプロセスを自動化します。

  2. 別のリージョンで App ID のインスタンスを作成し、構成する。

  3. バックアップを保管し、2 次ロケーションにある App ID インスタンスにリストアするプロセスをセットアップします。

API を使用したインスタンスのバックアップ

管理APIを使用して App ID インスタンスをバックアップするには、 App ID APIにリクエストを送信し、 App ID インスタンスのセットアップ情報を含むファイルを生成するスクリプトを記述します。 これらのファイルは、2 次リージョンの App ID インスタンスをリストアする必要があるため、安全な場所に保管してください。

App ID インスタンスのセットアップに基づいて、バックアップの設定を定義します (ユース・ケースに必要な設定など)。 例えば、以下のシナリオでは、 App ID インスタンスを以下の設定で構成します。

  • パスワード・ポリシー (ユーザーが 3 回連続して誤ったパスワードを入力した場合に 60 分間ユーザー・プロファイルをロックするなど)
  • SAML 構成

管理 API を使用してこれらのユーザー設定を取得するには、以下を送信します。

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 エンドポイントに GET リクエストして、 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/export/all API エンドポイントを使用します。 エクスポートをダウンロードするには、 cloud_directory/export/download API を使用します。 管理 API を使用して Cloud Directory ユーザーをエクスポートする方法について詳しくは、「 すべてのユーザーのエクスポート 」の資料を参照してください。
  • ユーザー・プロファイルをエクスポートするには、 users/export エンドポイントを使用します。
  • これらの 2 つのエクスポート API は 2 つのバックアップ・ファイルを生成します。これらのファイルは、後でリストア・プロセスで使用するために安全に保管する必要があります。

Terraform と API を使用したインスタンスのバックアップ

Terraform を使用して App ID 設定をバックアップするために、 App ID インスタンスのセットアップ情報を含むファイルを生成する Terraform スクリプトを作成できます。 これらのファイルは、2 次リージョンの App ID インスタンスをリストアするために使用する必要があるため、安全な場所に保管してください。

App ID インスタンスのセットアップに基づいて、バックアップの設定を定義します (ユース・ケースに必要な設定など)。 例えば、以下のシナリオでは、 App ID インスタンスを以下の設定で構成します。

  • パスワード・ポリシー (ユーザーが 3 回連続して誤ったパスワードを入力した場合に 60 分間ユーザー・プロファイルをロックするなど)
  • SAML 構成

以下の Terraform スクリプトを使用して、現在の構成を取得し、それをファイルに保管することができます。

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/export/all API エンドポイントを使用します。 エクスポートをダウンロードするには、 cloud_directory/export/download API を使用します。 管理 API を使用して Cloud Directory ユーザーをエクスポートする方法について詳しくは、 すべてのユーザーのエクスポート を参照してください。
  • ユーザー・プロファイルをエクスポートするには、 users/export エンドポイントを使用します。
  • これらの 2 つのエクスポート API は 2 つのバックアップ・ファイルを生成します。これらのファイルは、後でリストア・プロセスで使用するために保管する必要があります。

API を使用した App ID インスタンスのリストア

最初に、2 次リージョンに App ID の新規インスタンスを手動でプロビジョンする必要があります。 その後、バックアップ・ファイルを読み取り、管理 API 要求を使用して 2 次リージョンの App ID インスタンスをセットアップすることで、 App ID 設定を復元できます。

バックアップセクションに含まれるシナリオを続けると、管理APIに以下を送信することで、 SAML 構成とパスワードポリシーをリストアできる:

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/import/all API エンドポイントを使用します。 管理 API を使用して Cloud Directory ユーザーをインポートする方法について詳しくは、「 すべてのユーザーのインポート 」の資料を参照してください。
  • ユーザー・プロファイルをインポートするには、 users/import エンドポイントを使用します。

Terraform と API を使用した App ID インスタンスのリストア

Terraform と管理 API を組み合わせて使用して App ID インスタンスをリストアする場合、最初のステップは、2 次リージョンに App ID の新規インスタンスをプロビジョンするための Terraform スクリプトを作成することです。 その後、バックアップ・ファイルを読み取り、terraform コマンドを使用して 2 次リージョンの 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
  }
}

クラウド・ディレクトリーのユーザーおよびユーザー・プロファイルを復元するには、管理 API を使用することをお勧めします。

  • クラウド・ディレクトリー・ユーザーをインポートするには、 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 バケットに、サービスによって毎日2回バックアップされる。 24時間分のデータが失われる可能性がある。 これらのバックアップは、お客様が管理する災害復旧には利用できません。 サービスがバックアップから復元されると、インスタンスIDも復元されるため、エンドポイントを使用するクライアントは新しい接続文字列で更新する必要はありません。

  • RTO = 4時間
  • RPO = 最大12時間

IBM がサービスインスタンスを復元できない場合、お客様はディザスタリカバリのセクションに記載されている方法で復元する必要があります。

IBM® サービスの維持方法

すべてのアップグレードは、 IBM® サービスのベストプラクティスに従い、リカバリプランとロールバックプロセスを導入しています。 新機能やメンテナンスのための定期的なアップグレードは、通常業務の一環として行われます。 このようなメンテナンスは、 クライアントの可用性再試行ロジックによって 処理される短い中断間隔を引き起こすことがある。 変更は地域ごとに、また地域内のゾーンごとに順次展開される。 アップデートは、欠陥の最初の兆候でバックアップされる。

複雑な変更は、露出をコントロールする機能フラグで有効・無効にする。

顧客のワークロードに影響を与える変更は、通知で詳述される。 詳細については、このサービスに影響する計画的メンテナンス、アナウンスメント、リリースノートの 通知とステータスの監視を 参照してください。