Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kubernetesと4万コンテナで挑む!IoT負荷試験の裏側【SORACOM Discove...

Kubernetesと4万コンテナで挑む!IoT負荷試験の裏側【SORACOM Discovery 2025】

SORACOMを支える「コアネットワーク」の安定稼働には日々の試験が不可欠です。IoTトラフィックは人向けとは異なり「狭帯域・多接続」という特性があり、Kubernetesによる4万超のコンテナを用いてこの特性を再現しています。本セッションではこの負荷試験基盤を支える技術と、その裏側の工夫を紹介します。

株式会社ソラコム ソフトウェアエンジニア 宮 太地

Avatar for SORACOM

SORACOM PRO

July 30, 2025
Tweet

More Decks by SORACOM

Other Decks in Technology

Transcript

  1. IoT負荷試験のモチベーション ▪ 世界中のIoTデバイスを800万回線以上 ➢ ここ10年間で顧客数・回線数・通信量が飛躍的に増加 ▪ PGW – モバイルコアの心臓部 ➢

    3G~5Gトラフィックを捌く自社開発ソフトウェアルータ ➢ 世界5リージョン、2000台以上のEC2インスタンスで稼働 ▪ アジャイルなソフトウェア開発 ➢ 通常2週間ごとのリリース(新機能・安定性改善) これら規模・複雑性・開発速度を支え、リグレッションを防ぐ ベンチマークが不可欠
  2. PGW、ミクロにみるか?マクロにみるか? 本セッション のおはなし マ イ ク ロ マ ク ロ

    RustでPGW を再実装!! ソラコム辻 Cトラック 17:00~17:20 ▪ Micro-benchmarking ➢ 関数レベルの呼び出しコスト分析 • PGWコードベースに内包 • ハーネスはCriterion.rsを採用(単位:μsかKelem/sec) ▪ Macro-benchmarking ➢ C-Planeベンチマーク • Create Session Requestなどの呼処理能力(単位:rps) ➢ U-Planeベンチマーク • L3/L4のトラフィック転送能力(単位:bps)
  3. U-Planeベンチマーク要件 ▪ 一般的なキャリアネットワーク ➢ RFC2544, 8239等準拠のテストシナリオ ➢ Cisco TRexなどDPDKベースの広帯域トラフィックジェネレータ ▪

    IoTプラットフォーム特有の追加要件 ➢ 狭帯域かつ(超)多接続なテストシナリオ • s1.slow (=128kbps) で 100,000 UEs の同時接続性能をみたい! ➢ 公平制御アルゴリズムの検証 • 一部のUEだけ極端なパケットロス、ジッタが発生していないか?
  4. 理想のベンチマーク基盤をもとめて 1. 繰り返し性・再現性 • 完全にコード化されたベンチマークロジック。高精度で信頼できるテスター • 整備されたタスクランナーと簡潔な操作マニュアル 2. スケーラビリティ •

    1~数万UEs。1~数Gbps。必要なコンピュートを必要なタイミングで自動デプロイ • コンテナベースアーキテクチャ。AWSネイティブなインテグレーション 3. コスト最適性 • Terraformで構成管理された使い捨て可能ベンチマーク基盤 • Spotインスタンスの使用。自動進行するテストでエンジニアの張り付きが不要 4. データ永続性 • 標準的なバイナリデータとして書き出し。ダッシュボード同梱でコンテナ化 • 5分前に実施した最新のテスト結果も、半年前の結果も、同じ操作で比較分析可能
  5. ハイレベルアーキテクチャ ②擬似UEトラフィック生成 ①シナリオ翻訳 ③メトリクス収集 ベンチマーカ PGW(SUT) ✓ 送受信パケット数、ジッターなど Pushgateway経由でリアルタイムに収集 ✓

    Node Exporter ✓ Process Exporter SUT上で計測 PGWを挟む2つのPodでUEアクティビティを再現し、Prometheusで観測 ✓ 再現するUEの数だけ計測Podを作成 ✓ ベンチマークシナリオに基づき 各計測Podの設定を生成しetcd経由で配布
  6. All We Need Is Kubernetes ▪ コンピューティングのお守りから解放 ➢ 要求負荷量に応じて最適なインスタンスタイプを必要数デプロイ •

    実トラフィック印加にあわせてオートスケールアウト・イン ➢ Spotインスタンス化による大幅なコスト削減 • もちろん中断発生時のリカバリもKubernetesにおまかせ ▪ 宣言的ベンチマークを実現し認知負荷を低減 ➢ ベンチマークライフサイクルをReconciliation Loopに組み込み • 複雑なベンチマークロジックはOperatorパターンでコード化! ➢ Kustomize自体もMakefileなど標準タスクランナーでラップ • ドメイン知識を完全隠蔽し誰もが扱えるように!
  7. Amazon EKSではじめよう ▪ すべての関連リソース(>100)をTerraform管理 ➢ コマンド一発で構築・破棄。複数クラスタ同時使用可 • リソースタグでコストを追跡可 ➢ ベンチマーカ本体をHelmチャート化し自動インストール

    ➢ マネージドノードはBottlerocketを使用 • FargateノードはI/O性能に課題あり2025年3月時点 ▪ PGWとクロスアカウントVPCピアリングで直結 ➢ AWSのネットワーク負荷テストポリシーに準拠した構成
  8. 大規模コンテナデプロイの効率化 テストシナリオのスクリプト化 (Python, JS, ...) で可読性を向上 apiVersion: schale.soracom.io/v1beta1 kind: Gtperf

    metadata: labels: app.kubernetes.io/name: gtperf-operator app.kubernetes.io/managed-by: kustomize name: acceptance-test spec: parallelism: 1600 sut: pgw: 198.18.0.1 scenario: configMap: s1xfast-short-packet prometheus: pushGateway: pushgateway.mon apiVersion: v1 kind: ConfigMap metadata: name: s1xfast-short-packet data: scriptOrJson: | #!/usr/bin/env python3 import json print(json.dumps([{ "ue": { "ip": f"10.234.{i // 256}.{i % 256}", "imsi": f"{123456789000000 + i}", "uplink_teid": f"0x{(70000 + i):x}", "downlink_teid": f"0x{(80000 + i):x}" } # ... more fields } for i in range(1, 256 * 32)], indent=2))
  9. 『s1.slowで12,500UEs同時接続時のCPU負荷をみたい』 1UE = 約 2Pods = 計測時 3コンテナ/最大瞬間 6コンテナ 12.5KUEs

    = 25KPods = 計測時 37.5Kコンテナ/最大瞬間 75Kコンテナ 例 c6a.4xlargeが約 200台デプロイ = Spot目安 28USD/30分 128kbps×12,500UEs = 1.6Gbps の負荷を生成 Kubernetesと4万コンテナで挑む!
  10. 苦労したところと今後の課題 ▪ デプロイ規模がEKSの設計想定を超えている ➢ 200ノード 25,000Pods 最大 75,000コンテナを一度に展開させる ➢ その結果Karpenterの放置されてる既知の不具合を踏む[1]

    ➢ 数々の黒魔術を編み出し乗り切る[2] ▪ ENI/EC2クォータがノード集約率のボトルネック ➢ CPUとRAMのオーバプロビジョニングが目立つ[3] はるかに [1] Multi AZ Subnet to be selected only if there is available IPs #2921 [2] AWSテクニカルサポートに問い合わせたが「内部仕様につき〜」で期待する回答はもらえなかった [3] とはいえSpotインスタンスかつ起動時間20分程度であれば額面上問題になるほどではない