サービス メッシュは本当にクラウド ネイティブ アプリケーションに最適ですか?

マイクロサービス アーキテクチャを実装する企業が増えるにつれて、コミュニティにおけるサービス メッシュと関連ソリューションに関する議論が徐々に増加しています。 「フルスタックの可観測性」、透過的なセキュリティ、システムの弾力性などのサービス メッシュの機能は魅力的ですが、クラウド ネイティブ アプリケーションに本当に最適なのでしょうか?この記事では、サービス メッシュが意味をなす場合と意味をなさない場合について考察します。

[[236296]]

優れたマイクロサービスアーキテクチャは、よりアジャイルに行動することを可能にします

現在、製品やサービスの「市場投入までの時間」が企業の競争力を決定します。市場や顧客のニーズに迅速に対応できる企業が失敗することは難しい。マイクロサービス アーキテクチャは、ソフトウェアの俊敏性とワークフロー全体の「スピード」を強力にサポートします。さまざまなチームにアプリケーションのさまざまな部分を処理させる権限を与えることで、意思決定が「分散化」されます。

「分散型」意思決定には 2 つの重要な結果があります。まず、ソフトウェア チームは、グローバル標準に依存せずに、アーキテクチャ、リリース、テストなどに関する「ローカライズされた」決定を下すことができます。たとえば、各チームには、単一の標準化されたアプリケーション リリースではなく、独自のリリース ツールがあります。 2 番目に、チームはより迅速に意思決定を行うことができ、従来のモデルにおけるフレーバーやアーキテクチャなどの集中化された機能に対する障害が軽減されます。

マイクロサービスアーキテクチャは「無料」ではない。新たな障害モードを導入する。

マイクロサービスを導入すると、組織、プロセス、アーキテクチャに広範囲にわたる影響が及びます。マイクロサービス アーキテクチャ自体は分散システムです。マイクロサービス アーキテクチャに基づくアプリケーションでは、ビジネス ロジックはネットワークを介して相互に通信する複数のサービスに分散され、分散システムにはより多くの障害モードがあります。

これらの障害モードを考慮すると、小さな障害が大きな障害に発展するのを防ぐためのアーキテクチャとプロセスを導入することが重要です。 「高速」な場合、サービスが更新されたときにエラーが発生したり、負荷がかかったときにサービスがクラッシュしたりするなど、障害は避けられません。

アプリケーションが複雑になるにつれて、障害管理の必要性がさらに高まります。アプリケーションが少数のマイクロサービスで構成されている場合、障害の分離とトラブルシューティングは比較的簡単です。しかし、全国に数十または数百のマイクロサービスとチームが分散していると想像してください。私たちの障害管理システムは、アプリケーションに合わせて「拡張」する必要があります。

経営の失敗

当社では通常、プロアクティブなテスト、軽減、迅速な対応という 3 つの障害管理戦略を採用しています。

1. プロアクティブ テスト:プロセスとシステムを使用してアプリケーションまたはサービスをテストし、障害をできるだけ早く検出します。このアプローチには QA が含まれることが多く、従来はテスト チームはリリース前のテストに重点を置いていましたが、現在では実稼働テストにまで拡張されることが多くなっています。
2. 緩和:特定の障害が発生した場合の影響と損失を軽減するための特定の戦略を実装します。たとえば、サービスの複数のインスタンス間で負荷分散を保証するために、1 つのインスタンスに障害が発生しても、サービス全体が引き続き応答できます。
3. 迅速な対応:プロセスとシステムを通じて特定の障害を迅速に特定し、対処する

サービスメッシュ

サービスに障害が発生すると、上流および下流のサービスに影響が及びます。サービス間の通信を適切に管理することで、サービスの障害による影響を大幅に軽減できます。ここでサービス メッシュが登場します。

サービス メッシュは、サービス レベル (レイヤー 7 プロキシなど) の通信を管理し、3 つの障害管理戦略すべてで使用できる強力なプリミティブを提供します。

カナリアルーティング、トラフィックシャドウイング、ブルーグリーンデプロイメントなど、さまざまなリリースおよびテスト戦略のための動的ルーティング

回復力、回路遮断やレート制限などの戦略を通じて障害の影響を軽減する

可観測性、メトリクスを収集し、サービス間通信にコンテキスト（例：トレースデータ）を追加することで応答時間を改善します。

Service Mesh は、アプリケーション開発者にとって非常に透過的な方法でこれらの機能を追加します。

Service Mesh はアプリケーションの構築を高速化するのに役立ちますか?

サービス メッシュが企業にとって有益かどうかを判断するには、まず次の 2 つの重要な質問を考慮する必要があります。

• サービス トポロジはどの程度複雑ですか?
• サービス メッシュをソフトウェア開発ライフサイクルに統合するにはどうすればよいでしょうか?

