DOP弾力性に優れたクラウドソリューション
ある企業は、Auto Scalingグループで管理されている多数のEC2インスタンスを使用してWebアプリケーションを運用しています。スケールインが発生してインスタンスが終了する際、内部に保持されている一時的なアクセスログを安全にS3バケットへ退避させる必要があります。ダウンタイムやデータ損失を防ぎつつ、完全に自動化されたスケーリングサイクルを構築するために最適なアーキテクチャはどれですか。
AAuto Scalingのライフサイクルフックを設定して終了待機状態にし、EventBridgeでLambdaをトリガーしてログ退避後に終了プロセスを再開する
✓ 正解
ライフサイクルフックにより、インスタンスが終了する前に一定時間待機状態に保つことが可能です。この間にEventBridgeとLambdaを連携してログ退避などのカスタムアクションを自動実行し、完了後に終了を再開できるため、要件を完全に満たす最適な自動化構成となります。
BEC2インスタンスのユーザーデータにシャットダウンスクリプトを追加し、インスタンス終了時にログをS3へ同期するコマンドを自動的に実行させる
ユーザーデータはインスタンスの初回起動時にのみ実行されるスクリプトであり、終了プロセス中に実行されることはありません。したがって、インスタンスがシャットダウンされる際のログ退避アクションをトリガーする目的では使用できず、要件を満たさない不適切なアーキテクチャとなります。
CCloudWatch Logsエージェントを使用して、インスタンス終了イベントを検知した際にS3バケットへのエクスポートタスクを即座に実行する
CloudWatch Logsへのログ転送自体は可能ですが、終了イベントを起点としてS3エクスポートタスクを即座に自動実行するネイティブな統合機能はありません。また、終了プロセス自体を一時停止する仕組みが含まれていないため、退避前にインスタンスが終了してしまうリスクがあります。
DAuto Scalingの終了ポリシーをカスタム設定し、終了プロセス開始前にSNS経由で管理者に通知を送信して手動で退避が完了するまで待機する
SNSトピックへの通知を利用すること自体は可能ですが、運用管理者の手動介入を必要とする設計はDevOpsにおける自動化のベストプラクティスに完全に反します。動的にスケールするクラウド環境において運用負荷が著しく増大するため、プロフェッショナルレベルの設計として不適切です。
解説
Auto Scalingグループにおけるインスタンスの終了プロセス中に特定のカスタムアクション（ログの退避など）を確実に実行するためには、ライフサイクルフック機能を利用するのが最も適切です。ライフサイクルフックを設定すると、インスタンスは終了前に「Terminating:Wait」という待機状態に移行します。この間にEventBridgeを利用してLambda関数やSystems Manager Automationをトリガーし、ログの退避処理を自動実行させることができます。処理完了後にCompleteLifecycleAction APIを呼び出すことで待機状態を解除し、インスタンスの終了プロセスを安全に続行できます。これにより、データの消失を防ぎつつ、DevOpsのベストプラクティスである自動化を維持できます。
選択肢BのユーザーデータシャットダウンスクリプトはOSのシャットダウンシグナルに依存するため、Auto Scalingがインスタンスを強制終了するまでの猶予時間内にスクリプトが必ず完了する保証がなく、ログ退避が中断されるリスクがあります。
選択肢CのCloudWatch LogsエージェントによるS3エクスポートは非同期タスクであり、完了まで数時間かかる場合があります。インスタンス終了直前にトリガーしても退避完了を待機する仕組みがなく、データ損失を防ぐ要件を満たせません。
選択肢DのSNS通知＋手動退避の待機は、管理者の手動操作が必要となるため「完全に自動化されたスケーリングサイクル」という要件に反し、担当者が不在の場合はデータ損失のリスクが高まります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →