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

　これらの課題に対しては、Istioに関するナレッジを一元管理する社内Wikiを用意し、社内で情報を共有することで対策としているという。

社内限定のWikiにより、Istioに関する情報の属人化を防いでいる（出典：日立製作所）

その2：頻繁なバージョンアップへの対応コスト

　Istioの安定版であるLTS（Long Term Support）バージョンは3カ月ごとにリリースされるが、次のLTSがリリースされると過去バージョンのサポートは終了する（※1）ため、通常は3カ月、長くても6カ月という頻度で、バージョンアップへの追従が求められる。単純なバージョンアップへの追随だけでもその検証や移行の工数が大きく、スムーズな対応のために専任者を立てる必要があったという。

※1：Istioのリリースサイクルについて（公式サイト）

　また過去には特定の設定を禁止とするような破壊的アップデートがあり、構成の再検討に工数を必要としたこともあるという 。加えて、アップデートにより、リソース消費量の変化が発生するケースもある。例えばメモリの消費量が大幅に低減するようなメリットの大きい変化があった一方で、設定のデフォルト値が変更された影響でメトリクス情報が大量出力されるようになり，検証環境で 輻輳（ふくそう）が発生するような事象にも遭遇したという。

　井出氏はバージョンアップ関連の対策として、「Istio-Operator」と呼ばれる運用操作自動化ツールを挙げた。APIの提供によりインストールの複雑さを隠すもので、ValidationやDeprecatedポリシーの適用により堅牢（けんろう）性が向上している点も特徴だ。コミュニティーでは今後、Helmによるインストールを廃止し、こちらに移行する方針が検討されているという。

その3：Istioと個別サービス間における役割分担の難しさ

　タイムアウト、リトライ、CORS（Cross-Origin Resource Sharing）などはIstioでまかなえる機能だが、それらを既に個別のサービスで実装しているケースがあり、どちらにその役割を持たせるかという議論があったという。統一管理する方針ならIstioで実現すべきであるものの、無理な押し付けはサービスチームの反発を招きかねないと語った 。

　またIstioリソースの管理者（オーナー）を誰にすべきかという役割の課題も挙げた。Istio自体の位置付けが開発部門と運用部門の中間のような曖昧な存在であることもあり、適切にルール化しないと運用の混乱につながってしまう。ただし、そのルール適用も難しかった、と井出氏は実情を語った。

　例えば、Istioにはクラスタ全体に適用する機能があり、それらのリソースをサービスチームが自由にデプロイしてしまうとクラスタ障害につながる恐れがあるため、これだけ見ると「運用部門が 一元管理をすべき」と判断できる。しかし他方で、ルーティングやタイムアウトのように、アプリケーション要件で変わる要素は個々のサービスチームが自律的に設定する運用を促したい面もあり、そういった相反する権限要件に頭を悩ませたという。

　上記の対策としては、Istioの設定をHelm Chartとしてパッケージングし、サービスチームに提供する方法を採ったという。その結果、タイムアウトやリトライ設定のような、サービスチームに直接操作してほしい機能のみを設定項目として切り出すことができる。またHelmを介してサービスチームが活用したい機能を自ら判断可能にすることで 、ルールの押し付けによる反発を防ぎ、権限問題の解消も実現したという。

その4：プロキシのメモリ消費

　Istioは、先述したControl Planeでプロキシの宛先リストを作成し、それを各プロキシに配布することで、プロキシ同士が宛先を特定できる構造になっている。

　今回の検証では、その宛先リストがPod数に比例して増加する構成となっており、Podが1000個に達すると、プロキシ1つで750MBものメモリを消費する事態に発展。それにより、メモリエラー（Out of Memory）の発生を防ぐためのサイジングが高難度化してしまった。さらにリソース消費傾向はバージョンごとに変化するため、3カ月のアップデートごとに性能評価をせざるを得ない事態に陥ったという。

　上記に対しては、性能評価を自動で実行する「istio-bench」を内製して対応した。Pod数に応じたリソース消費量を予測するツールで、ダミーのPodを大量にデプロイしてIstioコンポーネントのリソース消費量（メモリ／CPU／通信量）をPrometheusから収集。これにより、Pod数に対するリソース消費量を予測しやすくし、サイジングの難易度を下げられたという。

日立製作所の独自ツール「istio-bench」により、サイジングを容易に（出典：日立製作所）

その5：認証認可の複雑化

　Istioの機能を最初から全体適用する場合、アプリケーションへの影響が大きくなってしまう。とはいえ一部のみに適用した場合、認証認可の仕組みが複雑になる。Istio適用有無で認証認可の方式や条件が異なるため、サービスごとに整理して適用する必要がある。対策として日立製作所では、認証のパターンを表の通り整理し、明確化しているという。

認証のパターンを整理し明確化（出典：日立製作所）

便利さと引き換えに生まれるコストをペイできるかどうかが鍵

　Istioは、拡大したマイクロサービスの運用管理において強力なツールであり、コミュニティーの勢いも盛んだ。他方で、運用負荷も高く、発展し続けるが故にプラクティスもまた定まっていないといえる。井出氏は、その特徴をおさらいした上で、「コストをペイできるユースケースがあるかどうかが重要」と強調し、検証成果報告の結びとした。