ECS Auto Scaling起動中や起動前にて、EFSが利用できない場合の挙動について調査してみた

今回の調査テーマ

こんにちはAWS事業本部コンサルティング部のこーへいです。

今回の調査テーマは「ECS Auto Scaling起動中や起動前にて、EFSが利用できない場合の挙動について」です。

調査を行う背景

上記は「AZ-Aのマウントターゲットが障害等で使用できなくなった際に、AZ-Aに配置されているEC2インスタンスはAZ-Cのマウントターゲットにフェイルオーバーされるのか？」を検証した記事となります。

結論から言うと、タイトルにもあるとおりフェイルオーバーは実現されず何かしらの対策が必要となりました。

今回はEC2ではなく、ECSの場合に以下の点が気になったので検証しブログにまとめるに至りました。

• ECSの場合でも同様にフェイルオーバーしないのか
• ECSタスクの起動中にEFSマウントターゲットが使用できなくなるとどのような挙動になるのか
• ECSタスクの起動前にEFSマウントターゲットが使用できないとどのような挙動になるのか

調査してみる

前提

今回の検証ではEFSに格納するファイルにECSタスクのシステムとしての依存関係がないケースを想定しています。

具体的には「index.html」ファイルはタスク内に格納しており、「index-2.html」ファイルはEFSファイルに格納しています。「index-2.html」ファイルを利用できなくても、タスク自体には特に影響がない状態ですね。

ECSタスクの起動中に、EFSマウントターゲットを落としてみた

まず初めにタスクが起動中の状態でマウントターゲットを削除してみました。

この場合は、タスクの稼働には影響がないものの、EFSは利用できず「index-2.html」ファイルにアクセスできませんでした。

またこの事実はECSにおいても、別AZにてフェイルオーバーがされないことを示唆しています。

マウントターゲットを再作成したところ、再びタスクからEFSのファイルにアクセスすることができました。

同AZに配置されているマウントターゲットを、ECSが内部で自動的に認識してくれるようです。

同様にマウントターゲットを削除した場合ではなく、SGで通信を遮断した場合も遮断中はEFSを利用できず、遮断を解除した段階で再びEFSにアクセスできるようになりました。

EFSマウントターゲットを落とした後で、ECSタスクを起動してみた

次にEFSマウントターゲットを削除した後で、ECSタスクを起動してみましょう。

前提でお話しした通り、EFSに格納しているファイルとタスクに格納しているファイルにシステム的な依存関係はないので、EFSファイルが利用できなくてもタスク自体には影響がない状況です。

結論から言うと、起動に失敗しました。

「ECSタスクの起動中に、EFSマウントターゲットを落としてみた」では、タスク起動中にマウントターゲットを落としてもタスクは稼働し続けましたが、タスク起動前にマウントターゲットが使用できない状態では起動自体が失敗してしまうみたいです。

またオートスケーリングなのでタスクが落ちてしまった場合には再度タスクが起動されます。

ですがAZ-Cにて1台タスクが正常稼働しており、AZ-Aにてマウントターゲットが使用出来ず起動に失敗する状況であれば、オートスケーリングが均等にタスク数を分散しようとAZ-Cにてタスクを起動し続けるため、起動⇄削除の無限ループに入ってしまいます。

ちなみにエラー内容は以下の通りです。

Resourceinitializationerror: failed to invoke EFS utils commands to set up EFS volumes: stderr: Failed to resolve "EFSのDNSホスト名" - check that your file system ID is correct, and ensure that the VPC has an EFS mount target for this file system ID. See https://docs.aws.amazon.com/console/efs/mount-dns-name for more detail. Attempting to lookup mount target ip address using botocore. Failed to import necessary dependency botocore, please install botocore first. : unsuccessful EFS utils command execution; code: 1

エラーについては上記記事にて別途解説しています(マウントターゲットが存在していない場合については省略していますが、ご了承ください)。

まとめ

これらの検証から生じる懸念は、起動中のECSタスクはEFSマウントターゲットが使用できなくても稼働し続けると言う点です。

なので例えばEFSにログ出力を行うような構成の場合、EFSマウントターゲットが復活するまでの間、ログ自体がロストしてしまいます。

その場合の対策として、マウントターゲットが使用できなくなった際に通知で知らせることが一つの案だと思いますが、アマゾン CloudWatch Amazon EFS のメトリクスを確認すると、ClientConnectionsの利用が有効だと思います。

本検証が、どなたかの役に立てば幸いです。