高可用性と災害復旧は同じですか？ 両方必要ですか？

高可用性（HA）とディザスタリカバリ（DR）は混同されやすいが、明確に異なる。

ワークロードに高可用性を設計することは、ワークロードの失敗を防ぐ努力である。 たとえば、RAIDアレイで複数のディスクにデータを分散させるのは、ディスク障害による機能停止を防ぐための努力である。 サーバー内の複数電源は、電源回路の停止による故障を防ぐための取り組みである。 異なるゾーンにある複数のサーバーにまたがってアプリケーションを実行することは、サーバーの障害やゾーンの障害によって引き起こされる停電を防ぐための努力である。

ディザスタリカバリとは、自由に使えるリソースがあるにもかかわらず、ワークロードに障害が発生した場合に、そのワークロードを復旧させることである。 例えば、あるワークロードは、複数のデータセンターの複数のハードウェア・デバイスで実行されるため、可用性が高く、障害に強いかもしれない 99.999 しかし、偶発的または悪意によるデータの消去や、すべてのデータセンターを含む広範囲を破壊する自然災害などの災害の影響を受けやすいことに変わりはない。

通常、可用性の高いワークロードが必要であればあるほど、そのワークロードの価値は高くなり、ビジネスにとって不可欠なものとなる。 ワークロードはビジネスに不可欠であるため、きちんと文書化された厳格な災害復旧計画を持つ必要性が高い。

何が災害なのか？

IT災害とは、アプリケーションや環境を著しく混乱させ、意図したとおりに機能させることができなくなる出来事である。 災害は短期的なものから長期的なものまであるが、通常、経済的、評判的、あるいはその両方において、ビジネスに大きな損害をもたらす。

災害は次のようなシナリオの結果として起こるかもしれない：

• 洪水、火災、地震などの自然災害。
• 停電や広範なネットワーク障害などのインフラ問題。
• データ、サービス、設定を削除する事故または悪意のある行為。
• 予期していなかったバグやその他のエラーを含むソフトウェアアップデートをロールアウトすること。

いずれの場合も、決められた時間内に、災害前の時点にサービスを復旧させる復旧計画が不可欠だ。 また、ダウンタイムがビジネスに与える影響と、復旧ソリューションにかかる費用の両方を含めて、コストを検討することも重要だ。

DRは1つの地域で行われるのか？

そう、DRは同じリージョン内で行うことができ、レイテンシが少なく、リージョンをまたいだデータレプリケーションが不要なため、より高速になる可能性がある。 しかし、より高い回復力を得るためには、別のリージョンを使用することが推奨される。 プライマリー地域が深刻な影響を受けた場合、同じ地域での回復は不可能かもしれない。

IBM Cloudは、公表されている サービスレベル目標（SLO ）に沿って、地域内のサービスを回復するよう努める。 復旧には数分あるいは数時間かかるかもしれないが、最悪の場合、おそらく物理的な財産の破壊があった場合、復旧には数日、数週間、数カ月かかることもある。

IBM Cloudでは、 IBM Cloudが災害と呼ぶような障害が発生した場合、 IBM Cloudはワークロードを復旧する前にサービスを復旧しなければならないかもしれない。 その場合、 IBM Cloudがリカバリを完了するまでの時間を、自分のリカバリにかかる時間に追加する必要がある。 単一地域だけに依存するかどうかを決める際には、この点に留意してほしい。

すべての災害は第二地域での復旧が必要なのか？

すべての災害が第二地域での復旧を必要とするわけではない。 データベース管理者が誤ってデータベースのテーブルを落としてしまったり、自動リリースがうまくいかなかったり、必要不可欠なマネージドクラウドサービスが正しく機能しなくなったりする可能性がある。 このような場合、データ復旧が鍵となる。 問題がどの程度広がっているか、組織がどの程度準備できているか、どの程度迅速に復旧する必要があるかにもよるが、このような災害が発生しても、他の地域へのフェイルオーバーを余儀なくされないかもしれない。 シナリオによっては、同じ地域で回復を達成することもできる。 計画では、複数の災害シナリオを考慮する。

誤ってサービスを削除しないようにするにはどうすればよいですか？

多くの IBM Cloud サービスには、誤って削除することを防ぐセーフガードが組み込まれていますが、適切なアクセス権を持つアカウント使用することで、より多くの保護を実装することができます。 Cloud Identity and Access Management (IAM)を使用して、異なるレベルのアクセスと権限を持つアカウントを作成する。 そして、目の前の業務タスクに適切なアカウントを使用し、開発者など他のユーザーには、必要なアクセス権と権限だけを与えるようにする。

Terraformを使用する場合は、更新アクセス権はあるが削除アクセス権はないサービスIDを使用する。