GKEにおけるサービスメッシュ(Istio/Stackdriver)

HRMOS採用管理のSREチームのlicht110です。
最近は監視周り整備とか開発環境、CI/CD改善などをやっております。

今回は7月にサンフランシスコで開催された Google Cloud Next ‘18 という GCP や G Suite などの新機能/新製品に関する発表が行われるイベントに参加してきましたので、その中で気になった技術を紹介したいと思います。

IstioとStackdriver

今回のイベントではこのIstioとStackdriverの二つが非常に推されているように感じました。

自分が参加したセッションが監視やDevOpsの分野に偏り気味だったということがありますが、半分以上のセッションでもこのIstio、Stackdriverが出てきておりました。

このIstioとStackdriverとは一体何者なのでしょうか?

Istio

Istioはサービスメッシュの役割を果たすOSSです。 サービスメッシュとは、マイクロサービスにおいて個々のサービス間の通信を制御し、カナリアデプロイ、A/Bテスト、認証、アクセスコントロールをするものです。

Istioのアーキテクチャ (上図:Istioのアーキテクチャ

Istioのアーキテクチャは上記の画像に示す通りで、4つのコンポーネントから成り立っています。

  • Envoy(Proxy)

    • マイクロサービス間のInput/Outputの通信全てを仲介する
  • Mixer

    • サービスメッシュにおいてアクセスコントロールとポリシーを施行する
  • Pilot

    • Envoyのためにサービスディスカバリー、カナリアデプロイ・A/Bテストなどのための通信制御、サーキットブレイカーなどを提供する
  • Citadel

    • 強力なクレデンシャル管理によるservice-to-service認証、ユーザー認証を提供する

Stackdriver

StackdriverはGCPの統合監視プラットフォームです。 主に以下の機能が提供されています。

  • Monitoring

  • Logging

  • Error Reporting

  • Debugger

  • Trace

Stackdriverコンソール

なぜIstioとStackdriverなのか

マイクロサービスアーキテクチャの課題

サービスメッシュが重要視されるようなった背景にはマイクロサービスアーキテクチャの流行があります。

マイクロサービスには良い点はたくさんありますが、当然のことながら課題も存在します。

一つは、アーキテクチャの複雑化です。

マイクロサービス化によってコンポーネントが増えて根本的にアーキテクチャは複雑化しているのでトラブル時の対応は当然難易度が上がります。

また、組織のサイロ化もマイクロサービス化したときによく聞く課題の一つです。

マイクロサービスの構造上、1チームで1つのマイクロサービス担当となることが多いと思います。

このとき、自チームのサービスのことはよくわかっているが隣のサービスのことはよく分からず、サービスの全体像を把握している人がいなくて何かエラーが起こった時の原因特定や対処が分からないといったことが起こり得ます。

そして、各マイクロサービスごとにデプロイが走ることにより常にサービスの状態が変化し続け、トラブルが起こったときの状態を把握するの難しいといった課題も出てくるようになりました。

IstioとStackdriverの機能とそれが解決する課題

サービストポロジーの可視化

下記の画像のように、Istioから送られた情報を元にStackdriverがサービストポロジーを可視化します。

これによって複雑化したマイクロサービスの全体像が一見できるようになり、さらにどこのマイクロサービス同士が通信しているのかも可視化されるのでトラブルシュートのときにかなり嬉しい機能だと思います。

service topology

エラーのトレースと根本分析

Stackdriverでは下記の画像のように、タイムスライダーをいじることで、その時点のサービスの状態を可視化してくれます。

例えばリクエスト数やレスポンスタイム、その他CPU、Memory使用率などエラーが起こった時のサービスの状態を一覧することができます。

service-status

さらに、どこの処理に時間がかかっているか、アプリケーションのログなどそこからまた一つ深い階層に潜ってエラーの根本に迫って行くことが可能です。

個人的にこれは非常に強力なツールであると感じています。

response-time

まとめ

上記のようにIstioとStackdriverの組み合わせは複雑化したマイクロサービスの全体像を可視化し、さらに非常に強力なデバッグ/エラートラッキング機能を備えたマイクロサービス時代必須の監視プラットフォームとなってくれるのではないかと期待しております。

また、今回の Google Cloud Next ’18 参加に対する感想ですが、私自身海外のカンファレンスに参加するというのは社会人になってからは初めてでしたので非常に新鮮で良い経験でした。

今時はYouTubeでイベント直後にセッションの内容が配信されたりしていて、現地に行く意味あるの?なんて声もありますが、実際GCPとしてどういう方向性を目指して行くのかとか、セッション参加者の様子などで盛り上がってる技術のトレンドなども肌で感じることができたので、現地に行くということは一定の価値があると思いました。

昨今はKubernetesのような共通のコンテナオーケストレーション技術が各クラウド業者でサービスと提供され始めているので、ベンダーアンロックインやマルチクラウド化が進みつつあるような印象を感じています(もちろん実際の課題はたくさんあると思いますが)。

それに伴いクラウド業界の勢力図にも変化が起こりつつあると感じているので、こういったカンファレンスに参加することによってトレンドを追う嗅覚だったりを身に付けるのは大事だと感じる良いイベントとなりました。