サービスメッシュとは何ですか。なぜ必要なのですか（マイクロサービスを使用するクラウドアプリケーションの場合）。

翻訳者からの序文 ：今週はLinkerd 1.0のリリースでマークされました。Linkerd1.0は、この製品だけでなく、このようなソフトウェアのカテゴリであるサービスメッシュ（文字通り「サービスグリッド」と訳されます）について話す絶好の機会です。 さらに、Linkerdの著者は、対応する記事を公開しました。



tl; dr：サービスメッシュは、サービス間の安全で高速かつ信頼性の高い相互作用を保証する専用のインフラストラクチャレイヤーです。 クラウドで実行するアプリケーション（クラウドネイティブ）を作成している場合、サービスメッシュが必要です。



過去1年間、サービスメッシュはクラウドスタックの重要なコンポーネントになりました。 PayPal、Lyft、Ticketmaster、Credit Karmaなどのトラフィックの多い企業は、すでに運用中のアプリケーションにサービスメッシュを追加しており、1月にクラウドアプリケーション用のサービスメッシュのオープンソース実装であるLinkerdがCloud Native Computing Foundationの公式プロジェクトになりました （ containerdとrktは最近同じ基金に譲渡されており、少なくともKubernetesとPrometheusについても知られています-約transl。） 。 しかし、サービスメッシュとは何ですか？ そして、なぜ彼は突然必要になったのですか？









この記事では、サービスメッシュを定義し、過去10年間のアプリケーションアーキテクチャの変更を通じてその起源を追跡します。 APIゲートウェイ、エッジプロキシ、エンタープライズサービスバスなど、関連する異なる概念からサービスメッシュを分離します。 最後に、サービスメッシュが必要な場所と、クラウドネイティブの世界でこの概念を適応させるために何を期待するかについて説明します。

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

サービスメッシュは、サービス間の相互運用性のための専用インフラストラクチャレイヤーです。 彼は、クラウドで動作するように設計された最新のアプリケーションを構成するサービスの複雑なトポロジを介して、信頼性の高いリクエスト配信を担当しています。 実際には、サービスメッシュは通常、アプリケーションがそれについて知る必要なしに、アプリケーションコードとともにデプロイされる軽量ネットワークプロキシの配列として実装されます。 （ただし、このアイデアにはさまざまなバリエーションがあることがわかります。）



別のレイヤーとしてのサービスメッシュの概念は、クラウド環境専用に作成されたアプリケーションの成長に関連しています。 このようなクラウドモデルでは、1つのアプリケーションが数百のサービスで構成され、各サービスが数千のインスタンスを持ち、 Kubernetesなどのオーケストレーションツールによって実行される動的計画に応じて、各インスタンスが絶えず変化する状態を持つことができます。 この世界では、サービスの相互作用は非常に複雑なプロセスであるだけでなく、実行可能環境の動作のユビキタスで基本的な部分でもあります。 それを管理することは、パフォーマンスと信頼性を維持するために非常に重要です。

サービスメッシュはネットワークモデルですか？

はい、サービスメッシュは、TCP / IPを超える抽象レベルのネットワークモデルです。 基礎となるL3 / L4ネットワークが表され、ポイント間でバイトを送信できることが理解されます。 （このネットワークは、環境の他のすべての側面と同様に、信頼性が低いことも理解されています。サービスメッシュは、ネットワーク障害処理を提供する必要があります。）



ある意味では、サービスメッシュはTCP / IPに似ています。 TCPスタックがネットワークエンドポイント間の信頼性の高いバイト転送の仕組みから抽象化されるように、サービスメッシュはサービス間でリクエストを送信する仕組みから抽象化されます。 TCPと同様に、サービスメッシュは実際の負荷とエンコード方法を重視しません。 アプリケーションには高レベルのタスク（「AからBへ何かを送信する」）があり、TCPの場合のように、サービスメッシュは途中で発生した問題を処理することでこの問題を解決できます。



TCPとは異なり、サービスメッシュには、「何かを機能させる」だけでなく、アプリケーション全体に統一されたエントリポイントを提供し、実行可能環境の可視性と制御を提供するという重要な目標があります。 サービスメッシュの直接的な目標は、目に見えない想定されるインフラストラクチャの領域からサービス間の相互作用をもたらすことであり、生態系の本格的な参加者の役割を提供し、すべてが監視、管理、制御の対象となります。

