🥇サービスメッシュのユースケース

ノート。翻訳。: この記事の著者 (Luc Perkins) は、Linkerd、SMI (Service Mesh Interface)、Kuma などのオープンソースプロジェクトの本拠地である CNCF の開発者アドボケートです (ところで、なぜ Istio がこのリストに載っていないのか疑問に思ったことはありませんか?)。「サービスメッシュ」と呼ばれる流行の誇大宣伝を DevOps コミュニティにさらに理解してもらうためのもう 16 つの試みとして、彼は、このようなソリューションが提供する XNUMX の典型的な機能をリストしています。

Сегодня サービスメッシュ ― ソフトウェアエンジニアリングで最もホットなトピックの 1 つです (当然のことですが)。私はこの技術に非常に将来性があると考えており、（もちろんそれが理にかなったものなら）広く採用されるようになることを夢見ています。しかし、ほとんどの人にとって、それはまだ謎の雰囲気に包まれています。さらに、 私は彼をよく知っている それを使用すると、その利点とそれが正確に何であるかを明確に定義することが困難になることがよくあります (あなたの謙虚な僕も含めて)。この記事では、さまざまなことを列挙して状況を改善しようとします。 使用シナリオ 「サービスグリッド」*。

* 注: 翻訳: この記事のここから先は、まだ新しい用語であるサービスメッシュを表すために、この翻訳 (「サービスメッシュ」) を使用します。

しかし、まずいくつかコメントしたいと思います。

私は、自分の教育のために取り組んだプロジェクト以外で、サービスメッシュを扱ったことも、使用したこともありませんでした。一方、私は2015年にTwitterの内部サービスメッシュ（当時は「サービスメッシュ」と呼ばれていませんでした）のドキュメントを大量に書き、リンカードなので、何か意味があるのです。
私のリストはおおよそのものであり、不完全です。確かに、私が知らないユースケースは存在しますし、テクノロジーが進化して普及するにつれて、新しいユースケースが出てくる可能性もあります。
同時に、既存のサービスメッシュ実装のすべてが、リストされているユースケースのすべてをサポートしているわけではありません。したがって、「サービスメッシュは...」という私の発言は、「一部の、あるいはすべての一般的なサービスメッシュ実装は...」と解釈される必要があります。
例の順序は重要ではありません。

短いリスト:

サービス検出。
暗号化。
認証と承認。
負荷分散;
回路遮断;
自動スケーリング;
カナリアデプロイメント。
ブルーグリーンデプロイメント。
健康チェック;
負荷制限;
トラフィックミラーリング。
絶縁;
リクエストレートの制限、再試行、タイムアウト。
テレメトリー;
監査;
視覚化。

1. サービス検出

TL;DR: 単純な名前を使用して、ネットワーク上の他のサービスに接続します。

サービスは、適切な名前を使用して自動的に互いを「見つける」ことができる必要があります。 service.api.production, pets/staging または cassandra。クラウド環境は弾力性があり、複数のサービスインスタンスを 1 つの名前の背後に隠すことができます。このような状況では、すべての IP アドレスをハードコードすることは物理的に不可能であることは明らかです。

さらに、あるサービスが別のサービスを見つけた場合、そのサービスにリクエストを送信しても、そのリクエストがデッドインスタンスの入力になってしまうことを心配する必要はありません。つまり、サービスメッシュはすべてのサービスインスタンスの健全性を監視し、ホストのリストを可能な限り最新の状態に保つ必要があります。

各サービスメッシュは、サービス検出メカニズムを異なる方法で実装します。現在、最も一般的な方法は、DNS Kubernetes などの外部プロセスに委任することです。以前は、この目的で Twitter の名前システムを使用していました。フィナグル。さらに、サービスメッシュテクノロジーにより、カスタム命名メカニズムを導入することが可能になります (ただし、このような機能を備えた SM 実装にはまだ出会ったことがありません)。

2. 暗号化

TL;DR: サービス間の暗号化されていないトラフィックを排除し、このプロセスを自動化してスケーラブルにします。

攻撃者が内部ネットワークに侵入できないことを知っておくのは良いことです。ファイアウォールはこの点で非常に役立ちます。しかし、ハッカーが侵入したらどうなるでしょうか?彼はサービス内トラフィックで何でも好きなことができるのでしょうか?そんなことが起きないことを祈りましょう。このようなシナリオを防ぐには、サービス間のすべてのトラフィックが暗号化されるゼロトラストネットワークを実装する必要があります。現代のサービスグリッドのほとんどは相互接続を通じてこれを実現しています TLS (相互TLS、mTLS)。場合によっては、mTLS はクラウドやクラスター全体で機能します (惑星間通信もいつかは同様の方法で実現されるようになると思います)。

