サービスメッシュを用いたマイクロサービス型分散システムの運用管理/servicemesh in hitachi

© Hitachi, Ltd. 2022. All rights reserved.
サービスメッシュを用いた
マイクロサービス型分散システムの運用管理
電子情報通信学会 ICM研究会
井出貴也、藪崎仁史
Services Computing Research Dept.
Center for Digital Service - Digital Platform Center
Research & Development Group, Hitachi, Ltd.
Nov 25, 2022

View Slide

内容
1. Service Meshとは
▪ ビジネス背景
▪ Microservice Architecture
▪ Service Meshのアイデア
2. 日立におけるService Mesh活用の取り組み
▪ 社内システムへのService Meshの適用
▪ Observability(監視)
▪ セキュリティ管理
1

View Slide

1. Service Meshとは
2

View Slide

昨今のビジネス環境におけるシステムのあり方
▪ 昨今のビジネス環境は不透明で変化も早い
▪ フィードバックループを素早く回し、顧客ニーズや市場動向に適合 → 市場競争力を確保
▪ 変化に対応しやすいシステムが求められる
3
▪ 顧客ニーズの多様化
▪ 高速な技術進歩
▪ 競合の動向
ビジネス環境
企画
開発
リリース
運用
フィード
バック
ソフトウェア
ライフサイクル
市場投入
反応

View Slide

Microservice Architecture
▪ 機能ごとに独立した小さなサービスを疎に連携させてシステムを構成する設計方式
▪ 各サービスを小規模チームが自律的に開発・運用 → 変化に対応しやすい
4
Microservices Architecture
UI
決済
商品
推薦
注文
管理
商品
管理
ユーザ
管理
発注
決済サービス
チーム
発注サービス
チーム
▪ 利点
◇ 意思決定しやすい
◇ デプロイやテストが独立
◇ 仕様の自由度が高い
◇ 開発規模を広げやすい

View Slide

Microservicesの成長
ビジネスの成長に伴いシステムは大きくなる
◇ サービスやチームが増加し、
◇ それぞれのサービスも随時変化
◇ サービスの開発言語や品質も様々
5

View Slide

Microservicesの運用
Microservicesをどのように運用するか？
◇ 通信の暗号化やアクセス制御は？
◇ 相手先サービスが落ちていた場合の対応は？
◇ システム全体の可視化は？
◇ この数のサービスに対し、個別に運用機能を実装？
6

View Slide

Microservices運用の模索
システム全体で一貫性のある管理がしたい
◇ サービスごとに仕様がばらばらだと運用がスケールしない
各サービスからは透過的に機能を付与したい
◇ サービスのコードを改修するにはコストがかかる
◇ サービス間の独立性が失われる
サービス間の通信を利用できないか
7

View Slide

Service Meshのアイデア
各サービスは通信で連携している
→
→
8
Svc1 Svc2
サービス間通信
運用者

View Slide

→ サービスの前段に配置したProxyで、サービス間通信を中継・制御し、運用機能を適用
→
9
Proxy Proxy
Svc1 Svc2
宛先の変更
通信暗号化
アクセス制御
メトリクス出力
運用者

View Slide

→ サービスの前段に配置したProxyで、サービス間通信を中継・制御し、運用機能を適用
→ 多量に出てくるProxyはControl Planeで一元管理
10
Proxy Proxy
Svc1 Svc2
宛先の変更
通信暗号化
アクセス制御
運用者
Control
Plane
制御
操作

View Slide

各サービスの前段に配置したProxyをControl Planeで制御するネットワークモデル
Service Meshとは
11
嬉しさ
システム全体で一貫性の
ある運用機能をサービスへ
透過的に付与できる
主要機能
▪ トラフィック制御
▪ 信頼性向上
▪ Observability(監視)
▪ セキュリティ管理
Service Mesh
Proxy
(Data Plane※)
Proxy
(Data Plane)
Svc1 Svc2
宛先の変更
通信暗号化
アクセス制御
運用者
Control
Plane
制御
操作
※ ProxyはData Planeとも呼称

View Slide

2.日立におけるService Mesh活用の取り組み
12

View Slide

日立の取り組み
2018年より、社内外プロジェクトへのService Meshの適用や機能開発を実施
以下の取り組みを紹介
1. 社内システムへのService Meshの適用
2. Service Meshを用いたObservability(監視)
3. Service Meshを用いたセキュリティ管理
13

View Slide

3.1. 社内システムへのService Meshの適用
14

View Slide

