Zenn
🍒

[AWS]動的アプリケーション構成と災害対策

2024/08/10に公開
AWS
初心者
Security
災害対策
tech

AWSを利用した動的アプリケーションの構成と災害時の対策方法~~~
運用に大切な事だな😲

DR「ディザスタリカバリ」とは

「ディザスタリカバリ（Disaster Recovery）、DR」は、自然災害やサイバー攻撃などでデータセンターやシステムの稼働に問題が発生した場合に損害の軽減や機能の維持、回復や復旧のための対策を講じる事。

例：「メインのデータセンターが自然災害にあった場合を想定し、離れた場所にある別のデータセンターにコピー環境（DR環境、DRサイト）を用意しておき、システムの稼働を継続させる」
従来、物理機器の冗長化や、地理的に離れたデータセンターを保持することは、膨大なコストと時間が必要でした。しかし、AWSでは、DR環境を簡単に構築できるようになっている。

DR(ディザスタリカバリ)におけるAWSの強み

  1. 初期投資を抑えられる
    本来はDRサイト用のデータセンターを準備したり、機器の購入、環境の構築など、膨大なコストと時間が必要になる。
    ただAWSでは、必要なリソースを必要なときに必要なだけ利用できるので、機器の購入も不要で、初期投資を抑えることができます
  2. 設備の維持や運用コストを最小限に抑えられる
    DRサイトは、求められる要件（※後述）によっては、災害時の利用だけでなく、平常時でも定常的に維持費が発生し続けます。AWSでは使用した分のみ課金されるため、平常時のコストを最小限に抑えることができます。
  3. グローバル環境を構築できる
    AWSは、世界中のリージョンを利用できます。また、リージョン内でも、アベイラビリティゾーンの利用によって、互いが影響を受けない環境を構築できます。
  4. マネージドサービスや自動化など、さまざまなサービスが提供されている

DR(ディザスタリカバリ)設計時の主な検討事項

  1. 災害・障害の発生規模　
    発生規模は、特定データセンター、首都圏全体、または日本全体なのかを確認する
    想定される規模によって、DRサイトのロケーションを選定する
  2. データロスの許容範囲
    「RPO（Recovery Point Objective：目標復旧時点）」を定義する
    RPOは、障害発生時に、どの時点まで復旧できるかを表す(例】1時間前に登録したデータを復旧する)
    バックアップの頻度やタイミングを定義する
  3. 障害発生から復旧までの時間　
    「RTO（Recovery Time Objective：目標復旧時間）」を定義する
    RTOは、障害が発生してからシステムが復旧するまでの時間を表す

    事前にバックアップをとっておく！それをAWS内だったら機械かったりせずDR環境を構築できる！

復旧のためのシナリオを定義する。

システムの重要度や求められるRTOにしたがって、復旧のためのシナリオを定義します。
システムの重要度、可用性、コストによって、求められるシナリオが変わってきます。可用性が高い（＝障害で停止する時間が短い）ほどコストがかかりますし、より重要なシステムほど高い可用性が求められます。

【シナリオ例1】バックアップ＆リストア

このシナリオでは、サーバー環境の情報やデータ、アプリケーションをバックアップして、障害発生時にこのバックアップから復旧させます。
復旧時に0から環境構築が必要になるため、復旧までにとても時間がかかる。
たとえば、データベース障害やWebサーバー障害のように、部分的な障害に向くシナリオです。

平常時の構成

  • ディスクのスナップショットやファイルのバックアップを定期的にS3にアップロードする。
  • バックアップの頻度は、事前に定義されたRPO（Recovery Point Objective：目標復旧時点）に基づいて設定する。

障害発生時の対応

  • 他のデータセンターやクラウド環境、または復旧後のオンプレミス環境に、S3からスナップショットやファイルを復元（リストア）する。

ポイント

バックアップには、高い可用性と耐障害性を持つ「Amazon S3」を利用。

  • 堅牢性: S3は99.999999999%（11ナイン）の堅牢性を提供。
  • 柔軟な容量管理: S3は容量無制限で、使用した分だけ課金される。
  • ライフサイクル管理: S3のオブジェクトにはライフサイクルポリシーを設定でき、古いバックアップデータの自動アーカイブや削除が可能。
  • クロスリージョンレプリケーション: S3のデータを複数のリージョンに自動的にレプリケートすることで、災害からの回復力をさらに向上させることができる。
【シナリオ例2】コールドスタンバイ

このシナリオでは、停止状態のサーバーを用意しておき、障害発生時に起ち上げます。
簡単に言うと、『災害や障害が発生した際に、一時的なDRサイト（仮のサイト）を起動してサービスを提供します。その間に元の本番環境の復旧作業を進める。』

平常時の構成例

  • バックアップ: シナリオ1（バックアップ＆リストア）を組み合わせて、必要なデータやサーバー環境を事前にバックアップしておく。
  • AMI作成: 必要なEC2インスタンスのAMI（Amazon Machine Image）を作成し、バックアップとして保持。
  • 自動化ツール準備: AWS CloudFormationなどの自動化ツールを用意し、障害発生時に迅速に環境を再構築できるようにする。