もちろん、mTLSサービスメッシュの場合 オプション。各サービスは独自の TLS を管理できますが、そのためには証明書を生成し、サービスホスト全体に配布し、ファイルからこれらの証明書を読み込むコードをアプリケーションに組み込む方法を見つける必要があります。はい、これらの証明書を定期的に更新することを忘れないでください。サービスメッシュは次のようなシステムでmTLSを自動化します。スピッフェこれにより、証明書の発行とローテーションのプロセスが自動化されます。

3. 認証と承認

TL;DR: リクエストがサービスに到達する前に、誰がリクエストを開始しているかを確認し、そのリクエストの送信者に許可されている操作を決定します。

サービスはよく知りたいと思うのは、誰がリクエスト（認証）を行い、この情報を使用して決定しますそのこの主体は、（認可）を行うことが許可されます。この場合、代名詞「who」は以下を隠している可能性があります。

その他のサービス。これを「認証」といいます ピアアたとえば、サービス web サービスにアクセスしたい db。サービスメッシュは通常、証明書が必要な識別子として機能し、mTLS を使用してこれらのタイプの問題を解決します。
一部の人間のユーザー。これを「認証」といいます リクエストたとえば、ユーザー haxor69 新しいランプを購入したいと思っています。サービスメッシュは、次のようなさまざまなメカニズムを提供します。 JSON Web Token.
私たちの多くは、アプリケーションコードでこれを実行する必要がありました。リクエストが来たらテーブルを見て usersユーザーを見つけてパスワードを比較し、列を確認します permissions サービスメッシュの場合、これはリクエストがサービスに到達する前に発生します。

リクエストの送信元が判明したら、その対象者に許可されている操作を決定する必要があります。一部のサービスメッシュでは、YAMLファイルまたはコマンドラインで基本的なポリシー（誰が何をできるか）を設定できますが、他のサービスメッシュでは次のようなフレームワークとの統合が可能です。ポリシーエージェントを開く。最終目標は、信頼できるソースからのリクエストであると確信して、サービスがあらゆるリクエストを受け入れるようにすることです。 и このアクションは許可されています。

4. 負荷分散

TL;DR: 特定のパターンに従って、サービスインスタンス間で負荷を分散します。

サービスセクションの「サービス」は、多くの場合、多数の同一のコピーで構成されます。例えば、今日のサービス cache 5部構成で、明日には11部に増えるかもしれません。リクエストは cacheは、特定の目的に従って配布されなければなりません。たとえば、レイテンシを最小限に抑えたり、稼働中のインスタンスに到達する確率を最大化したりします。最も一般的に使用されるアルゴリズムはラウンドロビンアルゴリズムですが、加重方式など、他にも多くのアルゴリズムがあります。 （加重） クエリ（優先ターゲットを選択できます）、リング （指輪） ハッシュ法（上流ホストには一貫性のあるハッシュ法を使用）または最小クエリ法（クエリが最も少ないインスタンスが優先される）のいずれかを選択します。

従来のロードバランサには、HTTP キャッシュや DDoS 保護などの他の機能もありますが、東西トラフィック (サービスメッシュの一般的なアプリケーション) にはあまり関係がありません。負荷分散にサービスメッシュを使用する必要はありませんが、集中管理されたコントロールプレーンから各サービスの負荷分散ポリシーを定義および制御できるため、ネットワークスタック内で個々のロードバランサーを実行および構成する必要がなくなります。

5. 回路遮断

TL;DR: 問題のあるサービスへのトラフィックを停止し、最悪のシナリオでの被害を制御します。

何らかの理由でサービスがトラフィックを処理できない場合、サービスメッシュはこの問題を解決するためのいくつかのオプションを提供します (その他のオプションについては、関連するセクションで説明します)。サーキットブレーキングは、サービスをトラフィックから切断するための最も強力なオプションです。しかし、それだけでは意味がありません。バックアップ計画が必要です。背圧をかけることも可能です。 (背圧) リクエストを行うサービス（このためにサービスメッシュを設定することを忘れないでください！）、または、たとえば、ステータスページを赤く塗りつぶし、「落下するクジラ」（「Twitter がダウンしています」）の次のバージョンのページにユーザーをリダイレクトします。

サービスグリッドでは、時シャットダウンが続き、そのこれは続きます。この場合、「when」には、特定の期間のリクエストの合計数、並列接続の数、保留中のリクエスト、アクティブな再試行など、指定されたパラメータの任意の組み合わせを含めることができます。

