助け合いフォーラム

AWS

AWS ソリューションアーキテクト - アソシエイト(SAA-C03)
問題ID : 30678
問題を開く
ある会社はオンプレミスでWebアプリケーションを運用している。同社はデータセンターの自然災害時の影響を考慮して、AWSを利用した災害復旧(DR:Disaster Recovery)を計画している。災害発生時にAWSのバックアップ環境でサービスを継続するために、オンプレミスで利用しているデータとAWSのバックアップデータを統一したい。なお、オンプレミスからAWSへのフェイルオーバーはAmazon Route 53のフェイルオーバールーティングポリシーを利用する。
どのようなソリューションの組み合わせが、もっともダウンタイム(障害によりアクセスできない時間)を少なくできるか。(2つ選択)

正解

ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する

AWS Storage Gatewayのボリュームゲートウェイ(ストアドボリューム)を設定する

解説

通常時はオンプレミスでWebアプリケーションを運用し、災害発生時にAWSのバックアップ環境でサービスを継続するには、AWSでフェイルオーバー先のサーバーの構築とバックアップデータの保管が必要です。

まず、フェイルオーバー先のサーバーの構築について考えます。
選択肢の
・ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する
・障害発生時にAWS CloudFormationテンプレートを実行して、ALBとEC2インスタンスを作成する
は、ともにフェイルオーバー後にALB配下のEC2インスタンスでサービスを継続できます。
サーバーが利用可能になるまでの時間を比較すると、前者は作成済みのインスタンスを起動するだけなのに対し、後者はALBとインスタンスの作成時間がかかります。設問の要件に「もっともダウンタイムを少なく」とあるので「ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する」方が適切です。

次に、バックアップデータの保管について考えます。
AWS Storage Gatewayは、オンプレミスからAWSのストレージサービスへのアクセスを高速かつセキュアに行うことができるサービスです。AWS Storage Gatewayのボリュームゲートウェイには「キャッシュ型」と「保管型」があります。

・キャッシュ型(キャッシュボリューム)
キャッシュストレージをオンプレミス(ローカル)に設置することで、高速アクセスが可能な堅牢性の高いストレージを利用することができます。オンプレミスのキャッシュストレージには頻繁にアクセスするデータのみを保持し、アクセス頻度の低いデータはS3へ保存することで、階層化されたストレージを実現します。


・保管型(ストアドボリューム)
オンプレミスのボリュームストレージに全てのデータを保持します。キャッシュ型とは異なり、全てのデータに対して高速アクセスが可能です。
ボリュームストレージ上のデータは任意のタイミングでS3にスナップショットとして保存されますので、災害対策や定期的なバックアップとして利用できます。


設問の要件に「オンプレミスで利用しているデータとAWSのバックアップデータを統一」とあるので、災害復旧のバックアップに適した「保管型(ストアドボリューム)」を設定します。

したがって正解は
・ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する
・AWS Storage Gatewayのボリュームゲートウェイ(ストアドボリューム)を設定する
です。

その他の選択肢については、以下のとおりです。

・障害発生時にAWS CloudFormationテンプレートを実行して、ALBとEC2インスタンスを作成する
前述のとおり「もっともダウンタイムを少なく」するには「ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する」方が適切なので、誤りです。

・AWS Storage Gatewayのボリュームゲートウェイ(キャッシュボリューム)を設定する
前述のとおり「オンプレミスで利用しているデータとAWSのバックアップデータを統一」するには「ストアドボリューム」の方が適切なので、誤りです。

・AWS Direct Connectでバックアップ環境のVPCとオンプレミスをセキュアに接続する
オンプレミスからAWSへのフェイルオーバーにDirect Connectは必要ないので、誤りです。

参考

【AWS Storage Gateway】
AWS Storage Gatewayは、オンプレミスからAWSのストレージサービスへのアクセスを高速かつセキュアに行うことができるサービスです。堅牢性・耐久性に優れたS3をファイル共有ストレージとして利用したり、災害対策を目的としたバックアップやアーカイブを行ったり、あまりアクセスされないデータを自社サーバーからAWSへ移動させるなど、様々なケースで利用できます。

Storage GatewayそのものはAmazon S3やAmazon FSxなどのようなストレージサービスではありません。Gateway(規格の異なるネットワーク間を中継して接続する機器)の名が示す通り、オンプレミスとAWSストレージサービスとを橋渡しする役目を持つサービスです。ユーザーはStorage Gatewayを利用することによって、オンプレミスからS3やFSxなどのストレージサービスをデータ保存先として利用できます。

Storage Gatewayには、使用するプロトコルが異なる複数のゲートウェイタイプが用意されています。


■ファイルゲートウェイ
オンプレミスからNFS(Network File System)またはSMB(Server Message Block)を使用してAWSストレージへアクセスできるサービスです。NFSとSMBは、どちらもサーバーなどへ保存されたファイルを複数のクライアントで共有するためのネットワークプロトコル(通信手順)です。NFSは主にLinuxを含むUNIX系OSに使用されており、SMBは主にWindows系OSに使用されています。
ファイルゲートウェイには、使用するAWSストレージによって2つの種類があります。

〇S3ファイルゲートウェイ
オンプレミスからNFSまたはSMBを使用して、S3バケットへアクセスできるようにするゲートウェイタイプです。ローカル(オンプレミス)にキャッシュストレージを持つため低レイテンシでのアクセスも可能です。


