なぜエンタープライズ サービス メッシュを作成するのでしょうか?

Service Mesh は、マイクロサービスを統合し、クラウド インフラストラクチャに移行するためのよく知られたアーキテクチャ パターンです。 今日、クラウド コンテナーの世界では、クラウド コンテナーなしで業務を遂行することは非常に困難です。 いくつかのオープンソース サービス メッシュ実装がすでに市場で入手可能ですが、その機能、信頼性、セキュリティは、特に全国の大手金融会社の要件となると、必ずしも十分であるとは限りません。 だからこそ、私たち Sbertech は Service Mesh をカスタマイズすることに決め、Service Mesh の何が優れているのか、何がそれほど優れていないのか、そしてそれについて私たちが何をしようとしているのかについて話したいと思います。

クラウド テクノロジーの人気に伴い、サービス メッシュ パターンの人気も高まっています。 これは、さまざまなネットワーク サービス間の対話を簡素化する専用のインフラストラクチャ層です。 最新のクラウド アプリケーションは数百、場合によっては数千のそのようなサービスで構成されており、それぞれのサービスには数千のコピーが存在する場合があります。

これらのサービス間の対話と管理は、サービス メッシュの重要なタスクです。 実際、これは多数のプロキシからなるネットワーク モデルであり、一元的に管理され、非常に便利な機能のセットを実行します。

プロキシ レベル (データ プレーン):

• ルーティングおよびトラフィックバランシングポリシーの割り当てと配布
• キー、証明書、トークンの配布
• テレメトリの収集、監視メトリクスの生成
• セキュリティおよび監視インフラストラクチャとの統合

コントロール プレーン レベル:

• ルーティングおよびトラフィック分散ポリシーの適用
• 再試行とタイムアウトの管理、「デッド」ノード (回路遮断) の検出、障害の挿入の管理、および他のメカニズムによるサービスの回復力の確保
• 通話認証/認可
• メトリクスの削除 (可観測性)

このテクノロジーの開発に興味を持つユーザーの範囲は非常に広く、小規模な新興企業から PayPal などの大規模なインターネット企業に至るまで多岐にわたります。

Service Mesh が企業部門に必要な理由は何ですか?

サービス メッシュを使用すると、明らかな利点が数多くあります。 まず第一に、開発者にとっては、コードを書くのに便利です。 テクノロジープラットフォームが登場トランスポート層がアプリケーション ロジックから完全に分離されているため、クラウド インフラストラクチャへの統合が大幅に簡素化されます。

加えて、 Service Mesh は、サプライヤーとコンシューマー間の関係を簡素化します。 今日では、API プロバイダーとコンシューマーが、特別な統合仲介者および調停者であるエンタープライズ サービス バスを介さずに、独自にインターフェイスとコントラクトに同意することがはるかに簡単になりました。 このアプローチは XNUMX つの指標に大きな影響を与えます。 新しい機能を市場に投入する速度 (市場投入までの時間) は向上しますが、同時に統合を個別に行う必要があるため、ソリューションのコストも増加します。 ビジネス機能開発チームが Service Mesh を使用すると、このバランスを維持するのに役立ちます。 その結果、API プロバイダーは、サービスのアプリケーション コンポーネントにのみ焦点を当て、それをサービス メッシュで公開するだけで済みます。API はすべてのクライアントですぐに利用できるようになり、統合の品質は本番環境に対応し、単一のコンポーネントを必要としません。追加コードの行。

次の利点は、 開発者は、Service Mesh を使用して、ビジネス機能のみに焦点を当てます。 — サービスの技術的要素ではなく、製品について。 たとえば、ネットワーク経由でサービスを呼び出す場合、どこかで接続障害が発生する可能性があるということを考える必要がなくなります。 さらに、サービス メッシュは、同じサービスのコピー間でトラフィックのバランスをとるのに役立ちます。コピーの XNUMX つが「停止」すると、システムはすべてのトラフィックを残りのライブ コピーに切り替えます。

サービス メッシュ - これは分散アプリケーションを作成するための良い基礎となりますこれにより、内部および外部の両方でサービスへの呼び出しを提供する詳細がクライアントから隠蔽されます。 Service Mesh を使用するすべてのアプリケーションは、ネットワークからも相互からもトランスポート レベルで分離されており、アプリケーション間には通信がありません。 この場合、開発者は自分のサービスを完全に制御できるようになります。

