はじめに
はじめまして。AWSを学習中の学生です。
AWSの基礎学習として、ハンズオンと座学を並行して進める中で、
まずはEC2上でFlaskを使い、RDSに保存したデータを表示するシンプルなWebアプリを作成しました。
しかし、この構成ではインスタンスが停止するとサービスも停止してしまうため、
単一構成のままでは運用するのに適していない、と座学を進める中で感じました。
そこで、ALBとAuto Scalingを導入し、
可用性を考慮した構成に改善しました。
本記事では、その構成と構築の過程で詰まった点をまとめます。
また、本記事で使用したコードは以下のGitHubリポジトリで公開しています。
構成概要
今回の構成は以下の通りです。
- ALBでリクエストを受け取り、複数のEC2に分散
- EC2上でFlaskアプリケーションを実行
- RDSでデータベースを管理
この構成にすることで、EC2単体構成の課題だった
「インスタンス停止時にサービスが停止する問題」を解決しています。
使用サービス
- EC2（Amazon Linux 2023）
- RDS（MySQL）
- ALB（Application Load Balancer）
- Auto Scaling Group
- Security Group
改善前の構成と課題
初めは以下のような構成でアプリケーションを動かしていました。
当初は動作確認を目的としていたため、この構成でも問題なく動作していました。
しかし、AWSの学習を進める中で、このような単一構成では
インスタンスが停止するとサービス全体が停止してしまうことや、
負荷に応じてインスタンス数を増減できないといった課題があると理解しました。
実際の学習の用途では大きな問題になることは少ないものの、
可用性や拡張性の観点では改善の余地がある構成であると考えました。
改善後の構成と設計理由
改善後の構成を再喝します。
この構成では、ALBを追加し、EC2をAuto Scaling Groupで複数台管理する形にしました。
ALBを使ったのは、リクエストを複数のEC2に振り分ける構成を実際に試したかったためです。
また、EC2を複数台にすることで、1台に依存しない構成を作りたいと考えました。
Auto Scaling Groupは、EC2を複数台で管理し、1台停止したときに自動で新しいインスタンスが起動することを確認するために設定しました。
今回は動的なスケーリングよりも、まずは冗長化された構成を試すことを目的として、
Min：1、Desired：2、Max：2 にしています。
実際にEC2を1台停止すると、新しいインスタンスが起動し、
ALB経由でアクセスできる状態が続くことを確認できました。
データベースにはRDS（MySQL）を使用しました。
EC2とは別にデータベースを配置することで、
アプリケーションとデータベースを分けた構成を学べると考えたためです。
通信の流れ
本構成における通信の流れは以下の通りです。
User → ALB → EC2 → RDS
まず、ユーザーがブラウザからアクセスすると、
HTTPリクエストはALBに送られます。
ALBは受け取ったリクエストをターゲットグループに基づいて、
複数あるEC2インスタンスのいずれかに転送します。
EC2ではFlaskアプリケーションを起動しており、
ポート5000でリクエストを受け取ります。
受け取ったリクエストに応じて処理を行い、必要に応じてRDSにアクセスします。
RDSではMySQLを使用しており、
ポート3306で接続します。
アプリケーションからのリクエストに応じてデータの読み書きを行い、
その結果をEC2に返します。
その後、EC2からALBを経由してユーザーにレスポンスが返されます。
セキュリティ設計
今回の構成では、Security Groupを用いて通信を制御しています。
具体的には、以下の通信のみを許可しています。
- ALB → EC2（5000）
- EC2 → RDS（3306）
- SSHは自分のIPからのみ許可
このように設定することで、必要な通信のみを許可し、
それ以外の通信は通らないようにしています。
また、EC2はパブリックサブネットに配置していますが、
Security GroupでALBからの通信のみを許可しているため、
実際にはALBを経由したアクセスのみ受け付ける構成としています。
同様に、RDSについてもEC2からの接続のみを許可しており、
外部から直接接続されないようにしています。
詰まった点・トラブル
構築の過程でいくつか詰まった点がありました。
主にALBとEC2間の通信や設定に関する問題で、意図した通りに動作しない状態がありました。
■ 503エラーが発生した
ALB経由でアクセスした際に、503エラーが返される状態になりました。
原因は、ALBからEC2の5000番ポートへの通信が許可されていなかったことでした。
Security Groupの設定を見直し、ALBからEC2への通信を許可することで解決しました。
■ ターゲットがunhealthyになる
ターゲットグループの状態がunhealthyとなり、リクエストが転送されない状態がありました。
このとき、EC2上でアプリケーションが正しく起動していない、または
0.0.0.0で待ち受けていない状態だと、ヘルスチェックに応答できないことを確認しました。
アプリケーションの起動方法を見直し、
0.0.0.0:5000で待ち受けるように修正することで解決しました。
■ AZ・サブネットの設定ミス
ALBとEC2のサブネットやAZの設定が一致していない状態になっており、
正常に通信できませんでした。
設定を見直し、同じVPC内のサブネットに配置することで通信できるようになりました。
検証内容
構成の動作確認として、EC2インスタンスを1台停止する検証を行いました。
インスタンスの停止
インスタンス停止後
新しいインスタンスが増えましたね
その結果、Auto Scaling Groupによって新しいインスタンスが自動で起動し、
ALB経由のアクセスが継続できることを確認しました。
この検証により、1台のインスタンスに障害が発生した場合でも、
サービスが停止しない構成になっていることを確認できました。
まとめ
EC2単体で動作させていた構成から、
ALBとAuto Scaling Groupを用いた構成に変更することで、
複数台でアプリケーションを動かす構成を試すことができました。
また、ALBを経由した通信や、
Security Groupによるアクセス制御の設定を実際に行うことで、
各サービスの役割や設定の意味を理解することができました。
構築の過程では、ALBとEC2の接続や設定ミスによりエラーが発生することもありましたが、
設定を見直しながら動作を確認することで解決することができました。
今後は、プライベートサブネットの利用や、
NAT Gatewayを用いた構成についても試してみたいと考えています。
本記事の構成は以下のリポジトリで公開しています。