はじめに

この記事は、次の二つの関心から始まっています。

マイクロサービスの様々な新しいコンセプト、パターンへの興味
その一つの実装であるIstioを用いて、NoSQLデータベースCouchbaseを使う準備

この様な関心から発した勉強の結果を整理したく、とはいえ付け焼き刃であることは否めない状態で、いたずらに中途半端な長さのものを書くのであれば、学習に使ったソース（後述）自体をを見ていただいた方がよいはずで、ここでは、どれだけ簡潔に（As Briefly As Possible）要約できるか、という観点で整理を試みてみたいと思います。

サービスメッシュ As Briefly As Possible

サービスメッシュとは

Data PlaneとControl Planeとからなるアーキテクチャー

Data Plane、Control Planeとは

Date Plane

データトラフィックを担う

Control Plane

(データ)トラフィックに関係する各種のコントロールを提供する

サービスメッシュ（Data Plane + Control Plane）の概念図

図は、サービスメッシュ（Control Plane）の代表的テクノロジーであるIstio公式ドキュメント What is Istioから引用

注釈

まず、エンジニアにとっては、サービスメッシュについての説明を読むよりも、アーキテクチャの構成要素の各役割を理解するのが、近道と考えました。

さらに、Data Planeという用語を聞いた時のはじめの印象は、情報技術の世界で「データ」とだけ言われても、ほとんど何も意味しない、というものでした（個人的には、「データ層」との連想で、データを保存するイメージを持った）。「コントロール」もまた然り。
それで、いくつかの解説記事を読んでいくと、つまりは、データ「トラフィック」という言葉を使えば（簡潔で）実体に則した表現になる、という着想に至りました。その後、上記のIstioの図を見て、我が意を得たり、と感じたという経緯です。

最後に、今回の要約は、そもそも、サービスメッシュとは何？、という疑問にたどり着いた人には、マイクロサービスやコンテナ技術（の目的や背景）について説明する必要はない、という地点から発しています（そういった関心をそもそも持っていない人には、意味をなさない要約に違いありません）。

事例から学ぶ

さて、概観を掴むことができたら、次は実際の利用について知ることが、理解を深める近道と考えます。
下記の記事では、そうした観点からいくつかの事例が紹介されています（いきなり「〜続き」からの紹介になってしまいますが、最後の参考情報についても参照ください）。

service meshにおけるcontrol plane と data planeの話の続き

ただ、Istio(Control Plane)については、「本番導入事例というのを、まだ見つけ」られておらず、いずれの事例も「Istioの導入を見送って、自分たちでcontrol planeを実装」したということの様です。

ではどうするか？

サービスから学ぶ

主要な、サービスプロバイダーの利用状況を確認してみます。

Istio on OpenShift in 2020

Getting Started with Istio on Amazon EKS

（上記、公式ブログで紹介されている様に）各社からサービスが提供されています。

企業の事例に採用されていないことだけを見ると未成熟な技術だからという印象も受けるところですが、必ずしもそうではないといえそうです（一社で使うのであれば、カスタマイズされたものを用いる方が取り回しのよい技術領域なのかもしれない、とも考えました。結論づけるには、より深い理解が必要ですが）。

自分自身の第二の関心に戻って考えると、こうしたメジャーなプロバイダーで対応されていることが、CouchbaseがIstioへの対応を行った前提ということになるでしょう。

Couchbase Autonomous OperatoのIstio対応

Istio with Couchbase Autonomous Operator

上の公式ドキュメントの記述は、非常に簡素ですが、そこで紹介されているCouchbaseCluster resource reference documentationから、具体的な関連を確かめてみます。

紹介されている設定例は、以下の様なものです。

spec:
  networking:
    exposeAdminConsole: true
    adminConsoleServiceTemplate:
      metadata:
        labels:
          key: value
      spec:
        type: LoadBalancer
    adminConsoleServices: # DEPRECATED
    - data
    adminConsoleServiceType: LoadBalancer # DEPRECATED
    exposedFeatureServiceTemplate:
      metadata:
        labels:
          key: value
      spec:
        type: LoadBalancer
    exposedFeatureServiceType: LoadBalancer # DEPRECATED
    exposedFeatureTrafficPolicy: Local # DEPRECATED
    serviceAnnotations: # DEPRECATED
      my-annotation: my-value
    loadBalancerSourceRanges: # DEPRECATED
    - "10.0.0.0/8"
    networkPlatform: Istio
    dns:
      domain: couchbase-0.us-east-1.example.com
    tls:
      static:
        serverSecret: couchbase-server-tls
        operatorSecret: couchbase-operator-tls
      clientCertificatePolicy: mandatory
      clientCertificatePaths:
      - path: san.email
        prefix: ""
        delimiter: "@"
      nodeToNodeEncryption: All

Istioが設定されている設定項目spec.networking.networkPlatformの説明は以下の様なものです。

This field defines the underlying network platform in use. Typically, this field does not need to be defined.

When Istio, this enables DNS host aliases in Couchbase server pods. Without this support, Couchbase server may connect to local services over the pod IP address, not localhost, and will be dropped by Istio when running in mTLS mode.

Field rules: The networkPlatform field is optional and must be Istio.

最後の行にある様に、この設定項目自体が、Istioありき、のものになっています。

最後に

今回はここまで。
Couchbase Autonomous Operatorの扱いについては、非常に中途半端なものになってしまいましたが、いずれ稿を改めて整理することができればと思います。

参考文献

今回、同じ著者による、以下の記事から多くを学びました（感謝）。

Envoy (Envoy proxy)、Istio とは？

"Service mesh data plane vs. control plane" by Matt Klein の日本語訳

service meshにおけるcontrol plane と data planeの話の続き