Service Meshがっつり入門/Get-Started-Service-Mesh

Service Mesh がっつり⼊⾨
分散システム時代の強⼒な味⽅をマスターしよう!!
Takuya Niita
Oracle Corporation Japan
Sep 07, 2022
Oracle Cloud Hangout Cafe Season6 #1

View Slide

Copyright © 2022, Oracle and/or its affiliates
2
1. Service Meshとは
2. Service Meshを実現するプロダクト
3. Istio⼊⾨
4. Istioを使ってみよう
5. まとめ
Agenda

View Slide

3
⾃⼰紹介
仁井⽥拓也
• ⽇本オラクル株式会社
• ソリューション・アーキテクト本部
• AppDev/Container/FaaS/(a little)ML…
• 前職は某SIer
• Oracle歴/Cloud Native歴︓3年半
• ジブリ⼤好き
• OCHaCafeは9回⽬の登壇(R:8回/P:1回)
• 実はオンサイトでやったことありません…
@takuya_0301

View Slide

4
Service Meshとは
Oracle Cloud Hangout Cafe 6 #1 – Service Mesh がっつり⼊⾨

View Slide

Copyright © 2022, Oracle and/or its affiliates |
5
⾼度なデプロイ戦略への追従
• サービスダウンタイム防⽌
• より⾼度なデプロイの実施
• ⼀部ユーザに対する試験的機
能のテスト
カスケード障害
• あるサービスの障害が連鎖的
に発⽣しサービス全体がダウン
（カスケード障害）
Observabilityの複雑さ
• ⼤量のサービスに
Observabilityの仕組みを導
⼊するコスト
セキュリティの煩雑さ
• 各サービス呼び出し時の認証/
認可の仕組みや通信暗号化
Metrics
Logging
Tracing
マイクロサービスにおける課題

View Slide

6
⾼度なデプロイ戦略へのモチベーション
• サービスダウンダイムなしでデプロイを実施したい
• 本番環境でテストを実施したい
⾼度なデプロイ戦略例
• A/B Test
• 旧バージョン(A)と新バージョン(B)を⽐較してどち
らの⽅が効果的かを⾒極め
• Canary Release
• ⼀部の限られたユーザーを被験体(カナリア)とし
て局所的に新機能を有効化
• Dark Launch(Shadow Test)
• 本番トランザクションを新バージョンにミラーリング
し、新機能をテスト(ユーザには影響しない)
⾼度なデプロイ戦略の導⼊
10%
90%
Canaly Release
A/B Test
A B
Dark Launch
トラフィックを
ミラーリング

View Slide

7
カスケード障害
• 局所的に発⽣した障害がその周辺コンポーネント、
もしくはシステム全体まで伝播した障害
• 原因のほとんどは、サーバ(コンポーネント)の過負
荷やリソースの枯渇
カスケード障害への防⽌策
• 適切な時間を設定したタイムアウトやリトライ回数上
限の設定
• サーキットブレイカーの導⼊
• ⼤量トラフィックによるサービスダウン防⽌や障害
時の通信を遮断/復旧を制御する仕組み
• 外れ値検出による流量制御(右図)
• コネクションプールによる流量制御
カスケード障害の防⽌
サービス
サービス
サービス
サービス
サービス
サービス
サーキットブレイカー
Closed(遮断OFF)
Open(遮断ON)
一定時間リクエストが成功し続けたら、”Closed”に戻す
(Half-Open)

View Slide

8
Observabilityの課題
• Observabilityの3本柱(Metrics/Tracing/Logging)を原
則全てのサービスに導⼊することが必要
• ロギングはアプリケーション側でログ出⼒すればOK(従
来通りの運⽤)だが、アクセスログは・・・
• メトリクス/トレーシング情報を全て⼿動で実装する
かなりの労⼒が・・・
効率的なObservabilityへの道
• 共通的なインフラとして⾃動的にObservabilityの仕組み
を導⼊
• ある程度のアクセスログ、メトリクス、トレーシングに
関する情報は構築後に即座に確認できるよう構築
効率的なObservability
サービス
監視サービス
サービスサービス
Metrics
Logging
Tracing
メトリクス/アクセスログ/トレース情報のエクスポート

View Slide

