Anthos Service Mesh（ASM）勉強会

Google Cloud | Anthos Service Mesh(ASM)勉強会 クラウド技術情報共有コミュニティ勉強会 2021年11月15日 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 松沢 敏志 © Matt. 2021. All rights reserved.

自己紹介 一言でいうと 日立のクラウドCoEチーム所属のソリューションアーキテクト、通称CCoEの何でも屋 所属 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 職歴 (※1) - 2007年に日立製作所入社以降、LinuxカーネルモジュールやOSSの開発エンジニア、 Red Hat製品のテクニカルサービス/サポートサービスL3エンジニア、 VMware/Microsoft製品を活用した国内HCIビジネス企画/立ち上げ、などを経験 - 2019年10-11月に米国FinTech系スタートアップにてデータ分析プログラムの開発 (インターン) - 2020年4月に日立グループのクラウドCoEチーム設立とともに異動、 クラウドアーキテクト/SREの役割でAWS/Azure/GCP案件に参画しての設計支援活動を中心に、 社内へのクラウド技術の普及活動、社外イベント講演などのプレゼンス向上活動にも従事 資格・受賞歴 (※1) - AWS認定資格12種コンプ、Azure認定資格6種、GCP認定資格3種など - 2021 APN AWS Top Engineer & APN ALL AWS Certifications Engineer受賞 まつざわ さとし 松沢 敏志 その他 - 好きなものは真っ赤なスポーツカーとロックミュージック、趣味は投資と仕事 - 次の目標は「Google Cloud Partner Top Engineerに、俺はなるっ!!!」 ※1：詳細はLinkedIn（https://www.linkedin.com/in/satoshi-matsuzawa-b209a1157/）をご参照ください。 © Matt. 2021. All rights reserved. 1

• https://www.linkedin.com/in/satoshi-matsuzawa-b209a1157/

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ © Matt. 2021. All rights reserved. 2

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ の前に © Matt. 2021. All rights reserved. 3

おさらい、マイクロサービスとは 用途や目的ごとに小さなアプリケーションを作って、それらを組み合わせてシステムを構築するアーキテクチャのパターン API 密結合 疎結合 © Matt. 2021. All rights reserved. 4

おさらい、マイクロサービスの主な利点 マイクロサービスの方が スケールアウトがしやすい マイクロサービスの方が 変更をかけやすい、開発がしやすい © Matt. 2021. All rights reserved. 5

マイクロサービスが抱える課題 ① 性能 APIコールはメモリ処理と比較して遅い ② サービス検出 (サービスディスカバリ) 依存関係にあるサービスの参照先が動的に変更されるので接続先情報の管理が大変 ③ トラフィック制御 他サービス障害に引きずられて落ちないようAPIコールのリトライ、タイムアウト、サーキットブレーカの実装が必要 ④ 可観測性 (オブザーバビリティ) サービス間通信の可視化やログの追跡が困難で、レスポンス遅延やエラー発生がどこで起きたのかの特定が難しい ⑤ セキュリティ サービス間の通信暗号化や認証・認可機能などの実装が必要 © Matt. 2021. All rights reserved. 6

マイクロサービスが抱える課題 ① 性能 APIコールはメモリ処理と比較して遅い ② サービス検出 (サービスディスカバリ) 依存関係にあるサービスの参照先が動的に変更されるので接続先情報の管理が大変 ③ トラフィック制御 他サービス障害に引きずられて落ちないようAPIコールのリトライ、タイムアウト、サーキットブレーカの実装が必要 ④ 可観測性 (オブザーバビリティ) サービス間通信の可視化やログの追跡が困難で、レスポンス遅延やエラー発生がどこで起きたのかの特定が難しい ⑤ セキュリティ サービス間の通信暗号化や認証・認可機能などの実装が必要 サービスメッシュが解決する課題 © Matt. 2021. All rights reserved. 7

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ © Matt. 2021. All rights reserved. 8

サービスメッシュとは マイクロサービスごとに(サイドカー)プロキシを配置して他のサービスとのすべての通信をプロキシ経由に させ、プロキシの管理はコントロールプレーンにて一元的に行うことによって、サービスの依存関係の解決、 トラフィック制御、セキュリティ、可観測性などの機能を提供をする仕組みです。 すべてのサービスがメッシュ状に接続される構造から「サービスメッシュ」と呼ばれているようです。 © Matt. 2021. All rights reserved. 9

