KubeCon+CloudNativeCon North America 2025レポート 5

KubeCon North America 2025、TikTokがネットワークをCilium/IPv6に移行した苦労を解説するセッションを紹介

KubeCon North America 2025から、TikTokがネットワークをCilium/IPv6に移行した際の苦労を解説したセッションを紹介。

松下 康之 - Yasuyuki Matsushita

6:01

KubeCon+CloudNativeCon North America 2025から、ショート動画サービスのTikTokがKubernetesクラスターのネットワークスタックをすべてIPv6に移行した際の苦労を解説したセッションを紹介する。プレゼンテーションを行ったのはTikTokのJoseph Pallamidessi氏とGiri kuncoro氏だ。

●動画:TikTok's IPv6 Journey To Cilium: Pitfalls and Lessons Learned

TikTokがネットワークスタックをIPv6に移行した際の苦労を解説するセッション

TikTokがネットワークスタックをIPv6に移行した際の苦労を解説するセッション

この写真の右端に写っている白のシャツの人物がPallamidessi氏、濃紺のシャツがKuncoro氏だ。

TikTokのインフラストラクチャーは10の地域に分散された130以上のデータセンターで実装されていると説明。すべてがKubernetesによるクラウドネイティブなシステムであると説明。

TikTokの130以上のデータセンターの概要を紹介

TikTokの130以上のデータセンターの概要を紹介

すべてがオンプレミスというわけではなくパブリッククラウドも併用し、仮想マシンの上で実装されたKubernetesもあればベアメタルの上で実装されているクラスターもあると説明した。

TikTokはソフトウェアを4階層に分けて管理をしていることを簡単に説明。ここでは最上位にアプリケーション、その下にクラスター、カーネルと続き、そしてデータセンターのハードウェアが層として定義されていることを示している。

アプリケーションからデータセンターのハードウェアまで4つに分けて管理運用

アプリケーションからデータセンターのハードウェアまで4つに分けて管理運用

その上で全体として受信が20GB//秒、送信が10GB/秒というネットワークトラフィックが発生していることを紹介。ネットワークはUDPを主体として構成されており、コントロールプレーンとしてgRPCを使っているということだろう。UDPは動画配信などの低いレイテンシーが求められるアプリケーションには最適だろう。

TikTokのネットワークを解説

TikTokのネットワークを解説

そしてTikTokが求めるネットワークに関しての要件を整理。物理ネットワークを抽象化できること、高性能であること、セキュリティとオブザーバービリティが最初から備わっていること、エコシステムが活発であることなどを挙げた。

TikTokがネットワークに求める要件を整理。高性能であることが必須

TikTokがネットワークに求める要件を整理。高性能であることが必須

これらの要件を満たせるものとしてCiliumを選択したと説明。初期のテストでは良い結果が出ていたことを説明したが、この後は複数のバージョンで問題が頻発したことを説明することになる。

Ciliumをネットワークスタックとして選択。初期のテストでは良い結果が出ていたが…

Ciliumをネットワークスタックとして選択。初期のテストでは良い結果が出ていたが…

またIPv6に移行を決めたのは階層化しないフラットなネットワーク構成にしたかったこと、またIPv4のアドレスが枯渇することが想定されたからと解説した。

IPv6に移行を決めたのはアドレス枯渇が予想されたから

IPv6に移行を決めたのはアドレス枯渇が予想されたから

しかしCiliumはIPv6の実装が遅れており、完全にIPv6に移行するつなぎとしてCalicoを使ったことを説明。Ciliumへの移行はIPv4、IPv4/IPv6併用、そして最後にIPv6だけのネットワークというように段階的にテストが行われたという。

Ciliumへの移行はIPv4、IPv4/IPv6併用、そして最後にIPv6のみという段階を踏む

Ciliumへの移行はIPv4、IPv4/IPv6併用、そして最後にIPv6のみという段階を踏む

最初に遭遇した問題点は、CiliumのエージェントがIPv4のアドレスを見つけられないと停止するというバグだ。

IPv4のアドレスが構成されていないと停止してしまうCiliumのエージェント問題

IPv4のアドレスが構成されていないと停止してしまうCiliumのエージェント問題

これに加えてCiliumが持つ2つのモードのうち、Encapsulation/TunnelモードではIPv6がサポートされないという問題もあった。さらに2つ目の問題として、パケットロスが発生するという問題も発生したという。そのため2023年から始まった移行プロジェクトではCilium 1.12を使うのではなく、1.14というバージョンまで移行を待つことにしたと説明。

1.12では同じノードからのパケットがロストしてしまうという問題点が発生

1.12では同じノードからのパケットがロストしてしまうという問題点が発生

しかし1.14でもDNSに対するポリシーが動作しないという3つ目の問題点が発生。このため1.15までさらにコミュニティによる開発を待つことになったと説明。

1.14でもDNSに関する問題点が発生。2025年1月リリース予定の1.15を待つことに

1.14でもDNSに関する問題点が発生。2025年1月リリース予定の1.15を待つことに

1.15では必要なテストのうち、IPv6のための多くのテストに合格したCiliumだったが、4つ目の問題が発生してしまう。

エンドツーエンドのテストに失敗してしまう4つ目の問題が発生

エンドツーエンドのテストに失敗してしまう4つ目の問題が発生

これはユーザーからHTTPのリクエストを受けたノードではなく異なるサブネット上のノードがユーザーにレスポンスを返す場合に、リクエストが返送されずにエラーとなってしまうという問題のようだ。

4つ目の問題点に遭遇。異なるサブネットからのレスポンスが受け取れない

4つ目の問題点に遭遇。異なるサブネットからのレスポンスが受け取れない

