連載:第10回「DXを売る」DX営業 ”サービスメッシュ” を説明できる?

ビジネス

はじめに
「DXを売る」シリーズを担当しているサイオステクノロジーの長谷川です。
前回はOpenShiftの特徴を説明できるか!?としてK8sの商用版であるRed HatのOpenShiftの特徴を説明しました。今回はコンテナやマイクロサービスの話題には欠かせない”サービスメッシュ”について営業レベルの知識を記述したいと思います。恐らく、聞いたことはあるけど説明できない営業さんが多いと思いますので、最後の【まとめ】だけでも覚えておくとよいと思います。

このBlogでは、DXソリューションを担当する営業の方を少しでも支援できるように分かりやすくご紹介します。参考にしてください。
第一回記事:「DXを売る」IT営業が気を付けるべき7つのポイント
第二回記事:「DXを売る」”DXに関心を持たせる” 営業トーク 」
第三回記事:「DXを売る」営業の”知ったかぶりコンテナ・トーク”」
第四回記事:「DXを売る」”IT自動化とDX推進を繋げる5つのポイント”

第五回記事:「DXを売る」営業の素朴な疑問 ”コンテナってどこでも動くの?”

第六回記事:「DXを売る」営業の素朴な疑問 ”サイドカーって何モノ?”

第七回記事:「DXを売る」営業の素朴な疑問 ”コンテナ向けOSって何?”

第八回記事:「DXを売る」DX営業”OpenShiftの特徴を説明できる?”(1/2)

第九回記事:「DXを売る」DX営業”OpenShiftの特徴を説明できる?”(2/2)

【その1】”サービスメッシュ” を一言で

  • 営業レベルなので以下のとおりでよいと思います。
    「マイクロサービスのアプリケーション間をつなぐネットワーク」
  • まずは、この一言が言えれば大丈夫だと思います。
  • 私が事業企画担当としてRed HatのOpenShift関連に関わり始めたころから、”サービスメッシュ”というワードをよく耳にしました。しかし、細かいことは理解していませんでした。そこで、なぜマイクロサービスにサービスメッシュが必要なのか? については次の章で記述しますね。

因みにRed Hatが公開している、OpenShift4.3のサービスメッシュのマニュアルには、以下のように説明されています。参考まで
「サービスメッシュ という用語は、分散したマイクロサービスアーキテクチャーの複数のアプリケーションを構成するマイクロサービスのネットワークおよびマイクロサービス間の対話を説明するために使用されます。サービスメッシュのサイズとおよび複雑性が増大すると、これ把握し、管理することがより困難になる可能性があります」
相変わらず、難しい表現だと思うのは私だけ?(笑)

【その2】なぜマイクロサービスのアプリケーションには ”サービスメッシュ” が必要なの?

以前のBlog(第三回)にマイクロサービスについて記述したので理解していると思います。
要は、”モノリシック(ここではモノリスと略す)”でつくられた一体型アプリケーションの弊害を無くすために”マイクロサービス”という分散型アプリケーション型が必要となったわけですが、
一体型のモノリスアプリケーションは、そもそも完全にそれぞれの機能が密結合なので通信でつなげる必要はありません。しかし、”マイクロサービス”のように分散されて機能や役割毎にモジュール化されているアプリケーションは、それぞれを繋げなければ全体システムとしては動きません。その繋ぎのネットワーク部分がサービスメッシュであると覚えておけばよいと思います。

【その3】サービスメッシュの役割

  • 前章でサービスメッシュは、マイクロサービス(分散型)アプリケーションだからこそ必要なんだと理解できました。
    しかし、サービスメッシュは何をするんだろう? マイクロサービス間を繋げるだけなのか?役割は? という疑問が出てきます。
    少し細かくなりますが、簡単に説明します。
    マイクロサービス(分散型)アプリケーションを適切に動かそうとすれば、当然のように、アプリケーション間通信に信頼性がなくてはなりません。送り先のマイクロサービスアプリケーションがクラッシュしているかもしれませんし、他のマイクロサービスアプリケーションが変な要求を出してくるかもしれませんよね。それぞれのアプリケーションの品質レベルも異なり、作成する開発言語も異なる、開発チームがそれぞれ異なる場合が多いのでそういった不具合は当然のように発生します。そういった問題を個々のアプリケーションに影響させないようにするための工夫が必要になるわけです。
    例えば、どこかのアプリケーションで問題が発生していれば、全体のモニタリングが必要になったり、送った先に問題があれば通信のリトライをしたり、タイムアウトの機能が必要にります。各アプリケーションがバラバラのフォーマットのログを出すのも困ります。そのためには、統一されたフォーマットでのログやメトリックス、トレーシング情報の出力が必要になります。
  • 纏めるとサービスメッシュの役割は2つ
    • サービス間通信の信頼性確保
    • 可視測性の実装
  • となり、その役割の実装(サービスメッシュ)をアプリケーションと分けアプリケーションの変更に影響しないようにしています(サイドカーとして)。
    下の図では緑の月のようなマークとしています。

以上のように、マイクロサービス型のアプリケーションは複雑なのですが、サービスメッシュによって通信や可視測性が適切にできるようにしています。

【その4】サービスメッシュの仕組みや構造

サービスメッシュによるマイクロサービスアプリケーション間の通信は、すべてのマイクロサービスアプリケーションの横にプロキシアプリケーションを置いてそのプロキシを通じておこないます。そのプロキシアプリケーションにサービス間通信の信頼性の機能や可観測性の機能を実装させます。すべてのマイクロサービスアプリケーションはそのプロキシアプリケーションを通じて相互に疎結合で通信をおこなっているわけです。
サービスメッシュとは、その通信の品質確保や可視測性のためのプロキシアプリケーションというわけです。
簡単ではありますが、サービスメッシュは、コントロールプレーンとデータプレーンに分かれています。どちらもコンテナのサイドカーで配置されます。
データプレーンである、プロキシアプリケーションとして現在代表的に利用されているのは、Envoyです。
コントロールプレーンとして代表的に利用されているのは、Istioです。イメージは以下のとおりです。

【まとめ】

  1. サービスメッシュは、マイクロサービスアプリケーション間を繋げて、お互いの問題を影響させないようにしてくれるので通信の品質が上がる
  2. サービスメッシュは、品質や開発言語が異なる多種多様のマイクロサービスアプリケーションに影響しない、統一されたログ出力やトレーシング情報の出力をしてくれるので、問題があっても解決しやすくしてくれる
  3. サービスメッシュには、EnvoyやIstioが有名で、サイドカーとして配置。すでにRed Hat OpenShift4には同梱済なのでOpenShiftを使うと便利。

以上、
今回のBlogの内容はお役に立ちましたでしょうか?
今後のBlog記事に関するご要望や実際のビジネスでのご相談事などございましたらお問合せいただきますようお願いいたします。最後まで読んでいただきありがとうございました。