2018年初頭、ネットワークや新たな5G標準に精通した友人や同僚と、何度も同じような話をしていました。未知の要素が非常に多いまま、移行を急いでいることに、誰もが漠然とした不安を感じていたのです。5Gによってコンテナやクラウドネイティブアーキテクチャへの移行が進むことは全員が理解していましたが、Kubernetesをはじめとするクラウドネイティブツールは、もともとまったく異なるユースケースを想定して作られたものだという認識もありました。私たち全員が目の当たりにしていたのは（おそらく、この記事をお読みの多くの方もお気づきだったと思いますが）、業界が大きな問題に直面する方向へ突き進んでいるという状況でした。
こうした懸念を抱いていた時期を経て、通信サービスプロバイダー（CSP）はクラウドネイティブインフラストラクチャへの移行に本格的に取り組み始めました。先駆けて導入を進めている事業者は、当初の設計どおりのKubernetesネットワーキングでは、サービスプロバイダーのユースケースで求められる要件を重要な領域で満たせないという、予期せぬ障壁に直面しています。通信事業者の目標が5G Stand Alone（SA）Coreの導入であっても、分散クラウドアーキテクチャによるモダナイゼーション施策の一環であっても、ネットワークの相互運用性、通信事業者向けのスケーラビリティ、通信事業者のセキュリティポリシーをサポートできるようKubernetesを適応させることは、クラウドネイティブインフラストラクチャ全体に不可欠です。
その後、Kubernetesは主に、パブリッククラウドや企業環境で稼働するWebおよびITのユースケースに重点を置いて進化してきました。そのため、サービスプロバイダーのユースケースを展開するための固有の要件やプロトコルが当初から想定されていなかったのも無理はありません。しかし幸いなことに、Kubernetesの設計者は、Kubernetesを拡張可能にする堅牢な設計パターンを整備しました。これにより、ネットワークトラフィックの管理、可視化と制御、HTTP/2、GTP、SIP、Diameterなどのプロトコルサポート拡張といった、通信事業者に不可欠なユースケースへの道が開かれています。
今日のサービスプロバイダーのユースケースにKubernetesを適合させるために必要な機能強化について説明する前に、まずサービスプロバイダーネットワーク特有の要件を確認します。
Kubernetesは、より大きなエコシステムに適合する必要がある
まず、Kubernetesクラスターは、サービスプロバイダーのより広範なネットワークおよび運用と統合する必要があります。アーキテクチャ上の決定は、運用コストと複雑さの増大という形で、長期的な影響を及ぼす可能性があります。ネットワークアーキテクトは、通信事業者の複数のユースケース、レガシープロトコルのサポート、Kubernetes内の動的な変更が既存のネットワークトポロジーに及ぼす影響を考慮する必要があります。こうした変更によって、複雑さがさらに増す可能性があります。
次に、通信事業者のワークロード（ネットワーク機能）は、ITワークロードとは異なります。サービスプロバイダーのネットワークとそのネットワーク機能では、標準的なHTTP/HTTPSやTCP以外のプロトコルも使用します。モバイル通信事業者にとって、SIP、GTP、SCTPなどの従来の3G/4Gプロトコルと5G HTTP2の両方をネットワークでサポートすることが極めて重要です。また、通信事業者のワークロードには、ITワークロードとは異なり、従来のネットワーク層の上位に追加の標準レイヤーがあります。
最後に、決して軽視できないのがセキュリティです。新たに生じるすべての露出ポイントにおいてセキュリティが最重要であり、新たな自動化、可視化、管理機能が求められます。新しいテクノロジーを導入する際は、すべてのレイヤーにセキュリティを導入し、新しいクラスターと連携して機能させる必要があります。サービスプロバイダーのSecOpsチームは、攻撃対象領域を縮小し、一貫したセキュリティ制御を実現する方法を常に模索しています。さらに、ネットワーク全体のセキュリティポリシーを更新し、時間の経過に応じて適応できるようにする必要があります。
こうした機能上のギャップに対処する現在の2つのアプローチ
Kubernetesパターンを回避
クラウドネイティブのパターンを回避していることは、Kubernetesに通信事業者のワークロードを処理するためのツールが標準で備わっていないため、アーキテクトがやむを得ずその場しのぎの仕組みを作らざるを得ない状況を示しています。通信事業者がこうしたパターンを崩している、懸念すべき事例がいくつか確認されています。
- Kubernetesネットワークの回避 — CNFの大多数は、1つ以上のインターフェースをKubernetesの制御外に配置しています。これらのCNFにはネットワークへの直接アクセスが必要です（多くの場合、外部に直接接続する追加インターフェースを可能にする「multus」の要望として提示されます）。ネットワークを一元的に制御できなければ、Kubernetes内部の複雑さが外部のサービスプロバイダーネットワークに露呈し、運用の複雑さとコストが増すだけでなく、セキュリティ上の攻撃対象領域も拡大します。また、Kubernetes内のコンテナの動的な性質が外部に露呈するため、アプリケーション／ネットワーク機能の開発者やネットワーク運用者には、IPアドレスの管理とその動的な性質への対応という、より大きな負担がかかります。
- ネットワーク機能ごとに個別のクラスターを使用 – Kubernetesネットワーキングには、ネットワークトラフィックのイングレスとエグレスを一元管理するポイントが標準では用意されていません。Kubernetesにはイングレスをある程度制御する機能がありますが、エグレストラフィックはほとんど考慮されておらず、イングレスとエグレスのネットワーキングを関連付ける組み込みの方法もありません。サーバーのIPアドレスとネットワーク機能のIPアドレスを対応付けるために、各ネットワーク機能をそれぞれ専用のクラスターで実行している導入事例が複数見られます。その結果、リソースのオーバーヘッドと設備投資（CapEx）が増加するだけでなく、運用が複雑化し、運用費（OpEx）も増加します。
Kubernetesのパターンに準拠
別のアプローチとして、Kubernetesの設計パターンに準拠し、外部環境に対するKubernetesクラスターのイングレス／エグレスのネットワークとセキュリティを一元的に管理できるサービスプロキシを導入する方法があります。サービスプロキシの目的は、サービスプロバイダー環境でKubernetesを使用する際に生じる機能上のギャップを補うことです。サービスプロキシには、以下の機能が求められます。
- Kubernetesネイティブのパターンを使用して、Kubernetesネットワーク機能を拡張（カスタムリソース定義、K8s制御ループ）
- より広範なネットワークとのインターフェース（BGPルーティング、エグレスSNAT IPの割り当て、IPv4/v6変換）
- イングレスとエグレスをリンク CNFごとに個別に
- 幅広いL4/L7プロトコルをサポート（tcp、udp、sctp、NGAP、HTTP/2、Diameter、GTP、SIP）
- セキュリティレイヤーを提供（TLS終端、ファイアウォール、DDoS、Webアプリケーションファイアウォール）
- 一貫性のあるCNFを提示し、変動の激しいKubernetesイベントを隠蔽
F5のアプローチ — サービスプロキシの導入
F5は、Kubernetesを拡張し、不足している機能を補うこのサービスプロキシを構築するために、前述の2つ目のシナリオを選択しました。数十年にわたって培ってきたトラフィック管理とセキュリティの専門知識に基づき、これは大規模なクラウドネイティブ移行を支えるうえで不可欠な機能だと考えています。F5は、Kubernetesの課題に直接対処し、サービスプロバイダーが標準のKubernetesにはないリソースを作成できるようにする、クラウドネイティブインフラストラクチャ製品「BIG-IP Next Service Proxy for Kubernetes（SPK）」を開発しました。本製品は本番環境に対応しており、現在ご利用いただけます。SPKは、自動化を実現し、より広範なネットワークおよびセキュリティポリシーと円滑に統合できるフレームワークにより、アーキテクチャを簡素化し、セキュリティを強化します。通信事業者向けのこのKubernetesアプローチは、複雑さと運用コストを引き続き低減するとともに、よりレジリエントでセキュアなインフラストラクチャの実現につながります。現在、5G SAへの移行が減速している状況を踏まえると（GlobalDataの調査で判明、通信事業者の5G SA導入が難航）、適切なサービスプロキシを導入しなければ、移行はさらに停滞すると考えられます。大規模なデジタルモダナイゼーションを進め、すでに本番環境でSPKを利用している通信事業者は、これまで認識していなかった5Gネットワークアーキテクチャの課題に対するKubernetesソリューションとして、SPKの有効性を実感しています。
F5のSPKは正式提供を開始しており、現在、大規模な通信事業者の本番環境で稼働しています。今後のイベントでは、他のアプローチと比較したSPKの機能や、F5のプラットフォーム上でCNFを認定する方法をご紹介します。詳細については、こちらのページをご覧ください。F5の担当者への直接のご相談をご希望の場合は、お問い合わせください。
関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。