対象システム
▪ 社内の開発者向けに開発環境を提供するサービス
◇ Webエディタやバックエンドサービスを提供
◇ バックエンドサービスはそれぞれ自律的に開発が進行
▪ Kubernetesベースのシステム。100+ Nodes、 2000+ Pods
15
Kubernetes
App
App
開発・実行
社内開発者
(ユーザ)
Service1
開発チーム
Service2
開発チーム
基盤チーム
開発
全体の
運用
開発
Service
1
Service
2
Web
Editor

View Slide

Service Mesh導入のモチベーション
1. サービス間通信を管理したい
◇ 動的ルーティング、信頼性向上
◇ 通信の暗号化やアクセス制御
◇ ログ・メトリクスの収集
2. 各サービスの内部には干渉したくない
3. Istioのトレンドが急浮上
16
OSSのService MeshであるIstioを
検証も兼ねて導入。本番環境で2年運用
開発
社内開発者
ユーザ
開発チーム
開発チーム
基盤チーム
開発
の
運用
開発

View Slide

Service Mesh活用の結果
一通りの機能要件を実現し、サービスのコードから運用ポリシーを分離
▪ ルーティング、通信暗号化、認証認可、信頼性向上など
▪ 開発・運用チーム間でのコミュニケーションコスト低減
▪ マニフェストに基づく宣言的な構成管理が有用
一方、Service Meshそのものの運用コストが問題化
▪ システム自体はService Meshというレイヤが追加され複雑化
▪ 2018年当時のIstioは未成熟、かつ運用プラクティスもない
▪ 出てきた課題を研究所と運用チームで都度解決
→ 以降で紹介
17

View Slide

課題1 Service Mesh操作の境界の確立
Service Meshはアプリとインフラの両方に影響 → 開発・運用者間の調整要
操作権限の管理
▪ クラスタ全体に適用される機能をサービスチームが自由に操作 → クラスタ障害
▪ 一方でルーティングやTimeout等の設定はサービスチームに任せたい
▪ 単一リソース内の特定設定のみの制限が必要 → Kubernetes機能では対応不可
サービスチーム側でのIstio機能の自律的な取捨選択
▪ Retry、Timeout、HTTPS終端などの機能はサービス側にもIstio側にも存在
▪ 無理な機能の押し付けはサービスチームの反発をまねく
▪ 「HTTPSが前提のOSSを使っているから、ProxyでHTTPS終端しないで」
18

View Slide

解決策1 Istio操作のパッケージ化
Istioの設定をHelm Chart※としてパッケージ化し、サービスチームに提供
▪ 直接的なIstio操作を阻止
▪ サービスチームに操作してほしい機能のみを設定項目に切り出す
▪ サービスチームは自分の使いたい機能をHelmを介して設定
結果
▪ 危険な操作を防止するガードレール兼、学習コスト低減として作用
▪ 現在はOpen Policy Agentなどのポリシー制御も有効と思われる
19
※Helm Chart：
Kubernetes向けの
設定配布用パッケージ

View Slide

課題2 Proxyのメモリ管理
IstioのProxyはどのように宛先を把握しているか？
▪ Control Planeにて宛先リストを作成し、全Proxyに配布
▪ 宛先リストは各Proxyのメモリに格納される
▪ 宛先が増えるとリストが肥大化(現在は解決策あり)
当時何が起きたか
▪ 各Proxyが750MBのメモリを消費 (現在は大幅に改善)
▪ メモリを750MB消費するPodが数千個もある
→ OOM KillerでPodやNodeが落ちる
▪ 更にリソース消費傾向はIstioのバージョンごとに変化
20

View Slide

