2016年頃、マイクロサービスやクラウドコンピューティング、DevOpsといった分野に、どこからともなく"サービスメッシュ"という用語が現れました。しかしながら、コンピュータに関する多くの概念がそうであるように、実際にはそれに関連するパターンやテクノロジの長い歴史があるのです。
サービスメッシュが登場した背景には、当時のITが経験した最悪の事態がありました。その頃、複数言語(polyglot)アプローチを用いた分散システムの開発が始まったことで、動的なサービス検索が求められるようになっていました。運用面ではエフェメラル(ephemeral)アーキテクチャが使用されるようになったことで、必然的に発生する通信障害の円滑な処理や、ネットワークポリシの適用が求められるようになりました。プラットフォームチームはKubernetesなどのコンテナオーケストレーションシステムを支持し、システム内外におけるトラフィックの動的なルーティングや、EnvoyのようなAPI中心の現代的なネットワークプロキシを求めるようになりました。
この記事では、ソフトウェアアーキテクトや技術リーダが当然持つであろう、"サービスメッシュとは何か？"、"サービスメッシュは必要なのか？"、"数多いサービスメッシュをどのように評価すればよいのか？"、といった疑問に答えたいと思います。
ページの最後にある目次メニューを使えば、このガイド内を素早くナビゲートすることができます。
サービスメッシュパターン
サービスメッシュパターンは、分散ソフトウェアシステム内のすべてのサービス間通信を管理することに主眼を置いています。
背景
このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。
意図
サービスメッシュが解決しようとする問題は次のようなものです。
- サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除
- 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外部化
- 他のサービスに対するパッシブおよびアクティブな監視機能の提供
- 分散システム全体を対象としたポリシ実施の非集中化
- 可観測性のデフォルト提供と関連データ収集の標準化
- 要求ロギングの実現
- 分散トレースの設定
- メトリクス収集
構造
サービスメッシュは、これまで"east-west"と呼ばれていたRPC(Remote Procedure Call)ベースのトラフィック、すなわち、データセンタ内で内部的に発行され、サービス間を渡り歩くリクエスト/レスポンス形式の通信をおもな処理対象としています。これは"north-south"トラフィック、すなわち外部で発行され、データセンタ内のエンドポイントやサービスに進入(ingress)する通信を処理対象として設計された、APIゲートウェイやエッジプロキシとは対照的です。
サービスメッシュの機能
サービスメッシュの実装は通常、以下の機能中のひとつ、あるいは複数を提供します。
- ネーミングの正規化と論理的ルーティングの追加(コードレベルの名称"user-service"からプラットフォーム固有のロケーション"AWS-us-east-1a/prod/users/v4"へのマッピングなど)
- トラフィックシェーピング(traffic shaping)とトラフィックシフティング(traffic shifting)の提供
- 一般的にはコンフィギュレーション可能なアルゴリズムを備えた、ロードバランシングのメンテナンス
- サービスのリリースをコントロールする機能の提供(カナリアリリース、トラフィック分割など)
- リクエスト毎のルーティングの提供(トラフィックシャドーイング、フォールトインジェクション、デバッグ再ルーティングなど)
- ヘルスチェック、タイムアウト/デッドライン、サーキットブレーキング、リトライ(バジェット)など、ベースラインでの信頼性向上
- 透過的な相互TLS(Transport Level Security)、ACL(Access Control Lists)などのポリシによるセキュリティの向上
- トップラインメトリクス(要求量、成功率、レイテンシなど)、分散トレーシングのサポート、リアルタイムなサービス間通信に"タップ"して調査する機能など、付加的な可観測性と監視機能の提供
- プラットフォームチームが"妥当なデフォルト"を設定して、不適切な通信からシステムを防御する機能
サービスメッシュのアーキテクチャ — 内部構造を見る
サービスメッシュはデータプレーンとコントロールプレーンという、2つの高レベルなコンポーネントで構成されます。Envoy Proxyの作者であるMatt Klein氏が"service mesh data plane versus control plane"という、このトピックを深く掘り下げた記事を書いています。
広く言われているように、データプレーンは"仕事をする(does the work)"もので、"[ネットワークエンドポイントを]出入りするすべてのネットワークパケットの条件付き変換、転送、監視"を役割としています。最近のシステムでは、データプレーンは(Envoy、HAProxy、MOSNなどのように)プロキシとして実装されるのが一般的で、サイドカーとして各サービスとともにプロセス外部で動作します。
Klein氏の言を借りれば、サービスメッシュにおけるデータプレーンは、"システムの全パケット/リクエストに関与し、サービスディスカバリ、ヘルスチェック、ルーティング、ロードバランシング、認証および承認、可観測性に関わる処理を行います"。CNCFでは現在、Klein氏の以前の記事"The Universal Data Plane API"のコンセプトに基づいたUniversal Data Plane APIの策定作業が進められています。このプロポーザルの趣旨はxDS APIの拡張にあります。xDS APIはEnvoyが定義と実装を行ったもので、MOSNなど他のプロキシもサポートしています。
コントロールプレーンは"仕事を監督する(supervises the work)"主体として、データプレーンの個々のインスタンスすべて — 独立したステートレスなサイドカープロキシ群 — を分散システムとして構成する役割を担います。パケットやリクエストへのアクセスは行いませんが、人間である運用者が、メッシュ内で動作するすべてのデータプレーンにポリシやコンフィギュレーションを与えることを可能にします。その他にも、データプレーンのテレメトリの収集と集中化、オペレータによる参照、といったことを可能にする役割も持っています。Red Hatが開発中のKialiは、このユースケースを対象とするものです。
次の図はIstioのアーキテクチャ資料から引用したものです。記載されているテクノロジはIstio特有のものですが、コンポーネントはすべてのサービスメッシュ実装に共通する一般的なものです。
Istioのアーキテクチャ、コントロールプレーンとデータプレーンのインタラクション方法を示す(厚意によりIstio資料から転載)
ユースケース
サービスメッシュが可能にする、あるいはサポートするユースケースにはさまざまなものがあります。
動的サービスディスカバリとルーティング
サービスメッシュは動的サービスディスカバリや、テスト目的のトラフィックシャドーイング(複製)、カナリアリリースやA/Bテストのためのトラフィック分割などのトラフィック管理を提供します。
サービスメッシュ内で使用されるプロキシは、一般的に"アプリケーション層"を認識(OSIネットワークスタックのレイヤ7で動作)しているため、トラフィックルーティングの決定やメトリクスへのラベリングを、HTTPヘッダなどのアプリケーション層プロトコルのメタデータに基づいて行うことが可能です。
サービス間通信の信頼性
サービスメッシュは、要求リトライやタイムアウト、レート制限、サーキットブレーキングといった、多面的な信頼性要件の実装や実践をサポートしています。"eight fallacies of distributed computing"に挙げられている誤りの補償(あるいはカプセル化)に使用されることも少なくありません。注意すべきなのは、サービスメッシュが提供するのは(HTTPリクエストのリトライのような)通信レベルの信頼性のみであるということです。HTTP POST要求の重複(非冪等性)の回避など、ビジネスへの影響に関する責任は、最終的にサービスが持たなくてはなりません。
トラフィックの可観測性
サービスメッシュはシステム内で処理される全リクエストのクリティカルパス上にあるので、リクエストの分散トレーシングやHTTPエラーコードの頻度、グローバルおよびサービス間のレイテンシといった"可観測性"を提供することも可能です。エンタープライズ業界では聞き慣れたフレーズではありますが、システム全体のトラフィックフローを"一括管理(Single Pane of Glass)"するビューを実装する上で、必要なすべてのデータをキャプチャする手段として、サービスメッシュが提案されることが少なくありません。
通信のセキュリティ
サービスメッシュはさらに、(x509認証による)サービスIDの提供、アプリケーションレベルのサービス/ネットワークのセグメンテーション("サービスA"は"サービスB"とは通信可能だが"サービスC"とは不可能、というように)、全通信の暗号化(TLSによる)、ユーザレベルの識別トークンや"passport"など、システム全般にわたるセキュリティ要件の実装と施行もサポートします。
アンチパターン
使用方法にアンチパターンが登場するというのは、そのテクノロジが成熟した証でもあります。サービスメッシュも例外ではありません。
トラフィック管理層が多過ぎる(全体的な速度低下)
このアンチパターンは、開発者がプラットフォームチームや運用チームとのコーディネーションを怠ったことにより、サービスメッシュによって実装されている通信処理ロジックが重複して存在する場合に発生します。例えば、サービスメッシュの設定によって通信レベルのリトライ機能が提供されているにも関わらず、アプリケーション内のコードでリトライ処理を実装すると、このような状況になります。このアンチパターンは、トランザクションの重複などの問題を発生させる可能性があります。
サービスメッシュという銀の弾丸(Silver Bullet)
ITに"銀の弾丸"というものは存在しませんが、ベンダは時として、新技術をこのようなラベルで売り込もうとすることがあります。サービスメッシュがマイクロサービスやKubernetesのようなコンテナオーケストレーション、あるいはクラウドネットワークの通信に関わるすべての問題を解決することはありません。サービスメッシュはサービス間(east-west)通信のみを容易にするためのものです。また、そのデプロイや実行にも運用コストは当然存在します。
Enterprise Service Bus (ESB) 2.0
マイクロサービス以前のサービス指向アーキテクチャ(SOA)の時代には、ソフトウェアコンポーネント間の通信システムとしてEnterprise Service Bus(EBS)が実装されていました。ESB時代からの失敗の多くが、サービスメッシュを使用することで繰り返されるのではないか、と危惧する声が一部から聞かれます。
ESBの提供する集中型の通信コントロールには明らかなメリットがあったのですが、ベンダ主導のテクノロジ開発によって、さまざまな問題が発生しました。例えば、EBS間の相互運用性の欠如、業界標準の勝手な拡張(WS-*準拠のスキーマに対するベンダ独自のコンフィギュレーション追加など)、コストの高さなどです。さらにESBベンダは、ビジネスロジックの通信バスへの統合や密結合を回避する努力を何もしていませんでした。
ビッグバン・デプロイメント
ITには一般論として、ビッグバンアプローチによるデプロイメントが最も管理の楽なアプローチであるという誘惑がありますが、AccelerateやState of DevOps Reportによる調査では、この考え方は否定されています。サービスメッシュの完全なロールアウトが、このテクノロジがエンドユーザの全リクエストを処理するクリティカル上にあるという意味であることから、ビッグバン・デプロイメントは極めてリスキーです。
サービスメッシュの実装と製品
以下ば、すべてではありませんが、現在流通しているサービスメッシュ実装の一覧です。
サービスメッシュの比較 — どのサービスメッシュにするか？
サービスメッシュの世界は目まぐるしく変わっているので、比較記事はあっという間に時代遅れになってしまいます。そのような中でも、いくつかの比較情報は存在します。ただし、ソースの偏り(存在すれば)や、比較を行ったデータには十分に注意してください。
- https://layer5.io/landscape
- https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/ (2019年5月訂正)
- https://platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/ (2019年10月更新)
- https://servicemesh.es/ (2020年2月最新版)
InfoQでは、サービスメッシュの導入に関しては常に、各プロダクトを導入者自身の手で試すことを推奨しています。
サービスメッシュのチュートリアル
複数のサービスメッシュを使った試験を検討中のエンジニアやアーキテクトには、次のようなチュートリアルやプレイグラウンド、ツールなどが用意されています。
- Layer 5 Meshery ― マルチサービスメッシュ管理プレーン
- Solo's SuperGloo ― サービスメッシュオーケストレーション・プラットフォーム
- KataCoda Istio tutorial
- Consul service mesh tutorial
- Linkerd tutorial
History of the Service Mesh
InfoQでは、現在サービスメッシュと呼ばれているトピックを、AirbnbがSmartStackをリリースした2013年後半から追い続けています。SmartStackは、当時現れ始めていた"マイクロサービス"形式のアーキテクチャに対して、アウトオブプロセスのサービスディスカバリメカニズム(HAProxyを使用)を提供するソフトウェアです。かつて"ユニコーン(unicorn)"と呼ばれていた企業の多くが、当時、すでに同じようなテクノロジを開発していました。2000年初頭にGoogleが開発を始めたStubby RPCフレームワークは、その後gRPCへと発展しています。また、同じ頃に開発されたGoogle Frontend (GFE)やGlobal Software Load Balancer (GSLB)は、その痕跡を現在のIstioに留めています。2010年の初めには、TwitterがScalaを使用しFinagleの開発に着手しましたが、そこからは後にLinkerdサービスメッシュが生まれました。
2014年暮れ、NetflixがリリースしたJavaを基盤としたユーティリティスイートには、任意の言語で記述されたアプリケーションからライブラリのスタンドアロンインスタンスへ、HTTP経由での通信を可能にする"サイドカー"プロセスのPranaが含まれていました。2016年になると、NGINXチームが"The Fabric Model"の提唱を始めました。これはサービスメッシュとよく似ていますが、実装には同社の有償製品であるNGINX Plusを使用する必要のあるものでした。
その他、サービスメッシュの歴史の中で注目すべきものとしては、2017年5月のIstio、2018年のLinkerd 2.0、2018年11月のConsul ConnectとSuperGloo、2019年5月のサービスメッシュインターフェース(SMI)、2019年9月のMaeshとKumaなどのリリースが挙げられるでしょう。
ユニコーン以外に登場したサービスメッシュ、例えばHashiCorpのConsulなどは、前述のテクノロジからヒントを得る一方で、CoreOSの造語であるGIFEE、すなわち"Google Infrastructure for Everuone Else"のコンセプトの実装を目的とするものでした。
現在のサービスメッシュのコンセプトが進化した過程を深く追求したPhil Calçado氏は、その結果を包括的な記事"Pattern: Service Mesh"に記しています。
サービスメッシュの(考えうる)未来を探る
サービスメッシュのテクノロジはいまだアーリーアダプションの段階にあるため、その将来に対してはさまざまな見解が存在します。広く言われているように、特に注目されている4つの領域があります。すなわち、RPC以外のユースケースのサポート追加、インターフェースとオペレーションの標準化、プラットフォームファブリック(platform fabric)へのさらなる進出、より効率的なヒューマンコントロールプレーンの構築です。
Kasun Indrasiri氏は記事"The Potential for Using a Service Mesh for Event-Driven Messaging"の中で、サービスメッシュ内にメッセージングサポートを実装するための新たなアーキテクチャパターンとして、プロトコルプロキシ・サイドカーとHTTPブリッジサイドカーという、２つの主要なパターンを取り上げて議論しています。これはサービスメッシュコミュニティでも活発な開発の続く領域のひとつで、Envoy内でのApahe Kafkaのサポートに向けた開発が、非常に多くの注目を集めています。
Christian Posta氏は以前、"Towards a Unified, Standard API for Consolidating Service Meshes"という記事で、サービスメッシュ使用の標準化の試みについて書いていました。この記事は、MicrosoftとKubeCon EUのパートナが先日発表したService Mesh Interface(SMI)についても論じています。SMIは、共通かつ可搬性のあるAPIを定義することで、IstioやLinkerd、Consul Connectなど、さまざまなサービスメッシュテクノロジ間の相互運用性を開発者に提供することを目的としています。
プラットフォームファブリックへのサービスメッシュの統合という話題は、さらに２つのサブトピックに分けることができます。
まず最初に、サービスメッシュデータプレーンによって導入されるネットワークオーバーヘッドを削減しようという動きがあります。この中には、"Linuxカーネルのネットワークスタックという重いレイヤをバイパス"するユーザ空間アプリケーションであるData Plane Development Kit (DPDK)、 Linuxカーネルの拡張Berkley Packet Filter (eBPF)機能を使用することで"極めて効率的なネットワーク、ポリシ拡張、ロードバランシング機能"を実現する、Ciliumチームによる開発などが含まれています。その他にも、"ネットワーク機能の仮想化(NFV, Network Function Virtualization)をクラウドネイティブな方法で新たにイメージする"試みとして、サービスメッシュのコンセプトをNetwork Service MeshとしてL2/L3ペイロードにマップしようとしているチームもあります。
第2に、AWS App MeshやGCP Traffic Director、Azure Service Fabric Meshが導入されたように、サービスメッシュをパブリッククラウドプラットフォームにより強く結合しようとする、複数のイニシアティブがあります。
Buoyantチームは、サービスメッシュテクノロジ用のより効率的な人間中心のコントロールプレーンの開発において、中心的な役割を果たしています。同チームは先頃、プラットフォームチームがKubernetesを運用するためのSaaSベースの"チームコントロールプレーン"として、Diveをリリースしました。Diveは高レベルかつ人間重視の機能をLinkerdサービスメッシュ上に加えることで、サービスカタログ、アプリケーションリリースの監査ログ、グローバルなサービストポロジなどを提供します。
FAQ
サービスメッシュとは何ですか？
サービスメッシュは、(一般的にはマイクロサービスベースの)分散ソフトウェアシステム内における、すべてのサービス間"east-west"トラフィックを管理するテクノロジです。ルーティングのようなビジネス指向の機能運用に加えて、セキュリティポリシの適用やQOS(Quality of Service)、レート制限のような非機能サポートも提供します。一般的には(すべてではありませんが)サイドカープロキシを使用して実装され、すべてのサービスがそれを通じて通信するようになります。
APIゲートウェイとは何が違うのですか？
サービスメッシュは、分散(一般的にはマイクロサービスベースの)ソフトウェアシステム内における、すべてのサービス間、つまり"east-west"トラフィックを管理します。ルーティングのようなビジネス指向の機能運用に加えて、セキュリティポリシの適用やQOS(Quality of Service)、レート制限のような非機能サポートも提供します。
それに対して、APIゲートウェイはクラスタへの入力、つまり"north-south"トラフィックをすべて管理することで、クロスファンクショナルな通信要件の付加的サポートを提供するためのものです。システムへの単一エントリポイントとして動作し、複数のAPIやサービスが結束して動作することで、ユーザに統一的なエクスペリエンスを提供する。
マイクロサービスをデプロイするには、サービスメッシュは必要なのでしょうか？
必須ではありません。サービスメッシュはテクノロジスタックの運用を複雑にすることから、サービス間通信のスケールアップの問題を抱えていたり、解決の必要な特別なユースケースのある企業のみでデプロイされるのが一般的です。
マイクロサービスにサービスディスカバリを実装するには、サービスメッシュが必要でしょうか？
いいえ、サービスメッシュは、サービスディスカバリを実装するひとつの方法に過ぎません。他にも、言語固有のライブラリ(RibbonやEureka、Finagleなど)によるソリューションなどがあります。
サービスメッシュはサービス間通信にオーバーヘッドやレイテンシを発生させますか？
はい、サービスメッシュは、サービスが他のサービスと通信する場合に、少なくとも２つのネットワークホップ(ひとつはソースのアウトバウンド接続を処理するプロキシによるもの、もうひとつはデスティネーションからのインバウンド接続を処理するプロキシによるもの)を加えます。ただし、この付加的なネットワークホップが発生するのは、一般的にはローカルホストやループバックネットワークインターフェースを経由する場合なので、追加されるレイテンシは小さなもの(ミリ秒単位)に過ぎません。対象とするユースケースでこれが問題となるかを検証し理解することは、システム分析とサービスメッシュ評価の一部として行われるべきです。
サービスメッシュは、アプリケーションがデプロイされるKubernetesや"クラウドネイティブプラットフォーム"の一部とするべきではないのでしょうか？
そうかも知れません。クラウドネイティブプラットフォームのコンポーネント間で関心の分離(separation of concerns、Kubernetesがコンテナオーケストレーションを担当し、サービスメッシュがサービス間通信を処理する、というようい)を維持すべきかどうかは、意見が分かれています。ただし、サービスメッシュ的な機能を最新のプラットフォーム・アズ・ア・サービス(PaaS)に追加する動きはあります。
サービスメッシュをどのように実装、デプロイ、あるいはロールアウトすればよいのでしょう？
さまざまなサービスメッシュ製品(上記)を分析して、選択したメッシュの実装ガイドラインに従うのが、最もよいアプローチでしょう。一般論としては、すべての利害関係者と協力して、新しいテクノロジを段階的に運用に取り入れていくのがベストです。
独自のサービスメッシュを開発することは可能でしょうか？
可能ですが、問題はそうするべきかどうか、ということです。サービスメッシュの開発が、あなたの企業のコアコンピテンシなのでしょうか？顧客への価値提供という面で、もっと効率的な方法があるのではないでしょうか？独自開発したメッシュのメンテナンス、セキュリティ上の問題へのパッチ、新たなテクノロジを取り入れるための定期的なアップデートなどを確約できますか？現在はオープンソースや有償製品としてさまざまなサービスメッシュが利用できるのですから、既存のソリューションを利用する方がおそらく効率的でしょう。
ソフトウェアデリバリ企業内のどのチームがサービスメッシュを所有するのでしょうか？
一般的には、Kubernetesや継続的デリバリパイプラインのインフラストラクチャと同じく、プラットフォームあるいは運用チームが所有します。ただし、サービスメッシュのプロパティを設定するのは開発者なので、両チームは密接に協力する必要があります。企業の多くは、NetflixやSpotify、Googleといった先駆者に倣って社内向けのプラットフォームチームを編成し、フルサイクルプロダクト指向の開発チームに対するツーリングやサービスの提供を行っています。
Envoyはサービスメッシュですか？
いいえ、EnvoyはLyftチームがオリジナルの設計と開発を行った、クラウドネイティブなプロキシです。Envoyはサービスメッシュのデータプレーンとしてよく利用されているのですが、これをサービスメッシュと見なすには、全体としてサービスメッシュを構成するように、コントロールプレーンと組み合わせて使用する必要があります。コントロールプレーンには集中管理型の設定ファイルリポジトリのような単純なものや、メトリックコレクタ、あるいはIstioのように包括的で複雑なものが考えられます。
"Istio"と"サービスメッシュ"は同義語ですか？
いいえ、Istioはサービスメッシュのひとつです。サービスメッシュのカテゴリが登場した時にIstioが有名になったため、Istioとサービスメッシュを混同しているソースがいくつかあります。このような混乱はサービスメッシュに限ったことではありません — Dockerとコンテナテクノロジでも同じような問題が起きています。
どのサービスメッシュを使えばよいのでしょうか？
この質問に対して、ひとつの答はありません。エンジニアは実装チームに対する現在の要件、スキル、リソース、許容される時間を理解する必要があります。上記のサービスメッシュ比較へのリンクは最初の足がかりになると思いますが、少なくとも２つのメッシュを比較して、どのプロダクト、テクノロジ、ワークフローが自分たちに適しているを試験することを強く推奨します。
サービスメッシュはKubernetes以外でも使用できるのでしょうか？
はい。大部分のサービスメッシュは、さまざまなインフラストラクチャ上にインストールして、データプレーンプロキシや関連するコントロールプレーンを管理することができます。HashiCorpのConsulはこの最も有名な例ですし、IstioをCloud Foundryで試験的に使用した例もあります。
その他のリソース
- InfoQサービスメッシュホームページ
- The InfoQ eMag — Service Mesh: Past, Present, and Future
- The Service Mesh: What Every Software Engineer Needs to Know about the World's Most Over-Hyped Technology
- Service Mesh Comparison
- Service Meshes
用語解説
APIゲートウェイ: クラスタに到着するすべての入力データ(north-south)管理、およびその他の機能を提供するもの。システムへの単一エントリポイントとして動作し、複数のAPIやサービスが結束して動作することで、ユーザに統一的なエクスペリエンスを提供する。
Consul: HashiCorpの提供するGoベースのサービスメッシュ。
コントロールプレーン: 独立したデータプレーンのインスタンス(プロキシ)群を、運用担当者による視認およびコントロールが可能な分散システムに構成するもの。
データプレーン: サービスネットワークエンドポイントを通過するすべてのネットワークパケットの条件付き変換、転送、監視を行うプロキシ。
East-Westトラフィック: データセンタ、ネットワーク、あるいはKubernetesクラスタ内のネットワークトラフィック。従来のネットワーク図では、サービス間(データセンタ内)のトラフィックフローが左から右(東から西)に描かれていたことから発した用語。
Envoy Proxy: クラウドネイティブアプリケーション用に設計された、オープンソースのエッジおよびサービスプロキシ。サービスメッシュ実装内のデータプレーンとして広く使用されている。
Ingressトラフィック: データセンタやネットワーク、Kubernetesクラスタ外で発生したネットワークトラフィック。
Istio: C++(データプレーン)およびGo(コントロールプレーン)で記述されたサービスメッシュで、オリジナルはGoogle、IBMがLyftのEnvoyチームとのパートナシップの下で開発した。
Kubernetes: Googleが開発し、現在はCNCFの管理下にある、コンテナオーケストレーションおよびスケジューリングフレームワーク。
Kuma: Kongの開発したGoベースのサービスメッシュ。
Linkerd: Twitter初期のJVMベースの通信フレームワークから発展した、Rust(データプレーン)とGo(コントロールプレーン)で開発されたサービスメッシュ。
Maesh: Traefik APIゲートウェイのメンテナであるContainousによる、Goベースのサービスメッシュ。
MOSN: (Envoy)xDS APIを実装したAnt FinancialチームによるGoベースのプロキシ。
North-Southトラフィック: データセンタ、ネットワーク、あるいはKubernetesクラスタに入力(あるいは進入)するネットワークトラフィック。従来のネットワーク図では、データセンタに入力するトラフィックをページの最上部から下(北から南)への流れとして描いていたことから発した用語。
プロキシ: エンドコンポーネント間の仲介役として動作するソフトウェアシステム。
セグメンテーション: ネットワークやクラスタを複数のサブネットワークネットワークに分割すること。
サービスメッシュ: 分散(一般的にはマイクロサービスベースの)ソフトウェアシステム内のサービス間(east-west)トラフィックを管理する。ルーティングなどの機能処理と、セキュリティポリシの実施やQOS(Quality of Service)、レート制限などの非機能サポートの両方を提供する。
サービスメッシュインターフェース(SMI): Kubernetes上にデプロイされるサービスメッシュを対象として策定作業中の標準インターフェース。
サービスメッシュポリシ: サービス/エンドポイント群が相互に、あるいは他のエンドポイントに対して通信を行う方法についての仕様。
サイドカー: 付加的なプロセスやサービス、あるいはコンテナを既存サービスと並列に(オートバイのサイドカーのように)デプロイするデプロイメントパターン。
"Single Pane of Glass": 複数のソースから取得したデータを統合されたディスプレイに表示するUIあるいは管理コンソール。
トラフィックシェーピング: レート制限やロードシェディング(load shedding)などのように、ネットワーク全体のトラフィックのフローを変更すること。
トラフィックシフティング: トラフィックをあるロケーションから別のロケーションに移行すること。
ソフトウェアアーキテクトの役割は、時代とともに変化し続けています。InfoQの"Software Architect's Newsletter"で、最新の情報を獲得しましょう。
著者について
Daniel Bryant氏は、組織変革とテクノロジをリードする人物です。現在の専門技術は、"DevOps"ツーリング、クラウド/コンテナプラットフォーム、マイクロサービス実装などを中心としています。Daniel氏はLondon Java Community(LJC)のリーダとして、オープンソースプロジェクトへのコントリビューション、InfoQやDZone、Voxxedなど著名な技術Webサイトでの記事の執筆を行う他、QConやJavaOne、Devoxxなどの国際的なカンファレンスでも定期的に講演しています。