ロードバランサーのリスナールールが消えた悲劇
【状況】
業務のタスクで、「開発側でシステムメンテナンスを行うため、各ドメインに紐づいているロードバランサーをメンテナンスページに自動的に切り替える仕組みを作成してほしい」という要望がありました。各ドメインに紐づいているロードバランサーが15個以上あり、一つずつリスナールールを変更し、メンテナンスページに切り替えるのはかなりの手間です。これを自動化している際に、AWS ALB（Application Load Balancer）のリスナールールが予期せず消失する問題に直面しました。（本番環境ではなかったことが不幸中の幸いでした。。。）
【テストした環境構成】
開発用のAWS環境にて、以下のような構成を試みました：
Application Load Balancer（ALB）: Webトラフィックを複数のバックエンドにルーティングするために使用。リスナールールとメンテナンスページをHTMLコードで作成
AWS Lambda: イベント駆動型のサーバーレスコンピューティング。今回はLambda関数でPythonでリスナールールの切り替えるようの処理を作成
EventBridge: 各種イベントをトリガーとして、異なるサービスを接続。今回はALBのルールをトリガーとしてLambdaを実行。メンテナンスページを時間で切り替えるためにスケジューリングでトリガーが実行できるように設定
【原因】
あらかじめ設定したLBに対し、EventBridgeで作成したトリガーに対し作成したリスナールール関連のLambdaを複数紐づけていた。それに気づかず
も片方のLambdaにはELBのリスナールールのarn(リソースネーム）が削除する処理がPythonで記述されていた。
ALBリスナールールとEventBridgeルールの間の依存関係の扱い方に起因しているのではないかと思われ。そのため、同じEventBridgeルールに複数のLambda関数を紐付けようとすると、ALBリスナールールが上書きされ、その結果リスナールールが消えて頑張って作成したALBに作成したメンテナンスページ用のリスナールールが上書きされました。
【考えられる対策】
別々のEventBridgeルールを作成する
各Lambdaには別々のEventBridgeルールを作成し、そのEventBridgeルールをALBリスナールールに紐付けます。この方法であれば、リスナールールが上書きされることはないみたいです。
ALBリスナールールにLambdaを直接紐付ける
ALBリスナールールにLambdaを直接紐付けることができます。ただし、1つのリスナールールに紐付けられるLambdaは1つだけ。。。。。。。。
AWS CloudFormationやTerraformの活用
設定管理ツールを使ってインフラストラクチャの設定をコード化することで、設定の変更や管理を一元化し、リスナールールの消失を防ぐことができます。特に、Terraformなどを使用して設定を管理すると、設定の競合を防ぎやすくなります。
まだまだ模索しないとですね。。簡易的なものはネットにあるブログ等を参考にすればできるのですが、構成をしっかりと考えてから対応するべきでした。。