障害発生時の対応

  • AMI(バックアップ保持してる場所)やCloudFormation(自動化ツール)を利用して、DRサイトに環境を構築する
  • データリストアを行う
  • DR環境を最新の状態にし、冗長化やスペックの強化（最適化）を行ったうえでサーバーを起動。
  • 既存のシステム環境からDRサイトへDNSの向き先を変更し、サービスをDRサイトで提供。
  • DRサイトでサービスを提供している間に、元の環境の復旧作業を進める。

ポイント

非常時に正確にDRサイトを構築し稼働できるかを確認するため、定期的な訓練や試験を行う事を推奨。

【シナリオ例3】ホットスタンバイ

災害や障害に備えて、平常時からメインサイトと同じ構成のDRサイトを常時稼働させておくスタイル。
結果、DRサイトの環境構築やデータ復旧の時間を最小限に抑えれる！

平常時の構成例

  • DRサイトはメインサイトと同じ構成で稼働&アプリケーションやデータベースをメインサイトとDRサイト間で常に同期し、最新の状態を維持します。

障害発生時の対応

  • DRサイトのサーバーの性能をアップさせたり、必要なサーバーの数を増やしたりします。
  • DNS設定をDRサイトに変更し、ユーザーのアクセスをDRサイトに誘導します。

ポイント

障害発生時、構成によってはシステムを停止せずに運用を継続できる可能性がある位早い！！
けど勿論コストはかかりやすい！

【シナリオ例4】マルチサイト

このシナリオでは、オンプレミス（自社サーバー）とAWSを組み合わせて冗長化を図ります。平常時から両方の環境を稼働させておき、必要に応じて切り替えることができます。
これは、【シナリオ例3】と同じような構成です。

平常時の構成例

  • メインサイトと同じ規模の構成をDR環境（AWS）に準備しておく。
  • DNSを使って、メインサイトとDRサイトにアクセスを分散させます。

障害発生時の対応

  • DNSサーバーのヘルスチェック機能が働き、障害が検知されると、自動的にDR環境（AWS）へのアクセスに切り替わる。

ポイント

オンプレミスとクラウドを組み合わせることで、障害発生時に自動的にシステムが切り替わり、サービスの継続性が保たれます。

Multi-AZ環境（マルチAZ環境）

Multi-AZ（マルチAZ）環境は、AWSで提供される高可用性と耐障害性を持たせたインフラ設計の一つ！
耐障害性を考慮したAWSでのインフラ構成として、最も一般的！

ポイント

パブリックサブネットは、異なる2つのAZ（ap-northeast-1c、ap-northeast-1d）で構築。
そのサブネット上にはEC2サーバーが構築されており、ALBによって冗長化構成となっています。

「ターゲットグループ」と「ヘルスチェック」

ターゲットグループとヘルスチェックは、ALBや他のタイプのロードバランサーに関連する重要な設定。
これらは、ロードバランサーの動作とシステムの冗長性に直接関係している。

ターゲットグループ

ターゲットグループ

  • ターゲットグループは、ALBがリクエストを送信するEC2インスタンスやIPアドレスなどのバックエンドリソースのグループ。
  • 設定: ターゲットグループは、ALBがリクエストをルーティングする際に、どのプロトコル（HTTPやHTTPSなど）とポート（80や443など）で通信を行うかを設定します。
ヘルスチェック

ヘルスチェック

  • ヘルスチェックは、ターゲットグループ内の各ターゲット（EC2インスタンスなど）が正常に稼働しているかどうかを定期的に確認する役割。
  • 動作: ロードバランサーは、指定されたインターバルでターゲットに対してリクエストを送信し、応答を確認します。正常な応答があれば「healthy」、障害があると「unhealthy」と表示します。
  • 「unhealthy」と判断されたターゲットへのリクエストは一時的に停止され、その後ターゲットが回復すると再びリクエストがルーティングされます。
    ヘルスチェックの結果は、コンソールで確認でき、アラートを設定して通知を受け取ることも可能です。

スティッキーセッション（セッションの維持）

AWSでは、ALBを用いることで、負荷分散や冗長化した構成を簡単に実現できる。
しかし、セッション管理を前提としたシステムでは、セッションの途中で別のEC2インスタンスに振られてしまった場合、セッションを維持できないという問題が起きる！
[例]：ログイン機能付きのアプリケーションでは、アクセスしたユーザがログイン状態かそうではないのか判断できない！

この問題(セッションを維持できない)の解決方法

結論：ALBにて「スティッキーセッション」を設定する！！！！🤲
「セッションが有効な間は同じサーバーにリクエストされる」ように設定（有効）すればよい!

設定方法
  1. EC2ダッシュボードの［ロードバランシング］で［ターゲットグループ］を選択する
  2. 対象のターゲットグループの名前を選択して、詳細ページを開きます。
  3. [Attributes] タブを選択して、[Edit] を選択します。
  4. [Edit target group attributes] ページで、[Stickiness]にチェックを入れ
    Stickiness typeで[Load balancer generated cookie]が選択されているのを確認してから[Save changes]をクリックして設定を保存！
    ※[Stickiness duration]は今回、デフォルトのままでOK！

暗記はできないけどまた読み返そう🤡

Discussion