サービス メッシュは具体的に何ができるのでしょうか?

​翻訳者 |ブガッティ

校正：孫淑娟

これら 2 つのマルチクラウド ネットワーク アーキテクチャを見てみましょう。ネットワーク サービスとセキュリティ関連の機能を自動化し、クラウドに依存しないサービス メッシュにオフロードすると、マルチクラウド環境の管理が簡素化されます。

特定のクラウド ベンダー向けのネットワーク ソリューションのためのマルチクラウド アーキテクチャ:

図1

クラウドに依存しないサービス メッシュ:

図2

多くのサービス メッシュ製品には、サービス検出、ゼロ トラスト ネットワーキング、負荷分散機能が含まれており、さらに進んで、マルチクラウド/マルチランタイム環境の接続、ネットワーク自動化、南北トラフィック制御を提供する製品もあります。クラウドに依存しないサービス メッシュの機能と、環境間で既存のツールを統合して管理の労力とコストを削減する可能性についてご覧ください。

サービス検出

サービス検出により、開発者はネットワーク上のすべての登録済みサービスのネットワークの場所と健全性を登録および追跡できます。これは、サービスが絶えず追加または削除される動的な環境において重要な機能です。これは多くの場合、サービス メッシュを導入するための最初のステップとなります。

サービス検出機能を取得する方法は多数あります。しかし、Kubernetes、Amazon EKS、Azure AKS、Google GKE、または AWS Cloud Map や構成管理データベース (CMDB) などのサービス検出ツールに組み込まれている一般的な機能は、多くの場合、実行されるプラットフォームまたはクラウドに固有のものです。検出できるサービスの範囲は、特定のプラットフォームまたはクラウドの境界に制限されます。しかし、今日のほとんどの組織は複数のプラットフォームまたはクラウド環境でアプリケーションを実行しているため、複数のサービス検出ソリューションを学習、インストール、管理する必要があります。

より良いアプローチは、複数のランタイム環境にまたがるクラウドに依存しないサービス メッシュです。たとえば、HashiCorp Consul は、Kubernetes、仮想マシン、Amazon ECS、HashiCorp Nomad をサポートするニュートラルなサービス メッシュであり、組織が複数の異種環境にわたるグローバルなサービス検出を一元的に処理できるようにします。

サービス ディスカバリをサービス メッシュに統合すると、プラットフォーム チームはサービス ディスカバリをグローバル共有サービスとして提供できるようになり、個々のチームが監視なしで独自のサービス ディスカバリ ツールを実行および管理する場合に比べて、コストが削減され、コンプライアンスが向上し、管理が簡素化されます。

ゼロトラストネットワーク

組織は、ネットワーク境界を保護するために従来のアプローチだけに頼るのではなく、ネットワークとインフラストラクチャを保護するためにゼロ トラスト ネットワーキングにますます注目するようになっています。

現代のクラウド環境には存在しない可能性のある境界の保護に依存する従来の城と堀のセキュリティ アプローチとは異なり、ゼロ トラスト セキュリティでは、承認および認証されない限り、サービス (境界の内側か外側かに関係なく) へのアクセスを許可すべきではなく、すべての通信が暗号化されていると考えています。

ゼロトラスト ネットワーキングのいくつかの原則を適用します。認証、承認、暗号化はサービス メッシュの主な機能です。サービス メッシュは、プロキシ (通常は Envoy) を介して、サービス間の受信トラフィックと送信トラフィックを自動的にリダイレクトします。これにより、承認、認証、暗号化などのタスクがプロキシにオフロードされます。

サービス メッシュは、認証を許可または拒否する単位として IP アドレスではなくサービス ID を使用するため、サービス間通信の管理タスクが大幅に簡素化されます。

管理者は、エージェントによって強制され、すべてのサービス間通信をブロックする単一の包括的な拒否ポリシーを構成できます。開発者は、必要に応じて特定のサービスが通信できるように、より詳細なポリシーを追加できます。

サービス メッシュ プロキシは、すべてのサービス間通信が自動的に認証および暗号化されることも保証します。サービス通信が発生する前に、プロキシは TLS 証明書が交換され、ネットワーク上のすべてのトラフィックが暗号化されていることを確認します。その結果、サイバーセキュリティ インシデントが発生した後でもサービス間の横方向の移動を防ぐ、より安全なネットワークが実現します。

最後に、サービス メッシュは、管理者と開発者が開発サイクルの早い段階でネットワーク サービスを承認、認証、暗号化できるようにすることで、組織がシフトレフトを行うのに本質的に役立ちます。シフトレフトにより、組織は本番環境に展開する前に、予期しないセキュリティの脆弱性による土壇場での遅延のリスクを軽減できます。さらに、サービス メッシュを使用してシフトレフトを行うと、ネットワーク管理者は個々の IP アドレスの管理ではなく、ネットワーク境界の保護に集中できるようになります。

サービス メッシュは、ネットワーク管理者の力を強化するものであり、開発者がセキュリティ ロジックではなくアプリケーションに集中し、証明書とキーの管理やローテーションの煩わしさを回避できるようにする抽象化レイヤーです。

負荷分散

サービス メッシュ上のデータ トラフィックはプロキシを通過するため、サービス メッシュはトラフィック シェーピングなどの機能も制御できます。簡単な例としては、サービスの複数のインスタンス間の負荷分散が挙げられます。サービス メッシュを使用すると、異なるロード バランサーを介して追加のネットワーク ホップを経由するのではなく、カスタム トラフィック パターンをインスタンス間で直接分散できます。インスタンスが追加または削除された場合でも、サービス メッシュはトラフィックの分散を動的に調整できます。サービス メッシュを使用すると、複数の異なる環境やクラウドにまたがる複数の異なる負荷分散デバイスを管理するコストと複雑さを大幅に削減できます。

