Alibaba Cloud SLB のパーシステンスについて

この記事は Alibaba Cloud の日本サイトの環境（ドキュメントやアカウント、そのアカウントでの検証結果）に基づいて記載しています。　日本サイトと国際サイトでは各プロダクトごとに提供機能が一部異なることがあります（そのほとんどは国際サイトの方が日本サイトよりも多機能になっている）。記事の内容は適宜最新化する予定です。

2019年3月27日にAlibaba Cloud SLB の機能追加のアナウンスがありました。リスナーの分散アルゴリズムに”コンシステンシーハッシュ法 (CH)”が追加されたとのこと。　　追加されたCH法の中身を紹介しつつAlibaba Cloud SLBで利用できる分散アルゴリズムやパーシステンスについてまとめてみました。

1. コンシステンシーハッシュ法 (CH)とは？

まずはAlibaba Cloudのドキュメントセンターを確認します。 Alibaba Cloud SLBのTCPリスナーのスケジュールアルゴリズムに以下の記載内容を確認しました。

2つの方式を選択出来るようです。　1つ目は”送信元IP”となり、要は送信元IPでハッシュを作り、それで照合かけて、同じ送信元IPからの通信は同じバックエンドサーバへ転送するという動作です。　2つ目は”タプル”で、4つの情報でハッシュを構成することになります。

[コンシステンシーハッシュ法 (CH)]:
[送信元 IP]: 送信元 IP アドレスに基づいたコンシステントハッシュ。同一の送信元 IP アドレスは、同一のバックエンドサーバーにスケジュールされます。
[タプル]: 四元数 (送信元 IP + 宛先 IP + 送信元ポート + 宛先ポート) に基づいたコンシステントハッシュ。同一のストリームは、同一のバックエンドサーバーにスケジュールされます。
https://jp.alibabacloud.com/help/doc-detail/85995.htm

コンシステンシーハッシュ法はその名の通りでハッシュ法です。詳しくは以下のウィキペディアなど確認してみてください。

URLはこちら

とりあえず、従来のアルゴリズムにハッシュ方式が加わったことがわかりました。

2. SLBで利用可能な分散アルゴリズム

Alibaba Cloud SLBで利用可能なアルゴリズムは以下の通りです。　また、個人的な経験にもとづくものですが適用シーンも追記してみました。

CH法が追加された一番のメリットはパーシステンスを制御できることですね。

アルゴリズム	説明	適用シーン
ラウンドロビン	バックエンドサーバーへ均等かつ順次に配信	・バックエンドサーバの性能が同じ・静的なWebアクセスなど平均的な処理量が均衡する場合
重み付きラウンドロビン (WRR)	重みの大きなバックエンドサーバーは、重みの小さなバックエンドサーバーより、多くのリクエストを受信	・バックエンドサーバの性能に差異がある場合・カナリアリリース
重み付け最小接続数 (WLC)]	重みの大きいサーバーは、一度に受信できる接続数の割合が高くなり、重みの値が同じ場合、接続数の少ないバックエンドサーバーの方が、より頻繁に (そして高い確率で) アクセスされる	・接続数を均等にしたい場合
コンシステンシーハッシュ法 (CH) [送信元 IP]	送信元 IP アドレスに基づいたコンシステントハッシュ。同一の送信元 IP アドレスは、同一のバックエンドサーバーにスケジュールされる	・送信元IPベースのパーシステンスが必要な場合
コンシステンシーハッシュ法 (CH) [タプル]	四元数 (送信元 IP + 宛先 IP + 送信元ポート + 宛先ポート) に基づいたコンシステントハッシュ。同一のストリームは、同一のバックエンドサーバーにスケジュールされる	・NAT環境など送信元IPベースでは偏りが発生する場合

しかし、CH法が追加される前はパーシステンスは実現できなかったのでしょうか？　答えとして、TCPのセッションレベルのパーシステンスは構成可能でした。　

実際のコンソール画面を紹介します。　”セッション維持の有効化”、これを有効にすることでセッションレベルのパーシステンスを実現することが出来ます。

”セッション維持の有効化”の横の？アイコンをマウスカーソルを合わせてヘルプを確認します。　”tcpプロトコルのセッションは同じIPアドレスに基づいて維持され、同じIPアドレスからのリクエストは同じバックエンドクラウドサーバーが受け取ります”と説明も確認出来ます。

TCPベースのセッション維持ですので、リスナープロトコルでUDPを利用する場合は当然利用出来ません。以下実際の設定画面ですが、”セッション維持の有効化”は表示されません。

リスナープロトコルを”HTTP”や”HTTPS”にした場合は”セッション維持の有効化”は可能ですがCookieを利用することが前提条件となります。

また、CH法の利用にはSLBの上位グレード（パフォーマンス保証型）の利用が必要です。　共有型ではCH法は利用出来ないことに注意が必要です。

3. SLBで実現できるパーシステンスのマトリックス

Alibaba Cloud SLBのパーシステンスはセッションレベルとCH法の2つの実現方式があることがわかりました。　また、CH法を利用するにはインスタンスタイプに条件があることもわかりました。　さらにリスナープロトコル（TCP/UDP/HTTP/HTTPS）を考慮する必要もあります。　そしてSLBインスタンスはイントラネットとインターネットの2種類あることも忘れてはいけません。

ややこしくなってきたのでマトリックスに整理していきます。

3.1. CH法を利用できるSLBインスタンス

スモールからCH法を利用できることを確認しました。　共有型もスモールも料金は同じなので基本的に”スモール”を選ぶのがよいかと。　なお、イントラネットでは共有型もスモールもインスタンスの料金は無料です。

インスタンスタイプ	イントラネット	インターネット
共有型	N/A	N/A
スモール	利用可能 ※1	利用可能 ※1
スタンダードI	利用可能 ※2	利用可能 ※2
スタンダードII	利用可能 ※2	利用可能 ※2
アドバンスドI	利用可能 ※2	利用可能 ※2
アドバンスドII	利用可能 ※2	利用可能 ※2
スーパー	利用可能 ※2	利用可能 ※2

※1 実際のコンソールからSLBを購入し設定画面を確認

※2 スタンダードIより上のモデルは実際の購入での確認は未実施（パフォーマンスが保証されたインスタンスが利用条件でスモールがOKであれば上位タイプもOKのはず）

3.2. リスナープロトコルのパーシステンス

リスナープロトコルのパーシステンスをまとめました。イントラネットとインターネットで違いはありませんでした。　また、Small以上のタイプは実際の画面では確認していませんがおそらくSmallと同じになります。

3.2.1. イントラネット-共有型

	TCP	UDP	HTML	HTTPS
セッション維持の有効化	送信元IP	N/A	Cookie	Cookie
CH法	N/A	N/A	N/A	N/A

3.2.2. イントラネット-Small

Share型ではN/AだったUDPのセッション維持が可能となっています。　また、CH法でも”QUIC ID”が選択肢として追加されています。

	TCP	UDP	HTML	HTTPS
セッション維持の有効化	送信元IP	IPアドレス（CH法）	Cookie	Cookie
CH法	送信元IP タプル	QUIC ID 送信元IP タプル	N/A	N/A

3.2.3. インターネット-共有

	TCP	UDP	HTML	HTTPS
セッション維持の有効化	送信元IP	N/A	Cookie	Cookie
CH法	N/A	N/A	N/A	N/A

3.2.4. インターネット-Small

	TCP	UDP	HTML	HTTPS
セッション維持の有効化	送信元IP	IPアドレス（CH法）	Cookie	Cookie
CH法	送信元IP タプル	QUIC ID 送信元IP タプル	N/A	N/A