Istio 1.0が先日リリースされた。多くの重要な機能がアルファからベータ、またはベータから安定版に移行している。AutoTraderやEbay、IBMなどの企業では、すでにさまざまな段階でデプロイされている。
オープンソースであるIstioプロジェクトのリリースチームに参加している、IBMシニアテクニカルメンバのLin Sun氏に、Istio全般の状況と、今回リリースされた1.0について話を聞いた。
氏はマイクロサービスと1.0の機能、サービスメッシュ、サイドカープロキシ、Istioプラットフォームのロードマップ、Kubernetes以外のプラットフォームでの稼働など、Istioに関するさまざまなトピックを扱っている。
InfoQ: Istioはサービスメッシュを中心に構築されていますが、それが本当に何を意味するのか、開発者やアーキテクトに説明をお願いできますか?
Sun: Istioは本質的に、サービスメッシュがマイクロサービスとどのように接続し、どのように保護し、どのようにコントロールすべきかという問題に対する、私たちの見解です。マイクロサービスは新しいクラウドアーキテクチャに対して、アジリティやスピード、フレキシビリティなど、多くのメリットをもたらしましたが、同時に落とし穴もあります。そのひとつが複雑性です。
ユーザがモノリシックなアプリケーションから、コンテナやマイクロサービスを基盤としたアーキテクチャに移行する際には、巨大なアプリを多数のさまざまな動作パーツに分割する作業が行なわれます。これと同じコンセプトが、マイクロサービスを使った新しいクラウドアプリにも当てはまります。唯一の違いは、さまざまなパーツがすべてスクラッチから開発されることです。どちらにしても、このモデルの抱える課題は変わりません。このようにさまざまなパーツを、一度にすべて管理するのは難しく、セキュリティに大きな影響を与えかねません。Istioは、開発者がコントロールを取り戻して、マイクロサービスを所定の方法で相互接続し、障害を処理することを保証する手段となります。これにより、マイクロサービスのネットワーク全体で起きていることを把握し、サービス間コミュニケーションを保護し、ポリシを確実に実施することが容易になります。
IstioはIBMのみを対象とするものではありません。現時点で200以上のコントリビュータを抱える、オープンなサービスメッシュプラットフォームなのです。IstioはIBM、Google、Lyftによって設立され、CiscoやRedhat、Tigeraなど無数のパートナが参加して、活発なコミュニティが成長を続けています。オープンアーキテクチャとエコシステムは、Istioを効果的なものにしている要素のひとつです — 使用するサービスのタイプを制限するようなベンダのロックインはなく、どのようなクラウドモデルでも — パブリック、プライベート、オンプレミス、あるいはそれらを組み合わせても — 運用が可能です。
Istioのもうひとつのメリットは、アプリケーションのコードを変更する必要がほとんど、あるいはまったくないことです。サービスがJavaScript、Go、Java、Pythonなど、何の言語でプログラムされていても問題ありません。一旦実装してしまえば、必要なのは、リクエストヘッダを適切に転送して分散トレーシングを活用するための、最小限のコード変更のみです。ロードバランシングやルーティング、リトライ、mTLSといった共通のタスクは、記述した言語に関わらず、すべてのマイクロサービスに対して一貫した方法でIstioが抽象化し、解決します。
InfoQ: Istio 0.8とistio 1.0との違い、Istio 1.0の実用性について、要点を説明して頂けますか?
Sun: Istio 0.8からIstio 1.0の間では、多数の重要な機能がアルファからベータに、ベータから安定版に昇格しています。これらの機能が相まって、ますます大規模で複雑になるマイクロサービスネットワークをスケールアップし管理する手段であるIstioを、コミュニティの強力なコラボレーションがテストし強化した結果として、最新かつ最も安定したリリースバージョンを実現しているのです。
例えばトラフィック管理では、HTTP1.1/HTTP2/gRPC/TCPプロトコルが安定版になりました。WebSocketとMongoDBは、トラフィック制御、レジエンス、ゲートウェイ、ゲートウェイのTLS終端とSNIサポートなどとともに、ベータ版に移行しています。フィルタは1.0で新たに追加されたので、まだアルファのままです。IBMは、大手企業のクラウド移行作業で学んだ知見を活かして、これら機能の多くにおいて開発の中心となっています。私たちはコミュニティと一致団結して、安全性やセキュリティ、管理機能など、istioを実務で運用するために開発チームが必要とするものを提供しています。お気付きと思いますが、私たちは新機能をまずアルファとして宣言した上で、自分たちのテストやエクスペリエンス、ユーザからのフィードバックで比較的安定した後に、複数回の長期サポート版(LTS)を経て安定版に昇格する方法を採用しています。ベータ版に達した時点で、実際の業務に、ただし慎重に導入することをユーザに推奨しています。
Istioのコア機能の大部分が安定版ないしベータ状態になったので、Istio 1.0は実運用が可能なレベルに達しました。AutoTraderやEbayなど一部のユーザは、すでにこのような方法でIstioを使用しています。IBM社内でも使用していますし、評価段階でIstioを使用しているユーザもたくさんいます。
Istio 1.0の強力な機能には、他にも次のようなものがあります。
- SNIのホスト値に基づいたトラフィックルートの設定が可能な、仮想サービスのSNIルーティングのサポート。
- Istioミキサコンポーネントにプルリクエスト(PR)を送らなくても、開発者自身がミキサアダプタを記述することが可能な、アウトオブプロセス・ミキサアダプタ。開発者が独自のペースで、独自のミキサアダプタを開発し、リリースすることが可能。
- ポリシチェックの大部分がenvoyサイドカープロキシで実行されるようになり、パフォーマンスと信頼性が向上した。例えば、マイクロサービスにRBACルールを適用する場合、ミキサは必要ない。
- 認証ポリシに加えて、相互TLSへの移行を容易にする“パーミッシブ”モードが新たに導入された。これにより、トランザクション中は“パーミッシブ”モードに入り、トランザクションが完全に終了した後はセキュリティを強化する、という運用が可能になる。
InfoQ: サイドカープロキシパターンはIstioの中核的な思想ですが、これは主にポッドにテレメトリを集めるためのものですか、あるいは、もっと大きな目的があるのでしょうか?
Sun: テレメトリデータの収集は、サイドカープロキシの行うことのひとつに過ぎません。デフォルトのプロキシ実装であるEnvoyは、ロードバランシングやルーティング、リトライなどの共通タスクを、すべての言語で一貫して処理します。
Envoyは、対象ポートのすべての受信トラフィックと、すべての送信トラフィックとをキャプチャして、MixerのサブコンポーネントであるIstioにテレメトリデータを送信します。さらに、レート制限のポリシチェックや、RBACあるいは属性ベースのポリシチェックを、ローカルに、あるいはIstio-policyコンポーネントを使用して実行します。最後に、認証や証明、相互TLSが有効な場合はそのキーをチェックすることで、メッシュ内のマイクロサービス間のセキュアな通信も処理します。
InfoQ: IstioはKubernetes専用ではないと思うのですが、他のプラットフォーム、例えばCloud FoundryやOpenShiftなどでも動作するのでしょうか?
Sun: この部分こそが、Istioがオープンに開発および運用されていることの美点です。Istioは事実上どこでも — Kubernetesクラスタでも、仮想マシン上でも、あるいはCloud Foundry環境内でも動作します。CNCFが公開しているKubernetes 1.91以降の適合試験にパスした、すべての環境が動作対象です。IBM Cloud Kubernetes Serviceやそれ以外のKubernetes 1.9クラスタを含む、あらゆる環境で実行できます、
インストール資料には、 さまざまな環境に対してIstioをセットアップする方法が説明されています。仮想マシンのサービスも、Istioメッシュの一部として参加可能です。IstioはCloud Foundryにも組み込まれています。Cloud Foundryのチームも、Istioの開発に積極的に貢献してくれています。
InfoQ: bookinfoの例題以外に、開発者やアーキテクトのためのIstio用の学習リソースを紹介して頂けますか?
Sun: bookinfoは、クラウドネイティブなマイクロサービス向けに書かれた素晴らしい学習用サンプルで、Istioのさまざまな機能を紹介するためにistio.io内でも広く採用されています。その他にも優れたリソースがたくさんあります。例えば、
- Istioに関するistio.ioのさまざまなブログ、タスク、例。
- KatacodaによるIstioとKubernetesの入門資料。
- IBMではKubernetes Guidebookの例を拡張して、マシンラーニングなど他のサービスとの統合方法を紹介しています。
- IBM CloudにもIstioリソースページが管理されています。
その他にも、Red HatやGoogleを始めとする多数のコミュニティメンバが、Istio入門を支援するためのさまざまなブログやタスク、サンプルを公開しています。
InfoQ: Istio 1.0以降のロードマップ、KubernetesやKnative、その他のコミュニティとの将来的な共同開発計画について教えて頂けますか?
Sun: IBMの立場としては、IstioがIBM Cloud上で簡単にセットアップして使用できることを重視しています。IstioはIBM Cloud戦略の重要なコンポーネントなのです。その中でも、特に重きを置いているのは、パブリックなIBM Cloud Kubernetes ServiceとオンプレミスのIBM Cloud Private環境にまたがるクラスタ全体で、統合されたマイクロサービスエクスペリエンスを提供する、連合型Istioサービスの提供です。
コミュニティ全般の見地から言えば、IBMとIstioコントリビュータが目標とするのは、1.0のフィックスと1.1のリリース、さらにはIstioを使いやすいものにして導入の幅を広げることです。この中には、必要に応じてIstioの部分的な採用を可能にすること、パフォーマンスとスケーラビリティの継続的な改善、ルーティングAPIなど重要機能の拡張、ノード毎にミキサを実行可能であること、複数の環境にIstioを展開すること、なども含まれています。複数のKubernetesクラスタをまたいでポッドをルーティングできないような、フラットでないネットワークのために、マルチキャストサポートの強化にも力を入れています。Istioは、Kubernetesコミュニティと緊密に連携しながら開発を進めています。コミュニティでは、Kubernetesを推奨プラットフォームとして引き続き選択しています。KnativeやFissionといった他のオープンソースプロジェクトがIstioを使っていることを嬉しく思います。彼らには将来的に、Istioをもっと簡単に使用できるものにしてくれる可能性があるからです。
Istio 1.0の技術的な詳細は、リリースノートに記載されている。
この記事を評価
- 編集者評
- 編集長アクション