ALBのルーティングを応用してレガシーWEBシステムにモダンなサブシステムを導入する 1. 概要編
Agaroot IT Partners(AITP)のtomoです。
WEB技術の変遷は実に目まぐるしいものです。かつてはEC2インスタンス1台にPHPやJavaの(なんならライブラリやフレームワークを使っていない)アプリを立ち上げることが当たり前でした。しかし今ではアプリの主流はSPAやSSRなどになり、インフラではDockerコンテナやオートスケーリングを導入することがスタンダードで、なんならそれも枯れつつある、といった具合なのではないでしょうか。
といっても昔から所有しているシステムはALBとEC2インスタンス1台構成で出来ていて、その上で動いているアプリは複雑になり過ぎて保守性が著しく低下している中、古参エンジニアを中心に頑張って保守改修を行っている、といったケースも多いかと思います。
そこで既存システムはそのままに、特定のリクエストパスへの応答はECS on Fargate上の新規アプリに転送する仕組みの構築方法を紹介します。
今回の内容も3本程度の複数記事に分けて公開する予定です。この記事ではシステムの概要に触れていきます。
この記事はこのような方におすすめ
- ALBを用いたWEBシステムを担当している方
- 保守性を欠いたレガシーシステムの保守改修に困っている方
- ECS/Fargate/ECRの概要は理解されている方
ECS/Fargate/ECRの概要について触れていくとそれだけで1本記事が書けてしまうので今回は省略させていただきます🙏
概要を知りたい方は下記記事などをご参照ください。
システムの概要
今回はこのようなシステムを作成します。
ALBの転送先にEC2インスタンスが存在するシステムに、ECS on Fargate上のアプリを追加して特定のパスへのリクエストはそちらに転送するようにします。
これによりEC2インスタンス上のアプリなどには一切手を加えず、特定のパスについてはDockerを用いて新規作成した新しいアプリでサービス提供することができます。
また、アーキテクチャ図では省略していますが、S3やKinesisを利用したログの保存も行っています。
ソースコード/構築手順など
https://github.com/aitp-tomo/alb-subsystem
上記GitHubリポジトリにCDKコードや構築手順などを記載しておきました。
また、試しに使えるALBなどによって構成されたシステムなどがない場合には下記記事を参考にALBやEC2などを作成いただければと思います。
https://qiita.com/okubot55/items/844ae5ac5b188435d58b
こんな感じになります
構築が完了した後ALBのDNS名を開くとトップページ(/)では変わらずEC2インスタンスなどの既存システムからレスポンスが返却されますが、サブシステム用のパス(今回は/subsystem)ではECS on Fargate上の新規アプリからレスポンスが返却されます。
そして今回は/subsystem/api/healthcheckというALBのヘルスチェック用のパスを用意していますが、これをブラウザでアクセスしてみると{"result":"OK"}とレスポンスが返却されます。サブシステム用のパスの更にその配下へのリクエストも想定通りECS on Fargate上の新規アプリにルーティングされていることがわかります。
次回から実装の詳しい説明を行います
今回はシステム概要の紹介のみとなりましたが、次回以降から実装の詳細について触れていきます。どうぞご期待ください👋
追記
続きが公開されたので、是非ご一読ください。