分散アプリケーション向けグローバルサービスメッシュ

Ankur Singla

このブログは、F5がSaaSサービスを構築・運用するために必要だったさまざまな取り組みを紹介するシリーズの第2回です。

1. 分散型Kubernetes PaaS向けコントロールプレーン
2. 分散アプリケーション向けグローバルサービスメッシュ
3. 分散インフラ、アプリ、データのためのプラットフォームセキュリティ
4. 分散クラスターのアプリケーションおよびネットワークセキュリティ
5. グローバルに分散したプラットフォーム全体のオブザーバビリティ
6. グローバルに分散したプラットフォームの運用とSRE
7. 分散マイクロサービス向けGolangサービスフレームワーク

以前のブログでは、新しいプラットフォームの構築に至ったニーズの背景をご紹介しました。このプラットフォームにより、スマートマニュファクチャリング、公共安全向け映像フォレンジック、アルゴリズム取引、通信事業者向け5Gネットワークなど、複雑で多様なアプリケーションを構築できるようになります。

本シリーズの最初のブログでは、パブリッククラウド、F5のプライベートネットワークPoP、エッジサイトに複数のマルチテナント型Kubernetesベースのアプリケーションクラスターを提供するための分散コントロールプレーンについて取り上げました。

このブログでは、分散したアプリケーションクラスターの接続とセキュリティ確保に伴う課題を、アプリケーション間、ユーザー／マシンからアプリケーション、アプリケーションからパブリックインターネットという3つの観点から取り上げます。また、まったく新しい完全統合型のL3-L7+データパス、グローバルに分散したコントロールプレーン、F5の高性能グローバルネットワークをご紹介します。これら3つを組み合わせることで、エッジ、任意のクラウドVPC内、またはF5のグローバルネットワークPoPで、包括的なネットワークサービスとセキュリティサービスを提供します。35社を超えるお客さまの本番環境で1年以上運用した後、導入規模の拡大を開始しました。そこで今こそ、これまでの歩みをご紹介する良い機会だと考えました。

要約

• 分散アプリケーションクラスターに高性能で信頼性とセキュリティに優れた接続を提供するには、新たなグローバルネットワークを構築する必要がありました。消費者とアプリケーションの接続およびセキュリティを提供するサービスプロバイダー（Akamai、Cloudflareなど）や、従業員とアプリケーションを接続して保護するサービスプロバイダー（Zscaler、Netskopeなど）は数多く存在しますが、アプリケーション間の接続とセキュリティのニーズに応えるサービスプロバイダーは存在しません。
  
• 分散アプリケーションを接続するグローバルネットワークに加え、これらのアプリケーションクラスターには、一貫した構成および運用モデルに基づくネットワーキング、信頼性、セキュリティの各サービス（APIルーティング、負荷分散、セキュリティ、ネットワークルーティング）が必要です。これらのサービスは、複数のクラウドプロバイダー拠点、リソースに制約のあるエッジ拠点、F5のグローバルネットワークのいずれか、または複数で実行できる必要があります。
  
• これらのネットワーキングおよびセキュリティサービスを提供するため、F5は、自社ネットワーク、多数のパブリッククラウド、エッジロケーションなど、実行場所を問わず一貫した構成、ポリシー、オブザーバビリティを実現する、新しい完全統合型のL3-L7+ネットワークデータパスを構築することにしました。これらのデータパスの多くは複数のサイトにわたって展開できるため、データパスをオーケストレーションするグローバル分散型コントロールプレーンも構築する必要がありました。
  
• グローバルネットワーク、新しいネットワークデータパス、分散型コントロールプレーンを組み合わせることで、このグローバルネットワーク全体へのネットワークアクセスを許可することなく、ゼロトラストセキュリティ、アプリケーション接続、クラスターの信頼性を実現する「グローバル分散型アプリケーションゲートウェイ」を構築しました。これは、セキュリティおよびコンプライアンスチームの業務を簡素化する「グローバルサービスメッシュ」です。

ケーブルはどこに？なぜグローバルネットワークを構築したのか

