CloudFormation で Lambda ベースのカスタムリソースを実装するためのベストプラクティスにはどのようなものがありますか?

所要時間1分
0

AWS CloudFormation で AWS Lambda ベースのカスタムリソースを実装する際には、ベストプラクティスに従いたいと考えています。

解決方法

AWS CloudFormation で AWS Lambda ベースのカスタムリソースを実装する際には、次のベストプラクティスを考慮してください。

障害をレポート、記録、処理するカスタムリソースを構築する

例外が発生すると、関数コードはレスポンスを送信することなく終了する場合があります。CloudFormation では、操作が成功したか失敗したかを確認するために HTTPS レスポンスが必要です。報告されない例外が発生すると、CloudFormation はスタックロールバックを開始する前に操作がタイムアウトするまで待機します。ロールバック中に例外が再発した場合、CloudFormation は再びタイムアウトを待って、ロールバックの失敗で終了します。この間、スタックは使用できません。

タイムアウトの問題を回避するには、Lambda 関数用に作成するコードに次を含めてください。

  • 例外を処理するためのロジック
  • トラブルシューティングシナリオのために失敗を記録する機能
  • 操作が失敗したことを確認する HTTPS レスポンスを CloudFormation に返す機能
  • 不完全な実行をキャプチャして処理できるようにするデッドレターキュー
  • CloudFormation にレスポンスを送信するための cfn-response モジュール

合理的なタイムアウト期間を設定し、それらが超過しそうなときに報告する

オペレーションが定義されたタイムアウト期間内に実行されない場合、関数は例外を発生させ、CloudFormation に応答は送信されません。

この問題を回避するには、次の点を考慮してください。

  • Lambda 関数のタイムアウト値を、処理時間とネットワーク状態の変動に対処するのに十分な大きさに設定します。
  • 関数がタイムアウトしようとしているときにエラーで CloudFormation に応答するには、関数にタイマーを設定します。タイマーは、カスタムリソースの遅延を防ぐのに役立ちます。

Create、Update、Delete イベントを中心に構築する

CloudFormation は、スタックアクションに応じて、関数に CreateUpdate、または Delete イベントを送信します。各イベントは異なる方法で処理されるため、3 つのイベントタイプのいずれかを受信したときに意図しない動作がないことを確認してください。

詳細については、「カスタムリソースのリクエストタイプ」を参照してください。

CloudFormation がリソースを識別し、置き換える方法を理解する

更新によって物理リソースの置き換えが開始されると、CloudFormation は Lambda 関数が返す PhysicalResourceId を以前の PhysicalResourceId と比較します。ID が異なる場合、CloudFormation はリソースが新しい物理リソースに置き換えられたものとみなします。

ただし、ロールバックの可能性を考慮して、古いリソースは暗黙的に削除されません。スタックの更新が正常に完了すると、古い物理 ID を識別子として Delete イベントリクエストが送信されます。スタックの更新が失敗し、ロールバックが発生すると、新しい物理 ID が Delete イベントで送信されます。

PhysicalResourceId を使用してリソースを一意に識別し、Delete イベントを受け取ったときに、置き換え時に正しいリソースのみが削除されるようにします。

冪等性を用いて関数を設計する

冪等関数は同じ入力で数回繰り返すことができ、結果は 1 回だけ実行した場合と同じになります。冪等性により、再試行、更新、ロールバックによって重複したリソースが作成されたり、エラーが発生したりすることがなくなります。

例えば、CloudFormation が関数を呼び出してリソースを作成したが、リソースが正常に作成されたというレスポンスを受け取らなかったとします。CloudFormation は関数を再度呼び出して 2 番目のリソースを作成する可能性があります。その後、最初のリソースは孤立する可能性があります。

ロールバックを正しく処理するようにハンドラーを実装する

スタック操作が失敗した場合、CloudFormation はすべてのリソースをロールバックして以前の状態に戻そうとします。これにより、更新によりリソースの置換が発生したかどうかにより、異なる動作が発生します。

ロールバックが正常に完了するようにするには、次の点を考慮してください。

  • Delete イベントを受信するまで、古いリソースを暗黙的に削除することは避けてください。
  • AWS CloudFormation でカスタムリソースを使用するときにベストプラクティスに従うのに役立つように、GitHub ウェブサイトの accustom または Custom Resource Helper を使用してください。

関連情報

カスタムリソース

AWS公式
AWS公式更新しました 2年前
コメントはありません

関連するコンテンツ