Kubernetes

サービスメッシュとは?

この記事はNGINX,Inc.のブログ記事「What Is a Service Mesh?」を和訳した内容となります。

URL: https://www.nginx.com/blog/what-is-a-service-mesh/

サービスメッシュは 、マイクロサービスアプリケーションの構成ができるインフラストラクチャ層です。これにより、サービスインスタンス間の通信が柔軟で信頼性が高く、高速になります。このメッシュは、サービスのディスカバリ、ロードバランシング、暗号化、認証と認可、サーキットブレーカーパターンのサポート、およびその他の機能を提供します。

サービスメッシュは、通常、各サービスインスタンスに対して、サイドカーと呼ばれるプロキシインスタンスを提供して実装されます。サイドカーは、サービス間の通信、監視、セキュリティ関連の懸念(個々のサービスから抽象化できるもの)を処理します。このようにして、開発者はサービス内のアプリケーションコードの開発、サポート、メンテナンスを処理し、運用担当者はサービスメッシュを維持して、アプリケーションを実行できます。

Google、IBM、Lyftの支援を受けているIstioは、現在、最もよく知られているサービスメッシュアーキテクチャです。もともとGoogleによってデザインされたKubernetesは、現在Istioにサポートされている唯一のコンテナオーケストレーションフレームワークです。

サービスメッシュには、コンポーネントサービスと機能に関する独自の用語があります。

  • コンテナ オーケストレーション フレームワーク アプリケーションインフラに次々とコンテナが追加されるにつれ、一連のコンテナを監視および管理するための別のツールである、コンテナ オーケストレーション フレームワークが不可欠になります。Kubernetesは、この市場を独占したようです。主要な競合相手であるDocker SwarmやMesosphere DC / OSでさえ、Kubernetesとの統合を代案として提示しています。
  • サービスとサービスインスタンス  具体的に言うと、開発者が作成するのはサービスではなく、サービスインスタンスのサービス定義またはテンプレートです。アプリケーションはこれらからサービスインスタンスを作成し、インスタンスは実際の作業を行います。ただし、サービスという用語は、多くの場合、インスタンス定義とインスタンス自体の両方に使用されます。
  • サイドカープロキシ  サイドカープロキシは、特定のサービスインスタンス専用のプロキシインスタンスです。他のサイドカープロキシと通信し、オーケストレーションフレームワークによって管理されます。
  • サービス・ディスカバリ インスタンスが別のサービスとやりとりする必要がある場合、他のサービスの健全で利用可能なインスタンスを見つける必要があります。コンテナ管理フレームワークは、リクエストを受信する準備ができているインスタンスのリストを保持します。
  • ロードバランシング サービスメッシュでは、ロードバランシングは一番下から機能します。サービスメッシュが管理している利用可能なインスタンスは、順に並べてリスト化され、最も負荷の軽いインスタンス(ここが負荷分散部分になります)が一番上に配置されます。
  • 暗号化 サービスメッシュは、リクエストとレスポンスを暗号化および復号化し、各サービスからその負担を取り除くことができます。サービスメッシュは、既存のパーシステントコネクションの再利用に優先順位を付け、コンピューティングリソース的に高価となる新規の接続を作る必要性を低減することで、パフォーマンスを向上させることができます。
  • 認証と承認 サービスメッシュは、アプリケーションの外部と内部の両方から行われたリクエストを認証し、検証されたリクエストのみをサービスインスタンスに送信することができます。
  • サーキットブレーカーパターンのサポート サービスメッシュは、不健全なインスタンスを分離し、それらが保証された段階で、健全なインスタンスプールに徐々に戻していくサーキットブレーカーパターンをサポートします。

サービスインスタンス、サイドカープロキシ、それらの間の相互作用など、サービスメッシュで作業を実行している部分は、サービスメッシュアプ​​リケーションのデータプレーンと呼ばれます。(名前には含まれませんが、データプレーンも処理を実行します)。でも、サービスメッシュアプ​​リケーションには、コントロールプレーンと呼ばれる監視および管理レイヤーも含まれています。

コントロールプレーンは、新しいインスタンスの作成、不健全または不必要なインスタンスの終了、監視、監視と管理の統合、アプリケーション全体のポリシーの実装、およびアプリケーション全体の正常なシャットダウンなどのタスクを処理します。コントロールプレーンは、通常、アプリケーションプログラミングインタフェース、コマンドラインインタフェース、およびアプリケーションを管理するためのグラフィカルユーザインタフェースを含むか、またはそれらに接続するように設計されています。

