コラム

CTC教育サービス・ホーム　＞　コラム　＞　AWSではじめよう、ネットワークの世界　＞　第5回　AWS提供のBIG-IP!? Application Load Balancer(ALB)

AWSではじめよう、ネットワークの世界

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第5回　AWS提供のBIG-IP!? Application Load Balancer(ALB) (津村彰) 2016年9月

こんにちは、もしくははじめまして。津村です。9月に入り、台風も過ぎ日差しもだんだん秋らしくなってまいりました。でも、もう10月の連休が楽しみの方もいらっしゃるかもしれませんね。

さて、今回はAWS Summit New York 2016のキーノートで発表され、2016/8/11にリリースされたばかりの、新しいロードバランサである「Application Load Balancer(以下ALB)」についてご紹介したいと思います。
「新しいモノですので、ちょっと...」と思われる方は、このコラム1～4を読みなおしてみましょう。そうすると、きっと理解できると思います。

fig01

1.　ELBとALBの違いと、挙動について

従来のELB(Elastic Load Balancer - 第4回参照)では、以下の機能が提供されていました。

Layer4によるロードバランジング(L4スイッチ)
SSL終端(SSLラッパー)
配下のインスタンスの死活確認

新しいALBは、リバースプロキシと呼ばれるものであり、別称「L7スイッチ」と呼ばれます。

Layer7(アプリケーションレイヤー)によるロードバランジング(L7スイッチ)
ルールベース・プライオリティベースによるルーティング
SSLラッパー(HTTP/2対応)
WebSocketネイティブ対応
配下のインスタンスの死活監視

簡単にいうと、HTTP/HTTPSの接続をWebサーバの代わりに一旦受け取り（リバースプロキシ）、リクエストを解釈しルールに基づき（ルールベースのルーティング）、配下のサーバへ再度リクエストを行います（ロードバランジング）。

よって、従来のアプリケーションそのままではソースIPアドレスの解釈が異なる場合があり、mod_rpafといったApacheモジュールの追加や、nginxのコンフィグ修正、およびアプリケーションの書き換えにより動作を変更する必要がる場合があります。本件については後述します。

また、SSLラッパーはHTTP/2という新しいプロトコルに対応しており、フルSSLの環境では従来のELBのSSLラッパーより、より高速なサイト表示を実現します。

概念や作成方法についてはクラスメソッド様のブログが詳しいですのでそちらに譲ります。
http://dev.classmethod.jp/cloud/aws/alb-application-load-balancer/

2.　Certificate Managerについて

ALBのSSLラッパーには、従来通りACMのSSL証明書を使用する事ができます。
今回は、ACMが発行するワイルドカード証明書を作成してみましょう。

fig02

コンソール（以下AMC）の、「Certificate Manager」（以下ACM）が、該当のサービスです。
こちらを開き、新規に証明書を発行します。

fig03

ウィザードに従い上手く作成に成功すると、上記の通りワイルドカード証明書（例では*.nikujaga.info）が発行されています。
この証明書をELBやALBで使用する事ができます。

3.　ALBのSSLラッパーの挙動

ALBでは、リスナーの設定においてロードバランサのプロトコルに「HTTPS」を選択する事により、先に作成したACMの証明書を使用する事ができます。

fig04

上記の例では、HTTPSを一度受け取り、配下のサーバへHTTPでリクエストするよう設定されています。
よって、インスタンス上ではHTTPサーバのみ起動する事で、フルSSL対応も可能です。

ALBのSSLラッパーはHTTP/2に対応しており、最新の対応ブラウザではHTTP/2という高速なプロトコルにより通信します。
例えば、HTTP/2 and SPDY indicatorというChrome拡張により、この挙動を調べる事ができます。下図はこのChrome拡張の表示例です。

fig05

HTTP/2プロトコルについては幾つか資料がありますが、概念を理解するのであれば、以下の書籍がライトに理解する事ができてお薦めです。
Get Started with HTTP/2 Kindle版 - Yuryu(著)
https://www.amazon.co.jp/dp/B01KSCN0EW/
注）一般書店での流通はありません。

4.　リバースプロキシの挙動

リバースプロキシとは、通常のプロキシサーバとは前後が逆であり、クライアントからの接続を代理で応答し、配下のサーバへ中継します。ELBはHTTP等のTCPセッションを配下のインスタンスで終端しますが、ALBではALBが終端します。
よって、配下の全てのインスタンスから応答が無い場合は、ALB自身がWebサーバとなり、以下のページを送信します。

fig06

なおこの表示は、ルールの工夫により専用のインスタンス（通称：Sorryサーバ）にてメンテナンス中の旨のページを配信する事で、免れることが出来ます。

配下のサーバでは、HTTPリクエストのソースIPアドレスはALBのIPアドレスとなる為、信頼する事はできません。代わりに、リクエストに以下の変数が追加されており、本来必要であったパラメータを配下のサーバは受け取る事ができます。

[HTTP_X_FORWARDED_PORT] => 443
[HTTP_X_FORWARDED_PROTO] => https
[HTTP_X_FORWARDED_FOR] => 123.45.67

5.　おわりに - ALBの応用例

たとえばALBは、以下のようなケースで活用する事ができます。例として２つ挙げましょう。

5.1. 同一サイト内でディレクトリ毎にOSやCMSを変更する場合

例えば、http://example.com/には、WordPressを、しかしhttp://example.com/application/ではDrupalを採用したい場合、同一のインスタンス内で複数のLAMP CMSを起動する事は至難の技です。ましてや、複数台でクラスタリングする為、その難易度は上がります。
この場合、ルールベースのルーティングを上手く利用する事で、パスに対し該当のCMSのサーバにルーティングする事ができます。
/application/* - Drupal Servers
default - WordPress Servers

また、配下のサーバでHTTPプロトコルさえ解釈すれば良いので、例えばLinux(LAMP)とWindows(IIS + .net ASP)を同一サイトに混在させる事も同様に可能です。

5.2. 特定パスにのみ負荷が集中する際の負荷対策

たとえば、パス/news/*に対しは大量の負荷が発生するが、それ以外のページには負荷がほとんど無い場合、/news/*に対し専用にインスタンスを割り当てることにより、同一の内容のサイズ違いのインスタンスを並べるのみで容易に負荷対策をする事が可能です。

/news/* - Large Server
Default - Small Server

5.3. さいごに

さいごに、ALBの挙動はオンプレミスでBIG-IPを触ってiRulesをカスタマイズされた方であれば、感覚として理解しやすいのでは無いでしょうか。
私自身、2005年頃にBIG-IPを用いて例に挙げたようなインフラの運用をしており、ようやく個人の手の届くところに来た、というのが本音です。ですので、BIG-IPのiRunesの挙動が理解できていれば、容易に使いこなすことが出来るのではないでしょうか。