F5 Distributed Cloud Services で実現するNetwork as a Service
エンタープライズネットワークがクラウドや関連会社などと連携し、ルーティングドメインが広がってきています。アプリケーション間の接続も増加傾向にあり、インフラエンジニアの運用は高難易度化している反面、アプリケーションのようにスピードアップを求められています。
ネットワーク機器などの自動化はAnsibleなどで進められていますが、分散化するアプリケーションの通信制御や、クラウドや、Kubernetesなど新しいネットワークシステムとの連携など、ネットワーク自動化だけでは対応が難しくなってきています。
この記事では異なるネットワークシステム間にF5 Distributed Cloud Services (F5XC) のインテントベースでアプリケーション間接続を実現するNetwork as a Serviceを紹介します。
肥大化/高度化するエンタープライズネットワーク
典型的なデータセンターネットワークは、データセンタースイッチファブリックにブランチオフィスを収容するルータ（SDWAN/SASEなど）、外接ルータ（クラウドデータセンター接続など）、インターネット接続FW、仮想マシンインフラ、オンプレサーバなどが接続され、VLANで異なるシステムを収容しています。FWのACLなどで異なるシステム間の通信制御をし、場合によってはNATでIPアドレス重複や、ネットワークのルーティングの分離を行っています。
昨今、DX化やクラウドシフト、システム連携などで、既存のネットワークに新しい仕組みが接続されてきています。例えばクラウドではVLANによるネットワーク分離ではなく、ラベルやネットワークドメインでの分離、KubernetesやOpenShiftなどのNamespace等による分離が行われるようになっています。
また、エッジコンピューティングなど新しい仕組みも今後増えてくることが予想されます。
このような新しい仕組みを既存ネットワークと組み合わせると、ACLの追加やNAT設定の増加、ルーティング変更やIPアドレス重複の解消などネットワークインフラが複雑化し、運用が高度化していきます。また、ネットワーク変更などの影響範囲が大きくなることで、設計導入テストの工数もかかるようになってきています。
インフラに関わる人はなかなか増員できないが、要件が増えている。というのは企業インフラシステムの共通の課題ではないでしょうか？
F5XCではネットワークシステムとアプリケーションセキュリティをパッケージにしたアプライアンスを用意し、ポータルサイトのコンソールから制御することで、個別のコンフィグ制御を排除し、インテントベースのコンフィグを用意しています。
ファイアウォールや、ロードバランサー、WAFなどの設定変更、機能追加や削除はSDNにより動的に行われ、断時間なしに行うことが可能です。
F5XCのアプライアンス (CE (Customer Edge))は、物理アプライアンス、仮想マシン、コンテナ、クラウドとどこでも動作することが可能で、CE間は動的なオーバーレイトンネルを作成します。F5XCのCEはアプリケーション接続ゲートウェイとして動作します。
このアプリケーション接続ゲートウェイは、クラウドや、Kubernetes、既存ネットワークなど、個別のベストプラクティスを持つネットワーキングの仕組みはそのままに、L3ルーティングドメインをF5XCのCEで終端することで、ルーティングドメインを分割します。複雑な処理をCEで行うことで、物理ネットワーク構成とコンフィグをシンプルにし、サービス提供のスピードの向上や運用負荷を減らせる可能性があります。
Network as a Serviceユースケース
マルチデータセンター、ハイブリッドクラウドL3VPN
データセンターなどのVLANにSegment (分割されたルーティングテーブル(VRF))を設定します。以下の例ではRed, Blue, Green, BlackのSegmentを作成しています。Blackには共通のアプルケーションがあるため、RedとBlueからのL3レベルの通信を許可しています。
ルータを使ったL3VPNでも同様のサービスは実現可能ですが、MPLSやSRv6 などの知識、Route DistinguisherやRoute Targetの管理、各ルータへのコンフィグ投入管理などキャリアネットワークの知識が必要となり、習熟コストや運用コストが高くなります。F5XCではL3VPNをサービスとして導入可能で、特定の知識の習熟コストを下げ簡単に導入が可能です。
マルチデータセンター/ハイブリッドクラウド ロードバランサー
IPアドレスが重複している場合や、ルーティングテーブルが分かれているネットワーク上のアプリケーションに対して、L4/L7ロードバランサーを設定できます。
例えば、BranchのBlue Segment (VLAN20)及び、Data CenterのBlue Segment (VLAN200)のネットワークでLoad Balancerを設定し、Origin Server (エンドポイント)をData CenterのBlack Segment (VLAN 400)と設定します。このように複数の拠点にまたがる設定を1つのオブジェクトで設定可能です。
Segmentに設定されたLoad BalancerではクライアントトラフィックをTCP/UDPで終端します。このため、異なるロケーションやSegment間でL3の疎通性が不要です。
また、Load Balancerにはアクセス可能なHTTP Path/Methodなどの制御やWAFなどのセキュリティ追加も容易です。
IPアドレス重複ソリューション
IPアドレスが重複し、ルータやFirewallでSNAT/DNATで通信制御を行うと、ネットワーク機器のコンフィグが複雑化や、障害発生時の障害切り分けの時間がかかるなどの弊害が出てきます。F5XC のLoad Balancerを使用したIPアドレス重複ソリューションは、NATコンフィグを明示的に行う必要はなく、IPネットワーク到達性もクライアント/エンドポイントからCEまででよく、ネットワーク機器のコンフィグの簡素化をできる可能性があります。
下図のようにブランチオフィスのクライアントがData Centerのblack.app.comに通信する場合、BranchのクライアントはCEを宛先としてトラフィックを送信します。CEは終端したトラフィックのLoad BalancerのEndpointの識別子としてXC Headerを挿入し、パケットをEndpointのCEに送信します。EndpointのCEはXC Headerを参照し、実際のEndpointに自身のインターフェイスのIPアドレスを送信元としてトラフィックを送信します。
このような動作を内部で動的に行うため、ユーザーは複雑なコンフィグなしにIPアドレス重複環境や、ルーティングテーブルが分割されたネットワーク間においてもアプリケーション通信を簡易な設定で可能になります。
また、Load Balancerでは多様なログやメトリックからエンドツーエンドのネットワーク遅延やL7リクエストログ、API可視化など高度な可観測性をコンソールで提供します。表示されるデータは自動的に集計されるため、ユーザーの個別設定は不要です。
Load Balancerのリクエストログの例です。各APIのパスやMethodのレスポンスコードや遅延などが一覧で表示されます。
集計したデータからAPIのグラフを作成することも可能です。ここから実際に使われているAPIを確認し、不要なAPIはポリシーを作成してブロックすることも可能です。
APIに対してセキュリティスコアを付与し、脆弱なAPIを発見することも可能です。
複雑化するネットワークをシンプルに
F5XCを使うことで、クラウド、オンプレ、VMware、Nutanix、Kubernetesなど様々なインフラで動くアプリケーションを、物理ネットワークの変更を最小限にして、動的に連携することが可能になります。
物理ネットワークの設計の簡素化
各インフラのベストプラクティスを利用可能
アプリケーション間通信のサービス化と可視化
こちらのYoutubeのリンクからNetwork as a Serviceやユーザーポータルのデモをご覧に慣れます。
API Seurity https://www.youtube.com/watch?v=EDRAPD1G_aA
個別ネットワーク機器の設定変更を極小化し、各種ネットワークモジュールのAPIを利用することでネットワークシステムのセルフサービス化の一歩にもなるのではないでしょうか？
例えばサービスポータルは各ネットワークサービスを提供するAPIと連携します。
ユーザーはサービスポータルから開通させたいサービスをリクエストします。サービスポータルはAPIをコールするだけで、例えばデータセンタースイッチにVLANが割り当てられ、アプリケーションをオンボーディング後に、アプリケーション通信サービスでLoad Balancerなどの設定を行います。
アラートなどはインシデント管理サービスを使い、場合に応じてサービスポータルから運用管理者へ通知を行います。
最後に
ここ数年でもクラウドだけでなく、KubernetesやSASEなど新しいネットワークの仕組みを持つサービスが登場しています。今後も新しいネットワークの仕組みを持ったサービスが登場することが予想されます。新しい仕組みを既存ネットワーク変更を最小にし、それぞれのベストプラクティスを使うことにより、個別の設計を減らすことで運用の簡素化や障害時に幅広いナレッジを使用することが可能になります。
アプリケーションはますます分散化されることも予想されるため、F5XCのNetwork as a Serviceを利用して次期ネットワーク基盤のネットワーク/インフラシステムのモジュール化、アプリケーション通信のサービス化のお手伝いができれば幸いです。