ここではサーバの負荷分散や冗長化の対策として必須となるロードバランサーについて紹介します。単一のサーバで運用するとなると、リクエストが多発した時に処理できなくなったり、また障害が発生した時にサービス断になってしまう可能性があります。そのため、複数のサーバで構成し、リクエストをうまく振り分けたり、障害のあるサーバを切り離したりする役割を担うのがロードバランサーです。
ALB（Application Load Balancer）の仕組み
ひと昔前は、ロードバランサーはトランスポート層レベルでトラフィックの振り分けを行っていましたが、近年ではアプリケーション層のレベルでの振り分けが主流になっております。これにより、アプリケーション層でのいろいろな条件によって処理を分岐したりもでき、応用性が高まりました。
AWSのアプリケーション層レベルのロードバランサーは、ALB（Application Load Balancer）と呼ばれていて、まずこのALBの概要について説明します。
ALBは、それひとつで複数のタイプのトラフィックを担うことができます。下の図に示すように、ALBには複数のリスナーを設定でき、さらにリスナーは複数の転送先を設定できます。
リスナーは受け付けるポートやプロトコルごとに設定され、さらにリスナーは条件ごとに転送先を複数設定できます。転送先はターゲットグループと呼ばれ、転送先ごとに作成します。ターゲットグループの中で振り分けるEC2インスタンスやlambda関数を設定します。
ターゲットグループにはヘルスチェックという機能があり、グループ内のEC2インスタンスが生きているかどうかを定期的にチェックしてくれます。何かしらの原因で疎通ができず Unhealthy になったインスタンスはトラフィックの振り分けが行われなくなります。障害が発生したインスタンスを自動で切り離してくれます。
エラーを返す機能など、詳細な機能はまだたくさんあるのですが、正常系のおおまかな流れは上記のようになっており、ひとつのALBで複数のトラフィックを扱うことが可能です。
HTTPSの終端として利用
ロードバランサーを利用すると、Webサーバの証明書の設定が楽にできます。自前で作成したWebサーバに証明書を設定しようとすると、すこし手間がかかります。Let’s encryptなどを使って証明書の取得とともに簡単にできる手段もありますが、ひと手間かかります。
ロードバランサーを前段におくと、ロードバランサーがHTTPSの処理を全てやってくれて、後段のWebサーバにはHTTPで転送するということができます。
ですので、後段のWebサーバは証明書やHTTPS通信の設定を一切する必要がないので楽です。ALBの設定で、使用する証明書を設定すれば完了です。証明書はドメインを持っていればACMで簡単に取得できて設定できますので、AWSコンソールだけで設定が完了します。
ALBのエンドポイントURLはデフォルトでは複雑なURLになっておりますので、ドメインを持っていたら、CNAMEでそのURLを取得ドメインのシンプルなURLに設定することで、上記の証明書を利用したHTTPS通信が可能になります。
Sticky Session
ALBは、トラフィックを複数のWebサーバに振り分けることができますが、毎回同じインスタンスのWebサーバに振り分けるとは限りません。REST APIであったり、単純なリクエストであれば支障はでないのですが、サーバで保存されているCookieを使ったセッションを利用する場合においては、そのセッション内においては、毎回同じインスタンスのWebサーバにアクセスしないとセッション情報が共有できないため、想定するアプリケーションの処理ができなくなります。
そこで、ALBにはSticky Sessionという機能があります。Sticky SessionではALBでも独自のCo okieを付与し、下記の図のように、ユーザと転送先のWebサーバを固定できるようにALBがうまくやってくれます。
Webアプリケーションでログインが必要なものは、だいたいこの仕組みが必要になってきます。PHP等でsessionを使っていたらこれを設定する必要があります。（もちろん後段が1台のインスタンスのみで、ALBを先ほどのHTTPS終端として利用しているだけでしたらこの設定は必要ありません）