分散アプリケーション向けグローバル サービス メッシュ
このブログは、 SaaSサービスの構築と運用に必要だったさまざまな側面を取り上げているブログ シリーズの 2 番目です。
- 分散Kubernetes PaaSのコントロールプレーン
- 分散アプリケーション向けのグローバル サービス メッシュ
- 分散インフラストラクチャ、アプリ、データのプラットフォームセキュリティ
- 分散クラスタのアプリケーションとネットワークのセキュリティ
- グローバルに分散されたプラットフォーム全体の可観測性
- グローバルに分散されたプラットフォームの運用と SRE
- 分散マイクロサービス向けの Golang サービス フレームワーク
以前のブログでは、新しいプラットフォームを構築するに至った私たちのニーズについて背景を説明しました。 このプラットフォームを使用することで、スマート製造、公共安全のためのビデオフォレンジック、アルゴリズム取引、通信事業者の 5G ネットワークなど、複雑で多様なアプリケーション セットをお客様が構築できるようになります。
このシリーズの最初のブログでは、パブリック クラウド、プライベート ネットワーク PoP、エッジ サイトで複数のマルチテナント Kubernetes ベースのアプリケーション クラスターを提供するための分散コントロール プレーンについて説明しました。
このブログでは、アプリケーション間、ユーザー/マシン間、アプリケーションとパブリック インターネット間の 3 つの観点から、これらの分散アプリケーション クラスターを接続して保護する際の課題に取り組みます。 完全に統合された新しい L3-L7+ データパス、グローバルに分散されたコントロール プレーン、高性能なグローバル ネットワークを紹介します。 これら 3 つを組み合わせることで、エッジ、任意のクラウド VPC 内、またはグローバル ネットワーク PoP 内で包括的なネットワークおよびセキュリティ サービスが提供されます。 35 社以上の顧客を対象に 1 年以上にわたって本番環境で運用した後、展開の拡大を開始し、今が私たちの取り組みを共有する良い機会だと感じました。
TL;DR (要約)
- 分散アプリケーション クラスターに高性能で信頼性が高く安全な接続を提供するには、新しいグローバル ネットワークを構築する必要がありました。 消費者とアプリケーション（Akamai、Cloudflare など）や従業員とアプリケーション（Zscaler、Netskope など）を接続して保護するサービス プロバイダーは多数ありますが、アプリケーション間の接続とセキュリティのニーズを満たすサービス プロバイダーは存在しません。
- これらのアプリケーション クラスターには、分散アプリケーションを接続するグローバル ネットワークに加えて、一貫した構成と運用モデルを備えたネットワーク、信頼性、セキュリティ サービス (API ルーティング、負荷分散、セキュリティ、ネットワーク ルーティング) が必要です。 これらのサービスは、複数のクラウド プロバイダーの場所、リソースが制限されたエッジの場所、および/またはグローバル ネットワーク内で実行する必要があります。
- これらのネットワークおよびセキュリティ サービスを提供するために、当社では、自社のネットワーク、多くのパブリック クラウド、エッジ ロケーションなど、どこで実行されていても一貫した構成、ポリシー、および観測性を備えた、新しく完全に統合された L3-L7+ ネットワーク データパスを構築することを決定しました。 これらのデータパスの多くは複数のサイトに展開できるため、これらのデータパスを調整するためにグローバルに分散されたコントロール プレーンを構築する必要もありました。
- グローバル ネットワーク、新しいネットワーク データパス、分散制御プレーンの組み合わせにより、このグローバル ネットワーク全体にネットワーク アクセスを与えることなく、ゼロ トラスト セキュリティ、アプリケーション接続、クラスターの信頼性を実現する「グローバル分散アプリケーション ゲートウェイ」が実現しました。これは、セキュリティおよびコンプライアンス チームにとって簡素化をもたらす「グローバル サービス メッシュ」です。
ケーブルはどこですか? なぜグローバルネットワークを構築したのでしょうか?
当社の顧客は、スマート製造、公共安全のためのビデオフォレンジック、アルゴリズム取引、通信事業者の 5G 移行など、かなり複雑でミッションクリティカルなアプリケーションを構築しているため、アプリケーションとこれらのアプリケーションのエンドユーザーに対して、常時接続で信頼性の高いエクスペリエンスを提供する必要があります。 これらのアプリケーションの中には、クラウド内のクラスター間でデータ パイプラインを実行したり、クラウド プロバイダー間でデータをバックアップしたり、グローバル ユーザー ベースからアプリのバックエンドへのリクエストを確実に配信したり、マシンから集中型クラウドで実行されているバックエンドへの高性能な接続を必要とするものがあります。
これらのニーズを満たすために、物理ネットワークには次の 2 つの要件がありました。
R1 — クラウドからクラウドへ— 世界中のパブリック クラウドまたはプライベート クラウドのロケーション間でのアプリケーションの高パフォーマンスとオンデマンド接続
R2 — インターネットからクラウドへ— エッジロケーションのデバイスやマシンがアプリケーションバックエンドに確実に接続できるようにするには、インターネットを使用してトラフィックをバックエンドまでバックホールするのではなく、複数の冗長パスを提供し、これらのユーザーの近くで接続を終了する必要がありました。
AT&T のようなネットワーク サービス プロバイダーに依頼すれば、要件 R1 と R2 を解決することもできましたが、シームレスなネットワーク エクスペリエンスや、API ベースの構成、ストリーミング テレメトリ、自社または顧客の IP プレフィックスを簡単に追加する機能、API ベースのネットワーク サービスなど、アプリケーション サービスとの統合は提供できませんでした。 さらに、サービス プロバイダーから世界規模のサービスを受けることは非常に困難であるか、非常に高価です。 これらすべての問題を解決するために 2 つまたは 3 つのサービス プロバイダーを利用することもできましたが、その場合、動作が異なり、障害モードが異なり、SLA が異なり、サポート システムも異なり、API が異なる (または API がない) さまざまなシステムが混在することになります。
そのため、最終的には独自のネットワークを構築する必要があり、ネットワークには次の 3 つの特性が必要になりました。
- R1 を解決するには、すべての地域を接続するために、複数のクラウド プロバイダーにわたって世界中にプライベート ネットワークを構築する必要がありました。そのための最善のアプローチは、主要なクラウド地域のクラウド プロバイダーとピアリングし、主要なコロケーション施設で直接接続リンクを組み合わせて使用することです。 ピアリングでは最良の SLA が保証されませんが、直接接続リンクではクラウド リージョン内で SLA 保証が提供されます。
- エッジ ロケーションのマシンの R2 を解決するには、各エッジ ロケーションから複数のアクティブ/アクティブ リンクをサポートする必要があり、そのリンクは低コストのインターネット リンク (セルラーまたはケーブル/ファイバー経由) や高コストの専用リンク (ファイバー/イーサネット経由) になる場合があります。 パフォーマンスと信頼性を確保するには、信頼性の低いインターネット経由でトラフィックを転送するのではなく、トラフィックを負荷分散し、エッジ ロケーションのできるだけ近くで終了する必要があります。 業界用語では、この機能は SD-WAN とも呼ばれます。
- インターネット ユーザーとエッジ アプリケーションの R2 を解決するには、TLS トラフィックのエッジ ターミネーションを実行する必要があり、これはユーザーのできるだけ近くで実行する必要もあります。 つまり、モバイル オペレータやコンテンツ プロバイダとの密なピアリングを備えたネットワーク エッジ ロケーションを構築し、複数のトランジット プロバイダを使用してトラフィックを導入して最適なルーティングを確保する必要がありました。
これら 3 つの特性を満たすには、多くのことを行う必要がありました。 ただし、ここでは 5 つの大きなバケット項目に焦点を当てます。
- 当社のネットワーク ギアによるグローバル ネットワーク PoP — 最終的には、主要な大都市圏に複数のネットワーク PoP を構築する必要がありました。プラットフォーム構築の初期段階では、パリ、ロンドン、アムステルダム、ルクセンブルクなどヨーロッパの複数の都市と、ニューヨーク市の米国 1 つの PoP から開始し、その後、シアトル、サンノゼ、アッシュバーン、フランクフルト、シンガポール、東京へと拡張しました。これにより、グローバルなカバレッジが得られ、すべての主要なクラウド プロバイダーに近い位置になりました。 当社はグローバル パートナーとして Equinix を選択し、Equinix が最適な選択肢ではない場所には Interxion、Telehouse/KDDI、Westin を追加しました。 当社は自動化を信条としているため、スイッチング/ルーティング機器には Juniper Networks、400G および 100G リンクのメトロ ファイバー相互接続には Adva を選択しました。
- プライベート バックボーン— これらすべての PoP を高いパフォーマンスと信頼性で接続するために、複数のトランジット プロバイダーの上にオーバーレイ ネットワークを構築するのではなく、Zayo、Centurylink、EuNetworks などのプロバイダーからの複数の 100G 波を組み合わせてグローバル プライベート バックボーンを構築することを選択しました。 多くの CDN (Cloudflare、Fastly など) やセキュリティ プロバイダー (Zscaler など) は、ダウンストリーム トラフィックを処理する際にトランジット接続とピアリング接続に完全に依存していますが、東西のアプリケーション間トラフィックを処理するため、プライベート バックボーンおよびトランジットの組み合わせを使用する十分な理由があると考えています。 これは当社に限ったことではありません。すべての主要なクラウド プロバイダーは、クラウド ロケーションを接続するグローバル プライベート バックボーンを持っています。
- インターネット ピアリングおよびトランジット プロバイダー— 多様性を高め、ユーザーやコンテンツ プロバイダー、または SaaS プロバイダーに到達するための最高のパフォーマンスを実現するには、できるだけ多くのオペレーターやコンテンツ プロバイダーと直接ピアリングすることが理想的なソリューションです。 PeeringDB ( PeeringDB の ASN-35280 ) に概説されているように、複数の取引所でピアリングを行います。 すべてのトラフィックがピアリング接続を通じて処理できるわけではないため、トランジット接続が役立ちます。 トランジット リンクとピアリング ポートは、品質を維持するために非常に注意深く監視する必要があります。そのため、当社は最終的に、世界中のさまざまな場所でサービスを提供するために、NTT、CenturyLink、Telia などの最高の Tier-1 プロバイダーを選択しました。
- クラウド ピアリングと相互接続— 最近、クラウド プロバイダーとの直接ピアリングを開始しましたが、これらの接続に対する SLA は保証されていません。たとえば、シアトル (ウェスティン施設) のピアリング接続では、3 つの主要なクラウド プロバイダーすべてに直接アクセスできます。 これらの接続はトランジット プロバイダーを経由するだけよりも優れていますが、SLA や追加機能が備わっているため、これらのクラウド プロバイダーへの直接接続 (AWS Direct Connect、Azure Express Route、GCP Dedicated Interconnect と呼ばれる) でネットワークを拡張し始めました。 これらのリンクは高価であり、内部 VPC/VNET サブネットへのアクセスのみを許可しますが、最適な接続性を提供します。
- ソフトウェア ゲートウェイ- PoP ロケーションに直接接続されていないクラウドまたはエッジ ロケーションには、ソフトウェア ゲートウェイをインストールします。 これらのゲートウェイが提供する高度な機能については、このブログの後半で説明しますが、トランスポート層に関連する機能の 1 つは、これらのゲートウェイが複数のネットワーク PoP への安全な VPN (IPsec または SSL) トンネルを自動的に作成し、冗長性と PoP へのトラフィックの負荷分散を実現することです。 さらに、クラウド展開では、これらのゲートウェイは、クラウド プロバイダーの NAT ゲートウェイを介して最も近い PoP へのアウトバウンド接続と、グローバル プライベート ネットワークへのオンランプを作成します。パブリック ネットワークを通過したり、パブリック IP アドレスを使用してクラウドの場所間でアプリケーション クラスターを接続したりする必要はありません。
私たちは開発の早い段階で、グローバル ネットワークの構築と運用には時間とスキルが必要であり、この専門知識を導入する必要があることに気付きました。 Acorus Networks (フランスのパリに拠点を置くセキュリティ プロバイダー) の創設者と数か月にわたって議論した結果、最終的に Acorus と Volterra を合併することになりました。 これにより、グローバル インフラストラクチャとネットワーク展開の問題を解決することができました。 Acorus は、優れたネットワークと運用チームを立ち上げ、Ansible を使用して物理ネットワーク構成を完全に自動化し、ソフトウェア チームが使用できるテレメトリと構成用の外部 API を構築しました。
高い信頼性とパフォーマンスを備えたグローバル プライベート ネットワークの構築に注力するチームを編成できたため、図 1 に示すように、エッジまたはクラウドの場所をまたぐアプリケーション間およびユーザー/マシンからアプリケーションへのトラフィックの両方の問題を簡単に解決できるようになりました。 さらに、ネットワーク PoP のコンピューティングおよびストレージ インフラストラクチャにより、API 終了、アプリ セキュリティ、ワークロード オフロード (エッジまたはクラウドから) をネットワークに追加することもできました。 これにより、当社は今後も長期にわたって機能を進化させ続け、需要に応じてネットワーク フットプリントとサービス カタログを簡単に拡張できるようになります。
アプリケーション向けネットワーク サービス — マルチクラウド、プライベート、エッジ?
グローバル ネットワークが機能するようになったら、アプリケーション クラスターとワークロードの追加を開始する必要がありました。 これらのワークロードには、独自のアプリケーション レベルの接続およびセキュリティ サービスのセットが必要です。
以前のブログで説明したように、このプラットフォームの目標は、複数の環境 (クラウド、エッジ、ネットワーク PoP) で実行されるワークロードを管理するチームの生産性を向上させ、複雑さを軽減することでした。
すべてのクラウド プロバイダーでは、アプリケーション クラスターへの安全な接続を確保するために、さまざまなクラウド リソースを構成、管理、監視する必要があります。 たとえば、Google Cloud では、アプリケーション クラスタのエンドツーエンドのネットワーク サービスを構成するには、さまざまなサービス セットを管理する必要があります。
広域ネットワーク (WAN) サービス
アプリケーション ネットワーキング サービス
- アプリケーション ロード バランサー、ネットワーク ロード バランサー(パブリック API)
- アプリケーション ロード バランサー、ネットワーク ロード バランサー(内部)
- サービス メッシュ(アプリ間)
ネットワークルーティングおよび分離サービス
素晴らしいですね。大きな課題ではありますが、各クラウド プロバイダー間で調和する構成と運用レイヤーを構築することで、この問題に取り組むことを決定できたはずです。 しかし、クラウド プロバイダーのサービスが当社のすべてのニーズを満たしているわけではなく (例: CSP にはアプリケーションと API セキュリティを実行する機能が欠けている)、最高のサービスではなく、継続的に変化しているため、これでは問題が解決されないことはわかっていました。
さらに、ネットワーク PoP とエッジ サイトについてはどうでしょうか? ハードウェア ベンダーまたはソフトウェア ベンダーから同様の機能を入手し、それらをすべて統合する必要があります (例: ルーティング + NAT + VPN の場合は Cisco/Juniper、負荷分散とファイアウォールの場合は F5 など)。 エッジロケーションでは、クラウドプロバイダーも大手ネットワークベンダーもリソースが制限された環境のネットワークサービスの問題を解決できないため、問題はさらに複雑になります。 エッジのもう 1 つの潜在的なオプションは、すべてのアプリケーション接続、セキュリティ、およびネットワーク サービスをグローバル ネットワークに移行することでしたが、同じエッジ サイト内のアプリ間トラフィックにもこれらのサービスの一部が必要であるため、この方法は機能しないことは明らかでした。
多くの議論を重ね、状況を調査した結果、多くのサービス プロバイダーとベンダー間で構成、テレメトリ、監視、アラートを統合し、それらのロードマップと API の変更に対応することは、シンプルさとスピードという当社の目標に反することがわかりました。
プラットフォーム全体で解決する必要があったもう 1 つの問題は、マルチテナントでした。これは、WAN サービスとネットワーク ルーティングの場合は簡単に実行できましたが、市場に出回っているほとんどのロード バランサーがマルチテナントをまったくサポートしていないか、非常に限定的にしかサポートしていないことを考えると、アプリケーション ネットワーキング サービスの場合は困難でした。
新しい L3-L7+ ネットワーク データパス
その結果、私たちはこの課題に取り組み、ネットワークルーティングサービスだけでなく、アプリケーション、セキュリティ、広域サービスも提供する高性能ネットワークデータパスを構築することを決定しました。 これにより、ハイブリッドおよび分散クラウド環境全体でサービス ポートフォリオを統合できるようになり、パブリック クラウド内の最小限のネイティブ サービスに依存することが必要になります。
チームには優れたネットワーク経験があり、以前 Contrail/Juniper を使用して同様の問題に対処したことがあったため、この問題を解決する最善の方法は、白紙の状態から始めて、L3 から L7+ までのサービスを単一のデータパスに統合し、当社のプラットフォームによって集中管理されながら任意のクラウドまたはエッジで実行できるまったく新しいネットワーク ソリューションを構築することだと考えました。
私たちは、この新しいデータパスの設計を開始するために、すでに 6 年間の開発期間を費やした OpenContrail vRouter (L3-L4 用) と、大規模なコミュニティの支援を受けている L7 用の Envoy という最適なプロジェクトを選択しました。 そうは言っても、新しい統合 L3-L7+ データパスを構築するには、Envoy のマルチテナント、Envoy の dpdk、ユーザー空間 dpdk TCP スタック、ネットワーク ポリシー、SSL/IPSec VPN、http 接続、動的リバース プロキシ、透過フォワード プロキシ、API ゲートウェイ、プログラム可能なアプリケーション ポリシー、DDoS 保護用の高速 ACL、PKI ID 統合、Chrome v8 エンジン、アプリケーションとネットワークのセキュリティなど、いくつかの変更と追加を行う必要がありました。
このデータパス (図 2を参照) は、アプリケーション クラスターのイングレス/エグレス ゲートウェイ、エッジのソフトウェア ゲートウェイとして展開され、クラスター内または複数のクラスター間でサービス メッシュ機能を提供したり、グローバル PoP からネットワーク サービスを提供したりするために使用されます。
プラットフォームのマルチテナントのニーズ (前回のブログで説明) に対応するために、このネットワーク データパスにも完全なマルチテナントを実現する必要がありました。 vRouter はすでにVRF をサポートしていたため、ルーティング層では比較的簡単でしたが、マルチテナントにするには Envoy に変更を加える必要がありました。 カーネル TCP スタックを使用していなかったため、Envoy の TCP ソケット インターフェイスを変更し、VRF 認識を追加しました。
このデータパスでは、API セキュリティ、アプリケーション ファイアウォール、ネットワーク セキュリティも実行する必要がありました。このために、アルゴリズム手法と機械推論を組み合わせて使用しました。このトピックについては、今後のブログ投稿で取り上げる予定です。
このネットワーク データパスを構築することで、多くの利点が得られました。
統一された構成、制御、観測性を備えた完全な L3-L7+ 機能
単一クラスタ内でのスケールアウトのサポートにより、ネットワークまたはパブリッククラウドのロケーションで、非常に小さなフットプリントと低パフォーマンスのエッジデバイスから100Gbps以上の容量までの範囲をサポートできます。
ネットワークベンダーやクラウドプロバイダーに依存せずに、ネットワークデータパスに新しい機能を迅速に追加します。
あらゆる環境で同様の障害およびパフォーマンス特性を備えた共通ソリューション。これは、当社の運用チームにとって非常に重要です。
この新しいネットワーク データパスを使用して複数のアプリ クラスターを展開できるようになったため、それらを構成、制御、監視するためのグローバルに分散されたコントロール プレーンを構築することが重要になりました。
分散ネットワーク専用のコントロールプレーン
多数の分散データパス処理ノードを管理するための分散制御プレーンの構築の一環として、当社のプラットフォーム チームが取り組む必要があった問題が複数あります。 新しいデータパスを構築したため、すぐに利用できるコントロール プレーンはなく、独自に作成する必要がありました。 単一のクラスター (クラウド、エッジ、またはネットワーク PoP) 内で実行されている複数のデータパスを管理するためのローカル コントロール プレーン。 これらのデータパス ノードには、構成の変更、ルートの更新、ヘルス チェックの実行、サービス検出の実行、BGP などのプロトコルを使用した他のネットワーク デバイスとのピアリング、メトリックとアクセス ログの集約などを管理するためのローカル コントロール プレーンが必要でした。 複数のローカル コントロール プレーンを管理する分散コントロール プレーン — グローバル ネットワーク PoP (図 3 ) では分散コントロール プレーンが実行されており、このコントロール プレーンは、ローカル コントロール プレーンの構成管理、各ローカル コントロール プレーン間の動作状態の分散、および各ノードからのデータ収集を担当します。 運用状態を分散するために、最終的に一貫性があり堅牢な BGP を使用することにしました。 私たちは OpenContrail の一部として、非常に大規模でマルチスレッドの BGP 実装を構築していたので、それを活用して、ヘルスチェックの配布、http/api エンドポイント、ポリシーの伝播など、負荷分散のための拡張機能を追加しました。
さらに、図 4に示すように、2 つのクラウド リージョン (AWS と Azure) で実行される集中管理プレーンがあり、分散制御プレーンと併用されてマルチテナントを実現します。 当社の SRE チームは複数のテナントを作成でき、各テナントはグローバル ネットワーク全体で他のテナントから完全に分離されています。 「パブリック ネットワーク」を使用してのみ相互にルーティングできます。 テナント内では、名前空間全体のサービスは、http/api/ネットワーク ルーティングとセキュリティ ルールに基づいて相互に通信できます。
コントロール プレーンは、当社の SRE チームのみが管理する別のテナントおよび分離された名前空間で Kubernetes ワークロードとして実行されます。 その結果、開発者や顧客がこのサービスを妨害することはできません。 さらに、コントロール プレーンは分散されているため、1 つの場所でコントロール プレーンが停止しても、サービス全体に影響が及ぶことはありません。
グローバルに分散されたアプリケーション ゲートウェイ?
グローバル ネットワークのニーズを把握し、アプリ クラスターの L3-L7+ ネットワーク サービス (新しいデータパスと分散制御プレーン) の要件を定義すると、製品チームがさらに多くの要件を提示し、私たちの生活はさらに刺激的なものになりました。 基本的に、次の機能を備えたグローバルなクラスター間サービス メッシュを提供することが求められていました。
- グローバル ネットワーク全体にアプリケーション接続 (ルーティング、制御、および可観測性) を提供しますが、ネットワーク接続は提供しません (少なくともデフォルトでは提供しません)。理由は単純で、ネットワークを接続するとあらゆる種類のセキュリティ脆弱性が生じ、複雑なファイアウォール ルールを作成することでしか解決できず、変更管理の実行が困難になるからです。
- エンドポイントの健全性と信頼性により、ネットワーク PoP のエッジ ロード バランサーを改善します。現在、エッジ ロード バランサー (AWS グローバル アクセラレーターや Akamai グローバル ロード バランサーなど) では、エッジ ロケーションからバックエンドへのルーティングの決定は、オリジン サーバーの健全性に基づいています (ほとんどの場合、オリジン サーバーは別のロード バランサーであり、実際のサービス エンドポイントではありません)。 私たちのチームは、オリジン ロード バランサーの健全性だけでなく、すべてのクラスターにわたるすべてのエンドポイントの健全性に基づいてトラフィックを管理できる、各エッジ ロード バランサーの機能を求めていました。
- GSLB 意思決定の一環としてエッジ サイト (ネットワーク PoP) の選択を改善します。現在、エニーキャストまたは GSLB は、ユーザー/クライアントをイングレスのために最も近いエッジ サイトにルーティングします。 ただし、さまざまな理由 (バックボーンやトランジット プロバイダーの負荷) により、ユーザーを別のイングレス エッジ サイトに送信する方がよい場合もあります。
要件 2 と 3 では、クライアントからサーバーへの接続の応答時間とパフォーマンスを向上させることが目標であり、これはアプリケーション間の通信や大規模な SaaS アプリケーションにとって非常に重要です。 要件 2 と 3 を満たすには、分散プロキシ (図 5)、つまりネットワーク アドレスではなくアプリケーション アドレスに基づいたイングレス プロキシとエグレス プロキシおよびルートを構築するのが最善のアプローチであることは明らかでした。 さらに、分散コントロール プレーンと BGP 拡張機能 (前述のとおり) を活用して、サービス エンドポイント (またはサーバー) の健全性を分散することにしました。 分散プロキシの実装を下の図に示します。
完全な L3-L7+ ネットワーク スタックを備えた分散プロキシになったため、これをグローバル分散アプリケーション ゲートウェイと呼びます。 当社のネットワーク データパスで利用可能なすべての機能が、グローバル ネットワーク全体で利用できるようになりました。たとえば、HTTP または API に基づく負荷分散とルーティング、エッジでのポリシー適用、API 変換、ユーザーに近い場所での TLS 終了などです。
分散アプリケーションゲートウェイによってもたらされるメリット
グローバルに分散されたアプリケーション ゲートウェイを実装することで、チームはさまざまなメリットを実現できました。 これらの成果は、運用の改善、セキュリティ、パフォーマンス、TCO の分野で得られました。
- セキュリティとコンプライアンス- ネットワーク アクセスなしでサイト間でアプリケーション アクセスを提供できるため、エッジまたはクラウドの場所にあるアプリケーション クラスター全体のセキュリティとコンプライアンスが大幅に向上しました。 また、サイト間でのネットワーク アクセスがなくなり、アプリケーション クラスターは各サイトで完全に NAT の背後で接続できるため、複雑なファイアウォール構成管理の必要性も軽減されました。
- 運用オーバーヘッド— ネットワーク PoP とエッジ/クラウド サイト全体でのネットワーク サービスの共通セットにより、SRE または DevOps がさまざまなサービス セットにわたって構成と監視を統合する必要がなくなりました。
- パフォーマンスと信頼性の向上- 当社のネットワーク PoP から最適なロード バランサーではなく、最も最適で正常なエンドポイントにルーティングするため、このプラットフォームは、市場の他のどのソリューションよりも、アプリケーション間またはユーザー間のトラフィックに対してはるかに高いパフォーマンスを提供できます。
- TCO の削減- 大規模な SaaS アプリケーションでは、世界中の複数のデータセンターから何百ものサービスのレプリカが提供されるのが一般的です。 これを効果的に行うには、SaaS プロバイダーは、この分散アプリケーション ゲートウェイを使用してすべての顧客が利用できる複雑な機能を構築する必要があります。
つづく…
このブログ シリーズでは、パブリック クラウド、プライベート ネットワーク PoP、エッジ サイトにある多数のアプリケーション クラスターを使用して、グローバルに分散された SaaS サービスを構築および運用するために必要なさまざまな側面について説明します。 次はプラットフォームとデータセキュリティです…