9
セキュリティの煩雑さ
• マイクロサービスにおけるサービス呼び出しは原則とし
てRESTやRPC(gRPCなど)などで実施
• 呼び出しする際に認証認可の仕組みを導⼊しない
とクライアントを信頼できない
• モノリスではメソッド(関数)呼び出しなどを利⽤す
るため認証が不要
• 呼び出しにはHTTPなどを利⽤するため通信暗号化
が必要
堅牢なセキュリティの導⼊
• 共通的なインフラとしてポリシー適⽤の仕組みを導⼊
• トラフィック制御やデフォルトでの通信暗号化、認
証認可を設定
堅牢なセキュリティ
サービス
サービス
サービス
サービス
セキュリティポリシー/認証認可ポリシー

View Slide

10
• カナリアリリース、A/Bテストなどの
⾼度なデプロイ戦略を容易に導⼊
• 障害が発⽣したサービスへの
通信を制御もしくは⼤量トラ
フィックの防⽌
• 余分な待ち時間の削減や
キャッシュの返却
• アプリケーションデプロイ後に⾃動
的にメトリクス/アクセスログ/トレー
ス情報が取得可能になるよう環
境を構築
• デフォルトで暗号化された通信
• 認証/認可やトラフィックフロー
をポリシーにより⼀括で制御
40%
60%
Metrics
Logging
Tracing
課題の解決には・・・︖︖

View Slide

11
• カナリアリリース、A/Bテストなどの
⾼度なデプロイ戦略を容易に導⼊
• 障害が発⽣したサービスへの
通信を制御もしくは⼤量トラ
フィックの防⽌
• 余分な待ち時間の削減や
キャッシュの返却
• アプリケーションデプロイ後に⾃動
的にメトリクス/アクセスログ/トレー
ス情報が取得可能になるよう環
境を構築
• デフォルトで暗号化された通信
• 認証/認可やトラフィックフロー
をポリシーにより⼀括で制御
40%
60%
Metrics
Logging
Tracing
課題の解決には・・・︖︖
サービスメッシュの利用

View Slide

12
サービスメッシュパターン
• 分散システム(マイクロサービス)におけるデザインパター
ンの⼀つ
• アプリケーション側に余分な実装を⾏うことなく、トラ
フィックの管理をシームレスに実施可能な仕組み
• アプリケーション間のトラフィックにおける制御をプロキシ
にアウトソーシング
• サービスメッシュが容易にするもの(≠必須)
• ⾼度なデプロイ戦略の導⼊
• 流⼊制限などのトラフィック制御
• 包括的なモニタリング
• ⾼度なセキュリティの構築(mTLS/認証認可)
• NIST SP 800-204でも⾔及
• サーキットブレーカによる障害伝播の防⽌
サービスメッシュとは
Service Proxy Service Proxy
Service Proxy Service Proxy
トラフィックポリシーの適⽤

View Slide

13
Istioのアーキテクチャ
• データプレーン
• サービス間通信をプロキシが担うことで通信を制御
• Kubernetes的にはサイドカーとしてPodごとに配置
• IstioではEnvoyをプロキシとして利⽤
• コントロールプレーン
• プロキシのポリシーを⼀元管理
• Istioではistiodというデーモンに統合
(参考)サービスメッシュのアーキテクチャ(Istioの例)
参考: https://istio.io/latest/docs/ops/deployment/architecture/
サービスメッシュを実現するサービスでは
同様のアーキテクチャを採用

View Slide

14
Service Meshを実現するプロダクト

View Slide

15
オープンソースベンダーサービス
Service Meshを実現するオープンソースとベンダーサービス

View Slide

16

View Slide

17
Istio
• https://istio.io/
• 最新1.15.0(2022/9現在)
• Istioとはギリシャ語で「Sail(帆)」を意味する単語
• 2番⽬に利⽤されているサービスメッシュプロダクト(CNCF Micro Surveyによる)
• トップはLINKERD
• Google社、IBM社、Lyft社が開発、2017年にオープンソース化
• 2022/4にCNCFに寄贈され、Incubating Projectとして申請されているが、
まだ未登録(2022/9現在)
• さまざまなマネージドService Mesh基盤がIstioをベースに開発
• Anthos Service Mesh/OpenShift Service Mesh…
• 実装されている機能が幅広く、VMもMesh内に含めることが可能
• サイドカープロキシにはEnvoyを採⽤
Istio

View Slide

