IBM Cloud Logs の高可用性と災害復旧について

高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。サービスについては、可用性はサービスレベル契約で定義されています。可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。（HA）とは、予期せぬ障害が発生した場合でも、サービスが稼働し続け、アクセス可能であることを意味します。災害復旧サービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。その影響は、高可用性設計が処理できる能力を超えています。とは、サービスインスタンスを稼働可能な状態に復旧するプロセスです。

IBM Cloud Logs は、高可用性、マルチテナント型の地域サービスです。利用可能な地域とデータセンターの場所については、ロケーションに関するドキュメントをご覧ください。地域サービスとして、 IBM Cloud Logs はスタンダードプランで定義されたサービスレベル目標（SLO）を達成しています。 SLO は保証ではないので、目標を達成できなくても IBM からのクレジットの発行はありません。

サービスレベル目標（SLO）は、 IBM Cloud サービスが満たすように設計された設計ポイントを記述する。 IBM Cloud Logs は、以下の可用性目標を達成するように設計されている。

SLOの IBM Cloud Logs
可用性目標	ターゲット値
可用性 %	99.99%

高可用性アーキテクチャ

アベイラビリティー・ゾーンとは、1 つの IBM Cloud リージョン内で論理的かつ物理的に分離された場所のことであり、データが処理され、ホストされる場所です。

アベイラビリティー・ゾーンをまたぐ単一障害点をなくして耐障害性を強化するために、ゾーンごとに、他のゾーンから切り離された電源、冷却装置、ネットワーク・インフラストラクチャーがあります。
同じリージョン内では、高帯域幅かつ低遅延のアベイラビリティー・ゾーン間通信を利用できます。

リージョン (ロケーション) とは、地理的および物理的に分けられたグループであり、各グループには 1 つ以上のアベイラビリティー・ゾーンが含まれます。リージョンごとに、他のリージョンから切り離された電気インフラストラクチャーとネットワーク・インフラストラクチャーがあります。

リージョンは、他のリージョンとの単一障害点の共有をなくし、かつ、リージョン内での低遅延のゾーン間通信が保証されるように設計されています。
冗長化のために、リージョンごとに 3 つの異なるデータ・センター (DC) があります。

高可用性機能

IBM Cloud Logs 以下の高可用性機能に対応しています

HA機能 IBM Cloud Logs
特長	説明
複数ゾーンの地域展開	IBM Cloud Logs マルチゾーンリージョン（MZR）のみに展開され、MZR内ではデータプレーンクラスタが3つのゾーンすべてにまたがって展開されるため、ゾーンの損失がサービスの可用性に影響を与えることはありません。
IBM Cloud Logs ゾーン間のリソース複製	IBM Cloud Logs のリソース（アラート、メトリクス、ログなど）はすべて、MZRs内の3つのゾーンに複製されます。これにより、ゾーンが失われた場合でもデータの保持が保証されます。
稼働状況/準備状況の監視	すべてのマイクロサービスは、 Kubernetes の生存性および準備性プローブによって監視されています。

災害復旧アーキテクチャ

IBM Cloud Logs Red Hat OpenShift on IBM Cloud 上のVPCで構築されており、マルチゾーンリージョンを使用し、3つのゾーンにすべてのワーカーノードを分散しています。 VPCロードバランサーは、受信したトラフィックを処理し、クラスタ内で実行されているサービスメッシュに転送します。

地域をまたいだ自動的なフェイルオーバーや災害復旧は行われません。リージョン内のすべてのアベイラビリティ・ゾーンに障害が発生すると、そのリージョンでは IBM Cloud Logs。

災害復旧機能

IBM Cloud Logs 以下の災害復旧機能をサポートしています

DR機能 IBM Cloud Logs
特長	説明
代替地域	代替の地域で稼働しているサービスは、メインのサービスとは別に利用できます
データベース・バックアップ	現在のデータセットのコピーが保存されます

DR計画

DR手順は定期的に実施されなければなりません。計画を立てる際には、以下の失敗シナリオと解決策を考慮してください。

