San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
San Antonio API Security Summit 2025 に参加しよう!
閉じる
プライバシー設定
ウェブサイト運営に必要なCookieや類似技術を使用しています。追加のCookieは貴社の同意がある場合のみ利用されます。同意は「Agree」をクリックすることでいただけます。どのデータが収集され、どのようにパートナーと共有されているかの詳細は、Cookieポリシープライバシーポリシーをご確認ください。
Cookieは、貴社デバイスの特性や、IPアドレス、閲覧履歴、位置情報、固有識別子などの特定の個人情報を取得、解析、保存するために使用されます。これらのデータは様々な目的で利用されます。分析Cookieによりパフォーマンスを評価し、オンライン体験やキャンペーンの効果向上に役立てます。パーソナライズCookieは、利用状況に応じた情報やサポートを通じ、貴社専用の体験を提供します。広告Cookieは、第三者が貴社のデータをもとにオーディエンスリストを作成し、ソーシャルメディアやネット上でのターゲット広告に使用します。貴社は各ページ下部のリンクから、いつでも同意の許可、拒否、または撤回が可能です。
ご送信ありがとうございます。内容を受け付けました。
申し訳ありません。フォーム送信時にエラーが発生しました。
DevSecOps

Istio

Istioを使うと、企業はIT部門がアプリの可観測性、混雑管理、プライバシーを強化するために必要なツールを備えたインフラレイヤーを利用できます。 

さらに詳しい内容を読む

Istioとは何か

オープンソースのサービスメッシュ層であり、独立してデプロイできる複数のサービス間でのデータ交換を管理するために導入できます。アプリ内のネットワーク関連の作業をシンプルかつ柔軟に自動化できる、言語に依存しないオープンなフレームワークを提供します。

Istioを使うことで、IT部門はソースコードを変更せずにネットワーク管理やパフォーマンス見込み、プライバシーを強化できます。これにより、セキュリティやネットワーク接続のために新たなコードを作成する負担がなくなります。

さらに、Istioは企業がモジュール式のソフトウェアコンポーネントを守り、接続し、監視できるようにし、企業ネットワークを素早く安全に更新することを可能にします。クラウドネイティブアプリを構成する複数の自己完結型の配信オプションを管理するために、Kubernetes上にIstioを導入する企業が増えています。これはモジュール式ソフトウェアコンポーネントアプリにおけるサービス間接続とデータ交換を支援・管理します。

Istioの用途

分散ネットワークでマイクロサービスを制御し、守るために使われます。具体的には、次の主要な機能を提供します:

  • トラフィック管理

負荷の調整やトラフィック経路制御、カナリア配信など高度なトラフィック監視機能を備えており、モジュール式ソフトウェアコンポーネント間のトラフィックを管理・制御しやすくします。

  • セキュリティ

サービス間のトラフィックを暗号化し、認証や承認ポリシーを適用し、安全な通信チャネルを提供することでエンドツーエンドのセキュリティを実現します。

パフォーマンスや動作を監視するための詳細なテレメトリやメトリクスを提供し、問題の診断やトラブルシューティングを容易にします。

  • ポリシー適用

複数のサービスにわたってレートリミットやアクセス権限、クオータ管理などのルールを適用し、自律分散しているサービスがあらかじめ設定されたパラメータ内で動作するようにできます。

Istio ingress gatewayは、包括的なツール群と機能を提供することでモジュール式ソフトウェアコンポーネントの監視と運用を簡素化し、開発者がネットワークインフラではなくアプリの開発に集中できるようにします。

Istioの仕組み 

Istioの構成はコントロールプレーンとデータプレーンに分けられます。データプレーンはオープンソースのエッジおよびパッケージプロキシであるEnvoyを拡張したもので、アプリからネットワーク関連の懸念を切り離すのに役立ちます。ネットワークフィルターのモジュールシステムを使って受信接続を管理し、さらにEnvoyはHTTPトラフィック用のL7フィルターを追加で組み込むことができます。ここでは、このデータプレーン部分とコントロールプレーン全体を詳しく見ていきましょう:

  1. データプレーン

デプロイにサイドカーを追加することでデータプレーン上のサービスを補助できます。このマイクロサービスの補助プロキシはほかのプロキシからのリクエストを転送し、受け取ります。これらのプロキシ群が連携し、マイクロサービス間の通信をブロックするメッシュネットワークを形成します。