解決策2 性能評価ツール「istio-bench」の開発
istio-benchにてメモリ消費量を予測し、事前にリソースを確保する
▪ Istioのメモリ消費の仕組みを分析し、ベンチマークツールを開発
▪ サンドボックス環境でメモリ消費傾向を把握し、予測を立てる
▪ 本ツールはOSSとして公開(https://github.com/Hitachi/istio-bench)
21

View Slide

(参考) IstioProxyのメモリ消費量の変遷
22
▪ 1000Podのときの各Proxyのメモリ消費量をistio-benchで計測
▪ v1.0時代に急激に削減。1.5.0での増加はTelemetry v2※1の影響か
※1. メトリクス情報をProxyから収集可能にする仕様
771MB
268MB
163MB
145MB 127MB 120MB 163MB 163MB
0
200
400
600
800
1000
1.0.2 1.0.7 1.1.7 1.2.9 1.3.2 1.4.5 1.5.0 1.6.2
Memory usage[MB]
Istio version

View Slide

課題3 運用難度の低減
Istioは通信制御, 認証認可, 監視の機能を集約
▪ 高い自由度、無数の設定ファイル(現在は自動化や簡略化により大きく改善)
▪ 送信側と受信側での認証設定などの整合性担保に苦労
▪ 運用に辺り覚えることが多く、属人化しやすい
障害時の原因切り分けに工数が取られる
▪ 障害には物理、仮想化、Kubernetes、Istio、Appなど様々な要因が絡む
▪ ProxyのTimeoutで障害が顕在化するため、Istioが疑われやすい
◇ 通信先のアプリが落ちた → Proxyがタイムアウトを返す
◇ 通信先でネットワーク障害 → Proxyがタイムアウトを返す
23

View Slide

解決策3 社内Istio情報共有Wikiの整備
運用チーム内で社内Wikiを整備
▪ 前述のHelm Chart化もあわせ
属人化を抑止
コンテンツ
▪ Istioの概要
▪ 挙動調査結果
▪ よくあるエラーとその原因
▪ デバッグ方法
▪ etc.
24

View Slide

知見：Istio導入可否の検討
▪ Istioは大きなシステム。簡単に抜き差しできるものではない
▪ 利点が懸念点を上回るか、自分にユースケース※1が当てはまるか事前に検討すること
25
▪ アプリ改修なしに、システム全体へ
一貫性のあるポリシーを適用
▪ 多くの機能、高い品質
◇ サービスレベル監視
◇ 動的な通信制御
◇ 通信暗号化や認証認可
◇ VM連携
▪ 活発な開発、etc.
▪ Service Meshレイヤー追加
によるシステム複雑化
▪ 多数の機能に対する学習コスト
▪ Istio本体の管理コスト
▪ 消費リソースの増加
▪ 2-10msの通信遅延
▪ Kubernetesへのロックイン
▪ 3~6ヶ月単位のアップデート、etc.
※1 便利なユースケース集
Megan O’Keefe, “Istio by Example!”, https://www.istiobyexample.dev/, Istio公式ドキュメント, https://istio.io/latest/docs/tasks/
利点懸念点

View Slide

(参考) Service Meshを活用する前提条件
Service Meshに至るまでにいくつか前提段階があると考えられる (定義・用語は独自)
26
段階達成されるべき要件
Business Level
継続的なサービスの更新、アジリティと品質の両立
運用設計（SLA設計、定期バージョンアップ、監視など）
組織体制（DevOps、開発者が運用に参加する、など）
Design Level
12 Factor App、イミュータブル、自動化、疎結合
API連携、Container-Native、CI/CD、バージョン管理
Platform Level
無停止アップデート、Graceful Shutdown(ユーザセッション追出し等)
セルフ・ヒーリング、データ永続化、スケール管理
Service Mesh Level
L7レベルのトラフィック制御、負荷分散
回復力向上（リトライ制御、タイムアウト、サーキットB）
デプロイ戦略（B/Gデプロイ、カナリアリリース、A/Bテスト）
透過的なObservability（メトリクス、トレース、ログ）
セキュリティ（mTLS、L7アクセス制御）
VM連携、マルチクラスタ連携
前
提

View Slide

3.2. Service Meshを用いたObservability
27

View Slide

Observabilityとは？ ※1
28
※1. 現状ソフトウェア分野ではObservabilityの合意された定義は存在せず、解釈の一例
データをもとに、システム内部で何が・何故起きているか把握できる状態にすること
▪ 複雑かつ頻繁に変化するシステムの運用では、未知の問題をもぐら叩きのように対処する
▪ 未知の現象を対処する能力を得る → 監視やテストを通したObservabilityの実現
Testing
Debugging
Monitoring
状態実現手段
Observability
Tracing
Logging
Metrics
Profiling
Test
Events Analyzing
Chaos Eng.
Simulating
etc.

View Slide

▪ Service Meshを活用したObservability基盤の構築
▪ アプリ透過型の分散トレーシング方式策定
→ 以降それぞれ紹介
29

View Slide

Service Meshを活用したObservability基盤
▪ Service Meshを用いてアプリのコードを改修することなくObservabilityを実現したい
▪ Service Meshで取得可能なデータの整理や各種監視ツールとの連携・運用方法の確立要
30
▪ スループット
▪ 応答時間
▪ エラー率
▪ アクセスログ
▪ トレーシング
▪ etc.
…
Kubernetes
アプリ
監視ツール
(Prometheus等)
アプリ
Proxy Proxy
レスポンス
リクエスト
レス時刻 – リク時刻
→ 応答時間

View Slide

Observability基盤の参照実装の構築
▪ Service Meshを用いてメトリクス、ログ、分散トレースを取得・可視化する基盤を構築
▪ 研究チーム内での継続的な運用と改修を通して日々知見の蓄積
31
K8s metrics
Prometheus
Operator
Jaeger
Operator
Container log
Logs
Metrics
Logs
Istio
Operator
ダッシュボード
監視ツール
Istio Operator
監視データ
アプリ
Grafana
Operator
Istio
status
Trace data
Access log
Traffic
metrics
Trace data
Logs
Jaeger
Application
UI
Proxy
Grafana
Prometheus
Loki
Control Plane
Promtail
Kubernetes
Kiali
Kiali
Operator
App1
Proxy
App2
Proxy
DB
Proxy
Metrics
Istio manifests
Throughput Error Rate Latency
Metrics
Trace
Log

View Slide

Observability基盤の構築・運用を通した知見
段階的な監視の導入
▪ 最初はメトリクスだけで良い。最初から色々あっても使いこなせない
▪ その後、ログ→トレース。トレースは導入コストが大きいため、必要性を感じてからの導入で良い
構成管理の状態の統一
▪ 監視基盤を構成する多数のOSSを個別に管理していては工数が破綻。一貫性を持たせる
▪ 監視ツールの構成はKubernetesのManifestで統一し、GitOpsで環境に導入
◇ HelmやCLIでインストールするOSSもManifestに変換して保持する
更新の自動化
▪ 手動での更新に工数が取られる → 更新しなくなる
▪ makefile等でリポジトリからのOSS取得からManifest化までを自動化し、CIに組み込む
32
(次のページからは別の内容)

View Slide

機能開発：透過的な分散トレーシングに向けた方式検討
▪ 分散トレーシング：複数サービスを跨った一連の処理の流れを追う手法
◇ ボトルネック分析やデバッグに活用される
▪ トラフィックにTraceIDなどのタグ情報を付与し、その流れを追うことで実現
33
リクエスト
トレース情報
の計測と送付
TraceID:123 TraceID:123
Frontend
app
Proxy proxy
Order
app
監視サーバ
TraceID
の伝播
トレース情報
TraceID
の付与
ユーザ
分散トレーシングの挙動分散トレーシングの可視化(Grafana)

View Slide

分散トレーシングの課題
課題：Service Meshのみでの分散トレーシングの実現
▪ 現状はアプリ側でのTraceID伝播処理の実装が必須
▪ トラフィックの伝播はアプリのロジックに依存し、対応関係がプロキシには判断できないため
34
リクエスト TraceID:123 TraceID:123
Frontend
app
Proxy proxy
Order
app
監視サーバ
TraceIDの伝播
はアプリ側で
のみ実施可能
トレース情報
▪ 商品ごとにデータ取得先が異なる
▪ ユーザごとに後続処理の
呼出可否が異なる
▪ 極論. 内部乱数で伝播先を変化
アプリロジックに依存する
トラフィックの伝播の例

View Slide

先行研究
Pivot Tracing
Mace, Jonathan, Ryan Roelke, and Rodrigo Fonseca. “Pivot tracing: Dynamic causal monitoring for distributed systems.”
ACM Transactions on Computer Systems (TOCS) 35.4, 1-28, 2018
▪ Javaの中間コードやPythonスクリプトなどを動的に書き換え、TraceIDの伝播処理を埋め込む
▪ 分散トレーシングの標準手法であるOpen Telemetryにも採用
▪ 課題：GoやRust等のバイナリを出力する言語への対応
Taintgrind
W. M. Khoo. “Taintgrind” https://github.com/wmkhoo/taintgrind
▪ スパイウェアの検出ツール
▪ Assembly等のレベルでアプリ内の変数にタグ情報を付け、その流れを追う
▪ 課題：アプリの処理速度への影響低減
35

View Slide

提案手法
▪ 通信パターンを解析し、受信と送信の対応付けが可能な場合はTraceIDを伝播
◇ 通信パターンのみでの対応付けが不可能な場合は、エラーを返す（救えるもののみ救う）
▪ 今後：本方式で対応可能な範囲の評価、ヒント情報による対応パターンの増加
36
Traffic/Syscall
Monitor (eBPF)
Pattern
Analyzer
Proxy App
Kernel space User space
通信情報システムコール計測データ
送受対応付け情報
受/送信リクエストの
対応付けが可能な
パターンか判定
対応付け情報に従い
送信リクエストへ
TraceIDを伝播
送信
受信
種類プロセスID スレッドID 送信元宛先
受信 123 1 A B
送信 123 1 B C
送信 123 1 B D
受信 123 2 A B
送信 123 2 B C
送信 123 2 B D
受信 123 1 A B
送信 123 1 B C
送信 123 1 B D
周期性を判定
トラフィック情報からの受/送信リクエストの対応付け
5tupleや
ストリームIDから
リクエストの
一意性を判定
周期内の順序が
受信1個に対し送
信N個がある構成
なら対応付けOK

View Slide

3.3. Service Meshを用いたセキュリティ管理
37

View Slide

▪ Microservicesのセキュリティ戦略の整理と参照実装の構築
▪ Service Meshを用いた認証ゲートウェイ Auth Gatewayの開発
→ 以降それぞれ紹介
38

View Slide

Microservicesのセキュリティ戦略の整理と参照実装の構築
▪ NIST SP800-204 Security Strategies for Microservices-based Application Systems
をベースにMicroservicesのセキュリティ戦略を整理
▪ Istioにてセキュリティ戦略を実現するための参照実装を構築（認証認可、暗号化、OPA連携など）
39
分類目的セキュリティ戦略概要
通信の保護と
認証・認可
不正アクセス
防止
通信暗号化 TLSを用いて通信が暗号化されている
サービス間認証マイクロサービスのインスタンス同士が相互に正当性を確認し合う
ユーザ認証検証可能なトークンを用い、ユーザの正当性を確認する
アクセス(認可)制御トラフィックの属性に基づきサービスへのアクセス可否を判断する
Ingress/Egress通信管理外部からの流入・流出トラフィックを管理する
回復力と
耐障害性
可用性の担保
ロードバランサー死活監視と連携させ、トラフィックの負荷を複数インスタンスに分散
流量制御アプリとインフラの要件に基づき単位時間あたりアクセス上限を設ける
サーキットブレーカー障害中のインスタンスへのアクセスを遮断し、障害の波及を抑止する
リトライ・タイムアウトエラー時のリトライ制御とハングアップ時のタイムアウトを設ける
セキュリティ
監視
攻撃の検知
メトリクス収集スループット、エラー率、レイテンシをベースライン監視する
ログ収集エラーやクラッシュ時のログ・ダンプを確保する
トレース収集複数インスタンスを跨ぐリクエストのトランザクションを確保する
権限の最小化被害局所化
コンテナの特権排除 Rootユーザやsudoの利用などを禁止する
サービスメッシュ操作権の制限操作権限をサービス単位やNamespace単位で払い出す
## 全プロキシを mTLS 以外受け付けなくさせる
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: mtls-strict-all
## istio-systemにデプロイすると全Namespaceに適用
namespace: istio-system
spec:
mtls:
mode: STRICT
---
## accessTo:legacy ラベルが付いたプロキシのみ平文を許容
kind: PeerAuthentication
metadata:
name: "access-to-legacy"
namespace: default
spec:
selector:
matchLabels:
accessTo: legacy
mtls:
mode: PERMISSIVE
Microservicesのセキュリティ戦略(ネットワークレイヤのみ)
## User Serviceまたは監視系からのアクセスのみ許可する
kind: AuthorizationPolicy
metadata:
name: user-db-allow-only-user-service
namespace: default
spec:
selector:
matchLabels:
name: user-db
action: ALLOW
rules:
# user ServiceAccountからの任意アクセスを許可
- from:
- source:
principals:
- "cluster.local/ns/default/sa/user"
# メトリクス収集のため、監視系へのGETリクエストは一様に許可
- to:
- operation:
methods: ["GET"]
ports: ["15020"] # メトリクス出力ポート

View Slide

Service Meshを用いた認証ゲートウェイ Auth Gatewayの開発
▪ Service Meshはサービス間認証に強いが、ユーザ認証は独自に環境を構築する必要あり
▪ Keycloak等とIstioを連携させたアプリ透過型のユーザ認証ゲートウェイAuth Gatewayを開発
(OSSとして公開予定)
40
Istioの認証認可機能 (Oは機能あり)
サービス間
認証
ユーザ認証
トークン発
◯
相互TLS
✕
アプリ側での
実装要
トークン
ローテート
◯
自動ローテート
✕
アプリ側での
実装要
トークン検証
◯
相互TLS
◯
JWT検証
アクセス制御
◯
属性ベース制御
◯
属性ベース制御
Auth Gatewayのアーキテクチャ (実態はHelm Chart)

View Slide

4. まとめ
41

View Slide

まとめ
Service Meshとは
▪ Proxyを活用したネットワークモデル
▪ 各サービスからは透過的、かつシステム全体で一貫した運用を行う
日立でのService Mesh活用の取り組みを紹介
1. 社内システムへのService Meshの適用
2. Service Meshを用いたObservability(監視)
3. Service Meshを用いたセキュリティ管理
42

View Slide

参考文献
1. A. Venkatraman and C. Arend, “Architecting a Next-Gen Hybrid Cloud
to Support Digital Resilience in 2021 and Beyond” IDC, 2021
2. W. Li, Y. Lemieux, J. Gao, Z. Zhao, Y. Han, “Service Mesh: Challenges,
State of the Art, and Future Research Opportunities,” 2019 IEEE
International Conference on Service-Oriented System Engineering
(SOSE), pp. 122-1225, 2019
3. “Istio”, https://github.com/istio/istio (参照2022/10/26)
4. “Linkerd2”, https://github.com/linkerd/linkerd2 (参照2022/10/26)
5. “CNCF Service Mesh Micro Survey 2022”
Cloud Native Computing Foundation, 2022
6. “Service Mesh Comparison” INFOQ, https://servicemesh.es/
(参照2022/10/26)
7. 井出貴也 “1年間のシステム運用を通して分かったIstioの嬉しさと活用における
注意点”, Cloud Native Days Kansai, 2019
8. “Helm” https://github.com/helm/helm (参照2022/10/26)
9. 井出貴也, “Istio-Bench” https://github.com/Hitachi/istio-bench
(参照2022/10/26)
10. Beyer, Betsy, et al. “Site reliability engineering: How Google runs
production systems” O'Reilly Media,Inc., Ch.6. Sec.6, 2016
11. 井出貴也 “Istioを活用したObservability基盤の構築と運用”,
Cloud Native Days Spring 2021 Online, 2021
12. Mace, Jonathan, Ryan Roelke, and Rodrigo Fonseca.
“Pivot tracing: Dynamic causal monitoring for distributed systems.”
ACM Transactions on Computer Systems (TOCS) 35.4, 1-28, 2018
13. W. M. Khoo. “Taintgrind” https://github.com/wmkhoo/taintgrind
(参照2022/10/26)
14. Chandramouli, Ramaswamy. “Microservices-based application
systems.” NIST Special Publication 800.204, 2019
15. Chandramouli, Ramaswamy, and Zack Butcher. “Building secure
microservices-based applications using service-mesh architecture.”
NIST Special Publication 800.204A, 2020
16. 井出貴也 “Istioを活用したセキュアなマイクロサービスの実現”,
Cloud Native Security Conference, 2022
17. “Open Policy Agent”, https://github.com/open-policy-agent/opa
(参照2022/10/26)
18. “Keycloak”, https://github.com/keycloak/keycloak (参照2022/10/26)
19. “OAuth2 Proxy” https://github.com/oauth2-proxy/oauth2-proxy
(参照2022/10/26)
20. “eBPF”, https://ebpf.io/ (参照2022/10/26)
21. “Cilium”, https://github.com/cilium/cilium (参照2022/10/26)
22. “Introducing Ambient Mesh”, Istio,
https://istio.io/latest/blog/2022/introducing-ambient-mesh
(参照 2022/10/26)
43

View Slide

商標
▪ Istio、Kubernetes、Helm、Open Policy AgentはThe Linux Foundationの
米国またはその他の国における登録商標または商標です
▪ Keycloakは、 Red Hat, Inc.の米国またはその他の国における登録商標または商標です
▪ OAuth2 Proxyは、OAuth2 Proxyの米国またはその他の国における登録商標または商標です
▪ NISTは、National Institute of Standards and Technology U.S. Department of Commerceの
米国またはその他の国における登録商標または商標です
▪ その他記載の会社名、製品名、サービス名、その他固有名詞は、
それぞれの会社の商標または登録商標です
▪ 本発表中の文章、図では、TM、🄬マークは表記しておりません。
44

View Slide

View Slide

サービスメッシュを用いたマイクロサービス型分散システムの運用管理/servicemesh in hitachi

サービスメッシュを用いたマイクロサービス型分散システムの運用管理/servicemesh in hitachi

id

More Decks by id

Other Decks in Research

Featured

Transcript