図3

対比：

図4

マルチクラウド接続

多くの組織では、さまざまなチームやサービスが、クラウド内のさまざまなネットワークや複数のリージョンに分散しています。多くの組織のサービスも複数のクラウド環境に展開されています。異なるクラウド ネットワーク間でこれらのサービスを安全に接続する機能は非常に必要であり、通常はネットワーク チームからの多大な労力を必要とします。さらに、サブネット間で重複しないクラスレス ドメイン間ルーティング (CIDR) 範囲を要求する制限により、仮想プライベート クラウド (VPC) と仮想ネ​​ットワーク (VNET) 間のネットワーク接続が妨げられる可能性があります。サービス メッシュ製品は、同じレベルの労力を必要とせずに、異なるクラウド ネットワーク上で実行されているサービスを安全に接続できます。

たとえば、HashiCorp Consul は、メッシュ ゲートウェイを使用して、クラウド全体の異なるネットワークで実行されている複数の Consul デプロイメント間の安全な接続を確立する、マルチデータセンター トポロジをサポートしています。チーム A は EKS に Consul クラスターをデプロイできます。チーム B は、AKS 上に別の Consul クラスターをデプロイできます。チーム C は、専用のローカル データ センター内の仮想マシンに Consul クラスターを展開できます。これら 3 つの Consul クラスター間でマルチデータセンター構成を確立できるため、VPN、Direct Connect、ExpressRoute などの追加のネットワーク構成を必要とせずに、EKS、AKS、VM 間で実行されるサービスに安全な接続を提供できます。 Consul メッシュ ゲートウェイを使用すると、ネットワーク間で IP 範囲が重複している場合でも、複数の Consul 展開をクラスタリングできます。

オートメーション

自動化は、動的な環境で特に有益です。需要が変動すると、オペレーターはサービス インスタンスの数を拡張する必要がありますが、これは比較的簡単な作業です。ただし、新しいインスタンスにアクセスするには、ネットワーク ファイアウォール、ロード バランサー、またはその他のネットワーク インフラストラクチャを更新する必要がある場合があります。同様に、新しいアプリケーション サービスでは、クライアントがアクセスできるようになる前にネットワーク機器の更新が必要になる場合があります。

ほとんどの組織にはネットワーク チームとセキュリティ チームが別々に存在するため、このワークフローでは多くの場合、ネットワーク デバイスの更新を要求する作業チケットを手動で送信する必要があり、完了するまでに数時間、場合によっては数日かかることがあります。サービスを縮小または無効にすると、追加の問題が発生する可能性があります。これは、ネットワーク チームに対してネットワーク デバイスから IP アドレスを削除するよう求める要求を無視することが容易であり、潜在的なセキュリティ侵害につながるためです。

これらの課題に対処するために、一部のサービス メッシュでは、HashiCorp Terraform などのインフラストラクチャ構成ツールとの独自の統合を構築しています。 Consul は Terraform と独自に統合されており、ネットワーク デバイスの更新と再構成を自動的にトリガーできます。オペレーターは、Consul カタログ内のサービスの変更に基づいてファイアウォールやロードバランサーなどのデバイスを自動的に更新するように Consul-Terraform-Sync (CTS) を構成できます。これらのタスクを自動化すると、手動のチケット発行システムへの依存が減り、ワークフローの効率が向上し、組織のセキュリティ体制が強化されます。

南北交通管制

組織のネットワーク内のサービス間のトラフィックを形成およびルーティングすることに加えて、これらのサービスが外部クライアントからアクセス可能であることも確認する必要があります。組織が単一のクラウドを超えて拡張する予定がない場合は、AWS API Gateway、Azure API Management、Google Cloud API Gateway などのクラウドネイティブ オプションが適切な選択肢となる可能性があります。複数のクラウドで実行している組織の場合、単一の共通プラットフォームに統合することには価値があります。

クラウドに依存しないサービス メッシュ (Consul を含む) の中には、クラウド ネイティブ ソリューションと同様の機能を提供できる API ゲートウェイが組み込まれているものもあります。これにより、組織は統合管理プレーンを使用して、サービス メッシュ内のトラフィック (東西) と外部クライアントからのトラフィック (南北) を管理できるようになり、異なる環境に複数の異なる API ゲートウェイを展開する必要がなくなります。

サービス メッシュ ツールの統合からメリットを得られるのは誰ですか?

サービス メッシュはさまざまなランタイム環境にわたるさまざまなツールの統合に役立つため、すべての組織がサービス メッシュをインフラストラクチャに統合する必要があるのでしょうか?それは状況によります。

複数のクラウドを使用している、または使用を計画している組織の 86% にとって、サービス メッシュはツールの無秩序な増加を抑制するのに間違いなく役立ちます。

単一のクラウド プロバイダーにコミットしている組織であっても、異なる開発チームが選択した異なるランタイム環境を扱っている場合があります。サービス メッシュを統合して、グローバル サービス検出、ゼロ トラスト ネットワーキング、負荷分散などの機能を提供することで、組織はツールの無秩序な増加を抑えることもできます。 Consul などのクラウドに依存しないサービス メッシュは、クラウド間でサービスを接続し、ネットワーク デバイスの更新を自動化し、外部クライアントからのサービス アクセスを制御する組み込み機能を通じて、さらなるツール統合を提供できます。

一部の小規模な組織ではツールを統合する意味がわからないかもしれませんが、少なくともサービス メッシュを力の倍増器として採用することでメリットが得られ、開発者、プラットフォーム エンジニア、ネットワーク エンジニアの追加作業を必要とせずに全体的なセキュリティ体制を改善できます。

原題:サービスメッシュでできることすべて​、著者: Van Phan