Cloud Native Developers JP 今だから改めて知っておきたい Service Meshの世界 @hhiroshell 1

Cloud Native Developers JP 宣伝 • COVID-19が収束したら遊舎⼯房に⾏くんだ…！ 2 遊舎⼯房さんの店舗はこちら→ ↓現在の@hhiroshellのキーボード #crkbd ⾃⼰紹介 @hhiroshell 早川 博 （はやかわ ひろし） • Cloud Nativeなインフラを開 発するエンジニア。 Yahoo Japan Corporation 所属 • エンジニアコミュニティ 「Cloud Native Developers JP」 オーガナイザー • Developers Summit 2018 Japan Container Days 12.18 CloudNative Days Tokyo 2019 登壇 • ⾃作キーボード沼

Cloud Native Developers JP ⽬次 1. Service Meshとは 2. 様々なService Meshのプロダクト 3. Service Meshの今後 3

Cloud Native Developers JP ⽬次 1. Service Meshとは 2. 様々なService Meshのプロダクト 3. Service Meshの今後 4

Cloud Native Developers JP マイクロサービス・アーキテクチャとは • マイクロサービス・アーキテクチャ （以下、Microservices） – ⼤規模なシステムを疎結合な複数のサー ビスの組み合わせで実現する設計⽅式 – サービス同⼠がネットワーク経由で呼び 合うことで連携する • REST over HTTP, gRPC, ⾮同期メッセージング ...etc – 個々のサービスがデプロイメントの⼀単 位 ⼤規模なシステムを疎結合な複数のサービスの組み合わせで実現する設計⽅式 5 https://github.com/microservices-demo/microservices-demo/blob/master/internal-docs/design.md

Cloud Native Developers JP ビジネスの変化 に追従できる！ • モノリシックアーキテクチャ – ⼤規模になると機能要素同⼠の依存 関係が複雑化しがち • ⼀部の変更が全体にどう影響するか把握 しにく、更新に⻑い⼯期を要する • 構成要素の単位が⼤きく、簡単にはス ケールできない • Microservices – 複数の疎結合なサービス群で⼤規模 なシステムを構成 • 変更の影響範囲を個々のサービスに留め られるため、サービス単位で⾼頻度に更 新できる • 必要な構成要素に絞って素早くスケール できる 6 なぜ Microservices が求められているのか？ Microservices はビジネスの不確実性に対処するためのアーキテクチャ ビジネスの変化に 追従できない…！

Cloud Native Developers JP Microservices における様々な課題 • パフォーマンス – ネットワーク通信増による性能劣化 • 複数サービスの協調動作 – サービス同⼠を連携させる難しさ • データの⼀貫性 – 分散したデータの⼀貫性の確保 • モニタリング – 監視の仕組みの構築運⽤コスト増 • ネットワーク起因の障害 – ⼀時的な通信断や遅延の発⽣ • 実装⽅式の分断 – 学習コスト、保守コスト増 • セキュリティ – 分散化に伴うアタックサーフェス増 • 構成管理のコスト – 多数サービスの管理はコストが⾼い Microservices の課題は多岐に渡る 7

Cloud Native Developers JP Microservices における様々な課題 • パフォーマンス – ネットワーク通信増による性能劣化 • 複数サービスの協調動作 – サービス同⼠を連携させる難しさ • データの⼀貫性 – 分散したデータの⼀貫性の確保 • モニタリング – 監視の仕組みの構築運⽤コスト増 • ネットワーク起因の障害 – ⼀時的な通信断や遅延の発⽣ • 実装⽅式の分断 – 学習コスト、保守コスト増 • セキュリティ – 分散化に伴うアタックサーフェス増 • 構成管理のコスト – 多数サービスの管理はコストが⾼い Microservices の課題は多岐に渡る 8 なんかたくさん ある！ >_<.

Cloud Native Developers JP まだまだあるよ…！ ビルド & デプロイ戦略 • ⾼頻度のリリースを⾏うためには、 ビルドからデプロイまでのプロセス の⾃動化が避けて通れない (CI/CD) • ⾃動化された⾼頻度リリースのリス クを低減するための⼯夫が必要 → Blue/Green デプロイメント カナリアリリース 安全な⾼頻度リリースのために必要なもの 9 V2 Canary V1 V1 CI/CD ツール ⾃動デプロイ クライ アント トラフィック 1% 99% 【カナリーデプロイメント 】 1%から始めて徐々に新バージョン へのトラフィック配分を増やす

Cloud Native Developers JP まだまだあるよ…！ ビルド & デプロイ戦略 • ⾼頻度のリリースを⾏うためには、 ビルドからデプロイまでのプロセス の⾃動化が避けて通れない (CI/CD) • ⾃動化された⾼頻度リリースのリス クを低減するための⼯夫が必要 → Blue/Green デプロイメント カナリアリリース 安全な⾼頻度リリースのために必要なもの 10 V2 Canary V1 V1 CI/CD ツール ⾃動デプロイ クライ アント トラフィック 1% 99% 【カナリーデプロイメント 】 1%から始めて徐々に新バージョン へのトラフィック配分を増やす もうこれ以上 無理〜！ >_<.

Cloud Native Developers JP 11 ⼤変だ…。 ⼤変だ…。 もうこれ以上 無理〜！ >_<. なんかたくさん ある！ >_<.

Cloud Native Developers JP 12 だれ？ 落ち着いて考えるのじゃ…。 もうこれ以上 無理〜！ >_<. なんかたくさん ある！ >_<.

Cloud Native Developers JP Microservices における様々な課題 • パフォーマンス – ネットワーク通信増による性能劣化 • 複数サービスの協調動作 – サービス同⼠を連携させる難しさ • データの⼀貫性 – 分散したデータの⼀貫性の確保 • モニタリング – 監視の仕組みの構築運⽤コスト増 • ネットワーク起因の障害 – ⼀時的な通信断や遅延の発⽣ • 実装⽅式の分断 – 学習コスト、保守コスト増 • セキュリティ – 分散化に伴うアタックサーフェス増 • 構成管理のコスト – 多数サービスの管理はコストが⾼い Microservices の課題は多岐に渡る 13 • TimeoutによるUX低下の軽減 • ⾮同期化やキャッシュの利⽤ • リーダー昇格パターンや Scheduler-Agent-Supervisor • 結果整合性の担保に留める • 補正トランザクションの導⼊ • サービス間通信の出⼊りを拾って メトリクスを集める

Cloud Native Developers JP Microservices における様々な課題 • パフォーマンス – ネットワーク通信増による性能劣化 • 複数サービスの協調動作 – サービス同⼠を連携させる難しさ • データの⼀貫性 – 分散したデータの⼀貫性の確保 • モニタリング – 監視の仕組みの構築運⽤コスト増 • ネットワーク起因の障害 – ⼀時的な通信断や遅延の発⽣ • 実装⽅式の分断 – 学習コスト、保守コスト増 • セキュリティ – 分散化に伴うアタックサーフェス増 • 構成管理のコスト – 多数サービスの管理はコストが⾼い Microservices の課題は多岐に渡る 14 • TimeoutによるUX低下の軽減 • ⾮同期化やキャッシュの利⽤ • リーダー昇格パターンや Scheduler-Agent-Supervisor • 結果整合性の担保に留める • 補正トランザクションの導⼊ • サービス間通信の出⼊りを拾って メトリクスを集める Network Network