おそらく回路遮断を過度に使用することは望ましくないと思いますが、緊急時に備えてバックアップ計画があることは知っておくと安心です。

6. 自動スケーリング

TL;DR: 指定された基準に基づいてサービスインスタンスの数を増減します。

サービスメッシュはスケジューラではないので、 実施する 独立してスケーリングします。ただし、プランナーが決定を下すための情報を提供することはできます。サービスメッシュはサービス間のすべてのトラフィックにアクセスできるため、どのサービスに問題が発生しているか、どのサービスが十分に活用されていないか (割り当てられた容量が無駄になっているか) など、何が起こっているかについての広範な情報が得られます。

たとえば、Kubernetes はポッドの CPU とメモリの使用量に基づいてサービスをスケーリングします。 （レポートをご覧ください）Kubernetes の自動スケーリングとリソース管理" - 約。翻訳）ただし、他のメトリック (この場合はトラフィック関連) に基づいてスケーリングすることにした場合は、専用のメトリックが必要になります。管理このようなものこれを行う方法を示しますエンボイ, イスティオ и プロメテウスただし、プロセス自体は非常に複雑です。サービスメッシュでは、サービスインスタンスの数を増やすなどの条件を簡単に指定できるようにすることで、これを簡素化したいと考えています。 auth実行を待機しているリクエストの数が 1 分間にしきい値を超えた場合。」

7. カナリアデプロイメント

TL;DR: サービスの新機能またはバージョンを一部のユーザーに対してテストします。

SaaS 製品を開発していて、その新しいバージョンをリリースする予定だとします。ステージングでテストしたところ、うまくいきました。しかし、現実世界でのその動作については依然として懸念が残っています。つまり、ユーザーの信頼を損なうことなく、実際のタスクで新しいバージョンをテストする必要があります。カナリアデプロイメントはこれに最適です。一部のユーザーに対して新しい機能をデモンストレーションすることができます。このサブセットは、最も忠実なユーザー、製品の無料バージョンを使用しているユーザー、または「モルモット」になることを志願したユーザーで構成される場合があります。

サービスメッシュでは、アプリケーションのどのバージョンを誰が参照できるかを決定する基準を指定し、それに応じてトラフィックをルーティングすることでこれを実現します。同時に、サービス自体には何も変更はありません。サービスのバージョン 1.0 では、すべてのリクエストがサービスを参照すべきユーザーから送信されたものと想定しており、バージョン 1.1 ではユーザーについても同様であると想定しています。その間に、古いバージョンと新しいバージョン間のトラフィックの割合を変更し、新しいバージョンが安定して動作し、「モルモット」がゴーサインを出した場合、増加するユーザーを新しいバージョンにリダイレクトすることができます。

8. ブルーグリーンデプロイメント

TL;DR: クールな新機能を展開しますが、すぐに元に戻す準備をしておいてください。

意味ブルーグリーンデプロイメント新しい「ブルー」サービスを展開し、古い「グリーン」サービスと並行して開始することです。すべてが順調に進み、新しいサービスがうまく機能すれば、古いサービスは徐々に廃止することができます。（悲しいことに、いつかこの新しい「ブルー」サービスも「グリーン」サービスと同じ運命を辿り、消えてしまうでしょう…）ブルーグリーンデプロイメントは、新しい機能がカバーする点でカナリアデプロイメントとは異なります。 一気に ユーザー（一部ではない）ここでのポイントは、何か問題が発生した場合に備えて「バックアップの避難場所」を用意しておくことです。

サービスメッシュは、「ブルー」サービスをテストし、問題が発生した場合に、機能している「グリーン」サービスに即座に切り替える非常に便利な方法を提供します。言うまでもなく、それらは「青」のものの動作に関する多くの情報も提供しており（以下の「テレメトリ」セクションを参照）、それが完全に動作する準備ができているかどうかを理解するのに役立ちます。

ノート。翻訳。: Kubernetesのさまざまなデプロイメント戦略（前述のカナリア、ブルー/グリーンなどを含む）の詳細については、以下を参照してください。この記事.

9. 健康チェック

TL;DR: どのサービスインスタンスが正常であるかを監視し、正常でなくなったインスタンスに応答します。

