ALBを試してみる
Last-modified: Mon, 21 Jan 2019 18:00:41 JST (2185d)
Top > ALBを試してみる
ALBを試してみました。
流れとしては、単品のEC2インスタンスを作成し、その上にALBを入れていきます。
ようは、今まで単品EC2のサーバだったものを、外からのアクセスURLはそのままに、
ALBで負荷分散をしたいケースを想定します。
- 単品EC2サーバの作成
まずはALBなし、単品EC2インスタンスを作成し、動作確認をします。
ここでは詳しく触れませんが、当然InternetGatewayに接続されているサブネット上に作る必要があります。
必要に応じ、IP制限などセキュリティグループ設定を行ってください。
(いや分かってるよ。という人は飛ばしてよいですw) このEC2はApacheをインストールし、/と/blogにファイルが置いてあります。 Apacheのログでも、アクセスされていることが確認できます。
- ALB作成
では、EC2の動きが確認できたところで、ALBを作成しましょう。
- EC2管理画面のロードバランサ―をクリックします。
- 次に、ロードバランサ―の作成ボタンをクリックします。
- ロードバランサ―の種類の選択画面が出ます。
ここでは、Application Load Balancerを作成します。 - 作成ウイザードが起動します。
適当な名前を付けます。(スクショではミスってスペースを入れましたが、エラーになります。)
ALBはVPC内部のプライベートネットワークでも使えますが、今回はインターネット向けに設定します。 - リスナーはデフォルトでHTTPプロトコルがセットされています。
HTTPSを追加したい場合は、リスナーの追加ボタンをクリックし、SSL証明書などの設定を行います。
ここでは、手早く動作を確認したいのでSSLは無しにしました。
ドメインを取得しているなら、AWS Certificate Managerの取得法を参考に無償の証明書をセットすることができます。 - アベイラビリティゾーンの設定です。
従来のELBでは、アベイラビリティゾーンは1つでもOKでしたが、ALBは2つ以上が必須となります。 - 次にALBに設定するセキュリティグループを設定します。
注意点として、ALBに設定したセキュリティグループIDをEC2側に設定したセキュリティグループ
で許可する設定にしないと、ALBからバックエンドのEC2へ通信不能となります。
それは、ALBに割り当てられるIPが不定なのと、かといってサブネット全体を許可するセキュリティグループは
ちょっとザルなので。この辺りはSecurityGroupについてを参照ください。
- 次に、ルーティングの設定です。ALBはターゲットグループと呼ばれるEC2インスタンスを
グルーピングした単位でインスタンスを設定します。
ここでは事前にターゲットグループの準備をしていないので、新しいターゲットグループを選択し、
TestTergetというターゲットグループを作成します。
ヘルスチェックはALBがサーバの死活監視でアクセスする先を指定します。
ここがALBからアクセス不能になると、ALBはインスタンスを切り離しますので、
必ずアクセスできるページを指定します。ELB+APacheでhttpsへリダイレクトをしたいも参考に。 - ターゲットの登録です。ここで、先ほど作成したターゲットグループに対し、
EC2インスタンスを割り当てます。ここでは先ほど作成したテスト用EC2インスタンスを割り当てます。 - 確認画面が出ますので、作成ボタンをクリックし作成します。
- ALBが作成されましたら、DNS名のところにアクセス可能なDNS名が表示されます。
通常ここをDNSへ登録するのですが、今回はテストなのでそのまま使います。
- ALBの動作確認
- EC2が1台の場合の挙動
ALBにアクセスします。先ほどのEC2インスタンスのApacheログにELBのヘルスチェックアクセスが記録されています。 アクセス元IPアドレスはALBのプライベートIPになっています。
アクセス元IPを取得するには、Apacheのログ設定が必要になります。同様にアプリケーション側でアクセス元IPアドレスで制限などを掛ける場合は、取得する環境変数の変更が必要になります。 - EC2が2台の場合の挙動
EC2が二台構成のとき、アクセスが振り分けられることを確認します。
面倒なので、先ほどのEC2インスタンスのクローンを作成します。こういう芸当ができるのがクラウドの利点ですね。 では、作成したEC2をターゲットグループに追加しましょう。EC2管理画面より、ターゲットグループをクリックします。 TestTergetを選択し、編集ボタンをクリックします。 先ほど作成したクローンインスタンスを追加します。 ALBにアクセスしてみます。
それぞれのEC2インスタンスに対し、交互にアクセスがあることが確認できます。
- EC2が1台の場合の挙動
- ALBによるルーティングの振り分け
では、ALBの特徴である、ルーティング(パスベースの振り分け)を見ていきましょう。
図のような構成を作ります。 つまり、いままで同一サーバ内にあった/blogを外に切り出すわけですね。
ただし、外部からのアクセスは変更しないようにします。
- EC2管理画面より、ターゲットグループをクリックします。
- ターゲットグループの作成をクリックします。
- ターゲットグループを設定します。ここではBlogTargetというのを作りました。
- つぎに作成したターゲットグループにインスタンスを割り当てます。
作成したBlogTargetを選択し、編集ボタンをクリックします。 - インスタンスを追加します。
- ALBのルーティングルールについて
では、ALBのルーティングルールを見ていきながら、挙動を見ていきましょう。
まずはルールを割り当てます。
ALBの画面からルールの表示・編集をクリックします。 +ボタンをクリックします。 ルールの挿入をクリックします。 では、/blogに対してのアクセスを振り分けるルールを設定しましょう。 ついでに、ALBの機能で、特定のレスポンスをサーバレスで返すことができますので、その機能も試してみましょう。
ここでは、すべてのパスに対し、NotFoundというテキストを返すことにしましょう。 最終的にこんな感じです。
では動作確認しましょう。
このままでは何やってもNotFoundなので、優先度を入れ替えてみます。
あれ?予想に反して、出てきませんね・・・
ルールを編集してみます。
出るようになりました。
では、NotFoundのルールを削除して、/blogのルールだけにしましょう。
それ以外はデフォルトルールが適用されるはずです。
ついでに、最初に作ったTestTergetから、Cloneインスタンスを削除します。これで、/blogに対するアクセスのみ、
クローンしたEC2インスタンスが受け持ちます。
うまく振り分けられ・・ないですね。
パスのルール設定で、アスタリスクをつけないと、完全一致になります。
ちゃんと振り分けられました。
ここで分かるように、あくまでパスベースなので、URL引数とかでの振り分けは出来ません。
なお、AWSのALB(Application Load Balancer)で複数アベイラビリティゾーンの設定で詰まった に単一AZのみにEC2インスタンスがあると、
アクセス不能になる事がある。とあったので、調べてみました。
自分の環境では、512回アクセスしましたが接続不能にはなりませんでした。
ただ、公式ドキュメントに大丈夫と記載がない以上、同一グループ内インスタンスはMulti-AZ構成にしておいたほうが無難そうです。
Counter: 1167,
today: 3,
yesterday: 1
このページの参照回数は、1167です。