こんにちは。右腕のテニス肘が復旧したら今度は左腕にテニス肘が発現したCTO室のkazです。 タイトルが若干大げさですが、2016年に電力自由化開始してから長らく構成していたシステムの一部にアップデートがあったので記録したいと思います。
概要
ローンチしたばかりの当時から戦略的にENECHANGEサイトと某電力会社試算サイトのドメインを共有していました。 そのため、リバースプロキシサーバを構築し、某電力会社向けのassetsであれば、クエリストリングを用いて経路を分ける力技な運用をしていました。 そうなるとオーバーヘッドもそこそこ大きくて、
- Nginxのリバースプロキシ設定が秘伝のタレ化しており、アプリ開発に影響を及ぼし、Rails開発者やメタコーダーさえも理解しておかなければいけないという社内ルールが存在する
- ELBのスケールに伴うIP変更に対応するため、2秒に1回名前解決するような処理をいれている
- ログが複雑化する
- 障害点が多すぎてインフラ担当者ですら正確にボトルネックを判定するのが難しい
- 怖い...触りたくない...
などなど...。日々、多忙な中、ある意味枯れているところに手を入れるというタスクを積めずに年月だけが過ぎていきました。
旧構成
まぁ、図にしてみたら簡単なんです。
リバースプロキシで下記のようにリクエストを割り振ってました。
- エネチェンジシミュレート
- 某電力会社の電力試算サイト
打ち手
ALBにはURLパスに基づいてリクエストを転送するルールを持つリスナーを作成できるパスベースルーティングと、ホストヘッダーのホスト名に基づいてリクエストをルーティングするホストベースルーティングがありますが、昨年、HTTPヘッダーとメソッド、クエリ文字列、ソース IP アドレスに基づいてルールを定義できるようになり、今までリバースプロキシで制御していた経路をALBだけで完結できるようになったので、これを利用しない手はありません。
新構成
まぁ、図にしてみたら簡単なんです。
設計のポイント
- 某電力会社のアプリケーションはElasticBeanstalkで運用している
- ALBのリスナールールにおいて各ルーティングはALBをターゲットにできないゆえにBeanstalkではALBの作成を抑止し、コスト削減する
- ALBのリスナールールにおいて各ルーティングが指定できるターゲットグループはALBと同一のVPCにある必要がある
- 同一サブネット内では重複してターゲットグループをターゲット指定できない
- PROD以外の環境のインスタンスの起動・停止は時間制御することでコスト削減を図る
- Railsのasset_hostというconfigを使用する
- xxxx.enechange.jp等で静的アセットを配信できる
以下はALBのリスナールールです。
Forward action
resource "aws_lb_listener_rule" "host_based_routing" { listener_arn = aws_lb_listener.front_end.arn priority = 99 action { type = "forward" target_group_arn = aws_lb_target_group.static.arn } condition { host_header { values = ["my-service.*.terraform.io"] } } }
query_string action
resource "aws_lb_listener_rule" "query_string_routing" { listener_arn = aws_lb_listener.front_end.arn action { type = "forward" condition { query_string { key = "health" value = "check" } query_string { value = "bar" } } }
Redirect action
resource "aws_lb_listener_rule" "path_pattern_routing" { listener_arn = aws_lb_listener.front_end.arn action { type = "redirect" redirect { port = "443" protocol = "HTTPS" status_code = "HTTP_301" } } condition { field = "path-pattern" values = ["/hoge/hogehoge/*"] } }
構成変更後
ALBにおいてRuleEvaluations、ActiveConnectionCountは増加してますが、ProcessedBytes、ConsumedLCUs、TargetResponseTimeが減少しました。
通信経路が減ったので体感でサイトの表示も早くなりました。