健康診断 （健康チェック） サービスインスタンスがトラフィックを受信して処理する準備ができているかどうかを判断するのに役立ちます。例えば、HTTPサービスの場合、ヘルスチェックはエンドポイントへのGETリクエストのように見えるかもしれません。 /health。答え 200 OK はインスタンスが正常であることを意味し、それ以外はトラフィックを受信する準備ができていないことを意味します。サービスメッシュを使用すると、ヘルスチェックの実行方法と実行頻度の両方を指定できます。この情報は、負荷分散や回路遮断などの他の目的に使用できます。

したがって、健康診断はユースケースとして単独で使用されるのではなく、通常は他の目標を達成するために使用されます。また、ヘルスチェックの結果に応じて、ステータスページの更新、GitHub での問題の作成、JIRA チケットの入力など、外部 (他のサービスメッシュターゲットを基準とした) アクションが必要になる場合があります。そして、サービスメッシュは、これらすべてを自動化する便利なメカニズムを提供します。

10. 負荷制限

TL;DR: 一時的な使用量の急増に応じてトラフィックのルートを変更します。

サービスがトラフィックで過負荷になった場合、そのトラフィックの一部を一時的に別の場所にリダイレクトできます（つまり、「ドロップ」または「ポア」します）。 （小屋） 彼をそこに置きます。たとえば、バックアップサービスやデータセンター、または永続的なものなどです。プレストピック。その結果、サービスはクラッシュしてすべての処理を停止するのではなく、一部のリクエストの処理を継続します。負荷制限は回路を遮断するよりも望ましいですが、過度に使用することはお勧めできません。下流のサービスがクラッシュする原因となる連鎖的な障害を防ぐのに役立ちます。

11. トラフィックの並列化/ミラーリング

TL;DR: 1 つのリクエストを一度に複数の場所に送信します。

場合によっては、リクエスト（または選択したリクエスト）を複数のサービスに一度に送信する必要があることがあります。典型的な例としては、運用トラフィックの一部をステージングサービスに送信することが挙げられます。メインの本番Webサーバーは下流のサービスにリクエストを送信します products.production そして彼だけに。そしてサービスメッシュはこのリクエストをインテリジェントにコピーし、 products.stagingウェブサーバーはそれを認識すらしません。

トラフィック並列化の上に実装できるサービスメッシュの別の関連ユースケースは、回帰テスト。これには、サービスの異なるバージョンに同じリクエストを送信し、すべてのバージョンが同じように動作するかどうかの確認が含まれます。私はまだ、次のような統合回帰テストシステムを備えたサービスメッシュ実装に出会ったことがありません。違いますしかし、アイデア自体は有望に思えます。

12.断熱材

TL;DR: サービスメッシュをミニネットワークに分割します。

別名 セグメンテーション分離とは、サービスメッシュを、互いの情報を一切知らない論理的に分離されたセグメントに分割する技術です。分離は、仮想プライベートネットワークの作成に少し似ています。主な違いは、サービスメッシュのすべての利点 (サービス検出など) を引き続き享受しながら、セキュリティが強化される点です。たとえば、攻撃者がサブネットの 1 つでサービスに侵入できたとしても、他のサブネットで実行されているサービスを確認したり、そのトラフィックを傍受したりすることはできません。

さらに、組織的なメリットもあるかもしれません。会社の構造に基づいてサービスをサブネットに分割し、サービスメッシュ全体を念頭に置くという認知負荷から開発者を解放することもできます。

13. リクエストレート制限、再試行、タイムアウト

TL;DR: 時間のかかるリクエスト管理タスクをコードベースに含める必要がなくなりました。

これらはすべて個別のユースケースと考えることもできますが、共通する機能が 1 つあるため、グループ化することにしました。共通する機能は、通常はアプリケーションライブラリによって処理されるリクエストライフサイクル管理タスクをオフロードすることです。 Ruby on Railsウェブサーバー（サービスメッシュと統合されていない）を開発していて、バックエンドサービスにリクエストを送信する場合、 gRPCアプリケーションは、N 回の要求が失敗した場合にどうするかを自ら決定する必要があります。また、これらのサービスが処理できるトラフィックの量を把握し、特別なライブラリを使用してこれらのパラメータをハードコードする必要があります。さらに、アプリはいつ諦めてリクエストを無駄にするか（タイムアウト）を決定する必要があります。上記のパラメータを変更するには、Web サーバーを停止し、再構成して再起動する必要があります。

これらの懸念事項をサービスメッシュに委任することは、サービス開発者がそれらについて考える必要がなくなるだけでなく、よりグローバルな方法でそれらを見ることができることを意味します。たとえば、A –> B –> C –> D –> E のような複雑なサービスチェーンがある場合は、リクエストのライフサイクル全体を考慮する必要があります。タスクがサービス C のタイムアウトを延長することである場合、サービスコードを更新し、プルリクエストが受け入れられて CI システムが更新されたサービスをデプロイするまで待機することによって、部分的にではなく一度にすべてを実行するのが合理的です。

