# Service-Centric Networking ## 定義 Service-Centric Networking とは、ネットワーク通信の第一級の対象を固定ホストやインターフェースではなく、同一機能を提供するプロセス群として扱う設計思想である。Serval はサービス識別子(`ServiceID`)、通信フロー識別子(`FlowID`)、到達位置(IP アドレス)を分離し、トランスポート層とネットワーク層の間に Service Access Layer(SAL)を置く。これにより、サービスの初回解決を遅延束縛し、アドレス変更・レプリカ増減・フロー移行をアプリケーションから隠蔽する。(Source: [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]]) ## 設計原則 - **役割の分離**: サービス名は「誰と通信するか」、`FlowID` は「どの通信コンテキストか」、IP アドレスは「どこへ届けるか」を表す。 - **遅延束縛**: サービス名からインスタンス・位置への束縛を接続開始時まで遅らせ、DNS キャッシュや事前設定による古い位置情報を避ける。 - **初回解決とデータ転送の分離**: 初回 SYN はサービスルータで解決し、確立後のデータはエンドポイント間で直接転送する。 - **サービスレベルの制御／データプレーン分離**: ユーザー空間のサービスコントローラがポリシーと解決を担い、SAL がサービス表に基づくパケット処理を担う。 - **フローの独立性**: フローをネットワークアドレスから切り離し、複数経路の追加とインターフェース間移行を SAL に集約する。 ## 横断的知見 - **サービスを第一級の名前にする位置は、プロキシ方式より低い**: Serval の SAL はトランスポート層とネットワーク層の間でサービス名と `FlowID` を処理し、ネットワーク層は変更しない。一方、[[サービスメッシュ]] はサイドカープロキシをアプリケーションと組み合わせ、サービス間通信の発見・転送・可観測性をプロセス外へ分離する。両者は制御プレーンとデータプレーンを分けるが、Serval はホストネットワークスタックの識別子と移動性を再設計し、サービスメッシュはアプリケーション間の運用機能をプロキシへ移す。(Source: [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]], [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]]) - **ロードバランサーをデータ経路から外す設計は、機能を集約する方式と異なる**: [[スクリプタブルロードバランサー]] はシャード解決やサービスレベルロジックをプロキシへ集約するのに対し、Serval は初回 SYN のサービス解決だけをサービスルータへ渡し、後続データを直接転送する。前者は判断の一貫性とアプリケーションからの抽象化を得やすいが、後者は全パケット通過による帯域制約を避ける。(Source: [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]], [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]]) - **名前の遅延束縛とフロー移行は別の機構だが、同じ識別子分離に依存する**: `ServiceID` の遅延束縛だけでは確立済み接続のアドレス変更に対応できない。Serval は `FlowID` をホスト内の不変な多重分離キーとして別に持つことで、サービスインスタンスの選択と確立済み通信の再同期を同じ SAL に接続する。(Source: [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]]) - **サービスルーティングはネットワーク層の上に置けるが、制御範囲はサービス表の配布方式で決まる**: Serval は階層型プレフィックス配布、DHT、ブロードキャスト、DNS 連携を同一のサービス表アクションへ写像する。したがって、サービス中心型という名前だけでは集中制御か分散制御かは決まらず、`FORWARD`・`DELAY`・`DEMUX` ルールを誰がいつ伝播するかが運用特性を決める。(Source: [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]]) ## 未解決の問い - 現代の暗号化トランスポート、QUIC、MPTCP、eBPF/XDP と `ServiceID`・`FlowID` を統合する場合、どの層がフロー移行と暗号状態の所有権を持つべきか。 - サービス識別子の登録権限、広域広告経路、自己証明識別子を組み合わせたとき、サービス乗っ取りと経路広告の不正をどの境界で検知・防止するか。 - 初回接続だけをサービスルータへ通す設計は、短命接続・大量の小パケット・サービス表更新頻度が高い環境で、現代の LPM・キャッシュ・SmartNIC 実装によりどこまでスケールするか。 - SAL のフロー移行は、経路変更に伴う RTT・帯域変化を輻輳制御へどう通知すれば、移行直後の過剰送信やテールレイテンシを避けられるか。 - Service-Centric Networking とサービスメッシュを同一ホストへ重ねた場合、サービス識別子、サービス発見、暗号終端、負荷分散、トレースコンテキストの責任境界はどう整理すべきか。 - 2012 年の Serval が提示したサービス中心型の抽象が、今日のコンテナ・クラウド・エッジ配置でどの程度実装され、どの要件がプロキシ層へ置き換わったのか。 ## 関連 - ソース: [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]] - システム: [[Serval]] - 関連概念: [[サービスメッシュ]] / [[スクリプタブルロードバランサー]] / [[負荷分散]] / [[TCP接続局所性]] / [[エニキャストルーティング]] - 関連 MOC: [[Network - MOC]] ## 出典 - [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]] — ServiceID・FlowID・SAL、サービスルーティング、サービスルータ、フロー移行、プロトタイプと実験結果。 - [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] — ロードバランサーへサービスロジックを集約する設計。 - [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]] — サービスメッシュのサイドカー、制御プレーン／データプレーン分離。