そのためCiliumのメンテナーとのコミュニケーションを繰り返し、2025年4月にロンドンで行われたKubeCon EuropeでCiliumのコミュニティにも相談をしたという。そしてバージョン1.18でEncapsulation/Tunnelingモードでのサポートが実装されることになったという。

ロンドンで行われたKubeCon EuropeでCiliumのメンテナーに相談

ロンドンで行われたKubeCon EuropeでCiliumのメンテナーに相談

Ciliumのコミュニティからの解決策は1.19での実装

Ciliumのコミュニティからの解決策は1.19での実装

結果としてエンドツーエンドでのテストにも成功し、これでIPv6のネットワークだけでTikTokのクラスターを構成することに目途がついたと解説。

エンドツーエンドテストにも成功して目途がついた

エンドツーエンドテストにも成功して目途がついた

この結果として2025年5月の1.18、そして9月にリリースされた1.19というバージョンでIPv6だけのネットワーク構成が本番環境で可能になったと説明。

遂に本番環境でIPv6だけのCiliumによるネットワーク構成がサービスイン

遂に本番環境でIPv6だけのCiliumによるネットワーク構成がサービスイン

これでめでたしめでたしという内容ではあるが、この後、オブザーバービリティのHubbleやデバッグのためのツールについて紹介するところで最後の問題を発見してしまう。

Ciliumの純正のオブザーバビリティツール、Hubbleを紹介

Ciliumの純正のオブザーバビリティツール、Hubbleを紹介

Hubbleに関してはCiliumの主な開発を行うIsovalentがチートシートを公開しており、それが役に立ったと説明した。

●参考:Cilium Hubble Cheat Sheet

Isovalentが作成したHubbleを使うためのコツをまとめたチートシート

Isovalentが作成したHubbleを使うためのコツをまとめたチートシート

またCiliumのデバッグを行うコマンドラインツールであるcilium-dbgも紹介。そしてcilium-dbgに内在する5番目の問題に遭遇したことも紹介した。

デバッグを行うコマンドラインツールのcilium-dbgを紹介

デバッグを行うコマンドラインツールのcilium-dbgを紹介

この問題はcilium-dbgにIPv4を前提としたコードがハードコードされていたというものだ。Cilium本体はIPv6だけの運用を前提に機能改善が行われたが、関連するツール自体がIPv4前提の実装であったということになる。これについてはパッチを書いてプルリクエストを送ることで解決したという。実際、最新バージョンでマージされ解決されている。

他にもpwru(packet, where are you?から命名)というパケットを追跡するためのツールも紹介した。

パケットを追跡するためのツール、pwruを紹介

パケットを追跡するためのツール、pwruを紹介

最後にこの経験をまとめた2枚のスライドを紹介。最初のスライドでは1.18でTikTokがやりたかったIPv6だけのアドレス空間でネットワークが構成できたこと、そのためにCiliumコミュニティが力強くサポートしてくれたことなどを挙げた。

TikTokのIPv6を探求する旅も1.18で終わりを迎えた

TikTokのIPv6を探求する旅も1.18で終わりを迎えた

このために2023年に評価した1.12から2025年の1.18まで、2年という時間が経過したが、コミュニティと共同で作業することにより、K\途中で諦めなかったことを評価した。またEncapsulation/Tunnelingモードはネイティブなルーティングモードよりもシンプルでありながら高速であること、デバッグのためのツールが役に立ったことなどを説明した。

2年かけてコミュニティとともにCiliumを諦めなかったことが成功のポイントか

2年かけてコミュニティとともにCiliumを諦めなかったことが成功のポイントか

また将来の構想として、CiliumのBGPコントロールプレーンによるNative Routingモードを評価したいことなどを挙げた。同時に協力してくれたCiliumのメンテナーを紹介し、彼らの協力なくしてはこのシステムは成功しなかったと強調した。

Ciliumのメンテナーの協力なしではこの実装は困難だったと説明

Ciliumのメンテナーの協力なしではこの実装は困難だったと説明

さらにKubeCon North Americaの共催イベントとして行われたCiliumConから、IPv6だけでCiliumを実装するという同じ発想のシステムにチャレンジしていたESnetのセッションを紹介した。これはNative-Routingモードでの実装という例だが、IPv6だけで構成した例として参考になるだろう。こちらのセッションを担当したKapil Agrawal氏も会場に参加していたようで、他の参加者からも注目されていた。

ESnetのKapil Agrawal氏によるCiliumConのセッションを紹介

ESnetのKapil Agrawal氏によるCiliumConのセッションを紹介

●CiliumConのESnetの動画:IPv6 First, Not Just Ready: Kubernetes Without IPv4 Using Cilium at ESnet

ESnetの手法はCiliumのNative-RoutingによるIPv6の実装だ

ESnetの手法はCiliumのNative-RoutingによるIPv6の実装だ

このスクリーンショットは上記の動画からだが、ESnetはNative-Routingを使っているようだ。TikTokとは要件が異なるということだろう。またセッション後の質疑応答では「Ciliumでのポリシー実装はどうやるのか?」という質問に対して、Ciliumの基本機能として実装されていることを回答した。以下のリンクはCiliumのネットワークポリシーのドキュメントである。

●参考:https://docs.cilium.io/en/latest/security/policy/

TikTokという巨大なネットワークアプリケーションを運用するネットワークがIPv6で実装されているのは、興味深いユースケースだろう。何よりも遭遇した問題点を2年掛けて一つずつ潰していったチームとコミュニティの努力が評価されるべき内容となった。アドレス枯渇への対処やレイテンシーの低減を目指す使い方として参考にして欲しい。

この記事をシェアしてください

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored