マイクロサービスを支える「Istio」の実力は？ サービスメッシュの利点と課題：日立製作所の研究員が語る（1/2 ページ）

マイクロサービスアーキテクチャを適用したアプリケーションは、規模の拡大に伴い運用が煩雑化してしまう。その課題の解決策として登場した「サービスメッシュ」という考え方とその実装として期待が高まっている「Istio」は、どの程度有用なのか。日立製作所の井出貴也氏が、検証の成果をもとに解説した。

[西野大介，SOMPOホールディングス]

日立製作所 研究開発グループ デジタルテクノロジーイノベーションセンタ サービスコンピューティング研究部 研究員 井出貴也氏

　独立したサービスを組み合わせて1つのアプリケーションを形作る「マイクロサービスアーキテクチャ」。サービスの構造に合わせて開発組織も個別に独立させることで、機能の追加拡張を容易にしたり、開発スピードの高速化を実現したりできるとして注目されている。

　しかし、運用面での課題は少なくない。アプリケーション内でサービス同士が通信するため、アクセス制御やルーティングなどの実装／管理コストは増大する。分割されたサービスそれぞれに独立したソリューションを適用した場合、工数が肥大化したり、仕様や品質がサービスごとに変わったりして、開発スピードに影響を及ぼす恐れがある。

　その課題を解決する手段の一つが、サービスの独立性という利点を生かしつつ、運用の一貫性を実現する「サービスメッシュ」と呼ばれるデザインパターンだ。2020年1月に行われた「Envoy Meetup Tokyo #1」の講演で、日立製作所の研究開発グループに所属する井出貴也氏は、「サービスメッシュ」およびその実装であるオープンソースソフトウェア（OSS）の「Istio」について、実運用してきた研究成果を公開した。

「Istio」を検証利用した上での結論

　IstioはGoogle、IBM、Lyftが開発を始めたOSSだ。独立したサービスで構築されたアプリケーションのサービス間通信を管理する。日立製作所の研究開発部門では、Istio 0.6が登場し、アプリケーション開発のトレンドとして浮上してから、検証を兼ねた実運用をしてきたという。

　井出氏はIstioの評価として「システム全体にわたって一貫性のある方法でサービス間通信を管理できるため便利だが、現状運用負荷が高い。活用できるかどうかは、その負荷をペイできるユースケースがあるか次第」と 結論付けた。加えて、「運用負荷以外にも、システムの複雑化、リソース消費およびレイテンシの増加という要素もあるため、その点を許容できるかどうかも観点として検討すべき」としている。以下、順を追って詳細を見ていきたい。

Istioの構造

　Kubernetes内の通信は、Kubernetesのコンポーネントである「Service」を介してPod内のコンテナに届けられる。Istioは、各Podの前段に透過プロキシサーバ（Envoy）を配置し、プロキシサーバ経由で通信をコンテナに届けるようにする。各プロキシが端点を押さえ、それらをIstioが提供する「Control Plane」（コントロールプレーン）と呼ばれる管理機能を用いて動的に制御させることで、ネットワークの一元管理を実現している。

Control Planeが各プロキシを動的制御することにより、「通信管理」「セキュリティ管理」「モニタリング」などを透過的に行うことが可能（出典：日立製作所）

日立製作所内でのIstio適用ケース

　日立製作所では、Istioの有用性の検証も兼ねて、自社の開発者向けに開発環境を提供するアプリケーションにIstioを導入した 。このアプリケーションは開発用のWebエディタおよびバックエンドサービスの環境を提供するもので、そのバックエンドの中身は個別の独立チームが自律的に開発する体制となっている。システム全体はKubernetesベースで構築され、100を超えるNodeと2000を超えるPodにより構成されるという。

　提供当初より、サービス間通信において柔軟なルーティングの実現や、サービス間アクセス制御、通信メトリクスを収集したいというニーズがあったものの、独立チームが開発するバックエンドサービスに干渉することは避けたいと考えていた。そこでIstioがトレンドに急浮上したことで導入を決めたという。

Kubernetesで構築され、組織横断で利用される環境の管理で、サービスメッシュが求められる局面だった（出典：日立製作所）

利用して実感したIstioの利点

　検証結果として「便利だが運用負荷は重い」という結論に至ったのは冒頭の説明の通りだが、「便利」という点について井出氏が挙げたのは以下の3点だ。

その1：透過的な通信管理

　Istioの機能は独立しているため、個々のサービスの改修が不要だ。そのため、既存のプロダクトやOSSなど、改修するには負荷が高いアプリケーションで利用する際に、その利便性の高さを実感したという。またAuto-Injection機能によりプロキシの自動挿入もできるため導入が容易で、バックエンドを作成するサービスチームとのコミュニケーションコストも低くできた実感があったという。

　加えて、通信管理機能自体も柔軟かつ高機能で、これまで個別のサービス内で設定していたリトライ数やタイムアウト、サーキットブレークなどの設定までKubernetes外で管理できたことも、利点として挙げた。

その2：Kubernetesネイティブの恩恵

　IstioはKubernetesネイティブであり、Istio自体もKubernetesで動作する。そのため、Kubernetes自体が持つ「Replica」や「Horizontal Pod Autoscaler」などの機能を活用することで、Istio自体の可用性やスケーラビリティを高められる。Kubernetes用のパッケージマネジャーの「Helm」など、Kubernetesがこれまでに積み上げてきたエコシステムを活用することもできる点は「非常に使い勝手がいい」とした。

その3：コミュニティーの活発さ

　OSSにとって重要である、コミュニティーの活動状況も利点として強調した。登録されたIssueは平均5日程度で反応があり、パッチアップデートも隔週レベルで提供されているなど、活況だという。そしてOSSとしての人気も高いため、公式ドキュメント以外にも書籍やブログなど情報が多いことも利点の一つだ、と井出氏は解説する。