サービスメッシュは何をしますか？

クラウドインフラストラクチャアプリケーションでの信頼できるクエリ転送は、非常に複雑になる可能性があります。 また、Linkerdのようなサービスメッシュは、ネットワークの問題からの保護、遅延を考慮したワークロードのバランス、サービスの検出（ 長期的な整合性モデルに基づく）、再試行、期限などの強力な手法でこの複雑さを処理します。 これらの機能はすべて一緒に機能する必要があり、それらと機能が動作する環境との相互作用は非常に困難です。



たとえば、Linkerdを介してサービスでリクエストが行われる場合、イベントの非常に単純化されたシーケンスは次のとおりです。

1. Linkerdは、動的ルーティングルールを適用して、要求の対象となるサービスを決定します。 本番またはステージングのサービスにリクエストを渡す必要がありますか？ ローカルデータセンターまたはクラウドのどちらでサービスを提供しますか？ テストされた最新のサービスバージョン、または実稼働環境でテストされた古いバージョン？ これらのルーティングルールはすべて動的に構成され、グローバルに、または選択したトラフィックスライスに適用できます。
2. 目的の受信者を見つけると、Linkerdは対応するエンドポイントのディスカバリサービスからインスタンスの適切なプールを照会します（複数ある場合があります）。 この情報が実際にリンカードが見るものと異なる場合、彼はどの情報源を信頼するかを決定します。
3. Linkerdは、いくつかの要因（最近のリクエストで記録されたレイテンシを含む）に基づいて、迅速な応答を返す可能性が高いインスタンスを選択します。
4. Linkerdは、操作の結果（遅延および応答タイプ）を記録して、インスタンスに要求を送信しようとします。
5. インスタンスがクラッシュする、応答しない、またはリクエストを処理できない場合、Linkerdは別のインスタンスでこのリクエストを試行します（リクエストがべき等であることがわかっている場合のみ）。
6. インスタンスが常にエラーを返す場合、Linkerdはそれを負荷分散プールから削除し、将来的に定期的にチェックします（インスタンスで短期的な障害が発生する可能性があります）。
7. 要求の期限に達すると、Linkerdは要求エラーを積極的に返し、繰り返し実行しようとして負荷を追加しません。
8. Linkerdは、上記の動作のあらゆる側面をメトリックと分散追跡の形で考慮します。このすべてのデータは、中央のメトリックシステムに送信されます。

また、これは単純化されたバージョンに過ぎません。Linkerdは、TLSの開始と終了、プロトコルの更新の実行、トラフィックの動的な切り替え、データセンター間の切り替えも実行できます。







これらの機能は、エンドポイントレベルとアプリケーションレベルの両方で復元力を提供するように設計されていることに注意することが重要です。 大規模な分散システムは、そのアーキテクチャに関係なく、1つの明確な特徴を持っています。小規模で局所的な落下がシステム全体にとって壊滅的な状態になる可能性が多くあります。 したがって、サービスメッシュは、そのような問題に対する保護を提供するように設計する必要があり、負荷を軽減し、基になるシステムが限界に達したときに急速に低下します。

サービスメッシュが必要な理由

もちろん、サービスメッシュは新しい機能を提供するのではなく、その機能が配置される場所のシフトです。 Webアプリケーションは常に、サービス間の相互作用の負担を引きずります。 サービスメッシュモデルの起源は、過去15年間のこれらのアプリケーションの進化に由来しています。



2000年代の典型的な中規模のWebアプリケーションアーキテクチャを想像してください。これらは3層です。 このモデルでは、アプリケーションロジック、コンテンツ配信ロジック、およびストレージロジックは別々のレイヤーです。 これらのレベル間の相互作用は複雑ですが、範囲が制限されています-通過セクションは2つだけです。 「メッシュ」 （つまり、メッシュ）はありません。各層のコードで実行されるトランジットセクション間のロジックの相互作用のみです。