DRシナリオ IBM Cloud Logs
失敗	解決方法
ハードウェアの故障（単一箇所）	IBM ゾーン内の単一ハードウェア障害に耐えるデータベースを提供します。設定は不要です。
ゾーン障害	IBM Cloud Logs ゾーンの故障が発生しても耐えられるマルチゾーン地域展開を使用しています。
データ破損	データが破損した場合、データベースはバックアップサイトで利用可能な最後の安定した状態にロールバックされます。リカバリには IBM Cloud Object Storage バックアップを使用します。バックアップを参照してください。
地域的な障害	HAとDRにおけるお客様の責任」の項の手順に従ってください

HAとDRに対するお客様の責任

IBM Cloud は、災害が発生した場合、数時間以内にサービスを復旧させるための事業継続事前に規定したサービス・レベル・アグリーメントに従って、障害に耐え、中断することなくミッション・クリティカルなサービスの通常運用を継続できる事業の能力。計画を策定している。データのバックアップおよび関連するコンテンツのリカバリーは、お客様の責任で行っていただきます。

地震、洪水、竜巻などの大規模な災害がリージョンで発生した場合、リージョン全体が影響を受ける可能性があります。

IBM Cloud Logs インスタンスを復旧するには、新しい IBM Cloud Logs インスタンスをプロビジョニングし、 IBM Cloud Logs リソースを再作成する必要があります。また、インスタンスに関連付けられている IBM Cloud Object Storage バケット用のDR戦略、および通知アラートをトリガーするように設定した可能性のある IBM Cloud Event Notifications インスタンス用のDR戦略も必要です。

このような事態に耐えられるようにワークロードを確実に設定するには、以下の手順を完了してください

ダウンしている構成を復元できる地域戦略を定義する。

リカバリリージョンを選択する際には、データの保存場所とコンプライアンス要件を確認してください。

場所の詳細については、以下をご覧ください
- IBM Cloud Logs 対応地域
- IBM Cloud Object Storage 対応地域
- IBM Cloud Event Notifications サポート対象地域。は、がサポートされているすべての地域でサポートされているわけではありません。 IBM Cloud Event Notifications IBM Cloud Logs
Terraformを使用しない構成の場合は、APIを使用して現在の構成をバックアップしてください。 Terraform を使用している場合は、Terraform スクリプトを保存して、ダウンしたリージョンを再作成できるようにしておきます。バックアップファイルまたは Terraform スクリプトを保存するために、バージョン管理システムの使用を検討してください。

Terraformを使用して IBM Cloud Logs インスタンスを作成できます。リソース管理 Terraform resources を参照してください。

Terraformを使用して、 IBM Cloud Logs リソースを作成できます。 IBM Cloud Logs Terraform リソースを参照してください。

Terraformを使用して、データバケット、メトリクスバケット、またはその両方を、複数の地理的地域にまたがってデータを保存およびアクセスし、高可用性、耐久性、および災害復旧機能を実現_するクロスリージョンレジリエンス機能_とともに作成することができます。 IBM Cloud Object Storage Terraform リソースを参照してください。

Terraformを使用して、 IBM Cloud Event Notifications のリソースを作成できます。 IBM Cloud Event Notifications Terraform リソースを参照してください。

Terraformを使用して、IAMの認証と権限を作成することができます。 IAM Terraformリソースを参照してください。

常に、代替の地域にバックアップ構成を復元できることをテストしてください。

地域災害が発生した場合、新しいリージョンでインスタンスを復旧するには、以下の手順を完了する必要があります

