(小ネタ)本番のみロードバランサーがある場合の注意点

方式設計小話。

webシステムを開発し、本番運用に至る過程で、下記のうち最低２つの環境があるのではと思います（所属している組織によって呼び方は色々変わるかと思いますが)。

・個人開発環境
・結合環境
・ステージング環境
・本番環境

上記の様に複数の環境があるにも関わらず、予算の都合上、「本番のみ複数台の冗長化構成。フロントにロードバランサー」という構成が多いのではと思います。そしてこの事実の与えるインパクトを過小評価してしまいトラブルが起こる場合があります。

ロードバランサー＆冗長化というキーワードを聞いた場合は、下記を必ず早期に確認しなければいけません。

No.1 セッション情報の引継ぎ。ロードバランサー担当者にお願いする事項は無いか
No.2 SSL通信の解除はどこが行うか？
No.3 どうやってhttp/httpsを見分けるか？
No.4 サーバ名は正しく返せるか？
No.5 ファイルの置き場所

順次説明していきます。

○No.1

ruby on railsの様に、クライアント側に実質状態維持の責務を移している場合は全く問題がありません。
しかしJ2EEでのHttpSessionでは大問題になります。HttpSessionは、各々のサーバのメモリー上に保持される為、２台以上サーバをたてる場合はこのメモリーの共有化がネックになります。
セッションのレプリケーションや永続化による回避方法もありますが、性能上大きな問題になる可能性もあります（機械的なセッションのシリアライズ、デシリアライズは意外にコストがかかる為）。
よってロードバランサーの設定で、「jsessionid」等のcookie内でのキーを利用し、片系に固定してしまうという手が良く使われます。

# 但しこれでは "本当の意味で"冗長化&高可用性にはならないですよね。

いずれにしろ、この課題に対してどう取り組むかは早期に決定されるべきです。

○No.2

ロードバランサーにも二種類有り
・SSL通信を自力で複合化するタイプ
・SSL通信は素通りさせるタイプ
があります。

SSL通信を複合化する責務はどこにあるのか（ロードバランサー or webサーバ)は早期に明確にする必要があります。

○No.3

webアプリケーションには、http通信でよい部分と、https通信でなければいけない部分があります。もしNo.2のロードバランサーにてSSL(https)通信が複合化される場合、webサーバ自身は、httpなのかhttpsなのか分からなくなる場合があります。

この問題がクリティカルになる可能性も大きい為、「どうやって見分けるのか？」（例 httpヘッダーに特定のキーが含まれる）を早期に確認しておくべきです。

○No.4

絶対パスとしてurlを生成する際、ホスト名が必要になります。その場合サーバ自身のサーバ名を利用して生成されると、冗長化構成の各サーバでバラバラになってしまう恐れがあります。

絶対パス生成の仕組みは早期に確認しておくべきです。

○No.5

各サーバからファイルシステムとして共用されるべき物が、どのような方式(例 NFSマウント)で実現されているかを確認する必要があります。

# これは意識している人が多いですが。

----

小ネタの割にはずいぶん長くなってしまいました。。
ある意味常識的な話題ですが、割とあいまいにしている人が多いので戒めの意味も込め記載させて頂きました。