"プロダクションユースに対応"したIstio v1.0サービスメッシュがリリース

先週サンフランシスコで開催されたGoogle Cloud Next 2018イベントで、Istio 1.0サービスのリリーススケジュールが発表された。今週、そのv1.0が正式にリリースされた。このオープンプラットフォームは、“サービスコードを変更せずに、ロードバランシング、サービス間認証、監視などを備えた、デプロイ済サービスのネットワークの構築”の容易化を目標とする。クロスクラスタメッシュのサポート、きめ細かなトラフィックフロー制御、相互TLS(Mutual TLS)のメッシュ全体へのインクリメンタルなロールアウトなどが主な新機能だ。

Istioは、Envoyプロキシデータプレーンのコントロールプレーンとして事実上機能する、オープンソースのプラットフォームである。Googleが実質的にプロジェクトをリードするが、Lyft (Envoyプロキシの開発元)、IBM、Pivotal、Cisco、Red Hat、VMwareなど、多くの企業が積極的にコントリビュートしている。

Istioのコントロールプレーンアーキテクチャは、ポリシの管理と運用を行なうMixer、トラフィック管理のPilot、識別と認証を管理するCltadelから構成されている。Envoyデータプレーンはサイドカーパターンを使用して、メッシュ内のサービスに並列して配置される。サービス間の通信をEnvoyサイドカーがインターセプトして、コントロールプレーンで指定されたポリシの適用とテレメトリ収集が行われる仕組みだ。

1.0リリースを伝えるIstioブログの発表記事によると、先回の0.8リリースからいくつかの新機能が追加されると同時に、“プロダクションユースのレベルに達したという意味で、既存の機能の多くがベータ版としてマークされている” (ただし、“ベータ”がそのような意味なのかについては、Twitter上で異論もある)。IstioをKubernetesクラスタにインストールする方法としては、ドキュメントにいくつかの選択肢が紹介されているが、公式にはHelmチャートの使用が推奨されている。DockerとHashiCorpのConsulを使用するシステム用のインストールガイドも提供されている(テストされていないが、HashiCorp Nomadへのインストールも可能だ)。

複数のKubernetesクラスタを単一メッシュに追加できるようになり、“クラスタ間の通信と一貫したポリシの適用”が可能になった。この機能はベータ版で、インストール手順書には“運用環境では手順の追加や、より複雑なデプロイメントオプションが必要な場合もある”、と警告されている。また、コントロールプレーンクラスタ内のサービスポッドの再起動によって、リモートクラスタとの通信が切断する問題(Istio issue #4822)があることも公開されている。

メッシュ全体のトラフィックを詳細に制御可能なNetworking APIも、同じくベータ版としてリリースされた。Gatewayを使用して入力および出力の責務を明示的にモデル化することで、オペレータが“ネットワークトポロジをコントロールし、エッジにおけるアクセスセキュリティ要件を充足すること”ができる、と資料では説明されている。

相互TLS(Mutual TLS/mTLS)は、Istio管理下の全サービスをビッグバン方式で更新する必要のない、段階的なロールアウトが可能になった。また、Istio認証ポリシで“PEMISSIVE”モードを提供することによって、Envoyサイドカーを持たないサービスがmTLS経由の通信をサポートする問題を克服している。このモードを有効にすると、サービスはHTTPトラフィックと相互TLSトラフィックの両方を使用できるようになる。マイグレーションが完了した後は、Permissiveモードを削除して、メッシュ内のすべての通信にTLSを適用することが必要だ。

Istio Mixerでは アウトプロセスアダプタ(out-of-priocess adapter)がサポートされて、ロギングや監視、クォータ、ACLチェックといったMixerの機能を提供する“gPRCアダプタ”、あるいは“gPRCインターフェースを公開するバックエンド”の開発が可能になった。リリースノートによると、このアウトプロセスアダプタ機能は現在開発中だが、今後のリリースではMixerの標準的な拡張手段となる予定で、アダプタの構築が大きく簡略化される。

サービスへのアクセスをコントロールする認証ポリシが、Envoyの内部でローカルに評価されるようになり、パフォーマンスと信頼性が向上した。ただし、ドキュメントには詳しく記されていないが、中央のMixerと各サービスのEnvoyプロキシ間でデータの一貫性を保つために、何らかのトレードオフがあるものと思われる。“Mixer and the SPOF Myth”と題された資料には、この件に関する追加情報が提供されている。

さらにリリースノートには、Istioコミュニティ全体が、継続的な回帰テストや大規模な環境シミュレーション、目標を限定したバグ修正など、パフォーマンスと信頼性のために多大な努力を払っている、と述べられている。これらテストの結果は、“数週間以内にその詳細が”公開される予定だ。

“Announcing Istio 1.0”と題された公式発表のブログ記事には、Istioの採用を検討中の企業として、eBay、Auto Trader UK、Descartes Labs、HP FitStation、JUSPAY、Namely、PubNub、Truliaといった名前が挙げられている。Googleの発表記事では、“少なくとも12社(GCPを含む)がIstioを運用中”であるとした上で、Auto Trader UKのデリバリインフラストラクチャ部門のリーダであるKarl Stoney氏の談話として、同社がコンテナおよびパブリッククラウドへの移行を速やかに達成するために、Istioの果たした役割が紹介されている。

Auto Trader UKでは、プライベートクラウドからパブリッククラウドへのマイグレーションに合わせて、仮想マシンからKubernetesへの移行も実施しています。Istioが提供する高度なコントロールと可視性によって、この野心的な作業のリスクを大幅に軽減することが可能になりました。

先週のGoogle Cloud Nextでは、Managed Istioのアルファ版リリースも発表されている。これは、Kubernetes Engineクラスタ上にCloud Service Platformの一部として自動的にインストールおよびアップグレードされる、オープンソース版Istioのインスタンスになる予定である。Pivotalもまた、同社のCloud FoundryプラットフォームでIstioをサポートしている。 mTLSサポートはすでに利用可能で、Ingress、サービス・ツー・サービスの追加サポート、アプリケーションセキュリティポリシも近日中に提供される予定である。Pivotal Istionのブログ記事ではまた、“抽象化が重要”であり、“テクノロジは目に付かなければベスト”であると論じるとともに、ビジネス価値の提供をサポートするソフトウェアやプラットフォームの構築に際して、開発者が避けるべき誤りについて警告している。

開発者としては、IstioとKubernetesを併用したいという誘惑に駆られるかも知れませんが、これは運用の負担を増大させ、コストを上昇させる可能性があります。ビジネスの中心がプラットフォームの構築や販売でない限り、それは時間とお金の無駄です。最高に優秀なエンジニアならば、オープンソースのコンポーネントを繋ぎ合わせるだけでない、独自のビジネスバリューの提供を模索すべきです。

Istioにコントリビュートする企業は他にもある。Datadog、SolarWinds、Sysdig、Google Stackdriver、Amazon CloudWatchなどの可観測性(Observability)プロバイダは、自社製品をIstioに統合するためのプラグインを提供している。Tigera、Cilium、Styraの3社は、ポリシ拡張とネットワーク機能を提供するエクステンションを構築した。Red Hatでも、Kialiと呼ばれる、サービスメッシュの管理と可観測性を実現するWebベースのUIドライバを開発している。Cloud Foundryは、次世代のトラフィックルーティングスタックをIstio上に開発している。先日発表されたKnativeサーバレスプロジェクトも同じ目的の開発を行なっており、ApigeeではAPI管理ソリューションでの採用を予定している。

Istio v1.0に関する詳細な情報は、プロジェクトのWebサイトのリリースノートで確認できる。