このアーキテクチャのアプローチが非常に大規模になったとき、それは壊れ始めました。 Google、Netflix、Twitterなどの企業は、大量のトラフィックを処理する必要に直面しています。その実装はクラウドネイティブアプローチの先駆けでした。アプリケーション層は多くのサービス（マイクロサービスとも呼ばれます）に分割され、レベルがトポロジーになりました。 これらのシステムでは、インタラクション用の汎用レイヤーがすぐに必要になりましたが、通常は「シッククライアント」ライブラリの形式を取りました。TwitterのFinagle、NetflixのHystrix、GoogleのStubbyです。



多くの点で、これらのライブラリ（Finagle、Stubby、Hystrix）は最初の「サービスグリッド」でした。 それらは特定の環境で動作するように研ぎ澄まされ、特定の言語とフレームワークの使用を必要としましたが、サービス間の相互作用を管理するための専用インフラストラクチャであり、（FinagleとHystrixオープンソースライブラリの場合）それらを開発した企業だけでなく使用されました。



クラウドで実行するように設計された最新のアプリケーションへの急速な動きがありました。 クラウドネイティブモデルは、多くの小規模サービスのマイクロサービスアプローチと2つの追加要因を組み合わせています。

1. リソースの分離と依存関係の管理を提供するコンテナー（Dockerなど）
2. ハードウェアから抽象化し、単一のプールを提供するオーケストレーションレイヤー（Kubernetesなど）。

これらの3つのコンポーネントにより、アプリケーションは負荷がかかった状態でも自然に適応し、クラウドに常に存在する部分的なグリッチを処理できます。 しかし、数百のサービスと数千のインスタンス、およびインスタンスの起動を計画するためのオーケストレーションレイヤーでさえ、サービストポロジに従う単一のリクエストのパスは非常に複雑になる可能性があり、コンテナが異なる言語でサービスを作成する機能を簡素化したため、ライブラリアプローチは中止されました実用的。



複雑さと非常に重要な要素の組み合わせにより、アプリケーションコードから分離され、基盤となる環境の非常に動的な性質に対処できるサービス間の相互作用のための専用レイヤーが必要になりました。 この層はサービスメッシュです。

将来のサービスメッシュ

クラウドエコシステムでのサービスメッシュの適応は急速に成長していますが、広範でエキサイティングなロードマップ[このコンセプトとその実装のさらなる開発-約 transl。]はまだ開いていません。 サーバーなしのコンピューティング要件（Amazon Lambdaなど）は、名前とバインディング[コンポーネント]によってサービスメッシュモデルに完全に適合し、クラウドエコシステムでのアプリケーションの自然な拡張を形成します。 認定サービスとアクセスポリシーの役割はクラウド環境ではまだ非常に若いため、ここではサービスメッシュがこのニーズの基本的な部分になるのに適しています。 最後に、以前のTCP / IPのようなサービスメッシュは、基盤となるインフラストラクチャに浸透し続けます。 LinkerdがFinagleなどのシステムから進化したため、クラウドスタックに追加できるユーザー空間内の独立したプロキシとしてのサービスメッシュの現在の実装は、進化を続けます。

おわりに

サービスメッシュは、クラウドネイティブカテゴリスタックの重要なコンポーネントです。 1年ほど前に登場したLinkerdは、Cloud Native Computing Foundationの一部であり、貢献者とユーザーのコミュニティを拡大しています。 ユーザーは多様です。Monzoのようなスタートアップから、英国の銀行業界を破壊します[完全にデジタル化された銀行で、金融データにアクセスするための開発者APIを提供しています-約 トランス。] 、PayPal、Ticketmaster、Credit Karmaなどの大規模なインターネット企業、およびHoughton Mifflin Harcourtのような何百年ものビジネスの歴史を持つ企業へ。



Linkerdオープンソースコミュニティのユーザーと貢献者は、サービスメッシュモデルの価値を毎日実証しています。 私たちは、素晴らしい製品の作成とコミュニティの継続的な成長に取り組んでいます。







PS記事の著者は、2015年にLinkerdの創設者の1人であり、Buoyant Inc（LinkerdをCNCFに譲渡した開発会社）の創設者兼CEOであるWilliam Morganです。



更新 （2018年2月20日）：ブイヤントの新製品「 コンジット -Kubernetes 向けの軽量サービスメッシュ 」のレビューもブログでお読みください。