お客さまが、スマートマニュファクチャリング、公共安全向け映像フォレンジック、アルゴリズム取引、通信事業者の5G移行など、非常に複雑でミッションクリティカルなアプリケーションを構築する中、F5には、アプリケーションとそのエンドユーザーに、常時稼働し、接続性と信頼性に優れたエクスペリエンスを提供することが求められます。こうしたアプリケーションの中には、クラウド内の複数クラスター間でデータパイプラインを実行するもの、クラウドプロバイダー間でデータをバックアップする必要があるもの、世界中のユーザーからのリクエストをアプリケーションのバックエンドへ確実に配信する必要があるもの、または各種マシンから集中型クラウドで稼働するバックエンドへの高性能な接続を必要とするものがあります。

これらのニーズを満たすため、物理ネットワークには次の2つの要件がありました。

R1 — クラウド間 — 世界各地のパブリッククラウドまたはプライベートクラウドにまたがる、アプリケーションの高性能なオンデマンド接続

R2 — インターネットからクラウドへ — エッジ拠点のデバイスやマシンをアプリケーションのバックエンドに確実に接続するには、複数の冗長パスを用意するとともに、インターネット経由でトラフィックをバックエンドまで迂回させるのではなく、これらのユーザーにできるだけ近い場所で接続を終端する必要がありました。

AT&Tのようなネットワークサービスプロバイダーを利用すれば、要件R1とR2を満たすことはできたかもしれません。しかし、APIベースの設定、ストリーミングテレメトリ、自社またはお客さまのIPプレフィックスを容易に追加できる機能、APIベースのネットワークサービスなど、シームレスなネットワークエクスペリエンスとアプリケーションサービスとの統合は実現できなかったでしょう。さらに、サービスプロバイダーを通じてグローバルなカバレッジを確保することは非常に困難であり、費用が法外に高くなる場合もあります。2社または3社の異なるサービスプロバイダーを利用すれば、これらすべての問題を解決できたかもしれませんが、その場合、動作、障害モード、SLA、サポートシステム、APIの仕様や有無がそれぞれ異なる複数のシステムが混在し、複雑化していたでしょう。

そのため、最終的には独自のネットワークを構築する必要があり、そのネットワークには次の3つの特性が求められました。

1. R1を解決するには、すべてのリージョンを接続するために、複数のクラウドプロバイダーにまたがるグローバルなプライベートネットワークを構築する必要がありました。その最善の方法は、主要なクラウドリージョンでクラウドプロバイダーとピアリングするとともに、主要なコロケーション施設でダイレクト接続リンクを組み合わせて使用することです。ピアリングでは最良のSLAは保証されませんが、ダイレクト接続リンクではクラウドリージョン内のSLAが保証されます。
   
2. エッジロケーションにあるマシンについてR2を解決するには、各エッジロケーションから複数のアクティブ／アクティブリンクをサポートする必要がありました。これらのリンクには、低コストのインターネットリンク（セルラーまたはケーブル／光ファイバー経由）と、より高コストの専用リンク（光ファイバー／イーサネット経由）の一方または両方を使用できます。パフォーマンスと信頼性を確保するには、信頼性の低いインターネット経由でトラフィックを遠方まで転送するのではなく、可能な限りエッジロケーションの近くでトラフィックを負荷分散し、終端する必要があります。業界用語では、この機能はSD-WANとも呼ばれます。
   
3. インターネットユーザーとエッジアプリケーションに関するR2を解決するには、TLSトラフィックをユーザーのできるだけ近くでエッジ終端する必要がありました。そのため、モバイル通信事業者やコンテンツプロバイダーと高密度にピアリングし、複数のトランジットプロバイダー経由でトラフィックを取り込んで最適なルーティングを確保できるネットワークエッジロケーションを構築する必要がありました。

これら3つの特性を満たすために、さまざまな対応が必要でした。ここでは、その中から5つの主要項目を取り上げます。

