- ソリューションアーキテクト
- プロジェクトマネージャー
- テクニカルオペレーション
- Other occupations (4)
- Development
- Business
- Other
世の中は選択の連続。
昼ごはん、豚骨ラーメンにするか?醤油豚骨にするか?
夜の居酒屋の一杯目、ビールにするか?ハイボールにするか?
打ち上げ花火、下から見るか? 横から見るか?
そして、
プロキシサーバのELB、CLB使うか? NLB使うか?
はじめに
AWSクラウドデザインパターンのCDP:High Availability NATパターンの中に、「HTTPプロキシーサーバーを内部ELB配下に配置し、プライベートセグメントの各インスタンスは内部ELBをHTTPプロキシーとして使用して、冗長化されたプロキシーサーバー経由でアウトバウンド通信を可能にする。」構成があります。 このデザインパターンが書かれたときのELBは、現在のClassic Load Balancer(CLB)が想定されているものと思われますが、2018年4月現在では、同様の構成をNetwork Load Balancer(NLB)でも実現することができます。以下、それぞれの設定ポイントと採用判断基準をまとめます。
CLBで構成する場合
設定ポイントは以下です。
内部向けロードバランサーとして設定する
ロードバランサーのプロトコルはTCPとして設定する
プロキシサーバ側で、クライアントの送信元IPアドレスを取得したい場合は、CLBでProxy Protocolを有効に設定します。(プロキシサーバ側も、Proxy Protocolに対応したものである必要があります。)
2点目のプロトコルをTCPにする点について補足します。 CLBのプロトコルをHTTPで設定すると、HTTPリクエスト内のURIを以下のように書き換えてしまい、プロキシサーバ側で接続先の情報を解釈できなくなります。この事象を防ぐため、プロトコルをTCPで設定する必要があります。
クライアントが出したリクエスト例
GET http://www.example.com/index.html HTTP/1.1
CLBが書き換えたリクエスト例
GET /index.html HTTP/1.1
NLBで構成する場合
設定ポイントは以下です。
- 内部向けロードバランサーとして設定する
- プロキシサーバ側で、クライアントの送信元IPアドレスを取得する際、ターゲットグループのタイプを「インスタンス」で設定した場合は、追加設定は不要です。(プロキシサーバにパケットが着信する送信元IPアドレスはクライアントのIPアドレスが保持されるため。)
一方、ターゲットグループを「IP」で設定した場合は、プロキシサーバにパケットが着信する送信元IPアドレスはCLBと同様にロードバランサーのIPアドレスとなるため、Proxy Protocolを有効にする必要があります。
どちらのELBを採用すべきか
一般的にVPCを使用する場合は、CLBではなくNLBを採用することが推奨されていますが、NLBの特性が運用上許容できるかどうかが、採用判断基準になると思われます。
- NLB自体にセキュリティグループを設定することはできません
- NLBは、アクセスログが出力できません
- NLB(内部向け)はVPN経由/VPC Peering経由でアクセスすることができません(Direct Connect経由であれば可能です)
以上、プロキシサーバの前段にELBを配置した構成のポイントとCLB/NLBの採用判断基準についてまとめました。
ちなみに、私、打ち上げ花火、家でハイボール飲みながらテレビで観る派です。ではでは。