Docker、Kubernetesに続く今後の注目コンテナテクノロジー「Istioとサービスメッシュ」とは？ | 東京エレクトロンデバイス

「Docker」に代表されるコンテナ型仮想化技術が普及するにつれて、コンテナに関連する新たなテクノロジーが次々に登場してきました。なかでもオーケストレーションツールとして事実上の標準となり、AWSやMicrosoft Azureなどが相次いでマネージドサービスを提供し始めた「Kubernetes」は、いまクラウドでもっともホットなソフトウェアかもしれません。

そして早くも、Kubernetesの次に注目される新しいテクノロジーが登場してきました。それが「Istio」と呼ばれるソフトウェアであり、それによって実現される「サービスメッシュ」という機能です。
Istioやサービスメッシュとは何でしょうか？
それを説明するうえで、まずはコンテナ型仮想化とKubernetesが何を実現してきたのか、改めて振り返ってみましょう。というのも、Istioとサービスメッシュはその延長線上に、必然のテクノロジーとして生まれたからです。

注目され始めたマイクロサービスアーキテクチャ

クラウドは仮想サーバーの提供を主要なサービスとしています。クラウドのユーザーはまず仮想サーバーを立ち上げ、その上にアプリケーションをデプロイして実行していました。もちろん現在でも、これは主要なクラウドの使い方だと言えます。 そこに登場してきたのが「Docker」に代表されるコンテナ型仮想化技術です。

仮想サーバーは、生成されてOSが起動し利用できるようになるまで分単位の待ち時間が発生します。一方、コンテナ型仮想化ではコンテナが切り出されて利用可能になるまで、待ち時間は秒単位ですぐに使え、しかも効率が良いため、サーバーに対して高密度に多数のコンテナを詰め込むことができます。
コンテナ型仮想化の特長などについては2016年2月の記事「注目を浴びるDockerコンテナ、従来の仮想化と何が違うのか？」で紹介していますので、ご覧ください。

こうして軽量かつ高密度といったコンテナの特長を基盤とする形で注目され始めたアプリケーションのアーキテクチャが「マイクロサービス」（Microservices）です。

マイクロサービスアーキテクチャの利点とは？

「マイクロサービスアーキテクチャ」を大まかに説明すると、大規模なアプリケーションを開発するときにすべての機能を密接に連携させた巨大な一枚岩のようなアプリケーションをつくるのではなく、アプリケーションを機能ごとに「サービス」と呼ばれる小さな部品に分割し、サービスを連携させながら全体を構築していく設計を基本とするものです。
マイクロサービスアーキテクチャの利点はいくつかありますが、主に次の3つが挙げられます。

1つはスケーラビリティの高さです。機能がサービスに分かれて分散処理が容易な仕組みになっているため、負荷に合わせてサービスのインスタンス数を増やしたり減らしたり、高いスケーラビリティを実現できます。

またサービスごとに機能が分かれているため、機能の追加や変更に際して全体を作り直す必要がなく、変更されたサービスを差し替えるだけで済むという柔軟性が2つ目の特長です。

3つ目はどこかに障害が発生しても、その影響をサービスの一部のインスタンスに止めて、システム全体としては稼働を続けるといった、障害に強い点が挙げられます。

マイクロサービスアーキテクチャはコンテナ型仮想化により、サーバーを論理的に小さな粒度で多数に切り分けてアプリケーションを実行できるようになったことで、その実現が後押しされています。
もちろんコンテナ型仮想化やマイクロアーキテクチャには欠点や課題もあり、すべてのアプリケーションにとって優れたものというわけではありません。例えばコンテナ型仮想化は分離レベルが低いことが大きな欠点ですし、マイクロアーキテクチャはサービス間のAPI定義が面倒であったり、全体をテストすることが難しかったりといった課題があります。

しかしそうした課題や欠点を考慮しても、コンテナ型仮想化を基盤とするマイクロサービスアーキテクチャはクラウド時代のアプリケーションの代表的なアーキテクチャである、という考えが一般的になりつつあるのです。

