MultipathTCP + 分散型ロードバランサー(1)
May 13, 2021
TL;DR
MPTCP と Maglev のような分散型ロードバランサーはアーキテクチャ的に組み合わせるのに無理がある。
ありあわせのソフトウェア(OSS 等) で実現するのは 不可能ではないが、懸念点が多い。
革新的なベストプラクティスはまだない。
はじめに
自分が卒論で書いた内容を備忘録とともに供養のためにまとめています。
振り返りながら 3 ヶ月後くらいに書いているので情報の正確性は各自で調べてください。
MPTCP
複数経路を使って 1 本の TCP コネクションを確立するためのプロトコル。
(https://asnokaze.hatenablog.com/entry/2017/07/20/220218)
具体例を上げるとスマホで Wifi+LTE で通信をするとかに使われる。実際に Siri とかはやってるらしい。 (*1)
Linux5.6 からカーネルに取り込まれた模様(*2)。Linux に取り込まれたおかげでサーバー対応がしやすくなって今後実用例が増えるかもしれない。
後述する実験では mainline に取り込まれた MPTCP 実装ではなく、カスタムカーネルの MPTCP 実装(*3)を使った。
分散型ロードバランサー
所謂今流行りの モダンなロードバランサー。
高速パケット処理技術(xdp/dpdk/netmap)等を使ってソフトウェアでバランシングする方式。
実装としては Facebook のkatran、vpp の lb モジュールなどが有名所。
複数台で分散して動作し、スケールアウトが用意で、全部が active/active で動作する。
そのため、分散型ロードバランサー とか N+1ロードバランサー とか言われる。
(卒論で N+1 ロードバランサーという言葉を使おうとしたら突っ込まれたからここでは分散型を多用している)
(卒論で使った図)
これらのロードバランサーでは TCP セッションは終端せず、ステートレスに動作し、サーバー上で TCP セッションを終端する。
ハッシュを使いバランシング先を決めることで、どの LB にパケットがルーティングされても唯一のサーバーに届くように一貫性を保っている。
(Maglev や Consistent Hash など特殊なハッシュ法を利用することでロードバランサーの増減にもある程度耐性がある)
あくまでもロードバランサーは L4 情報を見て、バックエンドサーバーにフォワードしているだけである。
MultipathTCP + 分散型ロードバランサーの問題点
上記の 2 つを混ぜ合わせ、MPTCP を分散型ロードバランサーで使うことを考えてみる。
何も考えず、２つのインターフェースを利用し、ロードバランサーを利用しようとすると、１つ目のインターフェースからの通信と２つ目のインターフェースからの通信ではフローが違うため、下の図のように違うサーバーへ届く可能性が高い。
もちろんこのケースでは２つ目の通信は正常に行えず、Connection Refusedになる。
そのため、これを正しくルーティングするための何かしらの手法が必要となってくる
MultipathTCP + 分散型ロードバランサー(2) に続く