注意すべきこと サービス メッシュ環境での分散アプリケーションの更新が容易になります。 たとえば、Blue/Green デプロイメントでは、XNUMX つのアプリケーション環境をインストールでき、そのうちの XNUMX つは更新されておらず、スタンバイ モードになっています。 リリースが失敗した場合の以前のバージョンへのロールバックは、サービス メッシュが適切に対応する特別なルーターによって実行されます。. 新しいバージョンをテストするには、次を使用できます カナリアリリース — クライアントのパイロット グループからのトラフィックまたはリクエストの 10% のみを新しいバージョンに切り替えます。 メインのトラフィックは古いバージョンに移行し、何も壊れません。

また Service Mesh により、リアルタイムの SLA 制御が可能になります。 分散プロキシ システムでは、クライアントの XNUMX つが割り当てられたクォータを超えたときにサービスが失敗することはありません。 API スループットが制限されている場合、大量のトランザクションで API スループットを圧倒することはできません。サービス メッシュはサービスの前に立って、不必要なトラフィックを許可しません。 統合レイヤーで反撃するだけで、サービス自体はそれに気づかずに動作し続けます。

企業が統合ソリューションの開発コストを削減したい場合、Service Mesh は次のことにも役立ちます。 商用製品からオープンソース版に切り替えることができます。 当社の Enterprise Service Mesh は、Service Mesh のオープンソース バージョンに基づいています。

もう一つの利点 - 単一の本格的な統合サービスセットの利用可能性。 すべての統合はこのミドルウェアを通じて構築されるため、会社のビジネスの中核を形成するアプリケーション間のすべての統合トラフィックと接続を管理できます。 とても快適です。

そして最後に Service Mesh は、企業が動的なインフラストラクチャに移行することを促進します。 現在、多くの人がコンテナ化に注目しています。 モノリスをマイクロサービスに分割し、これらすべてを美しく実装する - というトピックが高まっています。 しかし、長年運用されてきたシステムを新しいプラットフォームに移行しようとすると、すぐに多くの問題に遭遇します。すべてをコンテナにプッシュしてプラットフォームにデプロイするのは簡単ではありません。 そして、これらの分散コンポーネントの実装、同期、相互作用も、非常に複雑なトピックです。 彼らはどうやってお互いにコミュニケーションを取るのでしょうか？ 連鎖的に障害が発生する可能性はありますか? Service Mesh を使用すると、ネットワーク交換ロジックを忘れることができるため、これらの問題の一部を解決し、古いアーキテクチャから新しいアーキテクチャへの移行を容易にすることができます。

Service Mesh のカスタマイズが必要な理由は何ですか?

私たちの会社では、数百のシステムとモジュールが共存しており、ランタイムには非常に負荷がかかります。 したがって、あるシステムが別のシステムを呼び出して応答を受け取るという単純なパターンだけでは十分ではありません。本番環境ではさらに多くのことが必要になるからです。 エンタープライズ サービス メッシュには他に何が必要ですか?

イベント処理サービス

リアルタイム イベント処理、つまりクライアントの行動をリアルタイムで分析し、適切なオファーを即座に提示できるシステムを作成する必要があると想像してみましょう。 同様の機能を実装するには、次を使用します イベント駆動型アーキテクチャ (EDA) と呼ばれるアーキテクチャ パターン。 現在のサービス メッシュはそのようなパターンをネイティブにサポートしていませんが、これは特に銀行にとって非常に重要です。

リモート プロシージャ コール (RPC) が Service Mesh のすべてのバージョンでサポートされているのに、EDA と相性が悪いのは非常に奇妙です。 Service Mesh は一種の最新の分散統合であり、EDA は顧客エクスペリエンスの観点から独自のことを可能にする、非常に関連性の高いアーキテクチャ パターンであるためです。

私たちのエンタープライズ サービス メッシュは、この問題を解決するはずです。 さらに、さまざまなフィルターやテンプレートを使用した、保証された配信、ストリーミング、複雑なイベント処理の実装も確認したいと考えています。

ファイル転送サービス

EDA に加えて、ファイルを転送できれば便利です。エンタープライズ規模では、多くの場合、ファイル統合のみが可能です。 特に、ETL (抽出、変換、ロード) アーキテクチャ パターンが使用されます。 その中では、原則として、全員が排他的にファイルを交換します。ビッグデータが使用されるため、個別のリクエストをプッシュするのは非現実的です。 Enterprise Service Mesh でファイル転送をネイティブにサポートする機能により、ビジネスに必要な柔軟性が得られます。