補足、サイドカーとは コレ！ 補助的な機能を盛り込んだコンテナを付属することで、 メインコンテナ自身には手を加えず(コード改修不要で)、 補助的な機能を実装することが可能なコンテナ技術です。 © Matt. 2021. All rights reserved. 10

サービスメッシュのユースケース © Matt. 2021. All rights reserved. 11

サービスメッシュを実現する主要なソフトウェア CNCF(Cloud Native Computing Foundation)の卒業プロジェクトとなったことでも 話題になったソフトウェア、知名度は高い、読み方はリンカーディー AWS発祥のソフトウェア Microsoft発祥のソフトウェア Google発祥のソフトウェア、知名度は高い、 IBMやRed Hatも推しててOpenShiftなどでも採用されてる 読み方はイスティオ © Matt. 2021. All rights reserved. 12

サービスメッシュを実現する主要なソフトウェア CNCF(Cloud Native Computing Foundation)の卒業プロジェクトとなったことでも 話題になったソフトウェア、知名度は高い、読み方はリンカーディー 世はまさにサービスメッシュ戦国時代！！ AWS発祥のソフトウェア Google発祥のソフトウェア、知名度は高い、 IBMやRed Hatも推しててOpenShiftなどでも採用されてる 読み方はイスティオ 信長(Linkerd)、今川(Istio)、武田(App Mesh)、上杉(OSM)、だれが世を取るのかわからない!! ※武将とソフトウェアの対応は適当なので本当に意味はないです 道三(CFCN)の後ろ盾を得て、 今まさに桶狭間の戦いが起きようとしている!? Microsoft発祥のソフトウェア © Matt. 2021. All rights reserved. 13

各クラウドサービスにおけるサービスメッシュへの対応 Anthos Service Mesh (ベースはIstioの独自Distro) 今日はこちらについてのお話をします！ AWS App Mesh (ベースはAWS App Mesh) Open Service Mesh AKSアドオン (ベースはOSM) © Matt. 2021. All rights reserved. 14

各クラウドサービスにおけるサービスメッシュへの対応 ちなみに、 3社ともベースの技術が違くて困ったなと思われた方、 そもそもIaaS(VM、ネットワークなど)の定義の仕方ですら まったく同じじゃないでしょ？でも使えてますよね？ ベース技術が違うからってビビることはありません。 いつも通り設定の項目が多少違うだけ、 何も問題はありません。恐れる必要はないでしょう。 Anthos Service Mesh (ベースはIstioの独自Distro) 今日はこちらについてのお話をします！ AWS App Mesh (ベースはAWS App Mesh) Open Service Mesh AKSアドオン (ベースはOSM) © Matt. 2021. All rights reserved. 15

Anthos Service Mesh(ASM)とは Googleが提供するマネージドサービスメッシュ 動作環境としては次をサポート(※1) ‐ Google Kubernetes Engine(GKE)(※2) ‐ 各Anthosクラスタ(VMware/ベアメタル/AWS/Azure) ‐ 各Anthosアタッチクラスタ(Amazon Elastic Kubernetes Service(EKS)/Azure Kubernetes Engine(AKS)) ※1: GKEとそれ以外でサポートするKubernetesバージョンの範囲が異なるので注意が必要 ※2: Autopilotは現時点では未サポートなので注意が必要 ASMのメリット ‐ Googleのサポートが得られる(要サポート契約) ‐ Cloud Monitoring / Loggingと統合されている OSS Google Cloud Istio --> Anthos Service Mesh(ASM) © Matt. 2021. All rights reserved. 16

