今だから改めて知っておきたいService Meshの世界 / Welcome to the Service Mesh world.

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

View Slide

宣伝
• 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
登壇
• ⾃作キーボード沼

View Slide

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

View Slide

⽬次
4

View Slide

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

View Slide

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

View Slide

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

View Slide

8
なんかたくさん
ある！ >_

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

13
• TimeoutによるUX低下の軽減
• ⾮同期化やキャッシュの利⽤
• リーダー昇格パターンや
Scheduler-Agent-Supervisor
• 結果整合性の担保に留める
• 補正トランザクションの導⼊
• サービス間通信の出⼊りを拾って
メトリクスを集める

View Slide

14
• TimeoutによるUX低下の軽減
• ⾮同期化やキャッシュの利⽤
• リーダー昇格パターンや
Scheduler-Agent-Supervisor
• 結果整合性の担保に留める
• 補正トランザクションの導⼊
• サービス間通信の出⼊りを拾って
メトリクスを集める
Network
Network

View Slide

15
• ⼀時的な通信断にリトライで対処
• サーキットブレーカーで障害伝搬を抑制
• 実装の共通化箇所を設ける
（⾔語ランタイムやネットワーク層）
• 通信の暗号化
• 脆弱性検知の⾃動化
• 外部構成ストアの利⽤

View Slide

16
• ⼀時的な通信断にリトライで対処
• サーキットブレーカーで障害伝搬を抑制
• 実装の共通化箇所を設ける
（⾔語ランタイムやネットワーク層）
• 通信の暗号化
• 脆弱性検知の⾃動化
• 外部構成ストアの利⽤
Network
Network
Network

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

• 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

View Slide

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

View Slide

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
補正ロジック
更
新
補正データ
補正データ
補正データ
補正データ
ロ
!
ル
バ
ッ
ク

View Slide

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

View Slide

⽬次
26

View Slide

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

View Slide

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

View Slide

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

View Slide

Service Meshの選び⽅ 1/3
とす
まずは要件を明らかにしよう
30
• 解きたい課題は？ / それはService Meshで解決できる？
• 重視する⾮機能要件は？
• シンプルさ、使いやすさ
• 互換性

View Slide

とす
各プロダクトの特徴を把握しよう
31
• 次ページ以降、以下3プロダクトを紹介していきます
• Istio / Linkerd / Kuma

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

とす
候補のプロダクトを検証して最終決定しよう
36
• 最後は検証。コレばっかりは避けられない

View Slide

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

View Slide

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

View Slide

⽬次
39

View Slide

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

View Slide

• 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 の新たな⽅向性
この後のセッションでご紹介

View Slide

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

View Slide

Fin.
43

View Slide

Appendix.
参考⽂献
44

View Slide

【参考⽂献 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

View Slide

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

View Slide

今だから改めて知っておきたいService Meshの世界 / Welcome to the Service Mesh world.

今だから改めて知っておきたいService Meshの世界 / Welcome to the Service Mesh world.

hhiroshell

More Decks by hhiroshell

Other Decks in Technology

Featured

Transcript