Zenn
📘

[AWS]構成(ディザスタリカバリ,ALB,ロードバランサー)

2025/02/26に公開
AWS
alb
ディザスタリカバリ
バランシング
tech

ディザスタリカバリ（Disaster Recovery、DR）

自然災害。サーバー攻撃でデータセンターに問題が発生した時
損害の軽減、機能の維持、回復・復旧のための対策をする

今までは物理的に離れた場所にデータセンターを置いていた、コピー環境を用意する
⇒コストと時間かかる、めんどう

コスト抑えられるだけでなく、アベイラビリティゾーンの活用でグローバル環境を構築できる

DRを設計する際に考えるべきこと

災害・障害の規模

  • 発生規模はどのくらい？日本？世界？特定の場所？
  • この想定される規模で、DRをどこに置くか考える

RPO（Recovery Point Objective, 目標復旧時点）

  • RPOは、障害時にどの時点まで復旧するかを定義する
    • どの程度ならデータを失っても平気？
  • RPOに沿って、バックアップの頻度を考えておく

RTO（Recovery Time Objective, 目標復旧時間）

  • RTOは、障害発生から復旧までの時間を表す
  • RTOに沿って、システムの復旧方法・他システムへの切り替えるかを決める

復旧までのシナリオを定義
⇒ここでの 「シナリオ」 とは、システムが障害から復旧するまでの具体的な手順や戦略のこと。
優先順位、どんな障害を想定するか、復旧手順はどうするかなど

この辺は基本情報でも出てくる範囲
https://www.fe-siken.com/kakomon/01_aki/q57.html

具体的な復旧方法

① バックアップ＆リストア

  • 定期的にデータや環境をバックアップ（S3などに保存）
  • 障害発生時に0から環境を構築し、データを復元する
  • 復旧時間は長いが、コストは低い

復旧方法

  1. 新しい環境を用意

    • EC2（AWSの仮想サーバー）やオンプレミスに、新しいサーバーを準備。
    • 必要ならOSやミドルウェアをインストールし、アプリケーションの環境を構築。

  2. バックアップから復元（リストア）

    • S3に保存されているディスクスナップショットや、バックアップデータを復元。
    • データベースなら、RDSのスナップショットや手動バックアップからリストア。

  3. ネットワーク設定・動作確認

    • 復旧した環境に対して、適切なセキュリティグループやロードバランサーの設定を適用。
    • アプリケーションが正常に動作するかテスト。

特徴

  • 復旧時間（RTO）が長い（環境構築が必要なため）
  • コストは低い（普段はバックアップの保存だけで済む）
  • 部分的な障害向け（DBやAPサーバーのみが故障した場合）

② コールドスタンバイ

  • 停止状態のサーバーを用意しておき、障害時に起動する
  • 事前にAMIやCloudFormationで環境を準備
  • 復旧時間は中程度で、コストは低め（通常時はサーバーが動いていないため）

復旧方法

  1. DRサイト（待機用サーバー）を起動

    • 事前に作成しておいた AMI（EC2のイメージ） から新しいEC2を起動。
    • CloudFormationを使って、自動で環境を作成。

  2. データを復元（リストア）

    • S3やRDSのスナップショットから、最新のデータを復元。

  3. DNSを切り替え

    • Route 53のDNS設定を変更し、新しい環境（DRサイト）にアクセスを向ける。

  4. 動作確認

    • アプリケーションが正常に稼働しているか確認。

特徴

  • 復旧時間（RTO）は中程度（サーバーの起動が必要）
  • コストは低め（通常時は停止しているため、起動時のみ課金）
  • DRサイトの準備が必要（事前にAMIやCloudFormationを作成）

③ ホットスタンバイ

  • 常にDR環境（バックアップ環境）を最小構成で稼働させておく
  • 障害発生時にサーバースペックを拡張し、DNSを切り替え
  • 復旧時間は短く（数分以内）、コストは高い

復旧方法

  1. DRサイトへ自動切り替え

    • 事前に稼働しているDRサイトのサーバーをスケールアップ（CPUやメモリを増強）。
    • アプリケーションやDBがリアルタイムで同期されているため、即座に切り替え可能。

  2. DNSを切り替え

    • Route 53のヘルスチェックを利用して、障害を検知したら自動でDRサイトに切り替え。

特徴

  • 復旧時間（RTO）は短い（自動切り替えのため、数分以内で復旧）
  • コストは高い（DRサイトを常時稼働させるため）
  • リアルタイム同期が必要（データの整合性を保つため、DBやアプリを常時同期）

④ マルチサイト

  • メインサイトとDRサイトを常時フル稼働させ、DNSで負荷分散
  • 障害時は自動的にDRサイトへ切り替え（RTOほぼゼロ）
  • コストが最も高いが、可用性が最も高い

復旧方法

  1. DNSを切り替え

    • Route 53のヘルスチェックを利用し、メインサイトがダウンした場合に自動でDRサイトへリダイレクト。

  2. DRサイトで業務継続

    • すでにDRサイトが稼働しているため、サービスが継続する。

