AWSにDjangoの環境を整えていく03(ALB)

こんにちは。
株式会社クラスアクト インフラストラクチャ事業部の大塚です。

今回は前回作成したEC2+RDSにALBを追加していき、EC2に負荷分散的なことをしていきたいと思います。

他の記事は以下の記事で別途管理しております為、適宜ご覧ください。

環境イメージ

前回構築した環境にpublic-subnetをもう1つ作成し、そこにDjangoをインストールしたEC2を1つ用意します。このEC2はRDSに繋げています。
このあと、ALB(Application Load Balancer)をデプロイします。
最後にALBをターゲットにして、Webブラウジングが出来るかを確認していきたいと思います。

構築

subnetを1つ作成する

public subnetを1つデプロイします。

• VPC
  • vpc：classact-vpc
• サブネットの設定
  • サブネット名：classact-public-subnet03
  • AZ：ap-northeast-1c
  • CIDR：192.168.3.0/24
    
    作成されたことを確認します。
    

EC2のデプロイと環境構築及びRDSとの紐づけ

EC2をデプロイします。デプロイ先のsubnetは上記で作成したものです。
後は前デプロイした状態と同じです。
名前：classact-ec2-django-other01
サブネット：classact-public-subnet03

デプロイが出来たら今度はRDSの管理画面に移動してEC2と紐づけをしていきます。
Djangoで使用しているRDSを選択し、EC2接続のセットアップを押下します。

上記でデプロイしたインスタンスを選択します。

確認して次に進みます。

RDSの欄の1つである接続されたコンピューティングリソースにEC2インスタンスが追加されていることを確認します。

EC2の設定を入れ込んでいきます。各コマンドの内容は省略します。
DB周りの設定は以前設定済みですので、今回は実行しません。settings.pyの中身も前回のと同様です。
※本当であればAMIを作ってデプロイしたほうが良いのかなぁ・・・とは思います。

root@ip-192-168-3-183:~# apt update && apt upgrade -y 
root@ip-192-168-3-183:~# python3 -V
Python 3.10.12
root@ip-192-168-3-183:~# apt install python3-pip -y
root@ip-192-168-3-183:~# pip3 -V
pip 22.0.2 from /usr/lib/python3/dist-packages/pip (python 3.10)
root@ip-192-168-3-183:~# apt install python3-dev default-libmysqlclient-dev pkg-config mysql-client -y
root@ip-192-168-3-183:~# pip3 install django mysqlclient
root@ip-192-168-3-183:~# django-admin startproject classactPJ
root@ip-192-168-3-183:~# ls
classactPJ  snap
root@ip-192-168-3-183:~# cd classactPJ/
root@ip-192-168-3-183:~/classactPJ# ls
classactPJ  manage.py
root@ip-192-168-3-183:~/classactPJ# cd classactPJ/
root@ip-192-168-3-183:~/classactPJ/classactPJ# ls
__init__.py  asgi.py  settings.py  urls.py  wsgi.py
root@ip-192-168-3-183:~/classactPJ/classactPJ# vi settings.py 
root@ip-192-168-3-183:~/classactPJ/classactPJ# cd ..
root@ip-192-168-3-183:~/classactPJ# python3 manage.py runserver 0.0.0.0:80
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
April 16, 2024 - 20:22:06
Django version 5.0.4, using settings 'classactPJ.settings'
Starting development server at http://0.0.0.0:80/
Quit the server with CONTROL-C.

ALBのターゲットグループを作成する

EC2の管理画面の左タブにターゲットグループがありますので押下します。
デフォルトだと何も表示されてないと思います。作成していきます。

以下の設定を入れます。ヘルスチェックはデフォルトでいったん進めます。

• 基本的な設定
  • ターゲットタイプの選択：インスタンス
  • ターゲットグループ名：classact-tg-django
  • プロトコル：HTTP
  • IPアドレスタイプ：IPv4
  • VPC：classact-vpc
  • プロトコルバージョン：HTTP1

以下の画面が表示されます。
使用可能なインスタンスの欄に今までにデプロイしたEC2が2つ表示されていると思います。
それぞれにチェックを入れて、画面中央付近にある"保留中に以下を含める"を押下します。

画面下にあるターゲットを確認欄にEC2が表示されると思います。
このまま次に進みます。

ターゲットグループが作成されていることを確認します。

ALBをデプロイして接続テストをする（一部失敗アリ）

EC2管理画面の左にロードバランサータブを押下します。
ロードバランサーの作成を押下します。

ロードバランサーのタイプを聞かれます。今回はALBを選択します。

以下の内容で設定していきます。

• 基本的な設定
  • 名前；classact-alb-django
  • スキーム：インターネット向け
  • IPアドレス：IPv4
• ネットワークマッピング
  • VPC：classact-vpc
  • マッピング
    • ap-northeast-1a
      • サブネット：classact-public-subnet01
    • ap-northeast-1c
      • サブネット：classact-public-subnet03
• セキュリティグループ：classact-sg-django
• リスナーとルーティング
  • プロトコル：HTTP
  • デフォルトアクション：classact-tg-django

ALBがデプロイされたことを確認します。

ALBのリソースマップ-新規タブを押下するとどこに通信が流れるかを確認することが出来ます。

ALBのDNS名でhttp接続をしてみるとALBを抜けてEC2のDjangoにアクセスできます。
これで問題なさそうに見えるのですが、管理画面にログインして色々操作しようとすると、遷移がバグります。具体的には何度も何度もログインを求められるようになります。

これはロードバランシング時にEC2インスタンス2つに対してバラバラにロードバランシングしてしまうためだと思われます。
わかりにくいと思いますが、以下がそのログになります。左がsubnet01にデプロイされたEC2のログ、右がsubnet03にデプロイされたEC2のログとなります。38~46秒あたりを見てみると双方に通信をしていることがわかります。これはターゲットグループのロードバランシングアルゴリズムがラウンドロビンになっていることによると思います。

以下は完全に私のイメージですが、例えば赤矢印の流れでEC2にアクセスしてDjangoの管理画面に入った後、Django管理画面の別のページに遷移すると改めてロードバランシングされて青の矢印の流れで下のEC2にアクセスしてしまったとします。こっちの方ではログインをしていないので「ん？お前誰や！」的な話になって改めてログインを求められるのかなと。。。
この辺りは私の勉強不足感が否めません。。。

これを回避するために、同じEC2に接続し続けるように設定をしてあげる必要があります。

環境の修正

作成したターゲットグループのターゲット選択設定の維持設定を確認してみるとオフになっていることがわかります。（スクショ小さくて恐縮です。画面左少し下位です。）
この設定をオンにしてあげることで、最初にアクセスしたEC2に接続し続けるようになります。右上のアクションからターゲット属性編集を編集を押下します。

維持設定の欄で、維持設定をオンにチェックマークを入れます。
維持設定タイプをロードバランサーがCookieを生成しましたにします。

この状態でALB経由でEC2に接続すると同じEC2に対して接続をし続けるようになります。
改めてログを見てみると、subnet03に対して接続をし続けることでログが明らかに増えていることがわかります。