18
LINKERD
• https://linkerd.io/
• 最新2.12.0(2022/9現在)
• 元Twitterエンジニアが始めたBuoyant社が開発
• レポジトリ名が”Linkerd2”となっている
• CNCFのGraduated Project
• 利⽤者No.1のサービスメッシュプロダクト(CNCF Micro Surveyによる)
• Kubernetes向けのオープンソースの軽量サービスメッシュ
• VMには未対応(VM対応のロードマップあり)
• Linkerd2.xからKubernetes向けの軽量サイドカープロキシ”Conduit”を
マージ(実装はRustとGolang)
• Linkerd1.0は、JVM 上で動作するFinagle、Netty、Scalaで構築
• 発⾳は”Linker-DEE”
LINKERD

View Slide

19
HashiCorp Consul Service Mesh(Consul Connect)
Consul Service Mesh(Consul Connect)
• https://www.consul.io/
• 最新1.13.1(2022/9現在)
• HashiCorp社が開発
• インフラ上のサービス設定とサービスディスカバリのためのツールとして
オープンソースで開発
• マルチプラットフォーム、マルチクラウドなサービスメッシュ環境として
動作
• Cloud版/Enterprise版として有償版も提供
• 実装されている機能が多岐に渡り、⼀機能としてサービスメッシュとし
ての機能を実装
• VMもMesh内に含めることが可能
• サイドカープロキシには組み込みプロキシを採⽤しているが、Envoyも
サポート

View Slide

20
Kuma
• https://kuma.io/
• 最新1.8.0(2022/9現在)
• Kong社がオープンソースとして開発
• CNCFのSandbox Project
• 2019年に登場した⽐較的新しいサービスメッシュプラットフォーム
• 第1世代よりも、より洗練されたコントロールプレーンを謳って
いる
• サイドカープロキシーにEnvoyを採⽤し、多様なアプリケーション環
境をサポート
• VMもMesh内に含めることが可能
• Enterprise版として有償版も提供
Kuma

View Slide

21
Open Service Mesh
• https://openservicemesh.io/
• 最新1.2.1(2022/9現在)
• Microsoft社がオープンソースとして開発
• CNCFのSandbox Project
• 2020年に登場した⽐較的新しいサービスメッシュプラットフォーム
• SMI(Service Mesh Interface)仕様に準拠したサービスメッシュプラット
フォームとして開発
• 軽量で拡張可能なクラウドネイティブサービスメッシュを謳う
• VMには現時点で未対応
• 以前は対応していた様⼦…将来的には対応予定…??
• Azure Kubernetes Service(AKS)ではOpen Service Meshのアドオン
が存在(Azure Arcでも利⽤)
Open Service Mesh

View Slide

22
Service Mesh Interface(SMI)
• https://smi-spec.io/
• “A standard interface for service meshes on Kubernetes.”
• KubeCon Europe 2019(バルセロナ開催)でMicrosoft社/Linkerd/HashiCorp社な
どが共同で公開したサービスメッシュの標準仕様
• サービスメッシュを提供しているプラットフォームに依存しなければならない状況
からの脱却を意図（可搬性を持たせる）
• まだv0.6(2022/9現在)だが、最近ではGateway API(Ingressの後継に相当)との協
業もアナウンスされており、今後に期待
• https://smi-spec.io/blog/announcing-smi-gateway-api-gamma/
• Istio/Consul Service Meshはアダプタで対応
• LINKERD/Open Service Meshはピュアに対応
【参考】SMI(Service Mesh Interface)仕様

View Slide

23

View Slide

24
AWS App Mesh
• https://aws.amazon.com/jp/app-mesh/
• AWSのサービスとして開発されているマネージドのフルサービスメッシュプラット
フォーム
• サポート環境はFargate/ECS/EKS/Kubernetes on EC2/EC2 with Docker含)
• Envoyのコントロールプレーン部分をAWSマネージドサービスとして提供
• 他のAWSサービスとの連携が強⼒
• Amazon CloudWatch
• AWS X-Ray…
AWS App Mesh

View Slide

25
Anthos Service Mesh
• https://cloud.google.com/anthos/service-mesh
• Google社が提供しているマルチ/ハイブリッドクラウド環境”Anthos”のフルマ
ネージドサービスメッシュプラットフォーム
• 以下のようなGKE(Google Kubernetes Engine)ベースに環境を提供
• Anthos GKE on Google Cloud
• Anthos clusters on Vmware/AWS…
• 中⾝はマネージドIstio(必然的にサイドカープロキシはEnvoy)
• コントロールプレーンの部分がGoogle管理
• VM環境もサポート
• Google Cloudとの他サービスとの親和性
Anthos Service Mesh

