はじめに

IBM Cloud Load Balancerを使ってみました。

IBM Cloud Load Balancerは、従量課金のL4ロードバランサーです。
情報はこちらにあります。
https://console.bluemix.net/docs/infrastructure/loadbalancer-service/about.html

ウェブサーバーを2台準備

事前に、割り振り先となるサーバーを作って、ウェブサーバーを起動しておきます。（今回は別の検証にも使うために、Public IP付きのサーバーで作っていますが、IBM Cloud Load Balancerの割り振り先はPrivate IPになるため、Private IPのみのサーバーであっても、問題なく利用できます。IBM Cloud Docsでは、明確な理由がない場合、バックエンドのサーバーはPrivate IPのみで作ることがセキュリティの観点から推奨されています。）

分かりやすさのため、単純に1号機か2号機かを示すindex.htmlを配置しました。

# cat index.html 
server1
# 

# cat index.html 
server2
# 

IBM Cloud Load Balancerのオーダー

カタログの「ネットワーク」から、ロードバランサーを選択します。

IBM Cloud Load Blancerを選択し、「作成」を押下します。

価格は、時間当たりの基本料金プラス、扱ったデータ量に対する従量課金です。
Publicタイプには、アウトバウンド費用が別途かかります。

ロードバランサーのタイプとして、PublicかInternalを選択します。Publicタイプは、VIPがPublic IPアドレスとなります。（インターネットからのリクエストを受け付け、背後のPrivateネットワーク上のサーバーに割り振ります。）
Internalタイプは、VIPもPrivate IPとなります。

まずはPublicタイプのロードバランサーを作成してみます。下記の構成イメージです。

ロードバランサー自身も、Public IPとPrivate IPを持ちます。Private IPは、ユーザーが持っているPrivate サブネットから払い出されます。Public IPは、IBM CloudがプールしているPublic IPを使うか、ユーザーが持っているPublicサブネットから払い出すかを選びます。

冗長性のため、1つのオーダーにつき標準で2台のロードバランサーが作成され、それぞれがPublic IPとPrivate IPを1つずつ持つ構成となります。今回は、VIPを、自分が持っているPublicサブネットから払い出すよう選択しました。

ロードバランサーの名前と使用するプロトコルを指定します。

HTTPSを指定し、SSL証明書をインポートして、ロードバランサーで複号することも可能です。

ヘルスチェックの間隔や、死活判定のルールを指定します。

割り振り先となるサーバーを選択します。ロードバランサーと同じデータセンターにある、Primary IPを持つサーバーを、振り分け先として指定できます。

なお、2018年4月の時点では、ポータル画面から選べるのはPrimary IPを持ったサーバーのみです。
VMware上の仮想マシンのように、Portable IPを持つサーバーを割り振り先に設定するには、APIを使用して設定を行います。
https://console.bluemix.net/docs/infrastructure/loadbalancer-service/faqs.html#faq

ロード・バランサーをサービスとして VMWare で使用できますか。

SoftLayer ポータブル・プライベート・アドレスを割り当てられた VMware 仮想マシンは、ロード・バランサーにバックエンド・サーバーとして指定できます。この機能は現在、API を介してのみ使用でき、Web UI (GUI) では使用できません。API を介して追加されたポータブル・プライベート IP は、SoftLayer によって割り当てられていないため、GUI には「Unknown」と表示されます。この種の構成は、Xen や KVM などの他のハイパーバイザーでも使用できることに注意してください。

VMware NSX ネットワークなどで、SoftLayer 以外のアドレスが割り当てられた VMware 仮想マシンは、ロード・バランサーにバックエンド・サーバーとして直接追加することはできません。ただし、構成によっては、ロード・バランサーのバックエンド・サーバーとして SoftLayer プライベート・アドレスを持つ、NSX ゲートウェイなどの中継を構成できます (VMware NSX が管理するネットワークに接続されている VM である実在のサーバーを使用します)。

オーダーを確定します。

オーダーしたロードバランサーを確認する

数分でロードバランサーの作成が完了し、Onlineになります。

ロードバランサーにはFQDNが1つ割り当てられており、ロードバランサー自身が持つIPアドレスに紐づいています。負荷によってロードバランサー自身の台数が自動で増減するため（負荷が低くても、冗長性の観点から、1台になることはありません）、ロードバランサーの実IPは変化する可能性があります。そのため、利用者はFQDNを指定してアクセスする形になります。