IBM Cloud Logs インスタンスを復元する代替の地域を特定します。
IBM Cloud Logs の新しいインスタンスを作成します。詳しくは、インスタンスのプロビジョニングを参照してください。
インスタンスにデータまたはメトリクスバケットが構成されている場合は、以下の手順を完了してください
- 災害リージョンの IBM Cloud Logs インスタンスが_クロスリージョン_IBM Cloud Object Storage (COS) バケットを使用していた場合、同じバケットを新しい IBM Cloud Logs インスタンスにアタッチできますが、災害リージョンの IBM Cloud Logs インスタンスで作成されたデータを、新しい IBM Cloud Logs インスタンスのダッシュボードまたは CLI を使用してクエリすることはできません。新しい地域で取り込まれたデータのみ照会できます。ダウンしている地域から既存のデータをダウンロードして表示することができます。アーカイブのデータ構造についての詳細は、「アーカイブからデータを直接照会する」を参照してください。
- 被災地の IBM Cloud Logs インスタンスのログにアクセスする必要がある場合は、新しく作成した IBM Cloud Logs インスタンスのダッシュボードまたは CLI を使用して、 IBM サポートまでお問い合わせください。 IBM Cloud Object Storage の災害復旧戦略の詳細については、「Cross-Region Endpoints（クロスリージョンエンドポイント）」、「Data security（データセキュリティ）」、「Create a Secure Content Store （セキュアなの作成）」、「Using replication for business continuity and disaster recovery（レプリケーションによる事業継続と災害復旧）」を参照してください。
- 影響を受けた地域からローカルまたはリージョンのバケットを使用していた場合は、新しいバケットを作成してください。新しい IBM Cloud Logs インスタンスにバケットをアタッチします。詳細は、「データバケットの設定」および「メトリクスバケットの設定」を参照してください。
- IBM Cloud Logs インスタンスとバケット間のIAM権限を定義します。詳細は、「バケットへのアクセス権限を付与する S2S の作成」を参照してください。
災害の影響を受けた地域にあるインスタンスが IBM Cloud Object Storage バケットで構成されていない場合、ログとメトリクスデータは失われます。
インスタンスにアラートが設定されている場合は、以下の手順に従ってください
- 新しい IBM Cloud Event Notifications インスタンスを作成するか、または異なる地域で利用可能な既存のインスタンスを使用し、常にコンプライアンスとデータローカリティの要件を満たしていることを確認してください。詳しくは、インスタンスのプロビジョニングを参照してください。 IBM Cloud Event Notifications の災害復旧戦略に関する詳細は、 IBM Cloud Event Notifications の「お客様のデータの保護」および「災害復旧」をご覧ください。
- IBM Cloud Logs インスタンスと IBM Cloud Event Notifications インスタンス間のIAM権限を定義します。詳細は、「 IBM Cloud Event Notifications サービスで使用するための S2S 認証の作成」を参照してください。
- IBM Cloud Event Notifications をアウトバウンド統合として設定します。詳細については、 IBM Cloud Event Notifications の「イベントの宛先へのルーティングの設定」を参照してください。
IBM Cloud Logs の新しいインスタンスでリソースを再作成します。

ビューの作成。

ダッシュボードの作成を行います。

アラートを作成する。

TCOポリシーを作成する。

解析ルールを作成します。

メトリクスにイベントを作成します。

データ通信を有効にします。

データのルールを設定する。

データ強化ポリシーを設定する。

IBM Cloud Logs インスタンスの復旧を容易にするには、Terraformを使用してインスタンス、構成、およびIAMアクセスを管理します。 Terraformを使用すれば、他の地域でインスタンスを構成する際に手動での手順が不要になります。

インスタンスを復旧した後、新しいインスタンスにログを送信するためにデータソースを再構成する必要があります

新しいリージョンに IBM Cloud Logs Routing のテナントが設定されている場合、そのリージョンに関連付けられている現在のターゲットを使用して、プラットフォームのログを表示および監視する必要があります。新しいリージョンに IBM Cloud Logs Routing テナントが設定されていない場合は、新しい IBM Cloud Logs インスタンスを参照する IBM Cloud Logs Routing テナントを作成します。 IBM Cloud Logs Routing テナントの作成と IBM Cloud Logs Routing の高可用性と災害復旧の理解については、こちらをご覧ください。
新しい地域で、ダウンした地域からのアクティビティ追跡イベントを収集する IBM Cloud Activity Tracker Event Routing 構成が設定されている場合、既存の構成を使用してイベントを表示および管理することができます。ダウンした地域からのアクティビティ追跡イベントを収集する IBM Cloud Activity Tracker Event Routing 構成が新しい地域にない場合は、イベントを収集する場所と方法を指定するルールを追加する必要があります。詳細は、「地域災害に強いルーティング構成の作成」を参照してください。
ロギング・エージェントを再構成し、 IBM Cloud Logs のリカバリ領域のインジェクションエンドポイントを指すようにします。