View Slide

26
OCI Service Mesh
• https://www.oracle.com/jp/cloud/cloud-native/service-mesh/
• OracleがOCI上で提供しているフルマネージドのサービスメッシュプラットフォーム
• サポートする環境はOKE(Oracle Container Engine for Kubernetes)のみ
• VMは現状未サポート(ロードマップあり)
• サイドカープロキシはEnvoyベース
• コントロールプレーンはOracleが管理
• OSOK(OCI Service Operator for Kubernetes)というOKE⽤のOperatorが必須
• 現状はユーザがインストール
• OCIの他サービスとの親和性
• OCI証明書サービス
• OCI Logging…
OCI Service Mesh

View Slide

27
オープンソース
ベンダーサービス
プロダクトのまとめ
Istio LINKERD Consul Connect Kuma Open Service Mesh
データプレーン Envoy Conduit 組み込みプロキシ
Envoy
Envoy Envoy
VMサポート可不可可可不可
有償サポート無(ベンダー製品あり) 有有有無
GitHub Star数
(2022/9現在)
31k 8.7k 25.2k 2.9k 2.5k
AWS
App Mesh
Anthos
Service Mesh
OCI
Service Mesh
提供ベンダー Amazon Google Oracle
コントロールプレーン実装独自 Istioベース独自
データプレーン Envoy Envoy Envoy
VMサポート可可不可(ロードマップあり)

View Slide

28
Istio⼊⾨

View Slide

29

View Slide

30

View Slide

31
≦ Istio 1.4のコントロールプレーン
• 以下のコンポーネントから構築
• Pilotサービス
• Envoyへのconfig反映(構成管理)の提供
• Citadelサービス
• サービス対サービスとエンドユーザー認証/認可を提供。
SPIFFE(後述)の実装コンポーネント
• Mixerサービス
• Observability(Telemetry)関連機能やアクセス制御な
どを提供
• Galleyサービス
• ユーザがカスタマイズしたconfig設定の提供
≧ Istio 1.5のコントロールプレーン
• 3つのコンポーネントを1つのバイナリに(=istiod)
• MixerサービスはEnvoyに統合(Mixer v2)
Istioコントロールプレーン(istiod)
データプレーン(Envoy)
Pilot Citadel Galley
データプレーン(Envoy)
Pilot Citadel Galley
Mixer
≧ Istio 1.5
≦ Istio 1.4
config authentication
authorization
user config
telemetry
policy check
config/authentication/authorization/user config
Mixer

View Slide

32

View Slide

33
Envoy
• 2015/5からLyft社が開発
• 2016/9にオープンソースとして公開
• L4/L7両機能を持つプロキシソフトウェア
• 実装はC++
• プラグイン開発としてWebAssembly/Luaをサポート
• Envoyを動的に制御する仕組み(”xDS Protocol”)を⽤いた
API(”xDS API”)を実装することで制御(=コントロールプレーン)
• EDS(Endpoint Discovery Service)/CDS (Cluster
Discovery Service)/RDS (Route Discovery Service)…
• JavaとGolangのリファレンス実装が存在
• https://github.com/envoyproxy/java-control-plane
• https://github.com/envoyproxy/go-control-plane
Istioデータプレーン(Envoy)
CRD
xDS API
xDS Protocol
xDS APIを実装してしまえば、誰
でもIstio(コントロールプレーン)
は作れる…!!

View Slide

34
Gateway
• メッシュへのインバウンド/アウトバウンドトラフィックを管理
VirtualService
• DestinationRuleとともにルーティング機能を構成する要素
• Kubernetes標準リソースのServiceに紐づけ、 Deployment(Pod)
のバージョニング、負荷分散ポリシーやリトライ/タイムアウト設定
を適⽤
DestinationRule
• VirtualServiceとともにルーティング機能を構成する要素
• VirtualServiceの後に考慮され、ラベルなどを利⽤してルーティン
グ先を決定。負荷分散ポリシーやサーキットブレイカーの適⽤
ServiceEntry
• メッシュ内部でのサービスレジストリを登録
• 主にはメッシュ内にVMを包含する場合やメッシュ外のAP/DBなど
外部APIを定義
• Gateway(Egress) と併⽤するイメージ
Istioを構成するカスタムリソース群
Gateway(Ingress)
Gateway(Egress)
VirtualService
DestinationRule
サービス
レジストリ
ServiceEntry
(外部APIエンドポ
イント/VMなど)
Istioではサービスレジス
トリに登録されている外
部エンドポイントのみに
アクセスさることが可能
(デフォルトは全許可)

