Service Meshを使用しない方が良い理由（後半）

長い記事なので、２つに分けて投稿いたします。今回は後半です。

あなたの会社の人は、Service Meshに関する理論的な知識と実践的な経験がありますか？

これは私が何度も経験したことですが、Kubernetesに慣れていない人は、Service Meshにどのような機能があるか、ないのかが分からず、混乱したりや間違った期待をしてしまったり、作業に遅れが出たりして、プロジェクトに悪影響を及ぼします。これは通常、停電などの問題が起きたときに悪化します。理解できないものをデバッグすることはできません。

ここでは、私にとっては直感的に理解できることでも、人に説明しなければならないと感じた簡単な例を紹介します（これは、私のPTSD脳が、あらゆることの詳細を理解しなければならないと思わせているのでしょう）。Service Mesh環境では、Podがお互いに通信するとき、ロードバランサーは動作していません。それならなぜクラスタ内でClusterIPタイプのサービスを作って、2つのマイクロサービスを互いに会話させなければならないのか、それは一種のロードバランサーではないか、と思うかもしれません。IstioのようなツールはKubernetes Serviceを使ってService Discoveryを行いますが、各ポッドには小さなプロキシが一緒に走っているので（sidecarと呼ばれる）、Mesh内の各ポッドは他のポッドのIPをすべて認識しています。アプリケーションは作成したサービスを使用して、リーチさせたいサーバーを見つけますが、アプリケーションコンテナから出るトラフィックはプロキシサイドカーによって傍受され、ポリシーが適用されて、ポッドのIPを使用して受信側に直接トラフィックが送られ、ロードバランシングは行われません。

最後の段落で何も理解できなかったのなら、それこそ私がここで述べている問題なのです。この記事かこの本を読んでみてください。あるいは単に「MESH NAMEの仕組み」でググってみてください。

ですから、結論から言うと、「Service Mesh」の担当者は、その中身をしっかり理解する必要があるということです。

技術的負債の増加

Service Meshを本番環境で使用することは、スタートアップガイドにあるような単純なハローワールドの例よりもはるかに複雑です。本番稼動する前に配置しなければならないものがたくさんあるのですが、そのいくつかを挙げてみましょう。

• 自動化：Service Meshをどのようにデプロイし、使用するのか。私が携わったほとんどのプロジェクトでは、最終的に何らかのCI/CDでメッシュをデプロイし、マニフェスト（YAMLファイル）をデプロイしています…。
• モニタリングとトレース：ほとんどのMeshツールは、サイドカーから直接多くのメトリクスを提供しますが、それらのほとんどは、これらのメトリクスを取得、保存、可視化するためのサポートインフラストラクチャがあると思っています。これはおそらく、ある種のSaaSツール（datadogなど）またはOSSツールのセルフホスティングセット（Prometheus、Grafana、Alert Managerなど）でしょう。