Kubernetesによってコンテナのクラスタ基盤を提供

KubernetesやIstioは、このマイクロサービスアーキテクチャに基づくアプリケーションを実現するための機能を提供します。

アプリケーションに対して多彩な機能を提供する「Kubernetes」。それはコンテナオーケストレーションと呼ばれる

Kubernetesは複数のサービスをパッケージし、コンテナのクラスタ上に適切にデプロイする機能を提供します。複数のサービスをどのようにデプロイするかは「Helmチャート」と呼ばれる定義ファイルに記述します。これによって多数のサービスのデプロイがスムーズに行えるようになるわけです。
また万が一、アプリケーションを構成するコンテナクラスタ群のいずれかのコンテナが異常終了した場合には、自動的に新しいコンテナを再起動する死活管理も備えています。

アプリケーションに負荷がかかった場合、自動的もしくはマニュアル操作によってクラスタを構成するコンテナ数を増やして、負荷に対応できるようにするスケーリング機能も備えています。
どのようなサービスが展開されているかを発見するためのサービスディスカバリ機能、サービスに対して機能追加や更新などが行われた場合、新版のサービスをデプロイして旧版と切り替え、あるいは切り戻しを行うサービスのロールアウトとロールバック機能なども備えています。

こうしたアプリケーションのデプロイ、死活管理、スケーリング、サービスディスカバリやロールアウトなどの機能をKubernetesは提供しており、そしてKubernetesが提供するこのような機能のことを「コンテナオーケストレーション」と呼ぶわけです。

関連記事として2018年1月の記事「コンテナオーケストレーションツールの“事実上の標準”という座をつかんだKubernetes。その重要性とは？」を参照ください。

サービスレベルで機能を提供するIstio

そして、コンテナ型仮想化とKubernetesを基盤に登場してきたのがIstioです。
端的に言えば、Kubernetesがコンテナの集合体であるクラスタにマイクロサービスアーキテクチャの基盤機能を提供するのに対して、Istioはコンテナのうえで稼働する個々のサービスレベルでマイクロサービスアーキテクチャを実現するための機能を提供します。

そのためIstioはコンテナ上の個々のサービスに付き添い、プロキシと呼ばれる通信を仲介する機能を通じて、さまざまな機能を提供します。

「Istio」はコンテナのうえで稼働する個々のサービスレベルに対して、マイクロサービスアーキテクチャ実現のための機能を提供

Istioの主な機能の1つは、サービス間の通信の制御です。ブルー／グリーンデプロイメントと呼ばれる、あるサービスを新版に切り替える際の通信の切り替えなどが可能です。またサービス間の通信を暗号化し、サービス間での認証をきちんと行うことでセキュリティを高めることも実現してくれます。さらにサービスのモニタリングやログ収集を行うことで、サービスとアプリケーションの稼働状況を把握できるようにするのです。
こうしたIstioが提供する機能、つまりサービス間をつなぐうえで重要な機能群が、いわゆる「サービスメッシュ」と呼ばれています。

ようやく“バージョン1.0”に到達したIstio

Istioは2018年8月にようやく「バージョン1.0」に到達したばかりです。マイクロサービスアーキテクチャにしても、先進的な一部のWebサービス企業が採用し始めたところであり、これから本格的な普及期に入るでしょう。
もちろん、前述のようにコンテナやマイクロサービスアーキテクチャには利点ばかりではなく欠点もありますので、すべてのアプリケーションがマイクロサービスアーキテクチャになるわけではなく、引き続き従来の手法とアーキテクチャによって開発・運用したほうがよいものもたくさんあります。

しかしクラウドという基盤がこれから広く普及することは確実であり、マイクロサービスアーキテクチャはそのクラウド基盤に適したアーキテクチャであるとされていることから、その基盤を構成するコンテナであるKubernetesやIstioは、これからもさらに存在感を増して広く使われていくことになるはずです。