1. 自社ネットワーク機器を備えたグローバルネットワークPoP— 最終的に、主要都市圏に複数のネットワークPoPを構築する必要がありました。プラットフォーム構築の初期段階では、欧州のパリ、ロンドン、アムステルダム、ルクセンブルクと、米国のニューヨークにPoPを設置し、その後、シアトル、サンノゼ、アッシュバーン、フランクフルト、シンガポール、東京へと拡大しました。これにより、世界各地をカバーし、主要なクラウドプロバイダーの近くに拠点を置くことができました。グローバルパートナーにはEquinixを選び、Equinixが最適な選択肢ではない地域では、Interxion、Telehouse/KDDI、Westinで補完しました。また、自動化を重視しているため、スイッチング／ルーティング機器にはJuniper Networksを、400Gおよび100Gリンクによる都市圏内の光ファイバー相互接続にはAdvaを採用しました。
2. プライベートバックボーン — これらすべてのPoPを高いパフォーマンスと信頼性で接続するため、複数のトランジットプロバイダー上にオーバーレイネットワークを構築するのではなく、Zayo、Centurylink、EuNetworksなどのプロバイダーが提供する複数の100G波長回線を組み合わせて、グローバルなプライベートバックボーンを構築することにしました。多くのCDN（Cloudflare、Fastlyなど）やセキュリティプロバイダー（Zscalerなど）は、ダウンストリームトラフィックを配信するため、トランジット接続とピアリング接続のみに依存しています。一方、当社が扱うのはアプリケーション間の東西トラフィックであるため、プライベートバックボーンとトランジットを組み合わせることには十分な理由があると考えています。これは当社独自の構成ではありません。主要なクラウドプロバイダーはいずれも、各クラウド拠点を接続するグローバルなプライベートバックボーンを備えています。
3. インターネットピアリングおよびトランジットプロバイダー — 接続先の多様性を高め、ユーザー、コンテンツプロバイダー、SaaSプロバイダーへの接続で最高のパフォーマンスを実現するには、できるだけ多くの通信事業者やコンテンツプロバイダーと直接ピアリングすることが理想的です。PeeringDBに記載されているとおり、複数のインターネットエクスチェンジでピアリングしています（PeeringDBのASN-35280）。すべてのトラフィックをピアリング接続で処理できるわけではないため、そこでトランジット接続が必要になります。品質を維持するには、トランジットリンクとピアリングポートを細心の注意を払って監視する必要があります。そのため、世界各地でサービスを提供するTier-1プロバイダーとして、NTT、CenturyLink、Teliaなどの最適な事業者を選定しました。
4. クラウドピアリングと相互接続 — 最近、クラウドプロバイダーとの直接ピアリングを開始しましたが、これらの接続にはSLAが保証されていません。たとえば、シアトル（Westin施設）のピアリング接続では、主要な3つのクラウドプロバイダーすべてに直接接続できます。これらの接続はトランジットプロバイダーのみを経由する場合よりも優れていますが、SLAと追加機能が提供されるため、クラウドプロバイダーへの直接接続（AWS Direct Connect、Azure Express Route、GCP Dedicated Interconnect）を追加してネットワークを強化し始めました。これらのリンクは高額で、内部VPC/VNETサブネットにしかアクセスできませんが、最良の接続性を提供します。
5. ソフトウェアゲートウェイ — F5のPoPロケーションに直接接続されていないクラウドまたはエッジロケーションには、ソフトウェアゲートウェイを導入します。これらのゲートウェイが提供する高度な機能については、このブログの後半で説明します。トランスポート層に関連する機能の1つとして、これらのゲートウェイは、冗長性を確保するために複数のネットワークPoPへのセキュアなVPN（IPsecまたはSSL）トンネルを自動的に作成し、PoPへのトラフィックを負荷分散します。また、クラウド環境では、クラウドプロバイダーのNATゲートウェイを経由して最寄りのPoPへのアウトバウンド接続を確立し、F5のグローバルプライベートネットワークへの接続経路を提供します。そのため、パブリックネットワークを経由したり、パブリックIPアドレスを使用して複数のクラウドロケーション間でアプリケーションクラスターを接続したりする必要はありません。

