この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、コンサル部のキム・ジェウクです。
当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の 15日目のエントリです。
このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。
15日目のテーマはAmazon Application Load Balancerです。
Load Balancingとは？
ELB (Elastic Load Balancing) は、アプリケーションへのトラフィックを、1 つまたは複数のアベイラビリティーゾーン (AZ) 内の複数のターゲットおよび仮想アプライアンスに自動的に分散します。
つまり複数のサーバが分散処理を行うのをLoad Balancingと言います。
では「Load Balancerって何だろう？」と考える方もいらっしゃると思います。 Load Balancerは、Load Balancing技術を提供するサービスです。
AWSでは三つのLoad Balancerサービスを提供しています。
- Application Load Balancer
- Network Load Balancer
- Gateway Load Balancer
OSI7 階層
Load BalancerはOSIの7階層で、どの階層を基準に分散作業を行うのかによって、サービスが異なります。
Application Load Balancerは「Layer7」であるApplication階層を使用し、URLまたはhttp-headerから負荷分散が可能です。
つまり、URLに応じて負荷を分散させたり、HTTPヘッダのCookieの値に応じて負荷を分散するなど、クライアントの要請をより細分化してサーバに伝達できます。
また「Layer7」Load Balancerの場合、特定のパターンを持つウイルスを検知してネットワークを保護でき、DoS/DDoS のような異常なトラフィックをフィルタリングできます。
Application Load Balancerの仕組み
- クライアントはアプリケーションにリクエストを送信します。
- ロードバランサーのリスナーは、設定したプロトコルとポートに一致するリクエストを受信します。
- 受信リスナーは、指定したルールに対して受信リクエストを評価し、該当する場合、リクエストを適切なターゲットグループにルーティングします。HTTPS リスナーを使用して、TLS 暗号化と復号化の作業をロードバランサーにオフロードできます。
- 1 つ以上のターゲットグループの正常なターゲットは、ロードバランシングアルゴリズムと、リスナーで指定したルーティングルールに基づいてトラフィックを受け取ります。
Private Subnet？Public Subnet？
初めてApplication Load Balancerを作成するときによく悩むのが、Private Subnetを選択するのか、Public Subnetを選択するのかの部分だと思います。
Application Load Balancerを作成するとき「スキーム」で「インターネット向け」と「内部」を選択できます。 ここでPublic Subnetを選択するのか、Private Subnetを選択するのかで、スキームが変わってきます
「インターネット向け」クライアントからインターネット経由でリクエストをターゲットにルーティングします。「内部」は、プライベート IP アドレスを使用してターゲットにリクエストをルーティングします。
Load Balancerを作成すると、選択したSubnetにLoad Balancer Nodeが作られます。 インターネットを通じてウェブサーバーにアクセスしなければならない場合、Private Subnetを選択してしまうとLoad Balancer NodeがPrivate Subnetに作られるため、外部と通信ができない状況が発生してウェブサーバーにアクセスできません。それで、自分の状況に合わせてSubnetを選択する必要があります。
Subnetは「マッピング」で選択できます。
「スキーム」で、「インターネット向け」 を選択すると、Public Subnet を選択する必要がありますが、Private Subnet を選択すると、警告メッセージが表示されます。逆に「内部」を選択してPublic Subnetを選択しても、警告メッセージが表示されます。
- インターネット向け : Public Subnet
- 内部 : Private Subnet
マッピング？
2 つ以上のアベイラビリティーゾーンを有効にして、アプリケーションの耐障害性を高めます。
ゾーンごとに 1 つのサブネットを選択します。ロードバランサー用にデュアルスタックモードを有効にした場合は、IPv6 CIDR ブロックが関連付けられているサブネットを選択します。次のいずれかを指定できます。
- 少なくとも 2 つのアベイラビリティーゾーンからのサブネット
- 1 つ以上の Local Zones からのサブネット
- 1 つの Outpost サブネット
Security Group
Load Balancerでもセキュリティグループを設定することができます。Application Load BalancerではHTTPあるいはHTTPSを設定します。
上記のイメージのようにSecurity Groupのinbound rulesでタイプをHTTPに設定して、ソースをAnywhereに選択すればいいです。
そして、作成したApplication Load BalancerのSecurity GroupをEC2 Security Groupのinbound rulesに追加します。
HTTPSも同じです。でも、HTTPSの場合「SSL証明書」が必要です。
リスナーでHTTPSを選択すれば下に「セキュアリスナーの設定」が現れます。ここでSSL証明書を選択できます。
ACMにSSL証明書を登録する方法は下のBlogを参考してください。
Application Load Balancerを通じしないとEC2には直接HTTP、HTTPS接続ができないです。
Target Groups
各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。
各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。
ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。
health checks failed 問題
EC2にApacheがインストールされていなければ「health checks failed」というエラーが出てくる場合もありますので、EC2でApacheがインストールされているか確認する必要があります。
続いて、Apacheをインストールしたにもかかわらず、「Health checks failed with these codes: [403]」というエラーが表示されます。 このエラーは、現在ターゲットグループに登録されているパスにindex.htmlファイルがない場合に表示されるエラーです。
cp /usr/share/httpd/noindex/index.html /var/www/html/index.html/var/www/htmlパスにApacheのindex.htmlを持ってきます。
もう一度Target Groupsを確認してみると「healthy」に変わっているのを確認できます。
おわりに
以上、『AWS 再入門ブログリレー 2022』の15日目のエントリ『Amazon Application Load Balancer』編でした。
次回、2/24(木)は枡川(masukawa)さんの「CodeDeploy編」の予定ですのでお楽しみにしてください！