Istio

menu icon

Istio

開発者がさまざまなマイクロサービスのネットワークを円滑に接続、管理、保護するためのオープン・テクノロジー、Istioの詳細をご覧ください。

Istioとは

Istioは、Kubernetesクラスター内のコンテナを接続、モニター、保護する、構成可能なオープンソースのサービス・メッシュ・レイヤーです。本稿の執筆時点では、IstioはKubernetesのみでネイティブに動作しますが、オープンソースであるため、別のクラスター・ソフトウェアでもIstioを実行できるようにする拡張機能が作成される可能性があります。 ここでは、最も一般的なユースケースであるKubernetesでのIstioの使用に焦点を当てます。

Kubernetesはコンテナ・オーケストレーション・ツールであり、Kubernetesの1つの中核ユニットとなるのがノードです。ノードは、1つ以上のコンテナと、ファイル・システムやその他のコンポーネントから構成されます。 マイクロサービス・アーキテクチャーにはさまざまなノードが含まれることがあり、それぞれが異なるマイクロサービスを表しています。Kubernetesはノードの可用性とリソース消費量を管理し、ポッド・オートスケーラーにより需要の増加に応じてポッドを追加します。 Istioは、セキュリティー、管理、およびモニタリングを追加するために、追加のコンテナをポッドに注入します。

Istioはオープンソースであるため、これをサポートする任意のパブリッククラウド・プロバイダーと、それに協力する管理者がいる任意のプライベートクラウド上で実行することができます。

ネットワーク・サービス・メッシュ

組織がマイクロサービスに移行する場合、数十から数百の固有のアプリケーションをサポートする必要があります。 こうしたエンドポイントを個別に管理するということは、需要を含め、多数の仮想マシン(VM)をサポートすることを意味します。Kubernetesのようなクラスター・ソフトウェアは、ポッドを作成してスケーリングすることができますが、Kubernetesはルーティング、トラフィック・ルール、強力なモニタリング・ツールやデバッグ・ツールは提供しません。

そこでサービス・メッシュの登場です。

サービスの数が増えるにつれて、可能性のある通信パスは指数関数的に増加します。 2つのサービスには2つの通信パスしかありません。 3つのサービスには6つの通信パス、10のサービスには90の通信パスがあります。 サービス・メッシュは、通信のポリシーを作成することによって、それらの通信パスを構成する統一的な方法を提供します。

サービス・メッシュはサービスを計測し、事前定義された構成に従って通信トラフィックを誘導します。 つまり、管理者は、実行中のコンテナを構成する(そのようにコードを書く)のではなく、サービス・メッシュを構成しておくと、サービス・メッシュにその作業を完了させることができるということです。 以前、Webサーバーとサービス間通信では、常にこれが行われていました。

クラスターでこれを行う最も一般的な方法は、サイドカー・パターンを使用することです。 サイドカーとは、ポッド内部の新しいコンテナで、サービスとコンテナの間の通信トラフィックを経路指定して監視するものです。

IstioとKubernetes

前述のように、IstioはKubernetesの上にレイヤーを作り、基本的にプログラマーや管理者には見えないコンテナを追加します。 「サイドカー」コンテナと呼ばれるこれらのコンテナは、「中間者」として機能し、トラフィックを誘導してコンポーネント間の対話をモニタリングします。 この2つが組み合わされ、構成、モニタリング、管理の 3つの方法で機能します。

構成

Kubernetesを使用して構成を設定するための主な手法は、kubectlコマンドです。このコマンドは通常、「kubectl -f <filename>」(ファイルはYAMLファイル)です。Istioユーザーは、kubectlで別の新しい種類のYAMLファイルを実行するか、あるいは新しいオプションのioctlコマンドを使用することができます。

監視

Istioを使用すると、Kubernetesで実行しているアプリケーションの正常性を容易にモニターできます。 Istioの計測では、アプリケーションの正常性を管理して視覚化することができ、Kubernetesが提供するクラスターやノードの一般的なモニタリングよりも、多くの洞察が得られます。

管理

IstioのインターフェースはKubernetesと本質的に同じものなので、それを管理することに追加の作業はほぼ必要ありません。 Istioでは、ユーザーはKubernetesクラスター全体に影響を及ぼし管理するポリシーを作成することができます。それにより、カスタム管理コードが不要になり、各クラスターを管理する時間を短縮できます。

メリット

サービス・メッシュの主なメリットは、デバッグ、モニタリング、ルーティング、セキュリティーのより高い機能を利用できることです。 つまりIstioでは、より少ない労力でより幅広いサービス・グループを管理できるようになります。