開発のごく初期段階で、グローバルネットワークの構築と運用には時間とスキルが必要であり、その専門知識を取り入れる必要があると認識しました。フランスのパリを拠点とするセキュリティプロバイダー、Acorus Networksの創業者と数か月にわたって協議した結果、AcorusをVolterraに統合することになりました。これにより、グローバルインフラストラクチャとネットワーク展開に関する課題を解決できました。Acorusは、優れたネットワークと運用チームを独力で立ち上げていました。このチームは、Ansibleを使用して物理ネットワークの構成を完全に自動化し、Volterraのソフトウェアチームが利用できるテレメトリおよび構成用の外部APIを構築していました。

図1：グローバルネットワークを介したアプリ間またはユーザー／マシンからアプリへのトラフィック

高い信頼性とパフォーマンスを備えたグローバルプライベートネットワークの構築に専念するチームができたことで、図1に示すように、エッジやクラウドの拠点をまたぐアプリケーション間、およびユーザー／マシンからアプリケーションへのトラフィックに関する課題を容易に解決できるようになりました。さらに、ネットワークPoPのコンピューティングおよびストレージインフラストラクチャにより、API終端、アプリケーションセキュリティ、ワークロードのオフロード（エッジまたはクラウドから）もネットワークに追加できるようになりました。これにより、今後も長期にわたって機能を進化させ、需要に応じてネットワークの展開範囲とサービスカタログを容易に拡充できます。

アプリケーション向けネットワークサービス — マルチクラウド、プライベート、エッジ？

グローバルネットワークが稼働した後は、アプリケーションクラスターとワークロードを追加する必要がありました。これらのワークロードには、それぞれに対応したアプリケーションレベルの接続サービスとセキュリティサービスが必要です。

以前のブログで説明したように、このプラットフォームの目標は、複数の環境（クラウド、エッジ、F5のネットワークPoP）で稼働するワークロードを管理するチームの生産性を向上させ、複雑さを軽減することでした。

どのクラウドプロバイダーでも、アプリケーションクラスターへのセキュアな接続を実現するには、多種多様なクラウドリソースの構成、管理、監視が必要です。たとえばGoogle Cloudでアプリケーションクラスター向けのエンドツーエンドのネットワークサービスを構成するには、次のようなさまざまなサービス群を管理する必要があります。

広域ネットワーク（WAN）サービス

• 仮想プライベートネットワーク（VPN）および／または相互接続
• DNSサーバー
• DDoSとWAFS

アプリケーションネットワーキングサービス

• Application Load Balancer、Network Load Balancer（パブリックAPI）
• Application Load Balancer、Network Load Balancer（内部）
• サービスメッシュ （アプリ間）

ネットワークルーティングおよび分離サービス

• Virtual Private Cloud Network (VPC Network)
• サブネット、IP範囲、ルート
• NATゲートウェイ、ファイアウォールルール

確かに、これは大きな課題ではあるものの、各クラウドプロバイダー間の整合性を確保するための構成・運用レイヤーを構築するという方法も考えられました。しかし、クラウドプロバイダーのサービスは、CSPではアプリケーションおよびAPIセキュリティを実現する機能が不足しているなど、F5のあらゆるニーズを満たすものではなく、必ずしも最良の選択肢でもないうえ、絶えず変化しています。そのため、この方法では問題を解決できないことが分かっていました。

さらに、ネットワークPoPやエッジサイトについてはどうでしょうか。同様の機能をハードウェアまたはソフトウェアベンダーから調達し、すべて統合する必要があります。たとえば、ルーティング、NAT、VPNにはCisco/Juniper、負荷分散とファイアウォールにはF5を使用するといった具合です。エッジ拠点では、クラウドプロバイダーも大手ネットワークベンダーも、リソースに制約のある環境におけるネットワークサービスの課題を解決できないため、問題はさらに複雑になります。エッジ向けの別の選択肢として、アプリケーション接続、セキュリティ、ネットワークサービスをすべてグローバルネットワークに移行することも考えられました。しかし、同じエッジサイト内のアプリケーション間トラフィックにもこれらのサービスの一部が必要なため、この方法ではうまくいかないことは明らかでした。