〇FSxファイルゲートウェイ
オンプレミスからSMBを使用して、FSx for Windows File Serverへアクセスできるようにするゲートウェイタイプです。S3ファイルゲートウェイと同じく、ローカルにキャッシュストレージを持つため低レイテンシでのアクセスも可能です。


■ボリュームゲートウェイ
オンプレミスからiSCSI(Internet Small Computer System Interface)を使用して、S3をブロックストレージボリュームとして利用できるサービスです。iSCSIとはコンピュータのストレージを接続するSCSIをTCP/IPで実現したプロトコルのことで、サーバーはiSCSIで接続されたストレージ(Storage Gatewayの場合はS3)をローカルディスクとして利用できます。
ボリュームストレージ上のデータはS3にEBSスナップショットとして保存可能なので、災害対策や定期的なバックアップに利用できます。
ボリュームゲートウェイには2つの種類があります。

〇キャッシュ型(キャッシュボリューム)
すべてのデータをS3に保存し、高頻度アクセスのデータのみオンプレミスのキャッシュストレージにコピーします。データがキャッシュ上に存在しない場合はS3へアクセスするので遅延が発生しますが、オンプレミスのストレージ容量を抑えることができます。


〇保管型(ストアドボリューム)
すべてのデータをオンプレミスのボリュームストレージに保存し、S3に非同期でバックアップを保存します。キャッシュ型とは異なり全データへのアクセス先がオンプレミスになるので、S3へのアクセスによる遅延が発生しません。


■テープゲートウェイ
オンプレミスから物理テープストレージの代替として利用できるサービスです。VTL(Virtual Tape Library:仮想テープライブラリ)に対応したソフトウェアを介して、S3やS3 Glacierにバックアップデータを保存できます。
テープ(テープストレージ)とは磁気テープを用いたストレージです。大容量で安価、かつ長期的なデータ保存に向いているため、アーカイブやバックアップ用途として利用されます。
テープゲートウェイを利用することにより、オンプレミスで新規に物理テープを用意したりテープの切り替えを行うなど、テープの操作や管理が不要になります。また、アーカイブ先としてS3 Glacierとも連携しているため、よりコストを削減できます。

上に戻る

「AWS Direct Connectでバックアップ環境のVPCとオンプレミスをセキュアに接続する」のほうが・・・

公開日 2024/03/30

こちら、オンプレがメインで、AWSがバックアップ先。
障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。
さらに、問題文でも
「もっともダウンタイム(障害によりアクセスできない時間)を少なくできるか。」
とあるので、EC2は起動している状態でなければならないと判断しました。
そのため、
「AWS Direct Connectでバックアップ環境のVPCとオンプレミスをセキュアに接続する」
を正解と考えましたが、いかがでしょうか?

2024/04/01 11:28

障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。

たしかに、社内システムなどの切り替えはDirect Connectで繋ぐのが一般的な構成だと思います。

設問のシステムは「ある会社はオンプレミスでWebアプリケーションを運用している。」なので、Webアプリケーション=インターネット(外部)からのアクセスがあるシステムです。
なので、今回切り替え対象となるWebアプリケーションは、社内からプライベートでアクセスされるものではなく、インターネットからパブリックにアクセスされるものなので、Direct Connectを使用しません。

EC2は起動している状態でなければならないと判断しました。

起動しっぱなしが一番切り替えが速いというのも分かるのですが、EC2の状態の選択肢は
・ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する
・障害発生時にAWS CloudFormationテンプレートを実行して、ALBとEC2インスタンスを作成する
しかないので、作成して停止しておく方が速いという考え方になると思います。(障害時しか使用しないのに、ずっと起動し続けるのも結構料金がかかりますし、EC2の起動は数分以内に完了するので)


コメント

J Jun101

2024/04/01 19:02

「WEBアプリ=インターネット」と読み取らないといけないのがちょっと無理がある問題ですね。問題作成者の意図を読んで正解を導けって感じの問題ですね。

b birdpixy

2024/04/01 23:57

うーん、たとえ社内で使用するWebアプリケーションであっても、Web=HTTP(S)接続が基本なので、専用回線の要件がなければDX経由で接続する必要はないと思いますけど…… ちなみに > EC2は起動している状態でなければならないと判断しました。 > そのため、 >「AWS Direct Connectでバックアップ環境のVPCとオンプレミスをセキュアに接続する」 >を正解と考えましたが、いかがでしょうか? DXでバックアップ環境のVPCとオンプレミスをセキュアに接続していることと、EC2が起動している状態であることは関係ないように思えますが、どのように結びつきましたか?

この返信に対して
コメントを記入できます

2024/04/02 22:28

設問からは

同社はデータセンターの自然災害時の影響を考慮して、AWSを利用した災害復旧(DR:Disaster Recovery)を計画している。

のですから、仮にデータ同期やオンプレミスのシステム停止時切り替えのためにDirectConnectで接続していたとしても、そもそもデータセンターが自然災害により使用不可能な(DirectConnectエンドポイントが機能しない)状態を想定しているので

障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。

だと、「どこのエンドポイントからAWSのバックアップ環境にDirectConnect接続するの?」って観点が不足しているのではないかなと思います。


コメント

この返信に対して
コメントを記入できます

この投稿に対して返信しませんか?