$30 off During Our Annual Pro Sale. View Details »

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

hhiroshell
April 28, 2020

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

#cndjp 第14回勉強会 「ウイルスに負けるな!cndjp春のService Mesh祭り!」の発表資料です。
https://cnd.connpass.com/event/170826/

hhiroshell

April 28, 2020
Tweet

More Decks by hhiroshell

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    ⼤規模なシステムを疎結合な複数のサービスの組み合わせで実現する設計⽅式
    5
    https://github.com/microservices-demo/microservices-demo/blob/master/internal-docs/design.md

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. 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

    View Slide

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

    View Slide

  19. 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

    View Slide

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

    View Slide

  21. 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

    View Slide

  22. 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

    View Slide

  23. 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

    View Slide

  24. 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
    補正ロジック


    補正データ
    補正データ
    補正データ
    補正データ

    !




    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. 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

    View Slide

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

    View Slide

  35. 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/

    View Slide

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

    View Slide

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

    View Slide

  38. 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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  43. Cloud Native Developers JP
    Fin.
    43

    View Slide

  44. Cloud Native Developers JP
    Appendix.
    参考⽂献
    44

    View Slide

  45. 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

    View Slide

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

    View Slide