ASMとIstioの比較 項目 ASM GKE ASM On-Prem ASM Other Clouds Istio サポート Google Google Google コミュニティサポート サポート期間 (特定マイナーバージョン) 最低9か月 最低9か月 最低9か月 通常約6か月 コントロールプレーン管理 (istiod) Google管理 or ユーザ管理 ユーザ管理 ユーザ管理 ユーザ管理 (リソース管理、死活監視) mTLS証明書/鍵管理 Google管理(Mesh CA) or ユーザ管理(Istio CA) Google管理(Mesh CA) or ユーザ管理(Istio CA) ユーザ管理 (Istio CA) ユーザ管理 (Istio CA) トレーシング Cloud Trace Cloud Trace Zipkin, Jaeger, etc. Zipkin, Jaeger, etc. テレメトリ Cloud Monitoring + ASM Dashboard Cloud Monitoring Prometheus + Grafana Prometheus + Grafana サービスメッシュ可視化 ASM Dashboard Kiali Kiali Kiali ロギング Cloud Logging + ASM Dashboard Cloud Logging Stdout or other Stdout or other © Matt. 2021. All rights reserved. 17

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ © Matt. 2021. All rights reserved. 18

IstioとKubernetesのAPIリソース相関図 Gateway 参照 サブセット参照 VirtualService (Istioリソース) DestinationRule (Istioリソース) (Istioリソース) 転送先ルートとして指定 指定 App Service (k8sリソース) 設定 設定 Pod (k8sリソース) 通信 istio-ingressgateway Endpoints istiod経由で Endpointを取得 サブセット定義 Selector v1 Pod (k8sリソース) Envoy Proxy v2 Pod (k8sリソース) Envoy Proxy Application Container Application Container © Matt. 2021. All rights reserved. 19

Istio Gatewayリソース 外からメッシュへ入ってくる通信、外へ出ていく通信を管理するためのリソース ➢ 外から/内から待ち受けるプロトコルやポートなどを定義 ➢ Selectorで利用するIngress/Egress GatewayのPodを指定 ➢ ➢ デフォルトで作られるIngress Gatewayを指定する場合は、 "istio: ingressgateway"を指定する ➢ Ingress Gatewayが複数ある場合やEgress Gatewayをデプロ イした場合は、対象のGateway Podに指定したLabel値を Selectorに指定する TLS終端なども定義可能 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: webapp-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http http://*:80/ で受付 protocol: HTTP hosts: - "*" © Matt. 2021. All rights reserved. 20

Istio VirtualServiceリソース トラフィックの振り分け、ルーティングテーブルのルールを定義するリソース ➢ パスベースやヘッダー情報ベースなどの基本的なルーティング からトラフィック分割(Canary)などの高度な定義も指定可能 ➢ Gatewaysセクションでルールを適用するGatewayを指定 ➢ Destinationセクションで送信先のk8s Serviceを指定 (Subsetについては次のDestinationRulesリソース参照) ➢ タイムアウトやリトライ、疑似障害注入(Fault Injection)など の設定を構成することも可能 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: webapp-ingress spec: hosts: - "webapp.sample.com" gateways: - webapp-gateway http: - route: - destination: host: webapp webappというk8sサービスの subset: v1 v1サブセットへ75%振り分けて weight: 75 v2サブセットへ25%振り分け というCanaryの例 - destination: host: webapp subset: v2 weight: 25 © Matt. 2021. All rights reserved. 21

Istio DestinationRuleリソース 転送先サービスのサブセット化や各種トラフィックポリシーを定義するリソース ➢ 負荷分散ポリシーにはシンプルな分散アルゴリズムから ローカリティを意識した高度な分散アルゴリズムも指定可能 ➢ 流量制御としてコネクション数の上限値、異常検知によるサー キットブレーカの定義が可能 ➢ サービスとのTLS設定について定義可能 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: webapp-route spec: host: webapp trafficPolicy: loadBalancer: simple: RANDOM subsets: - name: v1 labels: webappというk8sサービスの version: v1ラベルが付与された version: v1 Podをサブセットv1、 - name: v2 version: v2ラベルの付与された Podをサブセットv2と定義 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN © Matt. 2021. All rights reserved. 22

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ © Matt. 2021. All rights reserved. 23

ASMの主要な設計ポイント 1. どこまでGoogle管理にするのか ⚫ コントロールプレーン(Istiod)管理 ⚫ データプレーン(Envoy proxy)管理 ⚫ mTLS証明書/鍵管理 2. 課金プランをどうするのか 3. ネットワーク構成をどうするのか © Matt. 2021. All rights reserved. 24

