Ciliumのネットワーク安定性向上事例：小さなコード修正で達成した驚くべき成果

 (gosuda.org)
9 ポイント 投稿者 lemonmint 2025-04-10 | 1件のコメント | WhatsAppで共有
  • 小規模なコード修正（たった1つの if 文の追加）がシステム安定性に大きく貢献したPR事例の紹介
  • bpf:nat: Restore ORG NAT entry if it's not found PRの影響力と重要性

NAT(Network Address Translation)の基本原理

  • NATは複数の機器が1つのグローバルIPを共有できるようにする技術
  • 内部デバイス（Private IP:Port）と外部インターネット間の通信を可能にする
  • NATテーブルは元のアドレスと変換後のアドレスの対応情報を保存する
  • プロセス:
    1. 内部機器が外部サーバーへの接続を試みる
    2. NATデバイスが送信元IP/ポートをグローバルIP/ポートに変換（SNAT）
    3. 外部サーバーの応答を再び内部機器向けに変換（DNAT）

KubernetesでのNAT活用

  • KubernetesでNATが重要に使われる2つの主要なケース:
    1. Podからクラスター外部への通信: Podの内部IPをノードのグローバルIPに変換
    2. NodePortを通じた外部からPodへの通信: 外部リクエストを特定のPodへルーティング

CiliumのNAT実装方式

  • 一般的にLinuxではconntrackとiptablesでNATを処理
  • CiliumはeBPF技術を使って従来のLinuxネットワークスタックをバイパス
  • CiliumはLRUハッシュマップ（BPF_MAP_TYPE_LRU_HASH）を使ってNATテーブルを直接管理

問題発生の原因

  • Lookup問題: 双方向（送信/受信）パケット処理のため同じデータを2回保存（RevSNAT）
  • LRUの限界: 限られたリソースのため使用頻度の低い項目が削除される
  • 接続損失 # Ciliumの小さなコード修正でネットワーク安定性を大きく向上させた事例

紹介: 小さなコード変更の大きな影響力

  • たった1つの if 文ブロックの追加だけでシステム安定性に非常に大きく貢献した事例
  • 該当PR: bpf:nat: Restore ORG NAT entry if it's not found
  • ネットワーク分野の非専門家にも理解できるように説明

NAT(Network Address Translation)の基本原理

  • NATは複数の機器が1つのグローバルIPを共有できるようにする技術
  • 内部のPrivate IP:Portの組み合わせを外部のPublic IP:Portにマッピングする方式で動作
  • 動作プロセス:
    • 内部機器が外部サーバーへ接続を試みる
    • NATデバイスが内部通信を外部通信へ変換（SNAT）
    • 応答が戻ると再び元の内部通信へ変換（DNAT）
    • 変換情報はNATテーブルに記録される

KubernetesでのNAT活用

  • Kubernetesは複雑なネットワーク構造を持ち、さまざまな場面でNATを活用
  • 主なNAT活用事例:
    1. Podからクラスター外部への通信: PodのプライベートIPをノードのグローバルIPに変換（SNAT）
    2. NodePortを通じた外部からPodへの通信: 外部トラフィックを適切なPodへ届けるためDNATとSNATを同時に実行

Ciliumの特別なアプローチ

  • 一般的なLinuxシステムではconntrackサブシステムとiptablesでNATを管理
  • CiliumはeBPF技術を使って従来のLinuxネットワークスタックをバイパス
  • SNAT処理のためLRUハッシュマップ（BPF_MAP_TYPE_LRU_HASH）形式でSNATテーブルを直接管理

問題の原因と症状

  • 参照（Lookup）問題:

    • NAT処理の検証のためハッシュテーブルの参照が必要
    • 高速参照のため同じデータをsrcとdstの値を反転させてRevSNATとしてテーブルに2回挿入

  • LRU(Least Recently Used)問題:

    • リソース制限によりデータがLRUロジックによって削除される可能性がある

  • 組み合わさった問題点:

    • 1つのTCP接続に対して同じデータが2回記録される
    • 2つのデータのうちどちらか一方でもLRUによって削除されると接続全体が切断される可能性がある

単純だが効果的な解決策

  • 核心となるアイデア: 一方向のパケットが観測されたら反対方向の項目も一緒に更新する
  • このシンプルなアプローチにより:
    • 双方向の項目がどちらも更新され、LRU削除の優先対象から遠ざかる
    • 片側の項目だけが削除されて通信全体が切断されるシナリオの発生可能性を低減
    • ベンチマークテストでネットワーク安定性が大幅に向上

結論と教訓

  • 複雑なシステムの中でもシンプルなアイデアが大きな変化をもたらし得ることを示す事例
  • 基本的なCS知識（NATの動作方式）に基づいて問題を解決
  • 問題回避のための別の方法: NATテーブルサイズの拡大
  • 客観的な証拠データで問題を徹底的に分析し貢献した開発者の情熱に敬意

技術的アプローチの価値

  • 問題の根本原因を理解して解決するアプローチの重要性
  • 単純なコード修正でシステム全体の安定性を大きく改善できるという教訓
  • 複雑なシステムでも基本原理を理解することの重要性

関連記事

1件のコメント

 
ethanhur 2025-04-14

素晴らしい経験をご紹介いただき、ありがとうございます！