nginMesh、コントロールプレーン、データプレーン、サイドカープロキシとしてのNGINXを含むIstioサービスメッシュ

 

NGINXには、nginMeshと呼ばれるIstio互換のサービスメッシュがあります。このnginMeshアーキテクチャの図は、典型的なIstioコンポーネントとともに、サイドカープロキシの役割を果たすNGINXを示しています。

サービスメッシュアーキテクチャの一般的な使用例は、コンテナとマイクロサービスを使用して非常に要求の厳しいアプリケーション開発の問題を解決する場合です。マイクロサービスの先駆者には、Lyft、Netflix、Twitterなどの企業があります。これらの企業は、1時間単位で出入りする世界中の何百万人ものユーザーに、堅牢なサービスを提供しています。(Netflixが直面しているいくつかのアーキテクチャ上の課題についての詳細な説明を参照してください)。アプリケーションのニーズがそれほど厳しくない場合、より単純なアーキテクチャで十分でしょう。

サービスメッシュ・アーキテクチャーが、すべてのアプリケーション開発およびデリバリーの問題に対する答えとなることはないでしょう。建築家や開発者は非常に多くのツールを持っていますが、ハンマーはそのうちの1つに過ぎず、彼らが対処しなければならないたくさんの問題の中で、釘もまたそのうちの1つにすぎないからです。たとえば、NGINX Microservices Reference Architectureには、マイクロサービスで問題を解決するために、連続的なアプローチを提供するいくつかの異なるモデルが含まれています。

サービスメッシュアーキテクチャ(NGINX、コンテナ、Kubernetes、構造的なアプローチとしてのマイクロサービスなど)に付随する要素は、非サービスメッシュ実装で生産的に使用できます。たとえば、サービスメッシュアーキテクチャとして開発されたIstioはモジュール式に設計されているため、開発者は必要なものを選択して使えます。サービスメッシュアプ​​リケーションをいつ、完全に実装するかどうかわからなくても、これを念頭に置いて、サービスメッシュの概念を確実に理解する価値はあります。

このブログの投稿は、シリーズの最初のものになります。現在、予定されている投稿は次のとおりです:

  1. サービスメッシュとは?ー  本投稿です。
  2. サービスメッシュアーキテクチャの利点と欠点 いつサービスメッシュが正解か、代替案がより良いかもしれないかを説明します。
  3. サービスメッシュとAPIゲートウェイ  APIゲートウェイが問題の大部分を解決しうる時、サービスメッシュに直ちに移行するべき時、およびそれらをミックスしたアプローチを使用する時を示します。
  4. KubernetesとService Meshアーキテクチャ サービスメッシュを含むさまざまなアーキテクチャでKubernetesを使用する方法について説明します。
  5. サービスメッシュアーキテクチャにおけるNGINXの使用 NGINXは、サービスメッシュ・アーキテクチャ(サイドカー・プロキシIngressコントローラ、またはその両方)の中で、ロードバランシング、サービス・ディスカバリ、キャッシングなどの機能を提供しながら、いくつかの重要な役割を果たします

***************************************************************************

本ブログサイトの”ホワイトペーパー一覧”ページにeBOOKを公開致しました。
https://nginx.sios.jp/white-paper

***************************************************************************

ホワイトペーパー「最新のアプリケーションデリバリーがもたらすビジネス価値」

今日のデジタル世界でビジネスの成功を握る鍵は、かつての「規模」から「スピード」に移行しました。


アプリケーションがリリースされるまでの期間はどんどん短くなっています。10年前であれば「6ヶ月」でも許されたものが、現在そして将来においては、「数週間から数日」になっていくでしょう。


このようなスピードを実現するには、これまでのモノリシックなデスクトップアプリケーションやクライアントサーバーアプリケーションから、軽量で疎結合型のRESTfulなサービスや、APIベースのサービスに移行する必要があります。


そして、アプリケーションデリバリー・インフラストラクチャは、変更が簡単で自動管理されるソフトウェアベースのプラットフォームでなければならないのです。


このホワイトペーパーでは、


◇ ビジネスでアプリケーションデリバリーが重要な理由

◇ ビジネス効果を高める10の方法

◇ NGINXはアプリケーションデリバリーをどのように変えるのか


事例をまじえて、わかりやすく解説します。


ダウンロード

コメントを残す

*