コントロールプレーンIstiod管理 (Google管理 vs ユーザ管理) GKEリリースチャンネルを利用するならGoogle管理、それ以外の構成だと選択肢自体がユーザ管理のみです Google管理 ユーザ管理 (In-cluster) = GKEノード上にリソースとして展開 Good Point 管理はGoogle任せなのでユーザはよりビジネスロジックに注力できる Bad Point リリースチャンネルのGKE構成のみで利用可能、カスタムCA利用不可 Good Point バージョン管理、更新タイミングなどをユーザがある程度制御できる Bad Point Istiodを定期的にユーザが更新する必要があるので手間がかかる © Matt. 2021. All rights reserved. 25

補足、GKEリリースチャンネルについて Kubernetesのコントロールプレーンとノードを自動アップデートするモードです (前回のGKE勉強会より抜粋) インターネット上に転がっている情報の中には「StableチャンネルだとASMがサポートされない」、 「StableチャンネルではIstiodのGoogle管理は利用できない」とウソを言っていることがあります。 現在ではちゃんとStableチャンネルでもサポートはされますのでご安心ください。 © Matt. 2021. All rights reserved. 26

ASMリリースチャンネルについて ASMのコントロールプレーンを自動アップデートするモード、概念はGKEリリースチャンネルと同じです チャンネル Rapid Regular Stable 利用可能なバージョン 詳細 最新のASMバージョン アップグレード頻度高。 最新の機能を早く利用したい人向け、テスト環境/評価環 境などでの利用を推奨されるチャンネル。 Rapidを経たASMバージョン アップグレード頻度中。 最新機能は使いたいけど、なるべく安定したものを使いた いという欲張りさん向けのチャンネル。 Regularを経たASMバージョン アップグレード頻度低。 安定性を最優先にするようなプロダクション用途での利用 を推奨されるチャンネル。 © Matt. 2021. All rights reserved. 27

Google管理データプレーンの適用について Google管理データプレーンとは Google管理コントロールプレーンの自動アップグレード時に、 サイドカープロキシも自動アップグレードを行う機能です。 ②こっちも自動でアップグレードしてくれる 現在はASMのRapid/Regularチャンネルのみに対応しています。 Google管理データプレーンの適用について ユーザがGoogle管理コントロールプレーンのアップグレードを 検知して、手動でサイドカープロキシのアップグレードを実施、 という運用が省略できるのでとても楽になる見込みです。 ①こっちが自動でアップグレードされたら ただし、現時点ではプレビュー段階の機能のためプロダクショ ン用途での適用は現時点では見送った方が良いかもしれません。 ご参考: Envoy Proxyの手動アップグレード手順 例えば以下のメトリクスを確認するなどCloud Monitoringからも確認できる - Resource type: Kubernetes Container - Metric: Proxy Clients - Group By: control_plane_version 1. ASMのコントロールプレーンがアップグレードされたことを確認する 2. 手動でEnvoy Proxyを含むKubernetes Deploymentリソースを入れ替える $ kubectl rollout restart <deployment> -n <namespace> © Matt. 2021. All rights reserved. 28

mTLS証明書/鍵管理 (Mesh CA vs Istio CA) カスタムCAが必要な場合はユーザ管理(Istio CA)、それ以外はGoogle管理(Mesh CA)がおすすめです Google管理 (Mesh CA) ユーザ管理 (Istio CA、旧称Citadel) vs Good Point ローテーションを意識しなくていい Good Point カスタムCAを扱うことができる Bad Point Istiodをユーザ管理(In-cluster)にする必要がある IstiodをGoogle管理とした場合は、Istio CAを選択することができません。 カスタムCAが必要な場合は、Istiodをユーザ管理(In-cluster)とする必要があります。 © Matt. 2021. All rights reserved. 29

課金ライセンス (Anthosライセンス vs ASMスタンドアロン) GKEでASMのみ使う場合はASMスタンドアロンライセンスの方が安くなる可能性あるので一考の余地あり (とはいえ、有料化されたのでスタンドアロンライセンスを利用するメリットはだいぶ薄れた感はある、、、) Anthosライセンス ASMスタンドアロンライセンス https://cloud.google.com/anthos/pricing https://cloud.google.com/service-mesh/pricing ➢ ノードのvCPU数に基づいた従量課金制 ➢ オンプレミスやマルチクラウドでのASMには必須 ➢ ASM以外のAnthos機能を使う場合にも必須 vs ➢ クラスタ数とPod数に基づいた従量課金制 (2021/10までは無料だったけど、、、) ➢ GKEでASMのみ使う際に利用可能 Anthos APIをプロジェクトで有効化するとAnthosライセンス料金での請求となるため、 ASMスタンドアロンライセンスを利用したい場合は注意が必要です。 © Matt. 2021. All rights reserved. 30

• https://cloud.google.com/anthos/pricing
• https://cloud.google.com/service-mesh/pricing

Ingressネットワーク構成 (L4LB vs L7LB、外部 vs 内部) ASMのデフォルトネットワーク構成 (=External L4LB) ➢ istio-ingressgateway は Deployment として配置、 Service のタイプは LoadBalancer が指定されていて実体は外部TCP負荷分散が裏で動作している ➢ アクセス元制限をするのであればServiceを書き換えて loadBalancerSourceRanges でアクセス元IPを定義する k8s service: LoadBalancer istio-ingressgateway 外部TCP負荷分散 Cloud Load Balancing kube-proxy(iptables) spec: loadBalancerSourceRenges: - “1.2.3.4/27" - “5.6.7.8/30" - “9.10.11.12/28" k8s deployment istio-ingressgateway Replica: 2 Limits: CPU: 2, MEM: 1Gi Requests: CPU: 100m, MEM: 128Mi k8s deployment k8s deployment Envoy Proxy Envoy Proxy App A Container App B Container Sidecar(Envoy Proxy) Limits: CPU: 100m, MEM: 50Mi Requests: CPU: 10m, MEM: 10Mi 特定の送信元からのアクセスに制限する例 © Matt. 2021. All rights reserved. 31

Ingressネットワーク構成 (L4LB vs L7LB、外部 vs 内部)
Cloud Armor(WAF)やCloud CDNとの統合をするなら外部HTTP(S)負荷分散に入れ替え
➢

Ingress を作成し、istio-ingressgateway の Service を NodePort にして NEG を有効化する

➢

istio-ingressgateway のヘルスチェックは /healthz/ready の15021ポートを指定する

k8s ingress

k8s service: NodePort(NEG有効)

istio-ingressgateway

k8s deployment

k8s deployment

istio-ingressgateway

Envoy Proxy

外部HTTP(S)負荷分散
Cloud Load Balancing

NEG(Network Endpoint Group)

BackendConfigで
/healthz/ready の Port 15021
に対してヘルスチェックを設定

App A Container

metadata:
annotations:
cloud.google.com/neg: '{"ingress": true}'
spec:
type: NodePortz

API Gatewayなどをフロントに置いて、Podへは内部通信のみとするならば内部負荷分散へ
L4LB(ServiceのLoadBalancerタイプ)の場合は定義にこちら(↓)を挿入

metadata:
annotations:
cloud.google.com/load-balancer-type: "Internal"

metadata:
annotations:
kubernetes.io/ingress.class: "gce-internal"
L7LB(Ingress)の場合は定義にこちら(↑)を挿入

© Matt. 2021. All rights reserved.

32

Egressネットワーク構成のベストプラクティス 多層防御アーキテクチャとするのが良いでしょう。 © Matt. 2021. All rights reserved. 33

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ © Matt. 2021. All rights reserved. 34

アップグレードの基礎 リリースサイクル ➢ ASMは3か月~ごとに最新マイナーバージョンをリリース、パッチは~1か月ごとにリリース ➢ ASMはIstioのリリースに加えて、独自にセキュリティおよびバグ修正を提供 1.11.2-asm.17 マイナーバージョン ASM独自パッチバージョン パッチバージョン ASMのバージョンポリシー ➢ ASMのマイナーバージョンはKubernetesの特定マイナーバージョン1つのみに対応 例外でGKEについては(GKE Stableチャンネルなどの関係で)古いKubernetesのマイナーバージョンも一部対応 ASM Kubernetes 1.11.x 1.10.x 1.9.x 1.21.x 1.20.x 1.19.x © Matt. 2021. All rights reserved. 35

