2017-12-24 8 views
3

クラウドフォーメーションを使用してVPCでラムダを作成しました。スタック全体を削除しようとすると、40〜45分かかることがあります。VPC削除時のラムダに時間がかかります

私Iamの役割は、次の権限を持っている:

Action:        
      - ec2:DescribeInstances 
      - ec2:CreateNetworkInterface 
      - ec2:AttachNetworkInterface 
      - ec2:DescribeNetworkInterfaces 
      - ec2:DeleteNetworkInterface 
      - ec2:DetachNetworkInterface 
      - ec2:ModifyNetworkInterfaceAttribute 
      - ec2:ResetNetworkInterfaceAttribute 
      - autoscaling:CompleteLifecycleAction 
      - iam:CreateRole 
      - iam:CreatePolicy 
      - iam:AttachRolePolicy 
      - iam:PassRole 
      - lambda:GetFunction 
      - lambda:ListFunctions 
      - lambda:CreateFunction 
      - lambda:DeleteFunction 
      - lambda:InvokeFunction 
      - lambda:GetFunctionConfiguration 
      - lambda:UpdateFunctionConfiguration 
      - lambda:UpdateFunctionCode 
      - lambda:CreateAlias 
      - lambda:UpdateAlias 
      - lambda:GetAlias 
      - lambda:ListAliases 
      - lambda:ListVersionsByFunction 
      - logs:FilterLogEvents 
      - cloudwatch:GetMetricStatistics 

スタックの削除時間を改善するためにどのように?

+1

サブネットが削除されるまで、VPCを削除することはできません。ラムダがすべてのコンテナを終了し、ENIが要求したENIを解放するまで、VPCは削除できません。ホールドアップの原因であると思われるENIを削除しないと、コンソールで手作業で削除して、役立つかどうか試してみる可能性があります。プロセスを早くすることはできません。 ..誰か他の考えがあるかどうかを見てみましょう。 –

+0

こんにちはMichael、問題はVPCの削除ではなく、カスタムVPCに展開されたラムダの削除です。 これは保持しているエラーです** CloudFormationは、ラムダ関数に関連付けられたNetworkInterfacesがクリーンアップされるのを待っています** ** 45分後、スタック全体が削除されていますが、すぐにそれをラップするか、この遅延が予想されますか? –

答えて

4

ラムダ機能がVPC内で実行されると、エラスティックネットワークインターフェイス(ENI)が作成され、ネットワークにアクセスできるようになります。 ENIは仮想NICと考えることができます。 MACアドレスと少なくとも1つのプライベートIPアドレスを持ち、VPCネットワークに接続し、VPC内部のIPアドレス(EC2インスタンス、RDSインスタンス、ELB、ALB、NLB、EFSなど)を持つリソースには、等。)。

明らかに文書化されていないようですが、Lambdaで使用されるこれらのインタフェースは、1:1でコンテナ(スペキュレーション)にマッピングされているようです。 Lambdaは、後続の呼び出し(投機ではなく)で再利用する必要があり、コンテナがすぐに破棄されることはなく、関連付けられたENI(投機)もないので、関数の実行直後にコンテナをシャットダウンしません。いずれにしても、遅れは文書化されています。

ラムダ関数が実行されてからENIが削除されるまでに遅延があります。

http://docs.aws.amazon.com/lambda/latest/dg/vpc.html

我々はラムダインフラの優先順位は、必要に応じて利用可能なリソースを作成し、迅速なアクセス性能上の理由のために利用できるそれらを保つことに集中するべきであると考えるとき、これは、理にかなっている - ので、再び物事を切断サービスがバックグラウンドで関与する第二の配慮。

要するに、この遅延は正常であり、予想されます。

おそらく、CloudFormationはこれらのインターフェイスを識別するためにタグを使用していますが、これらのインターフェイスを区別する方法は簡単にはわかりません。

ENIは、Network InterfacesのEC2コンソールの左ペインのペインに表示されますので、これらを自分で削除して処理を進めることができます...しかし、システムが許可していると仮定すると、慎重に注意してください.Lambdaがその後に使用しようとするコンテナに接続されているENIを削除すると、Lambdaはインターフェイスが失われていることを知らず、Lambdaが破壊するまで少なくとも関数がタイムアウトするか、コンテナ

+0

マイケルの更新をありがとうございます。この遅れが予想されるので、ここで何もできません。ただし、ENIの削除は手動で削除して、クラウド形成スタックを再度実行するときに作成するようにしても構いませんか?その時、新しいENIを作りますか? –

+0

ありがとうございます。この回答は非常に役に立ちます。 – matthewcummings516

関連する問題