オープンソースのサービスメッシュ層であり、独立してデプロイできる複数のサービス間でのデータ交換を管理するために導入できます。アプリ内のネットワーク関連の作業をシンプルかつ柔軟に自動化できる、言語に依存しないオープンなフレームワークを提供します。
Istioを使うことで、IT部門はソースコードを変更せずにネットワーク管理やパフォーマンス見込み、プライバシーを強化できます。これにより、セキュリティやネットワーク接続のために新たなコードを作成する負担がなくなります。
さらに、Istioは企業がモジュール式のソフトウェアコンポーネントを守り、接続し、監視できるようにし、企業ネットワークを素早く安全に更新することを可能にします。クラウドネイティブアプリを構成する複数の自己完結型の配信オプションを管理するために、Kubernetes上にIstioを導入する企業が増えています。これはモジュール式ソフトウェアコンポーネントアプリにおけるサービス間接続とデータ交換を支援・管理します。
分散ネットワークでマイクロサービスを制御し、守るために使われます。具体的には、次の主要な機能を提供します:
負荷の調整やトラフィック経路制御、カナリア配信など高度なトラフィック監視機能を備えており、モジュール式ソフトウェアコンポーネント間のトラフィックを管理・制御しやすくします。
サービス間のトラフィックを暗号化し、認証や承認ポリシーを適用し、安全な通信チャネルを提供することでエンドツーエンドのセキュリティを実現します。
パフォーマンスや動作を監視するための詳細なテレメトリやメトリクスを提供し、問題の診断やトラブルシューティングを容易にします。
複数のサービスにわたってレートリミットやアクセス権限、クオータ管理などのルールを適用し、自律分散しているサービスがあらかじめ設定されたパラメータ内で動作するようにできます。
Istio ingress gatewayは、包括的なツール群と機能を提供することでモジュール式ソフトウェアコンポーネントの監視と運用を簡素化し、開発者がネットワークインフラではなくアプリの開発に集中できるようにします。
Istioの構成はコントロールプレーンとデータプレーンに分けられます。データプレーンはオープンソースのエッジおよびパッケージプロキシであるEnvoyを拡張したもので、アプリからネットワーク関連の懸念を切り離すのに役立ちます。ネットワークフィルターのモジュールシステムを使って受信接続を管理し、さらにEnvoyはHTTPトラフィック用のL7フィルターを追加で組み込むことができます。ここでは、このデータプレーン部分とコントロールプレーン全体を詳しく見ていきましょう:
デプロイにサイドカーを追加することでデータプレーン上のサービスを補助できます。このマイクロサービスの補助プロキシはほかのプロキシからのリクエストを転送し、受け取ります。これらのプロキシ群が連携し、マイクロサービス間の通信をブロックするメッシュネットワークを形成します。
このプレーンは各サービス間のつながりに不可欠です。加えて、ネットワークが送られる通信の性質を把握したり、送信元や宛先に応じた適切な対応を取ったりすることは、これなしでは困難です。システム構成によっては、Istioのようなサービスメッシュソリューションがアプリに関する多様な機能を提供します。Envoyプロキシの能力により、Istioのサービスメッシュはさまざまな方法で機能します。具体的には:
Envoyを用いると、gRPC、HTTP、WebSocket、Transmission Control Protocol (TCP)などのルーティングに対してガイドラインを設定し、アプリのトラフィックを制御できます。これはパフォーマンスに影響し、デプロイ戦略の最適化にも役立ちます。Istioのトラフィック管理APIによって、サービスメッシュ通信をきめ細かく管理可能になり、Istioが扱えるトラフィックの種類が拡張されます。
フロー制御の中心となるAPIリソースは、バーチャルサービスとディスティネーションルールです。バーチャルサービスはIstioサービスメッシュに対してリクエスト転送の方法を示し、一連のルールを順番に評価します。次段階として、それとは別のディスティネーションルールを使います。特定の宛先への接続設定を行うことで、トラフィックが円滑に流れるようにします。
Istioは自動リトライ、フォールトインジェクション、サーキットブレイキングを標準でサポートしています。
Istioを守る最初のステップとして、各サービスに確固としたIDを与えます。ソリューションのエージェントとEnvoyプロキシは、キーと証明書のペアを自動でローテーションします。シチュエーションに応じて、ピア認証とリクエスト認証の2種類から選択可能です。
Istioがデプロイされている環境など、mTLSがフルスタックで利用できない場合はピア認証を使います。IstioはJSON Web Tokenの検証にも対応しており、専用のプロバイダやOpenID Connect (OIDC)プロバイダを使用できます。
Envoyがサービス間のトラフィックを制御し、レートリミットやアクセス制御などのセキュリティ戦略を適用します。
コントロールプレーンは、設定やサービスに関する独自の捉え方と、利用者が望む構成をあわせて柔軟に対応します。設定やルールが変わった場合でもプロキシのコードは動的に更新されます。これはトラフィックのルーティングを支援するためにプロキシを管理・設定する役割を担います。コントロールプレーンが持つ主要なポイントには以下が含まれます:
IstioとKubernetesをあわせて使うことで、コンテナを用いたマイクロサービスのシステムを円滑に動かすことができます。Istioはクラウド、オンプレミス、Kubernetes、Mesosなどで動作します。DevOpsエンジニアはIstioによって監視対象のサービスを把握できます。テレメトリにより、分散トレースや詳細なメトリクス、アクセスログの収集が可能です。これらの機能が組み合わさることで、さまざまなメリットを生み出します:
Istio Kubernetesによって分散サービスの可視性が深まります。アプリレベルのデータを収集し、コンテナや仮想マシンのネットワークを把握できます。クラスターで動作するアプリに対して、不透明な通信レイヤーを提供します。
相互トランスポート層セキュリティ(TLS)により、コンプライアンスやセキュリティポリシーを順守しつつサービスを認証し、サービス間通信を暗号化します。これによって通信ネットワーク全体の安全性が高まります。IDベースの多要素認証、許可、暗号化によってアプリレベルのセキュリティがさらに強固になります。
Istioは豊富なルーティング戦略、フェイルオーバー、リトライ、フォールトインジェクションを備えており、トラフィック動作を効率的に管理するのに役立ちます。ポストプロダクションのテストでChaos MonkeyをIstioと組み合わせることで、意図的に遅延やエラーを起こし、システム全体をより強固にします。ソリューションのトラフィック管理機能により、トラフィック量と基盤の容量を切り離せます。
サービスからのリクエストが到達する先を決定するネットワークトラフィック管理を担います。分散されたサービス間のトラフィックやAPI呼び出しを正しく流す役割を果たし、インテリジェントなルーティングをサポートします。エンドポイントが構成されると、リクエストはAPIコールとして認識され、データが送信・解析された後にレスポンスが返されます。
開発者がコードに集中して効率的にアプリを提供できるようにすることが重要です。同時にサービス間通信のための多言語ライブラリを構築する必要がありますが、Istio gatewayを活用すればこうした課題を解消できます。マイクロサービスを実現しつつ、プログラマーはアプリのビジネスロジック開発に集中可能です。
Istioはサービスレベルでの可視化を提供し、トレースやモニタリングを可能にするため、問題を把握しやすくなります。詳細情報がないとボトルネックの特定や解消は難しいですが、Istioのようなサービスメッシュを使えば、APIへの影響を最小限に抑えながら不調なサービスを即座に無効化できます。
Istio Kubernetesユーザーはコンテナベースのビルドシステムを活用し、複数のクラウド環境で稼働できます。パブリッククラウドやデータセンター、ハイブリッドクラウドにおいてサービス間セキュリティや問題監視、トラフィック制御を向上させます。
Istio Kubernetesにはクライアントベースのルーティング、ブルーグリーンやカナリアデプロイ、自動ロードバランシング機能があります。柔軟なAPIとプラグイン形式のポリシーレイヤーを用いて、Istioはアクセス制御やレートリミット、クオータを適用します。カスタマイズしたポリシーとして、利用許可リストやログ出力、監視なども含められます。
Istioのレートリミットは、拡大するマイクロサービス環境を管理します。マイクロサービス間の通信を集中管理し、サービスリクエストを処理するプロキシ層を分離します。プロキシコンテナから得られるテレメトリをダッシュボードで確認するため、インフラのパフォーマンスと信頼性が向上します。Istioはインフラの自己修復やあいまいなネットワーク障害への耐性も備えます。
Kubernetes上でIstioを稼働させると、大規模なマイクロサービスアプリに役立ちます。アプリへのアクセスが増えるとサービス間リクエストも増えるため、より洗練されたルーティングが求められます。データフローを最適化しつつソフトウェアのパフォーマンスを維持することが重要です。Istioのサービスメッシュを導入することで、新しいサービスを追加するたびにそれらの連携方法に悩むよりも、付加価値部分に集中できます。
サービスメッシュはモジュール式ソフトウェアコンポーネントを運用するうえでの課題を緩和する理想的なソリューションですが、完璧ではなく、いくつかの問題点や批判があります。Istioには、以下のような悪影響が指摘されています:
すでに複雑なシステムにプロキシなどの構成要素を追加すると、設計や運用がさらに煩雑になります。インフラレイヤーが増えることで構成が複雑化します。
Kubernetesのようなオーケストレーターに可変的なアーキテクチャ層を加えるには、両方の技術を熟知する必要があります。運用担当者にはさまざまな技術に関する深い知識と経験が求められます。
サービスメッシュは侵襲性が高く複雑な技術であり、アーキテクチャ全体の速度を落とす恐れがあります。サイドカーを経由するため、アプリ呼び出しごとに追加の手間がかかり、遅延が生じる可能性があります。
Istioの入り組んだ仕組みにより、開発者や運用者は難しいプラットフォームとそのルールに対応する必要があります。ドキュメントはしばしば最新でなく、Istioエコシステム内のプロジェクト間で同期が取れていません。特定の手順を説明する文献も非常に少ないです。
Istioは、Kubernetesでデフォルト設定を使うかたちなら簡単にセットアップできますが、これは開発環境までしか想定していない場合があります。カオスエンジニアリングなどの実験では設定をカスタマイズする必要があるため、経験豊富なエンジニアを招くなど、追加の手間がかかる可能性があります。
Istioアーキテクチャはサービス間の回復力とセキュリティ、デプロイ管理を提供するうえで優れていますが、サービスカバレッジに制限があります。その分析とパフォーマンステレメトリは対象のサービス間でのやり取りに限られます。Kubernetes環境以外でやりとりされるサービスも含めた全体像が必要となります。
Istioやほかのサービスメッシュで分散トレースログを取得するには、やり取り範囲内の各サービスコードに明示的な変更が必要です。手動でコードを更新しても、そのサービス内部の動作を完全に把握できない場合があります。Kubernetesノードが並ぶ環境では、独自のログ機能の開発に多大なコストをかけない限り、企業が見落としてしまうリスクが残ります。
Kubernetesにコンテナを追加し、開発者や運用者にとっては見えない形で動かします。サイドカーコンテナがトラフィックを制御して各コンポーネントのやり取りを監視します。構成、監視、管理のいずれにもIstioとKubernetesを併用します。
Kubernetesの主な設定手段は、YAMLファイルを使って「kubectl -f <filename>」を実行する方式です。Istioを導入している場合、kubectlや新たに提供されるオプションのioctlコマンドを使って別のYAMLファイルを実行できます。
Kubernetes上で動作するアプリの状態監視を容易にします。Istioのアプリケーションヘルスの管理・可視化は、単にKubernetesのクラスタやノードを監視するだけでなく、さらに踏み込んで行えます。
Kubernetesに近い操作性を提供するため、管理がスムーズです。Kubernetesクラスタ全体を制御するポリシーを定義し、独自の管理コードを減らすことが可能です。
最新情報を購読