IBM Cloud ICLBの動作確認(2) -分散方式編-

## 目的
IBM Cloud Load Balancerを活用して、Webサーバへのロードバランスを試してみた。
前回初期導入を実施したが、今回は実際にICLBロードバランスの基本機能を確認する。
前回記事はこちら

* 初期導入編：[IBM Cloud ICLBの初期導入(1) -初期導入編-](https://qiita.com/khoshina/items/6a092bec9a9dfeae2c01)
* 分散方式編：本ページ
* レイヤ7編：[IBM Cloud ICLBの初期導入(3) -レイヤ7編-](https://qiita.com/khoshina/items/492c92396844e573e34d)

## 環境
* ローカル端末：macOS Catalina 10.15.6 1台
* プラットフォーム:IBMCloud
    * ロードバランサ:IBM Cloud Load Balancer(ICLB) 1サービス(Public to Private)
    * DNSサービス:IBMCloud DNS 1サービス
    * 接続先サーバ:CentOS 7.7.1908(Virtual Server for Classic) 2台

### 概要構成図
![スクリーンショット 2020-09-04 23.07.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/703043/0243915c-4435-0ba0-f803-c226ec692c8b.png)

### 通信経路
Client -> ICLB(HTTPSアクセス):**認証局証明書デプロイ** -> Server(HTTPアクセス):**証明書不要**

1.インターネット端末よりICLBのFQDNへアクセスする。 -> https://iclb.xcloudyx.com
2.IBMCloud DNSのCNAME情報より、ICLBのPublicIPアドレスがわかる -> kou-iclb01-1160157
3.インターネット端末とICLB間でTLS(SSL)接続を確立する。
4.ICLBの分散アルゴリズムに基づいて、Privateネットワークのサーバ２台にHTTPで分散接続する。

## 動作確認
`ローカル端末での作業`
### DNS動作確認
パケットキャプチャで**iclb.xcloudyx.com**への名前解決が、正しく**kou-iclb01**に行っているか確認する。
下記２つのアドレスが帰ってくるため、問題なく名前解決できている。
* kou-iclb01-1160157-tok05.clb.appdomain,cloud A 165.192.xx.xx
* kou-iclb01-1160157-tok05.clb.appdomain,cloud A 128.168.xx.xx

なお、公式ドキュメントを見ると[IBM Cloud の IP 範囲](https://cloud.ibm.com/docs/hardware-firewall-dedicated?topic=hardware-firewall-dedicated-ibm-cloud-ip-ranges&locale=ja#-ip)の通り、TOK05とTOK04で冗長化されているのがわかる・・・が
微妙にアドレスが違うので実際にキャプチャ等で確認するのが、確実だ。。
なお、クラシックインフラストラクチャーのICLBは自動でスケールしないので、二箇所のIPを許可しておけば問題ない。


![スクリーンショット_2020-09-07_10_35_12-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/703043/9b773517-d380-b867-60ed-268299fdebce.png)


### 分散方式アルゴリズム
`IBM Cloudポータルでの作業`

まずは分散方式アルゴリズムの変更場所から
![スクリーンショット_2020_09_07_11_29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/703043/258326d7-289e-c413-8a14-5c830dd5b0c2.png)

ここから3種類選べます。
分散方式の詳細はこちら：[IBMCloud Docs ロードバランシング方式](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-ibm-cloud-load-balancer-basics#load-balancing-methods)
![スクリーンショット_2020_09_07_11_36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/703043/a77bf9f3-e67e-3257-2dfd-fa7e4fe9c1a9.png)

分散方式の考え方はおおよそこんな感じ
![kou検証_日々更新.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/703043/18e7735e-e135-f3de-3651-8076b3be09ef.png)


#### Round Robin動作確認
`ローカル端末での作業`
綺麗に交互分散されているのがわかる。

```
% while true; do curl -w "gettime:%{time_total} " https://iclb.xcloudyx.com; done
gettime:0.060745 server 2
gettime:0.053535 server 3
gettime:0.058839 server 2
gettime:0.054132 server 3
gettime:0.057778 server 2
gettime:0.062661 server 3
gettime:0.056181 server 2
gettime:0.059273 server 3
gettime:0.052910 server 2
gettime:0.065784 server 3
```

#### Weighted Round Robin動作確認
Weightの設定はサーバインスタンスの画面から設定可能
![貼り付けた画像_2022_04_19_11_39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/703043/0b9faa7a-dcbe-dc18-eba7-d60816373b63.png)

* server2 Weight: 10
* server3 Weight: 100

設定通り、server3のweightを極端に高くしたので、9/10でserver3へアクセスしている。


```
% while true; do curl -w "gettime:%{time_total} " https://iclb.xcloudyx.com; done
gettime:0.092044 server 3
gettime:0.071006 server 3
gettime:0.053502 server 3
gettime:0.059870 server 3
gettime:0.061027 server 3
gettime:0.043230 server 3
gettime:0.047741 server 3
gettime:0.050463 server 3
gettime:0.045995 server 2
gettime:0.047547 server 3
```
#### Least Connection動作確認
綺麗に交互分散されているのがわかる。
※セッションを再利用するので、参考程度

```
% while true; do curl -w "gettime:%{time_total} " https://iclb.xcloudyx.com; done
gettime:0.382872 server 3
gettime:0.181700 server 2
gettime:0.058307 server 3
gettime:0.060519 server 2
gettime:0.074530 server 3
gettime:0.064690 server 2
gettime:0.094003 server 3
gettime:0.078819 server 2
gettime:0.063927 server 3
gettime:0.077143 server 2
```

### Session Stickiness
`ローカル端末での作業`

一意性保証方式
同じサーバに分散されないと困る場合に利用する
参考：[セッション・パーシスタンス]
(https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-advanced-traffic-management-with-ibm-cloud-load-balancer#session-persistence)

考え方はこんな感じ

![kou検証_日々更新-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/703043/c7b60d10-ea7a-dd28-bc9c-f2e79186aede.png)

#### Source IP動作確認

SourceIPで接続先サーバが固定されているため、分散方式を指定してもしっかりと固定されている。

```
while true; do curl -w "gettime:%{time_total} " https://iclb.xcloudyx.com; done
gettime:0.042918 server 2
gettime:0.046681 server 2
gettime:0.036994 server 2
gettime:0.038384 server 2
```
#### Cookie 動作確認

Cookieが埋め込まれているか確認してみる。
**Set-Cookie**で取得できていることがわかる。

```
% curl -s -I https://iclb.xcloudyx.com
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 9
Content-Type: text/html; charset=UTF-8
Set-Cookie: IBMCLB-eb186581-444a-42f1-a17a-bdf062f20d7d=7849f757-6762-4ca7-ba8e-75879caf1e5d; path=/
Cache-control: private
```

cookieはブラウザに保存されるため、curlでアクセスするとcookieがなく普通に分散されてしまう。

```
while true; do curl -w "gettime:%{time_total} " https://iclb.xcloudyx.com; done
gettime:0.054822 server 3
gettime:0.055466 server 2
gettime:0.070774 server 3
gettime:0.075539 server 2
```

そこで、一度アクセスしてcookieを保存する。
その後、保存した情報を利用することでcurlでもcookieを保持した形で動作確認可能
**-c 保存場所**のオプションでcookieをローカルに保存する。

```
% curl -c cookie.txt -s -I https://iclb.xcloudyx.com
Set-Cookie: IBMCLB-eb186581-444a-42f1-a17a-bdf062f20d7d=8a20eb90-5d25-4304-8322
```

**-b 保存したファイル**のオプションで保存したcookieを利用する
サーバがしっかりと固定されていることがわかる。

```
while true; do curl -b cookie.txt -w "gettime:%{time_total} " https://iclb.xcloudyx.com; done
gettime:0.138776 server 2
gettime:0.195687 server 2
gettime:0.317266 server 2
gettime:0.302177 server 2
```