サービストポロジ

単一のマイクロサービスだけの場合、サービス メッシュの利点は限られます。増分リリースは、Kubernetes や API Gateway などの既存のインフラストラクチャを使用して実行することもできます。

しかし、サービス トポロジがますます複雑になるにつれて、サービス メッシュが大きな役割を果たすようになります。考慮すべき重要な制約は、サービス呼び出しチェーンの深さです。モノリスが数十個のマイクロサービスを直接呼び出す浅いトポロジの場合、サービス メッシュの利点は依然として限られています。サービス間通信をさらに導入すると、サービス A がサービス B を呼び出し、サービス C を呼び出すようになり、サービス メッシュが非常に重要になります。

サービスメッシュをSDLCに統合する

Service Mesh はサービスと同じ名前です。これは、マイクロサービスへのコード変更を必要としない、豊富な 7 層ネットワークです。

ただし、サービス メッシュをデプロイしても、アプリケーションの速度と俊敏性が自動的に向上するわけではありません。開発プロセスにサービス メッシュを統合する必要があります。

SDLCの一環として障害管理戦略を実装する

サービス メッシュは、障害管理のための強力なプリミティブを提供します。次に、さまざまな障害管理戦略と、それが SDLC にどのように適用されるかについて説明します。

アクティブテスト

マイクロサービス アプリケーションのテスト戦略は、実際の状況にできるだけ近づける必要があります。マルチサービス アプリケーションの複雑さを考慮して、現在のテスト戦略では、運用環境でのテスト (または運用データの使用) が重視されます。

サービス メッシュは、サービスへの L7 トラフィックを制御することによって本番環境でテストされます。たとえば、サービス メッシュはトラフィックの 1% をサービスのバージョン v1.1 にルーティングし、トラフィックの 99% を v1.0 (カナリア デプロイメント) にルーティングできます。これらの機能は、linkerd dtab や Istio ルーティング ルールなどの宣言型ルーティング ルールを通じて公開されます。

サービス メッシュはアクティブ テストへの唯一のアプローチではありません。その他の補完的な戦略としては、ローリングアップデート用の Kubernetes などのコンテナ スケジューラ、カナリア デプロイメントを実行できる API ゲートウェイ、カオス エンジニアリングの使用などがあります。

これらすべての戦略が実施されると、テストワークフローを誰が管理するかという疑問が明らかになります。サービス メッシュでは、メッシュを管理する同じチームがルーティング ルールを集中管理できます。

容易に

サービスは、コード エラー、リソース不足、ハードウェア障害など、さまざまな理由で失敗する可能性があります。障害が発生したサービスの爆発半径を制限することは、たとえ機能が低下した状態であっても、アプリケーション全体が機能し続けるために重要です。

サービス メッシュは、負荷分散、サーキット ブレーカー、サービス間通信のレート制限などの回復力パターンを通じて障害の影響を軽減します。たとえば、高負荷のサービスではレート制限が適用される場合があり、これにより、負荷によってサービス全体がダウンすることなく、一部の応答を処理できるようになります。

障害を軽減するための他の戦略としては、Hystrix などのスマート RPC ライブラリの使用や、コンテナ スケジューラの利用などがあります。 Kubernetes などのコンテナ スケジューラは、ヘルス チェックに応答しないサービスに対して、ヘルス チェック、自動スケーリング、動的ルーティングをサポートします。

これらの軽減戦略は、特定のサービスに対して適切に構成されている場合に最も効果的です。たとえば、サービスによって処理できるリクエストの数は異なり、必要なレート制限も異なります。レート制限などのポリシーはどのように設定しますか? Netflix は、これらの値を設定するためにいくつかの自動構成アルゴリズムを実装しています。他のアプローチとしては、サービスを正しく構成できるサービス作成者にこれらの機能を公開することが挙げられます。

可観測性

失敗は避けられません。監視、アラート/視覚化、分散トレース、ログ記録にわたる可観測性を実装することは、特定の障害に対する応答時間を最小限に抑えるために重要です。

Service Mesh は、スループット、レイテンシ、可用性に関するデータを含む、サービス間通信に関する詳細なメトリックを自動的に収集します。さらに、サービス メッシュは分散トレースをサポートするために必要なヘッダーを挿入できます。これらのヘッダーは、サービス自体によって伝播される必要があることに注意してください。

同様のメトリックを収集する他の方法としては、監視エージェントの使用、statsd によるメトリックの収集、ライブラリ (Jaeger インストルメンテーション ライブラリなど) によるトレースの実装などがあります。

可観測性の重要な要素は、アラートと視覚化をサービス作成者に公開することです。メトリックの収集は最初のステップに過ぎません。サービス作成者が特定のサービスに適したアラートと視覚化をどのように作成できるかを考慮することは、可観測性ループを閉じるために重要です。