P4と進むネットワークの向こう側

ビジネス開発本部 第1応用技術部
第1チーム
スハルトノ リオスナタ

 昨今、データセンターネットワークの構築においてAmazon、Apple、Facebook、Google、MicrosoftのようなHyperscale Data Center Operatorと呼ばれる企業が採用した手法が注目を浴びています。なぜなら彼らはネットワークは、スケール性(Scale-out型ネットワーク)を保ちながらもTCO(Total Cost of Ownership)の削減を同時に実現できているからです。例えば、ホワイトボックススイッチを利用することによって、初期投資を抑えることができます。あわせて、使用しない機能をソフトウェアから排除することで、余計なバグによるネットワークインパクトも抑えることができます。一方で、既存ベンダーの製品ではこういったカスタマイズは不可能です。その理由は、ユーザーが自由にスイッチのソフトウェアに手を加えることもできないからです。

 Hyperscale Data Center Operatorの主導の元、これまでのようなベンダー依存の状況からの脱却を目的に、ネットワーク機器をハードウェアとソフトウェアに分離させる流れが見られるようになりました。これにより、ユーザーはハードウェアのみを調達し、自社サービスに適したソフトウェアと組み合わせることができます。

図1.コストとスケールアウト

ホワイトボックススイッチとNOS(Network Operating Systems)

 ホワイトボックススイッチは、NOSを搭載していないため、一般的なスイッチング機能はありません。ホワイトボックススイッチをスイッチとして動作させるためには、ソフトウェアを組み込む必要があります。

図2.ホワイトボックススイッチ

 NOSには有償な物の他にオープンソースな物も世の中にリリースされています。そのため、ハードウェアのみを購入し、NOSはオープンで提供されているものを利用することで、価格を抑えることが可能です。また、すでにあるNOSを独自で改良し、ユーザーの独自実装を加えてスイッチにインプリメントすることも可能です。あるいは、自作でNOSを開発することも可能です。

ホワイトボックススイッチとNOSの連携

 NOSがハードウェアを制御するには、間にAPI(Application Programming Interface)またはSDK(Software Develoopment Kit)を仲介する必要があります。APIはハードウェア(搭載しているASIC含む)によって異なります。そのため、ハードウェアが変わると、使用するAPIが変わり、NOSもそれに合わせて修正する必要があります。ホワイトボックススイッチで採用されているASICは製品によってまちまちです。よって、そのハードウェアで動かせるNOSも異なります。特に、独自機能を実装する際には、ハードウェアによって使用できるプログラミング言語が異なり、新規で調達するスイッチによっては動かない場合があります。つまり、一度開発したNOSを再利用することができず、開発コストがかさむ結果となる場合があります。

図3.ハードウェアとNOSの関係

 実際に、NOSを開発する際には、ターゲットとなるスイッチチップベンダーごとにSDKが用意されており、各プラットフォームで個別の実装を必要としています。こういった状況を対処するために、SAI(Switch Abstraction Interface)が存在します。SAIは数あるハードウェアの制御方法を吸収し、統一する物です。NOSはSAIのAPIを用いてハードウェアを制御することになります。同じAPIを用いれば、ハードウェアが変わっても、同じ機能を実装することが可能になります。

図4.SAIによるハードウェア依存の吸収

プログラミング言語P4

 ユーザーのやりたいことによっては、ユーザーが直接ハードウェアにプログラムを実装する必要があります。例えば、独自の機能を実装したいが、SAIが提供している機能だけでは実装できないといったケースです。特に、一般的な機能ではなく特殊な機能を実装させたい場合に、こういった状況が発生します。そこでハードウェアのプログラミング言語としてP4が誕生しました。P4言語は、ハードウェアをソフトウェアプログラミング言語のような扱いでプログラミングできるようにしたものです。P4言語をサポートしているハードウェアであれば、ホワイトボックススイッチ本体が変わっても、既存のP4コードを再利用することで、同じ機能を実装することができます。つまり、ユーザーにとってはハードウェアに依存せず開発できることがメリットとなります。また、独自の機能を実装しようとした際に、SAIだけでは実装できないケースがあります。その時は、P4言語での開発が必要になります。P4言語での開発では、SAIだけではできないパケットの受け取り方やヘッダーの書き換え等も、自分自身で定義できます。最近では、P4言語にて開発できるハードウェアとしてスイッチだけでなく、スマートNICにもリリースされています。これにより、ネットワーク上のエンドツーエンドに独自実装を施すことができることも、P4言語のメリットの1つになります。今後も、P4に対応したハードウェアは増えてくると思われます。

