iptablesを置き換えるBPFをコンテナネットワークに使うCilium

コンテナを用いたクラウドネイティブなシステムに移行しようとすると、従来の仮想マシンベースのシステムよりも粒度の細かいコンテナワークロードをオーケストレーションする必要がある。昨今Kubernetesが注目されているのは、そのためだ。その際にコンテナ間のネットワークをどのように構成するのか？　は、インフラストラクチャーエンジニア、ネットワークエンジニア双方にとって頭が痛い問題である。特に多くのコンテナが連携するシステムであれば、コンテナ間のトラフィックを遅延なく通信させることが重要になる。

またIstioのように、サービスメッシュとしてPodの中にProxyをサイドカーモードで構成する場合、コンテナとProxyの間にも通信が発生し、ますますオーバーヘッドが生じることになる。これに対する解決策として、BPF（Berkley Packet Filter）というLinuxカーネル内でパケットをフィルターする機能を応用してPod間のネットワークをシンプルかつ高速にするオープンソースソフトウェアが話題になっている。今回はそのソフトウェア、Ciliumについて背景と概略を紹介しよう。

まずは2018年5月にコペンハーゲンで開催されたKubeCon/CloudNativeCon EuropeでのThomas Graf氏のプレゼンテーションの動画を紹介する。これは「Cilium - Accelerating Envoy with Linux Kernel」と題されたセッションを録画したものだ。Graf氏はLinux Kernelのデベロッパーとして活躍しているエンジニアで、Red Hatを退職後に、Ciliumの開発をリードするCovalentというベンチャーを創立した。またOpen vSwitchのコントリビューターでもあるという。

KubeCon Europe 2018での講演：Cilium - Accelerating Envoy with the Linux Kernel

このセッションでGraf氏は、BPFを実装したLinuxカーネルの事例を3点紹介した。Facebook、Netflix、GoogleのそれぞれがロードバランサーやトレーシングのためにBPFを使い始めているという。これに至るには、その背景を理解するべきだろう。そのためにはCiliumのサイトにある以下の記事を参照されたい。

Facebook、Netflixなどのユースケースを紹介

Why is the kernel community replacing iptables with BPF？

以前のようにネットワーク自体もそれほど高速ではなく、トラフィックの量も少なかった時代であれば、iptablesを使って送受信をフィルターするケースは有効だった。しかしサーバーがクラスターになり、仮想マシンがコンテナになる時代においては、iptablesに記述されるルールも数百から数千行に達することから、iptablesがボトルネックになるという問題点を解説している。

それに対してクラウドネイティブな環境では、IPアドレスとポート番号を用いたルールを使うiptablesよりも、カーネル内で実行されるプログラムを使ってIDをベースに実行されるフィルタリングのほうが優れているという。特にルールの追加時にリロードが必要となるiptablesに比べて、変更が即時に反映されるという部分は、現代のインターネットビジネスには必須の要件だろう。

Ciliumを理解するために、KubeConの動画に戻って解説を続けよう。Graf氏が紹介するFacebookのユースケースによれば、FacebookはBPFをロードバランサーとして利用することでパフォーマンスが10倍以上向上したという。

Facebookでのベンチマーク

そして本来のパケットフィルタリングとしての性能比較として、2つのサーバー間でパケットを送り続けてフィルターできる数を比較したのが以下のスライドだ。

DDoSに対抗する際の性能比較

ここで分かるのは、BPFはiptablesによるフィルタリングよりも遥かに高速に処理ができているという点だ。次のスライドも性能測定のスライドだが、ここでも数倍の高速化という結果が出ている。

iptablesとBPFの比較

このグラフで右から2番目のグレーのバーがBPFをベースにしたbpfilterの値だが、確かにiptables（黄色いバー）と比較して格段に高速になっている。また一番右のバーは、BPFをNICにオフロードしたケースの値だという。SmartNICでこのフィルタリングを実行することで、システムとしては格段に負荷を減らすことが可能となる。DDoS攻撃などへの対抗策として注目されているのはこのためだ。

このグラフの元になっている記事はこれだ。

BPF， eBPF， XDP and Bpfilter… What are These Things and What do They Mean for the Enterprise？

BPFを実装する際の流れを解説したのが、次のスライドだ。

BPFを実装する際の流れ

プログラムとして実装されたルールがバイトコードに変換され、サンドボックスで安全かどうかを判定された後に、カーネル内で実行されることを解説している。

そしてCiliumにおけるBPFは、単にフィルターとして使われるのではなく、コンテナ間の通信をセキュアかつ高速にするためにも応用されている。特にGraf氏が強調しているのは、コンテナ間の通信の部分にEnvoyが利用されるユースケースだ。サービスからEnvoyに至るセッションに複数回のSocket、TCP/IP、iptablesなどを経て外部に通信されるオーバーヘッドを、Ciliumを使うことで大幅に削減できるという部分だ。

Pod内のサービスからEnvoyに至るまでにオーバーヘッドが大きいという例

このPod内の通信を、BPFによってショートカットさせることで高速化が実現される。BPFが高速であるというのはFacebookなどのユースケースでも証明されている通りだとすると、ここでもその恩恵が受けられるというのがGraf氏の強調する点である。

CiliumがSocket－Socket間通信をショートカット

サイドカーで構成された場合のパフォーマンスについて解説したのが、次のスライドだ。ここでも大幅な高速化が示されている。

サイドカー構成でも大幅な高速化を実現

最後にCiliumのアーキテクチャーと必要要件が紹介された。

Ciliumのアーキテクチャー。設定されたルールはDaemonを通じてカーネル内で実行される

Graf氏は2018年8月に開催されたOpen Source Summit NAでも、Ciliumに関するセッションを行っている。

Cilium - Bringing the BPF Revolution to Kubernetes Networking and Security

ここではKubeConの「コンテナ間の通信を高速かつ安全にするネットワークスタック」としてのCiliumから、gRPCやKafkaのような別プロトコルでも使える高速なネットワークスタックとしてセッションを行っている。Kubernetesやサービスメッシュのためのネットワークから、他のシステムでも使えるというプレゼンテーションに微妙に変化している。それが5月のKubeConから8月のOSS NAの間の3ヶ月で起きた進歩ということなのだろう。

特にKafkaについては、多数のサーバーで大量のメッセージを高速に処理する必要があるという要件から、Ciliumには絶好の対象と言える。ここであえてKafkaの名前を挙げて紹介しているのは、ビッグデータのコミュニティに対する訴求であろう。

より詳しい情報は、CiliumのGitHubページを参照されたい。

https://github.com/cilium/cilium

またオープンソースソフトウェアのフローベースのインターネットスイッチの実装であるOpen vSwitchでも、BPFベースの拡張が行われている。ヨーロッパの通信業者であるOrangeが中心となって書かれた論文が発表された。現在、Okoという名称でOpen vSwitchを拡張するというプロジェクトが立ち上がっている。

Oko：Extending Open vSwitch with Stateful Filters（PDF）

高速性と高いセキュリティを実現し、iptablesの問題点を解消したCiliumには大きな可能性が秘められている。注目のオープンソースプロジェクトと言っていいだろう。