オーケストレーションサービス

大規模な組織では、ほとんどの場合、異なる製品を作成する異なるチームが存在します。 例えば銀行では、預金を扱うチームと融資商品を扱うチームがあり、そのようなケースは非常に多いです。 これらは、製品を作成し、API を開発し、他の人に提供するさまざまな人々、さまざまなチームです。 そして、多くの場合、これらのサービスを構成し、一連の API を順次呼び出すための複雑なロジックを実装する必要があります。 この問題を解決するには、この複合ロジック (複数の API の呼び出し、リクエスト ルートの記述など) をすべて簡素化する統合レイヤーのソリューションが必要です。 これは、Enterprise Service Mesh のオーケストレーション サービスです。

AI と ML

マイクロサービスが単一の統合レイヤーを介して通信する場合、サービス メッシュは自然に各サービスの呼び出しに関するすべてを認識します。 私たちは、誰が、誰に、いつ、どのくらいの時間、何回電話をかけたかなどのテレメトリを収集します。 これらのサービスが数十万件あり、通話が数十億件ある場合、これらすべてが蓄積され、ビッグ データが形成されます。 このデータは AI や機械学習などを使用して分析され、分析結果に基づいていくつかの有用な処理が可能になります。 サービス メッシュに統合されたこのすべてのネットワーク トラフィックとアプリケーション呼び出しの制御を、少なくとも部分的に人工知能に引き渡すことが適切でしょう。

APIゲートウェイサービス

通常、サービス メッシュには、信頼された境界内で相互に通信するプロキシとサービスがあります。 しかし、外部の取引相手もいます。 このグループの消費者に公開される API の要件は、はるかに厳格です。 このタスクは XNUMX つの主要な部分に分けられます。

• セキュリティ。 DDO、プロトコル、アプリケーション、オペレーティング システムなどの脆弱性に関連する問題。
• スコープ。 クライアントに提供する必要がある API の数が数千、さらには数十万に達すると、この API セットに対して何らかの管理ツールが必要になります。 API が動作しているかどうか、ステータスは何か、どのようなトラフィックが流れているか、どのような統計情報があるかなど、API を常に監視する必要があります。 API ゲートウェイは、プロセス全体を管理可能かつ安全にしながら、このタスクを処理する必要があります。 このコンポーネントのおかげで、Enterprise Service Mesh は内部 API と外部 API の両方を簡単に公開できるようになります。

特定プロトコル・データ形式対応サービス（ASゲートウェイ）

現在、ほとんどのサービス メッシュ ソリューションは、HTTP および HTTP2 トラフィックでのみネイティブに動作するか、TCP/IP レベルの縮小モードで動作します。 Enterprise Service Mesh は、他の多くの非常に特殊なデータ転送プロトコルとともに登場しています。 システムによってはメッセージ ブローカーを使用する場合もあれば、データベース レベルで統合されるシステムもあります。 企業に SAP がある場合は、独自の統合システムを使用することもできます。 さらに、これらはすべて機能しており、ビジネスの重要な部分です。

「レガシーを放棄して、Service Mesh を使用できる新しいシステムを作りましょう」と言うだけでは済みません。 すべての古いシステムを (マイクロサービス アーキテクチャ上で) 新しいシステムに接続するには、Service Mesh を使用できるシステムに何らかのアダプター、仲介、ゲートウェイが必要です。 そうですね、サービスと一緒に箱に入っていれば良いですね。 AC ゲートウェイは、あらゆる統合オプションをサポートできます。 想像してみてください。Enterprise Service Mesh をインストールするだけで、必要なすべてのプロトコルと対話できるようになります。 このアプローチは私たちにとって非常に重要です。

これは、Service Mesh の企業版 (Enterprise Service Mesh) を大まかにイメージするものです。 ここで説明するカスタマイズにより、統合プラットフォームの既製のオープンソース バージョンを使用しようとするときに発生する問題のほとんどが解決されます。 わずか数年前に導入された Service Mesh アーキテクチャは進化し続けており、私たちはその開発に貢献できることを嬉しく思っています。 私たちの経験があなたのお役に立てば幸いです。

出所： habr.com