アップグレードのパターン Google管理コントロールプレーン(リリースチャンネル)を利用している場合 ➢ 各チャンネルごとに設定された頻度に従い、コントロールプレーンが自動アップグレードされる ➢ データプレーンはユーザ管理の場合は手動アップグレードが必要 ➢ 自動アップグレード自体は無効化できない ユーザ管理コントロールプレーンを利用している場合 ➢ サポートが切れる前にユーザによるコントロールプレーン及びデータプレーンの手動アップグレードが必要 ➢ マイナーバージョンを飛ばしたアップグレードは避け、直上へのアップグレードを数回転させることを推奨 © Matt. 2021. All rights reserved. 36

本番環境で無理なくGKE+ASMをアップグレードしていくには 1. アップグレードの存在にいち早く気付く ➢ Pub/SubとCloud Functionsを設定してアップグレードのメッセージ通知をタイムリーに受け取る 2. 自動アップグレードの前にテストを行う ➢ テスト用クラスタを常設し、事前にテスト用クラスタで手動で最新バージョンにあげて動作確認をする 3. なるべくStableチャンネルを使う ➢ バグもアップグレード頻度も少なめにする 4. メンテナンス時間枠を正しく設定する ➢ ビジネス時間と被らないようにする 5. メンテナンス除外枠を正しく設定する ➢ ビジネスのピークタイム (ECサイトのセールなど)は絶対に避けよう ワークフロー例 © Matt. 2021. All rights reserved. 37

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ © Matt. 2021. All rights reserved. 38

ASMの使い方の例 トラフィック制御 ‐ カナリアリリース ‐ パスベースルーティング ‐ ヘッダー情報を基にしたルーティング ‐ カオスエンジニアリング ‐ サーキットブレーカ オブザーバビリティ(可観測性) ‐ ASM Dashboard ‐ ログ・メトリック ‐ 分散トレーシング セキュリティ ‐ Mutual TLS(mTLS) ‐ ASMユーザアクセス制御 ‐ Anthos Security Insights © Matt. 2021. All rights reserved. 39

トラフィック制御 © Matt. 2021. All rights reserved. 40

カナリアリリースの設定例 一般的なカナリアの例 service_b v1 95% service_b v1 service_a : 5% service_b v2 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service_b spec: hosts: - service_b http: - route: - destination: host: service_b subset: v1 weight: 95 - destination: host: service_b subset: v2 weight: 5 © Matt. 2021. All rights reserved. 41

パスベースルーティングの設定例 パスベースルーティングの例 auth frontend webapp apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: webapp spec: hosts: - webapp http: - match: - uri: prefix: "/login" route: - destination: host: auth - route: - destination: host: webapp © Matt. 2021. All rights reserved. 42

ヘッダー情報を基にしたルーティングの設定例 ユーザIDに基づくルーティングの例 service_b v2 matt service_b v1 上記以外 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service_b spec: hosts: - service_b http: - match: - headers: end-user: exact: matt route: - destination: host: service_b subset: v2 - route: - destination: host: service_b subset: v1 © Matt. 2021. All rights reserved. 43

カオスエンジニアリングの設定例 カオスエンジニアリングとは 本番稼働中のサービスにあえて疑似的な障害を起こして、 実際の障害にもちゃんと耐えられるようにするための取り組み 疑似障害注入(Fault Injection)の設定例 ASM(Istio)では疑似障害としてレスポンス遅延を起こしたり、 エラーレスポンスを返却させたりすることが可能 → 例では matt さんからのアクセスの場合だけ7秒だけ遅延を発生 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: service_b spec: hosts: - service_b http: - fault: delay: fixedDelay: 7s percentage: value: 100 match: - headers: end-user: exact: matt route: - destination: host: service_b subset: v1 - route: - destination: host: service_b subset: v1 © Matt. 2021. All rights reserved. 44