多くの議論を重ね、市場を調査した結果、複数のサービスプロバイダーやベンダーにまたがって構成、テレメトリ、監視、アラートを統合し、各社のロードマップやAPIの変更に追随することは、シンプルさとスピードを重視する私たちの目標に反すると判断しました。

プラットフォーム全体で解決する必要があったもう1つの課題は、マルチテナンシーです。WANサービスやネットワークルーティングでは比較的容易に実現できましたが、市場にあるロードバランサーの大半はマルチテナンシーをまったくサポートしていないか、サポートが非常に限定的であるため、アプリケーションネットワーキングサービスでは困難でした。

新たなL3～L7+ネットワークデータパス

その結果、私たちはこの課題に取り組み、ネットワークルーティングサービスだけでなく、アプリケーション、セキュリティ、広域ネットワークの各サービスも提供する高性能なネットワークデータパスを構築することにしました。これにより、ハイブリッドクラウドおよび分散クラウド環境全体でサービスポートフォリオを統合し、パブリッククラウドのネイティブサービスへの依存を最小限に抑えられます。

チームにはネットワーク分野で豊富な経験があり、以前Contrail/Juniperで同様の問題に取り組んだ実績もあったため、この問題を解決する最善の方法は、ゼロから設計し直し、L3～L7+のサービスを単一のデータパスに統合したまったく新しいネットワークソリューションを構築することだと考えました。このソリューションは、あらゆるクラウドやエッジで実行でき、F5のプラットフォームから一元管理できます。

この新しいデータパスの設計に着手するにあたり、最適なプロジェクトとして、すでに6年をかけて開発してきたL3～L4向けのOpenContrail vRouterと、コミュニティから幅広い支持を得ているL7向けのEnvoyを選びました。ただし、新たな統合L3～L7+データパスを構築するには、Envoyのマルチテナンシー対応、Envoy向けdpdk、ユーザー空間dpdk TCPスタック、ネットワークポリシー、SSL/IPSec VPN、http connect、動的リバースプロキシ、透過型フォワードプロキシ、APIゲートウェイ、プログラム可能なアプリケーションポリシー、DDoS対策用の高速ACL、PKIアイデンティティ統合、Chrome v8エンジン、アプリケーションおよびネットワークセキュリティなど、さまざまな変更や機能追加が必要でした。

図2：ネットワークデータパス

このデータパス（図2に示す）は、アプリケーションクラスターのイングレス／エグレスゲートウェイ、エッジのソフトウェアゲートウェイ、クラスター内または複数のクラスター間でサービスメッシュ機能を提供するための基盤、あるいはグローバルPoPからネットワークサービスを提供するための基盤として導入されます。

プラットフォームに求められるマルチテナンシー（前回のブログで解説）に対応するため、このネットワークデータパスでも完全なマルチテナンシーを実現する必要がありました。vRouterはすでにVRFをサポートしていたため、ルーティングレイヤーへの対応は比較的容易でしたが、Envoyをマルチテナント対応にするには変更が必要でした。カーネルのTCPスタックを使用していなかったため、EnvoyのTCPソケットインターフェースを変更し、VRFを認識する機能を追加しました。

このデータパスには、APIセキュリティ、アプリケーションファイアウォール、ネットワークセキュリティの機能も必要でした。そのため、アルゴリズム技術と機械推論を組み合わせて使用しました。このトピックについては、今後のブログ記事で取り上げます。

このネットワークデータパスを構築したことで、多くのメリットが得られました。

統一された設定、制御、可観測性を備えた包括的なL3～L7+機能

単一クラスター内でのスケールアウトに対応することで、設置面積が非常に小さく性能が低いエッジデバイスから、F5のネットワーク拠点またはパブリッククラウド拠点における100 Gbps以上の容量まで、幅広い規模に対応できます

