IBMがKubernetes活用のアプリ管理フレームワーク「Istio」

日本IBMは8月24日、都内でアプリ管理フレームワーク「Istio」の最新動向に関する説明会をメディア向けに開催した。

冒頭、日本IBM IBMクラウド事業本部テクニカル・セールスエグゼクティブ・テクニカル・スペシャリストの樽澤広亨氏は「元々クラウドは分散コンピューティングだが、これをさらに進化させていく上で、これまで経験したことがない超分散システムに直面する。Istioは基幹システムの安定稼働に向けたサービスメッシュを使いやすくするためのものだ」と、述べた。

日本IBM IBMクラウド事業本部テクニカル・セールスエグゼクティブ・テクニカル・スペシャリストの樽澤広亨氏

Istioは、米IBMとGoogle、Istioコミュニティが7月31日(現地時間)に「Istio 1.0」として発表し、サービスメッシュの最適化を可能としている。

マイクロサービス同士で複雑に絡み合うサービスメッシュを最適化するという

クラウドネイティブコンピューティング環境では、マイクロサービスを用いてアプリを構築する際に数百～数千ものサービスがネットワークに分散配置され、それらのネットワークをセキュアに管理する、つまりサービスメッシュの最適化を図ることが成功に導く鍵になるという。

デジタルビジネスを進める上では、素早いITシステム開発(スピード)と容易なシステム変更・保守(柔軟性)が求められている。

樽澤氏はそのような状況を踏まえ、「過去10年間におけるクラウドブームの中で各ベンダーが注力していたのはクラウドプラットフォーム(基盤)であり、アジャイル開発やマイクロサービスアーキテクチャなどのクラウドネイティブアプリ(業務)には注力してこなかった。最近では各ベンダーがアプリのモダナイゼーションに力を入れている」との認識を示す。

そこで、クラウドネイティブコンピューティングを実現する技術要素として「コンテナ化」「動的なオーケストレーション」「マイクロサービス指向」の3点を挙げている。

コンテナはクラウドネイティブに最適な仮想化技術であり、ミドルウェアとアプリだけをパッケージし、MB単位のサイズのためコンパクトであり、コンテナエンジンはオープンソースでどこでも動くことから秒単位のデプロイを可能とし、容易なデプロイ・移行ができる。

動的なオーケストレーションに関しては、コンテナは従来型の分散コンピューティングの技術要素に例えるとサーバプロセスであり、本番環境にはクラスタ構成が必要となるが、クラウドネイティブ環境においてクラスタ管理を行うことを「Kubernetes」が可能としている。

マイクロサービスについては、クラウドネイティブアプリ開発・運用のベストプラクティスであり、アーキテクチャや開発運用チームフォーメーション、システムライフサイクルを対象に、アプリ個別の保守を可能にする柔軟なモジュラー構造を実現するという。

特に重要なのがアーキテクチャであり、小さなサービスを複数連ねて大きなアプリを構築し、各マイクロサービスは独立した環境で稼働させるため、アプリを置き換える際はサービスを置き換えればいいことからメンテナンスを容易にしている。

従来型のアーキテクチャとマイクロサービスのアーキテクチャ

Kubernetesをベースにマイクロサービスのネットワークを管理

Istioは、上記3つの技術要素を持ち合わせており、Kubernetes環境をベースに各マイクロサービスのネットワークを管理する。

「Istio」の概要

樽澤氏は、Istioの特徴について「プラットフォームに依存しないことに加え、アプリのソースコードに依存せずに追加・変更を不要とし、プログラミング言語も問わない」と強調する。

各マイクロサービスにはプロキシサーバ「Envoy」が組み込まれており、サービス間の通信はEnvoyを経由する。Envoyにはルーティングやロドバランシングなどのロジックを組めば、サービス数が万単位でも管理できるという。

また、Envoyの構成管理を行うPilot、アクセス制御やポリシー設定などのMixer、Mutual TLSの認証であるCitadelで構成した管理用コンポーネントはCLIで管理する。

「Istio」のアーキテクチャ

機能としては、トラフィック管理、セキュリティ、監視の3つとなる。トラフィック管理ではルーティングやロードバランシング、タイムアウト/再試行、ブルー/グリーンデプロイメント、カナリアリリース、A/Bテスト、フォールトインジェクション(Chaos Engineering)、サーキットブレーカを可能としている。セキュリティでは認証、認可、暗号化、監視ではログ、トレース、メトリクスができる。

同氏は、特にトラフィック管理を重点的に説明し、一例として本番システム運用と並行して次期リリースの試行と評価を行うカナリアリリースは、トラフィック転送の90%を現行本番環境、残り10%を次期本番環境に振り分けることで、次期本番環境に問題がなければ次期本番環境にすべてを切り替えることを可能としている。