Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
今だから改めて知っておきたいService Meshの世界 / Welcome to the ...
Search
hhiroshell
April 28, 2020
Technology
8
2.2k
今だから改めて知っておきたいService Meshの世界 / Welcome to the Service Mesh world.
#cndjp 第14回勉強会 「ウイルスに負けるな!cndjp春のService Mesh祭り!」の発表資料です。
https://cnd.connpass.com/event/170826/
hhiroshell
April 28, 2020
Tweet
Share
More Decks by hhiroshell
See All by hhiroshell
LINEヤフーにおける超大規模プラットフォーム実現への挑戦と学び / Challenges and Lessons in Building an Ultra-Large-Scale Platform at LY Corporation
hhiroshell
3
1.1k
Architecting Kubernetes-Based Internal Developer Platforms: Essential Patterns and Practices
hhiroshell
0
87
Discover Your Tailored Platform Strategy with Real-World Practice
hhiroshell
1
200
Kubernetesでアプリの安定稼働と高頻度のアップデートを両立するためのプラクティス / Best Practices for Applications on Kubernetesto Achieve Both Frequent Updates and Stability
hhiroshell
10
3.8k
Platform EngineeringにおけるKubernetesの活用法とLINEヤフーにおける事例のご紹介 / Platform Engineering and Kubernetes Findy Lunch LT Edition
hhiroshell
7
1.7k
大規模Webアプリケーションプラットフォームを開発して軌道に乗るまでにやったこと / How to Put Platforms on Track
hhiroshell
2
2.5k
Kubernetesとカスタムコントローラーを活用したプラットフォーム開発・運用の勘所 / Platform Engineering and Kubernetes
hhiroshell
1
1.2k
Best Practices for Applications on Kubernetesto Achieve Both Frequent Updates and Stability
hhiroshell
3
680
Cloud Native Developers JP (cndjp) のご紹介 / about cndjp
hhiroshell
0
200
Other Decks in Technology
See All in Technology
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
0
260
属人化したE2E自動テストを ひも解く
honamin09
1
110
振る舞い駆動開発(BDD)における、テスト自動化の前に大切にしていること #stac2024 / BDD formulation
nihonbuson
3
960
LangChainとSupabaseを活用して、RAGを実装してみた
atsushii
0
160
「品質とスピードはトレード・オンできる」に向き合い続けた2年半を振り返る / Quality and speed can be traded on.
mii3king
0
660
ドメインロジックで考えるテスタビリティ
leveragestech
1
280
WED Company Deck for Engineer
wed
2
3.7k
論理レプリケーションを使ったDB統合
kkato1
0
310
まだチケットを手動で書いてるの?!GitHub Actionsと生成AIでチケットの作成を自動化してみた話 / 20241207 Yoshinori Katayama
shift_evolve
1
770
Advancing the 3D Geospatial Ecosystem in Japan via Global Collaborations
osgeojp
0
170
Reliability Engineering at Studist
katsuhisa91
PRO
0
120
40歲的我會給20歲的自己,關於軟體開發的7個建議
line_developers_tw
PRO
0
2.4k
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
The Invisible Side of Design
smashingmag
298
50k
Speed Design
sergeychernyshev
25
650
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Side Projects
sachag
452
42k
Embracing the Ebb and Flow
colly
84
4.5k
Done Done
chrislema
181
16k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Making the Leap to Tech Lead
cromwellryan
133
9k
How to Ace a Technical Interview
jacobian
276
23k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Transcript
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