サービスメッシュとは何ですか?

こんにちは！ コース開始前夜に 「ソフトウェアアーキテクト」 もう一つ役立つ翻訳を用意しました。

サービス メッシュは、アプリケーション プログラミング インターフェイス (API) 間の大量のネットワークベースのプロセス間通信を処理するために必要な、構成可能な低遅延インフラストラクチャ層です。 Service Mesh は、コンテナ化された、多くの場合一時的なアプリケーション インフラストラクチャ サービス間の高速で信頼性の高い安全な通信を可能にします。 Service Mesh は、サービス検出、負荷分散、暗号化、透過性、トレーサビリティ、認証と認可、自動シャットダウン パターンのサポートなどの機能を提供します (遮断器).
サービス メッシュは通常、各サービス インスタンスにプロキシ インスタンスを提供することによって実装されます。 サイドカー。 サイドカー サービス間の通信を処理し、セキュリティ問題を監視および解決します。つまり、個々のサービスから抽象化できるすべてのものです。 このようにして、開発者はサービスでアプリケーション コードを作成、保守、提供でき、システム管理者はサービス メッシュを操作してアプリケーションを実行できます。

Google、IBM、Lyft の Istio は、現在最も有名なサービス メッシュ アーキテクチャです。 また、もともと Google で開発された Kubernetes は、現在 Istio でサポートされている唯一のコンテナ オーケストレーション フレームワークです。 ベンダーは、商用サポートされる Istio バージョンを作成しようとしています。 彼らがオープンソース プロジェクトにどのような新しいものをもたらすことができるかを見るのは興味深いでしょう。

ただし、他のサービス メッシュ実装が開発されているため、Istio が唯一の選択肢ではありません。 パターン sidecar proxy Buoyant、HashiCorp、Solo.io などのプロジェクトから判断できるように、最も人気のある実装です。 代替アーキテクチャもあります。Netflix テクノロジー ツールキットは、Ribbon、Hysterix、Eureka、Archaius ライブラリ、および Azure Service Fabric などのプラットフォームを通じて Service Mesh 機能を実装するアプローチの XNUMX つです。

Service Mesh には、サービス コンポーネントと機能に関する独自の用語もあります。

• コンテナ オーケストレーション フレームワーク。 アプリケーション インフラストラクチャに追加されるコンテナが増えるにつれて、コンテナを監視および管理するための別のツール、つまりコンテナ オーケストレーション フレームワークが必要になります。 Kubernetes はこのニッチ市場をしっかりと占有しており、主な競合他社である Docker Swarm や Mesosphere DC/OS でさえ代替手段として Kubernetes との統合を提供しています。
• サービスとインスタンス (Kubernetes ポッド)。 インスタンスは、マイクロサービスの単一の実行コピーです。 XNUMX つのインスタンスが XNUMX つのコンテナである場合もあります。 Kubernetes では、インスタンスはポッドと呼ばれる独立したコンテナの小さなグループで構成されます。 クライアントがインスタンスやポッドに直接アクセスすることはほとんどなく、より多くの場合、同一でスケーラブルでフォールトトレラントなインスタンスやポッド (レプリカ) のセットであるサービスにアクセスします。
• サイドカープロキシ。 サイドカー プロキシは、単一のインスタンスまたはポッドで動作します。 サイドカー プロキシのポイントは、連携するコンテナからのトラフィックと戻りのトラフィックをルーティングまたはプロキシすることです。 Sidecar は他の Sidecar Proxies と対話し、オーケストレーション フレームワークによって管理されます。 多くのサービス メッシュ実装では、サイドカー プロキシを使用して、インスタンスまたはポッドに出入りするすべてのトラフィックをインターセプトして管理します。
• サービスディスカバリ。 インスタンスが別のサービスと通信する必要がある場合、他のサービスの正常で利用可能なインスタンスを見つける (検出する) 必要があります。 通常、インスタンスは DNS ルックアップを実行します。 コンテナ オーケストレーション フレームワークは、リクエストを受信する準備ができているインスタンスのリストを維持し、DNS クエリ用のインターフェイスを提供します。
• 負荷分散。 ほとんどのコンテナ オーケストレーション フレームワークは、レイヤー 4 (トランスポート) で負荷分散を提供します。 サービス メッシュは、レイヤー 7 (アプリケーション レベル) でより複雑な負荷分散を実装し、アルゴリズムが豊富で、トラフィックの管理がより効果的です。 API を使用して負荷分散設定を変更できるため、Blue-Green または Canary デプロイメントを調整できます。
• Шифрование。 Service Mesh はリクエストとレスポンスを暗号化および復号化できるため、サービスからこの負担を取り除くことができます。 Service Mesh は、既存の永続接続に優先順位を付けたり再利用したりすることでパフォーマンスを向上させ、新しい接続を作成するための高価な計算の必要性を軽減することもできます。 トラフィック暗号化の最も一般的な実装は次のとおりです。 相互TLS (mTLS)、公開キー基盤 (PKI) が、サイドカー プロキシで使用する証明書とキーを生成および配布します。
• 認証と認可。 サービス メッシュは、アプリケーションの外部または内部から行われたリクエストを承認および認証し、検証されたリクエストのみをインスタンスに送信します。
• 自動シャットダウンパターンのサポート。 サービスメッシュのサポート 自動シャットダウンパターンこれにより、異常なインスタンスが隔離され、必要に応じてそれらのインスタンスが徐々に正常なインスタンスのプールに戻されます。

インスタンス間のネットワーク トラフィックを管理する Service Mesh アプリケーションの部分は、 データプレーン。 動作を制御する構成を作成して展開する データプレーン、別のメソッドを使用して実行されます。 コントロールプレーン. コントロールプレーン 通常、アプリケーションを制御するための API、CLI、または GUI が含まれているか、それらに接続するように設計されています。

サービス メッシュのコントロール プレーンは、サイドカー プロキシとデータ プレーンの間で構成を分散します。

サービス メッシュ アーキテクチャは、コンテナーとマイクロサービスを使用して複雑な運用上の問題を解決するためによく使用されます。 この分野のパイオニア マイクロサービス Lyft、Netflix、Twitter などの企業は、世界中の何百万ものユーザーに安定したサービスを提供しています。 (ここでは、Netflix が直面したアーキテクチャ上の課題の一部を詳しく見ていきます。）。 それほど要求の厳しいアプリケーションの場合は、より単純なアーキテクチャで十分である可能性があります。

Service Mesh アーキテクチャが、アプリケーションの運用と配信に関するすべての問題を解決できるとは考えられません。 建築家や開発者は膨大なツールを持っていますが、その中でハンマーは XNUMX つだけです。多くのタスクの中で解決しなければならないのは、釘を打つという XNUMX つだけです。 NGINX のマイクロサービス リファレンス アーキテクチャたとえば、マイクロサービスを使用して問題を解決するための一連のアプローチを提供するいくつかの異なるモデルが含まれています。

アーキテクチャ アプローチとしての NGINX、コンテナ、Kubernetes、マイクロサービスなど、サービス メッシュ アーキテクチャに統合される要素は、サービス メッシュ以外の実装でも同様に生産性を高めることができます。 たとえば、Istio は完全なサービス メッシュ アーキテクチャとして設計されていますが、そのモジュール性により、開発者は必要なテクノロジ コンポーネントのみを選択して実装できます。 これを念頭に置くと、アプリケーションにサービス メッシュの概念を完全に実装できるかどうかわからない場合でも、サービス メッシュの概念を明確に理解することが重要です。

モジュラーモノリスと DDD

出所： habr.com