A High-Speed Load-Balancer Design with Guaranteed Per-Connection-Consistencyのメモ
どんなもの？
スケーラブルでバックエンドへのバランシングを公平に行うロードバランサのメカニズムの提案 GoogleのMaglevなどのロードバランサはPer-Connection-Consistencyを可能な限り確保するために，ハッシュを用いてバックエンドを決定してバランシングしている． 毎回ハッシュを用いてバランシングしているためMaglevでは最大で30%も偏ったバックエンドの選択を行ってしまう事がある． そこで，この論文ではバックエンドの選択が公平でPer-Connection-Consistencyを保証したロードバランサの提案を行っている．
先行研究と比べてどこがすごい？
毎回ハッシュを用いてバランシングしているためMaglevでは最大で30%も偏ったバックエンドの選択を行ってしまう事がある． この論文ではスケーラブルで，バックエンドの選択が公平なロードバランサを提案している．
技術や手法のキモ
一般的なロードバランサは以下のようなアーキテクチャで動作している．
基本的にストレートフォワードにバックエンドを決定していく，
提案手法のロードバランサでは，以下のようにパケットを処理する．
提案手法は最初のパケットに対しては，公平なアルゴリズムを用いてバックエンドを決定する．
そして，戻りパケットを解析し，バックエンドの情報をcookieとしてパケットに埋め込む．
二回目以降は埋め込まれたcookieの情報を用いて，バックエンドを算出しパケットをバックエンドにバランスする，
LBはスケールする時にこのバックエンドのテーブルだけを共有すればいいため，スケーリングも容易になる．
どうやって有効だと検証した？
実際に実装しベンチマークをとった．
提案手法は，性能もそこそこ出ており，バックエンドの選択が公平で，バックエンドのロードアベレージのばらつきも少ないことを確認した．
議論はある？
パケットにCookieを付加することがインターネットで可能なのかという事について． QUICの場合は，QUICの connection-id を使用する事が出来る ただ，TCPの場合には，TCP timestamp 拡張を使用する必要があり，これが動作するのかは疑問が残る
個人的にはDDoS攻撃には、Cookieを計算するためのhash関数をリバースエンジニアリングする必要があるからDDoSはstatelessの物と変らないという事になっているが、これは本当かなぁとちょっと思う。 もちろん、理論上正しくはそうかもしれないが、それをちゃんと実装出来ている物をあまり見た事がない。(Bindとかも常にこういう問題を出し続けているし、hash計算の失敗によるDoSは常に見付かり続けているので)
この構成を作るには、MSのAnantaみたいな構成を作る必要があるので、MaglevでL3DSRをやっているような構成だと使うのは難しい所がある。 結構、単純にLBを作るのではなく、CloudのD-Planeとしてまとまった物を作る必要がありそう。