PR

eBPF Summit、Verizon-Mediaが利用するKatranのセッションを紹介

2021年12月24日(金)
松下 康之 - Yasuyuki Matsushita
eBPF Summit 2021からVerizon-MediaによるL4ロードバランサーのセッションを紹介する。

eBPF Summit 2021から、日本以外でYahoo!ブランドのサービスを展開するVerizon-Mediaのセッションを紹介する。これはFacebookが開発し、オープンソースソフトウェアとして公開するeBPFをベースにしたL4ロードバランサーであるKatranに関するユースケースだ。

以下の動画の53分46秒から開始するセッションとなる。セッションを担当したのはKarthikeyan Thangaraji氏だ。

動画:eBPF Summit 2021 - Day 2

Yahoo!で使われているL4 Load Balancerを解説

Yahoo!で使われているL4 Load Balancerを解説

Katranそのものについては、開発したFacebookが公開しているブログ記事を参照されたい。

参考:Open-sourcing Katran, a scalable network load balancer

FacebookがL4ロードバランサーを作った背景

FacebookがL4ロードバランサーを作った背景

FacebookはKatranの前にもソフトウェアベースのロードバランサーを開発、利用していた。しかしパケット処理のCPU負担が高く、そのためにロードバランサーをバックエンドサーバーと共存させることが難しかった。その結果として急なアクセスピークに対応できなかったという。このことが、新しくXDP(eXpress Data Path)とeBPFを使ったロードバランサーをゼロから開発した理由だ。

またKatranが高速に処理が行えるという点に関しても、Facebookのブログでは以下の図を使って解説を行っている。

バックエンドのプロセスと通信する時以外はユーザースペースにパケットが出ない設計

バックエンドのプロセスと通信する時以外はユーザースペースにパケットが出ない設計

ここではロードバランサーとバックエンドのプロセスが並存するサーバーにおいて、そのサーバーローカルに実行されているプロセスと通信する時のみ、カーネルスペースからユーザースペースにパケットが渡される形になる。他のサーバーにルートさせる場合は、カーネルで実行されるeBPFのプログラムだけで処理が完了することになり、高速であるという。

ここからVerizon-Mediaのセッションに戻ろう。

ハードウェアベースのロードバランサーを使っていた時のマイナス点

ハードウェアベースのロードバランサーを使っていた時のマイナス点

ハードウェアベースのロードバランサーではダイナミックな構成変更ができず、バックエンドサーバーの構成も固定されており、オートスケールするできなかったという点を挙げて、ハードウェアベースのロードバランサーではYahoo!の求める運用ができなかったことを説明した。

Kubernetesのバックエンドに使われるKube-Proxyのマイナス点

Kubernetesのバックエンドに使われるKube-Proxyのマイナス点

またYahoo!のバックエンドはKubernetesベースであるため、デフォルトのロードバランサーKube-Proxyも検討された。しかしKube-Proxyは台数が少ない場合には問題ないが、iptablesベースであるためにサーバー台数が増えた場合の性能劣化が激しかったことを解説した。

CiliumをKubernetesのロードバランサーに採用

CiliumをKubernetesのロードバランサーに採用

CiliumがL4ロードバランサーとして選ばれた理由は、主にFacebookが挙げた内容と同じで、コモディティハードウェアにロードバランサーとアプリケーションを共存させることができたこと、XDPによってハードウェアベースのロードバランサーと性能面で劣らなかったこと、Kubernetesとの共存がスムーズだったことなどを挙げた。

Yahoo!のネットワーク構成

Yahoo!のネットワーク構成

ここではVerizon-Mediaが利用するYahoo!のためのネットワーク構成を解説。スパイン、リーフ、トップオブラックのスイッチ、そしてサーバーで構成されている。

Ciliumのロードバランサーとしての性能を比較

Ciliumのロードバランサーとしての性能を比較

このスライドではPodに直接パケットを送信した場合とCiliumを利用した場合のオーバーヘッドについて解説している。Ciliumを使った場合でもオーバーヘッドは非常に小さかったという。

最後に今後の予定を紹介。

Verizon-Mediaの今後の予定を紹介

Verizon-Mediaの今後の予定を紹介

現在はまだ2つのデータセンターでのみ実装され、アプリケーションとしてもまだ1つでしか本番稼働していないが、FY2020の第3四半期、第4四半期にはすべてのワークロードをCiliumベースのロードバランサーで処理するようになるだろうと語った。

日本のYahoo! Japanとは名称以外何も共通するものがないと思われるシステムを運用するVerizon-Mediaだが、Facebookの経験を自社に上手く展開したユースケースと言えるだろう。

基本的なテクノロジーであるeBPFを普及するための非営利団体であるeBPF FoudationにはFacebook、Google、Microsoft、Isovalentがプラチナムメンバー、Netflixがゴールドメンバーとなっている。今後、利用が拡がるに従って、メンバーシップやエコシステムも拡がっていくと思われる。2021年9月9日にAWSがEKSをオンプレミスでも実装するEKS Anywhereにおいて、Ciliumを標準のネットワークスタックとして採用することをIsovalentがブログで発表した。3大パブリッククラウドベンダーがCiliumをサポートしていることは大きな意味がある。

参考:AWS picks Cilium for Networking&Security on EKS Anywhere

eBPFとは何か?については以下の公式サイトを参照されたい。

参考:What is eBPF

ロードバランサーのKatranの公式GitHubは以下の通り。

Katranの公式GitHub:https://github.com/facebookincubator/katran

著者
松下 康之 - Yasuyuki Matsushita
フリーランスライター&マーケティングスペシャリスト。DEC、マイクロソフト、アドビ、レノボなどでのマーケティング、ビジネス誌の編集委員などを経てICT関連のトピックを追うライターに。オープンソースとセキュリティが最近の興味の中心。

連載バックナンバー

サーバー技術解説

Tigeraのアドボケイトが、x86とARMのマルチアーキテクチャークラスターを解説

2022/4/7
ARMの優位性を解説しながら、ARMをx86クラスターに追加するマルチアーキテクチャークラスターを、デモを用いて解説。
システム開発イベント

KubeCon NA 2021からサービスメッシュの2セッションを紹介

2022/3/18
KubeCon NA 2021からサービスメッシュのLinkerdの最新情報とIstioを使ったユースケースのセッションを紹介する。
セキュリティイベント

KubeCon NA 2021、ソフトウェア開発工程のタンパリングを防ぐSLSAを解説

2022/3/9
KubeCon NA 2021のプレカンファレンスから、ソフトウェアサプライチェーンを実装するフレームワークSLSAを取り上げたセッションを紹介する。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています