Istio導入のメリットとハマりどころを、実例に学ぶ～マイクロサービス化の先にある課題を解決する

• マイクロサービスを増やしていくならサービスメッシュ化を検討すべき
• KubernetesやIstioは今までの技術の集大成
• 運用したからこそわかるIstioのハマりポイント
  • ハマりどころ1：設定の反映が遅延する
  • ハマりどころ2：エンドポイント登録がnamespase単位で分かれていない
  • ハマりどころ3：istio-proxyの制限にひっかかる
• 使っている人に聞いてみた「Istio-proxyを経由すると10ms遅くなる？」
• Istioの導入はアーキテクチャだけでなく、組織の動きも変わる

「マイクロサービスの構築」が近年のWeb業界で大きなキーワードになっています。さまざまな企業が、さまざまなアプローチでマイクロサービス化にトライしていますが、サービスが分割していくほどに、各サービス間の接続が複雑化する、という課題も生まれています。

こうした課題を解決するソフトウェアとして「Istio」と、同ソフトがもたらす「サービスメッシュ」という概念が注目されています。Istioはまだまだリリースされて日の浅いソフトウェアですが、これをいち早く導入したのが企業・業界情報プラットフォーム「SPEEDA」を運営する株式会社ユーザベースです。

同社ではマイクロサービス化を推進していく中で、信頼性を保ちつつ、頻繁な変更に対応できるシステムを構築していくためにIstioを導入したといいます。今回はIstioのメリットやハマりどころといった、実運用に基づく貴重な知見を、同社のSRE阿南肇史（あなん・としふみ）さんに聞きました。

マイクロサービスを増やしていくならサービスメッシュ化を検討すべき

──まずは、SPEEDAにIstioを導入した背景を教えてください。

阿南　マイクロサービスの運用を楽にしたいというのが一番の理由です。SPEEDAはサービス開始から10年が経っており、モノリシックな構成になっていました。その結果、開発が思うように進まなかったり、ひとつの修正が広範囲に影響を及ぼしてしまう状態になっていたため、マイクロサービスアーキテクチャを採用し、オンプレミス環境にKubernetesを構築したのです。

しかし、Kubernetesを導入後、クラスター外部からのアクセス設定やマイクロサービス間のネットワークなどが次第に複雑になっていくという課題が見えてきたんです。弊社では、今後もマイクロサービス化を推進していく方針をとっていますので、複雑化するネットワークをサービスメッシュ化する必要性も感じていました。そこでサービスメッシュを実現するためにIstioを試しに使ってみたところ、SPEEDAにマッチすると感じたので導入しました。

──導入して特にメリットに感じた部分はありますか。

阿南　マイクロサービス化された環境ではネットワークのルーティング周りに課題が多くありますが、それをIstioに集約できるので運用が楽になります。

例えばSPEEDAではブルーグリーンデプロイの複雑な設定がIstioによって解決されました。Istio導入前はサービスごとにBlue環境とGreen環境のエンドポイントを用意し、上位にあるApacheで切り替えるようにしていました。簡単な図にすると、以下のような構成です。

しかし、この方法だとサービスごとに設定ファイルを作成し、Apacheでどちらにリクエストを送るか切り替えする必要があります。Blue/Greenでのリリースを採用しているため、常に一方の環境はクローズしておくといった状態をApacheが持つことになり、Apacheが意図せず再起動した際にBlueとGreenの環境を両方オープンしてしまう危険もありました。Istio導入のタイミングで、こういったルーティングの状態管理はIstioに任せることにしました。Istioを導入後の構成は以下のようになります。

ApacheはIstioにリクエストをフォワードするだけでよくなるため、複雑な設定を管理する煩雑さから解放されますし、リリースのパイプラインも組みやすくなります。

──サーバの状態をIstioに任せられると安心してデプロイできそうですね。

阿南　そうですね。加えて、Istioではデプロイとリリースのタイミングを簡単に切り分けることができます。僕は、デプロイはアプリケーションを環境に配置することであり、リリースは配置したアプリケーションにアクセスがある状態と解釈しています。設定をひとつ変えれば特定のサービス（バージョン）にだけアクセスがいくようにもできるため、サービス単位で安心してリリース前に本番環境でテストができます。

──マイクロサービスでは分散トレーシングも課題視されますが、その点はいかがでしょうか。

阿南　そういった面もサービスメッシュにしておくと、課題を解決しやすくなります。Istioは送信と受信の両方向の通信をトレースできるため、ネットワークのログが追いやすいからです。また、Addonでistio-tracingを有効にしておくと、jeagerで簡単にリクエストを可視化できるので、例えば特定のブラウザからのリクエストが遅いとか、あるAPIを経由した時に遅くなっている、といった事象を簡単に発見できます。

マイクロサービスは「ひとつのサービスが落ちても運用を続けられる」と言われますが、例外的なケースもあるでしょう。実際に弊社で運用している際にも、ひとつのAPI障害により上位のバランサーに負荷がかかり、広範囲の障害に繋がったケースもあります。ですので、こうした障害が発生した場合に、どのマイクロサービスに問題があるのか即座に把握する必要があります。

また、弊社のように必ずしも全てのサービスがKubernetesで運用されていなかったり、外部サービスとのAPIがあったりすると、クラスター外の通信も考慮しないといけません。Istioを導入すると、アプリケーションがレスポンスを返す際にクラスター外のAPIにアクセスする必要があった場合でも、そのAPI呼び出しにどれだけ時間がかかったか取得することができます。実際の運用でも特定のAPIが遅く原因を調査したところ、実は別のAPIと通信している部分が遅かったということがあります。istio-proxyで双方向の通信をトラックすることにより、そのような問題もすぐに見つけることができます。

──nginxなどでプロキシを立てるだけだと外部の通信はトラッキングしにくいですからね。

阿南　プロキシを立てて同じことを実現するのは難しいと思います。それにIstioはPrometheusやGrafanaなどのログ監視系のソフトウェアとも連携しやすいという利点もあります。ログを収集して可視化しやすいので、よくできているなと感心します。

KubernetesやIstioは今までの技術の集大成

──Istioのメリットを強く感じますが、導入で苦労した点はありますか。

阿南　そもそもサービスメッシュという概念を理解すること自体が大変でした。サイドカーパターンも実際に触ってみないと利点が理解しにくいと思います。あとは単純に概念とレイヤーが増えるので、ネットワークは複雑になります。

Podの中にWebサーバ以外の補助的な機能をもつサーバを立てる構成。Istio proxyの場合は、デフォルトでEnvoyというプロキシを利用する。通信をEnvoyに任せることができ、ネットワーク構成が変わってもアプリケーション側に影響がない。ひとつのコンテナに対してEnvoyをなぜインジェクトする必要があり、それによるメリットは何であるのかというのは阿南さんの言う通りドキュメントを読んでもつかみにくい。

──ネットワークが複雑になってもIstioを導入するメリットの方が大きいと感じますか。

阿南　そこはトレードオフだと思います。SPEEDAではネットワークを複雑にする代わりにアプリケーションをシンプルにするという選択をしました。

サイドカーパターンはアプリケーションに変更を加えず設定ができるため、ネットワークの共通処理を任せることができます。アプリ側でアクセス量によって許可や拒否を実装するのは大変です。そういったネットワークの処理はサイドカーに一任することでアプリをシンプルに保つことができます。

──ネットワークの仕組みが変わるので導入は大変そうですね。

阿南　導入は大変でした。まだまだIstioも発展途上のプロダクトなのでバグも多く、自分の手順が悪いのかIstioのバグなのか分からなくなることがよくありました（笑）。

また、ネットワークが複雑になり通信の流れを把握しにくくなるため、tcpdump、iptables、netstatなどの基礎的なコマンドを使い通信の流れを整理していきました。tcpdumpのログを見て「このPodまでは通信きているな」といったように把握していったんです。導入してみて分かったのは、Istioを本格的に自分たちで管理して運用するためにはネットワークの基礎を理解している必要がある、という点です。

ひとつTips的な話ですが、Istio proxyには前述のネットワーク系のコマンドが入っているので調査はしやすいと思います。コンテナでは容量を圧縮するためにコマンドも削って「curlが入ってない」ということもありえますが、こうしたケースでは便利ですね。

──ネットワークの複雑化やバグのリスクを考えると、シンプルに「便利だから導入しよう」と判断するのは難しいかもしれませんね。

阿南　マネージドIstio等を利用するとまた状況が変わるかもしれませんが、本気で自社運用しようと思ったらネットワークの流れを理解しないとトラブルに対応できないと思います。Kubernetesもそうですが、Istioは過去から連なる技術の集大成だと感じます。理解するためにそれ相応のスキルが要求される印象があるのは事実です。

──導入時のコツはありますか。

阿南　Istioによって作成されるコンポーネントの意味をひとつずつ理解していくことが一番の近道だと思います。インストールするだけでPodも一気に作成されるので、各Podの役割を把握して、control planeとdata planeの通信がどのように行われているのかを把握すべきでしょう。

もうひとつ、「何を解決したくてIstioを導入するのか」をはっきりしておくことが重要だと思います。弊社の場合、ルーティングやリリースの柔軟性、通信の透過性を高めるために導入したので、そのために必要な機能のみ適用しています。繰り返しますが、Istioはまだ発展途上のプロダクトですので、不安定な面もあります。いきなり全機能を有効にしてしまうと、どこで問題が起きているのか分からなくなってしまいます。例えば、mTLSが必須ではないケースであれば、最初は無効にしておいたほうがデバッグが簡単になります。通信のデバッグ時に、アプリケーションレベルの認証が入ってくるとさらに難易度が上がってしまいますので。

運用したからこそわかるIstioのハマりポイント