ロードバランサーのリスナールールが消えた悲劇のその後

前回の問題の概要

先日、私はロードバランサーのリスナールールが予期せず消失するという問題に直面しました。具体的には、業務のタスクで「各ドメインに紐づいているロードバランサーをメンテナンスページに自動的に切り替える仕組みを作成してほしい」という要望を受け、AWS環境での自動化を試みた際のことです。ALB（Application Load Balancer）のリスナールールが消えてしまい、せっかく作成したメンテナンスページへのルールがすべて無効になってしまったのです。

この問題に直面した際の詳細はこちらでご覧いただけます。

問題解決に向けた取り組み

ターゲットグループの設定

今回の問題解決には、ターゲットグループの設定が重要な役割を果たしました。ターゲットグループとは、ロードバランサーがリクエストをルーティングするバックエンドサーバーの集合体です。このターゲットグループを適切に設定することで、リスナールールの上書きや削除を防ぐことができるようになりました。

具体的には、以下の対策を講じました。

1. 別々のターゲットグループを作成:
   メンテナンスページ用のターゲットグループを新たに作成し、通常のトラフィックを処理するターゲットグループとは別に管理しました。これにより、メンテナンスページに切り替える際にリスナールールを変更するのではなく、ターゲットグループを切り替えるだけで済むようにしました。

2. ターゲットグループのステータスチェック:
   ターゲットグループにはヘルスチェックの設定を行い、メンテナンスページ用のターゲットグループが正常に稼働しているかを常にモニタリングできるようにしました。これにより、ターゲットグループが正常に動作していない場合でも、自動的にトラフィックを通常のバックエンドに戻すことが可能となりました。

別々のEventBridgeルールを作成

問題の原因は、同じEventBridgeルールに複数のLambda関数を紐付けることで、リスナールールが上書きされてしまったことにありました。これに対処するため、各Lambda関数には別々のEventBridgeルールを作成し、それらをそれぞれのALBリスナールールに紐付けるようにしました。この方法で、リスナールールの上書きを防ぐことができます。

ALBリスナールールにLambdaを直接紐付け

もう一つの対策として、ALBのリスナールールに直接Lambda関数を紐付ける方法を試みました。ただし、1つのリスナールールに対して紐付けられるLambdaは1つだけであるため、複数のLambdaを使用する場合は、ALBのリスナールール自体を増やす必要がありました。これにより、ルールが消失するリスクを減らすことができました。

効果と反省

これらの対策を講じた結果、同じ問題が再発することはなくなりました。別々のEventBridgeルールを用いることでリスナールールの上書きを防ぎ、ALBに直接Lambdaを紐付けることで管理を簡素化しました。さらに、ターゲットグループを別々に管理することで、メンテナンスページへの切り替えも容易になり、リスナールールが消失するリスクを大幅に軽減しました。

しかし、今回の問題は、事前に適切な設計を行わなかったことに起因しています。ネットにある簡易的な設定例を参考にしただけでは、実際の業務環境に適用するには不十分であることを痛感しました。今後は、構成をしっかりと考えてから実装に移ることが重要だと学びました。

その後の学びと今後の展望

この経験を通じて、インフラの自動化には慎重さと確実な設計が必要であることを学びました。特に、異なるサービス間の依存関係を正しく理解し、それに基づいた設計を行うことが、トラブルを未然に防ぐ鍵となります。今回の対策で得られた知見を活かし、さらに安定したシステム構築を目指していきます。