Cloud Native Developers JP Microservices における様々な課題 • パフォーマンス – ネットワーク通信増による性能劣化 • 複数サービスの協調動作 – サービス同⼠を連携させる難しさ • データの⼀貫性 – 分散したデータの⼀貫性の確保 • モニタリング – 監視の仕組みの構築運⽤コスト増 • ネットワーク起因の障害 – ⼀時的な通信断や遅延の発⽣ • 実装⽅式の分断 – 学習コスト、保守コスト増 • セキュリティ – 分散化に伴うアタックサーフェス増 • 構成管理のコスト – 多数サービスの管理はコストが⾼い Microservices の課題は多岐に渡る 15 • ⼀時的な通信断にリトライで対処 • サーキットブレーカーで障害伝搬を抑制 • 実装の共通化箇所を設ける （⾔語ランタイムやネットワーク層） • 通信の暗号化 • 脆弱性検知の⾃動化 • 外部構成ストアの利⽤

Cloud Native Developers JP Microservices における様々な課題 • パフォーマンス – ネットワーク通信増による性能劣化 • 複数サービスの協調動作 – サービス同⼠を連携させる難しさ • データの⼀貫性 – 分散したデータの⼀貫性の確保 • モニタリング – 監視の仕組みの構築運⽤コスト増 • ネットワーク起因の障害 – ⼀時的な通信断や遅延の発⽣ • 実装⽅式の分断 – 学習コスト、保守コスト増 • セキュリティ – 分散化に伴うアタックサーフェス増 • 構成管理のコスト – 多数サービスの管理はコストが⾼い Microservices の課題は多岐に渡る 16 • ⼀時的な通信断にリトライで対処 • サーキットブレーカーで障害伝搬を抑制 • 実装の共通化箇所を設ける （⾔語ランタイムやネットワーク層） • 通信の暗号化 • 脆弱性検知の⾃動化 • 外部構成ストアの利⽤ Network Network Network

Cloud Native Developers JP Service Meshのコンセプト • Microservices の課題はたくさんある が、ネットワークのところで対処で きるものも多いらしい • ネットワークのとこに⼀層設けてそ こで対策を実装したら良さそう – アプリケーションは変更不要 – 共通実装は専⽤プロダクトに任せて品 質アップ ネットワークの共通処理を委譲するレイヤー 17 サービスA サービスB Business CCC Business CCC サービスA サービスB Business Business Proxy CCC Proxy CCC Data Plane Microservices + Service Mesh Microservices * CCC = Cross Cutting Concerns 共通の関⼼事 Control Plane

Cloud Native Developers JP • ルーティング – L7 (Header, Path…) ベース のトラフィック配送 – 1%単位の配送割合指定 • 回復性 – リトライ – タイムアウト – サーキットブレーカー 18 • モニタリング – アクセスログ – 通信状態のメトリック – 分散トレーシング • セキュリティ – SSL相互認証 (mTLS) – 認可ポリシーの適⽤ Service Meshに期待される機能 ネットワークレイヤーで実現可能な様々な機能を提供

Cloud Native Developers JP Service Mesh が解決する課題の⼀例 – 障害の連鎖 1. サービスAが依存するサービスBで 障害発⽣ 19 システムの広範囲が機能しなくなるケースも 2. サービスAでサービスBの応答待ち のリクエストが累積 3. 応答待ちリクエストがAのリソース を専有し、Aも停⽌ 4. Bへのアクセス集中が続き、 Bが復旧困難に。Bに依存する他 サービスもAと同様に次々停⽌ A B A B A B A B C D

Cloud Native Developers JP 対策 - サーキットブレーカー • サービス呼び出しに対する応答が⼀定の条件を満たした場合に、障害発⽣ と判断し、以降の呼び出しを遮断する機構 • 呼び出し元のサービスに早期にエラーが返されるので、呼び出し元でのリ ソースの専有を回避。適切なエラーにフォールバックできる • リクエストが遮断されている間に障害を起こしたサービスが回復 20 障害が起きたサービスを負荷から開放して素早く復旧 サービス サービス サーキット ブレーカー サービス サービス サーキット ブレーカー error ! (1) ⼀定数のエラーを観測したら error ! (2) リクエストを遮断 復旧！

Cloud Native Developers JP Service Meshの基本的なアーキテクチャ 1/2 • Data Plane – サービス間のトラフィックを仲介するプロ キシ – 通信時にService Meshとしてのインテリジェ ントな機能を実⾏する • Control Plane – Data Planeを管理するコンポーネント – 各Data Planeに所定の設定を適⽤するなどの 役割をもつ 21 https://kuma.io/docs/0.4.0/overview/what-is-kuma/ Data Plane Control Plane

Cloud Native Developers JP • Sidecar – Data Planeをサービス毎に1つ配置 • Kubernetesでは各PodにSidecarコンテナと してData Planeを封⼊する – Sidecarの数が多くなり、その分オー バーヘッドが⼤きくなる傾向 • Daemon – Data Planeを各ホストに1つ配置 • KubernetesではDaemonSetとしてData Planeをデプロイする – mTLSが実装しにくく、この機能を 提供していないプロダクトがある 22 Service Meshの基本的なアーキテクチャ 2/2 サービスA サービスAʼ Proxy Proxy サービスB Proxy サービスA サービスAʼ Proxy サービスB Proxy

Cloud Native Developers JP Service Mesh の基本的なアーキテクチャ 3/3 • Data Plane の配備 – Sidecar コンテナとして各サービスのPodに封⼊されるか、DaemonSet として各 Node にひとつずつデプロイされる – Sidecar ⽅式が主流 • Control Plane の配備 – Pod として Kubernetes 上にデプロイされる • Service Mesh への設定の適⽤ – 各プロダクトの設定情報は CustomResourceDefinition の manifest として記述 – kubectl を使って、通常の Kubernetes リソースと同じ感覚で適⽤できる 23

Cloud Native Developers JP Service Meshで対処できない課題の例 • 複数のサービスに係るデータの更新に対して 結果整合性を確保したいケース – データ更新が途中でエラーになったとき、正しく ロールバックをかけるにはアプリケーションの知識 が必要 – ネットワークのレベルで⼀律な処理をかけるだけで は解決できない • 【参考】 – 「マイクロサービスにおける決済トランザクション管理」 • https://tech.mercari.com/entry/2019/06/07/155849 – 「補正トランザクション パターン」 • https://docs.microsoft.com/ja-jp/azure/architecture/patterns/compensating-transaction Service Meshは万能ではないので注意 24 サービスA 更新 サービスB 更新 サービスC 更新 サービスD 更新 サービスA 補正ロジック サービスB 補正ロジック サービスC 補正ロジック サービスD 補正ロジック 更 新 補正データ 補正データ 補正データ 補正データ ロ ! ル バ ッ ク

Cloud Native Developers JP 【参考】API Gateway • Socialな距離が遠い組織に提供するアクセス境 界として機能させたい（e.g. 商⽤の公開API） – バージョンや互換性の厳密な管理 – API利⽤量の監視。⽤途によっては課⾦の管理 • エンドポイントを統⼀してクライントの簡素 化を図りたい • 認証/認可、API利⽤量の管理などの機能を⼀元 化し背後のサービス群の実装を簡素化したい 似ているようで⽤途がちょっと違う 25 サービス サービス サービス サービス サービス サービス API Gateway

Cloud Native Developers JP ⽬次 1. Service Meshとは 2. 様々なService Meshのプロダクト 3. Service Meshの今後 26

Cloud Native Developers JP 27 Istioだけかと思いきや。 Service Meshの主要プロダクト • Istio • Linkerd • Kuma • Maesh • AWS App Mesh • Consul Connect • Anthos Service Mesh

Cloud Native Developers JP お知らせ • 以降のスライドで「Service Meshの選び⽅」という⽂⾔を含むタイトルのものは、 Service Mesh Comparison (https://servicemesh.es/) のコンテンツを元にしています。 28 © “INNOQ” Last updated: March 10 2020

Cloud Native Developers JP Service Meshの選び⽅ 1. 解決したい最も重要な課題を特定する 2. ⾮機能要件の観点で、重視するポイントを明らかにする 3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る 4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落 とす 5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオー バーヘッドを検証して候補を決定する 当たり前のことを地道にやっていく 29

Cloud Native Developers JP Service Meshの選び⽅ 1/3 1. 解決したい最も重要な課題を特定する 2. ⾮機能要件の観点で、重視するポイントを明らかにする 3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る 4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落 とす 5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオー バーヘッドを検証して候補を決定する まずは要件を明らかにしよう 30 • 解きたい課題は？ / それはService Meshで解決できる？ • 重視する⾮機能要件は？ • シンプルさ、使いやすさ • パフォーマンス • 互換性

Cloud Native Developers JP Service Meshの選び⽅ 2/3 1. 解決したい最も重要な課題を特定する 2. ⾮機能要件の観点で、重視するポイントを明らかにする 3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る 4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落 とす 5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオー バーヘッドを検証して候補を決定する 各プロダクトの特徴を把握しよう 31 • 次ページ以降、以下3プロダクトを紹介していきます • Istio / Linkerd / Kuma

Cloud Native Developers JP Istio • 諸元 – 開発主体: – 現在の最新バージョン: 1.5.2 • アーキテクチャ – EnvoyベースのData PlaneをSidecarとして封⼊して利⽤ • 特徴 – 最もメジャーなService Mesh。⽇本でもいくつかの事例がある – Service Meshに期待される機能を網羅的にカバー – 1.5.xから多数のコンポーネントからなるControl Planeを少数のバイナリに統合するな ど、運⽤しやすさを⾼める⽅向の進化に進みつつある ド定番。今最もメジャーなService Mesh 32

Cloud Native Developers JP Linkerd • 諸元 – 開発主体: Buoyant – 現在の最新バージョン: 2.7.1 • アーキテクチャ – Rustで実装された独⾃のData PlaneをSidecarとして封⼊して利⽤ • 特徴 – CNCFでホストされる唯⼀のService Mesh。Istioについでメジャー – Service Meshに期待される機能の多くを実装 – 独⾃のData Planeによる⾼性能を売りにしている。実際いくつかのベンチマーク例で はIstioよりも⾼性能な成績を出している – 設定の記述が⽐較的シンプルなのも特徴 パフォーマンスに優れた CNCF Project で唯⼀の Service Mesh 33

Cloud Native Developers JP Kuma • 諸元 – 開発主体: Kong – 現在の最新バージョン: 0.4.0 • アーキテクチャ – EnvoyベースのData PlaneをSidecarとして封⼊して利⽤ • 特徴 – 実現している機能は少なめだが、Envoyの形式の設定情報をそのままData Planeに配布 する機能があり、これによって⾃由度を確保している – ひとつのControl Planeで複数のメッシュを定義・管理し易い。マルチテナントのユー スケースで⾼い運⽤性を発揮しそう – Kubernetes以外の環境でのユースケースを他に⽐べ強く打ち出している（後述） シンプルで使いやすさに優れた新興プロダクト 34

Cloud Native Developers JP Kubernetes 以外の環境での活⽤例 • Kubermetes以外の環境（VMなど）にも⽤意に適⽤可能なことを⽣か して、アーキテクチャの変更前あらService Meshを適⽤する • モニタリングや安全なデプロイ⼿法を使ってリスクを低減しつつ、 アーキテクチャの変更を進める Service Meshを最初に適⽤してから安全にMicroservicesに移⾏する 35 https://kuma.io/docs/0.4.0/overview/vm-and-k8s-support/

Cloud Native Developers JP Service Meshの選び⽅ 3/3 1. 解決したい最も重要な課題を特定する 2. ⾮機能要件の観点で、重視するポイントを明らかにする 3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る 4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落 とす 5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオー バーヘッドを検証して候補を決定する 候補のプロダクトを検証して最終決定しよう 36 • 最後は検証。コレばっかりは避けられない

Cloud Native Developers JP Demo というほどでもないですが…。 • 各プロダクトのmanifestの感じを⾒てみます。 37

Cloud Native Developers JP Service Mesh のプロダクトを検証しよう • 最後には、実際に触って判断しよう – チュートリアルを流すだけでも、運⽤性を判断するための感触は得ることが できる – パフォーマンスは、⾃分たちのアプリケーションを使って性能⽬標を満たせ るか確認すべし • いくつかのベンチマークツールが参考にできる – @idさん w/ Hitatchi : https://github.com/Hitachi/istio-bench – Kinvolk 社の汎⽤ツール : https://github.com/kinvolk/service-mesh-benchmark • プロダクトによっては性能⽬標を公開している – Istio: https://istio.io/docs/ops/deployment/performance-and-scalability/ – Linkerd: https://linkerd.io/2/design-principles/ 「推測するな、計測せよ」 38

Cloud Native Developers JP ⽬次 1. Service Meshとは 2. 様々なService Meshのプロダクト 3. Service Meshの今後 39

Cloud Native Developers JP Service Mesh の今後 • 機能拡充よりも、プロダクトとしての成熟を⽬指す⽅向性が⽬⽴つ ようになってきた – 導⼊の容易さ、管理運⽤のし易さ – オーバーヘッドの削減 • とはいえ、広く普及するにはまだ課題が多いのが現状 – Data Plane の疎通障害時におけるトラブルシュート、デバッグの難しさ – Control Plane の管理、運⽤ノウハウの不⾜ • そもそも Kubernetes やその上のカスタム Controller を問題なく運⽤できているだろうか → さらなる実⽤性の向上に期待 実運⽤への適⽤を⾒据えた進化に期待 40

Cloud Native Developers JP • Network Service Mesh – L2/L3 レイヤーの Service Mesh – Kubernetes のリソースにユーザが使 いたい L2/L3 Network Serviceを与え るのが主な⽬的 – CNCF Sandbox プロジェクト • Service Mesh Interface – Service Mesh の標準仕様 – K8s の CustomResourceDefinition のと して仕様を定義。複数種のService Mesh の相互運⽤、互換性を⽬指す – CNCF Sandbox プロジェクト 41 Service Mesh の新たな⽅向性 この後のセッションでご紹介

Cloud Native Developers JP まとめ • Microservices には様々な課題がある • Microservices の課題のうち、ネットワークレイヤーで対処可能なも のの多くを、Service Mesh が解決してくれる • Service Mesh のプロダクトを選択するのは簡単ではない – 要件を明らかにしたうえで、実際に検証して選択する。王道かつ地道な選定 ⽅法にしたがおう 42

Cloud Native Developers JP Fin. 43

Cloud Native Developers JP Appendix. 参考⽂献 44

Cloud Native Developers JP 【参考⽂献 1/2】本編スライドでリンクしていないもの • Azure アーキテクチャ センター > 「設計のパターン」 – https://docs.microsoft.com/ja-jp/azure/architecture/patterns/ • Service Meshの⽐較サイト – Service Mesh Comparison: https://servicemesh.es/ – Layer5: https://layer5.io/landscape • 書籍「Kubnernetes実戦ガイド – クラウドネイティブアプリケーショ ンを⽀える技術」 – https://book.impress.co.jp/books/1118101053 45

Cloud Native Developers JP 【参考⽂献 2/2】「いらすとや」さんのイラスト • 落ち込む会社員たちのイラスト • バンザイをしている会社員たちのイラスト • 燃え尽きた⼈のイラスト（男性会社員） • インターネットの神様のイラスト • 交通整理をしている⼈のイラスト • ストーカーのイラスト（男性被害者） • 復職を考えている⼈のイラスト • 電鍵のイラスト 46