サービスメッシュ 0から始める！

はじめに

サービスメッシュについて紹介します。
社内でKubernetesの利用が普及しており、「サービスメッシュ」や「マイクロサービス」や「DevOps」などの言葉も社内で飛び交いますが、「サービスメッシュ」を誤った意味で利用されている気がしました。
自分の頭の整理の意味を含めて、これからサービスメッシュを調査される方や、エンジニアではない方もわかりやすい紹介します。

#そもそもサービスメッシュって何？
初めてこの単語を聞いたときは、

• 業界分析をする際に、細分化するフレームワーク？
• 商品の製造工程(素材の仕入れ→加工→販売)を細分化するフレームワーク？

のように考えて調査していましたが、「マイクロサービス」、「コンテナ」、「Docker」、「Kubernetes」などのキーワードが一緒に登場してくると思います。

とある資料にはこのように紹介されています。
クラウドネイティブ構造で、サービス同士が安全に、速く、信頼できる通信をするために、サービスメッシュが必要になると説明されています。
この時点でまだ何のことか分からなくて大丈夫です。

#マイクロサービスについての紹介
サービスメッシュを理解する上で、マイクロサービスの概念の理解が必要です。
マイクロサービスは、アプリケーションを構築する一般的な方法で、少ないリスクでコードを迅速にデプロイし、需要に対してアプリケーションをより効果的にスケールすることができます。

説明のための具体例：ECサイトのようなサービス (※四角はサービスを表す)

マイクロサービスの思想でサービス開発を行うことで、以下の特徴があります。

• スケールアウトしやすい：サービス単位でリソースを増減可能で、耐久性の向上やコストの最適化が見込める (例：黄は演算にメモリを消費しやすいので、多くのリクエストが短時間に集中したら、全て処理できるように台数を増やす)
• 変更しやすい：それぞれが疎結合に通信するため、サービスのバージョン更新や切り戻しが容易 (例：青で商品購入の機能を更新するが、セキュリティ低下は避けなければならないため、致命的なバグがあった場合はただちに古い四角に戻す)
• 大人数で開発しやすい：サービスが小さなまとまりで管理されることで、開発者が共同編集しても同じ部分を編集しないように管理しやすい (例：赤を開発している間に、他の人が緑を開発しても問題がない。)

一方で一般的に以下の課題があると言われています。

• サービスの発見：複数の小さなサービスが相互に連携しているため、依存関係にあるサービスの接続情報の管理が困難。 (例：緑は赤と青と依存関係にあり、赤と黄は依存関係にあり、青はDBと依存関係にあり、、など四角が増えるぼど煩雑になる)
• 障害の分離：あるサービスで発生した障害が連鎖し、大規模な障害に繋がる可能性がある。(例：黄で生じた障害により、緑は赤経由から障害の情報は受け取るものの原因が分からない)
• 分散トレーニング：１つのリクエストが複数のサービスに跨ぐため、リクエスト全体の処理の流れを把握が困難。(例：黄で処理に時間がかかっているか、赤で処理に時間がかかっているかが分からない)
• 認証・認可：アクセス元のサービスの権限に応じて、提供するコンテンツを制御することが困難。(例：無料会員か有料会員かによって、赤のコンテンツの出し分けを行うために、赤側でも認証情報を持たないといけない)

上記課題を解決するのがサービスメッシュと解釈していただきたい！！

##「マイクロサービス」関連語の紹介
Web等で調べていると異なる名前で紹介されることがあります。細かい違いはあるのですが、同じような意味でよく利用されることを認識してもらえれば良いです。

• アジャイル (2001~) : 小さなチームによるタイムボックス管理
• クラウド (2006~) : インフラとミドルウェアのソフトウェア化
• DevOps (2009~) : 開発と運用の協業
• NoOps (2011~) : 運用作業込みでのプラットフォーム化
• Microservices (2013~) : システム全体をサービス単位で変更
• Cloud Native Architecture (2017~) : ものすごくたくさんのノードを管理

