Istioの雰囲気

Istioとは何か

Istioはマイクロサービスがもたらした課題の1つである「複雑なサービス間通信」を解決しようとするものです。
マイクロサービス化により、多くの恩恵を受けることができました。しかし、マイクロサービスを開発・運用していると「デバッグするのが難しい」、「どこで遅延が起こっているかが分かりにくい」などの問題を感じたことがあると思います。そういった問題をアプリケーションと隔離されたレイヤで解決するのが、サービスメッシュです。サービスメッシュはアプリケーション開発者をビジネスロジックを書くことに集中させ、それ以外のマイクロサービス固有の問題から開放する救世主かもしれません。2019年の時点でおそらく最も注目を集めているサービスメッシュがIstioです。他にはLinkerd やAWS App Meshなどがあります。

  • KubernetesのPod内にSidecarとしてEnvoyをデプロイし、コードの変更なく、サービスメッシュの機能を追加できる
  • IstioのマニフェストはKubernetesのマニフェストのフォーマットをそのまま使用できる
  • Kubernetesに依存している訳ではなく、Nomadにも対応している

なぜIstioか

コードを修正することなく、マイクロサービスがもたらした多くの問題を解決できるからです。Istioは以下の課題を解決します。

  • Fault Isolation
  • Observability
  • サービス間の認証・認可

Istioのアーキテクチャ

下の図は公式のページにあるアーキテクチャの概要です。

Pilot

サービスディスカバリーやトラフィックコントロールの構成情報を管理しています。Envoyと連携し、サービス間の通信を制御します。

Mixer

Envoyと連携してリクエスト前のポリシー確認を行います。また、リクエスト送信後にアクセス制御やログ、トレース、メトリクスの収集を行い、PrometheusやInfluxDB、Stackdriverなどのテレメトリーサービスに連携します。

Citadel

CAとして相互TLSで使われる鍵の管理や証明書の発行を行います。

Galley

基盤となるプラットフォーム(Kubernetesなど)から取得したユーザーの詳細設定を検証し、他のIstioコンポーネントから隔離します。

Enovy

PodにSidecarとしてデプロイされたネットワークプロキシです。※2
サービスの情報、ルーティングなどをPilotから取得し、リクエストを適切なサービスのインスタンスに転送します。また、リクエストを受ける側のEnvoyはリクエストが許可されたものかをMixerに問い合わせます。処理が終われば、リクエストした側のEnvoyもリクエスト受けた側のEnvoyもMixerにテレメトリーを報告します。

現状の問題点

  • 学習コストが高い
  • 導入事例が少ない

サービスメッシュこそ未来

Istioに限った話ではありませんが、サービスメッシュには勢いがあります。例えば、以下のようなマネージドなサービスメッシュが台頭しています。

最後に

モノリシックなサービスを分割し、Kubernetes上のコンテナ環境へ移行させるだけでは、課題がいくつも残りました。そして、それらの課題の大部分はプロダクトを成長させていく上で、目を背けることができないものです。サービスメッシュにはそれらの課題を解決できるポテンシャルがあります。私はサービスメッシュやっていくぞ、という気持ちです。

参考

--

--

Software engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store