##耐障害性の向上1##
別リージョンや別AZにバックアップを取得保管する。
##耐障害性の向上2##
別リージョンや別AZにスタンバイ構成をとっておき、即座にフェイルオーバーできるようにする。
##高可用性の設計を考えるポイント##
目標復旧時間（RTO: RecoveryTime Objective）
「どれくらいの時間で復旧できれば影響が少ない？」の目安
目標復旧時点（RPO: RecoveryPoint Objective）
「いつ時点のデータを復旧できれば何とかなる？」
耐障害性
アプリケーションに組み込まれた冗長性
復元可能性
障害、災害発生時におけるサービス復旧にかかる機能など
拡張性
設計において、スケーラビリティを以下に確保するのか
トレードオフ
可用性を高めると、コストは高くなり、構成も複雑になるので、うまくバランスを調整する。
##単一障害点の排除1##
ELBを利用したマルチAZ構成にする
##単一障害点の排除2##
マルチAZでマスタースレーブ構成にし、リードレプリカで軽減する。
##障害復旧モデル##
| DR構成 | 説明 |
|---|---|
| バックアップ＆リストア | バックアップデータを別リージョンに保存しておき、DRサイト側レプリケーション。DR時はバックアップからシステムを復旧する。 |
| パイロットライト | DRサイト側でスペックの低いスタンバイDBをたて、通常時はデータ同期のみ行う。DR時はDRサイト側でAPを起動、DBをスケールアップし、復旧する。 |
| ウォームスタンバイ | DRサイトでスペックの低い構成を常時起動。DR時はサーバーをスケールアップし、DNSの名前解決先をDRサイト側に切り替え、復旧する。 |
| マルチサイト | DRサイトで完全に同スペックの構成を常時起動。DR時はDNSの名前解決先をDRサイト側に切り替えるのみで、短時間で業務復旧。 |
上記のような例があげられますが、重要な要件をどこにおくかによる。
例えば、コスト最適化に重点をおくのであれば、「バックアップ＆リストア」になるだろう。
ダウンタイムをもっとも短くするのであれば、「マルチサイト」となる。
