サービスメッシュと従来の API ゲートウェイでは、分散システム内のネットワークトラフィックを管理する上での役割が明確に異なります。サービスメッシュはマイクロサービス間の内部通信に重点を置き、アプリケーションコードを変更する必要なく、トラフィック管理のきめ細かい制御、負荷分散、可観測性をもたらします。一方、API ゲートウェイは外部クライアントのための一元化されたエントリーポイントとして機能し、クライアントに面する API の認証、認可、リクエストルーティングなどのタスクを処理します。
サービスメッシュは、分散システム内のマイクロサービスにネットワーク接続、セキュリティ、可観測性をもたらす専門的なインフラレイヤーです。負荷分散、回路遮断、トラフィックシフト、再試行メカニズムなど、サービス間の通信の複雑さを抽象化することで機能します。
サービスメッシュを定義するためには、まずマイクロサービスを定義する必要があります。マイクロサービスの仕組みを知らなければ、サービスメッシュについての解説を読んでも、飛行機を知らないのにファーストクラスとエコノミークラスを比較するようなものです。サービスメッシュはマイクロサービスベースのアプリケーションの動作を向上させるために生み出されたテクノロジーですが、それによって物事が複雑化することが多いと主張する人もいます。
マイクロサービスについて
マイクロサービスはソフトウェア・アプリケーション・アーキテクチャに対する最新のアプローチであり、アプリケーションは「サービス」と呼ばれる疎結合された小さなコンポーネントに分割されます。これらのマイクロサービスが集合的に、アプリケーション機能全体を提供します。このアプローチは、すべての機能を 1 つのソフトウェアに統合する従来の「モノリシック」なアプリケーションアーキテクチャとは対照的です。
Netflix はマイクロサービスの代表的な例です。10 年前、Netflix は統合型の巨大なソフトウェアアプリケーションでした。Netflix のすべての機能が単一の大規模なコードベース内に存在していました。これには、アプリケーションの一部を変更すると全体を再展開することになるという問題があり、ユーザーの多い商業的に重要なソフトウェアにとって望ましい状況ではありませんでした。
マイクロサービスアーキテクチャへの移行後、コンテンツ管理からアカウント管理、プレーヤーまで、Netflix の各領域が独自のマイクロサービスとして存在しています。実際には、詳細に見てみると、それらの各領域は複数のマイクロサービスで構成されています。開発者は各マイクロサービスに対して個別に作業を行うことができます。他のマイクロサービスへの影響を心配することなく、変更、スケーリング、再設定を行えます。理論的には、1 つのマイクロサービスに障害が発生しても、アプリケーションの残りの部分が停止することはありません（例外的なシナリオもあります）。
サービスメッシュとは
マイクロサービスアーキテクチャがどのようなものかを念頭に置いて、マイクロサービスベースのアプリケーション機能を信頼性の高いものにしようとする際に発生する可能性のある課題について考えてみましょう。このアーキテクチャはアプリケーションを独立したサービスに分離するという画期的な機能を備えていますが、多くの困難をもたらします。
特に、他のマイクロサービスの場所、通信方法、アプリ内で起きていることをマイクロサービスが把握するための仕組みがなければ、マイクロサービス間の通信が問題になる可能性があります。例えば、Netflix のストリーミングマイクロサービスは、加入者のアカウントに関する情報を見つけるためにはどこを調べればよいのかをどのように把握しているのでしょうか。そこで、サービスメッシュの出番です。しかし、サービスメッシュの支持者ではない人を落ち着かせるためには、このためにサービスメッシュがどうしても必要ではないということを指摘することが重要です。
サービスメッシュは、ネットワークを介したマイクロサービス間の通信を管理するインフラレイヤーです。アプリ内のサービスリクエストを制御します。また、サービスメッシュは通常、サービス探索、フェイルオーバー、負荷分散に加え、セキュリティ機能（暗号化など）を提供します。
サービスメッシュの仕組み
サービスメッシュの役割は、マイクロサービスベースのシステムにセキュリティ、可観測性、信頼性を追加することです。これは、各マイクロサービスに付加される「サイドカー」と呼ばれるプロキシを使用することで実現します（eBPF に基づく「サイドカーなし」のサービスメッシュもあります）。サイドカーは OSI スタックのレイヤー 7 で動作します。アプリケーションがコンテナベースである場合、サイドカーは各コンテナまたは仮想マシン（VM）に付加されます。その後、プロキシは「データプレーン」と「コントロールプレーン」で動作します。
データプレーンは、サイドカープロキシの隣で実行されるサービスで構成されます。サービス／サイドカーのペアごとに、サービスはアプリケーションのビジネスロジックを処理し、プロキシはサービスとシステム内の他のサービスの間に位置します。サイドカープロキシは、サービスへのトラフィックとサービスからのトラフィックをすべて処理します。また、Mutual Transport Layer Security（mTLS）などの接続機能を提供します。これにより、要求／応答メッセージフロー内の各サービスが他方の証明書を検証できます。
コントロールプレーンは、管理者がサービスメッシュとのインタラクションを行う場所です。プロキシの設定と制御や、サービスメッシュの管理に対処し、プロキシのセットアップと調整の方法を提供します。管理者はコントロールプレーンを通じてアクセス制御ポリシーを適用し、マイクロサービス間を移動するメッセージのルーティングルールを定義します。また、コントロールプレーンは、マイクロサービスの可観測性に関連するログやその他のデータをエクスポートできるようにします。
サービスメッシュのデータプレーンとコントロールプレーンが連携することで、次のことが可能になります。
セキュリティ — 認証や認可などのセキュリティポリシーをマイクロサービスに供給し、マイクロサービス間の通信を自動的に暗号化します。サービスメッシュはコントロールプレーンを通じてセキュリティポリシーを管理、監視、適用できます。
信頼性 — コントロールプレーン内のサイドカープロキシを介してマイクロサービス間の通信を管理し、プロセス内のサービスリクエストの信頼性を向上させます。また、サービスメッシュは、信頼性の強化と高可用性（HA）の実現を目的として、障害の負荷分散管理に対処できます。
可観測性 — マイクロサービスのパフォーマンスをシステム所有者に示します。サービスメッシュは、リソースを大量に消費しているマイクロサービスや障害のリスクのあるマイクロサービスを明らかにすることができます。サービスメッシュのコントロールプレーンは、マイクロサービスと他のアプリケーションコンポーネント間のインタラクションに関するテレメトリデータを収集します。
Kubernetes とサービスメッシュの統合
Kubernetes は広く採用されているコンテナ・オーケストレーション・プラットフォームであり、マイクロサービスの管理において重要な役割を担います。サービスメッシュを Kubernetes と統合することで、Kubernetes エコシステムで実行されるマイクロサービスの制御、セキュリティ、可観測性が強化されます。Kubernetes を Istio や Linkerd などのサービスメッシュと組み合わせることで、自動サービス探索、負荷分散、障害復旧が可能になります。Kubernetes とサービスメッシュはオープンソースであるため、組織は幅広いコミュニティや、クラウド・ネイティブ・アプリケーションをサポートするために継続的に進化する豊富なツールセットからメリットを得ることができます。Kubernetes をコンテナ管理の基盤として使用し、それをサービスメッシュと組み合わせることで、組織はサービス間の通信の可視性を向上させ、サービスインタラクションのレイテンシーを軽減し、システム全体の回復力を向上させることができます。
サービスメッシュとマイクロサービスの違い
マイクロサービスとサービスメッシュは混同されやすいです。マイクロサービスは、マイクロサービスベースのシステムのコンポーネントです。サービスメッシュはそれを接続することができます。その名のとおり、サービスメッシュはマイクロサービスの上に重なる連結組織のようなものです。言い換えると、サービスメッシュは、マイクロサービスベースのアプリケーションを動作させる相互接続と関連ロジックを管理するために実装される「パターン」です。
サービスメッシュが必要である理由
モノリシックなアプリケーションは、規模が大きくなり複雑化するとうまく機能しません。そうすると、アプリケーションをマイクロサービスに分割することが理にかなうようになります。このアプローチは、アジャイル、DevOps、継続的インテグレーション／継続的デリバリー（CI／CD）などの現代的なアプリケーション開発手法と整合しています。ソフトウェア開発チームとそのテストパートナーや運用パートナーは、個別の独立したマイクロサービスの新しいコードに集中できます。これは通常、ソフトウェアにとってもビジネス全体にとっても最善です。
しかし、マイクロサービスベースのアプリ内のサービス数が増加すると、すべての接続に対応することが困難になる可能性があります。関係者は、各サービスが他のサービスとどのように接続し、インタラクションを行う必要があるかを追跡するのに苦労する可能性がありますサービスの健全性を監視することが困難になります。数十から数百ものマイクロサービスを接続して監視する場合、信頼性も問題になる可能性があります。
サービスメッシュは、開発者が専門的なインフラレイヤーでサービス間の通信を処理できるようにすることにより、そのような問題に対処します。開発者は、数百もの接続を 1 つずつ処理するのではなく、コントロールプレーン内のプロキシを通じてアプリケーション全体を管理できます。サービスメッシュは、効率的な管理および監視機能をもたらします。
簡単に言うと、サービスメッシュの主なメリットは次のとおりです。
マイクロサービス間の通信をシンプル化する
通信エラーの検知と把握を容易にする
暗号化、認証、認可により、アプリのセキュリティを強化する
新しいマイクロサービスの開発、テスト、展開を迅速化することで、アプリ開発を高速化する
サービスメッシュの課題
しかし、サービスメッシュには独自の問題があります。例えば、サービスメッシュのレイヤーは、インフラ、メンテナンス、サポートなどを必要とする新たなシステム要素となります。それにリソースが奪われ、ネットワークとハードウェアの全体的なパフォーマンスに影響が生じる可能性があります。サイドカープロキシを追加することで、すでに複雑な環境がさらに複雑化する可能性があります。サイドカーを介してサービスコールを実行すると、手順が増え、アプリケーションの速度が低下する可能性があります。複数のマイクロサービスアーキテクチャ間の統合に関連する問題が発生するかもしれません。サービスメッシュが管理やサービス間の通信に対処しますが、依然としてネットワークの管理が必要です。
自動化によるサービスメッシュ内のレイテンシーの低減
サービスメッシュの主な懸念事項の 1 つは、サービス通信を処理するプロキシのレイヤーが追加されることにより、レイテンシーが増加する可能性があることです。しかし、Istio や Linkerd などのサービスメッシュには、そのようなレイテンシーの懸念を緩和する自動化機能が備わっています。インテリジェントなトラフィック管理と自動再試行により、サービスメッシュは通信経路を合理化し、遅延を最小限に抑えることができます。さらに、Istio は Envoy を使用してルーティングの決定を最適化し、自動化を活用して潜在的なネットワークボトルネックを回避することによってサービス間の応答を高速化します。これにより、レイテンシーが重大な問題になる可能性のある大規模なクラウドネイティブ環境でも、アプリケーションは高いパフォーマンスを維持できます。オープン・ソース・コミュニティによる継続的な更新と最適化により、現代的なサービスメッシュはますます、高度なトラフィック管理機能と最小限のオーバーヘッドのバランスを取ることができるようになっています。
結論
サービスメッシュはマイクロサービスで成功を収めるために役立ちます。このテクノロジーは、サービスと関連管理機能間の通信を処理するために必要なインフラレイヤーを提供します。適切な方法で実装されたサービスメッシュは、マイクロサービスベースのアプリケーションとシステムにセキュリティ、信頼性、可観測性をもたらします。
よくある質問
サービス・メッシュ・アーキテクチャは、安全な通信とデータ保護を実現するさまざまな機能を提供することにより、マイクロサービス内のセキュリティを強化します。重要なセキュリティ機能の 1 つとして、サービス間の暗号化通信を可能にする相互 TLS（mTLS）があげられます。さらに、サービスメッシュにより、きめ細かいアクセス制御ポリシーを適用できるようになり、管理者はサービスレベルでアクセス権限を定義して適用できます。
サービスメッシュの実装は、初めは複雑に見えるかもしれません。しかし、最初の複雑さより、長期的なメリットの方が上回っています。
自社の要件やインフラに合ったサービス・メッシュ・ソリューションを選択することが重要です。各サービスメッシュには独自の機能と統合があるため、固有のニーズに基づいてそれらを評価してください。非本番環境または一部のマイクロサービスサブセットにサービスメッシュを展開し、基本的なセットアップから開始します。組織の要件に基づいて、アクセス制御ポリシー、トラフィック・ルーティング・ルール、アプリケーションセキュリティ設定を定義します。
安定性とパフォーマンスに確信が持てるようになったら、サービスメッシュを他のマイクロサービスや環境に徐々に展開します。フィードバック、パフォーマンス指標、変化する要件に基づいて、サービスメッシュのセットアップを継続的に繰り返し、改善します。
自社のニーズに最適なサービスメッシュを決定する際に考慮すべき要素がいくつかあります。
コミュニティサポート：有益なリソースやドキュメントを提供しコミュニティ主導で貢献できる積極的なコミュニティサポートを備えたサービスメッシュを探します。
使いやすさ：直感的なツール、明快なドキュメント、使いやすいインターフェースを備えたソリューションを選択し、導入と継続的なメンテナンスをシンプル化します。
機能セット：各サービスメッシュの機能を評価し、自社の要件に適合しているかどうかを判断します。トラフィック管理機能、可観測性ツール、セキュリティ機能を探します。
互換性：サービスメッシュが既存のインフラ（コンテナ・オーケストレーション・プラットフォームやクラウド環境など）に適合することを確認します。
パフォーマンスとスケーラビリティ：予想されるワークロードに対応し、インフラの拡大に合わせてスケーリングできるソリューションを選択します。
Akamai が選ばれる理由
Akamai はサイバーセキュリティとクラウドコンピューティングを提供することで、オンラインビジネスの力となり、守っています。市場をリードするセキュリティソリューション、優れた脅威インテリジェンス、そして世界中の運用チームが、あらゆるところで企業のデータとアプリケーションを多層防御で守ります。Akamai のフルスタック・クラウドコンピューティング・ソリューションは、世界で最も分散されたプラットフォーム上で、パフォーマンスと手頃な価格を両立します。安心してビジネスを展開できる業界トップクラスの信頼性、スケール、専門知識の提供により、Akamai はグローバル企業の信頼を獲得しています。