デバッグの向上

例えば、サービスに複数の依存関係があるとします。 ある保険会社のpay_claimサービスは、deductible_amtサービスを呼び出し、このサービスはis_member_coveredサービスを呼び出すといったように続くとします。 複雑な依存関係の連鎖になると、10から12のサービス呼び出しが含まれることがあります。 これら12のサービスのいずれかに障害が発生すると、連鎖的に障害が発生し、その結果500番台エラーや400番台エラーが発生したり、場合によっては応答がまったくなかったりすることがあります。

その一連の呼び出しをデバッグするため、スタック・トレースに似た仕組みを使用できます。 フロントエンドでは、クライアント・サイドの開発者がWebサーバーからどのようなエレメントがどのような順序で取り出されているかを確認し、それらを調べることができます。 フロントエンドのプログラマーは、ウォーターフォール・ダイアグラムを取得してデバッグを補助することができます。

この例では、データセンターで何が起きているか、つまりcallback=parselLotamaAudiencesが他の4つのWebサービスをどのように呼び出しているか、応答がより遅いのはどれかについては示されていません。後ほど、Istioが関数呼び出しをトレースするためのツールをどのように提供するかについて、これに似た図で説明します。

モニタリングおよびプログラム識別情報

DevOpsチームおよびIT管理者は、トラフィックを監視して、待ち時間、サービス時間、トラフィックにおけるエラーの割合などを確認したいことがあります。そのような場合は、ダッシュボードで見たいと思うでしょう。 ダッシュボードは、時間の経過に伴う合計、平均、あるいはそれらのメトリックを視覚化したものを提供し、通常、特定のノード、サービス、ポッドに「ドリルダウン」する機能が備えられています。 Kubernetesはこの機能をネイティブに提供しません。

ポリシー

Kubernetesではデフォルトで、すべてのポッドが他のすべてのポッドにトラフィックを送信できます。 Istioでは、管理者がポリシーを作成して、相互に連携できるサービスを制限することができます。 例えば、サービスが真の依存関係にある他のサービスのみを呼び出せるようにすることができます。 サービスを維持するためのもう1つのポリシーは、レート制限です。これは、過剰なトラフィックによりサービスが停滞しないようにし、DoS(denial of service)攻撃を防ぎます。

ルーティングとロード・バランシング

デフォルトでは、Kubernetesはラウンドロビン・ロード・バランシングを提供します。1つのマイクロサービスを提供する6つのポッドがある場合、Kubernetesは、要求を各ポッドに昇順に送信した後、また最初に戻って送信するロード・バランサー(「サービス」)を提供します。 しかし企業は、同じサービスの異なるバージョンを実動にデプロイすることがあります。

この最も簡単な例が、Blue/Greenデプロイです。 このケースでは、ソフトウェアはまったく新しいバージョンのアプリケーションを実動にビルドすることがありますが、それには実動ユーザーの要求は送信されません。新しいバージョンをプロモートした後、企業は古いサーバーを保持して、障害が発生した場合に迅速にスイッチバックすることができます。

Istioでは、これは構成ファイルでのタグ付けの使用と同じくらい簡単です。 また、管理者はラベルを使用して接続先のサービスの種類を示したり、ヘッダーに基づいてルールを構築したりすることもできます。例えば、ベータ・ユーザーは最新で最大のビルドを含む「カナリア」ポッドに、そして通常のユーザーは安定した実動ビルドにルーティングされます。

回路遮断

サービスが過負荷またはダウン状態になると、それが続いている間はそれ以上の要求は失敗します。 Istioはエラーと遅延をトラッキングしているため、ポリシーによって設定された特定数の要求の後、強制的に一時停止してサービスを復旧させることができます。 小さなテキスト・ファイルを作成し、それを新しいポリシーとして使用するようIstioに指示することによって、クラスター全体にわたってこのポリシーを適用することができます。

セキュリティー

Istioは、認証、許可、および監査(AAA)とともに、ID、ポリシー、暗号化をデフォルトで提供します。 他のポッドと通信する管理下のポッドはすべて暗号化トラフィックを使用するため、監視できません。 IDサービスは、暗号化と組み合わされ、無許可ユーザーがサービス呼び出しを偽造(「スプーフ」)できないようにします。 AAAは、少ないオーバーヘッドでモニターするために必要なツールをセキュリティーおよび運用の担当者に提供します。

管理の簡素化

