ELBがApplication層でのロードバランシングに対応したらしい

AWSのELBが、Application層でのロードバランシングに対応したらしいです。 Application層で動くロードバランサーということで、ALBと呼ぶらしいです。

Application層で動作するロードバランサー

通信機能を7つの階層に分割するOSI参照モデル(物理層、データリンク層・・・などに分割するモデル)の最上層であるアプリケーション層で動作するロードバランサーです。

アプリケーション層で動作するため、この層で使われているHTTPというプロトコル等をもとに負荷分散をすることが可能になったようです。

現状(2016/08)のALBはHTTPリクエストのURLを用いてバランシングすることができます。

ELBでできなかったことと、ALBでできるようになること

ELBは通信を受け、処理を自身の配下のインスタンスに振り分けるという働きをしてくれていました。この際に、全ての処理を同一グループのインスタンスに負荷を分散しながら振り分けるというのがELBの挙動になります。

一方で、ALBではリクエストのURLに基づいて処理を割り振るグループを選択することができるようになります。

例えばhttp://example.com/*へのアクセスはデフォルトでGroup1に振り分けつつ、http://example.com/fugaへのアクセスのみGroup2に割り振るといったことが可能になります。

利点

これにより、より粒度の小さいサービスの組み合わせによるサービスの提供が可能になります。

例えば、ユーザーというドメインをCRUDするようなアプリケーションがあったとします。

http://example.com/user/createでユーザーを作成し、http://example.com/user/delete/{id}でユーザーを削除することができるとします。

ELBでは、ユーザーのCRUD機能を全て実装したサーバーをグループに入れておいて、http://example.com/へのリクエストを各グループに負荷分散して処理を振り分けていました。

これがALBではユーザーのCRUD機能をモノリシックに用意する必要がなくなります。

CreateやDeleteなど機能を単体で用意しておき、それらをGroup1とGroup2にそれぞれ格納します。 そして、http://example.com/user/createへの通信はGroup1に処理を振り分け、http://example.com/user/delete/{id}への通信はGroup2に処理を振り分ければいいわけです。

これによって、よりマイクロなサービスの組み合わせでサービス全体を提供することが可能になるわけです。

ALBを使う上で気をつけたいこと

deployの話

アプリケーションのdeploy周りについては考える必要が出てくる気がします。

ELBを使っていた場合はユーザーのCRUD機能が一枚岩で提供されていたので、deploy時にはまるっと入れ替えることができました。

これがALBを使っている場合はCreate機能やUpdate機能が分割できてしまうので、新旧を無停止で入れ替えようとするとタイムラグが起きて問題になる気がします。

今回は例を示す際にユーザーのCRUD機能をあげましたが、分割の単位はドメインごとに切るなりなんなり、サービスにあった切り口を考える必要があるでしょう。

可用性の話

各グループにそれぞれ別の責務を負わせるわけで、それぞれのグループで可用性を確保する必要があると思われます。複数AZで各グループ用のインスタンスを起動してあげる必要があるでしょう。 結構構成が煩雑になりそうなので、CloudFormationによるコード化はしておいたほうがいいかもしれません。

CloudFormationにはすでにALBも対応しているようで、AWS::ElasticLoadBalancingV2::LoadBalancerというようにElasticLoadBalancingV2ってやつを使ってあげればいいみたいです。