このプレーンは各サービス間のつながりに不可欠です。加えて、ネットワークが送られる通信の性質を把握したり、送信元や宛先に応じた適切な対応を取ったりすることは、これなしでは困難です。システム構成によっては、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がサービス間のトラフィックを制御し、レートリミットやアクセス制御などのセキュリティ戦略を適用します。

  1. コントロールプレーン

コントロールプレーンは、設定やサービスに関する独自の捉え方と、利用者が望む構成をあわせて柔軟に対応します。設定やルールが変わった場合でもプロキシのコードは動的に更新されます。これはトラフィックのルーティングを支援するためにプロキシを管理・設定する役割を担います。コントロールプレーンが持つ主要なポイントには以下が含まれます:

  • トランスポート層セキュリティによる暗号化と認証、およびIDベースの強固な確認でクラスター上のサービス間通信を保護
  • スイッチオーバー、リトライ、複雑なルーティング設定、フォールトインジェクションなどの手法を使用した柔軟なトラフィック管理
  • TCP、HTTP、WebSocket、gRPCなどのトラフィックを自動的に振り分け
  • クラスター全体のメトリクス、トレース情報、トラフィックを完全に自動収集
  • 強固なポリシーレイヤーと設定APIを使用してアクセス制御、レート管理、クオータを管理

Istioの利点

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の課題 

サービスメッシュはモジュール式ソフトウェアコンポーネントを運用するうえでの課題を緩和する理想的なソリューションですが、完璧ではなく、いくつかの問題点や批判があります。Istioには、以下のような悪影響が指摘されています:

  • 複雑さの増大

すでに複雑なシステムにプロキシなどの構成要素を追加すると、設計や運用がさらに煩雑になります。インフラレイヤーが増えることで構成が複雑化します。

  • 知識不足

Kubernetesのようなオーケストレーターに可変的なアーキテクチャ層を加えるには、両方の技術を熟知する必要があります。運用担当者にはさまざまな技術に関する深い知識と経験が求められます。

  • 速度の制約

サービスメッシュは侵襲性が高く複雑な技術であり、アーキテクチャ全体の速度を落とす恐れがあります。サイドカーを経由するため、アプリ呼び出しごとに追加の手間がかかり、遅延が生じる可能性があります。

  • ドキュメントの不足

Istioの入り組んだ仕組みにより、開発者や運用者は難しいプラットフォームとそのルールに対応する必要があります。ドキュメントはしばしば最新でなく、Istioエコシステム内のプロジェクト間で同期が取れていません。特定の手順を説明する文献も非常に少ないです。

  • 構成の手間

Istioは、Kubernetesでデフォルト設定を使うかたちなら簡単にセットアップできますが、これは開発環境までしか想定していない場合があります。カオスエンジニアリングなどの実験では設定をカスタマイズする必要があるため、経験豊富なエンジニアを招くなど、追加の手間がかかる可能性があります。

  • サービス範囲の限界

Istioアーキテクチャはサービス間の回復力とセキュリティ、デプロイ管理を提供するうえで優れていますが、サービスカバレッジに制限があります。その分析とパフォーマンステレメトリは対象のサービス間でのやり取りに限られます。Kubernetes環境以外でやりとりされるサービスも含めた全体像が必要となります。

  • 可視性低下のリスク

Istioやほかのサービスメッシュで分散トレースログを取得するには、やり取り範囲内の各サービスコードに明示的な変更が必要です。手動でコードを更新しても、そのサービス内部の動作を完全に把握できない場合があります。Kubernetesノードが並ぶ環境では、独自のログ機能の開発に多大なコストをかけない限り、企業が見落としてしまうリスクが残ります。

KubernetesでのIstioの活用

Kubernetesにコンテナを追加し、開発者や運用者にとっては見えない形で動かします。サイドカーコンテナがトラフィックを制御して各コンポーネントのやり取りを監視します。構成、監視、管理のいずれにもIstioとKubernetesを併用します。

  • 構成

Kubernetesの主な設定手段は、YAMLファイルを使って「kubectl -f <filename>」を実行する方式です。Istioを導入している場合、kubectlや新たに提供されるオプションのioctlコマンドを使って別のYAMLファイルを実行できます。

  • 監視

Kubernetes上で動作するアプリの状態監視を容易にします。Istioのアプリケーションヘルスの管理・可視化は、単にKubernetesのクラスタやノードを監視するだけでなく、さらに踏み込んで行えます。

  • 管理

Kubernetesに近い操作性を提供するため、管理がスムーズです。Kubernetesクラスタ全体を制御するポリシーを定義し、独自の管理コードを減らすことが可能です。

FAQ

最新情報を購読

学習目標
最新情報を
購読
購読する
関連トピック