Code Engineの高可用性と災害復旧について
高い可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA）とは、予期せぬ障害にもかかわらず、サービスが稼働し、アクセスし続ける能力のことである。 ディザスターリカバリーとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計が処理できる能力を超えています。、大規模な障害発生後にサービス業務を復旧させるプロセスのことである。
Code Engine Code Engine は、標準プランで サービスレベル目標（SLO）を満たして いる。
IBM Cloud の高可用性とディザスタリカバリの標準についての詳細は、 IBM Cloud が高可用性と冗長性を保証する方法を 参照してください。 また、サービス・レベル・アグリーメントに関する情報も参照できます。
Code Engine インスタンスの可用性
IBM Cloud® Code Engine は複数の場所（地域）で提供されている。 各リージョンには、冗長性のために3つのデータセンター（ゾーン）がある。
Code Engine プロジェクトをプロビジョンするときに、インスタンスを作成するロケーション (MZR) を選択します。 リージョンは、アプリ、ジョブ、ファンクション、フリートなどのワークロードがどこでホストされるかを決定する。
デフォルトでは、ワークロードは単一のゾーン内に配置される。 ホスティングゾーンに障害が発生した場合、ワークロードは残りのゾーンの1つに自動的に再作成される。
このサービスは、サービスのメンテナンスやソフトウェアのアップグレードなど、通常の運用中にゾーン間で制御されたワークロードの移動を実行する。 これらのロールアウトの再起動は、混乱を最小限に抑えるために優雅に実行される。 計画外のフェイルオーバーは、運用環境で予期せぬ事象が発生したときに発生する可能性がある。
Code Engine メタデータ（プロジェクト、アプリ、ファンクション、ジョブ、フリート、イメージビルド定義を含む）を保存し、可用性のためにリージョン内のすべてのゾーンにレプリケートします。 計算専用サービスとして、 Code Engine は、お客様のワークロードデータまたはコンテナイメージの高可用性を確保する責任を負いません。 高可用性を確保するためのガイダンスについては、各クラウドサービスのドキュメントを参照してください。 コンテナ・イメージの可用性については IBM Cloud Container Registry のガイダンスに従ってください。 IBM Cloud Object Storage、その他の IBM Cloud データベースやストレージサービスにデータを読み込んだり保存したりする場合は、各サービスの高可用性機能に関するドキュメントを参照してください。
Code Engineリージョン
次の表は、 Code Engine が利用可能な地域と、その高可用性ステータスの一覧である。
| 地域 | リージョン | 高可用性 |
|---|---|---|
| アジア太平洋 | オーストラリア (au-syd) |
MZR |
| アジア太平洋 | 大阪 (jp-osa) |
MZR |
| アジア太平洋 | 東京（jp-tok） |
MZR |
| ヨーロッパ | フランクフルト（eu-de） |
MZR |
| ヨーロッパ | マドリッド (eu-es) |
MZR |
| ヨーロッパ | ロンドン（eu-gb） |
MZR |
| 北米 | ダラス（us-south） |
MZR |
| 北米 | トロント (ca-tor) |
MZR |
| 北米 | ワシントン (us-east) |
MZR |
| 南アメリカ | ブラジル・サンパウロ (br-sao) |
MZR |
ジオグラフィとは、1つ以上の地域を含む地理的地域のことである。 各リージョンには 複数のアベイラビリティゾーンが あり、ローカルアクセス、低レイテンシ、セキュリティの要件を満たす。 各マルチゾーン・リージョン（MZR ）は、3つ以上の独立したゾーンで構成され、1つの障害事象が1つのゾーンにしか影響しないようになっている。
Code Engine インスタンスの災害復旧
地震、洪水、悪天候などの大規模な地域災害では、地域全体が影響を受ける可能性がある。 ワークロードがこのようなイベントに耐えられるようにするには、複数のMZRにワークロードを配置し、エッジプロキシサービスを使用して自動フェイルオーバーメカニズムを実装します。 例えば IBM Cloud® Internet Services. アプリケーションを複数のリージョンにデプロイする方法について詳しくは、 カスタム・ドメイン・ネームを使用した複数リージョンでのアプリケーションのデプロイを参照してください。
IBM、ディザスタリカバリを確実にする方法
Code Engine インスタンスのバックアップ
IBM Cloud Code Engine プロジェクトのメタデータを自動的にバックアップし、ディザスタリカバリの目的でクロスリージョン・ストレージに保存します。
| Code Engineリージョン | クロスリージョン・エンドポイント |
|---|---|
au-syd |
AP |
br-sao |
BR |
ca-tor |
CA |
eu-de |
EU |
eu-es |
EU |
eu-gb |
EU |
jp-osa |
AP |
jp-tok |
AP |
us-east |
US |
us-south |
US |
ジョブの複製や不要なアプリケーション・インスタンスのデプロイなど、ワークロードへの意図しない影響を避けるため、 Code Engine、ワークロードは自動的にリストアされません。 仕事量を回復させるのはあなたの責任です。 詳しくは、Code Engine を使用する際のお客様の責任についてを参照してください。
復旧時間目標（RTO）と復旧時点目標（RPO）
-
回復時間の目標 （RTO）とは、システム、アプリケーション、またはビジネス・プロセスが、重大なビジネス・インパクトを引き起こす前にオフラインにすることができる最大許容時間のことである。
-
復旧ポイント目標 （RPO）は、HAまたはDRイベント後のデータ損失の最大許容量（時間で測定）を定義する。
IBM は、HAフェイルオーバー、分離DRシナリオ（ お客様データとワークロード定義を除く）、データ復元、非技術的パラメータのシミュレーションを含むHA/DRテストを定期的に実施している。
これらのテストでは、RTO（復旧時間）とRPO（復旧時点）の目標が測定され、検証される。
| 目標 | ターゲット |
|---|---|
| ゾーン停電時の自動フェイルオーバー | RTO = 秒、RPO = 0 |
| ディザスターリカバリー（ お客様遺物の復旧を除く | RTO = 数時間、RPO = 1日 |
災害復旧の計画
IBM の HA/DR テストに加え、ディザスタリカバリ手順を定期的に練習する必要があります。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。
| Event | 解決方法 |
|---|---|
| ハードウェア障害（コンピュート・インフラ） | IBM ゾーン内のシングルポイントのハードウェア障害に強いインフラを提供します。 |
| ゾーン障害 | 自動フェイルオーバー （Code Engine インスタンスの可用性を 参照）。 作業負荷は自動的に利用可能なゾーンに移動する。 |
| データ破損 | データのバックアップを作成するのはあなたの責任です。 |
| 地域的な失敗 | 自動フェイルオーバーなし。 Code Engine インスタンスのディザスタリカバリで 説明したように、ワークロードを2つ目のマルチゾーン・リージョンに展開する必要があります。 |
| ワークロードの可用性 | あなたは、外部ストレージやデータベースから状態を回復するために、ビジネスアプリケーションを実装する責任があります。 |
| HA/DR 耐障害性 | お客様は、停電時にお客様のコンポーネントを管理し、ワークロードとお客様データを復元するために、訓練を受けたスタッフを確保する責任があります。 |
HAとDRの責任
各特徴に関連する以下のチェックリストを、計画の作成と実践に役立ててください。
-
IBM Cloud® Code Engine アプリ、ジョブ、フリートで使用されるコンテナイメージ
コンテナイメージが IBM Cloud Container Registry バックアップリージョンで利用可能であることを確認する。
-
IBM Cloud® Code Engine 関数に使用されるコードバンドル
コードバンドルが IBM Cloud Container Registry バックアップリージョンで利用可能であることを確認してください。
包括的な高可用性（HA）および災害復旧（DR）テスト計画には、RTOおよびRPO目標の定義、重要システムの特定、バックアップの完全性、ネットワーク・フェイルオーバー、データ同期の検証が含まれます。 主なステップには、障害（ノード障害やサイト停止など）のシミュレーション、フェイルオーバー手順の実行、システム機能の検証、フォールバックプロセスの文書化が含まれる。
-
試験準備
- 目標を定義する ：復旧時間目標（RTO）と復旧時点目標（RPO）を確認する。
- 重要なシステムを特定する ：フェイルオーバーが必要なすべてのシステム、データ、アプリケーションをリストアップする。
- チームの役割を確立する ：DRチームの責任を明確にし、主要な連絡担当者を割り当てる。
- バックアップの検証 ：バックアップが有効でアクセス可能であることを確認する。
- 環境の分離 ：本番環境への偶発的な影響を防ぐため、テストシステムを隔離する。
-
テストの実施
- 障害シナリオのシミュレーション ：ネットワーク接続の切断、サービスの停止、プライマリ・サーバーのシャットダウンなど、計画的な障害を開始します。
- フェイルオーバーの実行 ：セカンダリ/DR サイトへの文書化されたフェイルオーバー手順を実行する。
- データの完全性を検証する ：チェックサムやハッシュ値を使用して、データが破損していないことを確認する。
- アプリケーションの検証 ：DRサイト上のアプリケーションの機能をテストする。
- DNS/トラフィックの再ルーティング ：ユーザートラフィックが新しいアクティブノードにリダイレクトされることを検証する。
-
事後テストと記録
- フェイルバックの実行プライマリ・サイトを速やかにオンラインに戻し、データを再同期する。
- 結果を記録する ：時間、成功、計画からの逸脱を記録する。
- ギャップを特定する：計画の欠陥を特定し、それに応じて手順を更新する。
- コミュニケーション監査 ：すべての利害関係者に通知が送られたことを確認する。
-
一般的なテストシナリオ
- HAテスト ：スタンバイノードへのローカルフェイルオーバー（同じデータセンター内など）。
- DRテスト ：地理的に離れた場所への完全なフェイルオーバー。
- データの復元 ：バックアップ・データストアからプライマリまたは選択したバックアップ・ロケーションに、 お客様データとワークロード成果物を完全にリストアします。
- スタッフの可用性 ：主要な担当者が利用できない、またはシステムに接続できない場合の運用への影響をテストする。