IBM Cloud Load Balancerを使ってみた

#はじめに

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](https://console.bluemix.net/docs/infrastructure/loadbalancer-service/basic-load-balancing.html#-)では、明確な理由がない場合、バックエンドのサーバーはPrivate IPのみで作ることがセキュリティの観点から推奨されています。）

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/d2b31853-71b6-c829-ecc8-1906d2ffd954.png)

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

```1号機.
# cat index.html 
server1
# 
```

```2号機.
# cat index.html 
server2
# 
```

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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/1c5d3f22-b2fe-faf5-31e9-57e906303778.png)

IBM Cloud Load Blancerを選択し、「作成」を押下します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/882cd500-9a79-1e42-14d4-443f747d7e31.png)

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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/7a54cbc6-9b7f-3030-3c72-1c3991a03507.png)

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

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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/981ae555-6a62-eba6-62a4-32218bd0743f.png)


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

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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/87f0ccbb-67c3-606b-1289-cbb13316a665.png)

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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/7db6b2eb-71e4-4e15-c2a0-84e0ca6a2b82.png)

HTTPSを指定し、SSL証明書をインポートして、ロードバランサーで複号することも可能です。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/24a99db5-17b7-bd60-77bd-53ec3d50bdbc.png)

ヘルスチェックの間隔や、死活判定のルールを指定します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/d393104a-4ddb-9b5c-00c9-74ecd7c25252.png)

割り振り先となるサーバーを選択します。ロードバランサーと同じデータセンターにある、Primary IPを持つサーバーを、振り分け先として指定できます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/c963b112-1145-85aa-ce38-ffac6a9239a7.png)

なお、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 である実在のサーバーを使用します)。


![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/dae1a822-e8d8-7575-91f9-d6e11eeb054a.png)

オーダーを確定します。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/48cb3db9-5cf4-bb75-d054-6be44f44325e.png)

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

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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/d0de7d5f-a7f6-93a4-caae-6bd1b8ed7d69.png)


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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/7beca22f-bc0a-cc4a-40ef-e848a38a7cc7.png)

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アドレスが払い出されているのが分かります。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/270b930c-e9c1-3f4a-5914-937f7f6be788.png)

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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/83bd3312-22e9-f3a1-bfbc-efa40e848c90.png)

バックエンドのウェブサーバーには、このプライベート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週間分のスループットや接続数を確認可能です。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/cc91b9a7-a2cf-2e2d-2124-41e9681319dd.png)


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

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/d5bca674-fcb9-a91e-93d1-df8bff18b04f.png)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/fede100d-3485-8636-339f-2926625c1a48.png)

ウェブサーバーの標準的なアクセスログに残る送信元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層構造のシステムにも適用できます。

https://www.ibm.com/blogs/bluemix/2018/04/updates-cloud-load-balancer/

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/04d9c7c2-d87c-7008-896b-09b77ec62d49.png)

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や月額のロードバランサーにこの選択肢が加わることで、より柔軟なシステム構成が可能になったと思います。