KubeCon+CloudNativeCon North America 2025から、ショート動画サービスのTikTokがKubernetesクラスターのネットワークスタックをすべてIPv6に移行した際の苦労を解説したセッションを紹介する。プレゼンテーションを行ったのはTikTokのJoseph Pallamidessi氏とGiri kuncoro氏だ。
●動画:TikTok's IPv6 Journey To Cilium: Pitfalls and Lessons Learned
この写真の右端に写っている白のシャツの人物がPallamidessi氏、濃紺のシャツがKuncoro氏だ。
TikTokのインフラストラクチャーは10の地域に分散された130以上のデータセンターで実装されていると説明。すべてがKubernetesによるクラウドネイティブなシステムであると説明。
すべてがオンプレミスというわけではなくパブリッククラウドも併用し、仮想マシンの上で実装されたKubernetesもあればベアメタルの上で実装されているクラスターもあると説明した。
TikTokはソフトウェアを4階層に分けて管理をしていることを簡単に説明。ここでは最上位にアプリケーション、その下にクラスター、カーネルと続き、そしてデータセンターのハードウェアが層として定義されていることを示している。
その上で全体として受信が20GB//秒、送信が10GB/秒というネットワークトラフィックが発生していることを紹介。ネットワークはUDPを主体として構成されており、コントロールプレーンとしてgRPCを使っているということだろう。UDPは動画配信などの低いレイテンシーが求められるアプリケーションには最適だろう。
そしてTikTokが求めるネットワークに関しての要件を整理。物理ネットワークを抽象化できること、高性能であること、セキュリティとオブザーバービリティが最初から備わっていること、エコシステムが活発であることなどを挙げた。
これらの要件を満たせるものとしてCiliumを選択したと説明。初期のテストでは良い結果が出ていたことを説明したが、この後は複数のバージョンで問題が頻発したことを説明することになる。
またIPv6に移行を決めたのは階層化しないフラットなネットワーク構成にしたかったこと、またIPv4のアドレスが枯渇することが想定されたからと解説した。
しかしCiliumはIPv6の実装が遅れており、完全にIPv6に移行するつなぎとしてCalicoを使ったことを説明。Ciliumへの移行はIPv4、IPv4/IPv6併用、そして最後にIPv6だけのネットワークというように段階的にテストが行われたという。
最初に遭遇した問題点は、CiliumのエージェントがIPv4のアドレスを見つけられないと停止するというバグだ。
これに加えてCiliumが持つ2つのモードのうち、Encapsulation/TunnelモードではIPv6がサポートされないという問題もあった。さらに2つ目の問題として、パケットロスが発生するという問題も発生したという。そのため2023年から始まった移行プロジェクトではCilium 1.12を使うのではなく、1.14というバージョンまで移行を待つことにしたと説明。
しかし1.14でもDNSに対するポリシーが動作しないという3つ目の問題点が発生。このため1.15までさらにコミュニティによる開発を待つことになったと説明。
1.15では必要なテストのうち、IPv6のための多くのテストに合格したCiliumだったが、4つ目の問題が発生してしまう。
これはユーザーからHTTPのリクエストを受けたノードではなく異なるサブネット上のノードがユーザーにレスポンスを返す場合に、リクエストが返送されずにエラーとなってしまうという問題のようだ。
そのためCiliumのメンテナーとのコミュニケーションを繰り返し、2025年4月にロンドンで行われたKubeCon EuropeでCiliumのコミュニティにも相談をしたという。そしてバージョン1.18でEncapsulation/Tunnelingモードでのサポートが実装されることになったという。
結果としてエンドツーエンドでのテストにも成功し、これでIPv6のネットワークだけでTikTokのクラスターを構成することに目途がついたと解説。
この結果として2025年5月の1.18、そして9月にリリースされた1.19というバージョンでIPv6だけのネットワーク構成が本番環境で可能になったと説明。
これでめでたしめでたしという内容ではあるが、この後、オブザーバービリティのHubbleやデバッグのためのツールについて紹介するところで最後の問題を発見してしまう。
Hubbleに関してはCiliumの主な開発を行うIsovalentがチートシートを公開しており、それが役に立ったと説明した。
またCiliumのデバッグを行うコマンドラインツールであるcilium-dbgも紹介。そしてcilium-dbgに内在する5番目の問題に遭遇したことも紹介した。
この問題はcilium-dbgにIPv4を前提としたコードがハードコードされていたというものだ。Cilium本体はIPv6だけの運用を前提に機能改善が行われたが、関連するツール自体がIPv4前提の実装であったということになる。これについてはパッチを書いてプルリクエストを送ることで解決したという。実際、最新バージョンでマージされ解決されている。
他にもpwru(packet, where are you?から命名)というパケットを追跡するためのツールも紹介した。
最後にこの経験をまとめた2枚のスライドを紹介。最初のスライドでは1.18でTikTokがやりたかったIPv6だけのアドレス空間でネットワークが構成できたこと、そのためにCiliumコミュニティが力強くサポートしてくれたことなどを挙げた。
このために2023年に評価した1.12から2025年の1.18まで、2年という時間が経過したが、コミュニティと共同で作業することにより、K\途中で諦めなかったことを評価した。またEncapsulation/Tunnelingモードはネイティブなルーティングモードよりもシンプルでありながら高速であること、デバッグのためのツールが役に立ったことなどを説明した。
また将来の構想として、CiliumのBGPコントロールプレーンによるNative Routingモードを評価したいことなどを挙げた。同時に協力してくれたCiliumのメンテナーを紹介し、彼らの協力なくしてはこのシステムは成功しなかったと強調した。
さらにKubeCon North Americaの共催イベントとして行われたCiliumConから、IPv6だけでCiliumを実装するという同じ発想のシステムにチャレンジしていたESnetのセッションを紹介した。これはNative-Routingモードでの実装という例だが、IPv6だけで構成した例として参考になるだろう。こちらのセッションを担当したKapil Agrawal氏も会場に参加していたようで、他の参加者からも注目されていた。
●CiliumConのESnetの動画:IPv6 First, Not Just Ready: Kubernetes Without IPv4 Using Cilium at ESnet
このスクリーンショットは上記の動画からだが、ESnetはNative-Routingを使っているようだ。TikTokとは要件が異なるということだろう。またセッション後の質疑応答では「Ciliumでのポリシー実装はどうやるのか?」という質問に対して、Ciliumの基本機能として実装されていることを回答した。以下のリンクはCiliumのネットワークポリシーのドキュメントである。
●参考:https://docs.cilium.io/en/latest/security/policy/
TikTokという巨大なネットワークアプリケーションを運用するネットワークがIPv6で実装されているのは、興味深いユースケースだろう。何よりも遭遇した問題点を2年掛けて一つずつ潰していったチームとコミュニティの努力が評価されるべき内容となった。アドレス枯渇への対処やレイテンシーの低減を目指す使い方として参考にして欲しい。