IBM Cloud Logs を使用する際のあなたと IBM Cloud 間の所有責任についての詳細は、「 IBM Cloud Logs を使用する際の責任の理解」をご覧ください。

目標復旧時間（RTO）と目標復旧時点（RPO）

IBM Cloud Logs は、お客様のデータを保護し、サービス機能を復元する方法を提供します。事業継続計画は、サービスの目標復旧時点目標災害復旧計画において、データが復旧するまでの時間は、復旧時点から災害発生時点までを秒、分、時間で測定した時間である。（RPO）と復旧時間目標災害復旧計画において、災害後にビジネスプロセスが復旧するまでの時間。（RTO）を達成するためのものである。以下の表は、 IBM Cloud Logs の目標の概要である。

RPOとRTO IBM Cloud Logs
災害復旧目標	ターゲット値
RPO	4 時間以内
RTO	24時間以内に

変更管理

変更管理には、アップグレード、構成変更、削除などのタスクが含まれる。

ユーザーおよびプロセスには、業務に必要な最小限の特権でIAMの役割と権限を付与することをお勧めします。参照サービスの誤削除を防ぐにはどうすればよいですか？

Terraformを使用していない構成がある場合は、 IBM Cloud Logs の新しいバージョンにアップグレードする前に、APIを使用してバックアップを作成することを検討してください。

IBM®、災害復旧計画をどのようにサポートするか

IBM® 毎年、さまざまな災害シナリオを想定したテストを実施しており、テスト中に発見された事項に基づいて、復旧に関する文書を継続的に改善しています。
IBM® のお客様には、24時間365日体制のグローバルサポートをご利用いただけます。災害時には、待機中の専門スタッフが対応いたします。

IBM® のすべての主題専門家は、災害発生時の備えを万全にするため、事業継続と災害復旧に関する方針と手順について毎年研修を受けています。

IBM Cloud Logs は、可用性の高い、リージョナルなサービスです。

IBM Cloud Logs が利用可能な地域の詳細については、「ロケーション」をご覧ください。
各リージョンには冗長性のために3つの異なるデータセンターがあり、 active/active モードで設定されている。
特定のロケーション内のすべてのデータセンターで障害が発生すると、そのロケーションでは IBM Cloud Logs が使用できなくなります。
サポートされる各リージョンでは、複数の可用性ゾーンにわたるインフラストラクチャー全体でトラフィックが負荷分散されるため、単一障害点は存在しません。

以下の表に、IBM Cloud Logs サービスを提供しているリージョン (ロケーション) の高可用性 (HA) 状況をリストします。

サービス提供地域一覧
地域	リージョン	EU サポートあり	HA 状況
アジア太平洋	大阪 (`jp-osa`)	適用外	`MZR`
アジア太平洋	シドニー（`au-syd`）	適用外	`MZR`
アジア太平洋	東京（`jp-tok`）	適用外	`MZR`
ヨーロッパ	フランクフルト（`eu-de`）	はい	`MZR`
ヨーロッパ	ロンドン（`eu-gb`）	いいえ	`MZR`
ヨーロッパ	マドリード (`eu-es`)	はい	`MZR`
北米	トロント (`ca-tor`)	適用外	`MZR`
北米	モントリオール (`ca-mon`)	適用外	`MZR`
北米	ダラス（`us-south`）	適用外	`MZR`
北米	ワシントン (`us-east`)	適用外	`MZR`
南アメリカ	サンパウロ (`br-sao`)	適用外	`MZR`