View Slide

35
Istioのインストール構成(プロファイル)
• default
• 商⽤やマルチクラスタ構成のプライマリクラスタ⽤に構成
• demo
• デモアプリケーション⽤に構成
• minimal
• データプレーン(Gatewayなど)はユーザが個別の構成
• empty
• 全ての構成をユーザが個別に構成
• external
• コントロールプレーンを外部化している場合に構成
• preview
• Istioのプレビュー機能を試す場合に構成
(参考)Istioのインストール構成
主な
コンポーネント
default demo minimal empty external preview
Gateway
(Ingress)
✅ ✅ ✅
Gateway
(Egress)
✅
istiod ✅ ✅ ✅ ✅
参考:https://istio.io/latest/docs/setup/additional-setup/config-profiles/
IstioOperatorを利用してManifestで柔軟にカスタマイズ可能

View Slide

36
トラフィックルーティング
• Blue/Greenデプロイ、A/B、カナリアリリース
• DestinationRuleで定義したサブセットに
対してVirtualServiceによる振り分けを実
施
• HTTPヘッダーや重み付けによって実現
トラフィックミラーリング
• サブセット(ex. v1/v2)に対して、v1に流れてき
たトラフィックをv2にミラーリングすることが可能
• v2へのルーティングは”fire-and-
forget”(流しっぱなし)
• 本番環境で本番トラフィックを利⽤した
テスト⽬的での利⽤
Istioを利⽤してできること
ミラーリングの場合
トラフィック(デプロイ戦略)

View Slide

37
リトライ回数制限
• VirtualServiceを利⽤してリトライ条件と上限
回数を設定
• EnvoyFilter(後述)を利⽤してリトライ時の
Backoff(リトライ間隔)を延伸したり、ランダ
ムに時間を加算することも可能
(Exponential Backoff and Jitterパターン、
本⽇は割愛)
タイムアウト
• VirtualServiceを利⽤してタイムアウトを設定
• 複数サービスにまたがる場合は、エッジ(トラ
フィックのはじめ)でタイムアウトを⻑くし、深
層ではタイムアウトを短く
タイムアウトのみ場合
耐障害性

View Slide

38
サーキットブレイカー(外れ値検出⽅式)
• DestinationRuleを利⽤して設定(コネクションプール⽅式も同様)
• はずれ値を定義し、閾値を超過したサービスを排除(遮断)することが可能
• 5xxエラーが”7”回継続したらOpen(遮断ON)
• 15分後にHalf-Open(確認)に移行し、”5秒間”疎通確認
• 疎通できない場合は「”15(分)”×遮断回数分」待機
• 2回目は30分、3回目は45分…
• フェイルオーバー判定も可能
耐障害性
コネクションプール方式は
デモで解説します

View Slide