図5.P4プログラミング言語

P4対応のデバイスに期待されること

 前述のとおり、NICからネットワークデバイスまでフルカスタムができるのがP4の最大のメリットです。今回は2つの機能に絞ってユースケースをご紹介させていただきます。1つ目のユースケースは、今まで、ソフトウェアで実装されていた機能をハードウェアへオフロードする使い方です。例えば、DoS対策のハードウェアオフロードが注目されています。一般的なDoS攻撃は、TCP Synパケットを用いてサーバ側のリソースを尽きさせ、サービス提供できない状況に追い込む形で行うケースが多いです。専用機を使ったDoS対策を実施することもありますが、コストのデメリットやサーバのスケールに追い付いていけない問題が発生すると考えられます。サービスを拡大する際に、DoS対策に莫大なコストをかけるのではサービス自体の原価に影響が出る結果になってしまいます。P4を用いてDoS対策をハードウェアで実装できれば、スケールアウトに掛かるコストを節約することが可能になります。ハードウェアでの実装のため、検知できる攻撃の種類は限られますが、Syn Floodのような単純な攻撃であればP4スイッチでの実装は可能です。

図6.スイッチでのDoS対策

 2つ目のユースケースとして、INT(In-Band Network Telemetry)があります。INTはパケットが各スイッチを通過した際の状況(スイッチの内部コンポーネント情報含む)をリアルタイムで収集可能な技術です。これらの情報を可視化することによって、どのようなパケットがどの経路を、どれぐらい流れているかを確認することができます。一般的な監視システムやテレメトリと異なり、パケットの情報や通過した時点でのスイッチの情報も取得可能なため、フロー情報を含めた可視化が可能になります。INTを活用すれば、サービスチェイニングを導入した際にパケットの経路を把握することができます。また、サイレント障害の発生を早期に発見することも可能となります。

図7.INTでの可視化

P4の今後

 ハードウェアレベルで何を実装したいかを、明確にできているユーザーは積極的にP4に取り組むと思われます。なぜなら、使いたい機能をベンダーに実装してもらうよりP4で開発した方が、新機能の実装、商用展開をより早く実施できるからです。一方で、P4を用いた場合、運用開始後のサポートまでユーザー自身で行う必要があります。Hyper Scale Data Center事業者のような開発力があるユーザーは自社でクローズできますが、そうでないユーザーにとってはどうすれば解決できるかを模索する必要があります。

最後に

 P4の登場により、ユーザー自身がハードウェアをプログラミングすることが可能になりました。結果として、必要な機能を自ら実装し、使用しない機能を取り払うことで、インフラや運用の効率化が図れるようになります。一方、実装後のサポート体制の維持をどうするかといった新しい検討課題があるのは事実です。今後、P4のコミュニティが広がれば、ユースケースの情報交換やコードの共有が進み、より多くのユーザー層にP4が活用されると考えられます。P4はネットワーク業界に変革をもたらす可能性があるため、ネットワンシステムズでは引き続きP4活用に対する活動を実施してまいります。もしご興味があれば、弊社担当営業までお問い合わせください。

執筆者プロフィール

スハルトノ リオスナタ
ネットワンシステムズ株式会社 ビジネス開発本部 第1応用技術部 第1チーム所属

入社後キャンパススイッチ製品の評価、検証、提案支援業務に従事。
ネットワークとセキュリティの連携に関する業務にも従事し、自動化にも従事。
現在は、ホワイトボックススイッチ・P4言語やNFVに関する調査業務を担当。

イベント/レポート

pagetop