サーキットブレーカの設定例 サーキットブレーカとは 他のサービス障害に引きずられて連鎖的に障害を起こして しまうのを抑制するための手法です。 流量制御、外れ値検出の設定例 1. リクエスト数が閾値を超えるとエラーを返却する 2. リクエスト先からエラーが返ってきた場合に 一定期間負荷分散対象から除外する →例では30秒間に5回連続でリクエスト先からエラーが 返ってきたら3分間はそのリクエスト先を振り分け先から外す apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: webapp spec: host: webapp trafficPolicy: connectionPool: tcp: maxConnections: 100 http: http2MaxRequests: 1000 maxRequestsPerConnection: 10 outlierDetection: consecutive5xxErrors: 5 interval: 30s baseEjectionTime: 3m maxEjectionPercent: 100 © Matt. 2021. All rights reserved. 45

オブザーバビリティ(可観測性) © Matt. 2021. All rights reserved. 46

ASM Dashboard ➢ サービス間の依存関係を可視化 ➢ SLO(サービスレベル目標)を使ったサービスレベルの監視、アラート © Matt. 2021. All rights reserved. 47

ログ・メトリック ➢ Cloud Monitoring、Cloud Loggingとの連携 ➢ 監査ログはCloud Audit Logsで取得 ↓Envoyのアクセスログを有効化するには 追加設定が必要だよ © Matt. 2021. All rights reserved. 48

分散トレーシング Envoyの分散トレーシング機能と Cloud Traceとで連携可能 ↓トレーサーにデータを送るには設定が必要だよ！ © Matt. 2021. All rights reserved. 49

セキュリティ © Matt. 2021. All rights reserved. 50

Mutual TLS(mTLS) サーバ⇔クライアント間の相互認証(HTTPS+TLSクライアント認証)を行う。 →サービス間通信を暗号化するケースで利用する。 mTLSは2つのモードが設定可能です。 Permissive: 暗号化された通信と平文どちらも許容(デフォルト) Strict: 暗号化された通信のみ許容 ↓名前空間(Namespace)ごとに設定する場合 ←ワークロードごとに設定する場合 ↓ © Matt. 2021. All rights reserved. 51

ASMユーザアクセス制御 ➢ Identity-Aware Proxy(IAP)によるユーザ認証 https://cloud.google.com/service-mesh/docs/unified-install/options/iap-integration ➢ 既存のIDプロバイダでのユーザ認証 https://cloud.google.com/service-mesh/docs/unified-install/options/end-user-auth © Matt. 2021. All rights reserved. 52

• https://cloud.google.com/service-mesh/docs/unified-install/options/iap-integration
• https://cloud.google.com/service-mesh/docs/unified-install/options/end-user-auth

Anthos Security Insights(プレビュー) © Matt. 2021. All rights reserved. 53

本日のアジェンダ ⚫ サービスメッシュ/ASMの概要 ⚫ ASM(およびIstio)の基礎 ⚫ ASMの設計ポイント ⚫ ASMのアップデート戦略 ⚫ ASMの用例 ⚫ まとめ © Matt. 2021. All rights reserved. 54

まとめ ⚫ サービスメッシュはマイクロサービスの課題を解決するソリューションです。 ⚫ ASMはGoogleサポートを得られるIstioベースのマネージドサービスメッシュです。 ⚫ ASMはGKE以外のKubernetes(オンプレ、他クラウド)でもサポート対象です。 ⚫ 運用をうまく回すには事前のアップグレード戦略の作成がとっても重要です。 © Matt. 2021. All rights reserved. 55

終わりに とはいえ、サービスメッシュ/ASMはまだまだ過渡期、 今日できなかったことが明日できるようになっていても可笑しくありません！ 特に今回の資料で「〇〇は未サポート」「××はプレビュー機能」と記載した部分は、 近い将来、間違いなく情報に変化が起きると思われます！ ご利用の際は、常に最新の情報を公式ドキュメントから入手するよう心がけましょう！ ASM公式ドキュメント: https://cloud.google.com/service-mesh/docs Istio公式ドキュメント: https://istio.io/latest/docs/ © Matt. 2021. All rights reserved. 56

• https://cloud.google.com/service-mesh/docs
• https://istio.io/latest/docs/

END Google Cloud | Anthos Service Mesh(ASM)勉強会 クラウド技術情報共有コミュニティ勉強会 2021年11月15日 株式会社 日立製作所 / Software CoE / クラウドビジネス推進センタ 松沢 敏志 © Matt. 2021. All rights reserved.