サービスメッシュの２側面の特徴

サービスメッシュを技術的に理解するためには、Dockerなどのコンテナの理解や、Kubernetesなどのコンテナオーケストレーションの理解が必要になります。
しかし、とりあえず**「サービスメッシュはこう！」だと理解したい人のために、以下の２側面の特徴だけを覚えてください。
上の関連語に記載のあるように、「Microservices」と「DevOps」**は表裏一体の関係にあります。つまり、マイクロサービス構成の思想でサービスを設計することは、開発側と運用側の両側面を考慮した設計になることだということです。

サービスメッシュで開発に注力

サービスメッシュを実現するフレームワークとして「Istio」があります。Istioのチュートリアルで紹介されている構成を基に説明します。

これは本のレビューを表示するサイトを例にとったもので、Pythonで書かれたフロントエンド（/productpage）から3つのレビューを表示するJavaで書かれたモジュール、その後ろにNode.jsで書かれたRatingのモジュール、さらにRubyで書かれた詳細のモジュールがPodとして構成されています。

このように複数の言語で書かれたマイクロサービスを、各々コマンド1回叩くだけでオレンジのProxyと緑のサービスを一つのまとまりで稼働させることができます。つまり開発者にとって、サービスメッシュは意識する必要がないものです。

サービスメッシュでトラフィック管理

運用側は開発側とは独立して、サービスを運用することができます。
基本的には以下のトラフィック管理をユースケースとして紹介されることが多いです。

• ブルー/グリーン デプロイメント
• カナリアリリース
• コンテンツ・ベースド・ルーティング
• フォールト・インジェクション：遅延
• フォールト・インジェクション：エラー返信
• サーキット・ブレーカー

###ブルー/グリーン デプロイメント

ブルー/グリーンデプロイメントとは、サービスを停止することなく新たなサービスをリリースする手法です。現行本番環境「ブルー」とは別に次期本番環境「グリーン」を用意し、あるタイミングでエンドユーザーのアクセス先をブルーからグリーンに切り替えることで、システムを停止することなく継続的にサービスをリリースできます。

###カナリアリリース

カナリアリリースとは、アクセスの90％を本番系システムへ、10％を開発中の次期システムへと経路を振り分けます。その結果、次期システムの稼働に問題がないようであれば、すべてのアクセスを次期システムへと切り替える手法です。

###コンテンツ・ベースド・ルーティング

リクエストの内容によって、例えばテストユーザーだけを次期システムに振り分けるといった「コンテンツベースドルーティング」と呼ばれる運用もできます。

###フォールト・インジェクション：遅延

フォールトインジェクションは、カオスエンジニアリングとも呼ばれる手法です。意図的なネットワークの遅延やエラーコードを送信することで、システムの耐障害性テストを実施します。

###フォールト・インジェクション：エラー返信

上記遅延と同じです。

###サーキット・ブレーカー

サーキットブレーカーは、一定回数マイクロサービスの呼び出しに失敗した（応答が返ってこない）場合、プロキシサーバーが即座にエラーを返し、システムリソースのブロックやシステム全体のダウンを防ぐ手法です。

まとめ

サービスメッシュは他にも「Envoy」や「SideCar Pattern」、「Ingress」や「Control Plane」などの技術的な理解や、Dockerと Kubernetesがどのようにマイクロサービスの課題を解決しており、一方でどういった問題点を抱えているからサービスメッシュを導入すべきかなど深ぼる必要があります。
今回お伝えしたかったことは、今から「サービスメッシュ」を調査する方に向けて２点。

• 開発側は、各サービスごとに最適な言語やツール等を用いて開発に注力できること
• 運用側は、トラフィック管理を中心に複雑なサービス群の運用を容易にすること

私がサービスメッシュについて調査する際にすごく時間がかかったため、これからサービスメッシュを調査される方が、この記事を読み、理解を助けることを望みます。
また記載に誤りがある場合はご指摘いただけますと非常に助かります。