nslookupで確認すると、標準で2台作成されており、ロードバランサー自身が冗長構成になっていることが分かります。

$ nslookup LB01-xxxxx-tok02.lb.bluemix.net
Server:     x.x.x.x
Address:    x.x.x.x#53

Non-authoritative answer:
Name:   LB01-xxxxx-tok02.lb.bluemix.net
Address: 169.xx.xx.57
Name:   LB01-xxxxx-tok02.lb.bluemix.net
Address: 169.xx.xx.50

$

-----------2019/4/9追記 start-------------
前提条件を満たしたアカウントでは、ロードバランサー自身が複数ゾーン（例：TOK02とTOK04）に分散配置されるようになり、一層、可用性高く使えるようになりました！

https://cloud.ibm.com/docs/infrastructure/loadbalancer-service?topic=loadbalancer-service-multi-zone-region-mzr-overview#multi-zone-region-mzr-overview
-----------2019/4/9追記 end-------------

ユーザーのPublicサブネットから2つ、ロードバランサー用にIPアドレスが払い出されているのが分かります。

プライベート側サブネットからも2つ、ロードバランサーにIPアドレスが払い出されています。

バックエンドのウェブサーバーには、このプライベートIPからハートビートが来ています。

10.132.222.86 - - [12/Apr/2018:20:54:03 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.89 - - [12/Apr/2018:20:54:06 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.86 - - [12/Apr/2018:20:54:08 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.89 - - [12/Apr/2018:20:54:11 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.86 - - [12/Apr/2018:20:54:13 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.89 - - [12/Apr/2018:20:54:16 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.86 - - [12/Apr/2018:20:54:18 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.89 - - [12/Apr/2018:20:54:21 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.86 - - [12/Apr/2018:20:54:23 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.89 - - [12/Apr/2018:20:54:26 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.86 - - [12/Apr/2018:20:54:28 -0500] "GET / HTTP/1.0" 200 8 "-" "-"
10.132.222.89 - - [12/Apr/2018:20:54:31 -0500] "GET / HTTP/1.0" 200 8 "-" "-"

また、ダッシュボードから、最大で過去2週間分のスループットや接続数を確認可能です。

ブラウザから動作確認

ブラウザから、ロードバランサーに割り振られたFQDNにアクセスすると、配下のウェブサーバーに配置したコンテンツが閲覧できます。今回は単純なラウンドロビンにしたのでブラウザをリロードする度に2台のコンテンツが順番に表示されています。実際に業務で使う場合は、ユーザーが使うドメイン名のCNAMEとして、ロードバランサーのFQDNを登録する形になるでしょう。

ウェブサーバーの標準的なアクセスログに残る送信元IPアドレスは、エンドユーザーのIPアドレスでなく、ロードバランサーのPrivate IPとなるため、下記と同様、ログにX-Forwarded-Forの情報を出力しておくのが良いと思います。
https://qiita.com/testnin2/items/037e1337a1d9b5f13231

Privateタイプ

Privateタイプは、ロードバランサーのVIPがPrivate IPになります。
こちらのタイプを使うことで、Public側インターフェースを持たないシステムに専用線やIPSec VPN経由でアクセスする場合にも、IBM Cloud Load Balancerを利用することができます。

下図のような3層構造のシステムにも適用できます。

Internalタイプの場合も、ユーザーはFQDNを指定してブラウザからアクセスします。下記のようなDNSレコードが作成され、インターネット上でも名前解決できる状態になります。

$ nslookup LB02-xxxxx-tok02.lb.bluemix.net
Server: xxx.xxx.xxx.xxx
Address: xxx.xxx.xxx.xxx#53

Non-authoritative answer:
Name: LB02-xxxxx-tok02.lb.bluemix.net
Address: 10.132.222.102
Name: LB02-xxxxx-tok02.lb.bluemix.net
Address: 10.132.222.97

$

終わりに

以上、IBM Cloud Load Balancerを試してみました。
時間単位の基本料金と、扱ったデータ量の従量課金で使えるので、スモールスタートで使え、標準で冗長化もされており、高負荷時にはロードバランサーの台数が自動的に増えてスケールアウトしてくれます。

これまでのNetScaler VPXや月額のロードバランサーにこの選択肢が加わることで、より柔軟なシステム構成が可能になったと思います。