特徴

  • 復旧時間（RTO）はほぼゼロ（DNSが自動切り替えされるため）
  • コストが最も高い（2つの環境を常時フル稼働させる必要がある）
  • 可用性が最も高い（災害時でも業務継続可能）

まとめ

シナリオ RTO（復旧時間） コスト 特徴
バックアップ＆リストア 長い（数時間〜数日） 低 手動で復元するため復旧に時間がかかる
コールドスタンバイ 中程度（数十分〜数時間） 低〜中 事前に準備した環境を起動して復旧
ホットスタンバイ 短い（数分以内） 高 事前に動作する環境があり、切り替えがスムーズ
マルチサイト ほぼゼロ（即時） 非常に高い 2つの環境をフル稼働させるため、コストが最も高い

どのシナリオを選ぶべきか？

  • コストを抑えつつデータを守りたい → バックアップ＆リストア
  • 最小限のコストで可用性を確保したい → コールドスタンバイ
  • ダウンタイムを最小限にしたい → ホットスタンバイ
  • 常時システムを稼働させたい → マルチサイト

コストがかかる順（高い → 低い）

  1. マルチサイト（常に2つの環境をフル稼働させるため、最もコストが高い）
  2. ホットスタンバイ（DR環境を最小構成で常時稼働するため、コストが高い）
  3. コールドスタンバイ（通常は停止しているが、DR環境の準備にコストがかかる）
  4. バックアップ＆リストア（バックアップ保存のみで済むため、最もコストが低い）

作業が楽な順（楽 → 大変）

  1. マルチサイト（常に両方稼働しており、自動切り替えされるため、運用負担が最も少ない）
  2. ホットスタンバイ（普段から稼働しているため、障害時の対応が簡単）
  3. コールドスタンバイ（環境を起動する手間があるが、自動化すれば比較的楽）
  4. バックアップ＆リストア（ゼロから環境を構築する必要があり、最も手間がかかる）
順位 コストが高い＆作業が楽ランキング（高い → 低い）
1位 マルチサイト
2位 ホットスタンバイ
3位 コールドスタンバイ
4位 バックアップ＆リストア

ALB（Application Load Balancer）とは

ALB（Application Load Balancer） は、AWSのアプリケーションレベル（HTTP/HTTPS）で動作するロードバランサー です。

ALBの動作

  • アプリケーションのリクエストを複数のEC2に振り分ける
  • ターゲット（EC2やECSなど）をヘルスチェックし、正常なものだけにリクエストを送る
  • パスごとに異なるターゲットへルーティング可能（例：/api はAサーバー、/web はBサーバー）

ALBの料金

  • 💸使用した分だけ課金されるが、アクセスがなくても最低料金が発生
  • 1ヵ月使い続けると約18ドル以上
  • 使わない場合は削除を推奨

ALBの設定手順

  1. ロードバランサー本体を作成（ALBの基本設定）
  2. バランシングするターゲットを設定（EC2などのサーバーを登録）

バランシングとロードバランサー

📌 バランシング（Load Balancing）

バランシング（Load Balancing） とは、1つのサーバーにアクセスが集中しないように、複数のサーバーに均等に負荷を分散する仕組み 。

バランシングの仕組み

  1. ユーザーがWebサイトにアクセス
  2. ALB（ロードバランサー）がリクエストを受ける
  3. 正常なEC2サーバーにリクエストを振り分ける
  4. EC2がレスポンスを返す
  5. ALBがユーザーへ返す

📌 ロードバランサーとは？

ロードバランサー（Load Balancer） は、サーバーへのトラフィック（通信）を複数のサーバーに分散する仕組み 。

📝 ロードバランサーの役割

  1. 負荷分散（アクセスが1台のサーバーに集中しないようにする）
  2. 障害対策（1台がダウンしても他のサーバーが処理を継続できる）
  3. スケールアウト対応（サーバーを増やして対応できる）

📌 バランシングとロードバランサーの違い

用語 意味 例
バランシング（Load Balancing） 処理を複数のサーバーに分散する考え方や手法 1台のサーバーに負荷を集中させず、複数のサーバーで均等に処理する仕組み
ロードバランサー（Load Balancer） バランシングを実現するための機能や装置（AWSではALBなど） ユーザーからのリクエストを受け取り、適切なサーバーに振り分ける

💡「バランシング」は概念で、「ロードバランサー」はそれを実現する装置やサービス 。

✔️ バランシングだけでは実現できない

例えば、バランシングの概念を知っていても、手動でユーザーのリクエストを分散させることはできない。
「Aさんはサーバー1、Bさんはサーバー2へ…」とするのは現実的ではない。

✔️ ロードバランサーがバランシングを実装する

ロードバランサーを使うことで、自動的にリクエストを分散 でき、以下のことが可能になる。

  • 負荷を均等に分散
  • サーバーの死活監視（落ちたサーバーには振り分けない）
  • スケールアウト（サーバー追加時に自動で対応）

Discussion