特徴をつらつらとまとめてみる。
Overview
http://docs.amazonwebservices.com/ElasticLoadBalancing/latest/DeveloperGuide/arch-loadbalancing.html
生存確認をするよ
デフォルトでELBに関連付けたインスタンスに生きてるか確認するリクエストをELBは送るよ。
portやリクエスト先のURLは指定できるよ。
自分は専用のendpoint作ってそれで確認できるようにしてるよ！
ちなみに、動的なアプリケーションが動いているならそっちで受け取ったほうがいいよ。
静的ファイルだとApacheやnginxが落ちてないのは確認出来るけど、
奥のunicornやmongrelやpassengerらへんで詰まってるかもよ！
SSL楽チンだよ
ロードバランサーに証明書と秘密鍵をアップロードするだけでいいよ。
それぞれのインスタンスに証明書たちを配備したり、
設定する必要がないので楽だよ。
というのも、SSL Terminationとして知られているけど、
clientとELBの間はHTTPSで通信するけど、
ELBとinstance(s)の間はHTTP(port=80)で通信するよ。
clientのIPもとれるよ
clientとappサーバーのみだったら、
間に邪魔する奴はいなかったので簡単にclientのIPがとれたけど、
間にELBがいるからappサーバーからremote_ipをとろうとするとELBのIPになっちゃうよ。萎え。
でも、ちゃんと対処法があって、
request headerに以下のheaderが付与されるよ！
X-Forwarded-For: clientIPAddress
簡単だね！
ただ、場合によってはELBが複数枚噛んでる場合があって、
詳しくは割愛するけど、複数のIPアドレスが入ってる可能性があるよ！
X-Forwarded-For: clientIPAddress, previousLoadBalancerIPAddress
気をつけてね！自分はこれで少しハマったことがあるよ！
clientとのプロトコルもとれるよ
例えば、HTTPできたひとはHTTPSにリダイレクトしたいとする。
でも、先の通りELBとinstanceの間の通信は常にHTTP（にしないのもできるけど、メリットがね）だから、
clientとELB間のプロトコルが分からないよ！
なので、IPのときと同様にheaderを付与するよ！
X-Forwarded-Proto: originatingProtocol
これで分かるね！
instanceはこのheaderをみてhttpアクセスの人はhttpsのアドレスにリダイレクトするとかするんだね。
--
結局はただの和訳なんだけど、
ゆるーく書いてみた。