39
メトリクス
• サイドカーであるプロキシ(Envoy)が様々なメトリクスを
⾃動的にエクスポート
• Prometheus/Grafanaを利⽤してメトリクスを即時
に可視化
• Envoyが15090ポートで公開
• EnvoyFilterを利⽤して独⾃のメトリクスを定義す
ることも可能(本⽇は割愛)
トレーシング
• プロキシ(Envoy)が⾃動的にヘッダー (b3-propagation)
の付与とスパン(トレース間隔)作成を実施
• Jaegerなどでトレーシング情報を即時に可視化
• システム全体のトレースするにはアプリケーション
側でHTTPヘッダーの伝播が必須
$ kubectl exec -it deploy/webapp -c istio-proxy -- curl ¥
localhost:15090/stats/prometheus
...
envoy_cluster_assignment_stale{cluster_name="
outbound|80||catalog.istioinaction.svc.cluster.local"} 0
envoy_cluster_assignment_stale{cluster_name="xds-grpc"} 0
envoy_cluster_assignment_timeout_received{cluster_name="
outbound|80||catalog.istioinaction.svc.cluster.local"} 0
envoy_cluster_assignment_timeout_received{cluster_name="xds-grpc"}
…
$ curl -H "Host: httpbin.io" http://localhost/headers
….
"X-B3-Sampled": "1", # トレーシングヘッダー
“X-B3-Spanid”: “17ed6f800f125ecb”, # トレーシングヘッダー
"X-B3-Traceid": "05516f0b84c9de6817ed6f800f125ecb", # トレーシングヘッダー
"X-Envoy-Attempt-Count": "1", ”
"X-Envoy-Decorator-Operation": "”
….
Envoyのメトリクスエンドポイントにアクセスした場合のイメージ
任意のサービスにアクセスした場合のHTTPヘッダー
Observability
参考:https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/

View Slide

40
mTLS
• PeerAuthenticationを利⽤して実現
• プロキシ(Envoy)が注⼊されているサービス間のトラフィックは⾃動的にmTLS可能
• 証明書のローテーションも⾃動で実施
• メッシュ内のサービス間ではワークロードIDをもとにmTLSを実現
• SPIFFE(後述)が発⾏するID(“spifee:///ns//sa/”)
• ポートレベルで設定が可能(⼀部ポートのmTLS通信の除外設定に便利)
Istio環境ではデフォルトで
mTLS通信可能。
この設定だけでセキュアに!!
つまりは
Service Account(SA)で認証
セキュリティ(サービス間認証(mTLS))

View Slide

41
認証(Authentication)
• RequestAuthenticationを利⽤して実現
• RequestAuthentication :クレデンシャル(JWT)
を発⾏したサーバに対して検証するようにプロ
キシ(Envoy)を構成(jwksでの検証)
認可(Authorization)
• AuthorizationPolicyを利⽤して実現
• RequestAuthenticationと”rules”フィールドに
基づき認可を実施
• 右の例は”requestPrincipals”とHTTPメソッ
ド(GET)を許可ルールに指定
• “requestPrincipals”はJWT Claimの
“/”かSPIFFE ID(後述)
のいずれかを利用
認証
認可
セキュリティ(エンドユーザ認証(JWT))

View Slide

42
SPIFFE
• CNCF Incubating Projectの⼀つ
• “A universal identity control plane for distributed systems”
• ゼロトラストネットワークに基づくサービス間認証の標準仕様
• 分散システム(マイクロサービス)における多様なワークロード(コン
テナ/FaaS/VM)や環境(クラウド/オンプレ)に依存することなく、同
⼀インタフェースで利⽤可能
• X.509形式とJWT形式をサポート
• SPIFFE ID/Workload APIなどのコンポーネントが存在
• これらを実装したプロダクトにはSPIRE(参照実
装)/Istio/Hashicorp Consul/Kumaなどがある
【参考】SPIFFE(Secure Production Identity Framework For Everyone)
標準仕様
実装プロダクト
参考:https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE.md

View Slide

43
アーキテクチャ
• コントロールプレーン(v1.5からistiodというシングルバイナリ)とデータプレーン(Envoy)からなる
主なカスタムリソース(CRD)
• Gateway/DestinationRule/VirtualService/ServiceEntry
できること
• DestinationRule/VirtualServiceを利⽤したトラフィックルーティング(B/G、A/B、Canary…)とトラフィックミラーリング
• VirtualServiceを利⽤したリトライ制限やタイムアウトの設定
• DestinationRuleを利⽤したサーキットブレイカーの導⼊
• Envoyにデフォルトで組み込まれているObservabilityを利⽤したメトリクスの可視化やトレーシング
• PeerAuthentication/RequestAuthentication/AuthorizationPolicyを利⽤したmTLS/認証認可
Istioまとめ

View Slide

44
Envoyの拡張⽅法
• EnvoyFilterを利⽤
• カスタムリソース(Manifest)を利⽤して設定
• HttpConnectionManager(HCM)というネットワークフィル
ターを利⽤
• HTTPヘッダーやペイロードをL7に基づいてルーティング
• CORS/CSRF対策/外部認証/流⼊制限/フォールトイン
ジェクション…
• プラグインを実装
• Luaスクリプト/WebAssembly(Wasm)を利⽤
• EnvoyFilterにインラインで実装することも可能
• 外部サービスの呼び出しやカスタムコードを実⾏すること
が可能
【参考】Istioの拡張

View Slide

45
Istioを使ってみよう

View Slide

46
アーキテクチャ
• コントロールプレーン(v1.5からistiodというシングルバイナリ)とデータプレーン(Envoy)からなる
主なカスタムリソース(CRD)
• Gateway/DestinationRule/VirtualService/ServiceEntry
できること
• DestinationRule/VirtualServiceを利⽤したトラフィックルーティング(B/G、A/B、Canary…)とトラフィックミラーリング
• VirtualServiceを利⽤したリトライ制限やタイムアウトの設定
• DestinationRuleを利⽤したサーキットブレイカーの導⼊
• Envoyにデフォルトで組み込まれているObservabilityを利⽤したメトリクスの可視化やトレーシング
• PeerAuthentication/RequestAuthentication/AuthorizationPolicyを利⽤したmTLS/認証認可
Istioまとめ
これを一気に(一部ピックアップで)見せます…!!

View Slide

47
istioctlの利⽤
• Istioでは”istioctl”というコマンドが存在
• Istioctlによってインストール/アンインストール/構成の変更などがスムーズに実⾏可能
• istioctlのインストールはこれだけ!!(必要に応じてPATHを通す)
istioctlを利⽤したインストール
demoプロファイル(profile: demo)でインストールする場合(“--set profile=demo”を省略するとdefaultプロファイル)
※istioctlでManifestを出⼒し、カスタマイズした上でインストール/構成変更も可能
Istioのインストール
$ curl -L https://istio.io/downloadIstio | sh -
$ istioctl install --set profile=demo

View Slide

48
• Kubernetes環境︓Oracle Container Engine for Kubernetes(OKE) v1.24.1
• Istioバージョン︓v1.15.0
• 今回はプロファイル(demo)でセットアップ
• デモ⽤のアプリケーションはBookInfoアプリケーション
デモンストレーション環境
v2
v3
v1

View Slide

49
1. DestinationRuleとVirtualServiceの作成
2. Review v1:v2:v3=100:0:0の割合でルーティング
3. Review v1:v2:v3=0:50:50の割合でルーティング(A/Bテストのイメージ)
4. Review v1:v2:v3=80:10:10の割合でルーティング(カナリアリリースのイメージ)
Istioでトラフィック制御してみよう!!
Manifestで
ルーティングポリシー
を自在に制御

View Slide

50
1. 先ほどのトラフィックルーティングの状況をGrafanaで確認(⿊枠)
2. Kialiを利⽤してトラフィックの状況を可視化(⿊枠)
3. Jaegerを利⽤してアプリケーション全体のトレーシング情報の可視化(⾚枠)
IstioでObservabilityをやってみよう!!
80%
10%
10%

View Slide

51
1. DestinationRuleでコネクションプールを定義
• 今回は、コネクションプールを「1」、Pending(キューイング)可能なリクエストを「1」として定義
2. k6(負荷テストツール)を利⽤して同時に⼤量アクセス
• コネクションプール(1)を超過するとキューイング、かつ保持できるのは1リクエストのみ(超過した場合は503エラー)
Istioでサーキットブレイカー(コネクションプール⽅式)を試してみよう!!
適用するDestinationRule
503エラーを期待…!!

View Slide

52
1. IDCS(Oracle Identity Cloud Service)を利⽤したRequestAuthentication/AuthorizationPolicyを定義
• 事前に作成したユーザ情報を利⽤
• JWT claimの”issuer/subject”が”https://identity.oraclecloud.com/[email protected]”なら許可
• それ以外は拒否
2. Product pageに対してアクセス
Istioで認証認可をやってみよう!!
IDCS
ログイン
JWT
アクセス with JWT
JWKSでJWT検証
JWTはサービス側 or 外部(OPA等)
で取得

View Slide

53
【補⾜】Istioで認証認可をやってみよう!!
適用するRequestAuthentication/AuthorizationPolicy
期待するJWT
JWTやらJWKSやらについては「マイクロサービスの認証・認可とJWT」を参照
https://speakerdeck.com/oracle4engineer/authentication-and-authorization-in-microservices-and-jwt

View Slide

54
まとめ

View Slide

55
マイクロサービスの課題とService Meshのメリット
• ⾼度なデプロイ戦略への追従、障害の伝播によるサービスダウン、Observability/セキュリティの整備
• Service Meshを利⽤することでアプリケーションを変更することなく、課題を解決することが可能
Service Meshを実現するプラットフォーム
• オープンソース、ベンダーサービス問わずにさまざまなプラットフォームが存在するが、ほとんどがEnvoyベース
• 利⽤者数としては1番⼿がLINKERD、2番⼿がIstioとなっている
• Service Mesh Interface(SMI)というService Meshの標準仕様を策定する取り組みがあり、今後に期待
Istioで実現できること
• トラフィックの制御(本番トラフィックのミラーリングも可能)、耐障害性の⾼いアプリケーションを実現
• アプリ運⽤インフラ基盤の整備により、効率的なObservabilityや堅牢なセキュリティの実現
• EnvoyFilterやプラグインを利⽤した柔軟な拡張も可能
まとめ

View Slide

56
サービスメッシュプラットフォーム
• Istio
• https://istio.io/
• https://github.com/istio/community
• LINKERD
• https://linkerd.io/
• https://github.com/linkerd/linkerd2
• HashiCorp Consul Service Mesh
• https://www.consul.io/docs/connect
• https://github.com/hashicorp/consul
• Kuma
• https://kuma.io/
• https://github.com/kumahq/kuma
参考資料&Special Thanks!!

View Slide

57
サービスメッシュプラットフォーム
• Open Service Mesh
• https://openservicemesh.io/
• https://github.com/openservicemesh/osm
• AWS App Mesh
• https://aws.amazon.com/jp/app-mesh/
• Anthos Service Mesh
• https://cloud.google.com/anthos/service-mesh?hl=ja
• OCI Service Mesh
• https://www.oracle.com/jp/cloud/cloud-native/service-mesh/
• https://speakerdeck.com/oracle4engineer/oci-service-mesh-ovewview
• https://github.com/oracle/oci-service-operator(Kubernetes Operator)
• SMI(Service Mesh Interface)
• https://github.com/servicemeshinterface/smi-spec

View Slide

58
参考資料
• Announcing SMI's collaboration in the Gateway API GAMMA Initiative
• https://smi-spec.io/blog/announcing-smi-gateway-api-gamma/
• Exponential Backoff And Jitter
• https://aws.amazon.com/jp/blogs/architecture/exponential-backoff-and-jitter/
書籍
• Istio in Action(Manning)
• https://www.amazon.co.jp/dp/B09XN9RDY1/
参考サイト
• Service Mesh Comparison
• https://servicemesh.es/
• Service meshes are on the rise
• https://www.cncf.io/wp-content/uploads/2022/05/CNCF_Service_Mesh_MicroSurvey_Final.pdf
• NIST SP 800-204(Security Strategies for Microservice-based Application Systems)
• https://csrc.nist.gov/publications/detail/sp/800-204/final

View Slide

59
デモ資材
• https://github.com/oracle-japan/ochacafe_servicemesh_istio
参考セッション
• Cloud Native Security Conferrence 2022
• Istioを活⽤したセキュアなマイクロサービスの実現: アプリ透過型のユーザ及びサービス間の認証認可 @ido_kara_deruさん
• https://event.cloudnativedays.jp/cnsec2022/talks/1442
• サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来 @sakonさん/@Typhon666_deathさん
• https://event.cloudnativedays.jp/cnsec2022/talks/1450
参考ハンズオン
• OCI Service Meshを使ってサービスメッシュ環境を作ろう
• https://oracle-japan.github.io/ocitutorials/cloud-native/osm-for-beginners/
• Oracle Container Engine for Kubernetes(OKE)でサンプルマイクロサービスアプリケーションをデプロイしてオブザバビリティツールを利⽤してみよう(Istio利⽤)
• https://oracle-japan.github.io/ocitutorials/cloud-native/oke-for-advances/
• Oracle Container Engine for Kubernetes(OKE)でサンプルマイクロサービスアプリケーションをデプロイしてOCIのオブザバビリティサービスを利⽤してみよう
• https://oracle-japan.github.io/ocitutorials/cloud-native/oke-observability-for-advances/

View Slide

Thank you!!
60

View Slide

View Slide

Service Meshがっつり入門/Get-Started-Service-Mesh

Service Meshがっつり入門/Get-Started-Service-Mesh

oracle4engineer
PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

Service Meshがっつり入門/Get-Started-Service-Mesh

Service Meshがっつり入門/Get-Started-Service-Mesh

oracle4engineer PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

oracle4engineer
PRO