マイクロサービス(microservices)は、大きなアプリケーションを小さな部品に分割して、それらがAPI経由で互いに通信し合う、という開発方式だが、今ではとくに、コンテナをベースとするマイクロサービスが、多くのデベロッパーのあいだで最大人気のアプリケーション・アーキテクチャになっている。しかし、小さなサービスの大軍を管理することには、それなりの課題が伴う。デベロッパーとDevOpsたちが彼らのマイクロサービスベースのアプリケーションを管理しその安全を確保できるために、Google, IBM, およびLyftが今日、デプロイしたサービスのネットワークを作れるオープンなプラットホームIstioを発表した。そしてそれには、ロードバランシングやサービス間認証、モニタリングなどのツールが含まれている。
このプラットホームの利用にあたって、既存のアプリケーションの変更は必要ない。その理由として、Istioはネットワークのレベルにいて、ユーザーのマイクロサービス間のネットワーク通信をプロキシを使って捕捉するからだ。使用するプロキシはLyftが開発したEnvoyで、そのほかにサービス発見やロードバランシングのためのツールも含む。
Istioのチームはこう説明する: “一枚岩的なアプリケーションがマイクロサービスの集合に分解されると、分散システムの上で複数のサービスを統合していくことが、新たな課題になる。そしてそのためには、サービス発見、ロードバランシング、フォールトトレランス、エンドツーエンドのモニタリング、機能の実験のための動的ルーティング、そしてとりわけ重要なコンプライアンスとセキュリティを備えなければならない。これらを揃えるにあたって不整合が生じたり、つぎはぎだらけのライブラリやStackOverflowで拾ったコード片を使ったりしていると、複数の言語やランタイムにわたって互換性を欠く、ばらばらなソリューションができあがり、観察性/観測性が劣化し、その結果セキュリティが壊れることも少なくない”。
単一のライブラリに標準化してサービス間の通信を管理することは、理論的には可能だが、実際にはなかなかありえないことだ、とチームは主張する。そこで既存のサービスがそのまま残り、柔軟性を欠くことになる。
Istioはデベロッパーに単一のサービスメッシュを提供し、その中に、ロードバランシングやフローコントロールやセキュリティポリシーの実装に必要なモニタリングサービスがあって、ネットワークの信頼性が落ちてもアプリケーションが動き続けられるようにする。また、複数のアプリケーション間の通信に必要な認証とセキュリティを、TLS接続により提供する。そうするとデベロッパー自身は、証明の管理などの雑務を免除される。
IstioにはGoogleも参加しているから、今のところはコンテナオーケストレーションサービスとしてKubernetesしかサポートしていないが、いずれは他の環境もサポートしていく計画だ。むしろIstioの基本的な考え方は、特定の環境に縛られないことだから、今後はMesosなどもサポート対象になるだろう。またGoogle自身も、同社のユーザーAPI提供/管理プラットホームCloud EndpointsやApigeeをIstio対応にする措置を講じている。Googleは昨年Apigeeを、6億2500万ドルで買収した。
ただし、今やKubernetesプロジェクトの‘公共的住処（すみか）’となったCloud Native Computing Foundationにも、Istioに類似したプラットホームlinkerdがある。linkerdはすでに、DockerとMesosphereのDC/OS（データセンターオペレーティングシステム）のサポートを提供している。
