IBM Cloud Internet Services (CIS) のグローバル・ロード・バランサーで地理的経路（Geo routes）を設定する

# 地理的経路（Geo routes）について

IBM Cloud Internet Services (CIS) のグローバル・ロード・バランサーには、クライアントに近いオリジンサーバーにルーティングしてくれる、地理的経路（Geo routes）というオプション機能があります。（オプションと言っても、特に追加料金は発生しません！）

例えば、この記事で今から説明するように、日本にあるクライアントは東京DCのオリジンサーバーに行き、ワシントンにあるクライアントはダラスDCのオリジンサーバーに行き、パリにあるクライアントはフランクフルトDCのオリジンサーバーに行く、という設定が可能です。

このオプションを使わない場合は、シンプルに優先順位の設定に従って、例えば普段は優先順位の最も高い東京DCのオリジン、東京がダウンしたら次の優先順位のダラスDCのオリジン、というように切り替わります。

# 環境の準備

・オリジンサーバーとして、東京DC、ダラスDC、フランクフルトDCに1台ずつウェブサーバーを作成。
どのオリジンからの配信か分かるように、テストページの記載はそれぞれ変えています。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/981832df-7451-5593-ba73-02035e31f90b.png)

・GLBのヘルス・チェックは index.html に対して実施。間隔やタイムアウトはデフォルト値。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/7d472b3f-f668-08cc-9eaa-3cd38c72f7a2.png)

・GLBの起点プールを3つ作成し、それぞれのプールに1台ずつオリジンサーバーを配置。
　・pool-apに東京DCのサーバー
　・pool-usにダラスDCのサーバー
　・Pool-euにフランクフルトDCのサーバー

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/2b947ba0-83f2-96ac-2285-97941c51427d.png)
（この画面、日本語表示だと正常なのに赤で違和感がありますが、英語表示にすると、きちんとグリーンになっています...）
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/2c4543c7-4add-6aa7-94d4-b4051b0c0aa5.png)


pool-apの設定は下記です。他のpoolにも同様に、各エリアのオリジンを1台ずつ配置します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/acafc4ae-f75a-9b56-0c50-79efb29c25d8.png)

・GLB配下に3つのプールを配置。優先順位は pool-ap > pool-eu > pool-us の順
地理的経路（Geo routes）の設定箇所もこの画面にありますが、まだ設定はしていません。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/d659026e-5821-13f9-8d9f-a64c54f40c49.png)


GLBの設定方法は、下記もご参照ください。
https://console.bluemix.net/docs/infrastructure/cis/glb-setup.html#set-up-and-configure-your-load-balancers
https://qiita.com/y_tama/items/7e1ddd5dc94990835311

今の設定内容の場合、クライアントの地理的な位置に関わらず、シンプルに優先順位の設定に従って、普段は優先順位の最も高い東京DCのオリジン、東京がダウンしたら次の優先順位のフランクフルトDCのオリジン、というように切り替わります。

# 地理的経路（Geo routes）の設定

グローバル・ロード・バランサーの設定画面で、地理的経路の設定を行います。初期は、何も設定されていません。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/8fe64b09-7fba-b797-c3dc-8cd28a047577.png)

経路の追加で、「北アメリカ東部」を選択し、「追加」ボタンを押下します。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/fe7230e9-3648-cc99-bca9-803dc536db00.png)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/39a4deef-f6b3-4d42-272f-4411d7ca8750.png)

上記の「プールの追加」から、「起点プールの追加」のポップアップを開き、pool-usを追加します。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/bb5be4d4-6e6a-aafc-69b4-3205b8a4d988.png)

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/c0f04503-45a5-27a7-984d-4bb5782a5989.png)

同様に、「西ヨーロッパ」の地理的経路を追加し、その中に「pool-eu」を追加します。
同様に、「北東アジア」の地理的経路を追加し、その中に「pool-ap」を追加します。
（地理的経路の作成の順番は、特に動作には影響ありません）

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/685b5f13-b7c3-f5f4-2f11-e8f34a30cabb.png)

上記の例では各経路に1つのpoolですが、もしその1つがダウンすると、他のpoolに割り振られるのではなく、エラーとなります。各経路内で可用性を高める場合は、各経路の中にプールを追加します。例えば下記では、日本からのアクセスは通常はpool-ap（東京DC）のオリジンに行き、それがダウンした場合、pool-us（ダラスDC）のオリジンに行きます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/7998d843-434d-1f7c-bc0d-82465c92e42e.png)


# 動作確認

下記のように、クライアントに近いオリジンにルーティングされている事が分かります。

【ワシントンの環境からアクセス】→ ダラスのオリジンにルーティングされた。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/584b19c0-e148-bdd5-8141-715da6813444.png)

【パリの環境からアクセス】→ フランクフルトのオリジンにルーティングされた。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/84ae1415-fb0c-9a4e-000c-fba2ccbe0e83.png)

【東京の環境からアクセス】→ 東京のオリジンにルーティングされた。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/59627/1ce5b6e4-d20a-4ef3-55bf-820aa7f29836.png)

なお、GLBのFQDN（今回はlb01.tama0921.com）を名前解決した際の実IPアドレスは、いずれの環境で名前解決しても同一のIPアドレスとなり、pingの応答も大変早いです。グローバル・ロード・バランサーへのアクセスも、anycast が使われている事が分かります。

```
>nslookup lb01.tama0921.com
Server:  UnKnown
Address:  10.0.80.11

Non-authoritative answer:
Name:    lb01.tama0921.com
Addresses:  2400:cb00:2048:1::6814:9b3
          2400:cb00:2048:1::6814:ab3
          104.20.10.179
          104.20.9.179
>ping lb01.tama0921.com

Pinging lb01.tama0921.com [104.20.10.179] with 32 bytes of data:
Reply from 104.20.10.179: bytes=32 time=1ms TTL=60
Reply from 104.20.10.179: bytes=32 time=1ms TTL=60
Reply from 104.20.10.179: bytes=32 time<1ms TTL=60
Reply from 104.20.10.179: bytes=32 time<1ms TTL=60

Ping statistics for 104.20.10.179:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms
```

CISとanycastについては、下記もご参照ください。
https://qiita.com/y_tama/items/11615687eaa24cd1d67b

このように、グローバル・ロード・バランサーの地理的経路（Geo routes）の機能を使って、クライアントに近いオリジンサーバーにルーティングすることで、ウェブサイトの応答速度を向上させたり、エリアごとにコンテンツを変えるといった事も可能になります。