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

電子情報通信学会 ICM研究会 2022 招待講演
---
サービスメッシュの概要および日立の取り組みとして以下を紹介します。

1. 社内システムへのService Meshの適用
2. Service Meshを用いたObservability(監視)
- Observability基盤の構築
- 透過的な分散トレーシングに向けた方式検討
3. Service Meshを用いたセキュリティ管理
- Microservicesのセキュリティ戦略の整理と参照実装の構築
- Service Meshを用いた認証ゲートウェイ Auth Gatewayの開発

Transcript

1. © 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
2. © Hitachi, Ltd. 2022. All rights reserved. 内容 1. Service Meshとは ▪ ビジネス背景 ▪ Microservice Architecture ▪ Service Meshのアイデア 2. 日立におけるService Mesh活用の取り組み ▪ 社内システムへのService Meshの適用 ▪ Observability(監視) ▪ セキュリティ管理 1
3. © Hitachi, Ltd. 2022. All rights reserved. 1. Service Meshとは 2
4. © Hitachi, Ltd. 2022. All rights reserved. 昨今のビジネス環境におけるシステムのあり方 ▪ 昨今のビジネス環境は不透明で変化も早い ▪ フィードバックループを素早く回し、顧客ニーズや市場動向に適合 → 市場競争力を確保 ▪ 変化に対応しやすいシステムが求められる 3 ▪ 顧客ニーズの多様化 ▪ 高速な技術進歩 ▪ 競合の動向 ビジネス環境 企画 開発 リリース 運用 フィード バック ソフトウェア ライフサイクル 市場投入 反応
5. © Hitachi, Ltd. 2022. All rights reserved. Microservice Architecture ▪ 機能ごとに独立した小さなサービスを疎に連携させてシステムを構成する設計方式 ▪ 各サービスを小規模チームが自律的に開発・運用 → 変化に対応しやすい 4 Microservices Architecture UI 決済 商品 推薦 注文 管理 商品 管理 ユーザ 管理 発注 決済サービス チーム 発注サービス チーム ▪ 利点 ◇ 意思決定しやすい ◇ デプロイやテストが独立 ◇ 仕様の自由度が高い ◇ 開発規模を広げやすい
6. © Hitachi, Ltd. 2022. All rights reserved. Microservicesの成長 ビジネスの成長に伴いシステムは大きくなる ◇ サービスやチームが増加し、 ◇ それぞれのサービスも随時変化 ◇ サービスの開発言語や品質も様々 5
7. © Hitachi, Ltd. 2022. All rights reserved. Microservicesの運用 Microservicesをどのように運用するか？ ◇ 通信の暗号化やアクセス制御は？ ◇ 相手先サービスが落ちていた場合の対応は？ ◇ システム全体の可視化は？ ◇ この数のサービスに対し、個別に運用機能を実装？ 6
8. © Hitachi, Ltd. 2022. All rights reserved. Microservices運用の模索 システム全体で一貫性のある管理がしたい ◇ サービスごとに仕様がばらばらだと運用がスケールしない 各サービスからは透過的に機能を付与したい ◇ サービスのコードを改修するにはコストがかかる ◇ サービス間の独立性が失われる サービス間の通信を利用できないか 7
9. © Hitachi, Ltd. 2022. All rights reserved. Service Meshのアイデア 各サービスは通信で連携している → → 8 Svc1 Svc2 サービス間通信 運用者
10. © Hitachi, Ltd. 2022. All rights reserved. Service Meshのアイデア 各サービスは通信で連携している → サービスの前段に配置したProxyで、サービス間通信を中継・制御し、運用機能を適用 → 9 Proxy Proxy Svc1 Svc2 サービス間通信 宛先の変更 通信暗号化 アクセス制御 メトリクス出力 運用者
11. © Hitachi, Ltd. 2022. All rights reserved. Service Meshのアイデア 各サービスは通信で連携している → サービスの前段に配置したProxyで、サービス間通信を中継・制御し、運用機能を適用 → 多量に出てくるProxyはControl Planeで一元管理 10 Proxy Proxy Svc1 Svc2 サービス間通信 宛先の変更 通信暗号化 アクセス制御 メトリクス出力 運用者 Control Plane 制御 操作
12. © Hitachi, Ltd. 2022. All rights reserved. 各サービスの前段に配置したProxyをControl Planeで制御するネットワークモデル Service Meshとは 11 嬉しさ システム全体で一貫性の ある運用機能をサービスへ 透過的に付与できる 主要機能 ▪ トラフィック制御 ▪ 信頼性向上 ▪ Observability(監視) ▪ セキュリティ管理 Service Mesh Proxy (Data Plane※) Proxy (Data Plane) Svc1 Svc2 サービス間通信 宛先の変更 通信暗号化 アクセス制御 メトリクス出力 運用者 Control Plane 制御 操作 ※ ProxyはData Planeとも呼称
13. © Hitachi, Ltd. 2022. All rights reserved. 2.日立におけるService Mesh活用の取り組み 12
14. © Hitachi, Ltd. 2022. All rights reserved. 日立の取り組み 2018年より、社内外プロジェクトへのService Meshの適用や機能開発を実施 以下の取り組みを紹介 1. 社内システムへのService Meshの適用 2. Service Meshを用いたObservability(監視) 3. Service Meshを用いたセキュリティ管理 13
15. © Hitachi, Ltd. 2022. All rights reserved. 3.1. 社内システムへのService Meshの適用 14
16. © Hitachi, Ltd. 2022. All rights reserved. 対象システム ▪ 社内の開発者向けに開発環境を提供するサービス ◇ Webエディタやバックエンドサービスを提供 ◇ バックエンドサービスはそれぞれ自律的に開発が進行 ▪ Kubernetesベースのシステム。100+ Nodes、 2000+ Pods 15 Kubernetes App App 開発・実行 社内開発者 (ユーザ) Service1 開発チーム Service2 開発チーム 基盤チーム 開発 全体の 運用 開発 Service 1 Service 2 Web Editor
17. © Hitachi, Ltd. 2022. All rights reserved. Service Mesh導入のモチベーション 1. サービス間通信を管理したい ◇ 動的ルーティング、信頼性向上 ◇ 通信の暗号化やアクセス制御 ◇ ログ・メトリクスの収集 2. 各サービスの内部には干渉したくない 3. Istioのトレンドが急浮上 16 OSSのService MeshであるIstioを 検証も兼ねて導入。本番環境で2年運用 開発 社内開発者 ユーザ 開発チーム 開発チーム 基盤チーム 開発 の 運用 開発
18. © Hitachi, Ltd. 2022. All rights reserved. Service Mesh活用の結果 一通りの機能要件を実現し、サービスのコードから運用ポリシーを分離 ▪ ルーティング、通信暗号化、認証認可、信頼性向上など ▪ 開発・運用チーム間でのコミュニケーションコスト低減 ▪ マニフェストに基づく宣言的な構成管理が有用 一方、Service Meshそのものの運用コストが問題化 ▪ システム自体はService Meshというレイヤが追加され複雑化 ▪ 2018年当時のIstioは未成熟、かつ運用プラクティスもない ▪ 出てきた課題を研究所と運用チームで都度解決 → 以降で紹介 17
19. © Hitachi, Ltd. 2022. All rights reserved. 課題1 Service Mesh操作の境界の確立 Service Meshはアプリとインフラの両方に影響 → 開発・運用者間の調整要 操作権限の管理 ▪ クラスタ全体に適用される機能をサービスチームが自由に操作 → クラスタ障害 ▪ 一方でルーティングやTimeout等の設定はサービスチームに任せたい ▪ 単一リソース内の特定設定のみの制限が必要 → Kubernetes機能では対応不可 サービスチーム側でのIstio機能の自律的な取捨選択 ▪ Retry、Timeout、HTTPS終端などの機能はサービス側にもIstio側にも存在 ▪ 無理な機能の押し付けはサービスチームの反発をまねく ▪ 「HTTPSが前提のOSSを使っているから、ProxyでHTTPS終端しないで」 18
20. © Hitachi, Ltd. 2022. All rights reserved. 解決策1 Istio操作のパッケージ化 Istioの設定をHelm Chart※としてパッケージ化し、サービスチームに提供 ▪ 直接的なIstio操作を阻止 ▪ サービスチームに操作してほしい機能のみを設定項目に切り出す ▪ サービスチームは自分の使いたい機能をHelmを介して設定 結果 ▪ 危険な操作を防止するガードレール兼、学習コスト低減として作用 ▪ 現在はOpen Policy Agentなどのポリシー制御も有効と思われる 19 ※Helm Chart： Kubernetes向けの 設定配布用パッケージ
21. © Hitachi, Ltd. 2022. All rights reserved. 課題2 Proxyのメモリ管理 IstioのProxyはどのように宛先を把握しているか？ ▪ Control Planeにて宛先リストを作成し、全Proxyに配布 ▪ 宛先リストは各Proxyのメモリに格納される ▪ 宛先が増えるとリストが肥大化(現在は解決策あり) 当時何が起きたか ▪ 各Proxyが750MBのメモリを消費 (現在は大幅に改善) ▪ メモリを750MB消費するPodが数千個もある → OOM KillerでPodやNodeが落ちる ▪ 更にリソース消費傾向はIstioのバージョンごとに変化 20
22. © Hitachi, Ltd. 2022. All rights reserved. 解決策2 性能評価ツール「istio-bench」の開発 istio-benchにてメモリ消費量を予測し、事前にリソースを確保する ▪ Istioのメモリ消費の仕組みを分析し、ベンチマークツールを開発 ▪ サンドボックス環境でメモリ消費傾向を把握し、予測を立てる ▪ 本ツールはOSSとして公開(https://github.com/Hitachi/istio-bench) 21
23. © Hitachi, Ltd. 2022. All rights reserved. (参考) 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
24. © Hitachi, Ltd. 2022. All rights reserved. 課題3 運用難度の低減 Istioは通信制御, 認証認可, 監視の機能を集約 ▪ 高い自由度、無数の設定ファイル(現在は自動化や簡略化により大きく改善) ▪ 送信側と受信側での認証設定などの整合性担保に苦労 ▪ 運用に辺り覚えることが多く、属人化しやすい 障害時の原因切り分けに工数が取られる ▪ 障害には物理、仮想化、Kubernetes、Istio、Appなど様々な要因が絡む ▪ ProxyのTimeoutで障害が顕在化するため、Istioが疑われやすい ◇ 通信先のアプリが落ちた → Proxyがタイムアウトを返す ◇ 通信先でネットワーク障害 → Proxyがタイムアウトを返す 23
25. © Hitachi, Ltd. 2022. All rights reserved. 解決策3 社内Istio情報共有Wikiの整備 運用チーム内で社内Wikiを整備 ▪ 前述のHelm Chart化もあわせ 属人化を抑止 コンテンツ ▪ Istioの概要 ▪ 挙動調査結果 ▪ よくあるエラーとその原因 ▪ デバッグ方法 ▪ etc. 24
26. © Hitachi, Ltd. 2022. All rights reserved. 知見：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/ 利点 懸念点
27. © Hitachi, Ltd. 2022. All rights reserved. (参考) 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連携、マルチクラスタ連携 前 提
28. © Hitachi, Ltd. 2022. All rights reserved. 3.2. Service Meshを用いたObservability 27
29. © Hitachi, Ltd. 2022. All rights reserved. Observabilityとは？ ※1 28 ※1. 現状ソフトウェア分野ではObservabilityの合意された定義は存在せず、解釈の一例 データをもとに、システム内部で何が・何故起きているか把握できる状態にすること ▪ 複雑かつ頻繁に変化するシステムの運用では、未知の問題をもぐら叩きのように対処する ▪ 未知の現象を対処する能力を得る → 監視やテストを通したObservabilityの実現 Testing Debugging Monitoring 状態 実現手段 Observability Tracing Logging Metrics Profiling Test Events Analyzing Chaos Eng. Simulating etc.
30. © Hitachi, Ltd. 2022. All rights reserved. 日立の取り組み ▪ Service Meshを活用したObservability基盤の構築 ▪ アプリ透過型の分散トレーシング方式策定 → 以降それぞれ紹介 29
31. © Hitachi, Ltd. 2022. All rights reserved. Service Meshを活用したObservability基盤 ▪ Service Meshを用いてアプリのコードを改修することなくObservabilityを実現したい ▪ Service Meshで取得可能なデータの整理や各種監視ツールとの連携・運用方法の確立要 30 ▪ スループット ▪ 応答時間 ▪ エラー率 ▪ アクセスログ ▪ トレーシング ▪ etc. … Kubernetes アプリ 監視ツール (Prometheus等) アプリ Proxy Proxy レスポンス リクエスト レス時刻 – リク時刻 → 応答時間
32. © Hitachi, Ltd. 2022. All rights reserved. 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
33. © Hitachi, Ltd. 2022. All rights reserved. Observability基盤の構築・運用を通した知見 段階的な監視の導入 ▪ 最初はメトリクスだけで良い。最初から色々あっても使いこなせない ▪ その後、ログ→トレース。 トレースは導入コストが大きいため、必要性を感じてからの導入で良い 構成管理の状態の統一 ▪ 監視基盤を構成する多数のOSSを個別に管理していては工数が破綻。一貫性を持たせる ▪ 監視ツールの構成はKubernetesのManifestで統一し、GitOpsで環境に導入 ◇ HelmやCLIでインストールするOSSもManifestに変換して保持する 更新の自動化 ▪ 手動での更新に工数が取られる → 更新しなくなる ▪ makefile等でリポジトリからのOSS取得からManifest化までを自動化し、CIに組み込む 32 (次のページからは別の内容)
34. © Hitachi, Ltd. 2022. All rights reserved. 機能開発：透過的な分散トレーシングに向けた方式検討 ▪ 分散トレーシング：複数サービスを跨った一連の処理の流れを追う手法 ◇ ボトルネック分析やデバッグに活用される ▪ トラフィックにTraceIDなどのタグ情報を付与し、その流れを追うことで実現 33 リクエスト トレース情報 の計測と送付 TraceID:123 TraceID:123 Frontend app Proxy proxy Order app 監視サーバ TraceID の伝播 トレース情報 TraceID の付与 ユーザ 分散トレーシングの挙動 分散トレーシングの可視化(Grafana)
35. © Hitachi, Ltd. 2022. All rights reserved. 分散トレーシングの課題 課題：Service Meshのみでの分散トレーシングの実現 ▪ 現状はアプリ側でのTraceID伝播処理の実装が必須 ▪ トラフィックの伝播はアプリのロジックに依存し、対応関係がプロキシには判断できないため 34 リクエスト TraceID:123 TraceID:123 Frontend app Proxy proxy Order app 監視サーバ TraceIDの伝播 はアプリ側で のみ実施可能 トレース情報 ▪ 商品ごとにデータ取得先が異なる ▪ ユーザごとに後続処理の 呼出可否が異なる ▪ 極論. 内部乱数で伝播先を変化 アプリロジックに依存する トラフィックの伝播の例
36. © Hitachi, Ltd. 2022. All rights reserved. 先行研究 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
37. © Hitachi, Ltd. 2022. All rights reserved. 提案手法 ▪ 通信パターンを解析し、受信と送信の対応付けが可能な場合は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
38. © Hitachi, Ltd. 2022. All rights reserved. 3.3. Service Meshを用いたセキュリティ管理 37
39. © Hitachi, Ltd. 2022. All rights reserved. 日立の取り組み ▪ Microservicesのセキュリティ戦略の整理と参照実装の構築 ▪ Service Meshを用いた認証ゲートウェイ Auth Gatewayの開発 → 以降それぞれ紹介 38
40. © Hitachi, Ltd. 2022. All rights reserved. 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 ラベルが付いたプロキシのみ平文を許容 apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: "access-to-legacy" namespace: default spec: selector: matchLabels: accessTo: legacy mtls: mode: PERMISSIVE Microservicesのセキュリティ戦略(ネットワークレイヤのみ) ## User Serviceまたは監視系からのアクセスのみ許可する apiVersion: security.istio.io/v1beta1 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"] # メトリクス出力ポート
41. © Hitachi, Ltd. 2022. All rights reserved. Service Meshを用いた認証ゲートウェイ Auth Gatewayの開発 ▪ Service Meshはサービス間認証に強いが、ユーザ認証は独自に環境を構築する必要あり ▪ Keycloak等とIstioを連携させたアプリ透過型のユーザ認証ゲートウェイAuth Gatewayを開発 (OSSとして公開予定) 40 Istioの認証認可機能 (Oは機能あり) サービス間 認証 ユーザ認証 トークン発 ◯ 相互TLS ✕ アプリ側での 実装要 トークン ローテート ◯ 自動ローテート ✕ アプリ側での 実装要 トークン検証 ◯ 相互TLS ◯ JWT検証 アクセス制御 ◯ 属性ベース制御 ◯ 属性ベース制御 Auth Gatewayのアーキテクチャ (実態はHelm Chart)
42. © Hitachi, Ltd. 2022. All rights reserved. 4. まとめ 41
43. © Hitachi, Ltd. 2022. All rights reserved. まとめ Service Meshとは ▪ Proxyを活用したネットワークモデル ▪ 各サービスからは透過的、かつシステム全体で一貫した運用を行う 日立でのService Mesh活用の取り組みを紹介 1. 社内システムへのService Meshの適用 2. Service Meshを用いたObservability(監視) 3. Service Meshを用いたセキュリティ管理 42
44. © Hitachi, Ltd. 2022. All rights reserved. 参考文献 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
45. © Hitachi, Ltd. 2022. All rights reserved. 商標 ▪ 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