説明

_ジオグラフィー_とは、1 つ以上のリージョンを持つ地理的領域または広域の国家の集合体を指します。
_リージョン_とは、定義された地理的な領域です。
地域とは、特定の郵便番号の地域、町、市、州、州のグループ、あるいは国のグループかもしれない。
リージョンには複数のアベイラビリティ・ゾーンがあり、ローカル・アクセス、低レイテンシ、セキュリティの要件を満たす。
MZR は、マルチゾーン・リージョンを意味します。詳細はこちら。

各リージョンおよびデータ・センターでのサービスの提供状況について詳しくは、ロケーション別のサービスおよびインフラストラクチャーの提供状況を参照してください。

リージョン内で IBM Cloud Logs によって管理されるデータは、その地域の近くにあるデータ・センターで保管されます。

マルチゾーン・リージョン（MZR）は3つ以上のアベイラビリティ・ゾーンで構成され、互いに独立している。

デフォルトでは、 IBM Cloud Logs は3つのゾーンに展開されます。各ゾーンは active/active/active で設定されています

各ゾーンは、該当するリージョンの別々のデータ・センターに置かれます。
各ゾーンのデータは、低レイテンシーで自動的に他のゾーンにレプリケートされる。レプリケーションを有効にするために何かをする必要はない。
サービスは、1 つのゾーンで障害が発生しても中断しないように設計されています。

MZRアーキテクチャは、リージョン内のゾーン間の自動フェイルオーバーと、リージョン内の IBM Cloud Logs 展開の高可用性を提供する。

IBM Cloud Logs で管理されているメタデータには、重要な設定に関する情報（キー、アラート定義、 e2m 定義、メトリックデータなど）などのカスタマーメタデータが含まれています。

IBM Cloud Logs 定期的に各地域のデータをバックアップしています

定期的なバックアップは毎日行われ、30日間保持され、地域をまたいだ IBM Cloud Object Storage バケットに保存されます
継続的な増分バックアップは、過去 7 日分が保持されます。

完全な地域障害が発生した場合、バックアップデータは引き続き利用可能であり、 IBM Cloud Logs サービスの復旧の一部として復元されます。

IBM がゾーンの障害からどのように回復するか

ゾーンに障害が発生した場合は、 IBM Cloud がゾーンの停止を解消します。データプレーンはリージョン内の3つのゾーンすべてにまたがっているため、サービス可用性への影響はなく、グローバルロードバランサーは復元されたゾーンへのデータ送信を再開します。現時点では、お客様による対応は必要ありません。

IBM が地域的な障害からどのように回復するか

障害発生後にリージョンが復旧すると、 IBM はリージョンの状態からサービスインスタンスを復旧させようと試みます。リージョン内の状態が破損した場合、サービスは最後の内部バックアップの状態に復元され、サービスによって管理されるクロスリージョン IBM Cloud Object Storage バケット内の代替データサイトに継続的にストリーミングされます。バックアップデータが破損した場合、24時間分のデータ損失の可能性がある。これらのバックアップは、お客様管理の災害復旧にはご利用いただけません。

IBM がサービスインスタンスを復元できない場合は、お客様が災害復旧アーキテクチャに記載されている手順に従って復元する必要があります。

IBM がサービスを維持する方法

すべてのアップグレードは、 IBM のサービスにおけるベストプラクティスに従っており、復旧計画とロールバックプロセスが整備されています。通常業務の一環として、新機能やメンテナンスのための定期的なアップグレードが行われます。このようなメンテナンスにより、時折、短時間のサービス中断が発生することがありますが、これはクライアントの可用性再試行ロジックによって処理されます。変更は、地域ごとに、地域内のゾーンごとに順次展開されます。更新は、不具合の兆候が見られた時点で取り消されます。

顧客の作業負荷に影響を与える変更は通知に詳細が記載されています。詳細は、本サービスに影響する計画されたメンテナンス、アナウンス、リリースノートに関する監視通知とステータスをご覧ください。