QUESTION

ある会社は、改修できない業務アプリケーションを 1 台の Amazon EC2 インスタンスで運用しています。このアプリケーションは複数台に分散して動かすことができません。会社は、インスタンスやその基盤に障害が起きたときに、人手を介さず同じ構成のインスタンスへ置き換わる耐障害性を確保する必要があります。 これらの要件を満たすソリューションはどれですか。

1 / 1
回答を選択してください
正解B

解説

分散できない 1 台構成のアプリケーションを、障害時に自動で置き換える

  • 1改修できない業務アプリケーションを 1 台の Amazon EC2 インスタンスで運用していますアプリケーションの作りは、変えられません。台の外側の仕組みで復旧を用意することになるので、アプリケーション側の改修を前提にする案は取れません。
  • 2人手を介さず同じ構成のインスタンスへ置き換わる耐障害性を確保する必要があります検知や材料の準備までではなく、起動して戻すところまでが自動である必要があります。通知で終わる案もスナップショットを取るだけの案も、戻す操作が担当者に残ります
A不正解

CloudWatch アラームで運用チームへ通知

インスタンスの状態は Amazon CloudWatch のアラームで監視でき、異常を検知したその場で運用チームへ知らせられます。気づくまでの時間は確実に短くなります。

この案のアラームが行うのは通知までで、新しいインスタンスを起動して同じ構成に戻す操作は担当者が行うことになります。気づくまでの時間は短くなっても、人手を介さずという要件を満たしません。

B正解

容量をすべて 1 にした Auto Scaling グループ

Auto Scaling グループは、指定された希望容量を保つように台数を調整し続けます。EC2 のステータスチェックで異常と判定された台は、終了させて新しい台に置き換えます。すべてを 1 にしておくと増えも減りもしない一方で、障害で異常になった台や失われた台の代わりに、起動テンプレート(起動する台の構成をまとめた設定)から同じ構成の 1 台が自動で起動します

分散して動かせないアプリケーションでも、台数を 1 に固定したまま置き換えだけを任せられ、担当者の操作は要りません。

C不正解

Data Lifecycle Manager の毎時スナップショット

Amazon Data Lifecycle Manager はスナップショットの取得と保持を自動で回せるので、直前の状態へ戻す材料は常に用意されます。復旧に使える材料をそろえるという点では十分です。

自動なのは取得までで、障害が起きたあとにボリュームを作り、インスタンスを起動して接続先を戻す操作は担当者が行います。復旧の材料はそろっても、置き換えそのものは自動になりません。

D不正解

インスタンスの終了保護

終了保護を有効にすると、誤った操作でインスタンスが終了されることを防げます。1 台しかない構成では、取り違えてインスタンスを終了させてしまう事故を防ぐ備えとして意味があります。

防げるのは終了の操作だけで、インスタンスや基盤そのものに障害が起きて使えなくなる場面には効きません。そのときに、代わりのインスタンスが起動するわけでもありません。

ポイント

「1 台でしか動かない」「分散できない」と書かれていても、台数を保つ仕組みそのものは使えます
Auto Scaling グループの最小容量・最大容量・希望容量をすべて 1 にする: 増減はしないまま、インスタンスが異常と判定されたときや失われたときだけ起動テンプレートから同じ構成の 1 台が自動で起動します。
分散できないアプリケーションでも、置き換えだけを自動化できます。
アラームによる通知: 気づくまでの時間は短くなりますが、通知だけでは起動して戻す操作が人手に残ります。アラームのアクションでインスタンスを自動で復旧させることもできますが、対象は基盤側の障害(システムステータスチェックの失敗)だけで、同じ構成の新しいインスタンスへ置き換える仕組みではありません。
スナップショットの自動取得: 戻す材料は用意できますが、復元と起動の操作は残ります。
終了保護: 防ぐのは誤った終了の操作で、基盤の障害には効きません。
選択肢を並べたら、検知・材料の準備・置き換えのどこまでが自動かを 1 つずつ見分けます。要件が「人手を介さず」なら、置き換えまで受け持つものだけが残ります。