特定のネットワークベンダーやクラウドプロバイダーに依存することなく、ネットワークデータパスに新たな機能を迅速に追加できます

あらゆる環境で同様の障害特性とパフォーマンス特性を備えた共通ソリューションです。これは運用チームにとって非常に重要です。

この新しいネットワークデータパスによって複数のアプリクラスターを展開できるようになったため、それらの設定、制御、監視を行うグローバル分散型のコントロールプレーンを構築することが不可欠でした。

分散ネットワーク専用に設計されたコントロールプレーン

多数の分散データパス処理ノードを管理する分散コントロールプレーンの構築にあたり、プラットフォームチームは複数の課題に対処する必要がありました。新しいデータパスを構築したため、そのまま利用できる既製のコントロールプレーンはなく、独自に開発する必要がありました。具体的には、単一のクラスター（クラウド、エッジ、またはネットワークPoP）内で稼働する複数のデータパスを管理するローカルコントロールプレーンです。これらのデータパスノードには、構成変更やルート更新の管理、ヘルスチェック、サービスディスカバリ、BGPなどのプロトコルを使用した他のネットワークデバイスとのピアリング、メトリクスとアクセスログの集約などを行うローカルコントロールプレーンが必要でした。複数のローカルコントロールプレーンを管理する分散コントロールプレーン — F5のグローバルネットワークPoP（図3）では分散コントロールプレーンが稼働しており、ローカルコントロールプレーンの構成管理、各ローカルコントロールプレーンへの運用状態の配布、各ノードからのデータ収集を担います。運用状態の配布には、結果整合性と堅牢性を備えたBGPを採用しました。OpenContrailの一環として、非常にスケーラブルなマルチスレッド対応のBGP実装を構築していたため、これを活用し、ヘルスチェックの配布、http/apiエンドポイント、ポリシーの伝播など、ロードバランシング向けの拡張機能を追加しました。

図3：分散コントロールプレーンとローカルコントロールプレーン

さらに、図4に示すように、AWSとAzureの2つのクラウドリージョンで稼働する一元管理プレーンがあり、分散コントロールプレーンと併用することでマルチテナンシーを実現します。F5のSREチームは複数のテナントを作成でき、各テナントはグローバルネットワーク全体で他のテナントから完全に分離されます。テナント間のルーティングには「パブリックネットワーク」のみを使用できます。テナント内では、異なる名前空間のサービス間で、HTTP、API、ネットワークのルーティングおよびセキュリティルールに基づいて通信できます。

図4：ネットワークにおけるマルチテナンシー

コントロールプレーンは、F5のSREチームのみが管理する独立したテナントと分離された名前空間で、Kubernetesワークロードとして稼働します。そのため、開発者やお客さまがこのサービスを中断させることはできません。また、コントロールプレーンは分散されているため、1つの拠点でコントロールプレーンに障害が発生しても、サービス全体には影響しません。

グローバルに分散されたアプリケーションゲートウェイとは？

グローバルネットワークに必要な機能を明確にし、アプリクラスター向けのL3～L7+ネットワークサービス（新しいデータパスと分散コントロールプレーン）の要件を定義したところ、プロダクトチームからさらに難易度の高い要件が提示されました。つまり、次の機能を備えた、グローバルなクラスター間サービスメッシュの提供を求められたのです。

1. グローバルネットワーク全体でアプリケーション接続（ルーティング、制御、可観測性）を提供する一方、ネットワーク接続は提供しない（少なくともデフォルトでは提供しない）— 理由は単純です。ネットワーク同士を接続すると、複雑なファイアウォールルールを作成しなければ解消できないさまざまなセキュリティ脆弱性が生じ、変更管理が難しくなるためです。
   