従来のアプリケーションでは、Istioが提供するID、ポリシー、およびセキュリティーの各機能が依然として必要です。 そのためプログラマーと管理者は、不適切な抽象化レベルで作業し、すべてのサービスに対して同じセキュリティー・ルールを何度も再実施しなければなりません。 Istioでは、プログラマーと管理者は、単一のコントロール・パネルを使用して、クラスターのポリシーを設定し、適切なレベルで作業を行うことができます。 同時に、以下で説明するIstioのアクセス制御、ダッシュボード、およびデバッグ・ツールを使用すると、Webページに移動するのではなく、コマンド・ラインでプラグインを簡単に追加することができます。

サービスの視覚化

Istio 1.1には、Webベースの可視化を提供するKialiという新しいアドオンが含まれています。これを使用して、サービス要求をトラッキングしたり、掘り下げて詳細を調べたり、さらにはサービス要求履歴をJSONとしてエクスポートして独自の方法で照会およびフォーマットしたりすることができます。 以下のワークロード・グラフは、実際に相互に依存するサービスに基づいた、リアルタイムに生成される依存関係グラフです。 これはトラフィックを実際に観察した結果から生成されます。

Webベースの可視化を提供する、Kialiという新しいアドオンのイメージ

サービス呼び出しのトレース

IstioのコンポーネントであるJaegerサービスは、任意のサービスに対するトレースを提供します。 この例では、製品ページをトレースしました。 最初のイメージ内のドットは、サービス呼び出しを表します。 ドットをクリックすると、ウォーターフォール・ダイアグラムに「ドリルダウン」して、対象のサービス要求と応答をフォローすることができます。

Istioのコンポーネントで、任意のサービスに対するトレースを提供するJaegerサービスのイメージ  この例では、製品ページをトレースしました。 最初のイメージのドットはすべて、サービス・コールを表します。

製品ページをさらに詳しく調べることもできます。 エラーが製品ページ自体に含まれていることが分かります。詳細は正常に返されました。

製品ページのイメージ。  エラーが製品ページ自体に含まれていることが分かります。詳細は正常に返されました。

ダッシュボード

Istioには、システムの正常性とパフォーマンスをモニターする多数の(すぐに使用できる)ダッシュボードが備わっています。 ダッシュボードでは、CPUおよびメモリーの使用率、トラフィック需要、400番台および500番台のエラー、要求に対応するまでの時間などを測定できます。 これらのダッシュボードは、Istioをインストールして実行し、これに含まれているIstioのオープンソース・ダッシュボード・ツールの1つであるGrafanaを追加するだけで使用できます。 また、IstioはKialiとJaegerという2つのダッシュボードも提供します。

システムの正常性とパフォーマンスをモニターするIstioの多数の(すぐに使用できる)ダッシュボードのイメージ

Istioと Envoy

Istioは、モニタリング、管理、およびロギングを実行するために、大きく拡張されたEnvoyを使用しています。 すべてのポッドをトラッキングする必要があり、Istioはすべてのポッドに関する情報を集約して提供する必要があります。 Istio使用の代替案の1つとして、EnvoyをKubernetesクラスターに直接デプロイし、管理コードを書くことが考えられます。 しかし考えてみればこれは、カスタム開発プロジェクトに関連するコストとバグをすべて含め、Istioを本質的に書き直してしまうということです。

チュートリアル

Istioのウェブサイト(IBMの外部リンク)には、数多くの役立つドキュメンテーションと、Istioの使用を開始するための説明が記載されています。 

IstioとIBM

Managed Istioは、IBM Cloud Kubernetes Serviceの一部として利用できます。このサービスは、Istioのシームレスなインストール、コントロール・プレーン・コンポーネントの自動更新とライフサイクル管理、プラットフォーム・ロギングとモニター・ツールとの統合を提供します。 Managed Istio統合を新規または既存のクラスターに追加して、今すぐマイクロサービスの制御を取り戻しましょう。 Knativeの詳細については、「Knative: 基本ガイド」を参照してください。

IBM Cloud Kubernetesサービス上のManaged Istioの詳細をご覧ください。

マネージドKubernetesがクラウド・ジャーニーにおいてどのように役立つかについては、動画「マネージドKubernetesの利点」をご覧ください。

実稼働環境でのコンテナの導入を可能にし促進するためのベスト・プラクティスについて詳しくは、レポート「実動におけるコンテナとKubernetesの実行のベスト・プラクティス」を参照してください。

アプリケーション内のサービス間の対話を制御するためにサービス・メッシュがどのように役立つかについては、実用ガイド「Istio概説:サービス・メッシュ入門」(PDF、4.1 MB)をご覧ください。

IBM Cloudをすぐ使用するには、こちらからご登録ください。