第15章 サービス・メッシュ サービスメッシュ
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
おそらくコンテナに次いで、サービスメッシュという言葉はクラウドネイティブ開発の代名詞となっている。 しかし、コンテナと同様に、サービスメッシュは様々なオープンソースプロジェクトや商用製品を包含する幅広い用語である。クラウドネイティブアーキテクチャにおけるサービスメッシュの一般的な役割を理解することは有用だ。 この章では、サービスメッシュとは何か、さまざまなソフトウェアプロジェクトがどのように実装しているのか、そして最後に(そして最も重要なことだが)、アプリケーションにサービスメッシュを組み込むことが、それほど複雑でないアーキテクチャと比較して、どのような場合に意味があるのかを紹介する。
注
多くの抽象化されたクラウド・ネイティブ・アーキテクチャ図では、クラウド・ネイティブ・アーキテクチャにはサービスメッシュが必要だと思われている。これは全く正しくない。サービスメッシュの採用を検討する場合、(一般的にサードパーティが提供する)新しいコンポーネントを依存リストに追加する複雑さとのバランスを取る必要がある。多くの場合、アプリケーションのニーズを満たすのであれば、既存のKubernetesリソースに単純に依存する方が簡単で信頼性が高い。
Kubernetesの他のネットワークプリミティブ(ServicesやIngressなど)については以前に説明した。Kubernetesのコアにこれらのネットワーキング機能があることを考えると、なぜネットワーキング層に追加の機能(と複雑さ)を注入する必要があるのだろうか?基本的には、これらのネットワーキング・プリミティブを使用するソフトウェア・アプリケーションのニーズに起因する。
KubernetesのコアのNetworkingは、実際にはアプリケーションをデスティネーションとして認識するだけだ。ServiceリソースもIngressリソースも、特定のPodセットにトラフィックをルーティングするラベルセレクタを持っているが、それ以上にこれらのリソースがもたらす追加機能は比較的少ない。HTTPロードバランサとして、Ingressはこれを少し超えているが、多種多様な既存の実装に適合する共通のAPIを定義するという課題が、Ingress APIの機能を制限している。 真に "クラウドネイティブ "なHTTPルーティングAPIは、ベアメタルネットワーキングデバイスからクラウドネイティブ開発を考えずに作られたパブリッククラウドAPIまで、様々なロードバランサやプロキシと互換性があるのだろうか?
非常に現実的な方法で、Kubernetesのコア以外のサービスメッシュAPIの開発は、この課題の結果である。Ingress APIは、外界からのHTTP(S)トラフィックをクラウドネイティブアプリケーションに取り込む。Kubernetesのクラウドネイティブアプリケーション内では、既存のインフラとの互換性の必要性から解放され、サービスメッシュAPIは追加のクラウドネイティブネットワーキング機能を提供する。 では、これらの機能とは何か?ほとんどのサービスメッシュ実装で提供される一般化された機能は、ネットワークの暗号化と認可、トラフィックシェーピング、可観測性の3つだ。以下のセクションでは、それぞれについて順番に見ていく。