14. テレメトリ

TL;DR: サービスから必要な情報 (および必ずしも必要ではない情報) をすべて収集します。

テレメトリは、メトリック、分散トレース、およびログ記録を含む一般的な用語です。サービスメッシュは、3 種類のデータすべてを収集および処理するためのメカニズムを提供します。可能なオプションの数が多すぎるため、ここでは状況が少し曖昧になります。メトリクス収集ツールがあるプロメテウスログを収集するために使用できるその他のツール流暢, ロキ, ベクトルら。 （例えば、ClickHouseとログハウス K8sの場合 - 約（翻訳）分散トレースにはイェーガー各サービスメッシュは、一部のツールをサポートし、他のツールはサポートしない場合があります。このプロジェクトが成功するかどうかは興味深い。オープンテレメトリある程度の収束をもたらします。

この場合、サービスメッシュテクノロジの利点は、サイドカーコンテナーが原則として、サービスから上記のすべてのデータを収集できることです。つまり、単一のテレメトリ収集システムを自由に利用でき、サービスメッシュはこのすべての情報をさまざまな方法で処理できます。例えば：

CLI で特定のサービスからのログを末尾に出力します。
サービスメッシュダッシュボードからリクエスト量を追跡します。
分散トレースを収集し、Jaeger などのシステムに転送します。

注意、主観的判断： 一般的に言えば、テレメトリは強力なサービスメッシュ介入が望ましくない領域です。基本的な情報を収集し、ヒット率やレイテンシなどの「ゴールデンメトリック」をその場で追跡するのは問題ありませんが、すでに十分に確立され、十分に理解されている特殊なシステムを置き換えようとするフランケンシュタインスタックが登場しないことを祈ります。

15.監査

TL;DR: 歴史の教訓を忘れた者は、それを繰り返す運命にある。

監査とは、システム内の重要なイベントを観察する技術です。サービスメッシュの場合、これは、特定のサービスの特定のエンドポイントに誰がリクエストを送信したか、または先月特定のセキュリティ関連イベントが何回発生したかを追跡することを意味する場合があります。

監査がテレメトリと非常に密接に関連していることは明らかです。違いは、テレメトリは通常、パフォーマンスや技術的な適合性などに関連付けられているのに対し、監査は厳密に技術的な領域を超えた法的問題やその他の問題 (GDPR コンプライアンスなど) に関連する場合があることです。

16.視覚化

TL;DR: 奇妙なインターフェースの源泉である React.js 万歳。

もっと適切な用語があるかもしれませんが、私は知りません。ここで私が言いたいのは、サービスメッシュまたはそのコンポーネントの一部をグラフィカルに表現することです。これらの視覚化には、平均レイテンシ、サイドカーコンテナの構成情報、ヘルスチェックの結果、アラートなどの指標を含めることができます。

サービス指向の環境で作業する場合、モノリス陛下よりもはるかに高い認知負荷がかかります。したがって、認知的圧力はどんな犠牲を払ってでも軽減されるべきです。ボタンをクリックするだけで目的の結果が得られる、サービスメッシュのシンプルなグラフィカルインターフェイスは、このテクノロジの成長にとって非常に重要になる可能性があります。

リストに含まれなかった

当初はリストにさらにいくつかのユースケースを含めるつもりでしたが、そうしないことにしました。以下に、私の決断の理由とともにそれらを示します。

マルチデータセンター。私の考えでは、これはユースケースというよりは、サービスメッシュの狭く特定のアプリケーション、またはサービス検出などの機能セットです。
入口と出口。これは関連分野ですが、私は（おそらく人為的に）「東西トラフィック」の使用例に限定しました。入口と出口については別の記事で説明します。

まとめ

とりあえずこれで終わりです！繰り返しますが、このリストは非常に条件付きであり、不完全である可能性が高いです。何か見落としや間違いがあったと感じた場合は、Twitterでご連絡ください（フォロー）。礼儀作法を守ってください。

翻訳者からの追伸

この記事のメインイラストは、「サービスメッシュとは何ですか (いつ使用すればよいですか)?「（Gregory MacKinnon 著）。アプリケーション（緑色）の一部の機能が、それらの間の接続を提供するサービスメッシュ（青色）に移行した様子を示しています。

私たちのブログもお読みください:

出所： habr.com

サービスメッシュの使用シナリオ