はじめに
個人開発中のRailsアプリ「TaskLink」の本番環境に、AWS Application Load Balancer（ALB）を導入しました。
これまでは、
Internet
↓
EC2
↓
Nginx
↓
Puma
↓
Rails
というシンプルな構成でした。
動作自体は問題ありませんでしたが、
- HTTPS化の準備
- 将来的なAuto Scaling対応
- 本番環境らしい構成への改善
を目的としてALBを導入しました。
システム構成
導入前
Internet
↓
EC2
↓
Nginx
↓
Puma
↓
Rails
導入後
Internet
↓
Application Load Balancer
↓
EC2
↓
Nginx
↓
Puma
↓
Rails
ALBを挟むことで、インターネットからのアクセスをロードバランサー経由でEC2へルーティングする構成に変更しました。
Target Group作成
ALBからRailsアプリへリクエストを転送するため、Target Groupを作成しました。
設定内容は以下です。
| 項目 | 設定値 |
|---|---|
| Target Type | Instance |
| Protocol | HTTP |
| Port | 3000 |
| Health Check Path | / |
| Success Codes | 200-399 |
EC2をターゲット登録
Railsアプリが稼働しているEC2インスタンスをTarget Groupへ登録しました。
EC2 Instance
↓
Target Group
↓
Registered
ハマったポイント① ヘルスチェック失敗
初回構築時はTargetが
Unhealthy
Request timed out
となりました。
原因を調査するためEC2へSSH接続し、
curl -I http://127.0.0.1:3000
を実行しました。
結果は
HTTP/1.1 302 Found
でした。
Railsアプリ自体は正常に起動していました。
ハマったポイント② セキュリティグループ設定
ALBのセキュリティグループがデフォルト設定になっており、
ALB → EC2
の通信が許可されていませんでした。
以下のルールを追加しました。
| タイプ | ポート | ソース |
|---|---|---|
| HTTP | 80 | 0.0.0.0/0 |
また、EC2側では3000番ポートを許可しました。
ヘルスチェック成功
設定反映後、Target Groupの状態が
Healthy
になりました。
Internet
↓
ALB
↓
EC2
↓
Rails
の通信が正常に行われていることを確認できました。
動作確認
ALBのDNS名へアクセスし、
http://xxxxx.ap-northeast-1.elb.amazonaws.com
Railsのログイン画面が表示されることを確認しました。
導入効果
ALB導入により、
- HTTPS化の準備完了
- 将来的なAuto Scaling対応
- 負荷分散構成への拡張性確保
- 本番運用を意識したインフラ構成
を実現できました。
今後の改善
今後は以下を進める予定です。
- AWS Certificate Manager（ACM）によるHTTPS化
- HTTP→HTTPSリダイレクト
- CloudWatchによるALB 5xx監視
- Auto Scaling Group導入
まとめ
今回ALBを導入したことで、Railsアプリを単一EC2構成からより本番運用を意識した構成へ改善できました。
特にTarget Groupのヘルスチェックやセキュリティグループ設定は実際に手を動かして学ぶことが多く、AWSのネットワーク周りへの理解が深まる良い経験になりました。
次は ACM を利用したHTTPS化に挑戦し、より実践的なインフラ構成を目指したいと思います。