#cndjp 第14回勉強会 「ウイルスに負けるな!cndjp春のService Mesh祭り!」の発表資料です。 https://cnd.connpass.com/event/170826/
Cloud Native Developers JP今だから改めて知っておきたいService Meshの世界@hhiroshell1
View Slide
Cloud Native Developers JP宣伝• COVID-19が収束したら遊舎⼯房に⾏くんだ…!2遊舎⼯房さんの店舗はこちら→↓現在の@hhiroshellのキーボード #crkbd⾃⼰紹介@hhiroshell早川 博(はやかわ ひろし)• Cloud Nativeなインフラを開発するエンジニア。Yahoo Japan Corporation 所属• エンジニアコミュニティ「Cloud Native DevelopersJP」 オーガナイザー• Developers Summit 2018Japan Container Days 12.18CloudNative 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– 個々のサービスがデプロイメントの⼀単位⼤規模なシステムを疎結合な複数のサービスの組み合わせで実現する設計⽅式5https://github.com/microservices-demo/microservices-demo/blob/master/internal-docs/design.md
Cloud Native Developers JPビジネスの変化に追従できる!• モノリシックアーキテクチャ– ⼤規模になると機能要素同⼠の依存関係が複雑化しがち• ⼀部の変更が全体にどう影響するか把握しにく、更新に⻑い⼯期を要する• 構成要素の単位が⼤きく、簡単にはスケールできない• Microservices– 複数の疎結合なサービス群で⼤規模なシステムを構成• 変更の影響範囲を個々のサービスに留められるため、サービス単位で⾼頻度に更新できる• 必要な構成要素に絞って素早くスケールできる6なぜ Microservices が求められているのか?Microservices はビジネスの不確実性に対処するためのアーキテクチャビジネスの変化に追従できない…!
Cloud Native Developers JPMicroservices における様々な課題• パフォーマンス– ネットワーク通信増による性能劣化• 複数サービスの協調動作– サービス同⼠を連携させる難しさ• データの⼀貫性– 分散したデータの⼀貫性の確保• モニタリング– 監視の仕組みの構築運⽤コスト増• ネットワーク起因の障害– ⼀時的な通信断や遅延の発⽣• 実装⽅式の分断– 学習コスト、保守コスト増• セキュリティ– 分散化に伴うアタックサーフェス増• 構成管理のコスト– 多数サービスの管理はコストが⾼いMicroservices の課題は多岐に渡る7
Cloud Native Developers JPMicroservices における様々な課題• パフォーマンス– ネットワーク通信増による性能劣化• 複数サービスの協調動作– サービス同⼠を連携させる難しさ• データの⼀貫性– 分散したデータの⼀貫性の確保• モニタリング– 監視の仕組みの構築運⽤コスト増• ネットワーク起因の障害– ⼀時的な通信断や遅延の発⽣• 実装⽅式の分断– 学習コスト、保守コスト増• セキュリティ– 分散化に伴うアタックサーフェス増• 構成管理のコスト– 多数サービスの管理はコストが⾼いMicroservices の課題は多岐に渡る8なんかたくさんある! >_<.
Cloud Native Developers JPまだまだあるよ…! ビルド & デプロイ戦略• ⾼頻度のリリースを⾏うためには、ビルドからデプロイまでのプロセスの⾃動化が避けて通れない (CI/CD)• ⾃動化された⾼頻度リリースのリスクを低減するための⼯夫が必要→ Blue/Green デプロイメントカナリアリリース安全な⾼頻度リリースのために必要なもの9V2CanaryV1V1CI/CDツール⾃動デプロイクライアントトラフィック1%99%【カナリーデプロイメント 】1%から始めて徐々に新バージョンへのトラフィック配分を増やす
Cloud Native Developers JPまだまだあるよ…! ビルド & デプロイ戦略• ⾼頻度のリリースを⾏うためには、ビルドからデプロイまでのプロセスの⾃動化が避けて通れない (CI/CD)• ⾃動化された⾼頻度リリースのリスクを低減するための⼯夫が必要→ Blue/Green デプロイメントカナリアリリース安全な⾼頻度リリースのために必要なもの10V2CanaryV1V1CI/CDツール⾃動デプロイクライアントトラフィック1%99%【カナリーデプロイメント 】1%から始めて徐々に新バージョンへのトラフィック配分を増やすもうこれ以上無理〜! >_<.
Cloud Native Developers JP 11⼤変だ…。⼤変だ…。もうこれ以上無理〜! >_<.なんかたくさんある! >_<.
Cloud Native Developers JP 12だれ?落ち着いて考えるのじゃ…。もうこれ以上無理〜! >_<.なんかたくさんある! >_<.
Cloud Native Developers JPMicroservices における様々な課題• パフォーマンス– ネットワーク通信増による性能劣化• 複数サービスの協調動作– サービス同⼠を連携させる難しさ• データの⼀貫性– 分散したデータの⼀貫性の確保• モニタリング– 監視の仕組みの構築運⽤コスト増• ネットワーク起因の障害– ⼀時的な通信断や遅延の発⽣• 実装⽅式の分断– 学習コスト、保守コスト増• セキュリティ– 分散化に伴うアタックサーフェス増• 構成管理のコスト– 多数サービスの管理はコストが⾼いMicroservices の課題は多岐に渡る13• TimeoutによるUX低下の軽減• ⾮同期化やキャッシュの利⽤• リーダー昇格パターンやScheduler-Agent-Supervisor• 結果整合性の担保に留める• 補正トランザクションの導⼊• サービス間通信の出⼊りを拾ってメトリクスを集める
Cloud Native Developers JPMicroservices における様々な課題• パフォーマンス– ネットワーク通信増による性能劣化• 複数サービスの協調動作– サービス同⼠を連携させる難しさ• データの⼀貫性– 分散したデータの⼀貫性の確保• モニタリング– 監視の仕組みの構築運⽤コスト増• ネットワーク起因の障害– ⼀時的な通信断や遅延の発⽣• 実装⽅式の分断– 学習コスト、保守コスト増• セキュリティ– 分散化に伴うアタックサーフェス増• 構成管理のコスト– 多数サービスの管理はコストが⾼いMicroservices の課題は多岐に渡る14• TimeoutによるUX低下の軽減• ⾮同期化やキャッシュの利⽤• リーダー昇格パターンやScheduler-Agent-Supervisor• 結果整合性の担保に留める• 補正トランザクションの導⼊• サービス間通信の出⼊りを拾ってメトリクスを集めるNetworkNetwork
Cloud Native Developers JPMicroservices における様々な課題• パフォーマンス– ネットワーク通信増による性能劣化• 複数サービスの協調動作– サービス同⼠を連携させる難しさ• データの⼀貫性– 分散したデータの⼀貫性の確保• モニタリング– 監視の仕組みの構築運⽤コスト増• ネットワーク起因の障害– ⼀時的な通信断や遅延の発⽣• 実装⽅式の分断– 学習コスト、保守コスト増• セキュリティ– 分散化に伴うアタックサーフェス増• 構成管理のコスト– 多数サービスの管理はコストが⾼いMicroservices の課題は多岐に渡る15• ⼀時的な通信断にリトライで対処• サーキットブレーカーで障害伝搬を抑制• 実装の共通化箇所を設ける(⾔語ランタイムやネットワーク層)• 通信の暗号化• 脆弱性検知の⾃動化• 外部構成ストアの利⽤
Cloud Native Developers JPMicroservices における様々な課題• パフォーマンス– ネットワーク通信増による性能劣化• 複数サービスの協調動作– サービス同⼠を連携させる難しさ• データの⼀貫性– 分散したデータの⼀貫性の確保• モニタリング– 監視の仕組みの構築運⽤コスト増• ネットワーク起因の障害– ⼀時的な通信断や遅延の発⽣• 実装⽅式の分断– 学習コスト、保守コスト増• セキュリティ– 分散化に伴うアタックサーフェス増• 構成管理のコスト– 多数サービスの管理はコストが⾼いMicroservices の課題は多岐に渡る16• ⼀時的な通信断にリトライで対処• サーキットブレーカーで障害伝搬を抑制• 実装の共通化箇所を設ける(⾔語ランタイムやネットワーク層)• 通信の暗号化• 脆弱性検知の⾃動化• 外部構成ストアの利⽤NetworkNetworkNetwork
Cloud Native Developers JPService Meshのコンセプト• Microservices の課題はたくさんあるが、ネットワークのところで対処できるものも多いらしい• ネットワークのとこに⼀層設けてそこで対策を実装したら良さそう– アプリケーションは変更不要– 共通実装は専⽤プロダクトに任せて品質アップネットワークの共通処理を委譲するレイヤー17サービスA サービスBBusiness CCC Business CCCサービスA サービスBBusiness BusinessProxyCCCProxyCCCData PlaneMicroservices + Service MeshMicroservices* CCC = Cross Cutting Concerns 共通の関⼼事Control Plane
Cloud Native Developers JP• ルーティング– L7 (Header, Path…) ベースのトラフィック配送– 1%単位の配送割合指定• 回復性– リトライ– タイムアウト– サーキットブレーカー18• モニタリング– アクセスログ– 通信状態のメトリック– 分散トレーシング• セキュリティ– SSL相互認証 (mTLS)– 認可ポリシーの適⽤Service Meshに期待される機能ネットワークレイヤーで実現可能な様々な機能を提供
Cloud Native Developers JPService Mesh が解決する課題の⼀例 – 障害の連鎖1. サービスAが依存するサービスBで障害発⽣19システムの広範囲が機能しなくなるケースも2. サービスAでサービスBの応答待ちのリクエストが累積3. 応答待ちリクエストがAのリソースを専有し、Aも停⽌4. Bへのアクセス集中が続き、Bが復旧困難に。Bに依存する他サービスもAと同様に次々停⽌A B A BA B A BCD
Cloud Native Developers JP対策 - サーキットブレーカー• サービス呼び出しに対する応答が⼀定の条件を満たした場合に、障害発⽣と判断し、以降の呼び出しを遮断する機構• 呼び出し元のサービスに早期にエラーが返されるので、呼び出し元でのリソースの専有を回避。適切なエラーにフォールバックできる• リクエストが遮断されている間に障害を起こしたサービスが回復20障害が起きたサービスを負荷から開放して素早く復旧サービス サービスサーキットブレーカーサービス サービスサーキットブレーカーerror !(1) ⼀定数のエラーを観測したらerror !(2) リクエストを遮断復旧!
Cloud Native Developers JPService Meshの基本的なアーキテクチャ 1/2• Data Plane– サービス間のトラフィックを仲介するプロキシ– 通信時にService Meshとしてのインテリジェントな機能を実⾏する• Control Plane– Data Planeを管理するコンポーネント– 各Data Planeに所定の設定を適⽤するなどの役割をもつ21https://kuma.io/docs/0.4.0/overview/what-is-kuma/Data PlaneControl Plane
Cloud Native Developers JP• Sidecar– Data Planeをサービス毎に1つ配置• Kubernetesでは各PodにSidecarコンテナとしてData Planeを封⼊する– Sidecarの数が多くなり、その分オーバーヘッドが⼤きくなる傾向• Daemon– Data Planeを各ホストに1つ配置• KubernetesではDaemonSetとしてDataPlaneをデプロイする– mTLSが実装しにくく、この機能を提供していないプロダクトがある22Service Meshの基本的なアーキテクチャ 2/2サービスA サービスAʼProxy ProxyサービスBProxyサービスA サービスAʼProxyサービスBProxy
Cloud Native Developers JPService Mesh の基本的なアーキテクチャ 3/3• Data Plane の配備– Sidecar コンテナとして各サービスのPodに封⼊されるか、DaemonSet として各Node にひとつずつデプロイされる– Sidecar ⽅式が主流• Control Plane の配備– Pod として Kubernetes 上にデプロイされる• Service Mesh への設定の適⽤– 各プロダクトの設定情報は CustomResourceDefinition の manifest として記述– kubectl を使って、通常の Kubernetes リソースと同じ感覚で適⽤できる23
Cloud Native Developers JPService Meshで対処できない課題の例• 複数のサービスに係るデータの更新に対して結果整合性を確保したいケース– データ更新が途中でエラーになったとき、正しくロールバックをかけるにはアプリケーションの知識が必要– ネットワークのレベルで⼀律な処理をかけるだけでは解決できない• 【参考】– 「マイクロサービスにおける決済トランザクション管理」• https://tech.mercari.com/entry/2019/06/07/155849– 「補正トランザクション パターン」• https://docs.microsoft.com/ja-jp/azure/architecture/patterns/compensating-transactionService 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 27Istioだけかと思いきや。Service Meshの主要プロダクト• Istio • Linkerd • Kuma• Maesh • AWS App Mesh • Consul Connect • Anthos ServiceMesh
Cloud Native Developers JPお知らせ• 以降のスライドで「Service Meshの選び⽅」という⽂⾔を含むタイトルのものは、Service Mesh Comparison (https://servicemesh.es/) のコンテンツを元にしています。28© “INNOQ” Last updated: March 10 2020
Cloud Native Developers JPService Meshの選び⽅1. 解決したい最も重要な課題を特定する2. ⾮機能要件の観点で、重視するポイントを明らかにする3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落とす5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオーバーヘッドを検証して候補を決定する当たり前のことを地道にやっていく29
Cloud Native Developers JPService Meshの選び⽅ 1/31. 解決したい最も重要な課題を特定する2. ⾮機能要件の観点で、重視するポイントを明らかにする3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落とす5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオーバーヘッドを検証して候補を決定するまずは要件を明らかにしよう30• 解きたい課題は? / それはService Meshで解決できる?• 重視する⾮機能要件は?• シンプルさ、使いやすさ• パフォーマンス• 互換性
Cloud Native Developers JPService Meshの選び⽅ 2/31. 解決したい最も重要な課題を特定する2. ⾮機能要件の観点で、重視するポイントを明らかにする3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落とす5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオーバーヘッドを検証して候補を決定する各プロダクトの特徴を把握しよう31• 次ページ以降、以下3プロダクトを紹介していきます• Istio / Linkerd / Kuma
Cloud Native Developers JPIstio• 諸元– 開発主体:– 現在の最新バージョン: 1.5.2• アーキテクチャ– EnvoyベースのData PlaneをSidecarとして封⼊して利⽤• 特徴– 最もメジャーなService Mesh。⽇本でもいくつかの事例がある– Service Meshに期待される機能を網羅的にカバー– 1.5.xから多数のコンポーネントからなるControl Planeを少数のバイナリに統合するなど、運⽤しやすさを⾼める⽅向の進化に進みつつあるド定番。今最もメジャーなService Mesh32
Cloud Native Developers JPLinkerd• 諸元– 開発主体: Buoyant– 現在の最新バージョン: 2.7.1• アーキテクチャ– Rustで実装された独⾃のData PlaneをSidecarとして封⼊して利⽤• 特徴– CNCFでホストされる唯⼀のService Mesh。Istioについでメジャー– Service Meshに期待される機能の多くを実装– 独⾃のData Planeによる⾼性能を売りにしている。実際いくつかのベンチマーク例ではIstioよりも⾼性能な成績を出している– 設定の記述が⽐較的シンプルなのも特徴パフォーマンスに優れた CNCF Project で唯⼀の Service Mesh33
Cloud Native Developers JPKuma• 諸元– 開発主体: Kong– 現在の最新バージョン: 0.4.0• アーキテクチャ– EnvoyベースのData PlaneをSidecarとして封⼊して利⽤• 特徴– 実現している機能は少なめだが、Envoyの形式の設定情報をそのままData Planeに配布する機能があり、これによって⾃由度を確保している– ひとつのControl Planeで複数のメッシュを定義・管理し易い。マルチテナントのユースケースで⾼い運⽤性を発揮しそう– Kubernetes以外の環境でのユースケースを他に⽐べ強く打ち出している(後述)シンプルで使いやすさに優れた新興プロダクト34
Cloud Native Developers JPKubernetes 以外の環境での活⽤例• Kubermetes以外の環境(VMなど)にも⽤意に適⽤可能なことを⽣かして、アーキテクチャの変更前あらService Meshを適⽤する• モニタリングや安全なデプロイ⼿法を使ってリスクを低減しつつ、アーキテクチャの変更を進めるService Meshを最初に適⽤してから安全にMicroservicesに移⾏する35https://kuma.io/docs/0.4.0/overview/vm-and-k8s-support/
Cloud Native Developers JPService Meshの選び⽅ 3/31. 解決したい最も重要な課題を特定する2. ⾮機能要件の観点で、重視するポイントを明らかにする3. 各プロダクトのもつ機能と特徴から、2, 3個 の候補に絞る4. 各プロダクトのチュートリアルを試す。可能であれば候補を1つ落とす5. ⾃分のアプリケーションで、レイテンシとリソースに与えるオーバーヘッドを検証して候補を決定する候補のプロダクトを検証して最終決定しよう36• 最後は検証。コレばっかりは避けられない
Cloud Native Developers JPDemo というほどでもないですが…。• 各プロダクトのmanifestの感じを⾒てみます。37
Cloud Native Developers JPService 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 JPService 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 のとして仕様を定義。複数種のServiceMesh の相互運⽤、互換性を⽬指す– CNCF Sandbox プロジェクト41Service Mesh の新たな⽅向性この後のセッションでご紹介
Cloud Native Developers JPまとめ• Microservices には様々な課題がある• Microservices の課題のうち、ネットワークレイヤーで対処可能なものの多くを、Service Mesh が解決してくれる• Service Mesh のプロダクトを選択するのは簡単ではない– 要件を明らかにしたうえで、実際に検証して選択する。王道かつ地道な選定⽅法にしたがおう42
Cloud Native Developers JPFin.43
Cloud Native Developers JPAppendix.参考⽂献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/111810105345
Cloud Native Developers JP【参考⽂献 2/2】「いらすとや」さんのイラスト• 落ち込む会社員たちのイラスト• バンザイをしている会社員たちのイラスト• 燃え尽きた⼈のイラスト(男性会社員)• インターネットの神様のイラスト• 交通整理をしている⼈のイラスト• ストーカーのイラスト(男性被害者)• 復職を考えている⼈のイラスト• 電鍵のイラスト46