2. エンドポイントの健全性と信頼性に基づいてネットワークPoPのエッジロードバランサーを改善する — 現在、エッジロードバランサー（AWS Global AcceleratorやAkamai Global Load Balancerなど）では、エッジロケーションからバックエンドへのルーティングがオリジンサーバーの健全性に基づいて決定されます（多くの場合、オリジンサーバーは実際にサービスを提供するエンドポイントではなく、別のロードバランサーです）。私たちのチームは、各エッジロードバランサーが、オリジンロードバランサーの健全性だけでなく、すべてのクラスターにわたる全エンドポイントの健全性に基づいてトラフィックを管理できる機能を求めていました。
   
3. GSLBの判断におけるエッジサイト（ネットワークPoP）選択の改善 — 現在、AnycastまたはGSLBでは、ユーザー／クライアントから最も近いエッジサイトにトラフィックをルーティングし、そこで受信します。ただし、バックボーンやトランジットプロバイダーの負荷など、さまざまな理由により、別の受信エッジサイトにユーザーを誘導する方が適切な場合があります。

要件#2と#3では、クライアントからサーバーへの接続における応答時間とパフォーマンスの向上を目標としました。これは、アプリケーション間通信や大規模なSaaSアプリケーションにおいて極めて重要です。要件#2と#3を満たすには、分散プロキシ（図5）、すなわちイングレスプロキシとエグレスプロキシを構築し、ネットワークアドレスではなくアプリケーションアドレスに基づいてルーティングする方法が最適であることは明らかでした。さらに、分散コントロールプレーンとBGP拡張（前述）を活用し、サービス提供エンドポイント（またはサーバー）のヘルス情報を分散することにしました。この分散プロキシの実装を以下の図に示します。

図5：分散アプリケーションゲートウェイ

完全なL3～L7+ネットワークスタックを備えた分散プロキシとなったことから、これをグローバル分散型アプリケーションゲートウェイと呼んでいます。HTTPやAPIに基づく負荷分散とルーティング、エッジでのポリシー適用、API変換、ユーザーに近い場所でのTLS終端など、ネットワークデータパスで利用できるすべての機能を、グローバルネットワーク全体で利用できるようになりました。

Distributed Application Gatewayがもたらすメリット

グローバルに分散されたアプリケーションゲートウェイを導入したことで、チームは複数の効果を得ることができました。具体的には、運用の改善、セキュリティ、パフォーマンス、TCOの各領域で効果が得られました。

1. セキュリティとコンプライアンス — ネットワークアクセスを介さずにサイト間でアプリケーションへのアクセスを提供できるため、エッジまたはクラウド環境にあるアプリケーションクラスター全体のセキュリティとコンプライアンスが大幅に向上しました。また、サイト間のネットワークアクセスが不要で、各サイトのアプリケーションクラスターを完全にNAT配下に置いたまま接続できるため、複雑なファイアウォール構成管理の必要性も低減しました。
   
2. 運用負荷 — Network PoPとエッジ／クラウドサイトで共通のネットワークサービス群を使用することで、SREやDevOpsが異なるサービス群の間で構成とオブザーバビリティを統合する必要がなくなりました。
   
3. パフォーマンスと信頼性の向上 — ネットワークPoPから、最適なロードバランサーではなく、最適かつ正常なエンドポイントにルーティングするため、このプラットフォームは、アプリケーション間またはユーザーとアプリケーション間のトラフィックにおいて、市場の他のどのソリューションよりもはるかに高いパフォーマンスを実現できます。
   
4. TCOの改善 — 大規模なSaaSアプリケーションでは、世界各地の複数のデータセンターから数百ものサービスレプリカを提供することが一般的です。これを効果的に実現するには、SaaSプロバイダーが複雑な機能を構築する必要がありますが、分散アプリケーションゲートウェイにより、こうした機能をすべてのお客さまが利用できるようになりました。

次回へ続く……

このブログシリーズでは、パブリッククラウド上の多数のアプリケーションクラスター、F5のプライベートネットワークPoP、エッジサイトを活用し、グローバルに分散したSaaSサービスを構築・運用するために必要だったさまざまな取り組みをご紹介します。次回のテーマは「プラットフォームとデータのセキュリティ」です……

著者について

Ankur Singla

Ankur Singlaのその他のブログ記事